idnits 2.17.1 draft-ietf-ospf-vers2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7198 instances of lines with control characters in the document. == There are 45 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 1336 has weird spacing: '... dist from ...' == Line 1631 has weird spacing: '... Packet name ...' == Line 1633 has weird spacing: '...aintain neigh...' == Line 1664 has weird spacing: '... type name...' == Line 2369 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 (November 1997) is 9658 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 1513 -- Looks like a reference, but probably isn't: '2' on line 2338 -- Looks like a reference, but probably isn't: '3' on line 2369 -- Looks like a reference, but probably isn't: '4' on line 2678 -- Looks like a reference, but probably isn't: '5' on line 2981 -- Looks like a reference, but probably isn't: '6' on line 3035 -- Looks like a reference, but probably isn't: '7' on line 3911 -- Looks like a reference, but probably isn't: '8' on line 3981 -- Looks like a reference, but probably isn't: '9' on line 4250 -- Looks like a reference, but probably isn't: '10' on line 4364 -- Looks like a reference, but probably isn't: '11' on line 4394 -- Looks like a reference, but probably isn't: '12' on line 4598 -- Looks like a reference, but probably isn't: '13' on line 4779 -- Looks like a reference, but probably isn't: '14' on line 4803 -- Looks like a reference, but probably isn't: '15' on line 5138 -- Looks like a reference, but probably isn't: '16' on line 5145 -- Looks like a reference, but probably isn't: '17' on line 5363 -- Looks like a reference, but probably isn't: '18' on line 5367 -- Looks like a reference, but probably isn't: '19' on line 5849 -- Looks like a reference, but probably isn't: '20' on line 5932 -- Looks like a reference, but probably isn't: '21' on line 6189 -- Looks like a reference, but probably isn't: '22' on line 6396 -- Looks like a reference, but probably isn't: '23' on line 6486 -- Looks like a reference, but probably isn't: '24' on line 6909 == Missing Reference: 'NA' is mentioned on line 9089, but not defined == Missing Reference: 'NM1' is mentioned on line 9086, but not defined == Missing Reference: 'NM2' is mentioned on line 9089, but not defined == Unused Reference: 'Ref19' is defined on line 7461, but no explicit reference was found in the text == Unused Reference: 'Ref24' is defined on line 7338, but no explicit reference was found in the text == Unused Reference: 'Ref25' is defined on line 7341, but no explicit reference was found in the text == Unused Reference: 'Ref26' is defined on line 9200, but no explicit reference was found in the text == Unused Reference: 'NA,NM1' is defined on line 9080, 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. 'Ref24' ** Obsolete normative reference: RFC 2178 (ref. 'Ref25') (Obsoleted by RFC 2328) -- Duplicate reference: RFC2178, mentioned in 'Ref26', was also mentioned in 'Ref25'. ** Obsolete normative reference: RFC 2178 (ref. 'Ref26') (Obsoleted by RFC 2328) -- Possible downref: Non-RFC (?) normative reference: ref. 'NA,NM1' Summary: 19 errors (**), 0 flaws (~~), 17 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 Ascend Communications, Inc. 4 Expiration Date: May 1998 November 1997 5 File name: draft-ietf-ospf-vers2-00.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. An area routing capability is 39 provided, enabling an additional level of routing protection and a 40 reduction in routing protocol traffic. In addition, all OSPF 41 routing protocol exchanges are authenticated. 43 The differences between this memo and RFC 2178 are explained in 44 Appendix G. All differences are backward-compatible in nature. 45 Implementations of this memo and of RFCs 2178, 1583, and 1247 will 46 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 3 Splitting the AS into Areas ........................... 25 66 3.1 The backbone of the Autonomous System ................. 25 67 3.2 Inter-area routing .................................... 26 68 3.3 Classification of routers ............................. 26 69 3.4 A sample area configuration ........................... 27 70 3.5 IP subnetting support ................................. 33 71 3.6 Supporting stub areas ................................. 34 72 3.7 Partitions of areas ................................... 35 73 4 Functional Summary .................................... 37 74 4.1 Inter-area routing .................................... 37 75 4.2 AS external routes .................................... 38 76 4.3 Routing protocol packets .............................. 38 77 4.4 Basic implementation requirements ..................... 41 78 4.5 Optional OSPF capabilities ............................ 42 79 5 Protocol data structures .............................. 43 80 6 The Area Data Structure ............................... 46 81 7 Bringing Up Adjacencies ............................... 47 82 7.1 The Hello Protocol .................................... 48 83 7.2 The Synchronization of Databases ...................... 48 84 7.3 The Designated Router ................................. 49 85 7.4 The Backup Designated Router .......................... 51 86 7.5 The graph of adjacencies .............................. 51 87 8 Protocol Packet Processing ............................ 53 88 8.1 Sending protocol packets .............................. 53 89 8.2 Receiving protocol packets ............................ 55 90 9 The Interface Data Structure .......................... 57 91 9.1 Interface states ...................................... 60 92 9.2 Events causing interface state changes ................ 63 93 9.3 The Interface state machine ........................... 65 94 9.4 Electing the Designated Router ........................ 67 95 9.5 Sending Hello packets ................................. 70 96 9.5.1 Sending Hello packets on NBMA networks ................ 71 97 10 The Neighbor Data Structure ........................... 72 98 10.1 Neighbor states ....................................... 74 99 10.2 Events causing neighbor state changes ................. 78 100 10.3 The Neighbor state machine ............................ 80 101 10.4 Whether to become adjacent ............................ 85 102 10.5 Receiving Hello Packets ............................... 86 103 10.6 Receiving Database Description Packets ................ 88 104 10.7 Receiving Link State Request Packets .................. 92 105 10.8 Sending Database Description Packets .................. 92 106 10.9 Sending Link State Request Packets .................... 93 107 10.10 An Example ............................................ 94 108 11 The Routing Table Structure ........................... 96 109 11.1 Routing table lookup .................................. 99 110 11.2 Sample routing table, without areas .................. 100 111 11.3 Sample routing table, with areas ..................... 100 112 12 Link State Advertisements (LSAs) ..................... 102 113 12.1 The LSA Header ....................................... 104 114 12.1.1 LS age ............................................... 104 115 12.1.2 Options .............................................. 105 116 12.1.3 LS type .............................................. 105 117 12.1.4 Link State ID ........................................ 106 118 12.1.5 Advertising Router ................................... 107 119 12.1.6 LS sequence number ................................... 108 120 12.1.7 LS checksum .......................................... 108 121 12.2 The link state database .............................. 109 122 12.3 Representation of TOS ................................ 110 123 12.4 Originating LSAs ..................................... 111 124 12.4.1 Router-LSAs .......................................... 114 125 12.4.1.1 Describing point-to-point interfaces ................. 117 126 12.4.1.2 Describing broadcast and NBMA interfaces ............. 118 127 12.4.1.3 Describing virtual links ............................. 118 128 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 119 129 12.4.1.5 Examples of router-LSAs .............................. 119 130 12.4.2 Network-LSAs ......................................... 120 131 12.4.2.1 Examples of network-LSAs ............................. 121 132 12.4.3 Summary-LSAs ......................................... 122 133 12.4.3.1 Originating summary-LSAs into stub areas ............. 124 134 12.4.3.2 Examples of summary-LSAs ............................. 125 135 12.4.4 AS-external-LSAs ..................................... 125 136 12.4.4.1 Examples of AS-external-LSAs ......................... 126 137 13 The Flooding Procedure ............................... 128 138 13.1 Determining which LSA is newer ....................... 131 139 13.2 Installing LSAs in the database ...................... 132 140 13.3 Next step in the flooding procedure .................. 133 141 13.4 Receiving self-originated LSAs ....................... 136 142 13.5 Sending Link State Acknowledgment packets ............ 136 143 13.6 Retransmitting LSAs .................................. 139 144 13.7 Receiving link state acknowledgments ................. 139 145 14 Aging The Link State Database ........................ 140 146 14.1 Premature aging of LSAs .............................. 141 147 15 Virtual Links ........................................ 141 148 16 Calculation of the routing table ..................... 143 149 16.1 Calculating the shortest-path tree for an area ....... 145 150 16.1.1 The next hop calculation ............................. 150 151 16.2 Calculating the inter-area routes .................... 151 152 16.3 Examining transit areas' summary-LSAs ................ 152 153 16.4 Calculating AS external routes ....................... 155 154 16.4.1 External path preferences ............................ 157 155 16.5 Incremental updates -- summary-LSAs .................. 157 156 16.6 Incremental updates -- AS-external-LSAs .............. 158 157 16.7 Events generated as a result of routing table changes 159 158 16.8 Equal-cost multipath ................................. 160 159 Footnotes ............................................ 161 160 References ........................................... 164 161 A OSPF data formats .................................... 166 162 A.1 Encapsulation of OSPF packets ........................ 166 163 A.2 The Options field .................................... 168 164 A.3 OSPF Packet Formats .................................. 170 165 A.3.1 The OSPF packet header ............................... 171 166 A.3.2 The Hello packet ..................................... 173 167 A.3.3 The Database Description packet ...................... 175 168 A.3.4 The Link State Request packet ........................ 177 169 A.3.5 The Link State Update packet ......................... 179 170 A.3.6 The Link State Acknowledgment packet ................. 181 171 A.4 LSA formats .......................................... 183 172 A.4.1 The LSA header ....................................... 184 173 A.4.2 Router-LSAs .......................................... 186 174 A.4.3 Network-LSAs ......................................... 189 175 A.4.4 Summary-LSAs ......................................... 190 176 A.4.5 AS-external-LSAs ..................................... 192 177 B Architectural Constants .............................. 194 178 C Configurable Constants ............................... 196 179 C.1 Global parameters .................................... 196 180 C.2 Area parameters ...................................... 197 181 C.3 Router interface parameters .......................... 198 182 C.4 Virtual link parameters .............................. 200 183 C.5 NBMA network parameters .............................. 201 184 C.6 Point-to-MultiPoint network parameters ............... 201 185 C.7 Host route parameters ................................ 202 186 D Authentication ....................................... 203 187 D.1 Null authentication .................................. 203 188 D.2 Simple password authentication ....................... 203 189 D.3 Cryptographic authentication ......................... 204 190 D.4 Message generation ................................... 206 191 D.4.1 Generating Null authentication ....................... 207 192 D.4.2 Generating Simple password authentication ............ 207 193 D.4.3 Generating Cryptographic authentication .............. 207 194 D.5 Message verification ................................. 209 195 D.5.1 Verifying Null authentication ........................ 209 196 D.5.2 Verifying Simple password authentication ............. 209 197 D.5.3 Verifying Cryptographic authentication ............... 209 198 E An algorithm for assigning Link State IDs ............ 211 199 F Multiple interfaces to the same network/subnet ....... 213 200 G Differences from RFC 2178 ............................ 214 201 G.1 Flooding modifications ............................... 214 202 Security Considerations .............................. 215 203 Author's Address ..................................... 215 204 1. Introduction 206 This document is a specification of the Open Shortest Path First 207 (OSPF) TCP/IP internet routing protocol. OSPF is classified as an 208 Interior Gateway Protocol (IGP). This means that it distributes 209 routing information between routers belonging to a single Autonomous 210 System. The OSPF protocol is based on link-state or SPF technology. 211 This is a departure from the Bellman-Ford base used by traditional 212 TCP/IP internet routing protocols. 214 The OSPF protocol was developed by the OSPF working group of the 215 Internet Engineering Task Force. It has been designed expressly for 216 the TCP/IP internet environment, including explicit support for CIDR 217 and the tagging of externally-derived routing information. OSPF 218 also provides for the authentication of routing updates, and 219 utilizes IP multicast when sending/receiving the updates. In 220 addition, much work has been done to produce a protocol that 221 responds quickly to topology changes, yet involves small amounts of 222 routing protocol traffic. 224 1.1. Protocol overview 226 OSPF routes IP packets based solely on the destination IP 227 address found in the IP packet header. IP packets are routed 228 "as is" -- they are not encapsulated in any further protocol 229 headers as they transit the Autonomous System. OSPF is a 230 dynamic routing protocol. It quickly detects topological 231 changes in the AS (such as router interface failures) and 232 calculates new loop-free routes after a period of convergence. 233 This period of convergence is short and involves a minimum of 234 routing traffic. 236 In a link-state routing protocol, each router maintains a 237 database describing the Autonomous System's topology. This 238 database is referred to as the link-state database. Each 239 participating router has an identical database. Each individual 240 piece of this database is a particular router's local state 241 (e.g., the router's usable interfaces and reachable neighbors). 242 The router distributes its local state throughout the Autonomous 243 System by flooding. 245 All routers run the exact same algorithm, in parallel. From the 246 link-state database, each router constructs a tree of shortest 247 paths with itself as root. This shortest-path tree gives the 248 route to each destination in the Autonomous System. Externally 249 derived routing information appears on the tree as leaves. 251 When several equal-cost routes to a destination exist, traffic 252 is distributed equally among them. The cost of a route is 253 described by a single dimensionless metric. 255 OSPF allows sets of networks to be grouped together. Such a 256 grouping is called an area. The topology of an area is hidden 257 from the rest of the Autonomous System. This information hiding 258 enables a significant reduction in routing traffic. Also, 259 routing within the area is determined only by the area's own 260 topology, lending the area protection from bad routing data. An 261 area is a generalization of an IP subnetted network. 263 OSPF enables the flexible configuration of IP subnets. Each 264 route distributed by OSPF has a destination and mask. Two 265 different subnets of the same IP network number may have 266 different sizes (i.e., different masks). This is commonly 267 referred to as variable length subnetting. A packet is routed 268 to the best (i.e., longest or most specific) match. Host routes 269 are considered to be subnets whose masks are "all ones" 270 (0xffffffff). 272 All OSPF protocol exchanges are authenticated. This means that 273 only trusted routers can participate in the Autonomous System's 274 routing. A variety of authentication schemes can be used; in 275 fact, separate authentication schemes can be configured for each 276 IP subnet. 278 Externally derived routing data (e.g., routes learned from an 279 Exterior Gateway Protocol such as BGP; see [Ref23]) is 280 advertised throughout the Autonomous System. This externally 281 derived data is kept separate from the OSPF protocol's link 282 state data. Each external route can also be tagged by the 283 advertising router, enabling the passing of additional 284 information between routers on the boundary of the Autonomous 285 System. 287 1.2. Definitions of commonly used terms 289 This section provides definitions for terms that have a specific 290 meaning to the OSPF protocol and that are used throughout the 291 text. The reader unfamiliar with the Internet Protocol Suite is 292 referred to [Ref13] for an introduction to IP. 294 Router 295 A level three Internet Protocol packet switch. Formerly 296 called a gateway in much of the IP literature. 298 Autonomous System 299 A group of routers exchanging routing information via a 300 common routing protocol. Abbreviated as AS. 302 Interior Gateway Protocol 303 The routing protocol spoken by the routers belonging to an 304 Autonomous system. Abbreviated as IGP. Each Autonomous 305 System has a single IGP. Separate Autonomous Systems may be 306 running different IGPs. 308 Router ID 309 A 32-bit number assigned to each router running the OSPF 310 protocol. This number uniquely identifies the router within 311 an Autonomous System. 313 Network 314 In this memo, an IP network/subnet/supernet. It is possible 315 for one physical network to be assigned multiple IP 316 network/subnet numbers. We consider these to be separate 317 networks. Point-to-point physical networks are an exception 318 - they are considered a single network no matter how many 319 (if any at all) IP network/subnet numbers are assigned to 320 them. 322 Network mask 323 A 32-bit number indicating the range of IP addresses 324 residing on a single IP network/subnet/supernet. This 325 specification displays network masks as hexadecimal numbers. 326 For example, the network mask for a class C IP network is 327 displayed as 0xffffff00. Such a mask is often displayed 328 elsewhere in the literature as 255.255.255.0. 330 Point-to-point networks 331 A network that joins a single pair of routers. A 56Kb 332 serial line is an example of a point-to-point network. 334 Broadcast networks 335 Networks supporting many (more than two) attached routers, 336 together with the capability to address a single physical 337 message to all of the attached routers (broadcast). 338 Neighboring routers are discovered dynamically on these nets 339 using OSPF's Hello Protocol. The Hello Protocol itself 340 takes advantage of the broadcast capability. The OSPF 341 protocol makes further use of multicast capabilities, if 342 they exist. Each pair of routers on a broadcast network is 343 assumed to be able to communicate directly. An ethernet is 344 an example of a broadcast network. 346 Non-broadcast networks 347 Networks supporting many (more than two) routers, but having 348 no broadcast capability. Neighboring routers are maintained 349 on these nets using OSPF's Hello Protocol. However, due to 350 the lack of broadcast capability, some configuration 351 information may be necessary to aid in the discovery of 352 neighbors. On non-broadcast networks, OSPF protocol packets 353 that are normally multicast need to be sent to each 354 neighboring router, in turn. An X.25 Public Data Network 355 (PDN) is an example of a non-broadcast network. 357 OSPF runs in one of two modes over non-broadcast networks. 358 The first mode, called non-broadcast multi-access or NBMA, 359 simulates the operation of OSPF on a broadcast network. The 360 second mode, called Point-to-MultiPoint, treats the non- 361 broadcast network as a collection of point-to-point links. 362 Non-broadcast networks are referred to as NBMA networks or 363 Point-to-MultiPoint networks, depending on OSPF's mode of 364 operation over the network. 366 Interface 367 The connection between a router and one of its attached 368 networks. An interface has state information associated 369 with it, which is obtained from the underlying lower level 370 protocols and the routing protocol itself. An interface to 371 a network has associated with it a single IP address and 372 mask (unless the network is an unnumbered point-to-point 373 network). An interface is sometimes also referred to as a 374 link. 376 Neighboring routers 377 Two routers that have interfaces to a common network. 378 Neighbor relationships are maintained by, and usually 379 dynamically discovered by, OSPF's Hello Protocol. 381 Adjacency 382 A relationship formed between selected neighboring routers 383 for the purpose of exchanging routing information. Not 384 every pair of neighboring routers become adjacent. 386 Link state advertisement 387 Unit of data describing the local state of a router or 388 network. For a router, this includes the state of the 389 router's interfaces and adjacencies. Each link state 390 advertisement is flooded throughout the routing domain. The 391 collected link state advertisements of all routers and 392 networks forms the protocol's link state database. 393 Throughout this memo, link state advertisement is 394 abbreviated as LSA. 396 Hello Protocol 397 The part of the OSPF protocol used to establish and maintain 398 neighbor relationships. On broadcast networks the Hello 399 Protocol can also dynamically discover neighboring routers. 401 Flooding 402 The part of the OSPF protocol that distributes and 403 synchronizes the link-state database between OSPF routers. 405 Designated Router 406 Each broadcast and NBMA network that has at least two 407 attached routers has a Designated Router. The Designated 408 Router generates an LSA for the network and has other 409 special responsibilities in the running of the protocol. 410 The Designated Router is elected by the Hello Protocol. 412 The Designated Router concept enables a reduction in the 413 number of adjacencies required on a broadcast or NBMA 414 network. This in turn reduces the amount of routing 415 protocol traffic and the size of the link-state database. 417 Lower-level protocols 418 The underlying network access protocols that provide 419 services to the Internet Protocol and in turn the OSPF 420 protocol. Examples of these are the X.25 packet and frame 421 levels for X.25 PDNs, and the ethernet data link layer for 422 ethernets. 424 1.3. Brief history of link-state routing technology 426 OSPF is a link state routing protocol. Such protocols are also 427 referred to in the literature as SPF-based or distributed- 428 database protocols. This section gives a brief description of 429 the developments in link-state technology that have influenced 430 the OSPF protocol. 432 The first link-state routing protocol was developed for use in 433 the ARPANET packet switching network. This protocol is 434 described in [Ref3]. It has formed the starting point for all 435 other link-state protocols. The homogeneous ARPANET 436 environment, i.e., single-vendor packet switches connected by 437 synchronous serial lines, simplified the design and 438 implementation of the original protocol. 440 Modifications to this protocol were proposed in [Ref4]. These 441 modifications dealt with increasing the fault tolerance of the 442 routing protocol through, among other things, adding a checksum 443 to the LSAs (thereby detecting database corruption). The paper 444 also included means for reducing the routing traffic overhead in 445 a link-state protocol. This was accomplished by introducing 446 mechanisms which enabled the interval between LSA originations 447 to be increased by an order of magnitude. 449 A link-state algorithm has also been proposed for use as an ISO 450 IS-IS routing protocol. This protocol is described in [Ref2]. 451 The protocol includes methods for data and routing traffic 452 reduction when operating over broadcast networks. This is 453 accomplished by election of a Designated Router for each 454 broadcast network, which then originates an LSA for the network. 456 The OSPF Working Group of the IETF has extended this work in 457 developing the OSPF protocol. The Designated Router concept has 458 been greatly enhanced to further reduce the amount of routing 459 traffic required. Multicast capabilities are utilized for 460 additional routing bandwidth reduction. An area routing scheme 461 has been developed enabling information 462 hiding/protection/reduction. Finally, the algorithms have been 463 tailored for efficient operation in TCP/IP internets. 465 1.4. Organization of this document 467 The first three sections of this specification give a general 468 overview of the protocol's capabilities and functions. Sections 469 4-16 explain the protocol's mechanisms in detail. Packet 470 formats, protocol constants and configuration items are 471 specified in the appendices. 473 Labels such as HelloInterval encountered in the text refer to 474 protocol constants. They may or may not be configurable. 475 Architectural constants are summarized in Appendix B. 476 Configurable constants are summarized in Appendix C. 478 The detailed specification of the protocol is presented in terms 479 of data structures. This is done in order to make the 480 explanation more precise. Implementations of the protocol are 481 required to support the functionality described, but need not 482 use the precise data structures that appear in this memo. 484 1.5. Acknowledgments 486 The author would like to thank Ran Atkinson, Fred Baker, Jeffrey 487 Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra 488 Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui 489 Zhang and the rest of the OSPF Working Group for the ideas and 490 support they have given to this project. 492 The OSPF Point-to-MultiPoint interface is based on work done by 493 Fred Baker. 495 The OSPF Cryptographic Authentication option was developed by 496 Fred Baker and Ran Atkinson. 498 2. The Link-state Database: organization and calculations 500 The following subsections describe the organization of OSPF's link- 501 state database, and the routing calculations that are performed on 502 the database in order to produce a router's routing table. 504 2.1. Representation of routers and networks 506 The Autonomous System's link-state database describes a directed 507 graph. The vertices of the graph consist of routers and 508 networks. A graph edge connects two routers when they are 509 attached via a physical point-to-point network. An edge 510 connecting a router to a network indicates that the router has 511 an interface on the network. Networks can be either transit or 512 stub networks. Transit networks are those capable of carrying 513 data traffic that is neither locally originated nor locally 514 destined. A transit network is represented by a graph vertex 515 having both incoming and outgoing edges. A stub network's vertex 516 has only incoming edges. 518 The neighborhood of each network node in the graph depends on 519 the network's type (point-to-point, broadcast, NBMA or Point- 520 to-MultiPoint) and the number of routers having an interface to 521 the network. Three cases are depicted in Figure 1a. Rectangles 522 indicate routers. Circles and oblongs indicate networks. 523 Router names are prefixed with the letters RT and network names 524 with the letter N. Router interface names are prefixed by the 525 letter I. Lines between routers indicate point-to-point 526 networks. The left side of the figure shows networks with their 527 connected routers, with the resulting graphs shown on the right. 529 **FROM** 531 * |RT1|RT2| 532 +---+Ia +---+ * ------------ 533 |RT1|------|RT2| T RT1| | X | 534 +---+ Ib+---+ O RT2| X | | 535 * Ia| | X | 536 * Ib| X | | 538 Physical point-to-point networks 540 **FROM** 541 +---+ * 542 |RT7| * |RT7| N3| 543 +---+ T ------------ 544 | O RT7| | | 545 +----------------------+ * N3| X | | 546 N3 * 548 Stub networks 550 **FROM** 551 +---+ +---+ 552 |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | 553 +---+ +---+ * ------------------------ 554 | N2 | * RT3| | | | | X | 555 +----------------------+ T RT4| | | | | X | 556 | | O RT5| | | | | X | 557 +---+ +---+ * RT6| | | | | X | 558 |RT5| |RT6| * N2| X | X | X | X | | 559 +---+ +---+ 561 Broadcast or NBMA networks 563 Figure 1a: Network map components 565 Networks and routers are represented by vertices. 566 An edge connects Vertex A to Vertex B iff the 567 intersection of Column A and Row B is marked with 568 an X. 570 The top of Figure 1a shows two routers connected by a point-to- 571 point link. In the resulting link-state database graph, the two 572 router vertices are directly connected by a pair of edges, one 573 in each direction. Interfaces to point-to-point networks need 574 not be assigned IP addresses. When interface addresses are 575 assigned, they are modelled as stub links, with each router 576 advertising a stub connection to the other router's interface 577 address. Optionally, an IP subnet can be assigned to the point- 578 to-point network. In this case, both routers advertise a stub 579 link to the IP subnet, instead of advertising each others' IP 580 interface addresses. 582 The middle of Figure 1a shows a network with only one attached 583 router (i.e., a stub network). In this case, the network appears 584 on the end of a stub connection in the link-state database's 585 graph. 587 When multiple routers are attached to a broadcast network, the 588 link-state database graph shows all routers bidirectionally 589 connected to the network vertex. This is pictured at the bottom 590 of Figure 1a. 592 Each network (stub or transit) in the graph has an IP address 593 and associated network mask. The mask indicates the number of 594 nodes on the network. Hosts attached directly to routers 595 (referred to as host routes) appear on the graph as stub 596 networks. The network mask for a host route is always 597 0xffffffff, which indicates the presence of a single node. 599 2.1.1. Representation of non-broadcast networks 601 As mentioned previously, OSPF can run over non-broadcast 602 networks in one of two modes: NBMA or Point-to-MultiPoint. 603 The choice of mode determines the way that the Hello 604 protocol and flooding work over the non-broadcast network, 605 and the way that the network is represented in the link- 606 state database. 608 In NBMA mode, OSPF emulates operation over a broadcast 609 network: a Designated Router is elected for the NBMA 610 network, and the Designated Router originates an LSA for the 611 network. The graph representation for broadcast networks and 612 NBMA networks is identical. This representation is pictured 613 in the middle of Figure 1a. 615 NBMA mode is the most efficient way to run OSPF over non- 616 broadcast networks, both in terms of link-state database 617 size and in terms of the amount of routing protocol traffic. 618 However, it has one significant restriction: it requires all 619 routers attached to the NBMA network to be able to 620 communicate directly. This restriction may be met on some 621 non-broadcast networks, such as an ATM subnet utilizing 622 SVCs. But it is often not met on other non-broadcast 623 networks, such as PVC-only Frame Relay networks. On non- 624 broadcast networks where not all routers can communicate 625 directly you can break the non-broadcast network into 626 logical subnets, with the routers on each subnet being able 627 to communicate directly, and then run each separate subnet 628 as an NBMA network (see [Ref15]). This however requires 629 quite a bit of administrative overhead, and is prone to 630 misconfiguration. It is probably better to run such a non- 631 broadcast network in Point-to-Multipoint mode. 633 In Point-to-MultiPoint mode, OSPF treats all router-to- 634 router connections over the non-broadcast network as if they 635 were point-to-point links. No Designated Router is elected 636 for the network, nor is there an LSA generated for the 637 network. In fact, a vertex for the Point-to-MultiPoint 638 network does not appear in the graph of the link-state 639 database. 641 Figure 1b illustrates the link-state database representation 642 of a Point-to-MultiPoint network. On the left side of the 643 figure, a Point-to-MultiPoint network is pictured. It is 644 assumed that all routers can communicate directly, except 645 for routers RT4 and RT5. I3 though I6 indicate the routers' 646 IP interface addresses on the Point-to-MultiPoint network. 647 In the graphical representation of the link-state database, 648 routers that can communicate directly over the Point-to- 649 MultiPoint network are joined by bidirectional edges, and 650 each router also has a stub connection to its own IP 651 interface address (which is in contrast to the 652 representation of real point-to-point links; see Figure 1a). 654 On some non-broadcast networks, use of Point-to-MultiPoint 655 mode and data-link protocols such as Inverse ARP (see 656 [Ref14]) will allow autodiscovery of OSPF neighbors even 657 though broadcast support is not available. 659 2.1.2. An example link-state database 661 Figure 2 shows a sample map of an Autonomous System. The 662 rectangle labelled H1 indicates a host, which has a SLIP 663 **FROM** 664 +---+ +---+ 665 |RT3| |RT4| |RT3|RT4|RT5|RT6| 666 +---+ +---+ * -------------------- 667 I3| N2 |I4 * RT3| | X | X | X | 668 +----------------------+ T RT4| X | | | X | 669 I5| |I6 O RT5| X | | | X | 670 +---+ +---+ * RT6| X | X | X | | 671 |RT5| |RT6| * I3| X | | | | 672 +---+ +---+ I4| | X | | | 673 I5| | | X | | 674 I6| | | | X | 676 Figure 1b: Network map components 677 Point-to-MultiPoint networks 679 All routers can communicate directly over N2, except 680 routers RT4 and RT5. I3 through I6 indicate IP 681 interface addresses 683 connection to Router RT12. Router RT12 is therefore 684 advertising a host route. Lines between routers indicate 685 physical point-to-point networks. The only point-to-point 686 network that has been assigned interface addresses is the 687 one joining Routers RT6 and RT10. Routers RT5 and RT7 have 688 BGP connections to other Autonomous Systems. A set of BGP- 689 learned routes have been displayed for both of these 690 routers. 692 A cost is associated with the output side of each router 693 interface. This cost is configurable by the system 694 administrator. The lower the cost, the more likely the 695 interface is to be used to forward data traffic. Costs are 696 also associated with the externally derived routing data 697 (e.g., the BGP-learned routes). 699 The directed graph resulting from the map in Figure 2 is 700 depicted in Figure 3. Arcs are labelled with the cost of 701 the corresponding router output interface. Arcs having no 702 labelled cost have a cost of 0. Note that arcs leading from 703 networks to routers always have cost 0; they are significant 704 nonetheless. Note also that the externally derived routing 705 data appears on the graph as stubs. 707 + 708 | 3+---+ N12 N14 709 N1|--|RT1|\ 1 \ N13 / 710 | +---+ \ 8\ |8/8 711 + \ ____ \|/ 712 / \ 1+---+8 8+---+6 713 * N3 *---|RT4|------|RT5|--------+ 714 \____/ +---+ +---+ | 715 + / | |7 | 716 | 3+---+ / | | | 717 N2|--|RT2|/1 |1 |6 | 718 | +---+ +---+8 6+---+ | 719 + |RT3|--------------|RT6| | 720 +---+ +---+ | 721 |2 Ia|7 | 722 | | | 723 +---------+ | | 724 N4 | | 725 | | 726 | | 727 N11 | | 728 +---------+ | | 729 | | | N12 730 |3 | |6 2/ 731 +---+ | +---+/ 732 |RT9| | |RT7|---N15 733 +---+ | +---+ 9 734 |1 + | |1 735 _|__ | Ib|5 __|_ 736 / \ 1+----+2 | 3+----+1 / \ 737 * N9 *------|RT11|----|---|RT10|---* N6 * 738 \____/ +----+ | +----+ \____/ 739 | | | 740 |1 + |1 741 +--+ 10+----+ N8 +---+ 742 |H1|-----|RT12| |RT8| 743 +--+SLIP +----+ +---+ 744 |2 |4 745 | | 746 +---------+ +--------+ 747 N10 N7 749 Figure 2: A sample Autonomous System 750 **FROM** 752 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| 753 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| 754 ----- --------------------------------------------- 755 RT1| | | | | | | | | | | | |0 | | | | 756 RT2| | | | | | | | | | | | |0 | | | | 757 RT3| | | | | |6 | | | | | | |0 | | | | 758 RT4| | | | |8 | | | | | | | |0 | | | | 759 RT5| | | |8 | |6 |6 | | | | | | | | | | 760 RT6| | |8 | |7 | | | | |5 | | | | | | | 761 RT7| | | | |6 | | | | | | | | |0 | | | 762 * RT8| | | | | | | | | | | | | |0 | | | 763 * RT9| | | | | | | | | | | | | | | |0 | 764 T RT10| | | | | |7 | | | | | | | |0 |0 | | 765 O RT11| | | | | | | | | | | | | | |0 |0 | 766 * RT12| | | | | | | | | | | | | | | |0 | 767 * N1|3 | | | | | | | | | | | | | | | | 768 N2| |3 | | | | | | | | | | | | | | | 769 N3|1 |1 |1 |1 | | | | | | | | | | | | | 770 N4| | |2 | | | | | | | | | | | | | | 771 N6| | | | | | |1 |1 | |1 | | | | | | | 772 N7| | | | | | | |4 | | | | | | | | | 773 N8| | | | | | | | | |3 |2 | | | | | | 774 N9| | | | | | | | |1 | |1 |1 | | | | | 775 N10| | | | | | | | | | | |2 | | | | | 776 N11| | | | | | | | |3 | | | | | | | | 777 N12| | | | |8 | |2 | | | | | | | | | | 778 N13| | | | |8 | | | | | | | | | | | | 779 N14| | | | |8 | | | | | | | | | | | | 780 N15| | | | | | |9 | | | | | | | | | | 781 H1| | | | | | | | | | | |10| | | | | 783 Figure 3: The resulting directed graph 785 Networks and routers are represented by vertices. 786 An edge of cost X connects Vertex A to Vertex B iff 787 the intersection of Column A and Row B is marked 788 with an X. 790 The link-state database is pieced together from LSAs 791 generated by the routers. In the associated graphical 792 representation, the neighborhood of each router or transit 793 network is represented in a single, separate LSA. Figure 4 794 shows these LSAs graphically. Router RT12 has an interface 795 to two broadcast networks and a SLIP line to a host. 796 Network N6 is a broadcast network with three attached 797 routers. The cost of all links from Network N6 to its 798 attached routers is 0. Note that the LSA for Network N6 is 799 actually generated by one of the network's attached routers: 800 the router that has been elected Designated Router for the 801 network. 803 2.2. The shortest-path tree 805 When no OSPF areas are configured, each router in the Autonomous 806 System has an identical link-state database, leading to an 807 identical graphical representation. A router generates its 808 routing table from this graph by calculating a tree of shortest 809 paths with the router itself as root. Obviously, the shortest- 810 path tree depends on the router doing the calculation. The 811 shortest-path tree for Router RT6 in our example is depicted in 812 Figure 5. 814 The tree gives the entire path to any destination network or 815 host. However, only the next hop to the destination is used in 816 the forwarding process. Note also that the best route to any 817 router has also been calculated. For the processing of external 818 data, we note the next hop and distance to any router 819 advertising external routes. The resulting routing table for 820 Router RT6 is pictured in Table 2. Note that there is a 821 separate route for each end of a numbered point-to-point network 822 (in this case, the serial line between Routers RT6 and RT10). 824 **FROM** **FROM** 826 |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| 827 * -------------------- * ---------------------- 828 * RT12| | | | | * RT9| | | |0 | 829 T N9|1 | | | | T RT11| | | |0 | 830 O N10|2 | | | | O RT12| | | |0 | 831 * H1|10 | | | | * N9| | | | | 832 * * 833 RT12's router-LSA N9's network-LSA 835 Figure 4: Individual link state components 837 Networks and routers are represented by vertices. 838 An edge of cost X connects Vertex A to Vertex B iff 839 the intersection of Column A and Row B is marked 840 with an X. 842 RT6(origin) 843 RT5 o------------o-----------o Ib 844 /|\ 6 |\ 7 845 8/8|8\ | \ 846 / | \ 6| \ 847 o | o | \7 848 N12 o N14 | \ 849 N13 2 | \ 850 N4 o-----o RT3 \ 851 / \ 5 852 1/ RT10 o-------o Ia 853 / |\ 854 RT4 o-----o N3 3| \1 855 /| | \ N6 RT7 856 / | N8 o o---------o 857 / | | | /| 858 RT2 o o RT1 | | 2/ |9 859 / | | |RT8 / | 860 /3 |3 RT11 o o o o 861 / | | | N12 N15 862 N2 o o N1 1| |4 863 | | 864 N9 o o N7 865 /| 866 / | 867 N11 RT9 / |RT12 868 o--------o-------o o--------o H1 869 3 | 10 870 |2 871 | 872 o N10 874 Figure 5: The SPF tree for Router RT6 876 Edges that are not marked with a cost have a cost of 877 of zero (these are network-to-router links). Routes 878 to networks N12-N15 are external information that is 879 considered in Section 2.3 880 Destination Next Hop Distance 881 __________________________________ 882 N1 RT3 10 883 N2 RT3 10 884 N3 RT3 7 885 N4 RT3 8 886 Ib * 7 887 Ia RT10 12 888 N6 RT10 8 889 N7 RT10 12 890 N8 RT10 10 891 N9 RT10 11 892 N10 RT10 13 893 N11 RT10 14 894 H1 RT10 21 895 __________________________________ 896 RT5 RT5 6 897 RT7 RT10 8 899 Table 2: The portion of Router RT6's routing table listing local 900 destinations. 902 Routes to networks belonging to other AS'es (such as N12) appear 903 as dashed lines on the shortest path tree in Figure 5. Use of 904 this externally derived routing information is considered in the 905 next section. 907 2.3. Use of external routing information 909 After the tree is created the external routing information is 910 examined. This external routing information may originate from 911 another routing protocol such as BGP, or be statically 912 configured (static routes). Default routes can also be included 913 as part of the Autonomous System's external routing information. 915 External routing information is flooded unaltered throughout the 916 AS. In our example, all the routers in the Autonomous System 917 know that Router RT7 has two external routes, with metrics 2 and 918 9. 920 OSPF supports two types of external metrics. Type 1 external 921 metrics are expressed in the same units as OSPF interface cost 922 (i.e., in terms of the link state metric). Type 2 external 923 metrics are an order of magnitude larger; any Type 2 metric is 924 considered greater than the cost of any path internal to the AS. 925 Use of Type 2 external metrics assumes that routing between 926 AS'es is the major cost of routing a packet, and eliminates the 927 need for conversion of external costs to internal link state 928 metrics. 930 As an example of Type 1 external metric processing, suppose that 931 the Routers RT7 and RT5 in Figure 2 are advertising Type 1 932 external metrics. For each advertised external route, the total 933 cost from Router RT6 is calculated as the sum of the external 934 route's advertised cost and the distance from Router RT6 to the 935 advertising router. When two routers are advertising the same 936 external destination, RT6 picks the advertising router providing 937 the minimum total cost. RT6 then sets the next hop to the 938 external destination equal to the next hop that would be used 939 when routing packets to the chosen advertising router. 941 In Figure 2, both Router RT5 and RT7 are advertising an external 942 route to destination Network N12. Router RT7 is preferred since 943 it is advertising N12 at a distance of 10 (8+2) to Router RT6, 944 which is better than Router RT5's 14 (6+8). Table 3 shows the 945 entries that are added to the routing table when external routes 946 are examined: 948 Destination Next Hop Distance 949 __________________________________ 950 N12 RT10 10 951 N13 RT5 14 952 N14 RT5 14 953 N15 RT10 17 955 Table 3: The portion of Router RT6's routing table 956 listing external destinations. 958 Processing of Type 2 external metrics is simpler. The AS 959 boundary router advertising the smallest external metric is 960 chosen, regardless of the internal distance to the AS boundary 961 router. Suppose in our example both Router RT5 and Router RT7 962 were advertising Type 2 external routes. Then all traffic 963 destined for Network N12 would be forwarded to Router RT7, since 964 2 < 8. When several equal-cost Type 2 routes exist, the 965 internal distance to the advertising routers is used to break 966 the tie. 968 Both Type 1 and Type 2 external metrics can be present in the AS 969 at the same time. In that event, Type 1 external metrics always 970 take precedence. 972 This section has assumed that packets destined for external 973 destinations are always routed through the advertising AS 974 boundary router. This is not always desirable. For example, 975 suppose in Figure 2 there is an additional router attached to 976 Network N6, called Router RTX. Suppose further that RTX does 977 not participate in OSPF routing, but does exchange BGP 978 information with the AS boundary router RT7. Then, Router RT7 979 would end up advertising OSPF external routes for all 980 destinations that should be routed to RTX. An extra hop will 981 sometimes be introduced if packets for these destinations need 982 always be routed first to Router RT7 (the advertising router). 984 To deal with this situation, the OSPF protocol allows an AS 985 boundary router to specify a "forwarding address" in its AS- 986 external-LSAs. In the above example, Router RT7 would specify 987 RTX's IP address as the "forwarding address" for all those 988 destinations whose packets should be routed directly to RTX. 990 The "forwarding address" has one other application. It enables 991 routers in the Autonomous System's interior to function as 992 "route servers". For example, in Figure 2 the router RT6 could 993 become a route server, gaining external routing information 994 through a combination of static configuration and external 995 routing protocols. RT6 would then start advertising itself as 996 an AS boundary router, and would originate a collection of OSPF 997 AS-external-LSAs. In each AS-external-LSA, Router RT6 would 998 specify the correct Autonomous System exit point to use for the 999 destination through appropriate setting of the LSA's "forwarding 1000 address" field. 1002 2.4. Equal-cost multipath 1004 The above discussion has been simplified by considering only a 1005 single route to any destination. In reality, if multiple 1006 equal-cost routes to a destination exist, they are all 1007 discovered and used. This requires no conceptual changes to the 1008 algorithm, and its discussion is postponed until we consider the 1009 tree-building process in more detail. 1011 With equal cost multipath, a router potentially has several 1012 available next hops towards any given destination. 1014 3. Splitting the AS into Areas 1016 OSPF allows collections of contiguous networks and hosts to be 1017 grouped together. Such a group, together with the routers having 1018 interfaces to any one of the included networks, is called an area. 1019 Each area runs a separate copy of the basic link-state routing 1020 algorithm. This means that each area has its own link-state 1021 database and corresponding graph, as explained in the previous 1022 section. 1024 The topology of an area is invisible from the outside of the area. 1025 Conversely, routers internal to a given area know nothing of the 1026 detailed topology external to the area. This isolation of knowledge 1027 enables the protocol to effect a marked reduction in routing traffic 1028 as compared to treating the entire Autonomous System as a single 1029 link-state domain. 1031 With the introduction of areas, it is no longer true that all 1032 routers in the AS have an identical link-state database. A router 1033 actually has a separate link-state database for each area it is 1034 connected to. (Routers connected to multiple areas are called area 1035 border routers). Two routers belonging to the same area have, for 1036 that area, identical area link-state databases. 1038 Routing in the Autonomous System takes place on two levels, 1039 depending on whether the source and destination of a packet reside 1040 in the same area (intra-area routing is used) or different areas 1041 (inter-area routing is used). In intra-area routing, the packet is 1042 routed solely on information obtained within the area; no routing 1043 information obtained from outside the area can be used. This 1044 protects intra-area routing from the injection of bad routing 1045 information. We discuss inter-area routing in Section 3.2. 1047 3.1. The backbone of the Autonomous System 1049 The OSPF backbone is the special OSPF Area 0 (often written as 1050 Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP 1051 addresses). The OSPF backbone always contains all area border 1052 routers. The backbone is responsible for distributing routing 1053 information between non-backbone areas. The backbone must be 1054 contiguous. However, it need not be physically contiguous; 1055 backbone connectivity can be established/maintained through the 1056 configuration of virtual links. 1058 Virtual links can be configured between any two backbone routers 1059 that have an interface to a common non-backbone area. Virtual 1060 links belong to the backbone. The protocol treats two routers 1061 joined by a virtual link as if they were connected by an 1062 unnumbered point-to-point backbone network. On the graph of the 1063 backbone, two such routers are joined by arcs whose costs are 1064 the intra-area distances between the two routers. The routing 1065 protocol traffic that flows along the virtual link uses intra- 1066 area routing only. 1068 3.2. Inter-area routing 1070 When routing a packet between two non-backbone areas the 1071 backbone is used. The path that the packet will travel can be 1072 broken up into three contiguous pieces: an intra-area path from 1073 the source to an area border router, a backbone path between the 1074 source and destination areas, and then another intra-area path 1075 to the destination. The algorithm finds the set of such paths 1076 that have the smallest cost. 1078 Looking at this another way, inter-area routing can be pictured 1079 as forcing a star configuration on the Autonomous System, with 1080 the backbone as hub and each of the non-backbone areas as 1081 spokes. 1083 The topology of the backbone dictates the backbone paths used 1084 between areas. The topology of the backbone can be enhanced by 1085 adding virtual links. This gives the system administrator some 1086 control over the routes taken by inter-area traffic. 1088 The correct area border router to use as the packet exits the 1089 source area is chosen in exactly the same way routers 1090 advertising external routes are chosen. Each area border router 1091 in an area summarizes for the area its cost to all networks 1092 external to the area. After the SPF tree is calculated for the 1093 area, routes to all inter-area destinations are calculated by 1094 examining the summaries of the area border routers. 1096 3.3. Classification of routers 1098 Before the introduction of areas, the only OSPF routers having a 1099 specialized function were those advertising external routing 1100 information, such as Router RT5 in Figure 2. When the AS is 1101 split into OSPF areas, the routers are further divided according 1102 to function into the following four overlapping categories: 1104 Internal routers 1105 A router with all directly connected networks belonging to 1106 the same area. These routers run a single copy of the basic 1107 routing algorithm. 1109 Area border routers 1110 A router that attaches to multiple areas. Area border 1111 routers run multiple copies of the basic algorithm, one copy 1112 for each attached area. Area border routers condense the 1113 topological information of their attached areas for 1114 distribution to the backbone. The backbone in turn 1115 distributes the information to the other areas. 1117 Backbone routers 1118 A router that has an interface to the backbone area. This 1119 includes all routers that interface to more than one area 1120 (i.e., area border routers). However, backbone routers do 1121 not have to be area border routers. Routers with all 1122 interfaces connecting to the backbone area are supported. 1124 AS boundary routers 1125 A router that exchanges routing information with routers 1126 belonging to other Autonomous Systems. Such a router 1127 advertises AS external routing information throughout the 1128 Autonomous System. The paths to each AS boundary router are 1129 known by every router in the AS. This classification is 1130 completely independent of the previous classifications: AS 1131 boundary routers may be internal or area border routers, and 1132 may or may not participate in the backbone. 1134 3.4. A sample area configuration 1136 Figure 6 shows a sample area configuration. The first area 1137 consists of networks N1-N4, along with their attached routers 1138 RT1-RT4. The second area consists of networks N6-N8, along with 1139 their attached routers RT7, RT8, RT10 and RT11. The third area 1140 consists of networks N9-N11 and Host H1, along with their 1141 attached routers RT9, RT11 and RT12. The third area has been 1142 configured so that networks N9-N11 and Host H1 will all be 1143 grouped into a single route, when advertised external to the 1144 area (see Section 3.5 for more details). 1146 In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are 1147 internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area 1148 border routers. Finally, as before, Routers RT5 and RT7 are AS 1149 boundary routers. 1151 Figure 7 shows the resulting link-state database for the Area 1. 1152 The figure completely describes that area's intra-area routing. 1154 ........................... 1155 . + . 1156 . | 3+---+ . N12 N14 1157 . N1|--|RT1|\ 1 . \ N13 / 1158 . | +---+ \ . 8\ |8/8 1159 . + \ ____ . \|/ 1160 . / \ 1+---+8 8+---+6 1161 . * N3 *---|RT4|------|RT5|--------+ 1162 . \____/ +---+ +---+ | 1163 . + / \ . |7 | 1164 . | 3+---+ / \ . | | 1165 . N2|--|RT2|/1 1\ . |6 | 1166 . | +---+ +---+8 6+---+ | 1167 . + |RT3|------|RT6| | 1168 . +---+ +---+ | 1169 . 2/ . Ia|7 | 1170 . / . | | 1171 . +---------+ . | | 1172 .Area 1 N4 . | | 1173 ........................... | | 1174 .......................... | | 1175 . N11 . | | 1176 . +---------+ . | | 1177 . | . | | N12 1178 . |3 . Ib|5 |6 2/ 1179 . +---+ . +----+ +---+/ 1180 . |RT9| . .........|RT10|.....|RT7|---N15. 1181 . +---+ . . +----+ +---+ 9 . 1182 . |1 . . + /3 1\ |1 . 1183 . _|__ . . | / \ __|_ . 1184 . / \ 1+----+2 |/ \ / \ . 1185 . * N9 *------|RT11|----| * N6 * . 1186 . \____/ +----+ | \____/ . 1187 . | . . | | . 1188 . |1 . . + |1 . 1189 . +--+ 10+----+ . . N8 +---+ . 1190 . |H1|-----|RT12| . . |RT8| . 1191 . +--+SLIP +----+ . . +---+ . 1192 . |2 . . |4 . 1193 . | . . | . 1194 . +---------+ . . +--------+ . 1195 . N10 . . N7 . 1196 . . .Area 2 . 1197 .Area 3 . ................................ 1198 .......................... 1200 Figure 6: A sample OSPF area configuration 1201 It also shows the complete view of the internet for the two 1202 internal routers RT1 and RT2. It is the job of the area border 1203 routers, RT3 and RT4, to advertise into Area 1 the distances to 1204 all destinations external to the area. These are indicated in 1205 Figure 7 by the dashed stub routes. Also, RT3 and RT4 must 1206 advertise into Area 1 the location of the AS boundary routers 1207 RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are 1208 flooded throughout the entire AS, and in particular throughout 1209 Area 1. These LSAs are included in Area 1's database, and yield 1210 routes to Networks N12-N15. 1212 Routers RT3 and RT4 must also summarize Area 1's topology for 1213 distribution to the backbone. Their backbone LSAs are shown in 1214 Table 4. These summaries show which networks are contained in 1215 Area 1 (i.e., Networks N1-N4), and the distance to these 1216 networks from the routers RT3 and RT4 respectively. 1218 The link-state database for the backbone is shown in Figure 8. 1219 The set of routers pictured are the backbone routers. Router 1220 RT11 is a backbone router because it belongs to two areas. In 1221 order to make the backbone connected, a virtual link has been 1222 configured between Routers R10 and R11. 1224 The area border routers RT3, RT4, RT7, RT10 and RT11 condense 1225 the routing information of their attached non-backbone areas for 1226 distribution via the backbone; these are the dashed stubs that 1227 appear in Figure 8. Remember that the third area has been 1228 configured to condense Networks N9-N11 and Host H1 into a single 1229 route. This yields a single dashed line for networks N9-N11 and 1230 Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary 1231 routers; their externally derived information also appears on 1232 the graph in Figure 8 as stubs. 1234 Network RT3 adv. RT4 adv. 1235 _____________________________ 1236 N1 4 4 1237 N2 4 4 1238 N3 1 1 1239 N4 2 3 1241 Table 4: Networks advertised to the backbone 1242 by Routers RT3 and RT4. 1244 **FROM** 1246 |RT|RT|RT|RT|RT|RT| 1247 |1 |2 |3 |4 |5 |7 |N3| 1248 ----- ------------------- 1249 RT1| | | | | | |0 | 1250 RT2| | | | | | |0 | 1251 RT3| | | | | | |0 | 1252 * RT4| | | | | | |0 | 1253 * RT5| | |14|8 | | | | 1254 T RT7| | |20|14| | | | 1255 O N1|3 | | | | | | | 1256 * N2| |3 | | | | | | 1257 * N3|1 |1 |1 |1 | | | | 1258 N4| | |2 | | | | | 1259 Ia,Ib| | |20|27| | | | 1260 N6| | |16|15| | | | 1261 N7| | |20|19| | | | 1262 N8| | |18|18| | | | 1263 N9-N11,H1| | |29|36| | | | 1264 N12| | | | |8 |2 | | 1265 N13| | | | |8 | | | 1266 N14| | | | |8 | | | 1267 N15| | | | | |9 | | 1269 Figure 7: Area 1's Database. 1271 Networks and routers are represented by vertices. 1272 An edge of cost X connects Vertex A to Vertex B iff 1273 the intersection of Column A and Row B is marked 1274 with an X. 1276 **FROM** 1278 |RT|RT|RT|RT|RT|RT|RT 1279 |3 |4 |5 |6 |7 |10|11| 1280 ------------------------ 1281 RT3| | | |6 | | | | 1282 RT4| | |8 | | | | | 1283 RT5| |8 | |6 |6 | | | 1284 RT6|8 | |7 | | |5 | | 1285 RT7| | |6 | | | | | 1286 * RT10| | | |7 | | |2 | 1287 * RT11| | | | | |3 | | 1288 T N1|4 |4 | | | | | | 1289 O N2|4 |4 | | | | | | 1290 * N3|1 |1 | | | | | | 1291 * N4|2 |3 | | | | | | 1292 Ia| | | | | |5 | | 1293 Ib| | | |7 | | | | 1294 N6| | | | |1 |1 |3 | 1295 N7| | | | |5 |5 |7 | 1296 N8| | | | |4 |3 |2 | 1297 N9-N11,H1| | | | | | |11| 1298 N12| | |8 | |2 | | | 1299 N13| | |8 | | | | | 1300 N14| | |8 | | | | | 1301 N15| | | | |9 | | | 1303 Figure 8: The backbone's database. 1305 Networks and routers are represented by vertices. 1306 An edge of cost X connects Vertex A to Vertex B iff 1307 the intersection of Column A and Row B is marked 1308 with an X. 1310 The backbone enables the exchange of summary information between 1311 area border routers. Every area border router hears the area 1312 summaries from all other area border routers. It then forms a 1313 picture of the distance to all networks outside of its area by 1314 examining the collected LSAs, and adding in the backbone 1315 distance to each advertising router. 1317 Again using Routers RT3 and RT4 as an example, the procedure 1318 goes as follows: They first calculate the SPF tree for the 1319 backbone. This gives the distances to all other area border 1320 routers. Also noted are the distances to networks (Ia and Ib) 1321 and AS boundary routers (RT5 and RT7) that belong to the 1322 backbone. This calculation is shown in Table 5. 1324 Next, by looking at the area summaries from these area border 1325 routers, RT3 and RT4 can determine the distance to all networks 1326 outside their area. These distances are then advertised 1327 internally to the area by RT3 and RT4. The advertisements that 1328 Router RT3 and RT4 will make into Area 1 are shown in Table 6. 1329 Note that Table 6 assumes that an area range has been configured 1330 for the backbone which groups Ia and Ib into a single LSA. 1332 The information imported into Area 1 by Routers RT3 and RT4 1333 enables an internal router, such as RT1, to choose an area 1334 border router intelligently. Router RT1 would use RT4 for 1336 dist from dist from 1337 RT3 RT4 1338 __________________________________ 1339 to RT3 * 21 1340 to RT4 22 * 1341 to RT7 20 14 1342 to RT10 15 22 1343 to RT11 18 25 1344 __________________________________ 1345 to Ia 20 27 1346 to Ib 15 22 1347 __________________________________ 1348 to RT5 14 8 1349 to RT7 20 14 1351 Table 5: Backbone distances calculated 1352 by Routers RT3 and RT4. 1354 Destination RT3 adv. RT4 adv. 1355 _________________________________ 1356 Ia,Ib 20 27 1357 N6 16 15 1358 N7 20 19 1359 N8 18 18 1360 N9-N11,H1 29 36 1361 _________________________________ 1362 RT5 14 8 1363 RT7 20 14 1365 Table 6: Destinations advertised into Area 1 1366 by Routers RT3 and RT4. 1368 traffic to Network N6, RT3 for traffic to Network N10, and would 1369 load share between the two for traffic to Network N8. 1371 Router RT1 can also determine in this manner the shortest path 1372 to the AS boundary routers RT5 and RT7. Then, by looking at RT5 1373 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or 1374 RT7 when sending to a destination in another Autonomous System 1375 (one of the networks N12-N15). 1377 Note that a failure of the line between Routers RT6 and RT10 1378 will cause the backbone to become disconnected. Configuring a 1379 virtual link between Routers RT7 and RT10 will give the backbone 1380 more connectivity and more resistance to such failures. 1382 3.5. IP subnetting support 1384 OSPF attaches an IP address mask to each advertised route. The 1385 mask indicates the range of addresses being described by the 1386 particular route. For example, a summary-LSA for the 1387 destination 128.185.0.0 with a mask of 0xffff0000 actually is 1388 describing a single route to the collection of destinations 1389 128.185.0.0 - 128.185.255.255. Similarly, host routes are 1390 always advertised with a mask of 0xffffffff, indicating the 1391 presence of only a single destination. 1393 Including the mask with each advertised destination enables the 1394 implementation of what is commonly referred to as variable- 1395 length subnetting. This means that a single IP class A, B, or C 1396 network number can be broken up into many subnets of various 1397 sizes. For example, the network 128.185.0.0 could be broken up 1398 into 62 variable-sized subnets: 15 subnets of size 4K, 15 1399 subnets of size 256, and 32 subnets of size 8. Table 7 shows 1400 some of the resulting network addresses together with their 1401 masks. 1403 Network address IP address mask Subnet size 1404 _______________________________________________ 1405 128.185.16.0 0xfffff000 4K 1406 128.185.1.0 0xffffff00 256 1407 128.185.0.8 0xfffffff8 8 1409 Table 7: Some sample subnet sizes. 1411 There are many possible ways of dividing up a class A, B, and C 1412 network into variable sized subnets. The precise procedure for 1413 doing so is beyond the scope of this specification. This 1414 specification however establishes the following guideline: When 1415 an IP packet is forwarded, it is always forwarded to the network 1416 that is the best match for the packet's destination. Here best 1417 match is synonymous with the longest or most specific match. 1418 For example, the default route with destination of 0.0.0.0 and 1419 mask 0x00000000 is always a match for every IP destination. Yet 1420 it is always less specific than any other match. Subnet masks 1421 must be assigned so that the best match for any IP destination 1422 is unambiguous. 1424 Attaching an address mask to each route also enables the support 1425 of IP supernetting. For example, a single physical network 1426 segment could be assigned the [address,mask] pair 1427 [192.9.4.0,0xfffffc00]. The segment would then be single IP 1428 network, containing addresses from the four consecutive class C 1429 network numbers 192.9.4.0 through 192.9.7.0. Such addressing is 1430 now becoming commonplace with the advent of CIDR (see [Ref10]). 1432 In order to get better aggregation at area boundaries, area 1433 address ranges can be employed (see Section C.2 for more 1434 details). Each address range is defined as an [address,mask] 1435 pair. Many separate networks may then be contained in a single 1436 address range, just as a subnetted network is composed of many 1437 separate subnets. Area border routers then summarize the area 1438 contents (for distribution to the backbone) by advertising a 1439 single route for each address range. The cost of the route is 1440 the maximum cost to any of the networks falling in the specified 1441 range. 1443 For example, an IP subnetted network might be configured as a 1444 single OSPF area. In that case, a single address range could be 1445 configured: a class A, B, or C network number along with its 1446 natural IP mask. Inside the area, any number of variable sized 1447 subnets could be defined. However, external to the area a 1448 single route for the entire subnetted network would be 1449 distributed, hiding even the fact that the network is subnetted 1450 at all. The cost of this route is the maximum of the set of 1451 costs to the component subnets. 1453 3.6. Supporting stub areas 1455 In some Autonomous Systems, the majority of the link-state 1456 database may consist of AS-external-LSAs. An OSPF AS-external- 1457 LSA is usually flooded throughout the entire AS. However, OSPF 1458 allows certain areas to be configured as "stub areas". AS- 1459 external-LSAs are not flooded into/throughout stub areas; 1460 routing to AS external destinations in these areas is based on a 1461 (per-area) default only. This reduces the link-state database 1462 size, and therefore the memory requirements, for a stub area's 1463 internal routers. 1465 In order to take advantage of the OSPF stub area support, 1466 default routing must be used in the stub area. This is 1467 accomplished as follows. One or more of the stub area's area 1468 border routers must advertise a default route into the stub area 1469 via summary-LSAs. These summary defaults are flooded throughout 1470 the stub area, but no further. (For this reason these defaults 1471 pertain only to the particular stub area). These summary 1472 default routes will be used for any destination that is not 1473 explicitly reachable by an intra-area or inter-area path (i.e., 1474 AS external destinations). 1476 An area can be configured as a stub when there is a single exit 1477 point from the area, or when the choice of exit point need not 1478 be made on a per-external-destination basis. For example, Area 1479 3 in Figure 6 could be configured as a stub area, because all 1480 external traffic must travel though its single area border 1481 router RT11. If Area 3 were configured as a stub, Router RT11 1482 would advertise a default route for distribution inside Area 3 1483 (in a summary-LSA), instead of flooding the AS-external-LSAs for 1484 Networks N12-N15 into/throughout the area. 1486 The OSPF protocol ensures that all routers belonging to an area 1487 agree on whether the area has been configured as a stub. This 1488 guarantees that no confusion will arise in the flooding of AS- 1489 external-LSAs. 1491 There are a couple of restrictions on the use of stub areas. 1492 Virtual links cannot be configured through stub areas. In 1493 addition, AS boundary routers cannot be placed internal to stub 1494 areas. 1496 3.7. Partitions of areas 1498 OSPF does not actively attempt to repair area partitions. When 1499 an area becomes partitioned, each component simply becomes a 1500 separate area. The backbone then performs routing between the 1501 new areas. Some destinations reachable via intra-area routing 1502 before the partition will now require inter-area routing. 1504 However, in order to maintain full routing after the partition, 1505 an address range must not be split across multiple components of 1506 the area partition. Also, the backbone itself must not 1507 partition. If it does, parts of the Autonomous System will 1508 become unreachable. Backbone partitions can be repaired by 1509 configuring virtual links (see Section 15). 1511 Another way to think about area partitions is to look at the 1512 Autonomous System graph that was introduced in Section 2. Area 1513 IDs can be viewed as colors for the graph's edges.[1] Each edge 1514 of the graph connects to a network, or is itself a point-to- 1515 point network. In either case, the edge is colored with the 1516 network's Area ID. 1518 A group of edges, all having the same color, and interconnected 1519 by vertices, represents an area. If the topology of the 1520 Autonomous System is intact, the graph will have several regions 1521 of color, each color being a distinct Area ID. 1523 When the AS topology changes, one of the areas may become 1524 partitioned. The graph of the AS will then have multiple 1525 regions of the same color (Area ID). The routing in the 1526 Autonomous System will continue to function as long as these 1527 regions of same color are connected by the single backbone 1528 region. 1530 4. Functional Summary 1532 A separate copy of OSPF's basic routing algorithm runs in each area. 1533 Routers having interfaces to multiple areas run multiple copies of 1534 the algorithm. A brief summary of the routing algorithm follows. 1536 When a router starts, it first initializes the routing protocol data 1537 structures. The router then waits for indications from the lower- 1538 level protocols that its interfaces are functional. 1540 A router then uses the OSPF's Hello Protocol to acquire neighbors. 1541 The router sends Hello packets to its neighbors, and in turn 1542 receives their Hello packets. On broadcast and point-to-point 1543 networks, the router dynamically detects its neighboring routers by 1544 sending its Hello packets to the multicast address AllSPFRouters. 1545 On non-broadcast networks, some configuration information may be 1546 necessary in order to discover neighbors. On broadcast and NBMA 1547 networks the Hello Protocol also elects a Designated router for the 1548 network. 1550 The router will attempt to form adjacencies with some of its newly 1551 acquired neighbors. Link-state databases are synchronized between 1552 pairs of adjacent routers. On broadcast and NBMA networks, the 1553 Designated Router determines which routers should become adjacent. 1555 Adjacencies control the distribution of routing information. 1556 Routing updates are sent and received only on adjacencies. 1558 A router periodically advertises its state, which is also called 1559 link state. Link state is also advertised when a router's state 1560 changes. A router's adjacencies are reflected in the contents of 1561 its LSAs. This relationship between adjacencies and link state 1562 allows the protocol to detect dead routers in a timely fashion. 1564 LSAs are flooded throughout the area. The flooding algorithm is 1565 reliable, ensuring that all routers in an area have exactly the same 1566 link-state database. This database consists of the collection of 1567 LSAs originated by each router belonging to the area. From this 1568 database each router calculates a shortest-path tree, with itself as 1569 root. This shortest-path tree in turn yields a routing table for 1570 the protocol. 1572 4.1. Inter-area routing 1574 The previous section described the operation of the protocol 1575 within a single area. For intra-area routing, no other routing 1576 information is pertinent. In order to be able to route to 1577 destinations outside of the area, the area border routers inject 1578 additional routing information into the area. This additional 1579 information is a distillation of the rest of the Autonomous 1580 System's topology. 1582 This distillation is accomplished as follows: Each area border 1583 router is by definition connected to the backbone. Each area 1584 border router summarizes the topology of its attached non- 1585 backbone areas for transmission on the backbone, and hence to 1586 all other area border routers. An area border router then has 1587 complete topological information concerning the backbone, and 1588 the area summaries from each of the other area border routers. 1589 From this information, the router calculates paths to all 1590 inter-area destinations. The router then advertises these paths 1591 into its attached areas. This enables the area's internal 1592 routers to pick the best exit router when forwarding traffic 1593 inter-area destinations. 1595 4.2. AS external routes 1597 Routers that have information regarding other Autonomous Systems 1598 can flood this information throughout the AS. This external 1599 routing information is distributed verbatim to every 1600 participating router. There is one exception: external routing 1601 information is not flooded into "stub" areas (see Section 3.6). 1603 To utilize external routing information, the path to all routers 1604 advertising external information must be known throughout the AS 1605 (excepting the stub areas). For that reason, the locations of 1606 these AS boundary routers are summarized by the (non-stub) area 1607 border routers. 1609 4.3. Routing protocol packets 1611 The OSPF protocol runs directly over IP, using IP protocol 89. 1612 OSPF does not provide any explicit fragmentation/reassembly 1613 support. When fragmentation is necessary, IP 1614 fragmentation/reassembly is used. OSPF protocol packets have 1615 been designed so that large protocol packets can generally be 1616 split into several smaller protocol packets. This practice is 1617 recommended; IP fragmentation should be avoided whenever 1618 possible. 1620 Routing protocol packets should always be sent with the IP TOS 1621 field set to 0. If at all possible, routing protocol packets 1622 should be given preference over regular IP data traffic, both 1623 when being sent and received. As an aid to accomplishing this, 1624 OSPF protocol packets should have their IP precedence field set 1625 to the value Internetwork Control (see [Ref5]). 1627 All OSPF protocol packets share a common protocol header that is 1628 described in Appendix A. The OSPF packet types are listed below 1629 in Table 8. Their formats are also described in Appendix A. 1631 Type Packet name Protocol function 1632 __________________________________________________________ 1633 1 Hello Discover/maintain neighbors 1634 2 Database Description Summarize database contents 1635 3 Link State Request Database download 1636 4 Link State Update Database update 1637 5 Link State Ack Flooding acknowledgment 1639 Table 8: OSPF packet types. 1641 OSPF's Hello protocol uses Hello packets to discover and 1642 maintain neighbor relationships. The Database Description and 1643 Link State Request packets are used in the forming of 1644 adjacencies. OSPF's reliable update mechanism is implemented by 1645 the Link State Update and Link State Acknowledgment packets. 1647 Each Link State Update packet carries a set of new link state 1648 advertisements (LSAs) one hop further away from their point of 1649 origination. A single Link State Update packet may contain the 1650 LSAs of several routers. Each LSA is tagged with the ID of the 1651 originating router and a checksum of its link state contents. 1652 Each LSA also has a type field; the different types of OSPF LSAs 1653 are listed below in Table 9. 1655 OSPF routing packets (with the exception of Hellos) are sent 1656 only over adjacencies. This means that all OSPF protocol 1657 packets travel a single IP hop, except those that are sent over 1658 virtual adjacencies. The IP source address of an OSPF protocol 1659 packet is one end of a router adjacency, and the IP destination 1660 address is either the other end of the adjacency or an IP 1661 multicast address. 1663 LS LSA LSA description 1664 type name 1665 ________________________________________________________ 1666 1 Router-LSAs Originated by all routers. 1667 This LSA describes 1668 the collected states of the 1669 router's interfaces to an 1670 area. Flooded throughout a 1671 single area only. 1672 ________________________________________________________ 1673 2 Network-LSAs Originated for broadcast 1674 and NBMA networks by 1675 the Designated Router. This 1676 LSA contains the 1677 list of routers connected 1678 to the network. Flooded 1679 throughout a single area only. 1680 ________________________________________________________ 1681 3,4 Summary-LSAs Originated by area border 1682 routers, and flooded through- 1683 out the LSA's associated 1684 area. Each summary-LSA 1685 describes a route to a 1686 destination outside the area, 1687 yet still inside the AS 1688 (i.e., an inter-area route). 1689 Type 3 summary-LSAs describe 1690 routes to networks. Type 4 1691 summary-LSAs describe 1692 routes to AS boundary routers. 1693 ________________________________________________________ 1694 5 AS-external-LSAs Originated by AS boundary 1695 routers, and flooded through- 1696 out the AS. Each 1697 AS-external-LSA describes 1698 a route to a destination in 1699 another Autonomous System. 1700 Default routes for the AS can 1701 also be described by 1702 AS-external-LSAs. 1704 Table 9: OSPF link state advertisements (LSAs). 1706 4.4. Basic implementation requirements 1708 An implementation of OSPF requires the following pieces of 1709 system support: 1711 Timers 1712 Two different kind of timers are required. The first kind, 1713 called "single shot timers", fire once and cause a protocol 1714 event to be processed. The second kind, called "interval 1715 timers", fire at continuous intervals. These are used for 1716 the sending of packets at regular intervals. A good example 1717 of this is the regular broadcast of Hello packets. The 1718 granularity of both kinds of timers is one second. 1720 Interval timers should be implemented to avoid drift. In 1721 some router implementations, packet processing can affect 1722 timer execution. When multiple routers are attached to a 1723 single network, all doing broadcasts, this can lead to the 1724 synchronization of routing packets (which should be 1725 avoided). If timers cannot be implemented to avoid drift, 1726 small random amounts should be added to/subtracted from the 1727 interval timer at each firing. 1729 IP multicast 1730 Certain OSPF packets take the form of IP multicast 1731 datagrams. Support for receiving and sending IP multicast 1732 datagrams, along with the appropriate lower-level protocol 1733 support, is required. The IP multicast datagrams used by 1734 OSPF never travel more than one hop. For this reason, the 1735 ability to forward IP multicast datagrams is not required. 1736 For information on IP multicast, see [Ref7]. 1738 Variable-length subnet support 1739 The router's IP protocol support must include the ability to 1740 divide a single IP class A, B, or C network number into many 1741 subnets of various sizes. This is commonly called 1742 variable-length subnetting; see Section 3.5 for details. 1744 IP supernetting support 1745 The router's IP protocol support must include the ability to 1746 aggregate contiguous collections of IP class A, B, and C 1747 networks into larger quantities called supernets. 1748 Supernetting has been proposed as one way to improve the 1749 scaling of IP routing in the worldwide Internet. For more 1750 information on IP supernetting, see [Ref10]. 1752 Lower-level protocol support 1753 The lower level protocols referred to here are the network 1754 access protocols, such as the Ethernet data link layer. 1755 Indications must be passed from these protocols to OSPF as 1756 the network interface goes up and down. For example, on an 1757 ethernet it would be valuable to know when the ethernet 1758 transceiver cable becomes unplugged. 1760 Non-broadcast lower-level protocol support 1761 On non-broadcast networks, the OSPF Hello Protocol can be 1762 aided by providing an indication when an attempt is made to 1763 send a packet to a dead or non-existent router. For 1764 example, on an X.25 PDN a dead neighboring router may be 1765 indicated by the reception of a X.25 clear with an 1766 appropriate cause and diagnostic, and this information would 1767 be passed to OSPF. 1769 List manipulation primitives 1770 Much of the OSPF functionality is described in terms of its 1771 operation on lists of LSAs. For example, the collection of 1772 LSAs that will be retransmitted to an adjacent router until 1773 acknowledged are described as a list. Any particular LSA 1774 may be on many such lists. An OSPF implementation needs to 1775 be able to manipulate these lists, adding and deleting 1776 constituent LSAs as necessary. 1778 Tasking support 1779 Certain procedures described in this specification invoke 1780 other procedures. At times, these other procedures should 1781 be executed in-line, that is, before the current procedure 1782 is finished. This is indicated in the text by instructions 1783 to execute a procedure. At other times, the other 1784 procedures are to be executed only when the current 1785 procedure has finished. This is indicated by instructions 1786 to schedule a task. 1788 4.5. Optional OSPF capabilities 1790 The OSPF protocol defines several optional capabilities. A 1791 router indicates the optional capabilities that it supports in 1792 its OSPF Hello packets, Database Description packets and in its 1793 LSAs. This enables routers supporting a mix of optional 1794 capabilities to coexist in a single Autonomous System. 1796 Some capabilities must be supported by all routers attached to a 1797 specific area. In this case, a router will not accept a 1798 neighbor's Hello Packet unless there is a match in reported 1799 capabilities (i.e., a capability mismatch prevents a neighbor 1800 relationship from forming). An example of this is the 1801 ExternalRoutingCapability (see below). 1803 Other capabilities can be negotiated during the Database 1804 Exchange process. This is accomplished by specifying the 1805 optional capabilities in Database Description packets. A 1806 capability mismatch with a neighbor in this case will result in 1807 only a subset of the link state database being exchanged between 1808 the two neighbors. 1810 The routing table build process can also be affected by the 1811 presence/absence of optional capabilities. For example, since 1812 the optional capabilities are reported in LSAs, routers 1813 incapable of certain functions can be avoided when building the 1814 shortest path tree. 1816 The OSPF optional capabilities defined in this memo are listed 1817 below. See Section A.2 for more information. 1819 ExternalRoutingCapability 1820 Entire OSPF areas can be configured as "stubs" (see Section 1821 3.6). AS-external-LSAs will not be flooded into stub areas. 1822 This capability is represented by the E-bit in the OSPF 1823 Options field (see Section A.2). In order to ensure 1824 consistent configuration of stub areas, all routers 1825 interfacing to such an area must have the E-bit clear in 1826 their Hello packets (see Sections 9.5 and 10.5). 1828 5. Protocol Data Structures 1830 The OSPF protocol is described herein in terms of its operation on 1831 various protocol data structures. The following list comprises the 1832 top-level OSPF data structures. Any initialization that needs to be 1833 done is noted. OSPF areas, interfaces and neighbors also have 1834 associated data structures that are described later in this 1835 specification. 1837 Router ID 1838 A 32-bit number that uniquely identifies this router in the AS. 1839 One possible implementation strategy would be to use the 1840 smallest IP interface address belonging to the router. If a 1841 router's OSPF Router ID is changed, the router's OSPF software 1842 should be restarted before the new Router ID takes effect. In 1843 this case the router should flush its self-originated LSAs from 1844 the routing domain (see Section 14.1) before restarting, or they 1845 will persist for up to MaxAge minutes. 1847 Area structures 1848 Each one of the areas to which the router is connected has its 1849 own data structure. This data structure describes the working 1850 of the basic OSPF algorithm. Remember that each area runs a 1851 separate copy of the basic OSPF algorithm. 1853 Backbone (area) structure 1854 The OSPF backbone area is responsible for the dissemination of 1855 inter-area routing information. 1857 Virtual links configured 1858 The virtual links configured with this router as one endpoint. 1859 In order to have configured virtual links, the router itself 1860 must be an area border router. Virtual links are identified by 1861 the Router ID of the other endpoint -- which is another area 1862 border router. These two endpoint routers must be attached to a 1863 common area, called the virtual link's Transit area. Virtual 1864 links are part of the backbone, and behave as if they were 1865 unnumbered point-to-point networks between the two routers. A 1866 virtual link uses the intra-area routing of its Transit area to 1867 forward packets. Virtual links are brought up and down through 1868 the building of the shortest-path trees for the Transit area. 1870 List of external routes 1871 These are routes to destinations external to the Autonomous 1872 System, that have been gained either through direct experience 1873 with another routing protocol (such as BGP), or through 1874 configuration information, or through a combination of the two 1875 (e.g., dynamic external information to be advertised by OSPF 1876 with configured metric). Any router having these external routes 1877 is called an AS boundary router. These routes are advertised by 1878 the router into the OSPF routing domain via AS-external-LSAs. 1880 List of AS-external-LSAs 1881 Part of the link-state database. These have originated from the 1882 AS boundary routers. They comprise routes to destinations 1883 external to the Autonomous System. Note that, if the router is 1884 itself an AS boundary router, some of these AS-external-LSAs 1885 have been self-originated. 1887 The routing table 1888 Derived from the link-state database. Each entry in the routing 1889 table is indexed by a destination, and contains the 1890 destination's cost and a set of paths to use in forwarding 1891 packets to the destination. A path is described by its type and 1892 next hop. For more information, see Section 11. 1894 Figure 9 shows the collection of data structures present in a 1895 typical router. The router pictured is RT10, from the map in Figure 1896 6. Note that Router RT10 has a virtual link configured to Router 1897 RT11, with Area 2 as the link's Transit area. This is indicated by 1898 the dashed line in Figure 9. When the virtual link becomes active, 1899 through the building of the shortest path tree for Area 2, it 1900 becomes an interface to the backbone (see the two backbone 1901 interfaces depicted in Figure 9). 1903 +----+ 1904 |RT10|------+ 1905 +----+ \+-------------+ 1906 / \ |Routing Table| 1907 / \ +-------------+ 1908 / \ 1909 +------+ / \ +--------+ 1910 |Area 2|---+ +---|Backbone| 1911 +------+***********+ +--------+ 1912 / \ * / \ 1913 / \ * / \ 1914 +---------+ +---------+ +------------+ +------------+ 1915 |Interface| |Interface| |Virtual Link| |Interface Ib| 1916 | to N6 | | to N8 | | to RT11 | +------------+ 1917 +---------+ +---------+ +------------+ | 1918 / \ | | | 1919 / \ | | | 1920 +--------+ +--------+ | +-------------+ +------------+ 1921 |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| 1922 | RT8 | | RT7 | | +-------------+ +------------+ 1923 +--------+ +--------+ | 1924 | 1925 +-------------+ 1926 |Neighbor RT11| 1927 +-------------+ 1929 Figure 9: Router RT10's Data structures 1930 6. The Area Data Structure 1932 The area data structure contains all the information used to run the 1933 basic OSPF routing algorithm. Each area maintains its own link-state 1934 database. A network belongs to a single area, and a router interface 1935 connects to a single area. Each router adjacency also belongs to a 1936 single area. 1938 The OSPF backbone is the special OSPF area responsible for 1939 disseminating inter-area routing information. 1941 The area link-state database consists of the collection of router- 1942 LSAs, network-LSAs and summary-LSAs that have originated from the 1943 area's routers. This information is flooded throughout a single 1944 area only. The list of AS-external-LSAs (see Section 5) is also 1945 considered to be part of each area's link-state database. 1947 Area ID 1948 A 32-bit number identifying the area. The Area ID of 0.0.0.0 is 1949 reserved for the backbone. 1951 List of area address ranges 1952 In order to aggregate routing information at area boundaries, 1953 area address ranges can be employed. Each address range is 1954 specified by an [address,mask] pair and a status indication of 1955 either Advertise or DoNotAdvertise (see Section 12.4.3). 1957 Associated router interfaces 1958 This router's interfaces connecting to the area. A router 1959 interface belongs to one and only one area (or the backbone). 1960 For the backbone area this list includes all the virtual links. 1961 A virtual link is identified by the Router ID of its other 1962 endpoint; its cost is the cost of the shortest intra-area path 1963 through the Transit area that exists between the two routers. 1965 List of router-LSAs 1966 A router-LSA is generated by each router in the area. It 1967 describes the state of the router's interfaces to the area. 1969 List of network-LSAs 1970 One network-LSA is generated for each transit broadcast and NBMA 1971 network in the area. A network-LSA describes the set of routers 1972 currently connected to the network. 1974 List of summary-LSAs 1975 Summary-LSAs originate from the area's area border routers. 1976 They describe routes to destinations internal to the Autonomous 1977 System, yet external to the area (i.e., inter-area 1978 destinations). 1980 Shortest-path tree 1981 The shortest-path tree for the area, with this router itself as 1982 root. Derived from the collected router-LSAs and network-LSAs 1983 by the Dijkstra algorithm (see Section 16.1). 1985 TransitCapability 1986 This parameter indicates whether the area can carry data traffic 1987 that neither originates nor terminates in the area itself. This 1988 parameter is calculated when the area's shortest-path tree is 1989 built (see Section 16.1, where TransitCapability is set to TRUE 1990 if and only if there are one or more fully adjacent virtual 1991 links using the area as Transit area), and is used as an input 1992 to a subsequent step of the routing table build process (see 1993 Section 16.3). When an area's TransitCapability is set to TRUE, 1994 the area is said to be a "transit area". 1996 ExternalRoutingCapability 1997 Whether AS-external-LSAs will be flooded into/throughout the 1998 area. This is a configurable parameter. If AS-external-LSAs 1999 are excluded from the area, the area is called a "stub". Within 2000 stub areas, routing to AS external destinations will be based 2001 solely on a default summary route. The backbone cannot be 2002 configured as a stub area. Also, virtual links cannot be 2003 configured through stub areas. For more information, see 2004 Section 3.6. 2006 StubDefaultCost 2007 If the area has been configured as a stub area, and the router 2008 itself is an area border router, then the StubDefaultCost 2009 indicates the cost of the default summary-LSA that the router 2010 should advertise into the area. See Section 12.4.3 for more 2011 information. 2013 Unless otherwise specified, the remaining sections of this document 2014 refer to the operation of the OSPF protocol within a single area. 2016 7. Bringing Up Adjacencies 2018 OSPF creates adjacencies between neighboring routers for the purpose 2019 of exchanging routing information. Not every two neighboring 2020 routers will become adjacent. This section covers the generalities 2021 involved in creating adjacencies. For further details consult 2022 Section 10. 2024 7.1. The Hello Protocol 2026 The Hello Protocol is responsible for establishing and 2027 maintaining neighbor relationships. It also ensures that 2028 communication between neighbors is bidirectional. Hello packets 2029 are sent periodically out all router interfaces. Bidirectional 2030 communication is indicated when the router sees itself listed in 2031 the neighbor's Hello Packet. On broadcast and NBMA networks, 2032 the Hello Protocol elects a Designated Router for the network. 2034 The Hello Protocol works differently on broadcast networks, NBMA 2035 networks and Point-to-MultiPoint networks. On broadcast 2036 networks, each router advertises itself by periodically 2037 multicasting Hello Packets. This allows neighbors to be 2038 discovered dynamically. These Hello Packets contain the 2039 router's view of the Designated Router's identity, and the list 2040 of routers whose Hello Packets have been seen recently. 2042 On NBMA networks some configuration information may be necessary 2043 for the operation of the Hello Protocol. Each router that may 2044 potentially become Designated Router has a list of all other 2045 routers attached to the network. A router, having Designated 2046 Router potential, sends Hello Packets to all other potential 2047 Designated Routers when its interface to the NBMA network first 2048 becomes operational. This is an attempt to find the Designated 2049 Router for the network. If the router itself is elected 2050 Designated Router, it begins sending Hello Packets to all other 2051 routers attached to the network. 2053 On Point-to-MultiPoint networks, a router sends Hello Packets to 2054 all neighbors with which it can communicate directly. These 2055 neighbors may be discovered dynamically through a protocol such 2056 as Inverse ARP (see [Ref14]), or they may be configured. 2058 After a neighbor has been discovered, bidirectional 2059 communication ensured, and (if on a broadcast or NBMA network) a 2060 Designated Router elected, a decision is made regarding whether 2061 or not an adjacency should be formed with the neighbor (see 2062 Section 10.4). If an adjacency is to be formed, the first step 2063 is to synchronize the neighbors' link-state databases. This is 2064 covered in the next section. 2066 7.2. The Synchronization of Databases 2068 In a link-state routing algorithm, it is very important for all 2069 routers' link-state databases to stay synchronized. OSPF 2070 simplifies this by requiring only adjacent routers to remain 2071 synchronized. The synchronization process begins as soon as the 2072 routers attempt to bring up the adjacency. Each router 2073 describes its database by sending a sequence of Database 2074 Description packets to its neighbor. Each Database Description 2075 Packet describes a set of LSAs belonging to the router's 2076 database. When the neighbor sees an LSA that is more recent 2077 than its own database copy, it makes a note that this newer LSA 2078 should be requested. 2080 This sending and receiving of Database Description packets is 2081 called the "Database Exchange Process". During this process, 2082 the two routers form a master/slave relationship. Each Database 2083 Description Packet has a sequence number. Database Description 2084 Packets sent by the master (polls) are acknowledged by the slave 2085 through echoing of the sequence number. Both polls and their 2086 responses contain summaries of link state data. The master is 2087 the only one allowed to retransmit Database Description Packets. 2088 It does so only at fixed intervals, the length of which is the 2089 configured per-interface constant RxmtInterval. 2091 Each Database Description contains an indication that there are 2092 more packets to follow --- the M-bit. The Database Exchange 2093 Process is over when a router has received and sent Database 2094 Description Packets with the M-bit off. 2096 During and after the Database Exchange Process, each router has 2097 a list of those LSAs for which the neighbor has more up-to-date 2098 instances. These LSAs are requested in Link State Request 2099 Packets. Link State Request packets that are not satisfied are 2100 retransmitted at fixed intervals of time RxmtInterval. When the 2101 Database Description Process has completed and all Link State 2102 Requests have been satisfied, the databases are deemed 2103 synchronized and the routers are marked fully adjacent. At this 2104 time the adjacency is fully functional and is advertised in the 2105 two routers' router-LSAs. 2107 The adjacency is used by the flooding procedure as soon as the 2108 Database Exchange Process begins. This simplifies database 2109 synchronization, and guarantees that it finishes in a 2110 predictable period of time. 2112 7.3. The Designated Router 2114 Every broadcast and NBMA network has a Designated Router. The 2115 Designated Router performs two main functions for the routing 2116 protocol: 2118 o The Designated Router originates a network-LSA on behalf of 2119 the network. This LSA lists the set of routers (including 2120 the Designated Router itself) currently attached to the 2121 network. The Link State ID for this LSA (see Section 2122 12.1.4) is the IP interface address of the Designated 2123 Router. The IP network number can then be obtained by using 2124 the network's subnet/network mask. 2126 o The Designated Router becomes adjacent to all other routers 2127 on the network. Since the link state databases are 2128 synchronized across adjacencies (through adjacency bring-up 2129 and then the flooding procedure), the Designated Router 2130 plays a central part in the synchronization process. 2132 The Designated Router is elected by the Hello Protocol. A 2133 router's Hello Packet contains its Router Priority, which is 2134 configurable on a per-interface basis. In general, when a 2135 router's interface to a network first becomes functional, it 2136 checks to see whether there is currently a Designated Router for 2137 the network. If there is, it accepts that Designated Router, 2138 regardless of its Router Priority. (This makes it harder to 2139 predict the identity of the Designated Router, but ensures that 2140 the Designated Router changes less often. See below.) 2141 Otherwise, the router itself becomes Designated Router if it has 2142 the highest Router Priority on the network. A more detailed 2143 (and more accurate) description of Designated Router election is 2144 presented in Section 9.4. 2146 The Designated Router is the endpoint of many adjacencies. In 2147 order to optimize the flooding procedure on broadcast networks, 2148 the Designated Router multicasts its Link State Update Packets 2149 to the address AllSPFRouters, rather than sending separate 2150 packets over each adjacency. 2152 Section 2 of this document discusses the directed graph 2153 representation of an area. Router nodes are labelled with their 2154 Router ID. Transit network nodes are actually labelled with the 2155 IP address of their Designated Router. It follows that when the 2156 Designated Router changes, it appears as if the network node on 2157 the graph is replaced by an entirely new node. This will cause 2158 the network and all its attached routers to originate new LSAs. 2159 Until the link-state databases again converge, some temporary 2160 loss of connectivity may result. This may result in ICMP 2161 unreachable messages being sent in response to data traffic. 2162 For that reason, the Designated Router should change only 2163 infrequently. Router Priorities should be configured so that 2164 the most dependable router on a network eventually becomes 2165 Designated Router. 2167 7.4. The Backup Designated Router 2169 In order to make the transition to a new Designated Router 2170 smoother, there is a Backup Designated Router for each broadcast 2171 and NBMA network. The Backup Designated Router is also adjacent 2172 to all routers on the network, and becomes Designated Router 2173 when the previous Designated Router fails. If there were no 2174 Backup Designated Router, when a new Designated Router became 2175 necessary, new adjacencies would have to be formed between the 2176 new Designated Router and all other routers attached to the 2177 network. Part of the adjacency forming process is the 2178 synchronizing of link-state databases, which can potentially 2179 take quite a long time. During this time, the network would not 2180 be available for transit data traffic. The Backup Designated 2181 obviates the need to form these adjacencies, since they already 2182 exist. This means the period of disruption in transit traffic 2183 lasts only as long as it takes to flood the new LSAs (which 2184 announce the new Designated Router). 2186 The Backup Designated Router does not generate a network-LSA for 2187 the network. (If it did, the transition to a new Designated 2188 Router would be even faster. However, this is a tradeoff 2189 between database size and speed of convergence when the 2190 Designated Router disappears.) 2192 The Backup Designated Router is also elected by the Hello 2193 Protocol. Each Hello Packet has a field that specifies the 2194 Backup Designated Router for the network. 2196 In some steps of the flooding procedure, the Backup Designated 2197 Router plays a passive role, letting the Designated Router do 2198 more of the work. This cuts down on the amount of local routing 2199 traffic. See Section 13.3 for more information. 2201 7.5. The graph of adjacencies 2203 An adjacency is bound to the network that the two routers have 2204 in common. If two routers have multiple networks in common, 2205 they may have multiple adjacencies between them. 2207 One can picture the collection of adjacencies on a network as 2208 forming an undirected graph. The vertices consist of routers, 2209 with an edge joining two routers if they are adjacent. The 2210 graph of adjacencies describes the flow of routing protocol 2211 packets, and in particular Link State Update Packets, through 2212 the Autonomous System. 2214 Two graphs are possible, depending on whether a Designated 2215 Router is elected for the network. On physical point-to-point 2216 networks, Point-to-MultiPoint networks and virtual links, 2217 neighboring routers become adjacent whenever they can 2218 communicate directly. In contrast, on broadcast and NBMA 2219 networks only the Designated Router and the Backup Designated 2220 Router become adjacent to all other routers attached to the 2221 network. 2223 These graphs are shown in Figure 10. It is assumed that Router 2224 RT7 has become the Designated Router, and Router RT3 the Backup 2225 Designated Router, for the Network N2. The Backup Designated 2226 Router performs a lesser function during the flooding procedure 2227 than the Designated Router (see Section 13.3). This is the 2228 reason for the dashed lines connecting the Backup Designated 2229 Router RT3. 2231 +---+ +---+ 2232 |RT1|------------|RT2| o---------------o 2233 +---+ N1 +---+ RT1 RT2 2235 RT7 2236 o---------+ 2237 +---+ +---+ +---+ /|\ | 2238 |RT7| |RT3| |RT4| / | \ | 2239 +---+ +---+ +---+ / | \ | 2240 | | | / | \ | 2241 +-----------------------+ RT5o RT6o oRT4 | 2242 | | N2 * * * | 2243 +---+ +---+ * * * | 2244 |RT5| |RT6| * * * | 2245 +---+ +---+ *** | 2246 o---------+ 2247 RT3 2249 Figure 10: The graph of adjacencies 2250 8. Protocol Packet Processing 2252 This section discusses the general processing of OSPF routing 2253 protocol packets. It is very important that the router link-state 2254 databases remain synchronized. For this reason, routing protocol 2255 packets should get preferential treatment over ordinary data 2256 packets, both in sending and receiving. 2258 Routing protocol packets are sent along adjacencies only (with the 2259 exception of Hello packets, which are used to discover the 2260 adjacencies). This means that all routing protocol packets travel a 2261 single IP hop, except those sent over virtual links. 2263 All routing protocol packets begin with a standard header. The 2264 sections below provide details on how to fill in and verify this 2265 standard header. Then, for each packet type, the section giving 2266 more details on that particular packet type's processing is listed. 2268 8.1. Sending protocol packets 2270 When a router sends a routing protocol packet, it fills in the 2271 fields of the standard OSPF packet header as follows. For more 2272 details on the header format consult Section A.3.1: 2274 Version # 2275 Set to 2, the version number of the protocol as documented 2276 in this specification. 2278 Packet type 2279 The type of OSPF packet, such as Link state Update or Hello 2280 Packet. 2282 Packet length 2283 The length of the entire OSPF packet in bytes, including the 2284 standard OSPF packet header. 2286 Router ID 2287 The identity of the router itself (who is originating the 2288 packet). 2290 Area ID 2291 The OSPF area that the packet is being sent into. 2293 Checksum 2294 The standard IP 16-bit one's complement checksum of the 2295 entire OSPF packet, excluding the 64-bit authentication 2296 field. This checksum is calculated as part of the 2297 appropriate authentication procedure; for some OSPF 2298 authentication types, the checksum calculation is omitted. 2299 See Section D.4 for details. 2301 AuType and Authentication 2302 Each OSPF packet exchange is authenticated. Authentication 2303 types are assigned by the protocol and are documented in 2304 Appendix D. A different authentication procedure can be 2305 used for each IP network/subnet. Autype indicates the type 2306 of authentication procedure in use. The 64-bit 2307 authentication field is then for use by the chosen 2308 authentication procedure. This procedure should be the last 2309 called when forming the packet to be sent. See Section D.4 2310 for details. 2312 The IP destination address for the packet is selected as 2313 follows. On physical point-to-point networks, the IP 2314 destination is always set to the address AllSPFRouters. On all 2315 other network types (including virtual links), the majority of 2316 OSPF packets are sent as unicasts, i.e., sent directly to the 2317 other end of the adjacency. In this case, the IP destination is 2318 just the Neighbor IP address associated with the other end of 2319 the adjacency (see Section 10). The only packets not sent as 2320 unicasts are on broadcast networks; on these networks Hello 2321 packets are sent to the multicast destination AllSPFRouters, the 2322 Designated Router and its Backup send both Link State Update 2323 Packets and Link State Acknowledgment Packets to the multicast 2324 address AllSPFRouters, while all other routers send both their 2325 Link State Update and Link State Acknowledgment Packets to the 2326 multicast address AllDRouters. 2328 Retransmissions of Link State Update packets are ALWAYS sent 2329 directly to the neighbor. On multi-access networks, this means 2330 that retransmissions should be sent to the neighbor's IP 2331 address. 2333 The IP source address should be set to the IP address of the 2334 sending interface. Interfaces to unnumbered point-to-point 2335 networks have no associated IP address. On these interfaces, 2336 the IP source should be set to any of the other IP addresses 2337 belonging to the router. For this reason, there must be at 2338 least one IP address assigned to the router.[2] Note that, for 2339 most purposes, virtual links act precisely the same as 2340 unnumbered point-to-point networks. However, each virtual link 2341 does have an IP interface address (discovered during the routing 2342 table build process) which is used as the IP source when sending 2343 packets over the virtual link. 2345 For more information on the format of specific OSPF packet 2346 types, consult the sections listed in Table 10. 2348 Type Packet name detailed section (transmit) 2349 _________________________________________________________ 2350 1 Hello Section 9.5 2351 2 Database description Section 10.8 2352 3 Link state request Section 10.9 2353 4 Link state update Section 13.3 2354 5 Link state ack Section 13.5 2356 Table 10: Sections describing OSPF protocol packet transmission. 2358 8.2. Receiving protocol packets 2360 Whenever a protocol packet is received by the router it is 2361 marked with the interface it was received on. For routers that 2362 have virtual links configured, it may not be immediately obvious 2363 which interface to associate the packet with. For example, 2364 consider the Router RT11 depicted in Figure 6. If RT11 receives 2365 an OSPF protocol packet on its interface to Network N8, it may 2366 want to associate the packet with the interface to Area 2, or 2367 with the virtual link to Router RT10 (which is part of the 2368 backbone). In the following, we assume that the packet is 2369 initially associated with the non-virtual link.[3] 2371 In order for the packet to be accepted at the IP level, it must 2372 pass a number of tests, even before the packet is passed to OSPF 2373 for processing: 2375 o The IP checksum must be correct. 2377 o The packet's IP destination address must be the IP address 2378 of the receiving interface, or one of the IP multicast 2379 addresses AllSPFRouters or AllDRouters. 2381 o The IP protocol specified must be OSPF (89). 2383 o Locally originated packets should not be passed on to OSPF. 2384 That is, the source IP address should be examined to make 2385 sure this is not a multicast packet that the router itself 2386 generated. 2388 Next, the OSPF packet header is verified. The fields specified 2389 in the header must match those configured for the receiving 2390 interface. If they do not, the packet should be discarded: 2392 o The version number field must specify protocol version 2. 2394 o The Area ID found in the OSPF header must be verified. If 2395 both of the following cases fail, the packet should be 2396 discarded. The Area ID specified in the header must either: 2398 (1) Match the Area ID of the receiving interface. In this 2399 case, the packet has been sent over a single hop. 2400 Therefore, the packet's IP source address is required to 2401 be on the same network as the receiving interface. This 2402 can be verified by comparing the packet's IP source 2403 address to the interface's IP address, after masking 2404 both addresses with the interface mask. This comparison 2405 should not be performed on point-to-point networks. On 2406 point-to-point networks, the interface addresses of each 2407 end of the link are assigned independently, if they are 2408 assigned at all. 2410 (2) Indicate the backbone. In this case, the packet has 2411 been sent over a virtual link. The receiving router 2412 must be an area border router, and the Router ID 2413 specified in the packet (the source router) must be the 2414 other end of a configured virtual link. The receiving 2415 interface must also attach to the virtual link's 2416 configured Transit area. If all of these checks 2417 succeed, the packet is accepted and is from now on 2418 associated with the virtual link (and the backbone 2419 area). 2421 o Packets whose IP destination is AllDRouters should only be 2422 accepted if the state of the receiving interface is DR or 2423 Backup (see Section 9.1). 2425 o The AuType specified in the packet must match the AuType 2426 specified for the associated area. 2428 o The packet must be authenticated. The authentication 2429 procedure is indicated by the setting of AuType (see 2430 Appendix D). The authentication procedure may use one or 2431 more Authentication keys, which can be configured on a per- 2432 interface basis. The authentication procedure may also 2433 verify the checksum field in the OSPF packet header (which, 2434 when used, is set to the standard IP 16-bit one's complement 2435 checksum of the OSPF packet's contents after excluding the 2436 64-bit authentication field). If the authentication 2437 procedure fails, the packet should be discarded. 2439 If the packet type is Hello, it should then be further processed 2440 by the Hello Protocol (see Section 10.5). All other packet 2441 types are sent/received only on adjacencies. This means that 2442 the packet must have been sent by one of the router's active 2443 neighbors. If the receiving interface connects to a broadcast 2444 network, Point-to-MultiPoint network or NBMA network the sender 2445 is identified by the IP source address found in the packet's IP 2446 header. If the receiving interface connects to a point-to-point 2447 network or a virtual link, the sender is identified by the 2448 Router ID (source router) found in the packet's OSPF header. 2449 The data structure associated with the receiving interface 2450 contains the list of active neighbors. Packets not matching any 2451 active neighbor are discarded. 2453 At this point all received protocol packets are associated with 2454 an active neighbor. For the further input processing of 2455 specific packet types, consult the sections listed in Table 11. 2457 Type Packet name detailed section (receive) 2458 ________________________________________________________ 2459 1 Hello Section 10.5 2460 2 Database description Section 10.6 2461 3 Link state request Section 10.7 2462 4 Link state update Section 13 2463 5 Link state ack Section 13.7 2465 Table 11: Sections describing OSPF protocol packet reception. 2467 9. The Interface Data Structure 2469 An OSPF interface is the connection between a router and a network. 2470 We assume a single OSPF interface to each attached network/subnet, 2471 although supporting multiple interfaces on a single network is 2472 considered in Appendix F. Each interface structure has at most one 2473 IP interface address. 2475 An OSPF interface can be considered to belong to the area that 2476 contains the attached network. All routing protocol packets 2477 originated by the router over this interface are labelled with the 2478 interface's Area ID. One or more router adjacencies may develop 2479 over an interface. A router's LSAs reflect the state of its 2480 interfaces and their associated adjacencies. 2482 The following data items are associated with an interface. Note 2483 that a number of these items are actually configuration for the 2484 attached network; such items must be the same for all routers 2485 connected to the network. 2487 Type 2488 The OSPF interface type is either point-to-point, broadcast, 2489 NBMA, Point-to-MultiPoint or virtual link. 2491 State 2492 The functional level of an interface. State determines whether 2493 or not full adjacencies are allowed to form over the interface. 2494 State is also reflected in the router's LSAs. 2496 IP interface address 2497 The IP address associated with the interface. This appears as 2498 the IP source address in all routing protocol packets originated 2499 over this interface. Interfaces to unnumbered point-to-point 2500 networks do not have an associated IP address. 2502 IP interface mask 2503 Also referred to as the subnet mask, this indicates the portion 2504 of the IP interface address that identifies the attached 2505 network. Masking the IP interface address with the IP interface 2506 mask yields the IP network number of the attached network. On 2507 point-to-point networks and virtual links, the IP interface mask 2508 is not defined. On these networks, the link itself is not 2509 assigned an IP network number, and so the addresses of each side 2510 of the link are assigned independently, if they are assigned at 2511 all. 2513 Area ID 2514 The Area ID of the area to which the attached network belongs. 2515 All routing protocol packets originating from the interface are 2516 labelled with this Area ID. 2518 HelloInterval 2519 The length of time, in seconds, between the Hello packets that 2520 the router sends on the interface. Advertised in Hello packets 2521 sent out this interface. 2523 RouterDeadInterval 2524 The number of seconds before the router's neighbors will declare 2525 it down, when they stop hearing the router's Hello Packets. 2526 Advertised in Hello packets sent out this interface. 2528 InfTransDelay 2529 The estimated number of seconds it takes to transmit a Link 2530 State Update Packet over this interface. LSAs contained in the 2531 Link State Update packet will have their age incremented by this 2532 amount before transmission. This value should take into account 2533 transmission and propagation delays; it must be greater than 2534 zero. 2536 Router Priority 2537 An 8-bit unsigned integer. When two routers attached to a 2538 network both attempt to become Designated Router, the one with 2539 the highest Router Priority takes precedence. A router whose 2540 Router Priority is set to 0 is ineligible to become Designated 2541 Router on the attached network. Advertised in Hello packets 2542 sent out this interface. 2544 Hello Timer 2545 An interval timer that causes the interface to send a Hello 2546 packet. This timer fires every HelloInterval seconds. Note 2547 that on non-broadcast networks a separate Hello packet is sent 2548 to each qualified neighbor. 2550 Wait Timer 2551 A single shot timer that causes the interface to exit the 2552 Waiting state, and as a consequence select a Designated Router 2553 on the network. The length of the timer is RouterDeadInterval 2554 seconds. 2556 List of neighboring routers 2557 The other routers attached to this network. This list is formed 2558 by the Hello Protocol. Adjacencies will be formed to some of 2559 these neighbors. The set of adjacent neighbors can be 2560 determined by an examination of all of the neighbors' states. 2562 Designated Router 2563 The Designated Router selected for the attached network. The 2564 Designated Router is selected on all broadcast and NBMA networks 2565 by the Hello Protocol. Two pieces of identification are kept 2566 for the Designated Router: its Router ID and its IP interface 2567 address on the network. The Designated Router advertises link 2568 state for the network; this network-LSA is labelled with the 2569 Designated Router's IP address. The Designated Router is 2570 initialized to 0.0.0.0, which indicates the lack of a Designated 2571 Router. 2573 Backup Designated Router 2574 The Backup Designated Router is also selected on all broadcast 2575 and NBMA networks by the Hello Protocol. All routers on the 2576 attached network become adjacent to both the Designated Router 2577 and the Backup Designated Router. The Backup Designated Router 2578 becomes Designated Router when the current Designated Router 2579 fails. The Backup Designated Router is initialized to 0.0.0.0, 2580 indicating the lack of a Backup Designated Router. 2582 Interface output cost(s) 2583 The cost of sending a data packet on the interface, expressed in 2584 the link state metric. This is advertised as the link cost for 2585 this interface in the router-LSA. The cost of an interface must 2586 be greater than zero. 2588 RxmtInterval 2589 The number of seconds between LSA retransmissions, for 2590 adjacencies belonging to this interface. Also used when 2591 retransmitting Database Description and Link State Request 2592 Packets. 2594 AuType 2595 The type of authentication used on the attached network/subnet. 2596 Authentication types are defined in Appendix D. All OSPF packet 2597 exchanges are authenticated. Different authentication schemes 2598 may be used on different networks/subnets. 2600 Authentication key 2601 This configured data allows the authentication procedure to 2602 generate and/or verify OSPF protocol packets. The 2603 Authentication key can be configured on a per-interface basis. 2604 For example, if the AuType indicates simple password, the 2605 Authentication key would be a 64-bit clear password which is 2606 inserted into the OSPF packet header. If instead Autype 2607 indicates Cryptographic authentication, then the Authentication 2608 key is a shared secret which enables the generation/verification 2609 of message digests which are appended to the OSPF protocol 2610 packets. When Cryptographic authentication is used, multiple 2611 simultaneous keys are supported in order to achieve smooth key 2612 transition (see Section D.3). 2614 9.1. Interface states 2616 The various states that router interfaces may attain is 2617 documented in this section. The states are listed in order of 2618 progressing functionality. For example, the inoperative state 2619 is listed first, followed by a list of intermediate states 2620 before the final, fully functional state is achieved. The 2621 specification makes use of this ordering by sometimes making 2622 references such as "those interfaces in state greater than X". 2623 Figure 11 shows the graph of interface state changes. The arcs 2624 of the graph are labelled with the event causing the state 2625 change. These events are documented in Section 9.2. The 2626 interface state machine is described in more detail in Section 2627 9.3. 2629 Down 2630 This is the initial interface state. In this state, the 2631 lower-level protocols have indicated that the interface is 2632 unusable. No protocol traffic at all will be sent or 2633 received on such a interface. In this state, interface 2634 parameters should be set to their initial values. All 2636 +----+ UnloopInd +--------+ 2637 |Down|<--------------|Loopback| 2638 +----+ +--------+ 2639 | 2640 |InterfaceUp 2641 +-------+ | +--------------+ 2642 |Waiting|<-+-------------->|Point-to-point| 2643 +-------+ +--------------+ 2644 | 2645 WaitTimer|BackupSeen 2646 | 2647 | 2648 | NeighborChange 2649 +------+ +-+<---------------- +-------+ 2650 |Backup|<----------|?|----------------->|DROther| 2651 +------+---------->+-+<-----+ +-------+ 2652 Neighbor | | 2653 Change | |Neighbor 2654 | |Change 2655 | +--+ 2656 +---->|DR| 2657 +--+ 2659 Figure 11: Interface State changes 2661 In addition to the state transitions pictured, 2662 Event InterfaceDown always forces Down State, and 2663 Event LoopInd always forces Loopback State 2664 interface timers should be disabled, and there should be no 2665 adjacencies associated with the interface. 2667 Loopback 2668 In this state, the router's interface to the network is 2669 looped back. The interface may be looped back in hardware 2670 or software. The interface will be unavailable for regular 2671 data traffic. However, it may still be desirable to gain 2672 information on the quality of this interface, either through 2673 sending ICMP pings to the interface or through something 2674 like a bit error test. For this reason, IP packets may 2675 still be addressed to an interface in Loopback state. To 2676 facilitate this, such interfaces are advertised in router- 2677 LSAs as single host routes, whose destination is the IP 2678 interface address.[4] 2680 Waiting 2681 In this state, the router is trying to determine the 2682 identity of the (Backup) Designated Router for the network. 2683 To do this, the router monitors the Hello Packets it 2684 receives. The router is not allowed to elect a Backup 2685 Designated Router nor a Designated Router until it 2686 transitions out of Waiting state. This prevents unnecessary 2687 changes of (Backup) Designated Router. 2689 Point-to-point 2690 In this state, the interface is operational, and connects 2691 either to a physical point-to-point network or to a virtual 2692 link. Upon entering this state, the router attempts to form 2693 an adjacency with the neighboring router. Hello Packets are 2694 sent to the neighbor every HelloInterval seconds. 2696 DR Other 2697 The interface is to a broadcast or NBMA network on which 2698 another router has been selected to be the Designated 2699 Router. In this state, the router itself has not been 2700 selected Backup Designated Router either. The router forms 2701 adjacencies to both the Designated Router and the Backup 2702 Designated Router (if they exist). 2704 Backup 2705 In this state, the router itself is the Backup Designated 2706 Router on the attached network. It will be promoted to 2707 Designated Router when the present Designated Router fails. 2708 The router establishes adjacencies to all other routers 2709 attached to the network. The Backup Designated Router 2710 performs slightly different functions during the Flooding 2711 Procedure, as compared to the Designated Router (see Section 2712 13.3). See Section 7.4 for more details on the functions 2713 performed by the Backup Designated Router. 2715 DR In this state, this router itself is the Designated Router 2716 on the attached network. Adjacencies are established to all 2717 other routers attached to the network. The router must also 2718 originate a network-LSA for the network node. The network- 2719 LSA will contain links to all routers (including the 2720 Designated Router itself) attached to the network. See 2721 Section 7.3 for more details on the functions performed by 2722 the Designated Router. 2724 9.2. Events causing interface state changes 2726 State changes can be effected by a number of events. These 2727 events are pictured as the labelled arcs in Figure 11. The 2728 label definitions are listed below. For a detailed explanation 2729 of the effect of these events on OSPF protocol operation, 2730 consult Section 9.3. 2732 InterfaceUp 2733 Lower-level protocols have indicated that the network 2734 interface is operational. This enables the interface to 2735 transition out of Down state. On virtual links, the 2736 interface operational indication is actually a result of the 2737 shortest path calculation (see Section 16.7). 2739 WaitTimer 2740 The Wait Timer has fired, indicating the end of the waiting 2741 period that is required before electing a (Backup) 2742 Designated Router. 2744 BackupSeen 2745 The router has detected the existence or non-existence of a 2746 Backup Designated Router for the network. This is done in 2747 one of two ways. First, an Hello Packet may be received 2748 from a neighbor claiming to be itself the Backup Designated 2749 Router. Alternatively, an Hello Packet may be received from 2750 a neighbor claiming to be itself the Designated Router, and 2751 indicating that there is no Backup Designated Router. In 2752 either case there must be bidirectional communication with 2753 the neighbor, i.e., the router must also appear in the 2754 neighbor's Hello Packet. This event signals an end to the 2755 Waiting state. 2757 NeighborChange 2758 There has been a change in the set of bidirectional 2759 neighbors associated with the interface. The (Backup) 2760 Designated Router needs to be recalculated. The following 2761 neighbor changes lead to the NeighborChange event. For an 2762 explanation of neighbor states, see Section 10.1. 2764 o Bidirectional communication has been established to a 2765 neighbor. In other words, the state of the neighbor has 2766 transitioned to 2-Way or higher. 2768 o There is no longer bidirectional communication with a 2769 neighbor. In other words, the state of the neighbor has 2770 transitioned to Init or lower. 2772 o One of the bidirectional neighbors is newly declaring 2773 itself as either Designated Router or Backup Designated 2774 Router. This is detected through examination of that 2775 neighbor's Hello Packets. 2777 o One of the bidirectional neighbors is no longer 2778 declaring itself as Designated Router, or is no longer 2779 declaring itself as Backup Designated Router. This is 2780 again detected through examination of that neighbor's 2781 Hello Packets. 2783 o The advertised Router Priority for a bidirectional 2784 neighbor has changed. This is again detected through 2785 examination of that neighbor's Hello Packets. 2787 LoopInd 2788 An indication has been received that the interface is now 2789 looped back to itself. This indication can be received 2790 either from network management or from the lower level 2791 protocols. 2793 UnloopInd 2794 An indication has been received that the interface is no 2795 longer looped back. As with the LoopInd event, this 2796 indication can be received either from network management or 2797 from the lower level protocols. 2799 InterfaceDown 2800 Lower-level protocols indicate that this interface is no 2801 longer functional. No matter what the current interface 2802 state is, the new interface state will be Down. 2804 9.3. The Interface state machine 2806 A detailed description of the interface state changes follows. 2807 Each state change is invoked by an event (Section 9.2). This 2808 event may produce different effects, depending on the current 2809 state of the interface. For this reason, the state machine 2810 below is organized by current interface state and received 2811 event. Each entry in the state machine describes the resulting 2812 new interface state and the required set of additional actions. 2814 When an interface's state changes, it may be necessary to 2815 originate a new router-LSA. See Section 12.4 for more details. 2817 Some of the required actions below involve generating events for 2818 the neighbor state machine. For example, when an interface 2819 becomes inoperative, all neighbor connections associated with 2820 the interface must be destroyed. For more information on the 2821 neighbor state machine, see Section 10.3. 2823 State(s): Down 2825 Event: InterfaceUp 2827 New state: Depends upon action routine 2829 Action: Start the interval Hello Timer, enabling the 2830 periodic sending of Hello packets out the interface. 2831 If the attached network is a physical point-to-point 2832 network, Point-to-MultiPoint network or virtual 2833 link, the interface state transitions to Point-to- 2834 Point. Else, if the router is not eligible to 2835 become Designated Router the interface state 2836 transitions to DR Other. 2838 Otherwise, the attached network is a broadcast or 2839 NBMA network and the router is eligible to become 2840 Designated Router. In this case, in an attempt to 2841 discover the attached network's Designated Router 2842 the interface state is set to Waiting and the single 2843 shot Wait Timer is started. Additionally, if the 2844 network is an NBMA network examine the configured 2845 list of neighbors for this interface and generate 2846 the neighbor event Start for each neighbor that is 2847 also eligible to become Designated Router. 2849 State(s): Waiting 2851 Event: BackupSeen 2853 New state: Depends upon action routine. 2855 Action: Calculate the attached network's Backup Designated 2856 Router and Designated Router, as shown in Section 2857 9.4. As a result of this calculation, the new state 2858 of the interface will be either DR Other, Backup or 2859 DR. 2861 State(s): Waiting 2863 Event: WaitTimer 2865 New state: Depends upon action routine. 2867 Action: Calculate the attached network's Backup Designated 2868 Router and Designated Router, as shown in Section 2869 9.4. As a result of this calculation, the new state 2870 of the interface will be either DR Other, Backup or 2871 DR. 2873 State(s): DR Other, Backup or DR 2875 Event: NeighborChange 2877 New state: Depends upon action routine. 2879 Action: Recalculate the attached network's Backup Designated 2880 Router and Designated Router, as shown in Section 2881 9.4. As a result of this calculation, the new state 2882 of the interface will be either DR Other, Backup or 2883 DR. 2885 State(s): Any State 2887 Event: InterfaceDown 2889 New state: Down 2891 Action: All interface variables are reset, and interface 2892 timers disabled. Also, all neighbor connections 2893 associated with the interface are destroyed. This 2894 is done by generating the event KillNbr on all 2895 associated neighbors (see Section 10.2). 2897 State(s): Any State 2899 Event: LoopInd 2901 New state: Loopback 2903 Action: Since this interface is no longer connected to the 2904 attached network the actions associated with the 2905 above InterfaceDown event are executed. 2907 State(s): Loopback 2909 Event: UnloopInd 2911 New state: Down 2913 Action: No actions are necessary. For example, the 2914 interface variables have already been reset upon 2915 entering the Loopback state. Note that reception of 2916 an InterfaceUp event is necessary before the 2917 interface again becomes fully functional. 2919 9.4. Electing the Designated Router 2921 This section describes the algorithm used for calculating a 2922 network's Designated Router and Backup Designated Router. This 2923 algorithm is invoked by the Interface state machine. The 2924 initial time a router runs the election algorithm for a network, 2925 the network's Designated Router and Backup Designated Router are 2926 initialized to 0.0.0.0. This indicates the lack of both a 2927 Designated Router and a Backup Designated Router. 2929 The Designated Router election algorithm proceeds as follows: 2930 Call the router doing the calculation Router X. The list of 2931 neighbors attached to the network and having established 2932 bidirectional communication with Router X is examined. This 2933 list is precisely the collection of Router X's neighbors (on 2934 this network) whose state is greater than or equal to 2-Way (see 2935 Section 10.1). Router X itself is also considered to be on the 2936 list. Discard all routers from the list that are ineligible to 2937 become Designated Router. (Routers having Router Priority of 0 2938 are ineligible to become Designated Router.) The following 2939 steps are then executed, considering only those routers that 2940 remain on the list: 2942 (1) Note the current values for the network's Designated Router 2943 and Backup Designated Router. This is used later for 2944 comparison purposes. 2946 (2) Calculate the new Backup Designated Router for the network 2947 as follows. Only those routers on the list that have not 2948 declared themselves to be Designated Router are eligible to 2949 become Backup Designated Router. If one or more of these 2950 routers have declared themselves Backup Designated Router 2951 (i.e., they are currently listing themselves as Backup 2952 Designated Router, but not as Designated Router, in their 2953 Hello Packets) the one having highest Router Priority is 2954 declared to be Backup Designated Router. In case of a tie, 2955 the one having the highest Router ID is chosen. If no 2956 routers have declared themselves Backup Designated Router, 2957 choose the router having highest Router Priority, (again 2958 excluding those routers who have declared themselves 2959 Designated Router), and again use the Router ID to break 2960 ties. 2962 (3) Calculate the new Designated Router for the network as 2963 follows. If one or more of the routers have declared 2964 themselves Designated Router (i.e., they are currently 2965 listing themselves as Designated Router in their Hello 2966 Packets) the one having highest Router Priority is declared 2967 to be Designated Router. In case of a tie, the one having 2968 the highest Router ID is chosen. If no routers have 2969 declared themselves Designated Router, assign the Designated 2970 Router to be the same as the newly elected Backup Designated 2971 Router. 2973 (4) If Router X is now newly the Designated Router or newly the 2974 Backup Designated Router, or is now no longer the Designated 2975 Router or no longer the Backup Designated Router, repeat 2976 steps 2 and 3, and then proceed to step 5. For example, if 2977 Router X is now the Designated Router, when step 2 is 2978 repeated X will no longer be eligible for Backup Designated 2979 Router election. Among other things, this will ensure that 2980 no router will declare itself both Backup Designated Router 2981 and Designated Router.[5] 2983 (5) As a result of these calculations, the router itself may now 2984 be Designated Router or Backup Designated Router. See 2985 Sections 7.3 and 7.4 for the additional duties this would 2986 entail. The router's interface state should be set 2987 accordingly. If the router itself is now Designated Router, 2988 the new interface state is DR. If the router itself is now 2989 Backup Designated Router, the new interface state is Backup. 2990 Otherwise, the new interface state is DR Other. 2992 (6) If the attached network is an NBMA network, and the router 2993 itself has just become either Designated Router or Backup 2994 Designated Router, it must start sending Hello Packets to 2995 those neighbors that are not eligible to become Designated 2996 Router (see Section 9.5.1). This is done by invoking the 2997 neighbor event Start for each neighbor having a Router 2998 Priority of 0. 3000 (7) If the above calculations have caused the identity of either 3001 the Designated Router or Backup Designated Router to change, 3002 the set of adjacencies associated with this interface will 3003 need to be modified. Some adjacencies may need to be 3004 formed, and others may need to be broken. To accomplish 3005 this, invoke the event AdjOK? on all neighbors whose state 3006 is at least 2-Way. This will cause their eligibility for 3007 adjacency to be reexamined (see Sections 10.3 and 10.4). 3009 The reason behind the election algorithm's complexity is the 3010 desire for an orderly transition from Backup Designated Router 3011 to Designated Router, when the current Designated Router fails. 3012 This orderly transition is ensured through the introduction of 3013 hysteresis: no new Backup Designated Router can be chosen until 3014 the old Backup accepts its new Designated Router 3015 responsibilities. 3017 The above procedure may elect the same router to be both 3018 Designated Router and Backup Designated Router, although that 3019 router will never be the calculating router (Router X) itself. 3020 The elected Designated Router may not be the router having the 3021 highest Router Priority, nor will the Backup Designated Router 3022 necessarily have the second highest Router Priority. If Router 3023 X is not itself eligible to become Designated Router, it is 3024 possible that neither a Backup Designated Router nor a 3025 Designated Router will be selected in the above procedure. Note 3026 also that if Router X is the only attached router that is 3027 eligible to become Designated Router, it will select itself as 3028 Designated Router and there will be no Backup Designated Router 3029 for the network. 3031 9.5. Sending Hello packets 3033 Hello packets are sent out each functioning router interface. 3034 They are used to discover and maintain neighbor 3035 relationships.[6] On broadcast and NBMA networks, Hello Packets 3036 are also used to elect the Designated Router and Backup 3037 Designated Router. 3039 The format of an Hello packet is detailed in Section A.3.2. The 3040 Hello Packet contains the router's Router Priority (used in 3041 choosing the Designated Router), and the interval between Hello 3042 Packets sent out the interface (HelloInterval). The Hello 3043 Packet also indicates how often a neighbor must be heard from to 3044 remain active (RouterDeadInterval). Both HelloInterval and 3045 RouterDeadInterval must be the same for all routers attached to 3046 a common network. The Hello packet also contains the IP address 3047 mask of the attached network (Network Mask). On unnumbered 3048 point-to-point networks and on virtual links this field should 3049 be set to 0.0.0.0. 3051 The Hello packet's Options field describes the router's optional 3052 OSPF capabilities. One optional capability is defined in this 3053 specification (see Sections 4.5 and A.2). The E-bit of the 3054 Options field should be set if and only if the attached area is 3055 capable of processing AS-external-LSAs (i.e., it is not a stub 3056 area). If the E-bit is set incorrectly the neighboring routers 3057 will refuse to accept the Hello Packet (see Section 10.5). 3058 Unrecognized bits in the Hello Packet's Options field should be 3059 set to zero. 3061 In order to ensure two-way communication between adjacent 3062 routers, the Hello packet contains the list of all routers on 3063 the network from which Hello Packets have been seen recently. 3064 The Hello packet also contains the router's current choice for 3065 Designated Router and Backup Designated Router. A value of 3066 0.0.0.0 in these fields means that one has not yet been 3067 selected. 3069 On broadcast networks and physical point-to-point networks, 3070 Hello packets are sent every HelloInterval seconds to the IP 3071 multicast address AllSPFRouters. On virtual links, Hello 3072 packets are sent as unicasts (addressed directly to the other 3073 end of the virtual link) every HelloInterval seconds. On Point- 3074 to-MultiPoint networks, separate Hello packets are sent to each 3075 attached neighbor every HelloInterval seconds. Sending of Hello 3076 packets on NBMA networks is covered in the next section. 3078 9.5.1. Sending Hello packets on NBMA networks 3080 Static configuration information may be necessary in order 3081 for the Hello Protocol to function on non-broadcast networks 3082 (see Sections C.5 and C.6). On NBMA networks, every 3083 attached router which is eligible to become Designated 3084 Router becomes aware of all of its neighbors on the network 3085 (either through configuration or by some unspecified 3086 mechanism). Each neighbor is labelled with the neighbor's 3087 Designated Router eligibility. 3089 The interface state must be at least Waiting for any Hello 3090 Packets to be sent out the NBMA interface. Hello Packets 3091 are then sent directly (as unicasts) to some subset of a 3092 router's neighbors. Sometimes an Hello Packet is sent 3093 periodically on a timer; at other times it is sent as a 3094 response to a received Hello Packet. A router's hello- 3095 sending behavior varies depending on whether the router 3096 itself is eligible to become Designated Router. 3098 If the router is eligible to become Designated Router, it 3099 must periodically send Hello Packets to all neighbors that 3100 are also eligible. In addition, if the router is itself the 3101 Designated Router or Backup Designated Router, it must also 3102 send periodic Hello Packets to all other neighbors. This 3103 means that any two eligible routers are always exchanging 3104 Hello Packets, which is necessary for the correct operation 3105 of the Designated Router election algorithm. To minimize 3106 the number of Hello Packets sent, the number of eligible 3107 routers on an NBMA network should be kept small. 3109 If the router is not eligible to become Designated Router, 3110 it must periodically send Hello Packets to both the 3111 Designated Router and the Backup Designated Router (if they 3112 exist). It must also send an Hello Packet in reply to an 3113 Hello Packet received from any eligible neighbor (other than 3114 the current Designated Router and Backup Designated Router). 3115 This is needed to establish an initial bidirectional 3116 relationship with any potential Designated Router. 3118 When sending Hello packets periodically to any neighbor, the 3119 interval between Hello Packets is determined by the 3120 neighbor's state. If the neighbor is in state Down, Hello 3121 Packets are sent every PollInterval seconds. Otherwise, 3122 Hello Packets are sent every HelloInterval seconds. 3124 10. The Neighbor Data Structure 3126 An OSPF router converses with its neighboring routers. Each 3127 separate conversation is described by a "neighbor data structure". 3128 Each conversation is bound to a particular OSPF router interface, 3129 and is identified either by the neighboring router's OSPF Router ID 3130 or by its Neighbor IP address (see below). Thus if the OSPF router 3131 and another router have multiple attached networks in common, 3132 multiple conversations ensue, each described by a unique neighbor 3133 data structure. Each separate conversation is loosely referred to 3134 in the text as being a separate "neighbor". 3136 The neighbor data structure contains all information pertinent to 3137 the forming or formed adjacency between the two neighbors. 3138 (However, remember that not all neighbors become adjacent.) An 3139 adjacency can be viewed as a highly developed conversation between 3140 two routers. 3142 State 3143 The functional level of the neighbor conversation. This is 3144 described in more detail in Section 10.1. 3146 Inactivity Timer 3147 A single shot timer whose firing indicates that no Hello Packet 3148 has been seen from this neighbor recently. The length of the 3149 timer is RouterDeadInterval seconds. 3151 Master/Slave 3152 When the two neighbors are exchanging databases, they form a 3153 master/slave relationship. The master sends the first Database 3154 Description Packet, and is the only part that is allowed to 3155 retransmit. The slave can only respond to the master's Database 3156 Description Packets. The master/slave relationship is 3157 negotiated in state ExStart. 3159 DD Sequence Number 3160 The DD Sequence number of the Database Description packet that 3161 is currently being sent to the neighbor. 3163 Last received Database Description packet 3164 The initialize(I), more (M) and master(MS) bits, Options field, 3165 and DD sequence number contained in the last Database 3166 Description packet received from the neighbor. Used to determine 3167 whether the next Database Description packet received from the 3168 neighbor is a duplicate. 3170 Neighbor ID 3171 The OSPF Router ID of the neighboring router. The Neighbor ID 3172 is learned when Hello packets are received from the neighbor, or 3173 is configured if this is a virtual adjacency (see Section C.4). 3175 Neighbor Priority 3176 The Router Priority of the neighboring router. Contained in the 3177 neighbor's Hello packets, this item is used when selecting the 3178 Designated Router for the attached network. 3180 Neighbor IP address 3181 The IP address of the neighboring router's interface to the 3182 attached network. Used as the Destination IP address when 3183 protocol packets are sent as unicasts along this adjacency. 3184 Also used in router-LSAs as the Link ID for the attached network 3185 if the neighboring router is selected to be Designated Router 3186 (see Section 12.4.1). The Neighbor IP address is learned when 3187 Hello packets are received from the neighbor. For virtual 3188 links, the Neighbor IP address is learned during the routing 3189 table build process (see Section 15). 3191 Neighbor Options 3192 The optional OSPF capabilities supported by the neighbor. 3193 Learned during the Database Exchange process (see Section 10.6). 3194 The neighbor's optional OSPF capabilities are also listed in its 3195 Hello packets. This enables received Hello Packets to be 3196 rejected (i.e., neighbor relationships will not even start to 3197 form) if there is a mismatch in certain crucial OSPF 3198 capabilities (see Section 10.5). The optional OSPF capabilities 3199 are documented in Section 4.5. 3201 Neighbor's Designated Router 3202 The neighbor's idea of the Designated Router. If this is the 3203 neighbor itself, this is important in the local calculation of 3204 the Designated Router. Defined only on broadcast and NBMA 3205 networks. 3207 Neighbor's Backup Designated Router 3208 The neighbor's idea of the Backup Designated Router. If this is 3209 the neighbor itself, this is important in the local calculation 3210 of the Backup Designated Router. Defined only on broadcast and 3211 NBMA networks. 3213 The next set of variables are lists of LSAs. These lists describe 3214 subsets of the area link-state database. This memo defines five 3215 distinct types of LSAs, all of which may be present in an area 3216 link-state database: router-LSAs, network-LSAs, and Type 3 and 4 3217 summary-LSAs (all stored in the area data structure), and AS- 3218 external-LSAs (stored in the global data structure). 3220 Link state retransmission list 3221 The list of LSAs that have been flooded but not acknowledged on 3222 this adjacency. These will be retransmitted at intervals until 3223 they are acknowledged, or until the adjacency is destroyed. 3225 Database summary list 3226 The complete list of LSAs that make up the area link-state 3227 database, at the moment the neighbor goes into Database Exchange 3228 state. This list is sent to the neighbor in Database 3229 Description packets. 3231 Link state request list 3232 The list of LSAs that need to be received from this neighbor in 3233 order to synchronize the two neighbors' link-state databases. 3234 This list is created as Database Description packets are 3235 received, and is then sent to the neighbor in Link State Request 3236 packets. The list is depleted as appropriate Link State Update 3237 packets are received. 3239 10.1. Neighbor states 3241 The state of a neighbor (really, the state of a conversation 3242 being held with a neighboring router) is documented in the 3243 following sections. The states are listed in order of 3244 progressing functionality. For example, the inoperative state 3245 is listed first, followed by a list of intermediate states 3246 before the final, fully functional state is achieved. The 3247 specification makes use of this ordering by sometimes making 3248 references such as "those neighbors/adjacencies in state greater 3249 than X". Figures 12 and 13 show the graph of neighbor state 3250 changes. The arcs of the graphs are labelled with the event 3251 causing the state change. The neighbor events are documented in 3252 Section 10.2. 3254 The graph in Figure 12 shows the state changes effected by the 3255 Hello Protocol. The Hello Protocol is responsible for neighbor 3256 acquisition and maintenance, and for ensuring two way 3257 communication between neighbors. 3259 The graph in Figure 13 shows the forming of an adjacency. Not 3260 every two neighboring routers become adjacent (see Section 3261 10.4). The adjacency starts to form when the neighbor is in 3262 state ExStart. After the two routers discover their 3263 +----+ 3264 |Down| 3265 +----+ 3266 |\ 3267 | \Start 3268 | \ +-------+ 3269 Hello | +---->|Attempt| 3270 Received | +-------+ 3271 | | 3272 +----+<-+ |HelloReceived 3273 |Init|<---------------+ 3274 +----+<--------+ 3275 | | 3276 |2-Way |1-Way 3277 |Received |Received 3278 | | 3279 +-------+ | +-----+ 3280 |ExStart|<--------+------->|2-Way| 3281 +-------+ +-----+ 3283 Figure 12: Neighbor state changes (Hello Protocol) 3285 In addition to the state transitions pictured, 3286 Event KillNbr always forces Down State, 3287 Event InactivityTimer always forces Down State, 3288 Event LLDown always forces Down State 3289 +-------+ 3290 |ExStart| 3291 +-------+ 3292 | 3293 NegotiationDone| 3294 +->+--------+ 3295 |Exchange| 3296 +--+--------+ 3297 | 3298 Exchange| 3299 Done | 3300 +----+ | +-------+ 3301 |Full|<---------+----->|Loading| 3302 +----+<-+ +-------+ 3303 | LoadingDone | 3304 +------------------+ 3306 Figure 13: Neighbor state changes (Database Exchange) 3308 In addition to the state transitions pictured, 3309 Event SeqNumberMismatch forces ExStart state, 3310 Event BadLSReq forces ExStart state, 3311 Event 1-Way forces Init state, 3312 Event KillNbr always forces Down State, 3313 Event InactivityTimer always forces Down State, 3314 Event LLDown always forces Down State, 3315 Event AdjOK? leads to adjacency forming/breaking 3317 master/slave status, the state transitions to Exchange. At this 3318 point the neighbor starts to be used in the flooding procedure, 3319 and the two neighboring routers begin synchronizing their 3320 databases. When this synchronization is finished, the neighbor 3321 is in state Full and we say that the two routers are fully 3322 adjacent. At this point the adjacency is listed in LSAs. 3324 For a more detailed description of neighbor state changes, 3325 together with the additional actions involved in each change, 3326 see Section 10.3. 3328 Down 3329 This is the initial state of a neighbor conversation. It 3330 indicates that there has been no recent information received 3331 from the neighbor. On NBMA networks, Hello packets may 3332 still be sent to "Down" neighbors, although at a reduced 3333 frequency (see Section 9.5.1). 3335 Attempt 3336 This state is only valid for neighbors attached to NBMA 3337 networks. It indicates that no recent information has been 3338 received from the neighbor, but that a more concerted effort 3339 should be made to contact the neighbor. This is done by 3340 sending the neighbor Hello packets at intervals of 3341 HelloInterval (see Section 9.5.1). 3343 Init 3344 In this state, an Hello packet has recently been seen from 3345 the neighbor. However, bidirectional communication has not 3346 yet been established with the neighbor (i.e., the router 3347 itself did not appear in the neighbor's Hello packet). All 3348 neighbors in this state (or higher) are listed in the Hello 3349 packets sent from the associated interface. 3351 2-Way 3352 In this state, communication between the two routers is 3353 bidirectional. This has been assured by the operation of 3354 the Hello Protocol. This is the most advanced state short 3355 of beginning adjacency establishment. The (Backup) 3356 Designated Router is selected from the set of neighbors in 3357 state 2-Way or greater. 3359 ExStart 3360 This is the first step in creating an adjacency between the 3361 two neighboring routers. The goal of this step is to decide 3362 which router is the master, and to decide upon the initial 3363 DD sequence number. Neighbor conversations in this state or 3364 greater are called adjacencies. 3366 Exchange 3367 In this state the router is describing its entire link state 3368 database by sending Database Description packets to the 3369 neighbor. Each Database Description Packet has a DD 3370 sequence number, and is explicitly acknowledged. Only one 3371 Database Description Packet is allowed outstanding at any 3372 one time. In this state, Link State Request Packets may 3373 also be sent asking for the neighbor's more recent LSAs. 3374 All adjacencies in Exchange state or greater are used by the 3375 flooding procedure. In fact, these adjacencies are fully 3376 capable of transmitting and receiving all types of OSPF 3377 routing protocol packets. 3379 Loading 3380 In this state, Link State Request packets are sent to the 3381 neighbor asking for the more recent LSAs that have been 3382 discovered (but not yet received) in the Exchange state. 3384 Full 3385 In this state, the neighboring routers are fully adjacent. 3386 These adjacencies will now appear in router-LSAs and 3387 network-LSAs. 3389 10.2. Events causing neighbor state changes 3391 State changes can be effected by a number of events. These 3392 events are shown in the labels of the arcs in Figures 12 and 13. 3393 The label definitions are as follows: 3395 HelloReceived 3396 An Hello packet has been received from the neighbor. 3398 Start 3399 This is an indication that Hello Packets should now be sent 3400 to the neighbor at intervals of HelloInterval seconds. This 3401 event is generated only for neighbors associated with NBMA 3402 networks. 3404 2-WayReceived 3405 Bidirectional communication has been realized between the 3406 two neighboring routers. This is indicated by the router 3407 seeing itself in the neighbor's Hello packet. 3409 NegotiationDone 3410 The Master/Slave relationship has been negotiated, and DD 3411 sequence numbers have been exchanged. This signals the 3412 start of the sending/receiving of Database Description 3413 packets. For more information on the generation of this 3414 event, consult Section 10.8. 3416 ExchangeDone 3417 Both routers have successfully transmitted a full sequence 3418 of Database Description packets. Each router now knows what 3419 parts of its link state database are out of date. For more 3420 information on the generation of this event, consult Section 3421 10.8. 3423 BadLSReq 3424 A Link State Request has been received for an LSA not 3425 contained in the database. This indicates an error in the 3426 Database Exchange process. 3428 Loading Done 3429 Link State Updates have been received for all out-of-date 3430 portions of the database. This is indicated by the Link 3431 state request list becoming empty after the Database 3432 Exchange process has completed. 3434 AdjOK? 3435 A decision must be made as to whether an adjacency should be 3436 established/maintained with the neighbor. This event will 3437 start some adjacencies forming, and destroy others. 3439 The following events cause well developed neighbors to revert to 3440 lesser states. Unlike the above events, these events may occur 3441 when the neighbor conversation is in any of a number of states. 3443 SeqNumberMismatch 3444 A Database Description packet has been received that either 3445 a) has an unexpected DD sequence number, b) unexpectedly has 3446 the Init bit set or c) has an Options field differing from 3447 the last Options field received in a Database Description 3448 packet. Any of these conditions indicate that some error 3449 has occurred during adjacency establishment. 3451 1-Way 3452 An Hello packet has been received from the neighbor, in 3453 which the router is not mentioned. This indicates that 3454 communication with the neighbor is not bidirectional. 3456 KillNbr 3457 This is an indication that all communication with the 3458 neighbor is now impossible, forcing the neighbor to 3459 revert to Down state. 3461 InactivityTimer 3462 The inactivity Timer has fired. This means that no Hello 3463 packets have been seen recently from the neighbor. The 3464 neighbor reverts to Down state. 3466 LLDown 3467 This is an indication from the lower level protocols that 3468 the neighbor is now unreachable. For example, on an X.25 3469 network this could be indicated by an X.25 clear indication 3470 with appropriate cause and diagnostic fields. This event 3471 forces the neighbor into Down state. 3473 10.3. The Neighbor state machine 3475 A detailed description of the neighbor state changes follows. 3476 Each state change is invoked by an event (Section 10.2). This 3477 event may produce different effects, depending on the current 3478 state of the neighbor. For this reason, the state machine below 3479 is organized by current neighbor state and received event. Each 3480 entry in the state machine describes the resulting new neighbor 3481 state and the required set of additional actions. 3483 When a neighbor's state changes, it may be necessary to rerun 3484 the Designated Router election algorithm. This is determined by 3485 whether the interface NeighborChange event is generated (see 3486 Section 9.2). Also, if the Interface is in DR state (the router 3487 is itself Designated Router), changes in neighbor state may 3488 cause a new network-LSA to be originated (see Section 12.4). 3490 When the neighbor state machine needs to invoke the interface 3491 state machine, it should be done as a scheduled task (see 3492 Section 4.4). This simplifies things, by ensuring that neither 3493 state machine will be executed recursively. 3495 State(s): Down 3497 Event: Start 3499 New state: Attempt 3501 Action: Send an Hello Packet to the neighbor (this neighbor 3502 is always associated with an NBMA network) and start 3503 the Inactivity Timer for the neighbor. The timer's 3504 later firing would indicate that communication with 3505 the neighbor was not attained. 3507 State(s): Attempt 3509 Event: HelloReceived 3511 New state: Init 3513 Action: Restart the Inactivity Timer for the neighbor, since 3514 the neighbor has now been heard from. 3516 State(s): Down 3517 Event: HelloReceived 3519 New state: Init 3521 Action: Start the Inactivity Timer for the neighbor. The 3522 timer's later firing would indicate that the 3523 neighbor is dead. 3525 State(s): Init or greater 3527 Event: HelloReceived 3529 New state: No state change. 3531 Action: Restart the Inactivity Timer for the neighbor, since 3532 the neighbor has again been heard from. 3534 State(s): Init 3536 Event: 2-WayReceived 3538 New state: Depends upon action routine. 3540 Action: Determine whether an adjacency should be established 3541 with the neighbor (see Section 10.4). If not, the 3542 new neighbor state is 2-Way. 3544 Otherwise (an adjacency should be established) the 3545 neighbor state transitions to ExStart. Upon 3546 entering this state, the router increments the DD 3547 sequence number in the neighbor data structure. If 3548 this is the first time that an adjacency has been 3549 attempted, the DD sequence number should be assigned 3550 some unique value (like the time of day clock). It 3551 then declares itself master (sets the master/slave 3552 bit to master), and starts sending Database 3553 Description Packets, with the initialize (I), more 3554 (M) and master (MS) bits set. This Database 3555 Description Packet should be otherwise empty. This 3556 Database Description Packet should be retransmitted 3557 at intervals of RxmtInterval until the next state is 3558 entered (see Section 10.8). 3560 State(s): ExStart 3561 Event: NegotiationDone 3563 New state: Exchange 3565 Action: The router must list the contents of its entire area 3566 link state database in the neighbor Database summary 3567 list. The area link state database consists of the 3568 router-LSAs, network-LSAs and summary-LSAs contained 3569 in the area structure, along with the AS-external- 3570 LSAs contained in the global structure. AS- 3571 external-LSAs are omitted from a virtual neighbor's 3572 Database summary list. AS-external-LSAs are omitted 3573 from the Database summary list if the area has been 3574 configured as a stub (see Section 3.6). LSAs whose 3575 age is equal to MaxAge are instead added to the 3576 neighbor's Link state retransmission list. A 3577 summary of the Database summary list will be sent to 3578 the neighbor in Database Description packets. Each 3579 Database Description Packet has a DD sequence 3580 number, and is explicitly acknowledged. Only one 3581 Database Description Packet is allowed outstanding 3582 at any one time. For more detail on the sending and 3583 receiving of Database Description packets, see 3584 Sections 10.8 and 10.6. 3586 State(s): Exchange 3588 Event: ExchangeDone 3590 New state: Depends upon action routine. 3592 Action: If the neighbor Link state request list is empty, 3593 the new neighbor state is Full. No other action is 3594 required. This is an adjacency's final state. 3596 Otherwise, the new neighbor state is Loading. Start 3597 (or continue) sending Link State Request packets to 3598 the neighbor (see Section 10.9). These are requests 3599 for the neighbor's more recent LSAs (which were 3600 discovered but not yet received in the Exchange 3601 state). These LSAs are listed in the Link state 3602 request list associated with the neighbor. 3604 State(s): Loading 3605 Event: Loading Done 3607 New state: Full 3609 Action: No action required. This is an adjacency's final 3610 state. 3612 State(s): 2-Way 3614 Event: AdjOK? 3616 New state: Depends upon action routine. 3618 Action: Determine whether an adjacency should be formed with 3619 the neighboring router (see Section 10.4). If not, 3620 the neighbor state remains at 2-Way. Otherwise, 3621 transition the neighbor state to ExStart and perform 3622 the actions associated with the above state machine 3623 entry for state Init and event 2-WayReceived. 3625 State(s): ExStart or greater 3627 Event: AdjOK? 3629 New state: Depends upon action routine. 3631 Action: Determine whether the neighboring router should 3632 still be adjacent. If yes, there is no state change 3633 and no further action is necessary. 3635 Otherwise, the (possibly partially formed) adjacency 3636 must be destroyed. The neighbor state transitions 3637 to 2-Way. The Link state retransmission list, 3638 Database summary list and Link state request list 3639 are cleared of LSAs. 3641 State(s): Exchange or greater 3643 Event: SeqNumberMismatch 3645 New state: ExStart 3647 Action: The (possibly partially formed) adjacency is torn 3648 down, and then an attempt is made at 3649 reestablishment. The neighbor state first 3650 transitions to ExStart. The Link state 3651 retransmission list, Database summary list and Link 3652 state request list are cleared of LSAs. Then the 3653 router increments the DD sequence number in the 3654 neighbor data structure, declares itself master 3655 (sets the master/slave bit to master), and starts 3656 sending Database Description Packets, with the 3657 initialize (I), more (M) and master (MS) bits set. 3658 This Database Description Packet should be otherwise 3659 empty (see Section 10.8). 3661 State(s): Exchange or greater 3663 Event: BadLSReq 3665 New state: ExStart 3667 Action: The action for event BadLSReq is exactly the same as 3668 for the neighbor event SeqNumberMismatch. The 3669 (possibly partially formed) adjacency is torn down, 3670 and then an attempt is made at reestablishment. For 3671 more information, see the neighbor state machine 3672 entry that is invoked when event SeqNumberMismatch 3673 is generated in state Exchange or greater. 3675 State(s): Any state 3677 Event: KillNbr 3679 New state: Down 3681 Action: The Link state retransmission list, Database summary 3682 list and Link state request list are cleared of 3683 LSAs. Also, the Inactivity Timer is disabled. 3685 State(s): Any state 3687 Event: LLDown 3689 New state: Down 3691 Action: The Link state retransmission list, Database summary 3692 list and Link state request list are cleared of 3693 LSAs. Also, the Inactivity Timer is disabled. 3695 State(s): Any state 3697 Event: InactivityTimer 3699 New state: Down 3701 Action: The Link state retransmission list, Database summary 3702 list and Link state request list are cleared of 3703 LSAs. 3705 State(s): 2-Way or greater 3707 Event: 1-WayReceived 3709 New state: Init 3711 Action: The Link state retransmission list, Database summary 3712 list and Link state request list are cleared of 3713 LSAs. 3715 State(s): 2-Way or greater 3717 Event: 2-WayReceived 3719 New state: No state change. 3721 Action: No action required. 3723 State(s): Init 3725 Event: 1-WayReceived 3727 New state: No state change. 3729 Action: No action required. 3731 10.4. Whether to become adjacent 3733 Adjacencies are established with some subset of the router's 3734 neighbors. Routers connected by point-to-point networks, 3735 Point-to-MultiPoint networks and virtual links always become 3736 adjacent. On broadcast and NBMA networks, all routers become 3737 adjacent to both the Designated Router and the Backup Designated 3738 Router. 3740 The adjacency-forming decision occurs in two places in the 3741 neighbor state machine. First, when bidirectional communication 3742 is initially established with the neighbor, and secondly, when 3743 the identity of the attached network's (Backup) Designated 3744 Router changes. If the decision is made to not attempt an 3745 adjacency, the state of the neighbor communication stops at 2- 3746 Way. 3748 An adjacency should be established with a bidirectional neighbor 3749 when at least one of the following conditions holds: 3751 o The underlying network type is point-to-point 3753 o The underlying network type is Point-to-MultiPoint 3755 o The underlying network type is virtual link 3757 o The router itself is the Designated Router 3759 o The router itself is the Backup Designated Router 3761 o The neighboring router is the Designated Router 3763 o The neighboring router is the Backup Designated Router 3765 10.5. Receiving Hello Packets 3767 This section explains the detailed processing of a received 3768 Hello Packet. (See Section A.3.2 for the format of Hello 3769 packets.) The generic input processing of OSPF packets will 3770 have checked the validity of the IP header and the OSPF packet 3771 header. Next, the values of the Network Mask, HelloInterval, 3772 and RouterDeadInterval fields in the received Hello packet must 3773 be checked against the values configured for the receiving 3774 interface. Any mismatch causes processing to stop and the 3775 packet to be dropped. In other words, the above fields are 3776 really describing the attached network's configuration. However, 3777 there is one exception to the above rule: on point-to-point 3778 networks and on virtual links, the Network Mask in the received 3779 Hello Packet should be ignored. 3781 The receiving interface attaches to a single OSPF area (this 3782 could be the backbone). The setting of the E-bit found in the 3783 Hello Packet's Options field must match this area's 3784 ExternalRoutingCapability. If AS-external-LSAs are not flooded 3785 into/throughout the area (i.e, the area is a "stub") the E-bit 3786 must be clear in received Hello Packets, otherwise the E-bit 3787 must be set. A mismatch causes processing to stop and the 3788 packet to be dropped. The setting of the rest of the bits in 3789 the Hello Packet's Options field should be ignored. 3791 At this point, an attempt is made to match the source of the 3792 Hello Packet to one of the receiving interface's neighbors. If 3793 the receiving interface connects to a broadcast, Point-to- 3794 MultiPoint or NBMA network the source is identified by the IP 3795 source address found in the Hello's IP header. If the receiving 3796 interface connects to a point-to-point link or a virtual link, 3797 the source is identified by the Router ID found in the Hello's 3798 OSPF packet header. The interface's current list of neighbors 3799 is contained in the interface's data structure. If a matching 3800 neighbor structure cannot be found, (i.e., this is the first 3801 time the neighbor has been detected), one is created. The 3802 initial state of a newly created neighbor is set to Down. 3804 When receiving an Hello Packet from a neighbor on a broadcast, 3805 Point-to-MultiPoint or NBMA network, set the neighbor 3806 structure's Neighbor ID equal to the Router ID found in the 3807 packet's OSPF header. When receiving an Hello on a point-to- 3808 point network (but not on a virtual link) set the neighbor 3809 structure's Neighbor IP address to the packet's IP source 3810 address. 3812 Now the rest of the Hello Packet is examined, generating events 3813 to be given to the neighbor and interface state machines. These 3814 state machines are specified either to be executed or scheduled 3815 (see Section 4.4). For example, by specifying below that the 3816 neighbor state machine be executed in line, several neighbor 3817 state transitions may be effected by a single received Hello: 3819 o Each Hello Packet causes the neighbor state machine to be 3820 executed with the event HelloReceived. 3822 o Then the list of neighbors contained in the Hello Packet is 3823 examined. If the router itself appears in this list, the 3824 neighbor state machine should be executed with the event 2- 3825 WayReceived. Otherwise, the neighbor state machine should 3826 be executed with the event 1-WayReceived, and the processing 3827 of the packet stops. 3829 o Next, the Hello Packet's Router Priority field is examined. 3830 If this field is different than the one previously received 3831 from the neighbor, the receiving interface's state machine 3832 is scheduled with the event NeighborChange. In any case, 3833 the Router Priority field in the neighbor data structure 3834 should be updated accordingly. 3836 o Next the Designated Router field in the Hello Packet is 3837 examined. If the neighbor is both declaring itself to be 3838 Designated Router (Designated Router field = Neighbor IP 3839 address) and the Backup Designated Router field in the 3840 packet is equal to 0.0.0.0 and the receiving interface is in 3841 state Waiting, the receiving interface's state machine is 3842 scheduled with the event BackupSeen. Otherwise, if the 3843 neighbor is declaring itself to be Designated Router and it 3844 had not previously, or the neighbor is not declaring itself 3845 Designated Router where it had previously, the receiving 3846 interface's state machine is scheduled with the event 3847 NeighborChange. In any case, the Neighbors' Designated 3848 Router item in the neighbor structure is updated 3849 accordingly. 3851 o Finally, the Backup Designated Router field in the Hello 3852 Packet is examined. If the neighbor is declaring itself to 3853 be Backup Designated Router (Backup Designated Router field 3854 = Neighbor IP address) and the receiving interface is in 3855 state Waiting, the receiving interface's state machine is 3856 scheduled with the event BackupSeen. Otherwise, if the 3857 neighbor is declaring itself to be Backup Designated Router 3858 and it had not previously, or the neighbor is not declaring 3859 itself Backup Designated Router where it had previously, the 3860 receiving interface's state machine is scheduled with the 3861 event NeighborChange. In any case, the Neighbor's Backup 3862 Designated Router item in the neighbor structure is updated 3863 accordingly. 3865 On NBMA networks, receipt of an Hello Packet may also cause an 3866 Hello Packet to be sent back to the neighbor in response. See 3867 Section 9.5.1 for more details. 3869 10.6. Receiving Database Description Packets 3871 This section explains the detailed processing of a received 3872 Database Description Packet. The incoming Database Description 3873 Packet has already been associated with a neighbor and receiving 3874 interface by the generic input packet processing (Section 8.2). 3875 Whether the Database Description packet should be accepted, and 3876 if so, how it should be further processed depends upon the 3877 neighbor state. 3879 If a Database Description packet is accepted, the following 3880 packet fields should be saved in the corresponding neighbor data 3881 structure under "last received Database Description packet": 3882 the packet's initialize(I), more (M) and master(MS) bits, 3883 Options field, and DD sequence number. If these fields are set 3884 identically in two consecutive Database Description packets 3885 received from the neighbor, the second Database Description 3886 packet is considered to be a "duplicate" in the processing 3887 described below. 3889 If the Interface MTU field in the Database Description packet 3890 indicates an IP datagram size that is larger than the router can 3891 accept on the receiving interface without fragmentation, the 3892 Database Description packet is rejected. Otherwise, if the 3893 neighbor state is: 3895 Down 3896 The packet should be rejected. 3898 Attempt 3899 The packet should be rejected. 3901 Init 3902 The neighbor state machine should be executed with the event 3903 2-WayReceived. This causes an immediate state change to 3904 either state 2-Way or state ExStart. If the new state is 3905 ExStart, the processing of the current packet should then 3906 continue in this new state by falling through to case 3907 ExStart below. 3909 2-Way 3910 The packet should be ignored. Database Description Packets 3911 are used only for the purpose of bringing up adjacencies.[7] 3913 ExStart 3914 If the received packet matches one of the following cases, 3915 then the neighbor state machine should be executed with the 3916 event NegotiationDone (causing the state to transition to 3917 Exchange), the packet's Options field should be recorded in 3918 the neighbor structure's Neighbor Options field and the 3919 packet should be accepted as next in sequence and processed 3920 further (see below). Otherwise, the packet should be 3921 ignored. 3923 o The initialize(I), more (M) and master(MS) bits are set, 3924 the contents of the packet are empty, and the neighbor's 3925 Router ID is larger than the router's own. In this case 3926 the router is now Slave. Set the master/slave bit to 3927 slave, and set the neighbor data structure's DD sequence 3928 number to that specified by the master. 3930 o The initialize(I) and master(MS) bits are off, the 3931 packet's DD sequence number equals the neighbor data 3932 structure's DD sequence number (indicating 3933 acknowledgment) and the neighbor's Router ID is smaller 3934 than the router's own. In this case the router is 3935 Master. 3937 Exchange 3938 Duplicate Database Description packets are discarded by the 3939 master, and cause the slave to retransmit the last Database 3940 Description packet that it had sent. Otherwise (the packet 3941 is not a duplicate): 3943 o If the state of the MS-bit is inconsistent with the 3944 master/slave state of the connection, generate the 3945 neighbor event SeqNumberMismatch and stop processing the 3946 packet. 3948 o If the initialize(I) bit is set, generate the neighbor 3949 event SeqNumberMismatch and stop processing the packet. 3951 o If the packet's Options field indicates a different set 3952 of optional OSPF capabilities than were previously 3953 received from the neighbor (recorded in the Neighbor 3954 Options field of the neighbor structure), generate the 3955 neighbor event SeqNumberMismatch and stop processing the 3956 packet. 3958 o Database Description packets must be processed in 3959 sequence, as indicated by the packets' DD sequence 3960 numbers. If the router is master, the next packet 3961 received should have DD sequence number equal to the DD 3962 sequence number in the neighbor data structure. If the 3963 router is slave, the next packet received should have DD 3964 sequence number equal to one more than the DD sequence 3965 number stored in the neighbor data structure. In either 3966 case, if the packet is the next in sequence it should be 3967 accepted and its contents processed as specified below. 3969 o Else, generate the neighbor event SeqNumberMismatch and 3970 stop processing the packet. 3972 Loading or Full 3973 In this state, the router has sent and received an entire 3974 sequence of Database Description Packets. The only packets 3975 received should be duplicates (see above). In particular, 3976 the packet's Options field should match the set of optional 3977 OSPF capabilities previously indicated by the neighbor 3978 (stored in the neighbor structure's Neighbor Options field). 3979 Any other packets received, including the reception of a 3980 packet with the Initialize(I) bit set, should generate the 3981 neighbor event SeqNumberMismatch.[8] Duplicates should be 3982 discarded by the master. The slave must respond to 3983 duplicates by repeating the last Database Description packet 3984 that it had sent. 3986 When the router accepts a received Database Description Packet 3987 as the next in sequence the packet contents are processed as 3988 follows. For each LSA listed, the LSA's LS type is checked for 3989 validity. If the LS type is unknown (e.g., not one of the LS 3990 types 1-5 defined by this specification), or if this is an AS- 3991 external-LSA (LS type = 5) and the neighbor is associated with a 3992 stub area, generate the neighbor event SeqNumberMismatch and 3993 stop processing the packet. Otherwise, the router looks up the 3994 LSA in its database to see whether it also has an instance of 3995 the LSA. If it does not, or if the database copy is less recent 3996 (see Section 13.1), the LSA is put on the Link state request 3997 list so that it can be requested (immediately or at some later 3998 time) in Link State Request Packets. 4000 When the router accepts a received Database Description Packet 4001 as the next in sequence, it also performs the following actions, 4002 depending on whether it is master or slave: 4004 Master 4005 Increments the DD sequence number in the neighbor data 4006 structure. If the router has already sent its entire 4007 sequence of Database Description Packets, and the just 4008 accepted packet has the more bit (M) set to 0, the neighbor 4009 event ExchangeDone is generated. Otherwise, it should send 4010 a new Database Description to the slave. 4012 Slave 4013 Sets the DD sequence number in the neighbor data structure 4014 to the DD sequence number appearing in the received packet. 4015 The slave must send a Database Description Packet in reply. 4016 If the received packet has the more bit (M) set to 0, and 4017 the packet to be sent by the slave will also have the M-bit 4018 set to 0, the neighbor event ExchangeDone is generated. 4019 Note that the slave always generates this event before the 4020 master. 4022 10.7. Receiving Link State Request Packets 4024 This section explains the detailed processing of received Link 4025 State Request packets. Received Link State Request Packets 4026 specify a list of LSAs that the neighbor wishes to receive. 4027 Link State Request Packets should be accepted when the neighbor 4028 is in states Exchange, Loading, or Full. In all other states 4029 Link State Request Packets should be ignored. 4031 Each LSA specified in the Link State Request packet should be 4032 located in the router's database, and copied into Link State 4033 Update packets for transmission to the neighbor. These LSAs 4034 should NOT be placed on the Link state retransmission list for 4035 the neighbor. If an LSA cannot be found in the database, 4036 something has gone wrong with the Database Exchange process, and 4037 neighbor event BadLSReq should be generated. 4039 10.8. Sending Database Description Packets 4041 This section describes how Database Description Packets are sent 4042 to a neighbor. The Database Description packet's Interface MTU 4043 field is set to the size of the largest IP datagram that can be 4044 sent out the sending interface, without fragmentation. Common 4045 MTUs in use in the Internet can be found in Table 7-1 of 4046 [Ref22]. Interface MTU should be set to 0 in Database 4047 Description packets sent over virtual links. 4049 The router's optional OSPF capabilities (see Section 4.5) are 4050 transmitted to the neighbor in the Options field of the Database 4051 Description packet. The router should maintain the same set of 4052 optional capabilities throughout the Database Exchange and 4053 flooding procedures. If for some reason the router's optional 4054 capabilities change, the Database Exchange procedure should be 4055 restarted by reverting to neighbor state ExStart. One optional 4056 capability is defined in this specification (see Sections 4.5 4057 and A.2). The E-bit should be set if and only if the attached 4058 network belongs to a non-stub area. Unrecognized bits in the 4059 Options field should be set to zero. 4061 The sending of Database Description packets depends on the 4062 neighbor's state. In state ExStart the router sends empty 4063 Database Description packets, with the initialize (I), more (M) 4064 and master (MS) bits set. These packets are retransmitted every 4065 RxmtInterval seconds. 4067 In state Exchange the Database Description Packets actually 4068 contain summaries of the link state information contained in the 4069 router's database. Each LSA in the area's link-state database 4070 (at the time the neighbor transitions into Exchange state) is 4071 listed in the neighbor Database summary list. Each new Database 4072 Description Packet copies its DD sequence number from the 4073 neighbor data structure and then describes the current top of 4074 the Database summary list. Items are removed from the Database 4075 summary list when the previous packet is acknowledged. 4077 In state Exchange, the determination of when to send a Database 4078 Description packet depends on whether the router is master or 4079 slave: 4081 Master 4082 Database Description packets are sent when either a) the 4083 slave acknowledges the previous Database Description packet 4084 by echoing the DD sequence number or b) RxmtInterval seconds 4085 elapse without an acknowledgment, in which case the previous 4086 Database Description packet is retransmitted. 4088 Slave 4089 Database Description packets are sent only in response to 4090 Database Description packets received from the master. If 4091 the Database Description packet received from the master is 4092 new, a new Database Description packet is sent, otherwise 4093 the previous Database Description packet is resent. 4095 In states Loading and Full the slave must resend its last 4096 Database Description packet in response to duplicate Database 4097 Description packets received from the master. For this reason 4098 the slave must wait RouterDeadInterval seconds before freeing 4099 the last Database Description packet. Reception of a Database 4100 Description packet from the master after this interval will 4101 generate a SeqNumberMismatch neighbor event. 4103 10.9. Sending Link State Request Packets 4105 In neighbor states Exchange or Loading, the Link state request 4106 list contains a list of those LSAs that need to be obtained from 4107 the neighbor. To request these LSAs, a router sends the 4108 neighbor the beginning of the Link state request list, packaged 4109 in a Link State Request packet. 4111 When the neighbor responds to these requests with the proper 4112 Link State Update packet(s), the Link state request list is 4113 truncated and a new Link State Request packet is sent. This 4114 process continues until the Link state request list becomes 4115 empty. LSAs on the Link state request list that have been 4116 requested, but not yet received, are packaged into Link State 4117 Request packets for retransmission at intervals of RxmtInterval. 4118 There should be at most one Link State Request packet 4119 outstanding at any one time. 4121 When the Link state request list becomes empty, and the neighbor 4122 state is Loading (i.e., a complete sequence of Database 4123 Description packets has been sent to and received from the 4124 neighbor), the Loading Done neighbor event is generated. 4126 10.10. An Example 4128 Figure 14 shows an example of an adjacency forming. Routers RT1 4129 and RT2 are both connected to a broadcast network. It is 4130 assumed that RT2 is the Designated Router for the network, and 4131 that RT2 has a higher Router ID than Router RT1. 4133 The neighbor state changes realized by each router are listed on 4134 the sides of the figure. 4136 At the beginning of Figure 14, Router RT1's interface to the 4137 network becomes operational. It begins sending Hello Packets, 4138 although it doesn't know the identity of the Designated Router 4139 or of any other neighboring routers. Router RT2 hears this 4140 hello (moving the neighbor to Init state), and in its next Hello 4141 Packet indicates that it is itself the Designated Router and 4142 that it has heard Hello Packets from RT1. This in turn causes 4143 RT1 to go to state ExStart, as it starts to bring up the 4144 adjacency. 4146 RT1 begins by asserting itself as the master. When it sees that 4147 RT2 is indeed the master (because of RT2's higher Router ID), 4148 RT1 transitions to slave state and adopts its neighbor's DD 4149 sequence number. Database Description packets are then 4150 exchanged, with polls coming from the master (RT2) and responses 4151 from the slave (RT1). This sequence of Database Description 4152 Packets ends when both the poll and associated response has the 4153 M-bit off. 4155 In this example, it is assumed that RT2 has a completely up to 4156 date database. In that case, RT2 goes immediately into Full 4157 state. RT1 will go into Full state after updating the necessary 4158 parts of its database. This is done by sending Link State 4159 Request Packets, and receiving Link State Update Packets in 4160 response. Note that, while RT1 has waited until a complete set 4161 +---+ +---+ 4162 |RT1| |RT2| 4163 +---+ +---+ 4165 Down Down 4166 Hello(DR=0,seen=0) 4167 ------------------------------> 4168 Hello (DR=RT2,seen=RT1,...) Init 4169 <------------------------------ 4170 ExStart D-D (Seq=x,I,M,Master) 4171 ------------------------------> 4172 D-D (Seq=y,I,M,Master) ExStart 4173 <------------------------------ 4174 Exchange D-D (Seq=y,M,Slave) 4175 ------------------------------> 4176 D-D (Seq=y+1,M,Master) Exchange 4177 <------------------------------ 4178 D-D (Seq=y+1,M,Slave) 4179 ------------------------------> 4180 ... 4181 ... 4182 ... 4183 D-D (Seq=y+n, Master) 4184 <------------------------------ 4185 D-D (Seq=y+n, Slave) 4186 Loading ------------------------------> 4187 LS Request Full 4188 ------------------------------> 4189 LS Update 4190 <------------------------------ 4191 LS Request 4192 ------------------------------> 4193 LS Update 4194 <------------------------------ 4195 Full 4197 Figure 14: An adjacency bring-up example 4198 of Database Description Packets has been received (from RT2) 4199 before sending any Link State Request Packets, this need not be 4200 the case. RT1 could have interleaved the sending of Link State 4201 Request Packets with the reception of Database Description 4202 Packets. 4204 11. The Routing Table Structure 4206 The routing table data structure contains all the information 4207 necessary to forward an IP data packet toward its destination. Each 4208 routing table entry describes the collection of best paths to a 4209 particular destination. When forwarding an IP data packet, the 4210 routing table entry providing the best match for the packet's IP 4211 destination is located. The matching routing table entry then 4212 provides the next hop towards the packet's destination. OSPF also 4213 provides for the existence of a default route (Destination ID = 4214 DefaultDestination, Address Mask = 0x00000000). When the default 4215 route exists, it matches all IP destinations (although any other 4216 matching entry is a better match). Finding the routing table entry 4217 that best matches an IP destination is further described in Section 4218 11.1. 4220 There is a single routing table in each router. Two sample routing 4221 tables are described in Sections 11.2 and 11.3. The building of the 4222 routing table is discussed in Section 16. 4224 The rest of this section defines the fields found in a routing table 4225 entry. The first set of fields describes the routing table entry's 4226 destination. 4228 Destination Type 4229 Destination type is either "network" or "router". Only network 4230 entries are actually used when forwarding IP data traffic. 4231 Router routing table entries are used solely as intermediate 4232 steps in the routing table build process. 4234 A network is a range of IP addresses, to which IP data traffic 4235 may be forwarded. This includes IP networks (class A, B, or C), 4236 IP subnets, IP supernets and single IP hosts. The default route 4237 also falls into this category. 4239 Router entries are kept for area border routers and AS boundary 4240 routers. Routing table entries for area border routers are used 4241 when calculating the inter-area routes (see Section 16.2), and 4242 when maintaining configured virtual links (see Section 15). 4243 Routing table entries for AS boundary routers are used when 4244 calculating the AS external routes (see Section 16.4). 4246 Destination ID 4247 The destination's identifier or name. This depends on the 4248 Destination Type. For networks, the identifier is their 4249 associated IP address. For routers, the identifier is the OSPF 4250 Router ID.[9] 4252 Address Mask 4253 Only defined for networks. The network's IP address together 4254 with its address mask defines a range of IP addresses. For IP 4255 subnets, the address mask is referred to as the subnet mask. 4256 For host routes, the mask is "all ones" (0xffffffff). 4258 Optional Capabilities 4259 When the destination is a router this field indicates the 4260 optional OSPF capabilities supported by the destination router. 4261 The only optional capability defined by this specification is 4262 the ability to process AS-external-LSAs. For a further 4263 discussion of OSPF's optional capabilities, see Section 4.5. 4265 The set of paths to use for a destination may vary based on the OSPF 4266 area to which the paths belong. This means that there may be 4267 multiple routing table entries for the same destination, depending 4268 on the values of the next field. 4270 Area 4271 This field indicates the area whose link state information has 4272 led to the routing table entry's collection of paths. This is 4273 called the entry's associated area. For sets of AS external 4274 paths, this field is not defined. For destinations of type 4275 "router", there may be separate sets of paths (and therefore 4276 separate routing table entries) associated with each of several 4277 areas. For example, this will happen when two area border 4278 routers share multiple areas in common. For destinations of 4279 type "network", only the set of paths associated with the best 4280 area (the one providing the preferred route) is kept. 4282 The rest of the routing table entry describes the set of paths to 4283 the destination. The following fields pertain to the set of paths 4284 as a whole. In other words, each one of the paths contained in a 4285 routing table entry is of the same path-type and cost (see below). 4287 Path-type 4288 There are four possible types of paths used to route traffic to 4289 the destination, listed here in order of preference: intra-area, 4290 inter-area, type 1 external or type 2 external. Intra-area 4291 paths indicate destinations belonging to one of the router's 4292 attached areas. Inter-area paths are paths to destinations in 4293 other OSPF areas. These are discovered through the examination 4294 of received summary-LSAs. AS external paths are paths to 4295 destinations external to the AS. These are detected through the 4296 examination of received AS-external-LSAs. 4298 Cost 4299 The link state cost of the path to the destination. For all 4300 paths except type 2 external paths this describes the entire 4301 path's cost. For Type 2 external paths, this field describes 4302 the cost of the portion of the path internal to the AS. This 4303 cost is calculated as the sum of the costs of the path's 4304 constituent links. 4306 Type 2 cost 4307 Only valid for type 2 external paths. For these paths, this 4308 field indicates the cost of the path's external portion. This 4309 cost has been advertised by an AS boundary router, and is the 4310 most significant part of the total path cost. For example, a 4311 type 2 external path with type 2 cost of 5 is always preferred 4312 over a path with type 2 cost of 10, regardless of the cost of 4313 the two paths' internal components. 4315 Link State Origin 4316 Valid only for intra-area paths, this field indicates the LSA 4317 (router-LSA or network-LSA) that directly references the 4318 destination. For example, if the destination is a transit 4319 network, this is the transit network's network-LSA. If the 4320 destination is a stub network, this is the router-LSA for the 4321 attached router. The LSA is discovered during the shortest-path 4322 tree calculation (see Section 16.1). Multiple LSAs may 4323 reference the destination, however a tie-breaking scheme always 4324 reduces the choice to a single LSA. The Link State Origin field 4325 is not used by the OSPF protocol, but it is used by the routing 4326 table calculation in OSPF's Multicast routing extensions 4327 (MOSPF). 4329 When multiple paths of equal path-type and cost exist to a 4330 destination (called elsewhere "equal-cost" paths), they are stored 4331 in a single routing table entry. Each one of the "equal-cost" paths 4332 is distinguished by the following fields: 4334 Next hop 4335 The outgoing router interface to use when forwarding traffic to 4336 the destination. On broadcast, Point-to-MultiPoint and NBMA 4337 networks, the next hop also includes the IP address of the next 4338 router (if any) in the path towards the destination. 4340 Advertising router 4341 Valid only for inter-area and AS external paths. This field 4342 indicates the Router ID of the router advertising the summary- 4343 LSA or AS-external-LSA that led to this path. 4345 11.1. Routing table lookup 4347 When an IP data packet is received, an OSPF router finds the 4348 routing table entry that best matches the packet's destination. 4349 This routing table entry then provides the outgoing interface 4350 and next hop router to use in forwarding the packet. This 4351 section describes the process of finding the best matching 4352 routing table entry. The process consists of a number of steps, 4353 wherein the collection of routing table entries is progressively 4354 pruned. In the end, the single routing table entry remaining is 4355 called the "best match". 4357 Before the lookup begins, "discard" routing table entries should 4358 be inserted into the routing table for each of the router's 4359 active area address ranges (see Section 3.5). (An area range is 4360 considered "active" if the range contains one or more networks 4361 reachable by intra-area paths.) The destination of a "discard" 4362 entry is the set of addresses described by its associated active 4363 area address range, and the path type of each "discard" entry is 4364 set to "inter-area".[10] 4366 Note that the steps described below may fail to produce a best 4367 match routing table entry (i.e., all existing routing table 4368 entries are pruned for some reason or another), or the best 4369 match routing table entry may be one of the above "discard" 4370 routing table entries. In these cases, the packet's IP 4371 destination is considered unreachable. Instead of being 4372 forwarded, the packet should be discarded and an ICMP 4373 destination unreachable message should be returned to the 4374 packet's source. 4376 (1) Select the complete set of "matching" routing table entries 4377 from the routing table. Each routing table entry describes 4378 a (set of) path(s) to a range of IP addresses. If the data 4379 packet's IP destination falls into an entry's range of IP 4380 addresses, the routing table entry is called a match. (It is 4381 quite likely that multiple entries will match the data 4382 packet. For example, a default route will match all 4383 packets.) 4385 (2) Reduce the set of matching entries to those having the most 4386 preferential path-type (see Section 11). OSPF has a four 4387 level hierarchy of paths. Intra-area paths are the most 4388 preferred, followed in order by inter-area, type 1 external 4389 and type 2 external paths. 4391 (3) Select the remaining routing table entry that provides the 4392 most specific (longest) match. Another way of saying this is 4393 to choose the remaining entry that specifies the narrowest 4394 range of IP addresses.[11] For example, the entry for the 4395 address/mask pair of (128.185.1.0, 0xffffff00) is more 4396 specific than an entry for the pair (128.185.0.0, 4397 0xffff0000). The default route is the least specific match, 4398 since it matches all destinations. 4400 11.2. Sample routing table, without areas 4402 Consider the Autonomous System pictured in Figure 2. No OSPF 4403 areas have been configured. A single metric is shown per 4404 outbound interface. The calculation of Router RT6's routing 4405 table proceeds as described in Section 2.2. The resulting 4406 routing table is shown in Table 12. Destination types are 4407 abbreviated: Network as "N", Router as "R". 4409 There are no instances of multiple equal-cost shortest paths in 4410 this example. Also, since there are no areas, there are no 4411 inter-area paths. 4413 Routers RT5 and RT7 are AS boundary routers. Intra-area routes 4414 have been calculated to Routers RT5 and RT7. This allows 4415 external routes to be calculated to the destinations advertised 4416 by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is 4417 assumed all AS-external-LSAs originated by RT5 and RT7 are 4418 advertising type 1 external metrics. This results in type 1 4419 external paths being calculated to destinations N12-N15. 4421 11.3. Sample routing table, with areas 4423 Consider the previous example, this time split into OSPF areas. 4424 An OSPF area configuration is pictured in Figure 6. Router 4425 Type Dest Area Path Type Cost Next Adv. 4426 Hop(s) Router(s) 4427 ____________________________________________________________ 4428 N N1 0 intra-area 10 RT3 * 4429 N N2 0 intra-area 10 RT3 * 4430 N N3 0 intra-area 7 RT3 * 4431 N N4 0 intra-area 8 RT3 * 4432 N Ib 0 intra-area 7 * * 4433 N Ia 0 intra-area 12 RT10 * 4434 N N6 0 intra-area 8 RT10 * 4435 N N7 0 intra-area 12 RT10 * 4436 N N8 0 intra-area 10 RT10 * 4437 N N9 0 intra-area 11 RT10 * 4438 N N10 0 intra-area 13 RT10 * 4439 N N11 0 intra-area 14 RT10 * 4440 N H1 0 intra-area 21 RT10 * 4441 R RT5 0 intra-area 6 RT5 * 4442 R RT7 0 intra-area 8 RT10 * 4443 ____________________________________________________________ 4444 N N12 * type 1 ext. 10 RT10 RT7 4445 N N13 * type 1 ext. 14 RT5 RT5 4446 N N14 * type 1 ext. 14 RT5 RT5 4447 N N15 * type 1 ext. 17 RT10 RT7 4449 Table 12: The routing table for Router RT6 4450 (no configured areas). 4452 RT4's routing table will be described for this area 4453 configuration. Router RT4 has a connection to Area 1 and a 4454 backbone connection. This causes Router RT4 to view the AS as 4455 the concatenation of the two graphs shown in Figures 7 and 8. 4456 The resulting routing table is displayed in Table 13. 4458 Again, Routers RT5 and RT7 are AS boundary routers. Routers 4459 RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 4460 there are two routing entries for the area border router RT3, 4461 since it has two areas in common with RT4 (Area 1 and the 4462 backbone). 4464 Backbone paths have been calculated to all area border routers. 4465 These are used when determining the inter-area routes. Note 4466 that all of the inter-area routes are associated with the 4467 backbone; this is always the case when the calculating router is 4468 itself an area border router. Routing information is condensed 4469 at area boundaries. In this example, we assume that Area 3 has 4470 been defined so that networks N9-N11 and the host route to H1 4471 are all condensed to a single route when advertised into the 4472 backbone (by Router RT11). Note that the cost of this route is 4473 the maximum of the set of costs to its individual components. 4475 There is a virtual link configured between Routers RT10 and 4476 RT11. Without this configured virtual link, RT11 would be 4477 unable to advertise a route for networks N9-N11 and Host H1 into 4478 the backbone, and there would not be an entry for these networks 4479 in Router RT4's routing table. 4481 In this example there are two equal-cost paths to Network N12. 4482 However, they both use the same next hop (Router RT5). 4484 Router RT4's routing table would improve (i.e., some of the 4485 paths in the routing table would become shorter) if an 4486 additional virtual link were configured between Router RT4 and 4487 Router RT3. The new virtual link would itself be associated 4488 with the first entry for area border router RT3 in Table 13 (an 4489 intra-area path through Area 1). This would yield a cost of 1 4490 for the virtual link. The routing table entries changes that 4491 would be caused by the addition of this virtual link are shown 4492 in Table 14. 4494 12. Link State Advertisements (LSAs) 4496 Each router in the Autonomous System originates one or more link 4497 state advertisements (LSAs). This memo defines five distinct types 4498 of LSAs, which are described in Section 4.3. The collection of LSAs 4499 forms the link-state database. Each separate type of LSA has a 4500 separate function. Router-LSAs and network-LSAs describe how an 4501 area's routers and networks are interconnected. Summary-LSAs 4502 provide a way of condensing an area's routing information. AS- 4503 external-LSAs provide a way of transparently advertising 4504 externally-derived routing information throughout the Autonomous 4505 System. 4507 Each LSA begins with a standard 20-byte header. This LSA header is 4508 discussed below. 4510 Type Dest Area Path Type Cost Next Adv. 4511 Hops(s) Router(s) 4512 __________________________________________________________________ 4513 N N1 1 intra-area 4 RT1 * 4514 N N2 1 intra-area 4 RT2 * 4515 N N3 1 intra-area 1 * * 4516 N N4 1 intra-area 3 RT3 * 4517 R RT3 1 intra-area 1 * * 4518 __________________________________________________________________ 4519 N Ib 0 intra-area 22 RT5 * 4520 N Ia 0 intra-area 27 RT5 * 4521 R RT3 0 intra-area 21 RT5 * 4522 R RT5 0 intra-area 8 * * 4523 R RT7 0 intra-area 14 RT5 * 4524 R RT10 0 intra-area 22 RT5 * 4525 R RT11 0 intra-area 25 RT5 * 4526 __________________________________________________________________ 4527 N N6 0 inter-area 15 RT5 RT7 4528 N N7 0 inter-area 19 RT5 RT7 4529 N N8 0 inter-area 18 RT5 RT7 4530 N N9-N11,H1 0 inter-area 36 RT5 RT11 4531 __________________________________________________________________ 4532 N N12 * type 1 ext. 16 RT5 RT5,RT7 4533 N N13 * type 1 ext. 16 RT5 RT5 4534 N N14 * type 1 ext. 16 RT5 RT5 4535 N N15 * type 1 ext. 23 RT5 RT7 4537 Table 13: Router RT4's routing table 4538 in the presence of areas. 4540 Type Dest Area Path Type Cost Next Adv. 4541 Hop(s) Router(s) 4542 ________________________________________________________________ 4543 N Ib 0 intra-area 16 RT3 * 4544 N Ia 0 intra-area 21 RT3 * 4545 R RT3 0 intra-area 1 * * 4546 R RT10 0 intra-area 16 RT3 * 4547 R RT11 0 intra-area 19 RT3 * 4548 ________________________________________________________________ 4549 N N9-N11,H1 0 inter-area 30 RT3 RT11 4551 Table 14: Changes resulting from an 4552 additional virtual link. 4554 12.1. The LSA Header 4556 The LSA header contains the LS type, Link State ID and 4557 Advertising Router fields. The combination of these three 4558 fields uniquely identifies the LSA. 4560 There may be several instances of an LSA present in the 4561 Autonomous System, all at the same time. It must then be 4562 determined which instance is more recent. This determination is 4563 made by examining the LS sequence, LS checksum and LS age 4564 fields. These fields are also contained in the 20-byte LSA 4565 header. 4567 Several of the OSPF packet types list LSAs. When the instance 4568 is not important, an LSA is referred to by its LS type, Link 4569 State ID and Advertising Router (see Link State Request 4570 Packets). Otherwise, the LS sequence number, LS age and LS 4571 checksum fields must also be referenced. 4573 A detailed explanation of the fields contained in the LSA header 4574 follows. 4576 12.1.1. LS age 4578 This field is the age of the LSA in seconds. It should be 4579 processed as an unsigned 16-bit integer. It is set to 0 4580 when the LSA is originated. It must be incremented by 4581 InfTransDelay on every hop of the flooding procedure. LSAs 4582 are also aged as they are held in each router's database. 4584 The age of an LSA is never incremented past MaxAge. LSAs 4585 having age MaxAge are not used in the routing table 4586 calculation. When an LSA's age first reaches MaxAge, it is 4587 reflooded. An LSA of age MaxAge is finally flushed from the 4588 database when it is no longer needed to ensure database 4589 synchronization. For more information on the aging of LSAs, 4590 consult Section 14. 4592 The LS age field is examined when a router receives two 4593 instances of an LSA, both having identical LS sequence 4594 numbers and LS checksums. An instance of age MaxAge is then 4595 always accepted as most recent; this allows old LSAs to be 4596 flushed quickly from the routing domain. Otherwise, if the 4597 ages differ by more than MaxAgeDiff, the instance having the 4598 smaller age is accepted as most recent.[12] See Section 13.1 4599 for more details. 4601 12.1.2. Options 4603 The Options field in the LSA header indicates which optional 4604 capabilities are associated with the LSA. OSPF's optional 4605 capabilities are described in Section 4.5. One optional 4606 capability is defined by this specification, represented by 4607 the E-bit found in the Options field. The unrecognized bits 4608 in the Options field should be set to zero. 4610 The E-bit represents OSPF's ExternalRoutingCapability. This 4611 bit should be set in all LSAs associated with the backbone, 4612 and all LSAs associated with non-stub areas (see Section 4613 3.6). It should also be set in all AS-external-LSAs. It 4614 should be reset in all router-LSAs, network-LSAs and 4615 summary-LSAs associated with a stub area. For all LSAs, the 4616 setting of the E-bit is for informational purposes only; it 4617 does not affect the routing table calculation. 4619 12.1.3. LS type 4621 The LS type field dictates the format and function of the 4622 LSA. LSAs of different types have different names (e.g., 4623 router-LSAs or network-LSAs). All LSA types defined by this 4624 memo, except the AS-external-LSAs (LS type = 5), are flooded 4625 throughout a single area only. AS-external-LSAs are flooded 4626 throughout the entire Autonomous System, excepting stub 4627 areas (see Section 3.6). Each separate LSA type is briefly 4628 described below in Table 15. 4630 LS Type LSA description 4631 ________________________________________________ 4632 1 These are the router-LSAs. 4633 They describe the collected 4634 states of the router's 4635 interfaces. For more information, 4636 consult Section 12.4.1. 4637 ________________________________________________ 4638 2 These are the network-LSAs. 4639 They describe the set of routers 4640 attached to the network. For 4641 more information, consult 4642 Section 12.4.2. 4643 ________________________________________________ 4644 3 or 4 These are the summary-LSAs. 4645 They describe inter-area routes, 4646 and enable the condensation of 4647 routing information at area 4648 borders. Originated by area border 4649 routers, the Type 3 summary-LSAs 4650 describe routes to networks while the 4651 Type 4 summary-LSAs describe routes to 4652 AS boundary routers. 4653 ________________________________________________ 4654 5 These are the AS-external-LSAs. 4655 Originated by AS boundary routers, 4656 they describe routes 4657 to destinations external to the 4658 Autonomous System. A default route for 4659 the Autonomous System can also be 4660 described by an AS-external-LSA. 4662 Table 15: OSPF link state advertisements (LSAs). 4664 12.1.4. Link State ID 4666 This field identifies the piece of the routing domain that 4667 is being described by the LSA. Depending on the LSA's LS 4668 type, the Link State ID takes on the values listed in Table 4669 16. 4671 Actually, for Type 3 summary-LSAs (LS type = 3) and AS- 4672 external-LSAs (LS type = 5), the Link State ID may 4673 additionally have one or more of the destination network's 4674 LS Type Link State ID 4675 _______________________________________________ 4676 1 The originating router's Router ID. 4677 2 The IP interface address of the 4678 network's Designated Router. 4679 3 The destination network's IP address. 4680 4 The Router ID of the described AS 4681 boundary router. 4682 5 The destination network's IP address. 4684 Table 16: The LSA's Link State ID. 4686 "host" bits set. For example, when originating an AS- 4687 external-LSA for the network 10.0.0.0 with mask of 4688 255.0.0.0, the Link State ID can be set to anything in the 4689 range 10.0.0.0 through 10.255.255.255 inclusive (although 4690 10.0.0.0 should be used whenever possible). The freedom to 4691 set certain host bits allows a router to originate separate 4692 LSAs for two networks having the same address but different 4693 masks. See Appendix E for details. 4695 When the LSA is describing a network (LS type = 2, 3 or 5), 4696 the network's IP address is easily derived by masking the 4697 Link State ID with the network/subnet mask contained in the 4698 body of the LSA. When the LSA is describing a router (LS 4699 type = 1 or 4), the Link State ID is always the described 4700 router's OSPF Router ID. 4702 When an AS-external-LSA (LS Type = 5) is describing a 4703 default route, its Link State ID is set to 4704 DefaultDestination (0.0.0.0). 4706 12.1.5. Advertising Router 4708 This field specifies the OSPF Router ID of the LSA's 4709 originator. For router-LSAs, this field is identical to the 4710 Link State ID field. Network-LSAs are originated by the 4711 network's Designated Router. Summary-LSAs originated by 4712 area border routers. AS-external-LSAs are originated by AS 4713 boundary routers. 4715 12.1.6. LS sequence number 4717 The sequence number field is a signed 32-bit integer. It is 4718 used to detect old and duplicate LSAs. The space of 4719 sequence numbers is linearly ordered. The larger the 4720 sequence number (when compared as signed 32-bit integers) 4721 the more recent the LSA. To describe to sequence number 4722 space more precisely, let N refer in the discussion below to 4723 the constant 2**31. 4725 The sequence number -N (0x80000000) is reserved (and 4726 unused). This leaves -N + 1 (0x80000001) as the smallest 4727 (and therefore oldest) sequence number; this sequence number 4728 is referred to as the constant InitialSequenceNumber. A 4729 router uses InitialSequenceNumber the first time it 4730 originates any LSA. Afterwards, the LSA's sequence number 4731 is incremented each time the router originates a new 4732 instance of the LSA. When an attempt is made to increment 4733 the sequence number past the maximum value of N - 1 4734 (0x7fffffff; also referred to as MaxSequenceNumber), the 4735 current instance of the LSA must first be flushed from the 4736 routing domain. This is done by prematurely aging the LSA 4737 (see Section 14.1) and reflooding it. As soon as this flood 4738 has been acknowledged by all adjacent neighbors, a new 4739 instance can be originated with sequence number of 4740 InitialSequenceNumber. 4742 The router may be forced to promote the sequence number of 4743 one of its LSAs when a more recent instance of the LSA is 4744 unexpectedly received during the flooding process. This 4745 should be a rare event. This may indicate that an out-of- 4746 date LSA, originated by the router itself before its last 4747 restart/reload, still exists in the Autonomous System. For 4748 more information see Section 13.4. 4750 12.1.7. LS checksum 4752 This field is the checksum of the complete contents of the 4753 LSA, excepting the LS age field. The LS age field is 4754 excepted so that an LSA's age can be incremented without 4755 updating the checksum. The checksum used is the same that 4756 is used for ISO connectionless datagrams; it is commonly 4757 referred to as the Fletcher checksum. It is documented in 4758 Annex B of [Ref6]. The LSA header also contains the length 4759 of the LSA in bytes; subtracting the size of the LS age 4760 field (two bytes) yields the amount of data to checksum. 4762 The checksum is used to detect data corruption of an LSA. 4763 This corruption can occur while an LSA is being flooded, or 4764 while it is being held in a router's memory. The LS 4765 checksum field cannot take on the value of zero; the 4766 occurrence of such a value should be considered a checksum 4767 failure. In other words, calculation of the checksum is not 4768 optional. 4770 The checksum of an LSA is verified in two cases: a) when it 4771 is received in a Link State Update Packet and b) at times 4772 during the aging of the link state database. The detection 4773 of a checksum failure leads to separate actions in each 4774 case. See Sections 13 and 14 for more details. 4776 Whenever the LS sequence number field indicates that two 4777 instances of an LSA are the same, the LS checksum field is 4778 examined. If there is a difference, the instance with the 4779 larger LS checksum is considered to be most recent.[13] See 4780 Section 13.1 for more details. 4782 12.2. The link state database 4784 A router has a separate link state database for every area to 4785 which it belongs. All routers belonging to the same area have 4786 identical link state databases for the area. 4788 The databases for each individual area are always dealt with 4789 separately. The shortest path calculation is performed 4790 separately for each area (see Section 16). Components of the 4791 area link-state database are flooded throughout the area only. 4792 Finally, when an adjacency (belonging to Area A) is being 4793 brought up, only the database for Area A is synchronized between 4794 the two routers. 4796 The area database is composed of router-LSAs, network-LSAs and 4797 summary-LSAs (all listed in the area data structure). In 4798 addition, external routes (AS-external-LSAs) are included in all 4799 non-stub area databases (see Section 3.6). 4801 An implementation of OSPF must be able to access individual 4802 pieces of an area database. This lookup function is based on an 4803 LSA's LS type, Link State ID and Advertising Router.[14] There 4804 will be a single instance (the most up-to-date) of each LSA in 4805 the database. The database lookup function is invoked during 4806 the LSA flooding procedure (Section 13) and the routing table 4807 calculation (Section 16). In addition, using this lookup 4808 function the router can determine whether it has itself ever 4809 originated a particular LSA, and if so, with what LS sequence 4810 number. 4812 An LSA is added to a router's database when either a) it is 4813 received during the flooding process (Section 13) or b) it is 4814 originated by the router itself (Section 12.4). An LSA is 4815 deleted from a router's database when either a) it has been 4816 overwritten by a newer instance during the flooding process 4817 (Section 13) or b) the router originates a newer instance of one 4818 of its self-originated LSAs (Section 12.4) or c) the LSA ages 4819 out and is flushed from the routing domain (Section 14). 4820 Whenever an LSA is deleted from the database it must also be 4821 removed from all neighbors' Link state retransmission lists (see 4822 Section 10). 4824 12.3. Representation of TOS 4826 For backward compatibility with previous versions of the OSPF 4827 specification ([Ref9]), TOS-specific information can be included 4828 in router-LSAs, summary-LSAs and AS-external-LSAs. The encoding 4829 of TOS in OSPF LSAs is specified in Table 17. That table relates 4830 the OSPF encoding to the IP packet header's TOS field (defined 4831 in [Ref12]). The OSPF encoding is expressed as a decimal 4832 integer, and the IP packet header's TOS field is expressed in 4833 the binary TOS values used in [Ref12]. 4835 OSPF encoding RFC 1349 TOS values 4836 ___________________________________________ 4837 0 0000 normal service 4838 2 0001 minimize monetary cost 4839 4 0010 maximize reliability 4840 6 0011 4841 8 0100 maximize throughput 4842 10 0101 4843 12 0110 4844 14 0111 4845 16 1000 minimize delay 4846 18 1001 4847 20 1010 4848 22 1011 4849 24 1100 4850 26 1101 4851 28 1110 4852 30 1111 4854 Table 17: Representing TOS in OSPF. 4856 12.4. Originating LSAs 4858 Into any given OSPF area, a router will originate several LSAs. 4859 Each router originates a router-LSA. If the router is also the 4860 Designated Router for any of the area's networks, it will 4861 originate network-LSAs for those networks. 4863 Area border routers originate a single summary-LSA for each 4864 known inter-area destination. AS boundary routers originate a 4865 single AS-external-LSA for each known AS external destination. 4866 Destinations are advertised one at a time so that the change in 4867 any single route can be flooded without reflooding the entire 4868 collection of routes. During the flooding procedure, many LSAs 4869 can be carried by a single Link State Update packet. 4871 As an example, consider Router RT4 in Figure 6. It is an area 4872 border router, having a connection to Area 1 and the backbone. 4873 Router RT4 originates 5 distinct LSAs into the backbone (one 4874 router-LSA, and one summary-LSA for each of the networks N1-N4). 4875 Router RT4 will also originate 8 distinct LSAs into Area 1 (one 4876 router-LSA and seven summary-LSAs as pictured in Figure 7). If 4877 RT4 has been selected as Designated Router for Network N3, it 4878 will also originate a network-LSA for N3 into Area 1. 4880 In this same figure, Router RT5 will be originating 3 distinct 4881 AS-external-LSAs (one for each of the networks N12-N14). These 4882 will be flooded throughout the entire AS, assuming that none of 4883 the areas have been configured as stubs. However, if area 3 has 4884 been configured as a stub area, the AS-external-LSAs for 4885 networks N12-N14 will not be flooded into area 3 (see Section 4886 3.6). Instead, Router RT11 would originate a default summary- 4887 LSA that would be flooded throughout area 3 (see Section 4888 12.4.3). This instructs all of area 3's internal routers to 4889 send their AS external traffic to RT11. 4891 Whenever a new instance of an LSA is originated, its LS sequence 4892 number is incremented, its LS age is set to 0, its LS checksum 4893 is calculated, and the LSA is added to the link state database 4894 and flooded out the appropriate interfaces. See Section 13.2 4895 for details concerning the installation of the LSA into the link 4896 state database. See Section 13.3 for details concerning the 4897 flooding of newly originated LSAs. 4899 The ten events that can cause a new instance of an LSA to be 4900 originated are: 4902 (1) The LS age field of one of the router's self-originated LSAs 4903 reaches the value LSRefreshTime. In this case, a new 4904 instance of the LSA is originated, even though the contents 4905 of the LSA (apart from the LSA header) will be the same. 4906 This guarantees periodic originations of all LSAs. This 4907 periodic updating of LSAs adds robustness to the link state 4908 algorithm. LSAs that solely describe unreachable 4909 destinations should not be refreshed, but should instead be 4910 flushed from the routing domain (see Section 14.1). 4912 When whatever is being described by an LSA changes, a new LSA is 4913 originated. However, two instances of the same LSA may not be 4914 originated within the time period MinLSInterval. This may 4915 require that the generation of the next instance be delayed by 4916 up to MinLSInterval. The following events may cause the 4917 contents of an LSA to change. These events should cause new 4918 originations if and only if the contents of the new LSA would be 4919 different: 4921 (2) An interface's state changes (see Section 9.1). This may 4922 mean that it is necessary to produce a new instance of the 4923 router-LSA. 4925 (3) An attached network's Designated Router changes. A new 4926 router-LSA should be originated. Also, if the router itself 4927 is now the Designated Router, a new network-LSA should be 4928 produced. If the router itself is no longer the Designated 4929 Router, any network-LSA that it might have originated for 4930 the network should be flushed from the routing domain (see 4931 Section 14.1). 4933 (4) One of the neighboring routers changes to/from the FULL 4934 state. This may mean that it is necessary to produce a new 4935 instance of the router-LSA. Also, if the router is itself 4936 the Designated Router for the attached network, a new 4937 network-LSA should be produced. 4939 The next four events concern area border routers only: 4941 (5) An intra-area route has been added/deleted/modified in the 4942 routing table. This may cause a new instance of a summary- 4943 LSA (for this route) to be originated in each attached area 4944 (possibly including the backbone). 4946 (6) An inter-area route has been added/deleted/modified in the 4947 routing table. This may cause a new instance of a summary- 4948 LSA (for this route) to be originated in each attached area 4949 (but NEVER for the backbone). 4951 (7) The router becomes newly attached to an area. The router 4952 must then originate summary-LSAs into the newly attached 4953 area for all pertinent intra-area and inter-area routes in 4954 the router's routing table. See Section 12.4.3 for more 4955 details. 4957 (8) When the state of one of the router's configured virtual 4958 links changes, it may be necessary to originate a new 4959 router-LSA into the virtual link's Transit area (see the 4960 discussion of the router-LSA's bit V in Section 12.4.1), as 4961 well as originating a new router-LSA into the backbone. 4963 The last two events concern AS boundary routers (and former AS 4964 boundary routers) only: 4966 (9) An external route gained through direct experience with an 4967 external routing protocol (like BGP) changes. This will 4968 cause an AS boundary router to originate a new instance of 4969 an AS-external-LSA. 4971 (10) 4972 A router ceases to be an AS boundary router, perhaps after 4973 restarting. In this situation the router should flush all 4974 AS-external-LSAs that it had previously originated. These 4975 LSAs can be flushed via the premature aging procedure 4976 specified in Section 14.1. 4978 The construction of each type of LSA is explained in detail 4979 below. In general, these sections describe the contents of the 4980 LSA body (i.e., the part coming after the 20-byte LSA header). 4981 For information concerning the building of the LSA header, see 4982 Section 12.1. 4984 12.4.1. Router-LSAs 4986 A router originates a router-LSA for each area that it 4987 belongs to. Such an LSA describes the collected states of 4989 .................................... 4990 . 192.1.2 Area 1 . 4991 . + . 4992 . | . 4993 . | 3+---+1 . 4994 . N1 |--|RT1|-----+ . 4995 . | +---+ \ . 4996 . | \ _______N3 . 4997 . + \/ \ . 1+---+ 4998 . * 192.1.1 *------|RT4| 4999 . + /\_______/ . +---+ 5000 . | / | . 5001 . | 3+---+1 / | . 5002 . N2 |--|RT2|-----+ 1| . 5003 . | +---+ +---+8 . 6+---+ 5004 . | |RT3|----------------|RT6| 5005 . + +---+ . +---+ 5006 . 192.1.3 |2 . 18.10.0.6|7 5007 . | . | 5008 . +------------+ . 5009 . 192.1.4 (N4) . 5010 .................................... 5012 Figure 15: Area 1 with IP addresses shown 5013 the router's links to the area. The LSA is flooded 5014 throughout the particular area, and no further. 5016 The format of a router-LSA is shown in Appendix A (Section 5017 A.4.2). The first 20 bytes of the LSA consist of the 5018 generic LSA header that was discussed in Section 12.1. 5019 router-LSAs have LS type = 1. 5021 A router also indicates whether it is an area border router, 5022 or an AS boundary router, by setting the appropriate bits 5023 (bit B and bit E, respectively) in its router-LSAs. This 5024 enables paths to those types of routers to be saved in the 5025 routing table, for later processing of summary-LSAs and AS- 5026 external-LSAs. Bit B should be set whenever the router is 5027 actively attached to two or more areas, even if the router 5028 is not currently attached to the OSPF backbone area. Bit E 5029 should never be set in a router-LSA for a stub area (stub 5030 areas cannot contain AS boundary routers). 5032 In addition, the router sets bit V in its router-LSA for 5033 Area A if and only if the router is the endpoint of one or 5034 more fully adjacent virtual links having Area A as their 5035 Transit area. The setting of bit V enables other routers in 5036 Area A to discover whether the area supports transit traffic 5037 (see TransitCapability in Section 6). 5039 The router-LSA then describes the router's working 5040 connections (i.e., interfaces or links) to the area. Each 5041 link is typed according to the kind of attached network. 5042 Each link is also labelled with its Link ID. This Link ID 5043 gives a name to the entity that is on the other end of the 5044 link. Table 18 summarizes the values used for the Type and 5045 Link ID fields. 5047 Link type Description Link ID 5048 __________________________________________________ 5049 1 Point-to-point Neighbor Router ID 5050 link 5051 2 Link to transit Interface address of 5052 network Designated Router 5053 3 Link to stub IP network number 5054 network 5055 4 Virtual link Neighbor Router ID 5057 Table 18: Link descriptions in the 5058 router-LSA. 5060 In addition, the Link Data field is specified for each link. 5061 This field gives 32 bits of extra information for the link. 5062 For links to transit networks, numbered point-to-point links 5063 and virtual links, this field specifies the IP interface 5064 address of the associated router interface (this is needed 5065 by the routing table calculation, see Section 16.1.1). For 5066 links to stub networks, this field specifies the stub 5067 network's IP address mask. For unnumbered point-to-point 5068 links, the Link Data field should be set to the unnumbered 5069 interface's MIB-II [Ref8] ifIndex value. 5071 Finally, the cost of using the link for output is specified. 5072 The output cost of a link is configurable. With the 5073 exception of links to stub networks, the output cost must 5074 always be non-zero. 5076 To further describe the process of building the list of link 5077 descriptions, suppose a router wishes to build a router-LSA 5078 for Area A. The router examines its collection of interface 5079 data structures. For each interface, the following steps 5080 are taken: 5082 o If the attached network does not belong to Area A, no 5083 links are added to the LSA, and the next interface 5084 should be examined. 5086 o If the state of the interface is Down, no links are 5087 added. 5089 o If the state of the interface is Loopback, add a Type 3 5090 link (stub network) as long as this is not an interface 5091 to an unnumbered point-to-point network. The Link ID 5092 should be set to the IP interface address, the Link Data 5093 set to the mask 0xffffffff (indicating a host route), 5094 and the cost set to 0. 5096 o Otherwise, the link descriptions added to the router-LSA 5097 depend on the OSPF interface type. Link descriptions 5098 used for point-to-point interfaces are specified in 5099 Section 12.4.1.1, for virtual links in Section 12.4.1.2, 5100 for broadcast and NBMA interfaces in 12.4.1.3, and for 5101 Point-to-MultiPoint interfaces in 12.4.1.4. 5103 After consideration of all the router interfaces, host links 5104 are added to the router-LSA by examining the list of 5105 attached hosts belonging to Area A. A host route is 5106 represented as a Type 3 link (stub network) whose Link ID is 5107 the host's IP address, Link Data is the mask of all ones 5108 (0xffffffff), and cost the host's configured cost (see 5109 Section C.7). 5111 12.4.1.1. Describing point-to-point interfaces 5113 For point-to-point interfaces, one or more link 5114 descriptions are added to the router-LSA as follows: 5116 o If the neighboring router is fully adjacent, add a 5117 Type 1 link (point-to-point). The Link ID should be 5118 set to the Router ID of the neighboring router. For 5119 numbered point-to-point networks, the Link Data 5120 should specify the IP interface address. For 5121 unnumbered point-to-point networks, the Link Data 5122 field should specify the interface's MIB-II [Ref8] 5123 ifIndex value. The cost should be set to the output 5124 cost of the point-to-point interface. 5126 o In addition, as long as the state of the interface 5127 is "Point-to-Point" (and regardless of the 5128 neighboring router state), a Type 3 link (stub 5129 network) should be added. There are two forms that 5130 this stub link can take: 5132 Option 1 5133 Assuming that the neighboring router's IP 5134 address is known, set the Link ID of the Type 3 5135 link to the neighbor's IP address, the Link Data 5136 to the mask 0xffffffff (indicating a host 5137 route), and the cost to the interface's 5138 configured output cost.[15] 5140 Option 2 5141 If a subnet has been assigned to the point-to- 5142 point link, set the Link ID of the Type 3 link 5143 to the subnet's IP address, the Link Data to the 5144 subnet's mask, and the cost to the interface's 5145 configured output cost.[16] 5147 12.4.1.2. Describing broadcast and NBMA interfaces 5149 For operational broadcast and NBMA interfaces, a single 5150 link description is added to the router-LSA as follows: 5152 o If the state of the interface is Waiting, add a Type 5153 3 link (stub network) with Link ID set to the IP 5154 network number of the attached network, Link Data 5155 set to the attached network's address mask, and cost 5156 equal to the interface's configured output cost. 5158 o Else, there has been a Designated Router elected for 5159 the attached network. If the router is fully 5160 adjacent to the Designated Router, or if the router 5161 itself is Designated Router and is fully adjacent to 5162 at least one other router, add a single Type 2 link 5163 (transit network) with Link ID set to the IP 5164 interface address of the attached network's 5165 Designated Router (which may be the router itself), 5166 Link Data set to the router's own IP interface 5167 address, and cost equal to the interface's 5168 configured output cost. Otherwise, add a link as if 5169 the interface state were Waiting (see above). 5171 12.4.1.3. Describing virtual links 5173 For virtual links, a link description is added to the 5174 router-LSA only when the virtual neighbor is fully 5175 adjacent. In this case, add a Type 4 link (virtual link) 5176 with Link ID set to the Router ID of the virtual 5177 neighbor, Link Data set to the IP interface address 5178 associated with the virtual link and cost set to the 5179 cost calculated for the virtual link during the routing 5180 table calculation (see Section 15). 5182 12.4.1.4. Describing Point-to-MultiPoint interfaces 5184 For operational Point-to-MultiPoint interfaces, one or 5185 more link descriptions are added to the router-LSA as 5186 follows: 5188 o A single Type 3 link (stub network) is added with 5189 Link ID set to the router's own IP interface 5190 address, Link Data set to the mask 0xffffffff 5191 (indicating a host route), and cost set to 0. 5193 o For each fully adjacent neighbor associated with the 5194 interface, add an additional Type 1 link (point-to- 5195 point) with Link ID set to the Router ID of the 5196 neighboring router, Link Data set to the IP 5197 interface address and cost equal to the interface's 5198 configured output cost. 5200 12.4.1.5. Examples of router-LSAs 5202 Consider the router-LSAs generated by Router RT3, as 5203 pictured in Figure 6. The area containing Router RT3 5204 (Area 1) has been redrawn, with actual network 5205 addresses, in Figure 15. Assume that the last byte of 5206 all of RT3's interface addresses is 3, giving it the 5207 interface addresses 192.1.1.3 and 192.1.4.3, and that 5208 the other routers have similar addressing schemes. In 5209 addition, assume that all links are functional, and that 5210 Router IDs are assigned as the smallest IP interface 5211 address. 5213 RT3 originates two router-LSAs, one for Area 1 and one 5214 for the backbone. Assume that Router RT4 has been 5215 selected as the Designated router for network 192.1.1.0. 5216 RT3's router-LSA for Area 1 is then shown below. It 5217 indicates that RT3 has two connections to Area 1, the 5218 first a link to the transit network 192.1.1.0 and the 5219 second a link to the stub network 192.1.4.0. Note that 5220 the transit network is identified by the IP interface of 5221 its Designated Router (i.e., the Link ID = 192.1.1.4 5222 which is the Designated Router RT4's IP interface to 5223 192.1.1.0). Note also that RT3 has indicated that it is 5224 an area border router. 5226 ; RT3's router-LSA for Area 1 5228 LS age = 0 ;always true on origination 5229 Options = (E-bit) ; 5230 LS type = 1 ;indicates router-LSA 5231 Link State ID = 192.1.1.3 ;RT3's Router ID 5232 Advertising Router = 192.1.1.3 ;RT3's Router ID 5233 bit E = 0 ;not an AS boundary router 5234 bit B = 1 ;area border router 5235 #links = 2 5236 Link ID = 192.1.1.4 ;IP address of Desig. Rtr. 5237 Link Data = 192.1.1.3 ;RT3's IP interface to net 5238 Type = 2 ;connects to transit network 5239 # TOS metrics = 0 5240 metric = 1 5242 Link ID = 192.1.4.0 ;IP Network number 5243 Link Data = 0xffffff00 ;Network mask 5244 Type = 3 ;connects to stub network 5245 # TOS metrics = 0 5246 metric = 2 5248 Next RT3's router-LSA for the backbone is shown. It 5249 indicates that RT3 has a single attachment to the 5250 backbone. This attachment is via an unnumbered point- 5251 to-point link to Router RT6. RT3 has again indicated 5252 that it is an area border router. 5254 ; RT3's router-LSA for the backbone 5256 LS age = 0 ;always true on origination 5257 Options = (E-bit) ; 5258 LS type = 1 ;indicates router-LSA 5259 Link State ID = 192.1.1.3 ;RT3's router ID 5260 Advertising Router = 192.1.1.3 ;RT3's router ID 5261 bit E = 0 ;not an AS boundary router 5262 bit B = 1 ;area border router 5263 #links = 1 5264 Link ID = 18.10.0.6 ;Neighbor's Router ID 5265 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5266 Type = 1 ;connects to router 5267 # TOS metrics = 0 5268 metric = 8 5270 12.4.2. Network-LSAs 5272 A network-LSA is generated for every transit broadcast or 5273 NBMA network. (A transit network is a network having two or 5274 more attached routers). The network-LSA describes all the 5275 routers that are attached to the network. 5277 The Designated Router for the network originates the LSA. 5278 The Designated Router originates the LSA only if it is fully 5279 adjacent to at least one other router on the network. The 5280 network-LSA is flooded throughout the area that contains the 5281 transit network, and no further. The network-LSA lists 5282 those routers that are fully adjacent to the Designated 5283 Router; each fully adjacent router is identified by its OSPF 5284 Router ID. The Designated Router includes itself in this 5285 list. 5287 The Link State ID for a network-LSA is the IP interface 5288 address of the Designated Router. This value, masked by the 5289 network's address mask (which is also contained in the 5290 network-LSA) yields the network's IP address. 5292 A router that has formerly been the Designated Router for a 5293 network, but is no longer, should flush the network-LSA that 5294 it had previously originated. This LSA is no longer used in 5295 the routing table calculation. It is flushed by prematurely 5296 incrementing the LSA's age to MaxAge and reflooding (see 5297 Section 14.1). In addition, in those rare cases where a 5298 router's Router ID has changed, any network-LSAs that were 5299 originated with the router's previous Router ID must be 5300 flushed. Since the router may have no idea what it's 5301 previous Router ID might have been, these network-LSAs are 5302 indicated by having their Link State ID equal to one of the 5303 router's IP interface addresses and their Advertising Router 5304 equal to some value other than the router's current Router 5305 ID (see Section 13.4 for more details). 5307 12.4.2.1. Examples of network-LSAs 5309 Again consider the area configuration in Figure 6. 5310 Network-LSAs are originated for Network N3 in Area 1, 5311 Networks N6 and N8 in Area 2, and Network N9 in Area 3. 5312 Assuming that Router RT4 has been selected as the 5313 Designated Router for Network N3, the following 5314 network-LSA is generated by RT4 on behalf of Network N3 5315 (see Figure 15 for the address assignments): 5317 ; Network-LSA for Network N3 5319 LS age = 0 ;always true on origination 5320 Options = (E-bit) ; 5321 LS type = 2 ;indicates network-LSA 5322 Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. 5323 Advertising Router = 192.1.1.4 ;RT4's Router ID 5324 Network Mask = 0xffffff00 5325 Attached Router = 192.1.1.4 ;Router ID 5326 Attached Router = 192.1.1.1 ;Router ID 5327 Attached Router = 192.1.1.2 ;Router ID 5328 Attached Router = 192.1.1.3 ;Router ID 5330 12.4.3. Summary-LSAs 5332 The destination described by a summary-LSA is either an IP 5333 network, an AS boundary router or a range of IP addresses. 5334 Summary-LSAs are flooded throughout a single area only. The 5335 destination described is one that is external to the area, 5336 yet still belongs to the Autonomous System. 5338 Summary-LSAs are originated by area border routers. The 5339 precise summary routes to advertise into an area are 5340 determined by examining the routing table structure (see 5341 Section 11) in accordance with the algorithm described 5342 below. Note that only intra-area routes are advertised into 5343 the backbone, while both intra-area and inter-area routes 5344 are advertised into the other areas. 5346 To determine which routes to advertise into an attached Area 5347 A, each routing table entry is processed as follows. 5348 Remember that each routing table entry describes a set of 5349 equal-cost best paths to a particular destination: 5351 o Only Destination Types of network and AS boundary router 5352 are advertised in summary-LSAs. If the routing table 5353 entry's Destination Type is area border router, examine 5354 the next routing table entry. 5356 o AS external routes are never advertised in summary-LSAs. 5357 If the routing table entry has Path-type of type 1 5358 external or type 2 external, examine the next routing 5359 table entry. 5361 o Else, if the area associated with this set of paths is 5362 the Area A itself, do not generate a summary-LSA for the 5363 route.[17] 5365 o Else, if the next hops associated with this set of paths 5366 belong to Area A itself, do not generate a summary-LSA 5367 for the route.[18] This is the logical equivalent of a 5368 Distance Vector protocol's split horizon logic. 5370 o Else, if the routing table cost equals or exceeds the 5371 value LSInfinity, a summary-LSA cannot be generated for 5372 this route. 5374 o Else, if the destination of this route is an AS boundary 5375 router, a summary-LSA should be originated if and only 5376 if the routing table entry describes the preferred path 5377 to the AS boundary router (see Step 3 of Section 16.4). 5378 If so, a Type 4 summary-LSA is originated for the 5379 destination, with Link State ID equal to the AS boundary 5380 router's Router ID and metric equal to the routing table 5381 entry's cost. Note: these LSAs should not be generated 5382 if Area A has been configured as a stub area. 5384 o Else, the Destination type is network. If this is an 5385 inter-area route, generate a Type 3 summary-LSA for the 5386 destination, with Link State ID equal to the network's 5387 address (if necessary, the Link State ID can also have 5388 one or more of the network's host bits set; see Appendix 5389 E for details) and metric equal to the routing table 5390 cost. 5392 o The one remaining case is an intra-area route to a 5393 network. This means that the network is contained in 5394 one of the router's directly attached areas. In 5395 general, this information must be condensed before 5396 appearing in summary-LSAs. Remember that an area has a 5397 configured list of address ranges, each range consisting 5398 of an [address,mask] pair and a status indication of 5399 either Advertise or DoNotAdvertise. At most a single 5400 Type 3 summary-LSA is originated for each range. When 5401 the range's status indicates Advertise, a Type 3 5402 summary-LSA is generated with Link State ID equal to the 5403 range's address (if necessary, the Link State ID can 5404 also have one or more of the range's "host" bits set; 5405 see Appendix E for details) and cost equal to the 5406 largest cost of any of the component networks. When the 5407 range's status indicates DoNotAdvertise, the Type 3 5408 summary-LSA is suppressed and the component networks 5409 remain hidden from other areas. 5411 By default, if a network is not contained in any 5412 explicitly configured address range, a Type 3 summary- 5413 LSA is generated with Link State ID equal to the 5414 network's address (if necessary, the Link State ID can 5415 also have one or more of the network's "host" bits set; 5416 see Appendix E for details) and metric equal to the 5417 network's routing table cost. 5419 If an area is capable of carrying transit traffic (i.e., 5420 its TransitCapability is set to TRUE), routing 5421 information concerning backbone networks should not be 5422 condensed before being summarized into the area. Nor 5423 should the advertisement of backbone networks into 5424 transit areas be suppressed. In other words, the 5425 backbone's configured ranges should be ignored when 5426 originating summary-LSAs into transit areas. 5428 If a router advertises a summary-LSA for a destination which 5429 then becomes unreachable, the router must then flush the LSA 5430 from the routing domain by setting its age to MaxAge and 5431 reflooding (see Section 14.1). Also, if the destination is 5432 still reachable, yet can no longer be advertised according 5433 to the above procedure (e.g., it is now an inter-area route, 5434 when it used to be an intra-area route associated with some 5435 non-backbone area; it would thus no longer be advertisable 5436 to the backbone), the LSA should also be flushed from the 5437 routing domain. 5439 12.4.3.1. Originating summary-LSAs into stub areas 5441 The algorithm in Section 12.4.3 is optional when Area A 5442 is an OSPF stub area. Area border routers connecting to 5443 a stub area can originate summary-LSAs into the area 5444 according to the Section 12.4.3's algorithm, or can 5445 choose to originate only a subset of the summary-LSAs, 5446 possibly under configuration control. The fewer LSAs 5447 originated, the smaller the stub area's link state 5448 database, further reducing the demands on its routers' 5449 resources. However, omitting LSAs may also lead to sub- 5450 optimal inter-area routing, although routing will 5451 continue to function. 5453 As specified in Section 12.4.3, Type 4 summary-LSAs 5454 (ASBR-summary-LSAs) are never originated into stub 5455 areas. 5457 In a stub area, instead of importing external routes 5458 each area border router originates a "default summary- 5459 LSA" into the area. The Link State ID for the default 5460 summary-LSA is set to DefaultDestination, and the metric 5461 set to the (per-area) configurable parameter 5462 StubDefaultCost. Note that StubDefaultCost need not be 5463 configured identically in all of the stub area's area 5464 border routers. 5466 12.4.3.2. Examples of summary-LSAs 5468 Consider again the area configuration in Figure 6. 5469 Routers RT3, RT4, RT7, RT10 and RT11 are all area border 5470 routers, and therefore are originating summary-LSAs. 5471 Consider in particular Router RT4. Its routing table 5472 was calculated as the example in Section 11.3. RT4 5473 originates summary-LSAs into both the backbone and Area 5474 1. Into the backbone, Router RT4 originates separate 5475 LSAs for each of the networks N1-N4. Into Area 1, 5476 Router RT4 originates separate LSAs for networks N6-N8 5477 and the AS boundary routers RT5,RT7. It also condenses 5478 host routes Ia and Ib into a single summary-LSA. 5479 Finally, the routes to networks N9,N10,N11 and Host H1 5480 are advertised by a single summary-LSA. This 5481 condensation was originally performed by the router 5482 RT11. 5484 These LSAs are illustrated graphically in Figures 7 and 5485 8. Two of the summary-LSAs originated by Router RT4 5486 follow. The actual IP addresses for the networks and 5487 routers in question have been assigned in Figure 15. 5489 ; Summary-LSA for Network N1, 5490 ; originated by Router RT4 into the backbone 5492 LS age = 0 ;always true on origination 5493 Options = (E-bit) ; 5494 LS type = 3 ;Type 3 summary-LSA 5495 Link State ID = 192.1.2.0 ;N1's IP network number 5496 Advertising Router = 192.1.1.4 ;RT4's ID 5497 metric = 4 5499 ; Summary-LSA for AS boundary router RT7 5500 ; originated by Router RT4 into Area 1 5502 LS age = 0 ;always true on origination 5503 Options = (E-bit) ; 5504 LS type = 4 ;Type 4 summary-LSA 5505 Link State ID = Router RT7's ID 5506 Advertising Router = 192.1.1.4 ;RT4's ID 5507 metric = 14 5509 12.4.4. AS-external-LSAs 5511 AS-external-LSAs describe routes to destinations external to 5512 the Autonomous System. Most AS-external-LSAs describe 5513 routes to specific external destinations; in these cases the 5514 LSA's Link State ID is set to the destination network's IP 5515 address (if necessary, the Link State ID can also have one 5516 or more of the network's "host" bits set; see Appendix E for 5517 details). However, a default route for the Autonomous 5518 System can be described in an AS-external-LSA by setting the 5519 LSA's Link State ID to DefaultDestination (0.0.0.0). AS- 5520 external-LSAs are originated by AS boundary routers. An AS 5521 boundary router originates a single AS-external-LSA for each 5522 external route that it has learned, either through another 5523 routing protocol (such as BGP), or through configuration 5524 information. 5526 AS-external-LSAs are the only type of LSAs that are flooded 5527 throughout the entire Autonomous System; all other types of 5528 LSAs are specific to a single area. However, AS-external- 5529 LSAs are not flooded into/throughout stub areas (see Section 5530 3.6). This enables a reduction in link state database size 5531 for routers internal to stub areas. 5533 The metric that is advertised for an external route can be 5534 one of two types. Type 1 metrics are comparable to the link 5535 state metric. Type 2 metrics are assumed to be larger than 5536 the cost of any intra-AS path. 5538 If a router advertises an AS-external-LSA for a destination 5539 which then becomes unreachable, the router must then flush 5540 the LSA from the routing domain by setting its age to MaxAge 5541 and reflooding (see Section 14.1). 5543 12.4.4.1. Examples of AS-external-LSAs 5545 Consider once again the AS pictured in Figure 6. There 5546 are two AS boundary routers: RT5 and RT7. Router RT5 5547 originates three AS-external-LSAs, for networks N12-N14. 5548 Router RT7 originates two AS-external-LSAs, for networks 5549 N12 and N15. Assume that RT7 has learned its route to 5550 N12 via BGP, and that it wishes to advertise a Type 2 5551 metric to the AS. RT7 would then originate the 5552 following LSA for N12: 5554 ; AS-external-LSA for Network N12, 5555 ; originated by Router RT7 5557 LS age = 0 ;always true on origination 5558 Options = (E-bit) ; 5559 LS type = 5 ;AS-external-LSA 5560 Link State ID = N12's IP network number 5561 Advertising Router = Router RT7's ID 5562 bit E = 1 ;Type 2 metric 5563 metric = 2 5564 Forwarding address = 0.0.0.0 5566 In the above example, the forwarding address field has 5567 been set to 0.0.0.0, indicating that packets for the 5568 external destination should be forwarded to the 5569 advertising OSPF router (RT7). This is not always 5570 desirable. Consider the example pictured in Figure 16. 5571 There are three OSPF routers (RTA, RTB and RTC) 5572 connected to a common network. Only one of these 5573 routers, RTA, is exchanging BGP information with the 5574 non-OSPF router RTX. RTA must then originate AS- 5575 external-LSAs for those destinations it has learned from 5576 RTX. By using the AS-external-LSA's forwarding address 5577 field, RTA can specify that packets for these 5578 destinations be forwarded directly to RTX. Without this 5579 feature, Routers RTB and RTC would take an extra hop to 5580 get to these destinations. 5582 Note that when the forwarding address field is non-zero, 5583 it should point to a router belonging to another 5584 Autonomous System. 5586 A forwarding address can also be specified for the 5587 default route. For example, in figure 16 RTA may want 5588 to specify that all externally-destined packets should 5589 by default be forwarded to its BGP peer RTX. The 5590 resulting AS-external-LSA is pictured below. Note that 5591 the Link State ID is set to DefaultDestination. 5593 ; Default route, originated by Router RTA 5594 ; Packets forwarded through RTX 5596 LS age = 0 ;always true on origination 5597 Options = (E-bit) ; 5598 LS type = 5 ;AS-external-LSA 5599 Link State ID = DefaultDestination ; default route 5600 Advertising Router = Router RTA's ID 5601 bit E = 1 ;Type 2 metric 5602 metric = 1 5603 Forwarding address = RTX's IP address 5605 In figure 16, suppose instead that both RTA and RTB 5606 exchange BGP information with RTX. In this case, RTA 5607 and RTB would originate the same set of AS-external- 5608 LSAs. These LSAs, if they specify the same metric, 5609 would be functionally equivalent since they would 5610 specify the same destination and forwarding address 5611 (RTX). This leads to a clear duplication of effort. If 5612 only one of RTA or RTB originated the set of AS- 5613 external-LSAs, the routing would remain the same, and 5614 the size of the link state database would decrease. 5615 However, it must be unambiguously defined as to which 5616 router originates the LSAs (otherwise neither may, or 5617 the identity of the originator may oscillate). The 5618 following rule is thereby established: if two routers, 5619 both reachable from one another, originate functionally 5620 equivalent AS-external-LSAs (i.e., same destination, 5621 cost and non-zero forwarding address), then the LSA 5622 originated by the router having the highest OSPF Router 5623 ID is used. The router having the lower OSPF Router ID 5624 can then flush its LSA. Flushing an LSA is discussed in 5625 Section 14.1. 5627 13. The Flooding Procedure 5629 Link State Update packets provide the mechanism for flooding LSAs. 5630 A Link State Update packet may contain several distinct LSAs, and 5631 floods each LSA one hop further from its point of origination. To 5632 make the flooding procedure reliable, each LSA must be acknowledged 5633 separately. Acknowledgments are transmitted in Link State 5634 Acknowledgment packets. Many separate acknowledgments can also be 5636 + 5637 | 5638 +---+.....|.BGP 5639 |RTA|-----|.....+---+ 5640 +---+ |-----|RTX| 5641 | +---+ 5642 +---+ | 5643 |RTB|-----| 5644 +---+ | 5645 | 5646 +---+ | 5647 |RTC|-----| 5648 +---+ | 5649 | 5650 + 5652 Figure 16: Forwarding address example 5653 grouped together into a single packet. 5655 The flooding procedure starts when a Link State Update packet has 5656 been received. Many consistency checks have been made on the 5657 received packet before being handed to the flooding procedure (see 5658 Section 8.2). In particular, the Link State Update packet has been 5659 associated with a particular neighbor, and a particular area. If 5660 the neighbor is in a lesser state than Exchange, the packet should 5661 be dropped without further processing. 5663 All types of LSAs, other than AS-external-LSAs, are associated with 5664 a specific area. However, LSAs do not contain an area field. An 5665 LSA's area must be deduced from the Link State Update packet header. 5667 For each LSA contained in a Link State Update packet, the following 5668 steps are taken: 5670 (1) Validate the LSA's LS checksum. If the checksum turns out to be 5671 invalid, discard the LSA and get the next one from the Link 5672 State Update packet. 5674 (2) Examine the LSA's LS type. If the LS type is unknown, discard 5675 the LSA and get the next one from the Link State Update Packet. 5676 This specification defines LS types 1-5 (see Section 4.3). 5678 (3) Else if this is an AS-external-LSA (LS type = 5), and the area 5679 has been configured as a stub area, discard the LSA and get the 5680 next one from the Link State Update Packet. AS-external-LSAs 5681 are not flooded into/throughout stub areas (see Section 3.6). 5683 (4) Else if the LSA's LS age is equal to MaxAge, and there is 5684 currently no instance of the LSA in the router's link state 5685 database, then take the following actions: 5687 (a) Acknowledge the receipt of the LSA by sending a Link State 5688 Acknowledgment packet back to the sending neighbor (see 5689 Section 13.5). 5691 (b) Purge all outstanding requests for equal or previous 5692 instances of the LSA from all neighbors' Link State Request 5693 lists (see Section 10). 5695 (c) If the sending neighbor is in state Exchange or in state 5696 Loading, then install the MaxAge LSA in the link state 5697 database. Otherwise, simply discard the LSA. In either 5698 case, examine the next LSA (if any) listed in the Link State 5699 Update packet. 5701 (5) Otherwise, find the instance of this LSA that is currently 5702 contained in the router's link state database. If there is no 5703 database copy, or the received LSA is more recent than the 5704 database copy (see Section 13.1 below for the determination of 5705 which LSA is more recent) the following steps must be performed: 5707 (a) If there is already a database copy, and if the database 5708 copy was installed less than MinLSArrival seconds ago, 5709 discard the new LSA (without acknowledging it) and examine 5710 the next LSA (if any) listed in the Link State Update 5711 packet. 5713 (b) Otherwise immediately flood the new LSA out some subset of 5714 the router's interfaces (see Section 13.3). In some cases 5715 (e.g., the state of the receiving interface is DR and the 5716 LSA was received from a router other than the Backup DR) the 5717 LSA will be flooded back out the receiving interface. This 5718 occurrence should be noted for later use by the 5719 acknowledgment process (Section 13.5). 5721 (c) Remove the current database copy from all neighbors' Link 5722 state retransmission lists. 5724 (d) Install the new LSA in the link state database (replacing 5725 the current database copy). This may cause the routing 5726 table calculation to be scheduled. In addition, timestamp 5727 the new LSA with the current time (i.e., the time it was 5728 received). The flooding procedure cannot overwrite the 5729 newly installed LSA until MinLSArrival seconds have elapsed. 5730 The LSA installation process is discussed further in Section 5731 13.2. 5733 (e) Possibly acknowledge the receipt of the LSA by sending a 5734 Link State Acknowledgment packet back out the receiving 5735 interface. This is explained below in Section 13.5. 5737 (f) If this new LSA indicates that it was originated by the 5738 receiving router itself (i.e., is considered a self- 5739 originated LSA), the router must take special action, either 5740 updating the LSA or in some cases flushing it from the 5741 routing domain. For a description of how self-originated 5742 LSAs are detected and subsequently handled, see Section 5743 13.4. 5745 (6) Else, if there is an instance of the LSA on the sending 5746 neighbor's Link state request list, an error has occurred in the 5747 Database Exchange process. In this case, restart the Database 5748 Exchange process by generating the neighbor event BadLSReq for 5749 the sending neighbor and stop processing the Link State Update 5750 packet. 5752 (7) Else, if the received LSA is the same instance as the database 5753 copy (i.e., neither one is more recent) the following two steps 5754 should be performed: 5756 (a) If the LSA is listed in the Link state retransmission list 5757 for the receiving adjacency, the router itself is expecting 5758 an acknowledgment for this LSA. The router should treat the 5759 received LSA as an acknowledgment by removing the LSA from 5760 the Link state retransmission list. This is termed an 5761 "implied acknowledgment". Its occurrence should be noted 5762 for later use by the acknowledgment process (Section 13.5). 5764 (b) Possibly acknowledge the receipt of the LSA by sending a 5765 Link State Acknowledgment packet back out the receiving 5766 interface. This is explained below in Section 13.5. 5768 (8) Else, the database copy is more recent. If the database copy 5769 has LS age equal to MaxAge and LS sequence number equal to 5770 MaxSequenceNumber, simply discard the received LSA without 5771 acknowledging it. (In this case, the LSA's LS sequence number is 5772 wrapping, and the MaxSequenceNumber LSA must be completely 5773 flushed before any new LSA instance can be introduced). 5774 Otherwise, as long as the database copy has not been sent in a 5775 Link State Update within the last MinLSArrival seconds, send the 5776 database copy back to the sending neighbor, encapsulated within 5777 a Link State Update Packet. The Link State Update Packet should 5778 be sent directly to the neighbor. In so doing, do not put the 5779 database copy of the LSA on the neighbor's link state 5780 retransmission list, and do not acknowledge the received (less 5781 recent) LSA instance. 5783 13.1. Determining which LSA is newer 5785 When a router encounters two instances of an LSA, it must 5786 determine which is more recent. This occurred above when 5787 comparing a received LSA to its database copy. This comparison 5788 must also be done during the Database Exchange procedure which 5789 occurs during adjacency bring-up. 5791 An LSA is identified by its LS type, Link State ID and 5792 Advertising Router. For two instances of the same LSA, the LS 5793 sequence number, LS age, and LS checksum fields are used to 5794 determine which instance is more recent: 5796 o The LSA having the newer LS sequence number is more recent. 5797 See Section 12.1.6 for an explanation of the LS sequence 5798 number space. If both instances have the same LS sequence 5799 number, then: 5801 o If the two instances have different LS checksums, then the 5802 instance having the larger LS checksum (when considered as a 5803 16-bit unsigned integer) is considered more recent. 5805 o Else, if only one of the instances has its LS age field set 5806 to MaxAge, the instance of age MaxAge is considered to be 5807 more recent. 5809 o Else, if the LS age fields of the two instances differ by 5810 more than MaxAgeDiff, the instance having the smaller 5811 (younger) LS age is considered to be more recent. 5813 o Else, the two instances are considered to be identical. 5815 13.2. Installing LSAs in the database 5817 Installing a new LSA in the database, either as the result of 5818 flooding or a newly self-originated LSA, may cause the OSPF 5819 routing table structure to be recalculated. The contents of the 5820 new LSA should be compared to the old instance, if present. If 5821 there is no difference, there is no need to recalculate the 5822 routing table. When comparing an LSA to its previous instance, 5823 the following are all considered to be differences in contents: 5825 o The LSA's Options field has changed. 5827 o One of the LSA instances has LS age set to MaxAge, and 5828 the other does not. 5830 o The length field in the LSA header has changed. 5832 o The body of the LSA (i.e., anything outside the 20-byte 5833 LSA header) has changed. Note that this excludes changes 5834 in LS Sequence Number and LS Checksum. 5836 If the contents are different, the following pieces of the 5837 routing table must be recalculated, depending on the new LSA's 5838 LS type field: 5840 Router-LSAs and network-LSAs 5841 The entire routing table must be recalculated, starting with 5842 the shortest path calculations for each area (not just the 5843 area whose link-state database has changed). The reason 5844 that the shortest path calculation cannot be restricted to 5845 the single changed area has to do with the fact that AS 5846 boundary routers may belong to multiple areas. A change in 5847 the area currently providing the best route may force the 5848 router to use an intra-area route provided by a different 5849 area.[19] 5851 Summary-LSAs 5852 The best route to the destination described by the summary- 5853 LSA must be recalculated (see Section 16.5). If this 5854 destination is an AS boundary router, it may also be 5855 necessary to re-examine all the AS-external-LSAs. 5857 AS-external-LSAs 5858 The best route to the destination described by the AS- 5859 external-LSA must be recalculated (see Section 16.6). 5861 Also, any old instance of the LSA must be removed from the 5862 database when the new LSA is installed. This old instance must 5863 also be removed from all neighbors' Link state retransmission 5864 lists (see Section 10). 5866 13.3. Next step in the flooding procedure 5868 When a new (and more recent) LSA has been received, it must be 5869 flooded out some set of the router's interfaces. This section 5870 describes the second part of flooding procedure (the first part 5871 being the processing that occurred in Section 13), namely, 5872 selecting the outgoing interfaces and adding the LSA to the 5873 appropriate neighbors' Link state retransmission lists. Also 5874 included in this part of the flooding procedure is the 5875 maintenance of the neighbors' Link state request lists. 5877 This section is equally applicable to the flooding of an LSA 5878 that the router itself has just originated (see Section 12.4). 5879 For these LSAs, this section provides the entirety of the 5880 flooding procedure (i.e., the processing of Section 13 is not 5881 performed, since, for example, the LSA has not been received 5882 from a neighbor and therefore does not need to be acknowledged). 5884 Depending upon the LSA's LS type, the LSA can be flooded out 5885 only certain interfaces. These interfaces, defined by the 5886 following, are called the eligible interfaces: 5888 AS-external-LSAs (LS Type = 5) 5889 AS-external-LSAs are flooded throughout the entire AS, with 5890 the exception of stub areas (see Section 3.6). The eligible 5891 interfaces are all the router's interfaces, excluding 5892 virtual links and those interfaces attaching to stub areas. 5894 All other LS types 5895 All other types are specific to a single area (Area A). The 5896 eligible interfaces are all those interfaces attaching to 5897 the Area A. If Area A is the backbone, this includes all 5898 the virtual links. 5900 Link state databases must remain synchronized over all 5901 adjacencies associated with the above eligible interfaces. This 5902 is accomplished by executing the following steps on each 5903 eligible interface. It should be noted that this procedure may 5904 decide not to flood an LSA out a particular interface, if there 5905 is a high probability that the attached neighbors have already 5906 received the LSA. However, in these cases the flooding 5907 procedure must be absolutely sure that the neighbors eventually 5908 do receive the LSA, so the LSA is still added to each 5909 adjacency's Link state retransmission list. For each eligible 5910 interface: 5912 (1) Each of the neighbors attached to this interface are 5913 examined, to determine whether they must receive the new 5914 LSA. The following steps are executed for each neighbor: 5916 (a) If the neighbor is in a lesser state than Exchange, it 5917 does not participate in flooding, and the next neighbor 5918 should be examined. 5920 (b) Else, if the adjacency is not yet full (neighbor state 5921 is Exchange or Loading), examine the Link state request 5922 list associated with this adjacency. If there is an 5923 instance of the new LSA on the list, it indicates that 5924 the neighboring router has an instance of the LSA 5925 already. Compare the new LSA to the neighbor's copy: 5927 o If the new LSA is less recent, then examine the next 5928 neighbor. 5930 o If the two copies are the same instance, then delete 5931 the LSA from the Link state request list, and 5932 examine the next neighbor.[20] 5933 o Else, the new LSA is more recent. Delete the LSA 5934 from the Link state request list. 5936 (c) If the new LSA was received from this neighbor, examine 5937 the next neighbor. 5939 (d) At this point we are not positive that the neighbor has 5940 an up-to-date instance of this new LSA. Add the new LSA 5941 to the Link state retransmission list for the adjacency. 5942 This ensures that the flooding procedure is reliable; 5943 the LSA will be retransmitted at intervals until an 5944 acknowledgment is seen from the neighbor. 5946 (2) The router must now decide whether to flood the new LSA out 5947 this interface. If in the previous step, the LSA was NOT 5948 added to any of the Link state retransmission lists, there 5949 is no need to flood the LSA out the interface and the next 5950 interface should be examined. 5952 (3) If the new LSA was received on this interface, and it was 5953 received from either the Designated Router or the Backup 5954 Designated Router, chances are that all the neighbors have 5955 received the LSA already. Therefore, examine the next 5956 interface. 5958 (4) If the new LSA was received on this interface, and the 5959 interface state is Backup (i.e., the router itself is the 5960 Backup Designated Router), examine the next interface. The 5961 Designated Router will do the flooding on this interface. 5962 However, if the Designated Router fails the router (i.e., 5963 the Backup Designated Router) will end up retransmitting the 5964 updates. 5966 (5) If this step is reached, the LSA must be flooded out the 5967 interface. Send a Link State Update packet (including the 5968 new LSA as contents) out the interface. The LSA's LS age 5969 must be incremented by InfTransDelay (which must be > 0) 5970 when it is copied into the outgoing Link State Update packet 5971 (until the LS age field reaches the maximum value of 5972 MaxAge). 5974 On broadcast networks, the Link State Update packets are 5975 multicast. The destination IP address specified for the 5976 Link State Update Packet depends on the state of the 5977 interface. If the interface state is DR or Backup, the 5978 address AllSPFRouters should be used. Otherwise, the 5979 address AllDRouters should be used. 5981 On non-broadcast networks, separate Link State Update 5982 packets must be sent, as unicasts, to each adjacent neighbor 5983 (i.e., those in state Exchange or greater). The destination 5984 IP addresses for these packets are the neighbors' IP 5985 addresses. 5987 13.4. Receiving self-originated LSAs 5989 It is a common occurrence for a router to receive self- 5990 originated LSAs via the flooding procedure. A self-originated 5991 LSA is detected when either 1) the LSA's Advertising Router is 5992 equal to the router's own Router ID or 2) the LSA is a network- 5993 LSA and its Link State ID is equal to one of the router's own IP 5994 interface addresses. 5996 However, if the received self-originated LSA is newer than the 5997 last instance that the router actually originated, the router 5998 must take special action. The reception of such an LSA 5999 indicates that there are LSAs in the routing domain that were 6000 originated by the router before the last time it was restarted. 6001 In most cases, the router must then advance the LSA's LS 6002 sequence number one past the received LS sequence number, and 6003 originate a new instance of the LSA. 6005 It may be the case the router no longer wishes to originate the 6006 received LSA. Possible examples include: 1) the LSA is a 6007 summary-LSA or AS-external-LSA and the router no longer has an 6008 (advertisable) route to the destination, 2) the LSA is a 6009 network-LSA but the router is no longer Designated Router for 6010 the network or 3) the LSA is a network-LSA whose Link State ID 6011 is one of the router's own IP interface addresses but whose 6012 Advertising Router is not equal to the router's own Router ID 6013 (this latter case should be rare, and it indicates that the 6014 router's Router ID has changed since originating the LSA). In 6015 all these cases, instead of updating the LSA, the LSA should be 6016 flushed from the routing domain by incrementing the received 6017 LSA's LS age to MaxAge and reflooding (see Section 14.1). 6019 13.5. Sending Link State Acknowledgment packets 6021 Each newly received LSA must be acknowledged. This is usually 6022 done by sending Link State Acknowledgment packets. However, 6023 acknowledgments can also be accomplished implicitly by sending 6024 Link State Update packets (see step 7a of Section 13). 6026 Many acknowledgments may be grouped together into a single Link 6027 State Acknowledgment packet. Such a packet is sent back out the 6028 interface which received the LSAs. The packet can be sent in 6029 one of two ways: delayed and sent on an interval timer, or sent 6030 directly to a particular neighbor. The particular 6031 acknowledgment strategy used depends on the circumstances 6032 surrounding the receipt of the LSA. 6034 Sending delayed acknowledgments accomplishes several things: 1) 6035 it facilitates the packaging of multiple acknowledgments in a 6036 single Link State Acknowledgment packet, 2) it enables a single 6037 Link State Acknowledgment packet to indicate acknowledgments to 6038 several neighbors at once (through multicasting) and 3) it 6039 randomizes the Link State Acknowledgment packets sent by the 6040 various routers attached to a common network. The fixed 6041 interval between a router's delayed transmissions must be short 6042 (less than RxmtInterval) or needless retransmissions will ensue. 6044 Direct acknowledgments are sent directly to a particular 6045 neighbor in response to the receipt of duplicate LSAs. Direct 6046 acknowledgments are sent immediately when the duplicate is 6047 received. On multi-access networks, these acknowledgments are 6048 sent directly to the neighbor's IP address. 6050 The precise procedure for sending Link State Acknowledgment 6051 packets is described in Table 19. The circumstances surrounding 6052 the receipt of the LSA are listed in the left column. The 6053 acknowledgment action then taken is listed in one of the two 6054 right columns. This action depends on the state of the 6055 concerned interface; interfaces in state Backup behave 6056 differently from interfaces in all other states. Delayed 6057 acknowledgments must be delivered to all adjacent routers 6058 associated with the interface. On broadcast networks, this is 6059 accomplished by sending the delayed Link State Acknowledgment 6060 packets as multicasts. The Destination IP address used depends 6061 on the state of the interface. If the interface state is DR or 6062 Backup, the destination AllSPFRouters is used. In all other 6063 states, the destination AllDRouters is used. On non-broadcast 6064 networks, delayed Link State Acknowledgment packets must be 6065 unicast separately over each adjacency (i.e., neighbor whose 6066 state is >= Exchange). 6068 The reasoning behind sending the above packets as multicasts is 6069 best explained by an example. Consider the network 6070 configuration depicted in Figure 15. Suppose RT4 has been 6071 elected as Designated Router, and RT3 as Backup Designated 6072 Router for the network N3. When Router RT4 floods a new LSA to 6073 Network N3, it is received by routers RT1, RT2, and RT3. These 6074 routers will not flood the LSA back onto net N3, but they still 6075 Action taken in state 6076 Circumstances Backup All other states 6077 _______________________________________________________________ 6078 LSA has No acknowledgment No acknowledgment 6079 been flooded back sent. sent. 6080 out receiving in- 6081 terface (see Sec- 6082 tion 13, step 5b). 6083 _______________________________________________________________ 6084 LSA is Delayed acknowledg- Delayed ack- 6085 more recent than ment sent if adver- nowledgment sent. 6086 database copy, but tisement received 6087 was not flooded from Designated 6088 back out receiving Router, otherwise 6089 interface do nothing 6090 _______________________________________________________________ 6091 LSA is a Delayed acknowledg- No acknowledgment 6092 duplicate, and was ment sent if adver- sent. 6093 treated as an im- tisement received 6094 plied acknowledg- from Designated 6095 ment (see Section Router, otherwise 6096 13, step 7a). do nothing 6097 _______________________________________________________________ 6098 LSA is a Direct acknowledg- Direct acknowledg- 6099 duplicate, and was ment sent. ment sent. 6100 not treated as an 6101 implied ack- 6102 nowledgment. 6103 _______________________________________________________________ 6104 LSA's LS Direct acknowledg- Direct acknowledg- 6105 age is equal to ment sent. ment sent. 6106 MaxAge, and there is 6107 no current instance 6108 of the LSA 6109 in the link state 6110 database (see 6111 Section 13, step 4). 6113 Table 19: Sending link state acknowledgements. 6115 must ensure that their link-state databases remain synchronized 6116 with their adjacent neighbors. So RT1, RT2, and RT4 are waiting 6117 to see an acknowledgment from RT3. Likewise, RT4 and RT3 are 6118 both waiting to see acknowledgments from RT1 and RT2. This is 6119 best achieved by sending the acknowledgments as multicasts. 6121 The reason that the acknowledgment logic for Backup DRs is 6122 slightly different is because they perform differently during 6123 the flooding of LSAs (see Section 13.3, step 4). 6125 13.6. Retransmitting LSAs 6127 LSAs flooded out an adjacency are placed on the adjacency's Link 6128 state retransmission list. In order to ensure that flooding is 6129 reliable, these LSAs are retransmitted until they are 6130 acknowledged. The length of time between retransmissions is a 6131 configurable per-interface value, RxmtInterval. If this is set 6132 too low for an interface, needless retransmissions will ensue. 6133 If the value is set too high, the speed of the flooding, in the 6134 face of lost packets, may be affected. 6136 Several retransmitted LSAs may fit into a single Link State 6137 Update packet. When LSAs are to be retransmitted, only the 6138 number fitting in a single Link State Update packet should be 6139 sent. Another packet of retransmissions can be sent whenever 6140 some of the LSAs are acknowledged, or on the next firing of the 6141 retransmission timer. 6143 Link State Update Packets carrying retransmissions are always 6144 sent directly to the neighbor. On multi-access networks, this 6145 means that retransmissions are sent directly to the neighbor's 6146 IP address. Each LSA's LS age must be incremented by 6147 InfTransDelay (which must be > 0) when it is copied into the 6148 outgoing Link State Update packet (until the LS age field 6149 reaches the maximum value of MaxAge). 6151 If an adjacent router goes down, retransmissions may occur until 6152 the adjacency is destroyed by OSPF's Hello Protocol. When the 6153 adjacency is destroyed, the Link state retransmission list is 6154 cleared. 6156 13.7. Receiving link state acknowledgments 6158 Many consistency checks have been made on a received Link State 6159 Acknowledgment packet before it is handed to the flooding 6160 procedure. In particular, it has been associated with a 6161 particular neighbor. If this neighbor is in a lesser state than 6162 Exchange, the Link State Acknowledgment packet is discarded. 6164 Otherwise, for each acknowledgment in the Link State 6165 Acknowledgment packet, the following steps are performed: 6167 o Does the LSA acknowledged have an instance on the Link state 6168 retransmission list for the neighbor? If not, examine the 6169 next acknowledgment. Otherwise: 6171 o If the acknowledgment is for the same instance that is 6172 contained on the list, remove the item from the list and 6173 examine the next acknowledgment. Otherwise: 6175 o Log the questionable acknowledgment, and examine the next 6176 one. 6178 14. Aging The Link State Database 6180 Each LSA has an LS age field. The LS age is expressed in seconds. 6181 An LSA's LS age field is incremented while it is contained in a 6182 router's database. Also, when copied into a Link State Update 6183 Packet for flooding out a particular interface, the LSA's LS age is 6184 incremented by InfTransDelay. 6186 An LSA's LS age is never incremented past the value MaxAge. LSAs 6187 having age MaxAge are not used in the routing table calculation. As 6188 a router ages its link state database, an LSA's LS age may reach 6189 MaxAge.[21] At this time, the router must attempt to flush the LSA 6190 from the routing domain. This is done simply by reflooding the 6191 MaxAge LSA just as if it was a newly originated LSA (see Section 6192 13.3). 6194 When creating a Database summary list for a newly forming adjacency, 6195 any MaxAge LSAs present in the link state database are added to the 6196 neighbor's Link state retransmission list instead of the neighbor's 6197 Database summary list. See Section 10.3 for more details. 6199 A MaxAge LSA must be removed immediately from the router's link 6200 state database as soon as both a) it is no longer contained on any 6201 neighbor Link state retransmission lists and b) none of the router's 6202 neighbors are in states Exchange or Loading. 6204 When, in the process of aging the link state database, an LSA's LS 6205 age hits a multiple of CheckAge, its LS checksum should be verified. 6207 If the LS checksum is incorrect, a program or memory error has been 6208 detected, and at the very least the router itself should be 6209 restarted. 6211 14.1. Premature aging of LSAs 6213 An LSA can be flushed from the routing domain by setting its LS 6214 age to MaxAge, while leaving its LS sequence number alone, and 6215 then reflooding the LSA. This procedure follows the same course 6216 as flushing an LSA whose LS age has naturally reached the value 6217 MaxAge (see Section 14). In particular, the MaxAge LSA is 6218 removed from the router's link state database as soon as a) it 6219 is no longer contained on any neighbor Link state retransmission 6220 lists and b) none of the router's neighbors are in states 6221 Exchange or Loading. We call the setting of an LSA's LS age to 6222 MaxAge "premature aging". 6224 Premature aging is used when it is time for a self-originated 6225 LSA's sequence number field to wrap. At this point, the current 6226 LSA instance (having LS sequence number MaxSequenceNumber) must 6227 be prematurely aged and flushed from the routing domain before a 6228 new instance with sequence number equal to InitialSequenceNumber 6229 can be originated. See Section 12.1.6 for more information. 6231 Premature aging can also be used when, for example, one of the 6232 router's previously advertised external routes is no longer 6233 reachable. In this circumstance, the router can flush its AS- 6234 external-LSA from the routing domain via premature aging. This 6235 procedure is preferable to the alternative, which is to 6236 originate a new LSA for the destination specifying a metric of 6237 LSInfinity. Premature aging is also be used when unexpectedly 6238 receiving self-originated LSAs during the flooding procedure 6239 (see Section 13.4). 6241 A router may only prematurely age its own self-originated LSAs. 6242 The router may not prematurely age LSAs that have been 6243 originated by other routers. An LSA is considered self- 6244 originated when either 1) the LSA's Advertising Router is equal 6245 to the router's own Router ID or 2) the LSA is a network-LSA and 6246 its Link State ID is equal to one of the router's own IP 6247 interface addresses. 6249 15. Virtual Links 6251 The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, 6252 or some areas of the Autonomous System will become unreachable. To 6253 establish/maintain connectivity of the backbone, virtual links can 6254 be configured through non-backbone areas. Virtual links serve to 6255 connect physically separate components of the backbone. The two 6256 endpoints of a virtual link are area border routers. The virtual 6257 link must be configured in both routers. The configuration 6258 information in each router consists of the other virtual endpoint 6259 (the other area border router), and the non-backbone area the two 6260 routers have in common (called the Transit area). Virtual links 6261 cannot be configured through stub areas (see Section 3.6). 6263 The virtual link is treated as if it were an unnumbered point-to- 6264 point network belonging to the backbone and joining the two area 6265 border routers. An attempt is made to establish an adjacency over 6266 the virtual link. When this adjacency is established, the virtual 6267 link will be included in backbone router-LSAs, and OSPF packets 6268 pertaining to the backbone area will flow over the adjacency. Such 6269 an adjacency has been referred to in this document as a "virtual 6270 adjacency". 6272 In each endpoint router, the cost and viability of the virtual link 6273 is discovered by examining the routing table entry for the other 6274 endpoint router. (The entry's associated area must be the 6275 configured Transit area). This is called the virtual link's 6276 corresponding routing table entry. The InterfaceUp event occurs for 6277 a virtual link when its corresponding routing table entry becomes 6278 reachable. Conversely, the InterfaceDown event occurs when its 6279 routing table entry becomes unreachable. In other words, the 6280 virtual link's viability is determined by the existence of an 6281 intra-area path, through the Transit area, between the two 6282 endpoints. Note that a virtual link whose underlying path has cost 6283 greater than hexadecimal 0xffff (the maximum size of an interface 6284 cost in a router-LSA) should be considered inoperational (i.e., 6285 treated the same as if the path did not exist). 6287 The other details concerning virtual links are as follows: 6289 o AS-external-LSAs are NEVER flooded over virtual adjacencies. 6290 This would be duplication of effort, since the same AS- 6291 external-LSAs are already flooded throughout the virtual link's 6292 Transit area. For this same reason, AS-external-LSAs are not 6293 summarized over virtual adjacencies during the Database Exchange 6294 process. 6296 o The cost of a virtual link is NOT configured. It is defined to 6297 be the cost of the intra-area path between the two defining area 6298 border routers. This cost appears in the virtual link's 6299 corresponding routing table entry. When the cost of a virtual 6300 link changes, a new router-LSA should be originated for the 6301 backbone area. 6303 o Just as the virtual link's cost and viability are determined by 6304 the routing table build process (through construction of the 6305 routing table entry for the other endpoint), so are the IP 6306 interface address for the virtual interface and the virtual 6307 neighbor's IP address. These are used when sending OSPF 6308 protocol packets over the virtual link. Note that when one (or 6309 both) of the virtual link endpoints connect to the Transit area 6310 via an unnumbered point-to-point link, it may be impossible to 6311 calculate either the virtual interface's IP address and/or the 6312 virtual neighbor's IP address, thereby causing the virtual link 6313 to fail. 6315 o In each endpoint's router-LSA for the backbone, the virtual link 6316 is represented as a Type 4 link whose Link ID is set to the 6317 virtual neighbor's OSPF Router ID and whose Link Data is set to 6318 the virtual interface's IP address. See Section 12.4.1 for more 6319 information. 6321 o A non-backbone area can carry transit data traffic (i.e., is 6322 considered a "transit area") if and only if it serves as the 6323 Transit area for one or more fully adjacent virtual links (see 6324 TransitCapability in Sections 6 and 16.1). Such an area requires 6325 special treatment when summarizing backbone networks into it 6326 (see Section 12.4.3), and during the routing calculation (see 6327 Section 16.3). 6329 o The time between link state retransmissions, RxmtInterval, is 6330 configured for a virtual link. This should be well over the 6331 expected round-trip delay between the two routers. This may be 6332 hard to estimate for a virtual link; it is better to err on the 6333 side of making it too large. 6335 16. Calculation of the routing table 6337 This section details the OSPF routing table calculation. Using its 6338 attached areas' link state databases as input, a router runs the 6339 following algorithm, building its routing table step by step. At 6340 each step, the router must access individual pieces of the link 6341 state databases (e.g., a router-LSA originated by a certain router). 6342 This access is performed by the lookup function discussed in Section 6343 12.2. The lookup process may return an LSA whose LS age is equal to 6344 MaxAge. Such an LSA should not be used in the routing table 6345 calculation, and is treated just as if the lookup process had 6346 failed. 6348 The OSPF routing table's organization is explained in Section 11. 6349 Two examples of the routing table build process are presented in 6350 Sections 11.2 and 11.3. This process can be broken into the 6351 following steps: 6353 (1) The present routing table is invalidated. The routing table is 6354 built again from scratch. The old routing table is saved so 6355 that changes in routing table entries can be identified. 6357 (2) The intra-area routes are calculated by building the shortest- 6358 path tree for each attached area. In particular, all routing 6359 table entries whose Destination Type is "area border router" are 6360 calculated in this step. This step is described in two parts. 6361 At first the tree is constructed by only considering those links 6362 between routers and transit networks. Then the stub networks 6363 are incorporated into the tree. During the area's shortest-path 6364 tree calculation, the area's TransitCapability is also 6365 calculated for later use in Step 4. 6367 (3) The inter-area routes are calculated, through examination of 6368 summary-LSAs. If the router is attached to multiple areas 6369 (i.e., it is an area border router), only backbone summary-LSAs 6370 are examined. 6372 (4) In area border routers connecting to one or more transit areas 6373 (i.e, non-backbone areas whose TransitCapability is found to be 6374 TRUE), the transit areas' summary-LSAs are examined to see 6375 whether better paths exist using the transit areas than were 6376 found in Steps 2-3 above. 6378 (5) Routes to external destinations are calculated, through 6379 examination of AS-external-LSAs. The locations of the AS 6380 boundary routers (which originate the AS-external-LSAs) have 6381 been determined in steps 2-4. 6383 Steps 2-5 are explained in further detail below. 6385 Changes made to routing table entries as a result of these 6386 calculations can cause the OSPF protocol to take further actions. 6387 For example, a change to an intra-area route will cause an area 6388 border router to originate new summary-LSAs (see Section 12.4). See 6389 Section 16.7 for a complete list of the OSPF protocol actions 6390 resulting from routing table changes. 6392 16.1. Calculating the shortest-path tree for an area 6394 This calculation yields the set of intra-area routes associated 6395 with an area (called hereafter Area A). A router calculates the 6396 shortest-path tree using itself as the root.[22] The formation 6397 of the shortest path tree is done here in two stages. In the 6398 first stage, only links between routers and transit networks are 6399 considered. Using the Dijkstra algorithm, a tree is formed from 6400 this subset of the link state database. In the second stage, 6401 leaves are added to the tree by considering the links to stub 6402 networks. 6404 The procedure will be explained using the graph terminology that 6405 was introduced in Section 2. The area's link state database is 6406 represented as a directed graph. The graph's vertices are 6407 routers, transit networks and stub networks. The first stage of 6408 the procedure concerns only the transit vertices (routers and 6409 transit networks) and their connecting links. Throughout the 6410 shortest path calculation, the following data is also associated 6411 with each transit vertex: 6413 Vertex (node) ID 6414 A 32-bit number which together with the vertex type (router 6415 or network) uniquely identifies the vertex. For router 6416 vertices the Vertex ID is the router's OSPF Router ID. For 6417 network vertices, it is the IP address of the network's 6418 Designated Router. 6420 An LSA 6421 Each transit vertex has an associated LSA. For router 6422 vertices, this is a router-LSA. For transit networks, this 6423 is a network-LSA (which is actually originated by the 6424 network's Designated Router). In any case, the LSA's Link 6425 State ID is always equal to the above Vertex ID. 6427 List of next hops 6428 The list of next hops for the current set of shortest paths 6429 from the root to this vertex. There can be multiple 6430 shortest paths due to the equal-cost multipath capability. 6431 Each next hop indicates the outgoing router interface to use 6432 when forwarding traffic to the destination. On broadcast, 6433 Point-to-MultiPoint and NBMA networks, the next hop also 6434 includes the IP address of the next router (if any) in the 6435 path towards the destination. 6437 Distance from root 6438 The link state cost of the current set of shortest paths 6439 from the root to the vertex. The link state cost of a path 6440 is calculated as the sum of the costs of the path's 6441 constituent links (as advertised in router-LSAs and 6442 network-LSAs). One path is said to be "shorter" than 6443 another if it has a smaller link state cost. 6445 The first stage of the procedure (i.e., the Dijkstra algorithm) 6446 can now be summarized as follows. At each iteration of the 6447 algorithm, there is a list of candidate vertices. Paths from 6448 the root to these vertices have been found, but not necessarily 6449 the shortest ones. However, the paths to the candidate vertex 6450 that is closest to the root are guaranteed to be shortest; this 6451 vertex is added to the shortest-path tree, removed from the 6452 candidate list, and its adjacent vertices are examined for 6453 possible addition to/modification of the candidate list. The 6454 algorithm then iterates again. It terminates when the candidate 6455 list becomes empty. 6457 The following steps describe the algorithm in detail. Remember 6458 that we are computing the shortest path tree for Area A. All 6459 references to link state database lookup below are from Area A's 6460 database. 6462 (1) Initialize the algorithm's data structures. Clear the list 6463 of candidate vertices. Initialize the shortest-path tree to 6464 only the root (which is the router doing the calculation). 6465 Set Area A's TransitCapability to FALSE. 6467 (2) Call the vertex just added to the tree vertex V. Examine 6468 the LSA associated with vertex V. This is a lookup in the 6469 Area A's link state database based on the Vertex ID. If 6470 this is a router-LSA, and bit V of the router-LSA (see 6471 Section A.4.2) is set, set Area A's TransitCapability to 6472 TRUE. In any case, each link described by the LSA gives the 6473 cost to an adjacent vertex. For each described link, (say 6474 it joins vertex V to vertex W): 6476 (a) If this is a link to a stub network, examine the next 6477 link in V's LSA. Links to stub networks will be 6478 considered in the second stage of the shortest path 6479 calculation. 6481 (b) Otherwise, W is a transit vertex (router or transit 6482 network). Look up the vertex W's LSA (router-LSA or 6483 network-LSA) in Area A's link state database. If the 6484 LSA does not exist, or its LS age is equal to MaxAge, or 6485 it does not have a link back to vertex V, examine the 6486 next link in V's LSA.[23] 6488 (c) If vertex W is already on the shortest-path tree, 6489 examine the next link in the LSA. 6491 (d) Calculate the link state cost D of the resulting path 6492 from the root to vertex W. D is equal to the sum of the 6493 link state cost of the (already calculated) shortest 6494 path to vertex V and the advertised cost of the link 6495 between vertices V and W. If D is: 6497 o Greater than the value that already appears for 6498 vertex W on the candidate list, then examine the 6499 next link. 6501 o Equal to the value that appears for vertex W on the 6502 candidate list, calculate the set of next hops that 6503 result from using the advertised link. Input to 6504 this calculation is the destination (W), and its 6505 parent (V). This calculation is shown in Section 6506 16.1.1. This set of hops should be added to the 6507 next hop values that appear for W on the candidate 6508 list. 6510 o Less than the value that appears for vertex W on the 6511 candidate list, or if W does not yet appear on the 6512 candidate list, then set the entry for W on the 6513 candidate list to indicate a distance of D from the 6514 root. Also calculate the list of next hops that 6515 result from using the advertised link, setting the 6516 next hop values for W accordingly. The next hop 6517 calculation is described in Section 16.1.1; it takes 6518 as input the destination (W) and its parent (V). 6520 (3) If at this step the candidate list is empty, the shortest- 6521 path tree (of transit vertices) has been completely built 6522 and this stage of the procedure terminates. Otherwise, 6523 choose the vertex belonging to the candidate list that is 6524 closest to the root, and add it to the shortest-path tree 6525 (removing it from the candidate list in the process). Note 6526 that when there is a choice of vertices closest to the root, 6527 network vertices must be chosen before router vertices in 6528 order to necessarily find all equal-cost paths. This is 6529 consistent with the tie-breakers that were introduced in the 6530 modified Dijkstra algorithm used by OSPF's Multicast routing 6531 extensions (MOSPF). 6533 (4) Possibly modify the routing table. For those routing table 6534 entries modified, the associated area will be set to Area A, 6535 the path type will be set to intra-area, and the cost will 6536 be set to the newly discovered shortest path's calculated 6537 distance. 6539 If the newly added vertex is an area border router or AS 6540 boundary router, a routing table entry is added whose 6541 destination type is "router". The Options field found in 6542 the associated router-LSA is copied into the routing table 6543 entry's Optional capabilities field. Call the newly added 6544 vertex Router X. If Router X is the endpoint of one of the 6545 calculating router's virtual links, and the virtual link 6546 uses Area A as Transit area: the virtual link is declared 6547 up, the IP address of the virtual interface is set to the IP 6548 address of the outgoing interface calculated above for 6549 Router X, and the virtual neighbor's IP address is set to 6550 Router X's interface address (contained in Router X's 6551 router-LSA) that points back to the root of the shortest- 6552 path tree; equivalently, this is the interface that points 6553 back to Router X's parent vertex on the shortest-path tree 6554 (similar to the calculation in Section 16.1.1). 6556 If the newly added vertex is a transit network, the routing 6557 table entry for the network is located. The entry's 6558 Destination ID is the IP network number, which can be 6559 obtained by masking the Vertex ID (Link State ID) with its 6560 associated subnet mask (found in the body of the associated 6561 network-LSA). If the routing table entry already exists 6562 (i.e., there is already an intra-area route to the 6563 destination installed in the routing table), multiple 6564 vertices have mapped to the same IP network. For example, 6565 this can occur when a new Designated Router is being 6566 established. In this case, the current routing table entry 6567 should be overwritten if and only if the newly found path is 6568 just as short and the current routing table entry's Link 6569 State Origin has a smaller Link State ID than the newly 6570 added vertex' LSA. 6572 If there is no routing table entry for the network (the 6573 usual case), a routing table entry for the IP network should 6574 be added. The routing table entry's Link State Origin 6575 should be set to the newly added vertex' LSA. 6577 (5) Iterate the algorithm by returning to Step 2. 6579 The stub networks are added to the tree in the procedure's 6580 second stage. In this stage, all router vertices are again 6581 examined. Those that have been determined to be unreachable in 6582 the above first phase are discarded. For each reachable router 6583 vertex (call it V), the associated router-LSA is found in the 6584 link state database. Each stub network link appearing in the 6585 LSA is then examined, and the following steps are executed: 6587 (1) Calculate the distance D of stub network from the root. D 6588 is equal to the distance from the root to the router vertex 6589 (calculated in stage 1), plus the stub network link's 6590 advertised cost. Compare this distance to the current best 6591 cost to the stub network. This is done by looking up the 6592 stub network's current routing table entry. If the 6593 calculated distance D is larger, go on to examine the next 6594 stub network link in the LSA. 6596 (2) If this step is reached, the stub network's routing table 6597 entry must be updated. Calculate the set of next hops that 6598 would result from using the stub network link. This 6599 calculation is shown in Section 16.1.1; input to this 6600 calculation is the destination (the stub network) and the 6601 parent vertex (the router vertex). If the distance D is the 6602 same as the current routing table cost, simply add this set 6603 of next hops to the routing table entry's list of next hops. 6604 In this case, the routing table already has a Link State 6605 Origin. If this Link State Origin is a router-LSA whose 6606 Link State ID is smaller than V's Router ID, reset the Link 6607 State Origin to V's router-LSA. 6609 Otherwise D is smaller than the routing table cost. 6610 Overwrite the current routing table entry by setting the 6611 routing table entry's cost to D, and by setting the entry's 6612 list of next hops to the newly calculated set. Set the 6613 routing table entry's Link State Origin to V's router-LSA. 6614 Then go on to examine the next stub network link. 6616 For all routing table entries added/modified in the second 6617 stage, the associated area will be set to Area A and the path 6618 type will be set to intra-area. When the list of reachable 6619 router-LSAs is exhausted, the second stage is completed. At 6620 this time, all intra-area routes associated with Area A have 6621 been determined. 6623 The specification does not require that the above two stage 6624 method be used to calculate the shortest path tree. However, if 6625 another algorithm is used, an identical tree must be produced. 6626 For this reason, it is important to note that links between 6627 transit vertices must be bidirectional in order to be included 6628 in the above tree. It should also be mentioned that more 6629 efficient algorithms exist for calculating the tree; for 6630 example, the incremental SPF algorithm described in [Ref1]. 6632 16.1.1. The next hop calculation 6634 This section explains how to calculate the current set of 6635 next hops to use for a destination. Each next hop consists 6636 of the outgoing interface to use in forwarding packets to 6637 the destination together with the IP address of the next hop 6638 router (if any). The next hop calculation is invoked each 6639 time a shorter path to the destination is discovered. This 6640 can happen in either stage of the shortest-path tree 6641 calculation (see Section 16.1). In stage 1 of the 6642 shortest-path tree calculation a shorter path is found as 6643 the destination is added to the candidate list, or when the 6644 destination's entry on the candidate list is modified (Step 6645 2d of Stage 1). In stage 2 a shorter path is discovered 6646 each time the destination's routing table entry is modified 6647 (Step 2 of Stage 2). 6649 The set of next hops to use for the destination may be 6650 recalculated several times during the shortest-path tree 6651 calculation, as shorter and shorter paths are discovered. 6652 In the end, the destination's routing table entry will 6653 always reflect the next hops resulting from the absolute 6654 shortest path(s). 6656 Input to the next hop calculation is a) the destination and 6657 b) its parent in the current shortest path between the root 6658 (the calculating router) and the destination. The parent is 6659 always a transit vertex (i.e., always a router or a transit 6660 network). 6662 If there is at least one intervening router in the current 6663 shortest path between the destination and the root, the 6664 destination simply inherits the set of next hops from the 6665 parent. Otherwise, there are two cases. In the first case, 6666 the parent vertex is the root (the calculating router 6667 itself). This means that the destination is either a 6668 directly connected network or directly connected router. 6669 The outgoing interface in this case is simply the OSPF 6670 interface connecting to the destination network/router. If 6671 the destination is a router which connects to the 6672 calculating router via a Point-to-MultiPoint network, the 6673 destination's next hop IP address(es) can be determined by 6674 examining the destination's router-LSA: each link pointing 6675 back to the calculating router and having a Link Data field 6676 belonging to the Point-to-MultiPoint network provides an IP 6677 address of the next hop router. If the destination is a 6678 directly connected network, or a router which connects to 6679 the calculating router via a point-to-point interface, no 6680 next hop IP address is required. If the destination is a 6681 router connected to the calculating router via a virtual 6682 link, the setting of the next hop should be deferred until 6683 the calculation in Section 16.3. 6685 In the second case, the parent vertex is a network that 6686 directly connects the calculating router to the destination 6687 router. The list of next hops is then determined by 6688 examining the destination's router-LSA. For each link in 6689 the router-LSA that points back to the parent network, the 6690 link's Link Data field provides the IP address of a next hop 6691 router. The outgoing interface to use can then be derived 6692 from the next hop IP address (or it can be inherited from 6693 the parent network). 6695 16.2. Calculating the inter-area routes 6697 The inter-area routes are calculated by examining summary-LSAs. 6698 If the router has active attachments to multiple areas, only 6699 backbone summary-LSAs are examined. Routers attached to a 6700 single area examine that area's summary-LSAs. In either case, 6701 the summary-LSAs examined below are all part of a single area's 6702 link state database (call it Area A). 6704 Summary-LSAs are originated by the area border routers. Each 6705 summary-LSA in Area A is considered in turn. Remember that the 6706 destination described by a summary-LSA is either a network (Type 6707 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). 6708 For each summary-LSA: 6710 (1) If the cost specified by the LSA is LSInfinity, or if the 6711 LSA's LS age is equal to MaxAge, then examine the the next 6712 LSA. 6714 (2) If the LSA was originated by the calculating router itself, 6715 examine the next LSA. 6717 (3) If it is a Type 3 summary-LSA, and the collection of 6718 destinations described by the summary-LSA equals one of the 6719 router's configured area address ranges (see Section 3.5), 6720 and the particular area address range is active, then the 6721 summary-LSA should be ignored. "Active" means that there 6722 are one or more reachable (by intra-area paths) networks 6723 contained in the area range. 6725 (4) Else, call the destination described by the LSA N (for Type 6726 3 summary-LSAs, N's address is obtained by masking the LSA's 6727 Link State ID with the network/subnet mask contained in the 6728 body of the LSA), and the area border originating the LSA 6729 BR. Look up the routing table entry for BR having Area A as 6730 its associated area. If no such entry exists for router BR 6731 (i.e., BR is unreachable in Area A), do nothing with this 6732 LSA and consider the next in the list. Else, this LSA 6733 describes an inter-area path to destination N, whose cost is 6734 the distance to BR plus the cost specified in the LSA. Call 6735 the cost of this inter-area path IAC. 6737 (5) Next, look up the routing table entry for the destination N. 6738 (If N is an AS boundary router, look up the "router" routing 6739 table entry associated with Area A). If no entry exists for 6740 N or if the entry's path type is "type 1 external" or "type 6741 2 external", then install the inter-area path to N, with 6742 associated area Area A, cost IAC, next hop equal to the list 6743 of next hops to router BR, and Advertising router equal to 6744 BR. 6746 (6) Else, if the paths present in the table are intra-area 6747 paths, do nothing with the LSA (intra-area paths are always 6748 preferred). 6750 (7) Else, the paths present in the routing table are also 6751 inter-area paths. Install the new path through BR if it is 6752 cheaper, overriding the paths in the routing table. 6753 Otherwise, if the new path is the same cost, add it to the 6754 list of paths that appear in the routing table entry. 6756 16.3. Examining transit areas' summary-LSAs 6758 This step is only performed by area border routers attached to 6759 one or more non-backbone areas that are capable of carrying 6760 transit traffic (i.e., "transit areas", or those areas whose 6761 TransitCapability parameter has been set to TRUE in Step 2 of 6762 the Dijkstra algorithm (see Section 16.1). 6764 The purpose of the calculation below is to examine the transit 6765 areas to see whether they provide any better (shorter) paths 6766 than the paths previously calculated in Sections 16.1 and 16.2. 6767 Any paths found that are better than or equal to previously 6768 discovered paths are installed in the routing table. 6770 The calculation proceeds as follows. All the transit areas' 6771 summary-LSAs are examined in turn. Each such summary-LSA 6772 describes a route through a transit area Area A to a Network N 6773 (N's address is obtained by masking the LSA's Link State ID with 6774 the network/subnet mask contained in the body of the LSA) or in 6775 the case of a Type 4 summary-LSA, to an AS boundary router N. 6776 Suppose also that the summary-LSA was originated by an area 6777 border router BR. 6779 (1) If the cost advertised by the summary-LSA is LSInfinity, or 6780 if the LSA's LS age is equal to MaxAge, then examine the 6781 next LSA. 6783 (2) If the summary-LSA was originated by the calculating router 6784 itself, examine the next LSA. 6786 (3) Look up the routing table entry for N. (If N is an AS 6787 boundary router, look up the "router" routing table entry 6788 associated with the backbone area). If it does not exist, or 6789 if the route type is other than intra-area or inter-area, or 6790 if the area associated with the routing table entry is not 6791 the backbone area, then examine the next LSA. In other 6792 words, this calculation only updates backbone intra-area 6793 routes found in Section 16.1 and inter-area routes found in 6794 Section 16.2. 6796 (4) Look up the routing table entry for the advertising router 6797 BR associated with the Area A. If it is unreachable, examine 6798 the next LSA. Otherwise, the cost to destination N is the 6799 sum of the cost in BR's Area A routing table entry and the 6800 cost advertised in the LSA. Call this cost IAC. 6802 (5) If this cost is less than the cost occurring in N's routing 6803 table entry, overwrite N's list of next hops with those used 6804 for BR, and set N's routing table cost to IAC. Else, if IAC 6805 is the same as N's current cost, add BR's list of next hops 6806 to N's list of next hops. In any case, the area associated 6807 with N's routing table entry must remain the backbone area, 6808 and the path type (either intra-area or inter-area) must 6809 also remain the same. 6811 ........................ 6812 . Area 1 (transit) . + 6813 . . | 6814 . +---+1 1+---+100 | 6815 . |RT2|----------|RT4|=========| 6816 . 1/+---+********* +---+ | 6817 . /******* . | 6818 . 1/*Virtual . | 6819 1+---+/* Link . Net|work 6820 =======|RT1|* . | N1 6821 +---+\ . | 6822 . \ . | 6823 . \ . | 6824 . 1\+---+1 1+---+20 | 6825 . |RT3|----------|RT5|=========| 6826 . +---+ +---+ | 6827 . . | 6828 ........................ + 6830 Figure 17: Routing through transit areas 6832 It is important to note that the above calculation never makes 6833 unreachable destinations reachable, but instead just potentially 6834 finds better paths to already reachable destinations. The 6835 calculation installs any better cost found into the routing 6836 table entry, from which it may be readvertised in summary-LSAs 6837 to other areas. 6839 As an example of the calculation, consider the Autonomous System 6840 pictured in Figure 17. There is a single non-backbone area 6841 (Area 1) that physically divides the backbone into two separate 6842 pieces. To maintain connectivity of the backbone, a virtual link 6843 has been configured between routers RT1 and RT4. On the right 6844 side of the figure, Network N1 belongs to the backbone. The 6845 dotted lines indicate that there is a much shorter intra-area 6846 backbone path between router RT5 and Network N1 (cost 20) than 6847 there is between Router RT4 and Network N1 (cost 100). Both 6848 Router RT4 and Router RT5 will inject summary-LSAs for Network 6849 N1 into Area 1. 6851 After the shortest-path tree has been calculated for the 6852 backbone in Section 16.1, Router RT1 (left end of the virtual 6853 link) will have calculated a path through Router RT4 for all 6854 data traffic destined for Network N1. However, since Router RT5 6855 is so much closer to Network N1, all routers internal to Area 1 6856 (e.g., Routers RT2 and RT3) will forward their Network N1 6857 traffic towards Router RT5, instead of RT4. And indeed, after 6858 examining Area 1's summary-LSAs by the above calculation, Router 6859 RT1 will also forward Network N1 traffic towards RT5. Note that 6860 in this example the virtual link enables transit data traffic to 6861 be forwarded through Area 1, but the actual path the transit 6862 data traffic takes does not follow the virtual link. In other 6863 words, virtual links allow transit traffic to be forwarded 6864 through an area, but do not dictate the precise path that the 6865 traffic will take. 6867 16.4. Calculating AS external routes 6869 AS external routes are calculated by examining AS-external-LSAs. 6870 Each of the AS-external-LSAs is considered in turn. Most AS- 6871 external-LSAs describe routes to specific IP destinations. An 6872 AS-external-LSA can also describe a default route for the 6873 Autonomous System (Destination ID = DefaultDestination, 6874 network/subnet mask = 0x00000000). For each AS-external-LSA: 6876 (1) If the cost specified by the LSA is LSInfinity, or if the 6877 LSA's LS age is equal to MaxAge, then examine the next LSA. 6879 (2) If the LSA was originated by the calculating router itself, 6880 examine the next LSA. 6882 (3) Call the destination described by the LSA N. N's address is 6883 obtained by masking the LSA's Link State ID with the 6884 network/subnet mask contained in the body of the LSA. Look 6885 up the routing table entries (potentially one per attached 6886 area) for the AS boundary router (ASBR) that originated the 6887 LSA. If no entries exist for router ASBR (i.e., ASBR is 6888 unreachable), do nothing with this LSA and consider the next 6889 in the list. 6891 Else, this LSA describes an AS external path to destination 6892 N. Examine the forwarding address specified in the AS- 6893 external-LSA. This indicates the IP address to which 6894 packets for the destination should be forwarded. 6896 If the forwarding address is set to 0.0.0.0, packets should 6897 be sent to the ASBR itself. Among the multiple routing table 6898 entries for the ASBR, select the preferred entry as follows. 6899 If RFC1583Compatibility is set to "disabled", prune the set 6900 of routing table entries for the ASBR as described in 6901 Section 16.4.1. In any case, among the remaining routing 6902 table entries, select the routing table entry with the least 6903 cost; when there are multiple least cost routing table 6904 entries the entry whose associated area has the largest OSPF 6905 Area ID (when considered as an unsigned 32-bit integer) is 6906 chosen. 6908 If the forwarding address is non-zero, look up the 6909 forwarding address in the routing table.[24] The matching 6910 routing table entry must specify an intra-area or inter-area 6911 path; if no such path exists, do nothing with the LSA and 6912 consider the next in the list. 6914 (4) Let X be the cost specified by the preferred routing table 6915 entry for the ASBR/forwarding address, and Y the cost 6916 specified in the LSA. X is in terms of the link state 6917 metric, and Y is a type 1 or 2 external metric. 6919 (5) Look up the routing table entry for the destination N. If 6920 no entry exists for N, install the AS external path to N, 6921 with next hop equal to the list of next hops to the 6922 forwarding address, and advertising router equal to ASBR. 6923 If the external metric type is 1, then the path-type is set 6924 to type 1 external and the cost is equal to X+Y. If the 6925 external metric type is 2, the path-type is set to type 2 6926 external, the link state component of the route's cost is X, 6927 and the type 2 cost is Y. 6929 (6) Compare the AS external path described by the LSA with the 6930 existing paths in N's routing table entry, as follows. If 6931 the new path is preferred, it replaces the present paths in 6932 N's routing table entry. If the new path is of equal 6933 preference, it is added to N's routing table entry's list of 6934 paths. 6936 (a) Intra-area and inter-area paths are always preferred 6937 over AS external paths. 6939 (b) Type 1 external paths are always preferred over type 2 6940 external paths. When all paths are type 2 external 6941 paths, the paths with the smallest advertised type 2 6942 metric are always preferred. 6944 (c) If the new AS external path is still indistinguishable 6945 from the current paths in the N's routing table entry, 6946 and RFC1583Compatibility is set to "disabled", select 6947 the preferred paths based on the intra-AS paths to the 6948 ASBR/forwarding addresses, as specified in Section 6949 16.4.1. 6951 (d) If the new AS external path is still indistinguishable 6952 from the current paths in the N's routing table entry, 6953 select the preferred path based on a least cost 6954 comparison. Type 1 external paths are compared by 6955 looking at the sum of the distance to the forwarding 6956 address and the advertised type 1 metric (X+Y). Type 2 6957 external paths advertising equal type 2 metrics are 6958 compared by looking at the distance to the forwarding 6959 addresses. 6961 16.4.1. External path preferences 6963 When multiple intra-AS paths are available to 6964 ASBRs/forwarding addresses, the following rules indicate 6965 which paths are preferred. These rules apply when the same 6966 ASBR is reachable through multiple areas, or when trying to 6967 decide which of several AS-external-LSAs should be 6968 preferred. In the former case the paths all terminate at the 6969 same ASBR, while in the latter the paths terminate at 6970 separate ASBRs/forwarding addresses. In either case, each 6971 path is represented by a separate routing table entry as 6972 defined in Section 11. 6974 This section only applies when RFC1583Compatibility is set 6975 to "disabled". 6977 The path preference rules, stated from highest to lowest 6978 preference, are as follows. Note that as a result of these 6979 rules, there may still be multiple paths of the highest 6980 preference. In this case, the path to use must be determined 6981 based on cost, as described in Section 16.4. 6983 o Intra-area paths using non-backbone areas are always the 6984 most preferred. 6986 o Otherwise, intra-area backbone paths are preferred. 6988 o Inter-area paths are the least preferred. 6990 16.5. Incremental updates -- summary-LSAs 6992 When a new summary-LSA is received, it is not necessary to 6993 recalculate the entire routing table. Call the destination 6994 described by the summary-LSA N (N's address is obtained by 6995 masking the LSA's Link State ID with the network/subnet mask 6996 contained in the body of the LSA), and let Area A be the area to 6997 which the LSA belongs. There are then two separate cases: 6999 Case 1: Area A is the backbone and/or the router is not an area 7000 border router. 7001 In this case, the following calculations must be performed. 7002 First, if there is presently an inter-area route to the 7003 destination N, N's routing table entry is invalidated, 7004 saving the entry's values for later comparisons. Then the 7005 calculation in Section 16.2 is run again for the single 7006 destination N. In this calculation, all of Area A's 7007 summary-LSAs that describe a route to N are examined. In 7008 addition, if the router is an area border router attached to 7009 one or more transit areas, the calculation in Section 16.3 7010 must be run again for the single destination. If the 7011 results of these calculations have changed the cost/path to 7012 an AS boundary router (as would be the case for a Type 4 7013 summary-LSA) or to any forwarding addresses, all AS- 7014 external-LSAs will have to be reexamined by rerunning the 7015 calculation in Section 16.4. Otherwise, if N is now newly 7016 unreachable, the calculation in Section 16.4 must be rerun 7017 for the single destination N, in case an alternate external 7018 route to N exists. 7020 Case 2: Area A is a transit area and the router is an area 7021 border router. 7022 In this case, the following calculations must be performed. 7023 First, if N's routing table entry presently contains one or 7024 more inter-area paths that utilize the transit area Area A, 7025 these paths should be removed. If this removes all paths 7026 from the routing table entry, the entry should be 7027 invalidated. The entry's old values should be saved for 7028 later comparisons. Next the calculation in Section 16.3 must 7029 be run again for the single destination N. If the results of 7030 this calculation have caused the cost to N to increase, the 7031 complete routing table calculation must be rerun starting 7032 with the Dijkstra algorithm specified in Section 16.1. 7033 Otherwise, if the cost/path to an AS boundary router (as 7034 would be the case for a Type 4 summary-LSA) or to any 7035 forwarding addresses has changed, all AS-external-LSAs will 7036 have to be reexamined by rerunning the calculation in 7037 Section 16.4. Otherwise, if N is now newly unreachable, the 7038 calculation in Section 16.4 must be rerun for the single 7039 destination N, in case an alternate external route to N 7040 exists. 7042 16.6. Incremental updates -- AS-external-LSAs 7044 When a new AS-external-LSA is received, it is not necessary to 7045 recalculate the entire routing table. Call the destination 7046 described by the AS-external-LSA N. N's address is obtained by 7047 masking the LSA's Link State ID with the network/subnet mask 7048 contained in the body of the LSA. If there is already an intra- 7049 area or inter-area route to the destination, no recalculation is 7050 necessary (internal routes take precedence). 7052 Otherwise, the procedure in Section 16.4 will have to be 7053 performed, but only for those AS-external-LSAs whose destination 7054 is N. Before this procedure is performed, the present routing 7055 table entry for N should be invalidated. 7057 16.7. Events generated as a result of routing table changes 7059 Changes to routing table entries sometimes cause the OSPF area 7060 border routers to take additional actions. These routers need 7061 to act on the following routing table changes: 7063 o The cost or path type of a routing table entry has changed. 7064 If the destination described by this entry is a Network or 7065 AS boundary router, and this is not simply a change of AS 7066 external routes, new summary-LSAs may have to be generated 7067 (potentially one for each attached area, including the 7068 backbone). See Section 12.4.3 for more information. If a 7069 previously advertised entry has been deleted, or is no 7070 longer advertisable to a particular area, the LSA must be 7071 flushed from the routing domain by setting its LS age to 7072 MaxAge and reflooding (see Section 14.1). 7074 o A routing table entry associated with a configured virtual 7075 link has changed. The destination of such a routing table 7076 entry is an area border router. The change indicates a 7077 modification to the virtual link's cost or viability. 7079 If the entry indicates that the area border router is newly 7080 reachable, the corresponding virtual link is now 7081 operational. An InterfaceUp event should be generated for 7082 the virtual link, which will cause a virtual adjacency to 7083 begin to form (see Section 10.3). At this time the virtual 7084 link's IP interface address and the virtual neighbor's 7085 Neighbor IP address are also calculated. 7087 If the entry indicates that the area border router is no 7088 longer reachable, the virtual link and its associated 7089 adjacency should be destroyed. This means an InterfaceDown 7090 event should be generated for the associated virtual link. 7092 If the cost of the entry has changed, and there is a fully 7093 established virtual adjacency, a new router-LSA for the 7094 backbone must be originated. This in turn may cause further 7095 routing table changes. 7097 16.8. Equal-cost multipath 7099 The OSPF protocol maintains multiple equal-cost routes to all 7100 destinations. This can be seen in the steps used above to 7101 calculate the routing table, and in the definition of the 7102 routing table structure. 7104 Each one of the multiple routes will be of the same type 7105 (intra-area, inter-area, type 1 external or type 2 external), 7106 cost, and will have the same associated area. However, each 7107 route may specify a separate next hop and Advertising router. 7109 There is no requirement that a router running OSPF keep track of 7110 all possible equal-cost routes to a destination. An 7111 implementation may choose to keep only a fixed number of routes 7112 to any given destination. This does not affect any of the 7113 algorithms presented in this specification. 7115 Footnotes 7117 [1]The graph's vertices represent either routers, transit networks, 7118 or stub networks. Since routers may belong to multiple areas, it is 7119 not possible to color the graph's vertices. 7121 [2]It is possible for all of a router's interfaces to be unnumbered 7122 point-to-point links. In this case, an IP address must be assigned 7123 to the router. This address will then be advertised in the router's 7124 router-LSA as a host route. 7126 [3]Note that in these cases both interfaces, the non-virtual and the 7127 virtual, would have the same IP address. 7129 [4]Note that no host route is generated for, and no IP packets can 7130 be addressed to, interfaces to unnumbered point-to-point networks. 7131 This is regardless of such an interface's state. 7133 [5]It is instructive to see what happens when the Designated Router 7134 for the network crashes. Call the Designated Router for the network 7135 RT1, and the Backup Designated Router RT2. If Router RT1 crashes 7136 (or maybe its interface to the network dies), the other routers on 7137 the network will detect RT1's absence within RouterDeadInterval 7138 seconds. All routers may not detect this at precisely the same 7139 time; the routers that detect RT1's absence before RT2 does will, 7140 for a time, select RT2 to be both Designated Router and Backup 7141 Designated Router. When RT2 detects that RT1 is gone it will move 7142 itself to Designated Router. At this time, the remaining router 7143 having highest Router Priority will be selected as Backup Designated 7144 Router. 7146 [6]On point-to-point networks, the lower level protocols indicate 7147 whether the neighbor is up and running. Likewise, existence of the 7148 neighbor on virtual links is indicated by the routing table 7149 calculation. However, in both these cases, the Hello Protocol is 7150 still used. This ensures that communication between the neighbors 7151 is bidirectional, and that each of the neighbors has a functioning 7152 routing protocol layer. 7154 [7]When the identity of the Designated Router is changing, it may be 7155 quite common for a neighbor in this state to send the router a 7156 Database Description packet; this means that there is some momentary 7157 disagreement on the Designated Router's identity. 7159 [8]Note that it is possible for a router to resynchronize any of its 7160 fully established adjacencies by setting the adjacency's state back 7161 to ExStart. This will cause the other end of the adjacency to 7162 process a SeqNumberMismatch event, and therefore to also go back to 7163 ExStart state. 7165 [9]The address space of IP networks and the address space of OSPF 7166 Router IDs may overlap. That is, a network may have an IP address 7167 which is identical (when considered as a 32-bit number) to some 7168 router's Router ID. 7170 [10]"Discard" entries are necessary to ensure that route 7171 summarization at area boundaries will not cause packet looping. 7173 [11]It is assumed that, for two different address ranges matching 7174 the destination, one range is more specific than the other. Non- 7175 contiguous subnet masks can be configured to violate this 7176 assumption. Such subnet mask configurations cannot be handled by the 7177 OSPF protocol. 7179 [12]MaxAgeDiff is an architectural constant. It indicates the 7180 maximum dispersion of ages, in seconds, that can occur for a single 7181 LSA instance as it is flooded throughout the routing domain. If two 7182 LSAs differ by more than this, they are assumed to be different 7183 instances of the same LSA. This can occur when a router restarts 7184 and loses track of the LSA's previous LS sequence number. See 7185 Section 13.4 for more details. 7187 [13]When two LSAs have different LS checksums, they are assumed to 7188 be separate instances. This can occur when a router restarts, and 7189 loses track of the LSA's previous LS sequence number. In the case 7190 where the two LSAs have the same LS sequence number, it is not 7191 possible to determine which LSA is actually newer. However, if the 7192 wrong LSA is accepted as newer, the originating router will simply 7193 originate another instance. See Section 13.4 for further details. 7195 [14]There is one instance where a lookup must be done based on 7196 partial information. This is during the routing table calculation, 7197 when a network-LSA must be found based solely on its Link State ID. 7198 The lookup in this case is still well defined, since no two 7199 network-LSAs can have the same Link State ID. 7201 [15]This is the way RFC 1583 specified point-to-point 7202 representation. It has three advantages: a) it does not require 7203 allocating a subnet to the point-to-point link, b) it tends to bias 7204 the routing so that packets destined for the point-to-point 7205 interface will actually be received over the interface (which is 7206 useful for diagnostic purposes) and c) it allows network 7207 bootstrapping of a neighbor, without requiring that the bootstrap 7208 program contain an OSPF implementation. 7210 [16]This is the more traditional point-to-point representation used 7211 by protocols such as RIP. 7213 [17]This clause covers the case: Inter-area routes are not 7214 summarized to the backbone. This is because inter-area routes are 7215 always associated with the backbone area. 7217 [18]This clause is only invoked when a non-backbone Area A supports 7218 transit data traffic (i.e., has TransitCapability set to TRUE). For 7219 example, in the area configuration of Figure 6, Area 2 can support 7220 transit traffic due to the configured virtual link between Routers 7221 RT10 and RT11. As a result, Router RT11 need only originate a single 7222 summary-LSA into Area 2 (having the collapsed destination N9- 7223 N11,H1), since all of Router RT11's other eligible routes have next 7224 hops belonging to Area 2 itself (and as such only need be advertised 7225 by other area border routers; in this case, Routers RT10 and RT7). 7227 [19]By keeping more information in the routing table, it is possible 7228 for an implementation to recalculate the shortest path tree for only 7229 a single area. In fact, there are incremental algorithms that allow 7230 an implementation to recalculate only a portion of a single area's 7231 shortest path tree [Ref1]. However, these algorithms are beyond the 7232 scope of this specification. 7234 [20]This is how the Link state request list is emptied, which 7235 eventually causes the neighbor state to transition to Full. See 7236 Section 10.9 for more details. 7238 [21]It should be a relatively rare occurrence for an LSA's LS age to 7239 reach MaxAge in this fashion. Usually, the LSA will be replaced by 7240 a more recent instance before it ages out. 7242 [22]Strictly speaking, because of equal-cost multipath, the 7243 algorithm does not create a tree. We continue to use the "tree" 7244 terminology because that is what occurs most often in the existing 7245 literature. 7247 [23]Note that the presence of any link back to V is sufficient; it 7248 need not be the matching half of the link under consideration from V 7249 to W. This is enough to ensure that, before data traffic flows 7250 between a pair of neighboring routers, their link state databases 7251 will be synchronized. 7253 [24]When the forwarding address is non-zero, it should point to a 7254 router belonging to another Autonomous System. See Section 12.4.4 7255 for more details. 7257 References 7259 [Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing 7260 Algorithm Improvements", BBN Technical Report 3803, April 7261 1978. 7263 [Ref2] Digital Equipment Corporation, "Information processing 7264 systems -- Data communications -- Intermediate System to 7265 Intermediate System Intra-Domain Routing Protocol", October 7266 1987. 7268 [Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the 7269 ARPANET", IEEE Transactions on Communications, May 1980. 7271 [Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing 7272 Information", Computer Networks, December 1983. 7274 [Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, 7275 USC/Information Sciences Institute, September 1981. 7277 [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 7278 8073", RFC 905, ISO, April 1984. 7280 [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, 7281 RFC 1112, Stanford University, May 1988. 7283 [Ref8] McCloghrie, K., and M. Rose, "Management Information Base 7284 for network management of TCP/IP-based internets: MIB-II", 7285 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 7286 International, March 1991. 7288 [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 7289 1994. 7291 [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 7292 Inter-Domain Routing (CIDR): an Address Assignment and 7293 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 7294 OARnet, September 1993. 7296 [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 7297 1700, USC/Information Sciences Institute, October 1994. 7299 [Ref12] Almquist, P., "Type of Service in the Internet Protocol 7300 Suite", RFC 1349, July 1992. 7302 [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN 7303 Protocol Handbook, April 1985. 7305 [Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution 7306 Protocol", RFC 1293, January 1992. 7308 [Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 7309 Over Frame Relay Networks", RFC 1586, March 1994. 7311 [Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol 7312 Suite", ACM Computer Communications Review, Volume 19, 7313 Number 2, pp. 32-38, April 1989. 7315 [Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 7316 April 1992. 7318 [Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 7319 Inc., March 1994. 7321 [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 7322 RainbowBridge Communications, Stanford University, March 7323 1994. 7325 [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in 7326 progress. 7328 [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 7329 1793, Cascade, April 1995. 7331 [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 7332 DECWRL, Stanford University, November 1990. 7334 [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 7335 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 7336 Systems, March 1995. 7338 [Ref24] Hinden, R., "Internet Routing Protocol Standardization 7339 Criteria", BBN, October 1991. 7341 [Ref25] Moy, J., "OSPF Version 2", RFC 2178, Cascade Communications 7342 Corp., July 1997. 7344 [Ref26] Rosen, E., "Vulnerabilities of Network Control Protocols: An 7345 Example", Computer Communication Review, July 1981. 7347 A. OSPF data formats 7349 This appendix describes the format of OSPF protocol packets and OSPF 7350 LSAs. The OSPF protocol runs directly over the IP network layer. 7351 Before any data formats are described, the details of the OSPF 7352 encapsulation are explained. 7354 Next the OSPF Options field is described. This field describes 7355 various capabilities that may or may not be supported by pieces of 7356 the OSPF routing domain. The OSPF Options field is contained in OSPF 7357 Hello packets, Database Description packets and in OSPF LSAs. 7359 OSPF packet formats are detailed in Section A.3. A description of 7360 OSPF LSAs appears in Section A.4. 7362 A.1 Encapsulation of OSPF packets 7364 OSPF runs directly over the Internet Protocol's network layer. OSPF 7365 packets are therefore encapsulated solely by IP and local data-link 7366 headers. 7368 OSPF does not define a way to fragment its protocol packets, and 7369 depends on IP fragmentation when transmitting packets larger than 7370 the network MTU. If necessary, the length of OSPF packets can be up 7371 to 65,535 bytes (including the IP header). The OSPF packet types 7372 that are likely to be large (Database Description Packets, Link 7373 State Request, Link State Update, and Link State Acknowledgment 7374 packets) can usually be split into several separate protocol 7375 packets, without loss of functionality. This is recommended; IP 7376 fragmentation should be avoided whenever possible. Using this 7377 reasoning, an attempt should be made to limit the sizes of OSPF 7378 packets sent over virtual links to 576 bytes unless Path MTU 7379 Discovery is being performed (see [Ref22]). 7381 The other important features of OSPF's IP encapsulation are: 7383 o Use of IP multicast. Some OSPF messages are multicast, when 7384 sent over broadcast networks. Two distinct IP multicast 7385 addresses are used. Packets sent to these multicast addresses 7386 should never be forwarded; they are meant to travel a single hop 7387 only. To ensure that these packets will not travel multiple 7388 hops, their IP TTL must be set to 1. 7390 AllSPFRouters 7391 This multicast address has been assigned the value 7392 224.0.0.5. All routers running OSPF should be prepared to 7393 receive packets sent to this address. Hello packets are 7394 always sent to this destination. Also, certain OSPF 7395 protocol packets are sent to this address during the 7396 flooding procedure. 7398 AllDRouters 7399 This multicast address has been assigned the value 7400 224.0.0.6. Both the Designated Router and Backup Designated 7401 Router must be prepared to receive packets destined to this 7402 address. Certain OSPF protocol packets are sent to this 7403 address during the flooding procedure. 7405 o OSPF is IP protocol number 89. This number has been registered 7406 with the Network Information Center. IP protocol number 7407 assignments are documented in [Ref11]. 7409 o All OSPF routing protocol packets are sent using the normal 7410 service TOS value of binary 0000 defined in [Ref12]. 7412 o Routing protocol packets are sent with IP precedence set to 7413 Internetwork Control. OSPF protocol packets should be given 7414 precedence over regular IP data traffic, in both sending and 7415 receiving. Setting the IP precedence field in the IP header to 7416 Internetwork Control [Ref5] may help implement this objective. 7418 A.2 The Options field 7420 The OSPF Options field is present in OSPF Hello packets, Database 7421 Description packets and all LSAs. The Options field enables OSPF 7422 routers to support (or not support) optional capabilities, and to 7423 communicate their capability level to other OSPF routers. Through 7424 this mechanism routers of differing capabilities can be mixed within 7425 an OSPF routing domain. 7427 When used in Hello packets, the Options field allows a router to 7428 reject a neighbor because of a capability mismatch. Alternatively, 7429 when capabilities are exchanged in Database Description packets a 7430 router can choose not to forward certain LSAs to a neighbor because 7431 of its reduced functionality. Lastly, listing capabilities in LSAs 7432 allows routers to forward traffic around reduced functionality 7433 routers, by excluding them from parts of the routing table 7434 calculation. 7436 Five bits of the OSPF Options field have been assigned, although 7437 only one (the E-bit) is described completely by this memo. Each bit 7438 is described briefly below. Routers should reset (i.e. clear) 7439 unrecognized bits in the Options field when sending Hello packets or 7440 Database Description packets and when originating LSAs. Conversely, 7441 routers encountering unrecognized Option bits in received Hello 7442 Packets, Database Description packets or LSAs should ignore the 7443 capability and process the packet/LSA normally. 7445 +------------------------------------+ 7446 | * | * | DC | EA | N/P | MC | E | * | 7447 +------------------------------------+ 7449 The Options field 7451 E-bit 7452 This bit describes the way AS-external-LSAs are flooded, as 7453 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. 7455 MC-bit 7456 This bit describes whether IP multicast datagrams are forwarded 7457 according to the specifications in [Ref18]. 7459 N/P-bit 7460 This bit describes the handling of Type-7 LSAs, as specified in 7461 [Ref19]. 7463 EA-bit 7464 This bit describes the router's willingness to receive and 7465 forward External-Attributes-LSAs, as specified in [Ref20]. 7467 DC-bit 7468 This bit describes the router's handling of demand circuits, as 7469 specified in [Ref21]. 7471 A.3 OSPF Packet Formats 7473 There are five distinct OSPF packet types. All OSPF packet types 7474 begin with a standard 24 byte header. This header is described 7475 first. Each packet type is then described in a succeeding section. 7476 In these sections each packet's division into fields is displayed, 7477 and then the field definitions are enumerated. 7479 All OSPF packet types (other than the OSPF Hello packets) deal with 7480 lists of LSAs. For example, Link State Update packets implement the 7481 flooding of LSAs throughout the OSPF routing domain. Because of 7482 this, OSPF protocol packets cannot be parsed unless the format of 7483 LSAs is also understood. The format of LSAs is described in Section 7484 A.4. 7486 The receive processing of OSPF packets is detailed in Section 8.2. 7487 The sending of OSPF packets is explained in Section 8.1. 7489 A.3.1 The OSPF packet header 7491 Every OSPF packet starts with a standard 24 byte header. This 7492 header contains all the information necessary to determine whether 7493 the packet should be accepted for further processing. This 7494 determination is described in Section 8.2 of the specification. 7496 0 1 2 3 7497 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 7498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7499 | Version # | Type | Packet length | 7500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7501 | Router ID | 7502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7503 | Area ID | 7504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7505 | Checksum | AuType | 7506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7507 | Authentication | 7508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7509 | Authentication | 7510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7512 Version # 7513 The OSPF version number. This specification documents version 2 7514 of the protocol. 7516 Type 7517 The OSPF packet types are as follows. See Sections A.3.2 through 7518 A.3.6 for details. 7520 Type Description 7521 ________________________________ 7522 1 Hello 7523 2 Database Description 7524 3 Link State Request 7525 4 Link State Update 7526 5 Link State Acknowledgment 7527 Packet length 7528 The length of the OSPF protocol packet in bytes. This length 7529 includes the standard OSPF header. 7531 Router ID 7532 The Router ID of the packet's source. 7534 Area ID 7535 A 32 bit number identifying the area that this packet belongs 7536 to. All OSPF packets are associated with a single area. Most 7537 travel a single hop only. Packets travelling over a virtual 7538 link are labelled with the backbone Area ID of 0.0.0.0. 7540 Checksum 7541 The standard IP checksum of the entire contents of the packet, 7542 starting with the OSPF packet header but excluding the 64-bit 7543 authentication field. This checksum is calculated as the 16-bit 7544 one's complement of the one's complement sum of all the 16-bit 7545 words in the packet, excepting the authentication field. If the 7546 packet's length is not an integral number of 16-bit words, the 7547 packet is padded with a byte of zero before checksumming. The 7548 checksum is considered to be part of the packet authentication 7549 procedure; for some authentication types the checksum 7550 calculation is omitted. 7552 AuType 7553 Identifies the authentication procedure to be used for the 7554 packet. Authentication is discussed in Appendix D of the 7555 specification. Consult Appendix D for a list of the currently 7556 defined authentication types. 7558 Authentication 7559 A 64-bit field for use by the authentication scheme. See 7560 Appendix D for details. 7562 A.3.2 The Hello packet 7564 Hello packets are OSPF packet type 1. These packets are sent 7565 periodically on all interfaces (including virtual links) in order to 7566 establish and maintain neighbor relationships. In addition, Hello 7567 Packets are multicast on those physical networks having a multicast 7568 or broadcast capability, enabling dynamic discovery of neighboring 7569 routers. 7571 All routers connected to a common network must agree on certain 7572 parameters (Network mask, HelloInterval and RouterDeadInterval). 7573 These parameters are included in Hello packets, so that differences 7574 can inhibit the forming of neighbor relationships. A detailed 7575 explanation of the receive processing for Hello packets is presented 7576 in Section 10.5. The sending of Hello packets is covered in Section 7577 9.5. 7579 0 1 2 3 7580 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 7581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7582 | Version # | 1 | Packet length | 7583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7584 | Router ID | 7585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7586 | Area ID | 7587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7588 | Checksum | AuType | 7589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7590 | Authentication | 7591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7592 | Authentication | 7593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7594 | Network Mask | 7595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7596 | HelloInterval | Options | Rtr Pri | 7597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7598 | RouterDeadInterval | 7599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7600 | Designated Router | 7601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7602 | Backup Designated Router | 7603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7604 | Neighbor | 7605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7606 | ... | 7608 Network mask 7609 The network mask associated with this interface. For example, 7610 if the interface is to a class B network whose third byte is 7611 used for subnetting, the network mask is 0xffffff00. 7613 Options 7614 The optional capabilities supported by the router, as documented 7615 in Section A.2. 7617 HelloInterval 7618 The number of seconds between this router's Hello packets. 7620 Rtr Pri 7621 This router's Router Priority. Used in (Backup) Designated 7622 Router election. If set to 0, the router will be ineligible to 7623 become (Backup) Designated Router. 7625 RouterDeadInterval 7626 The number of seconds before declaring a silent router down. 7628 Designated Router 7629 The identity of the Designated Router for this network, in the 7630 view of the sending router. The Designated Router is identified 7631 here by its IP interface address on the network. Set to 0.0.0.0 7632 if there is no Designated Router. 7634 Backup Designated Router 7635 The identity of the Backup Designated Router for this network, 7636 in the view of the sending router. The Backup Designated Router 7637 is identified here by its IP interface address on the network. 7638 Set to 0.0.0.0 if there is no Backup Designated Router. 7640 Neighbor 7641 The Router IDs of each router from whom valid Hello packets have 7642 been seen recently on the network. Recently means in the last 7643 RouterDeadInterval seconds. 7645 A.3.3 The Database Description packet 7647 Database Description packets are OSPF packet type 2. These packets 7648 are exchanged when an adjacency is being initialized. They describe 7649 the contents of the link-state database. Multiple packets may be 7650 used to describe the database. For this purpose a poll-response 7651 procedure is used. One of the routers is designated to be the 7652 master, the other the slave. The master sends Database Description 7653 packets (polls) which are acknowledged by Database Description 7654 packets sent by the slave (responses). The responses are linked to 7655 the polls via the packets' DD sequence numbers. 7657 0 1 2 3 7658 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 7659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7660 | Version # | 2 | Packet length | 7661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7662 | Router ID | 7663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7664 | Area ID | 7665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7666 | Checksum | AuType | 7667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7668 | Authentication | 7669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7670 | Authentication | 7671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7672 | Interface MTU | Options |0|0|0|0|0|I|M|MS 7673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7674 | DD sequence number | 7675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7676 | | 7677 +- -+ 7678 | | 7679 +- An LSA Header -+ 7680 | | 7681 +- -+ 7682 | | 7683 +- -+ 7684 | | 7685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7686 | ... | 7688 The format of the Database Description packet is very similar to 7689 both the Link State Request and Link State Acknowledgment packets. 7690 The main part of all three is a list of items, each item describing 7691 a piece of the link-state database. The sending of Database 7692 Description Packets is documented in Section 10.8. The reception of 7693 Database Description packets is documented in Section 10.6. 7695 Interface MTU 7696 The size in bytes of the largest IP datagram that can be sent 7697 out the associated interface, without fragmentation. The MTUs 7698 of common Internet link types can be found in Table 7-1 of 7699 [Ref22]. Interface MTU should be set to 0 in Database 7700 Description packets sent over virtual links. 7702 Options 7703 The optional capabilities supported by the router, as documented 7704 in Section A.2. 7706 I-bit 7707 The Init bit. When set to 1, this packet is the first in the 7708 sequence of Database Description Packets. 7710 M-bit 7711 The More bit. When set to 1, it indicates that more Database 7712 Description Packets are to follow. 7714 MS-bit 7715 The Master/Slave bit. When set to 1, it indicates that the 7716 router is the master during the Database Exchange process. 7717 Otherwise, the router is the slave. 7719 DD sequence number 7720 Used to sequence the collection of Database Description Packets. 7721 The initial value (indicated by the Init bit being set) should 7722 be unique. The DD sequence number then increments until the 7723 complete database description has been sent. 7725 The rest of the packet consists of a (possibly partial) list of the 7726 link-state database's pieces. Each LSA in the database is described 7727 by its LSA header. The LSA header is documented in Section A.4.1. 7728 It contains all the information required to uniquely identify both 7729 the LSA and the LSA's current instance. 7731 A.3.4 The Link State Request packet 7733 Link State Request packets are OSPF packet type 3. After exchanging 7734 Database Description packets with a neighboring router, a router may 7735 find that parts of its link-state database are out-of-date. The 7736 Link State Request packet is used to request the pieces of the 7737 neighbor's database that are more up-to-date. Multiple Link State 7738 Request packets may need to be used. 7740 A router that sends a Link State Request packet has in mind the 7741 precise instance of the database pieces it is requesting. Each 7742 instance is defined by its LS sequence number, LS checksum, and LS 7743 age, although these fields are not specified in the Link State 7744 Request Packet itself. The router may receive even more recent 7745 instances in response. 7747 The sending of Link State Request packets is documented in Section 7748 10.9. The reception of Link State Request packets is documented in 7749 Section 10.7. 7751 0 1 2 3 7752 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 7753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7754 | Version # | 3 | Packet length | 7755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7756 | Router ID | 7757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7758 | Area ID | 7759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7760 | Checksum | AuType | 7761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7762 | Authentication | 7763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7764 | Authentication | 7765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7766 | LS type | 7767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7768 | Link State ID | 7769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7770 | Advertising Router | 7771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7772 | ... | 7774 Each LSA requested is specified by its LS type, Link State ID, and 7775 Advertising Router. This uniquely identifies the LSA, but not its 7776 instance. Link State Request packets are understood to be requests 7777 for the most recent instance (whatever that might be). 7779 A.3.5 The Link State Update packet 7781 Link State Update packets are OSPF packet type 4. These packets 7782 implement the flooding of LSAs. Each Link State Update packet 7783 carries a collection of LSAs one hop further from their origin. 7784 Several LSAs may be included in a single packet. 7786 Link State Update packets are multicast on those physical networks 7787 that support multicast/broadcast. In order to make the flooding 7788 procedure reliable, flooded LSAs are acknowledged in Link State 7789 Acknowledgment packets. If retransmission of certain LSAs is 7790 necessary, the retransmitted LSAs are always sent directly to the 7791 neighbor. For more information on the reliable flooding of LSAs, 7792 consult Section 13. 7794 0 1 2 3 7795 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 7796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7797 | Version # | 4 | Packet length | 7798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7799 | Router ID | 7800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7801 | Area ID | 7802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7803 | Checksum | AuType | 7804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7805 | Authentication | 7806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7807 | Authentication | 7808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7809 | # LSAs | 7810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7811 | | 7812 +- +-+ 7813 | LSAs | 7814 +- +-+ 7815 | ... | 7817 # LSAs 7818 The number of LSAs included in this update. 7820 The body of the Link State Update packet consists of a list of LSAs. 7821 Each LSA begins with a common 20 byte header, described in Section 7822 A.4.1. Detailed formats of the different types of LSAs are described 7823 in Section A.4. 7825 A.3.6 The Link State Acknowledgment packet 7827 Link State Acknowledgment Packets are OSPF packet type 5. To make 7828 the flooding of LSAs reliable, flooded LSAs are explicitly 7829 acknowledged. This acknowledgment is accomplished through the 7830 sending and receiving of Link State Acknowledgment packets. 7831 Multiple LSAs can be acknowledged in a single Link State 7832 Acknowledgment packet. 7834 Depending on the state of the sending interface and the sender of 7835 the corresponding Link State Update packet, a Link State 7836 Acknowledgment packet is sent either to the multicast address 7837 AllSPFRouters, to the multicast address AllDRouters, or as a 7838 unicast. The sending of Link State Acknowledgement packets is 7839 documented in Section 13.5. The reception of Link State 7840 Acknowledgement packets is documented in Section 13.7. 7842 The format of this packet is similar to that of the Data Description 7843 packet. The body of both packets is simply a list of LSA headers. 7845 0 1 2 3 7846 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 7847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7848 | Version # | 5 | Packet length | 7849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7850 | Router ID | 7851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7852 | Area ID | 7853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7854 | Checksum | AuType | 7855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7856 | Authentication | 7857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7858 | Authentication | 7859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7860 | | 7861 +- -+ 7862 | | 7863 +- An LSA Header -+ 7864 | | 7865 +- -+ 7866 | | 7867 +- -+ 7868 | | 7869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7870 | ... | 7872 Each acknowledged LSA is described by its LSA header. The LSA 7873 header is documented in Section A.4.1. It contains all the 7874 information required to uniquely identify both the LSA and the LSA's 7875 current instance. 7877 A.4 LSA formats 7879 This memo defines five distinct types of LSAs. Each LSA begins with 7880 a standard 20 byte LSA header. This header is explained in Section 7881 A.4.1. Succeeding sections then diagram the separate LSA types. 7883 Each LSA describes a piece of the OSPF routing domain. Every router 7884 originates a router-LSA. In addition, whenever the router is 7885 elected Designated Router, it originates a network-LSA. Other types 7886 of LSAs may also be originated (see Section 12.4). All LSAs are 7887 then flooded throughout the OSPF routing domain. The flooding 7888 algorithm is reliable, ensuring that all routers have the same 7889 collection of LSAs. (See Section 13 for more information concerning 7890 the flooding algorithm). This collection of LSAs is called the 7891 link-state database. 7893 From the link state database, each router constructs a shortest path 7894 tree with itself as root. This yields a routing table (see Section 7895 11). For the details of the routing table build process, see 7896 Section 16. 7898 A.4.1 The LSA header 7900 All LSAs begin with a common 20 byte header. This header contains 7901 enough information to uniquely identify the LSA (LS type, Link State 7902 ID, and Advertising Router). Multiple instances of the LSA may 7903 exist in the routing domain at the same time. It is then necessary 7904 to determine which instance is more recent. This is accomplished by 7905 examining the LS age, LS sequence number and LS checksum fields that 7906 are also contained in the LSA header. 7908 0 1 2 3 7909 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 7910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7911 | LS age | Options | LS type | 7912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7913 | Link State ID | 7914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7915 | Advertising Router | 7916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7917 | LS sequence number | 7918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7919 | LS checksum | length | 7920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7922 LS age 7923 The time in seconds since the LSA was originated. 7925 Options 7926 The optional capabilities supported by the described portion of 7927 the routing domain. OSPF's optional capabilities are documented 7928 in Section A.2. 7930 LS type 7931 The type of the LSA. Each LSA type has a separate advertisement 7932 format. The LSA types defined in this memo are as follows (see 7933 Section 12.1.3 for further explanation): 7935 LS Type Description 7936 ___________________________________ 7937 1 Router-LSAs 7938 2 Network-LSAs 7939 3 Summary-LSAs (IP network) 7940 4 Summary-LSAs (ASBR) 7941 5 AS-external-LSAs 7943 Link State ID 7944 This field identifies the portion of the internet environment 7945 that is being described by the LSA. The contents of this field 7946 depend on the LSA's LS type. For example, in network-LSAs the 7947 Link State ID is set to the IP interface address of the 7948 network's Designated Router (from which the network's IP address 7949 can be derived). The Link State ID is further discussed in 7950 Section 12.1.4. 7952 Advertising Router 7953 The Router ID of the router that originated the LSA. For 7954 example, in network-LSAs this field is equal to the Router ID of 7955 the network's Designated Router. 7957 LS sequence number 7958 Detects old or duplicate LSAs. Successive instances of an LSA 7959 are given successive LS sequence numbers. See Section 12.1.6 7960 for more details. 7962 LS checksum 7963 The Fletcher checksum of the complete contents of the LSA, 7964 including the LSA header but excluding the LS age field. See 7965 Section 12.1.7 for more details. 7967 length 7968 The length in bytes of the LSA. This includes the 20 byte LSA 7969 header. 7971 A.4.2 Router-LSAs 7973 Router-LSAs are the Type 1 LSAs. Each router in an area originates 7974 a router-LSA. The LSA describes the state and cost of the router's 7975 links (i.e., interfaces) to the area. All of the router's links to 7976 the area must be described in a single router-LSA. For details 7977 concerning the construction of router-LSAs, see Section 12.4.1. 7979 0 1 2 3 7980 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 7981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7982 | LS age | Options | 1 | 7983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7984 | Link State ID | 7985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7986 | Advertising Router | 7987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7988 | LS sequence number | 7989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7990 | LS checksum | length | 7991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7992 | 0 |V|E|B| 0 | # links | 7993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7994 | Link ID | 7995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7996 | Link Data | 7997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7998 | Type | # TOS | metric | 7999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8000 | ... | 8001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8002 | TOS | 0 | TOS metric | 8003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8004 | Link ID | 8005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8006 | Link Data | 8007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8008 | ... | 8010 In router-LSAs, the Link State ID field is set to the router's OSPF 8011 Router ID. Router-LSAs are flooded throughout a single area only. 8013 bit V 8014 When set, the router is an endpoint of one or more fully 8015 adjacent virtual links having the described area as Transit area 8016 (V is for virtual link endpoint). 8018 bit E 8019 When set, the router is an AS boundary router (E is for 8020 external). 8022 bit B 8023 When set, the router is an area border router (B is for border). 8025 # links 8026 The number of router links described in this LSA. This must be 8027 the total collection of router links (i.e., interfaces) to the 8028 area. 8030 The following fields are used to describe each router link (i.e., 8031 interface). Each router link is typed (see the below Type field). 8032 The Type field indicates the kind of link being described. It may 8033 be a link to a transit network, to another router or to a stub 8034 network. The values of all the other fields describing a router 8035 link depend on the link's Type. For example, each link has an 8036 associated 32-bit Link Data field. For links to stub networks this 8037 field specifies the network's IP address mask. For other link types 8038 the Link Data field specifies the router interface's IP address. 8040 Type 8041 A quick description of the router link. One of the following. 8042 Note that host routes are classified as links to stub networks 8043 with network mask of 0xffffffff. 8045 Type Description 8046 __________________________________________________ 8047 1 Point-to-point connection to another router 8048 2 Connection to a transit network 8049 3 Connection to a stub network 8050 4 Virtual link 8052 Link ID 8053 Identifies the object that this router link connects to. Value 8054 depends on the link's Type. When connecting to an object that 8055 also originates an LSA (i.e., another router or a transit 8056 network) the Link ID is equal to the neighboring LSA's Link 8057 State ID. This provides the key for looking up the neighboring 8058 LSA in the link state database during the routing table 8059 calculation. See Section 12.2 for more details. 8061 Type Link ID 8062 ______________________________________ 8063 1 Neighboring router's Router ID 8064 2 IP address of Designated Router 8065 3 IP network/subnet number 8066 4 Neighboring router's Router ID 8068 Link Data 8069 Value again depends on the link's Type field. For connections to 8070 stub networks, Link Data specifies the network's IP address 8071 mask. For unnumbered point-to-point connections, it specifies 8072 the interface's MIB-II [Ref8] ifIndex value. For the other link 8073 types it specifies the router interface's IP address. This 8074 latter piece of information is needed during the routing table 8075 build process, when calculating the IP address of the next hop. 8076 See Section 16.1.1 for more details. 8078 # TOS 8079 The number of different TOS metrics given for this link, not 8080 counting the required link metric (referred to as the TOS 0 8081 metric in [Ref9]). For example, if no additional TOS metrics 8082 are given, this field is set to 0. 8084 metric 8085 The cost of using this router link. 8087 Additional TOS-specific information may also be included, for 8088 backward compatibility with previous versions of the OSPF 8089 specification ([Ref9]). Within each link, and for each desired TOS, 8090 TOS TOS-specific link information may be encoded as follows: 8092 TOS IP Type of Service that this metric refers to. The encoding of 8093 TOS in OSPF LSAs is described in Section 12.3. 8095 TOS metric 8096 TOS-specific metric information. 8098 A.4.3 Network-LSAs 8100 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 8101 each broadcast and NBMA network in the area which supports two or 8102 more routers. The network-LSA is originated by the network's 8103 Designated Router. The LSA describes all routers attached to the 8104 network, including the Designated Router itself. The LSA's Link 8105 State ID field lists the IP interface address of the Designated 8106 Router. 8108 The distance from the network to all attached routers is zero. This 8109 is why metric fields need not be specified in the network-LSA. For 8110 details concerning the construction of network-LSAs, see Section 8111 12.4.2. 8113 0 1 2 3 8114 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 8115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8116 | LS age | Options | 2 | 8117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8118 | Link State ID | 8119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8120 | Advertising Router | 8121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8122 | LS sequence number | 8123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8124 | LS checksum | length | 8125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8126 | Network Mask | 8127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8128 | Attached Router | 8129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8130 | ... | 8132 Network Mask 8133 The IP address mask for the network. For example, a class A 8134 network would have the mask 0xff000000. 8136 Attached Router 8137 The Router IDs of each of the routers attached to the network. 8138 Actually, only those routers that are fully adjacent to the 8139 Designated Router are listed. The Designated Router includes 8140 itself in this list. The number of routers included can be 8141 deduced from the LSA header's length field. 8143 A.4.4 Summary-LSAs 8145 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated 8146 by area border routers. Summary-LSAs describe inter-area 8147 destinations. For details concerning the construction of summary- 8148 LSAs, see Section 12.4.3. 8150 Type 3 summary-LSAs are used when the destination is an IP network. 8151 In this case the LSA's Link State ID field is an IP network number 8152 (if necessary, the Link State ID can also have one or more of the 8153 network's "host" bits set; see Appendix E for details). When the 8154 destination is an AS boundary router, a Type 4 summary-LSA is used, 8155 and the Link State ID field is the AS boundary router's OSPF Router 8156 ID. (To see why it is necessary to advertise the location of each 8157 ASBR, consult Section 16.4.) Other than the difference in the Link 8158 State ID field, the format of Type 3 and 4 summary-LSAs is 8159 identical. 8161 0 1 2 3 8162 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 8163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8164 | LS age | Options | 3 or 4 | 8165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8166 | Link State ID | 8167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8168 | Advertising Router | 8169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8170 | LS sequence number | 8171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8172 | LS checksum | length | 8173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8174 | Network Mask | 8175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8176 | 0 | metric | 8177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8178 | TOS | TOS metric | 8179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8180 | ... | 8182 For stub areas, Type 3 summary-LSAs can also be used to describe a 8183 (per-area) default route. Default summary routes are used in stub 8184 areas instead of flooding a complete set of external routes. When 8185 describing a default summary route, the summary-LSA's Link State ID 8186 is always set to DefaultDestination (0.0.0.0) and the Network Mask 8187 is set to 0.0.0.0. 8189 Network Mask 8190 For Type 3 summary-LSAs, this indicates the destination 8191 network's IP address mask. For example, when advertising the 8192 location of a class A network the value 0xff000000 would be 8193 used. This field is not meaningful and must be zero for Type 4 8194 summary-LSAs. 8196 metric 8197 The cost of this route. Expressed in the same units as the 8198 interface costs in the router-LSAs. 8200 Additional TOS-specific information may also be included, for 8201 backward compatibility with previous versions of the OSPF 8202 specification ([Ref9]). For each desired TOS, TOS-specific 8203 information is encoded as follows: 8205 TOS IP Type of Service that this metric refers to. The encoding of 8206 TOS in OSPF LSAs is described in Section 12.3. 8208 TOS metric 8209 TOS-specific metric information. 8211 A.4.5 AS-external-LSAs 8213 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 8214 AS boundary routers, and describe destinations external to the AS. 8215 For details concerning the construction of AS-external-LSAs, see 8216 Section 12.4.3. 8218 AS-external-LSAs usually describe a particular external destination. 8219 For these LSAs the Link State ID field specifies an IP network 8220 number (if necessary, the Link State ID can also have one or more of 8221 the network's "host" bits set; see Appendix E for details). AS- 8222 external-LSAs are also used to describe a default route. Default 8223 routes are used when no specific route exists to the destination. 8224 When describing a default route, the Link State ID is always set to 8225 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8227 0 1 2 3 8228 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 8229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8230 | LS age | Options | 5 | 8231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8232 | Link State ID | 8233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8234 | Advertising Router | 8235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8236 | LS sequence number | 8237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8238 | LS checksum | length | 8239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8240 | Network Mask | 8241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8242 |E| 0 | metric | 8243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8244 | Forwarding address | 8245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8246 | External Route Tag | 8247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8248 |E| TOS | TOS metric | 8249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8250 | Forwarding address | 8251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8252 | External Route Tag | 8253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8254 | ... | 8256 Network Mask 8257 The IP address mask for the advertised destination. For 8258 example, when advertising a class A network the mask 0xff000000 8259 would be used. 8261 bit E 8262 The type of external metric. If bit E is set, the metric 8263 specified is a Type 2 external metric. This means the metric is 8264 considered larger than any link state path. If bit E is zero, 8265 the specified metric is a Type 1 external metric. This means 8266 that it is expressed in the same units as the link state metric 8267 (i.e., the same units as interface cost). 8269 metric 8270 The cost of this route. Interpretation depends on the external 8271 type indication (bit E above). 8273 Forwarding address 8274 Data traffic for the advertised destination will be forwarded to 8275 this address. If the Forwarding address is set to 0.0.0.0, data 8276 traffic will be forwarded instead to the LSA's originator (i.e., 8277 the responsible AS boundary router). 8279 External Route Tag 8280 A 32-bit field attached to each external route. This is not 8281 used by the OSPF protocol itself. It may be used to communicate 8282 information between AS boundary routers; the precise nature of 8283 such information is outside the scope of this specification. 8285 Additional TOS-specific information may also be included, for 8286 backward compatibility with previous versions of the OSPF 8287 specification ([Ref9]). For each desired TOS, TOS-specific 8288 information is encoded as follows: 8290 TOS The Type of Service that the following fields concern. The 8291 encoding of TOS in OSPF LSAs is described in Section 12.3. 8293 bit E 8294 For backward-compatibility with [Ref9]. 8296 TOS metric 8297 TOS-specific metric information. 8299 Forwarding address 8300 For backward-compatibility with [Ref9]. 8302 External Route Tag 8303 For backward-compatibility with [Ref9]. 8305 B. Architectural Constants 8307 Several OSPF protocol parameters have fixed architectural values. 8308 These parameters have been referred to in the text by names such as 8309 LSRefreshTime. The same naming convention is used for the 8310 configurable protocol parameters. They are defined in Appendix C. 8312 The name of each architectural constant follows, together with its 8313 value and a short description of its function. 8315 LSRefreshTime 8316 The maximum time between distinct originations of any particular 8317 LSA. If the LS age field of one of the router's self-originated 8318 LSAs reaches the value LSRefreshTime, a new instance of the LSA 8319 is originated, even though the contents of the LSA (apart from 8320 the LSA header) will be the same. The value of LSRefreshTime is 8321 set to 30 minutes. 8323 MinLSInterval 8324 The minimum time between distinct originations of any particular 8325 LSA. The value of MinLSInterval is set to 5 seconds. 8327 MinLSArrival 8328 For any particular LSA, the minimum time that must elapse 8329 between reception of new LSA instances during flooding. LSA 8330 instances received at higher frequencies are discarded. The 8331 value of MinLSArrival is set to 1 second. 8333 MaxAge 8334 The maximum age that an LSA can attain. When an LSA's LS age 8335 field reaches MaxAge, it is reflooded in an attempt to flush the 8336 LSA from the routing domain (See Section 14). LSAs of age MaxAge 8337 are not used in the routing table calculation. The value of 8338 MaxAge is set to 1 hour. 8340 CheckAge 8341 When the age of an LSA in the link state database hits a 8342 multiple of CheckAge, the LSA's checksum is verified. An 8343 incorrect checksum at this time indicates a serious error. The 8344 value of CheckAge is set to 5 minutes. 8346 MaxAgeDiff 8347 The maximum time dispersion that can occur, as an LSA is flooded 8348 throughout the AS. Most of this time is accounted for by the 8349 LSAs sitting on router output queues (and therefore not aging) 8350 during the flooding process. The value of MaxAgeDiff is set to 8351 15 minutes. 8353 LSInfinity 8354 The metric value indicating that the destination described by an 8355 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as 8356 an alternative to premature aging (see Section 14.1). It is 8357 defined to be the 24-bit binary value of all ones: 0xffffff. 8359 DefaultDestination 8360 The Destination ID that indicates the default route. This route 8361 is used when no other matching routing table entry can be found. 8362 The default destination can only be advertised in AS-external- 8363 LSAs and in stub areas' type 3 summary-LSAs. Its value is the 8364 IP address 0.0.0.0. Its associated Network Mask is also always 8365 0.0.0.0. 8367 InitialSequenceNumber 8368 The value used for LS Sequence Number when originating the first 8369 instance of any LSA. Its value is the signed 32-bit integer 8370 0x80000001. 8372 MaxSequenceNumber 8373 The maximum value that LS Sequence Number can attain. Its value 8374 is the signed 32-bit integer 0x7fffffff. 8376 C. Configurable Constants 8378 The OSPF protocol has quite a few configurable parameters. These 8379 parameters are listed below. They are grouped into general 8380 functional categories (area parameters, interface parameters, etc.). 8381 Sample values are given for some of the parameters. 8383 Some parameter settings need to be consistent among groups of 8384 routers. For example, all routers in an area must agree on that 8385 area's parameters, and all routers attached to a network must agree 8386 on that network's IP network number and mask. 8388 Some parameters may be determined by router algorithms outside of 8389 this specification (e.g., the address of a host connected to the 8390 router via a SLIP line). From OSPF's point of view, these items are 8391 still configurable. 8393 C.1 Global parameters 8395 In general, a separate copy of the OSPF protocol is run for each 8396 area. Because of this, most configuration parameters are 8397 defined on a per-area basis. The few global configuration 8398 parameters are listed below. 8400 Router ID 8401 This is a 32-bit number that uniquely identifies the router 8402 in the Autonomous System. One algorithm for Router ID 8403 assignment is to choose the largest or smallest IP address 8404 assigned to the router. If a router's OSPF Router ID is 8405 changed, the router's OSPF software should be restarted 8406 before the new Router ID takes effect. Before restarting in 8407 order to change its Router ID, the router should flush its 8408 self-originated LSAs from the routing domain (see Section 8409 14.1), or they will persist for up to MaxAge minutes. 8411 RFC1583Compatibility 8412 Controls the preference rules used in Section 16.4 when 8413 choosing among multiple AS-external-LSAs advertising the 8414 same destination. When set to "enabled", the preference 8415 rules remain those specified by RFC 1583 ([Ref9]). When set 8416 to "disabled", the preference rules are those stated in 8417 Section 16.4.1, which prevent routing loops when AS- 8418 external-LSAs for the same destination have been originated 8419 from different areas (see Section G.7). Set to "enabled" by 8420 default. 8422 In order to minimize the chance of routing loops, all OSPF 8423 routers in an OSPF routing domain should have 8424 RFC1583Compatibility set identically. When there are routers 8425 present that have not been updated with the functionality 8426 specified in Section 16.4.1 of this memo, all routers should 8427 have RFC1583Compatibility set to "enabled". Otherwise, all 8428 routers should have RFC1583Compatibility set to "disabled", 8429 preventing all routing loops. 8431 C.2 Area parameters 8433 All routers belonging to an area must agree on that area's 8434 configuration. Disagreements between two routers will lead to 8435 an inability for adjacencies to form between them, with a 8436 resulting hindrance to the flow of routing protocol and data 8437 traffic. The following items must be configured for an area: 8439 Area ID 8440 This is a 32-bit number that identifies the area. The Area 8441 ID of 0.0.0.0 is reserved for the backbone. If the area 8442 represents a subnetted network, the IP network number of the 8443 subnetted network may be used for the Area ID. 8445 List of address ranges 8446 An OSPF area is defined as a list of address ranges. Each 8447 address range consists of the following items: 8449 [IP address, mask] 8450 Describes the collection of IP addresses contained 8451 in the address range. Networks and hosts are 8452 assigned to an area depending on whether their 8453 addresses fall into one of the area's defining 8454 address ranges. Routers are viewed as belonging to 8455 multiple areas, depending on their attached 8456 networks' area membership. 8458 Status Set to either Advertise or DoNotAdvertise. Routing 8459 information is condensed at area boundaries. 8460 External to the area, at most a single route is 8461 advertised (via a summary-LSA) for each address 8462 range. The route is advertised if and only if the 8463 address range's Status is set to Advertise. 8464 Unadvertised ranges allow the existence of certain 8465 networks to be intentionally hidden from other 8466 areas. Status is set to Advertise by default. 8468 As an example, suppose an IP subnetted network is to be its 8469 own OSPF area. The area would be configured as a single 8470 address range, whose IP address is the address of the 8471 subnetted network, and whose mask is the natural class A, B, 8472 or C address mask. A single route would be advertised 8473 external to the area, describing the entire subnetted 8474 network. 8476 ExternalRoutingCapability 8477 Whether AS-external-LSAs will be flooded into/throughout the 8478 area. If AS-external-LSAs are excluded from the area, the 8479 area is called a "stub". Internal to stub areas, routing to 8480 external destinations will be based solely on a default 8481 summary route. The backbone cannot be configured as a stub 8482 area. Also, virtual links cannot be configured through stub 8483 areas. For more information, see Section 3.6. 8485 StubDefaultCost 8486 If the area has been configured as a stub area, and the 8487 router itself is an area border router, then the 8488 StubDefaultCost indicates the cost of the default summary- 8489 LSA that the router should advertise into the area. 8491 C.3 Router interface parameters 8493 Some of the configurable router interface parameters (such as IP 8494 interface address and subnet mask) actually imply properties of 8495 the attached networks, and therefore must be consistent across 8496 all the routers attached to that network. The parameters that 8497 must be configured for a router interface are: 8499 IP interface address 8500 The IP protocol address for this interface. This uniquely 8501 identifies the router over the entire internet. An IP 8502 address is not required on point-to-point networks. Such a 8503 point-to-point network is called "unnumbered". 8505 IP interface mask 8506 Also referred to as the subnet/network mask, this indicates 8507 the portion of the IP interface address that identifies the 8508 attached network. Masking the IP interface address with the 8509 IP interface mask yields the IP network number of the 8510 attached network. On point-to-point networks and virtual 8511 links, the IP interface mask is not defined. On these 8512 networks, the link itself is not assigned an IP network 8513 number, and so the addresses of each side of the link are 8514 assigned independently, if they are assigned at all. 8516 Area ID 8517 The OSPF area to which the attached network belongs. 8519 Interface output cost 8520 The cost of sending a packet on the interface, expressed in 8521 the link state metric. This is advertised as the link cost 8522 for this interface in the router's router-LSA. The interface 8523 output cost must always be greater than 0. 8525 RxmtInterval 8526 The number of seconds between LSA retransmissions, for 8527 adjacencies belonging to this interface. Also used when 8528 retransmitting Database Description and Link State Request 8529 Packets. This should be well over the expected round-trip 8530 delay between any two routers on the attached network. The 8531 setting of this value should be conservative or needless 8532 retransmissions will result. Sample value for a local area 8533 network: 5 seconds. 8535 InfTransDelay 8536 The estimated number of seconds it takes to transmit a Link 8537 State Update Packet over this interface. LSAs contained in 8538 the update packet must have their age incremented by this 8539 amount before transmission. This value should take into 8540 account the transmission and propagation delays of the 8541 interface. It must be greater than 0. Sample value for a 8542 local area network: 1 second. 8544 Router Priority 8545 An 8-bit unsigned integer. When two routers attached to a 8546 network both attempt to become Designated Router, the one 8547 with the highest Router Priority takes precedence. If there 8548 is still a tie, the router with the highest Router ID takes 8549 precedence. A router whose Router Priority is set to 0 is 8550 ineligible to become Designated Router on the attached 8551 network. Router Priority is only configured for interfaces 8552 to broadcast and NBMA networks. 8554 HelloInterval 8555 The length of time, in seconds, between the Hello Packets 8556 that the router sends on the interface. This value is 8557 advertised in the router's Hello Packets. It must be the 8558 same for all routers attached to a common network. The 8559 smaller the HelloInterval, the faster topological changes 8560 will be detected; however, more OSPF routing protocol 8561 traffic will ensue. Sample value for a X.25 PDN network: 30 8562 seconds. Sample value for a local area network: 10 seconds. 8564 RouterDeadInterval 8565 After ceasing to hear a router's Hello Packets, the number 8566 of seconds before its neighbors declare the router down. 8567 This is also advertised in the router's Hello Packets in 8568 their RouterDeadInterval field. This should be some 8569 multiple of the HelloInterval (say 4). This value again 8570 must be the same for all routers attached to a common 8571 network. 8573 AuType 8574 Identifies the authentication procedure to be used on the 8575 attached network. This value must be the same for all 8576 routers attached to the network. See Appendix D for a 8577 discussion of the defined authentication types. 8579 Authentication key 8580 This configured data allows the authentication procedure to 8581 verify OSPF protocol packets received over the interface. 8582 For example, if the AuType indicates simple password, the 8583 Authentication key would be a clear 64-bit password. 8584 Authentication keys associated with the other OSPF 8585 authentication types are discussed in Appendix D. 8587 C.4 Virtual link parameters 8589 Virtual links are used to restore/increase connectivity of the 8590 backbone. Virtual links may be configured between any pair of 8591 area border routers having interfaces to a common (non-backbone) 8592 area. The virtual link appears as an unnumbered point-to-point 8593 link in the graph for the backbone. The virtual link must be 8594 configured in both of the area border routers. 8596 A virtual link appears in router-LSAs (for the backbone) as if 8597 it were a separate router interface to the backbone. As such, 8598 it has all of the parameters associated with a router interface 8599 (see Section C.3). Although a virtual link acts like an 8600 unnumbered point-to-point link, it does have an associated IP 8601 interface address. This address is used as the IP source in 8602 OSPF protocol packets it sends along the virtual link, and is 8603 set dynamically during the routing table build process. 8604 Interface output cost is also set dynamically on virtual links 8605 to be the cost of the intra-area path between the two routers. 8606 The parameter RxmtInterval must be configured, and should be 8607 well over the expected round-trip delay between the two routers. 8608 This may be hard to estimate for a virtual link; it is better to 8609 err on the side of making it too large. Router Priority is not 8610 used on virtual links. 8612 A virtual link is defined by the following two configurable 8613 parameters: the Router ID of the virtual link's other endpoint, 8614 and the (non-backbone) area through which the virtual link runs 8615 (referred to as the virtual link's Transit area). Virtual links 8616 cannot be configured through stub areas. 8618 C.5 NBMA network parameters 8620 OSPF treats an NBMA network much like it treats a broadcast 8621 network. Since there may be many routers attached to the 8622 network, a Designated Router is selected for the network. This 8623 Designated Router then originates a network-LSA, which lists all 8624 routers attached to the NBMA network. 8626 However, due to the lack of broadcast capabilities, it may be 8627 necessary to use configuration parameters in the Designated 8628 Router selection. These parameters will only need to be 8629 configured in those routers that are themselves eligible to 8630 become Designated Router (i.e., those router's whose Router 8631 Priority for the network is non-zero), and then only if no 8632 automatic procedure for discovering neighbors exists: 8634 List of all other attached routers 8635 The list of all other routers attached to the NBMA network. 8636 Each router is listed by its IP interface address on the 8637 network. Also, for each router listed, that router's 8638 eligibility to become Designated Router must be defined. 8639 When an interface to a NBMA network comes up, the router 8640 sends Hello Packets only to those neighbors eligible to 8641 become Designated Router, until the identity of the 8642 Designated Router is discovered. 8644 PollInterval 8645 If a neighboring router has become inactive (Hello Packets 8646 have not been seen for RouterDeadInterval seconds), it may 8647 still be necessary to send Hello Packets to the dead 8648 neighbor. These Hello Packets will be sent at the reduced 8649 rate PollInterval, which should be much larger than 8650 HelloInterval. Sample value for a PDN X.25 network: 2 8651 minutes. 8653 C.6 Point-to-MultiPoint network parameters 8655 On Point-to-MultiPoint networks, it may be necessary to 8656 configure the set of neighbors that are directly reachable over 8657 the Point-to-MultiPoint network. Each neighbor is identified by 8658 its IP address on the Point-to-MultiPoint network. Designated 8659 Routers are not elected on Point-to-MultiPoint networks, so the 8660 Designated Router eligibility of configured neighbors is 8661 undefined. 8663 Alternatively, neighbors on Point-to-MultiPoint networks may be 8664 dynamically discovered by lower-level protocols such as Inverse 8665 ARP ([Ref14]). 8667 C.7 Host route parameters 8669 Host routes are advertised in router-LSAs as stub networks with 8670 mask 0xffffffff. They indicate either router interfaces to 8671 point-to-point networks, looped router interfaces, or IP hosts 8672 that are directly connected to the router (e.g., via a SLIP 8673 line). For each host directly connected to the router, the 8674 following items must be configured: 8676 Host IP address 8677 The IP address of the host. 8679 Cost of link to host 8680 The cost of sending a packet to the host, in terms of the 8681 link state metric. However, since the host probably has 8682 only a single connection to the internet, the actual 8683 configured cost in many cases is unimportant (i.e., will 8684 have no effect on routing). 8686 Area ID 8687 The OSPF area to which the host belongs. 8689 D. Authentication 8691 All OSPF protocol exchanges are authenticated. The OSPF packet 8692 header (see Section A.3.1) includes an authentication type field, 8693 and 64-bits of data for use by the appropriate authentication scheme 8694 (determined by the type field). 8696 The authentication type is configurable on a per-interface (or 8697 equivalently, on a per-network/subnet) basis. Additional 8698 authentication data is also configurable on a per-interface basis. 8700 Authentication types 0, 1 and 2 are defined by this specification. 8701 All other authentication types are reserved for definition by the 8702 IANA (iana@ISI.EDU). The current list of authentication types is 8703 described below in Table 20. 8705 AuType Description 8706 ___________________________________________ 8707 0 Null authentication 8708 1 Simple password 8709 2 Cryptographic authentication 8710 All others Reserved for assignment by the 8711 IANA (iana@ISI.EDU) 8713 Table 20: OSPF authentication types. 8715 D.1 Null authentication 8717 Use of this authentication type means that routing exchanges 8718 over the network/subnet are not authenticated. The 64-bit 8719 authentication field in the OSPF header can contain anything; it 8720 is not examined on packet reception. When employing Null 8721 authentication, the entire contents of each OSPF packet (other 8722 than the 64-bit authentication field) are checksummed in order 8723 to detect data corruption. 8725 D.2 Simple password authentication 8727 Using this authentication type, a 64-bit field is configured on 8728 a per-network basis. All packets sent on a particular network 8729 must have this configured value in their OSPF header 64-bit 8730 authentication field. This essentially serves as a "clear" 64- 8731 bit password. In addition, the entire contents of each OSPF 8732 packet (other than the 64-bit authentication field) are 8733 checksummed in order to detect data corruption. 8735 Simple password authentication guards against routers 8736 inadvertently joining the routing domain; each router must first 8737 be configured with its attached networks' passwords before it 8738 can participate in routing. However, simple password 8739 authentication is vulnerable to passive attacks currently 8740 widespread in the Internet (see [Ref16]). Anyone with physical 8741 access to the network can learn the password and compromise the 8742 security of the OSPF routing domain. 8744 D.3 Cryptographic authentication 8746 Using this authentication type, a shared secret key is 8747 configured in all routers attached to a common network/subnet. 8748 For each OSPF protocol packet, the key is used to 8749 generate/verify a "message digest" that is appended to the end 8750 of the OSPF packet. The message digest is a one-way function of 8751 the OSPF protocol packet and the secret key. Since the secret 8752 key is never sent over the network in the clear, protection is 8753 provided against passive attacks. 8755 The algorithms used to generate and verify the message digest 8756 are specified implicitly by the secret key. This specification 8757 completely defines the use of OSPF Cryptographic authentication 8758 when the MD5 algorithm is used. 8760 In addition, a non-decreasing sequence number is included in 8761 each OSPF protocol packet to protect against replay attacks. 8762 This provides long term protection; however, it is still 8763 possible to replay an OSPF packet until the sequence number 8764 changes. To implement this feature, each neighbor data structure 8766 0 1 2 3 8767 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 8768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8769 | 0 | Key ID | Auth Data Len | 8770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8771 | Cryptographic sequence number | 8772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8774 Figure 18: Usage of the Authentication field 8775 in the OSPF packet header when Cryptographic 8776 Authentication is employed 8777 contains a new field called the "cryptographic sequence number". 8778 This field is initialized to zero, and is also set to zero 8779 whenever the neighbor's state transitions to "Down". Whenever an 8780 OSPF packet is accepted as authentic, the cryptographic sequence 8781 number is set to the received packet's sequence number. 8783 This specification does not provide a rollover procedure for the 8784 cryptographic sequence number. When the cryptographic sequence 8785 number that the router is sending hits the maximum value, the 8786 router should reset the cryptographic sequence number that it is 8787 sending back to 0. After this is done, the router's neighbors 8788 will reject the router's OSPF packets for a period of 8789 RouterDeadInterval, and then the router will be forced to 8790 reestablish all adjacencies over the interface. However, it is 8791 expected that many implementations will use "seconds since 8792 reboot" (or "seconds since 1960", etc.) as the cryptographic 8793 sequence number. Such a choice will essentially prevent 8794 rollover, since the cryptographic sequence number field is 32 8795 bits in length. 8797 The OSPF Cryptographic authentication option does not provide 8798 confidentiality. 8800 When cryptographic authentication is used, the 64-bit 8801 Authentication field in the standard OSPF packet header is 8802 redefined as shown in Figure 18. The new field definitions are 8803 as follows: 8805 Key ID 8806 This field identifies the algorithm and secret key used to 8807 create the message digest appended to the OSPF packet. Key 8808 Identifiers are unique per-interface (or equivalently, per- 8809 subnet). 8811 Auth Data Len 8812 The length in bytes of the message digest appended to the 8813 OSPF packet. 8815 Cryptographic sequence number 8816 An unsigned 32-bit non-decreasing sequence number. Used to 8817 guard against replay attacks. 8819 The message digest appended to the OSPF packet is not actually 8820 considered part of the OSPF protocol packet: the message digest 8821 is not included in the OSPF header's packet length, although it 8822 is included in the packet's IP header length field. 8824 Each key is identified by the combination of interface and Key 8825 ID. An interface may have multiple keys active at any one time. 8826 This enables smooth transition from one key to another. Each key 8827 has four time constants associated with it. These time constants 8828 can be expressed in terms of a time-of-day clock, or in terms of 8829 a router's local clock (e.g., number of seconds since last 8830 reboot): 8832 KeyStartAccept 8833 The time that the router will start accepting packets that 8834 have been created with the given key. 8836 KeyStartGenerate 8837 The time that the router will start using the key for packet 8838 generation. 8840 KeyStopGenerate 8841 The time that the router will stop using the key for packet 8842 generation. 8844 KeyStopAccept 8845 The time that the router will stop accepting packets that 8846 have been created with the given key. 8848 In order to achieve smooth key transition, KeyStartAccept should 8849 be less than KeyStartGenerate and KeyStopGenerate should be less 8850 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are 8851 left unspecified, the key's lifetime is infinite. When a new key 8852 replaces an old, the KeyStartGenerate time for the new key must 8853 be less than or equal to the KeyStopGenerate time of the old 8854 key. 8856 Key storage should persist across a system restart, warm or 8857 cold, to avoid operational issues. In the event that the last 8858 key associated with an interface expires, it is unacceptable to 8859 revert to an unauthenticated condition, and not advisable to 8860 disrupt routing. Therefore, the router should send a "last 8861 authentication key expiration" notification to the network 8862 manager and treat the key as having an infinite lifetime until 8863 the lifetime is extended, the key is deleted by network 8864 management, or a new key is configured. 8866 D.4 Message generation 8868 After building the contents of an OSPF packet, the 8869 authentication procedure indicated by the sending interface's 8870 Autype value is called before the packet is sent. The 8871 authentication procedure modifies the OSPF packet as follows. 8873 D.4.1 Generating Null authentication 8875 When using Null authentication, the packet is modified as 8876 follows: 8878 (1) The Autype field in the standard OSPF header is set to 8879 0. 8881 (2) The checksum field in the standard OSPF header is set to 8882 the standard IP checksum of the entire contents of the 8883 packet, starting with the OSPF packet header but 8884 excluding the 64-bit authentication field. This 8885 checksum is calculated as the 16-bit one's complement of 8886 the one's complement sum of all the 16-bit words in the 8887 packet, excepting the authentication field. If the 8888 packet's length is not an integral number of 16-bit 8889 words, the packet is padded with a byte of zero before 8890 checksumming. 8892 D.4.2 Generating Simple password authentication 8894 When using Simple password authentication, the packet is 8895 modified as follows: 8897 (1) The Autype field in the standard OSPF header is set to 8898 1. 8900 (2) The checksum field in the standard OSPF header is set to 8901 the standard IP checksum of the entire contents of the 8902 packet, starting with the OSPF packet header but 8903 excluding the 64-bit authentication field. This 8904 checksum is calculated as the 16-bit one's complement of 8905 the one's complement sum of all the 16-bit words in the 8906 packet, excepting the authentication field. If the 8907 packet's length is not an integral number of 16-bit 8908 words, the packet is padded with a byte of zero before 8909 checksumming. 8911 (3) The 64-bit authentication field in the OSPF packet 8912 header is set to the 64-bit password (i.e., 8913 authentication key) that has been configured for the 8914 interface. 8916 D.4.3 Generating Cryptographic authentication 8918 When using Cryptographic authentication, there may be 8919 multiple keys configured for the interface. In this case, 8920 among the keys that are valid for message generation (i.e, 8921 that have KeyStartGenerate <= current time < 8922 KeyStopGenerate) choose the one with the most recent 8923 KeyStartGenerate time. Using this key, modify the packet as 8924 follows: 8926 (1) The Autype field in the standard OSPF header is set to 8927 2. 8929 (2) The checksum field in the standard OSPF header is not 8930 calculated, but is instead set to 0. 8932 (3) The Key ID (see Figure 18) is set to the chosen key's 8933 Key ID. 8935 (4) The Auth Data Len field is set to the length in bytes of 8936 the message digest that will be appended to the OSPF 8937 packet. When using MD5 as the authentication algorithm, 8938 Auth Data Len will be 16. 8940 (5) The 32-bit Cryptographic sequence number (see Figure 18) 8941 is set to a non-decreasing value (i.e., a value at least 8942 as large as the last value sent out the interface). The 8943 precise values to use in the cryptographic sequence 8944 number field are implementation-specific. For example, 8945 it may be based on a simple counter, or be based on the 8946 system's clock. 8948 (6) The message digest is then calculated and appended to 8949 the OSPF packet. The authentication algorithm to be 8950 used in calculating the digest is indicated by the key 8951 itself. Input to the authentication algorithm consists 8952 of the OSPF packet and the secret key. When using MD5 as 8953 the authentication algorithm, the message digest 8954 calculation proceeds as follows: 8956 (a) The 16 byte MD5 key is appended to the OSPF packet. 8958 (b) Trailing pad and length fields are added, as 8959 specified in [Ref17]. 8961 (c) The MD5 authentication algorithm is run over the 8962 concatenation of the OSPF packet, secret key, pad 8963 and length fields, producing a 16 byte message 8964 digest (see [Ref17]). 8966 (d) The MD5 digest is written over the OSPF key (i.e., 8967 appended to the original OSPF packet). The digest is 8968 not counted in the OSPF packet's length field, but 8969 is included in the packet's IP length field. Any 8970 trailing pad or length fields beyond the digest are 8971 not counted or transmitted. 8973 D.5 Message verification 8975 When an OSPF packet has been received on an interface, it must 8976 be authenticated. The authentication procedure is indicated by 8977 the setting of Autype in the standard OSPF packet header, which 8978 matches the setting of Autype for the receiving OSPF interface. 8980 If an OSPF protocol packet is accepted as authentic, processing 8981 of the packet continues as specified in Section 8.2. Packets 8982 which fail authentication are discarded. 8984 D.5.1 Verifying Null authentication 8986 When using Null authentication, the checksum field in the 8987 OSPF header must be verified. It must be set to the 16-bit 8988 one's complement of the one's complement sum of all the 16- 8989 bit words in the packet, excepting the authentication field. 8990 (If the packet's length is not an integral number of 16-bit 8991 words, the packet is padded with a byte of zero before 8992 checksumming.) 8994 D.5.2 Verifying Simple password authentication 8996 When using Simple password authentication, the received OSPF 8997 packet is authenticated as follows: 8999 (1) The checksum field in the OSPF header must be verified. 9000 It must be set to the 16-bit one's complement of the 9001 one's complement sum of all the 16-bit words in the 9002 packet, excepting the authentication field. (If the 9003 packet's length is not an integral number of 16-bit 9004 words, the packet is padded with a byte of zero before 9005 checksumming.) 9007 (2) The 64-bit authentication field in the OSPF packet 9008 header must be equal to the 64-bit password (i.e., 9009 authentication key) that has been configured for the 9010 interface. 9012 D.5.3 Verifying Cryptographic authentication 9014 When using Cryptographic authentication, the received OSPF 9015 packet is authenticated as follows: 9017 (1) Locate the receiving interface's configured key having 9018 Key ID equal to that specified in the received OSPF 9019 packet (see Figure 18). If the key is not found, or if 9020 the key is not valid for reception (i.e., current time < 9021 KeyStartAccept or current time >= KeyStopAccept), the 9022 OSPF packet is discarded. 9024 (2) If the cryptographic sequence number found in the OSPF 9025 header (see Figure 18) is less than the cryptographic 9026 sequence number recorded in the sending neighbor's data 9027 structure, the OSPF packet is discarded. 9029 (3) Verify the appended message digest in the following 9030 steps: 9032 (a) The received digest is set aside. 9034 (b) A new digest is calculated, as specified in Step 6 9035 of Section D.4.3. 9037 (c) The calculated and received digests are compared. If 9038 they do not match, the OSPF packet is discarded. If 9039 they do match, the OSPF protocol packet is accepted 9040 as authentic, and the "cryptographic sequence 9041 number" in the neighbor's data structure is set to 9042 the sequence number found in the packet's OSPF 9043 header. 9045 E. An algorithm for assigning Link State IDs 9047 The Link State ID in AS-external-LSAs and summary-LSAs is usually 9048 set to the described network's IP address. However, if necessary one 9049 or more of the network's host bits may be set in the Link State ID. 9050 This allows the router to originate separate LSAs for networks 9051 having the same address, yet different masks. Such networks can 9052 occur in the presence of supernetting and subnet 0s (see [Ref10]). 9054 This appendix gives one possible algorithm for setting the host bits 9055 in Link State IDs. The choice of such an algorithm is a local 9056 decision. Separate routers are free to use different algorithms, 9057 since the only LSAs affected are the ones that the router itself 9058 originates. The only requirement on the algorithms used is that the 9059 network's IP address should be used as the Link State ID whenever 9060 possible; this maximizes interoperability with OSPF implementations 9061 predating RFC 1583. 9063 The algorithm below is stated for AS-external-LSAs. This is only 9064 for clarity; the exact same algorithm can be used for summary-LSAs. 9065 Suppose that the router wishes to originate an AS-external-LSA for a 9066 network having address NA and mask NM1. The following steps are then 9067 used to determine the LSA's Link State ID: 9069 (1) Determine whether the router is already originating an AS- 9070 external-LSA with Link State ID equal to NA (in such an LSA the 9071 router itself will be listed as the LSA's Advertising Router). 9072 If not, the Link State ID is set equal to NA and the algorithm 9073 terminates. Otherwise, 9075 (2) Obtain the network mask from the body of the already existing 9076 AS-external-LSA. Call this mask NM2. There are then two cases: 9078 o NM1 is longer (i.e., more specific) than NM2. In this case, 9079 set the Link State ID in the new LSA to be the network 9080 [NA,NM1] with all the host bits set (i.e., equal to NA or'ed 9081 together with all the bits that are not set in NM1, which is 9082 network [NA,NM1]'s broadcast address). 9084 o NM2 is longer than NM1. In this case, change the existing 9085 LSA (having Link State ID of NA) to reference the new 9086 network [NA,NM1] by incrementing the sequence number, 9087 changing the mask in the body to NM1 and inserting the cost 9088 of the new network. Then originate a new LSA for the old 9089 network [NA,NM2], with Link State ID equal to NA or'ed 9090 together with the bits that are not set in NM2 (i.e., 9091 network [NA,NM2]'s broadcast address). 9093 The above algorithm assumes that all masks are contiguous; this 9094 ensures that when two networks have the same address, one mask is 9095 more specific than the other. The algorithm also assumes that no 9096 network exists having an address equal to another network's 9097 broadcast address. Given these two assumptions, the above algorithm 9098 always produces unique Link State IDs. The above algorithm can also 9099 be reworded as follows: When originating an AS-external-LSA, try to 9100 use the network number as the Link State ID. If that produces a 9101 conflict, examine the two networks in conflict. One will be a subset 9102 of the other. For the less specific network, use the network number 9103 as the Link State ID and for the more specific use the network's 9104 broadcast address instead (i.e., flip all the "host" bits to 1). If 9105 the most specific network was originated first, this will cause you 9106 to originate two LSAs at once. 9108 As an example of the algorithm, consider its operation when the 9109 following sequence of events occurs in a single router (Router A). 9111 (1) Router A wants to originate an AS-external-LSA for 9112 [10.0.0.0,255.255.255.0]: 9114 (a) A Link State ID of 10.0.0.0 is used. 9116 (2) Router A then wants to originate an AS-external-LSA for 9117 [10.0.0.0,255.255.0.0]: 9119 (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a 9120 new Link State ID of 10.0.0.255. 9122 (b) A Link State ID of 10.0.0.0 is used for 9123 [10.0.0.0,255.255.0.0]. 9125 (3) Router A then wants to originate an AS-external-LSA for 9126 [10.0.0.0,255.0.0.0]: 9128 (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a 9129 new Link State ID of 10.0.255.255. 9131 (b) A Link State ID of 10.0.0.0 is used for 9132 [10.0.0.0,255.0.0.0]. 9134 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID 9135 of 10.0.0.255. 9137 F. Multiple interfaces to the same network/subnet 9139 There are at least two ways to support multiple physical interfaces 9140 to the same IP subnet. Both methods will interoperate with 9141 implementations of RFC 1583 (and of course this memo). The two 9142 methods are sketched briefly below. An assumption has been made that 9143 each interface has been assigned a separate IP address (otherwise, 9144 support for multiple interfaces is more of a link-level or ARP issue 9145 than an OSPF issue). 9147 Method 1: 9148 Run the entire OSPF functionality over both interfaces, sending 9149 and receiving hellos, flooding, supporting separate interface 9150 and neighbor FSMs for each interface, etc. When doing this all 9151 other routers on the subnet will treat the two interfaces as 9152 separate neighbors, since neighbors are identified (on broadcast 9153 and NBMA networks) by their IP address. 9155 Method 1 has the following disadvantages: 9157 (1) You increase the total number of neighbors and adjacencies. 9159 (2) You lose the bidirectionality test on both interfaces, since 9160 bidirectionality is based on Router ID. 9162 (3) You have to consider both interfaces together during the 9163 Designated Router election, since if you declare both to be 9164 DR simultaneously you can confuse the tie-breaker (which is 9165 Router ID). 9167 Method 2: 9168 Run OSPF over only one interface (call it the primary 9169 interface), but include both the primary and secondary 9170 interfaces in your Router-LSA. 9172 Method 2 has the following disadvantages: 9174 (1) You lose the bidirectionality test on the secondary 9175 interface. 9177 (2) When the primary interface fails, you need to promote the 9178 secondary interface to primary status. 9180 G. Differences from RFC 2178 9182 This section documents the differences between this memo and RFC 9183 2178. All differences are backward-compatible. Implementations of 9184 this memo and of RFCs 2178, 1583, and 1247 will interoperate. 9186 G.1 Flooding modifications 9188 Two small changes have been made to the flooding procedure in 9189 Section 13. First, upon receiving a MaxAge LSA that has no 9190 database copy, requests for equal or previous instances of the 9191 LSA should be removed from all neighbors' Link State Request 9192 Lists, instead of just the sending neighbor's Link State Request 9193 List (see Step 4b in Section 13). Failure to do so could cause 9194 the Database Exchanges with the other neighbors to restart, 9195 because of the check in step 6 of Section 13. 9197 The second change is to step 8 in Section 13. Confusion between 9198 routers as to which LSA instance is more recent can cause a 9199 disastrous amount of flooding in a link-state protocol (see 9200 [Ref26]). OSPF guards against this problem in two ways: a) the 9201 LS age field is used like a TTL in flooding, to eventually 9202 remove looping LSAs from the network (see Section 13.3), and b) 9203 routers refuse to accept LSA updates more frequently than once 9204 every MinLSArrival seconds (see Section 13). However, there is 9205 still one case in RFC 2178 where disagreements regarding which 9206 LSA is more recent can cause a lot of flooding traffic: 9207 responding to old LSAs by reflooding the database copy. For 9208 this reason, Step 8 of Section 13 has been amended to only 9209 respond with the database copy when that copy has not been sent 9210 in any Link State Update within the last MinLSArrival seconds. 9212 Security Considerations 9214 All OSPF protocol exchanges are authenticated. OSPF supports 9215 multiple types of authentication; the type of authentication in use 9216 can be configured on a per network segment basis. One of OSPF's 9217 authentication types, namely the Cryptographic authentication 9218 option, is believed to be secure against passive attacks and provide 9219 significant protection against active attacks. When using the 9220 Cryptographic authentication option, each router appends a "message 9221 digest" to its transmitted OSPF packets. Receivers then use the 9222 shared secret key and received digest to verify that each received 9223 OSPF packet is authentic. 9225 The quality of the security provided by the Cryptographic 9226 authentication option depends completely on the strength of the 9227 message digest algorithm (MD5 is currently the only message digest 9228 algorithm specified), the strength of the key being used, and the 9229 correct implementation of the security mechanism in all 9230 communicating OSPF implementations. It also requires that all 9231 parties maintain the secrecy of the shared secret key. 9233 None of the OSPF authentication types provide confidentiality. Nor 9234 do they protect against traffic analysis. Key management is also not 9235 addressed by this memo. 9237 For more information, see Sections 8.1, 8.2, and Appendix D. 9239 Author's Address 9241 John Moy 9242 Ascend Communications, Inc. 9243 1 Robbins Road 9244 Westford, MA 01886 9246 Phone: 978-952-1367 9247 Fax: 978-392-2075 9248 Email: jmoy@casc.com 9250 This document expires in May 1998.