idnits 2.17.1 draft-ietf-ospf-version2-10.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-19) 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 7646 instances of lines with control characters in the document. == There are 49 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1383 has weird spacing: '... dist from ...' == Line 1681 has weird spacing: '... Packet name ...' == Line 1683 has weird spacing: '...aintain neigh...' == Line 1714 has weird spacing: '... type name...' == Line 2438 has weird spacing: '...virtual link....' == (13 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1997) is 9925 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1563 -- Looks like a reference, but probably isn't: '2' on line 2407 -- Looks like a reference, but probably isn't: '3' on line 2438 -- Looks like a reference, but probably isn't: '4' on line 2748 -- Looks like a reference, but probably isn't: '5' on line 3051 -- Looks like a reference, but probably isn't: '6' on line 3106 -- Looks like a reference, but probably isn't: '7' on line 3986 -- Looks like a reference, but probably isn't: '8' on line 4056 -- Looks like a reference, but probably isn't: '9' on line 4325 -- Looks like a reference, but probably isn't: '10' on line 4445 -- Looks like a reference, but probably isn't: '11' on line 4475 -- Looks like a reference, but probably isn't: '12' on line 4689 -- Looks like a reference, but probably isn't: '13' on line 4883 -- Looks like a reference, but probably isn't: '14' on line 4907 -- Looks like a reference, but probably isn't: '15' on line 5257 -- Looks like a reference, but probably isn't: '16' on line 5264 -- Looks like a reference, but probably isn't: '17' on line 5519 -- Looks like a reference, but probably isn't: '18' on line 5523 -- Looks like a reference, but probably isn't: '19' on line 6027 -- Looks like a reference, but probably isn't: '20' on line 6110 -- Looks like a reference, but probably isn't: '21' on line 6366 -- Looks like a reference, but probably isn't: '22' on line 6455 -- Looks like a reference, but probably isn't: '23' on line 6566 -- Looks like a reference, but probably isn't: '24' on line 6580 -- Looks like a reference, but probably isn't: '25' on line 6669 -- Looks like a reference, but probably isn't: '26' on line 7092 == Missing Reference: 'NA' is mentioned on line 9373, but not defined == Missing Reference: 'NM1' is mentioned on line 9370, but not defined == Missing Reference: 'NM2' is mentioned on line 9373, but not defined == Unused Reference: 'Ref19' is defined on line 7731, but no explicit reference was found in the text == Unused Reference: 'NA,NM1' is defined on line 9364, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref4' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref5' ** Downref: Normative reference to an Unknown state RFC: RFC 905 (ref. 'Ref6') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref7' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref8' ** Obsolete normative reference: RFC 1583 (ref. 'Ref9') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 1519 (ref. 'Ref10') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1700 (ref. 'Ref11') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref12' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref13' ** Obsolete normative reference: RFC 1293 (ref. 'Ref14') (Obsoleted by RFC 2390) ** Downref: Normative reference to an Informational RFC: RFC 1586 (ref. 'Ref15') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref16' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref17' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'Ref18') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref19' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref20' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref22' ** Obsolete normative reference: RFC 1771 (ref. 'Ref23') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'NA,NM1' Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 44 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy 3 Internet Draft Cascade Communications Corp. 4 Expiration Date: August 1997 February 1997 5 File name: draft-ietf-ospf-version2-10.txt 7 OSPF Version 2 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This memo documents version 2 of the OSPF protocol. OSPF is a 30 link-state routing protocol. It is designed to be run internal to a 31 single Autonomous System. Each OSPF router maintains an identical 32 database describing the Autonomous System's topology. From this 33 database, a routing table is calculated by constructing a shortest- 34 path tree. 36 OSPF recalculates routes quickly in the face of topological changes, 37 utilizing a minimum of routing protocol traffic. OSPF provides 38 support for equal-cost multipath. Separate routes can be calculated 39 for each IP Type of Service. An area routing capability is 40 provided, enabling an additional level of routing protection and a 41 reduction in routing protocol traffic. In addition, all OSPF 42 routing protocol exchanges are authenticated. 44 The differences between this memo and RFC 1583 are explained in 45 Appendix G. All differences are backward-compatible in nature. 46 Implementations of this memo and of RFC 1583 will interoperate. 48 Please send comments to ospf@gated.cornell.edu. 50 Table of Contents 52 1 Introduction ........................................... 7 53 1.1 Protocol Overview ...................................... 7 54 1.2 Definitions of commonly used terms ..................... 8 55 1.3 Brief history of link-state routing technology ........ 11 56 1.4 Organization of this document ......................... 12 57 1.5 Acknowledgments ....................................... 13 58 2 The link-state database: organization and calculations 13 59 2.1 Representation of routers and networks ................ 13 60 2.1.1 Representation of non-broadcast networks .............. 15 61 2.1.2 An example link-state database ........................ 16 62 2.2 The shortest-path tree ................................ 20 63 2.3 Use of external routing information ................... 22 64 2.4 Equal-cost multipath .................................. 24 65 2.5 TOS-based routing ..................................... 25 66 3 Splitting the AS into Areas ........................... 25 67 3.1 The backbone of the Autonomous System ................. 26 68 3.2 Inter-area routing .................................... 27 69 3.3 Classification of routers ............................. 27 70 3.4 A sample area configuration ........................... 28 71 3.5 IP subnetting support ................................. 34 72 3.6 Supporting stub areas ................................. 35 73 3.7 Partitions of areas ................................... 36 74 4 Functional Summary .................................... 38 75 4.1 Inter-area routing .................................... 38 76 4.2 AS external routes .................................... 39 77 4.3 Routing protocol packets .............................. 39 78 4.4 Basic implementation requirements ..................... 42 79 4.5 Optional OSPF capabilities ............................ 43 80 5 Protocol data structures .............................. 44 81 6 The Area Data Structure ............................... 46 82 7 Bringing Up Adjacencies ............................... 49 83 7.1 The Hello Protocol .................................... 49 84 7.2 The Synchronization of Databases ...................... 50 85 7.3 The Designated Router ................................. 51 86 7.4 The Backup Designated Router .......................... 52 87 7.5 The graph of adjacencies .............................. 53 88 8 Protocol Packet Processing ............................ 53 89 8.1 Sending protocol packets .............................. 54 90 8.2 Receiving protocol packets ............................ 56 91 9 The Interface Data Structure .......................... 59 92 9.1 Interface states ...................................... 62 93 9.2 Events causing interface state changes ................ 64 94 9.3 The Interface state machine ........................... 66 95 9.4 Electing the Designated Router ........................ 68 96 9.5 Sending Hello packets ................................. 71 97 9.5.1 Sending Hello packets on NBMA networks ................ 72 98 10 The Neighbor Data Structure ........................... 73 99 10.1 Neighbor states ....................................... 75 100 10.2 Events causing neighbor state changes ................. 79 101 10.3 The Neighbor state machine ............................ 80 102 10.4 Whether to become adjacent ............................ 86 103 10.5 Receiving Hello Packets ............................... 87 104 10.6 Receiving Database Description Packets ................ 89 105 10.7 Receiving Link State Request Packets .................. 92 106 10.8 Sending Database Description Packets .................. 93 107 10.9 Sending Link State Request Packets .................... 94 108 10.10 An Example ............................................ 95 109 11 The Routing Table Structure ........................... 95 110 11.1 Routing table lookup ................................. 100 111 11.2 Sample routing table, without areas .................. 101 112 11.3 Sample routing table, with areas ..................... 102 113 12 Link State Advertisements (LSAs) ..................... 103 114 12.1 The LSA Header ....................................... 105 115 12.1.1 LS age ............................................... 105 116 12.1.2 Options .............................................. 106 117 12.1.3 LS type .............................................. 107 118 12.1.4 Link State ID ........................................ 108 119 12.1.5 Advertising Router ................................... 109 120 12.1.6 LS sequence number ................................... 109 121 12.1.7 LS checksum .......................................... 110 122 12.2 The link state database .............................. 110 123 12.3 Representation of TOS ................................ 111 124 12.4 Originating LSAs ..................................... 112 125 12.4.1 Router-LSAs .......................................... 115 126 12.4.1.1 Describing point-to-point interfaces ................. 118 127 12.4.1.2 Describing broadcast and NBMA interfaces ............. 119 128 12.4.1.3 Describing virtual links ............................. 119 129 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 120 130 12.4.1.5 Examples of router-LSAs .............................. 120 131 12.4.2 Network-LSAs ......................................... 122 132 12.4.2.1 Examples of network-LSAs ............................. 123 133 12.4.3 Summary-LSAs ......................................... 123 134 12.4.3.1 Originating summary-LSAs into stub areas ............. 126 135 12.4.3.2 Examples of summary-LSAs ............................. 127 136 12.4.4 AS-external-LSAs ..................................... 128 137 12.4.4.1 Examples of AS-external-LSAs ......................... 128 138 13 The Flooding Procedure ............................... 130 139 13.1 Determining which LSA is newer ....................... 134 140 13.2 Installing LSAs in the database ...................... 134 141 13.3 Next step in the flooding procedure .................. 135 142 13.4 Receiving self-originated LSAs ....................... 138 143 13.5 Sending Link State Acknowledgment packets ............ 139 144 13.6 Retransmitting LSAs .................................. 141 145 13.7 Receiving link state acknowledgments ................. 142 146 14 Aging The Link State Database ........................ 142 147 14.1 Premature aging of LSAs .............................. 143 148 15 Virtual Links ........................................ 144 149 16 Calculation of the routing table ..................... 146 150 16.1 Calculating the shortest-path tree for an area ....... 147 151 16.1.1 The next hop calculation ............................. 152 152 16.2 Calculating the inter-area routes .................... 153 153 16.3 Examining transit areas' summary-LSAs ................ 155 154 16.4 Calculating AS external routes ....................... 157 155 16.4.1 External path preferences ............................ 159 156 16.5 Incremental updates -- summary-LSAs .................. 160 157 16.6 Incremental updates -- AS-external-LSAs .............. 161 158 16.7 Events generated as a result of routing table changes 161 159 16.8 Equal-cost multipath ................................. 162 160 16.9 Building the non-zero-TOS portion of the routing table 162 161 Footnotes ............................................ 165 162 References ........................................... 169 163 A OSPF data formats .................................... 171 164 A.1 Encapsulation of OSPF packets ........................ 171 165 A.2 The Options field .................................... 173 166 A.3 OSPF Packet Formats .................................. 175 167 A.3.1 The OSPF packet header ............................... 176 168 A.3.2 The Hello packet ..................................... 178 169 A.3.3 The Database Description packet ...................... 180 170 A.3.4 The Link State Request packet ........................ 182 171 A.3.5 The Link State Update packet ......................... 184 172 A.3.6 The Link State Acknowledgment packet ................. 186 173 A.4 LSA formats .......................................... 188 174 A.4.1 The LSA header ....................................... 189 175 A.4.2 Router-LSAs .......................................... 191 176 A.4.3 Network-LSAs ......................................... 195 177 A.4.4 Summary-LSAs ......................................... 196 178 A.4.5 AS-external-LSAs ..................................... 198 179 B Architectural Constants .............................. 200 180 C Configurable Constants ............................... 202 181 C.1 Global parameters .................................... 202 182 C.2 Area parameters ...................................... 203 183 C.3 Router interface parameters .......................... 204 184 C.4 Virtual link parameters .............................. 206 185 C.5 NBMA network parameters .............................. 207 186 C.6 Point-to-MultiPoint network parameters ............... 208 187 C.7 Host route parameters ................................ 208 188 D Authentication ....................................... 209 189 D.1 Null authentication .................................. 209 190 D.2 Simple password authentication ....................... 209 191 D.3 Cryptographic authentication ......................... 210 192 D.4 Message generation ................................... 212 193 D.4.1 Generating Null authentication ....................... 213 194 D.4.2 Generating Simple password authentication ............ 213 195 D.4.3 Generating Cryptographic authentication .............. 213 196 D.5 Message verification ................................. 215 197 D.5.1 Verifying Null authentication ........................ 215 198 D.5.2 Verifying Simple password authentication ............. 215 199 D.5.3 Verifying Cryptographic authentication ............... 215 200 E An algorithm for assigning Link State IDs ............ 217 201 F Multiple interfaces to the same network/subnet ....... 219 202 G Differences from RFC 1583 ............................ 220 203 G.1 Enhancements to OSPF authentication .................. 220 204 G.2 Addition of Point-to-MultiPoint interface ............ 220 205 G.3 Support for overlapping area ranges .................. 221 206 G.4 A modification to the flooding algorithm ............. 222 207 G.5 Introduction of the MinLSArrival constant ............ 222 208 G.6 Optionally advertising point-to-point links as subnets 223 209 G.7 Advertising same external route from multiple areas .. 223 210 G.8 Retransmission of initial Database Description packets 225 211 G.9 Detecting interface MTU mismatches ................... 225 212 Security Considerations .............................. 226 213 Author's Address ..................................... 226 214 1. Introduction 216 This document is a specification of the Open Shortest Path First 217 (OSPF) TCP/IP internet routing protocol. OSPF is classified as an 218 Interior Gateway Protocol (IGP). This means that it distributes 219 routing information between routers belonging to a single Autonomous 220 System. The OSPF protocol is based on link-state or SPF technology. 221 This is a departure from the Bellman-Ford base used by traditional 222 TCP/IP internet routing protocols. 224 The OSPF protocol was developed by the OSPF working group of the 225 Internet Engineering Task Force. It has been designed expressly for 226 the TCP/IP internet environment, including explicit support for IP 227 subnetting, TOS-based routing and the tagging of externally-derived 228 routing information. OSPF also provides for the authentication of 229 routing updates, and utilizes IP multicast when sending/receiving 230 the updates. In addition, much work has been done to produce a 231 protocol that responds quickly to topology changes, yet involves 232 small amounts of routing protocol traffic. 234 1.1. Protocol overview 236 OSPF routes IP packets based solely on the destination IP 237 address and IP Type of Service found in the IP packet header. 238 IP packets are routed "as is" -- they are not encapsulated in 239 any further protocol headers as they transit the Autonomous 240 System. OSPF is a dynamic routing protocol. It quickly detects 241 topological changes in the AS (such as router interface 242 failures) and calculates new loop-free routes after a period of 243 convergence. This period of convergence is short and involves a 244 minimum of routing traffic. 246 In a link-state routing protocol, each router maintains a 247 database describing the Autonomous System's topology. This 248 database is referred to as the link-state database. Each 249 participating router has an identical database. Each individual 250 piece of this database is a particular router's local state 251 (e.g., the router's usable interfaces and reachable neighbors). 252 The router distributes its local state throughout the Autonomous 253 System by flooding. 255 All routers run the exact same algorithm, in parallel. From the 256 link-state database, each router constructs a tree of shortest 257 paths with itself as root. This shortest-path tree gives the 258 route to each destination in the Autonomous System. Externally 259 derived routing information appears on the tree as leaves. 261 OSPF calculates separate routes for each Type of Service (TOS). 263 When several equal-cost routes to a destination exist, traffic 264 is distributed equally among them. The cost of a route is 265 described by a single dimensionless metric. 267 OSPF allows sets of networks to be grouped together. Such a 268 grouping is called an area. The topology of an area is hidden 269 from the rest of the Autonomous System. This information hiding 270 enables a significant reduction in routing traffic. Also, 271 routing within the area is determined only by the area's own 272 topology, lending the area protection from bad routing data. An 273 area is a generalization of an IP subnetted network. 275 OSPF enables the flexible configuration of IP subnets. Each 276 route distributed by OSPF has a destination and mask. Two 277 different subnets of the same IP network number may have 278 different sizes (i.e., different masks). This is commonly 279 referred to as variable length subnetting. A packet is routed 280 to the best (i.e., longest or most specific) match. Host routes 281 are considered to be subnets whose masks are "all ones" 282 (0xffffffff). 284 All OSPF protocol exchanges are authenticated. This means that 285 only trusted routers can participate in the Autonomous System's 286 routing. A variety of authentication schemes can be used; in 287 fact, separate authentication schemes can be configured for each 288 IP subnet. 290 Externally derived routing data (e.g., routes learned from an 291 Exterior Gateway Protocol such as BGP; see [Ref23]) is 292 advertised throughout the Autonomous System. This externally 293 derived data is kept separate from the OSPF protocol's link 294 state data. Each external route can also be tagged by the 295 advertising router, enabling the passing of additional 296 information between routers on the boundary of the Autonomous 297 System. 299 1.2. Definitions of commonly used terms 301 This section provides definitions for terms that have a specific 302 meaning to the OSPF protocol and that are used throughout the 303 text. The reader unfamiliar with the Internet Protocol Suite is 304 referred to [Ref13] for an introduction to IP. 306 Router 307 A level three Internet Protocol packet switch. Formerly 308 called a gateway in much of the IP literature. 310 Autonomous System 311 A group of routers exchanging routing information via a 312 common routing protocol. Abbreviated as AS. 314 Interior Gateway Protocol 315 The routing protocol spoken by the routers belonging to an 316 Autonomous system. Abbreviated as IGP. Each Autonomous 317 System has a single IGP. Separate Autonomous Systems may be 318 running different IGPs. 320 Router ID 321 A 32-bit number assigned to each router running the OSPF 322 protocol. This number uniquely identifies the router within 323 an Autonomous System. 325 Network 326 In this memo, an IP network/subnet/supernet. It is possible 327 for one physical network to be assigned multiple IP 328 network/subnet numbers. We consider these to be separate 329 networks. Point-to-point physical networks are an exception 330 - they are considered a single network no matter how many 331 (if any at all) IP network/subnet numbers are assigned to 332 them. 334 Network mask 335 A 32-bit number indicating the range of IP addresses 336 residing on a single IP network/subnet/supernet. This 337 specification displays network masks as hexadecimal numbers. 338 For example, the network mask for a class C IP network is 339 displayed as 0xffffff00. Such a mask is often displayed 340 elsewhere in the literature as 255.255.255.0. 342 Point-to-point networks 343 A network that joins a single pair of routers. A 56Kb 344 serial line is an example of a point-to-point network. 346 Broadcast networks 347 Networks supporting many (more than two) attached routers, 348 together with the capability to address a single physical 349 message to all of the attached routers (broadcast). 350 Neighboring routers are discovered dynamically on these nets 351 using OSPF's Hello Protocol. The Hello Protocol itself 352 takes advantage of the broadcast capability. The OSPF 353 protocol makes further use of multicast capabilities, if 354 they exist. Each pair of routers on a broadcast network is 355 assumed to be able to communicate directly. An ethernet is 356 an example of a broadcast network. 358 Non-broadcast networks 359 Networks supporting many (more than two) routers, but having 360 no broadcast capability. Neighboring routers are maintained 361 on these nets using OSPF's Hello Protocol. However, due to 362 the lack of broadcast capability, some configuration 363 information may be necessary to aid in the discovery of 364 neighbors. On non-broadcast networks, OSPF protocol packets 365 that are normally multicast need to be sent to each 366 neighboring router, in turn. An X.25 Public Data Network 367 (PDN) is an example of a non-broadcast network. 369 OSPF runs in one of two modes over non-broadcast networks. 370 The first mode, called non-broadcast multi-access or NBMA, 371 simulates the operation of OSPF on a broadcast network. The 372 second mode, called Point-to-MultiPoint, treats the non- 373 broadcast network as a collection of point-to-point links. 374 Non-broadcast networks are referred to as NBMA networks or 375 Point-to-MultiPoint networks, depending on OSPF's mode of 376 operation over the network. 378 Interface 379 The connection between a router and one of its attached 380 networks. An interface has state information associated 381 with it, which is obtained from the underlying lower level 382 protocols and the routing protocol itself. An interface to 383 a network has associated with it a single IP address and 384 mask (unless the network is an unnumbered point-to-point 385 network). An interface is sometimes also referred to as a 386 link. 388 Neighboring routers 389 Two routers that have interfaces to a common network. 390 Neighbor relationships are maintained by, and usually 391 dynamically discovered by, OSPF's Hello Protocol. 393 Adjacency 394 A relationship formed between selected neighboring routers 395 for the purpose of exchanging routing information. Not 396 every pair of neighboring routers become adjacent. 398 Link state advertisement 399 Unit of data describing the local state of a router or 400 network. For a router, this includes the state of the 401 router's interfaces and adjacencies. Each link state 402 advertisement is flooded throughout the routing domain. The 403 collected link state advertisements of all routers and 404 networks forms the protocol's link state database. 405 Throughout this memo, link state advertisement is 406 abbreviated as LSA. 408 Hello Protocol 409 The part of the OSPF protocol used to establish and maintain 410 neighbor relationships. On broadcast networks the Hello 411 Protocol can also dynamically discover neighboring routers. 413 Flooding 414 The part of the OSPF protocol that distributes and 415 synchronizes the link-state database between OSPF routers. 417 Designated Router 418 Each broadcast and NBMA network that has at least two 419 attached routers has a Designated Router. The Designated 420 Router generates an LSA for the network and has other 421 special responsibilities in the running of the protocol. 422 The Designated Router is elected by the Hello Protocol. 424 The Designated Router concept enables a reduction in the 425 number of adjacencies required on a broadcast or NBMA 426 network. This in turn reduces the amount of routing 427 protocol traffic and the size of the link-state database. 429 Lower-level protocols 430 The underlying network access protocols that provide 431 services to the Internet Protocol and in turn the OSPF 432 protocol. Examples of these are the X.25 packet and frame 433 levels for X.25 PDNs, and the ethernet data link layer for 434 ethernets. 436 1.3. Brief history of link-state routing technology 438 OSPF is a link state routing protocol. Such protocols are also 439 referred to in the literature as SPF-based or distributed- 440 database protocols. This section gives a brief description of 441 the developments in link-state technology that have influenced 442 the OSPF protocol. 444 The first link-state routing protocol was developed for use in 445 the ARPANET packet switching network. This protocol is 446 described in [Ref3]. It has formed the starting point for all 447 other link-state protocols. The homogeneous ARPANET 448 environment, i.e., single-vendor packet switches connected by 449 synchronous serial lines, simplified the design and 450 implementation of the original protocol. 452 Modifications to this protocol were proposed in [Ref4]. These 453 modifications dealt with increasing the fault tolerance of the 454 routing protocol through, among other things, adding a checksum 455 to the LSAs (thereby detecting database corruption). The paper 456 also included means for reducing the routing traffic overhead in 457 a link-state protocol. This was accomplished by introducing 458 mechanisms which enabled the interval between LSA originations 459 to be increased by an order of magnitude. 461 A link-state algorithm has also been proposed for use as an ISO 462 IS-IS routing protocol. This protocol is described in [Ref2]. 463 The protocol includes methods for data and routing traffic 464 reduction when operating over broadcast networks. This is 465 accomplished by election of a Designated Router for each 466 broadcast network, which then originates an LSA for the network. 468 The OSPF Working Group of the IETF has extended this work in 469 developing the OSPF protocol. The Designated Router concept has 470 been greatly enhanced to further reduce the amount of routing 471 traffic required. Multicast capabilities are utilized for 472 additional routing bandwidth reduction. An area routing scheme 473 has been developed enabling information 474 hiding/protection/reduction. Finally, the algorithms have been 475 tailored for efficient operation in TCP/IP internets. 477 1.4. Organization of this document 479 The first three sections of this specification give a general 480 overview of the protocol's capabilities and functions. Sections 481 4-16 explain the protocol's mechanisms in detail. Packet 482 formats, protocol constants and configuration items are 483 specified in the appendices. 485 Labels such as HelloInterval encountered in the text refer to 486 protocol constants. They may or may not be configurable. 487 Architectural constants are summarized in Appendix B. 488 Configurable constants are summarized in Appendix C. 490 The detailed specification of the protocol is presented in terms 491 of data structures. This is done in order to make the 492 explanation more precise. Implementations of the protocol are 493 required to support the functionality described, but need not 494 use the precise data structures that appear in this memo. 496 1.5. Acknowledgments 498 The author would like to thank Ran Atkinson, Fred Baker, Jeffrey 499 Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra 500 Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui 501 Zhang and the rest of the OSPF Working Group for the ideas and 502 support they have given to this project. 504 The OSPF Point-to-MultiPoint interface is based on work done by 505 Fred Baker. 507 The OSPF Cryptographic Authentication option was developed by 508 Fred Baker and Ran Atkinson. 510 2. The Link-state Database: organization and calculations 512 The following subsections describe the organization of OSPF's link- 513 state database, and the routing calculations that are performed on 514 the database in order to produce a router's routing table. 516 2.1. Representation of routers and networks 518 The Autonomous System's link-state database describes a directed 519 graph. The vertices of the graph consist of routers and 520 networks. A graph edge connects two routers when they are 521 attached via a physical point-to-point network. An edge 522 connecting a router to a network indicates that the router has 523 an interface on the network. Networks can be either transit or 524 stub networks. Transit networks are those capable of carrying 525 data traffic that is neither locally originated nor locally 526 destined. A transit network is represented by a graph vertex 527 having both incoming and outgoing edges. A stub network's vertex 528 has only incoming edges. 530 The neighborhood of each network node in the graph depends on 531 the network's type (point-to-point, broadcast, NBMA or Point- 532 to-MultiPoint) and the number of routers having an interface to 533 the network. Three cases are depicted in Figure 1a. Rectangles 534 indicate routers. Circles and oblongs indicate networks. 535 Router names are prefixed with the letters RT and network names 536 with the letter N. Router interface names are prefixed by the 537 letter I. Lines between routers indicate point-to-point 538 networks. The left side of the figure shows networks with their 539 connected routers, with the resulting graphs shown on the right. 541 **FROM** 543 * |RT1|RT2| 544 +---+Ia +---+ * ------------ 545 |RT1|------|RT2| T RT1| | X | 546 +---+ Ib+---+ O RT2| X | | 547 * Ia| | X | 548 * Ib| X | | 550 Physical point-to-point networks 552 **FROM** 553 +---+ * 554 |RT7| * |RT7| N3| 555 +---+ T ------------ 556 | O RT7| | | 557 +----------------------+ * N3| X | | 558 N3 * 560 Stub networks 562 **FROM** 563 +---+ +---+ 564 |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | 565 +---+ +---+ * ------------------------ 566 | N2 | * RT3| | | | | X | 567 +----------------------+ T RT4| | | | | X | 568 | | O RT5| | | | | X | 569 +---+ +---+ * RT6| | | | | X | 570 |RT5| |RT6| * N2| X | X | X | X | | 571 +---+ +---+ 573 Broadcast or NBMA networks 575 Figure 1a: Network map components 577 Networks and routers are represented by vertices. 578 An edge connects Vertex A to Vertex B iff the 579 intersection of Column A and Row B is marked with 580 an X. 582 The top of Figure 1a shows two routers connected by a point-to- 583 point link. In the resulting link-state database graph, the two 584 router vertices are directly connected by a pair of edges, one 585 in each direction. Interfaces to point-to-point networks need 586 not be assigned IP addresses. When interface addresses are 587 assigned, they are modelled as stub links, with each router 588 advertising a stub connection to the other router's interface 589 address. Optionally, an IP subnet can be assigned to the point- 590 to-point network. In this case, both routers advertise a stub 591 link to the IP subnet, instead of advertising each others' IP 592 interface addresses. 594 The middle of Figure 1a shows a network with only one attached 595 router (i.e., a stub network). In this case, the network appears 596 on the end of a stub connection in the link-state database's 597 graph. 599 When multiple routers are attached to a broadcast network, the 600 link-state database graph shows all routers bidirectionally 601 connected to the network vertex. This is pictured at the bottom 602 of Figure 1a. 604 Each network (stub or transit) in the graph has an IP address 605 and associated network mask. The mask indicates the number of 606 nodes on the network. Hosts attached directly to routers 607 (referred to as host routes) appear on the graph as stub 608 networks. The network mask for a host route is always 609 0xffffffff, which indicates the presence of a single node. 611 2.1.1. Representation of non-broadcast networks 613 As mentioned previously, OSPF can run over non-broadcast 614 networks in one of two modes: NBMA or Point-to-MultiPoint. 615 The choice of mode determines the way that the Hello 616 protocol and flooding work over the non-broadcast network, 617 and the way that the network is represented in the link- 618 state database. 620 In NBMA mode, OSPF emulates operation over a broadcast 621 network: a Designated Router is elected for the NBMA 622 network, and the Designated Router originates an LSA for the 623 network. The graph representation for broadcast networks and 624 NBMA networks is identical. This representation is pictured 625 in the middle of Figure 1a. 627 NBMA mode is the most efficient way to run OSPF over non- 628 broadcast networks, both in terms of link-state database 629 size and in terms of the amount of routing protocol traffic. 630 However, it has one significant restriction: it requires all 631 routers attached to the NBMA network to be able to 632 communicate directly. This restriction may be met on some 633 non-broadcast networks, such as an ATM subnet utilizing 634 SVCs. But it is often not met on other non-broadcast 635 networks, such as PVC-only Frame Relay networks. On non- 636 broadcast networks where not all routers can communicate 637 directly you can break the non-broadcast network into 638 logical subnets, with the routers on each subnet being able 639 to communicate directly, and then run each separate subnet 640 as an NBMA network (see [Ref15]). This however requires 641 quite a bit of administrative overhead, and is prone to 642 misconfiguration. It is probably better to run such a non- 643 broadcast network in Point-to-Multipoint mode. 645 In Point-to-MultiPoint mode, OSPF treats all router-to- 646 router connections over the non-broadcast network as if they 647 were point-to-point links. No Designated Router is elected 648 for the network, nor is there an LSA generated for the 649 network. In fact, a vertex for the Point-to-MultiPoint 650 network does not appear in the graph of the link-state 651 database. 653 Figure 1b illustrates the link-state database representation 654 of a Point-to-MultiPoint network. On the left side of the 655 figure, a Point-to-MultiPoint network is pictured. It is 656 assumed that all routers can communicate directly, except 657 for routers RT4 and RT5. I3 though I6 indicate the routers' 658 IP interface addresses on the Point-to-MultiPoint network. 659 In the graphical representation of the link-state database, 660 routers that can communicate directly over the Point-to- 661 MultiPoint network are joined by bidirectional edges, and 662 each router also has a stub connection to its own IP 663 interface address (which is in contrast to the 664 representation of real point-to-point links; see Figure 1a). 666 On some non-broadcast networks, use of Point-to-MultiPoint 667 mode and data-link protocols such as Inverse ARP (see 668 [Ref14]) will allow autodiscovery of OSPF neighbors even 669 though broadcast support is not available. 671 2.1.2. An example link-state database 673 Figure 2 shows a sample map of an Autonomous System. The 674 rectangle labelled H1 indicates a host, which has a SLIP 675 **FROM** 676 +---+ +---+ 677 |RT3| |RT4| |RT3|RT4|RT5|RT6| 678 +---+ +---+ * -------------------- 679 I3| N2 |I4 * RT3| | X | X | X | 680 +----------------------+ T RT4| X | | | X | 681 I5| |I6 O RT5| X | | | X | 682 +---+ +---+ * RT6| X | X | X | | 683 |RT5| |RT6| * I3| X | | | | 684 +---+ +---+ I4| | X | | | 685 I5| | | X | | 686 I6| | | | X | 688 Figure 1b: Network map components 689 Point-to-MultiPoint networks 691 All routers can communicate directly over N2, except 692 routers RT4 and RT5. I3 through I6 indicate IP 693 interface addresses 695 connection to Router RT12. Router RT12 is therefore 696 advertising a host route. Lines between routers indicate 697 physical point-to-point networks. The only point-to-point 698 network that has been assigned interface addresses is the 699 one joining Routers RT6 and RT10. Routers RT5 and RT7 have 700 BGP connections to other Autonomous Systems. A set of BGP- 701 learned routes have been displayed for both of these 702 routers. 704 A cost is associated with the output side of each router 705 interface. This cost is configurable by the system 706 administrator. The lower the cost, the more likely the 707 interface is to be used to forward data traffic. Costs are 708 also associated with the externally derived routing data 709 (e.g., the BGP-learned routes). 711 The directed graph resulting from the map in Figure 2 is 712 depicted in Figure 3. Arcs are labelled with the cost of 713 the corresponding router output interface. Arcs having no 714 labelled cost have a cost of 0. Note that arcs leading from 715 networks to routers always have cost 0; they are significant 716 nonetheless. Note also that the externally derived routing 717 data appears on the graph as stubs. 719 + 720 | 3+---+ N12 N14 721 N1|--|RT1|\ 1 \ N13 / 722 | +---+ \ 8\ |8/8 723 + \ ____ \|/ 724 / \ 1+---+8 8+---+6 725 * N3 *---|RT4|------|RT5|--------+ 726 \____/ +---+ +---+ | 727 + / | |7 | 728 | 3+---+ / | | | 729 N2|--|RT2|/1 |1 |6 | 730 | +---+ +---+8 6+---+ | 731 + |RT3|--------------|RT6| | 732 +---+ +---+ | 733 |2 Ia|7 | 734 | | | 735 +---------+ | | 736 N4 | | 737 | | 738 | | 739 N11 | | 740 +---------+ | | 741 | | | N12 742 |3 | |6 2/ 743 +---+ | +---+/ 744 |RT9| | |RT7|---N15 745 +---+ | +---+ 9 746 |1 + | |1 747 _|__ | Ib|5 __|_ 748 / \ 1+----+2 | 3+----+1 / \ 749 * N9 *------|RT11|----|---|RT10|---* N6 * 750 \____/ +----+ | +----+ \____/ 751 | | | 752 |1 + |1 753 +--+ 10+----+ N8 +---+ 754 |H1|-----|RT12| |RT8| 755 +--+SLIP +----+ +---+ 756 |2 |4 757 | | 758 +---------+ +--------+ 759 N10 N7 761 Figure 2: A sample Autonomous System 762 **FROM** 764 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| 765 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| 766 ----- --------------------------------------------- 767 RT1| | | | | | | | | | | | |0 | | | | 768 RT2| | | | | | | | | | | | |0 | | | | 769 RT3| | | | | |6 | | | | | | |0 | | | | 770 RT4| | | | |8 | | | | | | | |0 | | | | 771 RT5| | | |8 | |6 |6 | | | | | | | | | | 772 RT6| | |8 | |7 | | | | |5 | | | | | | | 773 RT7| | | | |6 | | | | | | | | |0 | | | 774 * RT8| | | | | | | | | | | | | |0 | | | 775 * RT9| | | | | | | | | | | | | | | |0 | 776 T RT10| | | | | |7 | | | | | | | |0 |0 | | 777 O RT11| | | | | | | | | | | | | | |0 |0 | 778 * RT12| | | | | | | | | | | | | | | |0 | 779 * N1|3 | | | | | | | | | | | | | | | | 780 N2| |3 | | | | | | | | | | | | | | | 781 N3|1 |1 |1 |1 | | | | | | | | | | | | | 782 N4| | |2 | | | | | | | | | | | | | | 783 N6| | | | | | |1 |1 | |1 | | | | | | | 784 N7| | | | | | | |4 | | | | | | | | | 785 N8| | | | | | | | | |3 |2 | | | | | | 786 N9| | | | | | | | |1 | |1 |1 | | | | | 787 N10| | | | | | | | | | | |2 | | | | | 788 N11| | | | | | | | |3 | | | | | | | | 789 N12| | | | |8 | |2 | | | | | | | | | | 790 N13| | | | |8 | | | | | | | | | | | | 791 N14| | | | |8 | | | | | | | | | | | | 792 N15| | | | | | |9 | | | | | | | | | | 793 H1| | | | | | | | | | | |10| | | | | 795 Figure 3: The resulting directed graph 797 Networks and routers are represented by vertices. 798 An edge of cost X connects Vertex A to Vertex B iff 799 the intersection of Column A and Row B is marked 800 with an X. 802 The link-state database is pieced together from LSAs 803 generated by the routers. In the associated graphical 804 representation, the neighborhood of each router or transit 805 network is represented in a single, separate LSA. Figure 4 806 shows these LSAs graphically. Router RT12 has an interface 807 to two broadcast networks and a SLIP line to a host. 808 Network N6 is a broadcast network with three attached 809 routers. The cost of all links from Network N6 to its 810 attached routers is 0. Note that the LSA for Network N6 is 811 actually generated by one of the network's attached routers: 812 the router that has been elected Designated Router for the 813 network. 815 2.2. The shortest-path tree 817 When no OSPF areas are configured, each router in the Autonomous 818 System has an identical link-state database, leading to an 819 identical graphical representation. A router generates its 820 routing table from this graph by calculating a tree of shortest 821 paths with the router itself as root. Obviously, the shortest- 822 path tree depends on the router doing the calculation. The 823 shortest-path tree for Router RT6 in our example is depicted in 824 Figure 5. 826 The tree gives the entire path to any destination network or 827 host. However, only the next hop to the destination is used in 828 the forwarding process. Note also that the best route to any 829 router has also been calculated. For the processing of external 830 data, we note the next hop and distance to any router 831 advertising external routes. The resulting routing table for 832 Router RT6 is pictured in Table 2. Note that there is a 833 separate route for each end of a numbered point-to-point network 834 (in this case, the serial line between Routers RT6 and RT10). 836 **FROM** **FROM** 838 |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| 839 * -------------------- * ---------------------- 840 * RT12| | | | | * RT9| | | |0 | 841 T N9|1 | | | | T RT11| | | |0 | 842 O N10|2 | | | | O RT12| | | |0 | 843 * H1|10 | | | | * N9| | | | | 844 * * 845 RT12's router-LSA N9's network-LSA 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 / | \ 6| \ 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 892 Destination Next Hop Distance 893 __________________________________ 894 N1 RT3 10 895 N2 RT3 10 896 N3 RT3 7 897 N4 RT3 8 898 Ib * 7 899 Ia RT10 12 900 N6 RT10 8 901 N7 RT10 12 902 N8 RT10 10 903 N9 RT10 11 904 N10 RT10 13 905 N11 RT10 14 906 H1 RT10 21 907 __________________________________ 908 RT5 RT5 6 909 RT7 RT10 8 911 Table 2: The portion of Router RT6's routing table listing local 912 destinations. 914 Routes to networks belonging to other AS'es (such as N12) appear 915 as dashed lines on the shortest path tree in Figure 5. Use of 916 this externally derived routing information is considered in the 917 next section. 919 2.3. Use of external routing information 921 After the tree is created the external routing information is 922 examined. This external routing information may originate from 923 another routing protocol such as BGP, or be statically 924 configured (static routes). Default routes can also be included 925 as part of the Autonomous System's external routing information. 927 External routing information is flooded unaltered throughout the 928 AS. In our example, all the routers in the Autonomous System 929 know that Router RT7 has two external routes, with metrics 2 and 930 9. 932 OSPF supports two types of external metrics. Type 1 external 933 metrics are expressed in the same units as OSPF interface cost 934 (i.e., in terms of the link state metric). Type 2 external 935 metrics are an order of magnitude larger; any Type 2 metric is 936 considered greater than the cost of any path internal to the AS. 937 Use of Type 2 external metrics assumes that routing between 938 AS'es is the major cost of routing a packet, and eliminates the 939 need for conversion of external costs to internal link state 940 metrics. 942 As an example of Type 1 external metric processing, suppose that 943 the Routers RT7 and RT5 in Figure 2 are advertising Type 1 944 external metrics. For each advertised external route, the total 945 cost from Router RT6 is calculated as the sum of the external 946 route's advertised cost and the distance from Router RT6 to the 947 advertising router. When two routers are advertising the same 948 external destination, RT6 picks the advertising router providing 949 the minimum total cost. RT6 then sets the next hop to the 950 external destination equal to the next hop that would be used 951 when routing packets to the chosen advertising router. 953 In Figure 2, both Router RT5 and RT7 are advertising an external 954 route to destination Network N12. Router RT7 is preferred since 955 it is advertising N12 at a distance of 10 (8+2) to Router RT6, 956 which is better than Router RT5's 14 (6+8). Table 3 shows the 957 entries that are added to the routing table when external routes 958 are examined: 960 Destination Next Hop Distance 961 __________________________________ 962 N12 RT10 10 963 N13 RT5 14 964 N14 RT5 14 965 N15 RT10 17 967 Table 3: The portion of Router RT6's routing table 968 listing external destinations. 970 Processing of Type 2 external metrics is simpler. The AS 971 boundary router advertising the smallest external metric is 972 chosen, regardless of the internal distance to the AS boundary 973 router. Suppose in our example both Router RT5 and Router RT7 974 were advertising Type 2 external routes. Then all traffic 975 destined for Network N12 would be forwarded to Router RT7, since 976 2 < 8. When several equal-cost Type 2 routes exist, the 977 internal distance to the advertising routers is used to break 978 the tie. 980 Both Type 1 and Type 2 external metrics can be present in the AS 981 at the same time. In that event, Type 1 external metrics always 982 take precedence. 984 This section has assumed that packets destined for external 985 destinations are always routed through the advertising AS 986 boundary router. This is not always desirable. For example, 987 suppose in Figure 2 there is an additional router attached to 988 Network N6, called Router RTX. Suppose further that RTX does 989 not participate in OSPF routing, but does exchange BGP 990 information with the AS boundary router RT7. Then, Router RT7 991 would end up advertising OSPF external routes for all 992 destinations that should be routed to RTX. An extra hop will 993 sometimes be introduced if packets for these destinations need 994 always be routed first to Router RT7 (the advertising router). 996 To deal with this situation, the OSPF protocol allows an AS 997 boundary router to specify a "forwarding address" in its AS- 998 external-LSAs. In the above example, Router RT7 would specify 999 RTX's IP address as the "forwarding address" for all those 1000 destinations whose packets should be routed directly to RTX. 1002 The "forwarding address" has one other application. It enables 1003 routers in the Autonomous System's interior to function as 1004 "route servers". For example, in Figure 2 the router RT6 could 1005 become a route server, gaining external routing information 1006 through a combination of static configuration and external 1007 routing protocols. RT6 would then start advertising itself as 1008 an AS boundary router, and would originate a collection of OSPF 1009 AS-external-LSAs. In each AS-external-LSA, Router RT6 would 1010 specify the correct Autonomous System exit point to use for the 1011 destination through appropriate setting of the LSA's "forwarding 1012 address" field. 1014 2.4. Equal-cost multipath 1016 The above discussion has been simplified by considering only a 1017 single route to any destination. In reality, if multiple 1018 equal-cost routes to a destination exist, they are all 1019 discovered and used. This requires no conceptual changes to the 1020 algorithm, and its discussion is postponed until we consider the 1021 tree-building process in more detail. 1023 With equal cost multipath, a router potentially has several 1024 available next hops towards any given destination. 1026 2.5. TOS-based routing 1028 OSPF can calculate a separate set of routes for each IP Type of 1029 Service. This means that, for any destination, there can 1030 potentially be multiple routing table entries, one for each IP 1031 TOS. The IP TOS values are represented in OSPF exactly as they 1032 appear in the IP packet header. 1034 Up to this point, all examples shown have assumed that routes do 1035 not vary on TOS. In order to differentiate routes based on TOS, 1036 separate interface costs can be configured for each TOS. For 1037 example, in Figure 2 there could be multiple costs (one for each 1038 TOS) listed for each interface. A cost for TOS 0 must always be 1039 specified. 1041 When interface costs vary based on TOS, a separate shortest path 1042 tree is calculated for each TOS (see Section 2.2). In addition, 1043 external costs can vary based on TOS. For example, in Figure 2 1044 Router RT7 could advertise a separate type 1 external metric for 1045 each TOS. Then, when calculating the TOS X distance to Network 1046 N15 the cost of the shortest TOS X path to RT7 would be added to 1047 the TOS X cost advertised by RT7 for Network N15 (see Section 1048 2.3). 1050 All OSPF implementations must be capable of calculating routes 1051 based on TOS. However, OSPF routers can be configured to route 1052 all packets on the TOS 0 path (see Appendix C), eliminating the 1053 need to calculate non-zero TOS paths. This can be used to 1054 conserve routing table space and processing resources in the 1055 router. These TOS-0-only routers can be mixed with routers that 1056 do route based on TOS. TOS-0-only routers will be avoided as 1057 much as possible when forwarding traffic requesting a non-zero 1058 TOS. 1060 It may be the case that no path exists for some non-zero TOS, 1061 even if the router is calculating non-zero TOS paths. In that 1062 case, packets requesting that non-zero TOS are routed along the 1063 TOS 0 path (see Section 11.1). 1065 3. Splitting the AS into Areas 1067 OSPF allows collections of contiguous networks and hosts to be 1068 grouped together. Such a group, together with the routers having 1069 interfaces to any one of the included networks, is called an area. 1070 Each area runs a separate copy of the basic link-state routing 1071 algorithm. This means that each area has its own link-state 1072 database and corresponding graph, as explained in the previous 1073 section. 1075 The topology of an area is invisible from the outside of the area. 1076 Conversely, routers internal to a given area know nothing of the 1077 detailed topology external to the area. This isolation of knowledge 1078 enables the protocol to effect a marked reduction in routing traffic 1079 as compared to treating the entire Autonomous System as a single 1080 link-state domain. 1082 With the introduction of areas, it is no longer true that all 1083 routers in the AS have an identical link-state database. A router 1084 actually has a separate link-state database for each area it is 1085 connected to. (Routers connected to multiple areas are called area 1086 border routers). Two routers belonging to the same area have, for 1087 that area, identical area link-state databases. 1089 Routing in the Autonomous System takes place on two levels, 1090 depending on whether the source and destination of a packet reside 1091 in the same area (intra-area routing is used) or different areas 1092 (inter-area routing is used). In intra-area routing, the packet is 1093 routed solely on information obtained within the area; no routing 1094 information obtained from outside the area can be used. This 1095 protects intra-area routing from the injection of bad routing 1096 information. We discuss inter-area routing in Section 3.2. 1098 3.1. The backbone of the Autonomous System 1100 The OSPF backbone is the special OSPF Area 0 (often written as 1101 Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP 1102 addresses). The OSPF backbone always contains all area border 1103 routers. The backbone is responsible for distributing routing 1104 information between non-backbone areas. The backbone must be 1105 contiguous. However, it need not be physically contiguous; 1106 backbone connectivity can be established/maintained through the 1107 configuration of virtual links. 1109 Virtual links can be configured between any two backbone routers 1110 that have an interface to a common non-backbone area. Virtual 1111 links belong to the backbone. The protocol treats two routers 1112 joined by a virtual link as if they were connected by an 1113 unnumbered point-to-point backbone network. On the graph of the 1114 backbone, two such routers are joined by arcs whose costs are 1115 the intra-area distances between the two routers. The routing 1116 protocol traffic that flows along the virtual link uses intra- 1117 area routing only. 1119 3.2. Inter-area routing 1121 When routing a packet between two non-backbone areas the 1122 backbone is used. The path that the packet will travel can be 1123 broken up into three contiguous pieces: an intra-area path from 1124 the source to an area border router, a backbone path between the 1125 source and destination areas, and then another intra-area path 1126 to the destination. The algorithm finds the set of such paths 1127 that have the smallest cost. 1129 Looking at this another way, inter-area routing can be pictured 1130 as forcing a star configuration on the Autonomous System, with 1131 the backbone as hub and each of the non-backbone areas as 1132 spokes. 1134 The topology of the backbone dictates the backbone paths used 1135 between areas. The topology of the backbone can be enhanced by 1136 adding virtual links. This gives the system administrator some 1137 control over the routes taken by inter-area traffic. 1139 The correct area border router to use as the packet exits the 1140 source area is chosen in exactly the same way routers 1141 advertising external routes are chosen. Each area border router 1142 in an area summarizes for the area its cost to all networks 1143 external to the area. After the SPF tree is calculated for the 1144 area, routes to all inter-area destinations are calculated by 1145 examining the summaries of the area border routers. 1147 3.3. Classification of routers 1149 Before the introduction of areas, the only OSPF routers having a 1150 specialized function were those advertising external routing 1151 information, such as Router RT5 in Figure 2. When the AS is 1152 split into OSPF areas, the routers are further divided according 1153 to function into the following four overlapping categories: 1155 Internal routers 1156 A router with all directly connected networks belonging to 1157 the same area. These routers run a single copy of the basic 1158 routing algorithm. 1160 Area border routers 1161 A router that attaches to multiple areas. Area border 1162 routers run multiple copies of the basic algorithm, one copy 1163 for each attached area. Area border routers condense the 1164 topological information of their attached areas for 1165 distribution to the backbone. The backbone in turn 1166 distributes the information to the other areas. 1168 Backbone routers 1169 A router that has an interface to the backbone area. This 1170 includes all routers that interface to more than one area 1171 (i.e., area border routers). However, backbone routers do 1172 not have to be area border routers. Routers with all 1173 interfaces connecting to the backbone area are supported. 1175 AS boundary routers 1176 A router that exchanges routing information with routers 1177 belonging to other Autonomous Systems. Such a router 1178 advertises AS external routing information throughout the 1179 Autonomous System. The paths to each AS boundary router are 1180 known by every router in the AS. This classification is 1181 completely independent of the previous classifications: AS 1182 boundary routers may be internal or area border routers, and 1183 may or may not participate in the backbone. 1185 3.4. A sample area configuration 1187 Figure 6 shows a sample area configuration. The first area 1188 consists of networks N1-N4, along with their attached routers 1189 RT1-RT4. The second area consists of networks N6-N8, along with 1190 their attached routers RT7, RT8, RT10 and RT11. The third area 1191 consists of networks N9-N11 and Host H1, along with their 1192 attached routers RT9, RT11 and RT12. The third area has been 1193 configured so that networks N9-N11 and Host H1 will all be 1194 grouped into a single route, when advertised external to the 1195 area (see Section 3.5 for more details). 1197 In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are 1198 internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area 1199 border routers. Finally, as before, Routers RT5 and RT7 are AS 1200 boundary routers. 1202 Figure 7 shows the resulting link-state database for the Area 1. 1203 The figure completely describes that area's intra-area routing. 1204 It also shows the complete view of the internet for the two 1205 internal routers RT1 and RT2. It is the job of the area border 1206 routers, RT3 and RT4, to advertise into Area 1 the distances to 1207 all destinations external to the area. These are indicated in 1208 Figure 7 by the dashed stub routes. Also, RT3 and RT4 must 1209 advertise into Area 1 the location of the AS boundary routers 1210 RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are 1211 flooded throughout the entire AS, and in particular throughout 1212 ........................... 1213 . + . 1214 . | 3+---+ . N12 N14 1215 . N1|--|RT1|\ 1 . \ N13 / 1216 . | +---+ \ . 8\ |8/8 1217 . + \ ____ . \|/ 1218 . / \ 1+---+8 8+---+6 1219 . * N3 *---|RT4|------|RT5|--------+ 1220 . \____/ +---+ +---+ | 1221 . + / \ . |7 | 1222 . | 3+---+ / \ . | | 1223 . N2|--|RT2|/1 1\ . |6 | 1224 . | +---+ +---+8 6+---+ | 1225 . + |RT3|------|RT6| | 1226 . +---+ +---+ | 1227 . 2/ . Ia|7 | 1228 . / . | | 1229 . +---------+ . | | 1230 .Area 1 N4 . | | 1231 ........................... | | 1232 .......................... | | 1233 . N11 . | | 1234 . +---------+ . | | 1235 . | . | | N12 1236 . |3 . Ib|5 |6 2/ 1237 . +---+ . +----+ +---+/ 1238 . |RT9| . .........|RT10|.....|RT7|---N15. 1239 . +---+ . . +----+ +---+ 9 . 1240 . |1 . . + /3 1\ |1 . 1241 . _|__ . . | / \ __|_ . 1242 . / \ 1+----+2 |/ \ / \ . 1243 . * N9 *------|RT11|----| * N6 * . 1244 . \____/ +----+ | \____/ . 1245 . | . . | | . 1246 . |1 . . + |1 . 1247 . +--+ 10+----+ . . N8 +---+ . 1248 . |H1|-----|RT12| . . |RT8| . 1249 . +--+SLIP +----+ . . +---+ . 1250 . |2 . . |4 . 1251 . | . . | . 1252 . +---------+ . . +--------+ . 1253 . N10 . . N7 . 1254 . . .Area 2 . 1255 .Area 3 . ................................ 1256 .......................... 1258 Figure 6: A sample OSPF area configuration 1259 Area 1. These LSAs are included in Area 1's database, and yield 1260 routes to Networks N12-N15. 1262 Routers RT3 and RT4 must also summarize Area 1's topology for 1263 distribution to the backbone. Their backbone LSAs are shown in 1264 Table 4. These summaries show which networks are contained in 1265 Area 1 (i.e., Networks N1-N4), and the distance to these 1266 networks from the routers RT3 and RT4 respectively. 1268 The link-state database for the backbone is shown in Figure 8. 1269 The set of routers pictured are the backbone routers. Router 1270 RT11 is a backbone router because it belongs to two areas. In 1271 order to make the backbone connected, a virtual link has been 1272 configured between Routers R10 and R11. 1274 The area border routers RT3, RT4, RT7, RT10 and RT11 condense 1275 the routing information of their attached non-backbone areas for 1276 distribution via the backbone; these are the dashed stubs that 1277 appear in Figure 8. Remember that the third area has been 1278 configured to condense Networks N9-N11 and Host H1 into a single 1279 route. This yields a single dashed line for networks N9-N11 and 1280 Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary 1281 routers; their externally derived information also appears on 1282 the graph in Figure 8 as stubs. 1284 The backbone enables the exchange of summary information between 1285 area border routers. Every area border router hears the area 1286 summaries from all other area border routers. It then forms a 1287 picture of the distance to all networks outside of its area by 1288 examining the collected LSAs, and adding in the backbone 1289 distance to each advertising router. 1291 Again using Routers RT3 and RT4 as an example, the procedure 1292 goes as follows: They first calculate the SPF tree for the 1294 Network RT3 adv. RT4 adv. 1295 _____________________________ 1296 N1 4 4 1297 N2 4 4 1298 N3 1 1 1299 N4 2 3 1301 Table 4: Networks advertised to the backbone 1302 by Routers RT3 and RT4. 1304 **FROM** 1306 |RT|RT|RT|RT|RT|RT| 1307 |1 |2 |3 |4 |5 |7 |N3| 1308 ----- ------------------- 1309 RT1| | | | | | |0 | 1310 RT2| | | | | | |0 | 1311 RT3| | | | | | |0 | 1312 * RT4| | | | | | |0 | 1313 * RT5| | |14|8 | | | | 1314 T RT7| | |20|14| | | | 1315 O N1|3 | | | | | | | 1316 * N2| |3 | | | | | | 1317 * N3|1 |1 |1 |1 | | | | 1318 N4| | |2 | | | | | 1319 Ia,Ib| | |20|27| | | | 1320 N6| | |16|15| | | | 1321 N7| | |20|19| | | | 1322 N8| | |18|18| | | | 1323 N9-N11,H1| | |29|36| | | | 1324 N12| | | | |8 |2 | | 1325 N13| | | | |8 | | | 1326 N14| | | | |8 | | | 1327 N15| | | | | |9 | | 1329 Figure 7: Area 1's Database. 1331 Networks and routers are represented by vertices. 1332 An edge of cost X connects Vertex A to Vertex B iff 1333 the intersection of Column A and Row B is marked 1334 with an X. 1336 **FROM** 1338 |RT|RT|RT|RT|RT|RT|RT 1339 |3 |4 |5 |6 |7 |10|11| 1340 ------------------------ 1341 RT3| | | |6 | | | | 1342 RT4| | |8 | | | | | 1343 RT5| |8 | |6 |6 | | | 1344 RT6|8 | |7 | | |5 | | 1345 RT7| | |6 | | | | | 1346 * RT10| | | |7 | | |2 | 1347 * RT11| | | | | |3 | | 1348 T N1|4 |4 | | | | | | 1349 O N2|4 |4 | | | | | | 1350 * N3|1 |1 | | | | | | 1351 * N4|2 |3 | | | | | | 1352 Ia| | | | | |5 | | 1353 Ib| | | |7 | | | | 1354 N6| | | | |1 |1 |3 | 1355 N7| | | | |5 |5 |7 | 1356 N8| | | | |4 |3 |2 | 1357 N9-N11,H1| | | | | | |11| 1358 N12| | |8 | |2 | | | 1359 N13| | |8 | | | | | 1360 N14| | |8 | | | | | 1361 N15| | | | |9 | | | 1363 Figure 8: The backbone's database. 1365 Networks and routers are represented by vertices. 1366 An edge of cost X connects Vertex A to Vertex B iff 1367 the intersection of Column A and Row B is marked 1368 with an X. 1370 backbone. This gives the distances to all other area border 1371 routers. Also noted are the distances to networks (Ia and Ib) 1372 and AS boundary routers (RT5 and RT7) that belong to the 1373 backbone. This calculation is shown in Table 5. 1375 Next, by looking at the area summaries from these area border 1376 routers, RT3 and RT4 can determine the distance to all networks 1377 outside their area. These distances are then advertised 1378 internally to the area by RT3 and RT4. The advertisements that 1379 Router RT3 and RT4 will make into Area 1 are shown in Table 6. 1380 Note that Table 6 assumes that an area range has been configured 1381 for the backbone which groups Ia and Ib into a single LSA. 1383 dist from dist from 1384 RT3 RT4 1385 __________________________________ 1386 to RT3 * 21 1387 to RT4 22 * 1388 to RT7 20 14 1389 to RT10 15 22 1390 to RT11 18 25 1391 __________________________________ 1392 to Ia 20 27 1393 to Ib 15 22 1394 __________________________________ 1395 to RT5 14 8 1396 to RT7 20 14 1398 Table 5: Backbone distances calculated 1399 by Routers RT3 and RT4. 1401 The information imported into Area 1 by Routers RT3 and RT4 1402 enables an internal router, such as RT1, to choose an area 1403 border router intelligently. Router RT1 would use RT4 for 1404 traffic to Network N6, RT3 for traffic to Network N10, and would 1405 load share between the two for traffic to Network N8. 1407 Router RT1 can also determine in this manner the shortest path 1408 to the AS boundary routers RT5 and RT7. Then, by looking at RT5 1409 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or 1410 RT7 when sending to a destination in another Autonomous System 1411 (one of the networks N12-N15). 1413 Destination RT3 adv. RT4 adv. 1414 _________________________________ 1415 Ia,Ib 20 27 1416 N6 16 15 1417 N7 20 19 1418 N8 18 18 1419 N9-N11,H1 29 36 1420 _________________________________ 1421 RT5 14 8 1422 RT7 20 14 1424 Table 6: Destinations advertised into Area 1 1425 by Routers RT3 and RT4. 1427 Note that a failure of the line between Routers RT6 and RT10 1428 will cause the backbone to become disconnected. Configuring a 1429 virtual link between Routers RT7 and RT10 will give the backbone 1430 more connectivity and more resistance to such failures. 1432 3.5. IP subnetting support 1434 OSPF attaches an IP address mask to each advertised route. The 1435 mask indicates the range of addresses being described by the 1436 particular route. For example, a summary-LSA for the 1437 destination 128.185.0.0 with a mask of 0xffff0000 actually is 1438 describing a single route to the collection of destinations 1439 128.185.0.0 - 128.185.255.255. Similarly, host routes are 1440 always advertised with a mask of 0xffffffff, indicating the 1441 presence of only a single destination. 1443 Including the mask with each advertised destination enables the 1444 implementation of what is commonly referred to as variable- 1445 length subnetting. This means that a single IP class A, B, or C 1446 network number can be broken up into many subnets of various 1447 sizes. For example, the network 128.185.0.0 could be broken up 1448 into 62 variable-sized subnets: 15 subnets of size 4K, 15 1449 subnets of size 256, and 32 subnets of size 8. Table 7 shows 1450 some of the resulting network addresses together with their 1451 masks. 1453 Network address IP address mask Subnet size 1454 _______________________________________________ 1455 128.185.16.0 0xfffff000 4K 1456 128.185.1.0 0xffffff00 256 1457 128.185.0.8 0xfffffff8 8 1459 Table 7: Some sample subnet sizes. 1461 There are many possible ways of dividing up a class A, B, and C 1462 network into variable sized subnets. The precise procedure for 1463 doing so is beyond the scope of this specification. This 1464 specification however establishes the following guideline: When 1465 an IP packet is forwarded, it is always forwarded to the network 1466 that is the best match for the packet's destination. Here best 1467 match is synonymous with the longest or most specific match. 1468 For example, the default route with destination of 0.0.0.0 and 1469 mask 0x00000000 is always a match for every IP destination. Yet 1470 it is always less specific than any other match. Subnet masks 1471 must be assigned so that the best match for any IP destination 1472 is unambiguous. 1474 Attaching an address mask to each route also enables the support 1475 of IP supernetting. For example, a single physical network 1476 segment could be assigned the [address,mask] pair 1477 [192.9.4.0,0xfffffc00]. The segment would then be single IP 1478 network, containing addresses from the four consecutive class C 1479 network numbers 192.9.4.0 through 192.9.7.0. Such addressing is 1480 now becoming commonplace with the advent of CIDR (see [Ref10]). 1482 In order to get better aggregation at area boundaries, area 1483 address ranges can be employed (see Section C.2 for more 1484 details). Each address range is defined as an [address,mask] 1485 pair. Many separate networks may then be contained in a single 1486 address range, just as a subnetted network is composed of many 1487 separate subnets. Area border routers then summarize the area 1488 contents (for distribution to the backbone) by advertising a 1489 single route for each address range. The cost of the route is 1490 the maximum cost to any of the networks falling in the specified 1491 range. 1493 For example, an IP subnetted network might be configured as a 1494 single OSPF area. In that case, a single address range could be 1495 configured: a class A, B, or C network number along with its 1496 natural IP mask. Inside the area, any number of variable sized 1497 subnets could be defined. However, external to the area a 1498 single route for the entire subnetted network would be 1499 distributed, hiding even the fact that the network is subnetted 1500 at all. The cost of this route is the maximum of the set of 1501 costs to the component subnets. 1503 3.6. Supporting stub areas 1505 In some Autonomous Systems, the majority of the link-state 1506 database may consist of AS-external-LSAs. An OSPF AS-external- 1507 LSA is usually flooded throughout the entire AS. However, OSPF 1508 allows certain areas to be configured as "stub areas". AS- 1509 external-LSAs are not flooded into/throughout stub areas; 1510 routing to AS external destinations in these areas is based on a 1511 (per-area) default only. This reduces the link-state database 1512 size, and therefore the memory requirements, for a stub area's 1513 internal routers. 1515 In order to take advantage of the OSPF stub area support, 1516 default routing must be used in the stub area. This is 1517 accomplished as follows. One or more of the stub area's area 1518 border routers must advertise a default route into the stub area 1519 via summary-LSAs. These summary defaults are flooded throughout 1520 the stub area, but no further. (For this reason these defaults 1521 pertain only to the particular stub area). These summary 1522 default routes will be used for any destination that is not 1523 explicitly reachable by an intra-area or inter-area path (i.e., 1524 AS external destinations). 1526 An area can be configured as a stub when there is a single exit 1527 point from the area, or when the choice of exit point need not 1528 be made on a per-external-destination basis. For example, Area 1529 3 in Figure 6 could be configured as a stub area, because all 1530 external traffic must travel though its single area border 1531 router RT11. If Area 3 were configured as a stub, Router RT11 1532 would advertise a default route for distribution inside Area 3 1533 (in a summary-LSA), instead of flooding the AS-external-LSAs for 1534 Networks N12-N15 into/throughout the area. 1536 The OSPF protocol ensures that all routers belonging to an area 1537 agree on whether the area has been configured as a stub. This 1538 guarantees that no confusion will arise in the flooding of AS- 1539 external-LSAs. 1541 There are a couple of restrictions on the use of stub areas. 1542 Virtual links cannot be configured through stub areas. In 1543 addition, AS boundary routers cannot be placed internal to stub 1544 areas. 1546 3.7. Partitions of areas 1548 OSPF does not actively attempt to repair area partitions. When 1549 an area becomes partitioned, each component simply becomes a 1550 separate area. The backbone then performs routing between the 1551 new areas. Some destinations reachable via intra-area routing 1552 before the partition will now require inter-area routing. 1554 However, in order to maintain full routing after the partition, 1555 an address range must not be split across multiple components of 1556 the area partition. Also, the backbone itself must not 1557 partition. If it does, parts of the Autonomous System will 1558 become unreachable. Backbone partitions can be repaired by 1559 configuring virtual links (see Section 15). 1561 Another way to think about area partitions is to look at the 1562 Autonomous System graph that was introduced in Section 2. Area 1563 IDs can be viewed as colors for the graph's edges.[1] Each edge 1564 of the graph connects to a network, or is itself a point-to- 1565 point network. In either case, the edge is colored with the 1566 network's Area ID. 1568 A group of edges, all having the same color, and interconnected 1569 by vertices, represents an area. If the topology of the 1570 Autonomous System is intact, the graph will have several regions 1571 of color, each color being a distinct Area ID. 1573 When the AS topology changes, one of the areas may become 1574 partitioned. The graph of the AS will then have multiple 1575 regions of the same color (Area ID). The routing in the 1576 Autonomous System will continue to function as long as these 1577 regions of same color are connected by the single backbone 1578 region. 1580 4. Functional Summary 1582 A separate copy of OSPF's basic routing algorithm runs in each area. 1583 Routers having interfaces to multiple areas run multiple copies of 1584 the algorithm. A brief summary of the routing algorithm follows. 1586 When a router starts, it first initializes the routing protocol data 1587 structures. The router then waits for indications from the lower- 1588 level protocols that its interfaces are functional. 1590 A router then uses the OSPF's Hello Protocol to acquire neighbors. 1591 The router sends Hello packets to its neighbors, and in turn 1592 receives their Hello packets. On broadcast and point-to-point 1593 networks, the router dynamically detects its neighboring routers by 1594 sending its Hello packets to the multicast address AllSPFRouters. 1595 On non-broadcast networks, some configuration information may be 1596 necessary in order to discover neighbors. On broadcast and NBMA 1597 networks the Hello Protocol also elects a Designated router for the 1598 network. 1600 The router will attempt to form adjacencies with some of its newly 1601 acquired neighbors. Link-state databases are synchronized between 1602 pairs of adjacent routers. On broadcast and NBMA networks, the 1603 Designated Router determines which routers should become adjacent. 1605 Adjacencies control the distribution of routing information. 1606 Routing updates are sent and received only on adjacencies. 1608 A router periodically advertises its state, which is also called 1609 link state. Link state is also advertised when a router's state 1610 changes. A router's adjacencies are reflected in the contents of 1611 its LSAs. This relationship between adjacencies and link state 1612 allows the protocol to detect dead routers in a timely fashion. 1614 LSAs are flooded throughout the area. The flooding algorithm is 1615 reliable, ensuring that all routers in an area have exactly the same 1616 link-state database. This database consists of the collection of 1617 LSAs originated by each router belonging to the area. From this 1618 database each router calculates a shortest-path tree, with itself as 1619 root. This shortest-path tree in turn yields a routing table for 1620 the protocol. 1622 4.1. Inter-area routing 1624 The previous section described the operation of the protocol 1625 within a single area. For intra-area routing, no other routing 1626 information is pertinent. In order to be able to route to 1627 destinations outside of the area, the area border routers inject 1628 additional routing information into the area. This additional 1629 information is a distillation of the rest of the Autonomous 1630 System's topology. 1632 This distillation is accomplished as follows: Each area border 1633 router is by definition connected to the backbone. Each area 1634 border router summarizes the topology of its attached non- 1635 backbone areas for transmission on the backbone, and hence to 1636 all other area border routers. An area border router then has 1637 complete topological information concerning the backbone, and 1638 the area summaries from each of the other area border routers. 1639 From this information, the router calculates paths to all 1640 inter-area destinations. The router then advertises these paths 1641 into its attached areas. This enables the area's internal 1642 routers to pick the best exit router when forwarding traffic 1643 inter-area destinations. 1645 4.2. AS external routes 1647 Routers that have information regarding other Autonomous Systems 1648 can flood this information throughout the AS. This external 1649 routing information is distributed verbatim to every 1650 participating router. There is one exception: external routing 1651 information is not flooded into "stub" areas (see Section 3.6). 1653 To utilize external routing information, the path to all routers 1654 advertising external information must be known throughout the AS 1655 (excepting the stub areas). For that reason, the locations of 1656 these AS boundary routers are summarized by the (non-stub) area 1657 border routers. 1659 4.3. Routing protocol packets 1661 The OSPF protocol runs directly over IP, using IP protocol 89. 1662 OSPF does not provide any explicit fragmentation/reassembly 1663 support. When fragmentation is necessary, IP 1664 fragmentation/reassembly is used. OSPF protocol packets have 1665 been designed so that large protocol packets can generally be 1666 split into several smaller protocol packets. This practice is 1667 recommended; IP fragmentation should be avoided whenever 1668 possible. 1670 Routing protocol packets should always be sent with the IP TOS 1671 field set to 0. If at all possible, routing protocol packets 1672 should be given preference over regular IP data traffic, both 1673 when being sent and received. As an aid to accomplishing this, 1674 OSPF protocol packets should have their IP precedence field set 1675 to the value Internetwork Control (see [Ref5]). 1677 All OSPF protocol packets share a common protocol header that is 1678 described in Appendix A. The OSPF packet types are listed below 1679 in Table 8. Their formats are also described in Appendix A. 1681 Type Packet name Protocol function 1682 __________________________________________________________ 1683 1 Hello Discover/maintain neighbors 1684 2 Database Description Summarize database contents 1685 3 Link State Request Database download 1686 4 Link State Update Database update 1687 5 Link State Ack Flooding acknowledgment 1689 Table 8: OSPF packet types. 1691 OSPF's Hello protocol uses Hello packets to discover and 1692 maintain neighbor relationships. The Database Description and 1693 Link State Request packets are used in the forming of 1694 adjacencies. OSPF's reliable update mechanism is implemented by 1695 the Link State Update and Link State Acknowledgment packets. 1697 Each Link State Update packet carries a set of new link state 1698 advertisements (LSAs) one hop further away from their point of 1699 origination. A single Link State Update packet may contain the 1700 LSAs of several routers. Each LSA is tagged with the ID of the 1701 originating router and a checksum of its link state contents. 1702 Each LSA also has a type field; the different types of OSPF LSAs 1703 are listed below in Table 9. 1705 OSPF routing packets (with the exception of Hellos) are sent 1706 only over adjacencies. This means that all OSPF protocol 1707 packets travel a single IP hop, except those that are sent over 1708 virtual adjacencies. The IP source address of an OSPF protocol 1709 packet is one end of a router adjacency, and the IP destination 1710 address is either the other end of the adjacency or an IP 1711 multicast address. 1713 LS LSA LSA description 1714 type name 1715 ________________________________________________________ 1716 1 Router-LSAs Originated by all routers. 1717 This LSA describes 1718 the collected states of the 1719 router's interfaces to an 1720 area. Flooded throughout a 1721 single area only. 1722 ________________________________________________________ 1723 2 Network-LSAs Originated for broadcast 1724 and NBMA networks by 1725 the Designated Router. This 1726 LSA contains the 1727 list of routers connected 1728 to the network. Flooded 1729 throughout a single area only. 1730 ________________________________________________________ 1731 3,4 Summary-LSAs Originated by area border 1732 routers, and flooded through- 1733 out the LSA's associated 1734 area. Each summary-LSA 1735 describes a route to a 1736 destination outside the area, 1737 yet still inside the AS 1738 (i.e., an inter-area route). 1739 Type 3 summary-LSAs describe 1740 routes to networks. Type 4 1741 summary-LSAs describe 1742 routes to AS boundary routers. 1743 ________________________________________________________ 1744 5 AS-external-LSAs Originated by AS boundary 1745 routers, and flooded through- 1746 out the AS. Each 1747 AS-external-LSA describes 1748 a route to a destination in 1749 another Autonomous System. 1750 Default routes for the AS can 1751 also be described by 1752 AS-external-LSAs. 1754 Table 9: OSPF link state advertisements (LSAs). 1756 4.4. Basic implementation requirements 1758 An implementation of OSPF requires the following pieces of 1759 system support: 1761 Timers 1762 Two different kind of timers are required. The first kind, 1763 called "single shot timers", fire once and cause a protocol 1764 event to be processed. The second kind, called "interval 1765 timers", fire at continuous intervals. These are used for 1766 the sending of packets at regular intervals. A good example 1767 of this is the regular broadcast of Hello packets. The 1768 granularity of both kinds of timers is one second. 1770 Interval timers should be implemented to avoid drift. In 1771 some router implementations, packet processing can affect 1772 timer execution. When multiple routers are attached to a 1773 single network, all doing broadcasts, this can lead to the 1774 synchronization of routing packets (which should be 1775 avoided). If timers cannot be implemented to avoid drift, 1776 small random amounts should be added to/subtracted from the 1777 interval timer at each firing. 1779 IP multicast 1780 Certain OSPF packets take the form of IP multicast 1781 datagrams. Support for receiving and sending IP multicast 1782 datagrams, along with the appropriate lower-level protocol 1783 support, is required. The IP multicast datagrams used by 1784 OSPF never travel more than one hop. For this reason, the 1785 ability to forward IP multicast datagrams is not required. 1786 For information on IP multicast, see [Ref7]. 1788 Variable-length subnet support 1789 The router's IP protocol support must include the ability to 1790 divide a single IP class A, B, or C network number into many 1791 subnets of various sizes. This is commonly called 1792 variable-length subnetting; see Section 3.5 for details. 1794 IP supernetting support 1795 The router's IP protocol support must include the ability to 1796 aggregate contiguous collections of IP class A, B, and C 1797 networks into larger quantities called supernets. 1798 Supernetting has been proposed as one way to improve the 1799 scaling of IP routing in the worldwide Internet. For more 1800 information on IP supernetting, see [Ref10]. 1802 Lower-level protocol support 1803 The lower level protocols referred to here are the network 1804 access protocols, such as the Ethernet data link layer. 1805 Indications must be passed from these protocols to OSPF as 1806 the network interface goes up and down. For example, on an 1807 ethernet it would be valuable to know when the ethernet 1808 transceiver cable becomes unplugged. 1810 Non-broadcast lower-level protocol support 1811 On non-broadcast networks, the OSPF Hello Protocol can be 1812 aided by providing an indication when an attempt is made to 1813 send a packet to a dead or non-existent router. For 1814 example, on an X.25 PDN a dead neighboring router may be 1815 indicated by the reception of a X.25 clear with an 1816 appropriate cause and diagnostic, and this information would 1817 be passed to OSPF. 1819 List manipulation primitives 1820 Much of the OSPF functionality is described in terms of its 1821 operation on lists of LSAs. For example, the collection of 1822 LSAs that will be retransmitted to an adjacent router until 1823 acknowledged are described as a list. Any particular LSA 1824 may be on many such lists. An OSPF implementation needs to 1825 be able to manipulate these lists, adding and deleting 1826 constituent LSAs as necessary. 1828 Tasking support 1829 Certain procedures described in this specification invoke 1830 other procedures. At times, these other procedures should 1831 be executed in-line, that is, before the current procedure 1832 is finished. This is indicated in the text by instructions 1833 to execute a procedure. At other times, the other 1834 procedures are to be executed only when the current 1835 procedure has finished. This is indicated by instructions 1836 to schedule a task. 1838 4.5. Optional OSPF capabilities 1840 The OSPF protocol defines several optional capabilities. A 1841 router indicates the optional capabilities that it supports in 1842 its OSPF Hello packets, Database Description packets and in its 1843 LSAs. This enables routers supporting a mix of optional 1844 capabilities to coexist in a single Autonomous System. 1846 Some capabilities must be supported by all routers attached to a 1847 specific area. In this case, a router will not accept a 1848 neighbor's Hello Packet unless there is a match in reported 1849 capabilities (i.e., a capability mismatch prevents a neighbor 1850 relationship from forming). An example of this is the 1851 ExternalRoutingCapability (see below). 1853 Other capabilities can be negotiated during the Database 1854 Exchange process. This is accomplished by specifying the 1855 optional capabilities in Database Description packets. A 1856 capability mismatch with a neighbor in this case will result in 1857 only a subset of the link state database being exchanged between 1858 the two neighbors. 1860 The routing table build process can also be affected by the 1861 presence/absence of optional capabilities. For example, since 1862 the optional capabilities are reported in LSAs, routers 1863 incapable of certain functions can be avoided when building the 1864 shortest path tree. An example of this is the TOS routing 1865 capability (see below). 1867 The OSPF optional capabilities defined in this memo are listed 1868 below. See Section A.2 for more information. 1870 ExternalRoutingCapability 1871 Entire OSPF areas can be configured as "stubs" (see Section 1872 3.6). AS-external-LSAs will not be flooded into stub areas. 1873 This capability is represented by the E-bit in the OSPF 1874 Options field (see Section A.2). In order to ensure 1875 consistent configuration of stub areas, all routers 1876 interfacing to such an area must have the E-bit clear in 1877 their Hello packets (see Sections 9.5 and 10.5). 1879 TOS capability 1880 All OSPF implementations must be able to calculate separate 1881 routes based on IP Type of Service. However, to save 1882 routing table space and processing resources, an OSPF router 1883 can be configured to ignore TOS when forwarding packets. In 1884 this case, the router calculates routes for TOS 0 only. 1885 This capability is represented by the T-bit in the OSPF 1886 Options field (see Section A.2). TOS-capable routers will 1887 attempt to avoid non-TOS-capable routers when calculating 1888 non-zero TOS paths. 1890 5. Protocol Data Structures 1892 The OSPF protocol is described herein in terms of its operation on 1893 various protocol data structures. The following list comprises the 1894 top-level OSPF data structures. Any initialization that needs to be 1895 done is noted. OSPF areas, interfaces and neighbors also have 1896 associated data structures that are described later in this 1897 specification. 1899 Router ID 1900 A 32-bit number that uniquely identifies this router in the AS. 1901 One possible implementation strategy would be to use the 1902 smallest IP interface address belonging to the router. If a 1903 router's OSPF Router ID is changed, the router's OSPF software 1904 should be restarted before the new Router ID takes effect. In 1905 this case the router should flush its self-originated LSAs from 1906 the routing domain (see Section 14.1) before restarting, or they 1907 will persist for up to MaxAge minutes. 1909 Area structures 1910 Each one of the areas to which the router is connected has its 1911 own data structure. This data structure describes the working 1912 of the basic OSPF algorithm. Remember that each area runs a 1913 separate copy of the basic OSPF algorithm. 1915 Backbone (area) structure 1916 The OSPF backbone area is responsible for the dissemination of 1917 inter-area routing information. 1919 Virtual links configured 1920 The virtual links configured with this router as one endpoint. 1921 In order to have configured virtual links, the router itself 1922 must be an area border router. Virtual links are identified by 1923 the Router ID of the other endpoint -- which is another area 1924 border router. These two endpoint routers must be attached to a 1925 common area, called the virtual link's Transit area. Virtual 1926 links are part of the backbone, and behave as if they were 1927 unnumbered point-to-point networks between the two routers. A 1928 virtual link uses the intra-area routing of its Transit area to 1929 forward packets. Virtual links are brought up and down through 1930 the building of the shortest-path trees for the Transit area. 1932 List of external routes 1933 These are routes to destinations external to the Autonomous 1934 System, that have been gained either through direct experience 1935 with another routing protocol (such as BGP), or through 1936 configuration information, or through a combination of the two 1937 (e.g., dynamic external information to be advertised by OSPF 1938 with configured metric). Any router having these external routes 1939 is called an AS boundary router. These routes are advertised by 1940 the router into the OSPF routing domain via AS-external-LSAs. 1942 List of AS-external-LSAs 1943 Part of the link-state database. These have originated from the 1944 AS boundary routers. They comprise routes to destinations 1945 external to the Autonomous System. Note that, if the router is 1946 itself an AS boundary router, some of these AS-external-LSAs 1947 have been self-originated. 1949 The routing table 1950 Derived from the link-state database. Each entry in the routing 1951 table is indexed by a destination, and contains the 1952 destination's cost and a set of paths to use in forwarding 1953 packets to the destination. A path is described by its type and 1954 next hop. For more information, see Section 11. 1956 TOS capability 1957 This item indicates whether the router will calculate separate 1958 routes based on TOS. This is a configurable parameter. For 1959 more information, see Sections 4.5 and 16.9. 1961 Figure 9 shows the collection of data structures present in a 1962 typical router. The router pictured is RT10, from the map in Figure 1963 6. Note that Router RT10 has a virtual link configured to Router 1964 RT11, with Area 2 as the link's Transit area. This is indicated by 1965 the dashed line in Figure 9. When the virtual link becomes active, 1966 through the building of the shortest path tree for Area 2, it 1967 becomes an interface to the backbone (see the two backbone 1968 interfaces depicted in Figure 9). 1970 6. The Area Data Structure 1972 The area data structure contains all the information used to run the 1973 basic OSPF routing algorithm. Each area maintains its own link-state 1974 database. A network belongs to a single area, and a router interface 1975 connects to a single area. Each router adjacency also belongs to a 1976 single area. 1978 The OSPF backbone is the special OSPF area responsible for 1979 disseminating inter-area routing information. 1981 The area link-state database consists of the collection of router- 1982 LSAs, network-LSAs and summary-LSAs that have originated from the 1983 area's routers. This information is flooded throughout a single 1984 area only. The list of AS-external-LSAs (see Section 5) is also 1985 considered to be part of each area's link-state database. 1987 +----+ 1988 |RT10|------+ 1989 +----+ \+-------------+ 1990 / \ |Routing Table| 1991 / \ +-------------+ 1992 / \ 1993 +------+ / \ +--------+ 1994 |Area 2|---+ +---|Backbone| 1995 +------+***********+ +--------+ 1996 / \ * / \ 1997 / \ * / \ 1998 +---------+ +---------+ +------------+ +------------+ 1999 |Interface| |Interface| |Virtual Link| |Interface Ib| 2000 | to N6 | | to N8 | | to RT11 | +------------+ 2001 +---------+ +---------+ +------------+ | 2002 / \ | | | 2003 / \ | | | 2004 +--------+ +--------+ | +-------------+ +------------+ 2005 |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| 2006 | RT8 | | RT7 | | +-------------+ +------------+ 2007 +--------+ +--------+ | 2008 | 2009 +-------------+ 2010 |Neighbor RT11| 2011 +-------------+ 2013 Figure 9: Router RT10's Data structures 2015 Area ID 2016 A 32-bit number identifying the area. The Area ID of 0.0.0.0 is 2017 reserved for the backbone. 2019 List of area address ranges 2020 In order to aggregate routing information at area boundaries, 2021 area address ranges can be employed. Each address range is 2022 specified by an [address,mask] pair and a status indication of 2023 either Advertise or DoNotAdvertise (see Section 12.4.3). 2025 Associated router interfaces 2026 This router's interfaces connecting to the area. A router 2027 interface belongs to one and only one area (or the backbone). 2028 For the backbone area this list includes all the virtual links. 2029 A virtual link is identified by the Router ID of its other 2030 endpoint; its cost is the cost of the shortest intra-area path 2031 through the Transit area that exists between the two routers. 2033 List of router-LSAs 2034 A router-LSA is generated by each router in the area. It 2035 describes the state of the router's interfaces to the area. 2037 List of network-LSAs 2038 One network-LSA is generated for each transit broadcast and NBMA 2039 network in the area. A network-LSA describes the set of routers 2040 currently connected to the network. 2042 List of summary-LSAs 2043 Summary-LSAs originate from the area's area border routers. 2044 They describe routes to destinations internal to the Autonomous 2045 System, yet external to the area (i.e., inter-area 2046 destinations). 2048 Shortest-path tree 2049 The shortest-path tree for the area, with this router itself as 2050 root. Derived from the collected router-LSAs and network-LSAs 2051 by the Dijkstra algorithm (see Section 16.1). 2053 TransitCapability 2054 This parameter indicates whether the area can carry data traffic 2055 that neither originates nor terminates in the area itself. This 2056 parameter is calculated when the area's shortest-path tree is 2057 built (see Section 16.1, where TransitCapability is set to TRUE 2058 if and only if there are one or more fully adjacent virtual 2059 links using the area as Transit area), and is used as an input 2060 to a subsequent step of the routing table build process (see 2061 Section 16.3). When an area's TransitCapability is set to TRUE, 2062 the area is said to be a "transit area". 2064 ExternalRoutingCapability 2065 Whether AS-external-LSAs will be flooded into/throughout the 2066 area. This is a configurable parameter. If AS-external-LSAs 2067 are excluded from the area, the area is called a "stub". Within 2068 stub areas, routing to AS external destinations will be based 2069 solely on a default summary route. The backbone cannot be 2070 configured as a stub area. Also, virtual links cannot be 2071 configured through stub areas. For more information, see 2072 Section 3.6. 2074 StubDefaultCost 2075 If the area has been configured as a stub area, and the router 2076 itself is an area border router, then the StubDefaultCost 2077 indicates the cost of the default summary-LSA that the router 2078 should advertise into the area. There can be a separate cost 2079 configured for each IP TOS. See Section 12.4.3 for more 2080 information. 2082 Unless otherwise specified, the remaining sections of this document 2083 refer to the operation of the OSPF protocol within a single area. 2085 7. Bringing Up Adjacencies 2087 OSPF creates adjacencies between neighboring routers for the purpose 2088 of exchanging routing information. Not every two neighboring 2089 routers will become adjacent. This section covers the generalities 2090 involved in creating adjacencies. For further details consult 2091 Section 10. 2093 7.1. The Hello Protocol 2095 The Hello Protocol is responsible for establishing and 2096 maintaining neighbor relationships. It also ensures that 2097 communication between neighbors is bidirectional. Hello packets 2098 are sent periodically out all router interfaces. Bidirectional 2099 communication is indicated when the router sees itself listed in 2100 the neighbor's Hello Packet. On broadcast and NBMA networks, 2101 the Hello Protocol elects a Designated Router for the network. 2103 The Hello Protocol works differently on broadcast networks, NBMA 2104 networks and Point-to-MultiPoint networks. On broadcast 2105 networks, each router advertises itself by periodically 2106 multicasting Hello Packets. This allows neighbors to be 2107 discovered dynamically. These Hello Packets contain the 2108 router's view of the Designated Router's identity, and the list 2109 of routers whose Hello Packets have been seen recently. 2111 On NBMA networks some configuration information may be necessary 2112 for the operation of the Hello Protocol. Each router that may 2113 potentially become Designated Router has a list of all other 2114 routers attached to the network. A router, having Designated 2115 Router potential, sends Hello Packets to all other potential 2116 Designated Routers when its interface to the NBMA network first 2117 becomes operational. This is an attempt to find the Designated 2118 Router for the network. If the router itself is elected 2119 Designated Router, it begins sending Hello Packets to all other 2120 routers attached to the network. 2122 On Point-to-MultiPoint networks, a router sends Hello Packets to 2123 all neighbors with which it can communicate directly. These 2124 neighbors may be discovered dynamically through a protocol such 2125 as Inverse ARP (see [Ref14]), or they may be configured. 2127 After a neighbor has been discovered, bidirectional 2128 communication ensured, and (if on a broadcast or NBMA network) a 2129 Designated Router elected, a decision is made regarding whether 2130 or not an adjacency should be formed with the neighbor (see 2131 Section 10.4). If an adjacency is to be formed, the first step 2132 is to synchronize the neighbors' link-state databases. This is 2133 covered in the next section. 2135 7.2. The Synchronization of Databases 2137 In a link-state routing algorithm, it is very important for all 2138 routers' link-state databases to stay synchronized. OSPF 2139 simplifies this by requiring only adjacent routers to remain 2140 synchronized. The synchronization process begins as soon as the 2141 routers attempt to bring up the adjacency. Each router 2142 describes its database by sending a sequence of Database 2143 Description packets to its neighbor. Each Database Description 2144 Packet describes a set of LSAs belonging to the router's 2145 database. When the neighbor sees an LSA that is more recent 2146 than its own database copy, it makes a note that this newer LSA 2147 should be requested. 2149 This sending and receiving of Database Description packets is 2150 called the "Database Exchange Process". During this process, 2151 the two routers form a master/slave relationship. Each Database 2152 Description Packet has a sequence number. Database Description 2153 Packets sent by the master (polls) are acknowledged by the slave 2154 through echoing of the sequence number. Both polls and their 2155 responses contain summaries of link state data. The master is 2156 the only one allowed to retransmit Database Description Packets. 2157 It does so only at fixed intervals, the length of which is the 2158 configured per-interface constant RxmtInterval. 2160 Each Database Description contains an indication that there are 2161 more packets to follow --- the M-bit. The Database Exchange 2162 Process is over when a router has received and sent Database 2163 Description Packets with the M-bit off. 2165 During and after the Database Exchange Process, each router has 2166 a list of those LSAs for which the neighbor has more up-to-date 2167 instances. These LSAs are requested in Link State Request 2168 Packets. Link State Request packets that are not satisfied are 2169 retransmitted at fixed intervals of time RxmtInterval. When the 2170 Database Description Process has completed and all Link State 2171 Requests have been satisfied, the databases are deemed 2172 synchronized and the routers are marked fully adjacent. At this 2173 time the adjacency is fully functional and is advertised in the 2174 two routers' router-LSAs. 2176 The adjacency is used by the flooding procedure as soon as the 2177 Database Exchange Process begins. This simplifies database 2178 synchronization, and guarantees that it finishes in a 2179 predictable period of time. 2181 7.3. The Designated Router 2183 Every broadcast and NBMA network has a Designated Router. The 2184 Designated Router performs two main functions for the routing 2185 protocol: 2187 o The Designated Router originates a network-LSA on behalf of 2188 the network. This LSA lists the set of routers (including 2189 the Designated Router itself) currently attached to the 2190 network. The Link State ID for this LSA (see Section 2191 12.1.4) is the IP interface address of the Designated 2192 Router. The IP network number can then be obtained by using 2193 the network's subnet/network mask. 2195 o The Designated Router becomes adjacent to all other routers 2196 on the network. Since the link state databases are 2197 synchronized across adjacencies (through adjacency bring-up 2198 and then the flooding procedure), the Designated Router 2199 plays a central part in the synchronization process. 2201 The Designated Router is elected by the Hello Protocol. A 2202 router's Hello Packet contains its Router Priority, which is 2203 configurable on a per-interface basis. In general, when a 2204 router's interface to a network first becomes functional, it 2205 checks to see whether there is currently a Designated Router for 2206 the network. If there is, it accepts that Designated Router, 2207 regardless of its Router Priority. (This makes it harder to 2208 predict the identity of the Designated Router, but ensures that 2209 the Designated Router changes less often. See below.) 2210 Otherwise, the router itself becomes Designated Router if it has 2211 the highest Router Priority on the network. A more detailed 2212 (and more accurate) description of Designated Router election is 2213 presented in Section 9.4. 2215 The Designated Router is the endpoint of many adjacencies. In 2216 order to optimize the flooding procedure on broadcast networks, 2217 the Designated Router multicasts its Link State Update Packets 2218 to the address AllSPFRouters, rather than sending separate 2219 packets over each adjacency. 2221 Section 2 of this document discusses the directed graph 2222 representation of an area. Router nodes are labelled with their 2223 Router ID. Transit network nodes are actually labelled with the 2224 IP address of their Designated Router. It follows that when the 2225 Designated Router changes, it appears as if the network node on 2226 the graph is replaced by an entirely new node. This will cause 2227 the network and all its attached routers to originate new LSAs. 2228 Until the link-state databases again converge, some temporary 2229 loss of connectivity may result. This may result in ICMP 2230 unreachable messages being sent in response to data traffic. 2231 For that reason, the Designated Router should change only 2232 infrequently. Router Priorities should be configured so that 2233 the most dependable router on a network eventually becomes 2234 Designated Router. 2236 7.4. The Backup Designated Router 2238 In order to make the transition to a new Designated Router 2239 smoother, there is a Backup Designated Router for each broadcast 2240 and NBMA network. The Backup Designated Router is also adjacent 2241 to all routers on the network, and becomes Designated Router 2242 when the previous Designated Router fails. If there were no 2243 Backup Designated Router, when a new Designated Router became 2244 necessary, new adjacencies would have to be formed between the 2245 new Designated Router and all other routers attached to the 2246 network. Part of the adjacency forming process is the 2247 synchronizing of link-state databases, which can potentially 2248 take quite a long time. During this time, the network would not 2249 be available for transit data traffic. The Backup Designated 2250 obviates the need to form these adjacencies, since they already 2251 exist. This means the period of disruption in transit traffic 2252 lasts only as long as it takes to flood the new LSAs (which 2253 announce the new Designated Router). 2255 The Backup Designated Router does not generate a network-LSA for 2256 the network. (If it did, the transition to a new Designated 2257 Router would be even faster. However, this is a tradeoff 2258 between database size and speed of convergence when the 2259 Designated Router disappears.) 2261 The Backup Designated Router is also elected by the Hello 2262 Protocol. Each Hello Packet has a field that specifies the 2263 Backup Designated Router for the network. 2265 In some steps of the flooding procedure, the Backup Designated 2266 Router plays a passive role, letting the Designated Router do 2267 more of the work. This cuts down on the amount of local routing 2268 traffic. See Section 13.3 for more information. 2270 7.5. The graph of adjacencies 2272 An adjacency is bound to the network that the two routers have 2273 in common. If two routers have multiple networks in common, 2274 they may have multiple adjacencies between them. 2276 One can picture the collection of adjacencies on a network as 2277 forming an undirected graph. The vertices consist of routers, 2278 with an edge joining two routers if they are adjacent. The 2279 graph of adjacencies describes the flow of routing protocol 2280 packets, and in particular Link State Update Packets, through 2281 the Autonomous System. 2283 Two graphs are possible, depending on whether a Designated 2284 Router is elected for the network. On physical point-to-point 2285 networks, Point-to-MultiPoint networks and virtual links, 2286 neighboring routers become adjacent whenever they can 2287 communicate directly. In contrast, on broadcast and NBMA 2288 networks only the Designated Router and the Backup Designated 2289 Router become adjacent to all other routers attached to the 2290 network. 2292 These graphs are shown in Figure 10. It is assumed that Router 2293 RT7 has become the Designated Router, and Router RT3 the Backup 2294 Designated Router, for the Network N2. The Backup Designated 2295 Router performs a lesser function during the flooding procedure 2296 than the Designated Router (see Section 13.3). This is the 2297 reason for the dashed lines connecting the Backup Designated 2298 Router RT3. 2300 8. Protocol Packet Processing 2302 This section discusses the general processing of OSPF routing 2303 protocol packets. It is very important that the router link-state 2304 databases remain synchronized. For this reason, routing protocol 2305 packets should get preferential treatment over ordinary data 2306 packets, both in sending and receiving. 2308 Routing protocol packets are sent along adjacencies only (with the 2309 exception of Hello packets, which are used to discover the 2310 adjacencies). This means that all routing protocol packets travel a 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 single IP hop, except those sent over virtual links. 2334 All routing protocol packets begin with a standard header. The 2335 sections below provide details on how to fill in and verify this 2336 standard header. Then, for each packet type, the section giving 2337 more details on that particular packet type's processing is listed. 2339 8.1. Sending protocol packets 2341 When a router sends a routing protocol packet, it fills in the 2342 fields of the standard OSPF packet header as follows. For more 2343 details on the header format consult Section A.3.1: 2345 Version # 2346 Set to 2, the version number of the protocol as documented 2347 in this specification. 2349 Packet type 2350 The type of OSPF packet, such as Link state Update or Hello 2351 Packet. 2353 Packet length 2354 The length of the entire OSPF packet in bytes, including the 2355 standard OSPF packet header. 2357 Router ID 2358 The identity of the router itself (who is originating the 2359 packet). 2361 Area ID 2362 The OSPF area that the packet is being sent into. 2364 Checksum 2365 The standard IP 16-bit one's complement checksum of the 2366 entire OSPF packet, excluding the 64-bit authentication 2367 field. This checksum is calculated as part of the 2368 appropriate authentication procedure; for some OSPF 2369 authentication types, the checksum calculation is omitted. 2370 See Section D.4 for details. 2372 AuType and Authentication 2373 Each OSPF packet exchange is authenticated. Authentication 2374 types are assigned by the protocol and are documented in 2375 Appendix D. A different authentication procedure can be 2376 used for each IP network/subnet. Autype indicates the type 2377 of authentication procedure in use. The 64-bit 2378 authentication field is then for use by the chosen 2379 authentication procedure. This procedure should be the last 2380 called when forming the packet to be sent. See Section D.4 2381 for details. 2383 The IP destination address for the packet is selected as 2384 follows. On physical point-to-point networks, the IP 2385 destination is always set to the address AllSPFRouters. On all 2386 other network types (including virtual links), the majority of 2387 OSPF packets are sent as unicasts, i.e., sent directly to the 2388 other end of the adjacency. In this case, the IP destination is 2389 just the Neighbor IP address associated with the other end of 2390 the adjacency (see Section 10). The only packets not sent as 2391 unicasts are on broadcast networks; on these networks Hello 2392 packets are sent to the multicast destination AllSPFRouters, the 2393 Designated Router and its Backup send both Link State Update 2394 Packets and Link State Acknowledgment Packets to the multicast 2395 address AllSPFRouters, while all other routers send both their 2396 Link State Update and Link State Acknowledgment Packets to the 2397 multicast address AllDRouters. 2399 Retransmissions of Link State Update packets are ALWAYS sent as 2400 unicasts. 2402 The IP source address should be set to the IP address of the 2403 sending interface. Interfaces to unnumbered point-to-point 2404 networks have no associated IP address. On these interfaces, 2405 the IP source should be set to any of the other IP addresses 2406 belonging to the router. For this reason, there must be at 2407 least one IP address assigned to the router.[2] Note that, for 2408 most purposes, virtual links act precisely the same as 2409 unnumbered point-to-point networks. However, each virtual link 2410 does have an IP interface address (discovered during the routing 2411 table build process) which is used as the IP source when sending 2412 packets over the virtual link. 2414 For more information on the format of specific OSPF packet 2415 types, consult the sections listed in Table 10. 2417 Type Packet name detailed section (transmit) 2418 _________________________________________________________ 2419 1 Hello Section 9.5 2420 2 Database description Section 10.8 2421 3 Link state request Section 10.9 2422 4 Link state update Section 13.3 2423 5 Link state ack Section 13.5 2425 Table 10: Sections describing OSPF protocol packet transmission. 2427 8.2. Receiving protocol packets 2429 Whenever a protocol packet is received by the router it is 2430 marked with the interface it was received on. For routers that 2431 have virtual links configured, it may not be immediately obvious 2432 which interface to associate the packet with. For example, 2433 consider the Router RT11 depicted in Figure 6. If RT11 receives 2434 an OSPF protocol packet on its interface to Network N8, it may 2435 want to associate the packet with the interface to Area 2, or 2436 with the virtual link to Router RT10 (which is part of the 2437 backbone). In the following, we assume that the packet is 2438 initially associated with the non-virtual link.[3] 2440 In order for the packet to be accepted at the IP level, it must 2441 pass a number of tests, even before the packet is passed to OSPF 2442 for processing: 2444 o The IP checksum must be correct. 2446 o The packet's IP destination address must be the IP address 2447 of the receiving interface, or one of the IP multicast 2448 addresses AllSPFRouters or AllDRouters. 2450 o The IP protocol specified must be OSPF (89). 2452 o Locally originated packets should not be passed on to OSPF. 2453 That is, the source IP address should be examined to make 2454 sure this is not a multicast packet that the router itself 2455 generated. 2457 Next, the OSPF packet header is verified. The fields specified 2458 in the header must match those configured for the receiving 2459 interface. If they do not, the packet should be discarded: 2461 o The version number field must specify protocol version 2. 2463 o The Area ID found in the OSPF header must be verified. If 2464 both of the following cases fail, the packet should be 2465 discarded. The Area ID specified in the header must either: 2467 (1) Match the Area ID of the receiving interface. In this 2468 case, the packet has been sent over a single hop. 2469 Therefore, the packet's IP source address is required to 2470 be on the same network as the receiving interface. This 2471 can be verified by comparing the packet's IP source 2472 address to the interface's IP address, after masking 2473 both addresses with the interface mask. This comparison 2474 should not be performed on point-to-point networks. On 2475 point-to-point networks, the interface addresses of each 2476 end of the link are assigned independently, if they are 2477 assigned at all. 2479 (2) Indicate the backbone. In this case, the packet has 2480 been sent over a virtual link. The receiving router 2481 must be an area border router, and the Router ID 2482 specified in the packet (the source router) must be the 2483 other end of a configured virtual link. The receiving 2484 interface must also attach to the virtual link's 2485 configured Transit area. If all of these checks 2486 succeed, the packet is accepted and is from now on 2487 associated with the virtual link (and the backbone 2488 area). 2490 o Packets whose IP destination is AllDRouters should only be 2491 accepted if the state of the receiving interface is DR or 2492 Backup (see Section 9.1). 2494 o The AuType specified in the packet must match the AuType 2495 specified for the associated area. 2497 o The packet must be authenticated. The authentication 2498 procedure is indicated by the setting of AuType (see 2499 Appendix D). The authentication procedure may use one or 2500 more Authentication keys, which can be configured on a per- 2501 interface basis. The authentication procedure may also 2502 verify the checksum field in the OSPF packet header (which, 2503 when used, is set to the standard IP 16-bit one's complement 2504 checksum of the OSPF packet's contents after excluding the 2505 64-bit authentication field). If the authentication 2506 procedure fails, the packet should be discarded. 2508 If the packet type is Hello, it should then be further processed 2509 by the Hello Protocol (see Section 10.5). All other packet 2510 types are sent/received only on adjacencies. This means that 2511 the packet must have been sent by one of the router's active 2512 neighbors. If the receiving interface connects to a broadcast 2513 network, Point-to-MultiPoint network or NBMA network the sender 2514 is identified by the IP source address found in the packet's IP 2515 header. If the receiving interface connects to a point-to-point 2516 network or a virtual link, the sender is identified by the 2517 Router ID (source router) found in the packet's OSPF header. 2518 The data structure associated with the receiving interface 2519 contains the list of active neighbors. Packets not matching any 2520 active neighbor are discarded. 2522 At this point all received protocol packets are associated with 2523 an active neighbor. For the further input processing of 2524 specific packet types, consult the sections listed in Table 11. 2526 Type Packet name detailed section (receive) 2527 ________________________________________________________ 2528 1 Hello Section 10.5 2529 2 Database description Section 10.6 2530 3 Link state request Section 10.7 2531 4 Link state update Section 13 2532 5 Link state ack Section 13.7 2534 Table 11: Sections describing OSPF protocol packet reception. 2536 9. The Interface Data Structure 2538 An OSPF interface is the connection between a router and a network. 2539 We assume a single OSPF interface to each attached network/subnet, 2540 although supporting multiple interfaces on a single network is 2541 considered in Appendix F. Each interface structure has at most one 2542 IP interface address. 2544 An OSPF interface can be considered to belong to the area that 2545 contains the attached network. All routing protocol packets 2546 originated by the router over this interface are labelled with the 2547 interface's Area ID. One or more router adjacencies may develop 2548 over an interface. A router's LSAs reflect the state of its 2549 interfaces and their associated adjacencies. 2551 The following data items are associated with an interface. Note 2552 that a number of these items are actually configuration for the 2553 attached network; such items must be the same for all routers 2554 connected to the network. 2556 Type 2557 The OSPF interface type is either point-to-point, broadcast, 2558 NBMA, Point-to-MultiPoint or virtual link. 2560 State 2561 The functional level of an interface. State determines whether 2562 or not full adjacencies are allowed to form over the interface. 2563 State is also reflected in the router's LSAs. 2565 IP interface address 2566 The IP address associated with the interface. This appears as 2567 the IP source address in all routing protocol packets originated 2568 over this interface. Interfaces to unnumbered point-to-point 2569 networks do not have an associated IP address. 2571 IP interface mask 2572 Also referred to as the subnet mask, this indicates the portion 2573 of the IP interface address that identifies the attached 2574 network. Masking the IP interface address with the IP interface 2575 mask yields the IP network number of the attached network. On 2576 point-to-point networks and virtual links, the IP interface mask 2577 is not defined. On these networks, the link itself is not 2578 assigned an IP network number, and so the addresses of each side 2579 of the link are assigned independently, if they are assigned at 2580 all. 2582 Area ID 2583 The Area ID of the area to which the attached network belongs. 2584 All routing protocol packets originating from the interface are 2585 labelled with this Area ID. 2587 HelloInterval 2588 The length of time, in seconds, between the Hello packets that 2589 the router sends on the interface. Advertised in Hello packets 2590 sent out this interface. 2592 RouterDeadInterval 2593 The number of seconds before the router's neighbors will declare 2594 it down, when they stop hearing the router's Hello Packets. 2595 Advertised in Hello packets sent out this interface. 2597 InfTransDelay 2598 The estimated number of seconds it takes to transmit a Link 2599 State Update Packet over this interface. LSAs contained in the 2600 Link State Update packet will have their age incremented by this 2601 amount before transmission. This value should take into account 2602 transmission and propagation delays; it must be greater than 2603 zero. 2605 Router Priority 2606 An 8-bit unsigned integer. When two routers attached to a 2607 network both attempt to become Designated Router, the one with 2608 the highest Router Priority takes precedence. A router whose 2609 Router Priority is set to 0 is ineligible to become Designated 2610 Router on the attached network. Advertised in Hello packets 2611 sent out this interface. 2613 Hello Timer 2614 An interval timer that causes the interface to send a Hello 2615 packet. This timer fires every HelloInterval seconds. Note 2616 that on non-broadcast networks a separate Hello packet is sent 2617 to each qualified neighbor. 2619 Wait Timer 2620 A single shot timer that causes the interface to exit the 2621 Waiting state, and as a consequence select a Designated Router 2622 on the network. The length of the timer is RouterDeadInterval 2623 seconds. 2625 List of neighboring routers 2626 The other routers attached to this network. This list is formed 2627 by the Hello Protocol. Adjacencies will be formed to some of 2628 these neighbors. The set of adjacent neighbors can be 2629 determined by an examination of all of the neighbors' states. 2631 Designated Router 2632 The Designated Router selected for the attached network. The 2633 Designated Router is selected on all broadcast and NBMA networks 2634 by the Hello Protocol. Two pieces of identification are kept 2635 for the Designated Router: its Router ID and its IP interface 2636 address on the network. The Designated Router advertises link 2637 state for the network; this network-LSA is labelled with the 2638 Designated Router's IP address. The Designated Router is 2639 initialized to 0.0.0.0, which indicates the lack of a Designated 2640 Router. 2642 Backup Designated Router 2643 The Backup Designated Router is also selected on all broadcast 2644 and NBMA networks by the Hello Protocol. All routers on the 2645 attached network become adjacent to both the Designated Router 2646 and the Backup Designated Router. The Backup Designated Router 2647 becomes Designated Router when the current Designated Router 2648 fails. The Backup Designated Router is initialized to 0.0.0.0, 2649 indicating the lack of a Backup Designated Router. 2651 Interface output cost(s) 2652 The cost of sending a data packet on the interface, expressed in 2653 the link state metric. This is advertised as the link cost for 2654 this interface in the router-LSA. There may be a separate cost 2655 for each IP Type of Service. The cost of an interface must be 2656 greater than zero. 2658 RxmtInterval 2659 The number of seconds between LSA retransmissions, for 2660 adjacencies belonging to this interface. Also used when 2661 retransmitting Database Description and Link State Request 2662 Packets. 2664 AuType 2665 The type of authentication used on the attached network/subnet. 2666 Authentication types are defined in Appendix D. All OSPF packet 2667 exchanges are authenticated. Different authentication schemes 2668 may be used on different networks/subnets. 2670 Authentication key 2671 This configured data allows the authentication procedure to 2672 generate and/or verify OSPF protocol packets. The 2673 Authentication key can be configured on a per-interface basis. 2674 For example, if the AuType indicates simple password, the 2675 Authentication key would be a 64-bit clear password which is 2676 inserted into the OSPF packet header. If instead Autype 2677 indicates Cryptographic authentication, then the Authentication 2678 key is a shared secret which enables the generation/verification 2679 of message digests which are appended to the OSPF protocol 2680 packets. When Cryptographic authentication is used, multiple 2681 simultaneous keys are supported in order to achieve smooth key 2682 transition (see Section D.3). 2684 9.1. Interface states 2686 The various states that router interfaces may attain is 2687 documented in this section. The states are listed in order of 2688 progressing functionality. For example, the inoperative state 2689 is listed first, followed by a list of intermediate states 2690 before the final, fully functional state is achieved. The 2691 specification makes use of this ordering by sometimes making 2692 references such as "those interfaces in state greater than X". 2693 Figure 11 shows the graph of interface state changes. The arcs 2695 +----+ UnloopInd +--------+ 2696 |Down|<--------------|Loopback| 2697 +----+ +--------+ 2698 | 2699 |InterfaceUp 2700 +-------+ | +--------------+ 2701 |Waiting|<-+-------------->|Point-to-point| 2702 +-------+ +--------------+ 2703 | 2704 WaitTimer|BackupSeen 2705 | 2706 | 2707 | NeighborChange 2708 +------+ +-+<---------------- +-------+ 2709 |Backup|<----------|?|----------------->|DROther| 2710 +------+---------->+-+<-----+ +-------+ 2711 Neighbor | | 2712 Change | |Neighbor 2713 | |Change 2714 | +--+ 2715 +---->|DR| 2716 +--+ 2718 Figure 11: Interface State changes 2720 In addition to the state transitions pictured, 2721 Event InterfaceDown always forces Down State, and 2722 Event LoopInd always forces Loopback State 2723 of the graph are labelled with the event causing the state 2724 change. These events are documented in Section 9.2. The 2725 interface state machine is described in more detail in Section 2726 9.3. 2728 Down 2729 This is the initial interface state. In this state, the 2730 lower-level protocols have indicated that the interface is 2731 unusable. No protocol traffic at all will be sent or 2732 received on such a interface. In this state, interface 2733 parameters should be set to their initial values. All 2734 interface timers should be disabled, and there should be no 2735 adjacencies associated with the interface. 2737 Loopback 2738 In this state, the router's interface to the network is 2739 looped back. The interface may be looped back in hardware 2740 or software. The interface will be unavailable for regular 2741 data traffic. However, it may still be desirable to gain 2742 information on the quality of this interface, either through 2743 sending ICMP pings to the interface or through something 2744 like a bit error test. For this reason, IP packets may 2745 still be addressed to an interface in Loopback state. To 2746 facilitate this, such interfaces are advertised in router- 2747 LSAs as single host routes, whose destination is the IP 2748 interface address.[4] 2750 Waiting 2751 In this state, the router is trying to determine the 2752 identity of the (Backup) Designated Router for the network. 2753 To do this, the router monitors the Hello Packets it 2754 receives. The router is not allowed to elect a Backup 2755 Designated Router nor a Designated Router until it 2756 transitions out of Waiting state. This prevents unnecessary 2757 changes of (Backup) Designated Router. 2759 Point-to-point 2760 In this state, the interface is operational, and connects 2761 either to a physical point-to-point network or to a virtual 2762 link. Upon entering this state, the router attempts to form 2763 an adjacency with the neighboring router. Hello Packets are 2764 sent to the neighbor every HelloInterval seconds. 2766 DR Other 2767 The interface is to a broadcast or NBMA network on which 2768 another router has been selected to be the Designated 2769 Router. In this state, the router itself has not been 2770 selected Backup Designated Router either. The router forms 2771 adjacencies to both the Designated Router and the Backup 2772 Designated Router (if they exist). 2774 Backup 2775 In this state, the router itself is the Backup Designated 2776 Router on the attached network. It will be promoted to 2777 Designated Router when the present Designated Router fails. 2778 The router establishes adjacencies to all other routers 2779 attached to the network. The Backup Designated Router 2780 performs slightly different functions during the Flooding 2781 Procedure, as compared to the Designated Router (see Section 2782 13.3). See Section 7.4 for more details on the functions 2783 performed by the Backup Designated Router. 2785 DR In this state, this router itself is the Designated Router 2786 on the attached network. Adjacencies are established to all 2787 other routers attached to the network. The router must also 2788 originate a network-LSA for the network node. The network- 2789 LSA will contain links to all routers (including the 2790 Designated Router itself) attached to the network. See 2791 Section 7.3 for more details on the functions performed by 2792 the Designated Router. 2794 9.2. Events causing interface state changes 2796 State changes can be effected by a number of events. These 2797 events are pictured as the labelled arcs in Figure 11. The 2798 label definitions are listed below. For a detailed explanation 2799 of the effect of these events on OSPF protocol operation, 2800 consult Section 9.3. 2802 InterfaceUp 2803 Lower-level protocols have indicated that the network 2804 interface is operational. This enables the interface to 2805 transition out of Down state. On virtual links, the 2806 interface operational indication is actually a result of the 2807 shortest path calculation (see Section 16.7). 2809 WaitTimer 2810 The Wait Timer has fired, indicating the end of the waiting 2811 period that is required before electing a (Backup) 2812 Designated Router. 2814 BackupSeen 2815 The router has detected the existence or non-existence of a 2816 Backup Designated Router for the network. This is done in 2817 one of two ways. First, an Hello Packet may be received 2818 from a neighbor claiming to be itself the Backup Designated 2819 Router. Alternatively, an Hello Packet may be received from 2820 a neighbor claiming to be itself the Designated Router, and 2821 indicating that there is no Backup Designated Router. In 2822 either case there must be bidirectional communication with 2823 the neighbor, i.e., the router must also appear in the 2824 neighbor's Hello Packet. This event signals an end to the 2825 Waiting state. 2827 NeighborChange 2828 There has been a change in the set of bidirectional 2829 neighbors associated with the interface. The (Backup) 2830 Designated Router needs to be recalculated. The following 2831 neighbor changes lead to the NeighborChange event. For an 2832 explanation of neighbor states, see Section 10.1. 2834 o Bidirectional communication has been established to a 2835 neighbor. In other words, the state of the neighbor has 2836 transitioned to 2-Way or higher. 2838 o There is no longer bidirectional communication with a 2839 neighbor. In other words, the state of the neighbor has 2840 transitioned to Init or lower. 2842 o One of the bidirectional neighbors is newly declaring 2843 itself as either Designated Router or Backup Designated 2844 Router. This is detected through examination of that 2845 neighbor's Hello Packets. 2847 o One of the bidirectional neighbors is no longer 2848 declaring itself as Designated Router, or is no longer 2849 declaring itself as Backup Designated Router. This is 2850 again detected through examination of that neighbor's 2851 Hello Packets. 2853 o The advertised Router Priority for a bidirectional 2854 neighbor has changed. This is again detected through 2855 examination of that neighbor's Hello Packets. 2857 LoopInd 2858 An indication has been received that the interface is now 2859 looped back to itself. This indication can be received 2860 either from network management or from the lower level 2861 protocols. 2863 UnloopInd 2864 An indication has been received that the interface is no 2865 longer looped back. As with the LoopInd event, this 2866 indication can be received either from network management or 2867 from the lower level protocols. 2869 InterfaceDown 2870 Lower-level protocols indicate that this interface is no 2871 longer functional. No matter what the current interface 2872 state is, the new interface state will be Down. 2874 9.3. The Interface state machine 2876 A detailed description of the interface state changes follows. 2877 Each state change is invoked by an event (Section 9.2). This 2878 event may produce different effects, depending on the current 2879 state of the interface. For this reason, the state machine 2880 below is organized by current interface state and received 2881 event. Each entry in the state machine describes the resulting 2882 new interface state and the required set of additional actions. 2884 When an interface's state changes, it may be necessary to 2885 originate a new router-LSA. See Section 12.4 for more details. 2887 Some of the required actions below involve generating events for 2888 the neighbor state machine. For example, when an interface 2889 becomes inoperative, all neighbor connections associated with 2890 the interface must be destroyed. For more information on the 2891 neighbor state machine, see Section 10.3. 2893 State(s): Down 2895 Event: InterfaceUp 2897 New state: Depends upon action routine 2899 Action: Start the interval Hello Timer, enabling the 2900 periodic sending of Hello packets out the interface. 2901 If the attached network is a physical point-to-point 2902 network, Point-to-MultiPoint network or virtual 2903 link, the interface state transitions to Point-to- 2904 Point. Else, if the router is not eligible to 2905 become Designated Router the interface state 2906 transitions to DR Other. 2908 Otherwise, the attached network is a broadcast or 2909 NBMA network and the router is eligible to become 2910 Designated Router. In this case, in an attempt to 2911 discover the attached network's Designated Router 2912 the interface state is set to Waiting and the single 2913 shot Wait Timer is started. Additionally, if the 2914 network is an NBMA network examine the configured 2915 list of neighbors for this interface and generate 2916 the neighbor event Start for each neighbor that is 2917 also eligible to become Designated Router. 2919 State(s): Waiting 2921 Event: BackupSeen 2923 New state: Depends upon action routine. 2925 Action: Calculate the attached network's Backup Designated 2926 Router and Designated Router, as shown in Section 2927 9.4. As a result of this calculation, the new state 2928 of the interface will be either DR Other, Backup or 2929 DR. 2931 State(s): Waiting 2933 Event: WaitTimer 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): DR Other, Backup or DR 2945 Event: NeighborChange 2947 New state: Depends upon action routine. 2949 Action: Recalculate 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): Any State 2957 Event: InterfaceDown 2959 New state: Down 2961 Action: All interface variables are reset, and interface 2962 timers disabled. Also, all neighbor connections 2963 associated with the interface are destroyed. This 2964 is done by generating the event KillNbr on all 2965 associated neighbors (see Section 10.2). 2967 State(s): Any State 2969 Event: LoopInd 2971 New state: Loopback 2973 Action: Since this interface is no longer connected to the 2974 attached network the actions associated with the 2975 above InterfaceDown event are executed. 2977 State(s): Loopback 2979 Event: UnloopInd 2981 New state: Down 2983 Action: No actions are necessary. For example, the 2984 interface variables have already been reset upon 2985 entering the Loopback state. Note that reception of 2986 an InterfaceUp event is necessary before the 2987 interface again becomes fully functional. 2989 9.4. Electing the Designated Router 2991 This section describes the algorithm used for calculating a 2992 network's Designated Router and Backup Designated Router. This 2993 algorithm is invoked by the Interface state machine. The 2994 initial time a router runs the election algorithm for a network, 2995 the network's Designated Router and Backup Designated Router are 2996 initialized to 0.0.0.0. This indicates the lack of both a 2997 Designated Router and a Backup Designated Router. 2999 The Designated Router election algorithm proceeds as follows: 3000 Call the router doing the calculation Router X. The list of 3001 neighbors attached to the network and having established 3002 bidirectional communication with Router X is examined. This 3003 list is precisely the collection of Router X's neighbors (on 3004 this network) whose state is greater than or equal to 2-Way (see 3005 Section 10.1). Router X itself is also considered to be on the 3006 list. Discard all routers from the list that are ineligible to 3007 become Designated Router. (Routers having Router Priority of 0 3008 are ineligible to become Designated Router.) The following 3009 steps are then executed, considering only those routers that 3010 remain on the list: 3012 (1) Note the current values for the network's Designated Router 3013 and Backup Designated Router. This is used later for 3014 comparison purposes. 3016 (2) Calculate the new Backup Designated Router for the network 3017 as follows. Only those routers on the list that have not 3018 declared themselves to be Designated Router are eligible to 3019 become Backup Designated Router. If one or more of these 3020 routers have declared themselves Backup Designated Router 3021 (i.e., they are currently listing themselves as Backup 3022 Designated Router, but not as Designated Router, in their 3023 Hello Packets) the one having highest Router Priority is 3024 declared to be Backup Designated Router. In case of a tie, 3025 the one having the highest Router ID is chosen. If no 3026 routers have declared themselves Backup Designated Router, 3027 choose the router having highest Router Priority, (again 3028 excluding those routers who have declared themselves 3029 Designated Router), and again use the Router ID to break 3030 ties. 3032 (3) Calculate the new Designated Router for the network as 3033 follows. If one or more of the routers have declared 3034 themselves Designated Router (i.e., they are currently 3035 listing themselves as Designated Router in their Hello 3036 Packets) the one having highest Router Priority is declared 3037 to be Designated Router. In case of a tie, the one having 3038 the highest Router ID is chosen. If no routers have 3039 declared themselves Designated Router, assign the Designated 3040 Router to be the same as the newly elected Backup Designated 3041 Router. 3043 (4) If Router X is now newly the Designated Router or newly the 3044 Backup Designated Router, or is now no longer the Designated 3045 Router or no longer the Backup Designated Router, repeat 3046 steps 2 and 3, and then proceed to step 5. For example, if 3047 Router X is now the Designated Router, when step 2 is 3048 repeated X will no longer be eligible for Backup Designated 3049 Router election. Among other things, this will ensure that 3050 no router will declare itself both Backup Designated Router 3051 and Designated Router.[5] 3053 (5) As a result of these calculations, the router itself may now 3054 be Designated Router or Backup Designated Router. See 3055 Sections 7.3 and 7.4 for the additional duties this would 3056 entail. The router's interface state should be set 3057 accordingly. If the router itself is now Designated Router, 3058 the new interface state is DR. If the router itself is now 3059 Backup Designated Router, the new interface state is Backup. 3060 Otherwise, the new interface state is DR Other. 3062 (6) If the attached network is an NBMA network, and the router 3063 itself has just become either Designated Router or Backup 3064 Designated Router, it must start sending Hello Packets to 3065 those neighbors that are not eligible to become Designated 3066 Router (see Section 9.5.1). This is done by invoking the 3067 neighbor event Start for each neighbor having a Router 3068 Priority of 0. 3070 (7) If the above calculations have caused the identity of either 3071 the Designated Router or Backup Designated Router to change, 3072 the set of adjacencies associated with this interface will 3073 need to be modified. Some adjacencies may need to be 3074 formed, and others may need to be broken. To accomplish 3075 this, invoke the event AdjOK? on all neighbors whose state 3076 is at least 2-Way. This will cause their eligibility for 3077 adjacency to be reexamined (see Sections 10.3 and 10.4). 3079 The reason behind the election algorithm's complexity is the 3080 desire for an orderly transition from Backup Designated Router 3081 to Designated Router, when the current Designated Router fails. 3082 This orderly transition is ensured through the introduction of 3083 hysteresis: no new Backup Designated Router can be chosen until 3084 the old Backup accepts its new Designated Router 3085 responsibilities. 3087 The above procedure may elect the same router to be both 3088 Designated Router and Backup Designated Router, although that 3089 router will never be the calculating router (Router X) itself. 3091 The elected Designated Router may not be the router having the 3092 highest Router Priority, nor will the Backup Designated Router 3093 necessarily have the second highest Router Priority. If Router 3094 X is not itself eligible to become Designated Router, it is 3095 possible that neither a Backup Designated Router nor a 3096 Designated Router will be selected in the above procedure. Note 3097 also that if Router X is the only attached router that is 3098 eligible to become Designated Router, it will select itself as 3099 Designated Router and there will be no Backup Designated Router 3100 for the network. 3102 9.5. Sending Hello packets 3104 Hello packets are sent out each functioning router interface. 3105 They are used to discover and maintain neighbor 3106 relationships.[6] On broadcast and NBMA networks, Hello Packets 3107 are also used to elect the Designated Router and Backup 3108 Designated Router. 3110 The format of an Hello packet is detailed in Section A.3.2. The 3111 Hello Packet contains the router's Router Priority (used in 3112 choosing the Designated Router), and the interval between Hello 3113 Packets sent out the interface (HelloInterval). The Hello 3114 Packet also indicates how often a neighbor must be heard from to 3115 remain active (RouterDeadInterval). Both HelloInterval and 3116 RouterDeadInterval must be the same for all routers attached to 3117 a common network. The Hello packet also contains the IP address 3118 mask of the attached network (Network Mask). On unnumbered 3119 point-to-point networks and on virtual links this field should 3120 be set to 0.0.0.0. 3122 The Hello packet's Options field describes the router's optional 3123 OSPF capabilities. Two optional capabilities are defined in 3124 this specification (see Sections 4.5 and A.2). The T-bit of the 3125 Options field should be set if the router is capable of 3126 calculating separate routes for each IP TOS. The E-bit should 3127 be set if and only if the attached area is capable of processing 3128 AS-external-LSAs (i.e., it is not a stub area). If the E-bit is 3129 set incorrectly the neighboring routers will refuse to accept 3130 the Hello Packet (see Section 10.5). Unrecognized bits in the 3131 Hello Packet's Options field should be set to zero. 3133 In order to ensure two-way communication between adjacent 3134 routers, the Hello packet contains the list of all routers on 3135 the network from which Hello Packets have been seen recently. 3136 The Hello packet also contains the router's current choice for 3137 Designated Router and Backup Designated Router. A value of 3138 0.0.0.0 in these fields means that one has not yet been 3139 selected. 3141 On broadcast networks and physical point-to-point networks, 3142 Hello packets are sent every HelloInterval seconds to the IP 3143 multicast address AllSPFRouters. On virtual links, Hello 3144 packets are sent as unicasts (addressed directly to the other 3145 end of the virtual link) every HelloInterval seconds. On Point- 3146 to-MultiPoint networks, separate Hello packets are sent to each 3147 attached neighbor every HelloInterval seconds. Sending of Hello 3148 packets on NBMA networks is covered in the next section. 3150 9.5.1. Sending Hello packets on NBMA networks 3152 Static configuration information may be necessary in order 3153 for the Hello Protocol to function on non-broadcast networks 3154 (see Sections C.5 and C.6). On NBMA networks, every 3155 attached router which is eligible to become Designated 3156 Router becomes aware of all of its neighbors on the network 3157 (either through configuration or by some unspecified 3158 mechanism). Each neighbor is labelled with the neighbor's 3159 Designated Router eligibility. 3161 The interface state must be at least Waiting for any Hello 3162 Packets to be sent out the NBMA interface. Hello Packets 3163 are then sent directly (as unicasts) to some subset of a 3164 router's neighbors. Sometimes an Hello Packet is sent 3165 periodically on a timer; at other times it is sent as a 3166 response to a received Hello Packet. A router's hello- 3167 sending behavior varies depending on whether the router 3168 itself is eligible to become Designated Router. 3170 If the router is eligible to become Designated Router, it 3171 must periodically send Hello Packets to all neighbors that 3172 are also eligible. In addition, if the router is itself the 3173 Designated Router or Backup Designated Router, it must also 3174 send periodic Hello Packets to all other neighbors. This 3175 means that any two eligible routers are always exchanging 3176 Hello Packets, which is necessary for the correct operation 3177 of the Designated Router election algorithm. To minimize 3178 the number of Hello Packets sent, the number of eligible 3179 routers on an NBMA network should be kept small. 3181 If the router is not eligible to become Designated Router, 3182 it must periodically send Hello Packets to both the 3183 Designated Router and the Backup Designated Router (if they 3184 exist). It must also send an Hello Packet in reply to an 3185 Hello Packet received from any eligible neighbor (other than 3186 the current Designated Router and Backup Designated Router). 3187 This is needed to establish an initial bidirectional 3188 relationship with any potential Designated Router. 3190 When sending Hello packets periodically to any neighbor, the 3191 interval between Hello Packets is determined by the 3192 neighbor's state. If the neighbor is in state Down, Hello 3193 Packets are sent every PollInterval seconds. Otherwise, 3194 Hello Packets are sent every HelloInterval seconds. 3196 10. The Neighbor Data Structure 3198 An OSPF router converses with its neighboring routers. Each 3199 separate conversation is described by a "neighbor data structure". 3200 Each conversation is bound to a particular OSPF router interface, 3201 and is identified either by the neighboring router's OSPF Router ID 3202 or by its Neighbor IP address (see below). Thus if the OSPF router 3203 and another router have multiple attached networks in common, 3204 multiple conversations ensue, each described by a unique neighbor 3205 data structure. Each separate conversation is loosely referred to 3206 in the text as being a separate "neighbor". 3208 The neighbor data structure contains all information pertinent to 3209 the forming or formed adjacency between the two neighbors. 3210 (However, remember that not all neighbors become adjacent.) An 3211 adjacency can be viewed as a highly developed conversation between 3212 two routers. 3214 State 3215 The functional level of the neighbor conversation. This is 3216 described in more detail in Section 10.1. 3218 Inactivity Timer 3219 A single shot timer whose firing indicates that no Hello Packet 3220 has been seen from this neighbor recently. The length of the 3221 timer is RouterDeadInterval seconds. 3223 Master/Slave 3224 When the two neighbors are exchanging databases, they form a 3225 master/slave relationship. The master sends the first Database 3226 Description Packet, and is the only part that is allowed to 3227 retransmit. The slave can only respond to the master's Database 3228 Description Packets. The master/slave relationship is 3229 negotiated in state ExStart. 3231 DD Sequence Number 3232 The DD Sequence number of the Database Description packet that 3233 is currently being sent to the neighbor. 3235 Last received Database Description packet 3236 The initialize(I), more (M) and master(MS) bits, Options field, 3237 and DD sequence number contained in the last Database 3238 Description packet received from the neighbor. Used to determine 3239 whether the next Database Description packet received from the 3240 neighbor is a duplicate. 3242 Neighbor ID 3243 The OSPF Router ID of the neighboring router. The Neighbor ID 3244 is learned when Hello packets are received from the neighbor, or 3245 is configured if this is a virtual adjacency (see Section C.4). 3247 Neighbor Priority 3248 The Router Priority of the neighboring router. Contained in the 3249 neighbor's Hello packets, this item is used when selecting the 3250 Designated Router for the attached network. 3252 Neighbor IP address 3253 The IP address of the neighboring router's interface to the 3254 attached network. Used as the Destination IP address when 3255 protocol packets are sent as unicasts along this adjacency. 3256 Also used in router-LSAs as the Link ID for the attached network 3257 if the neighboring router is selected to be Designated Router 3258 (see Section 12.4.1). The Neighbor IP address is learned when 3259 Hello packets are received from the neighbor. For virtual 3260 links, the Neighbor IP address is learned during the routing 3261 table build process (see Section 15). 3263 Neighbor Options 3264 The optional OSPF capabilities supported by the neighbor. 3265 Learned during the Database Exchange process (see Section 10.6). 3266 The neighbor's optional OSPF capabilities are also listed in its 3267 Hello packets. This enables received Hello Packets to be 3268 rejected (i.e., neighbor relationships will not even start to 3269 form) if there is a mismatch in certain crucial OSPF 3270 capabilities (see Section 10.5). The optional OSPF capabilities 3271 are documented in Section 4.5. 3273 Neighbor's Designated Router 3274 The neighbor's idea of the Designated Router. If this is the 3275 neighbor itself, this is important in the local calculation of 3276 the Designated Router. Defined only on broadcast and NBMA 3277 networks. 3279 Neighbor's Backup Designated Router 3280 The neighbor's idea of the Backup Designated Router. If this is 3281 the neighbor itself, this is important in the local calculation 3282 of the Backup Designated Router. Defined only on broadcast and 3283 NBMA networks. 3285 The next set of variables are lists of LSAs. These lists describe 3286 subsets of the area link-state database. This memo defines five 3287 distinct types of LSAs, all of which may be present in an area 3288 link-state database: router-LSAs, network-LSAs, and Type 3 and 4 3289 summary-LSAs (all stored in the area data structure), and AS- 3290 external-LSAs (stored in the global data structure). 3292 Link state retransmission list 3293 The list of LSAs that have been flooded but not acknowledged on 3294 this adjacency. These will be retransmitted at intervals until 3295 they are acknowledged, or until the adjacency is destroyed. 3297 Database summary list 3298 The complete list of LSAs that make up the area link-state 3299 database, at the moment the neighbor goes into Database Exchange 3300 state. This list is sent to the neighbor in Database 3301 Description packets. 3303 Link state request list 3304 The list of LSAs that need to be received from this neighbor in 3305 order to synchronize the two neighbors' link-state databases. 3306 This list is created as Database Description packets are 3307 received, and is then sent to the neighbor in Link State Request 3308 packets. The list is depleted as appropriate Link State Update 3309 packets are received. 3311 10.1. Neighbor states 3313 The state of a neighbor (really, the state of a conversation 3314 being held with a neighboring router) is documented in the 3315 following sections. The states are listed in order of 3316 progressing functionality. For example, the inoperative state 3317 is listed first, followed by a list of intermediate states 3318 before the final, fully functional state is achieved. The 3319 specification makes use of this ordering by sometimes making 3320 references such as "those neighbors/adjacencies in state greater 3321 than X". Figures 12 and 13 show the graph of neighbor state 3322 changes. The arcs of the graphs are labelled with the event 3323 causing the state change. The neighbor events are documented in 3324 Section 10.2. 3326 The graph in Figure 12 shows the state changes effected by the 3327 Hello Protocol. The Hello Protocol is responsible for neighbor 3328 acquisition and maintenance, and for ensuring two way 3329 communication between neighbors. 3331 The graph in Figure 13 shows the forming of an adjacency. Not 3332 every two neighboring routers become adjacent (see Section 3333 10.4). The adjacency starts to form when the neighbor is in 3334 state ExStart. After the two routers discover their 3335 master/slave status, the state transitions to Exchange. At this 3336 point the neighbor starts to be used in the flooding procedure, 3337 and the two neighboring routers begin synchronizing their 3338 databases. When this synchronization is finished, the neighbor 3339 is in state Full and we say that the two routers are fully 3340 adjacent. At this point the adjacency is listed in LSAs. 3342 For a more detailed description of neighbor state changes, 3344 +----+ 3345 |Down| 3346 +----+ 3347 |\ 3348 | \Start 3349 | \ +-------+ 3350 Hello | +---->|Attempt| 3351 Received | +-------+ 3352 | | 3353 +----+<-+ |HelloReceived 3354 |Init|<---------------+ 3355 +----+<--------+ 3356 | | 3357 |2-Way |1-Way 3358 |Received |Received 3359 | | 3360 +-------+ | +-----+ 3361 |ExStart|<--------+------->|2-Way| 3362 +-------+ +-----+ 3364 Figure 12: Neighbor state changes (Hello Protocol) 3366 In addition to the state transitions pictured, 3367 Event KillNbr always forces Down State, 3368 Event InactivityTimer always forces Down State, 3369 Event LLDown always forces Down State 3370 +-------+ 3371 |ExStart| 3372 +-------+ 3373 | 3374 NegotiationDone| 3375 +->+--------+ 3376 |Exchange| 3377 +--+--------+ 3378 | 3379 Exchange| 3380 Done | 3381 +----+ | +-------+ 3382 |Full|<---------+----->|Loading| 3383 +----+<-+ +-------+ 3384 | LoadingDone | 3385 +------------------+ 3387 Figure 13: Neighbor state changes (Database Exchange) 3389 In addition to the state transitions pictured, 3390 Event SeqNumberMismatch forces ExStart state, 3391 Event BadLSReq forces ExStart state, 3392 Event 1-Way forces Init state, 3393 Event KillNbr always forces Down State, 3394 Event InactivityTimer always forces Down State, 3395 Event LLDown always forces Down State, 3396 Event AdjOK? leads to adjacency forming/breaking 3398 together with the additional actions involved in each change, 3399 see Section 10.3. 3401 Down 3402 This is the initial state of a neighbor conversation. It 3403 indicates that there has been no recent information received 3404 from the neighbor. On NBMA networks, Hello packets may 3405 still be sent to "Down" neighbors, although at a reduced 3406 frequency (see Section 9.5.1). 3408 Attempt 3409 This state is only valid for neighbors attached to NBMA 3410 networks. It indicates that no recent information has been 3411 received from the neighbor, but that a more concerted effort 3412 should be made to contact the neighbor. This is done by 3413 sending the neighbor Hello packets at intervals of 3414 HelloInterval (see Section 9.5.1). 3416 Init 3417 In this state, an Hello packet has recently been seen from 3418 the neighbor. However, bidirectional communication has not 3419 yet been established with the neighbor (i.e., the router 3420 itself did not appear in the neighbor's Hello packet). All 3421 neighbors in this state (or higher) are listed in the Hello 3422 packets sent from the associated interface. 3424 2-Way 3425 In this state, communication between the two routers is 3426 bidirectional. This has been assured by the operation of 3427 the Hello Protocol. This is the most advanced state short 3428 of beginning adjacency establishment. The (Backup) 3429 Designated Router is selected from the set of neighbors in 3430 state 2-Way or greater. 3432 ExStart 3433 This is the first step in creating an adjacency between the 3434 two neighboring routers. The goal of this step is to decide 3435 which router is the master, and to decide upon the initial 3436 DD sequence number. Neighbor conversations in this state or 3437 greater are called adjacencies. 3439 Exchange 3440 In this state the router is describing its entire link state 3441 database by sending Database Description packets to the 3442 neighbor. Each Database Description Packet has a DD 3443 sequence number, and is explicitly acknowledged. Only one 3444 Database Description Packet is allowed outstanding at any 3445 one time. In this state, Link State Request Packets may 3446 also be sent asking for the neighbor's more recent LSAs. 3447 All adjacencies in Exchange state or greater are used by the 3448 flooding procedure. In fact, these adjacencies are fully 3449 capable of transmitting and receiving all types of OSPF 3450 routing protocol packets. 3452 Loading 3453 In this state, Link State Request packets are sent to the 3454 neighbor asking for the more recent LSAs that have been 3455 discovered (but not yet received) in the Exchange state. 3457 Full 3458 In this state, the neighboring routers are fully adjacent. 3459 These adjacencies will now appear in router-LSAs and 3460 network-LSAs. 3462 10.2. Events causing neighbor state changes 3464 State changes can be effected by a number of events. These 3465 events are shown in the labels of the arcs in Figures 12 and 13. 3466 The label definitions are as follows: 3468 HelloReceived 3469 An Hello packet has been received from the neighbor. 3471 Start 3472 This is an indication that Hello Packets should now be sent 3473 to the neighbor at intervals of HelloInterval seconds. This 3474 event is generated only for neighbors associated with NBMA 3475 networks. 3477 2-WayReceived 3478 Bidirectional communication has been realized between the 3479 two neighboring routers. This is indicated by the router 3480 seeing itself in the neighbor's Hello packet. 3482 NegotiationDone 3483 The Master/Slave relationship has been negotiated, and DD 3484 sequence numbers have been exchanged. This signals the 3485 start of the sending/receiving of Database Description 3486 packets. For more information on the generation of this 3487 event, consult Section 10.8. 3489 ExchangeDone 3490 Both routers have successfully transmitted a full sequence 3491 of Database Description packets. Each router now knows what 3492 parts of its link state database are out of date. For more 3493 information on the generation of this event, consult Section 3494 10.8. 3496 BadLSReq 3497 A Link State Request has been received for an LSA not 3498 contained in the database. This indicates an error in the 3499 Database Exchange process. 3501 Loading Done 3502 Link State Updates have been received for all out-of-date 3503 portions of the database. This is indicated by the Link 3504 state request list becoming empty after the Database 3505 Exchange process has completed. 3507 AdjOK? 3508 A decision must be made as to whether an adjacency should be 3509 established/maintained with the neighbor. This event will 3510 start some adjacencies forming, and destroy others. 3512 The following events cause well developed neighbors to revert to 3513 lesser states. Unlike the above events, these events may occur 3514 when the neighbor conversation is in any of a number of states. 3516 SeqNumberMismatch 3517 A Database Description packet has been received that either 3518 a) has an unexpected DD sequence number, b) unexpectedly has 3519 the Init bit set or c) has an Options field differing from 3520 the last Options field received in a Database Description 3521 packet. Any of these conditions indicate that some error 3522 has occurred during adjacency establishment. 3524 1-Way 3525 An Hello packet has been received from the neighbor, in 3526 which the router is not mentioned. This indicates that 3527 communication with the neighbor is not bidirectional. 3529 KillNbr 3530 This is an indication that all communication with the 3531 neighbor is now impossible, forcing the neighbor to 3532 revert to Down state. 3534 InactivityTimer 3535 The inactivity Timer has fired. This means that no Hello 3536 packets have been seen recently from the neighbor. The 3537 neighbor reverts to Down state. 3539 LLDown 3540 This is an indication from the lower level protocols that 3541 the neighbor is now unreachable. For example, on an X.25 3542 network this could be indicated by an X.25 clear indication 3543 with appropriate cause and diagnostic fields. This event 3544 forces the neighbor into Down state. 3546 10.3. The Neighbor state machine 3548 A detailed description of the neighbor state changes follows. 3549 Each state change is invoked by an event (Section 10.2). This 3550 event may produce different effects, depending on the current 3551 state of the neighbor. For this reason, the state machine below 3552 is organized by current neighbor state and received event. Each 3553 entry in the state machine describes the resulting new neighbor 3554 state and the required set of additional actions. 3556 When a neighbor's state changes, it may be necessary to rerun 3557 the Designated Router election algorithm. This is determined by 3558 whether the interface NeighborChange event is generated (see 3559 Section 9.2). Also, if the Interface is in DR state (the router 3560 is itself Designated Router), changes in neighbor state may 3561 cause a new network-LSA to be originated (see Section 12.4). 3563 When the neighbor state machine needs to invoke the interface 3564 state machine, it should be done as a scheduled task (see 3565 Section 4.4). This simplifies things, by ensuring that neither 3566 state machine will be executed recursively. 3568 State(s): Down 3570 Event: Start 3572 New state: Attempt 3574 Action: Send an Hello Packet to the neighbor (this neighbor 3575 is always associated with an NBMA network) and start 3576 the Inactivity Timer for the neighbor. The timer's 3577 later firing would indicate that communication with 3578 the neighbor was not attained. 3580 State(s): Attempt 3582 Event: HelloReceived 3584 New state: Init 3586 Action: Restart the Inactivity Timer for the neighbor, since 3587 the neighbor has now been heard from. 3589 State(s): Down 3591 Event: HelloReceived 3593 New state: Init 3595 Action: Start the Inactivity Timer for the neighbor. The 3596 timer's later firing would indicate that the 3597 neighbor is dead. 3599 State(s): Init or greater 3601 Event: HelloReceived 3603 New state: No state change. 3605 Action: Restart the Inactivity Timer for the neighbor, since 3606 the neighbor has again been heard from. 3608 State(s): Init 3610 Event: 2-WayReceived 3612 New state: Depends upon action routine. 3614 Action: Determine whether an adjacency should be established 3615 with the neighbor (see Section 10.4). If not, the 3616 new neighbor state is 2-Way. 3618 Otherwise (an adjacency should be established) the 3619 neighbor state transitions to ExStart. Upon 3620 entering this state, the router increments the DD 3621 sequence number in the neighbor data structure. If 3622 this is the first time that an adjacency has been 3623 attempted, the DD sequence number should be assigned 3624 some unique value (like the time of day clock). It 3625 then declares itself master (sets the master/slave 3626 bit to master), and starts sending Database 3627 Description Packets, with the initialize (I), more 3628 (M) and master (MS) bits set. This Database 3629 Description Packet should be otherwise empty. This 3630 Database Description Packet should be retransmitted 3631 at intervals of RxmtInterval until the next state is 3632 entered (see Section 10.8). 3634 State(s): ExStart 3636 Event: NegotiationDone 3638 New state: Exchange 3640 Action: The router must list the contents of its entire area 3641 link state database in the neighbor Database summary 3642 list. The area link state database consists of the 3643 router-LSAs, network-LSAs and summary-LSAs contained 3644 in the area structure, along with the AS-external- 3645 LSAs contained in the global structure. AS- 3646 external-LSAs are omitted from a virtual neighbor's 3647 Database summary list. AS-external-LSAs are omitted 3648 from the Database summary list if the area has been 3649 configured as a stub (see Section 3.6). LSAs whose 3650 age is equal to MaxAge are instead added to the 3651 neighbor's Link state retransmission list. A 3652 summary of the Database summary list will be sent to 3653 the neighbor in Database Description packets. Each 3654 Database Description Packet has a DD sequence 3655 number, and is explicitly acknowledged. Only one 3656 Database Description Packet is allowed outstanding 3657 at any one time. For more detail on the sending and 3658 receiving of Database Description packets, see 3659 Sections 10.8 and 10.6. 3661 State(s): Exchange 3663 Event: ExchangeDone 3665 New state: Depends upon action routine. 3667 Action: If the neighbor Link state request list is empty, 3668 the new neighbor state is Full. No other action is 3669 required. This is an adjacency's final state. 3671 Otherwise, the new neighbor state is Loading. Start 3672 (or continue) sending Link State Request packets to 3673 the neighbor (see Section 10.9). These are requests 3674 for the neighbor's more recent LSAs (which were 3675 discovered but not yet received in the Exchange 3676 state). These LSAs are listed in the Link state 3677 request list associated with the neighbor. 3679 State(s): Loading 3681 Event: Loading Done 3683 New state: Full 3685 Action: No action required. This is an adjacency's final 3686 state. 3688 State(s): 2-Way 3689 Event: AdjOK? 3691 New state: Depends upon action routine. 3693 Action: Determine whether an adjacency should be formed with 3694 the neighboring router (see Section 10.4). If not, 3695 the neighbor state remains at 2-Way. Otherwise, 3696 transition the neighbor state to ExStart and perform 3697 the actions associated with the above state machine 3698 entry for state Init and event 2-WayReceived. 3700 State(s): ExStart or greater 3702 Event: AdjOK? 3704 New state: Depends upon action routine. 3706 Action: Determine whether the neighboring router should 3707 still be adjacent. If yes, there is no state change 3708 and no further action is necessary. 3710 Otherwise, the (possibly partially formed) adjacency 3711 must be destroyed. The neighbor state transitions 3712 to 2-Way. The Link state retransmission list, 3713 Database summary list and Link state request list 3714 are cleared of LSAs. 3716 State(s): Exchange or greater 3718 Event: SeqNumberMismatch 3720 New state: ExStart 3722 Action: The (possibly partially formed) adjacency is torn 3723 down, and then an attempt is made at 3724 reestablishment. The neighbor state first 3725 transitions to ExStart. The Link state 3726 retransmission list, Database summary list and Link 3727 state request list are cleared of LSAs. Then the 3728 router increments the DD sequence number in the 3729 neighbor data structure, declares itself master 3730 (sets the master/slave bit to master), and starts 3731 sending Database Description Packets, with the 3732 initialize (I), more (M) and master (MS) bits set. 3733 This Database Description Packet should be otherwise 3734 empty (see Section 10.8). 3736 State(s): Exchange or greater 3738 Event: BadLSReq 3740 New state: ExStart 3742 Action: The action for event BadLSReq is exactly the same as 3743 for the neighbor event SeqNumberMismatch. The 3744 (possibly partially formed) adjacency is torn down, 3745 and then an attempt is made at reestablishment. For 3746 more information, see the neighbor state machine 3747 entry that is invoked when event SeqNumberMismatch 3748 is generated in state Exchange or greater. 3750 State(s): Any state 3752 Event: KillNbr 3754 New state: Down 3756 Action: The Link state retransmission list, Database summary 3757 list and Link state request list are cleared of 3758 LSAs. Also, the Inactivity Timer is disabled. 3760 State(s): Any state 3762 Event: LLDown 3764 New state: Down 3766 Action: The Link state retransmission list, Database summary 3767 list and Link state request list are cleared of 3768 LSAs. Also, the Inactivity Timer is disabled. 3770 State(s): Any state 3772 Event: InactivityTimer 3774 New state: Down 3776 Action: The Link state retransmission list, Database summary 3777 list and Link state request list are cleared of 3778 LSAs. 3780 State(s): 2-Way or greater 3782 Event: 1-WayReceived 3784 New state: Init 3786 Action: The Link state retransmission list, Database summary 3787 list and Link state request list are cleared of 3788 LSAs. 3790 State(s): 2-Way or greater 3792 Event: 2-WayReceived 3794 New state: No state change. 3796 Action: No action required. 3798 State(s): Init 3800 Event: 1-WayReceived 3802 New state: No state change. 3804 Action: No action required. 3806 10.4. Whether to become adjacent 3808 Adjacencies are established with some subset of the router's 3809 neighbors. Routers connected by point-to-point networks, 3810 Point-to-MultiPoint networks and virtual links always become 3811 adjacent. On broadcast and NBMA networks, all routers become 3812 adjacent to both the Designated Router and the Backup Designated 3813 Router. 3815 The adjacency-forming decision occurs in two places in the 3816 neighbor state machine. First, when bidirectional communication 3817 is initially established with the neighbor, and secondly, when 3818 the identity of the attached network's (Backup) Designated 3819 Router changes. If the decision is made to not attempt an 3820 adjacency, the state of the neighbor communication stops at 2- 3821 Way. 3823 An adjacency should be established with a bidirectional neighbor 3824 when at least one of the following conditions holds: 3826 o The underlying network type is point-to-point 3828 o The underlying network type is Point-to-MultiPoint 3830 o The underlying network type is virtual link 3832 o The router itself is the Designated Router 3834 o The router itself is the Backup Designated Router 3836 o The neighboring router is the Designated Router 3838 o The neighboring router is the Backup Designated Router 3840 10.5. Receiving Hello Packets 3842 This section explains the detailed processing of a received 3843 Hello Packet. (See Section A.3.2 for the format of Hello 3844 packets.) The generic input processing of OSPF packets will 3845 have checked the validity of the IP header and the OSPF packet 3846 header. Next, the values of the Network Mask, HelloInterval, 3847 and RouterDeadInterval fields in the received Hello packet must 3848 be checked against the values configured for the receiving 3849 interface. Any mismatch causes processing to stop and the 3850 packet to be dropped. In other words, the above fields are 3851 really describing the attached network's configuration. However, 3852 there is one exception to the above rule: on point-to-point 3853 networks and on virtual links, the Network Mask in the received 3854 Hello Packet should be ignored. 3856 The receiving interface attaches to a single OSPF area (this 3857 could be the backbone). The setting of the E-bit found in the 3858 Hello Packet's Options field must match this area's 3859 ExternalRoutingCapability. If AS-external-LSAs are not flooded 3860 into/throughout the area (i.e, the area is a "stub") the E-bit 3861 must be clear in received Hello Packets, otherwise the E-bit 3862 must be set. A mismatch causes processing to stop and the 3863 packet to be dropped. The setting of the rest of the bits in 3864 the Hello Packet's Options field should be ignored. 3866 At this point, an attempt is made to match the source of the 3867 Hello Packet to one of the receiving interface's neighbors. If 3868 the receiving interface connects to a broadcast, Point-to- 3869 MultiPoint or NBMA network the source is identified by the IP 3870 source address found in the Hello's IP header. If the receiving 3871 interface connects to a point-to-point link or a virtual link, 3872 the source is identified by the Router ID found in the Hello's 3873 OSPF packet header. The interface's current list of neighbors 3874 is contained in the interface's data structure. If a matching 3875 neighbor structure cannot be found, (i.e., this is the first 3876 time the neighbor has been detected), one is created. The 3877 initial state of a newly created neighbor is set to Down. 3879 When receiving an Hello Packet from a neighbor on a broadcast, 3880 Point-to-MultiPoint or NBMA network, set the neighbor 3881 structure's Neighbor ID equal to the Router ID found in the 3882 packet's OSPF header. When receiving an Hello on a point-to- 3883 point network (but not on a virtual link) set the neighbor 3884 structure's Neighbor IP address to the packet's IP source 3885 address. 3887 Now the rest of the Hello Packet is examined, generating events 3888 to be given to the neighbor and interface state machines. These 3889 state machines are specified either to be executed or scheduled 3890 (see Section 4.4). For example, by specifying below that the 3891 neighbor state machine be executed in line, several neighbor 3892 state transitions may be effected by a single received Hello: 3894 o Each Hello Packet causes the neighbor state machine to be 3895 executed with the event HelloReceived. 3897 o Then the list of neighbors contained in the Hello Packet is 3898 examined. If the router itself appears in this list, the 3899 neighbor state machine should be executed with the event 2- 3900 WayReceived. Otherwise, the neighbor state machine should 3901 be executed with the event 1-WayReceived, and the processing 3902 of the packet stops. 3904 o Next, the Hello Packet's Router Priority field is examined. 3905 If this field is different than the one previously received 3906 from the neighbor, the receiving interface's state machine 3907 is scheduled with the event NeighborChange. In any case, 3908 the Router Priority field in the neighbor data structure 3909 should be updated accordingly. 3911 o Next the Designated Router field in the Hello Packet is 3912 examined. If the neighbor is both declaring itself to be 3913 Designated Router (Designated Router field = Neighbor IP 3914 address) and the Backup Designated Router field in the 3915 packet is equal to 0.0.0.0 and the receiving interface is in 3916 state Waiting, the receiving interface's state machine is 3917 scheduled with the event BackupSeen. Otherwise, if the 3918 neighbor is declaring itself to be Designated Router and it 3919 had not previously, or the neighbor is not declaring itself 3920 Designated Router where it had previously, the receiving 3921 interface's state machine is scheduled with the event 3922 NeighborChange. In any case, the Neighbors' Designated 3923 Router item in the neighbor structure is updated 3924 accordingly. 3926 o Finally, the Backup Designated Router field in the Hello 3927 Packet is examined. If the neighbor is declaring itself to 3928 be Backup Designated Router (Backup Designated Router field 3929 = Neighbor IP address) and the receiving interface is in 3930 state Waiting, the receiving interface's state machine is 3931 scheduled with the event BackupSeen. Otherwise, if the 3932 neighbor is declaring itself to be Backup Designated Router 3933 and it had not previously, or the neighbor is not declaring 3934 itself Backup Designated Router where it had previously, the 3935 receiving interface's state machine is scheduled with the 3936 event NeighborChange. In any case, the Neighbor's Backup 3937 Designated Router item in the neighbor structure is updated 3938 accordingly. 3940 On NBMA networks, receipt of an Hello Packet may also cause an 3941 Hello Packet to be sent back to the neighbor in response. See 3942 Section 9.5.1 for more details. 3944 10.6. Receiving Database Description Packets 3946 This section explains the detailed processing of a received 3947 Database Description Packet. The incoming Database Description 3948 Packet has already been associated with a neighbor and receiving 3949 interface by the generic input packet processing (Section 8.2). 3950 Whether the Database Description packet should be accepted, and 3951 if so, how it should be further processed depends upon the 3952 neighbor state. 3954 If a Database Description packet is accepted, the following 3955 packet fields should be saved in the corresponding neighbor data 3956 structure under "last received Database Description packet": 3957 the packet's initialize(I), more (M) and master(MS) bits, 3958 Options field, and DD sequence number. If these fields are set 3959 identically in two consecutive Database Description packets 3960 received from the neighbor, the second Database Description 3961 packet is considered to be a "duplicate" in the processing 3962 described below. 3964 If the Interface MTU field in the Database Description packet 3965 indicates an IP datagram size that is larger than the router can 3966 accept on the receiving interface without fragmentation, the 3967 Database Description packet is rejected. Otherwise, if the 3968 neighbor state is: 3970 Down 3971 The packet should be rejected. 3973 Attempt 3974 The packet should be rejected. 3976 Init 3977 The neighbor state machine should be executed with the event 3978 2-WayReceived. This causes an immediate state change to 3979 either state 2-Way or state ExStart. If the new state is 3980 ExStart, the processing of the current packet should then 3981 continue in this new state by falling through to case 3982 ExStart below. 3984 2-Way 3985 The packet should be ignored. Database Description Packets 3986 are used only for the purpose of bringing up adjacencies.[7] 3988 ExStart 3989 If the received packet matches one of the following cases, 3990 then the neighbor state machine should be executed with the 3991 event NegotiationDone (causing the state to transition to 3992 Exchange), the packet's Options field should be recorded in 3993 the neighbor structure's Neighbor Options field and the 3994 packet should be accepted as next in sequence and processed 3995 further (see below). Otherwise, the packet should be 3996 ignored. 3998 o The initialize(I), more (M) and master(MS) bits are set, 3999 the contents of the packet are empty, and the neighbor's 4000 Router ID is larger than the router's own. In this case 4001 the router is now Slave. Set the master/slave bit to 4002 slave, and set the neighbor data structure's DD sequence 4003 number to that specified by the master. 4005 o The initialize(I) and master(MS) bits are off, the 4006 packet's DD sequence number equals the neighbor data 4007 structure's DD sequence number (indicating 4008 acknowledgment) and the neighbor's Router ID is smaller 4009 than the router's own. In this case the router is 4010 Master. 4012 Exchange 4013 Duplicate Database Description packets are discarded by the 4014 master, and cause the slave to retransmit the last Database 4015 Description packet that it had sent. Otherwise (the packet 4016 is not a duplicate): 4018 o If the state of the MS-bit is inconsistent with the 4019 master/slave state of the connection, generate the 4020 neighbor event SeqNumberMismatch and stop processing the 4021 packet. 4023 o If the initialize(I) bit is set, generate the neighbor 4024 event SeqNumberMismatch and stop processing the packet. 4026 o If the packet's Options field indicates a different set 4027 of optional OSPF capabilities than were previously 4028 received from the neighbor (recorded in the Neighbor 4029 Options field of the neighbor structure), generate the 4030 neighbor event SeqNumberMismatch and stop processing the 4031 packet. 4033 o Database Description packets must be processed in 4034 sequence, as indicated by the packets' DD sequence 4035 numbers. If the router is master, the next packet 4036 received should have DD sequence number equal to the DD 4037 sequence number in the neighbor data structure. If the 4038 router is slave, the next packet received should have DD 4039 sequence number equal to one more than the DD sequence 4040 number stored in the neighbor data structure. In either 4041 case, if the packet is the next in sequence it should be 4042 accepted and its contents processed as specified below. 4044 o Else, generate the neighbor event SeqNumberMismatch and 4045 stop processing the packet. 4047 Loading or Full 4048 In this state, the router has sent and received an entire 4049 sequence of Database Description Packets. The only packets 4050 received should be duplicates (see above). In particular, 4051 the packet's Options field should match the set of optional 4052 OSPF capabilities previously indicated by the neighbor 4053 (stored in the neighbor structure's Neighbor Options field). 4054 Any other packets received, including the reception of a 4055 packet with the Initialize(I) bit set, should generate the 4056 neighbor event SeqNumberMismatch.[8] Duplicates should be 4057 discarded by the master. The slave must respond to 4058 duplicates by repeating the last Database Description packet 4059 that it had sent. 4061 When the router accepts a received Database Description Packet 4062 as the next in sequence the packet contents are processed as 4063 follows. For each LSA listed, the LSA's LS type is checked for 4064 validity. If the LS type is unknown (e.g., not one of the LS 4065 types 1-5 defined by this specification), or if this is an AS- 4066 external-LSA (LS type = 5) and the neighbor is associated with a 4067 stub area, generate the neighbor event SeqNumberMismatch and 4068 stop processing the packet. Otherwise, the router looks up the 4069 LSA in its database to see whether it also has an instance of 4070 the LSA. If it does not, or if the database copy is less recent 4071 (see Section 13.1), the LSA is put on the Link state request 4072 list so that it can be requested (immediately or at some later 4073 time) in Link State Request Packets. 4075 When the router accepts a received Database Description Packet 4076 as the next in sequence, it also performs the following actions, 4077 depending on whether it is master or slave: 4079 Master 4080 Increments the DD sequence number in the neighbor data 4081 structure. If the router has already sent its entire 4082 sequence of Database Description Packets, and the just 4083 accepted packet has the more bit (M) set to 0, the neighbor 4084 event ExchangeDone is generated. Otherwise, it should send 4085 a new Database Description to the slave. 4087 Slave 4088 Sets the DD sequence number in the neighbor data structure 4089 to the DD sequence number appearing in the received packet. 4090 The slave must send a Database Description Packet in reply. 4091 If the received packet has the more bit (M) set to 0, and 4092 the packet to be sent by the slave will also have the M-bit 4093 set to 0, the neighbor event ExchangeDone is generated. 4094 Note that the slave always generates this event before the 4095 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 LSAs that the neighbor wishes to receive. 4102 Link State Request Packets should be accepted when the neighbor 4103 is in states Exchange, Loading, or Full. In all other states 4104 Link State Request Packets should be ignored. 4106 Each LSA specified in the Link State Request packet should be 4107 located in the router's database, and copied into Link State 4108 Update packets for transmission to the neighbor. These LSAs 4109 should NOT be placed on the Link state retransmission list for 4110 the neighbor. If an LSA cannot be found in the database, 4111 something has gone wrong with the Database Exchange process, and 4112 neighbor event BadLSReq should be generated. 4114 10.8. Sending Database Description Packets 4116 This section describes how Database Description Packets are sent 4117 to a neighbor. The Database Description packet's Interface MTU 4118 field is set to the size of the largest IP datagram that can be 4119 sent out the sending interface, without fragmentation. Common 4120 MTUs in use in the Internet can be found in Table 7-1 of 4121 [Ref22]. Interface MTU should be set to 0 in Database 4122 Description packets sent over virtual links. 4124 The router's optional OSPF capabilities (see Section 4.5) are 4125 transmitted to the neighbor in the Options field of the Database 4126 Description packet. The router should maintain the same set of 4127 optional capabilities throughout the Database Exchange and 4128 flooding procedures. If for some reason the router's optional 4129 capabilities change, the Database Exchange procedure should be 4130 restarted by reverting to neighbor state ExStart. There are 4131 currently two optional capabilities defined. The T-bit should 4132 be set if and only if the router is capable of calculating 4133 separate routes for each IP TOS. The E-bit should be set if and 4134 only if the attached network belongs to a non-stub area. The 4135 rest of the Options field should be set to zero. 4137 The sending of Database Description packets depends on the 4138 neighbor's state. In state ExStart the router sends empty 4139 Database Description packets, with the initialize (I), more (M) 4140 and master (MS) bits set. These packets are retransmitted every 4141 RxmtInterval seconds. 4143 In state Exchange the Database Description Packets actually 4144 contain summaries of the link state information contained in the 4145 router's database. Each LSA in the area's link-state database 4146 (at the time the neighbor transitions into Exchange state) is 4147 listed in the neighbor Database summary list. Each new Database 4148 Description Packet copies its DD sequence number from the 4149 neighbor data structure and then describes the current top of 4150 the Database summary list. Items are removed from the Database 4151 summary list when the previous packet is acknowledged. 4153 In state Exchange, the determination of when to send a Database 4154 Description packet depends on whether the router is master or 4155 slave: 4157 Master 4158 Database Description packets are sent when either a) the 4159 slave acknowledges the previous Database Description packet 4160 by echoing the DD sequence number or b) RxmtInterval seconds 4161 elapse without an acknowledgment, in which case the previous 4162 Database Description packet is retransmitted. 4164 Slave 4165 Database Description packets are sent only in response to 4166 Database Description packets received from the master. If 4167 the Database Description packet received from the master is 4168 new, a new Database Description packet is sent, otherwise 4169 the previous Database Description packet is resent. 4171 In states Loading and Full the slave must resend its last 4172 Database Description packet in response to duplicate Database 4173 Description packets received from the master. For this reason 4174 the slave must wait RouterDeadInterval seconds before freeing 4175 the last Database Description packet. Reception of a Database 4176 Description packet from the master after this interval will 4177 generate a SeqNumberMismatch neighbor event. 4179 10.9. Sending Link State Request Packets 4181 In neighbor states Exchange or Loading, the Link state request 4182 list contains a list of those LSAs that need to be obtained from 4183 the neighbor. To request these LSAs, a router sends the 4184 neighbor the beginning of the Link state request list, packaged 4185 in a Link State Request packet. 4187 When the neighbor responds to these requests with the proper 4188 Link State Update packet(s), the Link state request list is 4189 truncated and a new Link State Request packet is sent. This 4190 process continues until the Link state request list becomes 4191 empty. Unsatisfied Link State Request packets are retransmitted 4192 at intervals of RxmtInterval. There should be at most one Link 4193 State Request packet outstanding at any one time. 4195 When the Link state request list becomes empty, and the neighbor 4196 state is Loading (i.e., a complete sequence of Database 4197 Description packets has been sent to and received from the 4198 neighbor), the Loading Done neighbor event is generated. 4200 10.10. An Example 4202 Figure 14 shows an example of an adjacency forming. Routers RT1 4203 and RT2 are both connected to a broadcast network. It is 4204 assumed that RT2 is the Designated Router for the network, and 4205 that RT2 has a higher Router ID than Router RT1. 4207 The neighbor state changes realized by each router are listed on 4208 the sides of the figure. 4210 At the beginning of Figure 14, Router RT1's interface to the 4211 network becomes operational. It begins sending Hello Packets, 4212 although it doesn't know the identity of the Designated Router 4213 or of any other neighboring routers. Router RT2 hears this 4214 hello (moving the neighbor to Init state), and in its next Hello 4215 Packet indicates that it is itself the Designated Router and 4216 that it has heard Hello Packets from RT1. This in turn causes 4217 RT1 to go to state ExStart, as it starts to bring up the 4218 adjacency. 4220 RT1 begins by asserting itself as the master. When it sees that 4221 RT2 is indeed the master (because of RT2's higher Router ID), 4222 RT1 transitions to slave state and adopts its neighbor's DD 4223 sequence number. Database Description packets are then 4224 exchanged, with polls coming from the master (RT2) and responses 4225 from the slave (RT1). This sequence of Database Description 4226 Packets ends when both the poll and associated response has the 4227 M-bit off. 4229 In this example, it is assumed that RT2 has a completely up to 4230 date database. In that case, RT2 goes immediately into Full 4231 state. RT1 will go into Full state after updating the necessary 4232 parts of its database. This is done by sending Link State 4233 Request Packets, and receiving Link State Update Packets in 4234 response. Note that, while RT1 has waited until a complete set 4235 of Database Description Packets has been received (from RT2) 4236 before sending any Link State Request Packets, this need not be 4237 the case. RT1 could have interleaved the sending of Link State 4238 Request Packets with the reception of Database Description 4239 Packets. 4241 11. The Routing Table Structure 4243 The routing table data structure contains all the information 4244 necessary to forward an IP data packet toward its destination. Each 4245 routing table entry describes the collection of best paths to a 4246 particular destination. When forwarding an IP data packet, the 4248 +---+ +---+ 4249 |RT1| |RT2| 4250 +---+ +---+ 4252 Down Down 4253 Hello(DR=0,seen=0) 4254 ------------------------------> 4255 Hello (DR=RT2,seen=RT1,...) Init 4256 <------------------------------ 4257 ExStart D-D (Seq=x,I,M,Master) 4258 ------------------------------> 4259 D-D (Seq=y,I,M,Master) ExStart 4260 <------------------------------ 4261 Exchange D-D (Seq=y,M,Slave) 4262 ------------------------------> 4263 D-D (Seq=y+1,M,Master) Exchange 4264 <------------------------------ 4265 D-D (Seq=y+1,M,Slave) 4266 ------------------------------> 4267 ... 4268 ... 4269 ... 4270 D-D (Seq=y+n, Master) 4271 <------------------------------ 4272 D-D (Seq=y+n, Slave) 4273 Loading ------------------------------> 4274 LS Request Full 4275 ------------------------------> 4276 LS Update 4277 <------------------------------ 4278 LS Request 4279 ------------------------------> 4280 LS Update 4281 <------------------------------ 4282 Full 4284 Figure 14: An adjacency bring-up example 4285 routing table entry providing the best match for the packet's IP 4286 destination is located. The matching routing table entry then 4287 provides the next hop towards the packet's destination. OSPF also 4288 provides for the existence of a default route (Destination ID = 4289 DefaultDestination, Address Mask = 0x00000000). When the default 4290 route exists, it matches all IP destinations (although any other 4291 matching entry is a better match). Finding the routing table entry 4292 that best matches an IP destination is further described in Section 4293 11.1. 4295 There is a single routing table in each router. Two sample routing 4296 tables are described in Sections 11.2 and 11.3. The building of the 4297 routing table is discussed in Section 16. 4299 The rest of this section defines the fields found in a routing table 4300 entry. The first set of fields describes the routing table entry's 4301 destination. 4303 Destination Type 4304 Destination type is either "network" or "router". Only network 4305 entries are actually used when forwarding IP data traffic. 4306 Router routing table entries are used solely as intermediate 4307 steps in the routing table build process. 4309 A network is a range of IP addresses, to which IP data traffic 4310 may be forwarded. This includes IP networks (class A, B, or C), 4311 IP subnets, IP supernets and single IP hosts. The default route 4312 also falls into this category. 4314 Router entries are kept for area border routers and AS boundary 4315 routers. Routing table entries for area border routers are used 4316 when calculating the inter-area routes (see Section 16.2), and 4317 when maintaining configured virtual links (see Section 15). 4318 Routing table entries for AS boundary routers are used when 4319 calculating the AS external routes (see Section 16.4). 4321 Destination ID 4322 The destination's identifier or name. This depends on the 4323 Destination Type. For networks, the identifier is their 4324 associated IP address. For routers, the identifier is the OSPF 4325 Router ID.[9] 4327 Address Mask 4328 Only defined for networks. The network's IP address together 4329 with its address mask defines a range of IP addresses. For IP 4330 subnets, the address mask is referred to as the subnet mask. 4331 For host routes, the mask is "all ones" (0xffffffff). 4333 Optional Capabilities 4334 When the destination is a router this field indicates the 4335 optional OSPF capabilities supported by the destination router. 4336 The two optional capabilities currently defined by this 4337 specification are the ability to route based on IP TOS and the 4338 ability to process AS-external-LSAs. For a further discussion 4339 of OSPF's optional capabilities, see Section 4.5. 4341 The set of paths to use for a destination may vary based on IP Type 4342 of Service and the OSPF area to which the paths belong. This means 4343 that there may be multiple routing table entries for the same 4344 destination, depending on the values of the next two fields. 4346 Type of Service 4347 There can be a separate set of routes for each IP Type of 4348 Service. The encoding of TOS in OSPF LSAs is described in 4349 Section 12.3. 4351 Area 4352 This field indicates the area whose link state information has 4353 led to the routing table entry's collection of paths. This is 4354 called the entry's associated area. For sets of AS external 4355 paths, this field is not defined. For destinations of type 4356 "router", there may be separate sets of paths (and therefore 4357 separate routing table entries) associated with each of several 4358 areas. For example, this will happen when two area border 4359 routers share multiple areas in common. For destinations of 4360 type "network", only the set of paths associated with the best 4361 area (the one providing the preferred route) is kept. 4363 The rest of the routing table entry describes the set of paths to 4364 the destination. The following fields pertain to the set of paths 4365 as a whole. In other words, each one of the paths contained in a 4366 routing table entry is of the same path-type and cost (see below). 4368 Path-type 4369 There are four possible types of paths used to route traffic to 4370 the destination, listed here in order of preference: intra-area, 4371 inter-area, type 1 external or type 2 external. Intra-area 4372 paths indicate destinations belonging to one of the router's 4373 attached areas. Inter-area paths are paths to destinations in 4374 other OSPF areas. These are discovered through the examination 4375 of received summary-LSAs. AS external paths are paths to 4376 destinations external to the AS. These are detected through the 4377 examination of received AS-external-LSAs. 4379 Cost 4380 The link state cost of the path to the destination. For all 4381 paths except type 2 external paths this describes the entire 4382 path's cost. For Type 2 external paths, this field describes 4383 the cost of the portion of the path internal to the AS. This 4384 cost is calculated as the sum of the costs of the path's 4385 constituent links. 4387 Type 2 cost 4388 Only valid for type 2 external paths. For these paths, this 4389 field indicates the cost of the path's external portion. This 4390 cost has been advertised by an AS boundary router, and is the 4391 most significant part of the total path cost. For example, a 4392 type 2 external path with type 2 cost of 5 is always preferred 4393 over a path with type 2 cost of 10, regardless of the cost of 4394 the two paths' internal components. 4396 Link State Origin 4397 Valid only for intra-area paths, this field indicates the LSA 4398 (router-LSA or network-LSA) that directly references the 4399 destination. For example, if the destination is a transit 4400 network, this is the transit network's network-LSA. If the 4401 destination is a stub network, this is the router-LSA for the 4402 attached router. The LSA is discovered during the shortest-path 4403 tree calculation (see Section 16.1). Multiple LSAs may 4404 reference the destination, however a tie-breaking scheme always 4405 reduces the choice to a single LSA. The Link State Origin field 4406 is not used by the OSPF protocol, but it is used by the routing 4407 table calculation in OSPF's Multicast routing extensions 4408 (MOSPF). 4410 When multiple paths of equal path-type and cost exist to a 4411 destination (called elsewhere "equal-cost" paths), they are stored 4412 in a single routing table entry. Each one of the "equal-cost" paths 4413 is distinguished by the following fields: 4415 Next hop 4416 The outgoing router interface to use when forwarding traffic to 4417 the destination. On broadcast, Point-to-MultiPoint and NBMA 4418 networks, the next hop also includes the IP address of the next 4419 router (if any) in the path towards the destination. 4421 Advertising router 4422 Valid only for inter-area and AS external paths. This field 4423 indicates the Router ID of the router advertising the summary- 4424 LSA or AS-external-LSA that led to this path. 4426 11.1. Routing table lookup 4428 When an IP data packet is received, an OSPF router finds the 4429 routing table entry that best matches the packet's destination. 4430 This routing table entry then provides the outgoing interface 4431 and next hop router to use in forwarding the packet. This 4432 section describes the process of finding the best matching 4433 routing table entry. The process consists of a number of steps, 4434 wherein the collection of routing table entries is progressively 4435 pruned. In the end, the single routing table entry remaining is 4436 called the "best match". 4438 Before the lookup begins, "discard" routing table entries should 4439 be inserted into the routing table for each of the router's 4440 active area address ranges (see Section 3.5). (An area range is 4441 considered "active" if the range contains one or more networks 4442 reachable by intra-area paths.) The destination of a "discard" 4443 entry is the set of addresses described by its associated active 4444 area address range, and the path type of each "discard" entry is 4445 set to "inter-area".[10] 4447 Note that the steps described below may fail to produce a best 4448 match routing table entry (i.e., all existing routing table 4449 entries are pruned for some reason or another), or the best 4450 match routing table entry may be one of the above "discard" 4451 routing table entries. In these cases, the packet's IP 4452 destination is considered unreachable. Instead of being 4453 forwarded, the packet should be discarded and an ICMP 4454 destination unreachable message should be returned to the 4455 packet's source. 4457 (1) Select the complete set of "matching" routing table entries 4458 from the routing table. Each routing table entry describes 4459 a (set of) path(s) to a range of IP addresses. If the data 4460 packet's IP destination falls into an entry's range of IP 4461 addresses, the routing table entry is called a match. (It is 4462 quite likely that multiple entries will match the data 4463 packet. For example, a default route will match all 4464 packets.) 4466 (2) Reduce the set of matching entries to those having the most 4467 preferential path-type (see Section 11). OSPF has a four 4468 level hierarchy of paths. Intra-area paths are the most 4469 preferred, followed in order by inter-area, type 1 external 4470 and type 2 external paths. 4472 (3) Select the remaining routing table entry that provides the 4473 most specific (longest) match. Another way of saying this is 4474 to choose the remaining entry that specifies the narrowest 4475 range of IP addresses.[11] For example, the entry for the 4476 address/mask pair of (128.185.1.0, 0xffffff00) is more 4477 specific than an entry for the pair (128.185.0.0, 4478 0xffff0000). The default route is the least specific match, 4479 since it matches all destinations. 4481 (4) At this point, there may still be multiple routing table 4482 entries remaining. Each routing entry will specify the same 4483 range of IP addresses, but a different IP Type of Service. 4484 Select the routing table entry whose TOS value matches the 4485 TOS found in the packet header. If there is no routing table 4486 entry for this TOS, select the routing table entry for TOS 4487 0. In other words, packets requesting TOS X are routed along 4488 the TOS 0 path if a TOS X path does not exist. 4490 11.2. Sample routing table, without areas 4492 Consider the Autonomous System pictured in Figure 2. No OSPF 4493 areas have been configured. A single metric is shown per 4494 outbound interface, indicating that routes will not vary based 4495 on TOS. The calculation of Router RT6's routing table proceeds 4496 as described in Section 2.2. The resulting routing table is 4497 shown in Table 12. Destination types are abbreviated: Network 4498 as "N", Router as "R". 4500 There are no instances of multiple equal-cost shortest paths in 4501 this example. Also, since there are no areas, there are no 4502 inter-area paths. 4504 Routers RT5 and RT7 are AS boundary routers. Intra-area routes 4505 have been calculated to Routers RT5 and RT7. This allows 4506 external routes to be calculated to the destinations advertised 4507 by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is 4508 assumed all AS-external-LSAs originated by RT5 and RT7 are 4509 advertising type 1 external metrics. This results in type 1 4510 external paths being calculated to destinations N12-N15. 4512 Type Dest Area Path Type Cost Next Adv. 4513 Hop(s) Router(s) 4514 ____________________________________________________________ 4515 N N1 0 intra-area 10 RT3 * 4516 N N2 0 intra-area 10 RT3 * 4517 N N3 0 intra-area 7 RT3 * 4518 N N4 0 intra-area 8 RT3 * 4519 N Ib 0 intra-area 7 * * 4520 N Ia 0 intra-area 12 RT10 * 4521 N N6 0 intra-area 8 RT10 * 4522 N N7 0 intra-area 12 RT10 * 4523 N N8 0 intra-area 10 RT10 * 4524 N N9 0 intra-area 11 RT10 * 4525 N N10 0 intra-area 13 RT10 * 4526 N N11 0 intra-area 14 RT10 * 4527 N H1 0 intra-area 21 RT10 * 4528 R RT5 0 intra-area 6 RT5 * 4529 R RT7 0 intra-area 8 RT10 * 4530 ____________________________________________________________ 4531 N N12 * type 1 ext. 10 RT10 RT7 4532 N N13 * type 1 ext. 14 RT5 RT5 4533 N N14 * type 1 ext. 14 RT5 RT5 4534 N N15 * type 1 ext. 17 RT10 RT7 4536 Table 12: The routing table for Router RT6 4537 (no configured areas). 4539 11.3. Sample routing table, with areas 4541 Consider the previous example, this time split into OSPF areas. 4542 An OSPF area configuration is pictured in Figure 6. Router 4543 RT4's routing table will be described for this area 4544 configuration. Router RT4 has a connection to Area 1 and a 4545 backbone connection. This causes Router RT4 to view the AS as 4546 the concatenation of the two graphs shown in Figures 7 and 8. 4547 The resulting routing table is displayed in Table 13. 4549 Again, Routers RT5 and RT7 are AS boundary routers. Routers 4550 RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 4551 there are two routing entries for the area border router RT3, 4552 since it has two areas in common with RT4 (Area 1 and the 4553 backbone). 4555 Backbone paths have been calculated to all area border routers. 4556 These are used when determining the inter-area routes. Note 4557 that all of the inter-area routes are associated with the 4558 backbone; this is always the case when the calculating router is 4559 itself an area border router. Routing information is condensed 4560 at area boundaries. In this example, we assume that Area 3 has 4561 been defined so that networks N9-N11 and the host route to H1 4562 are all condensed to a single route when advertised into the 4563 backbone (by Router RT11). Note that the cost of this route is 4564 the maximum of the set of costs to its individual components. 4566 There is a virtual link configured between Routers RT10 and 4567 RT11. Without this configured virtual link, RT11 would be 4568 unable to advertise a route for networks N9-N11 and Host H1 into 4569 the backbone, and there would not be an entry for these networks 4570 in Router RT4's routing table. 4572 In this example there are two equal-cost paths to Network N12. 4573 However, they both use the same next hop (Router RT5). 4575 Router RT4's routing table would improve (i.e., some of the 4576 paths in the routing table would become shorter) if an 4577 additional virtual link were configured between Router RT4 and 4578 Router RT3. The new virtual link would itself be associated 4579 with the first entry for area border router RT3 in Table 13 (an 4580 intra-area path through Area 1). This would yield a cost of 1 4581 for the virtual link. The routing table entries changes that 4582 would be caused by the addition of this virtual link are shown 4583 in Table 14. 4585 12. Link State Advertisements (LSAs) 4587 Each router in the Autonomous System originates one or more link 4588 state advertisements (LSAs). This memo defines five distinct types 4589 of LSAs, which are described in Section 4.3. The collection of LSAs 4590 forms the link-state database. Each separate type of LSA has a 4591 separate function. Router-LSAs and network-LSAs describe how an 4592 area's routers and networks are interconnected. Summary-LSAs 4593 provide a way of condensing an area's routing information. AS- 4594 external-LSAs provide a way of transparently advertising 4595 externally-derived routing information throughout the Autonomous 4596 System. 4598 Each LSA begins with a standard 20-byte header. This LSA header is 4599 discussed below. 4601 Type Dest Area Path Type Cost Next Adv. 4602 Hops(s) Router(s) 4603 __________________________________________________________________ 4604 N N1 1 intra-area 4 RT1 * 4605 N N2 1 intra-area 4 RT2 * 4606 N N3 1 intra-area 1 * * 4607 N N4 1 intra-area 3 RT3 * 4608 R RT3 1 intra-area 1 * * 4609 __________________________________________________________________ 4610 N Ib 0 intra-area 22 RT5 * 4611 N Ia 0 intra-area 27 RT5 * 4612 R RT3 0 intra-area 21 RT5 * 4613 R RT5 0 intra-area 8 * * 4614 R RT7 0 intra-area 14 RT5 * 4615 R RT10 0 intra-area 22 RT5 * 4616 R RT11 0 intra-area 25 RT5 * 4617 __________________________________________________________________ 4618 N N6 0 inter-area 15 RT5 RT7 4619 N N7 0 inter-area 19 RT5 RT7 4620 N N8 0 inter-area 18 RT5 RT7 4621 N N9-N11,H1 0 inter-area 36 RT5 RT11 4622 __________________________________________________________________ 4623 N N12 * type 1 ext. 16 RT5 RT5,RT7 4624 N N13 * type 1 ext. 16 RT5 RT5 4625 N N14 * type 1 ext. 16 RT5 RT5 4626 N N15 * type 1 ext. 23 RT5 RT7 4628 Table 13: Router RT4's routing table 4629 in the presence of areas. 4631 Type Dest Area Path Type Cost Next Adv. 4632 Hop(s) Router(s) 4633 ________________________________________________________________ 4634 N Ib 0 intra-area 16 RT3 * 4635 N Ia 0 intra-area 21 RT3 * 4636 R RT3 0 intra-area 1 * * 4637 R RT10 0 intra-area 16 RT3 * 4638 R RT11 0 intra-area 19 RT3 * 4639 ________________________________________________________________ 4640 N N9-N11,H1 0 inter-area 30 RT3 RT11 4642 Table 14: Changes resulting from an 4643 additional virtual link. 4645 12.1. The LSA Header 4647 The LSA header contains the LS type, Link State ID and 4648 Advertising Router fields. The combination of these three 4649 fields uniquely identifies the LSA. 4651 There may be several instances of an LSA present in the 4652 Autonomous System, all at the same time. It must then be 4653 determined which instance is more recent. This determination is 4654 made by examining the LS sequence, LS checksum and LS age 4655 fields. These fields are also contained in the 20-byte LSA 4656 header. 4658 Several of the OSPF packet types list LSAs. When the instance 4659 is not important, an LSA is referred to by its LS type, Link 4660 State ID and Advertising Router (see Link State Request 4661 Packets). Otherwise, the LS sequence number, LS age and LS 4662 checksum fields must also be referenced. 4664 A detailed explanation of the fields contained in the LSA header 4665 follows. 4667 12.1.1. LS age 4669 This field is the age of the LSA in seconds. It should be 4670 processed as an unsigned 16-bit integer. It is set to 0 4671 when the LSA is originated. It must be incremented by 4672 InfTransDelay on every hop of the flooding procedure. LSAs 4673 are also aged as they are held in each router's database. 4675 The age of an LSA is never incremented past MaxAge. LSAs 4676 having age MaxAge are not used in the routing table 4677 calculation. When an LSA's age first reaches MaxAge, it is 4678 reflooded. An LSA of age MaxAge is finally flushed from the 4679 database when it is no longer needed to ensure database 4680 synchronization. For more information on the aging of LSAs, 4681 consult Section 14. 4683 The LS age field is examined when a router receives two 4684 instances of an LSA, both having identical LS sequence 4685 numbers and LS checksums. An instance of age MaxAge is then 4686 always accepted as most recent; this allows old LSAs to be 4687 flushed quickly from the routing domain. Otherwise, if the 4688 ages differ by more than MaxAgeDiff, the instance having the 4689 smaller age is accepted as most recent.[12] See Section 13.1 4690 for more details. 4692 12.1.2. Options 4694 The Options field in the LSA header indicates which optional 4695 capabilities are associated with the LSA. OSPF's optional 4696 capabilities are described in Section 4.5. There are 4697 currently two optional capabilities defined; they are 4698 represented by the T-bit and E-bit found in the Options 4699 field. The rest of the Options field should be set to zero. 4701 The E-bit represents OSPF's ExternalRoutingCapability. This 4702 bit should be set in all LSAs associated with the backbone, 4703 and all LSAs associated with non-stub areas (see Section 4704 3.6). It should also be set in all AS-external-LSAs. It 4705 should be reset in all router-LSAs, network-LSAs and 4706 summary-LSAs associated with a stub area. For all LSAs, the 4707 setting of the E-bit is for informational purposes only; it 4708 does not affect the routing table calculation. 4710 The T-bit represents OSPF's TOS routing capability. This 4711 bit should be set in a router-LSA if and only if the router 4712 is capable of calculating separate routes for each IP TOS 4713 (see Section 2.5). The T-bit should always be set in 4714 network-LSAs. It should be set in summary-LSAs and AS- 4715 external-LSAs if and only if the LSA describes paths for all 4716 TOS values, instead of just the TOS 0 path. Note that, with 4717 the T-bit set, there may still be only a single metric in 4718 the LSA (the TOS 0 metric). This would mean that paths for 4719 non-zero TOS exist, but are equivalent to the TOS 0 path. 4720 An LSA's T-bit is examined when calculating the routing 4721 table's non-zero TOS paths (see Section 16.9). 4723 12.1.3. LS type 4725 The LS type field dictates the format and function of the 4726 LSA. LSAs of different types have different names (e.g., 4727 router-LSAs or network-LSAs). All LSA types defined by this 4728 memo, except the AS-external-LSAs (LS type = 5), are flooded 4729 throughout a single area only. AS-external-LSAs are flooded 4730 throughout the entire Autonomous System, excepting stub 4731 areas (see Section 3.6). Each separate LSA type is briefly 4732 described below in Table 15. 4734 LS Type LSA description 4735 ________________________________________________ 4736 1 These are the router-LSAs. 4737 They describe the collected 4738 states of the router's 4739 interfaces. For more information, 4740 consult Section 12.4.1. 4741 ________________________________________________ 4742 2 These are the network-LSAs. 4743 They describe the set of routers 4744 attached to the network. For 4745 more information, consult 4746 Section 12.4.2. 4747 ________________________________________________ 4748 3 or 4 These are the summary-LSAs. 4749 They describe inter-area routes, 4750 and enable the condensation of 4751 routing information at area 4752 borders. Originated by area border 4753 routers, the Type 3 summary-LSAs 4754 describe routes to networks while the 4755 Type 4 summary-LSAs describe routes to 4756 AS boundary routers. 4757 ________________________________________________ 4758 5 These are the AS-external-LSAs. 4759 Originated by AS boundary routers, 4760 they describe routes 4761 to destinations external to the 4762 Autonomous System. A default route for 4763 the Autonomous System can also be 4764 described by an AS-external-LSA. 4766 Table 15: OSPF link state advertisements (LSAs). 4768 12.1.4. Link State ID 4770 This field identifies the piece of the routing domain that 4771 is being described by the LSA. Depending on the LSA's LS 4772 type, the Link State ID takes on the values listed in Table 4773 16. 4775 Actually, for Type 3 summary-LSAs (LS type = 3) and AS- 4776 external-LSAs (LS type = 5), the Link State ID may 4777 additionally have one or more of the destination network's 4778 "host" bits set. For example, when originating an AS- 4779 external-LSA for the network 10.0.0.0 with mask of 4780 255.0.0.0, the Link State ID can be set to anything in the 4781 range 10.0.0.0 through 10.255.255.255 inclusive (although 4782 10.0.0.0 should be used whenever possible). The freedom to 4783 set certain host bits allows a router to originate separate 4784 LSAs for two networks having the same address but different 4785 masks. See Appendix E for details. 4787 When the LSA is describing a network (LS type = 2, 3 or 5), 4788 the network's IP address is easily derived by masking the 4789 Link State ID with the network/subnet mask contained in the 4790 body of the LSA. When the LSA is describing a router (LS 4791 type = 1 or 4), the Link State ID is always the described 4792 router's OSPF Router ID. 4794 When an AS-external-LSA (LS Type = 5) is describing a 4795 default route, its Link State ID is set to 4796 DefaultDestination (0.0.0.0). 4798 LS Type Link State ID 4799 _______________________________________________ 4800 1 The originating router's Router ID. 4801 2 The IP interface address of the 4802 network's Designated Router. 4803 3 The destination network's IP address. 4804 4 The Router ID of the described AS 4805 boundary router. 4806 5 The destination network's IP address. 4808 Table 16: The LSA's Link State ID. 4810 12.1.5. Advertising Router 4812 This field specifies the OSPF Router ID of the LSA's 4813 originator. For router-LSAs, this field is identical to the 4814 Link State ID field. Network-LSAs are originated by the 4815 network's Designated Router. Summary-LSAs originated by 4816 area border routers. AS-external-LSAs are originated by AS 4817 boundary routers. 4819 12.1.6. LS sequence number 4821 The sequence number field is a signed 32-bit integer. It is 4822 used to detect old and duplicate LSAs. The space of 4823 sequence numbers is linearly ordered. The larger the 4824 sequence number (when compared as signed 32-bit integers) 4825 the more recent the LSA. To describe to sequence number 4826 space more precisely, let N refer in the discussion below to 4827 the constant 2**31. 4829 The sequence number -N (0x80000000) is reserved (and 4830 unused). This leaves -N + 1 (0x80000001) as the smallest 4831 (and therefore oldest) sequence number; this sequence number 4832 is referred to as the constant InitialSequenceNumber. A 4833 router uses InitialSequenceNumber the first time it 4834 originates any LSA. Afterwards, the LSA's sequence number 4835 is incremented each time the router originates a new 4836 instance of the LSA. When an attempt is made to increment 4837 the sequence number past the maximum value of N - 1 4838 (0x7fffffff; also referred to as MaxSequenceNumber), the 4839 current instance of the LSA must first be flushed from the 4840 routing domain. This is done by prematurely aging the LSA 4841 (see Section 14.1) and reflooding it. As soon as this flood 4842 has been acknowledged by all adjacent neighbors, a new 4843 instance can be originated with sequence number of 4844 InitialSequenceNumber. 4846 The router may be forced to promote the sequence number of 4847 one of its LSAs when a more recent instance of the LSA is 4848 unexpectedly received during the flooding process. This 4849 should be a rare event. This may indicate that an out-of- 4850 date LSA, originated by the router itself before its last 4851 restart/reload, still exists in the Autonomous System. For 4852 more information see Section 13.4. 4854 12.1.7. LS checksum 4856 This field is the checksum of the complete contents of the 4857 LSA, excepting the LS age field. The LS age field is 4858 excepted so that an LSA's age can be incremented without 4859 updating the checksum. The checksum used is the same that 4860 is used for ISO connectionless datagrams; it is commonly 4861 referred to as the Fletcher checksum. It is documented in 4862 Annex B of [Ref6]. The LSA header also contains the length 4863 of the LSA in bytes; subtracting the size of the LS age 4864 field (two bytes) yields the amount of data to checksum. 4866 The checksum is used to detect data corruption of an LSA. 4867 This corruption can occur while an LSA is being flooded, or 4868 while it is being held in a router's memory. The LS 4869 checksum field cannot take on the value of zero; the 4870 occurrence of such a value should be considered a checksum 4871 failure. In other words, calculation of the checksum is not 4872 optional. 4874 The checksum of an LSA is verified in two cases: a) when it 4875 is received in a Link State Update Packet and b) at times 4876 during the aging of the link state database. The detection 4877 of a checksum failure leads to separate actions in each 4878 case. See Sections 13 and 14 for more details. 4880 Whenever the LS sequence number field indicates that two 4881 instances of an LSA are the same, the LS checksum field is 4882 examined. If there is a difference, the instance with the 4883 larger LS checksum is considered to be most recent.[13] See 4884 Section 13.1 for more details. 4886 12.2. The link state database 4888 A router has a separate link state database for every area to 4889 which it belongs. All routers belonging to the same area have 4890 identical link state databases for the area. 4892 The databases for each individual area are always dealt with 4893 separately. The shortest path calculation is performed 4894 separately for each area (see Section 16). Components of the 4895 area link-state database are flooded throughout the area only. 4896 Finally, when an adjacency (belonging to Area A) is being 4897 brought up, only the database for Area A is synchronized between 4898 the two routers. 4900 The area database is composed of router-LSAs, network-LSAs and 4901 summary-LSAs (all listed in the area data structure). In 4902 addition, external routes (AS-external-LSAs) are included in all 4903 non-stub area databases (see Section 3.6). 4905 An implementation of OSPF must be able to access individual 4906 pieces of an area database. This lookup function is based on an 4907 LSA's LS type, Link State ID and Advertising Router.[14] There 4908 will be a single instance (the most up-to-date) of each LSA in 4909 the database. The database lookup function is invoked during 4910 the LSA flooding procedure (Section 13) and the routing table 4911 calculation (Section 16). In addition, using this lookup 4912 function the router can determine whether it has itself ever 4913 originated a particular LSA, and if so, with what LS sequence 4914 number. 4916 An LSA is added to a router's database when either a) it is 4917 received during the flooding process (Section 13) or b) it is 4918 originated by the router itself (Section 12.4). An LSA is 4919 deleted from a router's database when either a) it has been 4920 overwritten by a newer instance during the flooding process 4921 (Section 13) or b) the router originates a newer instance of one 4922 of its self-originated LSAs (Section 12.4) or c) the LSA ages 4923 out and is flushed from the routing domain (Section 14). 4924 Whenever an LSA is deleted from the database it must also be 4925 removed from all neighbors' Link state retransmission lists (see 4926 Section 10). 4928 12.3. Representation of TOS 4930 All OSPF LSAs (with the exception of network-LSAs) specify 4931 metrics. In router-LSAs, the metrics indicate the costs of the 4932 described interfaces. In summary-LSAs and AS-external-LSAs, the 4933 metric indicates the cost of the described path. In all of 4934 these LSAs, a separate metric can be specified for each IP TOS. 4935 The encoding of TOS in OSPF LSAs is specified in Table 17. That 4936 table relates the OSPF encoding to the IP packet header's TOS 4937 field (defined in [Ref12]). The OSPF encoding is expressed as a 4938 decimal integer, and the IP packet header's TOS field is 4939 expressed in the binary TOS values used in [Ref12]. 4941 OSPF encoding RFC 1349 TOS values 4942 ___________________________________________ 4943 0 0000 normal service 4944 2 0001 minimize monetary cost 4945 4 0010 maximize reliability 4946 6 0011 4947 8 0100 maximize throughput 4948 10 0101 4949 12 0110 4950 14 0111 4951 16 1000 minimize delay 4952 18 1001 4953 20 1010 4954 22 1011 4955 24 1100 4956 26 1101 4957 28 1110 4958 30 1111 4960 Table 17: Representing TOS in OSPF. 4962 Each OSPF LSA must specify the TOS 0 metric. Other TOS metrics, 4963 if they appear, must appear in order of increasing TOS encoding. 4964 For example, the TOS 8 (maximize throughput) metric must always 4965 appear before the TOS 16 (minimize delay) metric when both are 4966 specified. If a metric for some non-zero TOS is not specified, 4967 its cost defaults to the cost for TOS 0, unless the T-bit is 4968 reset in the LSA's Options field (see Section 12.1.2 for more 4969 details). 4971 12.4. Originating LSAs 4973 Into any given OSPF area, a router will originate several LSAs. 4974 Each router originates a router-LSA. If the router is also the 4975 Designated Router for any of the area's networks, it will 4976 originate network-LSAs for those networks. 4978 Area border routers originate a single summary-LSA for each 4979 known inter-area destination. AS boundary routers originate a 4980 single AS-external-LSA for each known AS external destination. 4981 Destinations are advertised one at a time so that the change in 4982 any single route can be flooded without reflooding the entire 4983 collection of routes. During the flooding procedure, many LSAs 4984 can be carried by a single Link State Update packet. 4986 As an example, consider Router RT4 in Figure 6. It is an area 4987 border router, having a connection to Area 1 and the backbone. 4988 Router RT4 originates 5 distinct LSAs into the backbone (one 4989 router-LSA, and one summary-LSA for each of the networks N1-N4). 4990 Router RT4 will also originate 8 distinct LSAs into Area 1 (one 4991 router-LSA and seven summary-LSAs as pictured in Figure 7). If 4992 RT4 has been selected as Designated Router for Network N3, it 4993 will also originate a network-LSA for N3 into Area 1. 4995 In this same figure, Router RT5 will be originating 3 distinct 4996 AS-external-LSAs (one for each of the networks N12-N14). These 4997 will be flooded throughout the entire AS, assuming that none of 4998 the areas have been configured as stubs. However, if area 3 has 4999 been configured as a stub area, the AS-external-LSAs for 5000 networks N12-N14 will not be flooded into area 3 (see Section 5001 3.6). Instead, Router RT11 would originate a default summary- 5002 LSA that would be flooded throughout area 3 (see Section 5003 12.4.3). This instructs all of area 3's internal routers to 5004 send their AS external traffic to RT11. 5006 Whenever a new instance of an LSA is originated, its LS sequence 5007 number is incremented, its LS age is set to 0, its LS checksum 5008 is calculated, and the LSA is added to the link state database 5009 and flooded out the appropriate interfaces. See Section 13.2 5010 for details concerning the installation of the LSA into the link 5011 state database. See Section 13.3 for details concerning the 5012 flooding of newly originated LSAs. 5014 The ten events that can cause a new instance of an LSA to be 5015 originated are: 5017 (1) The LS age field of one of the router's self-originated LSAs 5018 reaches the value LSRefreshTime. In this case, a new 5019 instance of the LSA is originated, even though the contents 5020 of the LSA (apart from the LSA header) will be the same. 5021 This guarantees periodic originations of all LSAs. This 5022 periodic updating of LSAs adds robustness to the link state 5023 algorithm. LSAs that solely describe unreachable 5024 destinations should not be refreshed, but should instead be 5025 flushed from the routing domain (see Section 14.1). 5027 When whatever is being described by an LSA changes, a new LSA is 5028 originated. However, two instances of the same LSA may not be 5029 originated within the time period MinLSInterval. This may 5030 require that the generation of the next instance be delayed by 5031 up to MinLSInterval. The following events may cause the 5032 contents of an LSA to change. These events should cause new 5033 originations if and only if the contents of the new LSA would be 5034 different: 5036 (2) An interface's state changes (see Section 9.1). This may 5037 mean that it is necessary to produce a new instance of the 5038 router-LSA. 5040 (3) An attached network's Designated Router changes. A new 5041 router-LSA should be originated. Also, if the router itself 5042 is now the Designated Router, a new network-LSA should be 5043 produced. If the router itself is no longer the Designated 5044 Router, any network-LSA that it might have originated for 5045 the network should be flushed from the routing domain (see 5046 Section 14.1). 5048 (4) One of the neighboring routers changes to/from the FULL 5049 state. This may mean that it is necessary to produce a new 5050 instance of the router-LSA. Also, if the router is itself 5051 the Designated Router for the attached network, a new 5052 network-LSA should be produced. 5054 The next four events concern area border routers only: 5056 (5) An intra-area route has been added/deleted/modified in the 5057 routing table. This may cause a new instance of a summary- 5058 LSA (for this route) to be originated in each attached area 5059 (possibly including the backbone). 5061 (6) An inter-area route has been added/deleted/modified in the 5062 routing table. This may cause a new instance of a summary- 5063 LSA (for this route) to be originated in each attached area 5064 (but NEVER for the backbone). 5066 (7) The router becomes newly attached to an area. The router 5067 must then originate summary-LSAs into the newly attached 5068 area for all pertinent intra-area and inter-area routes in 5069 the router's routing table. See Section 12.4.3 for more 5070 details. 5072 (8) When the state of one of the router's configured virtual 5073 links changes, it may be necessary to originate a new 5074 router-LSA into the virtual link's Transit area (see the 5075 discussion of the router-LSA's bit V in Section 12.4.1), as 5076 well as originating a new router-LSA into the backbone. 5078 The last two events concern AS boundary routers (and former AS 5079 boundary routers) only: 5081 (9) An external route gained through direct experience with an 5082 external routing protocol (like BGP) changes. This will 5083 cause an AS boundary router to originate a new instance of 5084 an AS-external-LSA. 5086 (10) 5087 A router ceases to be an AS boundary router, perhaps after 5088 restarting. In this situation the router should flush all 5089 AS-external-LSAs that it had previously originated. These 5090 LSAs can be flushed via the premature aging procedure 5091 specified in Section 14.1. 5093 The construction of each type of LSA is explained in detail 5094 below. In general, these sections describe the contents of the 5095 LSA body (i.e., the part coming after the 20-byte LSA header). 5096 For information concerning the building of the LSA header, see 5097 Section 12.1. 5099 12.4.1. Router-LSAs 5101 A router originates a router-LSA for each area that it 5102 belongs to. Such an LSA describes the collected states of 5103 the router's links to the area. The LSA is flooded 5104 throughout the particular area, and no further. 5106 The format of a router-LSA is shown in Appendix A (Section 5107 A.4.2). The first 20 bytes of the LSA consist of the 5108 generic LSA header that was discussed in Section 12.1. 5109 router-LSAs have LS type = 1. The router indicates whether 5110 it is willing to calculate separate routes for each IP TOS 5111 by setting (or resetting) the T-bit of the LSA's Options 5112 field. 5114 A router also indicates whether it is an area border router, 5115 or an AS boundary router, by setting the appropriate bits 5116 (bit B and bit E, respectively) in its router-LSAs. This 5117 enables paths to those types of routers to be saved in the 5118 routing table, for later processing of summary-LSAs and AS- 5119 external-LSAs. Bit B should be set whenever the router is 5120 actively attached to two or more areas, even if the router 5121 .................................... 5122 . 192.1.2 Area 1 . 5123 . + . 5124 . | . 5125 . | 3+---+1 . 5126 . N1 |--|RT1|-----+ . 5127 . | +---+ \ . 5128 . | \ _______N3 . 5129 . + \/ \ . 1+---+ 5130 . * 192.1.1 *------|RT4| 5131 . + /\_______/ . +---+ 5132 . | / | . 5133 . | 3+---+1 / | . 5134 . N2 |--|RT2|-----+ 1| . 5135 . | +---+ +---+8 . 6+---+ 5136 . | |RT3|----------------|RT6| 5137 . + +---+ . +---+ 5138 . 192.1.3 |2 . 18.10.0.6|7 5139 . | . | 5140 . +------------+ . 5141 . 192.1.4 (N4) . 5142 .................................... 5144 Figure 15: Area 1 with IP addresses shown 5146 is not currently attached to the OSPF backbone area. Bit E 5147 should never be set in a router-LSA for a stub area (stub 5148 areas cannot contain AS boundary routers). 5150 In addition, the router sets bit V in its router-LSA for 5151 Area A if and only if the router is the endpoint of one or 5152 more fully adjacent virtual links having Area A as their 5153 Transit area. The setting of bit V enables other routers in 5154 Area A to discover whether the area supports transit traffic 5155 (see TransitCapability in Section 6). 5157 The router-LSA then describes the router's working 5158 connections (i.e., interfaces or links) to the area. Each 5159 link is typed according to the kind of attached network. 5160 Each link is also labelled with its Link ID. This Link ID 5161 gives a name to the entity that is on the other end of the 5162 link. Table 18 summarizes the values used for the Type and 5163 Link ID fields. 5165 Link type Description Link ID 5166 __________________________________________________ 5167 1 Point-to-point Neighbor Router ID 5168 link 5169 2 Link to transit Interface address of 5170 network Designated Router 5171 3 Link to stub IP network number 5172 network 5173 4 Virtual link Neighbor Router ID 5175 Table 18: Link descriptions in the 5176 router-LSA. 5178 In addition, the Link Data field is specified for each link. 5179 This field gives 32 bits of extra information for the link. 5180 For links to transit networks, numbered point-to-point links 5181 and virtual links, this field specifies the IP interface 5182 address of the associated router interface (this is needed 5183 by the routing table calculation, see Section 16.1.1). For 5184 links to stub networks, this field specifies the stub 5185 network's IP address mask. For unnumbered point-to-point 5186 links, the Link Data field should be set to the unnumbered 5187 interface's MIB-II [Ref8] ifIndex value. 5189 Finally, the cost of using the link for output (possibly 5190 specifying a different cost for each Type of Service) is 5191 specified. The output cost of a link is configurable. With 5192 the exception of links to stub networks, the output cost 5193 must always be non-zero. 5195 To further describe the process of building the list of link 5196 descriptions, suppose a router wishes to build a router-LSA 5197 for Area A. The router examines its collection of interface 5198 data structures. For each interface, the following steps 5199 are taken: 5201 o If the attached network does not belong to Area A, no 5202 links are added to the LSA, and the next interface 5203 should be examined. 5205 o If the state of the interface is Down, no links are 5206 added. 5208 o If the state of the interface is Loopback, add a Type 3 5209 link (stub network) as long as this is not an interface 5210 to an unnumbered point-to-point network. The Link ID 5211 should be set to the IP interface address, the Link Data 5212 set to the mask 0xffffffff (indicating a host route), 5213 and the cost set to 0. 5215 o Otherwise, the link descriptions added to the router-LSA 5216 depend on the OSPF interface type. Link descriptions 5217 used for point-to-point interfaces are specified in 5218 Section 12.4.1.1, for virtual links in Section 12.4.1.2, 5219 for broadcast and NBMA interfaces in 12.4.1.3, and for 5220 Point-to-MultiPoint interfaces in 12.4.1.4. 5222 After consideration of all the router interfaces, host links 5223 are added to the router-LSA by examining the list of 5224 attached hosts belonging to Area A. A host route is 5225 represented as a Type 3 link (stub network) whose Link ID is 5226 the host's IP address, Link Data is the mask of all ones 5227 (0xffffffff), and cost the host's configured cost (see 5228 Section C.7). 5230 12.4.1.1. Describing point-to-point interfaces 5232 For point-to-point interfaces, one or more link 5233 descriptions are added to the router-LSA as follows: 5235 o If the neighboring router is fully adjacent, add a 5236 Type 1 link (point-to-point). The Link ID should be 5237 set to the Router ID of the neighboring router. For 5238 numbered point-to-point networks, the Link Data 5239 should specify the IP interface address. For 5240 unnumbered point-to-point networks, the Link Data 5241 field should specify the interface's MIB-II [Ref8] 5242 ifIndex value. The cost should be set to the output 5243 cost of the point-to-point interface. 5245 o In addition, as long as the state of the interface 5246 is "Point-to-Point" (and regardless of the 5247 neighboring router state), a Type 3 link (stub 5248 network) should be added. There are two forms that 5249 this stub link can take: 5251 Option 1 5252 Assuming that the neighboring router's IP 5253 address is known, set the Link ID of the Type 3 5254 link to the neighbor's IP address, the Link Data 5255 to the mask 0xffffffff (indicating a host 5256 route), and the cost to the interface's 5257 configured output cost.[15] 5259 Option 2 5260 If a subnet has been assigned to the point-to- 5261 point link, set the Link ID of the Type 3 link 5262 to the subnet's IP address, the Link Data to the 5263 subnet's mask, and the cost to the interface's 5264 configured output cost.[16] 5266 12.4.1.2. Describing broadcast and NBMA interfaces 5268 For operational broadcast and NBMA interfaces, a single 5269 link description is added to the router-LSA as follows: 5271 o If the state of the interface is Waiting, add a Type 5272 3 link (stub network) with Link ID set to the IP 5273 network number of the attached network, Link Data 5274 set to the attached network's address mask, and cost 5275 equal to the interface's configured output cost. 5277 o Else, there has been a Designated Router elected for 5278 the attached network. If the router is fully 5279 adjacent to the Designated Router, or if the router 5280 itself is Designated Router and is fully adjacent to 5281 at least one other router, add a single Type 2 link 5282 (transit network) with Link ID set to the IP 5283 interface address of the attached network's 5284 Designated Router (which may be the router itself), 5285 Link Data set to the router's own IP interface 5286 address, and cost equal to the interface's 5287 configured output cost. Otherwise, add a link as if 5288 the interface state were Waiting (see above). 5290 12.4.1.3. Describing virtual links 5292 For virtual links, a link description is added to the 5293 router-LSA only when the virtual neighbor is fully 5294 adjacent. In this case, add a Type 4 link (virtual link) 5295 with Link ID set to the Router ID of the virtual 5296 neighbor, Link Data set to the IP interface address 5297 associated with the virtual link and cost set to the 5298 cost calculated for the virtual link during the routing 5299 table calculation (see Section 15). 5301 12.4.1.4. Describing Point-to-MultiPoint interfaces 5303 For operational Point-to-MultiPoint interfaces, one or 5304 more link descriptions are added to the router-LSA as 5305 follows: 5307 o A single Type 3 link (stub network) is added with 5308 Link ID set to the router's own IP interface 5309 address, Link Data set to the mask 0xffffffff 5310 (indicating a host route), and cost set to 0. 5312 o For each fully adjacent neighbor associated with the 5313 interface, add an additional Type 1 link (point-to- 5314 point) with Link ID set to the Router ID of the 5315 neighboring router, Link Data set to the IP 5316 interface address and cost equal to the interface's 5317 configured output cost. 5319 12.4.1.5. Examples of router-LSAs 5321 Consider the router-LSAs generated by Router RT3, as 5322 pictured in Figure 6. The area containing Router RT3 5323 (Area 1) has been redrawn, with actual network 5324 addresses, in Figure 15. Assume that the last byte of 5325 all of RT3's interface addresses is 3, giving it the 5326 interface addresses 192.1.1.3 and 192.1.4.3, and that 5327 the other routers have similar addressing schemes. In 5328 addition, assume that all links are functional, and that 5329 Router IDs are assigned as the smallest IP interface 5330 address. 5332 RT3 originates two router-LSAs, one for Area 1 and one 5333 for the backbone. Assume that Router RT4 has been 5334 selected as the Designated router for network 192.1.1.0. 5335 RT3's router-LSA for Area 1 is then shown below. It 5336 indicates that RT3 has two connections to Area 1, the 5337 first a link to the transit network 192.1.1.0 and the 5338 second a link to the stub network 192.1.4.0. Note that 5339 the transit network is identified by the IP interface of 5340 its Designated Router (i.e., the Link ID = 192.1.1.4 5341 which is the Designated Router RT4's IP interface to 5342 192.1.1.0). Note also that RT3 has indicated that it is 5343 capable of calculating separate routes based on IP TOS, 5344 through setting the T-bit in the Options field. It has 5345 also indicated that it is an area border router. 5347 ; RT3's router-LSA for Area 1 5348 LS age = 0 ;always true on origination 5349 Options = (T-bit|E-bit) ;TOS-capable 5350 LS type = 1 ;indicates router-LSA 5351 Link State ID = 192.1.1.3 ;RT3's Router ID 5352 Advertising Router = 192.1.1.3 ;RT3's Router ID 5353 bit E = 0 ;not an AS boundary router 5354 bit B = 1 ;area border router 5355 #links = 2 5356 Link ID = 192.1.1.4 ;IP address of Desig. Rtr. 5357 Link Data = 192.1.1.3 ;RT3's IP interface to net 5358 Type = 2 ;connects to transit network 5359 # other metrics = 0 5360 TOS 0 metric = 1 5362 Link ID = 192.1.4.0 ;IP Network number 5363 Link Data = 0xffffff00 ;Network mask 5364 Type = 3 ;connects to stub network 5365 # other metrics = 0 5366 TOS 0 metric = 2 5368 Next RT3's router-LSA for the backbone is shown. It 5369 indicates that RT3 has a single attachment to the 5370 backbone. This attachment is via an unnumbered point- 5371 to-point link to Router RT6. RT3 has again indicated 5372 that it is TOS-capable, and that it is an area border 5373 router. 5375 ; RT3's router-LSA for the backbone 5377 LS age = 0 ;always true on origination 5378 Options = (T-bit|E-bit) ;TOS-capable 5379 LS type = 1 ;indicates router-LSA 5380 Link State ID = 192.1.1.3 ;RT3's router ID 5381 Advertising Router = 192.1.1.3 ;RT3's router ID 5382 bit E = 0 ;not an AS boundary router 5383 bit B = 1 ;area border router 5384 #links = 1 5385 Link ID = 18.10.0.6 ;Neighbor's Router ID 5386 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5387 Type = 1 ;connects to router 5388 # other metrics = 0 5389 TOS 0 metric = 8 5391 Even though Router RT3 has indicated that it is TOS- 5392 capable in the above examples, only a single metric (the 5393 TOS 0 metric) has been specified for each interface. 5394 Different metrics can be specified for each TOS. The 5395 encoding of TOS in OSPF LSAs is described in Section 5396 12.3. 5398 As an example, suppose the point-to-point link between 5399 Routers RT3 and RT6 in Figure 15 is a satellite link. 5400 The AS administrator may want to encourage the use of 5401 the line for high bandwidth traffic. This would be done 5402 by setting the metric artificially low for the 5403 appropriate TOS value. Router RT3 would then originate 5404 the following router-LSA for the backbone (TOS 8 = 5405 maximize throughput): 5407 ; RT3's router-LSA for the backbone 5409 LS age = 0 ;always true on origination 5410 Options = (T-bit|E-bit) ;TOS-capable 5411 LS type = 1 ;indicates router-LSA 5412 Link State ID = 192.1.1.3 ;RT3's Router ID 5413 Advertising Router = 192.1.1.3 5414 bit E = 0 ;not an AS boundary router 5415 bit B = 1 ;area border router 5416 #links = 1 5417 Link ID = 18.10.0.6 ;Neighbor's Router ID 5418 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5419 Type = 1 ;connects to router 5420 # other metrics = 1 5421 TOS 0 metric = 8 5422 TOS = 8 ;maximize throughput 5423 metric = 1 ;traffic preferred 5425 12.4.2. Network-LSAs 5427 A network-LSA is generated for every transit broadcast or 5428 NBMA network. (A transit network is a network having two or 5429 more attached routers). The network-LSA describes all the 5430 routers that are attached to the network. 5432 The Designated Router for the network originates the LSA. 5433 The Designated Router originates the LSA only if it is fully 5434 adjacent to at least one other router on the network. The 5435 network-LSA is flooded throughout the area that contains the 5436 transit network, and no further. The network-LSA lists 5437 those routers that are fully adjacent to the Designated 5438 Router; each fully adjacent router is identified by its OSPF 5439 Router ID. The Designated Router includes itself in this 5440 list. 5442 The Link State ID for a network-LSA is the IP interface 5443 address of the Designated Router. This value, masked by the 5444 network's address mask (which is also contained in the 5445 network-LSA) yields the network's IP address. 5447 A router that has formerly been the Designated Router for a 5448 network, but is no longer, should flush the network-LSA that 5449 it had previously originated. This LSA is no longer used in 5450 the routing table calculation. It is flushed by prematurely 5451 incrementing the LSA's age to MaxAge and reflooding (see 5452 Section 14.1). In addition, in those rare cases where a 5453 router's Router ID has changed, any network-LSAs that were 5454 originated with the router's previous Router ID must be 5455 flushed. Since the router may have no idea what it's 5456 previous Router ID might have been, these network-LSAs are 5457 indicated by having their Link State ID equal to one of the 5458 router's IP interface addresses and their Advertising Router 5459 equal to some value other than the router's current Router 5460 ID (see Section 13.4 for more details). 5462 12.4.2.1. Examples of network-LSAs 5464 Again consider the area configuration in Figure 6. 5465 Network-LSAs are originated for Network N3 in Area 1, 5466 Networks N6 and N8 in Area 2, and Network N9 in Area 3. 5467 Assuming that Router RT4 has been selected as the 5468 Designated Router for Network N3, the following 5469 network-LSA is generated by RT4 on behalf of Network N3 5470 (see Figure 15 for the address assignments): 5472 ; Network-LSA for Network N3 5474 LS age = 0 ;always true on origination 5475 Options = (T-bit|E-bit) ;TOS-capable 5476 LS type = 2 ;indicates network-LSA 5477 Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. 5478 Advertising Router = 192.1.1.4 ;RT4's Router ID 5479 Network Mask = 0xffffff00 5480 Attached Router = 192.1.1.4 ;Router ID 5481 Attached Router = 192.1.1.1 ;Router ID 5482 Attached Router = 192.1.1.2 ;Router ID 5483 Attached Router = 192.1.1.3 ;Router ID 5485 12.4.3. Summary-LSAs 5487 The destination described by a summary-LSA is either an IP 5488 network, an AS boundary router or a range of IP addresses. 5490 Summary-LSAs are flooded throughout a single area only. The 5491 destination described is one that is external to the area, 5492 yet still belongs to the Autonomous System. 5494 Summary-LSAs are originated by area border routers. The 5495 precise summary routes to advertise into an area are 5496 determined by examining the routing table structure (see 5497 Section 11) in accordance with the algorithm described 5498 below. Note that only intra-area routes are advertised into 5499 the backbone, while both intra-area and inter-area routes 5500 are advertised into the other areas. 5502 To determine which routes to advertise into an attached Area 5503 A, each routing table entry is processed as follows. 5504 Remember that each routing table entry describes a set of 5505 equal-cost best paths to a particular destination: 5507 o Only Destination Types of network and AS boundary router 5508 are advertised in summary-LSAs. If the routing table 5509 entry's Destination Type is area border router, examine 5510 the next routing table entry. 5512 o AS external routes are never advertised in summary-LSAs. 5513 If the routing table entry has Path-type of type 1 5514 external or type 2 external, examine the next routing 5515 table entry. 5517 o Else, if the area associated with this set of paths is 5518 the Area A itself, do not generate a summary-LSA for the 5519 route.[17] 5521 o Else, if the next hops associated with this set of paths 5522 belong to Area A itself, do not generate a summary-LSA 5523 for the route.[18] This is the logical equivalent of a 5524 Distance Vector protocol's split horizon logic. 5526 o Else, if the routing table cost equals or exceeds the 5527 value LSInfinity, a summary-LSA cannot be generated for 5528 this route. 5530 o Else, if the destination of this route is an AS boundary 5531 router, a summary-LSA should be originated if and only 5532 if the routing table entry describes the preferred path 5533 to the AS boundary router (see Step 3 of Section 16.4). 5534 If so, a Type 4 summary-LSA is originated for the 5535 destination, with Link State ID equal to the AS boundary 5536 router's Router ID and metric equal to the routing table 5537 entry's cost. Note: these LSAs should not be generated 5538 if Area A has been configured as a stub area. 5540 o Else, the Destination type is network. If this is an 5541 inter-area route, generate a Type 3 summary-LSA for the 5542 destination, with Link State ID equal to the network's 5543 address (if necessary, the Link State ID can also have 5544 one or more of the network's host bits set; see Appendix 5545 E for details) and metric equal to the routing table 5546 cost. 5548 o The one remaining case is an intra-area route to a 5549 network. This means that the network is contained in 5550 one of the router's directly attached areas. In 5551 general, this information must be condensed before 5552 appearing in summary-LSAs. Remember that an area has a 5553 configured list of address ranges, each range consisting 5554 of an [address,mask] pair and a status indication of 5555 either Advertise or DoNotAdvertise. At most a single 5556 Type 3 summary-LSA is originated for each range. When 5557 the range's status indicates Advertise, a Type 3 5558 summary-LSA is generated with Link State ID equal to the 5559 range's address (if necessary, the Link State ID can 5560 also have one or more of the range's "host" bits set; 5561 see Appendix E for details) and cost equal to the 5562 largest cost of any of the component networks. When the 5563 range's status indicates DoNotAdvertise, the Type 3 5564 summary-LSA is suppressed and the component networks 5565 remain hidden from other areas. 5567 By default, if a network is not contained in any 5568 explicitly configured address range, a Type 3 summary- 5569 LSA is generated with Link State ID equal to the 5570 network's address (if necessary, the Link State ID can 5571 also have one or more of the network's "host" bits set; 5572 see Appendix E for details) and metric equal to the 5573 network's routing table cost. 5575 If an area is capable of carrying transit traffic (i.e., 5576 its TransitCapability is set to TRUE), routing 5577 information concerning backbone networks should not be 5578 condensed before being summarized into the area. Nor 5579 should the advertisement of backbone networks into 5580 transit areas be suppressed. In other words, the 5581 backbone's configured ranges should be ignored when 5582 originating summary-LSAs into transit areas. 5584 If a router advertises a summary-LSA for a destination which 5585 then becomes unreachable, the router must then flush the LSA 5586 from the routing domain by setting its age to MaxAge and 5587 reflooding (see Section 14.1). Also, if the destination is 5588 still reachable, yet can no longer be advertised according 5589 to the above procedure (e.g., it is now an inter-area route, 5590 when it used to be an intra-area route associated with some 5591 non-backbone area; it would thus no longer be advertisable 5592 to the backbone), the LSA should also be flushed from the 5593 routing domain. 5595 For the destination described by a summary-LSA there may be 5596 separate sets of paths, and therefore separate routing table 5597 entries, for each Type of Service. All these entries must 5598 be considered when building the summary-LSA for the 5599 destination; a single LSA must specify the separate costs 5600 (if they exist) for each TOS. The encoding of TOS in OSPF 5601 LSAs is described in Section 12.3. 5603 Clearing the T-bit in the Options field of a summary-LSA 5604 indicates that there is a TOS 0 path to the destination, but 5605 no paths for non-zero TOS. This can happen when non-TOS- 5606 capable routers exist in the routing domain (see Section 5607 2.5). 5609 12.4.3.1. Originating summary-LSAs into stub areas 5611 The algorithm in Section 12.4.3 is optional when Area A 5612 is an OSPF stub area. Area border routers connecting to 5613 a stub area can originate summary-LSAs into the area 5614 according to the Section 12.4.3's algorithm, or can 5615 choose to originate only a subset of the summary-LSAs, 5616 possibly under configuration control. The fewer LSAs 5617 originated, the smaller the stub area's link state 5618 database, further reducing the demands on its routers' 5619 resources. However, omitting LSAs may also lead to sub- 5620 optimal inter-area routing, although routing will 5621 continue to function. 5623 As specified in Section 12.4.3, Type 4 summary-LSAs 5624 (ASBR-summary-LSAs) are never originated into stub 5625 areas. 5627 In a stub area, instead of importing external routes 5628 each area border router originates a "default summary- 5629 LSA" into the area. The Link State ID for the default 5630 summary-LSA is set to DefaultDestination, and the metric 5631 set to the (per-area) configurable parameter 5632 StubDefaultCost. Note that StubDefaultCost need not be 5633 configured identically in all of the stub area's area 5634 border routers. 5636 12.4.3.2. Examples of summary-LSAs 5638 Consider again the area configuration in Figure 6. 5639 Routers RT3, RT4, RT7, RT10 and RT11 are all area border 5640 routers, and therefore are originating summary-LSAs. 5641 Consider in particular Router RT4. Its routing table 5642 was calculated as the example in Section 11.3. RT4 5643 originates summary-LSAs into both the backbone and Area 5644 1. Into the backbone, Router RT4 originates separate 5645 LSAs for each of the networks N1-N4. Into Area 1, 5646 Router RT4 originates separate LSAs for networks N6-N8 5647 and the AS boundary routers RT5,RT7. It also condenses 5648 host routes Ia and Ib into a single summary-LSA. 5649 Finally, the routes to networks N9,N10,N11 and Host H1 5650 are advertised by a single summary-LSA. This 5651 condensation was originally performed by the router 5652 RT11. 5654 These LSAs are illustrated graphically in Figures 7 and 5655 8. Two of the summary-LSAs originated by Router RT4 5656 follow. The actual IP addresses for the networks and 5657 routers in question have been assigned in Figure 15. 5659 ; Summary-LSA for Network N1, 5660 ; originated by Router RT4 into the backbone 5662 LS age = 0 ;always true on origination 5663 Options = (T-bit|E-bit) ;TOS-capable 5664 LS type = 3 ;Type 3 summary-LSA 5665 Link State ID = 192.1.2.0 ;N1's IP network number 5666 Advertising Router = 192.1.1.4 ;RT4's ID 5667 TOS = 0 5668 metric = 4 5670 ; Summary-LSA for AS boundary router RT7 5671 ; originated by Router RT4 into Area 1 5673 LS age = 0 ;always true on origination 5674 Options = (T-bit|E-bit) ;TOS-capable 5675 LS type = 4 ;Type 4 summary-LSA 5676 Link State ID = Router RT7's ID 5677 Advertising Router = 192.1.1.4 ;RT4's ID 5678 TOS = 0 5679 metric = 14 5681 12.4.4. AS-external-LSAs 5683 AS-external-LSAs describe routes to destinations external to 5684 the Autonomous System. Most AS-external-LSAs describe 5685 routes to specific external destinations; in these cases the 5686 LSA's Link State ID is set to the destination network's IP 5687 address (if necessary, the Link State ID can also have one 5688 or more of the network's "host" bits set; see Appendix E for 5689 details). However, a default route for the Autonomous 5690 System can be described in an AS-external-LSA by setting the 5691 LSA's Link State ID to DefaultDestination (0.0.0.0). AS- 5692 external-LSAs are originated by AS boundary routers. An AS 5693 boundary router originates a single AS-external-LSA for each 5694 external route that it has learned, either through another 5695 routing protocol (such as BGP), or through configuration 5696 information. 5698 AS-external-LSAs are the only type of LSAs that are flooded 5699 throughout the entire Autonomous System; all other types of 5700 LSAs are specific to a single area. However, AS-external- 5701 LSAs are not flooded into/throughout stub areas (see Section 5702 3.6). This enables a reduction in link state database size 5703 for routers internal to stub areas. 5705 The metric that is advertised for an external route can be 5706 one of two types. Type 1 metrics are comparable to the link 5707 state metric. Type 2 metrics are assumed to be larger than 5708 the cost of any intra-AS path. As with summary-LSAs, if 5709 separate paths exist based on TOS, separate TOS costs can be 5710 included in the AS-external-LSA The encoding of TOS in OSPF 5711 LSAs is described in Section 12.3. If the T-bit of the 5712 LSA's Options field is clear, no non-zero TOS paths to the 5713 destination exist. 5715 If a router advertises an AS-external-LSA for a destination 5716 which then becomes unreachable, the router must then flush 5717 the LSA from the routing domain by setting its age to MaxAge 5718 and reflooding (see Section 14.1). 5720 12.4.4.1. Examples of AS-external-LSAs 5722 Consider once again the AS pictured in Figure 6. There 5723 are two AS boundary routers: RT5 and RT7. Router RT5 5724 originates three AS-external-LSAs, for networks N12-N14. 5725 Router RT7 originates two AS-external-LSAs, for networks 5726 N12 and N15. Assume that RT7 has learned its route to 5727 N12 via BGP, and that it wishes to advertise a Type 2 5728 metric to the AS. RT7 would then originate the 5729 following LSA for N12: 5731 ; AS-external-LSA for Network N12, 5732 ; originated by Router RT7 5734 LS age = 0 ;always true on origination 5735 Options = (T-bit|E-bit) ;TOS-capable 5736 LS type = 5 ;AS-external-LSA 5737 Link State ID = N12's IP network number 5738 Advertising Router = Router RT7's ID 5739 bit E = 1 ;Type 2 metric 5740 TOS = 0 5741 metric = 2 5742 Forwarding address = 0.0.0.0 5744 In the above example, the forwarding address field has 5745 been set to 0.0.0.0, indicating that packets for the 5746 external destination should be forwarded to the 5747 advertising OSPF router (RT7). This is not always 5748 desirable. Consider the example pictured in Figure 16. 5749 There are three OSPF routers (RTA, RTB and RTC) 5750 connected to a common network. Only one of these 5751 routers, RTA, is exchanging BGP information with the 5752 non-OSPF router RTX. RTA must then originate AS- 5753 external-LSAs for those destinations it has learned from 5754 RTX. By using the AS-external-LSA's forwarding address 5755 field, RTA can specify that packets for these 5756 destinations be forwarded directly to RTX. Without this 5757 feature, Routers RTB and RTC would take an extra hop to 5758 get to these destinations. 5760 Note that when the forwarding address field is non-zero, 5761 it should point to a router belonging to another 5762 Autonomous System. 5764 A forwarding address can also be specified for the 5765 default route. For example, in figure 16 RTA may want 5766 to specify that all externally-destined packets should 5767 by default be forwarded to its BGP peer RTX. The 5768 resulting AS-external-LSA is pictured below. Note that 5769 the Link State ID is set to DefaultDestination. 5771 ; Default route, originated by Router RTA 5772 ; Packets forwarded through RTX 5774 LS age = 0 ;always true on origination 5775 Options = (T-bit|E-bit) ;TOS-capable 5776 LS type = 5 ;AS-external-LSA 5777 Link State ID = DefaultDestination ; default route 5778 Advertising Router = Router RTA's ID 5779 bit E = 1 ;Type 2 metric 5780 TOS = 0 5781 metric = 1 5782 Forwarding address = RTX's IP address 5784 In figure 16, suppose instead that both RTA and RTB 5785 exchange BGP information with RTX. In this case, RTA 5786 and RTB would originate the same set of AS-external- 5787 LSAs. These LSAs, if they specify the same metric, 5788 would be functionally equivalent since they would 5789 specify the same destination and forwarding address 5790 (RTX). This leads to a clear duplication of effort. If 5791 only one of RTA or RTB originated the set of AS- 5792 external-LSAs, the routing would remain the same, and 5793 the size of the link state database would decrease. 5794 However, it must be unambiguously defined as to which 5795 router originates the LSAs (otherwise neither may, or 5796 the identity of the originator may oscillate). The 5797 following rule is thereby established: if two routers, 5798 both reachable from one another, originate functionally 5799 equivalent AS-external-LSAs (i.e., same destination, 5800 cost and non-zero forwarding address), then the LSA 5801 originated by the router having the highest OSPF Router 5802 ID is used. The router having the lower OSPF Router ID 5803 can then flush its LSA. Flushing an LSA is discussed in 5804 Section 14.1. 5806 13. The Flooding Procedure 5808 Link State Update packets provide the mechanism for flooding LSAs. 5809 A Link State Update packet may contain several distinct LSAs, and 5810 floods each LSA one hop further from its point of origination. To 5811 make the flooding procedure reliable, each LSA must be acknowledged 5812 separately. Acknowledgments are transmitted in Link State 5813 Acknowledgment packets. Many separate acknowledgments can also be 5814 grouped together into a single packet. 5816 The flooding procedure starts when a Link State Update packet has 5817 been received. Many consistency checks have been made on the 5818 received packet before being handed to the flooding procedure (see 5819 Section 8.2). In particular, the Link State Update packet has been 5821 + 5822 | 5823 +---+.....|.BGP 5824 |RTA|-----|.....+---+ 5825 +---+ |-----|RTX| 5826 | +---+ 5827 +---+ | 5828 |RTB|-----| 5829 +---+ | 5830 | 5831 +---+ | 5832 |RTC|-----| 5833 +---+ | 5834 | 5835 + 5837 Figure 16: Forwarding address example 5839 associated with a particular neighbor, and a particular area. If 5840 the neighbor is in a lesser state than Exchange, the packet should 5841 be dropped without further processing. 5843 All types of LSAs, other than AS-external-LSAs, are associated with 5844 a specific area. However, LSAs do not contain an area field. An 5845 LSA's area must be deduced from the Link State Update packet header. 5847 For each LSA contained in a Link State Update packet, the following 5848 steps are taken: 5850 (1) Validate the LSA's LS checksum. If the checksum turns out to be 5851 invalid, discard the LSA and get the next one from the Link 5852 State Update packet. 5854 (2) Examine the LSA's LS type. If the LS type is unknown, discard 5855 the LSA and get the next one from the Link State Update Packet. 5856 This specification defines LS types 1-5 (see Section 4.3). 5858 (3) Else if this is an AS-external-LSA (LS type = 5), and the area 5859 has been configured as a stub area, discard the LSA and get the 5860 next one from the Link State Update Packet. AS-external-LSAs 5861 are not flooded into/throughout stub areas (see Section 3.6). 5863 (4) Else if the LSA's LS age is equal to MaxAge, and there is 5864 currently no instance of the LSA in the router's link state 5865 database, then take the following actions: 5867 (a) Acknowledge the receipt of the LSA by sending a Link State 5868 Acknowledgment packet back to the sending neighbor (see 5869 Section 13.5). 5871 (b) Purge all outstanding requests for equal or previous 5872 instances of the LSA from the sending neighbor's Link State 5873 Request list (see Section 10). 5875 (c) If the sending neighbor is in state Exchange or in state 5876 Loading, then install the MaxAge LSA in the link state 5877 database. Otherwise, simply discard the LSA. In either 5878 case, examine the next LSA (if any) listed in the Link State 5879 Update packet. 5881 (5) Otherwise, find the instance of this LSA that is currently 5882 contained in the router's link state database. If there is no 5883 database copy, or the received LSA is more recent than the 5884 database copy (see Section 13.1 below for the determination of 5885 which LSA is more recent) the following steps must be performed: 5887 (a) If there is already a database copy, and if the database 5888 copy was installed less than MinLSArrival seconds ago, 5889 discard the new LSA (without acknowledging it) and examine 5890 the next LSA (if any) listed in the Link State Update 5891 packet. 5893 (b) Otherwise immediately flood the new LSA out some subset of 5894 the router's interfaces (see Section 13.3). In some cases 5895 (e.g., the state of the receiving interface is DR and the 5896 LSA was received from a router other than the Backup DR) the 5897 LSA will be flooded back out the receiving interface. This 5898 occurrence should be noted for later use by the 5899 acknowledgment process (Section 13.5). 5901 (c) Remove the current database copy from all neighbors' Link 5902 state retransmission lists. 5904 (d) Install the new LSA in the link state database (replacing 5905 the current database copy). This may cause the routing 5906 table calculation to be scheduled. In addition, timestamp 5907 the new LSA with the current time (i.e., the time it was 5908 received). The flooding procedure cannot overwrite the 5909 newly installed LSA until MinLSArrival seconds have elapsed. 5910 The LSA installation process is discussed further in Section 5911 13.2. 5913 (e) Possibly acknowledge the receipt of the LSA by sending a 5914 Link State Acknowledgment packet back out the receiving 5915 interface. This is explained below in Section 13.5. 5917 (f) If this new LSA indicates that it was originated by the 5918 receiving router itself (i.e., is considered a self- 5919 originated LSA), the router must take special action, either 5920 updating the LSA or in some cases flushing it from the 5921 routing domain. For a description of how self-originated 5922 LSAs are detected and subsequently handled, see Section 5923 13.4. 5925 (6) Else, if there is an instance of the LSA on the sending 5926 neighbor's Link state request list, an error has occurred in the 5927 Database Exchange process. In this case, restart the Database 5928 Exchange process by generating the neighbor event BadLSReq for 5929 the sending neighbor and stop processing the Link State Update 5930 packet. 5932 (7) Else, if the received LSA is the same instance as the database 5933 copy (i.e., neither one is more recent) the following two steps 5934 should be performed: 5936 (a) If the LSA is listed in the Link state retransmission list 5937 for the receiving adjacency, the router itself is expecting 5938 an acknowledgment for this LSA. The router should treat the 5939 received LSA as an acknowledgment by removing the LSA from 5940 the Link state retransmission list. This is termed an 5941 "implied acknowledgment". Its occurrence should be noted 5942 for later use by the acknowledgment process (Section 13.5). 5944 (b) Possibly acknowledge the receipt of the LSA by sending a 5945 Link State Acknowledgment packet back out the receiving 5946 interface. This is explained below in Section 13.5. 5948 (8) Else, the database copy is more recent. If the database copy 5949 has LS age equal to MaxAge and LS sequence number equal to 5950 MaxSequenceNumber, simply discard the received LSA without 5951 acknowledging it. (In this case, the LSA's LS sequence number is 5952 wrapping, and the MaxSequenceNumber LSA must be completely 5953 flushed before any new LSA instance can be introduced). 5954 Otherwise, send the database copy back to the sending neighbor, 5955 encapsulated within a Link State Update Packet. The Link State 5956 Update Packet should be unicast to the neighbor. In so doing, do 5957 not put the database copy of the LSA on the neighbor's link 5958 state retransmission list, and do not acknowledge the received 5959 (less recent) LSA instance. 5961 13.1. Determining which LSA is newer 5963 When a router encounters two instances of an LSA, it must 5964 determine which is more recent. This occurred above when 5965 comparing a received LSA to its database copy. This comparison 5966 must also be done during the Database Exchange procedure which 5967 occurs during adjacency bring-up. 5969 An LSA is identified by its LS type, Link State ID and 5970 Advertising Router. For two instances of the same LSA, the LS 5971 sequence number, LS age, and LS checksum fields are used to 5972 determine which instance is more recent: 5974 o The LSA having the newer LS sequence number is more recent. 5975 See Section 12.1.6 for an explanation of the LS sequence 5976 number space. If both instances have the same LS sequence 5977 number, then: 5979 o If the two instances have different LS checksums, then the 5980 instance having the larger LS checksum (when considered as a 5981 16-bit unsigned integer) is considered more recent. 5983 o Else, if only one of the instances has its LS age field set 5984 to MaxAge, the instance of age MaxAge is considered to be 5985 more recent. 5987 o Else, if the LS age fields of the two instances differ by 5988 more than MaxAgeDiff, the instance having the smaller 5989 (younger) LS age is considered to be more recent. 5991 o Else, the two instances are considered to be identical. 5993 13.2. Installing LSAs in the database 5995 Installing a new LSA in the database, either as the result of 5996 flooding or a newly self-originated LSA, may cause the OSPF 5997 routing table structure to be recalculated. The contents of the 5998 new LSA should be compared to the old instance, if present. If 5999 there is no difference, there is no need to recalculate the 6000 routing table. When comparing an LSA to its previous instance, 6001 the following are all considered to be differences in contents: 6003 o The LSA's Options field has changed. 6005 o One of the LSA instances has LS age set to MaxAge, and 6006 the other does not. 6008 o The length field in the LSA header has changed. 6010 o The body of the LSA (i.e., anything outside the 20-byte 6011 LSA header) has changed. Note that this excludes changes 6012 in LS Sequence Number and LS Checksum. 6014 If the contents are different, the following pieces of the 6015 routing table must be recalculated, depending on the new LSA's 6016 LS type field: 6018 Router-LSAs and network-LSAs 6019 The entire routing table must be recalculated, starting with 6020 the shortest path calculations for each area (not just the 6021 area whose link-state database has changed). The reason 6022 that the shortest path calculation cannot be restricted to 6023 the single changed area has to do with the fact that AS 6024 boundary routers may belong to multiple areas. A change in 6025 the area currently providing the best route may force the 6026 router to use an intra-area route provided by a different 6027 area.[19] 6029 Summary-LSAs 6030 The best route to the destination described by the summary- 6031 LSA must be recalculated (see Section 16.5). If this 6032 destination is an AS boundary router, it may also be 6033 necessary to re-examine all the AS-external-LSAs. 6035 AS-external-LSAs 6036 The best route to the destination described by the AS- 6037 external-LSA must be recalculated (see Section 16.6). 6039 Also, any old instance of the LSA must be removed from the 6040 database when the new LSA is installed. This old instance must 6041 also be removed from all neighbors' Link state retransmission 6042 lists (see Section 10). 6044 13.3. Next step in the flooding procedure 6046 When a new (and more recent) LSA has been received, it must be 6047 flooded out some set of the router's interfaces. This section 6048 describes the second part of flooding procedure (the first part 6049 being the processing that occurred in Section 13), namely, 6050 selecting the outgoing interfaces and adding the LSA to the 6051 appropriate neighbors' Link state retransmission lists. Also 6052 included in this part of the flooding procedure is the 6053 maintenance of the neighbors' Link state request lists. 6055 This section is equally applicable to the flooding of an LSA 6056 that the router itself has just originated (see Section 12.4). 6057 For these LSAs, this section provides the entirety of the 6058 flooding procedure (i.e., the processing of Section 13 is not 6059 performed, since, for example, the LSA has not been received 6060 from a neighbor and therefore does not need to be acknowledged). 6062 Depending upon the LSA's LS type, the LSA can be flooded out 6063 only certain interfaces. These interfaces, defined by the 6064 following, are called the eligible interfaces: 6066 AS-external-LSAs (LS Type = 5) 6067 AS-external-LSAs are flooded throughout the entire AS, with 6068 the exception of stub areas (see Section 3.6). The eligible 6069 interfaces are all the router's interfaces, excluding 6070 virtual links and those interfaces attaching to stub areas. 6072 All other LS types 6073 All other types are specific to a single area (Area A). The 6074 eligible interfaces are all those interfaces attaching to 6075 the Area A. If Area A is the backbone, this includes all 6076 the virtual links. 6078 Link state databases must remain synchronized over all 6079 adjacencies associated with the above eligible interfaces. This 6080 is accomplished by executing the following steps on each 6081 eligible interface. It should be noted that this procedure may 6082 decide not to flood an LSA out a particular interface, if there 6083 is a high probability that the attached neighbors have already 6084 received the LSA. However, in these cases the flooding 6085 procedure must be absolutely sure that the neighbors eventually 6086 do receive the LSA, so the LSA is still added to each 6087 adjacency's Link state retransmission list. For each eligible 6088 interface: 6090 (1) Each of the neighbors attached to this interface are 6091 examined, to determine whether they must receive the new 6092 LSA. The following steps are executed for each neighbor: 6094 (a) If the neighbor is in a lesser state than Exchange, it 6095 does not participate in flooding, and the next neighbor 6096 should be examined. 6098 (b) Else, if the adjacency is not yet full (neighbor state 6099 is Exchange or Loading), examine the Link state request 6100 list associated with this adjacency. If there is an 6101 instance of the new LSA on the list, it indicates that 6102 the neighboring router has an instance of the LSA 6103 already. Compare the new LSA to the neighbor's copy: 6105 o If the new LSA is less recent, then examine the next 6106 neighbor. 6108 o If the two copies are the same instance, then delete 6109 the LSA from the Link state request list, and 6110 examine the next neighbor.[20] 6112 o Else, the new LSA is more recent. Delete the LSA 6113 from the Link state request list. 6115 (c) If the new LSA was received from this neighbor, examine 6116 the next neighbor. 6118 (d) At this point we are not positive that the neighbor has 6119 an up-to-date instance of this new LSA. Add the new LSA 6120 to the Link state retransmission list for the adjacency. 6121 This ensures that the flooding procedure is reliable; 6122 the LSA will be retransmitted at intervals until an 6123 acknowledgment is seen from the neighbor. 6125 (2) The router must now decide whether to flood the new LSA out 6126 this interface. If in the previous step, the LSA was NOT 6127 added to any of the Link state retransmission lists, there 6128 is no need to flood the LSA out the interface and the next 6129 interface should be examined. 6131 (3) If the new LSA was received on this interface, and it was 6132 received from either the Designated Router or the Backup 6133 Designated Router, chances are that all the neighbors have 6134 received the LSA already. Therefore, examine the next 6135 interface. 6137 (4) If the new LSA was received on this interface, and the 6138 interface state is Backup (i.e., the router itself is the 6139 Backup Designated Router), examine the next interface. The 6140 Designated Router will do the flooding on this interface. 6141 However, if the Designated Router fails the router (i.e., 6142 the Backup Designated Router) will end up retransmitting the 6143 updates. 6145 (5) If this step is reached, the LSA must be flooded out the 6146 interface. Send a Link State Update packet (including the 6147 new LSA as contents) out the interface. The LSA's LS age 6148 must be incremented by InfTransDelay (which must be > 0) 6149 when it is copied into the outgoing Link State Update packet 6150 (until the LS age field reaches the maximum value of 6151 MaxAge). 6153 On broadcast networks, the Link State Update packets are 6154 multicast. The destination IP address specified for the 6155 Link State Update Packet depends on the state of the 6156 interface. If the interface state is DR or Backup, the 6157 address AllSPFRouters should be used. Otherwise, the 6158 address AllDRouters should be used. 6160 On non-broadcast networks, separate Link State Update 6161 packets must be sent, as unicasts, to each adjacent neighbor 6162 (i.e., those in state Exchange or greater). The destination 6163 IP addresses for these packets are the neighbors' IP 6164 addresses. 6166 13.4. Receiving self-originated LSAs 6168 It is a common occurrence for a router to receive self- 6169 originated LSAs via the flooding procedure. A self-originated 6170 LSA is detected when either 1) the LSA's Advertising Router is 6171 equal to the router's own Router ID or 2) the LSA is a network- 6172 LSA and its Link State ID is equal to one of the router's own IP 6173 interface addresses. 6175 However, if the received self-originated LSA is newer than the 6176 last instance that the router actually originated, the router 6177 must take special action. The reception of such an LSA 6178 indicates that there are LSAs in the routing domain that were 6179 originated by the router before the last time it was restarted. 6180 In most cases, the router must then advance the LSA's LS 6181 sequence number one past the received LS sequence number, and 6182 originate a new instance of the LSA. 6184 It may be the case the router no longer wishes to originate the 6185 received LSA. Possible examples include: 1) the LSA is a 6186 summary-LSA or AS-external-LSA and the router no longer has an 6187 (advertisable) route to the destination, 2) the LSA is a 6188 network-LSA but the router is no longer Designated Router for 6189 the network or 3) the LSA is a network-LSA whose Link State ID 6190 is one of the router's own IP interface addresses but whose 6191 Advertising Router is not equal to the router's own Router ID 6192 (this latter case should be rare, and it indicates that the 6193 router's Router ID has changed since originating the LSA). In 6194 all these cases, instead of updating the LSA, the LSA should be 6195 flushed from the routing domain by incrementing the received 6196 LSA's LS age to MaxAge and reflooding (see Section 14.1). 6198 13.5. Sending Link State Acknowledgment packets 6200 Each newly received LSA must be acknowledged. This is usually 6201 done by sending Link State Acknowledgment packets. However, 6202 acknowledgments can also be accomplished implicitly by sending 6203 Link State Update packets (see step 7a of Section 13). 6205 Many acknowledgments may be grouped together into a single Link 6206 State Acknowledgment packet. Such a packet is sent back out the 6207 interface which received the LSAs. The packet can be sent in 6208 one of two ways: delayed and sent on an interval timer, or sent 6209 directly (as a unicast) to a particular neighbor. The 6210 particular acknowledgment strategy used depends on the 6211 circumstances surrounding the receipt of the LSA. 6213 Sending delayed acknowledgments accomplishes several things: 1) 6214 it facilitates the packaging of multiple acknowledgments in a 6215 single Link State Acknowledgment packet, 2) it enables a single 6216 Link State Acknowledgment packet to indicate acknowledgments to 6217 several neighbors at once (through multicasting) and 3) it 6218 randomizes the Link State Acknowledgment packets sent by the 6219 various routers attached to a common network. The fixed 6220 interval between a router's delayed transmissions must be short 6221 (less than RxmtInterval) or needless retransmissions will ensue. 6223 Direct acknowledgments are sent to a particular neighbor in 6224 response to the receipt of duplicate LSAs. These 6225 acknowledgments are sent as unicasts, and are sent immediately 6226 when the duplicate is received. 6228 The precise procedure for sending Link State Acknowledgment 6229 packets is described in Table 19. The circumstances surrounding 6230 the receipt of the LSA are listed in the left column. The 6231 acknowledgment action then taken is listed in one of the two 6232 right columns. This action depends on the state of the 6233 concerned interface; interfaces in state Backup behave 6234 differently from interfaces in all other states. Delayed 6235 acknowledgments must be delivered to all adjacent routers 6236 associated with the interface. On broadcast networks, this is 6237 accomplished by sending the delayed Link State Acknowledgment 6238 packets as multicasts. The Destination IP address used depends 6239 Action taken in state 6240 Circumstances Backup All other states 6241 _______________________________________________________________ 6242 LSA has No acknowledgment No acknowledgment 6243 been flooded back sent. sent. 6244 out receiving in- 6245 terface (see Sec- 6246 tion 13, step 5b). 6247 _______________________________________________________________ 6248 LSA is Delayed acknowledg- Delayed ack- 6249 more recent than ment sent if adver- nowledgment sent. 6250 database copy, but tisement received 6251 was not flooded from Designated 6252 back out receiving Router, otherwise 6253 interface do nothing 6254 _______________________________________________________________ 6255 LSA is a Delayed acknowledg- No acknowledgment 6256 duplicate, and was ment sent if adver- sent. 6257 treated as an im- tisement received 6258 plied acknowledg- from Designated 6259 ment (see Section Router, otherwise 6260 13, step 7a). do nothing 6261 _______________________________________________________________ 6262 LSA is a Direct acknowledg- Direct acknowledg- 6263 duplicate, and was ment sent. ment sent. 6264 not treated as an 6265 implied ack- 6266 nowledgment. 6267 _______________________________________________________________ 6268 LSA's LS Direct acknowledg- Direct acknowledg- 6269 age is equal to ment sent. ment sent. 6270 MaxAge, and there is 6271 no current instance 6272 of the LSA 6273 in the link state 6274 database (see 6275 Section 13, step 4). 6277 Table 19: Sending link state acknowledgements. 6279 on the state of the interface. If the interface state is DR or 6280 Backup, the destination AllSPFRouters is used. In all other 6281 states, the destination AllDRouters is used. On non-broadcast 6282 networks, delayed Link State Acknowledgment packets must be 6283 unicast separately over each adjacency (i.e., neighbor whose 6284 state is >= Exchange). 6286 The reasoning behind sending the above packets as multicasts is 6287 best explained by an example. Consider the network 6288 configuration depicted in Figure 15. Suppose RT4 has been 6289 elected as Designated Router, and RT3 as Backup Designated 6290 Router for the network N3. When Router RT4 floods a new LSA to 6291 Network N3, it is received by routers RT1, RT2, and RT3. These 6292 routers will not flood the LSA back onto net N3, but they still 6293 must ensure that their link-state databases remain synchronized 6294 with their adjacent neighbors. So RT1, RT2, and RT4 are waiting 6295 to see an acknowledgment from RT3. Likewise, RT4 and RT3 are 6296 both waiting to see acknowledgments from RT1 and RT2. This is 6297 best achieved by sending the acknowledgments as multicasts. 6299 The reason that the acknowledgment logic for Backup DRs is 6300 slightly different is because they perform differently during 6301 the flooding of LSAs (see Section 13.3, step 4). 6303 13.6. Retransmitting LSAs 6305 LSAs flooded out an adjacency are placed on the adjacency's Link 6306 state retransmission list. In order to ensure that flooding is 6307 reliable, these LSAs are retransmitted until they are 6308 acknowledged. The length of time between retransmissions is a 6309 configurable per-interface value, RxmtInterval. If this is set 6310 too low for an interface, needless retransmissions will ensue. 6311 If the value is set too high, the speed of the flooding, in the 6312 face of lost packets, may be affected. 6314 Several retransmitted LSAs may fit into a single Link State 6315 Update packet. When LSAs are to be retransmitted, only the 6316 number fitting in a single Link State Update packet should be 6317 sent. Another packet of retransmissions can be sent whenever 6318 some of the LSAs are acknowledged, or on the next firing of the 6319 retransmission timer. 6321 Link State Update Packets carrying retransmissions are always 6322 sent as unicasts (directly to the physical address of the 6323 neighbor). They are never sent as multicasts. Each LSA's LS 6324 age must be incremented by InfTransDelay (which must be > 0) 6325 when it is copied into the outgoing Link State Update packet 6326 (until the LS age field reaches the maximum value of MaxAge). 6328 If an adjacent router goes down, retransmissions may occur until 6329 the adjacency is destroyed by OSPF's Hello Protocol. When the 6330 adjacency is destroyed, the Link state retransmission list is 6331 cleared. 6333 13.7. Receiving link state acknowledgments 6335 Many consistency checks have been made on a received Link State 6336 Acknowledgment packet before it is handed to the flooding 6337 procedure. In particular, it has been associated with a 6338 particular neighbor. If this neighbor is in a lesser state than 6339 Exchange, the Link State Acknowledgment packet is discarded. 6341 Otherwise, for each acknowledgment in the Link State 6342 Acknowledgment packet, the following steps are performed: 6344 o Does the LSA acknowledged have an instance on the Link state 6345 retransmission list for the neighbor? If not, examine the 6346 next acknowledgment. Otherwise: 6348 o If the acknowledgment is for the same instance that is 6349 contained on the list, remove the item from the list and 6350 examine the next acknowledgment. Otherwise: 6352 o Log the questionable acknowledgment, and examine the next 6353 one. 6355 14. Aging The Link State Database 6357 Each LSA has an LS age field. The LS age is expressed in seconds. 6358 An LSA's LS age field is incremented while it is contained in a 6359 router's database. Also, when copied into a Link State Update 6360 Packet for flooding out a particular interface, the LSA's LS age is 6361 incremented by InfTransDelay. 6363 An LSA's LS age is never incremented past the value MaxAge. LSAs 6364 having age MaxAge are not used in the routing table calculation. As 6365 a router ages its link state database, an LSA's LS age may reach 6366 MaxAge.[21] At this time, the router must attempt to flush the LSA 6367 from the routing domain. This is done simply by reflooding the 6368 MaxAge LSA just as if it was a newly originated LSA (see Section 6369 13.3). 6371 When creating a Database summary list for a newly forming adjacency, 6372 any MaxAge LSAs present in the link state database are added to the 6373 neighbor's Link state retransmission list instead of the neighbor's 6374 Database summary list. See Section 10.3 for more details. 6376 A MaxAge LSA must be removed immediately from the router's link 6377 state database as soon as both a) it is no longer contained on any 6378 neighbor Link state retransmission lists and b) none of the router's 6379 neighbors are in states Exchange or Loading. 6381 When, in the process of aging the link state database, an LSA's LS 6382 age hits a multiple of CheckAge, its LS checksum should be verified. 6383 If the LS checksum is incorrect, a program or memory error has been 6384 detected, and at the very least the router itself should be 6385 restarted. 6387 14.1. Premature aging of LSAs 6389 An LSA can be flushed from the routing domain by setting its LS 6390 age to MaxAge and reflooding the LSA. This procedure follows 6391 the same course as flushing an LSA whose LS age has naturally 6392 reached the value MaxAge (see Section 14). In particular, the 6393 MaxAge LSA is removed from the router's link state database as 6394 soon as a) it is no longer contained on any neighbor Link state 6395 retransmission lists and b) none of the router's neighbors are 6396 in states Exchange or Loading. We call the setting of an LSA's 6397 LS age to MaxAge "premature aging". 6399 Premature aging is used when it is time for a self-originated 6400 LSA's sequence number field to wrap. At this point, the current 6401 LSA instance (having LS sequence number MaxSequenceNumber) must 6402 be prematurely aged and flushed from the routing domain before a 6403 new instance with sequence number equal to InitialSequenceNumber 6404 can be originated. See Section 12.1.6 for more information. 6406 Premature aging can also be used when, for example, one of the 6407 router's previously advertised external routes is no longer 6408 reachable. In this circumstance, the router can flush its AS- 6409 external-LSA from the routing domain via premature aging. This 6410 procedure is preferable to the alternative, which is to 6411 originate a new LSA for the destination specifying a metric of 6412 LSInfinity. Premature aging is also be used when unexpectedly 6413 receiving self-originated LSAs during the flooding procedure 6414 (see Section 13.4). 6416 A router may only prematurely age its own self-originated LSAs. 6417 The router may not prematurely age LSAs that have been 6418 originated by other routers. An LSA is considered self- 6419 originated when either 1) the LSA's Advertising Router is equal 6420 to the router's own Router ID or 2) the LSA is a network-LSA and 6421 its Link State ID is equal to one of the router's own IP 6422 interface addresses. 6424 15. Virtual Links 6426 The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, 6427 or some areas of the Autonomous System will become unreachable. To 6428 establish/maintain connectivity of the backbone, virtual links can 6429 be configured through non-backbone areas. Virtual links serve to 6430 connect physically separate components of the backbone. The two 6431 endpoints of a virtual link are area border routers. The virtual 6432 link must be configured in both routers. The configuration 6433 information in each router consists of the other virtual endpoint 6434 (the other area border router), and the non-backbone area the two 6435 routers have in common (called the Transit area). Virtual links 6436 cannot be configured through stub areas (see Section 3.6). 6438 The virtual link is treated as if it were an unnumbered point-to- 6439 point network belonging to the backbone and joining the two area 6440 border routers. An attempt is made to establish an adjacency over 6441 the virtual link. When this adjacency is established, the virtual 6442 link will be included in backbone router-LSAs, and OSPF packets 6443 pertaining to the backbone area will flow over the adjacency. Such 6444 an adjacency has been referred to in this document as a "virtual 6445 adjacency". 6447 In each endpoint router, the cost and viability of the virtual link 6448 is discovered by examining the routing table entry for the other 6449 endpoint router. (The entry's associated area must be the 6450 configured Transit area). Actually, there may be a separate routing 6451 table entry for each Type of Service. These are called the virtual 6452 link's corresponding routing table entries. The InterfaceUp event 6453 occurs for a virtual link when its corresponding TOS 0 routing table 6454 entry becomes reachable. Conversely, the InterfaceDown event occurs 6455 when its TOS 0 routing table entry becomes unreachable.[22] In other 6456 words, the virtual link's viability is determined by the existence 6457 of an intra-area path, through the Transit area, between the two 6458 endpoints. Note that a virtual link whose underlying path has cost 6459 greater than hexadecimal 0xffff (the maximum size of an interface 6460 cost in a router-LSA) should be considered inoperational (i.e., 6461 treated the same as if the path did not exist). 6463 The other details concerning virtual links are as follows: 6465 o AS-external-LSAs are NEVER flooded over virtual adjacencies. 6466 This would be duplication of effort, since the same AS- 6467 external-LSAs are already flooded throughout the virtual link's 6468 Transit area. For this same reason, AS-external-LSAs are not 6469 summarized over virtual adjacencies during the Database Exchange 6470 process. 6472 o The cost of a virtual link is NOT configured. It is defined to 6473 be the cost of the intra-area path between the two defining area 6474 border routers. This cost appears in the virtual link's 6475 corresponding routing table entry. When the cost of a virtual 6476 link changes, a new router-LSA should be originated for the 6477 backbone area. 6479 o Just as the virtual link's cost and viability are determined by 6480 the routing table build process (through construction of the 6481 routing table entry for the other endpoint), so are the IP 6482 interface address for the virtual interface and the virtual 6483 neighbor's IP address. These are used when sending OSPF 6484 protocol packets over the virtual link. Note that when one (or 6485 both) of the virtual link endpoints connect to the Transit area 6486 via an unnumbered point-to-point link, it may be impossible to 6487 calculate either the virtual interface's IP address and/or the 6488 virtual neighbor's IP address, thereby causing the virtual link 6489 to fail. 6491 o In each endpoint's router-LSA for the backbone, the virtual link 6492 is represented as a Type 4 link whose Link ID is set to the 6493 virtual neighbor's OSPF Router ID and whose Link Data is set to 6494 the virtual interface's IP address. See Section 12.4.1 for more 6495 information. Note that it may be the case that there is a TOS 0 6496 path, but no non-zero TOS paths, between the two endpoint 6497 routers. In this case, both routers must revert to being non- 6498 TOS-capable, clearing the T-bit in the Options field of their 6499 backbone router-LSAs. 6501 o A non-backbone area can carry transit data traffic (i.e., is 6502 considered a "transit area") if and only if it serves as the 6503 Transit area for one or more fully adjacent virtual links (see 6504 TransitCapability in Sections 6 and 16.1). Such an area requires 6505 special treatment when summarizing backbone networks into it 6506 (see Section 12.4.3), and during the routing calculation (see 6507 Section 16.3). 6509 o The time between link state retransmissions, RxmtInterval, is 6510 configured for a virtual link. This should be well over the 6511 expected round-trip delay between the two routers. This may be 6512 hard to estimate for a virtual link; it is better to err on the 6513 side of making it too large. 6515 16. Calculation of the routing table 6517 This section details the OSPF routing table calculation. Using its 6518 attached areas' link state databases as input, a router runs the 6519 following algorithm, building its routing table step by step. At 6520 each step, the router must access individual pieces of the link 6521 state databases (e.g., a router-LSA originated by a certain router). 6522 This access is performed by the lookup function discussed in Section 6523 12.2. The lookup process may return an LSA whose LS age is equal to 6524 MaxAge. Such an LSA should not be used in the routing table 6525 calculation, and is treated just as if the lookup process had 6526 failed. 6528 The OSPF routing table's organization is explained in Section 11. 6529 Two examples of the routing table build process are presented in 6530 Sections 11.2 and 11.3. This process can be broken into the 6531 following steps: 6533 (1) The present routing table is invalidated. The routing table is 6534 built again from scratch. The old routing table is saved so 6535 that changes in routing table entries can be identified. 6537 (2) The intra-area routes are calculated by building the shortest- 6538 path tree for each attached area. In particular, all routing 6539 table entries whose Destination Type is "area border router" are 6540 calculated in this step. This step is described in two parts. 6541 At first the tree is constructed by only considering those links 6542 between routers and transit networks. Then the stub networks 6543 are incorporated into the tree. During the area's shortest-path 6544 tree calculation, the area's TransitCapability is also 6545 calculated for later use in Step 4. 6547 (3) The inter-area routes are calculated, through examination of 6548 summary-LSAs. If the router is attached to multiple areas 6549 (i.e., it is an area border router), only backbone summary-LSAs 6550 are examined. 6552 (4) In area border routers connecting to one or more transit areas 6553 (i.e, non-backbone areas whose TransitCapability is found to be 6554 TRUE), the transit areas' summary-LSAs are examined to see 6555 whether better paths exist using the transit areas than were 6556 found in Steps 2-3 above. 6558 (5) Routes to external destinations are calculated, through 6559 examination of AS-external-LSAs. The locations of the AS 6560 boundary routers (which originate the AS-external-LSAs) have 6561 been determined in steps 2-4. 6563 Steps 2-5 are explained in further detail below. The explanations 6564 describe the calculations for TOS 0 only. It may also be necessary 6565 to perform each step (separately) for each of the non-zero TOS 6566 values.[23] For more information concerning the building of non-zero 6567 TOS routes see Section 16.9. 6569 Changes made to routing table entries as a result of these 6570 calculations can cause the OSPF protocol to take further actions. 6571 For example, a change to an intra-area route will cause an area 6572 border router to originate new summary-LSAs (see Section 12.4). See 6573 Section 16.7 for a complete list of the OSPF protocol actions 6574 resulting from routing table changes. 6576 16.1. Calculating the shortest-path tree for an area 6578 This calculation yields the set of intra-area routes associated 6579 with an area (called hereafter Area A). A router calculates the 6580 shortest-path tree using itself as the root.[24] The formation 6581 of the shortest path tree is done here in two stages. In the 6582 first stage, only links between routers and transit networks are 6583 considered. Using the Dijkstra algorithm, a tree is formed from 6584 this subset of the link state database. In the second stage, 6585 leaves are added to the tree by considering the links to stub 6586 networks. 6588 The procedure will be explained using the graph terminology that 6589 was introduced in Section 2. The area's link state database is 6590 represented as a directed graph. The graph's vertices are 6591 routers, transit networks and stub networks. The first stage of 6592 the procedure concerns only the transit vertices (routers and 6593 transit networks) and their connecting links. Throughout the 6594 shortest path calculation, the following data is also associated 6595 with each transit vertex: 6597 Vertex (node) ID 6598 A 32-bit number uniquely identifying the vertex. For router 6599 vertices this is the router's OSPF Router ID. For network 6600 vertices, this is the IP address of the network's Designated 6601 Router. 6603 An LSA 6604 Each transit vertex has an associated LSA. For router 6605 vertices, this is a router-LSA. For transit networks, this 6606 is a network-LSA (which is actually originated by the 6607 network's Designated Router). In any case, the LSA's Link 6608 State ID is always equal to the above Vertex ID. 6610 List of next hops 6611 The list of next hops for the current set of shortest paths 6612 from the root to this vertex. There can be multiple 6613 shortest paths due to the equal-cost multipath capability. 6614 Each next hop indicates the outgoing router interface to use 6615 when forwarding traffic to the destination. On broadcast, 6616 Point-to-MultiPoint and NBMA networks, the next hop also 6617 includes the IP address of the next router (if any) in the 6618 path towards the destination. 6620 Distance from root 6621 The link state cost of the current set of shortest paths 6622 from the root to the vertex. The link state cost of a path 6623 is calculated as the sum of the costs of the path's 6624 constituent links (as advertised in router-LSAs and 6625 network-LSAs). One path is said to be "shorter" than 6626 another if it has a smaller link state cost. 6628 The first stage of the procedure (i.e., the Dijkstra algorithm) 6629 can now be summarized as follows. At each iteration of the 6630 algorithm, there is a list of candidate vertices. Paths from 6631 the root to these vertices have been found, but not necessarily 6632 the shortest ones. However, the paths to the candidate vertex 6633 that is closest to the root are guaranteed to be shortest; this 6634 vertex is added to the shortest-path tree, removed from the 6635 candidate list, and its adjacent vertices are examined for 6636 possible addition to/modification of the candidate list. The 6637 algorithm then iterates again. It terminates when the candidate 6638 list becomes empty. 6640 The following steps describe the algorithm in detail. Remember 6641 that we are computing the shortest path tree for Area A. All 6642 references to link state database lookup below are from Area A's 6643 database. 6645 (1) Initialize the algorithm's data structures. Clear the list 6646 of candidate vertices. Initialize the shortest-path tree to 6647 only the root (which is the router doing the calculation). 6648 Set Area A's TransitCapability to FALSE. 6650 (2) Call the vertex just added to the tree vertex V. Examine 6651 the LSA associated with vertex V. This is a lookup in the 6652 Area A's link state database based on the Vertex ID. If 6653 this is a router-LSA, and bit V of the router-LSA (see 6654 Section A.4.2) is set, set Area A's TransitCapability to 6655 TRUE. In any case, each link described by the LSA gives the 6656 cost to an adjacent vertex. For each described link, (say 6657 it joins vertex V to vertex W): 6659 (a) If this is a link to a stub network, examine the next 6660 link in V's LSA. Links to stub networks will be 6661 considered in the second stage of the shortest path 6662 calculation. 6664 (b) Otherwise, W is a transit vertex (router or transit 6665 network). Look up the vertex W's LSA (router-LSA or 6666 network-LSA) in Area A's link state database. If the 6667 LSA does not exist, or its LS age is equal to MaxAge, or 6668 it does not have a link back to vertex V, examine the 6669 next link in V's LSA.[25] 6671 (c) If vertex W is already on the shortest-path tree, 6672 examine the next link in the LSA. 6674 (d) Calculate the link state cost D of the resulting path 6675 from the root to vertex W. D is equal to the sum of the 6676 link state cost of the (already calculated) shortest 6677 path to vertex V and the advertised cost of the link 6678 between vertices V and W. If D is: 6680 o Greater than the value that already appears for 6681 vertex W on the candidate list, then examine the 6682 next link. 6684 o Equal to the value that appears for vertex W on the 6685 candidate list, calculate the set of next hops that 6686 result from using the advertised link. Input to 6687 this calculation is the destination (W), and its 6688 parent (V). This calculation is shown in Section 6689 16.1.1. This set of hops should be added to the 6690 next hop values that appear for W on the candidate 6691 list. 6693 o Less than the value that appears for vertex W on the 6694 candidate list, or if W does not yet appear on the 6695 candidate list, then set the entry for W on the 6696 candidate list to indicate a distance of D from the 6697 root. Also calculate the list of next hops that 6698 result from using the advertised link, setting the 6699 next hop values for W accordingly. The next hop 6700 calculation is described in Section 16.1.1; it takes 6701 as input the destination (W) and its parent (V). 6703 (3) If at this step the candidate list is empty, the shortest- 6704 path tree (of transit vertices) has been completely built 6705 and this stage of the procedure terminates. Otherwise, 6706 choose the vertex belonging to the candidate list that is 6707 closest to the root, and add it to the shortest-path tree 6708 (removing it from the candidate list in the process). Note 6709 that when there is a choice of vertices closest to the root, 6710 network vertices must be chosen before router vertices in 6711 order to necessarily find all equal-cost paths. This is 6712 consistent with the tie-breakers that were introduced in the 6713 modified Dijkstra algorithm used by OSPF's Multicast routing 6714 extensions (MOSPF). 6716 (4) Possibly modify the routing table. For those routing table 6717 entries modified, the associated area will be set to Area A, 6718 the path type will be set to intra-area, and the cost will 6719 be set to the newly discovered shortest path's calculated 6720 distance. 6722 If the newly added vertex is an area border router or AS 6723 boundary router, a routing table entry is added whose 6724 destination type is "router". The Options field found in 6725 the associated router-LSA is copied into the routing table 6726 entry's Optional capabilities field. Call the newly added 6727 vertex Router X. If Router X is the endpoint of one of the 6728 calculating router's virtual links, and the virtual link 6729 uses Area A as Transit area: the virtual link is declared 6730 up, the IP address of the virtual interface is set to the IP 6731 address of the outgoing interface calculated above for 6732 Router X, and the virtual neighbor's IP address is set to 6733 Router X's interface address (contained in Router X's 6734 router-LSA) that points back to the root of the shortest- 6735 path tree; equivalently, this is the interface that points 6736 back to Router X's parent vertex on the shortest-path tree 6737 (similar to the calculation in Section 16.1.1). 6739 If the newly added vertex is a transit network, the routing 6740 table entry for the network is located. The entry's 6741 Destination ID is the IP network number, which can be 6742 obtained by masking the Vertex ID (Link State ID) with its 6743 associated subnet mask (found in the body of the associated 6744 network-LSA). If the routing table entry already exists 6745 (i.e., there is already an intra-area route to the 6746 destination installed in the routing table), multiple 6747 vertices have mapped to the same IP network. For example, 6748 this can occur when a new Designated Router is being 6749 established. In this case, the current routing table entry 6750 should be overwritten if and only if the newly found path is 6751 just as short and the current routing table entry's Link 6752 State Origin has a smaller Link State ID than the newly 6753 added vertex' LSA. 6755 If there is no routing table entry for the network (the 6756 usual case), a routing table entry for the IP network should 6757 be added. The routing table entry's Link State Origin 6758 should be set to the newly added vertex' LSA. 6760 (5) Iterate the algorithm by returning to Step 2. 6762 The stub networks are added to the tree in the procedure's 6763 second stage. In this stage, all router vertices are again 6764 examined. Those that have been determined to be unreachable in 6765 the above first phase are discarded. For each reachable router 6766 vertex (call it V), the associated router-LSA is found in the 6767 link state database. Each stub network link appearing in the 6768 LSA is then examined, and the following steps are executed: 6770 (1) Calculate the distance D of stub network from the root. D 6771 is equal to the distance from the root to the router vertex 6772 (calculated in stage 1), plus the stub network link's 6773 advertised cost. Compare this distance to the current best 6774 cost to the stub network. This is done by looking up the 6775 stub network's current routing table entry. If the 6776 calculated distance D is larger, go on to examine the next 6777 stub network link in the LSA. 6779 (2) If this step is reached, the stub network's routing table 6780 entry must be updated. Calculate the set of next hops that 6781 would result from using the stub network link. This 6782 calculation is shown in Section 16.1.1; input to this 6783 calculation is the destination (the stub network) and the 6784 parent vertex (the router vertex). If the distance D is the 6785 same as the current routing table cost, simply add this set 6786 of next hops to the routing table entry's list of next hops. 6787 In this case, the routing table already has a Link State 6788 Origin. If this Link State Origin is a router-LSA whose 6789 Link State ID is smaller than V's Router ID, reset the Link 6790 State Origin to V's router-LSA. 6792 Otherwise D is smaller than the routing table cost. 6793 Overwrite the current routing table entry by setting the 6794 routing table entry's cost to D, and by setting the entry's 6795 list of next hops to the newly calculated set. Set the 6796 routing table entry's Link State Origin to V's router-LSA. 6797 Then go on to examine the next stub network link. 6799 For all routing table entries added/modified in the second 6800 stage, the associated area will be set to Area A and the path 6801 type will be set to intra-area. When the list of reachable 6802 router-LSAs is exhausted, the second stage is completed. At 6803 this time, all intra-area routes associated with Area A have 6804 been determined. 6806 The specification does not require that the above two stage 6807 method be used to calculate the shortest path tree. However, if 6808 another algorithm is used, an identical tree must be produced. 6809 For this reason, it is important to note that links between 6810 transit vertices must be bidirectional in order to be included 6811 in the above tree. It should also be mentioned that more 6812 efficient algorithms exist for calculating the tree; for 6813 example, the incremental SPF algorithm described in [Ref1]. 6815 16.1.1. The next hop calculation 6817 This section explains how to calculate the current set of 6818 next hops to use for a destination. Each next hop consists 6819 of the outgoing interface to use in forwarding packets to 6820 the destination together with the IP address of the next hop 6821 router (if any). The next hop calculation is invoked each 6822 time a shorter path to the destination is discovered. This 6823 can happen in either stage of the shortest-path tree 6824 calculation (see Section 16.1). In stage 1 of the 6825 shortest-path tree calculation a shorter path is found as 6826 the destination is added to the candidate list, or when the 6827 destination's entry on the candidate list is modified (Step 6828 2d of Stage 1). In stage 2 a shorter path is discovered 6829 each time the destination's routing table entry is modified 6830 (Step 2 of Stage 2). 6832 The set of next hops to use for the destination may be 6833 recalculated several times during the shortest-path tree 6834 calculation, as shorter and shorter paths are discovered. 6835 In the end, the destination's routing table entry will 6836 always reflect the next hops resulting from the absolute 6837 shortest path(s). 6839 Input to the next hop calculation is a) the destination and 6840 b) its parent in the current shortest path between the root 6841 (the calculating router) and the destination. The parent is 6842 always a transit vertex (i.e., always a router or a transit 6843 network). 6845 If there is at least one intervening router in the current 6846 shortest path between the destination and the root, the 6847 destination simply inherits the set of next hops from the 6848 parent. Otherwise, there are two cases. In the first case, 6849 the parent vertex is the root (the calculating router 6850 itself). This means that the destination is either a 6851 directly connected network or directly connected router. 6852 The outgoing interface in this case is simply the OSPF 6853 interface connecting to the destination network/router. If 6854 the destination is a router which connects to the 6855 calculating router via a Point-to-MultiPoint network, the 6856 destination's next hop IP address(es) can be determined by 6857 examining the destination's router-LSA: each link pointing 6858 back to the calculating router and having a Link Data field 6859 belonging to the Point-to-MultiPoint network provides an IP 6860 address of the next hop router. If the destination is a 6861 directly connected network, or a router which connects to 6862 the calculating router via a point-to-point interface, no 6863 next hop IP address is required. If the destination is a 6864 router connected to the calculating router via a virtual 6865 link, the setting of the next hop should be deferred until 6866 the calculation in Section 16.3. 6868 In the second case, the parent vertex is a network that 6869 directly connects the calculating router to the destination 6870 router. The list of next hops is then determined by 6871 examining the destination's router-LSA. For each link in 6872 the router-LSA that points back to the parent network, the 6873 link's Link Data field provides the IP address of a next hop 6874 router. The outgoing interface to use can then be derived 6875 from the next hop IP address (or it can be inherited from 6876 the parent network). 6878 16.2. Calculating the inter-area routes 6880 The inter-area routes are calculated by examining summary-LSAs. 6881 If the router has active attachments to multiple areas, only 6882 backbone summary-LSAs are examined. Routers attached to a 6883 single area examine that area's summary-LSAs. In either case, 6884 the summary-LSAs examined below are all part of a single area's 6885 link state database (call it Area A). 6887 Summary-LSAs are originated by the area border routers. Each 6888 summary-LSA in Area A is considered in turn. Remember that the 6889 destination described by a summary-LSA is either a network (Type 6890 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). 6891 For each summary-LSA: 6893 (1) If the cost specified by the LSA is LSInfinity, or if the 6894 LSA's LS age is equal to MaxAge, then examine the the next 6895 LSA. 6897 (2) If the LSA was originated by the calculating router itself, 6898 examine the next LSA. 6900 (3) If it is a Type 3 summary-LSA, and the collection of 6901 destinations described by the summary-LSA equals one of the 6902 router's configured area address ranges (see Section 3.5), 6903 and the particular area address range is active, then the 6904 summary-LSA should be ignored. "Active" means that there 6905 are one or more reachable (by intra-area paths) networks 6906 contained in the area range. 6908 (4) Else, call the destination described by the LSA N (for Type 6909 3 summary-LSAs, N's address is obtained by masking the LSA's 6910 Link State ID with the network/subnet mask contained in the 6911 body of the LSA), and the area border originating the LSA 6912 BR. Look up the routing table entry for BR having Area A as 6913 its associated area. If no such entry exists for router BR 6914 (i.e., BR is unreachable in Area A), do nothing with this 6915 LSA and consider the next in the list. Else, this LSA 6916 describes an inter-area path to destination N, whose cost is 6917 the distance to BR plus the cost specified in the LSA. Call 6918 the cost of this inter-area path IAC. 6920 (5) Next, look up the routing table entry for the destination N. 6921 (If N is an AS boundary router, look up the "router" routing 6922 table entry associated with Area A). If no entry exists for 6923 N or if the entry's path type is "type 1 external" or "type 6924 2 external", then install the inter-area path to N, with 6925 associated area Area A, cost IAC, next hop equal to the list 6926 of next hops to router BR, and Advertising router equal to 6927 BR. 6929 (6) Else, if the paths present in the table are intra-area 6930 paths, do nothing with the LSA (intra-area paths are always 6931 preferred). 6933 (7) Else, the paths present in the routing table are also 6934 inter-area paths. Install the new path through BR if it is 6935 cheaper, overriding the paths in the routing table. 6936 Otherwise, if the new path is the same cost, add it to the 6937 list of paths that appear in the routing table entry. 6939 16.3. Examining transit areas' summary-LSAs 6941 This step is only performed by area border routers attached to 6942 one or more non-backbone areas that are capable of carrying 6943 transit traffic (i.e., "transit areas", or those areas whose 6944 TransitCapability parameter has been set to TRUE in Step 2 of 6945 the Dijkstra algorithm (see Section 16.1). 6947 The purpose of the calculation below is to examine the transit 6948 areas to see whether they provide any better (shorter) paths 6949 than the paths previously calculated in Sections 16.1 and 16.2. 6950 Any paths found that are better than or equal to previously 6951 discovered paths are installed in the routing table. 6953 The calculation proceeds as follows. All the transit areas' 6954 summary-LSAs are examined in turn. Each such summary-LSA 6955 describes a route through a transit area Area A to a Network N 6956 (N's address is obtained by masking the LSA's Link State ID with 6957 the network/subnet mask contained in the body of the LSA) or in 6958 the case of a Type 4 summary-LSA, to an AS boundary router N. 6959 Suppose also that the summary-LSA was originated by an area 6960 border router BR. 6962 (1) If the cost advertised by the summary-LSA is LSInfinity, or 6963 if the LSA's LS age is equal to MaxAge, then examine the 6964 next LSA. 6966 (2) If the summary-LSA was originated by the calculating router 6967 itself, examine the next LSA. 6969 (3) Look up the routing table entry for N. (If N is an AS 6970 boundary router, look up the "router" routing table entry 6971 associated with the backbone area). If it does not exist, or 6972 if the route type is other than intra-area or inter-area, or 6973 if the area associated with the routing table entry is not 6974 the backbone area, then examine the next LSA. In other 6975 words, this calculation only updates backbone intra-area 6976 routes found in Section 16.1 and inter-area routes found in 6977 Section 16.2. 6979 (4) Look up the routing table entry for the advertising router 6980 BR associated with the Area A. If it is unreachable, examine 6981 the next LSA. Otherwise, the cost to destination N is the 6982 sum of the cost in BR's Area A routing table entry and the 6983 cost advertised in the LSA. Call this cost IAC. 6985 (5) If this cost is less than the cost occurring in N's routing 6986 table entry, overwrite N's list of next hops with those used 6987 for BR, and set N's routing table cost to IAC. Else, if IAC 6988 is the same as N's current cost, add BR's list of next hops 6989 to N's list of next hops. In any case, the area associated 6990 with N's routing table entry must remain the backbone area, 6991 and the path type (either intra-area or inter-area) must 6992 also remain the same. 6994 It is important to note that the above calculation never makes 6995 unreachable destinations reachable, but instead just potentially 6996 finds better paths to already reachable destinations. The 6997 calculation installs any better cost found into the routing 6998 table entry, from which it may be readvertised in summary-LSAs 6999 to other areas. 7001 As an example of the calculation, consider the Autonomous System 7002 pictured in Figure 17. There is a single non-backbone area 7004 ........................ 7005 . Area 1 (transit) . + 7006 . . | 7007 . +---+1 1+---+100 | 7008 . |RT2|----------|RT4|=========| 7009 . 1/+---+********* +---+ | 7010 . /******* . | 7011 . 1/*Virtual . | 7012 1+---+/* Link . Net|work 7013 =======|RT1|* . | N1 7014 +---+\ . | 7015 . \ . | 7016 . \ . | 7017 . 1\+---+1 1+---+20 | 7018 . |RT3|----------|RT5|=========| 7019 . +---+ +---+ | 7020 . . | 7021 ........................ + 7023 Figure 17: Routing through transit areas 7024 (Area 1) that physically divides the backbone into two separate 7025 pieces. To maintain connectivity of the backbone, a virtual link 7026 has been configured between routers RT1 and RT4. On the right 7027 side of the figure, Network N1 belongs to the backbone. The 7028 dotted lines indicate that there is a much shorter intra-area 7029 backbone path between router RT5 and Network N1 (cost 20) than 7030 there is between Router RT4 and Network N1 (cost 100). Both 7031 Router RT4 and Router RT5 will inject summary-LSAs for Network 7032 N1 into Area 1. 7034 After the shortest-path tree has been calculated for the 7035 backbone in Section 16.1, Router RT1 (left end of the virtual 7036 link) will have calculated a path through Router RT4 for all 7037 data traffic destined for Network N1. However, since Router RT5 7038 is so much closer to Network N1, all routers internal to Area 1 7039 (e.g., Routers RT2 and RT3) will forward their Network N1 7040 traffic towards Router RT5, instead of RT4. And indeed, after 7041 examining Area 1's summary-LSAs by the above calculation, Router 7042 RT1 will also forward Network N1 traffic towards RT5. Note that 7043 in this example the virtual link enables transit data traffic to 7044 be forwarded through Area 1, but the actual path the transit 7045 data traffic takes does not follow the virtual link. In other 7046 words, virtual links allow transit traffic to be forwarded 7047 through an area, but do not dictate the precise path that the 7048 traffic will take. 7050 16.4. Calculating AS external routes 7052 AS external routes are calculated by examining AS-external-LSAs. 7053 Each of the AS-external-LSAs is considered in turn. Most AS- 7054 external-LSAs describe routes to specific IP destinations. An 7055 AS-external-LSA can also describe a default route for the 7056 Autonomous System (Destination ID = DefaultDestination, 7057 network/subnet mask = 0x00000000). For each AS-external-LSA: 7059 (1) If the cost specified by the LSA is LSInfinity, or if the 7060 LSA's LS age is equal to MaxAge, then examine the next LSA. 7062 (2) If the LSA was originated by the calculating router itself, 7063 examine the next LSA. 7065 (3) Call the destination described by the LSA N. N's address is 7066 obtained by masking the LSA's Link State ID with the 7067 network/subnet mask contained in the body of the LSA. Look 7068 up the routing table entries (potentially one per attached 7069 area) for the AS boundary router (ASBR) that originated the 7070 LSA. If no entries exist for router ASBR (i.e., ASBR is 7071 unreachable), do nothing with this LSA and consider the next 7072 in the list. 7074 Else, this LSA describes an AS external path to destination 7075 N. Examine the forwarding address specified in the AS- 7076 external-LSA. This indicates the IP address to which 7077 packets for the destination should be forwarded. 7079 If the forwarding address is set to 0.0.0.0, packets should 7080 be sent to the ASBR itself. Among the multiple routing table 7081 entries for the ASBR, select the preferred entry as follows. 7082 If RFC1583Compatibility is set to "disabled", prune the set 7083 of routing table entries for the ASBR as described in 7084 Section 16.4.1. In any case, among the remaining routing 7085 table entries, select the routing table entry with the least 7086 cost; when there are multiple least cost routing table 7087 entries the entry whose associated area has the largest OSPF 7088 Area ID (when considered as an unsigned 32-bit integer) is 7089 chosen. 7091 If the forwarding address is non-zero, look up the 7092 forwarding address in the routing table.[26] The matching 7093 routing table entry must specify an intra-area or inter-area 7094 path; if no such path exists, do nothing with the LSA and 7095 consider the next in the list. 7097 (4) Let X be the cost specified by the preferred routing table 7098 entry for the ASBR/forwarding address, and Y the cost 7099 specified in the LSA. X is in terms of the link state 7100 metric, and Y is a type 1 or 2 external metric. 7102 (5) Look up the routing table entry for the destination N. If 7103 no entry exists for N, install the AS external path to N, 7104 with next hop equal to the list of next hops to the 7105 forwarding address, and advertising router equal to ASBR. 7106 If the external metric type is 1, then the path-type is set 7107 to type 1 external and the cost is equal to X+Y. If the 7108 external metric type is 2, the path-type is set to type 2 7109 external, the link state component of the route's cost is X, 7110 and the type 2 cost is Y. 7112 (6) Compare the AS external path described by the LSA with the 7113 existing paths in N's routing table entry, as follows. If 7114 the new path is preferred, it replaces the present paths in 7115 N's routing table entry. If the new path is of equal 7116 preference, it is added to N's routing table entry's list of 7117 paths. 7119 (a) Intra-area and inter-area paths are always preferred 7120 over AS external paths. 7122 (b) Type 1 external paths are always preferred over type 2 7123 external paths. When all paths are type 2 external 7124 paths, the paths with the smallest advertised type 2 7125 metric are always preferred. 7127 (c) If the new AS external path is still indistinguishable 7128 from the current paths in the N's routing table entry, 7129 and RFC1583Compatibility is set to "disabled", select 7130 the preferred paths based on the intra-AS paths to the 7131 ASBR/forwarding addresses, as specified in Section 7132 16.4.1. 7134 (d) If the new AS external path is still indistinguishable 7135 from the current paths in the N's routing table entry, 7136 select the preferred path based on a least cost 7137 comparison. Type 1 external paths are compared by 7138 looking at the sum of the distance to the forwarding 7139 address and the advertised type 1 metric (X+Y). Type 2 7140 external paths advertising equal type 2 metrics are 7141 compared by looking at the distance to the forwarding 7142 addresses. 7144 16.4.1. External path preferences 7146 When multiple intra-AS paths are available to 7147 ASBRs/forwarding addresses, the following rules indicate 7148 which paths are preferred. These rules apply when the same 7149 ASBR is reachable through multiple areas, or when trying to 7150 decide which of several AS-external-LSAs should be 7151 preferred. In the former case the paths all terminate at the 7152 same ASBR, while in the latter the paths terminate at 7153 separate ASBRs/forwarding addresses. In either case, each 7154 path is represented by a separate routing table entry as 7155 defined in Section 11. 7157 This section only applies when RFC1583Compatibility is set 7158 to "disabled". 7160 The path preference rules, stated from highest to lowest 7161 preference, are as follows. Note that as a result of these 7162 rules, there may still be multiple paths of the highest 7163 preference. In this case, the path to use must be determined 7164 based on cost, as described in Section 16.4. 7166 o Intra-area paths using non-backbone areas are always the 7167 most preferred. 7169 o Otherwise, intra-area backbone paths are preferred. 7171 o Inter-area paths are the least preferred. 7173 16.5. Incremental updates -- summary-LSAs 7175 When a new summary-LSA is received, it is not necessary to 7176 recalculate the entire routing table. Call the destination 7177 described by the summary-LSA N (N's address is obtained by 7178 masking the LSA's Link State ID with the network/subnet mask 7179 contained in the body of the LSA), and let Area A be the area to 7180 which the LSA belongs. There are then two separate cases: 7182 Case 1: Area A is the backbone and/or the router is not an area 7183 border router. 7184 In this case, the following calculations must be performed. 7185 First, if there is presently an inter-area route to the 7186 destination N, N's routing table entry is invalidated, 7187 saving the entry's values for later comparisons. Then the 7188 calculation in Section 16.2 is run again for the single 7189 destination N. In this calculation, all of Area A's 7190 summary-LSAs that describe a route to N are examined. In 7191 addition, if the router is an area border router attached to 7192 one or more transit areas, the calculation in Section 16.3 7193 must be run again for the single destination. If the 7194 results of these calculations have changed the cost/path to 7195 an AS boundary router (as would be the case for a Type 4 7196 summary-LSA) or to any forwarding addresses, all AS- 7197 external-LSAs will have to be reexamined by rerunning the 7198 calculation in Section 16.4. Otherwise, if N is now newly 7199 unreachable, the calculation in Section 16.4 must be rerun 7200 for the single destination N, in case an alternate external 7201 route to N exists. 7203 Case 2: Area A is a transit area and the router is an area 7204 border router. 7205 In this case, the following calculations must be performed. 7206 First, if N's routing table entry presently contains one or 7207 more inter-area paths that utilize the transit area Area A, 7208 these paths should be removed. If this removes all paths 7209 from the routing table entry, the entry should be 7210 invalidated. The entry's old values should be saved for 7211 later comparisons. Next the calculation in Section 16.3 must 7212 be run again for the single destination N. If the results of 7213 this calculation have caused the cost to N to increase, the 7214 complete routing table calculation must be rerun starting 7215 with the Dijkstra algorithm specified in Section 16.1. 7216 Otherwise, if the cost/path to an AS boundary router (as 7217 would be the case for a Type 4 summary-LSA) or to any 7218 forwarding addresses has changed, all AS-external-LSAs will 7219 have to be reexamined by rerunning the calculation in 7220 Section 16.4. Otherwise, if N is now newly unreachable, the 7221 calculation in Section 16.4 must be rerun for the single 7222 destination N, in case an alternate external route to N 7223 exists. 7225 16.6. Incremental updates -- AS-external-LSAs 7227 When a new AS-external-LSA is received, it is not necessary to 7228 recalculate the entire routing table. Call the destination 7229 described by the AS-external-LSA N. N's address is obtained by 7230 masking the LSA's Link State ID with the network/subnet mask 7231 contained in the body of the LSA. If there is already an intra- 7232 area or inter-area route to the destination, no recalculation is 7233 necessary (internal routes take precedence). 7235 Otherwise, the procedure in Section 16.4 will have to be 7236 performed, but only for those AS-external-LSAs whose destination 7237 is N. Before this procedure is performed, the present routing 7238 table entry for N should be invalidated. 7240 16.7. Events generated as a result of routing table changes 7242 Changes to routing table entries sometimes cause the OSPF area 7243 border routers to take additional actions. These routers need 7244 to act on the following routing table changes: 7246 o The cost or path type of a routing table entry has changed. 7247 If the destination described by this entry is a Network or 7248 AS boundary router, and this is not simply a change of AS 7249 external routes, new summary-LSAs may have to be generated 7250 (potentially one for each attached area, including the 7251 backbone). See Section 12.4.3 for more information. If a 7252 previously advertised entry has been deleted, or is no 7253 longer advertisable to a particular area, the LSA must be 7254 flushed from the routing domain by setting its LS age to 7255 MaxAge and reflooding (see Section 14.1). 7257 o A routing table entry associated with a configured virtual 7258 link has changed. The destination of such a routing table 7259 entry is an area border router. The change indicates a 7260 modification to the virtual link's cost or viability. 7262 If the entry indicates that the area border router is newly 7263 reachable (via TOS 0), the corresponding virtual link is now 7264 operational. An InterfaceUp event should be generated for 7265 the virtual link, which will cause a virtual adjacency to 7266 begin to form (see Section 10.3). At this time the virtual 7267 link's IP interface address and the virtual neighbor's 7268 Neighbor IP address are also calculated. 7270 If the entry indicates that the area border router is no 7271 longer reachable (via TOS 0), the virtual link and its 7272 associated adjacency should be destroyed. This means an 7273 InterfaceDown event should be generated for the associated 7274 virtual link. 7276 If the cost of the entry has changed, and there is a fully 7277 established virtual adjacency, a new router-LSA for the 7278 backbone must be originated. This in turn may cause further 7279 routing table changes. 7281 16.8. Equal-cost multipath 7283 The OSPF protocol maintains multiple equal-cost routes to all 7284 destinations. This can be seen in the steps used above to 7285 calculate the routing table, and in the definition of the 7286 routing table structure. 7288 Each one of the multiple routes will be of the same type 7289 (intra-area, inter-area, type 1 external or type 2 external), 7290 cost, and will have the same associated area. However, each 7291 route specifies a separate next hop and Advertising router. 7293 There is no requirement that a router running OSPF keep track of 7294 all possible equal-cost routes to a destination. An 7295 implementation may choose to keep only a fixed number of routes 7296 to any given destination. This does not affect any of the 7297 algorithms presented in this specification. 7299 16.9. Building the non-zero-TOS portion of the routing table 7301 The OSPF protocol can calculate a different set of routes for 7302 each IP TOS (see Section 2.5). Support for TOS-based routing is 7303 optional. TOS-capable and non-TOS-capable routers can be mixed 7304 in an OSPF routing domain. Routers not supporting TOS calculate 7305 only the TOS 0 route to each destination. These routes are then 7306 used to forward all data traffic, regardless of the TOS 7307 indications in the data packet's IP header. A router that does 7308 not support TOS indicates this fact to the other OSPF routers by 7309 clearing the T-bit in the Options field of its router-LSA. 7311 The above sections detailing the routing table calculations 7312 handle the TOS 0 case only. In general, for routers supporting 7313 TOS-based routing, each piece of the routing table calculation 7314 must be rerun separately for the non-zero TOS values. When 7315 calculating routes for TOS X, only TOS X metrics can be used. 7316 Any LSA may specify a separate cost for each TOS (a cost for TOS 7317 0 must always be specified). The encoding of TOS in OSPF LSAs 7318 is described in Section 12.3. 7320 An LSA can specify that it is restricted to TOS 0 (i.e., non- 7321 zero TOS is not handled) by clearing the T-bit in the LSA's 7322 Option field. Such LSAs are not used when calculating routes 7323 for non-zero TOS. For this reason, it is possible that a 7324 destination is unreachable for some non-zero TOS. In this case, 7325 the TOS 0 path is used when forwarding packets (see Section 7326 11.1). 7328 The following lists the modifications needed when running the 7329 routing table calculation for a non-zero TOS value (called TOS 7330 X). In general, routers and LSAs that do not support TOS are 7331 omitted from the calculation. 7333 Calculating the shortest-path tree (Section 16.1). 7334 Routers that do not support TOS-based routing should be 7335 omitted from the shortest-path tree calculation. These 7336 routers are identified as those having the T-bit reset in 7337 the Options field of their router-LSAs. Such routers should 7338 never be added to the Dijkstra algorithm's candidate list, 7339 nor should their router-LSAs be examined when adding the 7340 stub networks to the tree. In particular, if the T-bit is 7341 reset in the calculating router's own router-LSA, it does 7342 not run the shortest-path tree calculation for non-zero TOS 7343 values. 7345 Calculating the inter-area routes (Section 16.2). 7346 Inter-area paths are the concatenation of a path to an area 7347 border router with a summary link. When calculating TOS X 7348 routes, both path components must also specify TOS X. In 7349 other words, only TOS X paths to the area border router are 7350 examined, and the area border router must be advertising a 7351 TOS X route to the destination. Note that this means that 7352 summary-LSAs having the T-bit reset in their Options field 7353 are not considered. 7355 Examining transit areas' summary-LSAs (Section 16.3). 7356 This calculation again considers the concatenation of a path 7357 to an area border router with a summary link. As with 7358 inter-area routes, only TOS X paths to the area border 7359 router are examined, and the area border router must be 7360 advertising a TOS X route to the destination. 7362 Calculating AS external routes (Section 16.4). 7363 This calculation considers the concatenation of a path to a 7364 forwarding address with an AS external link. Only TOS X 7365 paths to the forwarding address are examined, and the AS 7366 boundary router must be advertising a TOS X route to the 7367 destination. Note that this means that AS-external-LSAs 7368 having the T-bit reset in their Options field are not 7369 considered. 7371 In addition, the advertising AS boundary router must also be 7372 reachable for its LSAs to be considered (see Section 16.4). 7373 However, if the advertising router and the forwarding 7374 address are not one in the same, the advertising router need 7375 only be reachable via TOS 0. 7377 Footnotes 7379 [1]The graph's vertices represent either routers, transit networks, 7380 or stub networks. Since routers may belong to multiple areas, it is 7381 not possible to color the graph's vertices. 7383 [2]It is possible for all of a router's interfaces to be unnumbered 7384 point-to-point links. In this case, an IP address must be assigned 7385 to the router. This address will then be advertised in the router's 7386 router-LSA as a host route. 7388 [3]Note that in these cases both interfaces, the non-virtual and the 7389 virtual, would have the same IP address. 7391 [4]Note that no host route is generated for, and no IP packets can 7392 be addressed to, interfaces to unnumbered point-to-point networks. 7393 This is regardless of such an interface's state. 7395 [5]It is instructive to see what happens when the Designated Router 7396 for the network crashes. Call the Designated Router for the network 7397 RT1, and the Backup Designated Router RT2. If Router RT1 crashes 7398 (or maybe its interface to the network dies), the other routers on 7399 the network will detect RT1's absence within RouterDeadInterval 7400 seconds. All routers may not detect this at precisely the same 7401 time; the routers that detect RT1's absence before RT2 does will, 7402 for a time, select RT2 to be both Designated Router and Backup 7403 Designated Router. When RT2 detects that RT1 is gone it will move 7404 itself to Designated Router. At this time, the remaining router 7405 having highest Router Priority will be selected as Backup Designated 7406 Router. 7408 [6]On point-to-point networks, the lower level protocols indicate 7409 whether the neighbor is up and running. Likewise, existence of the 7410 neighbor on virtual links is indicated by the routing table 7411 calculation. However, in both these cases, the Hello Protocol is 7412 still used. This ensures that communication between the neighbors 7413 is bidirectional, and that each of the neighbors has a functioning 7414 routing protocol layer. 7416 [7]When the identity of the Designated Router is changing, it may be 7417 quite common for a neighbor in this state to send the router a 7418 Database Description packet; this means that there is some momentary 7419 disagreement on the Designated Router's identity. 7421 [8]Note that it is possible for a router to resynchronize any of its 7422 fully established adjacencies by setting the adjacency's state back 7423 to ExStart. This will cause the other end of the adjacency to 7424 process a SeqNumberMismatch event, and therefore to also go back to 7425 ExStart state. 7427 [9]The address space of IP networks and the address space of OSPF 7428 Router IDs may overlap. That is, a network may have an IP address 7429 which is identical (when considered as a 32-bit number) to some 7430 router's Router ID. 7432 [10]"Discard" entries are necessary to ensure that route 7433 summarization at area boundaries will not cause packet looping. 7435 [11]It is assumed that, for two different address ranges matching 7436 the destination, one range is more specific than the other. Non- 7437 contiguous subnet masks can be configured to violate this 7438 assumption. Such subnet mask configurations cannot be handled by the 7439 OSPF protocol. 7441 [12]MaxAgeDiff is an architectural constant. It indicates the 7442 maximum dispersion of ages, in seconds, that can occur for a single 7443 LSA instance as it is flooded throughout the routing domain. If two 7444 LSAs differ by more than this, they are assumed to be different 7445 instances of the same LSA. This can occur when a router restarts 7446 and loses track of the LSA's previous LS sequence number. See 7447 Section 13.4 for more details. 7449 [13]When two LSAs have different LS checksums, they are assumed to 7450 be separate instances. This can occur when a router restarts, and 7451 loses track of the LSA's previous LS sequence number. In the case 7452 where the two LSAs have the same LS sequence number, it is not 7453 possible to determine which LSA is actually newer. However, if the 7454 wrong LSA is accepted as newer, the originating router will simply 7455 originate another instance. See Section 13.4 for further details. 7457 [14]There is one instance where a lookup must be done based on 7458 partial information. This is during the routing table calculation, 7459 when a network-LSA must be found based solely on its Link State ID. 7460 The lookup in this case is still well defined, since no two 7461 network-LSAs can have the same Link State ID. 7463 [15]This is the way RFC 1583 specified point-to-point 7464 representation. It has three advantages: a) it does not require 7465 allocating a subnet to the point-to-point link, b) it tends to bias 7466 the routing so that packets destined for the point-to-point 7467 interface will actually be received over the interface (which is 7468 useful for diagnostic purposes) and c) it allows network 7469 bootstrapping of a neighbor, without requiring that the bootstrap 7470 program contain an OSPF implementation. 7472 [16]This is the more traditional point-to-point representation used 7473 by protocols such as RIP. 7475 [17]This clause covers the case: Inter-area routes are not 7476 summarized to the backbone. This is because inter-area routes are 7477 always associated with the backbone area. 7479 [18]This clause is only invoked when a non-backbone Area A supports 7480 transit data traffic (i.e., has TransitCapability set to TRUE). For 7481 example, in the area configuration of Figure 6, Area 2 can support 7482 transit traffic due to the configured virtual link between Routers 7483 RT10 and RT11. As a result, Router RT11 need only originate a single 7484 summary-LSA into Area 2 (having the collapsed destination N9- 7485 N11,H1), since all of Router RT11's other eligible routes have next 7486 hops belonging to Area 2 itself (and as such only need be advertised 7487 by other area border routers; in this case, Routers RT10 and RT7). 7489 [19]By keeping more information in the routing table, it is possible 7490 for an implementation to recalculate the shortest path tree for only 7491 a single area. In fact, there are incremental algorithms that allow 7492 an implementation to recalculate only a portion of a single area's 7493 shortest path tree [Ref1]. However, these algorithms are beyond the 7494 scope of this specification. 7496 [20]This is how the Link state request list is emptied, which 7497 eventually causes the neighbor state to transition to Full. See 7498 Section 10.9 for more details. 7500 [21]It should be a relatively rare occurrence for an LSA's LS age to 7501 reach MaxAge in this fashion. Usually, the LSA will be replaced by 7502 a more recent instance before it ages out. 7504 [22]Only the TOS 0 routes are important here because all OSPF 7505 protocol packets are sent with TOS = 0. See Appendix A. 7507 [23]It may be the case that paths to certain destinations do not 7508 vary based on TOS. For these destinations, the routing calculation 7509 need not be repeated for each TOS value. In addition, there need 7510 only be a single routing table entry for these destinations (instead 7511 of a separate entry for each TOS value). 7513 [24]Strictly speaking, because of equal-cost multipath, the 7514 algorithm does not create a tree. We continue to use the "tree" 7515 terminology because that is what occurs most often in the existing 7516 literature. 7518 [25]Note that the presence of any link back to V is sufficient; it 7519 need not be the matching half of the link under consideration from V 7520 to W. This is enough to ensure that, before data traffic flows 7521 between a pair of neighboring routers, their link state databases 7522 will be synchronized. 7524 [26]When the forwarding address is non-zero, it should point to a 7525 router belonging to another Autonomous System. See Section 12.4.4 7526 for more details. 7528 References 7530 [Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing 7531 Algorithm Improvements", BBN Technical Report 3803, April 7532 1978. 7534 [Ref2] Digital Equipment Corporation, "Information processing 7535 systems -- Data communications -- Intermediate System to 7536 Intermediate System Intra-Domain Routing Protocol", October 7537 1987. 7539 [Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the 7540 ARPANET", IEEE Transactions on Communications, May 1980. 7542 [Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing 7543 Information", Computer Networks, December 1983. 7545 [Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, 7546 USC/Information Sciences Institute, September 1981. 7548 [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 7549 8073", RFC 905, ISO, April 1984. 7551 [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, 7552 RFC 1112, Stanford University, May 1988. 7554 [Ref8] McCloghrie, K., and M. Rose, "Management Information Base 7555 for network management of TCP/IP-based internets: MIB-II", 7556 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 7557 International, March 1991. 7559 [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 7560 1994. 7562 [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 7563 Inter-Domain Routing (CIDR): an Address Assignment and 7564 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 7565 OARnet, September 1993. 7567 [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 7568 1700, USC/Information Sciences Institute, October 1994. 7570 [Ref12] Almquist, P., "Type of Service in the Internet Protocol 7571 Suite", RFC 1349, July 1992. 7573 [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN 7574 Protocol Handbook, April 1985. 7576 [Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution 7577 Protocol", RFC 1293, January 1992. 7579 [Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 7580 Over Frame Relay Networks", RFC 1586, March 1994. 7582 [Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol 7583 Suite", ACM Computer Communications Review, Volume 19, 7584 Number 2, pp. 32-38, April 1989. 7586 [Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 7587 April 1992. 7589 [Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 7590 Inc., March 1994. 7592 [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 7593 RainbowBridge Communications, Stanford University, March 7594 1994. 7596 [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in 7597 progress. 7599 [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 7600 1793, Cascade, April 1995. 7602 [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 7603 DECWRL, Stanford University, November 1990. 7605 [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 7606 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 7607 Systems, March 1995. 7609 A. OSPF data formats 7611 This appendix describes the format of OSPF protocol packets and OSPF 7612 LSAs. The OSPF protocol runs directly over the IP network layer. 7613 Before any data formats are described, the details of the OSPF 7614 encapsulation are explained. 7616 Next the OSPF Options field is described. This field describes 7617 various capabilities that may or may not be supported by pieces of 7618 the OSPF routing domain. The OSPF Options field is contained in OSPF 7619 Hello packets, Database Description packets and in OSPF LSAs. 7621 OSPF packet formats are detailed in Section A.3. A description of 7622 OSPF LSAs appears in Section A.4. 7624 A.1 Encapsulation of OSPF packets 7626 OSPF runs directly over the Internet Protocol's network layer. OSPF 7627 packets are therefore encapsulated solely by IP and local data-link 7628 headers. 7630 OSPF does not define a way to fragment its protocol packets, and 7631 depends on IP fragmentation when transmitting packets larger than 7632 the network MTU. If necessary, the length of OSPF packets can be up 7633 to 65,535 bytes (including the IP header). The OSPF packet types 7634 that are likely to be large (Database Description Packets, Link 7635 State Request, Link State Update, and Link State Acknowledgment 7636 packets) can usually be split into several separate protocol 7637 packets, without loss of functionality. This is recommended; IP 7638 fragmentation should be avoided whenever possible. Using this 7639 reasoning, an attempt should be made to limit the sizes of OSPF 7640 packets sent over virtual links to 576 bytes unless Path MTU 7641 Discovery is being performed (see [Ref22]). 7643 The other important features of OSPF's IP encapsulation are: 7645 o Use of IP multicast. Some OSPF messages are multicast, when 7646 sent over broadcast networks. Two distinct IP multicast 7647 addresses are used. Packets sent to these multicast addresses 7648 should never be forwarded; they are meant to travel a single hop 7649 only. To ensure that these packets will not travel multiple 7650 hops, their IP TTL must be set to 1. 7652 AllSPFRouters 7653 This multicast address has been assigned the value 7654 224.0.0.5. All routers running OSPF should be prepared to 7655 receive packets sent to this address. Hello packets are 7656 always sent to this destination. Also, certain OSPF 7657 protocol packets are sent to this address during the 7658 flooding procedure. 7660 AllDRouters 7661 This multicast address has been assigned the value 7662 224.0.0.6. Both the Designated Router and Backup Designated 7663 Router must be prepared to receive packets destined to this 7664 address. Certain OSPF protocol packets are sent to this 7665 address during the flooding procedure. 7667 o OSPF is IP protocol number 89. This number has been registered 7668 with the Network Information Center. IP protocol number 7669 assignments are documented in [Ref11]. 7671 o Routing protocol packets are sent with IP TOS of 0. The OSPF 7672 protocol supports TOS-based routing. Routes to any particular 7673 destination may vary based on TOS. However, all OSPF routing 7674 protocol packets are sent using the normal service TOS value of 7675 binary 0000 defined in [Ref12]. 7677 o Routing protocol packets are sent with IP precedence set to 7678 Internetwork Control. OSPF protocol packets should be given 7679 precedence over regular IP data traffic, in both sending and 7680 receiving. Setting the IP precedence field in the IP header to 7681 Internetwork Control [Ref5] may help implement this objective. 7683 A.2 The Options field 7685 The OSPF Options field is present in OSPF Hello packets, Database 7686 Description packets and all LSAs. The Options field enables OSPF 7687 routers to support (or not support) optional capabilities, and to 7688 communicate their capability level to other OSPF routers. Through 7689 this mechanism routers of differing capabilities can be mixed within 7690 an OSPF routing domain. 7692 When used in Hello packets, the Options field allows a router to 7693 reject a neighbor because of a capability mismatch. Alternatively, 7694 when capabilities are exchanged in Database Description packets a 7695 router can choose not to forward certain LSAs to a neighbor because 7696 of its reduced functionality. Lastly, listing capabilities in LSAs 7697 allows routers to forward traffic around reduced functionality 7698 routers, by excluding them from parts of the routing table 7699 calculation. 7701 Six bits of the OSPF Options field have been assigned, although only 7702 two (the T-bit and E-bit) are described completely by this memo. 7703 Each bit is described briefly below. Routers should reset (i.e. 7704 clear) unrecognized bits in the Options field when sending Hello 7705 packets or Database Description packets and when originating LSAs. 7706 Conversely, routers encountering unrecognized Option bits in 7707 received Hello Packets, Database Description packets or LSAs should 7708 ignore the capability and process the packet/LSA normally. 7710 +------------------------------------+ 7711 | * | * | DC | EA | N/P | MC | E | T | 7712 +------------------------------------+ 7714 The Options field 7716 T-bit 7717 This bit describes the router's TOS-based routing capability, as 7718 specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of this memo. 7720 E-bit 7721 This bit describes the way AS-external-LSAs are flooded, as 7722 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. 7724 MC-bit 7725 This bit describes whether IP multicast datagrams are forwarded 7726 according to the specifications in [Ref18]. 7728 N/P-bit 7729 This bit describes the handling of Type-7 LSAs, as specified in 7731 [Ref19]. 7733 EA-bit 7734 This bit describes the router's willingness to receive and 7735 forward External-Attributes-LSAs, as specified in [Ref20]. 7737 DC-bit 7738 This bit describes the router's handling of demand circuits, as 7739 specified in [Ref21]. 7741 A.3 OSPF Packet Formats 7743 There are five distinct OSPF packet types. All OSPF packet types 7744 begin with a standard 24 byte header. This header is described 7745 first. Each packet type is then described in a succeeding section. 7746 In these sections each packet's division into fields is displayed, 7747 and then the field definitions are enumerated. 7749 All OSPF packet types (other than the OSPF Hello packets) deal with 7750 lists of LSAs. For example, Link State Update packets implement the 7751 flooding of LSAs throughout the OSPF routing domain. Because of 7752 this, OSPF protocol packets cannot be parsed unless the format of 7753 LSAs is also understood. The format of LSAs is described in Section 7754 A.4. 7756 The receive processing of OSPF packets is detailed in Section 8.2. 7757 The sending of OSPF packets is explained in Section 8.1. 7759 A.3.1 The OSPF packet header 7761 Every OSPF packet starts with a standard 24 byte header. This 7762 header contains all the information necessary to determine whether 7763 the packet should be accepted for further processing. This 7764 determination is described in Section 8.2 of the specification. 7766 0 1 2 3 7767 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 7768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7769 | Version # | Type | Packet length | 7770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7771 | Router ID | 7772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7773 | Area ID | 7774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7775 | Checksum | AuType | 7776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7777 | Authentication | 7778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7779 | Authentication | 7780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7782 Version # 7783 The OSPF version number. This specification documents version 2 7784 of the protocol. 7786 Type 7787 The OSPF packet types are as follows. See Sections A.3.2 through 7788 A.3.6 for details. 7790 Type Description 7791 ________________________________ 7792 1 Hello 7793 2 Database Description 7794 3 Link State Request 7795 4 Link State Update 7796 5 Link State Acknowledgment 7797 Packet length 7798 The length of the OSPF protocol packet in bytes. This length 7799 includes the standard OSPF header. 7801 Router ID 7802 The Router ID of the packet's source. 7804 Area ID 7805 A 32 bit number identifying the area that this packet belongs 7806 to. All OSPF packets are associated with a single area. Most 7807 travel a single hop only. Packets travelling over a virtual 7808 link are labelled with the backbone Area ID of 0.0.0.0. 7810 Checksum 7811 The standard IP checksum of the entire contents of the packet, 7812 starting with the OSPF packet header but excluding the 64-bit 7813 authentication field. This checksum is calculated as the 16-bit 7814 one's complement of the one's complement sum of all the 16-bit 7815 words in the packet, excepting the authentication field. If the 7816 packet's length is not an integral number of 16-bit words, the 7817 packet is padded with a byte of zero before checksumming. The 7818 checksum is considered to be part of the packet authentication 7819 procedure; for some authentication types the checksum 7820 calculation is omitted. 7822 AuType 7823 Identifies the authentication procedure to be used for the 7824 packet. Authentication is discussed in Appendix D of the 7825 specification. Consult Appendix D for a list of the currently 7826 defined authentication types. 7828 Authentication 7829 A 64-bit field for use by the authentication scheme. See 7830 Appendix D for details. 7832 A.3.2 The Hello packet 7834 Hello packets are OSPF packet type 1. These packets are sent 7835 periodically on all interfaces (including virtual links) in order to 7836 establish and maintain neighbor relationships. In addition, Hello 7837 Packets are multicast on those physical networks having a multicast 7838 or broadcast capability, enabling dynamic discovery of neighboring 7839 routers. 7841 All routers connected to a common network must agree on certain 7842 parameters (Network mask, HelloInterval and RouterDeadInterval). 7843 These parameters are included in Hello packets, so that differences 7844 can inhibit the forming of neighbor relationships. A detailed 7845 explanation of the receive processing for Hello packets is presented 7846 in Section 10.5. The sending of Hello packets is covered in Section 7847 9.5. 7849 0 1 2 3 7850 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 7851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7852 | Version # | 1 | Packet length | 7853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7854 | Router ID | 7855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7856 | Area ID | 7857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7858 | Checksum | AuType | 7859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7860 | Authentication | 7861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7862 | Authentication | 7863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7864 | Network Mask | 7865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7866 | HelloInterval | Options | Rtr Pri | 7867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7868 | RouterDeadInterval | 7869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7870 | Designated Router | 7871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7872 | Backup Designated Router | 7873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7874 | Neighbor | 7875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7876 | ... | 7878 Network mask 7879 The network mask associated with this interface. For example, 7880 if the interface is to a class B network whose third byte is 7881 used for subnetting, the network mask is 0xffffff00. 7883 Options 7884 The optional capabilities supported by the router, as documented 7885 in Section A.2. 7887 HelloInterval 7888 The number of seconds between this router's Hello packets. 7890 Rtr Pri 7891 This router's Router Priority. Used in (Backup) Designated 7892 Router election. If set to 0, the router will be ineligible to 7893 become (Backup) Designated Router. 7895 RouterDeadInterval 7896 The number of seconds before declaring a silent router down. 7898 Designated Router 7899 The identity of the Designated Router for this network, in the 7900 view of the sending router. The Designated Router is identified 7901 here by its IP interface address on the network. Set to 0.0.0.0 7902 if there is no Designated Router. 7904 Backup Designated Router 7905 The identity of the Backup Designated Router for this network, 7906 in the view of the sending router. The Backup Designated Router 7907 is identified here by its IP interface address on the network. 7908 Set to 0.0.0.0 if there is no Backup Designated Router. 7910 Neighbor 7911 The Router IDs of each router from whom valid Hello packets have 7912 been seen recently on the network. Recently means in the last 7913 RouterDeadInterval seconds. 7915 A.3.3 The Database Description packet 7917 Database Description packets are OSPF packet type 2. These packets 7918 are exchanged when an adjacency is being initialized. They describe 7919 the contents of the link-state database. Multiple packets may be 7920 used to describe the database. For this purpose a poll-response 7921 procedure is used. One of the routers is designated to be the 7922 master, the other the slave. The master sends Database Description 7923 packets (polls) which are acknowledged by Database Description 7924 packets sent by the slave (responses). The responses are linked to 7925 the polls via the packets' DD sequence numbers. 7927 0 1 2 3 7928 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 7929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7930 | Version # | 2 | Packet length | 7931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7932 | Router ID | 7933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7934 | Area ID | 7935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7936 | Checksum | AuType | 7937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7938 | Authentication | 7939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7940 | Authentication | 7941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7942 | Interface MTU | Options |0|0|0|0|0|I|M|MS 7943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7944 | DD sequence number | 7945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7946 | | 7947 +- -+ 7948 | | 7949 +- An LSA Header -+ 7950 | | 7951 +- -+ 7952 | | 7953 +- -+ 7954 | | 7955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7956 | ... | 7958 The format of the Database Description packet is very similar to 7959 both the Link State Request and Link State Acknowledgment packets. 7960 The main part of all three is a list of items, each item describing 7961 a piece of the link-state database. The sending of Database 7962 Description Packets is documented in Section 10.8. The reception of 7963 Database Description packets is documented in Section 10.6. 7965 Interface MTU 7966 The size in bytes of the largest IP datagram that can be sent 7967 out the associated interface, without fragmentation. The MTUs 7968 of common Internet link types can be found in Table 7-1 of 7969 [Ref22]. Interface MTU should be set to 0 in Database 7970 Description packets sent over virtual links. 7972 Options 7973 The optional capabilities supported by the router, as documented 7974 in Section A.2. 7976 I-bit 7977 The Init bit. When set to 1, this packet is the first in the 7978 sequence of Database Description Packets. 7980 M-bit 7981 The More bit. When set to 1, it indicates that more Database 7982 Description Packets are to follow. 7984 MS-bit 7985 The Master/Slave bit. When set to 1, it indicates that the 7986 router is the master during the Database Exchange process. 7987 Otherwise, the router is the slave. 7989 DD sequence number 7990 Used to sequence the collection of Database Description Packets. 7991 The initial value (indicated by the Init bit being set) should 7992 be unique. The DD sequence number then increments until the 7993 complete database description has been sent. 7995 The rest of the packet consists of a (possibly partial) list of the 7996 link-state database's pieces. Each LSA in the database is described 7997 by its LSA header. The LSA header is documented in Section A.4.1. 7998 It contains all the information required to uniquely identify both 7999 the LSA and the LSA's current instance. 8001 A.3.4 The Link State Request packet 8003 Link State Request packets are OSPF packet type 3. After exchanging 8004 Database Description packets with a neighboring router, a router may 8005 find that parts of its link-state database are out-of-date. The 8006 Link State Request packet is used to request the pieces of the 8007 neighbor's database that are more up-to-date. Multiple Link State 8008 Request packets may need to be used. 8010 A router that sends a Link State Request packet has in mind the 8011 precise instance of the database pieces it is requesting. Each 8012 instance is defined by its LS sequence number, LS checksum, and LS 8013 age, although these fields are not specified in the Link State 8014 Request Packet itself. The router may receive even more recent 8015 instances in response. 8017 The sending of Link State Request packets is documented in Section 8018 10.9. The reception of Link State Request packets is documented in 8019 Section 10.7. 8021 0 1 2 3 8022 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 8023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8024 | Version # | 3 | Packet length | 8025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8026 | Router ID | 8027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8028 | Area ID | 8029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8030 | Checksum | AuType | 8031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8032 | Authentication | 8033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8034 | Authentication | 8035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8036 | LS type | 8037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8038 | Link State ID | 8039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8040 | Advertising Router | 8041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8042 | ... | 8044 Each LSA requested is specified by its LS type, Link State ID, and 8045 Advertising Router. This uniquely identifies the LSA, but not its 8046 instance. Link State Request packets are understood to be requests 8047 for the most recent instance (whatever that might be). 8049 A.3.5 The Link State Update packet 8051 Link State Update packets are OSPF packet type 4. These packets 8052 implement the flooding of LSAs. Each Link State Update packet 8053 carries a collection of LSAs one hop further from their origin. 8054 Several LSAs may be included in a single packet. 8056 Link State Update packets are multicast on those physical networks 8057 that support multicast/broadcast. In order to make the flooding 8058 procedure reliable, flooded LSAs are acknowledged in Link State 8059 Acknowledgment packets. If retransmission of certain LSAs is 8060 necessary, the retransmitted LSAs are always carried by unicast Link 8061 State Update packets. For more information on the reliable flooding 8062 of LSAs, consult Section 13. 8064 0 1 2 3 8065 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 8066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8067 | Version # | 4 | Packet length | 8068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8069 | Router ID | 8070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8071 | Area ID | 8072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8073 | Checksum | AuType | 8074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8075 | Authentication | 8076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8077 | Authentication | 8078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8079 | # LSAs | 8080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8081 | | 8082 +- +-+ 8083 | LSAs | 8084 +- +-+ 8085 | ... | 8087 # LSAs 8088 The number of LSAs included in this update. 8090 The body of the Link State Update packet consists of a list of LSAs. 8091 Each LSA begins with a common 20 byte header, described in Section 8092 A.4.1. Detailed formats of the different types of LSAs are described 8093 in Section A.4. 8095 A.3.6 The Link State Acknowledgment packet 8097 Link State Acknowledgment Packets are OSPF packet type 5. To make 8098 the flooding of LSAs reliable, flooded LSAs are explicitly 8099 acknowledged. This acknowledgment is accomplished through the 8100 sending and receiving of Link State Acknowledgment packets. 8101 Multiple LSAs can be acknowledged in a single Link State 8102 Acknowledgment packet. 8104 Depending on the state of the sending interface and the sender of 8105 the corresponding Link State Update packet, a Link State 8106 Acknowledgment packet is sent either to the multicast address 8107 AllSPFRouters, to the multicast address AllDRouters, or as a 8108 unicast. The sending of Link State Acknowledgement packets is 8109 documented in Section 13.5. The reception of Link State 8110 Acknowledgement packets is documented in Section 13.7. 8112 The format of this packet is similar to that of the Data Description 8113 packet. The body of both packets is simply a list of LSA headers. 8115 0 1 2 3 8116 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 8117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8118 | Version # | 5 | Packet length | 8119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8120 | Router ID | 8121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8122 | Area ID | 8123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8124 | Checksum | AuType | 8125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8126 | Authentication | 8127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8128 | Authentication | 8129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8130 | | 8131 +- -+ 8132 | | 8133 +- An LSA Header -+ 8134 | | 8135 +- -+ 8136 | | 8137 +- -+ 8138 | | 8139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8140 | ... | 8142 Each acknowledged LSA is described by its LSA header. The LSA 8143 header is documented in Section A.4.1. It contains all the 8144 information required to uniquely identify both the LSA and the LSA's 8145 current instance. 8147 A.4 LSA formats 8149 This memo defines five distinct types of LSAs. Each LSA begins with 8150 a standard 20 byte LSA header. This header is explained in Section 8151 A.4.1. Succeeding sections then diagram the separate LSA types. 8153 Each LSA describes a piece of the OSPF routing domain. Every router 8154 originates a router-LSA. In addition, whenever the router is 8155 elected Designated Router, it originates a network-LSA. Other types 8156 of LSAs may also be originated (see Section 12.4). All LSAs are 8157 then flooded throughout the OSPF routing domain. The flooding 8158 algorithm is reliable, ensuring that all routers have the same 8159 collection of LSAs. (See Section 13 for more information concerning 8160 the flooding algorithm). This collection of LSAs is called the 8161 link-state database. 8163 From the link state database, each router constructs a shortest path 8164 tree with itself as root. This yields a routing table (see Section 8165 11). For the details of the routing table build process, see 8166 Section 16. 8168 A.4.1 The LSA header 8170 All LSAs begin with a common 20 byte header. This header contains 8171 enough information to uniquely identify the LSA (LS type, Link State 8172 ID, and Advertising Router). Multiple instances of the LSA may 8173 exist in the routing domain at the same time. It is then necessary 8174 to determine which instance is more recent. This is accomplished by 8175 examining the LS age, LS sequence number and LS checksum fields that 8176 are also contained in the LSA header. 8178 0 1 2 3 8179 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 8180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8181 | LS age | Options | LS type | 8182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8183 | Link State ID | 8184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8185 | Advertising Router | 8186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8187 | LS sequence number | 8188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8189 | LS checksum | length | 8190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8192 LS age 8193 The time in seconds since the LSA was originated. 8195 Options 8196 The optional capabilities supported by the described portion of 8197 the routing domain. OSPF's optional capabilities are documented 8198 in Section A.2. 8200 LS type 8201 The type of the LSA. Each LSA type has a separate advertisement 8202 format. The LSA types defined in this memo are as follows (see 8203 Section 12.1.3 for further explanation): 8205 LS Type Description 8206 ___________________________________ 8207 1 Router-LSAs 8208 2 Network-LSAs 8209 3 Summary-LSAs (IP network) 8210 4 Summary-LSAs (ASBR) 8211 5 AS-external-LSAs 8213 Link State ID 8214 This field identifies the portion of the internet environment 8215 that is being described by the LSA. The contents of this field 8216 depend on the LSA's LS type. For example, in network-LSAs the 8217 Link State ID is set to the IP interface address of the 8218 network's Designated Router (from which the network's IP address 8219 can be derived). The Link State ID is further discussed in 8220 Section 12.1.4. 8222 Advertising Router 8223 The Router ID of the router that originated the LSA. For 8224 example, in network-LSAs this field is equal to the Router ID of 8225 the network's Designated Router. 8227 LS sequence number 8228 Detects old or duplicate LSAs. Successive instances of an LSA 8229 are given successive LS sequence numbers. See Section 12.1.6 8230 for more details. 8232 LS checksum 8233 The Fletcher checksum of the complete contents of the LSA, 8234 including the LSA header but excluding the LS age field. See 8235 Section 12.1.7 for more details. 8237 length 8238 The length in bytes of the LSA. This includes the 20 byte LSA 8239 header. 8241 A.4.2 Router-LSAs 8243 Router-LSAs are the Type 1 LSAs. Each router in an area originates 8244 a router-LSA. The LSA describes the state and cost of the router's 8245 links (i.e., interfaces) to the area. All of the router's links to 8246 the area must be described in a single router-LSA. For details 8247 concerning the construction of router-LSAs, see Section 12.4.1. 8249 0 1 2 3 8250 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 8251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8252 | LS age | Options | 1 | 8253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8254 | Link State ID | 8255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8256 | Advertising Router | 8257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8258 | LS sequence number | 8259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8260 | LS checksum | length | 8261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8262 | 0 |V|E|B| 0 | # links | 8263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8264 | Link ID | 8265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8266 | Link Data | 8267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8268 | Type | # TOS | TOS 0 metric | 8269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8270 | TOS | 0 | metric | 8271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8272 | ... | 8273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8274 | TOS | 0 | metric | 8275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8276 | Link ID | 8277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8278 | Link Data | 8279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8280 | ... | 8282 In router-LSAs, the Link State ID field is set to the router's OSPF 8283 Router ID. The T-bit is set in the LSA's Option field if and only 8284 if the router is able to calculate a separate set of routes for each 8285 IP TOS. Router-LSAs are flooded throughout a single area only. 8287 bit V 8288 When set, the router is an endpoint of one or more fully 8289 adjacent virtual links having the described area as Transit area 8290 (V is for virtual link endpoint). 8292 bit E 8293 When set, the router is an AS boundary router (E is for 8294 external). 8296 bit B 8297 When set, the router is an area border router (B is for border). 8299 # links 8300 The number of router links described in this LSA. This must be 8301 the total collection of router links (i.e., interfaces) to the 8302 area. 8304 The following fields are used to describe each router link (i.e., 8305 interface). Each router link is typed (see the below Type field). 8306 The Type field indicates the kind of link being described. It may 8307 be a link to a transit network, to another router or to a stub 8308 network. The values of all the other fields describing a router 8309 link depend on the link's Type. For example, each link has an 8310 associated 32-bit Link Data field. For links to stub networks this 8311 field specifies the network's IP address mask. For other link types 8312 the Link Data field specifies the router interface's IP address. 8314 Type 8315 A quick description of the router link. One of the following. 8316 Note that host routes are classified as links to stub networks 8317 with network mask of 0xffffffff. 8319 Type Description 8320 __________________________________________________ 8321 1 Point-to-point connection to another router 8322 2 Connection to a transit network 8323 3 Connection to a stub network 8324 4 Virtual link 8326 Link ID 8327 Identifies the object that this router link connects to. Value 8328 depends on the link's Type. When connecting to an object that 8329 also originates an LSA (i.e., another router or a transit 8330 network) the Link ID is equal to the neighboring LSA's Link 8331 State ID. This provides the key for looking up the neighboring 8332 LSA in the link state database during the routing table 8333 calculation. See Section 12.2 for more details. 8335 Type Link ID 8336 ______________________________________ 8337 1 Neighboring router's Router ID 8338 2 IP address of Designated Router 8339 3 IP network/subnet number 8340 4 Neighboring router's Router ID 8342 Link Data 8343 Value again depends on the link's Type field. For connections to 8344 stub networks, Link Data specifies the network's IP address 8345 mask. For unnumbered point-to-point connections, it specifies 8346 the interface's MIB-II [Ref8] ifIndex value. For the other link 8347 types it specifies the router interface's IP address. This 8348 latter piece of information is needed during the routing table 8349 build process, when calculating the IP address of the next hop. 8350 See Section 16.1.1 for more details. 8352 # TOS 8353 The number of different TOS metrics given for this link, not 8354 counting the required metric for TOS 0. For example, if no 8355 additional TOS metrics are given, this field is set to 0. 8357 TOS 0 metric 8358 The cost of using this router link for TOS 0. 8360 For each link, separate metrics may be specified for each Type of 8361 Service (TOS). The metric for TOS 0 must always be included, and 8362 was discussed above. Metrics for non-zero TOS are described below. 8363 The encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8364 that the cost for non-zero TOS values that are not specified 8365 defaults to the TOS 0 cost. Metrics must be listed in order of 8366 increasing TOS encoding. For example, the metric for TOS 16 must 8367 always follow the metric for TOS 8 when both are specified. 8369 TOS IP Type of Service that this metric refers to. The encoding of 8370 TOS in OSPF LSAs is described in Section 12.3. 8372 metric 8373 The cost of using this outbound router link, for traffic of the 8374 specified TOS. 8376 A.4.3 Network-LSAs 8378 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 8379 each broadcast and NBMA network in the area which supports two or 8380 more routers. The network-LSA is originated by the network's 8381 Designated Router. The LSA describes all routers attached to the 8382 network, including the Designated Router itself. The LSA's Link 8383 State ID field lists the IP interface address of the Designated 8384 Router. 8386 The distance from the network to all attached routers is zero, for 8387 all Types of Service. This is why the TOS and metric fields need 8388 not be specified in the network-LSA. For details concerning the 8389 construction of network-LSAs, see Section 12.4.2. 8391 0 1 2 3 8392 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 8393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8394 | LS age | Options | 2 | 8395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8396 | Link State ID | 8397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8398 | Advertising Router | 8399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8400 | LS sequence number | 8401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8402 | LS checksum | length | 8403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8404 | Network Mask | 8405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8406 | Attached Router | 8407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8408 | ... | 8410 Network Mask 8411 The IP address mask for the network. For example, a class A 8412 network would have the mask 0xff000000. 8414 Attached Router 8415 The Router IDs of each of the routers attached to the network. 8416 Actually, only those routers that are fully adjacent to the 8417 Designated Router are listed. The Designated Router includes 8418 itself in this list. The number of routers included can be 8419 deduced from the LSA header's length field. 8421 A.4.4 Summary-LSAs 8423 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated 8424 by area border routers. Summary-LSAs describe inter-area 8425 destinations. For details concerning the construction of summary- 8426 LSAs, see Section 12.4.3. 8428 Type 3 summary-LSAs are used when the destination is an IP network. 8429 In this case the LSA's Link State ID field is an IP network number 8430 (if necessary, the Link State ID can also have one or more of the 8431 network's "host" bits set; see Appendix E for details). When the 8432 destination is an AS boundary router, a Type 4 summary-LSA is used, 8433 and the Link State ID field is the AS boundary router's OSPF Router 8434 ID. (To see why it is necessary to advertise the location of each 8435 ASBR, consult Section 16.4.) Other than the difference in the Link 8436 State ID field, the format of Type 3 and 4 summary-LSAs is 8437 identical. 8439 0 1 2 3 8440 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 8441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8442 | LS age | Options | 3 or 4 | 8443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8444 | Link State ID | 8445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8446 | Advertising Router | 8447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8448 | LS sequence number | 8449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8450 | LS checksum | length | 8451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8452 | Network Mask | 8453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8454 | TOS | metric | 8455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8456 | ... | 8458 For stub areas, Type 3 summary-LSAs can also be used to describe a 8459 (per-area) default route. Default summary routes are used in stub 8460 areas instead of flooding a complete set of external routes. When 8461 describing a default summary route, the summary-LSA's Link State ID 8462 is always set to DefaultDestination (0.0.0.0) and the Network Mask 8463 is set to 0.0.0.0. 8465 Separate costs may be advertised for each IP Type of Service. The 8466 encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8467 that the cost for TOS 0 must be included, and is always listed 8468 first. If the T-bit is reset in the LSA's Option field, only a 8469 route for TOS 0 is described by the LSA. Otherwise, routes for the 8470 other TOS values are also described; if a cost for a certain TOS is 8471 not included, its cost defaults to that specified for TOS 0. 8473 Network Mask 8474 For Type 3 summary-LSAs, this indicates the destination 8475 network's IP address mask. For example, when advertising the 8476 location of a class A network the value 0xff000000 would be 8477 used. This field is not meaningful and must be zero for Type 4 8478 summary-LSAs. 8480 For each specified Type of Service, the following fields are 8481 defined. The number of TOS routes included can be calculated from 8482 the LSA header's length field. A value for TOS 0 must be specified; 8483 it is listed first. Other values must be listed in order of 8484 increasing TOS encoding. For example, the cost for TOS 16 must 8485 always follow the cost for TOS 8 when both are specified. 8487 TOS The Type of Service that the following cost concerns. The 8488 encoding of TOS in OSPF LSAs is described in Section 12.3. 8490 metric 8491 The cost of this route. Expressed in the same units as the 8492 interface costs in the router-LSAs. 8494 A.4.5 AS-external-LSAs 8496 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 8497 AS boundary routers, and describe destinations external to the AS. 8498 For details concerning the construction of AS-external-LSAs, see 8499 Section 12.4.3. 8501 AS-external-LSAs usually describe a particular external destination. 8502 For these LSAs the Link State ID field specifies an IP network 8503 number (if necessary, the Link State ID can also have one or more of 8504 the network's "host" bits set; see Appendix E for details). AS- 8505 external-LSAs are also used to describe a default route. Default 8506 routes are used when no specific route exists to the destination. 8507 When describing a default route, the Link State ID is always set to 8508 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8510 0 1 2 3 8511 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 8512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8513 | LS age | Options | 5 | 8514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8515 | Link State ID | 8516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8517 | Advertising Router | 8518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8519 | LS sequence number | 8520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8521 | LS checksum | length | 8522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8523 | Network Mask | 8524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8525 |E| TOS | metric | 8526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8527 | Forwarding address | 8528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8529 | External Route Tag | 8530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8531 | ... | 8533 Separate costs may be advertised for each IP Type of Service. The 8534 encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8535 that the cost for TOS 0 must be included, and is always listed 8536 first. If the T-bit is reset in the LSA's Option field, only a 8537 route for TOS 0 is described by the LSA. Otherwise, routes for the 8538 other TOS values are also described; if a cost for a certain TOS is 8539 not included, its cost defaults to that specified for TOS 0. 8541 Network Mask 8542 The IP address mask for the advertised destination. For 8543 example, when advertising a class A network the mask 0xff000000 8544 would be used. 8546 For each specified Type of Service, the following fields are 8547 defined. The number of TOS routes included can be calculated from 8548 the LSA header's length field. A value for TOS 0 must be specified; 8549 it is listed first. Other values must be listed in order of 8550 increasing TOS encoding. For example, the cost for TOS 16 must 8551 always follow the cost for TOS 8 when both are specified. 8553 TOS The Type of Service that the following fields concern. The 8554 encoding of TOS in OSPF LSAs is described in Section 12.3. 8556 bit E 8557 The type of external metric. If bit E is set, the metric 8558 specified is a Type 2 external metric. This means the metric is 8559 considered larger than any link state path. If bit E is zero, 8560 the specified metric is a Type 1 external metric. This means 8561 that it is expressed in the same units as the link state metric 8562 (i.e., the same units as interface cost). 8564 metric 8565 The cost of this route. Interpretation depends on the external 8566 type indication (bit E above). 8568 Forwarding address 8569 Data traffic for the advertised destination and TOS will be 8570 forwarded to this address. If the Forwarding address is set to 8571 0.0.0.0, data traffic will be forwarded instead to the LSA's 8572 originator (i.e., the responsible AS boundary router). 8574 External Route Tag 8575 A 32-bit field attached to each external route. This is not 8576 used by the OSPF protocol itself. It may be used to communicate 8577 information between AS boundary routers; the precise nature of 8578 such information is outside the scope of this specification. 8580 B. Architectural Constants 8582 Several OSPF protocol parameters have fixed architectural values. 8583 These parameters have been referred to in the text by names such as 8584 LSRefreshTime. The same naming convention is used for the 8585 configurable protocol parameters. They are defined in Appendix C. 8587 The name of each architectural constant follows, together with its 8588 value and a short description of its function. 8590 LSRefreshTime 8591 The maximum time between distinct originations of any particular 8592 LSA. If the LS age field of one of the router's self-originated 8593 LSAs reaches the value LSRefreshTime, a new instance of the LSA 8594 is originated, even though the contents of the LSA (apart from 8595 the LSA header) will be the same. The value of LSRefreshTime is 8596 set to 30 minutes. 8598 MinLSInterval 8599 The minimum time between distinct originations of any particular 8600 LSA. The value of MinLSInterval is set to 5 seconds. 8602 MinLSArrival 8603 For any particular LSA, the minimum time that must elapse 8604 between reception of new LSA instances during flooding. LSA 8605 instances received at higher frequencies are discarded. The 8606 value of MinLSArrival is set to 1 second. 8608 MaxAge 8609 The maximum age that an LSA can attain. When an LSA's LS age 8610 field reaches MaxAge, it is reflooded in an attempt to flush the 8611 LSA from the routing domain (See Section 14). LSAs of age MaxAge 8612 are not used in the routing table calculation. The value of 8613 MaxAge is set to 1 hour. 8615 CheckAge 8616 When the age of an LSA in the link state database hits a 8617 multiple of CheckAge, the LSA's checksum is verified. An 8618 incorrect checksum at this time indicates a serious error. The 8619 value of CheckAge is set to 5 minutes. 8621 MaxAgeDiff 8622 The maximum time dispersion that can occur, as an LSA is flooded 8623 throughout the AS. Most of this time is accounted for by the 8624 LSAs sitting on router output queues (and therefore not aging) 8625 during the flooding process. The value of MaxAgeDiff is set to 8626 15 minutes. 8628 LSInfinity 8629 The metric value indicating that the destination described by an 8630 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as 8631 an alternative to premature aging (see Section 14.1). It is 8632 defined to be the 24-bit binary value of all ones: 0xffffff. 8634 DefaultDestination 8635 The Destination ID that indicates the default route. This route 8636 is used when no other matching routing table entry can be found. 8637 The default destination can only be advertised in AS-external- 8638 LSAs and in stub areas' type 3 summary-LSAs. Its value is the 8639 IP address 0.0.0.0. Its associated Network Mask is also always 8640 0.0.0.0. 8642 InitialSequenceNumber 8643 The value used for LS Sequence Number when originating the first 8644 instance of any LSA. Its value is the signed 32-bit integer 8645 0x80000001. 8647 MaxSequenceNumber 8648 The maximum value that LS Sequence Number can attain. Its value 8649 is the signed 32-bit integer 0x7fffffff. 8651 C. Configurable Constants 8653 The OSPF protocol has quite a few configurable parameters. These 8654 parameters are listed below. They are grouped into general 8655 functional categories (area parameters, interface parameters, etc.). 8656 Sample values are given for some of the parameters. 8658 Some parameter settings need to be consistent among groups of 8659 routers. For example, all routers in an area must agree on that 8660 area's parameters, and all routers attached to a network must agree 8661 on that network's IP network number and mask. 8663 Some parameters may be determined by router algorithms outside of 8664 this specification (e.g., the address of a host connected to the 8665 router via a SLIP line). From OSPF's point of view, these items are 8666 still configurable. 8668 C.1 Global parameters 8670 In general, a separate copy of the OSPF protocol is run for each 8671 area. Because of this, most configuration parameters are 8672 defined on a per-area basis. The few global configuration 8673 parameters are listed below. 8675 Router ID 8676 This is a 32-bit number that uniquely identifies the router 8677 in the Autonomous System. One algorithm for Router ID 8678 assignment is to choose the largest or smallest IP address 8679 assigned to the router. If a router's OSPF Router ID is 8680 changed, the router's OSPF software should be restarted 8681 before the new Router ID takes effect. Before restarting in 8682 order to change its Router ID, the router should flush its 8683 self-originated LSAs from the routing domain (see Section 8684 14.1), or they will persist for up to MaxAge minutes. 8686 TOS capability 8687 This item indicates whether the router will calculate 8688 separate routes based on TOS. For more information, see 8689 Sections 4.5 and 16.9. 8691 RFC1583Compatibility 8692 Controls the preference rules used in Section 16.4 when 8693 choosing among multiple AS-external-LSAs advertising the 8694 same destination. When set to "enabled", the preference 8695 rules remain those specified by RFC 1583 ([Ref9]). When set 8696 to "disabled", the preference rules are those stated in 8697 Section 16.4.1, which prevent routing loops when AS- 8698 external-LSAs for the same destination have been originated 8699 from different areas (see Section G.7). Set to "enabled" by 8700 default. 8702 In order to minimize the chance of routing loops, all OSPF 8703 routers in an OSPF routing domain should have 8704 RFC1583Compatibility set identically. When there are routers 8705 present that have not been updated with the functionality 8706 specified in Section 16.4.1 of this memo, all routers should 8707 have RFC1583Compatibility set to "enabled". Otherwise, all 8708 routers should have RFC1583Compatibility set to "disabled", 8709 preventing all routing loops. 8711 C.2 Area parameters 8713 All routers belonging to an area must agree on that area's 8714 configuration. Disagreements between two routers will lead to 8715 an inability for adjacencies to form between them, with a 8716 resulting hindrance to the flow of routing protocol and data 8717 traffic. The following items must be configured for an area: 8719 Area ID 8720 This is a 32-bit number that identifies the area. The Area 8721 ID of 0.0.0.0 is reserved for the backbone. If the area 8722 represents a subnetted network, the IP network number of the 8723 subnetted network may be used for the Area ID. 8725 List of address ranges 8726 An OSPF area is defined as a list of address ranges. Each 8727 address range consists of the following items: 8729 [IP address, mask] 8730 Describes the collection of IP addresses contained 8731 in the address range. Networks and hosts are 8732 assigned to an area depending on whether their 8733 addresses fall into one of the area's defining 8734 address ranges. Routers are viewed as belonging to 8735 multiple areas, depending on their attached 8736 networks' area membership. 8738 Status Set to either Advertise or DoNotAdvertise. Routing 8739 information is condensed at area boundaries. 8740 External to the area, at most a single route is 8741 advertised (via a summary-LSA) for each address 8742 range. The route is advertised if and only if the 8743 address range's Status is set to Advertise. 8744 Unadvertised ranges allow the existence of certain 8745 networks to be intentionally hidden from other 8746 areas. Status is set to Advertise by default. 8748 As an example, suppose an IP subnetted network is to be its 8749 own OSPF area. The area would be configured as a single 8750 address range, whose IP address is the address of the 8751 subnetted network, and whose mask is the natural class A, B, 8752 or C address mask. A single route would be advertised 8753 external to the area, describing the entire subnetted 8754 network. 8756 ExternalRoutingCapability 8757 Whether AS-external-LSAs will be flooded into/throughout the 8758 area. If AS-external-LSAs are excluded from the area, the 8759 area is called a "stub". Internal to stub areas, routing to 8760 external destinations will be based solely on a default 8761 summary route. The backbone cannot be configured as a stub 8762 area. Also, virtual links cannot be configured through stub 8763 areas. For more information, see Section 3.6. 8765 StubDefaultCost 8766 If the area has been configured as a stub area, and the 8767 router itself is an area border router, then the 8768 StubDefaultCost indicates the cost of the default summary- 8769 LSA that the router should advertise into the area. There 8770 can be a separate cost configured for each IP TOS. See 8771 Section 12.4.3 for more information. 8773 C.3 Router interface parameters 8775 Some of the configurable router interface parameters (such as IP 8776 interface address and subnet mask) actually imply properties of 8777 the attached networks, and therefore must be consistent across 8778 all the routers attached to that network. The parameters that 8779 must be configured for a router interface are: 8781 IP interface address 8782 The IP protocol address for this interface. This uniquely 8783 identifies the router over the entire internet. An IP 8784 address is not required on point-to-point networks. Such a 8785 point-to-point network is called "unnumbered". 8787 IP interface mask 8788 Also referred to as the subnet/network mask, this indicates 8789 the portion of the IP interface address that identifies the 8790 attached network. Masking the IP interface address with the 8791 IP interface mask yields the IP network number of the 8792 attached network. On point-to-point networks and virtual 8793 links, the IP interface mask is not defined. On these 8794 networks, the link itself is not assigned an IP network 8795 number, and so the addresses of each side of the link are 8796 assigned independently, if they are assigned at all. 8798 Area ID 8799 The OSPF area to which the attached network belongs. 8801 Interface output cost(s) 8802 The cost of sending a packet on the interface, expressed in 8803 the link state metric. This is advertised as the link cost 8804 for this interface in the router's router-LSA. There may be 8805 a separate cost for each IP Type of Service. The interface 8806 output cost(s) must always be greater than 0. 8808 RxmtInterval 8809 The number of seconds between LSA retransmissions, for 8810 adjacencies belonging to this interface. Also used when 8811 retransmitting Database Description and Link State Request 8812 Packets. This should be well over the expected round-trip 8813 delay between any two routers on the attached network. The 8814 setting of this value should be conservative or needless 8815 retransmissions will result. Sample value for a local area 8816 network: 5 seconds. 8818 InfTransDelay 8819 The estimated number of seconds it takes to transmit a Link 8820 State Update Packet over this interface. LSAs contained in 8821 the update packet must have their age incremented by this 8822 amount before transmission. This value should take into 8823 account the transmission and propagation delays of the 8824 interface. It must be greater than 0. Sample value for a 8825 local area network: 1 second. 8827 Router Priority 8828 An 8-bit unsigned integer. When two routers attached to a 8829 network both attempt to become Designated Router, the one 8830 with the highest Router Priority takes precedence. If there 8831 is still a tie, the router with the highest Router ID takes 8832 precedence. A router whose Router Priority is set to 0 is 8833 ineligible to become Designated Router on the attached 8834 network. Router Priority is only configured for interfaces 8835 to broadcast and NBMA networks. 8837 HelloInterval 8838 The length of time, in seconds, between the Hello Packets 8839 that the router sends on the interface. This value is 8840 advertised in the router's Hello Packets. It must be the 8841 same for all routers attached to a common network. The 8842 smaller the HelloInterval, the faster topological changes 8843 will be detected; however, more OSPF routing protocol 8844 traffic will ensue. Sample value for a X.25 PDN network: 30 8845 seconds. Sample value for a local area network: 10 seconds. 8847 RouterDeadInterval 8848 After ceasing to hear a router's Hello Packets, the number 8849 of seconds before its neighbors declare the router down. 8850 This is also advertised in the router's Hello Packets in 8851 their RouterDeadInterval field. This should be some 8852 multiple of the HelloInterval (say 4). This value again 8853 must be the same for all routers attached to a common 8854 network. 8856 AuType 8857 Identifies the authentication procedure to be used on the 8858 attached network. This value must be the same for all 8859 routers attached to the network. See Appendix D for a 8860 discussion of the defined authentication types. 8862 Authentication key 8863 This configured data allows the authentication procedure to 8864 verify OSPF protocol packets received over the interface. 8865 For example, if the AuType indicates simple password, the 8866 Authentication key would be a clear 64-bit password. 8867 Authentication keys associated with the other OSPF 8868 authentication types are discussed in Appendix D. 8870 C.4 Virtual link parameters 8872 Virtual links are used to restore/increase connectivity of the 8873 backbone. Virtual links may be configured between any pair of 8874 area border routers having interfaces to a common (non-backbone) 8875 area. The virtual link appears as an unnumbered point-to-point 8876 link in the graph for the backbone. The virtual link must be 8877 configured in both of the area border routers. 8879 A virtual link appears in router-LSAs (for the backbone) as if 8880 it were a separate router interface to the backbone. As such, 8881 it has all of the parameters associated with a router interface 8882 (see Section C.3). Although a virtual link acts like an 8883 unnumbered point-to-point link, it does have an associated IP 8884 interface address. This address is used as the IP source in 8885 OSPF protocol packets it sends along the virtual link, and is 8886 set dynamically during the routing table build process. 8887 Interface output cost is also set dynamically on virtual links 8888 to be the cost of the intra-area path between the two routers. 8889 The parameter RxmtInterval must be configured, and should be 8890 well over the expected round-trip delay between the two routers. 8891 This may be hard to estimate for a virtual link; it is better to 8892 err on the side of making it too large. Router Priority is not 8893 used on virtual links. 8895 A virtual link is defined by the following two configurable 8896 parameters: the Router ID of the virtual link's other endpoint, 8897 and the (non-backbone) area through which the virtual link runs 8898 (referred to as the virtual link's Transit area). Virtual links 8899 cannot be configured through stub areas. 8901 C.5 NBMA network parameters 8903 OSPF treats an NBMA network much like it treats a broadcast 8904 network. Since there may be many routers attached to the 8905 network, a Designated Router is selected for the network. This 8906 Designated Router then originates a network-LSA, which lists all 8907 routers attached to the NBMA network. 8909 However, due to the lack of broadcast capabilities, it may be 8910 necessary to use configuration parameters in the Designated 8911 Router selection. These parameters will only need to be 8912 configured in those routers that are themselves eligible to 8913 become Designated Router (i.e., those router's whose Router 8914 Priority for the network is non-zero), and then only if no 8915 automatic procedure for discovering neighbors exists: 8917 List of all other attached routers 8918 The list of all other routers attached to the NBMA network. 8919 Each router is listed by its IP interface address on the 8920 network. Also, for each router listed, that router's 8921 eligibility to become Designated Router must be defined. 8922 When an interface to a NBMA network comes up, the router 8923 sends Hello Packets only to those neighbors eligible to 8924 become Designated Router, until the identity of the 8925 Designated Router is discovered. 8927 PollInterval 8928 If a neighboring router has become inactive (Hello Packets 8929 have not been seen for RouterDeadInterval seconds), it may 8930 still be necessary to send Hello Packets to the dead 8931 neighbor. These Hello Packets will be sent at the reduced 8932 rate PollInterval, which should be much larger than 8933 HelloInterval. Sample value for a PDN X.25 network: 2 8934 minutes. 8936 C.6 Point-to-MultiPoint network parameters 8938 On Point-to-MultiPoint networks, it may be necessary to 8939 configure the set of neighbors that are directly reachable over 8940 the Point-to-MultiPoint network. Each neighbor is identified by 8941 its IP address on the Point-to-MultiPoint network. Designated 8942 Routers are not elected on Point-to-MultiPoint networks, so the 8943 Designated Router eligibility of configured neighbors is 8944 undefined. 8946 Alternatively, neighbors on Point-to-MultiPoint networks may be 8947 dynamically discovered by lower-level protocols such as Inverse 8948 ARP ([Ref14]). 8950 C.7 Host route parameters 8952 Host routes are advertised in router-LSAs as stub networks with 8953 mask 0xffffffff. They indicate either router interfaces to 8954 point-to-point networks, looped router interfaces, or IP hosts 8955 that are directly connected to the router (e.g., via a SLIP 8956 line). For each host directly connected to the router, the 8957 following items must be configured: 8959 Host IP address 8960 The IP address of the host. 8962 Cost of link to host 8963 The cost of sending a packet to the host, in terms of the 8964 link state metric. There may be multiple costs configured, 8965 one for each IP TOS. However, since the host probably has 8966 only a single connection to the internet, the actual 8967 configured cost(s) in many cases is unimportant (i.e., will 8968 have no effect on routing). 8970 Area ID 8971 The OSPF area to which the host belongs. 8973 D. Authentication 8975 All OSPF protocol exchanges are authenticated. The OSPF packet 8976 header (see Section A.3.1) includes an authentication type field, 8977 and 64-bits of data for use by the appropriate authentication scheme 8978 (determined by the type field). 8980 The authentication type is configurable on a per-interface (or 8981 equivalently, on a per-network/subnet) basis. Additional 8982 authentication data is also configurable on a per-interface basis. 8984 Authentication types 0, 1 and 2 are defined by this specification. 8985 All other authentication types are reserved for definition by the 8986 IANA (iana@ISI.EDU). The current list of authentication types is 8987 described below in Table 20. 8989 AuType Description 8990 ___________________________________________ 8991 0 Null authentication 8992 1 Simple password 8993 2 Cryptographic authentication 8994 All others Reserved for assignment by the 8995 IANA (iana@ISI.EDU) 8997 Table 20: OSPF authentication types. 8999 D.1 Null authentication 9001 Use of this authentication type means that routing exchanges 9002 over the network/subnet are not authenticated. The 64-bit 9003 authentication field in the OSPF header can contain anything; it 9004 is not examined on packet reception. When employing Null 9005 authentication, the entire contents of each OSPF packet (other 9006 than the 64-bit authentication field) are checksummed in order 9007 to detect data corruption. 9009 D.2 Simple password authentication 9011 Using this authentication type, a 64-bit field is configured on 9012 a per-network basis. All packets sent on a particular network 9013 must have this configured value in their OSPF header 64-bit 9014 authentication field. This essentially serves as a "clear" 64- 9015 bit password. In addition, the entire contents of each OSPF 9016 packet (other than the 64-bit authentication field) are 9017 checksummed in order to detect data corruption. 9019 Simple password authentication guards against routers 9020 inadvertently joining the routing domain; each router must first 9021 be configured with its attached networks' passwords before it 9022 can participate in routing. However, simple password 9023 authentication is vulnerable to passive attacks currently 9024 widespread in the Internet (see [Ref16]). Anyone with physical 9025 access to the network can learn the password and compromise the 9026 security of the OSPF routing domain. 9028 D.3 Cryptographic authentication 9030 Using this authentication type, a shared secret key is 9031 configured in all routers attached to a common network/subnet. 9032 For each OSPF protocol packet, the key is used to 9033 generate/verify a "message digest" that is appended to the end 9034 of the OSPF packet. The message digest is a one-way function of 9035 the OSPF protocol packet and the secret key. Since the secret 9036 key is never sent over the network in the clear, protection is 9037 provided against passive attacks. 9039 The algorithms used to generate and verify the message digest 9040 are specified implicitly by the secret key. This specification 9041 completely defines the use of OSPF Cryptographic authentication 9042 when the MD5 algorithm is used. 9044 In addition, a non-decreasing sequence number is included in 9045 each OSPF protocol packet to protect against replay attacks. 9046 This provides long term protection; however, it is still 9047 possible to replay an OSPF packet until the sequence number 9048 changes. To implement this feature, each neighbor data structure 9050 0 1 2 3 9051 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 9052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9053 | 0 | Key ID | Auth Data Len | 9054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9055 | Cryptographic sequence number | 9056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9058 Figure 18: Usage of the Authentication field 9059 in the OSPF packet header when Cryptographic 9060 Authentication is employed 9061 contains a new field called the "cryptographic sequence number". 9062 This field is initialized to zero, and is also set to zero 9063 whenever the neighbor's state transitions to "Down". Whenever an 9064 OSPF packet is accepted as authentic, the cryptographic sequence 9065 number is set to the received packet's sequence number. 9067 This specification does not provide a rollover procedure for the 9068 cryptographic sequence number. When the cryptographic sequence 9069 number that the router is sending hits the maximum value, the 9070 router should reset the cryptographic sequence number that it is 9071 sending back to 0. After this is done, the router's neighbors 9072 will reject the router's OSPF packets for a period of 9073 RouterDeadInterval, and then the router will be forced to 9074 reestablish all adjacencies over the interface. However, it is 9075 expected that many implementations will use "seconds since 9076 reboot" (or "seconds since 1960", etc.) as the cryptographic 9077 sequence number. Such a choice will essentially prevent 9078 rollover, since the cryptographic sequence number field is 32 9079 bits in length. 9081 The OSPF Cryptographic authentication option does not provide 9082 confidentiality. 9084 When cryptographic authentication is used, the 64-bit 9085 Authentication field in the standard OSPF packet header is 9086 redefined as shown in Figure 18. The new field definitions are 9087 as follows: 9089 Key ID 9090 This field identifies the algorithm and secret key used to 9091 create the message digest appended to the OSPF packet. Key 9092 Identifiers are unique per-interface (or equivalently, per- 9093 subnet). 9095 Auth Data Len 9096 The length in bytes of the message digest appended to the 9097 OSPF packet. 9099 Cryptographic sequence number 9100 An unsigned 32-bit non-decreasing sequence number. Used to 9101 guard against replay attacks. 9103 The message digest appended to the OSPF packet is not actually 9104 considered part of the OSPF protocol packet: the message digest 9105 is not included in the OSPF header's packet length, although it 9106 is included in the packet's IP header length field. 9108 Each key is identified by the combination of interface and Key 9109 ID. An interface may have multiple keys active at any one time. 9110 This enables smooth transition from one key to another. Each key 9111 has four time constants associated with it. These time constants 9112 can be expressed in terms of a time-of-day clock, or in terms of 9113 a router's local clock (e.g., number of seconds since last 9114 reboot): 9116 KeyStartAccept 9117 The time that the router will start accepting packets that 9118 have been created with the given key. 9120 KeyStartGenerate 9121 The time that the router will start using the key for packet 9122 generation. 9124 KeyStopGenerate 9125 The time that the router will stop using the key for packet 9126 generation. 9128 KeyStopAccept 9129 The time that the router will stop accepting packets that 9130 have been created with the given key. 9132 In order to achieve smooth key transition, KeyStartAccept should 9133 be less than KeyStartGenerate and KeyStopGenerate should be less 9134 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are 9135 left unspecified, the key's lifetime is infinite. When a new key 9136 replaces an old, the KeyStartGenerate time for the new key must 9137 be less than or equal to the KeyStopGenerate time of the old 9138 key. 9140 Key storage should persist across a system restart, warm or 9141 cold, to avoid operational issues. In the event that the last 9142 key associated with an interface expires, it is unacceptable to 9143 revert to an unauthenticated condition, and not advisable to 9144 disrupt routing. Therefore, the router should send a "last 9145 authentication key expiration" notification to the network 9146 manager and treat the key as having an infinite lifetime until 9147 the lifetime is extended, the key is deleted by network 9148 management, or a new key is configured. 9150 D.4 Message generation 9152 After building the contents of an OSPF packet, the 9153 authentication procedure indicated by the sending interface's 9154 Autype value is called before the packet is sent. The 9155 authentication procedure modifies the OSPF packet as follows. 9157 D.4.1 Generating Null authentication 9159 When using Null authentication, the packet is modified as 9160 follows: 9162 (1) The Autype field in the standard OSPF header is set to 9163 0. 9165 (2) The checksum field in the standard OSPF header is set to 9166 the standard IP checksum of the entire contents of the 9167 packet, starting with the OSPF packet header but 9168 excluding the 64-bit authentication field. This 9169 checksum is calculated as the 16-bit one's complement of 9170 the one's complement sum of all the 16-bit words in the 9171 packet, excepting the authentication field. If the 9172 packet's length is not an integral number of 16-bit 9173 words, the packet is padded with a byte of zero before 9174 checksumming. 9176 D.4.2 Generating Simple password authentication 9178 When using Simple password authentication, the packet is 9179 modified as follows: 9181 (1) The Autype field in the standard OSPF header is set to 9182 1. 9184 (2) The checksum field in the standard OSPF header is set to 9185 the standard IP checksum of the entire contents of the 9186 packet, starting with the OSPF packet header but 9187 excluding the 64-bit authentication field. This 9188 checksum is calculated as the 16-bit one's complement of 9189 the one's complement sum of all the 16-bit words in the 9190 packet, excepting the authentication field. If the 9191 packet's length is not an integral number of 16-bit 9192 words, the packet is padded with a byte of zero before 9193 checksumming. 9195 (3) The 64-bit authentication field in the OSPF packet 9196 header is set to the 64-bit password (i.e., 9197 authentication key) that has been configured for the 9198 interface. 9200 D.4.3 Generating Cryptographic authentication 9202 When using Cryptographic authentication, there may be 9203 multiple keys configured for the interface. In this case, 9204 among the keys that are valid for message generation (i.e, 9205 that have KeyStartGenerate <= current time < 9206 KeyStopGenerate) choose the one with the most recent 9207 KeyStartGenerate time. Using this key, modify the packet as 9208 follows: 9210 (1) The Autype field in the standard OSPF header is set to 9211 2. 9213 (2) The checksum field in the standard OSPF header is not 9214 calculated, but is instead set to 0. 9216 (3) The Key ID (see Figure 18) is set to the chosen key's 9217 Key ID. 9219 (4) The Auth Data Len field is set to the length in bytes of 9220 the message digest that will be appended to the OSPF 9221 packet. When using MD5 as the authentication algorithm, 9222 Auth Data Len will be 16. 9224 (5) The 32-bit Cryptographic sequence number (see Figure 18) 9225 is set to a non-decreasing value (i.e., a value at least 9226 as large as the last value sent out the interface). The 9227 precise values to use in the cryptographic sequence 9228 number field are implementation-specific. For example, 9229 it may be based on a simple counter, or be based on the 9230 system's clock. 9232 (6) The message digest is then calculated and appended to 9233 the OSPF packet. The authentication algorithm to be 9234 used in calculating the digest is indicated by the key 9235 itself. Input to the authentication algorithm consists 9236 of the OSPF packet and the secret key. When using MD5 as 9237 the authentication algorithm, the message digest 9238 calculation proceeds as follows: 9240 (a) The 16 byte MD5 key is appended to the OSPF packet. 9242 (b) Trailing pad and length fields are added, as 9243 specified in [Ref17]. 9245 (c) The MD5 authentication algorithm is run over the 9246 concatenation of the OSPF packet, secret key, pad 9247 and length fields, producing a 16 byte message 9248 digest (see [Ref17]). 9250 (d) The MD5 digest is written over the OSPF key (i.e., 9251 appended to the original OSPF packet). The digest is 9252 not counted in the OSPF packet's length field, but 9253 is included in the packet's IP length field. Any 9254 trailing pad or length fields beyond the digest are 9255 not counted or transmitted. 9257 D.5 Message verification 9259 When an OSPF packet has been received on an interface, it must 9260 be authenticated. The authentication procedure is indicated by 9261 the setting of Autype in the standard OSPF packet header, which 9262 matches the setting of Autype for the receiving OSPF interface. 9264 If an OSPF protocol packet is accepted as authentic, processing 9265 of the packet continues as specified in Section 8.2. Packets 9266 which fail authentication are discarded. 9268 D.5.1 Verifying Null authentication 9270 When using Null authentication, the checksum field in the 9271 OSPF header must be verified. It must be set to the 16-bit 9272 one's complement of the one's complement sum of all the 16- 9273 bit words in the packet, excepting the authentication field. 9274 (If the packet's length is not an integral number of 16-bit 9275 words, the packet is padded with a byte of zero before 9276 checksumming.) 9278 D.5.2 Verifying Simple password authentication 9280 When using Simple password authentication, the received OSPF 9281 packet is authenticated as follows: 9283 (1) The checksum field in the OSPF header must be verified. 9284 It must be set to the 16-bit one's complement of the 9285 one's complement sum of all the 16-bit words in the 9286 packet, excepting the authentication field. (If the 9287 packet's length is not an integral number of 16-bit 9288 words, the packet is padded with a byte of zero before 9289 checksumming.) 9291 (2) The 64-bit authentication field in the OSPF packet 9292 header must be equal to the 64-bit password (i.e., 9293 authentication key) that has been configured for the 9294 interface. 9296 D.5.3 Verifying Cryptographic authentication 9298 When using Cryptographic authentication, the received OSPF 9299 packet is authenticated as follows: 9301 (1) Locate the receiving interface's configured key having 9302 Key ID equal to that specified in the received OSPF 9303 packet (see Figure 18). If the key is not found, or if 9304 the key is not valid for reception (i.e., current time < 9305 KeyStartAccept or current time >= KeyStopAccept), the 9306 OSPF packet is discarded. 9308 (2) If the cryptographic sequence number found in the OSPF 9309 header (see Figure 18) is less than the cryptographic 9310 sequence number recorded in the sending neighbor's data 9311 structure, the OSPF packet is discarded. 9313 (3) Verify the appended message digest in the following 9314 steps: 9316 (a) The received digest is set aside. 9318 (b) A new digest is calculated, as specified in Step 6 9319 of Section D.4.3. 9321 (c) The calculated and received digests are compared. If 9322 they do not match, the OSPF packet is discarded. If 9323 they do match, the OSPF protocol packet is accepted 9324 as authentic, and the "cryptographic sequence 9325 number" in the neighbor's data structure is set to 9326 the sequence number found in the packet's OSPF 9327 header. 9329 E. An algorithm for assigning Link State IDs 9331 The Link State ID in AS-external-LSAs and summary-LSAs is usually 9332 set to the described network's IP address. However, if necessary one 9333 or more of the network's host bits may be set in the Link State ID. 9334 This allows the router to originate separate LSAs for networks 9335 having the same address, yet different masks. Such networks can 9336 occur in the presence of supernetting and subnet 0s (see [Ref10]). 9338 This appendix gives one possible algorithm for setting the host bits 9339 in Link State IDs. The choice of such an algorithm is a local 9340 decision. Separate routers are free to use different algorithms, 9341 since the only LSAs affected are the ones that the router itself 9342 originates. The only requirement on the algorithms used is that the 9343 network's IP address should be used as the Link State ID whenever 9344 possible; this maximizes interoperability with OSPF implementations 9345 predating RFC 1583. 9347 The algorithm below is stated for AS-external-LSAs. This is only 9348 for clarity; the exact same algorithm can be used for summary-LSAs. 9349 Suppose that the router wishes to originate an AS-external-LSA for a 9350 network having address NA and mask NM1. The following steps are then 9351 used to determine the LSA's Link State ID: 9353 (1) Determine whether the router is already originating an AS- 9354 external-LSA with Link State ID equal to NA (in such an LSA the 9355 router itself will be listed as the LSA's Advertising Router). 9356 If not, the Link State ID is set equal to NA and the algorithm 9357 terminates. Otherwise, 9359 (2) Obtain the network mask from the body of the already existing 9360 AS-external-LSA. Call this mask NM2. There are then two cases: 9362 o NM1 is longer (i.e., more specific) than NM2. In this case, 9363 set the Link State ID in the new LSA to be the network 9364 [NA,NM1] with all the host bits set (i.e., equal to NA or'ed 9365 together with all the bits that are not set in NM1, which is 9366 network [NA,NM1]'s broadcast address). 9368 o NM2 is longer than NM1. In this case, change the existing 9369 LSA (having Link State ID of NA) to reference the new 9370 network [NA,NM1] by incrementing the sequence number, 9371 changing the mask in the body to NM1 and inserting the cost 9372 of the new network. Then originate a new LSA for the old 9373 network [NA,NM2], with Link State ID equal to NA or'ed 9374 together with the bits that are not set in NM2 (i.e., 9375 network [NA,NM2]'s broadcast address). 9377 The above algorithm assumes that all masks are contiguous; this 9378 ensures that when two networks have the same address, one mask is 9379 more specific than the other. The algorithm also assumes that no 9380 network exists having an address equal to another network's 9381 broadcast address. Given these two assumptions, the above algorithm 9382 always produces unique Link State IDs. The above algorithm can also 9383 be reworded as follows: When originating an AS-external-LSA, try to 9384 use the network number as the Link State ID. If that produces a 9385 conflict, examine the two networks in conflict. One will be a subset 9386 of the other. For the less specific network, use the network number 9387 as the Link State ID and for the more specific use the network's 9388 broadcast address instead (i.e., flip all the "host" bits to 1). If 9389 the most specific network was originated first, this will cause you 9390 to originate two LSAs at once. 9392 As an example of the algorithm, consider its operation when the 9393 following sequence of events occurs in a single router (Router A). 9395 (1) Router A wants to originate an AS-external-LSA for 9396 [10.0.0.0,255.255.255.0]: 9398 (a) A Link State ID of 10.0.0.0 is used. 9400 (2) Router A then wants to originate an AS-external-LSA for 9401 [10.0.0.0,255.255.0.0]: 9403 (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a 9404 new Link State ID of 10.0.0.255. 9406 (b) A Link State ID of 10.0.0.0 is used for 9407 [10.0.0.0,255.255.0.0]. 9409 (3) Router A then wants to originate an AS-external-LSA for 9410 [10.0.0.0,255.0.0.0]: 9412 (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a 9413 new Link State ID of 10.0.255.255. 9415 (b) A Link State ID of 10.0.0.0 is used for 9416 [10.0.0.0,255.0.0.0]. 9418 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID 9419 of 10.0.0.255. 9421 F. Multiple interfaces to the same network/subnet 9423 There are at least two ways to support multiple physical interfaces 9424 to the same IP subnet. Both methods will interoperate with 9425 implementations of RFC 1583 (and of course this memo). The two 9426 methods are sketched briefly below. An assumption has been made that 9427 each interface has been assigned a separate IP address (otherwise, 9428 support for multiple interfaces is more of a link-level or ARP issue 9429 than an OSPF issue). 9431 Method 1: 9432 Run the entire OSPF functionality over both interfaces, sending 9433 and receiving hellos, flooding, supporting separate interface 9434 and neighbor FSMs for each interface, etc. When doing this all 9435 other routers on the subnet will treat the two interfaces as 9436 separate neighbors, since neighbors are identified (on broadcast 9437 and NBMA networks) by their IP address. 9439 Method 1 has the following disadvantages: 9441 (1) You increase the total number of neighbors and adjacencies. 9443 (2) You lose the bidirectionality test on both interfaces, since 9444 bidirectionality is based on Router ID. 9446 (3) You have to consider both interfaces together during the 9447 Designated Router election, since if you declare both to be 9448 DR simultaneously you can confuse the tie-breaker (which is 9449 Router ID). 9451 Method 2: 9452 Run OSPF over only one interface (call it the primary 9453 interface), but include both the primary and secondary 9454 interfaces in your Router-LSA. 9456 Method 2 has the following disadvantages: 9458 (1) You lose the bidirectionality test on the secondary 9459 interface. 9461 (2) When the primary interface fails, you need to promote the 9462 secondary interface to primary status. 9464 G. Differences from RFC 1583 9466 This section documents the differences between this memo and RFC 9467 1583. All differences are backward-compatible. Implementations of 9468 this memo and of RFC 1583 will interoperate. 9470 G.1 Enhancements to OSPF authentication 9472 An additional OSPF authentication type has been added: the 9473 Cryptographic authentication type. This has been defined so that 9474 any arbitrary "Keyed Message Digest" algorithm can be used for 9475 packet authentication. Operation using the MD5 algorithm is 9476 completely specified (see Appendix D). 9478 A number of other changes were also made to OSPF packet 9479 authentication, affecting the following Sections: 9481 o The authentication type is now specified per-interface, 9482 rather than per-area (Sections 6, 9, C.2 and C.3). 9484 o The OSPF packet header checksum is now considered part of 9485 the authentication procedure, and so has been moved out of 9486 the packet send and receive logic (Sections 8.1 and 8.2) and 9487 into the description of authentication types (Appendix D). 9489 o In Appendix D, sections detailing message generation and 9490 message verification have been added. 9492 o For the OSPF Cryptographic authentication type, a discussion 9493 of key management, including the requirement for 9494 simultaneous support of multiple keys, key lifetimes and 9495 smooth key transition, has been added to Appendix D. 9497 G.2 Addition of Point-to-MultiPoint interface 9499 This memo adds an additional method for running OSPF over non- 9500 broadcast networks: the Point-to-Multipoint network. To 9501 implement this addition, the language of RFC 1583 has been 9502 altered slightly. References to "multi-access" networks have 9503 been deleted. The term "non-broadcast networks" is now used to 9504 describe networks which can connect many routers, but which do 9505 not natively support broadcast/multicast (such as a public Frame 9506 relay network). Over non-broadcast networks, there are two 9507 options for running OSPF: modelling them as "NBMA networks" or 9508 as "Point-to-MultiPoint networks". NBMA networks require full 9509 mesh connectivity between routers; when employing NBMA networks 9510 in the presence of partial mesh connectivity, multiple NBMA 9511 networks must be configured, as described in [Ref15]. In 9512 contrast, Point-to-Multipoint networks have been designed to 9513 work simply and naturally when faced with partial mesh 9514 connectivity. 9516 The addition of Point-to-MultiPoint networks has impacted the 9517 text in many places, which are briefly summarized below: 9519 o Section 2 describing the OSPF link-state database has been 9520 split into additional subsections, with one of the 9521 subsections (Section 2.1.1) describing the differing map 9522 representations of the two non-broadcast network options. 9523 This subsection also contrasts the NBMA network and Point- 9524 to-MultiPoint network options, and describes the situations 9525 when one is preferable to the other. 9527 o In contrast to NBMA networks, Point-to-MultiPoint networks 9528 have the following properties. Adjacencies are established 9529 between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 9530 and 10.4). There is no Designated Router or Backup 9531 Designated Router for a Point-to-MultiPoint network 9532 (Sections 7.3 and 7.4). No network-LSA is originated for 9533 Point-to-MultiPoint networks (Sections 12.4.2 and A.4.3). 9534 Router Priority is not configured for Point-to-MultiPoint 9535 interfaces, nor for neighbors on Point-to-MultiPoint 9536 networks (Sections C.3 and C.6). 9538 o The Interface FSM for a Point-to-MultiPoint interface is 9539 identical to that used for point-to-point interfaces. Two 9540 states are possible: "Down" and "Point-to-Point" (Section 9541 9.3). 9543 o When originating a router-LSA, and Point-to-MultiPoint 9544 interface is reported as a collection of "point-to-point 9545 links" to all of the interface's adjacent neighbors, 9546 together with a single stub link advertising the interface's 9547 IP address with a cost of 0 (Section 12.4.1.4). 9549 o When flooding out a non-broadcast interface (when either in 9550 NBMA or Point-to-MultiPoint mode) the Link State Update or 9551 Link State Acknowledgment packet must be replicated in order 9552 to be sent to each of the interface's neighbors (see 9553 Sections 13.3 and 13.5). 9555 G.3 Support for overlapping area ranges 9557 RFC 1583 requires that all networks falling into a given area 9558 range actually belong to a single area. This memo relaxes that 9559 restriction. This is useful in the following example. Suppose 9560 that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of 9561 these subnets are assigned to a single OSPF area (call it Area 9562 X), while a few subnets are assigned to other areas. In order to 9563 get this configuration to work with RFC 1583, you must not 9564 summarize the subnets of Area X with the single range [10.0.0.0, 9565 255.0.0.0], because then the subnets of 10.0.0.0 belonging to 9566 other areas would become unreachable. However, with this memo 9567 you can summarize the subnets in Area X, provided that the 9568 subnets belonging to other areas are not summarized. 9570 Implementation details for this change can be found in Sections 9571 11.1 and 16.2. 9573 G.4 A modification to the flooding algorithm 9575 The OSPF flooding algorithm has been modified as follows. When a 9576 Link State Update Packet is received that contains an LSA 9577 instance which is actually less recent than the the router's 9578 current database copy, the router will now in most cases respond 9579 by flooding back its database copy. This is in contrast to the 9580 RFC 1583 behavior, which was to simply throw the received LSA 9581 away. 9583 Detailed description of the change can be found in Step 8 of 9584 Section 13. 9586 This change improves MaxAge processing. There are times when 9587 MaxAge LSAs stay in a router's database for extended intervals: 9588 1) when they are stuck in a retransmission queue on a slow link 9589 or 2) when a router is not properly flushing them from its 9590 database, due to software bugs. The prolonged existence of these 9591 MaxAge LSAs can inhibit the flooding of new instances of the 9592 LSA. New instances typically start with LS sequence number equal 9593 to InitialSequenceNumber, and are treated as less recent (and 9594 hence were discarded according to RFC 1583) by routers still 9595 holding MaxAge instances. However, with the above change to 9596 flooding, a router holding a MaxAge instance will flood back the 9597 MaxAge instance. When this flood reaches the LSA's originator, 9598 it will then pick the next highest LS sequence number and 9599 reflood, overwriting the MaxAge instance. 9601 G.5 Introduction of the MinLSArrival constant 9603 OSPF limits the frequency that new instances of any particular 9604 LSA can be accepted during flooding. This is extra protection, 9605 just in case a neighboring router is violating the mandated 9606 limit on LSA (re)originations (namely, one per LSA in any 9607 MinLSInterval). 9609 In RFC 1583, the frequency at which new LSA instances were 9610 accepted was also set equal to once every MinLSInterval seconds. 9611 However, in some circumstances this led to unwanted link state 9612 retransmissions, even when the LSA originator was obeying the 9613 MinLSInterval limit on originations. This was due to either 1) 9614 choice of clock granularity in some OSPF implementations or 2) 9615 differing clock speed in neighboring routers. 9617 To alleviate this problem, the frequency at which new LSA 9618 instances are accepted during flooding has now been increased to 9619 once every MinLSArrival seconds, whose value is set to 1. This 9620 change is reflected in Steps 5a and 5d of Section 13, and in 9621 Appendix B. 9623 G.6 Optionally advertising point-to-point links as subnets 9625 When describing a point-to-point interface in its router-LSA, a 9626 router may now advertise a stub link to the point-to-point 9627 network's subnet. This is specified as an alternative to the RFC 9628 1583 behavior, which is to advertise a stub link to the 9629 neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for 9630 details. 9632 G.7 Advertising same external route from multiple areas 9634 This document fixes routing loops which can occur in RFC 1583 9635 when the same external destination is advertised by AS boundary 9636 routers in separate areas. There are two manifestations of this 9637 problem. The first, discovered by Dennis Ferguson, occurs when 9638 an aggregated forwarding address is in use. In this case, the 9639 desirability of the forwarding address can change for the worse 9640 as a packet crosses an area aggregation boundary on the way to 9641 the forwarding address, which in turn can cause the preference 9642 of AS-external-LSAs to change, resulting in a routing loop. 9644 The second manifestation was discovered by Richard Woundy. It is 9645 caused by an incomplete application of OSPF's preference of 9646 intra-area routes over inter-area routes: paths to any given 9647 ASBR/forwarding address are selected first based on intra-area 9648 preference, while the comparison between separate 9649 ASBRs/forwarding addresses is driven only by cost, ignoring 9650 intra-area preference. His example is replicated in Figure 19. 9651 Both router A3 and router B3 are originating an AS-external-LSA 9652 for 10.0.0.0/8, with the same type 2 metric. Router A1 selects 9653 B1 as its next hop towards 10.0.0.0/8, based on shorter cost to 9654 ASBR B3 (via B1->B2->B3). However, the shorter route to B3 is 9655 not available to B1, due to B1's preference for the (higher 9656 cost) intra-area route to B3 through Area A. This leads B1 to 9657 select A1 as its next hop to 10.0.0.0/8, resulting in a routing 9658 loop. 9660 The following two changes have been made to prevent these 9661 routing loops: 9663 o When originating a type 3 summary-LSA for a configured area 9664 address range, the cost of the summary-LSA is now set to the 9665 maximum cost of the range's component networks (instead of 9666 the previous algorithm which set the cost to the minimum 9667 component cost). This change affects Sections 3.5 and 9668 12.4.3, Figures 7 and 8, and Tables 6 and 13. 9670 o The preference rules for choosing among multiple AS- 9671 external-LSAs have been changed. Where previously cost was 9672 the only determining factor, now the preference is driven 9673 first by type of path (intra-area or inter-area, through 9674 non-backbone area or through backbone) to the 9675 ASBR/forwarding address, using cost only to break ties. This 9676 change affects Sections 16.4 and 16.4.1. 9678 After implementing this change, the example in Figure 19 is 9679 modified as follows. Router A1 now chooses A3 as the next 9681 10.0.0.0/8 9682 ---------- 9683 | 9684 +----+ 9685 | XX | 9686 +----+ 9687 RIP / \ RIP 9688 --------------------- -------------------- 9689 ! ! 9690 ! ! 9691 +----+ +----+ 1 +----+......+----+.... 9692 | A3 |------| A1 |---------------| B1 |------| B3 | . 9693 +----+ 6 +----+ +----+ 8 +----+ . 9694 1| . / . 9695 OSPF backbone | . / . 9696 +----+ 2 / . 9697 | B2 |------- Area A. 9698 +----+................ 9700 Figure 19: Example routing loop when the 9701 same external route is advertised from multiple 9702 areas 9703 hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The 9704 reason for both choices is that ASBRs/forwarding addresses 9705 are now chosen based first on intra-area preference, and 9706 then by cost. 9708 Unfortunately, this change is not backward compatible. While 9709 the change prevents routing loops when all routers run the 9710 new preference rules, it can actually create routing loops 9711 when some routers are running the new preference rules and 9712 other routers implement RFC 1583. For this reason, a new 9713 configuration parameter has been added: 9714 RFC1583Compatibility. Only when RFC1583Compatibility is set 9715 to "disabled" will the new preference rules take effect. See 9716 Appendix C for more details. 9718 G.8 Retransmission of initial Database Description packets 9720 This memo allows retransmission of initial Database Description 9721 packets, without resetting the state of the adjacency. In some 9722 environments, retransmission of the initial Database Description 9723 packet may be unavoidable. For example, the link delay incurred 9724 by a satellite link may exceed the value configured for an 9725 interface's RxmtInterval. In RFC 1583 such an environment 9726 prevents a full adjacency from ever forming. 9728 In this memo, changes have been made in the reception of 9729 Database Description packets so that retransmitted initial 9730 Database Description packets are treated identically to any 9731 other retransmitted Database Description packets. See Section 9732 10.6 for details. 9734 G.9 Detecting interface MTU mismatches 9736 When two neighboring routers have a different interface MTU for 9737 their common network segment, serious problems can ensue: large 9738 packets are prevented from being successfully transferred from 9739 one router to the other, impairing OSPF's flooding algorithm and 9740 possibly creating "black holes" for user data traffic. 9742 This memo provides a fix for the interface MTU mismatch problem 9743 by advertising the interface MTU in Database Description 9744 packets. When a router receives a Database description packet 9745 advertising an MTU larger than the router can receive, the 9746 router drops the Database Description packet. This prevents an 9747 adjacency from forming, telling OSPF flooding and user data 9748 traffic to avoid the connection between the two routers. For 9749 more information, see Sections 10.6, 10.8, and A.3.3. 9751 Security Considerations 9753 All OSPF protocol exchanges are authenticated. OSPF supports 9754 multiple types of authentication; the type of authentication in use 9755 can be configured on a per network segment basis. One of OSPF's 9756 authentication types, namely the Cryptographic authentication 9757 option, is believed to be secure against passive attacks and provide 9758 significant protection against active attacks. When using the 9759 Cryptographic authentication option, each router appends a "message 9760 digest" to its transmitted OSPF packets. Receivers then use the 9761 shared secret key and received digest to verify that each received 9762 OSPF packet is authentic. 9764 The quality of the security provided by the Cryptographic 9765 authentication option depends completely on the strength of the 9766 message digest algorithm (MD5 is currently the only message digest 9767 algorithm specified), the strength of the key being used, and the 9768 correct implementation of the security mechanism in all 9769 communicating OSPF implementations. It also requires that all 9770 parties maintain the secrecy of the shared secret key. 9772 None of the OSPF authentication types provide confidentiality. Nor 9773 do they protect against traffic analysis. Key management is also not 9774 addressed by this memo. 9776 For more information, see Sections 8.1, 8.2, and Appendix D. 9778 Author's Address 9780 John Moy 9781 Cascade Communications Corp. 9782 5 Carlisle Road 9783 Westford, MA 01886 9785 Phone: 508-952-1367 9786 Fax: 508-692-9214 9787 Email: jmoy@casc.com 9789 This document expires in August 1997.