idnits 2.17.1 draft-ietf-ospf-version2-05.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 7602 instances of lines with control characters in the document. == There are 50 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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 1388 has weird spacing: '... Area borde...' == Line 1685 has weird spacing: '... Packet name ...' == Line 1687 has weird spacing: '...aintain neigh...' == Line 1719 has weird spacing: '... type name...' == Line 2449 has weird spacing: '...virtual link....' == (14 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 (June 1995) is 10542 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) == Missing Reference: '22' is mentioned on line 6564, but not defined == Missing Reference: '23' is mentioned on line 6675, but not defined == Missing Reference: '24' is mentioned on line 6689, but not defined == Missing Reference: '25' is mentioned on line 6782, but not defined == Missing Reference: '26' is mentioned on line 7211, but not defined -- Looks like a reference, but probably isn't: 'NA' on line 9450 -- Looks like a reference, but probably isn't: 'NM1' on line 9447 -- Looks like a reference, but probably isn't: 'NM2' on line 9450 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Unknown state RFC: RFC 905 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1519 (ref. '10') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1700 (ref. '11') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1349 (ref. '12') (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 1586 (ref. '15') -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '17') ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '18') -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 16 errors (**), 0 flaws (~~), 14 warnings (==), 16 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 4 Expiration Date: December 1995 June 1995 5 File name: draft-ietf-ospf-version2-05.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 ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 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 the current OSPF specification (RFC 1583) 45 and this memo are explained in Appendix F. All differences are 46 backward-compatible in nature. Implementations of RFC 1583 and of 47 this memo will interoperate. 49 Please send comments to ospf@gated.cornell.edu. 51 Table of Contents 53 1 Introduction ........................................... 7 54 1.1 Protocol Overview ...................................... 7 55 1.2 Definitions of commonly used terms ..................... 8 56 1.3 Brief history of link-state routing technology ........ 11 57 1.4 Organization of this document ......................... 12 58 1.5 Acknowledgments ....................................... 13 59 2 The link-state database: organization and calculations 13 60 2.1 Representation of routers and networks ................ 13 61 2.1.1 Representation of non-broadcast networks .............. 15 62 2.1.2 An example link-state database ........................ 16 63 2.2 The shortest-path tree ................................ 20 64 2.3 Use of external routing information ................... 22 65 2.4 Equal-cost multipath .................................. 24 66 2.5 TOS-based routing ..................................... 24 67 3 Splitting the AS into Areas ........................... 25 68 3.1 The backbone of the Autonomous System ................. 26 69 3.2 Inter-area routing .................................... 26 70 3.3 Classification of routers ............................. 27 71 3.4 A sample area configuration ........................... 28 72 3.5 IP subnetting support ................................. 34 73 3.6 Supporting stub areas ................................. 35 74 3.7 Partitions of areas ................................... 36 75 4 Functional Summary .................................... 38 76 4.1 Inter-area routing .................................... 38 77 4.2 AS external routes .................................... 39 78 4.3 Routing protocol packets .............................. 39 79 4.4 Basic implementation requirements ..................... 42 80 4.5 Optional OSPF capabilities ............................ 43 81 5 Protocol data structures .............................. 45 82 6 The Area Data Structure ............................... 46 83 7 Bringing Up Adjacencies ............................... 49 84 7.1 The Hello Protocol .................................... 49 85 7.2 The Synchronization of Databases ...................... 50 86 7.3 The Designated Router ................................. 51 87 7.4 The Backup Designated Router .......................... 52 88 7.5 The graph of adjacencies .............................. 53 89 8 Protocol Packet Processing ............................ 54 90 8.1 Sending protocol packets .............................. 54 91 8.2 Receiving protocol packets ............................ 56 92 9 The Interface Data Structure .......................... 59 93 9.1 Interface states ...................................... 62 94 9.2 Events causing interface state changes ................ 64 95 9.3 The Interface state machine ........................... 66 96 9.4 Electing the Designated Router ........................ 69 97 9.5 Sending Hello packets ................................. 71 98 9.5.1 Sending Hello packets on NBMA networks ................ 72 99 10 The Neighbor Data Structure ........................... 73 100 10.1 Neighbor states ....................................... 76 101 10.2 Events causing neighbor state changes ................. 79 102 10.3 The Neighbor state machine ............................ 81 103 10.4 Whether to become adjacent ............................ 87 104 10.5 Receiving Hello Packets ............................... 87 105 10.6 Receiving Database Description Packets ................ 90 106 10.7 Receiving Link State Request Packets .................. 93 107 10.8 Sending Database Description Packets .................. 93 108 10.9 Sending Link State Request Packets .................... 94 109 10.10 An Example ............................................ 95 110 11 The Routing Table Structure ........................... 97 111 11.1 Routing table lookup ................................. 100 112 11.2 Sample routing table, without areas .................. 101 113 11.3 Sample routing table, with areas ..................... 102 114 12 Link State Advertisements ............................ 104 115 12.1 The Link State Advertisement Header .................. 105 116 12.1.1 LS age ............................................... 106 117 12.1.2 Options .............................................. 106 118 12.1.3 LS type .............................................. 107 119 12.1.4 Link State ID ........................................ 107 120 12.1.5 Advertising Router ................................... 109 121 12.1.6 LS sequence number ................................... 109 122 12.1.7 LS checksum .......................................... 110 123 12.2 The link state database .............................. 111 124 12.3 Representation of TOS ................................ 112 125 12.4 Originating link state advertisements ................ 113 126 12.4.1 Router links ......................................... 116 127 12.4.1.1 Describing point-to-point interfaces ................. 119 128 12.4.1.2 Describing broadcast and NBMA interfaces ............. 120 129 12.4.1.3 Describing virtual links ............................. 121 130 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 121 131 12.4.1.5 Examples of router-LSAs .............................. 121 132 12.4.2 Network links ........................................ 124 133 12.4.2.1 Examples of network-LSAs ............................. 124 134 12.4.3 Summary links ........................................ 125 135 12.4.3.1 Originating summary links into stub areas ............ 128 136 12.4.3.2 Examples of summary-LSAs ............................. 128 137 12.4.4 AS external links .................................... 129 138 12.4.4.1 Examples of AS-external-LSAs ......................... 130 139 13 The Flooding Procedure ............................... 133 140 13.1 Determining which link state is newer ................ 136 141 13.2 Installing link state advertisements in the database . 136 142 13.3 Next step in the flooding procedure .................. 138 143 13.4 Receiving self-originated link state ................. 140 144 13.5 Sending Link State Acknowledgment packets ............ 141 145 13.6 Retransmitting link state advertisements ............. 144 146 13.7 Receiving link state acknowledgments ................. 144 147 14 Aging The Link State Database ........................ 145 148 14.1 Premature aging of advertisements .................... 145 149 15 Virtual Links ........................................ 146 150 16 Calculation of the routing table ..................... 148 151 16.1 Calculating the shortest-path tree for an area ....... 150 152 16.1.1 The next hop calculation ............................. 155 153 16.2 Calculating the inter-area routes .................... 156 154 16.3 Examining transit areas' summary links ............... 158 155 16.4 Calculating AS external routes ....................... 160 156 16.5 Incremental updates -- summary link advertisements ... 162 157 16.6 Incremental updates -- AS external link advertisements 163 158 16.7 Events generated as a result of routing table changes 163 159 16.8 Equal-cost multipath ................................. 164 160 16.9 Building the non-zero-TOS portion of the routing table 164 161 Footnotes ............................................ 167 162 References ........................................... 171 163 A OSPF data formats .................................... 173 164 A.1 Encapsulation of OSPF packets ........................ 173 165 A.2 The Options field .................................... 175 166 A.3 OSPF Packet Formats .................................. 177 167 A.3.1 The OSPF packet header ............................... 178 168 A.3.2 The Hello packet ..................................... 180 169 A.3.3 The Database Description packet ...................... 182 170 A.3.4 The Link State Request packet ........................ 184 171 A.3.5 The Link State Update packet ......................... 186 172 A.3.6 The Link State Acknowledgment packet ................. 188 173 A.4 Link state advertisement formats ..................... 190 174 A.4.1 The Link State Advertisement header .................. 191 175 A.4.2 Router links advertisements .......................... 193 176 A.4.3 Network links advertisements ......................... 197 177 A.4.4 Summary link advertisements .......................... 199 178 A.4.5 AS external link advertisements ...................... 201 179 B Architectural Constants .............................. 203 180 C Configurable Constants ............................... 205 181 C.1 Global parameters .................................... 205 182 C.2 Area parameters ...................................... 205 183 C.3 Router interface parameters .......................... 207 184 C.4 Virtual link parameters .............................. 209 185 C.5 NBMA network parameters .............................. 210 186 C.6 Point-to-Point network parameters .................... 210 187 C.7 Host route parameters ................................ 211 188 D Authentication ....................................... 212 189 D.1 Null authentication .................................. 212 190 D.2 Simple password authentication ....................... 212 191 D.3 Cryptographic authentication ......................... 213 192 D.4 Message generation ................................... 215 193 D.4.1 Generating Null authentication ....................... 215 194 D.4.2 Generating Simple password authentication ............ 216 195 D.4.3 Generating Cryptographic authentication .............. 216 196 D.5 Message verification ................................. 217 197 D.5.1 Verifying Null authentication ........................ 218 198 D.5.2 Verifying Simple password authentication ............. 218 199 D.5.3 Verifying Cryptographic authentication ............... 218 200 E An algorithm for assigning Link State IDs ............ 220 201 F Differences from RFC 1583 ............................ 222 202 F.1 Enhancements to OSPF authentication .................. 222 203 F.2 Addition of Point-to-MultiPoint interface ............ 222 204 F.3 Support for overlapping area ranges .................. 223 205 F.4 A modification to the flooding algorithm ............. 224 206 F.5 Introduction of the MinLSArrival constant ............ 224 207 F.6 Optionally advertising point-to-point links as subnets 225 208 Security Considerations .............................. 226 209 Author's Address ..................................... 226 210 1. Introduction 212 This document is a specification of the Open Shortest Path First 213 (OSPF) TCP/IP internet routing protocol. OSPF is classified as an 214 Interior Gateway Protocol (IGP). This means that it distributes 215 routing information between routers belonging to a single Autonomous 216 System. The OSPF protocol is based on link-state or SPF technology. 217 This is a departure from the Bellman-Ford base used by traditional 218 TCP/IP internet routing protocols. 220 The OSPF protocol was developed by the OSPF working group of the 221 Internet Engineering Task Force. It has been designed expressly for 222 the TCP/IP internet environment, including explicit support for IP 223 subnetting, TOS-based routing and the tagging of externally-derived 224 routing information. OSPF also provides for the authentication of 225 routing updates, and utilizes IP multicast when sending/receiving 226 the updates. In addition, much work has been done to produce a 227 protocol that responds quickly to topology changes, yet involves 228 small amounts of routing protocol traffic. 230 1.1. Protocol overview 232 OSPF routes IP packets based solely on the destination IP 233 address and IP Type of Service found in the IP packet header. 234 IP packets are routed "as is" -- they are not encapsulated in 235 any further protocol headers as they transit the Autonomous 236 System. OSPF is a dynamic routing protocol. It quickly detects 237 topological changes in the AS (such as router interface 238 failures) and calculates new loop-free routes after a period of 239 convergence. This period of convergence is short and involves a 240 minimum of routing traffic. 242 In a link-state routing protocol, each router maintains a 243 database describing the Autonomous System's topology. This 244 database is referred to as the link-state database. Each 245 participating router has an identical database. Each individual 246 piece of this database is a particular router's local state 247 (e.g., the router's usable interfaces and reachable neighbors). 248 The router distributes its local state throughout the Autonomous 249 System by flooding. 251 All routers run the exact same algorithm, in parallel. From the 252 link-state database, each router constructs a tree of shortest 253 paths with itself as root. This shortest-path tree gives the 254 route to each destination in the Autonomous System. Externally 255 derived routing information appears on the tree as leaves. 257 OSPF calculates separate routes for each Type of Service (TOS). 259 When several equal-cost routes to a destination exist, traffic 260 is distributed equally among them. The cost of a route is 261 described by a single dimensionless metric. 263 OSPF allows sets of networks to be grouped together. Such a 264 grouping is called an area. The topology of an area is hidden 265 from the rest of the Autonomous System. This information hiding 266 enables a significant reduction in routing traffic. Also, 267 routing within the area is determined only by the area's own 268 topology, lending the area protection from bad routing data. An 269 area is a generalization of an IP subnetted network. 271 OSPF enables the flexible configuration of IP subnets. Each 272 route distributed by OSPF has a destination and mask. Two 273 different subnets of the same IP network number may have 274 different sizes (i.e., different masks). This is commonly 275 referred to as variable length subnetting. A packet is routed 276 to the best (i.e., longest or most specific) match. Host routes 277 are considered to be subnets whose masks are "all ones" 278 (0xffffffff). 280 All OSPF protocol exchanges are authenticated. This means that 281 only trusted routers can participate in the Autonomous System's 282 routing. A variety of authentication schemes can be used; in 283 fact, separate authentication schemes can be configured for each 284 IP subnet. 286 Externally derived routing data (e.g., routes learned from the 287 Exterior Gateway Protocol (EGP)) is advertised throughout the 288 Autonomous System. This externally derived data is kept 289 separate from the OSPF protocol's link state data. Each 290 external route can also be tagged by the advertising router, 291 enabling the passing of additional information between routers 292 on the boundary of the Autonomous System. 294 1.2. Definitions of commonly used terms 296 This section provides definitions for terms that have a specific 297 meaning to the OSPF protocol and that are used throughout the 298 text. The reader unfamiliar with the Internet Protocol Suite is 299 referred to [13] for an introduction to IP. 301 Router 302 A level three Internet Protocol packet switch. Formerly 303 called a gateway in much of the IP literature. 305 Autonomous System 306 A group of routers exchanging routing information via a 307 common routing protocol. Abbreviated as AS. 309 Interior Gateway Protocol 310 The routing protocol spoken by the routers belonging to an 311 Autonomous system. Abbreviated as IGP. Each Autonomous 312 System has a single IGP. Separate Autonomous Systems may be 313 running different IGPs. 315 Router ID 316 A 32-bit number assigned to each router running the OSPF 317 protocol. This number uniquely identifies the router within 318 an Autonomous System. 320 Network 321 In this memo, an IP network/subnet/supernet. It is possible 322 for one physical network to be assigned multiple IP 323 network/subnet numbers. We consider these to be separate 324 networks. Point-to-point physical networks are an exception 325 - they are considered a single network no matter how many 326 (if any at all) IP network/subnet numbers are assigned to 327 them. 329 Network mask 330 A 32-bit number indicating the range of IP addresses 331 residing on a single IP network/subnet/supernet. This 332 specification displays network masks as hexadecimal numbers. 333 For example, the network mask for a class C IP network is 334 displayed as 0xffffff00. Such a mask is often displayed 335 elsewhere in the literature as 255.255.255.0. 337 Point-to-point networks 338 A network that joins a single pair of routers. A 56Kb 339 serial line is an example of a point-to-point network. 341 Broadcast networks 342 Networks supporting many (more than two) attached routers, 343 together with the capability to address a single physical 344 message to all of the attached routers (broadcast). 345 Neighboring routers are discovered dynamically on these nets 346 using OSPF's Hello Protocol. The Hello Protocol itself 347 takes advantage of the broadcast capability. The OSPF 348 protocol makes further use of multicast capabilities, if 349 they exist. Each pair of routers on a broadcast network is 350 assumed to be able to communicate directly. An ethernet is 351 an example of a broadcast network. 353 Non-broadcast networks 354 Networks supporting many (more than two) routers, but having 355 no broadcast capability. Neighboring routers are maintained 356 on these nets using OSPF's Hello Protocol. However, due to 357 the lack of broadcast capability, some configuration 358 information may be necessary to aid in the discovery of 359 neighbors. On non-broadcast networks, OSPF protocol packets 360 that are normally multicast need to be sent to each 361 neighboring router, in turn. An X.25 Public Data Network 362 (PDN) is an example of a non-broadcast network. 364 OSPF runs in one of two modes over non-broadcast networks. 365 The first mode, called non-broadcast multi-access or NBMA, 366 simulates the operation of OSPF on a broadcast network. The 367 second mode, called Point-to-MultiPoint, treats the non- 368 broadcast network as a collection of point-to-point links. 369 Non-broadcast networks are referred to as NBMA networks or 370 Point-to-MultiPoint networks, depending on OSPF's mode of 371 operation over the network. 373 Interface 374 The connection between a router and one of its attached 375 networks. An interface has state information associated 376 with it, which is obtained from the underlying lower level 377 protocols and the routing protocol itself. An interface to 378 a network has associated with it a single IP address and 379 mask (unless the network is an unnumbered point-to-point 380 network). An interface is sometimes also referred to as a 381 link. 383 Neighboring routers 384 Two routers that have interfaces to a common network. 385 Neighbor relationships are maintained by, and usually 386 dynamically discovered by, OSPF's Hello Protocol. 388 Adjacency 389 A relationship formed between selected neighboring routers 390 for the purpose of exchanging routing information. Not 391 every pair of neighboring routers become adjacent. 393 Link state advertisement 394 Unit of data describing the local state of a router or 395 network. For a router, this includes the state of the 396 router's interfaces and adjacencies. Each link state 397 advertisement is flooded throughout the routing domain. The 398 collected link state advertisements of all routers and 399 networks forms the protocol's link state database. 400 Throughout this memo, link state advertisement is 401 abbreviated as LSA. 403 Hello Protocol 404 The part of the OSPF protocol used to establish and maintain 405 neighbor relationships. On broadcast networks the Hello 406 Protocol can also dynamically discover neighboring routers. 408 Flooding 409 The part of the OSPF protocol that distributes and 410 synchronizes the link-state database between OSPF routers. 412 Designated Router 413 Each broadcast and NBMA network that has at least two 414 attached routers has a Designated Router. The Designated 415 Router generates a link state advertisement for the network 416 and has other special responsibilities in the running of the 417 protocol. The Designated Router is elected by the Hello 418 Protocol. 420 The Designated Router concept enables a reduction in the 421 number of adjacencies required on a broadcast or NBMA 422 network. This in turn reduces the amount of routing 423 protocol traffic and the size of the link-state database. 425 Lower-level protocols 426 The underlying network access protocols that provide 427 services to the Internet Protocol and in turn the OSPF 428 protocol. Examples of these are the X.25 packet and frame 429 levels for X.25 PDNs, and the ethernet data link layer for 430 ethernets. 432 1.3. Brief history of link-state routing technology 434 OSPF is a link state routing protocol. Such protocols are also 435 referred to in the literature as SPF-based or distributed- 436 database protocols. This section gives a brief description of 437 the developments in link-state technology that have influenced 438 the OSPF protocol. 440 The first link-state routing protocol was developed for use in 441 the ARPANET packet switching network. This protocol is 442 described in [3]. It has formed the starting point for all 443 other link-state protocols. The homogeneous ARPANET 444 environment, i.e., single-vendor packet switches connected by 445 synchronous serial lines, simplified the design and 446 implementation of the original protocol. 448 Modifications to this protocol were proposed in [4]. These 449 modifications dealt with increasing the fault tolerance of the 450 routing protocol through, among other things, adding a checksum 451 to the link state advertisements (thereby detecting database 452 corruption). The paper also included means for reducing the 453 routing traffic overhead in a link-state protocol. This was 454 accomplished by introducing mechanisms which enabled the 455 interval between link state advertisement originations to be 456 increased by an order of magnitude. 458 A link-state algorithm has also been proposed for use as an ISO 459 IS-IS routing protocol. This protocol is described in [2]. The 460 protocol includes methods for data and routing traffic reduction 461 when operating over broadcast networks. This is accomplished by 462 election of a Designated Router for each broadcast network, 463 which then originates a link state advertisement for the 464 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 a link-state 621 advertisement for the network. The graph representation for 622 broadcast networks and NBMA networks is identical. This 623 representation is pictured 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 [15]). This however requires quite a 639 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 a link-state advertisement 647 generated for the network. In fact, a vertex for the Point- 648 to-MultiPoint network does not appear in the graph of the 649 link-state 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 [14]) 666 will allow autodiscovery of OSPF neighbors even though 667 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 EGP connections to other Autonomous Systems. A set of EGP- 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 EGP-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 link state 801 advertisements generated by the routers. In the associated 802 graphical representation, the neighborhood of each router or 803 transit network is represented in a single, separate link 804 state advertisement. Figure 4 shows these link-state 805 advertisements graphically. Router RT12 has an interface to 806 two broadcast networks and a SLIP line to a host. Network 807 N6 is a broadcast network with three attached routers. The 808 cost of all links from Network N6 to its attached routers is 809 0. Note that the link state advertisement for Network N6 is 810 actually generated by one of the network's attached routers: 811 the router that has been elected Designated Router for the 812 network. 814 2.2. The shortest-path tree 816 When no OSPF areas are configured, each router in the Autonomous 817 System has an identical link-state database, leading to an 818 identical graphical representation. A router generates its 819 routing table from this graph by calculating a tree of shortest 820 paths with the router itself as root. Obviously, the shortest- 821 path tree depends on the router doing the calculation. The 822 shortest-path tree for Router RT6 in our example is depicted in 823 Figure 5. 825 The tree gives the entire path to any destination network or 826 host. However, only the next hop to the destination is used in 827 the forwarding process. Note also that the best route to any 828 router has also been calculated. For the processing of external 829 data, we note the next hop and distance to any router 830 advertising external routes. The resulting routing table for 831 Router RT6 is pictured in Table 2. Note that there is a 832 separate route for each end of a numbered point-to-point network 833 (in this case, the serial line between Routers RT6 and RT10). 835 **FROM** **FROM** 837 |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| 838 * -------------------- * ---------------------- 839 * RT12| | | | | * RT9| | | |0 | 840 T N9|1 | | | | T RT11| | | |0 | 841 O N10|2 | | | | O RT12| | | |0 | 842 * H1|10 | | | | * N9| | | | | 843 * * 844 RT12's router links N9's network links 845 advertisement advertisement 847 Figure 4: Individual link state components 849 Networks and routers are represented by vertices. 850 An edge of cost X connects Vertex A to Vertex B iff 851 the intersection of Column A and Row B is marked 852 with an X. 854 RT6(origin) 855 RT5 o------------o-----------o Ib 856 /|\ 6 |\ 7 857 8/8|8\ | \ 858 / | \ | \ 859 o | o | \7 860 N12 o N14 | \ 861 N13 2 | \ 862 N4 o-----o RT3 \ 863 / \ 5 864 1/ RT10 o-------o Ia 865 / |\ 866 RT4 o-----o N3 3| \1 867 /| | \ N6 RT7 868 / | N8 o o---------o 869 / | | | /| 870 RT2 o o RT1 | | 2/ |9 871 / | | |RT8 / | 872 /3 |3 RT11 o o o o 873 / | | | N12 N15 874 N2 o o N1 1| |4 875 | | 876 N9 o o N7 877 /| 878 / | 879 N11 RT9 / |RT12 880 o--------o-------o o--------o H1 881 3 | 10 882 |2 883 | 884 o N10 886 Figure 5: The SPF tree for Router RT6 888 Edges that are not marked with a cost have a cost of 889 of zero (these are network-to-router links). Routes 890 to networks N12-N15 are external information that is 891 considered in Section 2.3 893 Routes to networks belonging to other AS'es (such as N12) appear 894 as dashed lines on the shortest path tree in Figure 5. Use of 895 this externally derived routing information is considered in the 896 next section. 898 Destination Next Hop Distance 899 __________________________________ 900 N1 RT3 10 901 N2 RT3 10 902 N3 RT3 7 903 N4 RT3 8 904 Ib * 7 905 Ia RT10 12 906 N6 RT10 8 907 N7 RT10 12 908 N8 RT10 10 909 N9 RT10 11 910 N10 RT10 13 911 N11 RT10 14 912 H1 RT10 21 913 __________________________________ 914 RT5 RT5 6 915 RT7 RT10 8 917 Table 2: The portion of Router RT6's routing table listing local 918 destinations. 920 2.3. Use of external routing information 922 After the tree is created the external routing information is 923 examined. This external routing information may originate from 924 another routing protocol such as EGP, or be statically 925 configured (static routes). Default routes can also be included 926 as part of the Autonomous System's external routing information. 928 External routing information is flooded unaltered throughout the 929 AS. In our example, all the routers in the Autonomous System 930 know that Router RT7 has two external routes, with metrics 2 and 931 9. 933 OSPF supports two types of external metrics. Type 1 external 934 metrics are expressed in the same units as OSPF interface cost 935 (i.e., in terms of the link state metric). Type 2 external 936 metrics are an order of magnitude larger; any Type 2 metric is 937 considered greater than the cost of any path internal to the AS. 938 Use of Type 2 external metrics assumes that routing between 939 AS'es is the major cost of routing a packet, and eliminates the 940 need for conversion of external costs to internal link state 941 metrics. 943 As an example of Type 1 external metric processing, suppose that 944 the Routers RT7 and RT5 in Figure 2 are advertising Type 1 945 external metrics. For each advertised external route, the total 946 cost from Router RT6 is calculated as the sum of the external 947 route's advertised cost and the distance from Router RT6 to the 948 advertising router. When two routers are advertising the same 949 external destination, RT6 picks the advertising router providing 950 the minimum total cost. RT6 then sets the next hop to the 951 external destination equal to the next hop that would be used 952 when routing packets to the chosen advertising router. 954 In Figure 2, both Router RT5 and RT7 are advertising an external 955 route to destination Network N12. Router RT7 is preferred since 956 it is advertising N12 at a distance of 10 (8+2) to Router RT6, 957 which is better than Router RT5's 14 (6+8). Table 3 shows the 958 entries that are added to the routing table when external routes 959 are examined: 961 Destination Next Hop Distance 962 __________________________________ 963 N12 RT10 10 964 N13 RT5 14 965 N14 RT5 14 966 N15 RT10 17 968 Table 3: The portion of Router RT6's routing table 969 listing external destinations. 971 Processing of Type 2 external metrics is simpler. The AS 972 boundary router advertising the smallest external metric is 973 chosen, regardless of the internal distance to the AS boundary 974 router. Suppose in our example both Router RT5 and Router RT7 975 were advertising Type 2 external routes. Then all traffic 976 destined for Network N12 would be forwarded to Router RT7, since 977 2 < 8. When several equal-cost Type 2 routes exist, the 978 internal distance to the advertising routers is used to break 979 the tie. 981 Both Type 1 and Type 2 external metrics can be present in the AS 982 at the same time. In that event, Type 1 external metrics always 983 take precedence. 985 This section has assumed that packets destined for external 986 destinations are always routed through the advertising AS 987 boundary router. This is not always desirable. For example, 988 suppose in Figure 2 there is an additional router attached to 989 Network N6, called Router RTX. Suppose further that RTX does 990 not participate in OSPF routing, but does exchange EGP 991 information with the AS boundary router RT7. Then, Router RT7 992 would end up advertising OSPF external routes for all 993 destinations that should be routed to RTX. An extra hop will 994 sometimes be introduced if packets for these destinations need 995 always be routed first to Router RT7 (the advertising router). 997 To deal with this situation, the OSPF protocol allows an AS 998 boundary router to specify a "forwarding address" in its 999 external advertisements. In the above example, Router RT7 would 1000 specify RTX's IP address as the "forwarding address" for all 1001 those destinations whose packets should be routed directly to 1002 RTX. 1004 The "forwarding address" has one other application. It enables 1005 routers in the Autonomous System's interior to function as 1006 "route servers". For example, in Figure 2 the router RT6 could 1007 become a route server, gaining external routing information 1008 through a combination of static configuration and external 1009 routing protocols. RT6 would then start advertising itself as 1010 an AS boundary router, and would originate a collection of OSPF 1011 external advertisements. In each external advertisement, Router 1012 RT6 would specify the correct Autonomous System exit point to 1013 use for the destination through appropriate setting of the 1014 advertisement's "forwarding address" field. 1016 2.4. Equal-cost multipath 1018 The above discussion has been simplified by considering only a 1019 single route to any destination. In reality, if multiple 1020 equal-cost routes to a destination exist, they are all 1021 discovered and used. This requires no conceptual changes to the 1022 algorithm, and its discussion is postponed until we consider the 1023 tree-building process in more detail. 1025 With equal cost multipath, a router potentially has several 1026 available next hops towards any given destination. 1028 2.5. TOS-based routing 1030 OSPF can calculate a separate set of routes for each IP Type of 1031 Service. This means that, for any destination, there can 1032 potentially be multiple routing table entries, one for each IP 1033 TOS. The IP TOS values are represented in OSPF exactly as they 1034 appear in the IP packet header. 1036 Up to this point, all examples shown have assumed that routes do 1037 not vary on TOS. In order to differentiate routes based on TOS, 1038 separate interface costs can be configured for each TOS. For 1039 example, in Figure 2 there could be multiple costs (one for each 1040 TOS) listed for each interface. A cost for TOS 0 must always be 1041 specified. 1043 When interface costs vary based on TOS, a separate shortest path 1044 tree is calculated for each TOS (see Section 2.2). In addition, 1045 external costs can vary based on TOS. For example, in Figure 2 1046 Router RT7 could advertise a separate type 1 external metric for 1047 each TOS. Then, when calculating the TOS X distance to Network 1048 N15 the cost of the shortest TOS X path to RT7 would be added to 1049 the TOS X cost advertised by RT7 for Network N15 (see Section 1050 2.3). 1052 All OSPF implementations must be capable of calculating routes 1053 based on TOS. However, OSPF routers can be configured to route 1054 all packets on the TOS 0 path (see Appendix C), eliminating the 1055 need to calculate non-zero TOS paths. This can be used to 1056 conserve routing table space and processing resources in the 1057 router. These TOS-0-only routers can be mixed with routers that 1058 do route based on TOS. TOS-0-only routers will be avoided as 1059 much as possible when forwarding traffic requesting a non-zero 1060 TOS. 1062 It may be the case that no path exists for some non-zero TOS, 1063 even if the router is calculating non-zero TOS paths. In that 1064 case, packets requesting that non-zero TOS are routed along the 1065 TOS 0 path (see Section 11.1). 1067 3. Splitting the AS into Areas 1069 OSPF allows collections of contiguous networks and hosts to be 1070 grouped together. Such a group, together with the routers having 1071 interfaces to any one of the included networks, is called an area. 1072 Each area runs a separate copy of the basic link-state routing 1073 algorithm. This means that each area has its own link-state 1074 database and corresponding graph, as explained in the previous 1075 section. 1077 The topology of an area is invisible from the outside of the area. 1078 Conversely, routers internal to a given area know nothing of the 1079 detailed topology external to the area. This isolation of knowledge 1080 enables the protocol to effect a marked reduction in routing traffic 1081 as compared to treating the entire Autonomous System as a single 1082 link-state domain. 1084 With the introduction of areas, it is no longer true that all 1085 routers in the AS have an identical link-state database. A router 1086 actually has a separate link-state database for each area it is 1087 connected to. (Routers connected to multiple areas are called area 1088 border routers). Two routers belonging to the same area have, for 1089 that area, identical area link-state databases. 1091 Routing in the Autonomous System takes place on two levels, 1092 depending on whether the source and destination of a packet reside 1093 in the same area (intra-area routing is used) or different areas 1094 (inter-area routing is used). In intra-area routing, the packet is 1095 routed solely on information obtained within the area; no routing 1096 information obtained from outside the area can be used. This 1097 protects intra-area routing from the injection of bad routing 1098 information. We discuss inter-area routing in Section 3.2. 1100 3.1. The backbone of the Autonomous System 1102 The OSPF backbone is the special OSPF Area 0 (often written as 1103 Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP 1104 addresses). The OSPF backbone always contains all area border 1105 routers. The backbone is responsible for distributing routing 1106 information between non-backbone areas. The backbone must be 1107 contiguous. However, it need not be physically contiguous; 1108 backbone connectivity can be established/maintained through the 1109 configuration of virtual links. 1111 Virtual links can be configured between any two backbone routers 1112 that have an interface to a common non-backbone area. Virtual 1113 links belong to the backbone. The protocol treats two routers 1114 joined by a virtual link as if they were connected by an 1115 unnumbered point-to-point backbone network. On the graph of the 1116 backbone, two such routers are joined by arcs whose costs are 1117 the intra-area distances between the two routers. The routing 1118 protocol traffic that flows along the virtual link uses intra- 1119 area routing only. 1121 3.2. Inter-area routing 1123 When routing a packet between two non-backbone areas the 1124 backbone is used. The path that the packet will travel can be 1125 broken up into three contiguous pieces: an intra-area path from 1126 the source to an area border router, a backbone path between the 1127 source and destination areas, and then another intra-area path 1128 to the destination. The algorithm finds the set of such paths 1129 that have the smallest cost. 1131 Looking at this another way, inter-area routing can be pictured 1132 as forcing a star configuration on the Autonomous System, with 1133 the backbone as hub and each of the non-backbone areas as 1134 spokes. 1136 The topology of the backbone dictates the backbone paths used 1137 between areas. The topology of the backbone can be enhanced by 1138 adding virtual links. This gives the system administrator some 1139 control over the routes taken by inter-area traffic. 1141 The correct area border router to use as the packet exits the 1142 source area is chosen in exactly the same way routers 1143 advertising external routes are chosen. Each area border router 1144 in an area summarizes for the area its cost to all networks 1145 external to the area. After the SPF tree is calculated for the 1146 area, routes to all inter-area destinations are calculated by 1147 examining the summaries of the area border routers. 1149 3.3. Classification of routers 1151 Before the introduction of areas, the only OSPF routers having a 1152 specialized function were those advertising external routing 1153 information, such as Router RT5 in Figure 2. When the AS is 1154 split into OSPF areas, the routers are further divided according 1155 to function into the following four overlapping categories: 1157 Internal routers 1158 A router with all directly connected networks belonging to 1159 the same area. These routers run a single copy of the basic 1160 routing algorithm. 1162 Area border routers 1163 A router that attaches to multiple areas. Area border 1164 routers run multiple copies of the basic algorithm, one copy 1165 for each attached area. Area border routers condense the 1166 topological information of their attached areas for 1167 distribution to the backbone. The backbone in turn 1168 distributes the information to the other areas. 1170 Backbone routers 1171 A router that has an interface to the backbone area. This 1172 includes all routers that interface to more than one area 1173 (i.e., area border routers). However, backbone routers do 1174 not have to be area border routers. Routers with all 1175 interfaces connecting to the backbone area are supported. 1177 AS boundary routers 1178 A router that exchanges routing information with routers 1179 belonging to other Autonomous Systems. Such a router 1180 advertises AS external routing information throughout the 1181 Autonomous System. The path to each AS boundary router is 1182 known by every router in the AS. This classification is 1183 completely independent of the previous classifications: AS 1184 boundary routers may be internal or area border routers, and 1185 may or may not participate in the backbone. 1187 3.4. A sample area configuration 1189 Figure 6 shows a sample area configuration. The first area 1190 consists of networks N1-N4, along with their attached routers 1191 RT1-RT4. The second area consists of networks N6-N8, along with 1192 their attached routers RT7, RT8, RT10 and RT11. The third area 1193 consists of networks N9-N11 and Host H1, along with their 1194 attached routers RT9, RT11 and RT12. The third area has been 1195 configured so that networks N9-N11 and Host H1 will all be 1196 grouped into a single route, when advertised external to the 1197 area (see Section 3.5 for more details). 1199 In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are 1200 internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area 1201 border routers. Finally, as before, Routers RT5 and RT7 are AS 1202 boundary routers. 1204 Figure 7 shows the resulting link-state database for the Area 1. 1205 The figure completely describes that area's intra-area routing. 1206 It also shows the complete view of the internet for the two 1207 internal routers RT1 and RT2. It is the job of the area border 1208 routers, RT3 and RT4, to advertise into Area 1 the distances to 1209 all destinations external to the area. These are indicated in 1210 Figure 7 by the dashed stub routes. Also, RT3 and RT4 must 1211 advertise into Area 1 the location of the AS boundary routers 1212 RT5 and RT7. Finally, external advertisements from RT5 and RT7 1213 are flooded throughout the entire AS, and in particular 1214 throughout Area 1. These advertisements are included in Area 1215 1's database, and yield routes to Networks N12-N15. 1217 Routers RT3 and RT4 must also summarize Area 1's topology for 1218 distribution to the backbone. Their backbone advertisements are 1219 ........................... 1220 . + . 1221 . | 3+---+ . N12 N14 1222 . N1|--|RT1|\ 1 . \ N13 / 1223 . | +---+ \ . 8\ |8/8 1224 . + \ ____ . \|/ 1225 . / \ 1+---+8 8+---+6 1226 . * N3 *---|RT4|------|RT5|--------+ 1227 . \____/ +---+ +---+ | 1228 . + / \ . |7 | 1229 . | 3+---+ / \ . | | 1230 . N2|--|RT2|/1 1\ . |6 | 1231 . | +---+ +---+8 6+---+ | 1232 . + |RT3|------|RT6| | 1233 . +---+ +---+ | 1234 . 2/ . Ia|7 | 1235 . / . | | 1236 . +---------+ . | | 1237 .Area 1 N4 . | | 1238 ........................... | | 1239 .......................... | | 1240 . N11 . | | 1241 . +---------+ . | | 1242 . | . | | N12 1243 . |3 . Ib|5 |6 2/ 1244 . +---+ . +----+ +---+/ 1245 . |RT9| . .........|RT10|.....|RT7|---N15. 1246 . +---+ . . +----+ +---+ 9 . 1247 . |1 . . + /3 1\ |1 . 1248 . _|__ . . | / \ __|_ . 1249 . / \ 1+----+2 |/ \ / \ . 1250 . * N9 *------|RT11|----| * N6 * . 1251 . \____/ +----+ | \____/ . 1252 . | . . | | . 1253 . |1 . . + |1 . 1254 . +--+ 10+----+ . . N8 +---+ . 1255 . |H1|-----|RT12| . . |RT8| . 1256 . +--+SLIP +----+ . . +---+ . 1257 . |2 . . |4 . 1258 . | . . | . 1259 . +---------+ . . +--------+ . 1260 . N10 . . N7 . 1261 . . .Area 2 . 1262 .Area 3 . ................................ 1263 .......................... 1265 Figure 6: A sample OSPF area configuration 1266 shown in Table 4. These summaries show which networks are 1267 contained in Area 1 (i.e., Networks N1-N4), and the distance to 1268 these networks from the routers RT3 and RT4 respectively. 1270 The link-state database for the backbone is shown in Figure 8. 1271 The set of routers pictured are the backbone routers. Router 1272 RT11 is a backbone router because it belongs to two areas. In 1273 order to make the backbone connected, a virtual link has been 1274 configured between Routers R10 and R11. 1276 The area border routers RT3, RT4, RT7, RT10 and RT11 condense 1277 the routing information of their attached non-backbone areas for 1278 distribution via the backbone; these are the dashed stubs that 1279 appear in Figure 8. Remember that the third area has been 1280 configured to condense Networks N9-N11 and Host H1 into a single 1281 route. This yields a single dashed line for networks N9-N11 and 1282 Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary 1283 routers; their externally derived information also appears on 1284 the graph in Figure 8 as stubs. 1286 The backbone enables the exchange of summary information between 1287 area border routers. Every area border router hears the area 1288 summaries from all other area border routers. It then forms a 1289 picture of the distance to all networks outside of its area by 1290 examining the collected advertisements, and adding in the 1291 backbone distance to each advertising router. 1293 Again using Routers RT3 and RT4 as an example, the procedure 1294 goes as follows: They first calculate the SPF tree for the 1295 backbone. This gives the distances to all other area border 1296 routers. Also noted are the distances to networks (Ia and Ib) 1297 and AS boundary routers (RT5 and RT7) that belong to the 1298 backbone. This calculation is shown in Table 5. 1300 Network RT3 adv. RT4 adv. 1301 _____________________________ 1302 N1 4 4 1303 N2 4 4 1304 N3 1 1 1305 N4 2 3 1307 Table 4: Networks advertised to the backbone 1308 by Routers RT3 and RT4. 1310 **FROM** 1312 |RT|RT|RT|RT|RT|RT| 1313 |1 |2 |3 |4 |5 |7 |N3| 1314 ----- ------------------- 1315 RT1| | | | | | |0 | 1316 RT2| | | | | | |0 | 1317 RT3| | | | | | |0 | 1318 * RT4| | | | | | |0 | 1319 * RT5| | |14|8 | | | | 1320 T RT7| | |20|14| | | | 1321 O N1|3 | | | | | | | 1322 * N2| |3 | | | | | | 1323 * N3|1 |1 |1 |1 | | | | 1324 N4| | |2 | | | | | 1325 Ia,Ib| | |15|22| | | | 1326 N6| | |16|15| | | | 1327 N7| | |20|19| | | | 1328 N8| | |18|18| | | | 1329 N9-N11,H1| | |19|16| | | | 1330 N12| | | | |8 |2 | | 1331 N13| | | | |8 | | | 1332 N14| | | | |8 | | | 1333 N15| | | | | |9 | | 1335 Figure 7: Area 1's Database. 1337 Networks and routers are represented by vertices. 1338 An edge of cost X connects Vertex A to Vertex B iff 1339 the intersection of Column A and Row B is marked 1340 with an X. 1342 **FROM** 1344 |RT|RT|RT|RT|RT|RT|RT 1345 |3 |4 |5 |6 |7 |10|11| 1346 ------------------------ 1347 RT3| | | |6 | | | | 1348 RT4| | |8 | | | | | 1349 RT5| |8 | |6 |6 | | | 1350 RT6|8 | |7 | | |5 | | 1351 RT7| | |6 | | | | | 1352 * RT10| | | |7 | | |2 | 1353 * RT11| | | | | |3 | | 1354 T N1|4 |4 | | | | | | 1355 O N2|4 |4 | | | | | | 1356 * N3|1 |1 | | | | | | 1357 * N4|2 |3 | | | | | | 1358 Ia| | | | | |5 | | 1359 Ib| | | |7 | | | | 1360 N6| | | | |1 |1 |3 | 1361 N7| | | | |5 |5 |7 | 1362 N8| | | | |4 |3 |2 | 1363 N9-N11,H1| | | | | | |1 | 1364 N12| | |8 | |2 | | | 1365 N13| | |8 | | | | | 1366 N14| | |8 | | | | | 1367 N15| | | | |9 | | | 1369 Figure 8: The backbone's database. 1371 Networks and routers are represented by vertices. 1372 An edge of cost X connects Vertex A to Vertex B iff 1373 the intersection of Column A and Row B is marked 1374 with an X. 1376 Next, by looking at the area summaries from these area border 1377 routers, RT3 and RT4 can determine the distance to all networks 1378 outside their area. These distances are then advertised 1379 internally to the area by RT3 and RT4. The advertisements that 1380 Router RT3 and RT4 will make into Area 1 are shown in Table 6. 1381 Note that Table 6 assumes that an area range has been configured 1382 for the backbone which groups Ia and Ib into a single 1383 advertisement. 1385 The information imported into Area 1 by Routers RT3 and RT4 1386 enables an internal router, such as RT1, to choose an area 1387 border router intelligently. Router RT1 would use RT4 for 1388 Area border dist from dist from 1389 router RT3 RT4 1390 ______________________________________ 1391 to RT3 * 21 1392 to RT4 22 * 1393 to RT7 20 14 1394 to RT10 15 22 1395 to RT11 18 25 1396 ______________________________________ 1397 to Ia 20 27 1398 to Ib 15 22 1399 ______________________________________ 1400 to RT5 14 8 1401 to RT7 20 14 1403 Table 5: Backbone distances calculated 1404 by Routers RT3 and RT4. 1406 Destination RT3 adv. RT4 adv. 1407 _________________________________ 1408 Ia,Ib 15 22 1409 N6 16 15 1410 N7 20 19 1411 N8 18 18 1412 N9-N11,H1 19 26 1413 _________________________________ 1414 RT5 14 8 1415 RT7 20 14 1417 Table 6: Destinations advertised into Area 1 1418 by Routers RT3 and RT4. 1420 traffic to Network N6, RT3 for traffic to Network N10, and would 1421 load share between the two for traffic to Network N8. 1423 Router RT1 can also determine in this manner the shortest path 1424 to the AS boundary routers RT5 and RT7. Then, by looking at RT5 1425 and RT7's external advertisements, Router RT1 can decide between 1426 RT5 or RT7 when sending to a destination in another Autonomous 1427 System (one of the networks N12-N15). 1429 Note that a failure of the line between Routers RT6 and RT10 1430 will cause the backbone to become disconnected. Configuring a 1431 virtual link between Routers RT7 and RT10 will give the backbone 1432 more connectivity and more resistance to such failures. 1434 3.5. IP subnetting support 1436 OSPF attaches an IP address mask to each advertised route. The 1437 mask indicates the range of addresses being described by the 1438 particular route. For example, a summary advertisement for the 1439 destination 128.185.0.0 with a mask of 0xffff0000 actually is 1440 describing a single route to the collection of destinations 1441 128.185.0.0 - 128.185.255.255. Similarly, host routes are 1442 always advertised with a mask of 0xffffffff, indicating the 1443 presence of only a single destination. 1445 Including the mask with each advertised destination enables the 1446 implementation of what is commonly referred to as variable- 1447 length subnetting. This means that a single IP class A, B, or C 1448 network number can be broken up into many subnets of various 1449 sizes. For example, the network 128.185.0.0 could be broken up 1450 into 62 variable-sized subnets: 15 subnets of size 4K, 15 1451 subnets of size 256, and 32 subnets of size 8. Table 7 shows 1452 some of the resulting network addresses together with their 1453 masks. 1455 Network address IP address mask Subnet size 1456 _______________________________________________ 1457 128.185.16.0 0xfffff000 4K 1458 128.185.1.0 0xffffff00 256 1459 128.185.0.8 0xfffffff8 8 1461 Table 7: Some sample subnet sizes. 1463 There are many possible ways of dividing up a class A, B, and C 1464 network into variable sized subnets. The precise procedure for 1465 doing so is beyond the scope of this specification. This 1466 specification however establishes the following guideline: When 1467 an IP packet is forwarded, it is always forwarded to the network 1468 that is the best match for the packet's destination. Here best 1469 match is synonymous with the longest or most specific match. 1470 For example, the default route with destination of 0.0.0.0 and 1471 mask 0x00000000 is always a match for every IP destination. Yet 1472 it is always less specific than any other match. Subnet masks 1473 must be assigned so that the best match for any IP destination 1474 is unambiguous. 1476 Attaching an address mask to each route also enables the support 1477 of IP supernetting. For example, a single physical network 1478 segment could be assigned the [address,mask] pair 1479 [192.9.4.0,0xfffffc00]. The segment would then be single IP 1480 network, containing addresses from the four consecutive class C 1481 network numbers 192.9.4.0 through 192.9.7.0. Such addressing is 1482 now becoming commonplace with the advent of CIDR (see [10]). 1484 In order to get better aggregation at area boundaries, area 1485 address ranges can be employed (see Section C.2 for more 1486 details). Each address range is defined as an [address,mask] 1487 pair. Many separate networks may then be contained in a single 1488 address range, just as a subnetted network is composed of many 1489 separate subnets. Area border routers then summarize the area 1490 contents (for distribution to the backbone) by advertising a 1491 single route for each address range. The cost of the route is 1492 the minimum cost to any of the networks falling in the specified 1493 range. 1495 For example, an IP subnetted network might be configured as a 1496 single OSPF area. In that case, a single address range could be 1497 configured: a class A, B, or C network number along with its 1498 natural IP mask. Inside the area, any number of variable sized 1499 subnets could be defined. However, external to the area a 1500 single route for the entire subnetted network would be 1501 distributed, hiding even the fact that the network is subnetted 1502 at all. The cost of this route is the minimum of the set of 1503 costs to the component subnets. 1505 3.6. Supporting stub areas 1507 In some Autonomous Systems, the majority of the link-state 1508 database may consist of AS external advertisements. An OSPF AS 1509 external advertisement is usually flooded throughout the entire 1510 AS. However, OSPF allows certain areas to be configured as 1511 "stub areas". AS external advertisements are not flooded 1512 into/throughout stub areas; routing to AS external destinations 1513 in these areas is based on a (per-area) default only. This 1514 reduces the link-state database size, and therefore the memory 1515 requirements, for a stub area's internal routers. 1517 In order to take advantage of the OSPF stub area support, 1518 default routing must be used in the stub area. This is 1519 accomplished as follows. One or more of the stub area's area 1520 border routers must advertise a default route into the stub area 1521 via summary link advertisements. These summary defaults are 1522 flooded throughout the stub area, but no further. (For this 1523 reason these defaults pertain only to the particular stub area). 1524 These summary default routes will be used for any destination 1525 that is not explicitly reachable by an intra-area or inter-area 1526 path (i.e., AS external destinations). 1528 An area can be configured as a stub when there is a single exit 1529 point from the area, or when the choice of exit point need not 1530 be made on a per-external-destination basis. For example, Area 1531 3 in Figure 6 could be configured as a stub area, because all 1532 external traffic must travel though its single area border 1533 router RT11. If Area 3 were configured as a stub, Router RT11 1534 would advertise a default route for distribution inside Area 3 1535 (in a summary link advertisement), instead of flooding the AS 1536 external advertisements for Networks N12-N15 into/throughout the 1537 area. 1539 The OSPF protocol ensures that all routers belonging to an area 1540 agree on whether the area has been configured as a stub. This 1541 guarantees that no confusion will arise in the flooding of AS 1542 external advertisements. 1544 There are a couple of restrictions on the use of stub areas. 1545 Virtual links cannot be configured through stub areas. In 1546 addition, AS boundary routers cannot be placed internal to stub 1547 areas. 1549 3.7. Partitions of areas 1551 OSPF does not actively attempt to repair area partitions. When 1552 an area becomes partitioned, each component simply becomes a 1553 separate area. The backbone then performs routing between the 1554 new areas. Some destinations reachable via intra-area routing 1555 before the partition will now require inter-area routing. 1557 However, in order to maintain full routing after the partition, 1558 an address range must not be split across multiple components of 1559 the area partition. Also, the backbone itself must not 1560 partition. If it does, parts of the Autonomous System will 1561 become unreachable. Backbone partitions can be repaired by 1562 configuring virtual links (see Section 15). 1564 Another way to think about area partitions is to look at the 1565 Autonomous System graph that was introduced in Section 2. Area 1566 IDs can be viewed as colors for the graph's edges.[1] Each edge 1567 of the graph connects to a network, or is itself a point-to- 1568 point network. In either case, the edge is colored with the 1569 network's Area ID. 1571 A group of edges, all having the same color, and interconnected 1572 by vertices, represents an area. If the topology of the 1573 Autonomous System is intact, the graph will have several regions 1574 of color, each color being a distinct Area ID. 1576 When the AS topology changes, one of the areas may become 1577 partitioned. The graph of the AS will then have multiple 1578 regions of the same color (Area ID). The routing in the 1579 Autonomous System will continue to function as long as these 1580 regions of same color are connected by the single backbone 1581 region. 1583 4. Functional Summary 1585 A separate copy of OSPF's basic routing algorithm runs in each area. 1586 Routers having interfaces to multiple areas run multiple copies of 1587 the algorithm. A brief summary of the routing algorithm follows. 1589 When a router starts, it first initializes the routing protocol data 1590 structures. The router then waits for indications from the lower- 1591 level protocols that its interfaces are functional. 1593 A router then uses the OSPF's Hello Protocol to acquire neighbors. 1594 The router sends Hello packets to its neighbors, and in turn 1595 receives their Hello packets. On broadcast and point-to-point 1596 networks, the router dynamically detects its neighboring routers by 1597 sending its Hello packets to the multicast address AllSPFRouters. 1598 On non-broadcast networks, some configuration information may be 1599 necessary in order to discover neighbors. On broadcast and NBMA 1600 networks the Hello Protocol also elects a Designated router for the 1601 network. 1603 The router will attempt to form adjacencies with some of its newly 1604 acquired neighbors. Link-state databases are synchronized between 1605 pairs of adjacent routers. On broadcast and NBMA networks, the 1606 Designated Router determines which routers should become adjacent. 1608 Adjacencies control the distribution of routing information. 1609 Routing updates are sent and received only on adjacencies. 1611 A router periodically advertises its state, which is also called 1612 link state. Link state is also advertised when a router's state 1613 changes. A router's adjacencies are reflected in the contents of 1614 its link state advertisements. This relationship between 1615 adjacencies and link state allows the protocol to detect dead 1616 routers in a timely fashion. 1618 Link state advertisements are flooded throughout the area. The 1619 flooding algorithm is reliable, ensuring that all routers in an area 1620 have exactly the same link-state database. This database consists 1621 of the collection of link state advertisements originated by each 1622 router belonging to the area. From this database each router 1623 calculates a shortest-path tree, with itself as root. This 1624 shortest-path tree in turn yields a routing table for the protocol. 1626 4.1. Inter-area routing 1628 The previous section described the operation of the protocol 1629 within a single area. For intra-area routing, no other routing 1630 information is pertinent. In order to be able to route to 1631 destinations outside of the area, the area border routers inject 1632 additional routing information into the area. This additional 1633 information is a distillation of the rest of the Autonomous 1634 System's topology. 1636 This distillation is accomplished as follows: Each area border 1637 router is by definition connected to the backbone. Each area 1638 border router summarizes the topology of its attached non- 1639 backbone areas for transmission on the backbone, and hence to 1640 all other area border routers. An area border router then has 1641 complete topological information concerning the backbone, and 1642 the area summaries from each of the other area border routers. 1643 From this information, the router calculates paths to all 1644 inter-area destinations. The router then advertises these paths 1645 into its attached areas. This enables the area's internal 1646 routers to pick the best exit router when forwarding traffic 1647 inter-area destinations. 1649 4.2. AS external routes 1651 Routers that have information regarding other Autonomous Systems 1652 can flood this information throughout the AS. This external 1653 routing information is distributed verbatim to every 1654 participating router. There is one exception: external routing 1655 information is not flooded into "stub" areas (see Section 3.6). 1657 To utilize external routing information, the path to all routers 1658 advertising external information must be known throughout the AS 1659 (excepting the stub areas). For that reason, the locations of 1660 these AS boundary routers are summarized by the (non-stub) area 1661 border routers. 1663 4.3. Routing protocol packets 1665 The OSPF protocol runs directly over IP, using IP protocol 89. 1666 OSPF does not provide any explicit fragmentation/reassembly 1667 support. When fragmentation is necessary, IP 1668 fragmentation/reassembly is used. OSPF protocol packets have 1669 been designed so that large protocol packets can generally be 1670 split into several smaller protocol packets. This practice is 1671 recommended; IP fragmentation should be avoided whenever 1672 possible. 1674 Routing protocol packets should always be sent with the IP TOS 1675 field set to 0. If at all possible, routing protocol packets 1676 should be given preference over regular IP data traffic, both 1677 when being sent and received. As an aid to accomplishing this, 1678 OSPF protocol packets should have their IP precedence field set 1679 to the value Internetwork Control (see [5]). 1681 All OSPF protocol packets share a common protocol header that is 1682 described in Appendix A. The OSPF packet types are listed below 1683 in Table 8. Their formats are also described in Appendix A. 1685 Type Packet name Protocol function 1686 __________________________________________________________ 1687 1 Hello Discover/maintain neighbors 1688 2 Database Description Summarize database contents 1689 3 Link State Request Database download 1690 4 Link State Update Database update 1691 5 Link State Ack Flooding acknowledgment 1693 Table 8: OSPF packet types. 1695 OSPF's Hello protocol uses Hello packets to discover and 1696 maintain neighbor relationships. The Database Description and 1697 Link State Request packets are used in the forming of 1698 adjacencies. OSPF's reliable update mechanism is implemented by 1699 the Link State Update and Link State Acknowledgment packets. 1701 Each Link State Update packet carries a set of new link state 1702 advertisements one hop further away from their point of 1703 origination. A single Link State Update packet may contain the 1704 link state advertisements of several routers. Each 1705 advertisement is tagged with the ID of the originating router 1706 and a checksum of its link state contents. Each advertisement 1707 also has a type field; the different types of OSPF link state 1708 advertisements are listed below in Table 9. 1710 OSPF routing packets (with the exception of Hellos) are sent 1711 only over adjacencies. This means that all OSPF protocol 1712 packets travel a single IP hop, except those that are sent over 1713 virtual adjacencies. The IP source address of an OSPF protocol 1714 packet is one end of a router adjacency, and the IP destination 1715 address is either the other end of the adjacency or an IP 1716 multicast address. 1718 LS Advertisement Advertisement description 1719 type name 1720 _________________________________________________________ 1721 1 Router links Originated by all routers. 1722 advertisements This advertisement describes 1723 the collected states of the 1724 router's interfaces to an 1725 area. Flooded throughout a 1726 single area only. 1727 _________________________________________________________ 1728 2 Network links Originated for broadcast 1729 advertisements and NBMA networks by 1730 the Designated Router. This 1731 advertisement contains the 1732 list of routers connected 1733 to the network. Flooded 1734 throughout a single area only. 1735 _________________________________________________________ 1736 3,4 Summary link Originated by area border 1737 advertisements routers, and flooded through- 1738 out the advertisement's 1739 associated area. Each summary 1740 link advertisement describes 1741 a route to a destination out- 1742 side the area, yet still inside 1743 the AS (i.e., an inter-area 1744 route). Type 3 advertisements 1745 describe routes to networks. 1746 Type 4 advertisements describe 1747 routes to AS boundary routers. 1748 _________________________________________________________ 1749 5 AS external link Originated by AS boundary 1750 advertisements routers, and flooded through- 1751 out the AS. Each AS external 1752 link advertisement describes 1753 a route to a destination in 1754 another Autonomous System. 1755 Default routes for the AS can 1756 also be described by AS 1757 external link advertisements. 1759 Table 9: OSPF link state advertisements. 1761 4.4. Basic implementation requirements 1763 An implementation of OSPF requires the following pieces of 1764 system support: 1766 Timers 1767 Two different kind of timers are required. The first kind, 1768 called "single shot timers", fire once and cause a protocol 1769 event to be processed. The second kind, called "interval 1770 timers", fire at continuous intervals. These are used for 1771 the sending of packets at regular intervals. A good example 1772 of this is the regular broadcast of Hello packets. The 1773 granularity of both kinds of timers is one second. 1775 Interval timers should be implemented to avoid drift. In 1776 some router implementations, packet processing can affect 1777 timer execution. When multiple routers are attached to a 1778 single network, all doing broadcasts, this can lead to the 1779 synchronization of routing packets (which should be 1780 avoided). If timers cannot be implemented to avoid drift, 1781 small random amounts should be added to/subtracted from the 1782 interval timer at each firing. 1784 IP multicast 1785 Certain OSPF packets take the form of IP multicast 1786 datagrams. Support for receiving and sending IP multicast 1787 datagrams, along with the appropriate lower-level protocol 1788 support, is required. The IP multicast datagrams used by 1789 OSPF never travel more than one hop. For this reason, the 1790 ability to forward IP multicast datagrams is not required. 1791 For information on IP multicast, see [7]. 1793 Variable-length subnet support 1794 The router's IP protocol support must include the ability to 1795 divide a single IP class A, B, or C network number into many 1796 subnets of various sizes. This is commonly called 1797 variable-length subnetting; see Section 3.5 for details. 1799 IP supernetting support 1800 The router's IP protocol support must include the ability to 1801 aggregate contiguous collections of IP class A, B, and C 1802 networks into larger quantities called supernets. 1803 Supernetting has been proposed as one way to improve the 1804 scaling of IP routing in the worldwide Internet. For more 1805 information on IP supernetting, see [10]. 1807 Lower-level protocol support 1808 The lower level protocols referred to here are the network 1809 access protocols, such as the Ethernet data link layer. 1810 Indications must be passed from these protocols to OSPF as 1811 the network interface goes up and down. For example, on an 1812 ethernet it would be valuable to know when the ethernet 1813 transceiver cable becomes unplugged. 1815 Non-broadcast lower-level protocol support 1816 On non-broadcast networks, the OSPF Hello Protocol can be 1817 aided by providing an indication when an attempt is made to 1818 send a packet to a dead or non-existent router. For 1819 example, on an X.25 PDN a dead neighboring router may be 1820 indicated by the reception of a X.25 clear with an 1821 appropriate cause and diagnostic, and this information would 1822 be passed to OSPF. 1824 List manipulation primitives 1825 Much of the OSPF functionality is described in terms of its 1826 operation on lists of link state advertisements. For 1827 example, the collection of advertisements that will be 1828 retransmitted to an adjacent router until acknowledged are 1829 described as a list. Any particular advertisement may be on 1830 many such lists. An OSPF implementation needs to be able to 1831 manipulate these lists, adding and deleting constituent 1832 advertisements as necessary. 1834 Tasking support 1835 Certain procedures described in this specification invoke 1836 other procedures. At times, these other procedures should 1837 be executed in-line, that is, before the current procedure 1838 is finished. This is indicated in the text by instructions 1839 to execute a procedure. At other times, the other 1840 procedures are to be executed only when the current 1841 procedure has finished. This is indicated by instructions 1842 to schedule a task. 1844 4.5. Optional OSPF capabilities 1846 The OSPF protocol defines several optional capabilities. A 1847 router indicates the optional capabilities that it supports in 1848 its OSPF Hello packets, Database Description packets and in its 1849 link state advertisements. This enables routers supporting a 1850 mix of optional capabilities to coexist in a single Autonomous 1851 System. 1853 Some capabilities must be supported by all routers attached to a 1854 specific area. In this case, a router will not accept a 1855 neighbor's Hello Packet unless there is a match in reported 1856 capabilities (i.e., a capability mismatch prevents a neighbor 1857 relationship from forming). An example of this is the 1858 ExternalRoutingCapability (see below). 1860 Other capabilities can be negotiated during the Database 1861 Exchange process. This is accomplished by specifying the 1862 optional capabilities in Database Description packets. A 1863 capability mismatch with a neighbor in this case will result in 1864 only a subset of the link state database being exchanged between 1865 the two neighbors. 1867 The routing table build process can also be affected by the 1868 presence/absence of optional capabilities. For example, since 1869 the optional capabilities are reported in link state 1870 advertisements, routers incapable of certain functions can be 1871 avoided when building the shortest path tree. An example of 1872 this is the TOS routing capability (see below). 1874 The OSPF optional capabilities defined in this memo are listed 1875 below. See Section A.2 for more information. 1877 ExternalRoutingCapability 1878 Entire OSPF areas can be configured as "stubs" (see Section 1879 3.6). AS external advertisements will not be flooded into 1880 stub areas. This capability is represented by the E-bit in 1881 the OSPF Options field (see Section A.2). In order to 1882 ensure consistent configuration of stub areas, all routers 1883 interfacing to such an area must have the E-bit clear in 1884 their Hello packets (see Sections 9.5 and 10.5). 1886 TOS capability 1887 All OSPF implementations must be able to calculate separate 1888 routes based on IP Type of Service. However, to save 1889 routing table space and processing resources, an OSPF router 1890 can be configured to ignore TOS when forwarding packets. In 1891 this case, the router calculates routes for TOS 0 only. 1892 This capability is represented by the T-bit in the OSPF 1893 Options field (see Section A.2). TOS-capable routers will 1894 attempt to avoid non-TOS-capable routers when calculating 1895 non-zero TOS paths. 1897 5. Protocol Data Structures 1899 The OSPF protocol is described herein in terms of its operation on 1900 various protocol data structures. The following list comprises the 1901 top-level OSPF data structures. Any initialization that needs to be 1902 done is noted. OSPF areas, interfaces and neighbors also have 1903 associated data structures that are described later in this 1904 specification. 1906 Router ID 1907 A 32-bit number that uniquely identifies this router in the AS. 1908 One possible implementation strategy would be to use the 1909 smallest IP interface address belonging to the router. If a 1910 router's OSPF Router ID is changed, the router's OSPF software 1911 should be restarted before the new Router ID takes effect. In 1912 this case the router should flush its self-originated link state 1913 advertisements from the routing domain (see Section 14.1) before 1914 restarting, or they will persist for up to MaxAge minutes. 1916 Area structures 1917 Each one of the areas to which the router is connected has its 1918 own data structure. This data structure describes the working 1919 of the basic OSPF algorithm. Remember that each area runs a 1920 separate copy of the basic OSPF algorithm. 1922 Backbone (area) structure 1923 The OSPF backbone area is responsible for the dissemination of 1924 inter-area routing information. 1926 Virtual links configured 1927 The virtual links configured with this router as one endpoint. 1928 In order to have configured virtual links, the router itself 1929 must be an area border router. Virtual links are identified by 1930 the Router ID of the other endpoint -- which is another area 1931 border router. These two endpoint routers must be attached to a 1932 common area, called the virtual link's Transit area. Virtual 1933 links are part of the backbone, and behave as if they were 1934 unnumbered point-to-point networks between the two routers. A 1935 virtual link uses the intra-area routing of its Transit area to 1936 forward packets. Virtual links are brought up and down through 1937 the building of the shortest-path trees for the Transit area. 1939 List of external routes 1940 These are routes to destinations external to the Autonomous 1941 System, that have been gained either through direct experience 1942 with another routing protocol (such as EGP), or through 1943 configuration information, or through a combination of the two 1944 (e.g., dynamic external information to be advertised by OSPF 1945 with configured metric). Any router having these external routes 1946 is called an AS boundary router. These routes are advertised by 1947 the router into the OSPF routing domain via AS external link 1948 advertisements. 1950 List of AS external link advertisements 1951 Part of the link-state database. These have originated from the 1952 AS boundary routers. They comprise routes to destinations 1953 external to the Autonomous System. Note that, if the router is 1954 itself an AS boundary router, some of these AS external link 1955 advertisements have been self-originated. 1957 The routing table 1958 Derived from the link-state database. Each entry in the routing 1959 table is indexed by a destination, and contains the 1960 destination's cost and a set of paths to use in forwarding 1961 packets to the destination. A path is described by its type and 1962 next hop. For more information, see Section 11. 1964 TOS capability 1965 This item indicates whether the router will calculate separate 1966 routes based on TOS. This is a configurable parameter. For 1967 more information, see Sections 4.5 and 16.9. 1969 Figure 9 shows the collection of data structures present in a 1970 typical router. The router pictured is RT10, from the map in Figure 1971 6. Note that Router RT10 has a virtual link configured to Router 1972 RT11, with Area 2 as the link's Transit area. This is indicated by 1973 the dashed line in Figure 9. When the virtual link becomes active, 1974 through the building of the shortest path tree for Area 2, it 1975 becomes an interface to the backbone (see the two backbone 1976 interfaces depicted in Figure 9). 1978 6. The Area Data Structure 1980 The area data structure contains all the information used to run the 1981 basic OSPF routing algorithm. Each area maintains its own link-state 1982 database. A network belongs to a single area, and a router interface 1983 connects to a single area. Each router adjacency also belongs to a 1984 single area. 1986 The OSPF backbone is the special OSPF area responsible for 1987 disseminating inter-area routing information. 1989 The area link-state database consists of the collection of router 1990 links, network links and summary link advertisements that have 1992 +----+ 1993 |RT10|------+ 1994 +----+ \+-------------+ 1995 / \ |Routing Table| 1996 / \ +-------------+ 1997 / \ 1998 +------+ / \ +--------+ 1999 |Area 2|---+ +---|Backbone| 2000 +------+***********+ +--------+ 2001 / \ * / \ 2002 / \ * / \ 2003 +---------+ +---------+ +------------+ +------------+ 2004 |Interface| |Interface| |Virtual Link| |Interface Ib| 2005 | to N6 | | to N8 | | to RT11 | +------------+ 2006 +---------+ +---------+ +------------+ | 2007 / \ | | | 2008 / \ | | | 2009 +--------+ +--------+ | +-------------+ +------------+ 2010 |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| 2011 | RT8 | | RT7 | | +-------------+ +------------+ 2012 +--------+ +--------+ | 2013 | 2014 +-------------+ 2015 |Neighbor RT11| 2016 +-------------+ 2018 Figure 9: Router RT10's Data structures 2020 originated from the area's routers. This information is flooded 2021 throughout a single area only. The list of AS external link 2022 advertisements (see Section 5) is also considered to be part of each 2023 area's link-state database. 2025 Area ID 2026 A 32-bit number identifying the area. The Area ID of 0.0.0.0 is 2027 reserved for the backbone. 2029 List of area address ranges 2030 In order to aggregate routing information at area boundaries, 2031 area address ranges can be employed. Each address range is 2032 specified by an [address,mask] pair and a status indication of 2033 either Advertise or DoNotAdvertise (see Section 12.4.3). 2035 Associated router interfaces 2036 This router's interfaces connecting to the area. A router 2037 interface belongs to one and only one area (or the backbone). 2038 For the backbone area this list includes all the virtual links. 2039 A virtual link is identified by the Router ID of its other 2040 endpoint; its cost is the cost of the shortest intra-area path 2041 through the Transit area that exists between the two routers. 2043 List of router links advertisements 2044 A router links advertisement is generated by each router in the 2045 area. It describes the state of the router's interfaces to the 2046 area. 2048 List of network links advertisements 2049 One network links advertisement is generated for each transit 2050 broadcast and NBMA network in the area. A network links 2051 advertisement describes the set of routers currently connected 2052 to the network. 2054 List of summary link advertisements 2055 Summary link advertisements originate from the area's area 2056 border routers. They describe routes to destinations internal 2057 to the Autonomous System, yet external to the area (i.e., 2058 inter-area destinations). 2060 Shortest-path tree 2061 The shortest-path tree for the area, with this router itself as 2062 root. Derived from the collected router links and network links 2063 advertisements by the Dijkstra algorithm (see Section 16.1). 2065 TransitCapability 2066 Set to TRUE if and only if there are one or more active virtual 2067 links using the area as a Transit area. Equivalently, this 2068 parameter indicates whether the area can carry data traffic that 2069 neither originates nor terminates in the area itself. This 2070 parameter is calculated when the area's shortest-path tree is 2071 built (see Section 16.1, and is used as an input to a subsequent 2072 step of the routing table build process (see Section 16.3). 2074 ExternalRoutingCapability 2075 Whether AS external advertisements will be flooded 2076 into/throughout the area. This is a configurable parameter. If 2077 AS external advertisements are excluded from the area, the area 2078 is called a "stub". Within stub areas, routing to AS external 2079 destinations will be based solely on a default summary route. 2080 The backbone cannot be configured as a stub area. Also, virtual 2081 links cannot be configured through stub areas. For more 2082 information, see Section 3.6. 2084 StubDefaultCost 2085 If the area has been configured as a stub area, and the router 2086 itself is an area border router, then the StubDefaultCost 2087 indicates the cost of the default summary link that the router 2088 should advertise into the area. There can be a separate cost 2089 configured for each IP TOS. See Section 12.4.3 for more 2090 information. 2092 Unless otherwise specified, the remaining sections of this document 2093 refer to the operation of the OSPF protocol within a single area. 2095 7. Bringing Up Adjacencies 2097 OSPF creates adjacencies between neighboring routers for the purpose 2098 of exchanging routing information. Not every two neighboring 2099 routers will become adjacent. This section covers the generalities 2100 involved in creating adjacencies. For further details consult 2101 Section 10. 2103 7.1. The Hello Protocol 2105 The Hello Protocol is responsible for establishing and 2106 maintaining neighbor relationships. It also ensures that 2107 communication between neighbors is bidirectional. Hello packets 2108 are sent periodically out all router interfaces. Bidirectional 2109 communication is indicated when the router sees itself listed in 2110 the neighbor's Hello Packet. On broadcast and NBMA networks, 2111 the Hello Protocol elects a Designated Router for the network. 2113 The Hello Protocol works differently on broadcast networks, NBMA 2114 networks and Point-to-MultiPoint networks. On broadcast 2115 networks, each router advertises itself by periodically 2116 multicasting Hello Packets. This allows neighbors to be 2117 discovered dynamically. These Hello Packets contain the 2118 router's view of the Designated Router's identity, and the list 2119 of routers whose Hello Packets have been seen recently. 2121 On NBMA networks some configuration information may be necessary 2122 for the operation of the Hello Protocol. Each router that may 2123 potentially become Designated Router has a list of all other 2124 routers attached to the network. A router, having Designated 2125 Router potential, sends Hello Packets to all other potential 2126 Designated Routers when its interface to the NBMA network first 2127 becomes operational. This is an attempt to find the Designated 2128 Router for the network. If the router itself is elected 2129 Designated Router, it begins sending Hello Packets to all other 2130 routers attached to the network. 2132 On Point-to-MultiPoint networks, a router sends Hello Packets to 2133 all neighbors with which it can communicate directly. These 2134 neighbors may be discovered dynamically through a protocol such 2135 as Inverse ARP (see [14]), or they may be configured. 2137 After a neighbor has been discovered, bidirectional 2138 communication ensured, and (if on a broadcast or NBMA network) a 2139 Designated Router elected, a decision is made regarding whether 2140 or not an adjacency should be formed with the neighbor (see 2141 Section 10.4). If an adjacency is to be formed, the first step 2142 is to synchronize the neighbors' link-state databases. This is 2143 covered in the next section. 2145 7.2. The Synchronization of Databases 2147 In a link-state routing algorithm, it is very important for all 2148 routers' link-state databases to stay synchronized. OSPF 2149 simplifies this by requiring only adjacent routers to remain 2150 synchronized. The synchronization process begins as soon as the 2151 routers attempt to bring up the adjacency. Each router 2152 describes its database by sending a sequence of Database 2153 Description packets to its neighbor. Each Database Description 2154 Packet describes a set of link state advertisements belonging to 2155 the router's database. When the neighbor sees a link state 2156 advertisement that is more recent than its own database copy, it 2157 makes a note that this newer advertisement should be requested. 2159 This sending and receiving of Database Description packets is 2160 called the "Database Exchange Process". During this process, 2161 the two routers form a master/slave relationship. Each Database 2162 Description Packet has a sequence number. Database Description 2163 Packets sent by the master (polls) are acknowledged by the slave 2164 through echoing of the sequence number. Both polls and their 2165 responses contain summaries of link state data. The master is 2166 the only one allowed to retransmit Database Description Packets. 2167 It does so only at fixed intervals, the length of which is the 2168 configured per-interface constant RxmtInterval. 2170 Each Database Description contains an indication that there are 2171 more packets to follow --- the M-bit. The Database Exchange 2172 Process is over when a router has received and sent Database 2173 Description Packets with the M-bit off. 2175 During and after the Database Exchange Process, each router has 2176 a list of those link state advertisements for which the neighbor 2177 has more up-to-date instances. These advertisements are 2178 requested in Link State Request Packets. Link State Request 2179 packets that are not satisfied are retransmitted at fixed 2180 intervals of time RxmtInterval. When the Database Description 2181 Process has completed and all Link State Requests have been 2182 satisfied, the databases are deemed synchronized and the routers 2183 are marked fully adjacent. At this time the adjacency is fully 2184 functional and is advertised in the two routers' link state 2185 advertisements. 2187 The adjacency is used by the flooding procedure as soon as the 2188 Database Exchange Process begins. This simplifies database 2189 synchronization, and guarantees that it finishes in a 2190 predictable period of time. 2192 7.3. The Designated Router 2194 Every broadcast and NBMA network has a Designated Router. The 2195 Designated Router performs two main functions for the routing 2196 protocol: 2198 o The Designated Router originates a network links 2199 advertisement on behalf of the network. This advertisement 2200 lists the set of routers (including the Designated Router 2201 itself) currently attached to the network. The Link State 2202 ID for this advertisement (see Section 12.1.4) is the IP 2203 interface address of the Designated Router. The IP network 2204 number can then be obtained by using the network's 2205 subnet/network mask. 2207 o The Designated Router becomes adjacent to all other routers 2208 on the network. Since the link state databases are 2209 synchronized across adjacencies (through adjacency bring-up 2210 and then the flooding procedure), the Designated Router 2211 plays a central part in the synchronization process. 2213 The Designated Router is elected by the Hello Protocol. A 2214 router's Hello Packet contains its Router Priority, which is 2215 configurable on a per-interface basis. In general, when a 2216 router's interface to a network first becomes functional, it 2217 checks to see whether there is currently a Designated Router for 2218 the network. If there is, it accepts that Designated Router, 2219 regardless of its Router Priority. (This makes it harder to 2220 predict the identity of the Designated Router, but ensures that 2221 the Designated Router changes less often. See below.) 2222 Otherwise, the router itself becomes Designated Router if it has 2223 the highest Router Priority on the network. A more detailed 2224 (and more accurate) description of Designated Router election is 2225 presented in Section 9.4. 2227 The Designated Router is the endpoint of many adjacencies. In 2228 order to optimize the flooding procedure on broadcast networks, 2229 the Designated Router multicasts its Link State Update Packets 2230 to the address AllSPFRouters, rather than sending separate 2231 packets over each adjacency. 2233 Section 2 of this document discusses the directed graph 2234 representation of an area. Router nodes are labelled with their 2235 Router ID. Transit network nodes are actually labelled with the 2236 IP address of their Designated Router. It follows that when the 2237 Designated Router changes, it appears as if the network node on 2238 the graph is replaced by an entirely new node. This will cause 2239 the network and all its attached routers to originate new link 2240 state advertisements. Until the link-state databases again 2241 converge, some temporary loss of connectivity may result. This 2242 may result in ICMP unreachable messages being sent in response 2243 to data traffic. For that reason, the Designated Router should 2244 change only infrequently. Router Priorities should be 2245 configured so that the most dependable router on a network 2246 eventually becomes Designated Router. 2248 7.4. The Backup Designated Router 2250 In order to make the transition to a new Designated Router 2251 smoother, there is a Backup Designated Router for each broadcast 2252 and NBMA network. The Backup Designated Router is also adjacent 2253 to all routers on the network, and becomes Designated Router 2254 when the previous Designated Router fails. If there were no 2255 Backup Designated Router, when a new Designated Router became 2256 necessary, new adjacencies would have to be formed between the 2257 new Designated Router and all other routers attached to the 2258 network. Part of the adjacency forming process is the 2259 synchronizing of link-state databases, which can potentially 2260 take quite a long time. During this time, the network would not 2261 be available for transit data traffic. The Backup Designated 2262 obviates the need to form these adjacencies, since they already 2263 exist. This means the period of disruption in transit traffic 2264 lasts only as long as it takes to flood the new link state 2265 advertisements (which announce the new Designated Router). 2267 The Backup Designated Router does not generate a network links 2268 advertisement for the network. (If it did, the transition to a 2269 new Designated Router would be even faster. However, this is a 2270 tradeoff between database size and speed of convergence when the 2271 Designated Router disappears.) 2273 The Backup Designated Router is also elected by the Hello 2274 Protocol. Each Hello Packet has a field that specifies the 2275 Backup Designated Router for the network. 2277 In some steps of the flooding procedure, the Backup Designated 2278 Router plays a passive role, letting the Designated Router do 2279 more of the work. This cuts down on the amount of local routing 2280 traffic. See Section 13.3 for more information. 2282 7.5. The graph of adjacencies 2284 An adjacency is bound to the network that the two routers have 2285 in common. If two routers have multiple networks in common, 2286 they may have multiple adjacencies between them. 2288 One can picture the collection of adjacencies on a network as 2289 forming an undirected graph. The vertices consist of routers, 2290 with an edge joining two routers if they are adjacent. The 2291 graph of adjacencies describes the flow of routing protocol 2292 packets, and in particular Link State Update Packets, through 2293 the Autonomous System. 2295 Two graphs are possible, depending on whether a Designated 2296 Router is elected for the network. On physical point-to-point 2297 networks, Point-to-MultiPoint networks and virtual links, 2298 neighboring routers become adjacent whenever they can 2299 communicate directly. In contrast, on broadcast and NBMA 2300 networks only the Designated Router and the Backup Designated 2301 Router become adjacent to all other routers attached to the 2302 network. 2304 These graphs are shown in Figure 10. It is assumed that Router 2305 RT7 has become the Designated Router, and Router RT3 the Backup 2306 Designated Router, for the Network N2. The Backup Designated 2307 Router performs a lesser function during the flooding procedure 2308 than the Designated Router (see Section 13.3). This is the 2309 reason for the dashed lines connecting the Backup Designated 2310 Router RT3. 2312 +---+ +---+ 2313 |RT1|------------|RT2| o---------------o 2314 +---+ N1 +---+ RT1 RT2 2316 RT7 2317 o---------+ 2318 +---+ +---+ +---+ /|\ | 2319 |RT7| |RT3| |RT4| / | \ | 2320 +---+ +---+ +---+ / | \ | 2321 | | | / | \ | 2322 +-----------------------+ RT5o RT6o oRT4 | 2323 | | N2 * * * | 2324 +---+ +---+ * * * | 2325 |RT5| |RT6| * * * | 2326 +---+ +---+ *** | 2327 o---------+ 2328 RT3 2330 Figure 10: The graph of adjacencies 2332 8. Protocol Packet Processing 2334 This section discusses the general processing of OSPF routing 2335 protocol packets. It is very important that the router link-state 2336 databases remain synchronized. For this reason, routing protocol 2337 packets should get preferential treatment over ordinary data 2338 packets, both in sending and receiving. 2340 Routing protocol packets are sent along adjacencies only (with the 2341 exception of Hello packets, which are used to discover the 2342 adjacencies). This means that all routing protocol packets travel a 2343 single IP hop, except those sent over virtual links. 2345 All routing protocol packets begin with a standard header. The 2346 sections below provide details on how to fill in and verify this 2347 standard header. Then, for each packet type, the section giving 2348 more details on that particular packet type's processing is listed. 2350 8.1. Sending protocol packets 2352 When a router sends a routing protocol packet, it fills in the 2353 fields of the standard OSPF packet header as follows. For more 2354 details on the header format consult Section A.3.1: 2356 Version # 2357 Set to 2, the version number of the protocol as documented 2358 in this specification. 2360 Packet type 2361 The type of OSPF packet, such as Link state Update or Hello 2362 Packet. 2364 Packet length 2365 The length of the entire OSPF packet in bytes, including the 2366 standard OSPF packet header. 2368 Router ID 2369 The identity of the router itself (who is originating the 2370 packet). 2372 Area ID 2373 The OSPF area that the packet is being sent into. 2375 Checksum 2376 The standard IP 16-bit one's complement checksum of the 2377 entire OSPF packet, excluding the 64-bit authentication 2378 field. This checksum is calculated as part of the 2379 appropriate authentication procedure; for some OSPF 2380 authentication types, the checksum calculation is omitted. 2381 See Section D.4 for details. 2383 AuType and Authentication 2384 Each OSPF packet exchange is authenticated. Authentication 2385 types are assigned by the protocol and are documented in 2386 Appendix D. A different authentication procedure can be 2387 used for each IP network/subnet. Autype indicates the type 2388 of authentication procedure in use. The 64-bit 2389 authentication field is then for use by the chosen 2390 authentication procedure. This procedure should be the last 2391 called when forming the packet to be sent. See Section D.4 2392 for details. 2394 The IP destination address for the packet is selected as 2395 follows. On physical point-to-point networks, the IP 2396 destination is always set to the address AllSPFRouters. On all 2397 other network types (including virtual links), the majority of 2398 OSPF packets are sent as unicasts, i.e., sent directly to the 2399 other end of the adjacency. In this case, the IP destination is 2400 just the Neighbor IP address associated with the other end of 2401 the adjacency (see Section 10). The only packets not sent as 2402 unicasts are on broadcast networks; on these networks Hello 2403 packets are sent to the multicast destination AllSPFRouters, the 2404 Designated Router and its Backup send both Link State Update 2405 Packets and Link State Acknowledgment Packets to the multicast 2406 address AllSPFRouters, while all other routers send both their 2407 Link State Update and Link State Acknowledgment Packets to the 2408 multicast address AllDRouters. 2410 Retransmissions of Link State Update packets are ALWAYS sent as 2411 unicasts. 2413 The IP source address should be set to the IP address of the 2414 sending interface. Interfaces to unnumbered point-to-point 2415 networks have no associated IP address. On these interfaces, 2416 the IP source should be set to any of the other IP addresses 2417 belonging to the router. For this reason, there must be at 2418 least one IP address assigned to the router.[2] Note that, for 2419 most purposes, virtual links act precisely the same as 2420 unnumbered point-to-point networks. However, each virtual link 2421 does have an IP interface address (discovered during the routing 2422 table build process) which is used as the IP source when sending 2423 packets over the virtual link. 2425 For more information on the format of specific OSPF packet 2426 types, consult the sections listed in Table 10. 2428 Type Packet name detailed section (transmit) 2429 _________________________________________________________ 2430 1 Hello Section 9.5 2431 2 Database description Section 10.8 2432 3 Link state request Section 10.9 2433 4 Link state update Section 13.3 2434 5 Link state ack Section 13.5 2436 Table 10: Sections describing OSPF protocol packet transmission. 2438 8.2. Receiving protocol packets 2440 Whenever a protocol packet is received by the router it is 2441 marked with the interface it was received on. For routers that 2442 have virtual links configured, it may not be immediately obvious 2443 which interface to associate the packet with. For example, 2444 consider the Router RT11 depicted in Figure 6. If RT11 receives 2445 an OSPF protocol packet on its interface to Network N8, it may 2446 want to associate the packet with the interface to Area 2, or 2447 with the virtual link to Router RT10 (which is part of the 2448 backbone). In the following, we assume that the packet is 2449 initially associated with the non-virtual link.[3] 2451 In order for the packet to be accepted at the IP level, it must 2452 pass a number of tests, even before the packet is passed to OSPF 2453 for processing: 2455 o The IP checksum must be correct. 2457 o The packet's IP destination address must be the IP address 2458 of the receiving interface, or one of the IP multicast 2459 addresses AllSPFRouters or AllDRouters. 2461 o The IP protocol specified must be OSPF (89). 2463 o Locally originated packets should not be passed on to OSPF. 2464 That is, the source IP address should be examined to make 2465 sure this is not a multicast packet that the router itself 2466 generated. 2468 Next, the OSPF packet header is verified. The fields specified 2469 in the header must match those configured for the receiving 2470 interface. If they do not, the packet should be discarded: 2472 o The version number field must specify protocol version 2. 2474 o The Area ID found in the OSPF header must be verified. If 2475 both of the following cases fail, the packet should be 2476 discarded. The Area ID specified in the header must either: 2478 (1) Match the Area ID of the receiving interface. In this 2479 case, the packet has been sent over a single hop. 2480 Therefore, the packet's IP source address is required to 2481 be on the same network as the receiving interface. This 2482 can be verified by comparing the packet's IP source 2483 address to the interface's IP address, after masking 2484 both addresses with the interface mask. This comparison 2485 should not be performed on point-to-point networks. On 2486 point-to-point networks, the interface addresses of each 2487 end of the link are assigned independently, if they are 2488 assigned at all. 2490 (2) Indicate the backbone. In this case, the packet has 2491 been sent over a virtual link. The receiving router 2492 must be an area border router, and the Router ID 2493 specified in the packet (the source router) must be the 2494 other end of a configured virtual link. The receiving 2495 interface must also attach to the virtual link's 2496 configured Transit area. If all of these checks 2497 succeed, the packet is accepted and is from now on 2498 associated with the virtual link (and the backbone 2499 area). 2501 o Packets whose IP destination is AllDRouters should only be 2502 accepted if the state of the receiving interface is DR or 2503 Backup (see Section 9.1). 2505 o The AuType specified in the packet must match the AuType 2506 specified for the associated area. 2508 o The packet must be authenticated. The authentication 2509 procedure is indicated by the setting of AuType (see 2510 Appendix D). The authentication procedure may use one or 2511 more Authentication keys, which can be configured on a per- 2512 interface basis. The authentication procedure may also 2513 verify the checksum field in the OSPF packet header (which, 2514 when used, is set to the standard IP 16-bit one's complement 2515 checksum of the OSPF packet's contents after excluding the 2516 64-bit authentication field). If the authentication 2517 procedure fails, the packet should be discarded. 2519 If the packet type is Hello, it should then be further processed 2520 by the Hello Protocol (see Section 10.5). All other packet 2521 types are sent/received only on adjacencies. This means that 2522 the packet must have been sent by one of the router's active 2523 neighbors. If the receiving interface connects to a broadcast 2524 network, Point-to-MultiPoint network or NBMA network the sender 2525 is identified by the IP source address found in the packet's IP 2526 header. If the receiving interface connects to a point-to-point 2527 network or a virtual link, the sender is identified by the 2528 Router ID (source router) found in the packet's OSPF header. 2529 The data structure associated with the receiving interface 2530 contains the list of active neighbors. Packets not matching any 2531 active neighbor are discarded. 2533 At this point all received protocol packets are associated with 2534 an active neighbor. For the further input processing of 2535 specific packet types, consult the sections listed in Table 11. 2537 Type Packet name detailed section (receive) 2538 ________________________________________________________ 2539 1 Hello Section 10.5 2540 2 Database description Section 10.6 2541 3 Link state request Section 10.7 2542 4 Link state update Section 13 2543 5 Link state ack Section 13.7 2545 Table 11: Sections describing OSPF protocol packet reception. 2547 9. The Interface Data Structure 2549 An OSPF interface is the connection between a router and a network. 2550 There is a single OSPF interface structure for each attached 2551 network; each interface structure has at most one IP interface 2552 address (see below). The support for multiple addresses on a single 2553 network is a matter for future consideration. 2555 An OSPF interface can be considered to belong to the area that 2556 contains the attached network. All routing protocol packets 2557 originated by the router over this interface are labelled with the 2558 interface's Area ID. One or more router adjacencies may develop 2559 over an interface. A router's link state advertisements reflect the 2560 state of its interfaces and their associated adjacencies. 2562 The following data items are associated with an interface. Note 2563 that a number of these items are actually configuration for the 2564 attached network; such items must be the same for all routers 2565 connected to the network. 2567 Type 2568 The OSPF interface type is either point-to-point, broadcast, 2569 NBMA, Point-to-MultiPoint or virtual link. 2571 State 2572 The functional level of an interface. State determines whether 2573 or not full adjacencies are allowed to form over the interface. 2574 State is also reflected in the router's link state 2575 advertisements. 2577 IP interface address 2578 The IP address associated with the interface. This appears as 2579 the IP source address in all routing protocol packets originated 2580 over this interface. Interfaces to unnumbered point-to-point 2581 networks do not have an associated IP address. 2583 IP interface mask 2584 Also referred to as the subnet mask, this indicates the portion 2585 of the IP interface address that identifies the attached 2586 network. Masking the IP interface address with the IP interface 2587 mask yields the IP network number of the attached network. On 2588 point-to-point networks and virtual links, the IP interface mask 2589 is not defined. On these networks, the link itself is not 2590 assigned an IP network number, and so the addresses of each side 2591 of the link are assigned independently, if they are assigned at 2592 all. 2594 Area ID 2595 The Area ID of the area to which the attached network belongs. 2596 All routing protocol packets originating from the interface are 2597 labelled with this Area ID. 2599 HelloInterval 2600 The length of time, in seconds, between the Hello packets that 2601 the router sends on the interface. Advertised in Hello packets 2602 sent out this interface. 2604 RouterDeadInterval 2605 The number of seconds before the router's neighbors will declare 2606 it down, when they stop hearing the router's Hello Packets. 2607 Advertised in Hello packets sent out this interface. 2609 InfTransDelay 2610 The estimated number of seconds it takes to transmit a Link 2611 State Update Packet over this interface. Link state 2612 advertisements contained in the Link State Update packet will 2613 have their age incremented by this amount before transmission. 2614 This value should take into account transmission and propagation 2615 delays; it must be greater than zero. 2617 Router Priority 2618 An 8-bit unsigned integer. When two routers attached to a 2619 network both attempt to become Designated Router, the one with 2620 the highest Router Priority takes precedence. A router whose 2621 Router Priority is set to 0 is ineligible to become Designated 2622 Router on the attached network. Advertised in Hello packets 2623 sent out this interface. 2625 Hello Timer 2626 An interval timer that causes the interface to send a Hello 2627 packet. This timer fires every HelloInterval seconds. Note 2628 that on non-broadcast networks a separate Hello packet is sent 2629 to each qualified neighbor. 2631 Wait Timer 2632 A single shot timer that causes the interface to exit the 2633 Waiting state, and as a consequence select a Designated Router 2634 on the network. The length of the timer is RouterDeadInterval 2635 seconds. 2637 List of neighboring routers 2638 The other routers attached to this network. This list is formed 2639 by the Hello Protocol. Adjacencies will be formed to some of 2640 these neighbors. The set of adjacent neighbors can be 2641 determined by an examination of all of the neighbors' states. 2643 Designated Router 2644 The Designated Router selected for the attached network. The 2645 Designated Router is selected on all broadcast and NBMA networks 2646 by the Hello Protocol. Two pieces of identification are kept 2647 for the Designated Router: its Router ID and its IP interface 2648 address on the network. The Designated Router advertises link 2649 state for the network; this network link state advertisement is 2650 labelled with the Designated Router's IP address. The 2651 Designated Router is initialized to 0.0.0.0, which indicates the 2652 lack of a Designated Router. 2654 Backup Designated Router 2655 The Backup Designated Router is also selected on all broadcast 2656 and NBMA networks by the Hello Protocol. All routers on the 2657 attached network become adjacent to both the Designated Router 2658 and the Backup Designated Router. The Backup Designated Router 2659 becomes Designated Router when the current Designated Router 2660 fails. The Backup Designated Router is initialized to 0.0.0.0, 2661 indicating the lack of a Backup Designated Router. 2663 Interface output cost(s) 2664 The cost of sending a data packet on the interface, expressed in 2665 the link state metric. This is advertised as the link cost for 2666 this interface in the router links advertisement. There may be 2667 a separate cost for each IP Type of Service. The cost of an 2668 interface must be greater than zero. 2670 RxmtInterval 2671 The number of seconds between link state advertisement 2672 retransmissions, for adjacencies belonging to this interface. 2673 Also used when retransmitting Database Description and Link 2674 State Request Packets. 2676 AuType 2677 The type of authentication used on the attached network/subnet. 2678 Authentication types are defined in Appendix D. All OSPF packet 2679 exchanges are authenticated. Different authentication schemes 2680 may be used on different networks/subnets. 2682 Authentication key 2683 This configured data allows the authentication procedure to 2684 generate and/or verify OSPF protocol packets. The 2685 Authentication key can be configured on a per-interface basis. 2686 For example, if the AuType indicates simple password, the 2687 Authentication key would be a 64-bit clear password which is 2688 inserted into the OSPF packet header. If instead Autype 2689 indicates Cryptographic authentication, then the Authentication 2690 key is a shared secret which enables the generation/verification 2691 of message digests which are appended to the OSPF protocol 2692 packets. When Cryptographic authentication is used, multiple 2693 simultaneous keys are supported in order to achieve smooth key 2694 transition (see Section D.3). 2696 9.1. Interface states 2698 The various states that router interfaces may attain is 2699 documented in this section. The states are listed in order of 2700 progressing functionality. For example, the inoperative state 2701 is listed first, followed by a list of intermediate states 2702 before the final, fully functional state is achieved. The 2703 specification makes use of this ordering by sometimes making 2704 references such as "those interfaces in state greater than X". 2705 Figure 11 shows the graph of interface state changes. The arcs 2706 of the graph are labelled with the event causing the state 2707 change. These events are documented in Section 9.2. The 2708 interface state machine is described in more detail in Section 2709 9.3. 2711 Down 2712 This is the initial interface state. In this state, the 2713 lower-level protocols have indicated that the interface is 2714 unusable. No protocol traffic at all will be sent or 2715 received on such a interface. In this state, interface 2716 parameters should be set to their initial values. All 2717 interface timers should be disabled, and there should be no 2718 adjacencies associated with the interface. 2720 Loopback 2721 In this state, the router's interface to the network is 2722 +----+ UnloopInd +--------+ 2723 |Down|<--------------|Loopback| 2724 +----+ +--------+ 2725 | 2726 |InterfaceUp 2727 +-------+ | +--------------+ 2728 |Waiting|<-+-------------->|Point-to-point| 2729 +-------+ +--------------+ 2730 | 2731 WaitTimer|BackupSeen 2732 | 2733 | 2734 | NeighborChange 2735 +------+ +-+<---------------- +-------+ 2736 |Backup|<----------|?|----------------->|DROther| 2737 +------+---------->+-+<-----+ +-------+ 2738 Neighbor | | 2739 Change | |Neighbor 2740 | |Change 2741 | +--+ 2742 +---->|DR| 2743 +--+ 2745 Figure 11: Interface State changes 2747 In addition to the state transitions pictured, 2748 Event InterfaceDown always forces Down State, and 2749 Event LoopInd always forces Loopback State 2751 looped back. The interface may be looped back in hardware 2752 or software. The interface will be unavailable for regular 2753 data traffic. However, it may still be desirable to gain 2754 information on the quality of this interface, either through 2755 sending ICMP pings to the interface or through something 2756 like a bit error test. For this reason, IP packets may 2757 still be addressed to an interface in Loopback state. To 2758 facilitate this, such interfaces are advertised in router 2759 links advertisements as single host routes, whose 2760 destination is the IP interface address.[4] 2762 Waiting 2763 In this state, the router is trying to determine the 2764 identity of the (Backup) Designated Router for the network. 2765 To do this, the router monitors the Hello Packets it 2766 receives. The router is not allowed to elect a Backup 2767 Designated Router nor a Designated Router until it 2768 transitions out of Waiting state. This prevents unnecessary 2769 changes of (Backup) Designated Router. 2771 Point-to-point 2772 In this state, the interface is operational, and connects 2773 either to a physical point-to-point network or to a virtual 2774 link. Upon entering this state, the router attempts to form 2775 an adjacency with the neighboring router. Hello Packets are 2776 sent to the neighbor every HelloInterval seconds. 2778 DR Other 2779 The interface is to a broadcast or NBMA network on which 2780 another router has been selected to be the Designated 2781 Router. In this state, the router itself has not been 2782 selected Backup Designated Router either. The router forms 2783 adjacencies to both the Designated Router and the Backup 2784 Designated Router (if they exist). 2786 Backup 2787 In this state, the router itself is the Backup Designated 2788 Router on the attached network. It will be promoted to 2789 Designated Router when the present Designated Router fails. 2790 The router establishes adjacencies to all other routers 2791 attached to the network. The Backup Designated Router 2792 performs slightly different functions during the Flooding 2793 Procedure, as compared to the Designated Router (see Section 2794 13.3). See Section 7.4 for more details on the functions 2795 performed by the Backup Designated Router. 2797 DR In this state, this router itself is the Designated Router 2798 on the attached network. Adjacencies are established to all 2799 other routers attached to the network. The router must also 2800 originate a network links advertisement for the network 2801 node. The advertisement will contain links to all routers 2802 (including the Designated Router itself) attached to the 2803 network. See Section 7.3 for more details on the functions 2804 performed by the Designated Router. 2806 9.2. Events causing interface state changes 2808 State changes can be effected by a number of events. These 2809 events are pictured as the labelled arcs in Figure 11. The 2810 label definitions are listed below. For a detailed explanation 2811 of the effect of these events on OSPF protocol operation, 2812 consult Section 9.3. 2814 InterfaceUp 2815 Lower-level protocols have indicated that the network 2816 interface is operational. This enables the interface to 2817 transition out of Down state. On virtual links, the 2818 interface operational indication is actually a result of the 2819 shortest path calculation (see Section 16.7). 2821 WaitTimer 2822 The Wait Timer has fired, indicating the end of the waiting 2823 period that is required before electing a (Backup) 2824 Designated Router. 2826 BackupSeen 2827 The router has detected the existence or non-existence of a 2828 Backup Designated Router for the network. This is done in 2829 one of two ways. First, an Hello Packet may be received 2830 from a neighbor claiming to be itself the Backup Designated 2831 Router. Alternatively, an Hello Packet may be received from 2832 a neighbor claiming to be itself the Designated Router, and 2833 indicating that there is no Backup Designated Router. In 2834 either case there must be bidirectional communication with 2835 the neighbor, i.e., the router must also appear in the 2836 neighbor's Hello Packet. This event signals an end to the 2837 Waiting state. 2839 NeighborChange 2840 There has been a change in the set of bidirectional 2841 neighbors associated with the interface. The (Backup) 2842 Designated Router needs to be recalculated. The following 2843 neighbor changes lead to the NeighborChange event. For an 2844 explanation of neighbor states, see Section 10.1. 2846 o Bidirectional communication has been established to a 2847 neighbor. In other words, the state of the neighbor has 2848 transitioned to 2-Way or higher. 2850 o There is no longer bidirectional communication with a 2851 neighbor. In other words, the state of the neighbor has 2852 transitioned to Init or lower. 2854 o One of the bidirectional neighbors is newly declaring 2855 itself as either Designated Router or Backup Designated 2856 Router. This is detected through examination of that 2857 neighbor's Hello Packets. 2859 o One of the bidirectional neighbors is no longer 2860 declaring itself as Designated Router, or is no longer 2861 declaring itself as Backup Designated Router. This is 2862 again detected through examination of that neighbor's 2863 Hello Packets. 2865 o The advertised Router Priority for a bidirectional 2866 neighbor has changed. This is again detected through 2867 examination of that neighbor's Hello Packets. 2869 LoopInd 2870 An indication has been received that the interface is now 2871 looped back to itself. This indication can be received 2872 either from network management or from the lower level 2873 protocols. 2875 UnloopInd 2876 An indication has been received that the interface is no 2877 longer looped back. As with the LoopInd event, this 2878 indication can be received either from network management or 2879 from the lower level protocols. 2881 InterfaceDown 2882 Lower-level protocols indicate that this interface is no 2883 longer functional. No matter what the current interface 2884 state is, the new interface state will be Down. 2886 9.3. The Interface state machine 2888 A detailed description of the interface state changes follows. 2889 Each state change is invoked by an event (Section 9.2). This 2890 event may produce different effects, depending on the current 2891 state of the interface. For this reason, the state machine 2892 below is organized by current interface state and received 2893 event. Each entry in the state machine describes the resulting 2894 new interface state and the required set of additional actions. 2896 When an interface's state changes, it may be necessary to 2897 originate a new router links advertisement. See Section 12.4 2898 for more details. 2900 Some of the required actions below involve generating events for 2901 the neighbor state machine. For example, when an interface 2902 becomes inoperative, all neighbor connections associated with 2903 the interface must be destroyed. For more information on the 2904 neighbor state machine, see Section 10.3. 2906 State(s): Down 2907 Event: InterfaceUp 2909 New state: Depends upon action routine 2911 Action: Start the interval Hello Timer, enabling the 2912 periodic sending of Hello packets out the interface. 2913 If the attached network is a physical point-to-point 2914 network, Point-to-MultiPoint network or virtual 2915 link, the interface state transitions to Point-to- 2916 Point. Else, if the router is not eligible to 2917 become Designated Router the interface state 2918 transitions to DR Other. 2920 Otherwise, the attached network is a broadcast or 2921 NBMA network and the router is eligible to become 2922 Designated Router. In this case, in an attempt to 2923 discover the attached network's Designated Router 2924 the interface state is set to Waiting and the single 2925 shot Wait Timer is started. Additionally, if the 2926 network is an NBMA network examine the configured 2927 list of neighbors for this interface and generate 2928 the neighbor event Start for each neighbor that is 2929 also eligible to become Designated Router. 2931 State(s): Waiting 2933 Event: BackupSeen 2935 New state: Depends upon action routine. 2937 Action: Calculate the attached network's Backup Designated 2938 Router and Designated Router, as shown in Section 2939 9.4. As a result of this calculation, the new state 2940 of the interface will be either DR Other, Backup or 2941 DR. 2943 State(s): Waiting 2945 Event: WaitTimer 2947 New state: Depends upon action routine. 2949 Action: Calculate the attached network's Backup Designated 2950 Router and Designated Router, as shown in Section 2951 9.4. As a result of this calculation, the new state 2952 of the interface will be either DR Other, Backup or 2953 DR. 2955 State(s): DR Other, Backup or DR 2957 Event: NeighborChange 2959 New state: Depends upon action routine. 2961 Action: Recalculate the attached network's Backup Designated 2962 Router and Designated Router, as shown in Section 2963 9.4. As a result of this calculation, the new state 2964 of the interface will be either DR Other, Backup or 2965 DR. 2967 State(s): Any State 2969 Event: InterfaceDown 2971 New state: Down 2973 Action: All interface variables are reset, and interface 2974 timers disabled. Also, all neighbor connections 2975 associated with the interface are destroyed. This 2976 is done by generating the event KillNbr on all 2977 associated neighbors (see Section 10.2). 2979 State(s): Any State 2981 Event: LoopInd 2983 New state: Loopback 2985 Action: Since this interface is no longer connected to the 2986 attached network the actions associated with the 2987 above InterfaceDown event are executed. 2989 State(s): Loopback 2991 Event: UnloopInd 2993 New state: Down 2995 Action: No actions are necessary. For example, the 2996 interface variables have already been reset upon 2997 entering the Loopback state. Note that reception of 2998 an InterfaceUp event is necessary before the 2999 interface again becomes fully functional. 3001 9.4. Electing the Designated Router 3003 This section describes the algorithm used for calculating a 3004 network's Designated Router and Backup Designated Router. This 3005 algorithm is invoked by the Interface state machine. The 3006 initial time a router runs the election algorithm for a network, 3007 the network's Designated Router and Backup Designated Router are 3008 initialized to 0.0.0.0. This indicates the lack of both a 3009 Designated Router and a Backup Designated Router. 3011 The Designated Router election algorithm proceeds as follows: 3012 Call the router doing the calculation Router X. The list of 3013 neighbors attached to the network and having established 3014 bidirectional communication with Router X is examined. This 3015 list is precisely the collection of Router X's neighbors (on 3016 this network) whose state is greater than or equal to 2-Way (see 3017 Section 10.1). Router X itself is also considered to be on the 3018 list. Discard all routers from the list that are ineligible to 3019 become Designated Router. (Routers having Router Priority of 0 3020 are ineligible to become Designated Router.) The following 3021 steps are then executed, considering only those routers that 3022 remain on the list: 3024 (1) Note the current values for the network's Designated Router 3025 and Backup Designated Router. This is used later for 3026 comparison purposes. 3028 (2) Calculate the new Backup Designated Router for the network 3029 as follows. Only those routers on the list that have not 3030 declared themselves to be Designated Router are eligible to 3031 become Backup Designated Router. If one or more of these 3032 routers have declared themselves Backup Designated Router 3033 (i.e., they are currently listing themselves as Backup 3034 Designated Router, but not as Designated Router, in their 3035 Hello Packets) the one having highest Router Priority is 3036 declared to be Backup Designated Router. In case of a tie, 3037 the one having the highest Router ID is chosen. If no 3038 routers have declared themselves Backup Designated Router, 3039 choose the router having highest Router Priority, (again 3040 excluding those routers who have declared themselves 3041 Designated Router), and again use the Router ID to break 3042 ties. 3044 (3) Calculate the new Designated Router for the network as 3045 follows. If one or more of the routers have declared 3046 themselves Designated Router (i.e., they are currently 3047 listing themselves as Designated Router in their Hello 3048 Packets) the one having highest Router Priority is declared 3049 to be Designated Router. In case of a tie, the one having 3050 the highest Router ID is chosen. If no routers have 3051 declared themselves Designated Router, assign the Designated 3052 Router to be the same as the newly elected Backup Designated 3053 Router. 3055 (4) If Router X is now newly the Designated Router or newly the 3056 Backup Designated Router, or is now no longer the Designated 3057 Router or no longer the Backup Designated Router, repeat 3058 steps 2 and 3, and then proceed to step 5. For example, if 3059 Router X is now the Designated Router, when step 2 is 3060 repeated X will no longer be eligible for Backup Designated 3061 Router election. Among other things, this will ensure that 3062 no router will declare itself both Backup Designated Router 3063 and Designated Router.[5] 3065 (5) As a result of these calculations, the router itself may now 3066 be Designated Router or Backup Designated Router. See 3067 Sections 7.3 and 7.4 for the additional duties this would 3068 entail. The router's interface state should be set 3069 accordingly. If the router itself is now Designated Router, 3070 the new interface state is DR. If the router itself is now 3071 Backup Designated Router, the new interface state is Backup. 3072 Otherwise, the new interface state is DR Other. 3074 (6) If the attached network is an NBMA network, and the router 3075 itself has just become either Designated Router or Backup 3076 Designated Router, it must start sending Hello Packets to 3077 those neighbors that are not eligible to become Designated 3078 Router (see Section 9.5.1). This is done by invoking the 3079 neighbor event Start for each neighbor having a Router 3080 Priority of 0. 3082 (7) If the above calculations have caused the identity of either 3083 the Designated Router or Backup Designated Router to change, 3084 the set of adjacencies associated with this interface will 3085 need to be modified. Some adjacencies may need to be 3086 formed, and others may need to be broken. To accomplish 3087 this, invoke the event AdjOK? on all neighbors whose state 3088 is at least 2-Way. This will cause their eligibility for 3089 adjacency to be reexamined (see Sections 10.3 and 10.4). 3091 The reason behind the election algorithm's complexity is the 3092 desire for an orderly transition from Backup Designated Router 3093 to Designated Router, when the current Designated Router fails. 3094 This orderly transition is ensured through the introduction of 3095 hysteresis: no new Backup Designated Router can be chosen until 3096 the old Backup accepts its new Designated Router 3097 responsibilities. 3099 The above procedure may elect the same router to be both 3100 Designated Router and Backup Designated Router, although that 3101 router will never be the calculating router (Router X) itself. 3102 The elected Designated Router may not be the router having the 3103 highest Router Priority, nor will the Backup Designated Router 3104 necessarily have the second highest Router Priority. If Router 3105 X is not itself eligible to become Designated Router, it is 3106 possible that neither a Backup Designated Router nor a 3107 Designated Router will be selected in the above procedure. Note 3108 also that if Router X is the only attached router that is 3109 eligible to become Designated Router, it will select itself as 3110 Designated Router and there will be no Backup Designated Router 3111 for the network. 3113 9.5. Sending Hello packets 3115 Hello packets are sent out each functioning router interface. 3116 They are used to discover and maintain neighbor 3117 relationships.[6] On broadcast and NBMA networks, Hello Packets 3118 are also used to elect the Designated Router and Backup 3119 Designated Router. 3121 The format of an Hello packet is detailed in Section A.3.2. The 3122 Hello Packet contains the router's Router Priority (used in 3123 choosing the Designated Router), and the interval between Hello 3124 Packets sent out the interface (HelloInterval). The Hello 3125 Packet also indicates how often a neighbor must be heard from to 3126 remain active (RouterDeadInterval). Both HelloInterval and 3127 RouterDeadInterval must be the same for all routers attached to 3128 a common network. The Hello packet also contains the IP address 3129 mask of the attached network (Network Mask). On unnumbered 3130 point-to-point networks and on virtual links this field should 3131 be set to 0.0.0.0. 3133 The Hello packet's Options field describes the router's optional 3134 OSPF capabilities. Two optional capabilities area defined in 3135 this specification (see Sections 4.5 and A.2). The T-bit of the 3136 Options field should be set if the router is capable of 3137 calculating separate routes for each IP TOS. The E-bit should 3138 be set if and only if the attached area is capable of processing 3139 AS external advertisements (i.e., it is not a stub area). If 3140 the E-bit is set incorrectly the neighboring routers will refuse 3141 to accept the Hello Packet (see Section 10.5). Unrecognized bits 3142 in the Hello Packet's Options field should be set to zero. 3144 In order to ensure two-way communication between adjacent 3145 routers, the Hello packet contains the list of all routers on 3146 the network from which Hello Packets have been seen recently. 3147 The Hello packet also contains the router's current choice for 3148 Designated Router and Backup Designated Router. A value of 3149 0.0.0.0 in these fields means that one has not yet been 3150 selected. 3152 On broadcast networks and physical point-to-point networks, 3153 Hello packets are sent every HelloInterval seconds to the IP 3154 multicast address AllSPFRouters. On virtual links, Hello 3155 packets are sent as unicasts (addressed directly to the other 3156 end of the virtual link) every HelloInterval seconds. On Point- 3157 to-MultiPoint networks, separate Hello packets are sent to each 3158 attached neighbor every HelloInterval seconds. Sending of Hello 3159 packets on NBMA networks is covered in the next section. 3161 9.5.1. Sending Hello packets on NBMA networks 3163 Static configuration information may be necessary in order 3164 for the Hello Protocol to function on non-broadcast networks 3165 (see Sections C.5 and C.6). On NBMA networks, every 3166 attached router which is eligible to become Designated 3167 Router becomes aware of all of its neighbors on the network 3168 (either through configuration or by some unspecified 3169 mechanism). Each neighbor is labelled with the neighbor's 3170 Designated Router eligibility. 3172 The interface state must be at least Waiting for any Hello 3173 Packets to be sent out the NBMA interface. Hello Packets 3174 are then sent directly (as unicasts) to some subset of a 3175 router's neighbors. Sometimes an Hello Packet is sent 3176 periodically on a timer; at other times it is sent as a 3177 response to a received Hello Packet. A router's hello- 3178 sending behavior varies depending on whether the router 3179 itself is eligible to become Designated Router. 3181 If the router is eligible to become Designated Router, it 3182 must periodically send Hello Packets to all neighbors that 3183 are also eligible. In addition, if the router is itself the 3184 Designated Router or Backup Designated Router, it must also 3185 send periodic Hello Packets to all other neighbors. This 3186 means that any two eligible routers are always exchanging 3187 Hello Packets, which is necessary for the correct operation 3188 of the Designated Router election algorithm. To minimize 3189 the number of Hello Packets sent, the number of eligible 3190 routers on an NBMA network should be kept small. 3192 If the router is not eligible to become Designated Router, 3193 it must periodically send Hello Packets to both the 3194 Designated Router and the Backup Designated Router (if they 3195 exist). It must also send an Hello Packet in reply to an 3196 Hello Packet received from any eligible neighbor (other than 3197 the current Designated Router and Backup Designated Router). 3198 This is needed to establish an initial bidirectional 3199 relationship with any potential Designated Router. 3201 When sending Hello packets periodically to any neighbor, the 3202 interval between Hello Packets is determined by the 3203 neighbor's state. If the neighbor is in state Down, Hello 3204 Packets are sent every PollInterval seconds. Otherwise, 3205 Hello Packets are sent every HelloInterval seconds. 3207 10. The Neighbor Data Structure 3209 An OSPF router converses with its neighboring routers. Each 3210 separate conversation is described by a "neighbor data structure". 3211 Each conversation is bound to a particular OSPF router interface, 3212 and is identified either by the neighboring router's OSPF Router ID 3213 or by its Neighbor IP address (see below). Thus if the OSPF router 3214 and another router have multiple attached networks in common, 3215 multiple conversations ensue, each described by a unique neighbor 3216 data structure. Each separate conversation is loosely referred to 3217 in the text as being a separate "neighbor". 3219 The neighbor data structure contains all information pertinent to 3220 the forming or formed adjacency between the two neighbors. 3221 (However, remember that not all neighbors become adjacent.) An 3222 adjacency can be viewed as a highly developed conversation between 3223 two routers. 3225 State 3226 The functional level of the neighbor conversation. This is 3227 described in more detail in Section 10.1. 3229 Inactivity Timer 3230 A single shot timer whose firing indicates that no Hello Packet 3231 has been seen from this neighbor recently. The length of the 3232 timer is RouterDeadInterval seconds. 3234 Master/Slave 3235 When the two neighbors are exchanging databases, they form a 3236 master/slave relationship. The master sends the first Database 3237 Description Packet, and is the only part that is allowed to 3238 retransmit. The slave can only respond to the master's Database 3239 Description Packets. The master/slave relationship is 3240 negotiated in state ExStart. 3242 DD Sequence Number 3243 A 32-bit number identifying individual Database Description 3244 packets. When the neighbor state ExStart is entered, the DD 3245 sequence number should be set to a value not previously seen by 3246 the neighboring router. One possible scheme is to use the 3247 machine's time of day counter. The DD sequence number is then 3248 incremented by the master with each new Database Description 3249 packet sent. The slave's DD sequence number indicates the last 3250 packet received from the master. Only one packet is allowed 3251 outstanding at a time. 3253 Neighbor ID 3254 The OSPF Router ID of the neighboring router. The Neighbor ID 3255 is learned when Hello packets are received from the neighbor, or 3256 is configured if this is a virtual adjacency (see Section C.4). 3258 Neighbor Priority 3259 The Router Priority of the neighboring router. Contained in the 3260 neighbor's Hello packets, this item is used when selecting the 3261 Designated Router for the attached network. 3263 Neighbor IP address 3264 The IP address of the neighboring router's interface to the 3265 attached network. Used as the Destination IP address when 3266 protocol packets are sent as unicasts along this adjacency. 3267 Also used in router links advertisements as the Link ID for the 3268 attached network if the neighboring router is selected to be 3269 Designated Router (see Section 12.4.1). The Neighbor IP address 3270 is learned when Hello packets are received from the neighbor. 3271 For virtual links, the Neighbor IP address is learned during the 3272 routing table build process (see Section 15). 3274 Neighbor Options 3275 The optional OSPF capabilities supported by the neighbor. 3276 Learned during the Database Exchange process (see Section 10.6). 3277 The neighbor's optional OSPF capabilities are also listed in its 3278 Hello packets. This enables received Hello Packets to be 3279 rejected (i.e., neighbor relationships will not even start to 3280 form) if there is a mismatch in certain crucial OSPF 3281 capabilities (see Section 10.5). The optional OSPF capabilities 3282 are documented in Section 4.5. 3284 Neighbor's Designated Router 3285 The neighbor's idea of the Designated Router. If this is the 3286 neighbor itself, this is important in the local calculation of 3287 the Designated Router. Defined only on broadcast and NBMA 3288 networks. 3290 Neighbor's Backup Designated Router 3291 The neighbor's idea of the Backup Designated Router. If this is 3292 the neighbor itself, this is important in the local calculation 3293 of the Backup Designated Router. Defined only on broadcast and 3294 NBMA networks. 3296 The next set of variables are lists of link state advertisements. 3297 These lists describe subsets of the area link-state database. This 3298 memo defines five distinct types of link state advertisements, all 3299 of which may be present in an area link-state database: router 3300 links, network links, and Type 3 and 4 summary links (all stored in 3301 the area data structure), and AS external links (stored in the 3302 global data structure). 3304 Link state retransmission list 3305 The list of link state advertisements that have been flooded but 3306 not acknowledged on this adjacency. These will be retransmitted 3307 at intervals until they are acknowledged, or until the adjacency 3308 is destroyed. 3310 Database summary list 3311 The complete list of link state advertisements that make up the 3312 area link-state database, at the moment the neighbor goes into 3313 Database Exchange state. This list is sent to the neighbor in 3314 Database Description packets. 3316 Link state request list 3317 The list of link state advertisements that need to be received 3318 from this neighbor in order to synchronize the two neighbors' 3319 link-state databases. This list is created as Database 3320 Description packets are received, and is then sent to the 3321 neighbor in Link State Request packets. The list is depleted as 3322 appropriate Link State Update packets are received. 3324 10.1. Neighbor states 3326 The state of a neighbor (really, the state of a conversation 3327 being held with a neighboring router) is documented in the 3328 following sections. The states are listed in order of 3329 progressing functionality. For example, the inoperative state 3330 is listed first, followed by a list of intermediate states 3331 before the final, fully functional state is achieved. The 3332 specification makes use of this ordering by sometimes making 3333 references such as "those neighbors/adjacencies in state greater 3334 than X". Figures 12 and 13 show the graph of neighbor state 3335 changes. The arcs of the graphs are labelled with the event 3336 causing the state change. The neighbor events are documented in 3337 Section 10.2. 3339 The graph in Figure 12 shows the state changes effected by the 3340 Hello Protocol. The Hello Protocol is responsible for neighbor 3341 acquisition and maintenance, and for ensuring two way 3342 communication between neighbors. 3344 +----+ 3345 |Down| 3346 +----+ 3347 | | rt 3348 | +-------+ 3349 Hello | +---->|Attempt| 3350 Received | +-------+ 3351 | | 3352 +----+<-+ |HelloReceived 3353 |Init|<---------------+ 3354 +----+<--------+ 3355 | | 3356 |2-Way |1-Way 3357 |Received |Received 3358 | | 3359 +-------+ | +-----+ 3360 |ExStart|<--------+------->|2-Way| 3361 +-------+ +-----+ 3363 Figure 12: Neighbor state changes (Hello Protocol) 3365 In addition to the state transitions pictured, 3366 Event KillNbr always forces Down State, 3367 Event InactivityTimer always forces Down State, 3368 Event LLDown always forces Down State 3369 +-------+ 3370 |ExStart| 3371 +-------+ 3372 | 3373 NegotiationDone| 3374 +->+--------+ 3375 |Exchange| 3376 +--+--------+ 3377 | 3378 Exchange| 3379 Done | 3380 +----+ | +-------+ 3381 |Full|<---------+----->|Loading| 3382 +----+<-+ +-------+ 3383 | LoadingDone | 3384 +------------------+ 3386 Figure 13: Neighbor state changes (Database Exchange) 3388 In addition to the state transitions pictured, 3389 Event SeqNumberMismatch forces ExStart state, 3390 Event BadLSReq forces ExStart state, 3391 Event 1-Way forces Init state, 3392 Event KillNbr always forces Down State, 3393 Event InactivityTimer always forces Down State, 3394 Event LLDown always forces Down State, 3395 Event AdjOK? leads to adjacency forming/breaking 3397 The graph in Figure 13 shows the forming of an adjacency. Not 3398 every two neighboring routers become adjacent (see Section 3399 10.4). The adjacency starts to form when the neighbor is in 3400 state ExStart. After the two routers discover their 3401 master/slave status, the state transitions to Exchange. At this 3402 point the neighbor starts to be used in the flooding procedure, 3403 and the two neighboring routers begin synchronizing their 3404 databases. When this synchronization is finished, the neighbor 3405 is in state Full and we say that the two routers are fully 3406 adjacent. At this point the adjacency is listed in link state 3407 advertisements. 3409 For a more detailed description of neighbor state changes, 3410 together with the additional actions involved in each change, 3411 see Section 10.3. 3413 Down 3414 This is the initial state of a neighbor conversation. It 3415 indicates that there has been no recent information received 3416 from the neighbor. On NBMA networks, Hello packets may 3417 still be sent to "Down" neighbors, although at a reduced 3418 frequency (see Section 9.5.1). 3420 Attempt 3421 This state is only valid for neighbors attached to NBMA 3422 networks. It indicates that no recent information has been 3423 received from the neighbor, but that a more concerted effort 3424 should be made to contact the neighbor. This is done by 3425 sending the neighbor Hello packets at intervals of 3426 HelloInterval (see Section 9.5.1). 3428 Init 3429 In this state, an Hello packet has recently been seen from 3430 the neighbor. However, bidirectional communication has not 3431 yet been established with the neighbor (i.e., the router 3432 itself did not appear in the neighbor's Hello packet). All 3433 neighbors in this state (or higher) are listed in the Hello 3434 packets sent from the associated interface. 3436 2-Way 3437 In this state, communication between the two routers is 3438 bidirectional. This has been assured by the operation of 3439 the Hello Protocol. This is the most advanced state short 3440 of beginning adjacency establishment. The (Backup) 3441 Designated Router is selected from the set of neighbors in 3442 state 2-Way or greater. 3444 ExStart 3445 This is the first step in creating an adjacency between the 3446 two neighboring routers. The goal of this step is to decide 3447 which router is the master, and to decide upon the initial 3448 DD sequence number. Neighbor conversations in this state or 3449 greater are called adjacencies. 3451 Exchange 3452 In this state the router is describing its entire link state 3453 database by sending Database Description packets to the 3454 neighbor. Each Database Description Packet has a DD 3455 sequence number, and is explicitly acknowledged. Only one 3456 Database Description Packet is allowed outstanding at any 3457 one time. In this state, Link State Request Packets may 3458 also be sent asking for the neighbor's more recent 3459 advertisements. All adjacencies in Exchange state or 3460 greater are used by the flooding procedure. In fact, these 3461 adjacencies are fully capable of transmitting and receiving 3462 all types of OSPF routing protocol packets. 3464 Loading 3465 In this state, Link State Request packets are sent to the 3466 neighbor asking for the more recent advertisements that have 3467 been discovered (but not yet received) in the Exchange 3468 state. 3470 Full 3471 In this state, the neighboring routers are fully adjacent. 3472 These adjacencies will now appear in router links and 3473 network links advertisements. 3475 10.2. Events causing neighbor state changes 3477 State changes can be effected by a number of events. These 3478 events are shown in the labels of the arcs in Figures 12 and 13. 3479 The label definitions are as follows: 3481 HelloReceived 3482 An Hello packet has been received from the neighbor. 3484 Start 3485 This is an indication that Hello Packets should now be sent 3486 to the neighbor at intervals of HelloInterval seconds. This 3487 event is generated only for neighbors associated with NBMA 3488 networks. 3490 2-WayReceived 3491 Bidirectional communication has been realized between the 3492 two neighboring routers. This is indicated by the router 3493 seeing itself in the neighbor's Hello packet. 3495 NegotiationDone 3496 The Master/Slave relationship has been negotiated, and DD 3497 sequence numbers have been exchanged. This signals the 3498 start of the sending/receiving of Database Description 3499 packets. For more information on the generation of this 3500 event, consult Section 10.8. 3502 ExchangeDone 3503 Both routers have successfully transmitted a full sequence 3504 of Database Description packets. Each router now knows what 3505 parts of its link state database are out of date. For more 3506 information on the generation of this event, consult Section 3507 10.8. 3509 BadLSReq 3510 A Link State Request has been received for a link state 3511 advertisement not contained in the database. This indicates 3512 an error in the Database Exchange process. 3514 Loading Done 3515 Link State Updates have been received for all out-of-date 3516 portions of the database. This is indicated by the Link 3517 state request list becoming empty after the Database 3518 Exchange process has completed. 3520 AdjOK? 3521 A decision must be made as to whether an adjacency should be 3522 established/maintained with the neighbor. This event will 3523 start some adjacencies forming, and destroy others. 3525 The following events cause well developed neighbors to revert to 3526 lesser states. Unlike the above events, these events may occur 3527 when the neighbor conversation is in any of a number of states. 3529 SeqNumberMismatch 3530 A Database Description packet has been received that either 3531 a) has an unexpected DD sequence number, b) unexpectedly has 3532 the Init bit set or c) has an Options field differing from 3533 the last Options field received in a Database Description 3534 packet. Any of these conditions indicate that some error 3535 has occurred during adjacency establishment. 3537 1-Way 3538 An Hello packet has been received from the neighbor, in 3539 which the router is not mentioned. This indicates that 3540 communication with the neighbor is not bidirectional. 3542 KillNbr 3543 This is an indication that all communication with the 3544 neighbor is now impossible, forcing the neighbor to 3545 revert to Down state. 3547 InactivityTimer 3548 The inactivity Timer has fired. This means that no Hello 3549 packets have been seen recently from the neighbor. The 3550 neighbor reverts to Down state. 3552 LLDown 3553 This is an indication from the lower level protocols that 3554 the neighbor is now unreachable. For example, on an X.25 3555 network this could be indicated by an X.25 clear indication 3556 with appropriate cause and diagnostic fields. This event 3557 forces the neighbor into Down state. 3559 10.3. The Neighbor state machine 3561 A detailed description of the neighbor state changes follows. 3562 Each state change is invoked by an event (Section 10.2). This 3563 event may produce different effects, depending on the current 3564 state of the neighbor. For this reason, the state machine below 3565 is organized by current neighbor state and received event. Each 3566 entry in the state machine describes the resulting new neighbor 3567 state and the required set of additional actions. 3569 When a neighbor's state changes, it may be necessary to rerun 3570 the Designated Router election algorithm. This is determined by 3571 whether the interface NeighborChange event is generated (see 3572 Section 9.2). Also, if the Interface is in DR state (the router 3573 is itself Designated Router), changes in neighbor state may 3574 cause a new network links advertisement to be originated (see 3575 Section 12.4). 3577 When the neighbor state machine needs to invoke the interface 3578 state machine, it should be done as a scheduled task (see 3579 Section 4.4). This simplifies things, by ensuring that neither 3580 state machine will be executed recursively. 3582 State(s): Down 3584 Event: Start 3586 New state: Attempt 3588 Action: Send an Hello Packet to the neighbor (this neighbor 3589 is always associated with an NBMA network) and start 3590 the Inactivity Timer for the neighbor. The timer's 3591 later firing would indicate that communication with 3592 the neighbor was not attained. 3594 State(s): Attempt 3596 Event: HelloReceived 3598 New state: Init 3599 Action: Restart the Inactivity Timer for the neighbor, since 3600 the neighbor has now been heard from. 3602 State(s): Down 3604 Event: HelloReceived 3606 New state: Init 3608 Action: Start the Inactivity Timer for the neighbor. The 3609 timer's later firing would indicate that the 3610 neighbor is dead. 3612 State(s): Init or greater 3614 Event: HelloReceived 3616 New state: No state change. 3618 Action: Restart the Inactivity Timer for the neighbor, since 3619 the neighbor has again been heard from. 3621 State(s): Init 3623 Event: 2-WayReceived 3625 New state: Depends upon action routine. 3627 Action: Determine whether an adjacency should be established 3628 with the neighbor (see Section 10.4). If not, the 3629 new neighbor state is 2-Way. 3631 Otherwise (an adjacency should be established) the 3632 neighbor state transitions to ExStart. Upon 3633 entering this state, the router increments the DD 3634 sequence number for this neighbor. If this is the 3635 first time that an adjacency has been attempted, the 3636 DD sequence number should be assigned some unique 3637 value (like the time of day clock). It then 3638 declares itself master (sets the master/slave bit to 3639 master), and starts sending Database Description 3640 Packets, with the initialize (I), more (M) and 3641 master (MS) bits set. This Database Description 3642 Packet should be otherwise empty. This Database 3643 Description Packet should be retransmitted at 3644 intervals of RxmtInterval until the next state is 3645 entered (see Section 10.8). 3647 State(s): ExStart 3649 Event: NegotiationDone 3651 New state: Exchange 3653 Action: The router must list the contents of its entire area 3654 link state database in the neighbor Database summary 3655 list. The area link state database consists of the 3656 router links, network links and summary links 3657 contained in the area structure, along with the AS 3658 external links contained in the global structure. 3659 AS external link advertisements are omitted from a 3660 virtual neighbor's Database summary list. AS 3661 external advertisements are omitted from the 3662 Database summary list if the area has been 3663 configured as a stub (see Section 3.6). 3664 Advertisements whose age is equal to MaxAge are 3665 instead added to the neighbor's Link state 3666 retransmission list. A summary of the Database 3667 summary list will be sent to the neighbor in 3668 Database Description packets. Each Database 3669 Description Packet has a DD sequence number, and is 3670 explicitly acknowledged. Only one Database 3671 Description Packet is allowed outstanding at any one 3672 time. For more detail on the sending and receiving 3673 of Database Description packets, see Sections 10.8 3674 and 10.6. 3676 State(s): Exchange 3678 Event: ExchangeDone 3680 New state: Depends upon action routine. 3682 Action: If the neighbor Link state request list is empty, 3683 the new neighbor state is Full. No other action is 3684 required. This is an adjacency's final state. 3686 Otherwise, the new neighbor state is Loading. Start 3687 (or continue) sending Link State Request packets to 3688 the neighbor (see Section 10.9). These are requests 3689 for the neighbor's more recent advertisements (which 3690 were discovered but not yet received in the Exchange 3691 state). These advertisements are listed in the Link 3692 state request list associated with the neighbor. 3694 State(s): Loading 3696 Event: Loading Done 3698 New state: Full 3700 Action: No action required. This is an adjacency's final 3701 state. 3703 State(s): 2-Way 3705 Event: AdjOK? 3707 New state: Depends upon action routine. 3709 Action: Determine whether an adjacency should be formed with 3710 the neighboring router (see Section 10.4). If not, 3711 the neighbor state remains at 2-Way. Otherwise, 3712 transition the neighbor state to ExStart and perform 3713 the actions associated with the above state machine 3714 entry for state Init and event 2-WayReceived. 3716 State(s): ExStart or greater 3718 Event: AdjOK? 3720 New state: Depends upon action routine. 3722 Action: Determine whether the neighboring router should 3723 still be adjacent. If yes, there is no state change 3724 and no further action is necessary. 3726 Otherwise, the (possibly partially formed) adjacency 3727 must be destroyed. The neighbor state transitions 3728 to 2-Way. The Link state retransmission list, 3729 Database summary list and Link state request list 3730 are cleared of link state advertisements. 3732 State(s): Exchange or greater 3733 Event: SeqNumberMismatch 3735 New state: ExStart 3737 Action: The (possibly partially formed) adjacency is torn 3738 down, and then an attempt is made at 3739 reestablishment. The neighbor state first 3740 transitions to ExStart. The Link state 3741 retransmission list, Database summary list and Link 3742 state request list are cleared of link state 3743 advertisements. Then the router increments the DD 3744 sequence number for this neighbor, declares itself 3745 master (sets the master/slave bit to master), and 3746 starts sending Database Description Packets, with 3747 the initialize (I), more (M) and master (MS) bits 3748 set. This Database Description Packet should be 3749 otherwise empty (see Section 10.8). 3751 State(s): Exchange or greater 3753 Event: BadLSReq 3755 New state: ExStart 3757 Action: The action for event BadLSReq is exactly the same as 3758 for the neighbor event SeqNumberMismatch. The 3759 (possibly partially formed) adjacency is torn down, 3760 and then an attempt is made at reestablishment. For 3761 more information, see the neighbor state machine 3762 entry that is invoked when event SeqNumberMismatch 3763 is generated in state Exchange or greater. 3765 State(s): Any state 3767 Event: KillNbr 3769 New state: Down 3771 Action: The Link state retransmission list, Database summary 3772 list and Link state request list are cleared of link 3773 state advertisements. Also, the Inactivity Timer is 3774 disabled. 3776 State(s): Any state 3777 Event: LLDown 3779 New state: Down 3781 Action: The Link state retransmission list, Database summary 3782 list and Link state request list are cleared of link 3783 state advertisements. Also, the Inactivity Timer is 3784 disabled. 3786 State(s): Any state 3788 Event: InactivityTimer 3790 New state: Down 3792 Action: The Link state retransmission list, Database summary 3793 list and Link state request list are cleared of link 3794 state advertisements. 3796 State(s): 2-Way or greater 3798 Event: 1-WayReceived 3800 New state: Init 3802 Action: The Link state retransmission list, Database summary 3803 list and Link state request list are cleared of link 3804 state advertisements. 3806 State(s): 2-Way or greater 3808 Event: 2-WayReceived 3810 New state: No state change. 3812 Action: No action required. 3814 State(s): Init 3816 Event: 1-WayReceived 3818 New state: No state change. 3820 Action: No action required. 3822 10.4. Whether to become adjacent 3824 Adjacencies are established with some subset of the router's 3825 neighbors. Routers connected by point-to-point networks, 3826 Point-to-MultiPoint networks and virtual links always become 3827 adjacent. On broadcast and NBMA networks, all routers become 3828 adjacent to both the Designated Router and the Backup Designated 3829 Router. 3831 The adjacency-forming decision occurs in two places in the 3832 neighbor state machine. First, when bidirectional communication 3833 is initially established with the neighbor, and secondly, when 3834 the identity of the attached network's (Backup) Designated 3835 Router changes. If the decision is made to not attempt an 3836 adjacency, the state of the neighbor communication stops at 2- 3837 Way. 3839 An adjacency should be established with a bidirectional neighbor 3840 when at least one of the following conditions holds: 3842 o The underlying network type is point-to-point 3844 o The underlying network type is Point-to-MultiPoint 3846 o The underlying network type is virtual link 3848 o The router itself is the Designated Router 3850 o The router itself is the Backup Designated Router 3852 o The neighboring router is the Designated Router 3854 o The neighboring router is the Backup Designated Router 3856 10.5. Receiving Hello Packets 3858 This section explains the detailed processing of a received 3859 Hello Packet. (See Section A.3.2 for the format of Hello 3860 packets.) The generic input processing of OSPF packets will 3861 have checked the validity of the IP header and the OSPF packet 3862 header. Next, the values of the Network Mask, HelloInterval, 3863 and RouterDeadInterval fields in the received Hello packet must 3864 be checked against the values configured for the receiving 3865 interface. Any mismatch causes processing to stop and the 3866 packet to be dropped. In other words, the above fields are 3867 really describing the attached network's configuration. However, 3868 there is one exception to the above rule: on point-to-point 3869 networks and on virtual links, the Network Mask in the received 3870 Hello Packet should be ignored. 3872 The receiving interface attaches to a single OSPF area (this 3873 could be the backbone). The setting of the E-bit found in the 3874 Hello Packet's Options field must match this area's 3875 ExternalRoutingCapability. If AS external advertisements are 3876 not flooded into/throughout the area (i.e, the area is a "stub") 3877 the E-bit must be clear in received Hello Packets, otherwise the 3878 E-bit must be set. A mismatch causes processing to stop and the 3879 packet to be dropped. The setting of the rest of the bits in 3880 the Hello Packet's Options field should be ignored. 3882 At this point, an attempt is made to match the source of the 3883 Hello Packet to one of the receiving interface's neighbors. If 3884 the receiving interface connects to a broadcast, Point-to- 3885 MultiPoint or NBMA network the source is identified by the IP 3886 source address found in the Hello's IP header. If the receiving 3887 interface connects to a point-to-point link or a virtual link, 3888 the source is identified by the Router ID found in the Hello's 3889 OSPF packet header. The interface's current list of neighbors 3890 is contained in the interface's data structure. If a matching 3891 neighbor structure cannot be found, (i.e., this is the first 3892 time the neighbor has been detected), one is created. The 3893 initial state of a newly created neighbor is set to Down. 3895 When receiving an Hello Packet from a neighbor on a broadcast, 3896 Point-to-MultiPoint or NBMA network, set the neighbor 3897 structure's Neighbor ID equal to the Router ID found in the 3898 packet's OSPF header. When receiving an Hello on a point-to- 3899 point network (but not on a virtual link) set the neighbor 3900 structure's Neighbor IP address to the packet's IP source 3901 address. 3903 Now the rest of the Hello Packet is examined, generating events 3904 to be given to the neighbor and interface state machines. These 3905 state machines are specified either to be executed or scheduled 3906 (see Section 4.4). For example, by specifying below that the 3907 neighbor state machine be executed in line, several neighbor 3908 state transitions may be effected by a single received Hello: 3910 o Each Hello Packet causes the neighbor state machine to be 3911 executed with the event HelloReceived. 3913 o Then the list of neighbors contained in the Hello Packet is 3914 examined. If the router itself appears in this list, the 3915 neighbor state machine should be executed with the event 2- 3916 WayReceived. Otherwise, the neighbor state machine should 3917 be executed with the event 1-WayReceived, and the processing 3918 of the packet stops. 3920 o Next, the Hello Packet's Router Priority field is examined. 3921 If this field is different than the one previously received 3922 from the neighbor, the receiving interface's state machine 3923 is scheduled with the event NeighborChange. In any case, 3924 the Router Priority field in the neighbor data structure 3925 should be updated accordingly. 3927 o Next the Designated Router field in the Hello Packet is 3928 examined. If the neighbor is both declaring itself to be 3929 Designated Router (Designated Router field = Neighbor IP 3930 address) and the Backup Designated Router field in the 3931 packet is equal to 0.0.0.0 and the receiving interface is in 3932 state Waiting, the receiving interface's state machine is 3933 scheduled with the event BackupSeen. Otherwise, if the 3934 neighbor is declaring itself to be Designated Router and it 3935 had not previously, or the neighbor is not declaring itself 3936 Designated Router where it had previously, the receiving 3937 interface's state machine is scheduled with the event 3938 NeighborChange. In any case, the Neighbors' Designated 3939 Router item in the neighbor structure is updated 3940 accordingly. 3942 o Finally, the Backup Designated Router field in the Hello 3943 Packet is examined. If the neighbor is declaring itself to 3944 be Backup Designated Router (Backup Designated Router field 3945 = Neighbor IP address) and the receiving interface is in 3946 state Waiting, the receiving interface's state machine is 3947 scheduled with the event BackupSeen. Otherwise, if the 3948 neighbor is declaring itself to be Backup Designated Router 3949 and it had not previously, or the neighbor is not declaring 3950 itself Backup Designated Router where it had previously, the 3951 receiving interface's state machine is scheduled with the 3952 event NeighborChange. In any case, the Neighbor's Backup 3953 Designated Router item in the neighbor structure is updated 3954 accordingly. 3956 On NBMA networks, receipt of an Hello Packet may also cause an 3957 Hello Packet to be sent back to the neighbor in response. See 3958 Section 9.5.1 for more details. 3960 10.6. Receiving Database Description Packets 3962 This section explains the detailed processing of a received 3963 Database Description Packet. The incoming Database Description 3964 Packet has already been associated with a neighbor and receiving 3965 interface by the generic input packet processing (Section 8.2). 3966 The further processing of the Database Description Packet 3967 depends on the neighbor state. If the neighbor's state is Down 3968 or Attempt the packet should be ignored. Otherwise, if the 3969 state is: 3971 Init 3972 The neighbor state machine should be executed with the event 3973 2-WayReceived. This causes an immediate state change to 3974 either state 2-Way or state ExStart. If the new state is 3975 ExStart, the processing of the current packet should then 3976 continue in this new state by falling through to case 3977 ExStart below. 3979 2-Way 3980 The packet should be ignored. Database Description Packets 3981 are used only for the purpose of bringing up adjacencies.[7] 3983 ExStart 3984 If the received packet matches one of the following cases, 3985 then the neighbor state machine should be executed with the 3986 event NegotiationDone (causing the state to transition to 3987 Exchange), the packet's Options field should be recorded in 3988 the neighbor structure's Neighbor Options field and the 3989 packet should be accepted as next in sequence and processed 3990 further (see below). Otherwise, the packet should be 3991 ignored. 3993 o The initialize(I), more (M) and master(MS) bits are set, 3994 the contents of the packet are empty, and the neighbor's 3995 Router ID is larger than the router's own. In this case 3996 the router is now Slave. Set the master/slave bit to 3997 slave, and set the DD sequence number to that specified 3998 by the master. 4000 o The initialize(I) and master(MS) bits are off, the 4001 packet's DD sequence number equals the router's own DD 4002 sequence number (indicating acknowledgment) and the 4003 neighbor's Router ID is smaller than the router's own. 4004 In this case the router is Master. 4006 Exchange 4007 If the state of the MS-bit is inconsistent with the 4008 master/slave state of the connection, generate the neighbor 4009 event SeqNumberMismatch and stop processing the packet. 4010 Otherwise: 4012 o If the initialize(I) bit is set, generate the neighbor 4013 event SeqNumberMismatch and stop processing the packet. 4015 o If the packet's Options field indicates a different set 4016 of optional OSPF capabilities than were previously 4017 received from the neighbor (recorded in the Neighbor 4018 Options field of the neighbor structure), generate the 4019 neighbor event SeqNumberMismatch and stop processing the 4020 packet. 4022 o If the router is master, and the packet's DD sequence 4023 number equals the router's own DD sequence number (this 4024 packet is the next in sequence) the packet should be 4025 accepted and its contents processed (below). 4027 o If the router is master, and the packet's DD sequence 4028 number is one less than the router's DD sequence number, 4029 the packet is a duplicate. Duplicates should be 4030 discarded by the master. 4032 o If the router is slave, and the packet's DD sequence 4033 number is one more than the router's own DD sequence 4034 number (this packet is the next in sequence) the packet 4035 should be accepted and its contents processed (below). 4037 o If the router is slave, and the packet's DD sequence 4038 number is equal to the router's DD sequence number, the 4039 packet is a duplicate. The slave must respond to 4040 duplicates by repeating the last Database Description 4041 packet that it had sent. 4043 o Else, generate the neighbor event SeqNumberMismatch and 4044 stop processing the packet. 4046 Loading or Full 4047 In this state, the router has sent and received an entire 4048 sequence of Database Description Packets. The only packets 4049 received should be duplicates (see above). In particular, 4050 the packet's Options field should match the set of optional 4051 OSPF capabilities previously indicated by the neighbor 4052 (stored in the neighbor structure's Neighbor Options field). 4053 Any other packets received, including the reception of a 4054 packet with the Initialize(I) bit set, should generate the 4055 neighbor event SeqNumberMismatch.[8] Duplicates should be 4056 discarded by the master. The slave must respond to 4057 duplicates by repeating the last Database Description packet 4058 that it had sent. 4060 When the router accepts a received Database Description Packet 4061 as the next in sequence the packet contents are processed as 4062 follows. For each link state advertisement listed, the 4063 advertisement's LS type is checked for validity. If the LS type 4064 is unknown (e.g., not one of the LS types 1-5 defined by this 4065 specification), or if this is a AS external advertisement (LS 4066 type = 5) and the neighbor is associated with a stub area, 4067 generate the neighbor event SeqNumberMismatch and stop 4068 processing the packet. Otherwise, the router looks up the 4069 advertisement in its database to see whether it also has an 4070 instance of the link state advertisement. If it does not, or if 4071 the database copy is less recent (see Section 13.1), the link 4072 state advertisement is put on the Link state request list so 4073 that it can be requested (immediately or at some later time) in 4074 Link State Request Packets. 4076 When the router accepts a received Database Description Packet 4077 as the next in sequence, it also performs the following actions, 4078 depending on whether it is master or slave: 4080 Master 4081 Increments the DD sequence number. If the router has 4082 already sent its entire sequence of Database Description 4083 Packets, and the just accepted packet has the more bit (M) 4084 set to 0, the neighbor event ExchangeDone is generated. 4085 Otherwise, it should send a new Database Description to the 4086 slave. 4088 Slave 4089 Sets the DD sequence number to the DD sequence number 4090 appearing in the received packet. The slave must send a 4091 Database Description Packet in reply. If the received 4092 packet has the more bit (M) set to 0, and the packet to be 4093 sent by the slave will also have the M-bit set to 0, the 4094 neighbor event ExchangeDone is generated. Note that the 4095 slave always generates this event before the master. 4097 10.7. Receiving Link State Request Packets 4099 This section explains the detailed processing of received Link 4100 State Request packets. Received Link State Request Packets 4101 specify a list of link state advertisements that the neighbor 4102 wishes to receive. Link State Request Packets should be 4103 accepted when the neighbor is in states Exchange, Loading, or 4104 Full. In all other states Link State Request Packets should be 4105 ignored. 4107 Each link state advertisement specified in the Link State 4108 Request packet should be located in the router's database, and 4109 copied into Link State Update packets for transmission to the 4110 neighbor. These link state advertisements should NOT be placed 4111 on the Link state retransmission list for the neighbor. If a 4112 link state advertisement cannot be found in the database, 4113 something has gone wrong with the Database Exchange process, and 4114 neighbor event BadLSReq should be generated. 4116 10.8. Sending Database Description Packets 4118 This section describes how Database Description Packets are sent 4119 to a neighbor. The router's optional OSPF capabilities (see 4120 Section 4.5) are transmitted to the neighbor in the Options 4121 field of the Database Description packet. The router should 4122 maintain the same set of optional capabilities throughout the 4123 Database Exchange and flooding procedures. If for some reason 4124 the router's optional capabilities change, the Database Exchange 4125 procedure should be restarted by reverting to neighbor state 4126 ExStart. There are currently two optional capabilities defined. 4127 The T-bit should be set if and only if the router is capable of 4128 calculating separate routes for each IP TOS. The E-bit should 4129 be set if and only if the attached network belongs to a non-stub 4130 area. The rest of the Options field should be set to zero. 4132 The sending of Database Description packets depends on the 4133 neighbor's state. In state ExStart the router sends empty 4134 Database Description packets, with the initialize (I), more (M) 4135 and master (MS) bits set. These packets are retransmitted every 4136 RxmtInterval seconds. 4138 In state Exchange the Database Description Packets actually 4139 contain summaries of the link state information contained in the 4140 router's database. Each link state advertisement in the area's 4141 link-state database (at the time the neighbor transitions into 4142 Exchange state) is listed in the neighbor Database summary list. 4143 When a new Database Description Packet is to be sent, the 4144 packet's DD sequence number is incremented, and the (new) top of 4145 the Database summary list is described by the packet. Items are 4146 removed from the Database summary list when the previous packet 4147 is acknowledged. 4149 In state Exchange, the determination of when to send a Database 4150 Description packet depends on whether the router is master or 4151 slave: 4153 Master 4154 Database Description packets are sent when either a) the 4155 slave acknowledges the previous Database Description packet 4156 by echoing the DD sequence number or b) RxmtInterval seconds 4157 elapse without an acknowledgment, in which case the previous 4158 Database Description packet is retransmitted. 4160 Slave 4161 Database Description packets are sent only in response to 4162 Database Description packets received from the master. If 4163 the Database Description packet received from the master is 4164 new, a new Database Description packet is sent, otherwise 4165 the previous Database Description packet is resent. 4167 In states Loading and Full the slave must resend its last 4168 Database Description packet in response to duplicate Database 4169 Description packets received from the master. For this reason 4170 the slave must wait RouterDeadInterval seconds before freeing 4171 the last Database Description packet. Reception of a Database 4172 Description packet from the master after this interval will 4173 generate a SeqNumberMismatch neighbor event. 4175 10.9. Sending Link State Request Packets 4177 In neighbor states Exchange or Loading, the Link state request 4178 list contains a list of those link state advertisements that 4179 need to be obtained from the neighbor. To request these 4180 advertisements, a router sends the neighbor the beginning of the 4181 Link state request list, packaged in a Link State Request 4182 packet. 4184 When the neighbor responds to these requests with the proper 4185 Link State Update packet(s), the Link state request list is 4186 truncated and a new Link State Request packet is sent. This 4187 process continues until the Link state request list becomes 4188 empty. Unsatisfied Link State Request packets are retransmitted 4189 at intervals of RxmtInterval. There should be at most one Link 4190 State Request packet outstanding at any one time. 4192 When the Link state request list becomes empty, and the neighbor 4193 state is Loading (i.e., a complete sequence of Database 4194 Description packets has been sent to and received from the 4195 neighbor), the Loading Done neighbor event is generated. 4197 10.10. An Example 4199 Figure 14 shows an example of an adjacency forming. Routers RT1 4200 and RT2 are both connected to a broadcast network. It is 4201 assumed that RT2 is the Designated Router for the network, and 4202 that RT2 has a higher Router ID than Router RT1. 4204 The neighbor state changes realized by each router are listed on 4205 the sides of the figure. 4207 At the beginning of Figure 14, Router RT1's interface to the 4208 network becomes operational. It begins sending Hello Packets, 4209 although it doesn't know the identity of the Designated Router 4210 or of any other neighboring routers. Router RT2 hears this 4211 hello (moving the neighbor to Init state), and in its next Hello 4212 Packet indicates that it is itself the Designated Router and 4213 that it has heard Hello Packets from RT1. This in turn causes 4214 RT1 to go to state ExStart, as it starts to bring up the 4215 adjacency. 4217 RT1 begins by asserting itself as the master. When it sees that 4218 RT2 is indeed the master (because of RT2's higher Router ID), 4219 RT1 transitions to slave state and adopts its neighbor's DD 4220 sequence number. Database Description packets are then 4221 exchanged, with polls coming from the master (RT2) and responses 4222 from the slave (RT1). This sequence of Database Description 4223 Packets ends when both the poll and associated response has the 4224 M-bit off. 4226 In this example, it is assumed that RT2 has a completely up to 4227 date database. In that case, RT2 goes immediately into Full 4228 state. RT1 will go into Full state after updating the necessary 4229 parts of its database. This is done by sending Link State 4230 Request Packets, and receiving Link State Update Packets in 4231 response. Note that, while RT1 has waited until a complete set 4232 of Database Description Packets has been received (from RT2) 4233 before sending any Link State Request Packets, this need not be 4234 the case. RT1 could have interleaved the sending of Link State 4235 Request Packets with the reception of Database Description 4236 +---+ +---+ 4237 |RT1| |RT2| 4238 +---+ +---+ 4240 Down Down 4241 Hello(DR=0,seen=0) 4242 ------------------------------> 4243 Hello (DR=RT2,seen=RT1,...) Init 4244 <------------------------------ 4245 ExStart D-D (Seq=x,I,M,Master) 4246 ------------------------------> 4247 D-D (Seq=y,I,M,Master) ExStart 4248 <------------------------------ 4249 Exchange D-D (Seq=y,M,Slave) 4250 ------------------------------> 4251 D-D (Seq=y+1,M,Master) Exchange 4252 <------------------------------ 4253 D-D (Seq=y+1,M,Slave) 4254 ------------------------------> 4255 ... 4256 ... 4257 ... 4258 D-D (Seq=y+n, Master) 4259 <------------------------------ 4260 D-D (Seq=y+n, Slave) 4261 Loading ------------------------------> 4262 LS Request Full 4263 ------------------------------> 4264 LS Update 4265 <------------------------------ 4266 LS Request 4267 ------------------------------> 4268 LS Update 4269 <------------------------------ 4270 Full 4272 Figure 14: An adjacency bring-up example 4273 Packets. 4275 11. The Routing Table Structure 4277 The routing table data structure contains all the information 4278 necessary to forward an IP data packet toward its destination. Each 4279 routing table entry describes the collection of best paths to a 4280 particular destination. When forwarding an IP data packet, the 4281 routing table entry providing the best match for the packet's IP 4282 destination is located. The matching routing table entry then 4283 provides the next hop towards the packet's destination. OSPF also 4284 provides for the existence of a default route (Destination ID = 4285 DefaultDestination, Address Mask = 0x00000000). When the default 4286 route exists, it matches all IP destinations (although any other 4287 matching entry is a better match). Finding the routing table entry 4288 that best matches an IP destination is further described in Section 4289 11.1. 4291 There is a single routing table in each router. Two sample routing 4292 tables are described in Sections 11.2 and 11.3. The building of the 4293 routing table is discussed in Section 16. 4295 The rest of this section defines the fields found in a routing table 4296 entry. The first set of fields describes the routing table entry's 4297 destination. 4299 Destination Type 4300 The destination can be one of three types. Only the first type, 4301 Network, is actually used when forwarding IP data traffic. The 4302 other destinations are used solely as intermediate steps in the 4303 routing table build process. 4305 Network 4306 A range of IP addresses, to which IP data traffic may be 4307 forwarded. This includes IP networks (class A, B, or C), IP 4308 subnets, IP supernets and single IP hosts. The default 4309 route also falls in this category. 4311 Area border router 4312 Routers that are connected to multiple OSPF areas. Such 4313 routers originate summary link advertisements. These 4314 routing table entries are used when calculating the inter- 4315 area routes (see Section 16.2). These routing table entries 4316 may also be associated with configured virtual links. 4318 AS boundary router 4319 Routers that originate AS external link advertisements. 4320 These routing table entries are used when calculating the AS 4321 external routes (see Section 16.4). 4323 Destination ID 4324 The destination's identifier or name. This depends on the 4325 Destination Type. For networks, the identifier is their 4326 associated IP address. For all other types, the identifier is 4327 the OSPF Router ID.[9] 4329 Address Mask 4330 Only defined for networks. The network's IP address together 4331 with its address mask defines a range of IP addresses. For IP 4332 subnets, the address mask is referred to as the subnet mask. 4333 For host routes, the mask is "all ones" (0xffffffff). 4335 Optional Capabilities 4336 When the destination is a router (either an area border router 4337 or an AS boundary router) this field indicates the optional OSPF 4338 capabilities supported by the destination router. The two 4339 optional capabilities currently defined by this specification 4340 are the ability to route based on IP TOS and the ability to 4341 process AS external link advertisements. For a further 4342 discussion of OSPF's optional capabilities, see Section 4.5. 4344 The set of paths to use for a destination may vary based on IP Type 4345 of Service and the OSPF area to which the paths belong. This means 4346 that there may be multiple routing table entries for the same 4347 destination, depending on the values of the next two fields. 4349 Type of Service 4350 There can be a separate set of routes for each IP Type of 4351 Service. The encoding of TOS in OSPF link state advertisements 4352 is described in Section 12.3. 4354 Area 4355 This field indicates the area whose link state information has 4356 led to the routing table entry's collection of paths. This is 4357 called the entry's associated area. For sets of AS external 4358 paths, this field is not defined. For destinations of type 4359 "area border router", there may be separate sets of paths (and 4360 therefore separate routing table entries) associated with each 4361 of several areas. This will happen when two area border routers 4362 share multiple areas in common. For all other destination 4363 types, only the set of paths associated with the best area (the 4364 one providing the shortest route) is kept. 4366 The rest of the routing table entry describes the set of paths to 4367 the destination. The following fields pertain to the set of paths 4368 as a whole. In other words, each one of the paths contained in a 4369 routing table entry is of the same path-type and cost (see below). 4371 Path-type 4372 There are four possible types of paths used to route traffic to 4373 the destination, listed here in order of preference: intra-area, 4374 inter-area, type 1 external or type 2 external. Intra-area 4375 paths indicate destinations belonging to one of the router's 4376 attached areas. Inter-area paths are paths to destinations in 4377 other OSPF areas. These are discovered through the examination 4378 of received summary link advertisements. AS external paths are 4379 paths to destinations external to the AS. These are detected 4380 through the examination of received AS external link 4381 advertisements. 4383 Cost 4384 The link state cost of the path to the destination. For all 4385 paths except type 2 external paths this describes the entire 4386 path's cost. For Type 2 external paths, this field describes 4387 the cost of the portion of the path internal to the AS. This 4388 cost is calculated as the sum of the costs of the path's 4389 constituent links. 4391 Type 2 cost 4392 Only valid for type 2 external paths. For these paths, this 4393 field indicates the cost of the path's external portion. This 4394 cost has been advertised by an AS boundary router, and is the 4395 most significant part of the total path cost. For example, a 4396 type 2 external path with type 2 cost of 5 is always preferred 4397 over a path with type 2 cost of 10, regardless of the cost of 4398 the two paths' internal components. 4400 Link State Origin 4401 Valid only for intra-area paths, this field indicates the link 4402 state advertisement (router links or network links) that 4403 directly references the destination. For example, if the 4404 destination is a transit network, this is the transit network's 4405 network links advertisement. If the destination is a stub 4406 network, this is the router links advertisement for the attached 4407 router. The advertisement is discovered during the shortest- 4408 path tree calculation (see Section 16.1). Multiple 4409 advertisements may reference the destination, however a tie- 4410 breaking scheme always reduces the choice to a single 4411 advertisement. The Link State Origin field is not used by the 4412 OSPF protocol, but it is used by the routing table calculation 4413 in OSPF's Multicast routing extensions (MOSPF). 4415 When multiple paths of equal path-type and cost exist to a 4416 destination (called elsewhere "equal-cost" paths), they are stored 4417 in a single routing table entry. Each one of the "equal-cost" paths 4418 is distinguished by the following fields: 4420 Next hop 4421 The outgoing router interface to use when forwarding traffic to 4422 the destination. On broadcast, Point-to-MultiPoint and NBMA 4423 networks, the next hop also includes the IP address of the next 4424 router (if any) in the path towards the destination. This next 4425 router will always be one of the adjacent neighbors. 4427 Advertising router 4428 Valid only for inter-area and AS external paths. This field 4429 indicates the Router ID of the router advertising the summary 4430 link or AS external link that led to this path. 4432 11.1. Routing table lookup 4434 When an IP data packet is received, an OSPF router finds the 4435 routing table entry that best matches the packet's destination. 4436 This routing table entry then provides the outgoing interface 4437 and next hop router to use in forwarding the packet. This 4438 section describes the process of finding the best matching 4439 routing table entry. The process consists of a number of steps, 4440 wherein the collection of routing table entries is progressively 4441 pruned. In the end, the single routing table entry remaining is 4442 called the "best match". 4444 Before the lookup begins, "discard" routing table entries should 4445 be inserted into the routing table for each of the router's 4446 active area address ranges (see Section 3.5). (Remember that an 4447 area range is considered "active" if the range contains one or 4448 more networks reachable by intra-area paths.) The destination of 4449 a "discard" entry is the set of addresses described by its 4450 associated active area address range, and the path type of each 4451 "discard" entry is set to "inter-area".[10] 4453 Note that the steps described below may fail to produce a best 4454 match routing table entry (i.e., all existing routing table 4455 entries are pruned for some reason or another), or the best 4456 match routing table entry may be one of the above "discard" 4457 routing table entries. In these cases, the packet's IP 4458 destination is considered unreachable. Instead of being 4459 forwarded, the packet should be discarded and an ICMP 4460 destination unreachable message should be returned to the 4461 packet's source. 4463 (1) Select the complete set of "matching" routing table entries 4464 from the routing table. Each routing table entry describes 4465 a (set of) path(s) to a range of IP addresses. If the data 4466 packet's IP destination falls into an entry's range of IP 4467 addresses, the routing table entry is called a match. (It is 4468 quite likely that multiple entries will match the data 4469 packet. For example, a default route will match all 4470 packets.) 4472 (2) Reduce the set of matching entries to those having the most 4473 preferential path-type (see Section 11). OSPF has a four 4474 level hierarchy of paths. Intra-area paths are the most 4475 preferred, followed in order by inter-area, type 1 external 4476 and type 2 external paths. 4478 (3) Select the remaining routing table entry that provides the 4479 most specific (longest) match. Another way of saying this is 4480 to choose the remaining entry that specifies the narrowest 4481 range of IP addresses.[11] For example, the entry for the 4482 address/mask pair of (128.185.1.0, 0xffffff00) is more 4483 specific than an entry for the pair (128.185.0.0, 4484 0xffff0000). The default route is the least specific match, 4485 since it matches all destinations. 4487 (4) At this point, there may still be multiple routing table 4488 entries remaining. Each routing entry will specify the same 4489 range of IP addresses, but a different IP Type of Service. 4490 Select the routing table entry whose TOS value matches the 4491 TOS found in the packet header. If there is no routing table 4492 entry for this TOS, select the routing table entry for TOS 4493 0. In other words, packets requesting TOS X are routed along 4494 the TOS 0 path if a TOS X path does not exist. 4496 11.2. Sample routing table, without areas 4498 Consider the Autonomous System pictured in Figure 2. No OSPF 4499 areas have been configured. A single metric is shown per 4500 outbound interface, indicating that routes will not vary based 4501 on TOS. The calculation of Router RT6's routing table proceeds 4502 as described in Section 2.2. The resulting routing table is 4503 shown in Table 12. Destination types are abbreviated: Network 4504 as "N", area border router as "BR" and AS boundary router as 4505 "ASBR". 4507 There are no instances of multiple equal-cost shortest paths in 4508 this example. Also, since there are no areas, there are no 4509 inter-area paths. 4511 Routers RT5 and RT7 are AS boundary routers. Intra-area routes 4512 have been calculated to Routers RT5 and RT7. This allows 4513 external routes to be calculated to the destinations advertised 4514 by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is 4515 assumed all AS external advertisements originated by RT5 and RT7 4516 are advertising type 1 external metrics. This results in type 1 4517 external paths being calculated to destinations N12-N15. 4519 11.3. Sample routing table, with areas 4521 Consider the previous example, this time split into OSPF areas. 4522 An OSPF area configuration is pictured in Figure 6. Router 4523 RT4's routing table will be described for this area 4524 configuration. Router RT4 has a connection to Area 1 and a 4525 backbone connection. This causes Router RT4 to view the AS as 4526 the concatenation of the two graphs shown in Figures 7 and 8. 4527 The resulting routing table is displayed in Table 13. 4529 Again, Routers RT5 and RT7 are AS boundary routers. Routers 4530 RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 4531 there are two routing table entries (in this case having 4532 identical paths) for Router RT7, in its dual capacities as an 4533 area border router and an AS boundary router. Note also that 4534 there are two routing entries for the area border router RT3, 4535 since it has two areas in common with RT4 (Area 1 and the 4536 backbone). 4538 Backbone paths have been calculated to all area border routers 4539 (BR). These are used when determining the inter-area routes. 4540 Note that all of the inter-area routes are associated with the 4541 backbone; this is always the case when the calculating router is 4542 itself an area border router. Routing information is condensed 4543 at area boundaries. In this example, we assume that Area 3 has 4544 been defined so that networks N9-N11 and the host route to H1 4545 are all condensed to a single route when advertised into the 4546 backbone (by Router RT11). Note that the cost of this route is 4547 the minimum of the set of costs to its individual components. 4549 Type Dest Area Path Type Cost Next Adv. 4550 Hop(s) Router(s) 4551 ____________________________________________________________ 4552 N N1 0 intra-area 10 RT3 * 4553 N N2 0 intra-area 10 RT3 * 4554 N N3 0 intra-area 7 RT3 * 4555 N N4 0 intra-area 8 RT3 * 4556 N Ib 0 intra-area 7 * * 4557 N Ia 0 intra-area 12 RT10 * 4558 N N6 0 intra-area 8 RT10 * 4559 N N7 0 intra-area 12 RT10 * 4560 N N8 0 intra-area 10 RT10 * 4561 N N9 0 intra-area 11 RT10 * 4562 N N10 0 intra-area 13 RT10 * 4563 N N11 0 intra-area 14 RT10 * 4564 N H1 0 intra-area 21 RT10 * 4565 ASBR RT5 0 intra-area 6 RT5 * 4566 ASBR RT7 0 intra-area 8 RT10 * 4567 ____________________________________________________________ 4568 N N12 * type 1 ext. 10 RT10 RT7 4569 N N13 * type 1 ext. 14 RT5 RT5 4570 N N14 * type 1 ext. 14 RT5 RT5 4571 N N15 * type 1 ext. 17 RT10 RT7 4573 Table 12: The routing table for Router RT6 4574 (no configured areas). 4576 There is a virtual link configured between Routers RT10 and 4577 RT11. Without this configured virtual link, RT11 would be 4578 unable to advertise a route for networks N9-N11 and Host H1 into 4579 the backbone, and there would not be an entry for these networks 4580 in Router RT4's routing table. 4582 In this example there are two equal-cost paths to Network N12. 4583 However, they both use the same next hop (Router RT5). 4585 Router RT4's routing table would improve (i.e., some of the 4586 paths in the routing table would become shorter) if an 4587 additional virtual link were configured between Router RT4 and 4588 Router RT3. The new virtual link would itself be associated 4589 with the first entry for area border router RT3 in Table 13 (an 4590 intra-area path through Area 1). This would yield a cost of 1 4591 for the virtual link. The routing table entries changes that 4592 Type Dest Area Path Type Cost Next Adv. 4593 Hops(s) Router(s) 4594 __________________________________________________________________ 4595 N N1 1 intra-area 4 RT1 * 4596 N N2 1 intra-area 4 RT2 * 4597 N N3 1 intra-area 1 * * 4598 N N4 1 intra-area 3 RT3 * 4599 BR RT3 1 intra-area 1 * * 4600 __________________________________________________________________ 4601 N Ib 0 intra-area 22 RT5 * 4602 N Ia 0 intra-area 27 RT5 * 4603 BR RT3 0 intra-area 21 RT5 * 4604 BR RT7 0 intra-area 14 RT5 * 4605 BR RT10 0 intra-area 22 RT5 * 4606 BR RT11 0 intra-area 25 RT5 * 4607 ASBR RT5 0 intra-area 8 * * 4608 ASBR RT7 0 intra-area 14 RT5 * 4609 __________________________________________________________________ 4610 N N6 0 inter-area 15 RT5 RT7 4611 N N7 0 inter-area 19 RT5 RT7 4612 N N8 0 inter-area 18 RT5 RT7 4613 N N9-N11,H1 0 inter-area 26 RT5 RT11 4614 __________________________________________________________________ 4615 N N12 * type 1 ext. 16 RT5 RT5,RT7 4616 N N13 * type 1 ext. 16 RT5 RT5 4617 N N14 * type 1 ext. 16 RT5 RT5 4618 N N15 * type 1 ext. 23 RT5 RT7 4620 Table 13: Router RT4's routing table 4621 in the presence of areas. 4623 would be caused by the addition of this virtual link are shown 4624 in Table 14. 4626 12. Link State Advertisements 4628 Each router in the Autonomous System originates one or more link 4629 state advertisements. This memo defines five distinct types of link 4630 state advertisements, which are described in Section 4.3. The 4631 collection of link state advertisements forms the link-state 4632 database. Each separate type of advertisement has a separate 4633 function. Router links and network links advertisements describe 4634 how an area's routers and networks are interconnected. Summary link 4635 Type Dest Area Path Type Cost Next Adv. 4636 Hop(s) Router(s) 4637 ________________________________________________________________ 4638 N Ib 0 intra-area 16 RT3 * 4639 N Ia 0 intra-area 21 RT3 * 4640 BR RT3 0 intra-area 1 * * 4641 BR RT10 0 intra-area 16 RT3 * 4642 BR RT11 0 intra-area 19 RT3 * 4643 ________________________________________________________________ 4644 N N9-N11,H1 0 inter-area 20 RT3 RT11 4646 Table 14: Changes resulting from an 4647 additional virtual link. 4649 advertisements provide a way of condensing an area's routing 4650 information. AS external advertisements provide a way of 4651 transparently advertising externally-derived routing information 4652 throughout the Autonomous System. 4654 Each link state advertisement begins with a standard 20-byte header. 4655 This link state advertisement header is discussed below. 4657 12.1. The Link State Advertisement Header 4659 The link state advertisement header contains the LS type, Link 4660 State ID and Advertising Router fields. The combination of 4661 these three fields uniquely identifies the link state 4662 advertisement. 4664 There may be several instances of an advertisement present in 4665 the Autonomous System, all at the same time. It must then be 4666 determined which instance is more recent. This determination is 4667 made by examining the LS sequence, LS checksum and LS age 4668 fields. These fields are also contained in the 20-byte link 4669 state advertisement header. 4671 Several of the OSPF packet types list link state advertisements. 4672 When the instance is not important, an advertisement is referred 4673 to by its LS type, Link State ID and Advertising Router (see 4674 Link State Request Packets). Otherwise, the LS sequence number, 4675 LS age and LS checksum fields must also be referenced. 4677 A detailed explanation of the fields contained in the link state 4678 advertisement header follows. 4680 12.1.1. LS age 4682 This field is the age of the link state advertisement in 4683 seconds. It should be processed as an unsigned 16-bit 4684 integer. It is set to 0 when the link state advertisement 4685 is originated. It must be incremented by InfTransDelay on 4686 every hop of the flooding procedure. Link state 4687 advertisements are also aged as they are held in each 4688 router's database. 4690 The age of a link state advertisement is never incremented 4691 past MaxAge. Advertisements having age MaxAge are not used 4692 in the routing table calculation. When an advertisement's 4693 age first reaches MaxAge, it is reflooded. A link state 4694 advertisement of age MaxAge is finally flushed from the 4695 database when it is no longer needed to ensure database 4696 synchronization. For more information on the aging of link 4697 state advertisements, consult Section 14. 4699 The LS age field is examined when a router receives two 4700 instances of a link state advertisement, both having 4701 identical LS sequence numbers and LS checksums. An instance 4702 of age MaxAge is then always accepted as most recent; this 4703 allows old advertisements to be flushed quickly from the 4704 routing domain. Otherwise, if the ages differ by more than 4705 MaxAgeDiff, the instance having the smaller age is accepted 4706 as most recent.[12] See Section 13.1 for more details. 4708 12.1.2. Options 4710 The Options field in the link state advertisement header 4711 indicates which optional capabilities are associated with 4712 the advertisement. OSPF's optional capabilities are 4713 described in Section 4.5. There are currently two optional 4714 capabilities defined; they are represented by the T-bit and 4715 E-bit found in the Options field. The rest of the Options 4716 field should be set to zero. 4718 The E-bit represents OSPF's ExternalRoutingCapability. This 4719 bit should be set in all advertisements associated with the 4720 backbone, and all advertisements associated with non-stub 4721 areas (see Section 3.6). It should also be set in all AS 4722 external link advertisements. It should be reset in all 4723 router links, network links and summary link advertisements 4724 associated with a stub area. For all link state 4725 advertisements, the setting of the E-bit is for 4726 informational purposes only; it does not affect the routing 4727 table calculation. 4729 The T-bit represents OSPF's TOS routing capability. This 4730 bit should be set in a router links advertisement if and 4731 only if the router is capable of calculating separate routes 4732 for each IP TOS (see Section 2.5). The T-bit should always 4733 be set in network links advertisements. It should be set in 4734 summary link and AS external link advertisements if and only 4735 if the advertisement describes paths for all TOS values, 4736 instead of just the TOS 0 path. Note that, with the T-bit 4737 set, there may still be only a single metric in the 4738 advertisement (the TOS 0 metric). This would mean that 4739 paths for non-zero TOS exist, but are equivalent to the TOS 4740 0 path. A link state advertisement's T-bit is examined when 4741 calculating the routing table's non-zero TOS paths (see 4742 Section 16.9). 4744 12.1.3. LS type 4746 The LS type field dictates the format and function of the 4747 link state advertisement. Advertisements of different types 4748 have different names (e.g., router links or network links). 4749 All advertisement types defined by this memo, except the AS 4750 external link advertisements (LS type = 5), are flooded 4751 throughout a single area only. AS external link 4752 advertisements are flooded throughout the entire Autonomous 4753 System, excepting stub areas (see Section 3.6). Each 4754 separate advertisement type is briefly described below in 4755 Table 15. 4757 12.1.4. Link State ID 4759 This field identifies the piece of the routing domain that 4760 is being described by the advertisement. Depending on the 4761 advertisement's LS type, the Link State ID takes on the 4762 values listed in Table 16. 4764 Actually, for Type 3 summary link (LS type = 3) 4765 advertisements and AS external link (LS type = 5) 4766 advertisements, the Link State ID may additionally have one 4767 or more of the destination network's "host" bits set. For 4768 example, when originating an AS external link for the 4769 network 10.0.0.0 with mask of 255.0.0.0, the Link State ID 4770 can be set to anything in the range 10.0.0.0 through 4771 10.255.255.255 inclusive (although 10.0.0.0 should be used 4772 whenever possible). The freedom to set certain host bits 4773 LS Type Advertisement description 4774 __________________________________________________ 4775 1 These are the router links 4776 advertisements. They describe the 4777 collected states of the router's 4778 interfaces. For more information, 4779 consult Section 12.4.1. 4780 __________________________________________________ 4781 2 These are the network links 4782 advertisements. They describe the set 4783 of routers attached to the network. For 4784 more information, consult 4785 Section 12.4.2. 4786 __________________________________________________ 4787 3 or 4 These are the summary link 4788 advertisements. They describe 4789 inter-area routes, and enable the 4790 condensation of routing information at 4791 area borders. Originated by area border 4792 routers, the Type 3 advertisements 4793 describe routes to networks while the 4794 Type 4 advertisements describe routes to 4795 AS boundary routers. 4796 __________________________________________________ 4797 5 These are the AS external link 4798 advertisements. Originated by AS 4799 boundary routers, they describe routes 4800 to destinations external to the 4801 Autonomous System. A default route for 4802 the Autonomous System can also be 4803 described by an AS external link 4804 advertisement. 4806 Table 15: OSPF link state advertisements. 4808 LS Type Link State ID 4809 _______________________________________________ 4810 1 The originating router's Router ID. 4811 2 The IP interface address of the 4812 network's Designated Router. 4813 3 The destination network's IP address. 4814 4 The Router ID of the described AS 4815 boundary router. 4816 5 The destination network's IP address. 4818 Table 16: The advertisement's Link State ID. 4820 allows a router to originate separate advertisements for two 4821 networks having the same address but different masks. See 4822 Appendix E for details. 4824 When the link state advertisement is describing a network 4825 (LS type = 2, 3 or 5), the network's IP address is easily 4826 derived by masking the Link State ID with the network/subnet 4827 mask contained in the body of the link state advertisement. 4828 When the link state advertisement is describing a router (LS 4829 type = 1 or 4), the Link State ID is always the described 4830 router's OSPF Router ID. 4832 When an AS external advertisement (LS Type = 5) is 4833 describing a default route, its Link State ID is set to 4834 DefaultDestination (0.0.0.0). 4836 12.1.5. Advertising Router 4838 This field specifies the OSPF Router ID of the 4839 advertisement's originator. For router links 4840 advertisements, this field is identical to the Link State ID 4841 field. Network link advertisements are originated by the 4842 network's Designated Router. Summary link advertisements 4843 are originated by area border routers. AS external link 4844 advertisements are originated by AS boundary routers. 4846 12.1.6. LS sequence number 4848 The sequence number field is a signed 32-bit integer. It is 4849 used to detect old and duplicate link state advertisements. 4850 The space of sequence numbers is linearly ordered. The 4851 larger the sequence number (when compared as signed 32-bit 4852 integers) the more recent the advertisement. To describe to 4853 sequence number space more precisely, let N refer in the 4854 discussion below to the constant 2**31. 4856 The sequence number -N (0x80000000) is reserved (and 4857 unused). This leaves -N + 1 (0x80000001) as the smallest 4858 (and therefore oldest) sequence number; this sequence number 4859 is referred to as the constant InitialSequenceNumber. A 4860 router uses InitialSequenceNumber the first time it 4861 originates any link state advertisement. Afterwards, the 4862 advertisement's sequence number is incremented each time the 4863 router originates a new instance of the advertisement. When 4864 an attempt is made to increment the sequence number past the 4865 maximum value of N - 1 (0x7fffffff; also referred to as 4866 MaxSequenceNumber), the current instance of the 4867 advertisement must first be flushed from the routing domain. 4868 This is done by prematurely aging the advertisement (see 4869 Section 14.1) and reflooding it. As soon as this flood has 4870 been acknowledged by all adjacent neighbors, a new instance 4871 can be originated with sequence number of 4872 InitialSequenceNumber. 4874 The router may be forced to promote the sequence number of 4875 one of its advertisements when a more recent instance of the 4876 advertisement is unexpectedly received during the flooding 4877 process. This should be a rare event. This may indicate 4878 that an out-of-date advertisement, originated by the router 4879 itself before its last restart/reload, still exists in the 4880 Autonomous System. For more information see Section 13.4. 4882 12.1.7. LS checksum 4884 This field is the checksum of the complete contents of the 4885 advertisement, excepting the LS age field. The LS age field 4886 is excepted so that an advertisement's age can be 4887 incremented without updating the checksum. The checksum 4888 used is the same that is used for ISO connectionless 4889 datagrams; it is commonly referred to as the Fletcher 4890 checksum. It is documented in Annex B of [6]. The link 4891 state advertisement header also contains the length of the 4892 advertisement in bytes; subtracting the size of the LS age 4893 field (two bytes) yields the amount of data to checksum. 4895 The checksum is used to detect data corruption of an 4896 advertisement. This corruption can occur while an 4897 advertisement is being flooded, or while it is being held in 4898 a router's memory. The LS checksum field cannot take on the 4899 value of zero; the occurrence of such a value should be 4900 considered a checksum failure. In other words, calculation 4901 of the checksum is not optional. 4903 The checksum of a link state advertisement is verified in 4904 two cases: a) when it is received in a Link State Update 4905 Packet and b) at times during the aging of the link state 4906 database. The detection of a checksum failure leads to 4907 separate actions in each case. See Sections 13 and 14 for 4908 more details. 4910 Whenever the LS sequence number field indicates that two 4911 instances of an advertisement are the same, the LS checksum 4912 field is examined. If there is a difference, the instance 4913 with the larger LS checksum is considered to be most 4914 recent.[13] See Section 13.1 for more details. 4916 12.2. The link state database 4918 A router has a separate link state database for every area to 4919 which it belongs. All routers belonging to the same area have 4920 identical link state databases for the area. 4922 The databases for each individual area are always dealt with 4923 separately. The shortest path calculation is performed 4924 separately for each area (see Section 16). Components of the 4925 area link-state database are flooded throughout the area only. 4926 Finally, when an adjacency (belonging to Area A) is being 4927 brought up, only the database for Area A is synchronized between 4928 the two routers. 4930 The area database is composed of router links advertisements, 4931 network links advertisements, and summary link advertisements 4932 (all listed in the area data structure). In addition, external 4933 routes (AS external advertisements) are included in all non-stub 4934 area databases (see Section 3.6). 4936 An implementation of OSPF must be able to access individual 4937 pieces of an area database. This lookup function is based on an 4938 advertisement's LS type, Link State ID and Advertising 4939 Router.[14] There will be a single instance (the most up-to- 4940 date) of each link state advertisement in the database. The 4941 database lookup function is invoked during the link state 4942 flooding procedure (Section 13) and the routing table 4943 calculation (Section 16). In addition, using this lookup 4944 function the router can determine whether it has itself ever 4945 originated a particular link state advertisement, and if so, 4946 with what LS sequence number. 4948 A link state advertisement is added to a router's database when 4949 either a) it is received during the flooding process (Section 4950 13) or b) it is originated by the router itself (Section 12.4). 4951 A link state advertisement is deleted from a router's database 4952 when either a) it has been overwritten by a newer instance 4953 during the flooding process (Section 13) or b) the router 4954 originates a newer instance of one of its self-originated 4955 advertisements (Section 12.4) or c) the advertisement ages out 4956 and is flushed from the routing domain (Section 14). Whenever a 4957 link state advertisement is deleted from the database it must 4958 also be removed from all neighbors' Link state retransmission 4959 lists (see Section 10). 4961 12.3. Representation of TOS 4963 All OSPF link state advertisements (with the exception of 4964 network links advertisements) specify metrics. In router links 4965 advertisements, the metrics indicate the costs of the described 4966 interfaces. In summary link and AS external link 4967 advertisements, the metric indicates the cost of the described 4968 path. In all of these advertisements, a separate metric can be 4969 specified for each IP TOS. The encoding of TOS in OSPF link 4970 state advertisements is specified in Table 17. That table 4971 relates the OSPF encoding to the IP packet header's TOS field 4972 (defined in [12]). The OSPF encoding is expressed as a decimal 4973 integer, and the IP packet header's TOS field is expressed in 4974 the binary TOS values used in [12]. 4976 OSPF encoding RFC 1349 TOS values 4977 ___________________________________________ 4978 0 0000 normal service 4979 2 0001 minimize monetary cost 4980 4 0010 maximize reliability 4981 6 0011 4982 8 0100 maximize throughput 4983 10 0101 4984 12 0110 4985 14 0111 4986 16 1000 minimize delay 4987 18 1001 4988 20 1010 4989 22 1011 4990 24 1100 4991 26 1101 4992 28 1110 4993 30 1111 4995 Table 17: Representing TOS in OSPF. 4997 Each OSPF link state advertisement must specify the TOS 0 4998 metric. Other TOS metrics, if they appear, must appear in order 4999 of increasing TOS encoding. For example, the TOS 8 (maximize 5000 throughput) metric must always appear before the TOS 16 5001 (minimize delay) metric when both are specified. If a metric 5002 for some non-zero TOS is not specified, its cost defaults to the 5003 cost for TOS 0, unless the T-bit is reset in the advertisement's 5004 Options field (see Section 12.1.2 for more details). 5006 12.4. Originating link state advertisements 5008 Into any given OSPF area, a router will originate several link 5009 state advertisements. Each router originates a router links 5010 advertisement. If the router is also the Designated Router for 5011 any of the area's networks, it will originate network links 5012 advertisements for those networks. 5014 Area border routers originate a single summary link 5015 advertisement for each known inter-area destination. AS 5016 boundary routers originate a single AS external link 5017 advertisement for each known AS external destination. 5018 Destinations are advertised one at a time so that the change in 5019 any single route can be flooded without reflooding the entire 5020 collection of routes. During the flooding procedure, many link 5021 state advertisements can be carried by a single Link State 5022 Update packet. 5024 As an example, consider Router RT4 in Figure 6. It is an area 5025 border router, having a connection to Area 1 and the backbone. 5026 Router RT4 originates 5 distinct link state advertisements into 5027 the backbone (one router links, and one summary link for each of 5028 the networks N1-N4). Router RT4 will also originate 8 distinct 5029 link state advertisements into Area 1 (one router links and 5030 seven summary link advertisements as pictured in Figure 7). If 5031 RT4 has been selected as Designated Router for Network N3, it 5032 will also originate a network links advertisement for N3 into 5033 Area 1. 5035 In this same figure, Router RT5 will be originating 3 distinct 5036 AS external link advertisements (one for each of the networks 5037 N12-N14). These will be flooded throughout the entire AS, 5038 assuming that none of the areas have been configured as stubs. 5039 However, if area 3 has been configured as a stub area, the 5040 external advertisements for networks N12-N14 will not be flooded 5041 into area 3 (see Section 3.6). Instead, Router RT11 would 5042 originate a default summary link advertisement that would be 5043 flooded throughout area 3 (see Section 12.4.3). This instructs 5044 all of area 3's internal routers to send their AS external 5045 traffic to RT11. 5047 Whenever a new instance of a link state advertisement is 5048 originated, its LS sequence number is incremented, its LS age is 5049 set to 0, its LS checksum is calculated, and the advertisement 5050 is added to the link state database and flooded out the 5051 appropriate interfaces. See Section 13.2 for details concerning 5052 the installation of the advertisement into the link state 5053 database. See Section 13.3 for details concerning the flooding 5054 of newly originated advertisements. 5056 The ten events that can cause a new instance of a link state 5057 advertisement to be originated are: 5059 (1) The LS age field of one of the router's self-originated 5060 advertisements reaches the value LSRefreshTime. In this 5061 case, a new instance of the link state advertisement is 5062 originated, even though the contents of the advertisement 5063 (apart from the link state advertisement header) will be the 5064 same. This guarantees periodic originations of all link 5065 state advertisements. This periodic updating of link state 5066 advertisements adds robustness to the link state algorithm. 5067 Link state advertisements that solely describe unreachable 5068 destinations should not be refreshed, but should instead be 5069 flushed from the routing domain (see Section 14.1). 5071 When whatever is being described by a link state advertisement 5072 changes, a new advertisement is originated. However, two 5073 instances of the same link state advertisement may not be 5074 originated within the time period MinLSInterval. This may 5075 require that the generation of the next instance be delayed by 5076 up to MinLSInterval. The following events may cause the 5077 contents of a link state advertisement to change. These events 5078 should cause new originations if and only if the contents of the 5079 new advertisement would be different: 5081 (2) An interface's state changes (see Section 9.1). This may 5082 mean that it is necessary to produce a new instance of the 5083 router links advertisement. 5085 (3) An attached network's Designated Router changes. A new 5086 router links advertisement should be originated. Also, if 5087 the router itself is now the Designated Router, a new 5088 network links advertisement should be produced. If the 5089 router itself is no longer the Designated Router, any 5090 network links advertisement that it might have originated 5091 for the network should be flushed from the routing domain 5092 (see Section 14.1). 5094 (4) One of the neighboring routers changes to/from the FULL 5095 state. This may mean that it is necessary to produce a new 5096 instance of the router links advertisement. Also, if the 5097 router is itself the Designated Router for the attached 5098 network, a new network links advertisement should be 5099 produced. 5101 The next four events concern area border routers only: 5103 (5) An intra-area route has been added/deleted/modified in the 5104 routing table. This may cause a new instance of a summary 5105 links advertisement (for this route) to be originated in 5106 each attached area (possibly including the backbone). 5108 (6) An inter-area route has been added/deleted/modified in the 5109 routing table. This may cause a new instance of a summary 5110 links advertisement (for this route) to be originated in 5111 each attached area (but NEVER for the backbone). 5113 (7) The router becomes newly attached to an area. The router 5114 must then originate summary link advertisements into the 5115 newly attached area for all pertinent intra-area and inter- 5116 area routes in the router's routing table. See Section 5117 12.4.3 for more details. 5119 (8) When the state of one of the router's configured virtual 5120 links changes, it may be necessary to originate a new router 5121 links advertisement into the virtual link's transit area 5122 (see the discussion of the router links advertisement's bit 5123 V in Section 12.4.1), as well as originating a new router 5124 links advertisement into the backbone. 5126 The last two events concern AS boundary routers (and former AS 5127 boundary routers) only: 5129 (9) An external route gained through direct experience with an 5130 external routing protocol (like EGP) changes. This will 5131 cause an AS boundary router to originate a new instance of 5132 an AS external link advertisement. 5134 (10) 5135 A router ceases to be an AS boundary router, perhaps after 5136 restarting. In this situation the router should flush all AS 5137 external link advertisements that it had previously 5138 originated. These advertisements can be flushed via the 5139 premature aging procedure specified in Section 14.1. 5141 The construction of each type of link state advertisement is 5142 explained in detail below. In general, these sections describe 5143 the contents of the advertisement body (i.e., the part coming 5144 after the 20-byte advertisement header). For information 5145 concerning the building of the link state advertisement header, 5146 see Section 12.1. 5148 12.4.1. Router links 5150 A router originates a router links advertisement for each 5151 area that it belongs to. Such an advertisement describes 5152 the collected states of the router's links to the area. The 5153 advertisement is flooded throughout the particular area, and 5154 no further. 5156 .................................... 5157 . 192.1.2 Area 1 . 5158 . + . 5159 . | . 5160 . | 3+---+1 . 5161 . N1 |--|RT1|-----+ . 5162 . | +---+ . 5163 . | _______N3 . 5164 . + / . 1+---+ 5165 . * 192.1.1 *------|RT4| 5166 . + /_______/ . +---+ 5167 . | / | . 5168 . | 3+---+1 / | . 5169 . N2 |--|RT2|-----+ 1| . 5170 . | +---+ +---+8 . 6+---+ 5171 . | |RT3|----------------|RT6| 5172 . + +---+ . +---+ 5173 . 192.1.3 |2 . 18.10.0.6|7 5174 . | . | 5175 . +------------+ . 5176 . 192.1.4 (N4) . 5177 .................................... 5179 Figure 15: Area 1 with IP addresses shown 5181 The format of a router links advertisement is shown in 5182 Appendix A (Section A.4.2). The first 20 bytes of the 5183 advertisement consist of the generic link state 5184 advertisement header that was discussed in Section 12.1. 5185 Router links advertisements have LS type = 1. The router 5186 indicates whether it is willing to calculate separate routes 5187 for each IP TOS by setting (or resetting) the T-bit of the 5188 link state advertisement's Options field. 5190 A router also indicates whether it is an area border router, 5191 or an AS boundary router, by setting the appropriate bits 5192 (bit B and bit E, respectively) in its router links 5193 advertisements. This enables paths to those types of routers 5194 to be saved in the routing table, for later processing of 5195 summary link advertisements and AS external link 5196 advertisements. Bit B should be set whenever the router is 5197 actively attached to two or more areas, even if the router 5198 is not currently attached to the OSPF backbone area. Bit E 5199 should never be set in a router links advertisement for a 5200 stub area (stub areas cannot contain AS boundary routers). 5201 In addition, the router sets bit V in its router links 5202 advertisement for Area A if and only if it is the endpoint 5203 of an active virtual link using Area A as its Transit area. 5204 This enables the other routers attached to Area A to 5205 discover whether the area currently supports any virtual 5206 links (i.e., is a transit area). 5208 The router links advertisement then describes the router's 5209 working connections (i.e., interfaces or links) to the area. 5210 Each link is typed according to the kind of attached 5211 network. Each link is also labelled with its Link ID. This 5212 Link ID gives a name to the entity that is on the other end 5213 of the link. Table 18 summarizes the values used for the 5214 Type and Link ID fields. 5216 Link type Description Link ID 5217 __________________________________________________ 5218 1 Point-to-point Neighbor Router ID 5219 link 5220 2 Link to transit Interface address of 5221 network Designated Router 5222 3 Link to stub IP network number 5223 network 5224 4 Virtual link Neighbor Router ID 5226 Table 18: Link descriptions in the 5227 router links advertisement. 5229 In addition, the Link Data field is specified for each link. 5230 This field gives 32 bits of extra information for the link. 5231 For links to transit networks, numbered point-to-point links 5232 and virtual links, this field specifies the IP interface 5233 address of the associated router interface (this is needed 5234 by the routing table calculation, see Section 16.1.1). For 5235 links to stub networks, this field specifies the stub 5236 network's IP address mask. For unnumbered point-to-point 5237 links, the Link Data field should be set to the unnumbered 5238 interface's MIB-II [8] ifIndex value. 5240 Finally, the cost of using the link for output (possibly 5241 specifying a different cost for each Type of Service) is 5242 specified. The output cost of a link is configurable. With 5243 the exception of links to stub networks, the output cost 5244 must always be non-zero. 5246 To further describe the process of building the list of link 5247 descriptions, suppose a router wishes to build a router 5248 links advertisement for Area A. The router examines its 5249 collection of interface data structures. For each 5250 interface, the following steps are taken: 5252 o If the attached network does not belong to Area A, no 5253 links are added to the advertisement, and the next 5254 interface should be examined. 5256 o If the state of the interface is Down, no links are 5257 added. 5259 o If the state of the interface is Loopback, add a Type 3 5260 link (stub network) as long as this is not an interface 5261 to an unnumbered point-to-point network. The Link ID 5262 should be set to the IP interface address, the Link Data 5263 set to the mask 0xffffffff (indicating a host route), 5264 and the cost set to 0. 5266 o Otherwise, the link descriptions added to the router-LSA 5267 depend on the OSPF interface type. Link descriptions 5268 used for point-to-point interfaces are specified in 5269 Section 12.4.1.1, for virtual links in Section 12.4.1.2, 5270 for broadcast and NBMA interfaces in 12.4.1.3, and for 5271 Point-to-MultiPoint interfaces in 12.4.1.4. 5273 After consideration of all the router interfaces, host links 5274 are added to the router-LSA by examining the list of 5275 attached hosts belonging to Area A. A host route is 5276 represented as a Type 3 link (stub network) whose Link ID is 5277 the host's IP address, Link Data is the mask of all ones 5278 (0xffffffff), and cost the host's configured cost (see 5279 Section C.7). 5281 12.4.1.1. Describing point-to-point interfaces 5283 For point-to-point interfaces, one or more link 5284 descriptions are added to the router-LSA as follows: 5286 o If the neighboring router is fully adjacent, add a 5287 Type 1 link (point-to-point). The Link ID should be 5288 set to the Router ID of the neighboring router. For 5289 numbered point-to-point networks, the Link Data 5290 should specify the IP interface address. For 5291 unnumbered point-to-point networks, the Link Data 5292 field should specify the interface's MIB-II [8] 5293 ifIndex value. The cost should be set to the output 5294 cost of the point-to-point interface. 5296 o In addition, as long as the state of the interface 5297 is "Point-to-Point" (and regardless of the 5298 neighboring router state), a Type 3 link (stub 5299 network) should be added. There are two forms that 5300 this stub link can take: 5302 Option 1 5303 Assuming that the neighboring router's IP 5304 address is known, set the Link ID of the Type 3 5305 link to the neighbor's IP address, the Link Data 5306 to the mask 0xffffffff (indicating a host 5307 route), and the cost to the interface's 5308 configured output cost.[15] 5310 Option 2 5311 If a subnet has been assigned to the point-to- 5312 point link, set the Link ID of the Type 3 link 5313 to the subnet's IP address, the Link Data to the 5314 subnet's mask, and the cost to the interface's 5315 configured output cost.[16] 5317 12.4.1.2. Describing broadcast and NBMA interfaces 5319 For operational broadcast and NBMA interfaces, a single 5320 link description is added to the router-LSA as follows: 5322 o If the state of the interface is Waiting, add a Type 5323 3 link (stub network) with Link ID set to the IP 5324 network number of the attached network, Link Data 5325 set to the attached network's address mask, and cost 5326 equal to the interface's configured output cost. 5328 o Else, there has been a Designated Router elected for 5329 the attached network. If the router is fully 5330 adjacent to the Designated Router, or if the router 5331 itself is Designated Router and is fully adjacent to 5332 at least one other router, add a single Type 2 link 5333 (transit network) with Link ID set to the IP 5334 interface address of the attached network's 5335 Designated Router (which may be the router itself), 5336 Link Data set to the router's own IP interface 5337 address, and cost equal to the interface's 5338 configured output cost. Otherwise, add a link as if 5339 the interface state were Waiting (see above). 5341 12.4.1.3. Describing virtual links 5343 For virtual links, a link description is added to the 5344 router-LSA only when the neighboring router is fully 5345 adjacent. In this case, add a Type 4 link (virtual link) 5346 with Link ID set to the Router ID of the neighboring 5347 router, Link Data set to the IP interface address 5348 associated with the virtual link and cost set to the 5349 cost calculated for the virtual link during the routing 5350 table calculation (see Section 15). 5352 12.4.1.4. Describing Point-to-MultiPoint interfaces 5354 For operational Point-to-MultiPoint interfaces, one or 5355 more link descriptions are added to the router-LSA as 5356 follows: 5358 o A single Type 3 link (stub network) is added with 5359 Link ID set to the router's own IP interface 5360 address, Link Data set to the mask 0xffffffff 5361 (indicating a host route), and cost set to 0. 5363 o For each fully adjacent neighbor associated with the 5364 interface, add an additional Type 1 link (point-to- 5365 point) with Link ID set to the Router ID of the 5366 neighboring router, Link Data set to the IP 5367 interface address and cost equal to the interface's 5368 configured output cost. 5370 12.4.1.5. Examples of router-LSAs 5372 Consider the router links advertisements generated by 5373 Router RT3, as pictured in Figure 6. The area 5374 containing Router RT3 (Area 1) has been redrawn, with 5375 actual network addresses, in Figure 15. Assume that the 5376 last byte of all of RT3's interface addresses is 3, 5377 giving it the interface addresses 192.1.1.3 and 5378 192.1.4.3, and that the other routers have similar 5379 addressing schemes. In addition, assume that all links 5380 are functional, and that Router IDs are assigned as the 5381 smallest IP interface address. 5383 RT3 originates two router links advertisements, one for 5384 Area 1 and one for the backbone. Assume that Router RT4 5385 has been selected as the Designated router for network 5386 192.1.1.0. RT3's router links advertisement for Area 1 5387 is then shown below. It indicates that RT3 has two 5388 connections to Area 1, the first a link to the transit 5389 network 192.1.1.0 and the second a link to the stub 5390 network 192.1.4.0. Note that the transit network is 5391 identified by the IP interface of its Designated Router 5392 (i.e., the Link ID = 192.1.1.4 which is the Designated 5393 Router RT4's IP interface to 192.1.1.0). Note also that 5394 RT3 has indicated that it is capable of calculating 5395 separate routes based on IP TOS, through setting the T- 5396 bit in the Options field. It has also indicated that it 5397 is an area border router. 5399 ; RT3's router links advertisement for Area 1 5401 LS age = 0 ;always true on origination 5402 Options = (T-bit|E-bit) ;TOS-capable 5403 LS type = 1 ;indicates router links 5404 Link State ID = 192.1.1.3 ;RT3's Router ID 5405 Advertising Router = 192.1.1.3 ;RT3's Router ID 5406 bit E = 0 ;not an AS boundary router 5407 bit B = 1 ;area border router 5408 #links = 2 5409 Link ID = 192.1.1.4 ;IP address of Desig. Rtr. 5410 Link Data = 192.1.1.3 ;RT3's IP interface to net 5411 Type = 2 ;connects to transit network 5412 # other metrics = 0 5413 TOS 0 metric = 1 5415 Link ID = 192.1.4.0 ;IP Network number 5416 Link Data = 0xffffff00 ;Network mask 5417 Type = 3 ;connects to stub network 5418 # other metrics = 0 5419 TOS 0 metric = 2 5421 Next RT3's router links advertisement for the backbone 5422 is shown. It indicates that RT3 has a single attachment 5423 to the backbone. This attachment is via an unnumbered 5424 point-to-point link to Router RT6. RT3 has again 5425 indicated that it is TOS-capable, and that it is an area 5426 border router. 5428 ; RT3's router links advertisement for the backbone 5430 LS age = 0 ;always true on origination 5431 Options = (T-bit|E-bit) ;TOS-capable 5432 LS type = 1 ;indicates router links 5433 Link State ID = 192.1.1.3 ;RT3's router ID 5434 Advertising Router = 192.1.1.3 ;RT3's router ID 5435 bit E = 0 ;not an AS boundary router 5436 bit B = 1 ;area border router 5437 #links = 1 5438 Link ID = 18.10.0.6 ;Neighbor's Router ID 5439 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5440 Type = 1 ;connects to router 5441 # other metrics = 0 5442 TOS 0 metric = 8 5444 Even though Router RT3 has indicated that it is TOS- 5445 capable in the above examples, only a single metric (the 5446 TOS 0 metric) has been specified for each interface. 5447 Different metrics can be specified for each TOS. The 5448 encoding of TOS in OSPF link state advertisements is 5449 described in Section 12.3. 5451 As an example, suppose the point-to-point link between 5452 Routers RT3 and RT6 in Figure 15 is a satellite link. 5453 The AS administrator may want to encourage the use of 5454 the line for high bandwidth traffic. This would be done 5455 by setting the metric artificially low for the 5456 appropriate TOS value. Router RT3 would then originate 5457 the following router links advertisement for the 5458 backbone (TOS 8 = maximize throughput): 5460 ; RT3's router links advertisement for the backbone 5462 LS age = 0 ;always true on origination 5463 Options = (T-bit|E-bit) ;TOS-capable 5464 LS type = 1 ;indicates router links 5465 Link State ID = 192.1.1.3 ;RT3's Router ID 5466 Advertising Router = 192.1.1.3 5467 bit E = 0 ;not an AS boundary router 5468 bit B = 1 ;area border router 5469 #links = 1 5470 Link ID = 18.10.0.6 ;Neighbor's Router ID 5471 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5472 Type = 1 ;connects to router 5473 # other metrics = 1 5474 TOS 0 metric = 8 5475 TOS = 8 ;maximize throughput 5476 metric = 1 ;traffic preferred 5477 12.4.2. Network links 5479 A network links advertisement is generated for every transit 5480 broadcast or NBMA network. (A transit network is a network 5481 having two or more attached routers). The network links 5482 advertisement describes all the routers that are attached to 5483 the network. 5485 The Designated Router for the network originates the 5486 advertisement. The Designated Router originates the 5487 advertisement only if it is fully adjacent to at least one 5488 other router on the network. The network links 5489 advertisement is flooded throughout the area that contains 5490 the transit network, and no further. The networks links 5491 advertisement lists those routers that are fully adjacent to 5492 the Designated Router; each fully adjacent router is 5493 identified by its OSPF Router ID. The Designated Router 5494 includes itself in this list. 5496 The Link State ID for a network links advertisement is the 5497 IP interface address of the Designated Router. This value, 5498 masked by the network's address mask (which is also 5499 contained in the network links advertisement) yields the 5500 network's IP address. 5502 A router that has formerly been the Designated Router for a 5503 network, but is no longer, should flush the network links 5504 advertisement that it had previously originated. This 5505 advertisement is no longer used in the routing table 5506 calculation. It is flushed by prematurely incrementing the 5507 advertisement's age to MaxAge and reflooding (see Section 5508 14.1). In addition, in those rare cases where a router's 5509 Router ID has changed, any network links advertisements that 5510 were originated with the router's previous Router ID must be 5511 flushed. Since the router may have no idea what it's 5512 previous Router ID might have been, these network links 5513 advertisements are indicated by having their Link State ID 5514 equal to one of the router's IP interface addresses and 5515 their Advertising Router equal to some value other than the 5516 router's current Router ID (see Section 13.4 for more 5517 details). 5519 12.4.2.1. Examples of network-LSAs 5521 Again consider the area configuration in Figure 6. 5522 Network links advertisements are originated for Network 5523 N3 in Area 1, Networks N6 and N8 in Area 2, and Network 5524 N9 in Area 3. Assuming that Router RT4 has been 5525 selected as the Designated Router for Network N3, the 5526 following network links advertisement is generated by 5527 RT4 on behalf of Network N3 (see Figure 15 for the 5528 address assignments): 5530 ; network links advertisement for Network N3 5532 LS age = 0 ;always true on origination 5533 Options = (T-bit|E-bit) ;TOS-capable 5534 LS type = 2 ;indicates network links 5535 Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. 5536 Advertising Router = 192.1.1.4 ;RT4's Router ID 5537 Network Mask = 0xffffff00 5538 Attached Router = 192.1.1.4 ;Router ID 5539 Attached Router = 192.1.1.1 ;Router ID 5540 Attached Router = 192.1.1.2 ;Router ID 5541 Attached Router = 192.1.1.3 ;Router ID 5543 12.4.3. Summary links 5545 The destination described by a summary link advertisement is 5546 either an IP network, an AS boundary router or a range of IP 5547 addresses. Summary link advertisements are flooded 5548 throughout a single area only. The destination described is 5549 one that is external to the area, yet still belongs to the 5550 Autonomous System. 5552 Summary link advertisements are originated by area border 5553 routers. The precise summary routes to advertise into an 5554 area are determined by examining the routing table structure 5555 (see Section 11) in accordance with the algorithm described 5556 below. Note that only intra-area routes are advertised into 5557 the backbone, while both intra-area and inter-area routes 5558 are advertised into the other areas. 5560 To determine which routes to advertise into an attached Area 5561 A, each routing table entry is processed as follows. 5562 Remember that each routing table entry describes a set of 5563 equal-cost best paths to a particular destination: 5565 o Only Destination Types of network and AS boundary router 5566 are advertised in summary link advertisements. If the 5567 routing table entry's Destination Type is area border 5568 router, examine the next routing table entry. 5570 o AS external routes are never advertised in summary link 5571 advertisements. If the routing table entry has Path- 5572 type of type 1 external or type 2 external, examine the 5573 next routing table entry. 5575 o Else, if the area associated with this set of paths is 5576 the Area A itself, do not generate a summary link 5577 advertisement for the route.[17] 5579 o Else, if the next hops associated with this set of paths 5580 belong to Area A itself, do not generate a summary link 5581 advertisement for the route.[18] This is the logical 5582 equivalent of a Distance Vector protocol's split horizon 5583 logic. 5585 o Else, if the routing table cost equals or exceeds the 5586 value LSInfinity, a summary link advertisement cannot be 5587 generated for this route. 5589 o Else, if the destination of this route is an AS boundary 5590 router, generate a Type 4 link state advertisement for 5591 the destination, with Link State ID equal to the AS 5592 boundary router's Router ID and metric equal to the 5593 routing table entry's cost. These advertisements should 5594 not be generated if Area A has been configured as a stub 5595 area. 5597 o Else, the Destination type is network. If this is an 5598 inter-area route, generate a Type 3 advertisement for 5599 the destination, with Link State ID equal to the 5600 network's address (if necessary, the Link State ID can 5601 also have one or more of the network's host bits set; 5602 see Appendix E for details) and metric equal to the 5603 routing table cost. 5605 o The one remaining case is an intra-area route to a 5606 network. This means that the network is contained in 5607 one of the router's directly attached areas. In 5608 general, this information must be condensed before 5609 appearing in summary link advertisements. Remember that 5610 an area has a configured list of address ranges, each 5611 range consisting of an [address,mask] pair and a status 5612 indication of either Advertise or DoNotAdvertise. At 5613 most a single Type 3 advertisement is made for each 5614 range. When the range's status indicates Advertise, a 5615 Type 3 advertisement is generated with Link State ID 5616 equal to the range's address (if necessary, the Link 5617 State ID can also have one or more of the range's "host" 5618 bits set; see Appendix E for details) and cost equal to 5619 the smallest cost of any of the component networks. When 5620 the range's status indicates DoNotAdvertise, the Type 3 5621 advertisement is suppressed and the component networks 5622 remain hidden from other areas. 5624 By default, if a network is not contained in any 5625 explicitly configured address range, a Type 3 5626 advertisement is generated with Link State ID equal to 5627 the network's address (if necessary, the Link State ID 5628 can also have one or more of the network's "host" bits 5629 set; see Appendix E for details) and metric equal to the 5630 network's routing table cost. 5632 If virtual links are being used to provide/increase 5633 connectivity of the backbone, routing information 5634 concerning the backbone networks should not be condensed 5635 before being summarized into the virtual links' Transit 5636 areas. Nor should the advertisement of backbone networks 5637 into Transit areas be suppressed. In other words, the 5638 backbone's configured ranges should be ignored when 5639 originating summary links into Transit areas. The 5640 existence of virtual links is determined during the 5641 shortest path calculation for the Transit areas (see 5642 Section 16.1). 5644 If a router advertises a summary advertisement for a 5645 destination which then becomes unreachable, the router must 5646 then flush the advertisement from the routing domain by 5647 setting its age to MaxAge and reflooding (see Section 14.1). 5648 Also, if the destination is still reachable, yet can no 5649 longer be advertised according to the above procedure (e.g., 5650 it is now an inter-area route, when it used to be an intra- 5651 area route associated with some non-backbone area; it would 5652 thus no longer be advertisable to the backbone), the 5653 advertisement should also be flushed from the routing 5654 domain. 5656 For the destination described by a summary-LSA there may be 5657 separate sets of paths, and therefore separate routing table 5658 entries, for each Type of Service. All these entries must 5659 be considered when building the summary link advertisement 5660 for the destination; a single advertisement must specify the 5661 separate costs (if they exist) for each TOS. The encoding 5662 of TOS in OSPF link state advertisements is described in 5663 Section 12.3. 5665 Clearing the T-bit in the Options field of a summary link 5666 advertisement indicates that there is a TOS 0 path to the 5667 destination, but no paths for non-zero TOS. This can happen 5668 when non-TOS-capable routers exist in the routing domain 5669 (see Section 2.5). 5671 12.4.3.1. Originating summary links into stub areas 5673 The algorithm in Section 12.4.3 is optional when Area A 5674 is an OSPF stub area. Area border routers connecting to 5675 a stub area can originate summary link advertisements 5676 into the area according to the Section 12.4.3's 5677 algorithm, or can choose to originate only a subset of 5678 the advertisements, possibly under configuration 5679 control. The fewer advertisements originated, the 5680 smaller the stub area's link state database, further 5681 reducing the demands on its routers' resources. However, 5682 omitting advertisements may also lead to sub-optimal 5683 inter-area routing, although routing will continue to 5684 function. 5686 As specified in Section 12.4.3, Type 4 link state 5687 advertisements (ASBR summary links) are never originated 5688 into stub areas. 5690 In a stub area, instead of importing external routes 5691 each area border router originates a "default summary 5692 link" into the area. The Link State ID for the default 5693 summary link is set to DefaultDestination, and the 5694 metric set to the (per-area) configurable parameter 5695 StubDefaultCost. Note that StubDefaultCost need not be 5696 configured identically in all of the stub area's area 5697 border routers. 5699 12.4.3.2. Examples of summary-LSAs 5701 Consider again the area configuration in Figure 6. 5702 Routers RT3, RT4, RT7, RT10 and RT11 are all area border 5703 routers, and therefore are originating summary link 5704 advertisements. Consider in particular Router RT4. Its 5705 routing table was calculated as the example in Section 5706 11.3. RT4 originates summary link advertisements into 5707 both the backbone and Area 1. Into the backbone, Router 5708 RT4 originates separate advertisements for each of the 5709 networks N1-N4. Into Area 1, Router RT4 originates 5710 separate advertisements for networks N6-N8 and the AS 5711 boundary routers RT5,RT7. It also condenses host routes 5712 Ia and Ib into a single summary link advertisement. 5713 Finally, the routes to networks N9,N10,N11 and Host H1 5714 are advertised by a single summary link advertisement. 5715 This condensation was originally performed by the router 5716 RT11. 5718 These advertisements are illustrated graphically in 5719 Figures 7 and 8. Two of the summary link advertisements 5720 originated by Router RT4 follow. The actual IP 5721 addresses for the networks and routers in question have 5722 been assigned in Figure 15. 5724 ; summary link advertisement for Network N1, 5725 ; originated by Router RT4 into the backbone 5727 LS age = 0 ;always true on origination 5728 Options = (T-bit|E-bit) ;TOS-capable 5729 LS type = 3 ;summary link to IP net 5730 Link State ID = 192.1.2.0 ;N1's IP network number 5731 Advertising Router = 192.1.1.4 ;RT4's ID 5732 TOS = 0 5733 metric = 4 5735 ; summary link advertisement for AS boundary router RT7 5736 ; originated by Router RT4 into Area 1 5738 LS age = 0 ;always true on origination 5739 Options = (T-bit|E-bit) ;TOS-capable 5740 LS type = 4 ;summary link to ASBR 5741 Link State ID = Router RT7's ID 5742 Advertising Router = 192.1.1.4 ;RT4's ID 5743 TOS = 0 5744 metric = 14 5746 12.4.4. AS external links 5748 AS external link advertisements describe routes to 5749 destinations external to the Autonomous System. Most AS 5750 external link advertisements describe routes to specific 5751 external destinations; in these cases the advertisement's 5752 Link State ID is set to the destination network's IP address 5753 (if necessary, the Link State ID can also have one or more 5754 of the network's "host" bits set; see Appendix E for 5755 details). However, a default route for the Autonomous 5756 System can be described in an AS external link advertisement 5757 by setting the advertisement's Link State ID to 5758 DefaultDestination (0.0.0.0). AS external link 5759 advertisements are originated by AS boundary routers. An AS 5760 boundary router originates a single AS external link 5761 advertisement for each external route that it has learned, 5762 either through another routing protocol (such as EGP), or 5763 through configuration information. 5765 AS external link advertisements are the only type of link 5766 state advertisements that are flooded throughout the entire 5767 Autonomous System; all other types of link state 5768 advertisements are specific to a single area. However, AS 5769 external link advertisements are not flooded into/throughout 5770 stub areas (see Section 3.6). This enables a reduction in 5771 link state database size for routers internal to stub areas. 5773 The metric that is advertised for an external route can be 5774 one of two types. Type 1 metrics are comparable to the link 5775 state metric. Type 2 metrics are assumed to be larger than 5776 the cost of any intra-AS path. As with summary link 5777 advertisements, if separate paths exist based on TOS, 5778 separate TOS costs can be included in the AS external link 5779 advertisement. The encoding of TOS in OSPF link state 5780 advertisements is described in Section 12.3. If the T-bit 5781 of the advertisement's Options field is clear, no non-zero 5782 TOS paths to the destination exist. 5784 If a router advertises an AS external link advertisement for 5785 a destination which then becomes unreachable, the router 5786 must then flush the advertisement from the routing domain by 5787 setting its age to MaxAge and reflooding (see Section 14.1). 5789 12.4.4.1. Examples of AS-external-LSAs 5791 Consider once again the AS pictured in Figure 6. There 5792 are two AS boundary routers: RT5 and RT7. Router RT5 5793 originates three external link advertisements, for 5794 networks N12-N14. Router RT7 originates two external 5795 link advertisements, for networks N12 and N15. Assume 5796 that RT7 has learned its route to N12 via EGP, and that 5797 it wishes to advertise a Type 2 metric to the AS. RT7 5798 would then originate the following advertisement for 5799 N12: 5801 ; AS external link advertisement for Network N12, 5802 ; originated by Router RT7 5804 LS age = 0 ;always true on origination 5805 Options = (T-bit|E-bit) ;TOS-capable 5806 LS type = 5 ;indicates AS external link 5807 Link State ID = N12's IP network number 5808 Advertising Router = Router RT7's ID 5809 bit E = 1 ;Type 2 metric 5810 TOS = 0 5811 metric = 2 5812 Forwarding address = 0.0.0.0 5814 In the above example, the forwarding address field has 5815 been set to 0.0.0.0, indicating that packets for the 5816 external destination should be forwarded to the 5817 advertising OSPF router (RT7). This is not always 5818 desirable. Consider the example pictured in Figure 16. 5819 There are three OSPF routers (RTA, RTB and RTC) 5820 connected to a common network. Only one of these 5821 routers, RTA, is exchanging EGP information with the 5822 non-OSPF router RTX. RTA must then originate AS 5823 external link advertisements for those destinations it 5824 has learned from RTX. By using the AS external link 5825 advertisement's forwarding address field, RTA can 5826 specify that packets for these destinations be forwarded 5827 directly to RTX. Without this feature, Routers RTB and 5828 RTC would take an extra hop to get to these 5829 destinations. 5831 Note that when the forwarding address field is non-zero, 5832 it should point to a router belonging to another 5833 Autonomous System. 5835 A forwarding address can also be specified for the 5836 default route. For example, in figure 16 RTA may want 5837 to specify that all externally-destined packets should 5838 by default be forwarded to its EGP peer RTX. The 5839 resulting AS external link advertisement is pictured 5840 below. Note that the Link State ID is set to 5841 DefaultDestination. 5843 ; Default route, originated by Router RTA 5844 ; Packets forwarded through RTX 5846 LS age = 0 ;always true on origination 5847 Options = (T-bit|E-bit) ;TOS-capable 5848 LS type = 5 ;indicates AS external link 5849 Link State ID = DefaultDestination ; default route 5850 Advertising Router = Router RTA's ID 5851 bit E = 1 ;Type 2 metric 5852 TOS = 0 5853 metric = 1 5854 Forwarding address = RTX's IP address 5856 In figure 16, suppose instead that both RTA and RTB 5857 exchange EGP information with RTX. In this case, RTA 5858 and RTB would originate the same set of AS external link 5859 advertisements. These advertisements, if they specify 5860 the same metric, would be functionally equivalent since 5861 they would specify the same destination and forwarding 5862 address (RTX). This leads to a clear duplication of 5863 effort. If only one of RTA or RTB originated the set of 5864 external advertisements, the routing would remain the 5865 same, and the size of the link state database would 5866 decrease. However, it must be unambiguously defined as 5867 to which router originates the advertisements (otherwise 5868 neither may, or the identity of the originator may 5869 oscillate). The following rule is thereby established: 5870 if two routers, both reachable from one another, 5871 originate functionally equivalent AS external 5872 advertisements (i.e., same destination, cost and non- 5873 zero forwarding address), then the advertisement 5874 originated by the router having the highest OSPF Router 5875 ID is used. The router having the lower OSPF Router ID 5876 can then flush its advertisement. Flushing a link state 5877 advertisement is discussed in Section 14.1. 5879 + 5880 | 5881 +---+.....|.EGP 5882 |RTA|-----|.....+---+ 5883 +---+ |-----|RTX| 5884 | +---+ 5885 +---+ | 5886 |RTB|-----| 5887 +---+ | 5888 | 5889 +---+ | 5890 |RTC|-----| 5891 +---+ | 5892 | 5893 + 5895 Figure 16: Forwarding address example 5896 13. The Flooding Procedure 5898 Link State Update packets provide the mechanism for flooding link 5899 state advertisements. A Link State Update packet may contain 5900 several distinct advertisements, and floods each advertisement one 5901 hop further from its point of origination. To make the flooding 5902 procedure reliable, each advertisement must be acknowledged 5903 separately. Acknowledgments are transmitted in Link State 5904 Acknowledgment packets. Many separate acknowledgments can also be 5905 grouped together into a single packet. 5907 The flooding procedure starts when a Link State Update packet has 5908 been received. Many consistency checks have been made on the 5909 received packet before being handed to the flooding procedure (see 5910 Section 8.2). In particular, the Link State Update packet has been 5911 associated with a particular neighbor, and a particular area. If 5912 the neighbor is in a lesser state than Exchange, the packet should 5913 be dropped without further processing. 5915 All types of link state advertisements, other than AS external link 5916 advertisements, are associated with a specific area. However, link 5917 state advertisements do not contain an area field. A link state 5918 advertisement's area must be deduced from the Link State Update 5919 packet header. 5921 For each link state advertisement contained in a Link State Update 5922 packet, the following steps are taken: 5924 (1) Validate the advertisement's LS checksum. If the checksum turns 5925 out to be invalid, discard the advertisement and get the next 5926 one from the Link State Update packet. 5928 (2) Examine the link state advertisement's LS type. If the LS type 5929 is unknown, discard the advertisement and get the next one from 5930 the Link State Update Packet. This specification defines LS 5931 types 1-5 (see Section 4.3). 5933 (3) Else if this is an AS external link advertisement (LS type = 5), 5934 and the area has been configured as a stub area, discard the 5935 advertisement and get the next one from the Link State Update 5936 Packet. AS external link advertisements are not flooded 5937 into/throughout stub areas (see Section 3.6). 5939 (4) Else if the advertisement's LS age is equal to MaxAge, and there 5940 is currently no instance of the advertisement in the router's 5941 link state database, then take the following actions: 5943 (a) Acknowledge the receipt of the advertisement by sending a 5944 Link State Acknowledgment packet back to the sending 5945 neighbor (see Section 13.5). 5947 (b) Purge all outstanding requests for equal or previous 5948 instances of the advertisement from the sending neighbor's 5949 Link State Request list (see Section 10). 5951 (c) If the sending neighbor is in state Exchange or in state 5952 Loading, then install the MaxAge advertisement in the link 5953 state database. Otherwise, simply discard the 5954 advertisement. In either case, examine the next 5955 advertisement (if any) listed in the Link State Update 5956 packet. 5958 (5) Otherwise, find the instance of this advertisement that is 5959 currently contained in the router's link state database. If 5960 there is no database copy, or the received advertisement is more 5961 recent than the database copy (see Section 13.1 below for the 5962 determination of which advertisement is more recent) the 5963 following steps must be performed: 5965 (a) If there is already a database copy, and if the database 5966 copy was installed less than MinLSArrival seconds ago, 5967 discard the new advertisement (without acknowledging it) and 5968 examine the next advertisement (if any) listed in the Link 5969 State Update packet. 5971 (b) Otherwise immediately flood the new advertisement out some 5972 subset of the router's interfaces (see Section 13.3). In 5973 some cases (e.g., the state of the receiving interface is DR 5974 and the advertisement was received from a router other than 5975 the Backup DR) the advertisement will be flooded back out 5976 the receiving interface. This occurrence should be noted 5977 for later use by the acknowledgment process (Section 13.5). 5979 (c) Remove the current database copy from all neighbors' Link 5980 state retransmission lists. 5982 (d) Install the new advertisement in the link state database 5983 (replacing the current database copy). This may cause the 5984 routing table calculation to be scheduled. In addition, 5985 timestamp the new advertisement with the current time (i.e., 5986 the time it was received). The flooding procedure cannot 5987 overwrite the newly installed advertisement until 5988 MinLSArrival seconds have elapsed. The advertisement 5989 installation process is discussed further in Section 13.2. 5991 (e) Possibly acknowledge the receipt of the advertisement by 5992 sending a Link State Acknowledgment packet back out the 5993 receiving interface. This is explained below in Section 5994 13.5. 5996 (f) If this new link state advertisement indicates that it was 5997 originated by the receiving router itself (i.e., is 5998 considered a self-originated advertisement), the router must 5999 take special action, either updating the advertisement or in 6000 some cases flushing it from the routing domain. For a 6001 description of how self-originated advertisements are 6002 detected and subsequently handled, see Section 13.4. 6004 (6) Else, if there is an instance of the advertisement on the 6005 sending neighbor's Link state request list, an error has 6006 occurred in the Database Exchange process. In this case, 6007 restart the Database Exchange process by generating the neighbor 6008 event BadLSReq for the sending neighbor and stop processing the 6009 Link State Update packet. 6011 (7) Else, if the received advertisement is the same instance as the 6012 database copy (i.e., neither one is more recent) the following 6013 two steps should be performed: 6015 (a) If the advertisement is listed in the Link state 6016 retransmission list for the receiving adjacency, the router 6017 itself is expecting an acknowledgment for this 6018 advertisement. The router should treat the received 6019 advertisement as an acknowledgment by removing the 6020 advertisement from the Link state retransmission list. This 6021 is termed an "implied acknowledgment". Its occurrence 6022 should be noted for later use by the acknowledgment process 6023 (Section 13.5). 6025 (b) Possibly acknowledge the receipt of the advertisement by 6026 sending a Link State Acknowledgment packet back out the 6027 receiving interface. This is explained below in Section 6028 13.5. 6030 (8) Else, the database copy is more recent. If the database copy 6031 has LS age equal to MaxAge and LS sequence number equal to 6032 MaxSequenceNumber, simply discard the received LSA without 6033 acknowledging it. (In this case, the LSA's LS sequence number is 6034 wrapping, and the MaxSequenceNumber LSA must be completely 6035 flushed before any new LSA instance can be introduced). 6036 Otherwise, send the database copy back to the sending neighbor, 6037 encapsulated within a Link State Update Packet. The Link State 6038 Update Packet should be unicast to the neighbor. In so doing, do 6039 not put the database copy of the LSA on the neighbor's link 6040 state retransmission list, and do not acknowledge the received 6041 (less recent) LSA instance. 6043 13.1. Determining which link state is newer 6045 When a router encounters two instances of a link state 6046 advertisement, it must determine which is more recent. This 6047 occurred above when comparing a received advertisement to its 6048 database copy. This comparison must also be done during the 6049 Database Exchange procedure which occurs during adjacency 6050 bring-up. 6052 A link state advertisement is identified by its LS type, Link 6053 State ID and Advertising Router. For two instances of the same 6054 advertisement, the LS sequence number, LS age, and LS checksum 6055 fields are used to determine which instance is more recent: 6057 o The advertisement having the newer LS sequence number is 6058 more recent. See Section 12.1.6 for an explanation of the 6059 LS sequence number space. If both instances have the same 6060 LS sequence number, then: 6062 o If the two instances have different LS checksums, then the 6063 instance having the larger LS checksum (when considered as a 6064 16-bit unsigned integer) is considered more recent. 6066 o Else, if only one of the instances has its LS age field set 6067 to MaxAge, the instance of age MaxAge is considered to be 6068 more recent. 6070 o Else, if the LS age fields of the two instances differ by 6071 more than MaxAgeDiff, the instance having the smaller 6072 (younger) LS age is considered to be more recent. 6074 o Else, the two instances are considered to be identical. 6076 13.2. Installing link state advertisements in the database 6078 Installing a new link state advertisement in the database, 6079 either as the result of flooding or a newly self-originated 6080 advertisement, may cause the OSPF routing table structure to be 6081 recalculated. The contents of the new advertisement should be 6082 compared to the old instance, if present. If there is no 6083 difference, there is no need to recalculate the routing table. 6085 When comparing an LSA to its previous instance, the following 6086 are all considered to be differences in contents: 6088 o The LSA's Options field has changed. 6090 o One of the LSA instances has LS age set to MaxAge, and 6091 the other does not. 6093 o The length field in the LSA header has changed. 6095 o The body of the LSA (i.e., anything outside the 20-byte 6096 link state header) has changed. Note that this excludes 6097 changes in LS Sequence Number and LS Checksum. 6099 If the contents are different, the following pieces of the 6100 routing table must be recalculated, depending on the new 6101 advertisement's LS type field: 6103 Router links and network links advertisements 6104 The entire routing table must be recalculated, starting with 6105 the shortest path calculations for each area (not just the 6106 area whose link-state database has changed). The reason 6107 that the shortest path calculation cannot be restricted to 6108 the single changed area has to do with the fact that AS 6109 boundary routers may belong to multiple areas. A change in 6110 the area currently providing the best route may force the 6111 router to use an intra-area route provided by a different 6112 area.[19] 6114 Summary link advertisements 6115 The best route to the destination described by the summary 6116 link advertisement must be recalculated (see Section 16.5). 6117 If this destination is an AS boundary router, it may also be 6118 necessary to re-examine all the AS external link 6119 advertisements. 6121 AS external link advertisements 6122 The best route to the destination described by the AS 6123 external link advertisement must be recalculated (see 6124 Section 16.6). 6126 Also, any old instance of the advertisement must be removed from 6127 the database when the new advertisement is installed. This old 6128 instance must also be removed from all neighbors' Link state 6129 retransmission lists (see Section 10). 6131 13.3. Next step in the flooding procedure 6133 When a new (and more recent) advertisement has been received, it 6134 must be flooded out some set of the router's interfaces. This 6135 section describes the second part of flooding procedure (the 6136 first part being the processing that occurred in Section 13), 6137 namely, selecting the outgoing interfaces and adding the 6138 advertisement to the appropriate neighbors' Link state 6139 retransmission lists. Also included in this part of the 6140 flooding procedure is the maintenance of the neighbors' Link 6141 state request lists. 6143 This section is equally applicable to the flooding of an 6144 advertisement that the router itself has just originated (see 6145 Section 12.4). For these advertisements, this section provides 6146 the entirety of the flooding procedure (i.e., the processing of 6147 Section 13 is not performed, since, for example, the 6148 advertisement has not been received from a neighbor and 6149 therefore does not need to be acknowledged). 6151 Depending upon the advertisement's LS type, the advertisement 6152 can be flooded out only certain interfaces. These interfaces, 6153 defined by the following, are called the eligible interfaces: 6155 AS external link advertisements (LS Type = 5) 6156 AS external link advertisements are flooded throughout the 6157 entire AS, with the exception of stub areas (see Section 6158 3.6). The eligible interfaces are all the router's 6159 interfaces, excluding virtual links and those interfaces 6160 attaching to stub areas. 6162 All other LS types 6163 All other types are specific to a single area (Area A). The 6164 eligible interfaces are all those interfaces attaching to 6165 the Area A. If Area A is the backbone, this includes all 6166 the virtual links. 6168 Link state databases must remain synchronized over all 6169 adjacencies associated with the above eligible interfaces. This 6170 is accomplished by executing the following steps on each 6171 eligible interface. It should be noted that this procedure may 6172 decide not to flood a link state advertisement out a particular 6173 interface, if there is a high probability that the attached 6174 neighbors have already received the advertisement. However, in 6175 these cases the flooding procedure must be absolutely sure that 6176 the neighbors eventually do receive the advertisement, so the 6177 advertisement is still added to each adjacency's Link state 6178 retransmission list. For each eligible interface: 6180 (1) Each of the neighbors attached to this interface are 6181 examined, to determine whether they must receive the new 6182 advertisement. The following steps are executed for each 6183 neighbor: 6185 (a) If the neighbor is in a lesser state than Exchange, it 6186 does not participate in flooding, and the next neighbor 6187 should be examined. 6189 (b) Else, if the adjacency is not yet full (neighbor state 6190 is Exchange or Loading), examine the Link state request 6191 list associated with this adjacency. If there is an 6192 instance of the new advertisement on the list, it 6193 indicates that the neighboring router has an instance of 6194 the advertisement already. Compare the new 6195 advertisement to the neighbor's copy: 6197 o If the new advertisement is less recent, then 6198 examine the next neighbor. 6200 o If the two copies are the same instance, then delete 6201 the advertisement from the Link state request list, 6202 and examine the next neighbor.[20] 6204 o Else, the new advertisement is more recent. Delete 6205 the advertisement from the Link state request list. 6207 (c) If the new advertisement was received from this 6208 neighbor, examine the next neighbor. 6210 (d) At this point we are not positive that the neighbor has 6211 an up-to-date instance of this new advertisement. Add 6212 the new advertisement to the Link state retransmission 6213 list for the adjacency. This ensures that the flooding 6214 procedure is reliable; the advertisement will be 6215 retransmitted at intervals until an acknowledgment is 6216 seen from the neighbor. 6218 (2) The router must now decide whether to flood the new link 6219 state advertisement out this interface. If in the previous 6220 step, the link state advertisement was NOT added to any of 6221 the Link state retransmission lists, there is no need to 6222 flood the advertisement out the interface and the next 6223 interface should be examined. 6225 (3) If the new advertisement was received on this interface, and 6226 it was received from either the Designated Router or the 6227 Backup Designated Router, chances are that all the neighbors 6228 have received the advertisement already. Therefore, examine 6229 the next interface. 6231 (4) If the new advertisement was received on this interface, and 6232 the interface state is Backup (i.e., the router itself is 6233 the Backup Designated Router), examine the next interface. 6234 The Designated Router will do the flooding on this 6235 interface. However, if the Designated Router fails the 6236 router (i.e., the Backup Designated Router) will end up 6237 retransmitting the updates. 6239 (5) If this step is reached, the advertisement must be flooded 6240 out the interface. Send a Link State Update packet 6241 (including the new advertisement as contents) out the 6242 interface. The advertisement's LS age must be incremented 6243 by InfTransDelay (which must be > 0) when it is copied into 6244 the outgoing Link State Update packet (until the LS age 6245 field reaches the maximum value of MaxAge). 6247 On broadcast networks, the Link State Update packets are 6248 multicast. The destination IP address specified for the 6249 Link State Update Packet depends on the state of the 6250 interface. If the interface state is DR or Backup, the 6251 address AllSPFRouters should be used. Otherwise, the 6252 address AllDRouters should be used. 6254 On non-broadcast networks, separate Link State Update 6255 packets must be sent, as unicasts, to each adjacent neighbor 6256 (i.e., those in state Exchange or greater). The destination 6257 IP addresses for these packets are the neighbors' IP 6258 addresses. 6260 13.4. Receiving self-originated link state 6262 It is a common occurrence for a router to receive self- 6263 originated link state advertisements via the flooding procedure. 6264 A self-originated advertisement is detected when either 1) the 6265 advertisement's Advertising Router is equal to the router's own 6266 Router ID or 2) the advertisement is a network links 6267 advertisement and its Link State ID is equal to one of the 6268 router's own IP interface addresses. 6270 However, if the received self-originated advertisement is newer 6271 than the last instance that the router actually originated, the 6272 router must take special action. The reception of such an 6273 advertisement indicates that there are link state advertisements 6274 in the routing domain that were originated by the router before 6275 the last time it was restarted. In most cases, the router must 6276 then advance the advertisement's LS sequence number one past the 6277 received LS sequence number, and originate a new instance of the 6278 advertisement. 6280 It may be the case the router no longer wishes to originate the 6281 received advertisement. Possible examples include: 1) the 6282 advertisement is a summary link or AS external link and the 6283 router no longer has an (advertisable) route to the destination, 6284 2) the advertisement is a network links advertisement but the 6285 router is no longer Designated Router for the network or 3) the 6286 advertisement is a network links advertisement whose Link State 6287 ID is one of the router's own IP interface addresses but whose 6288 Advertising Router is not equal to the router's own Router ID 6289 (this latter case should be rare, and it indicates that the 6290 router's Router ID has changed since originating the 6291 advertisement). In all these cases, instead of updating the 6292 advertisement, the advertisement should be flushed from the 6293 routing domain by incrementing the received advertisement's LS 6294 age to MaxAge and reflooding (see Section 14.1). 6296 13.5. Sending Link State Acknowledgment packets 6298 Each newly received link state advertisement must be 6299 acknowledged. This is usually done by sending Link State 6300 Acknowledgment packets. However, acknowledgments can also be 6301 accomplished implicitly by sending Link State Update packets 6302 (see step 7a of Section 13). 6304 Many acknowledgments may be grouped together into a single Link 6305 State Acknowledgment packet. Such a packet is sent back out the 6306 interface which received the advertisements. The packet can be 6307 sent in one of two ways: delayed and sent on an interval timer, 6308 or sent directly (as a unicast) to a particular neighbor. The 6309 particular acknowledgment strategy used depends on the 6310 circumstances surrounding the receipt of the advertisement. 6312 Sending delayed acknowledgments accomplishes several things: 1) 6313 it facilitates the packaging of multiple acknowledgments in a 6314 single Link State Acknowledgment packet, 2) it enables a single 6315 Link State Acknowledgment packet to indicate acknowledgments to 6316 several neighbors at once (through multicasting) and 3) it 6317 randomizes the Link State Acknowledgment packets sent by the 6318 various routers attached to a common network. The fixed 6319 interval between a router's delayed transmissions must be short 6320 (less than RxmtInterval) or needless retransmissions will ensue. 6322 Direct acknowledgments are sent to a particular neighbor in 6323 response to the receipt of duplicate link state advertisements. 6324 These acknowledgments are sent as unicasts, and are sent 6325 immediately when the duplicate is received. 6327 The precise procedure for sending Link State Acknowledgment 6328 packets is described in Table 19. The circumstances surrounding 6329 the receipt of the advertisement are listed in the left column. 6330 The acknowledgment action then taken is listed in one of the two 6331 right columns. This action depends on the state of the 6332 concerned interface; interfaces in state Backup behave 6333 differently from interfaces in all other states. Delayed 6334 acknowledgments must be delivered to all adjacent routers 6335 associated with the interface. On broadcast networks, this is 6336 accomplished by sending the delayed Link State Acknowledgment 6337 packets as multicasts. The Destination IP address used depends 6338 on the state of the interface. If the interface state is DR or 6339 Backup, the destination AllSPFRouters is used. In all other 6340 states, the destination AllDRouters is used. On non-broadcast 6341 networks, delayed Link State Acknowledgment packets must be 6342 unicast separately over each adjacency (i.e., neighbor whose 6343 state is >= Exchange). 6345 The reasoning behind sending the above packets as multicasts is 6346 best explained by an example. Consider the network 6347 configuration depicted in Figure 15. Suppose RT4 has been 6348 elected as Designated Router, and RT3 as Backup Designated 6349 Router for the network N3. When Router RT4 floods a new 6350 advertisement to Network N3, it is received by routers RT1, RT2, 6351 and RT3. These routers will not flood the advertisement back 6352 onto net N3, but they still must ensure that their link-state 6353 databases remain synchronized with their adjacent neighbors. So 6354 RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3. 6355 Likewise, RT4 and RT3 are both waiting to see acknowledgments 6356 from RT1 and RT2. This is best achieved by sending the 6357 acknowledgments as multicasts. 6359 The reason that the acknowledgment logic for Backup DRs is 6360 slightly different is because they perform differently during 6361 the flooding of link state advertisements (see Section 13.3, 6362 step 4). 6364 Action taken in state 6365 Circumstances Backup All other states 6366 _______________________________________________________________ 6367 Advertisement has No acknowledgment No acknowledgment 6368 been flooded back sent. sent. 6369 out receiving in- 6370 terface (see Sec- 6371 tion 13, step 5b). 6372 _______________________________________________________________ 6373 Advertisement is Delayed acknowledg- Delayed ack- 6374 more recent than ment sent if adver- nowledgment sent. 6375 database copy, but tisement received 6376 was not flooded from Designated 6377 back out receiving Router, otherwise 6378 interface do nothing 6379 _______________________________________________________________ 6380 Advertisement is a Delayed acknowledg- No acknowledgment 6381 duplicate, and was ment sent if adver- sent. 6382 treated as an im- tisement received 6383 plied acknowledg- from Designated 6384 ment (see Section Router, otherwise 6385 13, step 7a). do nothing 6386 _______________________________________________________________ 6387 Advertisement is a Direct acknowledg- Direct acknowledg- 6388 duplicate, and was ment sent. ment sent. 6389 not treated as an 6390 implied ack- 6391 nowledgment. 6392 _______________________________________________________________ 6393 Advertisement's LS Direct acknowledg- Direct acknowledg- 6394 age is equal to ment sent. ment sent. 6395 MaxAge, and there is 6396 no current instance 6397 of the advertisement 6398 in the link state 6399 database (see 6400 Section 13, step 4). 6402 Table 19: Sending link state acknowledgements. 6404 13.6. Retransmitting link state advertisements 6406 Advertisements flooded out an adjacency are placed on the 6407 adjacency's Link state retransmission list. In order to ensure 6408 that flooding is reliable, these advertisements are 6409 retransmitted until they are acknowledged. The length of time 6410 between retransmissions is a configurable per-interface value, 6411 RxmtInterval. If this is set too low for an interface, needless 6412 retransmissions will ensue. If the value is set too high, the 6413 speed of the flooding, in the face of lost packets, may be 6414 affected. 6416 Several retransmitted advertisements may fit into a single Link 6417 State Update packet. When advertisements are to be 6418 retransmitted, only the number fitting in a single Link State 6419 Update packet should be sent. Another packet of retransmissions 6420 can be sent whenever some of the advertisements are 6421 acknowledged, or on the next firing of the retransmission timer. 6423 Link State Update Packets carrying retransmissions are always 6424 sent as unicasts (directly to the physical address of the 6425 neighbor). They are never sent as multicasts. Each 6426 advertisement's LS age must be incremented by InfTransDelay 6427 (which must be > 0) when it is copied into the outgoing Link 6428 State Update packet (until the LS age field reaches the maximum 6429 value of MaxAge). 6431 If an adjacent router goes down, retransmissions may occur until 6432 the adjacency is destroyed by OSPF's Hello Protocol. When the 6433 adjacency is destroyed, the Link state retransmission list is 6434 cleared. 6436 13.7. Receiving link state acknowledgments 6438 Many consistency checks have been made on a received Link State 6439 Acknowledgment packet before it is handed to the flooding 6440 procedure. In particular, it has been associated with a 6441 particular neighbor. If this neighbor is in a lesser state than 6442 Exchange, the Link State Acknowledgment packet is discarded. 6444 Otherwise, for each acknowledgment in the Link State 6445 Acknowledgment packet, the following steps are performed: 6447 o Does the advertisement acknowledged have an instance on the 6448 Link state retransmission list for the neighbor? If not, 6449 examine the next acknowledgment. Otherwise: 6451 o If the acknowledgment is for the same instance that is 6452 contained on the list, remove the item from the list and 6453 examine the next acknowledgment. Otherwise: 6455 o Log the questionable acknowledgment, and examine the next 6456 one. 6458 14. Aging The Link State Database 6460 Each link state advertisement has an LS age field. The LS age is 6461 expressed in seconds. An advertisement's LS age field is 6462 incremented while it is contained in a router's database. Also, 6463 when copied into a Link State Update Packet for flooding out a 6464 particular interface, the advertisement's LS age is incremented by 6465 InfTransDelay. 6467 An advertisement's LS age is never incremented past the value 6468 MaxAge. Advertisements having age MaxAge are not used in the 6469 routing table calculation. As a router ages its link state 6470 database, an advertisement's LS age may reach MaxAge.[21] At this 6471 time, the router must attempt to flush the advertisement from the 6472 routing domain. This is done simply by reflooding the MaxAge 6473 advertisement just as if it was a newly originated advertisement 6474 (see Section 13.3). 6476 When creating a Database summary list for a newly forming adjacency, 6477 any MaxAge advertisements present in the link state database are 6478 added to the neighbor's Link state retransmission list instead of 6479 the neighbor's Database summary list. See Section 10.3 for more 6480 details. 6482 A MaxAge advertisement must be removed immediately from the router's 6483 link state database as soon as both a) it is no longer contained on 6484 any neighbor Link state retransmission lists and b) none of the 6485 router's neighbors are in states Exchange or Loading. 6487 When, in the process of aging the link state database, an 6488 advertisement's LS age hits a multiple of CheckAge, its LS checksum 6489 should be verified. If the LS checksum is incorrect, a program or 6490 memory error has been detected, and at the very least the router 6491 itself should be restarted. 6493 14.1. Premature aging of advertisements 6495 A link state advertisement can be flushed from the routing 6496 domain by setting its LS age to MaxAge and reflooding the 6497 advertisement. This procedure follows the same course as 6498 flushing an advertisement whose LS age has naturally reached the 6499 value MaxAge (see Section 14). In particular, the MaxAge 6500 advertisement is removed from the router's link state database 6501 as soon as a) it is no longer contained on any neighbor Link 6502 state retransmission lists and b) none of the router's neighbors 6503 are in states Exchange or Loading. We call the setting of an 6504 advertisement's LS age to MaxAge premature aging. 6506 Premature aging is used when it is time for a self-originated 6507 advertisement's sequence number field to wrap. At this point, 6508 the current advertisement instance (having LS sequence number 6509 MaxSequenceNumber) must be prematurely aged and flushed from the 6510 routing domain before a new instance with sequence number equal 6511 to InitialSequenceNumber can be originated. See Section 12.1.6 6512 for more information. 6514 Premature aging can also be used when, for example, one of the 6515 router's previously advertised external routes is no longer 6516 reachable. In this circumstance, the router can flush its 6517 external advertisement from the routing domain via premature 6518 aging. This procedure is preferable to the alternative, which is 6519 to originate a new advertisement for the destination specifying 6520 a metric of LSInfinity. Premature aging is also be used when 6521 unexpectedly receiving self-originated advertisements during the 6522 flooding procedure (see Section 13.4). 6524 A router may only prematurely age its own self-originated link 6525 state advertisements. The router may not prematurely age 6526 advertisements that have been originated by other routers. An 6527 advertisement is considered self-originated when either 1) the 6528 advertisement's Advertising Router is equal to the router's own 6529 Router ID or 2) the advertisement is a network links 6530 advertisement and its Link State ID is equal to one of the 6531 router's own IP interface addresses. 6533 15. Virtual Links 6535 The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, 6536 or some areas of the Autonomous System will become unreachable. To 6537 establish/maintain connectivity of the backbone, virtual links can 6538 be configured through non-backbone areas. Virtual links serve to 6539 connect physically separate components of the backbone. The two 6540 endpoints of a virtual link are area border routers. The virtual 6541 link must be configured in both routers. The configuration 6542 information in each router consists of the other virtual endpoint 6543 (the other area border router), and the non-backbone area the two 6544 routers have in common (called the transit area). Virtual links 6545 cannot be configured through stub areas (see Section 3.6). 6547 The virtual link is treated as if it were an unnumbered point-to- 6548 point network (belonging to the backbone) joining the two area 6549 border routers. An attempt is made to establish an adjacency over 6550 the virtual link. When this adjacency is established, the virtual 6551 link will be included in backbone router links advertisements, and 6552 OSPF packets pertaining to the backbone area will flow over the 6553 adjacency. Such an adjacency has been referred to in this document 6554 as a "virtual adjacency". 6556 In each endpoint router, the cost and viability of the virtual link 6557 is discovered by examining the routing table entry for the other 6558 endpoint router. (The entry's associated area must be the 6559 configured transit area). Actually, there may be a separate routing 6560 table entry for each Type of Service. These are called the virtual 6561 link's corresponding routing table entries. The InterfaceUp event 6562 occurs for a virtual link when its corresponding TOS 0 routing table 6563 entry becomes reachable. Conversely, the InterfaceDown event occurs 6564 when its TOS 0 routing table entry becomes unreachable.[22] In other 6565 words, the virtual link's viability is determined by the existence 6566 of an intra-area path, through the transit area, between the two 6567 endpoints. Note that a virtual link whose underlying path has cost 6568 greater than hexadecimal 0xffff (the maximum size of an interface 6569 cost in a router links advertisement) should be considered 6570 inoperational (i.e., treated the same as if the path did not exist). 6572 The other details concerning virtual links are as follows: 6574 o AS external links are NEVER flooded over virtual adjacencies. 6575 This would be duplication of effort, since the same AS external 6576 links are already flooded throughout the virtual link's transit 6577 area. For this same reason, AS external link advertisements are 6578 not summarized over virtual adjacencies during the Database 6579 Exchange process. 6581 o The cost of a virtual link is NOT configured. It is defined to 6582 be the cost of the intra-area path between the two defining area 6583 border routers. This cost appears in the virtual link's 6584 corresponding routing table entry. When the cost of a virtual 6585 link changes, a new router links advertisement should be 6586 originated for the backbone area. 6588 o Just as the virtual link's cost and viability are determined by 6589 the routing table build process (through construction of the 6590 routing table entry for the other endpoint), so are the IP 6591 interface address for the virtual interface and the virtual 6592 neighbor's IP address. These are used when sending OSPF 6593 protocol packets over the virtual link. Note that when one (or 6594 both) of the virtual link endpoints connect to the transit area 6595 via an unnumbered point-to-point link, it may be impossible to 6596 calculate either the virtual interface's IP address and/or the 6597 virtual neighbor's IP address, thereby causing the virtual link 6598 to fail. 6600 o In each endpoint's router links advertisement for the backbone, 6601 the virtual link is represented as a Type 4 link whose Link ID 6602 is set to the virtual neighbor's OSPF Router ID and whose Link 6603 Data is set to the virtual interface's IP address. See Section 6604 12.4.1 for more information. Note that it may be the case that 6605 there is a TOS 0 path, but no non-zero TOS paths, between the 6606 two endpoint routers. In this case, both routers must revert to 6607 being non-TOS-capable, clearing the T-bit in the Options field 6608 of their backbone router links advertisements. 6610 o When virtual links are in use, information concerning backbone 6611 networks should not be condensed before being summarized into 6612 the virtual links' transit areas. In other words, each backbone 6613 network should be advertised into the transit areas in a 6614 separate summary link advertisement, regardless of the 6615 backbone's configured area address ranges. See Section 12.4.3 6616 for more information. 6618 o The time between link state retransmissions, RxmtInterval, is 6619 configured for a virtual link. This should be well over the 6620 expected round-trip delay between the two routers. This may be 6621 hard to estimate for a virtual link; it is better to err on the 6622 side of making it too large. 6624 16. Calculation of the routing table 6626 This section details the OSPF routing table calculation. Using its 6627 attached areas' link state databases as input, a router runs the 6628 following algorithm, building its routing table step by step. At 6629 each step, the router must access individual pieces of the link 6630 state databases (e.g., a router links advertisement originated by a 6631 certain router). This access is performed by the lookup function 6632 discussed in Section 12.2. The lookup process may return a link 6633 state advertisement whose LS age is equal to MaxAge. Such an 6634 advertisement should not be used in the routing table calculation, 6635 and is treated just as if the lookup process had failed. 6637 The OSPF routing table's organization is explained in Section 11. 6638 Two examples of the routing table build process are presented in 6639 Sections 11.2 and 11.3. This process can be broken into the 6640 following steps: 6642 (1) The present routing table is invalidated. The routing table is 6643 built again from scratch. The old routing table is saved so 6644 that changes in routing table entries can be identified. 6646 (2) The intra-area routes are calculated by building the shortest- 6647 path tree for each attached area. In particular, all routing 6648 table entries whose Destination Type is "area border router" are 6649 calculated in this step. This step is described in two parts. 6650 At first the tree is constructed by only considering those links 6651 between routers and transit networks. Then the stub networks 6652 are incorporated into the tree. During the area's shortest-path 6653 tree calculation, the area's TransitCapability is also 6654 calculated for later use in Step 4. 6656 (3) The inter-area routes are calculated, through examination of 6657 summary link advertisements. If the router is attached to 6658 multiple areas (i.e., it is an area border router), only 6659 backbone summary link advertisements are examined. 6661 (4) In area border routers connecting to one or more transit areas 6662 (i.e, non-backbone areas whose TransitCapability is found to be 6663 TRUE), the transit areas' summary link advertisements are 6664 examined to see whether better paths exist using the transit 6665 areas than were found in Steps 2-3 above. 6667 (5) Routes to external destinations are calculated, through 6668 examination of AS external link advertisements. The locations 6669 of the AS boundary routers (which originate the AS external link 6670 advertisements) have been determined in steps 2-4. 6672 Steps 2-5 are explained in further detail below. The explanations 6673 describe the calculations for TOS 0 only. It may also be necessary 6674 to perform each step (separately) for each of the non-zero TOS 6675 values.[23] For more information concerning the building of non-zero 6676 TOS routes see Section 16.9. 6678 Changes made to routing table entries as a result of these 6679 calculations can cause the OSPF protocol to take further actions. 6680 For example, a change to an intra-area route will cause an area 6681 border router to originate new summary link advertisements (see 6682 Section 12.4). See Section 16.7 for a complete list of the OSPF 6683 protocol actions resulting from routing table changes. 6685 16.1. Calculating the shortest-path tree for an area 6687 This calculation yields the set of intra-area routes associated 6688 with an area (called hereafter Area A). A router calculates the 6689 shortest-path tree using itself as the root.[24] The formation 6690 of the shortest path tree is done here in two stages. In the 6691 first stage, only links between routers and transit networks are 6692 considered. Using the Dijkstra algorithm, a tree is formed from 6693 this subset of the link state database. In the second stage, 6694 leaves are added to the tree by considering the links to stub 6695 networks. 6697 The procedure will be explained using the graph terminology that 6698 was introduced in Section 2. The area's link state database is 6699 represented as a directed graph. The graph's vertices are 6700 routers, transit networks and stub networks. The first stage of 6701 the procedure concerns only the transit vertices (routers and 6702 transit networks) and their connecting links. Throughout the 6703 shortest path calculation, the following data is also associated 6704 with each transit vertex: 6706 Vertex (node) ID 6707 A 32-bit number uniquely identifying the vertex. For router 6708 vertices this is the router's OSPF Router ID. For network 6709 vertices, this is the IP address of the network's Designated 6710 Router. 6712 A link state advertisement 6713 Each transit vertex has an associated link state 6714 advertisement. For router vertices, this is a router links 6715 advertisement. For transit networks, this is a network 6716 links advertisement (which is actually originated by the 6717 network's Designated Router). In any case, the 6718 advertisement's Link State ID is always equal to the above 6719 Vertex ID. 6721 List of next hops 6722 The list of next hops for the current set of shortest paths 6723 from the root to this vertex. There can be multiple 6724 shortest paths due to the equal-cost multipath capability. 6725 Each next hop indicates the outgoing router interface to use 6726 when forwarding traffic to the destination. On broadcast, 6727 Point-to-MultiPoint and NBMA networks, the next hop also 6728 includes the IP address of the next router (if any) in the 6729 path towards the destination. 6731 Distance from root 6732 The link state cost of the current set of shortest paths 6733 from the root to the vertex. The link state cost of a path 6734 is calculated as the sum of the costs of the path's 6735 constituent links (as advertised in router links and network 6736 links advertisements). One path is said to be "shorter" 6737 than another if it has a smaller link state cost. 6739 The first stage of the procedure (i.e., the Dijkstra algorithm) 6740 can now be summarized as follows. At each iteration of the 6741 algorithm, there is a list of candidate vertices. Paths from 6742 the root to these vertices have been found, but not necessarily 6743 the shortest ones. However, the paths to the candidate vertex 6744 that is closest to the root are guaranteed to be shortest; this 6745 vertex is added to the shortest-path tree, removed from the 6746 candidate list, and its adjacent vertices are examined for 6747 possible addition to/modification of the candidate list. The 6748 algorithm then iterates again. It terminates when the candidate 6749 list becomes empty. 6751 The following steps describe the algorithm in detail. Remember 6752 that we are computing the shortest path tree for Area A. All 6753 references to link state database lookup below are from Area A's 6754 database. 6756 (1) Initialize the algorithm's data structures. Clear the list 6757 of candidate vertices. Initialize the shortest-path tree to 6758 only the root (which is the router doing the calculation). 6759 Set Area A's TransitCapability to FALSE. 6761 (2) Call the vertex just added to the tree vertex V. Examine 6762 the link state advertisement associated with vertex V. This 6763 is a lookup in the Area A's link state database based on the 6764 Vertex ID. If this is a router links advertisement, and bit 6765 V of the router links advertisement (see Section A.4.2) is 6766 set, set Area A's TransitCapability to TRUE. In any case, 6767 each link described by the advertisement gives the cost to 6768 an adjacent vertex. For each described link, (say it joins 6769 vertex V to vertex W): 6771 (a) If this is a link to a stub network, examine the next 6772 link in V's advertisement. Links to stub networks will 6773 be considered in the second stage of the shortest path 6774 calculation. 6776 (b) Otherwise, W is a transit vertex (router or transit 6777 network). Look up the vertex W's link state 6778 advertisement (router links or network links) in Area 6779 A's link state database. If the advertisement does not 6780 exist, or its LS age is equal to MaxAge, or it does not 6781 have a link back to vertex V, examine the next link in 6782 V's advertisement.[25] 6784 (c) If vertex W is already on the shortest-path tree, 6785 examine the next link in the advertisement. 6787 (d) Calculate the link state cost D of the resulting path 6788 from the root to vertex W. D is equal to the sum of the 6789 link state cost of the (already calculated) shortest 6790 path to vertex V and the advertised cost of the link 6791 between vertices V and W. If D is: 6793 o Greater than the value that already appears for 6794 vertex W on the candidate list, then examine the 6795 next link. 6797 o Equal to the value that appears for vertex W on the 6798 candidate list, calculate the set of next hops that 6799 result from using the advertised link. Input to 6800 this calculation is the destination (W), and its 6801 parent (V). This calculation is shown in Section 6802 16.1.1. This set of hops should be added to the 6803 next hop values that appear for W on the candidate 6804 list. 6806 o Less than the value that appears for vertex W on the 6807 candidate list, or if W does not yet appear on the 6808 candidate list, then set the entry for W on the 6809 candidate list to indicate a distance of D from the 6810 root. Also calculate the list of next hops that 6811 result from using the advertised link, setting the 6812 next hop values for W accordingly. The next hop 6813 calculation is described in Section 16.1.1; it takes 6814 as input the destination (W) and its parent (V). 6816 (3) If at this step the candidate list is empty, the shortest- 6817 path tree (of transit vertices) has been completely built 6818 and this stage of the procedure terminates. Otherwise, 6819 choose the vertex belonging to the candidate list that is 6820 closest to the root, and add it to the shortest-path tree 6821 (removing it from the candidate list in the process). Note 6822 that when there is a choice of vertices closest to the root, 6823 network vertices must be chosen before router vertices in 6824 order to necessarily find all equal-cost paths. This is 6825 consistent with the tie-breakers that were introduced in the 6826 modified Dijkstra algorithm used by OSPF's Multicast routing 6827 extensions (MOSPF). 6829 (4) Possibly modify the routing table. For those routing table 6830 entries modified, the associated area will be set to Area A, 6831 the path type will be set to intra-area, and the cost will 6832 be set to the newly discovered shortest path's calculated 6833 distance. 6835 If the newly added vertex is an area border router (call it 6836 ABR), a routing table entry is added whose destination type 6837 is "area border router". The Options field found in the 6838 associated router links advertisement is copied into the 6839 routing table entry's Optional capabilities field. If in 6840 addition ABR is the endpoint of one of the calculating 6841 router's configured virtual links that uses Area A as its 6842 Transit area: the virtual link is declared up, the IP 6843 address of the virtual interface is set to the IP address of 6844 the outgoing interface calculated above for ABR, and the 6845 virtual neighbor's IP address is set to the ABR interface 6846 address (contained in ABR's router links advertisement) that 6847 points back to the root of the shortest-path tree; 6848 equivalently, this is the interface that points back to 6849 ABR's parent vertex on the shortest-path tree (similar to 6850 the calculation in Section 16.1.1). 6852 If the newly added vertex is an AS boundary router, the 6853 routing table entry of type "AS boundary router" for the 6854 destination is located. Since routers can belong to more 6855 than one area, it is possible that several sets of intra- 6856 area paths exist to the AS boundary router, each set using a 6857 different area. However, the AS boundary router's routing 6858 table entry must indicate a set of paths which utilize a 6859 single area. The area leading to the routing table entry is 6860 selected as follows: The area providing the shortest path 6861 is always chosen; if more than one area provides paths with 6862 the same minimum cost, the area with the largest OSPF Area 6863 ID (when considered as an unsigned 32-bit integer) is 6864 chosen. Note that whenever an AS boundary router's routing 6865 table entry is added/modified, the Options found in the 6866 associated router links advertisement is copied into the 6867 routing table entry's Optional capabilities field. 6869 If the newly added vertex is a transit network, the routing 6870 table entry for the network is located. The entry's 6871 Destination ID is the IP network number, which can be 6872 obtained by masking the Vertex ID (Link State ID) with its 6873 associated subnet mask (found in the body of the associated 6874 network links advertisement). If the routing table entry 6875 already exists (i.e., there is already an intra-area route 6876 to the destination installed in the routing table), multiple 6877 vertices have mapped to the same IP network. For example, 6878 this can occur when a new Designated Router is being 6879 established. In this case, the current routing table entry 6880 should be overwritten if and only if the newly found path is 6881 just as short and the current routing table entry's Link 6882 State Origin has a smaller Link State ID than the newly 6883 added vertex' link state advertisement. 6885 If there is no routing table entry for the network (the 6886 usual case), a routing table entry for the IP network should 6887 be added. The routing table entry's Link State Origin 6888 should be set to the newly added vertex' link state 6889 advertisement. 6891 (5) Iterate the algorithm by returning to Step 2. 6893 The stub networks are added to the tree in the procedure's 6894 second stage. In this stage, all router vertices are again 6895 examined. Those that have been determined to be unreachable in 6896 the above first phase are discarded. For each reachable router 6897 vertex (call it V), the associated router links advertisement is 6898 found in the link state database. Each stub network link 6899 appearing in the advertisement is then examined, and the 6900 following steps are executed: 6902 (1) Calculate the distance D of stub network from the root. D 6903 is equal to the distance from the root to the router vertex 6904 (calculated in stage 1), plus the stub network link's 6905 advertised cost. Compare this distance to the current best 6906 cost to the stub network. This is done by looking up the 6907 stub network's current routing table entry. If the 6908 calculated distance D is larger, go on to examine the next 6909 stub network link in the advertisement. 6911 (2) If this step is reached, the stub network's routing table 6912 entry must be updated. Calculate the set of next hops that 6913 would result from using the stub network link. This 6914 calculation is shown in Section 16.1.1; input to this 6915 calculation is the destination (the stub network) and the 6916 parent vertex (the router vertex). If the distance D is the 6917 same as the current routing table cost, simply add this set 6918 of next hops to the routing table entry's list of next hops. 6919 In this case, the routing table already has a Link State 6920 Origin. If this Link State Origin is a router links 6921 advertisement whose Link State ID is smaller than V's Router 6922 ID, reset the Link State Origin to V's router links 6923 advertisement. 6925 Otherwise D is smaller than the routing table cost. 6926 Overwrite the current routing table entry by setting the 6927 routing table entry's cost to D, and by setting the entry's 6928 list of next hops to the newly calculated set. Set the 6929 routing table entry's Link State Origin to V's router links 6930 advertisement. Then go on to examine the next stub network 6931 link. 6933 For all routing table entries added/modified in the second 6934 stage, the associated area will be set to Area A and the path 6935 type will be set to intra-area. When the list of reachable 6936 router links is exhausted, the second stage is completed. At 6937 this time, all intra-area routes associated with Area A have 6938 been determined. 6940 The specification does not require that the above two stage 6941 method be used to calculate the shortest path tree. However, if 6942 another algorithm is used, an identical tree must be produced. 6943 For this reason, it is important to note that links between 6944 transit vertices must be bidirectional in order to be included 6945 in the above tree. It should also be mentioned that more 6946 efficient algorithms exist for calculating the tree; for 6947 example, the incremental SPF algorithm described in [1]. 6949 16.1.1. The next hop calculation 6951 This section explains how to calculate the current set of 6952 next hops to use for a destination. Each next hop consists 6953 of the outgoing interface to use in forwarding packets to 6954 the destination together with the next hop router (if any). 6955 The next hop calculation is invoked each time a shorter path 6956 to the destination is discovered. This can happen in either 6957 stage of the shortest-path tree calculation (see Section 6958 16.1). In stage 1 of the shortest-path tree calculation a 6959 shorter path is found as the destination is added to the 6960 candidate list, or when the destination's entry on the 6961 candidate list is modified (Step 2d of Stage 1). In stage 2 6962 a shorter path is discovered each time the destination's 6963 routing table entry is modified (Step 2 of Stage 2). 6965 The set of next hops to use for the destination may be 6966 recalculated several times during the shortest-path tree 6967 calculation, as shorter and shorter paths are discovered. 6968 In the end, the destination's routing table entry will 6969 always reflect the next hops resulting from the absolute 6970 shortest path(s). 6972 Input to the next hop calculation is a) the destination and 6973 b) its parent in the current shortest path between the root 6974 (the calculating router) and the destination. The parent is 6975 always a transit vertex (i.e., always a router or a transit 6976 network). 6978 If there is at least one intervening router in the current 6979 shortest path between the destination and the root, the 6980 destination simply inherits the set of next hops from the 6981 parent. Otherwise, there are two cases. In the first case, 6982 the parent vertex is the root (the calculating router 6983 itself). This means that the destination is either a 6984 directly connected network or directly connected router. 6985 The next hop in this case is simply the OSPF interface 6986 connecting to the network/router; no next hop router is 6987 required. If the connecting OSPF interface in this case is a 6988 virtual link, the setting of the next hop should be deferred 6989 until the calculation in Section 16.3. 6991 In the second case, the parent vertex is a network that 6992 directly connects the calculating router to the destination 6993 router. The list of next hops is then determined by 6994 examining the destination's router links advertisement. For 6995 each link in the advertisement that points back to the 6996 parent network, the link's Link Data field provides the IP 6997 address of a next hop router. The outgoing interface to use 6998 can then be derived from the next hop IP address (or it can 6999 be inherited from the parent network). 7001 16.2. Calculating the inter-area routes 7003 The inter-area routes are calculated by examining summary link 7004 advertisements. If the router has active attachments to 7005 multiple areas, only backbone summary link advertisements are 7006 examined. Routers attached to a single area examine that area's 7007 summary links. In either case, the summary links examined below 7008 are all part of a single area's link state database (call it 7009 Area A). 7011 Summary link advertisements are originated by the area border 7012 routers. Each summary link advertisement in Area A is 7013 considered in turn. Remember that the destination described by 7014 a summary link advertisement is either a network (Type 3 summary 7015 link advertisements) or an AS boundary router (Type 4 summary 7016 link advertisements). For each summary link advertisement: 7018 (1) If the cost specified by the advertisement is LSInfinity, or 7019 if the advertisement's LS age is equal to MaxAge, then 7020 examine the the next advertisement. 7022 (2) If the advertisement was originated by the calculating 7023 router itself, examine the next advertisement. 7025 (3) If it is a Type 3 summary-LSA, and the collection of 7026 destinations described by the summary-LSA equals one of the 7027 router's configured area address ranges (see Section 3.5), 7028 and the particular area address range is active, then the 7029 summary link advertisement should be ignored. Active means 7030 that there are one or more reachable (by intra-area paths) 7031 networks contained in the area range. 7033 (4) Else, call the destination described by the advertisement N 7034 (for Type 3 summary links, N's address is obtained by 7035 masking the advertisement's Link State ID with the 7036 network/subnet mask contained in the body of the 7037 advertisement), and the area border originating the 7038 advertisement BR. Look up the routing table entry for BR 7039 having Area A as its associated area. If no such entry 7040 exists for router BR (i.e., BR is unreachable in Area A), do 7041 nothing with this advertisement and consider the next in the 7042 list. Else, this advertisement describes an inter-area path 7043 to destination N, whose cost is the distance to BR plus the 7044 cost specified in the advertisement. Call the cost of this 7045 inter-area path IAC. 7047 (5) Next, look up the routing table entry for the destination N. 7048 (The entry's Destination Type is either Network or AS 7049 boundary router.) If no entry exists for N or if the 7050 entry's path type is "type 1 external" or "type 2 external", 7051 then install the inter-area path to N, with associated area 7052 Area A, cost IAC, next hop equal to the list of next hops to 7053 router BR, and Advertising router equal to BR. 7055 (6) Else, if the paths present in the table are intra-area 7056 paths, do nothing with the advertisement (intra-area paths 7057 are always preferred). 7059 (7) Else, the paths present in the routing table are also 7060 inter-area paths. Install the new path through BR if it is 7061 cheaper, overriding the paths in the routing table. 7062 Otherwise, if the new path is the same cost, add it to the 7063 list of paths that appear in the routing table entry. 7065 16.3. Examining transit areas' summary links 7067 This step is only performed by area border routers attached to 7068 one or more transit areas. Transit areas are those areas 7069 supporting one or more virtual links; their TransitCapability 7070 parameter has been set to TRUE in Step 2 of the Dijkstra 7071 algorithm (see Section 16.1). They are the only non-backbone 7072 areas that can carry data traffic that neither originates nor 7073 terminates in the area itself. 7075 The purpose of the calculation below is to examine the transit 7076 areas to see whether they provide any better (shorter) paths 7077 than the paths previously calculated in Sections 16.1 and 16.2. 7078 Any paths found that are better than or equal to previously 7079 discovered paths are installed in the routing table. 7081 The calculation proceeds as follows. All the transit areas' 7082 summary link advertisements are examined in turn. Each such 7083 summary link advertisement describes a route through a transit 7084 area Area A to a Network N (N's address is obtained by masking 7085 the advertisement's Link State ID with the network/subnet mask 7086 contained in the body of the advertisement) or in the case of a 7087 Type 4 summary link advertisement, to an AS boundary router N. 7088 Suppose also that the summary link advertisement was originated 7089 by an area border router BR. 7091 (1) If the cost advertised by the summary link advertisement is 7092 LSInfinity, or if the advertisement's LS age is equal to 7093 MaxAge, then examine the next advertisement. 7095 (2) If the summary link advertisement was originated by the 7096 calculating router itself, examine the next advertisement. 7098 (3) Look up the routing table entry for N. If it does not exist, 7099 or if the route type is other than intra-area or inter-area, 7100 or if the area associated with the routing table entry is 7101 not the backbone area, then examine the next advertisement. 7102 In other words, this calculation only updates backbone 7103 intra-area routes found in Section 16.1 and inter-area 7104 routes found in Section 16.2. 7106 (4) Look up the routing table entry for the advertising router 7107 BR associated with the Area A. If it is unreachable, examine 7108 the next advertisement. Otherwise, the cost to destination N 7109 is the sum of the cost in BR's Area A routing table entry 7110 and the cost advertised in the advertisement. Call this cost 7111 IAC. 7113 (5) If this cost is less than the cost occurring in N's routing 7114 table entry, overwrite N's list of next hops with those used 7115 for BR, and set N's routing table cost to IAC. Else, if IAC 7116 is the same as N's current cost, add BR's list of next hops 7117 to N's list of next hops. In any case, the area associated 7118 with N's routing table entry must remain the backbone area, 7119 and the path type (either intra-area or inter-area) must 7120 also remain the same. 7122 It is important to note that the above calculation never makes 7123 unreachable destinations reachable, but instead just potentially 7124 finds better paths to already reachable destinations. The 7125 calculation installs any better cost found into the routing 7126 table entry, from which it may be readvertised in summary link 7127 advertisements to other areas. 7129 As an example of the calculation, consider the Autonomous System 7131 ........................ 7132 . Area 1 (transit) . + 7133 . . | 7134 . +---+1 1+---+100 | 7135 . |RT2|----------|RT4|=========| 7136 . 1/+---+********* +---+ | 7137 . /******* . | 7138 . 1/*Virtual . | 7139 1+---+/* Link . Net|work 7140 =======|RT1|* . | N1 7141 +---+\ . | 7142 . \ . | 7143 . \ . | 7144 . 1\+---+1 1+---+20 | 7145 . |RT3|----------|RT5|=========| 7146 . +---+ +---+ | 7147 . . | 7148 ........................ + 7150 Figure 17: Routing through transit areas 7151 pictured in Figure 17. There is a single non-backbone area 7152 (Area 1) that physically divides the backbone into two separate 7153 pieces. To maintain connectivity of the backbone, a virtual link 7154 has been configured between routers RT1 and RT4. On the right 7155 side of the figure, Network N1 belongs to the backbone. The 7156 dotted lines indicate that there is a much shorter intra-area 7157 backbone path between router RT5 and Network N1 (cost 20) than 7158 there is between Router RT4 and Network N1 (cost 100). Both 7159 Router RT4 and Router RT5 will inject summary link 7160 advertisements for Network N1 into Area 1. 7162 After the shortest-path tree has been calculated for the 7163 backbone in Section 16.1, Router RT1 (left end of the virtual 7164 link) will have calculated a path through Router RT4 for all 7165 data traffic destined for Network N1. However, since Router RT5 7166 is so much closer to Network N1, all routers internal to Area 1 7167 (e.g., Routers RT2 and RT3) will forward their Network N1 7168 traffic towards Router RT5, instead of RT4. And indeed, after 7169 examining Area 1's summary link advertisements by the above 7170 calculation, Router RT1 will also forward Network N1 traffic 7171 towards RT5. Note that in this example the virtual link enables 7172 Network N1 traffic to be forwarded through the transit area Area 7173 1, but the actual path the data traffic takes does not follow 7174 the virtual link. In other words, virtual links allow transit 7175 traffic to be forwarded through an area, but do not dictate the 7176 precise path that the traffic will take. 7178 16.4. Calculating AS external routes 7180 AS external routes are calculated by examining AS external link 7181 advertisements. Each of the AS external link advertisements is 7182 considered in turn. Most AS external link advertisements 7183 describe routes to specific IP destinations. An AS external 7184 link advertisement can also describe a default route for the 7185 Autonomous System (Destination ID = DefaultDestination, 7186 network/subnet mask = 0x00000000). For each AS external link 7187 advertisement: 7189 (1) If the cost specified by the advertisement is LSInfinity, or 7190 if the advertisement's LS age is equal to MaxAge, then 7191 examine the next advertisement. 7193 (2) If the advertisement was originated by the calculating 7194 router itself, examine the next advertisement. 7196 (3) Call the destination described by the advertisement N. N's 7197 address is obtained by masking the advertisement's Link 7198 State ID with the network/subnet mask contained in the body 7199 of the advertisement. Look up the routing table entry for 7200 the AS boundary router (ASBR) that originated the 7201 advertisement. If no entry exists for router ASBR (i.e., 7202 ASBR is unreachable), do nothing with this advertisement and 7203 consider the next in the list. 7205 Else, this advertisement describes an AS external path to 7206 destination N. Examine the forwarding address specified in 7207 the AS external link advertisement. This indicates the IP 7208 address to which packets for the destination should be 7209 forwarded. If the forwarding address is set to 0.0.0.0, 7210 packets should be sent to the ASBR itself. Otherwise, look 7211 up the forwarding address in the routing table.[26] An 7212 intra-area or inter-area path must exist to the forwarding 7213 address. If no such path exists, do nothing with the 7214 advertisement and consider the next in the list. 7216 Call the routing table distance to the forwarding address X 7217 (when the forwarding address is set to 0.0.0.0, this is the 7218 distance to the ASBR itself), and the cost specified in the 7219 advertisement Y. X is in terms of the link state metric, 7220 and Y is a type 1 or 2 external metric. 7222 (4) Next, look up the routing table entry for the destination N. 7223 If no entry exists for N, install the AS external path to N, 7224 with next hop equal to the list of next hops to the 7225 forwarding address, and advertising router equal to ASBR. 7226 If the external metric type is 1, then the path-type is set 7227 to type 1 external and the cost is equal to X+Y. If the 7228 external metric type is 2, the path-type is set to type 2 7229 external, the link state component of the route's cost is X, 7230 and the type 2 cost is Y. 7232 (5) Else, if the paths present in the table are not type 1 or 7233 type 2 external paths, do nothing (AS external paths have 7234 the lowest priority). 7236 (6) Otherwise, compare the cost of this new AS external path to 7237 the ones present in the table. Type 1 external paths are 7238 always shorter than type 2 external paths. Type 1 external 7239 paths are compared by looking at the sum of the distance to 7240 the forwarding address and the advertised type 1 metric 7241 (X+Y). Type 2 external paths are compared by looking at the 7242 advertised type 2 metrics, and then if necessary, the 7243 distance to the forwarding addresses. 7245 If the new path is shorter, it replaces the present paths in 7246 the routing table entry. If the new path is the same cost, 7247 it is added to the routing table entry's list of paths. 7249 16.5. Incremental updates -- summary link advertisements 7251 When a new summary link advertisement is received, it is not 7252 necessary to recalculate the entire routing table. Call the 7253 destination described by the summary link advertisement N (N's 7254 address is obtained by masking the advertisement's Link State ID 7255 with the network/subnet mask contained in the body of the 7256 advertisement), and let Area A be the area to which the 7257 advertisement belongs. There are then two separate cases: 7259 Case 1: Area A is the backbone and/or the router is not an area 7260 border router. 7261 In this case, the following calculations must be performed. 7262 First, if there is presently an inter-area route to the 7263 destination N, N's routing table entry is invalidated, 7264 saving the entry's values for later comparisons. Then the 7265 calculation in Section 16.2 is run again for the single 7266 destination N. In this calculation, all of Area A's summary 7267 link advertisements that describe a route to N are examined. 7268 In addition, if the router is an area border router attached 7269 to one or more transit areas, the calculation in Section 7270 16.3 must be run again for the single destination. If the 7271 results of these calculations have changed the cost/path to 7272 an AS boundary router (as would be the case for a Type 4 7273 summary link advertisement) or to any forwarding addresses, 7274 all AS external link advertisements will have to be 7275 reexamined by rerunning the calculation in Section 16.4. 7276 Otherwise, if N is now newly unreachable, the calculation in 7277 Section 16.4 must be rerun for the single destination N, in 7278 case an alternate external route to N exists. 7280 Case 2: Area A is a transit area and the router is an area 7281 border router. 7282 In this case, the following calculations must be performed. 7283 First, if N's routing table entry presently contains one or 7284 more inter-area paths that utilize the transit area Area A, 7285 these paths should be removed. If this removes all paths 7286 from the routing table entry, the entry should be 7287 invalidated. The entry's old values should be saved for 7288 later comparisons. Next the calculation in Section 16.3 must 7289 be run again for the single destination N. If the results of 7290 this calculation have caused the cost to N to increase, the 7291 complete routing table calculation must be rerun starting 7292 with the Dijkstra algorithm specified in Section 16.1. 7293 Otherwise, if the cost/path to an AS boundary router (as 7294 would be the case for a Type 4 summary link advertisement) 7295 or to any forwarding addresses has changed, all AS external 7296 link advertisements will have to be reexamined by rerunning 7297 the calculation in Section 16.4. Otherwise, if N is now 7298 newly unreachable, the calculation in Section 16.4 must be 7299 rerun for the single destination N, in case an alternate 7300 external route to N exists. 7302 16.6. Incremental updates -- AS external link advertisements 7304 When a new AS external link advertisement is received, it is not 7305 necessary to recalculate the entire routing table. Call the 7306 destination described by the AS external link advertisement N. 7307 N's address is obtained by masking the advertisement's Link 7308 State ID with the network/subnet mask contained in the body of 7309 the advertisement. If there is already an intra-area or inter- 7310 area route to the destination, no recalculation is necessary 7311 (internal routes take precedence). 7313 Otherwise, the procedure in Section 16.4 will have to be 7314 performed, but only for those AS external link advertisements 7315 whose destination is N. Before this procedure is performed, the 7316 present routing table entry for N should be invalidated. 7318 16.7. Events generated as a result of routing table changes 7320 Changes to routing table entries sometimes cause the OSPF area 7321 border routers to take additional actions. These routers need 7322 to act on the following routing table changes: 7324 o The cost or path type of a routing table entry has changed. 7325 If the destination described by this entry is a Network or 7326 AS boundary router, and this is not simply a change of AS 7327 external routes, new summary link advertisements may have to 7328 be generated (potentially one for each attached area, 7329 including the backbone). See Section 12.4.3 for more 7330 information. If a previously advertised entry has been 7331 deleted, or is no longer advertisable to a particular area, 7332 the advertisement must be flushed from the routing domain by 7333 setting its LS age to MaxAge and reflooding (see Section 7334 14.1). 7336 o A routing table entry associated with a configured virtual 7337 link has changed. The destination of such a routing table 7338 entry is an area border router. The change indicates a 7339 modification to the virtual link's cost or viability. 7341 If the entry indicates that the area border router is newly 7342 reachable (via TOS 0), the corresponding virtual link is now 7343 operational. An InterfaceUp event should be generated for 7344 the virtual link, which will cause a virtual adjacency to 7345 begin to form (see Section 10.3). At this time the virtual 7346 link's IP interface address and the virtual neighbor's 7347 Neighbor IP address are also calculated. 7349 If the entry indicates that the area border router is no 7350 longer reachable (via TOS 0), the virtual link and its 7351 associated adjacency should be destroyed. This means an 7352 InterfaceDown event should be generated for the associated 7353 virtual link. 7355 If the cost of the entry has changed, and there is a fully 7356 established virtual adjacency, a new router links 7357 advertisement for the backbone must be originated. This in 7358 turn may cause further routing table changes. 7360 16.8. Equal-cost multipath 7362 The OSPF protocol maintains multiple equal-cost routes to all 7363 destinations. This can be seen in the steps used above to 7364 calculate the routing table, and in the definition of the 7365 routing table structure. 7367 Each one of the multiple routes will be of the same type 7368 (intra-area, inter-area, type 1 external or type 2 external), 7369 cost, and will have the same associated area. However, each 7370 route specifies a separate next hop and Advertising router. 7372 There is no requirement that a router running OSPF keep track of 7373 all possible equal-cost routes to a destination. An 7374 implementation may choose to keep only a fixed number of routes 7375 to any given destination. This does not affect any of the 7376 algorithms presented in this specification. 7378 16.9. Building the non-zero-TOS portion of the routing table 7380 The OSPF protocol can calculate a different set of routes for 7381 each IP TOS (see Section 2.5). Support for TOS-based routing is 7382 optional. TOS-capable and non-TOS-capable routers can be mixed 7383 in an OSPF routing domain. Routers not supporting TOS calculate 7384 only the TOS 0 route to each destination. These routes are then 7385 used to forward all data traffic, regardless of the TOS 7386 indications in the data packet's IP header. A router that does 7387 not support TOS indicates this fact to the other OSPF routers by 7388 clearing the T-bit in the Options field of its router links 7389 advertisement. 7391 The above sections detailing the routing table calculations 7392 handle the TOS 0 case only. In general, for routers supporting 7393 TOS-based routing, each piece of the routing table calculation 7394 must be rerun separately for the non-zero TOS values. When 7395 calculating routes for TOS X, only TOS X metrics can be used. 7396 Any link state advertisement may specify a separate cost for 7397 each TOS (a cost for TOS 0 must always be specified). The 7398 encoding of TOS in OSPF link state advertisements is described 7399 in Section 12.3. 7401 An advertisement can specify that it is restricted to TOS 0 7402 (i.e., non-zero TOS is not handled) by clearing the T-bit in the 7403 link state advertisement's Option field. Such advertisements 7404 are not used when calculating routes for non-zero TOS. For this 7405 reason, it is possible that a destination is unreachable for 7406 some non-zero TOS. In this case, the TOS 0 path is used when 7407 forwarding packets (see Section 11.1). 7409 The following lists the modifications needed when running the 7410 routing table calculation for a non-zero TOS value (called TOS 7411 X). In general, routers and advertisements that do not support 7412 TOS are omitted from the calculation. 7414 Calculating the shortest-path tree (Section 16.1). 7415 Routers that do not support TOS-based routing should be 7416 omitted from the shortest-path tree calculation. These 7417 routers are identified as those having the T-bit reset in 7418 the Options field of their router links advertisements. 7419 Such routers should never be added to the Dijktra 7420 algorithm's candidate list, nor should their router links 7421 advertisements be examined when adding the stub networks to 7422 the tree. In particular, if the T-bit is reset in the 7423 calculating router's own router links advertisement, it does 7424 not run the shortest-path tree calculation for non-zero TOS 7425 values. 7427 Calculating the inter-area routes (Section 16.2). 7428 Inter-area paths are the concatenation of a path to an area 7429 border router with a summary link. When calculating TOS X 7430 routes, both path components must also specify TOS X. In 7431 other words, only TOS X paths to the area border router are 7432 examined, and the area border router must be advertising a 7433 TOS X route to the destination. Note that this means that 7434 summary link advertisements having the T-bit reset in their 7435 Options field are not considered. 7437 Examining transit areas' summary links (Section 16.3). 7438 This calculation again considers the concatenation of a path 7439 to an area border router with a summary link. As with 7440 inter-area routes, only TOS X paths to the area border 7441 router are examined, and the area border router must be 7442 advertising a TOS X route to the destination. 7444 Calculating AS external routes (Section 16.4). 7445 This calculation considers the concatenation of a path to a 7446 forwarding address with an AS external link. Only TOS X 7447 paths to the forwarding address are examined, and the AS 7448 boundary router must be advertising a TOS X route to the 7449 destination. Note that this means that AS external link 7450 advertisements having the T-bit reset in their Options field 7451 are not considered. 7453 In addition, the advertising AS boundary router must also be 7454 reachable for its advertisements to be considered (see 7455 Section 16.4). However, if the advertising router and the 7456 forwarding address are not one in the same, the advertising 7457 router need only be reachable via TOS 0. 7459 Footnotes 7461 [1]The graph's vertices represent either routers, transit networks, 7462 or stub networks. Since routers may belong to multiple areas, it is 7463 not possible to color the graph's vertices. 7465 [2]It is possible for all of a router's interfaces to be unnumbered 7466 point-to-point links. In this case, an IP address must be assigned 7467 to the router. This address will then be advertised in the router's 7468 router links advertisement as a host route. 7470 [3]Note that in these cases both interfaces, the non-virtual and the 7471 virtual, would have the same IP address. 7473 [4]Note that no host route is generated for, and no IP packets can 7474 be addressed to, interfaces to unnumbered point-to-point networks. 7475 This is regardless of such an interface's state. 7477 [5]It is instructive to see what happens when the Designated Router 7478 for the network crashes. Call the Designated Router for the network 7479 RT1, and the Backup Designated Router RT2. If Router RT1 crashes 7480 (or maybe its interface to the network dies), the other routers on 7481 the network will detect RT1's absence within RouterDeadInterval 7482 seconds. All routers may not detect this at precisely the same 7483 time; the routers that detect RT1's absence before RT2 does will, 7484 for a time, select RT2 to be both Designated Router and Backup 7485 Designated Router. When RT2 detects that RT1 is gone it will move 7486 itself to Designated Router. At this time, the remaining router 7487 having highest Router Priority will be selected as Backup Designated 7488 Router. 7490 [6]On point-to-point networks, the lower level protocols indicate 7491 whether the neighbor is up and running. Likewise, existence of the 7492 neighbor on virtual links is indicated by the routing table 7493 calculation. However, in both these cases, the Hello Protocol is 7494 still used. This ensures that communication between the neighbors 7495 is bidirectional, and that each of the neighbors has a functioning 7496 routing protocol layer. 7498 [7]When the identity of the Designated Router is changing, it may be 7499 quite common for a neighbor in this state to send the router a 7500 Database Description packet; this means that there is some momentary 7501 disagreement on the Designated Router's identity. 7503 [8]Note that it is possible for a router to resynchronize any of its 7504 fully established adjacencies by setting the adjacency's state back 7505 to ExStart. This will cause the other end of the adjacency to 7506 process a SeqNumberMismatch event, and therefore to also go back to 7507 ExStart state. 7509 [9]The address space of IP networks and the address space of OSPF 7510 Router IDs may overlap. That is, a network may have an IP address 7511 which is identical (when considered as a 32-bit number) to some 7512 router's Router ID. 7514 [10]"Discard" entries are necessary to ensure that route 7515 summarization at area boundaries will not cause packet looping. 7517 [11]It is assumed that, for two different address ranges matching 7518 the destination, one range is more specific than the other. Non- 7519 contiguous subnet masks can be configured to violate this 7520 assumption. Such subnet mask configurations cannot be handled by the 7521 OSPF protocol. 7523 [12]MaxAgeDiff is an architectural constant. It indicates the 7524 maximum dispersion of ages, in seconds, that can occur for a single 7525 link state instance as it is flooded throughout the routing domain. 7526 If two advertisements differ by more than this, they are assumed to 7527 be different instances of the same advertisement. This can occur 7528 when a router restarts and loses track of the advertisement's 7529 previous LS sequence number. See Section 13.4 for more details. 7531 [13]When two advertisements have different LS checksums, they are 7532 assumed to be separate instances. This can occur when a router 7533 restarts, and loses track of the advertisement's previous LS 7534 sequence number. In the case where the two advertisements have the 7535 same LS sequence number, it is not possible to determine which link 7536 state is actually newer. However, if the wrong advertisement is 7537 accepted as newer, the originating router will simply originate 7538 another instance. See Section 13.4 for further details. 7540 [14]There is one instance where a lookup must be done based on 7541 partial information. This is during the routing table calculation, 7542 when a network links advertisement must be found based solely on its 7543 Link State ID. The lookup in this case is still well defined, since 7544 no two network links advertisements can have the same Link State ID. 7546 [15]This is the way RFC 1583 specified point-to-point 7547 representation. It has three advantages: a) it does not require 7548 allocating a subnet to the point-to-point link, b) it tends to bias 7549 the routing so that packets destined for the point-to-point 7550 interface will actually be received over the interface (which is 7551 useful for diagnostic purposes) and c) it allows network 7552 bootstrapping of a neighbor, without requiring that the bootstrap 7553 program contain an OSPF implementation. 7555 [16]This is the more traditional point-to-point representation used 7556 by protocols such as RIP. 7558 [17]This clause covers the case: Inter-area routes are not 7559 summarized to the backbone. This is because inter-area routes are 7560 always associated with the backbone area. 7562 [18]This clause is only invoked when Area A is a Transit area 7563 supporting one or more virtual links. For example, in the area 7564 configuration of Figure 6, Router RT11 need only originate a single 7565 summary link having the (collapsed) destination N9-N11,H1 into its 7566 connected Transit area Area 2, since all of its other eligible 7567 routes have next hops belonging to Area 2 (and as such only need be 7568 advertised by other area border routers; in this case, Routers RT10 7569 and RT7). 7571 [19]By keeping more information in the routing table, it is possible 7572 for an implementation to recalculate the shortest path tree for only 7573 a single area. In fact, there are incremental algorithms that allow 7574 an implementation to recalculate only a portion of a single area's 7575 shortest path tree [1]. However, these algorithms are beyond the 7576 scope of this specification. 7578 [20]This is how the Link state request list is emptied, which 7579 eventually causes the neighbor state to transition to Full. See 7580 Section 10.9 for more details. 7582 [21]It should be a relatively rare occurrence for an advertisement's 7583 LS age to reach MaxAge in this fashion. Usually, the advertisement 7584 will be replaced by a more recent instance before it ages out. 7586 [22]Only the TOS 0 routes are important here because all OSPF 7587 protocol packets are sent with TOS = 0. See Appendix A. 7589 [23]It may be the case that paths to certain destinations do not 7590 vary based on TOS. For these destinations, the routing calculation 7591 need not be repeated for each TOS value. In addition, there need 7592 only be a single routing table entry for these destinations (instead 7593 of a separate entry for each TOS value). 7595 [24]Strictly speaking, because of equal-cost multipath, the 7596 algorithm does not create a tree. We continue to use the "tree" 7597 terminology because that is what occurs most often in the existing 7598 literature. 7600 [25]Note that the presence of any link back to V is sufficient; it 7601 need not be the matching half of the link under consideration from V 7602 to W. This is enough to ensure that, before data traffic flows 7603 between a pair of neighboring routers, their link state databases 7604 will be synchronized. 7606 [26]When the forwarding address is non-zero, it should point to a 7607 router belonging to another Autonomous System. See Section 12.4.4 7608 for more details. 7610 References 7612 [1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing 7613 Algorithm Improvements", BBN Technical Report 3803, April 1978. 7615 [2] Digital Equipment Corporation, "Information processing systems 7616 -- Data communications -- Intermediate System to Intermediate 7617 System Intra-Domain Routing Protocol", October 1987. 7619 [3] McQuillan, J. et.al., "The New Routing Algorithm for the 7620 ARPANET", IEEE Transactions on Communications, May 1980. 7622 [4] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", 7623 Computer Networks, December 1983. 7625 [5] Postel, J., "Internet Protocol", STD 5, RFC 791, 7626 USC/Information Sciences Institute, September 1981. 7628 [6] McKenzie, A., "ISO Transport Protocol specification ISO DP 7629 8073", RFC 905, ISO, April 1984. 7631 [7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 7632 1112, Stanford University, May 1988. 7634 [8] McCloghrie, K., and M. Rose, "Management Information Base for 7635 network management of TCP/IP-based internets: MIB-II", STD 17, 7636 RFC 1213, Hughes LAN Systems, Performance Systems 7637 International, March 1991. 7639 [9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. 7641 [10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter- 7642 Domain Routing (CIDR): an Address Assignment and Aggregation 7643 Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 7644 1993. 7646 [11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 7647 1700, USC/Information Sciences Institute, October 1994. 7649 [12] Almquist, P., "Type of Service in the Internet Protocol Suite", 7650 RFC 1349, July 1992. 7652 [13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN 7653 Protocol Handbook, April 1985. 7655 [14] Bradley, T., and C. Brown, "Inverse Address Resolution 7656 Protocol", RFC 1293, January 1992. 7658 [15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 7659 Over Frame Relay Networks", RFC 1586, March 1994. 7661 [16] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", 7662 ACM Computer Communications Review, Volume 19, Number 2, pp. 7663 32-38, April 1989. 7665 [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 7666 1992. 7668 [18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 7669 Inc., March 1994. 7671 [19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 7672 RainbowBridge Communications, Stanford University, March 1994. 7674 [20] Ferguson, D., "The OSPF External Attributes LSA", work in 7675 progress. 7677 [21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 7678 Cascade, April 1995. 7680 A. OSPF data formats 7682 This appendix describes the format of OSPF protocol packets and OSPF 7683 link state advertisements. The OSPF protocol runs directly over the 7684 IP network layer. Before any data formats are described, the 7685 details of the OSPF encapsulation are explained. 7687 Next the OSPF Options field is described. This field describes 7688 various capabilities that may or may not be supported by pieces of 7689 the OSPF routing domain. The OSPF Options field is contained in OSPF 7690 Hello packets, Database Description packets and in OSPF link state 7691 advertisements. 7693 OSPF packet formats are detailed in Section A.3. A description of 7694 OSPF link state advertisements appears in Section A.4. 7696 A.1 Encapsulation of OSPF packets 7698 OSPF runs directly over the Internet Protocol's network layer. OSPF 7699 packets are therefore encapsulated solely by IP and local data-link 7700 headers. 7702 OSPF does not define a way to fragment its protocol packets, and 7703 depends on IP fragmentation when transmitting packets larger than 7704 the network MTU. The OSPF packet types that are likely to be large 7705 (Database Description Packets, Link State Request, Link State 7706 Update, and Link State Acknowledgment packets) can usually be split 7707 into several separate protocol packets, without loss of 7708 functionality. This is recommended; IP fragmentation should be 7709 avoided whenever possible. Using this reasoning, an attempt should 7710 be made to limit the sizes of packets sent over virtual links to 576 7711 bytes. However, if necessary, the length of OSPF packets can be up 7712 to 65,535 bytes (including the IP header). 7714 The other important features of OSPF's IP encapsulation are: 7716 o Use of IP multicast. Some OSPF messages are multicast, when 7717 sent over broadcast networks. Two distinct IP multicast 7718 addresses are used. Packets sent to these multicast addresses 7719 should never be forwarded; they are meant to travel a single hop 7720 only. To ensure that these packets will not travel multiple 7721 hops, their IP TTL must be set to 1. 7723 AllSPFRouters 7724 This multicast address has been assigned the value 7725 224.0.0.5. All routers running OSPF should be prepared to 7726 receive packets sent to this address. Hello packets are 7727 always sent to this destination. Also, certain OSPF 7728 protocol packets are sent to this address during the 7729 flooding procedure. 7731 AllDRouters 7732 This multicast address has been assigned the value 7733 224.0.0.6. Both the Designated Router and Backup Designated 7734 Router must be prepared to receive packets destined to this 7735 address. Certain OSPF protocol packets are sent to this 7736 address during the flooding procedure. 7738 o OSPF is IP protocol number 89. This number has been registered 7739 with the Network Information Center. IP protocol number 7740 assignments are documented in [11]. 7742 o Routing protocol packets are sent with IP TOS of 0. The OSPF 7743 protocol supports TOS-based routing. Routes to any particular 7744 destination may vary based on TOS. However, all OSPF routing 7745 protocol packets are sent using the normal service TOS value of 7746 binary 0000 defined in [12]. 7748 o Routing protocol packets are sent with IP precedence set to 7749 Internetwork Control. OSPF protocol packets should be given 7750 precedence over regular IP data traffic, in both sending and 7751 receiving. Setting the IP precedence field in the IP header to 7752 Internetwork Control [5] may help implement this objective. 7754 A.2 The Options field 7756 The OSPF Options field is present in OSPF Hello packets, Database 7757 Description packets and all link state advertisements. The Options 7758 field enables OSPF routers to support (or not support) optional 7759 capabilities, and to communicate their capability level to other 7760 OSPF routers. Through this mechanism routers of differing 7761 capabilities can be mixed within an OSPF routing domain. 7763 When used in Hello packets, the Options field allows a router to 7764 reject a neighbor because of a capability mismatch. Alternatively, 7765 when capabilities are exchanged in Database Description packets a 7766 router can choose not to forward certain link state advertisements 7767 to a neighbor because of its reduced functionality. Lastly, listing 7768 capabilities in link state advertisements allows routers to forward 7769 traffic around reduced functionality routers, by excluding them from 7770 parts of the routing table calculation. 7772 Six bits of the OSPF Options field have been assigned, although only 7773 two (the T-bit and E-bit) are described completely by this memo. 7774 Each bit is described briefly below. Routers should reset (i.e. 7775 clear) unrecognized bits in the Options field when sending Hello 7776 packets or Database Description packets and when originating link 7777 state advertisements. Conversely, routers encountering unrecognized 7778 Option bits in received Hello Packets, Database Description packets 7779 or link state advertisements should ignore the capability and 7780 process the packet/advertisement normally. 7782 +------------------------------------+ 7783 | * | * | DC | EA | N/P | MC | E | T | 7784 +------------------------------------+ 7786 The Options field 7788 T-bit 7789 This bit describes the router's TOS-based routing capability, as 7790 specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of this memo. 7792 E-bit 7793 This bit describes the way AS-external-LSAs are flooded, as 7794 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. 7796 MC-bit 7797 This bit describes whether IP multicast datagrams are forwarded 7798 according to the specifications in [18]. 7800 N/P-bit 7801 This bit describes the handling of Type-7 LSAs, as specified in 7802 [19]. 7804 EA-bit 7805 This bit describes the router's willingness to receive and 7806 forward External-Attributes-LSAs, as specified in [20]. 7808 DC-bit 7809 This bit describes the router's handling of demand circuits, as 7810 specified in [21]. 7812 A.3 OSPF Packet Formats 7814 There are five distinct OSPF packet types. All OSPF packet types 7815 begin with a standard 24 byte header. This header is described 7816 first. Each packet type is then described in a succeeding section. 7817 In these sections each packet's division into fields is displayed, 7818 and then the field definitions are enumerated. 7820 All OSPF packet types (other than the OSPF Hello packets) deal with 7821 lists of link state advertisements. For example, Link State Update 7822 packets implement the flooding of advertisements throughout the OSPF 7823 routing domain. Because of this, OSPF protocol packets cannot be 7824 parsed unless the format of link state advertisements is also 7825 understood. The format of Link state advertisements is described in 7826 Section A.4. 7828 The receive processing of OSPF packets is detailed in Section 8.2. 7829 The sending of OSPF packets is explained in Section 8.1. 7831 A.3.1 The OSPF packet header 7833 Every OSPF packet starts with a standard 24 byte header. This 7834 header contains all the information necessary to determine whether 7835 the packet should be accepted for further processing. This 7836 determination is described in Section 8.2 of the specification. 7838 0 1 2 3 7839 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 7840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7841 | Version # | Type | Packet length | 7842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7843 | Router ID | 7844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7845 | Area ID | 7846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7847 | Checksum | AuType | 7848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7849 | Authentication | 7850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7851 | Authentication | 7852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7854 Version # 7855 The OSPF version number. This specification documents version 2 7856 of the protocol. 7858 Type 7859 The OSPF packet types are as follows. See Sections A.3.2 through 7860 A.3.6 for details. 7862 Type Description 7863 ________________________________ 7864 1 Hello 7865 2 Database Description 7866 3 Link State Request 7867 4 Link State Update 7868 5 Link State Acknowledgment 7869 Packet length 7870 The length of the OSPF protocol packet in bytes. This length 7871 includes the standard OSPF header. 7873 Router ID 7874 The Router ID of the packet's source. 7876 Area ID 7877 A 32 bit number identifying the area that this packet belongs 7878 to. All OSPF packets are associated with a single area. Most 7879 travel a single hop only. Packets travelling over a virtual 7880 link are labelled with the backbone Area ID of 0.0.0.0. 7882 Checksum 7883 The standard IP checksum of the entire contents of the packet, 7884 starting with the OSPF packet header but excluding the 64-bit 7885 authentication field. This checksum is calculated as the 16-bit 7886 one's complement of the one's complement sum of all the 16-bit 7887 words in the packet, excepting the authentication field. If the 7888 packet's length is not an integral number of 16-bit words, the 7889 packet is padded with a byte of zero before checksumming. The 7890 checksum is considered to be part of the packet authentication 7891 procedure; for some authentication types the checksum 7892 calculation is omitted. 7894 AuType 7895 Identifies the authentication procedure to be used for the 7896 packet. Authentication is discussed in Appendix D of the 7897 specification. Consult Appendix D for a list of the currently 7898 defined authentication types. 7900 Authentication 7901 A 64-bit field for use by the authentication scheme. See 7902 Appendix D for details. 7904 A.3.2 The Hello packet 7906 Hello packets are OSPF packet type 1. These packets are sent 7907 periodically on all interfaces (including virtual links) in order to 7908 establish and maintain neighbor relationships. In addition, Hello 7909 Packets are multicast on those physical networks having a multicast 7910 or broadcast capability, enabling dynamic discovery of neighboring 7911 routers. 7913 All routers connected to a common network must agree on certain 7914 parameters (Network mask, HelloInterval and RouterDeadInterval). 7915 These parameters are included in Hello packets, so that differences 7916 can inhibit the forming of neighbor relationships. A detailed 7917 explanation of the receive processing for Hello packets is presented 7918 in Section 10.5. The sending of Hello packets is covered in Section 7919 9.5. 7921 0 1 2 3 7922 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 7923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7924 | Version # | 1 | Packet length | 7925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7926 | Router ID | 7927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7928 | Area ID | 7929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7930 | Checksum | AuType | 7931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7932 | Authentication | 7933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7934 | Authentication | 7935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7936 | Network Mask | 7937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7938 | HelloInterval | Options | Rtr Pri | 7939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7940 | RouterDeadInterval | 7941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7942 | Designated Router | 7943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7944 | Backup Designated Router | 7945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7946 | Neighbor | 7947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7948 | ... | 7950 Network mask 7951 The network mask associated with this interface. For example, 7952 if the interface is to a class B network whose third byte is 7953 used for subnetting, the network mask is 0xffffff00. 7955 Options 7956 The optional capabilities supported by the router, as documented 7957 in Section A.2. 7959 HelloInterval 7960 The number of seconds between this router's Hello packets. 7962 Rtr Pri 7963 This router's Router Priority. Used in (Backup) Designated 7964 Router election. If set to 0, the router will be ineligible to 7965 become (Backup) Designated Router. 7967 RouterDeadInterval 7968 The number of seconds before declaring a silent router down. 7970 Designated Router 7971 The identity of the Designated Router for this network, in the 7972 view of the sending router. The Designated Router is identified 7973 here by its IP interface address on the network. Set to 0.0.0.0 7974 if there is no Designated Router. 7976 Backup Designated Router 7977 The identity of the Backup Designated Router for this network, 7978 in the view of the sending router. The Backup Designated Router 7979 is identified here by its IP interface address on the network. 7980 Set to 0.0.0.0 if there is no Backup Designated Router. 7982 Neighbor 7983 The Router IDs of each router from whom valid Hello packets have 7984 been seen recently on the network. Recently means in the last 7985 RouterDeadInterval seconds. 7987 A.3.3 The Database Description packet 7989 Database Description packets are OSPF packet type 2. These packets 7990 are exchanged when an adjacency is being initialized. They describe 7991 the contents of the link-state database. Multiple packets may be 7992 used to describe the database. For this purpose a poll-response 7993 procedure is used. One of the routers is designated to be the 7994 master, the other the slave. The master sends Database Description 7995 packets (polls) which are acknowledged by Database Description 7996 packets sent by the slave (responses). The responses are linked to 7997 the polls via the packets' DD sequence numbers. 7999 0 1 2 3 8000 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 8001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8002 | Version # | 2 | Packet length | 8003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8004 | Router ID | 8005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8006 | Area ID | 8007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8008 | Checksum | AuType | 8009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8010 | Authentication | 8011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8012 | Authentication | 8013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8014 | 0 | 0 | Options |0|0|0|0|0|I|M|MS 8015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8016 | DD sequence number | 8017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8018 | | 8019 +- -+ 8020 | A | 8021 +- Link State Advertisement -+ 8022 | Header | 8023 +- -+ 8024 | | 8025 +- -+ 8026 | | 8027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8028 | ... | 8030 The format of the Database Description packet is very similar to 8031 both the Link State Request and Link State Acknowledgment packets. 8032 The main part of all three is a list of items, each item describing 8033 a piece of the link-state database. The sending of Database 8034 Description Packets is documented in Section 10.8. The reception of 8035 Database Description packets is documented in Section 10.6. 8037 0 These fields are reserved. They must be 0. 8039 Options 8040 The optional capabilities supported by the router, as documented 8041 in Section A.2. 8043 I-bit 8044 The Init bit. When set to 1, this packet is the first in the 8045 sequence of Database Description Packets. 8047 M-bit 8048 The More bit. When set to 1, it indicates that more Database 8049 Description Packets are to follow. 8051 MS-bit 8052 The Master/Slave bit. When set to 1, it indicates that the 8053 router is the master during the Database Exchange process. 8054 Otherwise, the router is the slave. 8056 DD sequence number 8057 Used to sequence the collection of Database Description Packets. 8058 The initial value (indicated by the Init bit being set) should 8059 be unique. The DD sequence number then increments until the 8060 complete database description has been sent. 8062 The rest of the packet consists of a (possibly partial) list of the 8063 link-state database's pieces. Each link state advertisement in the 8064 database is described by its link state advertisement header. The 8065 link state advertisement header is documented in Section A.4.1. It 8066 contains all the information required to uniquely identify both the 8067 advertisement and the advertisement's current instance. 8069 A.3.4 The Link State Request packet 8071 Link State Request packets are OSPF packet type 3. After exchanging 8072 Database Description packets with a neighboring router, a router may 8073 find that parts of its link-state database are out-of-date. The 8074 Link State Request packet is used to request the pieces of the 8075 neighbor's database that are more up-to-date. Multiple Link State 8076 Request packets may need to be used. 8078 A router that sends a Link State Request packet has in mind the 8079 precise instance of the database pieces it is requesting. Each 8080 instance is defined by its LS sequence number, LS checksum, and LS 8081 age, although these fields are not specified in the Link State 8082 Request Packet itself. The router may receive even more recent 8083 instances in response. 8085 The sending of Link State Request packets is documented in Section 8086 10.9. The reception of Link State Request packets is documented in 8087 Section 10.7. 8089 0 1 2 3 8090 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 8091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8092 | Version # | 3 | Packet length | 8093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8094 | Router ID | 8095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8096 | Area ID | 8097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8098 | Checksum | AuType | 8099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8100 | Authentication | 8101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8102 | Authentication | 8103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8104 | LS type | 8105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8106 | Link State ID | 8107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8108 | Advertising Router | 8109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8110 | ... | 8112 Each advertisement requested is specified by its LS type, Link State 8113 ID, and Advertising Router. This uniquely identifies the 8114 advertisement, but not its instance. Link State Request packets are 8115 understood to be requests for the most recent instance (whatever 8116 that might be). 8118 A.3.5 The Link State Update packet 8120 Link State Update packets are OSPF packet type 4. These packets 8121 implement the flooding of link state advertisements. Each Link 8122 State Update packet carries a collection of link state 8123 advertisements one hop further from their origin. Several link 8124 state advertisements may be included in a single packet. 8126 Link State Update packets are multicast on those physical networks 8127 that support multicast/broadcast. In order to make the flooding 8128 procedure reliable, flooded advertisements are acknowledged in Link 8129 State Acknowledgment packets. If retransmission of certain 8130 advertisements is necessary, the retransmitted advertisements are 8131 always carried by unicast Link State Update packets. For more 8132 information on the reliable flooding of link state advertisements, 8133 consult Section 13. 8135 0 1 2 3 8136 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 8137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8138 | Version # | 4 | Packet length | 8139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8140 | Router ID | 8141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8142 | Area ID | 8143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8144 | Checksum | AuType | 8145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8146 | Authentication | 8147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8148 | Authentication | 8149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8150 | # advertisements | 8151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8152 | | 8153 +- +-+ 8154 | Link state advertisements | 8155 +- +-+ 8156 | ... | 8158 # advertisements 8159 The number of link state advertisements included in this update. 8161 The body of the Link State Update packet consists of a list of link 8162 state advertisements. Each advertisement begins with a common 20 8163 byte header, described in Section A.4.1. Detailed formats of the 8164 different types of link state advertisements are described in 8165 Section A.4. 8167 A.3.6 The Link State Acknowledgment packet 8169 Link State Acknowledgment Packets are OSPF packet type 5. To make 8170 the flooding of link state advertisements reliable, flooded 8171 advertisements are explicitly acknowledged. This acknowledgment is 8172 accomplished through the sending and receiving of Link State 8173 Acknowledgment packets. Multiple link state advertisements can be 8174 acknowledged in a single Link State Acknowledgment packet. 8176 Depending on the state of the sending interface and the sender of 8177 the corresponding Link State Update packet, a Link State 8178 Acknowledgment packet is sent either to the multicast address 8179 AllSPFRouters, to the multicast address AllDRouters, or as a 8180 unicast. The sending of Link State Acknowledgement packets is 8181 documented in Section 13.5. The reception of Link State 8182 Acknowledgement packets is documented in Section 13.7. 8184 The format of this packet is similar to that of the Data Description 8185 packet. The body of both packets is simply a list of link state 8186 advertisement headers. 8188 0 1 2 3 8189 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 8190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8191 | Version # | 5 | Packet length | 8192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8193 | Router ID | 8194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8195 | Area ID | 8196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8197 | Checksum | AuType | 8198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8199 | Authentication | 8200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8201 | Authentication | 8202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8203 | | 8204 +- -+ 8205 | A | 8206 +- Link State Advertisement -+ 8207 | Header | 8208 +- -+ 8209 | | 8210 +- -+ 8211 | | 8212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8213 | ... | 8215 Each acknowledged link state advertisement is described by its link 8216 state advertisement header. The link state advertisement header is 8217 documented in Section A.4.1. It contains all the information 8218 required to uniquely identify both the advertisement and the 8219 advertisement's current instance. 8221 A.4 Link state advertisement formats 8223 This memo defines five distinct types of link state advertisements. 8224 Each link state advertisement begins with a standard 20 byte link 8225 state advertisement header. This header is explained in Section 8226 A.4.1. Succeeding sections then diagram the separate link state 8227 advertisement types. 8229 Each link state advertisement describes a piece of the OSPF routing 8230 domain. Every router originates a router links advertisement. In 8231 addition, whenever the router is elected Designated Router, it 8232 originates a network links advertisement. Other types of link state 8233 advertisements may also be originated (see Section 12.4). All link 8234 state advertisements are then flooded throughout the OSPF routing 8235 domain. The flooding algorithm is reliable, ensuring that all 8236 routers have the same collection of link state advertisements. (See 8237 Section 13 for more information concerning the flooding algorithm). 8238 This collection of advertisements is called the link-state database. 8240 From the link state database, each router constructs a shortest path 8241 tree with itself as root. This yields a routing table (see Section 8242 11). For the details of the routing table build process, see 8243 Section 16. 8245 A.4.1 The Link State Advertisement header 8247 All link state advertisements begin with a common 20 byte header. 8248 This header contains enough information to uniquely identify the 8249 advertisement (LS type, Link State ID, and Advertising Router). 8250 Multiple instances of the link state advertisement may exist in the 8251 routing domain at the same time. It is then necessary to determine 8252 which instance is more recent. This is accomplished by examining 8253 the LS age, LS sequence number and LS checksum fields that are also 8254 contained in the link state advertisement header. 8256 0 1 2 3 8257 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 8258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8259 | LS age | Options | LS type | 8260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8261 | Link State ID | 8262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8263 | Advertising Router | 8264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8265 | LS sequence number | 8266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8267 | LS checksum | length | 8268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8270 LS age 8271 The time in seconds since the link state advertisement was 8272 originated. 8274 Options 8275 The optional capabilities supported by the described portion of 8276 the routing domain. OSPF's optional capabilities are documented 8277 in Section A.2. 8279 LS type 8280 The type of the link state advertisement. Each link state type 8281 has a separate advertisement format. The link state types 8282 defined in this memo are as follows (see Section 12.1.3 for 8283 further explanation): 8285 LS Type Description 8286 ___________________________________ 8287 1 Router links 8288 2 Network links 8289 3 Summary link (IP network) 8290 4 Summary link (ASBR) 8291 5 AS external link 8293 Link State ID 8294 This field identifies the portion of the internet environment 8295 that is being described by the advertisement. The contents of 8296 this field depend on the advertisement's LS type. For example, 8297 in network links advertisements the Link State ID is set to the 8298 IP interface address of the network's Designated Router (from 8299 which the network's IP address can be derived). The Link State 8300 ID is further discussed in Section 12.1.4. 8302 Advertising Router 8303 The Router ID of the router that originated the link state 8304 advertisement. For example, in network links advertisements 8305 this field is equal to the Router ID of the network's Designated 8306 Router. 8308 LS sequence number 8309 Detects old or duplicate link state advertisements. Successive 8310 instances of a link state advertisement are given successive LS 8311 sequence numbers. See Section 12.1.6 for more details. 8313 LS checksum 8314 The Fletcher checksum of the complete contents of the link state 8315 advertisement, including the link state advertisement header but 8316 excluding the LS age field. See Section 12.1.7 for more details. 8318 length 8319 The length in bytes of the link state advertisement. This 8320 includes the 20 byte link state advertisement header. 8322 A.4.2 Router links advertisements 8324 Router links advertisements are the Type 1 link state 8325 advertisements. Each router in an area originates a router links 8326 advertisement. The advertisement describes the state and cost of 8327 the router's links (i.e., interfaces) to the area. All of the 8328 router's links to the area must be described in a single router 8329 links advertisement. For details concerning the construction of 8330 router links advertisements, see Section 12.4.1. 8332 0 1 2 3 8333 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 8334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8335 | LS age | Options | 1 | 8336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8337 | Link State ID | 8338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8339 | Advertising Router | 8340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8341 | LS sequence number | 8342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8343 | LS checksum | length | 8344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8345 | 0 |V|E|B| 0 | # links | 8346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8347 | Link ID | 8348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8349 | Link Data | 8350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8351 | Type | # TOS | TOS 0 metric | 8352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8353 | TOS | 0 | metric | 8354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8355 | ... | 8356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8357 | TOS | 0 | metric | 8358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8359 | Link ID | 8360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8361 | Link Data | 8362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8363 | ... | 8365 In router links advertisements, the Link State ID field is set to 8366 the router's OSPF Router ID. The T-bit is set in the 8367 advertisement's Option field if and only if the router is able to 8368 calculate a separate set of routes for each IP TOS. Router links 8369 advertisements are flooded throughout a single area only. 8371 bit V 8372 When set, the router is an endpoint of an active virtual link 8373 that is using the described area as a Transit area (V is for 8374 virtual link endpoint). 8376 bit E 8377 When set, the router is an AS boundary router (E is for 8378 external). 8380 bit B 8381 When set, the router is an area border router (B is for border). 8383 # links 8384 The number of router links described in this advertisement. 8385 This must be the total collection of router links (i.e., 8386 interfaces) to the area. 8388 The following fields are used to describe each router link (i.e., 8389 interface). Each router link is typed (see the below Type field). 8390 The Type field indicates the kind of link being described. It may 8391 be a link to a transit network, to another router or to a stub 8392 network. The values of all the other fields describing a router 8393 link depend on the link's Type. For example, each link has an 8394 associated 32-bit Link Data field. For links to stub networks this 8395 field specifies the network's IP address mask. For other link types 8396 the Link Data field specifies the router interface's IP address. 8398 Type 8399 A quick description of the router link. One of the following. 8400 Note that host routes are classified as links to stub networks 8401 with network mask of 0xffffffff. 8403 Type Description 8404 __________________________________________________ 8405 1 Point-to-point connection to another router 8406 2 Connection to a transit network 8407 3 Connection to a stub network 8408 4 Virtual link 8409 Link ID 8410 Identifies the object that this router link connects to. Value 8411 depends on the link's Type. When connecting to an object that 8412 also originates a link state advertisement (i.e., another router 8413 or a transit network) the Link ID is equal to the neighboring 8414 advertisement's Link State ID. This provides the key for 8415 looking up the neighboring advertisement in the link state 8416 database during the routing table calculation. See Section 12.2 8417 for more details. 8419 Type Link ID 8420 ______________________________________ 8421 1 Neighboring router's Router ID 8422 2 IP address of Designated Router 8423 3 IP network/subnet number 8424 4 Neighboring router's Router ID 8426 Link Data 8427 Value again depends on the link's Type field. For connections to 8428 stub networks, Link Data specifies the network's IP address 8429 mask. For unnumbered point-to-point connections, it specifies 8430 the interface's MIB-II [8] ifIndex value. For the other link 8431 types it specifies the router interface's IP address. This 8432 latter piece of information is needed during the routing table 8433 build process, when calculating the IP address of the next hop. 8434 See Section 16.1.1 for more details. 8436 # TOS 8437 The number of different TOS metrics given for this link, not 8438 counting the required metric for TOS 0. For example, if no 8439 additional TOS metrics are given, this field is set to 0. 8441 TOS 0 metric 8442 The cost of using this router link for TOS 0. 8444 For each link, separate metrics may be specified for each Type of 8445 Service (TOS). The metric for TOS 0 must always be included, and 8446 was discussed above. Metrics for non-zero TOS are described below. 8447 The encoding of TOS in OSPF link state advertisements is described 8448 in Section 12.3. Note that the cost for non-zero TOS values that 8449 are not specified defaults to the TOS 0 cost. Metrics must be 8450 listed in order of increasing TOS encoding. For example, the metric 8451 for TOS 16 must always follow the metric for TOS 8 when both are 8452 specified. 8454 TOS IP Type of Service that this metric refers to. The encoding of 8455 TOS in OSPF link state advertisements is described in Section 8456 12.3. 8458 metric 8459 The cost of using this outbound router link, for traffic of the 8460 specified TOS. 8462 A.4.3 Network links advertisements 8464 Network links advertisements are the Type 2 link state 8465 advertisements. A network links advertisement is originated for 8466 each broadcast and NBMA network in the area which supports two or 8467 more routers. The network links advertisement is originated by the 8468 network's Designated Router. The advertisement describes all 8469 routers attached to the network, including the Designated Router 8470 itself. The advertisement's Link State ID field lists the IP 8471 interface address of the Designated Router. 8473 The distance from the network to all attached routers is zero, for 8474 all Types of Service. This is why the TOS and metric fields need 8475 not be specified in the network links advertisement. For details 8476 concerning the construction of network links advertisements, see 8477 Section 12.4.2. 8479 0 1 2 3 8480 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 8481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8482 | LS age | Options | 2 | 8483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8484 | Link State ID | 8485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8486 | Advertising Router | 8487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8488 | LS sequence number | 8489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8490 | LS checksum | length | 8491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8492 | Network Mask | 8493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8494 | Attached Router | 8495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8496 | ... | 8498 Network Mask 8499 The IP address mask for the network. For example, a class A 8500 network would have the mask 0xff000000. 8502 Attached Router 8503 The Router IDs of each of the routers attached to the network. 8504 Actually, only those routers that are fully adjacent to the 8505 Designated Router are listed. The Designated Router includes 8506 itself in this list. The number of routers included can be 8507 deduced from the link state advertisement header's length field. 8509 A.4.4 Summary link advertisements 8511 Summary link advertisements are the Type 3 and 4 link state 8512 advertisements. These advertisements are originated by area border 8513 routers. Summary link advertisements describe inter-area 8514 destinations. For details concerning the construction of summary 8515 link advertisements, see Section 12.4.3. 8517 Type 3 link state advertisements are used when the destination is an 8518 IP network. In this case the advertisement's Link State ID field is 8519 an IP network number (if necessary, the Link State ID can also have 8520 one or more of the network's "host" bits set; see Appendix E for 8521 details). When the destination is an AS boundary router, a Type 4 8522 advertisement is used, and the Link State ID field is the AS 8523 boundary router's OSPF Router ID. (To see why it is necessary to 8524 advertise the location of each ASBR, consult Section 16.4.) Other 8525 than the difference in the Link State ID field, the format of Type 3 8526 and 4 link state advertisements is identical. 8528 0 1 2 3 8529 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 8530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8531 | LS age | Options | 3 or 4 | 8532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8533 | Link State ID | 8534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8535 | Advertising Router | 8536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8537 | LS sequence number | 8538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8539 | LS checksum | length | 8540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8541 | Network Mask | 8542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8543 | TOS | metric | 8544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8545 | ... | 8547 For stub areas, Type 3 summary link advertisements can also be used 8548 to describe a (per-area) default route. Default summary routes are 8549 used in stub areas instead of flooding a complete set of external 8550 routes. When describing a default summary route, the 8551 advertisement's Link State ID is always set to DefaultDestination 8552 (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8554 Separate costs may be advertised for each IP Type of Service. The 8555 encoding of TOS in OSPF link state advertisements is described in 8556 Section 12.3. Note that the cost for TOS 0 must be included, and is 8557 always listed first. If the T-bit is reset in the advertisement's 8558 Option field, only a route for TOS 0 is described by the 8559 advertisement. Otherwise, routes for the other TOS values are also 8560 described; if a cost for a certain TOS is not included, its cost 8561 defaults to that specified for TOS 0. 8563 Network Mask 8564 For Type 3 link state advertisements, this indicates the 8565 destination network's IP address mask. For example, when 8566 advertising the location of a class A network the value 8567 0xff000000 would be used. This field is not meaningful and must 8568 be zero for Type 4 link state advertisements. 8570 For each specified Type of Service, the following fields are 8571 defined. The number of TOS routes included can be calculated from 8572 the link state advertisement header's length field. A values for 8573 TOS 0 must be specified; it is listed first. Other values must be 8574 listed in order of increasing TOS encoding. For example, the cost 8575 for TOS 16 must always follow the cost for TOS 8 when both are 8576 specified. 8578 TOS The Type of Service that the following cost concerns. The 8579 encoding of TOS in OSPF link state advertisements is described 8580 in Section 12.3. 8582 metric 8583 The cost of this route. Expressed in the same units as the 8584 interface costs in the router links advertisements. 8586 A.4.5 AS external link advertisements 8588 AS external link advertisements are the Type 5 link state 8589 advertisements. These advertisements are originated by AS boundary 8590 routers, and describe destinations external to the AS. For details 8591 concerning the construction of AS external link advertisements, see 8592 Section 12.4.3. 8594 AS external link advertisements usually describe a particular 8595 external destination. For these advertisements the Link State ID 8596 field specifies an IP network number (if necessary, the Link State 8597 ID can also have one or more of the network's "host" bits set; see 8598 Appendix E for details). AS external link advertisements are also 8599 used to describe a default route. Default routes are used when no 8600 specific route exists to the destination. When describing a default 8601 route, the Link State ID is always set to DefaultDestination 8602 (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8604 0 1 2 3 8605 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 8606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8607 | LS age | Options | 5 | 8608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8609 | Link State ID | 8610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8611 | Advertising Router | 8612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8613 | LS sequence number | 8614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8615 | LS checksum | length | 8616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8617 | Network Mask | 8618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8619 |E| TOS | metric | 8620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8621 | Forwarding address | 8622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8623 | External Route Tag | 8624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8625 | ... | 8627 Separate costs may be advertised for each IP Type of Service. The 8628 encoding of TOS in OSPF link state advertisements is described in 8629 Section 12.3. Note that the cost for TOS 0 must be included, and is 8630 always listed first. If the T-bit is reset in the advertisement's 8631 Option field, only a route for TOS 0 is described by the 8632 advertisement. Otherwise, routes for the other TOS values are also 8633 described; if a cost for a certain TOS is not included, its cost 8634 defaults to that specified for TOS 0. 8636 Network Mask 8637 The IP address mask for the advertised destination. For 8638 example, when advertising a class A network the mask 0xff000000 8639 would be used. 8641 For each specified Type of Service, the following fields are 8642 defined. The number of TOS routes included can be calculated from 8643 the link state advertisement header's length field. A values for 8644 TOS 0 must be specified; it is listed first. Other values must be 8645 listed in order of increasing TOS encoding. For example, the cost 8646 for TOS 16 must always follow the cost for TOS 8 when both are 8647 specified. 8649 TOS The Type of Service that the following fields concern. The 8650 encoding of TOS in OSPF link state advertisements is described 8651 in Section 12.3. 8653 bit E 8654 The type of external metric. If bit E is set, the metric 8655 specified is a Type 2 external metric. This means the metric is 8656 considered larger than any link state path. If bit E is zero, 8657 the specified metric is a Type 1 external metric. This means 8658 that it is expressed in the same units as the link state metric 8659 (i.e., the same units as interface cost). 8661 metric 8662 The cost of this route. Interpretation depends on the external 8663 type indication (bit E above). 8665 Forwarding address 8666 Data traffic for the advertised destination and TOS will be 8667 forwarded to this address. If the Forwarding address is set to 8668 0.0.0.0, data traffic will be forwarded instead to the 8669 advertisement's originator (i.e., the responsible AS boundary 8670 router). 8672 External Route Tag 8673 A 32-bit field attached to each external route. This is not 8674 used by the OSPF protocol itself. It may be used to communicate 8675 information between AS boundary routers; the precise nature of 8676 such information is outside the scope of this specification. 8678 B. Architectural Constants 8680 Several OSPF protocol parameters have fixed architectural values. 8681 These parameters have been referred to in the text by names such as 8682 LSRefreshTime. The same naming convention is used for the 8683 configurable protocol parameters. They are defined in Appendix C. 8685 The name of each architectural constant follows, together with its 8686 value and a short description of its function. 8688 LSRefreshTime 8689 The maximum time between distinct originations of any particular 8690 link state advertisement. If the LS age field of one of the 8691 router's self-originated advertisements reaches the value 8692 LSRefreshTime, a new instance of the link state advertisement is 8693 originated, even though the contents of the advertisement (apart 8694 from the link state header) will be the same. The value of 8695 LSRefreshTime is set to 30 minutes. 8697 MinLSInterval 8698 The minimum time between distinct originations of any particular 8699 link state advertisement. The value of MinLSInterval is set to 8700 5 seconds. 8702 MinLSArrival 8703 For any particular LSA, the minimum time that must elapse 8704 between reception of new LSA instances during flooding. LSA 8705 instances received at higher frequencies are discarded. The 8706 value of MinLSArrival is set to 1 second. 8708 MaxAge 8709 The maximum age that a link state advertisement can attain. When 8710 an advertisement's LS age field reaches MaxAge, it is reflooded 8711 in an attempt to flush the advertisement from the routing domain 8712 (See Section 14). Advertisements of age MaxAge are not used in 8713 the routing table calculation. The value of MaxAge is set to 1 8714 hour. 8716 CheckAge 8717 When the age of a link state advertisement in the link state 8718 database hits a multiple of CheckAge, the advertisement's 8719 checksum is verified. An incorrect checksum at this time 8720 indicates a serious error. The value of CheckAge is set to 5 8721 minutes. 8723 MaxAgeDiff 8724 The maximum time dispersion that can occur, as a link state 8725 advertisement is flooded throughout the AS. Most of this time 8726 is accounted for by the link state advertisements sitting on 8727 router output queues (and therefore not aging) during the 8728 flooding process. The value of MaxAgeDiff is set to 15 minutes. 8730 LSInfinity 8731 The metric value indicating that the destination described by a 8732 link state advertisement is unreachable. Used in summary link 8733 advertisements and AS external link advertisements as an 8734 alternative to premature aging (see Section 14.1). It is defined 8735 to be the 24-bit binary value of all ones: 0xffffff. 8737 DefaultDestination 8738 The Destination ID that indicates the default route. This route 8739 is used when no other matching routing table entry can be found. 8740 The default destination can only be advertised in AS external 8741 link advertisements and in stub areas' type 3 summary link 8742 advertisements. Its value is the IP address 0.0.0.0. It 8743 associated Network Mask is also always 0.0.0.0. 8745 InitialSequenceNumber 8746 The value used for LS Sequence Number when originating the first 8747 instance of any LSA. Its value is the signed 32-bit integer 8748 0x80000001. 8750 MaxSequenceNumber 8751 The maximum value that LS Sequence Number can attain. Its value 8752 is the signed 32-bit integer 0x7fffffff. 8754 C. Configurable Constants 8756 The OSPF protocol has quite a few configurable parameters. These 8757 parameters are listed below. They are grouped into general 8758 functional categories (area parameters, interface parameters, etc.). 8759 Sample values are given for some of the parameters. 8761 Some parameter settings need to be consistent among groups of 8762 routers. For example, all routers in an area must agree on that 8763 area's parameters, and all routers attached to a network must agree 8764 on that network's IP network number and mask. 8766 Some parameters may be determined by router algorithms outside of 8767 this specification (e.g., the address of a host connected to the 8768 router via a SLIP line). From OSPF's point of view, these items are 8769 still configurable. 8771 C.1 Global parameters 8773 In general, a separate copy of the OSPF protocol is run for each 8774 area. Because of this, most configuration parameters are 8775 defined on a per-area basis. The few global configuration 8776 parameters are listed below. 8778 Router ID 8779 This is a 32-bit number that uniquely identifies the router 8780 in the Autonomous System. One algorithm for Router ID 8781 assignment is to choose the largest or smallest IP address 8782 assigned to the router. If a router's OSPF Router ID is 8783 changed, the router's OSPF software should be restarted 8784 before the new Router ID takes effect. Before restarting in 8785 order to change its Router ID, the router should flush its 8786 self-originated link state advertisements from the routing 8787 domain (see Section 14.1), or they will persist for up to 8788 MaxAge minutes. 8790 TOS capability 8791 This item indicates whether the router will calculate 8792 separate routes based on TOS. For more information, see 8793 Sections 4.5 and 16.9. 8795 C.2 Area parameters 8797 All routers belonging to an area must agree on that area's 8798 configuration. Disagreements between two routers will lead to 8799 an inability for adjacencies to form between them, with a 8800 resulting hindrance to the flow of routing protocol and data 8801 traffic. The following items must be configured for an area: 8803 Area ID 8804 This is a 32-bit number that identifies the area. The Area 8805 ID of 0.0.0.0 is reserved for the backbone. If the area 8806 represents a subnetted network, the IP network number of the 8807 subnetted network may be used for the Area ID. 8809 List of address ranges 8810 An OSPF area is defined as a list of address ranges. Each 8811 address range consists of the following items: 8813 [IP address, mask] 8814 Describes the collection of IP addresses contained 8815 in the address range. Networks and hosts are 8816 assigned to an area depending on whether their 8817 addresses fall into one of the area's defining 8818 address ranges. Routers are viewed as belonging to 8819 multiple areas, depending on their attached 8820 networks' area membership. 8822 Status Set to either Advertise or DoNotAdvertise. Routing 8823 information is condensed at area boundaries. 8824 External to the area, at most a single route is 8825 advertised (via a summary link advertisement) for 8826 each address range. The route is advertised if and 8827 only if the address range's Status is set to 8828 Advertise. Unadvertised ranges allow the existence 8829 of certain networks to be intentionally hidden from 8830 other areas. Status is set to Advertise by default. 8832 As an example, suppose an IP subnetted network is to be its 8833 own OSPF area. The area would be configured as a single 8834 address range, whose IP address is the address of the 8835 subnetted network, and whose mask is the natural class A, B, 8836 or C address mask. A single route would be advertised 8837 external to the area, describing the entire subnetted 8838 network. 8840 ExternalRoutingCapability 8841 Whether AS external advertisements will be flooded 8842 into/throughout the area. If AS external advertisements are 8843 excluded from the area, the area is called a "stub". 8844 Internal to stub areas, routing to external destinations 8845 will be based solely on a default summary route. The 8846 backbone cannot be configured as a stub area. Also, virtual 8847 links cannot be configured through stub areas. For more 8848 information, see Section 3.6. 8850 StubDefaultCost 8851 If the area has been configured as a stub area, and the 8852 router itself is an area border router, then the 8853 StubDefaultCost indicates the cost of the default summary 8854 link that the router should advertise into the area. There 8855 can be a separate cost configured for each IP TOS. See 8856 Section 12.4.3 for more information. 8858 C.3 Router interface parameters 8860 Some of the configurable router interface parameters (such as IP 8861 interface address and subnet mask) actually imply properties of 8862 the attached networks, and therefore must be consistent across 8863 all the routers attached to that network. The parameters that 8864 must be configured for a router interface are: 8866 IP interface address 8867 The IP protocol address for this interface. This uniquely 8868 identifies the router over the entire internet. An IP 8869 address is not required on point-to-point networks. Such a 8870 point-to-point network is called "unnumbered". 8872 IP interface mask 8873 Also referred to as the subnet/network mask, this indicates 8874 the portion of the IP interface address that identifies the 8875 attached network. Masking the IP interface address with the 8876 IP interface mask yields the IP network number of the 8877 attached network. On point-to-point networks and virtual 8878 links, the IP interface mask is not defined. On these 8879 networks, the link itself is not assigned an IP network 8880 number, and so the addresses of each side of the link are 8881 assigned independently, if they are assigned at all. 8883 Area ID 8884 The OSPF area to which the attached network belongs. 8886 Interface output cost(s) 8887 The cost of sending a packet on the interface, expressed in 8888 the link state metric. This is advertised as the link cost 8889 for this interface in the router's router links 8890 advertisement. There may be a separate cost for each IP 8891 Type of Service. The interface output cost(s) must always 8892 be greater than 0. 8894 RxmtInterval 8895 The number of seconds between link state advertisement 8896 retransmissions, for adjacencies belonging to this 8897 interface. Also used when retransmitting Database 8898 Description and Link State Request Packets. This should be 8899 well over the expected round-trip delay between any two 8900 routers on the attached network. The setting of this value 8901 should be conservative or needless retransmissions will 8902 result. Sample value for a local area network: 5 seconds. 8904 InfTransDelay 8905 The estimated number of seconds it takes to transmit a Link 8906 State Update Packet over this interface. Link state 8907 advertisements contained in the update packet must have 8908 their age incremented by this amount before transmission. 8909 This value should take into account the transmission and 8910 propagation delays of the interface. It must be greater 8911 than 0. Sample value for a local area network: 1 second. 8913 Router Priority 8914 An 8-bit unsigned integer. When two routers attached to a 8915 network both attempt to become Designated Router, the one 8916 with the highest Router Priority takes precedence. If there 8917 is still a tie, the router with the highest Router ID takes 8918 precedence. A router whose Router Priority is set to 0 is 8919 ineligible to become Designated Router on the attached 8920 network. Router Priority is only configured for interfaces 8921 to broadcast and NBMA networks. 8923 HelloInterval 8924 The length of time, in seconds, between the Hello Packets 8925 that the router sends on the interface. This value is 8926 advertised in the router's Hello Packets. It must be the 8927 same for all routers attached to a common network. The 8928 smaller the HelloInterval, the faster topological changes 8929 will be detected; however, more OSPF routing protocol 8930 traffic will ensue. Sample value for a X.25 PDN network: 30 8931 seconds. Sample value for a local area network: 10 seconds. 8933 RouterDeadInterval 8934 After ceasing to hear a router's Hello Packets, the number 8935 of seconds before its neighbors declare the router down. 8936 This is also advertised in the router's Hello Packets in 8937 their RouterDeadInterval field. This should be some 8938 multiple of the HelloInterval (say 4). This value again 8939 must be the same for all routers attached to a common 8940 network. 8942 AuType 8943 Identifies the authentication procedure to be used on the 8944 attached network. This value must be the same for all 8945 routers attached to the network. See Appendix D for a 8946 discussion of the defined authentication types. 8948 Authentication key 8949 This configured data allows the authentication procedure to 8950 verify OSPF protocol packets received over the interface. 8951 For example, if the AuType indicates simple password, the 8952 Authentication key would be a clear 64-bit password. 8953 Authentication keys associated with the other OSPF 8954 authentication types are discussed in Appendix D. 8956 C.4 Virtual link parameters 8958 Virtual links are used to restore/increase connectivity of the 8959 backbone. Virtual links may be configured between any pair of 8960 area border routers having interfaces to a common (non-backbone) 8961 area. The virtual link appears as an unnumbered point-to-point 8962 link in the graph for the backbone. The virtual link must be 8963 configured in both of the area border routers. 8965 A virtual link appears in router links advertisements (for the 8966 backbone) as if it were a separate router interface to the 8967 backbone. As such, it has all of the parameters associated with 8968 a router interface (see Section C.3). Although a virtual link 8969 acts like an unnumbered point-to-point link, it does have an 8970 associated IP interface address. This address is used as the IP 8971 source in OSPF protocol packets it sends along the virtual link, 8972 and is set dynamically during the routing table build process. 8973 Interface output cost is also set dynamically on virtual links 8974 to be the cost of the intra-area path between the two routers. 8975 The parameter RxmtInterval must be configured, and should be 8976 well over the expected round-trip delay between the two routers. 8977 This may be hard to estimate for a virtual link; it is better to 8978 err on the side of making it too large. Router Priority is not 8979 used on virtual links. 8981 A virtual link is defined by the following two configurable 8982 parameters: the Router ID of the virtual link's other endpoint, 8983 and the (non-backbone) area through which the virtual link runs 8984 (referred to as the virtual link's Transit area). Virtual links 8985 cannot be configured through stub areas. 8987 C.5 NBMA network parameters 8989 OSPF treats an NBMA network much like it treats a broadcast 8990 network. Since there may be many routers attached to the 8991 network, a Designated Router is selected for the network. This 8992 Designated Router then originates a networks links 8993 advertisement, which lists all routers attached to the NBMA 8994 network. 8996 However, due to the lack of broadcast capabilities, it may be 8997 necessary to use configuration parameters in the Designated 8998 Router selection. These parameters will only need to be 8999 configured in those routers that are themselves eligible to 9000 become Designated Router (i.e., those router's whose Router 9001 Priority for the network is non-zero), and then only if no 9002 automatic procedure for discovering neighbors exists: 9004 List of all other attached routers 9005 The list of all other routers attached to the NBMA network. 9006 Each router is listed by its IP interface address on the 9007 network. Also, for each router listed, that router's 9008 eligibility to become Designated Router must be defined. 9009 When an interface to a NBMA network comes up, the router 9010 sends Hello Packets only to those neighbors eligible to 9011 become Designated Router, until the identity of the 9012 Designated Router is discovered. 9014 PollInterval 9015 If a neighboring router has become inactive (Hello Packets 9016 have not been seen for RouterDeadInterval seconds), it may 9017 still be necessary to send Hello Packets to the dead 9018 neighbor. These Hello Packets will be sent at the reduced 9019 rate PollInterval, which should be much larger than 9020 HelloInterval. Sample value for a PDN X.25 network: 2 9021 minutes. 9023 C.6 Point-to-Point network parameters 9025 On Point-to-MultiPoint networks, it may be necessary to 9026 configure the set of neighbors that are directly reachable over 9027 the Point-to-MultiPoint network. Each neighbor is identified by 9028 its IP address on the Point-to-MultiPoint network. Designated 9029 Routers are not elected on Point-to-MultiPoint networks, so the 9030 Designated Router eligibility of configured neighbors is 9031 undefined. 9033 Alternatively, neighbors on Point-to-MultiPoint networks may be 9034 dynamically discovered by lower-level protocols such as Inverse 9035 ARP ([14]). 9037 C.7 Host route parameters 9039 Host routes are advertised in router links advertisements as 9040 stub networks with mask 0xffffffff. They indicate either router 9041 interfaces to point-to-point networks, looped router interfaces, 9042 or IP hosts that are directly connected to the router (e.g., via 9043 a SLIP line). For each host directly connected to the router, 9044 the following items must be configured: 9046 Host IP address 9047 The IP address of the host. 9049 Cost of link to host 9050 The cost of sending a packet to the host, in terms of the 9051 link state metric. There may be multiple costs configured, 9052 one for each IP TOS. However, since the host probably has 9053 only a single connection to the internet, the actual 9054 configured cost(s) in many cases is unimportant (i.e., will 9055 have no effect on routing). 9057 Area ID 9058 The OSPF area to which the host belongs. 9060 D. Authentication 9062 All OSPF protocol exchanges are authenticated. The OSPF packet 9063 header (see Section A.3.1) includes an authentication type field, 9064 and 64-bits of data for use by the appropriate authentication scheme 9065 (determined by the type field). 9067 The authentication type is configurable on a per-interface basis. 9068 Additional authentication data is also configurable on a per- 9069 interface basis. 9071 Authentication types 0, 1 and 2 are defined by this specification. 9072 All other authentication types are reserved for definition by the 9073 IANA (iana@ISI.EDU). The current list of authentication types is 9074 described below in Table 20. 9076 AuType Description 9077 ___________________________________________ 9078 0 Null authentication 9079 1 Simple password 9080 2 Cryptographic authentication 9081 All others Reserved for assignment by the 9082 IANA (iana@ISI.EDU) 9084 Table 20: OSPF authentication types. 9086 D.1 Null authentication 9088 Use of this authentication type means that routing exchanges in 9089 the area are not authenticated. The 64-bit authentication field 9090 in the OSPF header can contain anything; it is not examined on 9091 packet reception. When employing Null authentication, the entire 9092 contents of each OSPF packet (other than the 64-bit 9093 authentication field) are checksummed in order to detect data 9094 corruption. 9096 D.2 Simple password authentication 9098 Using this authentication type, a 64-bit field is configured on 9099 a per-network basis. All packets sent on a particular network 9100 must have this configured value in their OSPF header 64-bit 9101 authentication field. This essentially serves as a "clear" 64- 9102 bit password. In addition, the entire contents of each OSPF 9103 packet (other than the 64-bit authentication field) are 9104 checksummed in order to detect data corruption. 9106 Simple password authentication guards against routers 9107 inadvertently joining the area; each router must first be 9108 configured with its attached networks' passwords before it can 9109 participate in the routing domain. However, simple password 9110 authentication is vulnerable to passive attacks currently 9111 widespread in the Internet (see [16]). Anyone with physical 9112 access to the network can learn the password and compromise the 9113 security of the OSPF routing domain. 9115 D.3 Cryptographic authentication 9117 Using this authentication type, a shared secret key is 9118 configured in all routers attached to a common network/subnet. 9119 For each OSPF protocol packet, the key is used to 9120 generate/verify a "message digest" that is appended to the end 9121 of the OSPF packet. The message digest is a one-way function of 9122 the OSPF protocol packet and the secret key. Since the secret 9123 key is never sent over the network in the clear, protection is 9124 provided against passive attacks. 9126 The algorithms used to generate and verify the message digest 9127 are specified implicitly by the secret key. This specification 9128 completely defines the use of OSPF Cryptographic authentication 9129 when the MD5 algorithm is used. 9131 In addition, a non-decreasing sequence number is included in 9132 each OSPF protocol packet to protect against replay attacks. 9133 This provide long term protection; however, it is still possible 9134 to replay a message until the sequence number changes. To 9135 implement this feature, each neighbor data structure contains a 9137 0 1 2 3 9138 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 9139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9140 | 0 | Key ID | Auth Data Len | 9141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9142 | Cryptographic sequence number | 9143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9145 Figure 18: Usage of the Authentication field 9146 in the OSPF packet header when Cryptographic 9147 Authentication is employed 9148 new field called the "cryptographic sequence number". This field 9149 is initialized to zero, and is also set to zero whenever the 9150 neighbor's state transitions to "Down". Whenever an OSPF packet 9151 is accepted as authentic, the cryptographic sequence number is 9152 set to the received packet's sequence number. 9154 The OSPF Cryptographic authentication option does not provide 9155 confidentiality. 9157 When cryptographic authentication is used, the 64-bit 9158 Authentication field in the standard OSPF packet header is 9159 redefined as shown in Figure 18. The new field definitions are 9160 as follows: 9162 Key ID 9163 This field identifies the algorithm and secret key used to 9164 create the message digest appended to the OSPF packet. Key 9165 Identifiers are unique per-interface (or equivalently, per- 9166 subnet). 9168 Auth Data Len 9169 The length in bytes of the message digest appended to the 9170 OSPF packet. 9172 Cryptographic sequence number 9173 An unsigned 32-bit non-decreasing sequence number. Used to 9174 guard against replay attacks. 9176 The message digest appended to the OSPF packet is not actually 9177 considered part of the OSPF protocol packet: the message digest 9178 is not included in the OSPF header's packet length, although it 9179 is included in the packet's IP header length field. 9181 Each key is identified by the combination of interface and Key 9182 ID. An interface may have multiple keys active at any one time. 9183 This enables smooth transition from one key to another. Each key 9184 has four time constants associated with it. These time constants 9185 can be expressed in terms of a time-of-day clock, or in terms of 9186 a router's local clock (e.g., number of seconds since last 9187 reboot): 9189 KeyStartAccept 9190 The time that the router will start accepting packets that 9191 have been created with the given key. 9193 KeyStartGenerate 9194 The time that the router will start using the key for packet 9195 generation. 9197 KeyStopGenerate 9198 The time that the router will stop using the key for packet 9199 generation. 9201 KeyStopAccept 9202 The time that the router will stop accepting packets that 9203 have been created with the given key. 9205 In order to achieve smooth key transition, KeyStartAccept should 9206 be less than KeyStartGenerate and KeyStopGenerate should be less 9207 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are 9208 left unspecified, the key's lifetime is infinite. When a new key 9209 replaces an old, the KeyStartGenerate time for the new key must 9210 be less than or equal to the KeyStopGenerate time of the old 9211 key. 9213 Key storage should persist across a system restart, warm or 9214 cold, to avoid operational issues. In the event that the last 9215 key associated with an interface expires, it is unacceptable to 9216 revert to an unauthenticated condition, and not advisable to 9217 disrupt routing. Therefore, the router should send a "last 9218 authentication key expiration" notification to the network 9219 manager and treat the key as having an infinite lifetime until 9220 the lifetime is extended, the key is deleted by network 9221 management, or a new key is configured. 9223 D.4 Message generation 9225 After building the contents of an OSPF packet, the 9226 authentication procedure indicated by the sending interface's 9227 Autype value is called before the packet is sent. The 9228 authentication procedure modifies the OSPF packet as follows. 9230 D.4.1 Generating Null authentication 9232 When using Null authentication, the packet is modified as 9233 follows: 9235 (1) The Autype field in the standard OSPF header is set to 9236 0. 9238 (2) The checksum field in the standard OSPF header is set to 9239 the standard IP checksum of the entire contents of the 9240 packet, starting with the OSPF packet header but 9241 excluding the 64-bit authentication field. This 9242 checksum is calculated as the 16-bit one's complement of 9243 the one's complement sum of all the 16-bit words in the 9244 packet, excepting the authentication field. If the 9245 packet's length is not an integral number of 16-bit 9246 words, the packet is padded with a byte of zero before 9247 checksumming. 9249 D.4.2 Generating Simple password authentication 9251 When using Simple password authentication, the packet is 9252 modified as follows: 9254 (1) The Autype field in the standard OSPF header is set to 9255 1. 9257 (2) The checksum field in the standard OSPF header is set to 9258 the standard IP checksum of the entire contents of the 9259 packet, starting with the OSPF packet header but 9260 excluding the 64-bit authentication field. This 9261 checksum is calculated as the 16-bit one's complement of 9262 the one's complement sum of all the 16-bit words in the 9263 packet, excepting the authentication field. If the 9264 packet's length is not an integral number of 16-bit 9265 words, the packet is padded with a byte of zero before 9266 checksumming. 9268 (3) The 64-bit authentication field in the OSPF packet 9269 header is set to the 64-bit password (i.e., 9270 authentication key) that has been configured for the 9271 interface. 9273 D.4.3 Generating Cryptographic authentication 9275 When using Cryptographic authentication, there may be 9276 multiple keys configured for the interface. In this case, 9277 among the keys that are valid for message generation (i.e, 9278 that have KeyStartGenerate <= current time < 9279 KeyStopGenerate) choose the one with the most recent 9280 KeyStartGenerate time. Using this key, modify the packet as 9281 follows: 9283 (1) The Autype field in the standard OSPF header is set to 9284 2. 9286 (2) The checksum field in the standard OSPF header is not 9287 calculated, but is instead set to 0. 9289 (3) The Key ID (see Figure 18) is set to the chosen key's 9290 Key ID. 9292 (4) The Auth Data Len field is set to the length in bytes of 9293 the message digest that will be appended to the OSPF 9294 packet. When using MD5 as the authentication algorithm, 9295 Auth Data Len will be 16. 9297 (5) The 32-bit Cryptographic sequence number (see Figure 18) 9298 is set to a non-decreasing value (i.e., a value at least 9299 as large as the last value sent out the interface). The 9300 precise values to use in the cryptographic sequence 9301 number field are implementation-specific. For example, 9302 it may be based on a simple counter, or be based on the 9303 system's clock. 9305 (6) The message digest that is to be appended to the OSPF 9306 packet is now calculated in the following steps. The 9307 authentication algorithm to be used in calculating the 9308 digest is indicated by the key itself. 9310 (a) The key is appended to the OSPF message. When using 9311 MD5 as the authentication algorithm, the key will be 9312 16 bytes long. For all algorithms, the OSPF 9313 Authentication Key is never longer than the 9314 resulting message digest. 9316 (b) If required by the authentication algorithm, 9317 trailing pad and length fields are added (for MD5, 9318 see [17]). 9320 (c) The authentication algorithm is used to calculate 9321 the message digest (for MD5, see [17]). 9323 (d) The digest is written over the OSPF key (i.e., 9324 appended to the original OSPF message). When MD5 is 9325 used, the digest will be 16 bytes long. The digest 9326 is not counted in the OSPF packet's length field, 9327 but is included in the packet's IP length field. Any 9328 trailing pad or length fields beyond the digest are 9329 not counted or transmitted. 9331 D.5 Message verification 9333 When an OSPF packet has been received on an interface, it must 9334 be authenticated. The authentication procedure is indicated by 9335 the setting of Autype in the standard OSPF packet header, which 9336 matches the setting of Autype for the receiving OSPF interface. 9338 If an OSPF protocol packet is accepted as authentic, processing 9339 of the packet continues as specified in Section 8.2. Packets 9340 which fail authentication are discarded. 9342 D.5.1 Verifying Null authentication 9344 When using Null authentication, the checksum field in the 9345 OSPF header must be verified. It must be set to the 16-bit 9346 one's complement of the one's complement sum of all the 16- 9347 bit words in the packet, excepting the authentication field. 9348 (If the packet's length is not an integral number of 16-bit 9349 words, the packet is padded with a byte of zero before 9350 checksumming.) 9352 D.5.2 Verifying Simple password authentication 9354 When using Simple password authentication, the received OSPF 9355 packet is authenticated as follows: 9357 (1) The checksum field in the OSPF header must be verified. 9358 It must be set to the 16-bit one's complement of the 9359 one's complement sum of all the 16-bit words in the 9360 packet, excepting the authentication field. (If the 9361 packet's length is not an integral number of 16-bit 9362 words, the packet is padded with a byte of zero before 9363 checksumming.) 9365 (2) The 64-bit authentication field in the OSPF packet 9366 header must be equal to the 64-bit password (i.e., 9367 authentication key) that has been configured for the 9368 interface. 9370 D.5.3 Verifying Cryptographic authentication 9372 When using Cryptographic authentication, the received OSPF 9373 packet is authenticated as follows: 9375 (1) Locate the receiving interface's configured key having 9376 Key ID equal to that specified in the received OSPF 9377 packet (see Figure 18). If the key is not found, or if 9378 the key is not valid for reception (i.e., current time < 9379 KeyStartAccept or current time >= KeyStopAccept), the 9380 OSPF packet is discarded. 9382 (2) If the cryptographic sequence number found in the OSPF 9383 header (see Figure 18) is less than the cryptographic 9384 sequence number recorded in the sending neighbor's data 9385 structure, the OSPF packet is discarded. 9387 (3) Verify the appended message digest in the following 9388 steps: 9390 (a) The received digest is set aside. 9392 (b) A new digest is calculated, following steps 6a 9393 through 6d of Section D.4.3. 9395 (c) The calculated and received digests are compared. If 9396 they do not match, the OSPF packet is discarded. If 9397 they do match, the OSPF protocol packet is accepted 9398 as authentic, and the "cryptographic sequence 9399 number" in the neighbor's data structure is set to 9400 the sequence number found in the packet's OSPF 9401 header. 9403 E. An algorithm for assigning Link State IDs 9405 The Link State ID in AS external link advertisements and summary 9406 link advertisements is usually set to the described network's IP 9407 address. However, if necessary one or more of the network's host 9408 bits may be set in the Link State ID. This allows the router to 9409 originate separate advertisements for networks having the same 9410 address, yet different masks. Such networks can occur in the 9411 presence of supernetting and subnet 0s (see [10]). 9413 This appendix gives one possible algorithm for setting the host bits 9414 in Link State IDs. The choice of such an algorithm is a local 9415 decision. Separate routers are free to use different algorithms, 9416 since the only advertisements affected are the ones that the router 9417 itself originates. The only requirement on the algorithms used is 9418 that the network's IP address should be used as the Link State ID 9419 whenever possible; this maximizes interoperability with OSPF 9420 implementations predating RFC 1583. 9422 The algorithm below is stated for AS external link advertisements. 9423 This is only for clarity; the exact same algorithm can be used for 9424 summary link advertisements. Suppose that the router wishes to 9425 originate an AS external link advertisement for a network having 9426 address NA and mask NM1. The following steps are then used to 9427 determine the advertisement's Link State ID: 9429 (1) Determine whether the router is already originating an AS 9430 external link advertisement with Link State ID equal to NA (in 9431 such an advertisement the router itself will be listed as the 9432 advertisement's Advertising Router). If not, the Link State ID 9433 is set equal to NA and the algorithm terminates. Otherwise, 9435 (2) Obtain the network mask from the body of the already existing AS 9436 external link advertisement. Call this mask NM2. There are then 9437 two cases: 9439 o NM1 is longer (i.e., more specific) than NM2. In this case, 9440 set the Link State ID in the new advertisement to be the 9441 network [NA,NM1] with all the host bits set (i.e., equal to 9442 NA or'ed together with all the bits that are not set in NM1, 9443 which is network [NA,NM1]'s broadcast address). 9445 o NM2 is longer than NM1. In this case, change the existing 9446 advertisement (having Link State ID of NA) to reference the 9447 new network [NA,NM1] by incrementing the sequence number, 9448 changing the mask in the body to NM1 and inserting the cost 9449 of the new network. Then originate a new advertisement for 9450 the old network [NA,NM2], with Link State ID equal to NA 9451 or'ed together with the bits that are not set in NM2 (i.e., 9452 network [NA,NM2]'s broadcast address). 9454 The above algorithm assumes that all masks are contiguous; this 9455 ensures that when two networks have the same address, one mask is 9456 more specific than the other. The algorithm also assumes that no 9457 network exists having an address equal to another network's 9458 broadcast address. Given these two assumptions, the above algorithm 9459 always produces unique Link State IDs. The above algorithm can also 9460 be reworded as follows: When originating an AS external link state 9461 advertisement, try to use the network number as the Link State ID. 9462 If that produces a conflict, examine the two networks in conflict. 9463 One will be a subset of the other. For the less specific network, 9464 use the network number as the Link State ID and for the more 9465 specific use the network's broadcast address instead (i.e., flip all 9466 the "host" bits to 1). If the most specific network was originated 9467 first, this will cause you to originate two link state 9468 advertisements at once. 9470 As an example of the algorithm, consider its operation when the 9471 following sequence of events occurs in a single router (Router A). 9473 (1) Router A wants to originate an AS external link advertisement 9474 for [10.0.0.0,255.255.255.0]: 9476 (a) A Link State ID of 10.0.0.0 is used. 9478 (2) Router A then wants to originate an AS external link 9479 advertisement for [10.0.0.0,255.255.0.0]: 9481 (a) The advertisement for [10.0.0,0,255.255.255.0] is 9482 reoriginated using a new Link State ID of 10.0.0.255. 9484 (b) A Link State ID of 10.0.0.0 is used for 9485 [10.0.0.0,255.255.0.0]. 9487 (3) Router A then wants to originate an AS external link 9488 advertisement for [10.0.0.0,255.0.0.0]: 9490 (a) The advertisement for [10.0.0.0,255.255.0.0] is reoriginated 9491 using a new Link State ID of 10.0.255.255. 9493 (b) A Link State ID of 10.0.0.0 is used for 9494 [10.0.0.0,255.0.0.0]. 9496 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID 9497 of 10.0.0.255. 9499 F. Differences from RFC 1583 9501 This section documents the differences between this memo and RFC 9502 1583. All differences are backward-compatible. Implementations of 9503 this memo and of RFC 1583 will interoperate. 9505 F.1 Enhancements to OSPF authentication 9507 An additional OSPF authentication type has been added: the 9508 Cryptographic authentication type. This has been defined so that 9509 any arbitrary "Keyed Message Digest" algorithm can be used for 9510 packet authentication. Operation using the MD5 algorithm is 9511 completely specified (see Appendix D). 9513 A number of other changes were also made to OSPF packet 9514 authentication, affecting the following Sections: 9516 o The authentication type is now specified per-interface, 9517 rather than per-area (Sections 6, 9, C.2 and C.3). 9519 o The OSPF packet header checksum is now considered part of 9520 the authentication procedure, and so has been moved out of 9521 the packet send and receive logic (Sections 8.1 and 8.2) and 9522 into the description of authentication types (Appendix D). 9524 o In Appendix D, sections detailing message generation and 9525 message verification have been added. 9527 o For the OSPF Cryptographic authentication type, a discussion 9528 of key management, including the requirement for 9529 simultaneous support of multiple keys, key lifetimes and 9530 smooth key transition, has been added to Appendix D. 9532 F.2 Addition of Point-to-MultiPoint interface 9534 This memo adds an additional method for running OSPF over non- 9535 broadcast networks: the Point-to-Multipoint network. To 9536 implement this addition, the language of RFC 1583 has been 9537 altered slightly. References to "multi-access" networks have 9538 been deleted. The term "non-broadcast networks" is now used to 9539 describe networks which can connect many routers, but which do 9540 not natively support broadcast/multicast (such as a public Frame 9541 relay network). Over non-broadcast networks, there are two 9542 options for running OSPF: modelling them as "NBMA networks" or 9543 as "Point-to-MultiPoint networks". NBMA networks require full 9544 mesh connectivity between routers; when employing NBMA networks 9545 in the presence of partial mesh connectivity, multiple NBMA 9546 networks must be configured, as described in [15]. In contrast, 9547 Point-to-Multipoint networks have been designed to work simply 9548 and naturally when faced with partial mesh connectivity. 9550 The addition of Point-to-MultiPoint networks has impacted the 9551 text in many places, which are briefly summarized below: 9553 o Section 2 describing the OSPF link-state database has been 9554 split into additional subsections, with one of the 9555 subsections (Section 2.1.1) describing the differing map 9556 representations of the two non-broadcast network options. 9557 This subsection also contrasts the NBMA network and Point- 9558 to-MultiPoint network options, and describes the situations 9559 when one is preferable to the other. 9561 o In contrast to NBMA networks, Point-to-MultiPoint networks 9562 have the following properties. Adjacencies are established 9563 between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 9564 and 10.4). There is no Designated Router or Backup 9565 Designated Router for a Point-to-MultiPoint network 9566 (Sections 7.3 and 7.4). No network-LSA is originated for 9567 Point-to-MultiPoint networks (Sections 12.4.2 and A.4.3). 9568 Router Priority is not configured for Point-to-MultiPoint 9569 interfaces, nor for neighbors on Point-to-MultiPoint 9570 networks (Sections C.3 and C.6). 9572 o The Interface FSM for a Point-to-MultiPoint interface is 9573 identical to that used for point-to-point interfaces. Two 9574 states are possible: "Down" and Point-to-Point" (Section 9575 9.3). 9577 o When originating a router-LSA, and Point-to-MultiPoint 9578 interface is reported as a collection of "point-to-point 9579 links" to all of the interface's adjacent neighbors, 9580 together with a single stub link advertising the interface's 9581 IP address with a cost of 0 (Section 12.4.1.4). 9583 o When flooding out a non-broadcast interface (when either in 9584 NBMA or Point-to-MultiPoint mode) the Link State Update or 9585 Link State Acknowledgment packet must be replicated in order 9586 to be sent to each of the interface's neighbors (see 9587 Sections 13.3 and 13.5). 9589 F.3 Support for overlapping area ranges 9591 RFC 1583 requires that all networks falling into a given area 9592 range actually belong to a single area. This memo relaxes that 9593 restriction. This is useful in the following example. Suppose 9594 that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of 9595 these subnets are assigned to a single OSPF area (call it Area 9596 X), while a few subnets are assigned to other areas. In order to 9597 get this configuration to work with RFC 1583, you must not 9598 summarize the subnets of Area X with the single range [10.0.0.0, 9599 255.0.0.0], because then the subnets of 10.0.0.0 belonging to 9600 other areas would become unreachable. However, with this memo 9601 you can summarize the subnets in Area X, provided that the 9602 subnets belonging to other areas are not summarized. 9604 Implementation details for this change can be found in Sections 9605 11.1 and 16.2. 9607 F.4 A modification to the flooding algorithm 9609 The OSPF flooding algorithm has been modified as follows. When a 9610 Link State Update Packet is received that contains an LSA 9611 instance which is actually less recent than the the router's 9612 current database copy, the router will now in most cases respond 9613 by flooding back its database copy. This is in contrast to the 9614 RFC 1583 behavior, which was to simply throw the received LSA 9615 away. 9617 Detailed description of the change can be found in Step 8 of 9618 Section 13. 9620 This change improves MaxAge processing. There are times when 9621 MaxAge LSAs stay in a router's database for extended intervals: 9622 1) when they are stuck in a retransmission queue on a slow link 9623 or 2) when a router is not properly flushing them from its 9624 database, due to software bugs. The prolonged existence of these 9625 MaxAge LSAs can inhibit the flooding of new instances of the 9626 LSA. New instances typically start with LS sequence number equal 9627 to InitialSequenceNumber, and are treated as less recent (and 9628 hence were discarded according to RFC 1583) by routers still 9629 holding MaxAge instances. However, with the above change to 9630 flooding, a router holding a MaxAge instance will flood back the 9631 MaxAge instance. When this flood reaches the LSA's originator, 9632 it will then pick the next highest LS sequence number and 9633 reflood, overwriting the MaxAge instance. 9635 F.5 Introduction of the MinLSArrival constant 9637 OSPF limits the frequency that new instances of any particular 9638 LSA can be accepted during flooding. This is extra protection, 9639 just in case a neighboring router is violating the mandated 9640 limit on LSA (re)originations (namely, one per LSA in any 9641 MinLSInterval). 9643 In RFC 1583, the frequency at which new LSA instances were 9644 accepted was also set equal to once every MinLSInterval seconds. 9645 However, in some circumstances this led to unwanted link state 9646 retransmissions, even when the LSA originator was obeying the 9647 MinLSInterval limit on originations. This was due to either 1) 9648 choice of clock granularity in some OSPF implementations or 2) 9649 differing clock speed in neighboring routers. 9651 To alleviate this problem, the frequency at which new LSA 9652 instances are accepted during flooding has now been increased to 9653 once every MinLSArrival seconds, whose value is set to 1. This 9654 change is reflected in Steps 5a and 5d of Section 13, and in 9655 Appendix B. 9657 F.6 Optionally advertising point-to-point links as subnets 9659 When describing a point-to-point interface in its router-LSA, a 9660 router may now advertise a stub link to the point-to-point 9661 network's subnet. This is specified as an alternative to the RFC 9662 1583 behavior, which is to advertise a stub link to the 9663 neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for 9664 details. 9666 Security Considerations 9668 All OSPF protocol exchanges are authenticated. OSPF supports 9669 multiple types of authentication; the type of authentication in use 9670 can be configured on a per network segment basis. One of OSPF's 9671 authentication types, namely the Cryptographic authentication 9672 option, is believed to be secure against active and passive attacks. 9673 When using the Cryptographic authentication option, each router 9674 appends a "message digest" to its transmitted OSPF packets. 9675 Receivers then use the shared secret key and received digest to 9676 verify that each received OSPF packet is authentic. 9678 The quality of the security provided by the Cryptographic 9679 authentication option depends completely on the strength of the 9680 message digest algorithm (MD5 is currently the only message digest 9681 algorithm specified), the strength of the key being used, and the 9682 correct implementation of the security mechanism in all 9683 communicating OSPF implementations. It also requires that all 9684 parties maintain the secrecy of the shared secret key. 9686 None of the OSPF authentication types provide confidentiality. Nor 9687 do they protect against traffic analysis. Key management is also not 9688 addressed by this memo. 9690 For more information, see Sections 8.1, 8.2, and Appendix D. 9692 Author's Address 9694 John Moy 9695 Cascade Communications Corp. 9696 5 Carlisle Road 9697 Westford, MA 01886 9699 Phone: 508-692-2600 Ext. 394 9700 Fax: 508-692-9214 9701 Email: jmoy@casc.com 9703 This document expires in December 1995.