idnits 2.17.1 draft-ietf-ospf-vers2-02.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-27) 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 7226 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 1339 has weird spacing: '... dist from ...' == Line 1634 has weird spacing: '... Packet name ...' == Line 1636 has weird spacing: '...aintain neigh...' == Line 1667 has weird spacing: '... type name...' == Line 2372 has weird spacing: '...virtual link....' == (11 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 (January 1998) is 9599 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 1516 -- Looks like a reference, but probably isn't: '2' on line 2341 -- Looks like a reference, but probably isn't: '3' on line 2372 -- Looks like a reference, but probably isn't: '4' on line 2681 -- Looks like a reference, but probably isn't: '5' on line 2984 -- Looks like a reference, but probably isn't: '6' on line 3038 -- Looks like a reference, but probably isn't: '7' on line 3914 -- Looks like a reference, but probably isn't: '8' on line 3984 -- Looks like a reference, but probably isn't: '9' on line 4253 -- Looks like a reference, but probably isn't: '10' on line 4364 -- Looks like a reference, but probably isn't: '11' on line 4370 -- Looks like a reference, but probably isn't: '12' on line 4584 -- Looks like a reference, but probably isn't: '13' on line 4765 -- Looks like a reference, but probably isn't: '14' on line 4789 -- Looks like a reference, but probably isn't: '15' on line 5124 -- Looks like a reference, but probably isn't: '16' on line 5131 -- Looks like a reference, but probably isn't: '17' on line 5349 -- Looks like a reference, but probably isn't: '18' on line 5353 -- Looks like a reference, but probably isn't: '19' on line 5826 -- Looks like a reference, but probably isn't: '20' on line 5909 -- Looks like a reference, but probably isn't: '21' on line 6170 -- Looks like a reference, but probably isn't: '22' on line 6376 -- Looks like a reference, but probably isn't: '23' on line 6466 -- Looks like a reference, but probably isn't: '24' on line 6895 == Missing Reference: 'NA' is mentioned on line 9074, but not defined == Missing Reference: 'NM1' is mentioned on line 9071, but not defined == Missing Reference: 'NM2' is mentioned on line 9074, but not defined == Unused Reference: 'Ref19' is defined on line 7446, but no explicit reference was found in the text == Unused Reference: 'Ref24' is defined on line 7323, but no explicit reference was found in the text == Unused Reference: 'Ref25' is defined on line 7326, but no explicit reference was found in the text == Unused Reference: 'Ref26' is defined on line 9193, but no explicit reference was found in the text == Unused Reference: 'NA,NM1' is defined on line 9065, 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: July 1998 January 1998 5 File name: draft-ietf-ospf-vers2-02.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 ....................................... 103 114 12.1.1 LS age ............................................... 104 115 12.1.2 Options .............................................. 104 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 ................................... 107 120 12.1.7 LS checksum .......................................... 108 121 12.2 The link state database .............................. 108 122 12.3 Representation of TOS ................................ 109 123 12.4 Originating LSAs ..................................... 110 124 12.4.1 Router-LSAs .......................................... 113 125 12.4.1.1 Describing point-to-point interfaces ................. 116 126 12.4.1.2 Describing broadcast and NBMA interfaces ............. 117 127 12.4.1.3 Describing virtual links ............................. 117 128 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 118 129 12.4.1.5 Examples of router-LSAs .............................. 118 130 12.4.2 Network-LSAs ......................................... 119 131 12.4.2.1 Examples of network-LSAs ............................. 120 132 12.4.3 Summary-LSAs ......................................... 121 133 12.4.3.1 Originating summary-LSAs into stub areas ............. 123 134 12.4.3.2 Examples of summary-LSAs ............................. 124 135 12.4.4 AS-external-LSAs ..................................... 124 136 12.4.4.1 Examples of AS-external-LSAs ......................... 125 137 13 The Flooding Procedure ............................... 127 138 13.1 Determining which LSA is newer ....................... 130 139 13.2 Installing LSAs in the database ...................... 131 140 13.3 Next step in the flooding procedure .................. 132 141 13.4 Receiving self-originated LSAs ....................... 135 142 13.5 Sending Link State Acknowledgment packets ............ 135 143 13.6 Retransmitting LSAs .................................. 138 144 13.7 Receiving link state acknowledgments ................. 138 145 14 Aging The Link State Database ........................ 139 146 14.1 Premature aging of LSAs .............................. 140 147 15 Virtual Links ........................................ 140 148 16 Calculation of the routing table ..................... 142 149 16.1 Calculating the shortest-path tree for an area ....... 143 150 16.1.1 The next hop calculation ............................. 149 151 16.2 Calculating the inter-area routes .................... 150 152 16.3 Examining transit areas' summary-LSAs ................ 151 153 16.4 Calculating AS external routes ....................... 154 154 16.4.1 External path preferences ............................ 156 155 16.5 Incremental updates -- summary-LSAs .................. 156 156 16.6 Incremental updates -- AS-external-LSAs .............. 157 157 16.7 Events generated as a result of routing table changes 158 158 16.8 Equal-cost multipath ................................. 159 159 Footnotes ............................................ 160 160 References ........................................... 163 161 A OSPF data formats .................................... 165 162 A.1 Encapsulation of OSPF packets ........................ 165 163 A.2 The Options field .................................... 167 164 A.3 OSPF Packet Formats .................................. 169 165 A.3.1 The OSPF packet header ............................... 170 166 A.3.2 The Hello packet ..................................... 172 167 A.3.3 The Database Description packet ...................... 174 168 A.3.4 The Link State Request packet ........................ 176 169 A.3.5 The Link State Update packet ......................... 178 170 A.3.6 The Link State Acknowledgment packet ................. 180 171 A.4 LSA formats .......................................... 182 172 A.4.1 The LSA header ....................................... 183 173 A.4.2 Router-LSAs .......................................... 185 174 A.4.3 Network-LSAs ......................................... 188 175 A.4.4 Summary-LSAs ......................................... 189 176 A.4.5 AS-external-LSAs ..................................... 191 177 B Architectural Constants .............................. 193 178 C Configurable Constants ............................... 195 179 C.1 Global parameters .................................... 195 180 C.2 Area parameters ...................................... 196 181 C.3 Router interface parameters .......................... 197 182 C.4 Virtual link parameters .............................. 199 183 C.5 NBMA network parameters .............................. 200 184 C.6 Point-to-MultiPoint network parameters ............... 200 185 C.7 Host route parameters ................................ 201 186 D Authentication ....................................... 202 187 D.1 Null authentication .................................. 202 188 D.2 Simple password authentication ....................... 202 189 D.3 Cryptographic authentication ......................... 203 190 D.4 Message generation ................................... 205 191 D.4.1 Generating Null authentication ....................... 206 192 D.4.2 Generating Simple password authentication ............ 206 193 D.4.3 Generating Cryptographic authentication .............. 206 194 D.5 Message verification ................................. 208 195 D.5.1 Verifying Null authentication ........................ 208 196 D.5.2 Verifying Simple password authentication ............. 208 197 D.5.3 Verifying Cryptographic authentication ............... 208 198 E An algorithm for assigning Link State IDs ............ 210 199 F Multiple interfaces to the same network/subnet ....... 212 200 G Differences from RFC 2178 ............................ 213 201 G.1 Flooding modifications ............................... 213 202 G.2 Changes to external path preferences ................. 213 203 G.3 Incomplete resolution of virtual next hops ........... 214 204 G.4 Routing table lookup ................................. 214 205 Security Considerations .............................. 215 206 Author's Address ..................................... 215 207 1. Introduction 209 This document is a specification of the Open Shortest Path First 210 (OSPF) TCP/IP internet routing protocol. OSPF is classified as an 211 Interior Gateway Protocol (IGP). This means that it distributes 212 routing information between routers belonging to a single Autonomous 213 System. The OSPF protocol is based on link-state or SPF technology. 214 This is a departure from the Bellman-Ford base used by traditional 215 TCP/IP internet routing protocols. 217 The OSPF protocol was developed by the OSPF working group of the 218 Internet Engineering Task Force. It has been designed expressly for 219 the TCP/IP internet environment, including explicit support for CIDR 220 and the tagging of externally-derived routing information. OSPF 221 also provides for the authentication of routing updates, and 222 utilizes IP multicast when sending/receiving the updates. In 223 addition, much work has been done to produce a protocol that 224 responds quickly to topology changes, yet involves small amounts of 225 routing protocol traffic. 227 1.1. Protocol overview 229 OSPF routes IP packets based solely on the destination IP 230 address found in the IP packet header. IP packets are routed 231 "as is" -- they are not encapsulated in any further protocol 232 headers as they transit the Autonomous System. OSPF is a 233 dynamic routing protocol. It quickly detects topological 234 changes in the AS (such as router interface failures) and 235 calculates new loop-free routes after a period of convergence. 236 This period of convergence is short and involves a minimum of 237 routing traffic. 239 In a link-state routing protocol, each router maintains a 240 database describing the Autonomous System's topology. This 241 database is referred to as the link-state database. Each 242 participating router has an identical database. Each individual 243 piece of this database is a particular router's local state 244 (e.g., the router's usable interfaces and reachable neighbors). 245 The router distributes its local state throughout the Autonomous 246 System by flooding. 248 All routers run the exact same algorithm, in parallel. From the 249 link-state database, each router constructs a tree of shortest 250 paths with itself as root. This shortest-path tree gives the 251 route to each destination in the Autonomous System. Externally 252 derived routing information appears on the tree as leaves. 254 When several equal-cost routes to a destination exist, traffic 255 is distributed equally among them. The cost of a route is 256 described by a single dimensionless metric. 258 OSPF allows sets of networks to be grouped together. Such a 259 grouping is called an area. The topology of an area is hidden 260 from the rest of the Autonomous System. This information hiding 261 enables a significant reduction in routing traffic. Also, 262 routing within the area is determined only by the area's own 263 topology, lending the area protection from bad routing data. An 264 area is a generalization of an IP subnetted network. 266 OSPF enables the flexible configuration of IP subnets. Each 267 route distributed by OSPF has a destination and mask. Two 268 different subnets of the same IP network number may have 269 different sizes (i.e., different masks). This is commonly 270 referred to as variable length subnetting. A packet is routed 271 to the best (i.e., longest or most specific) match. Host routes 272 are considered to be subnets whose masks are "all ones" 273 (0xffffffff). 275 All OSPF protocol exchanges are authenticated. This means that 276 only trusted routers can participate in the Autonomous System's 277 routing. A variety of authentication schemes can be used; in 278 fact, separate authentication schemes can be configured for each 279 IP subnet. 281 Externally derived routing data (e.g., routes learned from an 282 Exterior Gateway Protocol such as BGP; see [Ref23]) is 283 advertised throughout the Autonomous System. This externally 284 derived data is kept separate from the OSPF protocol's link 285 state data. Each external route can also be tagged by the 286 advertising router, enabling the passing of additional 287 information between routers on the boundary of the Autonomous 288 System. 290 1.2. Definitions of commonly used terms 292 This section provides definitions for terms that have a specific 293 meaning to the OSPF protocol and that are used throughout the 294 text. The reader unfamiliar with the Internet Protocol Suite is 295 referred to [Ref13] for an introduction to IP. 297 Router 298 A level three Internet Protocol packet switch. Formerly 299 called a gateway in much of the IP literature. 301 Autonomous System 302 A group of routers exchanging routing information via a 303 common routing protocol. Abbreviated as AS. 305 Interior Gateway Protocol 306 The routing protocol spoken by the routers belonging to an 307 Autonomous system. Abbreviated as IGP. Each Autonomous 308 System has a single IGP. Separate Autonomous Systems may be 309 running different IGPs. 311 Router ID 312 A 32-bit number assigned to each router running the OSPF 313 protocol. This number uniquely identifies the router within 314 an Autonomous System. 316 Network 317 In this memo, an IP network/subnet/supernet. It is possible 318 for one physical network to be assigned multiple IP 319 network/subnet numbers. We consider these to be separate 320 networks. Point-to-point physical networks are an exception 321 - they are considered a single network no matter how many 322 (if any at all) IP network/subnet numbers are assigned to 323 them. 325 Network mask 326 A 32-bit number indicating the range of IP addresses 327 residing on a single IP network/subnet/supernet. This 328 specification displays network masks as hexadecimal numbers. 329 For example, the network mask for a class C IP network is 330 displayed as 0xffffff00. Such a mask is often displayed 331 elsewhere in the literature as 255.255.255.0. 333 Point-to-point networks 334 A network that joins a single pair of routers. A 56Kb 335 serial line is an example of a point-to-point network. 337 Broadcast networks 338 Networks supporting many (more than two) attached routers, 339 together with the capability to address a single physical 340 message to all of the attached routers (broadcast). 341 Neighboring routers are discovered dynamically on these nets 342 using OSPF's Hello Protocol. The Hello Protocol itself 343 takes advantage of the broadcast capability. The OSPF 344 protocol makes further use of multicast capabilities, if 345 they exist. Each pair of routers on a broadcast network is 346 assumed to be able to communicate directly. An ethernet is 347 an example of a broadcast network. 349 Non-broadcast networks 350 Networks supporting many (more than two) routers, but having 351 no broadcast capability. Neighboring routers are maintained 352 on these nets using OSPF's Hello Protocol. However, due to 353 the lack of broadcast capability, some configuration 354 information may be necessary to aid in the discovery of 355 neighbors. On non-broadcast networks, OSPF protocol packets 356 that are normally multicast need to be sent to each 357 neighboring router, in turn. An X.25 Public Data Network 358 (PDN) is an example of a non-broadcast network. 360 OSPF runs in one of two modes over non-broadcast networks. 361 The first mode, called non-broadcast multi-access or NBMA, 362 simulates the operation of OSPF on a broadcast network. The 363 second mode, called Point-to-MultiPoint, treats the non- 364 broadcast network as a collection of point-to-point links. 365 Non-broadcast networks are referred to as NBMA networks or 366 Point-to-MultiPoint networks, depending on OSPF's mode of 367 operation over the network. 369 Interface 370 The connection between a router and one of its attached 371 networks. An interface has state information associated 372 with it, which is obtained from the underlying lower level 373 protocols and the routing protocol itself. An interface to 374 a network has associated with it a single IP address and 375 mask (unless the network is an unnumbered point-to-point 376 network). An interface is sometimes also referred to as a 377 link. 379 Neighboring routers 380 Two routers that have interfaces to a common network. 381 Neighbor relationships are maintained by, and usually 382 dynamically discovered by, OSPF's Hello Protocol. 384 Adjacency 385 A relationship formed between selected neighboring routers 386 for the purpose of exchanging routing information. Not 387 every pair of neighboring routers become adjacent. 389 Link state advertisement 390 Unit of data describing the local state of a router or 391 network. For a router, this includes the state of the 392 router's interfaces and adjacencies. Each link state 393 advertisement is flooded throughout the routing domain. The 394 collected link state advertisements of all routers and 395 networks forms the protocol's link state database. 396 Throughout this memo, link state advertisement is 397 abbreviated as LSA. 399 Hello Protocol 400 The part of the OSPF protocol used to establish and maintain 401 neighbor relationships. On broadcast networks the Hello 402 Protocol can also dynamically discover neighboring routers. 404 Flooding 405 The part of the OSPF protocol that distributes and 406 synchronizes the link-state database between OSPF routers. 408 Designated Router 409 Each broadcast and NBMA network that has at least two 410 attached routers has a Designated Router. The Designated 411 Router generates an LSA for the network and has other 412 special responsibilities in the running of the protocol. 413 The Designated Router is elected by the Hello Protocol. 415 The Designated Router concept enables a reduction in the 416 number of adjacencies required on a broadcast or NBMA 417 network. This in turn reduces the amount of routing 418 protocol traffic and the size of the link-state database. 420 Lower-level protocols 421 The underlying network access protocols that provide 422 services to the Internet Protocol and in turn the OSPF 423 protocol. Examples of these are the X.25 packet and frame 424 levels for X.25 PDNs, and the ethernet data link layer for 425 ethernets. 427 1.3. Brief history of link-state routing technology 429 OSPF is a link state routing protocol. Such protocols are also 430 referred to in the literature as SPF-based or distributed- 431 database protocols. This section gives a brief description of 432 the developments in link-state technology that have influenced 433 the OSPF protocol. 435 The first link-state routing protocol was developed for use in 436 the ARPANET packet switching network. This protocol is 437 described in [Ref3]. It has formed the starting point for all 438 other link-state protocols. The homogeneous ARPANET 439 environment, i.e., single-vendor packet switches connected by 440 synchronous serial lines, simplified the design and 441 implementation of the original protocol. 443 Modifications to this protocol were proposed in [Ref4]. These 444 modifications dealt with increasing the fault tolerance of the 445 routing protocol through, among other things, adding a checksum 446 to the LSAs (thereby detecting database corruption). The paper 447 also included means for reducing the routing traffic overhead in 448 a link-state protocol. This was accomplished by introducing 449 mechanisms which enabled the interval between LSA originations 450 to be increased by an order of magnitude. 452 A link-state algorithm has also been proposed for use as an ISO 453 IS-IS routing protocol. This protocol is described in [Ref2]. 454 The protocol includes methods for data and routing traffic 455 reduction when operating over broadcast networks. This is 456 accomplished by election of a Designated Router for each 457 broadcast network, which then originates an LSA for the network. 459 The OSPF Working Group of the IETF has extended this work in 460 developing the OSPF protocol. The Designated Router concept has 461 been greatly enhanced to further reduce the amount of routing 462 traffic required. Multicast capabilities are utilized for 463 additional routing bandwidth reduction. An area routing scheme 464 has been developed enabling information 465 hiding/protection/reduction. Finally, the algorithms have been 466 tailored for efficient operation in TCP/IP internets. 468 1.4. Organization of this document 470 The first three sections of this specification give a general 471 overview of the protocol's capabilities and functions. Sections 472 4-16 explain the protocol's mechanisms in detail. Packet 473 formats, protocol constants and configuration items are 474 specified in the appendices. 476 Labels such as HelloInterval encountered in the text refer to 477 protocol constants. They may or may not be configurable. 478 Architectural constants are summarized in Appendix B. 479 Configurable constants are summarized in Appendix C. 481 The detailed specification of the protocol is presented in terms 482 of data structures. This is done in order to make the 483 explanation more precise. Implementations of the protocol are 484 required to support the functionality described, but need not 485 use the precise data structures that appear in this memo. 487 1.5. Acknowledgments 489 The author would like to thank Ran Atkinson, Fred Baker, Jeffrey 490 Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra 491 Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui 492 Zhang and the rest of the OSPF Working Group for the ideas and 493 support they have given to this project. 495 The OSPF Point-to-MultiPoint interface is based on work done by 496 Fred Baker. 498 The OSPF Cryptographic Authentication option was developed by 499 Fred Baker and Ran Atkinson. 501 2. The Link-state Database: organization and calculations 503 The following subsections describe the organization of OSPF's link- 504 state database, and the routing calculations that are performed on 505 the database in order to produce a router's routing table. 507 2.1. Representation of routers and networks 509 The Autonomous System's link-state database describes a directed 510 graph. The vertices of the graph consist of routers and 511 networks. A graph edge connects two routers when they are 512 attached via a physical point-to-point network. An edge 513 connecting a router to a network indicates that the router has 514 an interface on the network. Networks can be either transit or 515 stub networks. Transit networks are those capable of carrying 516 data traffic that is neither locally originated nor locally 517 destined. A transit network is represented by a graph vertex 518 having both incoming and outgoing edges. A stub network's vertex 519 has only incoming edges. 521 The neighborhood of each network node in the graph depends on 522 the network's type (point-to-point, broadcast, NBMA or Point- 523 to-MultiPoint) and the number of routers having an interface to 524 the network. Three cases are depicted in Figure 1a. Rectangles 525 indicate routers. Circles and oblongs indicate networks. 526 Router names are prefixed with the letters RT and network names 527 with the letter N. Router interface names are prefixed by the 528 letter I. Lines between routers indicate point-to-point 529 networks. The left side of the figure shows networks with their 530 connected routers, with the resulting graphs shown on the right. 532 **FROM** 534 * |RT1|RT2| 535 +---+Ia +---+ * ------------ 536 |RT1|------|RT2| T RT1| | X | 537 +---+ Ib+---+ O RT2| X | | 538 * Ia| | X | 539 * Ib| X | | 541 Physical point-to-point networks 543 **FROM** 544 +---+ * 545 |RT7| * |RT7| N3| 546 +---+ T ------------ 547 | O RT7| | | 548 +----------------------+ * N3| X | | 549 N3 * 551 Stub networks 553 **FROM** 554 +---+ +---+ 555 |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | 556 +---+ +---+ * ------------------------ 557 | N2 | * RT3| | | | | X | 558 +----------------------+ T RT4| | | | | X | 559 | | O RT5| | | | | X | 560 +---+ +---+ * RT6| | | | | X | 561 |RT5| |RT6| * N2| X | X | X | X | | 562 +---+ +---+ 564 Broadcast or NBMA networks 566 Figure 1a: Network map components 568 Networks and routers are represented by vertices. 569 An edge connects Vertex A to Vertex B iff the 570 intersection of Column A and Row B is marked with 571 an X. 573 The top of Figure 1a shows two routers connected by a point-to- 574 point link. In the resulting link-state database graph, the two 575 router vertices are directly connected by a pair of edges, one 576 in each direction. Interfaces to point-to-point networks need 577 not be assigned IP addresses. When interface addresses are 578 assigned, they are modelled as stub links, with each router 579 advertising a stub connection to the other router's interface 580 address. Optionally, an IP subnet can be assigned to the point- 581 to-point network. In this case, both routers advertise a stub 582 link to the IP subnet, instead of advertising each others' IP 583 interface addresses. 585 The middle of Figure 1a shows a network with only one attached 586 router (i.e., a stub network). In this case, the network appears 587 on the end of a stub connection in the link-state database's 588 graph. 590 When multiple routers are attached to a broadcast network, the 591 link-state database graph shows all routers bidirectionally 592 connected to the network vertex. This is pictured at the bottom 593 of Figure 1a. 595 Each network (stub or transit) in the graph has an IP address 596 and associated network mask. The mask indicates the number of 597 nodes on the network. Hosts attached directly to routers 598 (referred to as host routes) appear on the graph as stub 599 networks. The network mask for a host route is always 600 0xffffffff, which indicates the presence of a single node. 602 2.1.1. Representation of non-broadcast networks 604 As mentioned previously, OSPF can run over non-broadcast 605 networks in one of two modes: NBMA or Point-to-MultiPoint. 606 The choice of mode determines the way that the Hello 607 protocol and flooding work over the non-broadcast network, 608 and the way that the network is represented in the link- 609 state database. 611 In NBMA mode, OSPF emulates operation over a broadcast 612 network: a Designated Router is elected for the NBMA 613 network, and the Designated Router originates an LSA for the 614 network. The graph representation for broadcast networks and 615 NBMA networks is identical. This representation is pictured 616 in the middle of Figure 1a. 618 NBMA mode is the most efficient way to run OSPF over non- 619 broadcast networks, both in terms of link-state database 620 size and in terms of the amount of routing protocol traffic. 621 However, it has one significant restriction: it requires all 622 routers attached to the NBMA network to be able to 623 communicate directly. This restriction may be met on some 624 non-broadcast networks, such as an ATM subnet utilizing 625 SVCs. But it is often not met on other non-broadcast 626 networks, such as PVC-only Frame Relay networks. On non- 627 broadcast networks where not all routers can communicate 628 directly you can break the non-broadcast network into 629 logical subnets, with the routers on each subnet being able 630 to communicate directly, and then run each separate subnet 631 as an NBMA network (see [Ref15]). This however requires 632 quite a bit of administrative overhead, and is prone to 633 misconfiguration. It is probably better to run such a non- 634 broadcast network in Point-to-Multipoint mode. 636 In Point-to-MultiPoint mode, OSPF treats all router-to- 637 router connections over the non-broadcast network as if they 638 were point-to-point links. No Designated Router is elected 639 for the network, nor is there an LSA generated for the 640 network. In fact, a vertex for the Point-to-MultiPoint 641 network does not appear in the graph of the link-state 642 database. 644 Figure 1b illustrates the link-state database representation 645 of a Point-to-MultiPoint network. On the left side of the 646 figure, a Point-to-MultiPoint network is pictured. It is 647 assumed that all routers can communicate directly, except 648 for routers RT4 and RT5. I3 though I6 indicate the routers' 649 IP interface addresses on the Point-to-MultiPoint network. 650 In the graphical representation of the link-state database, 651 routers that can communicate directly over the Point-to- 652 MultiPoint network are joined by bidirectional edges, and 653 each router also has a stub connection to its own IP 654 interface address (which is in contrast to the 655 representation of real point-to-point links; see Figure 1a). 657 On some non-broadcast networks, use of Point-to-MultiPoint 658 mode and data-link protocols such as Inverse ARP (see 659 [Ref14]) will allow autodiscovery of OSPF neighbors even 660 though broadcast support is not available. 662 2.1.2. An example link-state database 664 Figure 2 shows a sample map of an Autonomous System. The 665 rectangle labelled H1 indicates a host, which has a SLIP 666 **FROM** 667 +---+ +---+ 668 |RT3| |RT4| |RT3|RT4|RT5|RT6| 669 +---+ +---+ * -------------------- 670 I3| N2 |I4 * RT3| | X | X | X | 671 +----------------------+ T RT4| X | | | X | 672 I5| |I6 O RT5| X | | | X | 673 +---+ +---+ * RT6| X | X | X | | 674 |RT5| |RT6| * I3| X | | | | 675 +---+ +---+ I4| | X | | | 676 I5| | | X | | 677 I6| | | | X | 679 Figure 1b: Network map components 680 Point-to-MultiPoint networks 682 All routers can communicate directly over N2, except 683 routers RT4 and RT5. I3 through I6 indicate IP 684 interface addresses 686 connection to Router RT12. Router RT12 is therefore 687 advertising a host route. Lines between routers indicate 688 physical point-to-point networks. The only point-to-point 689 network that has been assigned interface addresses is the 690 one joining Routers RT6 and RT10. Routers RT5 and RT7 have 691 BGP connections to other Autonomous Systems. A set of BGP- 692 learned routes have been displayed for both of these 693 routers. 695 A cost is associated with the output side of each router 696 interface. This cost is configurable by the system 697 administrator. The lower the cost, the more likely the 698 interface is to be used to forward data traffic. Costs are 699 also associated with the externally derived routing data 700 (e.g., the BGP-learned routes). 702 The directed graph resulting from the map in Figure 2 is 703 depicted in Figure 3. Arcs are labelled with the cost of 704 the corresponding router output interface. Arcs having no 705 labelled cost have a cost of 0. Note that arcs leading from 706 networks to routers always have cost 0; they are significant 707 nonetheless. Note also that the externally derived routing 708 data appears on the graph as stubs. 710 + 711 | 3+---+ N12 N14 712 N1|--|RT1|\ 1 \ N13 / 713 | +---+ \ 8\ |8/8 714 + \ ____ \|/ 715 / \ 1+---+8 8+---+6 716 * N3 *---|RT4|------|RT5|--------+ 717 \____/ +---+ +---+ | 718 + / | |7 | 719 | 3+---+ / | | | 720 N2|--|RT2|/1 |1 |6 | 721 | +---+ +---+8 6+---+ | 722 + |RT3|--------------|RT6| | 723 +---+ +---+ | 724 |2 Ia|7 | 725 | | | 726 +---------+ | | 727 N4 | | 728 | | 729 | | 730 N11 | | 731 +---------+ | | 732 | | | N12 733 |3 | |6 2/ 734 +---+ | +---+/ 735 |RT9| | |RT7|---N15 736 +---+ | +---+ 9 737 |1 + | |1 738 _|__ | Ib|5 __|_ 739 / \ 1+----+2 | 3+----+1 / \ 740 * N9 *------|RT11|----|---|RT10|---* N6 * 741 \____/ +----+ | +----+ \____/ 742 | | | 743 |1 + |1 744 +--+ 10+----+ N8 +---+ 745 |H1|-----|RT12| |RT8| 746 +--+SLIP +----+ +---+ 747 |2 |4 748 | | 749 +---------+ +--------+ 750 N10 N7 752 Figure 2: A sample Autonomous System 753 **FROM** 755 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| 756 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| 757 ----- --------------------------------------------- 758 RT1| | | | | | | | | | | | |0 | | | | 759 RT2| | | | | | | | | | | | |0 | | | | 760 RT3| | | | | |6 | | | | | | |0 | | | | 761 RT4| | | | |8 | | | | | | | |0 | | | | 762 RT5| | | |8 | |6 |6 | | | | | | | | | | 763 RT6| | |8 | |7 | | | | |5 | | | | | | | 764 RT7| | | | |6 | | | | | | | | |0 | | | 765 * RT8| | | | | | | | | | | | | |0 | | | 766 * RT9| | | | | | | | | | | | | | | |0 | 767 T RT10| | | | | |7 | | | | | | | |0 |0 | | 768 O RT11| | | | | | | | | | | | | | |0 |0 | 769 * RT12| | | | | | | | | | | | | | | |0 | 770 * N1|3 | | | | | | | | | | | | | | | | 771 N2| |3 | | | | | | | | | | | | | | | 772 N3|1 |1 |1 |1 | | | | | | | | | | | | | 773 N4| | |2 | | | | | | | | | | | | | | 774 N6| | | | | | |1 |1 | |1 | | | | | | | 775 N7| | | | | | | |4 | | | | | | | | | 776 N8| | | | | | | | | |3 |2 | | | | | | 777 N9| | | | | | | | |1 | |1 |1 | | | | | 778 N10| | | | | | | | | | | |2 | | | | | 779 N11| | | | | | | | |3 | | | | | | | | 780 N12| | | | |8 | |2 | | | | | | | | | | 781 N13| | | | |8 | | | | | | | | | | | | 782 N14| | | | |8 | | | | | | | | | | | | 783 N15| | | | | | |9 | | | | | | | | | | 784 H1| | | | | | | | | | | |10| | | | | 786 Figure 3: The resulting directed graph 788 Networks and routers are represented by vertices. 789 An edge of cost X connects Vertex A to Vertex B iff 790 the intersection of Column A and Row B is marked 791 with an X. 793 The link-state database is pieced together from LSAs 794 generated by the routers. In the associated graphical 795 representation, the neighborhood of each router or transit 796 network is represented in a single, separate LSA. Figure 4 797 shows these LSAs graphically. Router RT12 has an interface 798 to two broadcast networks and a SLIP line to a host. 799 Network N6 is a broadcast network with three attached 800 routers. The cost of all links from Network N6 to its 801 attached routers is 0. Note that the LSA for Network N6 is 802 actually generated by one of the network's attached routers: 803 the router that has been elected Designated Router for the 804 network. 806 2.2. The shortest-path tree 808 When no OSPF areas are configured, each router in the Autonomous 809 System has an identical link-state database, leading to an 810 identical graphical representation. A router generates its 811 routing table from this graph by calculating a tree of shortest 812 paths with the router itself as root. Obviously, the shortest- 813 path tree depends on the router doing the calculation. The 814 shortest-path tree for Router RT6 in our example is depicted in 815 Figure 5. 817 The tree gives the entire path to any destination network or 818 host. However, only the next hop to the destination is used in 819 the forwarding process. Note also that the best route to any 820 router has also been calculated. For the processing of external 821 data, we note the next hop and distance to any router 822 advertising external routes. The resulting routing table for 823 Router RT6 is pictured in Table 2. Note that there is a 824 separate route for each end of a numbered point-to-point network 825 (in this case, the serial line between Routers RT6 and RT10). 827 **FROM** **FROM** 829 |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| 830 * -------------------- * ---------------------- 831 * RT12| | | | | * RT9| | | |0 | 832 T N9|1 | | | | T RT11| | | |0 | 833 O N10|2 | | | | O RT12| | | |0 | 834 * H1|10 | | | | * N9| | | | | 835 * * 836 RT12's router-LSA N9's network-LSA 838 Figure 4: Individual link state components 840 Networks and routers are represented by vertices. 841 An edge of cost X connects Vertex A to Vertex B iff 842 the intersection of Column A and Row B is marked 843 with an X. 845 RT6(origin) 846 RT5 o------------o-----------o Ib 847 /|\ 6 |\ 7 848 8/8|8\ | \ 849 / | \ 6| \ 850 o | o | \7 851 N12 o N14 | \ 852 N13 2 | \ 853 N4 o-----o RT3 \ 854 / \ 5 855 1/ RT10 o-------o Ia 856 / |\ 857 RT4 o-----o N3 3| \1 858 /| | \ N6 RT7 859 / | N8 o o---------o 860 / | | | /| 861 RT2 o o RT1 | | 2/ |9 862 / | | |RT8 / | 863 /3 |3 RT11 o o o o 864 / | | | N12 N15 865 N2 o o N1 1| |4 866 | | 867 N9 o o N7 868 /| 869 / | 870 N11 RT9 / |RT12 871 o--------o-------o o--------o H1 872 3 | 10 873 |2 874 | 875 o N10 877 Figure 5: The SPF tree for Router RT6 879 Edges that are not marked with a cost have a cost of 880 of zero (these are network-to-router links). Routes 881 to networks N12-N15 are external information that is 882 considered in Section 2.3 883 Destination Next Hop Distance 884 __________________________________ 885 N1 RT3 10 886 N2 RT3 10 887 N3 RT3 7 888 N4 RT3 8 889 Ib * 7 890 Ia RT10 12 891 N6 RT10 8 892 N7 RT10 12 893 N8 RT10 10 894 N9 RT10 11 895 N10 RT10 13 896 N11 RT10 14 897 H1 RT10 21 898 __________________________________ 899 RT5 RT5 6 900 RT7 RT10 8 902 Table 2: The portion of Router RT6's routing table listing local 903 destinations. 905 Routes to networks belonging to other AS'es (such as N12) appear 906 as dashed lines on the shortest path tree in Figure 5. Use of 907 this externally derived routing information is considered in the 908 next section. 910 2.3. Use of external routing information 912 After the tree is created the external routing information is 913 examined. This external routing information may originate from 914 another routing protocol such as BGP, or be statically 915 configured (static routes). Default routes can also be included 916 as part of the Autonomous System's external routing information. 918 External routing information is flooded unaltered throughout the 919 AS. In our example, all the routers in the Autonomous System 920 know that Router RT7 has two external routes, with metrics 2 and 921 9. 923 OSPF supports two types of external metrics. Type 1 external 924 metrics are expressed in the same units as OSPF interface cost 925 (i.e., in terms of the link state metric). Type 2 external 926 metrics are an order of magnitude larger; any Type 2 metric is 927 considered greater than the cost of any path internal to the AS. 928 Use of Type 2 external metrics assumes that routing between 929 AS'es is the major cost of routing a packet, and eliminates the 930 need for conversion of external costs to internal link state 931 metrics. 933 As an example of Type 1 external metric processing, suppose that 934 the Routers RT7 and RT5 in Figure 2 are advertising Type 1 935 external metrics. For each advertised external route, the total 936 cost from Router RT6 is calculated as the sum of the external 937 route's advertised cost and the distance from Router RT6 to the 938 advertising router. When two routers are advertising the same 939 external destination, RT6 picks the advertising router providing 940 the minimum total cost. RT6 then sets the next hop to the 941 external destination equal to the next hop that would be used 942 when routing packets to the chosen advertising router. 944 In Figure 2, both Router RT5 and RT7 are advertising an external 945 route to destination Network N12. Router RT7 is preferred since 946 it is advertising N12 at a distance of 10 (8+2) to Router RT6, 947 which is better than Router RT5's 14 (6+8). Table 3 shows the 948 entries that are added to the routing table when external routes 949 are examined: 951 Destination Next Hop Distance 952 __________________________________ 953 N12 RT10 10 954 N13 RT5 14 955 N14 RT5 14 956 N15 RT10 17 958 Table 3: The portion of Router RT6's routing table 959 listing external destinations. 961 Processing of Type 2 external metrics is simpler. The AS 962 boundary router advertising the smallest external metric is 963 chosen, regardless of the internal distance to the AS boundary 964 router. Suppose in our example both Router RT5 and Router RT7 965 were advertising Type 2 external routes. Then all traffic 966 destined for Network N12 would be forwarded to Router RT7, since 967 2 < 8. When several equal-cost Type 2 routes exist, the 968 internal distance to the advertising routers is used to break 969 the tie. 971 Both Type 1 and Type 2 external metrics can be present in the AS 972 at the same time. In that event, Type 1 external metrics always 973 take precedence. 975 This section has assumed that packets destined for external 976 destinations are always routed through the advertising AS 977 boundary router. This is not always desirable. For example, 978 suppose in Figure 2 there is an additional router attached to 979 Network N6, called Router RTX. Suppose further that RTX does 980 not participate in OSPF routing, but does exchange BGP 981 information with the AS boundary router RT7. Then, Router RT7 982 would end up advertising OSPF external routes for all 983 destinations that should be routed to RTX. An extra hop will 984 sometimes be introduced if packets for these destinations need 985 always be routed first to Router RT7 (the advertising router). 987 To deal with this situation, the OSPF protocol allows an AS 988 boundary router to specify a "forwarding address" in its AS- 989 external-LSAs. In the above example, Router RT7 would specify 990 RTX's IP address as the "forwarding address" for all those 991 destinations whose packets should be routed directly to RTX. 993 The "forwarding address" has one other application. It enables 994 routers in the Autonomous System's interior to function as 995 "route servers". For example, in Figure 2 the router RT6 could 996 become a route server, gaining external routing information 997 through a combination of static configuration and external 998 routing protocols. RT6 would then start advertising itself as 999 an AS boundary router, and would originate a collection of OSPF 1000 AS-external-LSAs. In each AS-external-LSA, Router RT6 would 1001 specify the correct Autonomous System exit point to use for the 1002 destination through appropriate setting of the LSA's "forwarding 1003 address" field. 1005 2.4. Equal-cost multipath 1007 The above discussion has been simplified by considering only a 1008 single route to any destination. In reality, if multiple 1009 equal-cost routes to a destination exist, they are all 1010 discovered and used. This requires no conceptual changes to the 1011 algorithm, and its discussion is postponed until we consider the 1012 tree-building process in more detail. 1014 With equal cost multipath, a router potentially has several 1015 available next hops towards any given destination. 1017 3. Splitting the AS into Areas 1019 OSPF allows collections of contiguous networks and hosts to be 1020 grouped together. Such a group, together with the routers having 1021 interfaces to any one of the included networks, is called an area. 1022 Each area runs a separate copy of the basic link-state routing 1023 algorithm. This means that each area has its own link-state 1024 database and corresponding graph, as explained in the previous 1025 section. 1027 The topology of an area is invisible from the outside of the area. 1028 Conversely, routers internal to a given area know nothing of the 1029 detailed topology external to the area. This isolation of knowledge 1030 enables the protocol to effect a marked reduction in routing traffic 1031 as compared to treating the entire Autonomous System as a single 1032 link-state domain. 1034 With the introduction of areas, it is no longer true that all 1035 routers in the AS have an identical link-state database. A router 1036 actually has a separate link-state database for each area it is 1037 connected to. (Routers connected to multiple areas are called area 1038 border routers). Two routers belonging to the same area have, for 1039 that area, identical area link-state databases. 1041 Routing in the Autonomous System takes place on two levels, 1042 depending on whether the source and destination of a packet reside 1043 in the same area (intra-area routing is used) or different areas 1044 (inter-area routing is used). In intra-area routing, the packet is 1045 routed solely on information obtained within the area; no routing 1046 information obtained from outside the area can be used. This 1047 protects intra-area routing from the injection of bad routing 1048 information. We discuss inter-area routing in Section 3.2. 1050 3.1. The backbone of the Autonomous System 1052 The OSPF backbone is the special OSPF Area 0 (often written as 1053 Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP 1054 addresses). The OSPF backbone always contains all area border 1055 routers. The backbone is responsible for distributing routing 1056 information between non-backbone areas. The backbone must be 1057 contiguous. However, it need not be physically contiguous; 1058 backbone connectivity can be established/maintained through the 1059 configuration of virtual links. 1061 Virtual links can be configured between any two backbone routers 1062 that have an interface to a common non-backbone area. Virtual 1063 links belong to the backbone. The protocol treats two routers 1064 joined by a virtual link as if they were connected by an 1065 unnumbered point-to-point backbone network. On the graph of the 1066 backbone, two such routers are joined by arcs whose costs are 1067 the intra-area distances between the two routers. The routing 1068 protocol traffic that flows along the virtual link uses intra- 1069 area routing only. 1071 3.2. Inter-area routing 1073 When routing a packet between two non-backbone areas the 1074 backbone is used. The path that the packet will travel can be 1075 broken up into three contiguous pieces: an intra-area path from 1076 the source to an area border router, a backbone path between the 1077 source and destination areas, and then another intra-area path 1078 to the destination. The algorithm finds the set of such paths 1079 that have the smallest cost. 1081 Looking at this another way, inter-area routing can be pictured 1082 as forcing a star configuration on the Autonomous System, with 1083 the backbone as hub and each of the non-backbone areas as 1084 spokes. 1086 The topology of the backbone dictates the backbone paths used 1087 between areas. The topology of the backbone can be enhanced by 1088 adding virtual links. This gives the system administrator some 1089 control over the routes taken by inter-area traffic. 1091 The correct area border router to use as the packet exits the 1092 source area is chosen in exactly the same way routers 1093 advertising external routes are chosen. Each area border router 1094 in an area summarizes for the area its cost to all networks 1095 external to the area. After the SPF tree is calculated for the 1096 area, routes to all inter-area destinations are calculated by 1097 examining the summaries of the area border routers. 1099 3.3. Classification of routers 1101 Before the introduction of areas, the only OSPF routers having a 1102 specialized function were those advertising external routing 1103 information, such as Router RT5 in Figure 2. When the AS is 1104 split into OSPF areas, the routers are further divided according 1105 to function into the following four overlapping categories: 1107 Internal routers 1108 A router with all directly connected networks belonging to 1109 the same area. These routers run a single copy of the basic 1110 routing algorithm. 1112 Area border routers 1113 A router that attaches to multiple areas. Area border 1114 routers run multiple copies of the basic algorithm, one copy 1115 for each attached area. Area border routers condense the 1116 topological information of their attached areas for 1117 distribution to the backbone. The backbone in turn 1118 distributes the information to the other areas. 1120 Backbone routers 1121 A router that has an interface to the backbone area. This 1122 includes all routers that interface to more than one area 1123 (i.e., area border routers). However, backbone routers do 1124 not have to be area border routers. Routers with all 1125 interfaces connecting to the backbone area are supported. 1127 AS boundary routers 1128 A router that exchanges routing information with routers 1129 belonging to other Autonomous Systems. Such a router 1130 advertises AS external routing information throughout the 1131 Autonomous System. The paths to each AS boundary router are 1132 known by every router in the AS. This classification is 1133 completely independent of the previous classifications: AS 1134 boundary routers may be internal or area border routers, and 1135 may or may not participate in the backbone. 1137 3.4. A sample area configuration 1139 Figure 6 shows a sample area configuration. The first area 1140 consists of networks N1-N4, along with their attached routers 1141 RT1-RT4. The second area consists of networks N6-N8, along with 1142 their attached routers RT7, RT8, RT10 and RT11. The third area 1143 consists of networks N9-N11 and Host H1, along with their 1144 attached routers RT9, RT11 and RT12. The third area has been 1145 configured so that networks N9-N11 and Host H1 will all be 1146 grouped into a single route, when advertised external to the 1147 area (see Section 3.5 for more details). 1149 In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are 1150 internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area 1151 border routers. Finally, as before, Routers RT5 and RT7 are AS 1152 boundary routers. 1154 Figure 7 shows the resulting link-state database for the Area 1. 1155 The figure completely describes that area's intra-area routing. 1157 ........................... 1158 . + . 1159 . | 3+---+ . N12 N14 1160 . N1|--|RT1|\ 1 . \ N13 / 1161 . | +---+ \ . 8\ |8/8 1162 . + \ ____ . \|/ 1163 . / \ 1+---+8 8+---+6 1164 . * N3 *---|RT4|------|RT5|--------+ 1165 . \____/ +---+ +---+ | 1166 . + / \ . |7 | 1167 . | 3+---+ / \ . | | 1168 . N2|--|RT2|/1 1\ . |6 | 1169 . | +---+ +---+8 6+---+ | 1170 . + |RT3|------|RT6| | 1171 . +---+ +---+ | 1172 . 2/ . Ia|7 | 1173 . / . | | 1174 . +---------+ . | | 1175 .Area 1 N4 . | | 1176 ........................... | | 1177 .......................... | | 1178 . N11 . | | 1179 . +---------+ . | | 1180 . | . | | N12 1181 . |3 . Ib|5 |6 2/ 1182 . +---+ . +----+ +---+/ 1183 . |RT9| . .........|RT10|.....|RT7|---N15. 1184 . +---+ . . +----+ +---+ 9 . 1185 . |1 . . + /3 1\ |1 . 1186 . _|__ . . | / \ __|_ . 1187 . / \ 1+----+2 |/ \ / \ . 1188 . * N9 *------|RT11|----| * N6 * . 1189 . \____/ +----+ | \____/ . 1190 . | . . | | . 1191 . |1 . . + |1 . 1192 . +--+ 10+----+ . . N8 +---+ . 1193 . |H1|-----|RT12| . . |RT8| . 1194 . +--+SLIP +----+ . . +---+ . 1195 . |2 . . |4 . 1196 . | . . | . 1197 . +---------+ . . +--------+ . 1198 . N10 . . N7 . 1199 . . .Area 2 . 1200 .Area 3 . ................................ 1201 .......................... 1203 Figure 6: A sample OSPF area configuration 1204 It also shows the complete view of the internet for the two 1205 internal routers RT1 and RT2. It is the job of the area border 1206 routers, RT3 and RT4, to advertise into Area 1 the distances to 1207 all destinations external to the area. These are indicated in 1208 Figure 7 by the dashed stub routes. Also, RT3 and RT4 must 1209 advertise into Area 1 the location of the AS boundary routers 1210 RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are 1211 flooded throughout the entire AS, and in particular throughout 1212 Area 1. These LSAs are included in Area 1's database, and yield 1213 routes to Networks N12-N15. 1215 Routers RT3 and RT4 must also summarize Area 1's topology for 1216 distribution to the backbone. Their backbone LSAs are shown in 1217 Table 4. These summaries show which networks are contained in 1218 Area 1 (i.e., Networks N1-N4), and the distance to these 1219 networks from the routers RT3 and RT4 respectively. 1221 The link-state database for the backbone is shown in Figure 8. 1222 The set of routers pictured are the backbone routers. Router 1223 RT11 is a backbone router because it belongs to two areas. In 1224 order to make the backbone connected, a virtual link has been 1225 configured between Routers R10 and R11. 1227 The area border routers RT3, RT4, RT7, RT10 and RT11 condense 1228 the routing information of their attached non-backbone areas for 1229 distribution via the backbone; these are the dashed stubs that 1230 appear in Figure 8. Remember that the third area has been 1231 configured to condense Networks N9-N11 and Host H1 into a single 1232 route. This yields a single dashed line for networks N9-N11 and 1233 Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary 1234 routers; their externally derived information also appears on 1235 the graph in Figure 8 as stubs. 1237 Network RT3 adv. RT4 adv. 1238 _____________________________ 1239 N1 4 4 1240 N2 4 4 1241 N3 1 1 1242 N4 2 3 1244 Table 4: Networks advertised to the backbone 1245 by Routers RT3 and RT4. 1247 **FROM** 1249 |RT|RT|RT|RT|RT|RT| 1250 |1 |2 |3 |4 |5 |7 |N3| 1251 ----- ------------------- 1252 RT1| | | | | | |0 | 1253 RT2| | | | | | |0 | 1254 RT3| | | | | | |0 | 1255 * RT4| | | | | | |0 | 1256 * RT5| | |14|8 | | | | 1257 T RT7| | |20|14| | | | 1258 O N1|3 | | | | | | | 1259 * N2| |3 | | | | | | 1260 * N3|1 |1 |1 |1 | | | | 1261 N4| | |2 | | | | | 1262 Ia,Ib| | |20|27| | | | 1263 N6| | |16|15| | | | 1264 N7| | |20|19| | | | 1265 N8| | |18|18| | | | 1266 N9-N11,H1| | |29|36| | | | 1267 N12| | | | |8 |2 | | 1268 N13| | | | |8 | | | 1269 N14| | | | |8 | | | 1270 N15| | | | | |9 | | 1272 Figure 7: Area 1's Database. 1274 Networks and routers are represented by vertices. 1275 An edge of cost X connects Vertex A to Vertex B iff 1276 the intersection of Column A and Row B is marked 1277 with an X. 1279 **FROM** 1281 |RT|RT|RT|RT|RT|RT|RT 1282 |3 |4 |5 |6 |7 |10|11| 1283 ------------------------ 1284 RT3| | | |6 | | | | 1285 RT4| | |8 | | | | | 1286 RT5| |8 | |6 |6 | | | 1287 RT6|8 | |7 | | |5 | | 1288 RT7| | |6 | | | | | 1289 * RT10| | | |7 | | |2 | 1290 * RT11| | | | | |3 | | 1291 T N1|4 |4 | | | | | | 1292 O N2|4 |4 | | | | | | 1293 * N3|1 |1 | | | | | | 1294 * N4|2 |3 | | | | | | 1295 Ia| | | | | |5 | | 1296 Ib| | | |7 | | | | 1297 N6| | | | |1 |1 |3 | 1298 N7| | | | |5 |5 |7 | 1299 N8| | | | |4 |3 |2 | 1300 N9-N11,H1| | | | | | |11| 1301 N12| | |8 | |2 | | | 1302 N13| | |8 | | | | | 1303 N14| | |8 | | | | | 1304 N15| | | | |9 | | | 1306 Figure 8: The backbone's database. 1308 Networks and routers are represented by vertices. 1309 An edge of cost X connects Vertex A to Vertex B iff 1310 the intersection of Column A and Row B is marked 1311 with an X. 1313 The backbone enables the exchange of summary information between 1314 area border routers. Every area border router hears the area 1315 summaries from all other area border routers. It then forms a 1316 picture of the distance to all networks outside of its area by 1317 examining the collected LSAs, and adding in the backbone 1318 distance to each advertising router. 1320 Again using Routers RT3 and RT4 as an example, the procedure 1321 goes as follows: They first calculate the SPF tree for the 1322 backbone. This gives the distances to all other area border 1323 routers. Also noted are the distances to networks (Ia and Ib) 1324 and AS boundary routers (RT5 and RT7) that belong to the 1325 backbone. This calculation is shown in Table 5. 1327 Next, by looking at the area summaries from these area border 1328 routers, RT3 and RT4 can determine the distance to all networks 1329 outside their area. These distances are then advertised 1330 internally to the area by RT3 and RT4. The advertisements that 1331 Router RT3 and RT4 will make into Area 1 are shown in Table 6. 1332 Note that Table 6 assumes that an area range has been configured 1333 for the backbone which groups Ia and Ib into a single LSA. 1335 The information imported into Area 1 by Routers RT3 and RT4 1336 enables an internal router, such as RT1, to choose an area 1337 border router intelligently. Router RT1 would use RT4 for 1339 dist from dist from 1340 RT3 RT4 1341 __________________________________ 1342 to RT3 * 21 1343 to RT4 22 * 1344 to RT7 20 14 1345 to RT10 15 22 1346 to RT11 18 25 1347 __________________________________ 1348 to Ia 20 27 1349 to Ib 15 22 1350 __________________________________ 1351 to RT5 14 8 1352 to RT7 20 14 1354 Table 5: Backbone distances calculated 1355 by Routers RT3 and RT4. 1357 Destination RT3 adv. RT4 adv. 1358 _________________________________ 1359 Ia,Ib 20 27 1360 N6 16 15 1361 N7 20 19 1362 N8 18 18 1363 N9-N11,H1 29 36 1364 _________________________________ 1365 RT5 14 8 1366 RT7 20 14 1368 Table 6: Destinations advertised into Area 1 1369 by Routers RT3 and RT4. 1371 traffic to Network N6, RT3 for traffic to Network N10, and would 1372 load share between the two for traffic to Network N8. 1374 Router RT1 can also determine in this manner the shortest path 1375 to the AS boundary routers RT5 and RT7. Then, by looking at RT5 1376 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or 1377 RT7 when sending to a destination in another Autonomous System 1378 (one of the networks N12-N15). 1380 Note that a failure of the line between Routers RT6 and RT10 1381 will cause the backbone to become disconnected. Configuring a 1382 virtual link between Routers RT7 and RT10 will give the backbone 1383 more connectivity and more resistance to such failures. 1385 3.5. IP subnetting support 1387 OSPF attaches an IP address mask to each advertised route. The 1388 mask indicates the range of addresses being described by the 1389 particular route. For example, a summary-LSA for the 1390 destination 128.185.0.0 with a mask of 0xffff0000 actually is 1391 describing a single route to the collection of destinations 1392 128.185.0.0 - 128.185.255.255. Similarly, host routes are 1393 always advertised with a mask of 0xffffffff, indicating the 1394 presence of only a single destination. 1396 Including the mask with each advertised destination enables the 1397 implementation of what is commonly referred to as variable- 1398 length subnetting. This means that a single IP class A, B, or C 1399 network number can be broken up into many subnets of various 1400 sizes. For example, the network 128.185.0.0 could be broken up 1401 into 62 variable-sized subnets: 15 subnets of size 4K, 15 1402 subnets of size 256, and 32 subnets of size 8. Table 7 shows 1403 some of the resulting network addresses together with their 1404 masks. 1406 Network address IP address mask Subnet size 1407 _______________________________________________ 1408 128.185.16.0 0xfffff000 4K 1409 128.185.1.0 0xffffff00 256 1410 128.185.0.8 0xfffffff8 8 1412 Table 7: Some sample subnet sizes. 1414 There are many possible ways of dividing up a class A, B, and C 1415 network into variable sized subnets. The precise procedure for 1416 doing so is beyond the scope of this specification. This 1417 specification however establishes the following guideline: When 1418 an IP packet is forwarded, it is always forwarded to the network 1419 that is the best match for the packet's destination. Here best 1420 match is synonymous with the longest or most specific match. 1421 For example, the default route with destination of 0.0.0.0 and 1422 mask 0x00000000 is always a match for every IP destination. Yet 1423 it is always less specific than any other match. Subnet masks 1424 must be assigned so that the best match for any IP destination 1425 is unambiguous. 1427 Attaching an address mask to each route also enables the support 1428 of IP supernetting. For example, a single physical network 1429 segment could be assigned the [address,mask] pair 1430 [192.9.4.0,0xfffffc00]. The segment would then be single IP 1431 network, containing addresses from the four consecutive class C 1432 network numbers 192.9.4.0 through 192.9.7.0. Such addressing is 1433 now becoming commonplace with the advent of CIDR (see [Ref10]). 1435 In order to get better aggregation at area boundaries, area 1436 address ranges can be employed (see Section C.2 for more 1437 details). Each address range is defined as an [address,mask] 1438 pair. Many separate networks may then be contained in a single 1439 address range, just as a subnetted network is composed of many 1440 separate subnets. Area border routers then summarize the area 1441 contents (for distribution to the backbone) by advertising a 1442 single route for each address range. The cost of the route is 1443 the maximum cost to any of the networks falling in the specified 1444 range. 1446 For example, an IP subnetted network might be configured as a 1447 single OSPF area. In that case, a single address range could be 1448 configured: a class A, B, or C network number along with its 1449 natural IP mask. Inside the area, any number of variable sized 1450 subnets could be defined. However, external to the area a 1451 single route for the entire subnetted network would be 1452 distributed, hiding even the fact that the network is subnetted 1453 at all. The cost of this route is the maximum of the set of 1454 costs to the component subnets. 1456 3.6. Supporting stub areas 1458 In some Autonomous Systems, the majority of the link-state 1459 database may consist of AS-external-LSAs. An OSPF AS-external- 1460 LSA is usually flooded throughout the entire AS. However, OSPF 1461 allows certain areas to be configured as "stub areas". AS- 1462 external-LSAs are not flooded into/throughout stub areas; 1463 routing to AS external destinations in these areas is based on a 1464 (per-area) default only. This reduces the link-state database 1465 size, and therefore the memory requirements, for a stub area's 1466 internal routers. 1468 In order to take advantage of the OSPF stub area support, 1469 default routing must be used in the stub area. This is 1470 accomplished as follows. One or more of the stub area's area 1471 border routers must advertise a default route into the stub area 1472 via summary-LSAs. These summary defaults are flooded throughout 1473 the stub area, but no further. (For this reason these defaults 1474 pertain only to the particular stub area). These summary 1475 default routes will be used for any destination that is not 1476 explicitly reachable by an intra-area or inter-area path (i.e., 1477 AS external destinations). 1479 An area can be configured as a stub when there is a single exit 1480 point from the area, or when the choice of exit point need not 1481 be made on a per-external-destination basis. For example, Area 1482 3 in Figure 6 could be configured as a stub area, because all 1483 external traffic must travel though its single area border 1484 router RT11. If Area 3 were configured as a stub, Router RT11 1485 would advertise a default route for distribution inside Area 3 1486 (in a summary-LSA), instead of flooding the AS-external-LSAs for 1487 Networks N12-N15 into/throughout the area. 1489 The OSPF protocol ensures that all routers belonging to an area 1490 agree on whether the area has been configured as a stub. This 1491 guarantees that no confusion will arise in the flooding of AS- 1492 external-LSAs. 1494 There are a couple of restrictions on the use of stub areas. 1495 Virtual links cannot be configured through stub areas. In 1496 addition, AS boundary routers cannot be placed internal to stub 1497 areas. 1499 3.7. Partitions of areas 1501 OSPF does not actively attempt to repair area partitions. When 1502 an area becomes partitioned, each component simply becomes a 1503 separate area. The backbone then performs routing between the 1504 new areas. Some destinations reachable via intra-area routing 1505 before the partition will now require inter-area routing. 1507 However, in order to maintain full routing after the partition, 1508 an address range must not be split across multiple components of 1509 the area partition. Also, the backbone itself must not 1510 partition. If it does, parts of the Autonomous System will 1511 become unreachable. Backbone partitions can be repaired by 1512 configuring virtual links (see Section 15). 1514 Another way to think about area partitions is to look at the 1515 Autonomous System graph that was introduced in Section 2. Area 1516 IDs can be viewed as colors for the graph's edges.[1] Each edge 1517 of the graph connects to a network, or is itself a point-to- 1518 point network. In either case, the edge is colored with the 1519 network's Area ID. 1521 A group of edges, all having the same color, and interconnected 1522 by vertices, represents an area. If the topology of the 1523 Autonomous System is intact, the graph will have several regions 1524 of color, each color being a distinct Area ID. 1526 When the AS topology changes, one of the areas may become 1527 partitioned. The graph of the AS will then have multiple 1528 regions of the same color (Area ID). The routing in the 1529 Autonomous System will continue to function as long as these 1530 regions of same color are connected by the single backbone 1531 region. 1533 4. Functional Summary 1535 A separate copy of OSPF's basic routing algorithm runs in each area. 1536 Routers having interfaces to multiple areas run multiple copies of 1537 the algorithm. A brief summary of the routing algorithm follows. 1539 When a router starts, it first initializes the routing protocol data 1540 structures. The router then waits for indications from the lower- 1541 level protocols that its interfaces are functional. 1543 A router then uses the OSPF's Hello Protocol to acquire neighbors. 1544 The router sends Hello packets to its neighbors, and in turn 1545 receives their Hello packets. On broadcast and point-to-point 1546 networks, the router dynamically detects its neighboring routers by 1547 sending its Hello packets to the multicast address AllSPFRouters. 1548 On non-broadcast networks, some configuration information may be 1549 necessary in order to discover neighbors. On broadcast and NBMA 1550 networks the Hello Protocol also elects a Designated router for the 1551 network. 1553 The router will attempt to form adjacencies with some of its newly 1554 acquired neighbors. Link-state databases are synchronized between 1555 pairs of adjacent routers. On broadcast and NBMA networks, the 1556 Designated Router determines which routers should become adjacent. 1558 Adjacencies control the distribution of routing information. 1559 Routing updates are sent and received only on adjacencies. 1561 A router periodically advertises its state, which is also called 1562 link state. Link state is also advertised when a router's state 1563 changes. A router's adjacencies are reflected in the contents of 1564 its LSAs. This relationship between adjacencies and link state 1565 allows the protocol to detect dead routers in a timely fashion. 1567 LSAs are flooded throughout the area. The flooding algorithm is 1568 reliable, ensuring that all routers in an area have exactly the same 1569 link-state database. This database consists of the collection of 1570 LSAs originated by each router belonging to the area. From this 1571 database each router calculates a shortest-path tree, with itself as 1572 root. This shortest-path tree in turn yields a routing table for 1573 the protocol. 1575 4.1. Inter-area routing 1577 The previous section described the operation of the protocol 1578 within a single area. For intra-area routing, no other routing 1579 information is pertinent. In order to be able to route to 1580 destinations outside of the area, the area border routers inject 1581 additional routing information into the area. This additional 1582 information is a distillation of the rest of the Autonomous 1583 System's topology. 1585 This distillation is accomplished as follows: Each area border 1586 router is by definition connected to the backbone. Each area 1587 border router summarizes the topology of its attached non- 1588 backbone areas for transmission on the backbone, and hence to 1589 all other area border routers. An area border router then has 1590 complete topological information concerning the backbone, and 1591 the area summaries from each of the other area border routers. 1592 From this information, the router calculates paths to all 1593 inter-area destinations. The router then advertises these paths 1594 into its attached areas. This enables the area's internal 1595 routers to pick the best exit router when forwarding traffic 1596 inter-area destinations. 1598 4.2. AS external routes 1600 Routers that have information regarding other Autonomous Systems 1601 can flood this information throughout the AS. This external 1602 routing information is distributed verbatim to every 1603 participating router. There is one exception: external routing 1604 information is not flooded into "stub" areas (see Section 3.6). 1606 To utilize external routing information, the path to all routers 1607 advertising external information must be known throughout the AS 1608 (excepting the stub areas). For that reason, the locations of 1609 these AS boundary routers are summarized by the (non-stub) area 1610 border routers. 1612 4.3. Routing protocol packets 1614 The OSPF protocol runs directly over IP, using IP protocol 89. 1615 OSPF does not provide any explicit fragmentation/reassembly 1616 support. When fragmentation is necessary, IP 1617 fragmentation/reassembly is used. OSPF protocol packets have 1618 been designed so that large protocol packets can generally be 1619 split into several smaller protocol packets. This practice is 1620 recommended; IP fragmentation should be avoided whenever 1621 possible. 1623 Routing protocol packets should always be sent with the IP TOS 1624 field set to 0. If at all possible, routing protocol packets 1625 should be given preference over regular IP data traffic, both 1626 when being sent and received. As an aid to accomplishing this, 1627 OSPF protocol packets should have their IP precedence field set 1628 to the value Internetwork Control (see [Ref5]). 1630 All OSPF protocol packets share a common protocol header that is 1631 described in Appendix A. The OSPF packet types are listed below 1632 in Table 8. Their formats are also described in Appendix A. 1634 Type Packet name Protocol function 1635 __________________________________________________________ 1636 1 Hello Discover/maintain neighbors 1637 2 Database Description Summarize database contents 1638 3 Link State Request Database download 1639 4 Link State Update Database update 1640 5 Link State Ack Flooding acknowledgment 1642 Table 8: OSPF packet types. 1644 OSPF's Hello protocol uses Hello packets to discover and 1645 maintain neighbor relationships. The Database Description and 1646 Link State Request packets are used in the forming of 1647 adjacencies. OSPF's reliable update mechanism is implemented by 1648 the Link State Update and Link State Acknowledgment packets. 1650 Each Link State Update packet carries a set of new link state 1651 advertisements (LSAs) one hop further away from their point of 1652 origination. A single Link State Update packet may contain the 1653 LSAs of several routers. Each LSA is tagged with the ID of the 1654 originating router and a checksum of its link state contents. 1655 Each LSA also has a type field; the different types of OSPF LSAs 1656 are listed below in Table 9. 1658 OSPF routing packets (with the exception of Hellos) are sent 1659 only over adjacencies. This means that all OSPF protocol 1660 packets travel a single IP hop, except those that are sent over 1661 virtual adjacencies. The IP source address of an OSPF protocol 1662 packet is one end of a router adjacency, and the IP destination 1663 address is either the other end of the adjacency or an IP 1664 multicast address. 1666 LS LSA LSA description 1667 type name 1668 ________________________________________________________ 1669 1 Router-LSAs Originated by all routers. 1670 This LSA describes 1671 the collected states of the 1672 router's interfaces to an 1673 area. Flooded throughout a 1674 single area only. 1675 ________________________________________________________ 1676 2 Network-LSAs Originated for broadcast 1677 and NBMA networks by 1678 the Designated Router. This 1679 LSA contains the 1680 list of routers connected 1681 to the network. Flooded 1682 throughout a single area only. 1683 ________________________________________________________ 1684 3,4 Summary-LSAs Originated by area border 1685 routers, and flooded through- 1686 out the LSA's associated 1687 area. Each summary-LSA 1688 describes a route to a 1689 destination outside the area, 1690 yet still inside the AS 1691 (i.e., an inter-area route). 1692 Type 3 summary-LSAs describe 1693 routes to networks. Type 4 1694 summary-LSAs describe 1695 routes to AS boundary routers. 1696 ________________________________________________________ 1697 5 AS-external-LSAs Originated by AS boundary 1698 routers, and flooded through- 1699 out the AS. Each 1700 AS-external-LSA describes 1701 a route to a destination in 1702 another Autonomous System. 1703 Default routes for the AS can 1704 also be described by 1705 AS-external-LSAs. 1707 Table 9: OSPF link state advertisements (LSAs). 1709 4.4. Basic implementation requirements 1711 An implementation of OSPF requires the following pieces of 1712 system support: 1714 Timers 1715 Two different kind of timers are required. The first kind, 1716 called "single shot timers", fire once and cause a protocol 1717 event to be processed. The second kind, called "interval 1718 timers", fire at continuous intervals. These are used for 1719 the sending of packets at regular intervals. A good example 1720 of this is the regular broadcast of Hello packets. The 1721 granularity of both kinds of timers is one second. 1723 Interval timers should be implemented to avoid drift. In 1724 some router implementations, packet processing can affect 1725 timer execution. When multiple routers are attached to a 1726 single network, all doing broadcasts, this can lead to the 1727 synchronization of routing packets (which should be 1728 avoided). If timers cannot be implemented to avoid drift, 1729 small random amounts should be added to/subtracted from the 1730 interval timer at each firing. 1732 IP multicast 1733 Certain OSPF packets take the form of IP multicast 1734 datagrams. Support for receiving and sending IP multicast 1735 datagrams, along with the appropriate lower-level protocol 1736 support, is required. The IP multicast datagrams used by 1737 OSPF never travel more than one hop. For this reason, the 1738 ability to forward IP multicast datagrams is not required. 1739 For information on IP multicast, see [Ref7]. 1741 Variable-length subnet support 1742 The router's IP protocol support must include the ability to 1743 divide a single IP class A, B, or C network number into many 1744 subnets of various sizes. This is commonly called 1745 variable-length subnetting; see Section 3.5 for details. 1747 IP supernetting support 1748 The router's IP protocol support must include the ability to 1749 aggregate contiguous collections of IP class A, B, and C 1750 networks into larger quantities called supernets. 1751 Supernetting has been proposed as one way to improve the 1752 scaling of IP routing in the worldwide Internet. For more 1753 information on IP supernetting, see [Ref10]. 1755 Lower-level protocol support 1756 The lower level protocols referred to here are the network 1757 access protocols, such as the Ethernet data link layer. 1758 Indications must be passed from these protocols to OSPF as 1759 the network interface goes up and down. For example, on an 1760 ethernet it would be valuable to know when the ethernet 1761 transceiver cable becomes unplugged. 1763 Non-broadcast lower-level protocol support 1764 On non-broadcast networks, the OSPF Hello Protocol can be 1765 aided by providing an indication when an attempt is made to 1766 send a packet to a dead or non-existent router. For 1767 example, on an X.25 PDN a dead neighboring router may be 1768 indicated by the reception of a X.25 clear with an 1769 appropriate cause and diagnostic, and this information would 1770 be passed to OSPF. 1772 List manipulation primitives 1773 Much of the OSPF functionality is described in terms of its 1774 operation on lists of LSAs. For example, the collection of 1775 LSAs that will be retransmitted to an adjacent router until 1776 acknowledged are described as a list. Any particular LSA 1777 may be on many such lists. An OSPF implementation needs to 1778 be able to manipulate these lists, adding and deleting 1779 constituent LSAs as necessary. 1781 Tasking support 1782 Certain procedures described in this specification invoke 1783 other procedures. At times, these other procedures should 1784 be executed in-line, that is, before the current procedure 1785 is finished. This is indicated in the text by instructions 1786 to execute a procedure. At other times, the other 1787 procedures are to be executed only when the current 1788 procedure has finished. This is indicated by instructions 1789 to schedule a task. 1791 4.5. Optional OSPF capabilities 1793 The OSPF protocol defines several optional capabilities. A 1794 router indicates the optional capabilities that it supports in 1795 its OSPF Hello packets, Database Description packets and in its 1796 LSAs. This enables routers supporting a mix of optional 1797 capabilities to coexist in a single Autonomous System. 1799 Some capabilities must be supported by all routers attached to a 1800 specific area. In this case, a router will not accept a 1801 neighbor's Hello Packet unless there is a match in reported 1802 capabilities (i.e., a capability mismatch prevents a neighbor 1803 relationship from forming). An example of this is the 1804 ExternalRoutingCapability (see below). 1806 Other capabilities can be negotiated during the Database 1807 Exchange process. This is accomplished by specifying the 1808 optional capabilities in Database Description packets. A 1809 capability mismatch with a neighbor in this case will result in 1810 only a subset of the link state database being exchanged between 1811 the two neighbors. 1813 The routing table build process can also be affected by the 1814 presence/absence of optional capabilities. For example, since 1815 the optional capabilities are reported in LSAs, routers 1816 incapable of certain functions can be avoided when building the 1817 shortest path tree. 1819 The OSPF optional capabilities defined in this memo are listed 1820 below. See Section A.2 for more information. 1822 ExternalRoutingCapability 1823 Entire OSPF areas can be configured as "stubs" (see Section 1824 3.6). AS-external-LSAs will not be flooded into stub areas. 1825 This capability is represented by the E-bit in the OSPF 1826 Options field (see Section A.2). In order to ensure 1827 consistent configuration of stub areas, all routers 1828 interfacing to such an area must have the E-bit clear in 1829 their Hello packets (see Sections 9.5 and 10.5). 1831 5. Protocol Data Structures 1833 The OSPF protocol is described herein in terms of its operation on 1834 various protocol data structures. The following list comprises the 1835 top-level OSPF data structures. Any initialization that needs to be 1836 done is noted. OSPF areas, interfaces and neighbors also have 1837 associated data structures that are described later in this 1838 specification. 1840 Router ID 1841 A 32-bit number that uniquely identifies this router in the AS. 1842 One possible implementation strategy would be to use the 1843 smallest IP interface address belonging to the router. If a 1844 router's OSPF Router ID is changed, the router's OSPF software 1845 should be restarted before the new Router ID takes effect. In 1846 this case the router should flush its self-originated LSAs from 1847 the routing domain (see Section 14.1) before restarting, or they 1848 will persist for up to MaxAge minutes. 1850 Area structures 1851 Each one of the areas to which the router is connected has its 1852 own data structure. This data structure describes the working 1853 of the basic OSPF algorithm. Remember that each area runs a 1854 separate copy of the basic OSPF algorithm. 1856 Backbone (area) structure 1857 The OSPF backbone area is responsible for the dissemination of 1858 inter-area routing information. 1860 Virtual links configured 1861 The virtual links configured with this router as one endpoint. 1862 In order to have configured virtual links, the router itself 1863 must be an area border router. Virtual links are identified by 1864 the Router ID of the other endpoint -- which is another area 1865 border router. These two endpoint routers must be attached to a 1866 common area, called the virtual link's Transit area. Virtual 1867 links are part of the backbone, and behave as if they were 1868 unnumbered point-to-point networks between the two routers. A 1869 virtual link uses the intra-area routing of its Transit area to 1870 forward packets. Virtual links are brought up and down through 1871 the building of the shortest-path trees for the Transit area. 1873 List of external routes 1874 These are routes to destinations external to the Autonomous 1875 System, that have been gained either through direct experience 1876 with another routing protocol (such as BGP), or through 1877 configuration information, or through a combination of the two 1878 (e.g., dynamic external information to be advertised by OSPF 1879 with configured metric). Any router having these external routes 1880 is called an AS boundary router. These routes are advertised by 1881 the router into the OSPF routing domain via AS-external-LSAs. 1883 List of AS-external-LSAs 1884 Part of the link-state database. These have originated from the 1885 AS boundary routers. They comprise routes to destinations 1886 external to the Autonomous System. Note that, if the router is 1887 itself an AS boundary router, some of these AS-external-LSAs 1888 have been self-originated. 1890 The routing table 1891 Derived from the link-state database. Each entry in the routing 1892 table is indexed by a destination, and contains the 1893 destination's cost and a set of paths to use in forwarding 1894 packets to the destination. A path is described by its type and 1895 next hop. For more information, see Section 11. 1897 Figure 9 shows the collection of data structures present in a 1898 typical router. The router pictured is RT10, from the map in Figure 1899 6. Note that Router RT10 has a virtual link configured to Router 1900 RT11, with Area 2 as the link's Transit area. This is indicated by 1901 the dashed line in Figure 9. When the virtual link becomes active, 1902 through the building of the shortest path tree for Area 2, it 1903 becomes an interface to the backbone (see the two backbone 1904 interfaces depicted in Figure 9). 1906 +----+ 1907 |RT10|------+ 1908 +----+ \+-------------+ 1909 / \ |Routing Table| 1910 / \ +-------------+ 1911 / \ 1912 +------+ / \ +--------+ 1913 |Area 2|---+ +---|Backbone| 1914 +------+***********+ +--------+ 1915 / \ * / \ 1916 / \ * / \ 1917 +---------+ +---------+ +------------+ +------------+ 1918 |Interface| |Interface| |Virtual Link| |Interface Ib| 1919 | to N6 | | to N8 | | to RT11 | +------------+ 1920 +---------+ +---------+ +------------+ | 1921 / \ | | | 1922 / \ | | | 1923 +--------+ +--------+ | +-------------+ +------------+ 1924 |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| 1925 | RT8 | | RT7 | | +-------------+ +------------+ 1926 +--------+ +--------+ | 1927 | 1928 +-------------+ 1929 |Neighbor RT11| 1930 +-------------+ 1932 Figure 9: Router RT10's Data structures 1933 6. The Area Data Structure 1935 The area data structure contains all the information used to run the 1936 basic OSPF routing algorithm. Each area maintains its own link-state 1937 database. A network belongs to a single area, and a router interface 1938 connects to a single area. Each router adjacency also belongs to a 1939 single area. 1941 The OSPF backbone is the special OSPF area responsible for 1942 disseminating inter-area routing information. 1944 The area link-state database consists of the collection of router- 1945 LSAs, network-LSAs and summary-LSAs that have originated from the 1946 area's routers. This information is flooded throughout a single 1947 area only. The list of AS-external-LSAs (see Section 5) is also 1948 considered to be part of each area's link-state database. 1950 Area ID 1951 A 32-bit number identifying the area. The Area ID of 0.0.0.0 is 1952 reserved for the backbone. 1954 List of area address ranges 1955 In order to aggregate routing information at area boundaries, 1956 area address ranges can be employed. Each address range is 1957 specified by an [address,mask] pair and a status indication of 1958 either Advertise or DoNotAdvertise (see Section 12.4.3). 1960 Associated router interfaces 1961 This router's interfaces connecting to the area. A router 1962 interface belongs to one and only one area (or the backbone). 1963 For the backbone area this list includes all the virtual links. 1964 A virtual link is identified by the Router ID of its other 1965 endpoint; its cost is the cost of the shortest intra-area path 1966 through the Transit area that exists between the two routers. 1968 List of router-LSAs 1969 A router-LSA is generated by each router in the area. It 1970 describes the state of the router's interfaces to the area. 1972 List of network-LSAs 1973 One network-LSA is generated for each transit broadcast and NBMA 1974 network in the area. A network-LSA describes the set of routers 1975 currently connected to the network. 1977 List of summary-LSAs 1978 Summary-LSAs originate from the area's area border routers. 1979 They describe routes to destinations internal to the Autonomous 1980 System, yet external to the area (i.e., inter-area 1981 destinations). 1983 Shortest-path tree 1984 The shortest-path tree for the area, with this router itself as 1985 root. Derived from the collected router-LSAs and network-LSAs 1986 by the Dijkstra algorithm (see Section 16.1). 1988 TransitCapability 1989 This parameter indicates whether the area can carry data traffic 1990 that neither originates nor terminates in the area itself. This 1991 parameter is calculated when the area's shortest-path tree is 1992 built (see Section 16.1, where TransitCapability is set to TRUE 1993 if and only if there are one or more fully adjacent virtual 1994 links using the area as Transit area), and is used as an input 1995 to a subsequent step of the routing table build process (see 1996 Section 16.3). When an area's TransitCapability is set to TRUE, 1997 the area is said to be a "transit area". 1999 ExternalRoutingCapability 2000 Whether AS-external-LSAs will be flooded into/throughout the 2001 area. This is a configurable parameter. If AS-external-LSAs 2002 are excluded from the area, the area is called a "stub". Within 2003 stub areas, routing to AS external destinations will be based 2004 solely on a default summary route. The backbone cannot be 2005 configured as a stub area. Also, virtual links cannot be 2006 configured through stub areas. For more information, see 2007 Section 3.6. 2009 StubDefaultCost 2010 If the area has been configured as a stub area, and the router 2011 itself is an area border router, then the StubDefaultCost 2012 indicates the cost of the default summary-LSA that the router 2013 should advertise into the area. See Section 12.4.3 for more 2014 information. 2016 Unless otherwise specified, the remaining sections of this document 2017 refer to the operation of the OSPF protocol within a single area. 2019 7. Bringing Up Adjacencies 2021 OSPF creates adjacencies between neighboring routers for the purpose 2022 of exchanging routing information. Not every two neighboring 2023 routers will become adjacent. This section covers the generalities 2024 involved in creating adjacencies. For further details consult 2025 Section 10. 2027 7.1. The Hello Protocol 2029 The Hello Protocol is responsible for establishing and 2030 maintaining neighbor relationships. It also ensures that 2031 communication between neighbors is bidirectional. Hello packets 2032 are sent periodically out all router interfaces. Bidirectional 2033 communication is indicated when the router sees itself listed in 2034 the neighbor's Hello Packet. On broadcast and NBMA networks, 2035 the Hello Protocol elects a Designated Router for the network. 2037 The Hello Protocol works differently on broadcast networks, NBMA 2038 networks and Point-to-MultiPoint networks. On broadcast 2039 networks, each router advertises itself by periodically 2040 multicasting Hello Packets. This allows neighbors to be 2041 discovered dynamically. These Hello Packets contain the 2042 router's view of the Designated Router's identity, and the list 2043 of routers whose Hello Packets have been seen recently. 2045 On NBMA networks some configuration information may be necessary 2046 for the operation of the Hello Protocol. Each router that may 2047 potentially become Designated Router has a list of all other 2048 routers attached to the network. A router, having Designated 2049 Router potential, sends Hello Packets to all other potential 2050 Designated Routers when its interface to the NBMA network first 2051 becomes operational. This is an attempt to find the Designated 2052 Router for the network. If the router itself is elected 2053 Designated Router, it begins sending Hello Packets to all other 2054 routers attached to the network. 2056 On Point-to-MultiPoint networks, a router sends Hello Packets to 2057 all neighbors with which it can communicate directly. These 2058 neighbors may be discovered dynamically through a protocol such 2059 as Inverse ARP (see [Ref14]), or they may be configured. 2061 After a neighbor has been discovered, bidirectional 2062 communication ensured, and (if on a broadcast or NBMA network) a 2063 Designated Router elected, a decision is made regarding whether 2064 or not an adjacency should be formed with the neighbor (see 2065 Section 10.4). If an adjacency is to be formed, the first step 2066 is to synchronize the neighbors' link-state databases. This is 2067 covered in the next section. 2069 7.2. The Synchronization of Databases 2071 In a link-state routing algorithm, it is very important for all 2072 routers' link-state databases to stay synchronized. OSPF 2073 simplifies this by requiring only adjacent routers to remain 2074 synchronized. The synchronization process begins as soon as the 2075 routers attempt to bring up the adjacency. Each router 2076 describes its database by sending a sequence of Database 2077 Description packets to its neighbor. Each Database Description 2078 Packet describes a set of LSAs belonging to the router's 2079 database. When the neighbor sees an LSA that is more recent 2080 than its own database copy, it makes a note that this newer LSA 2081 should be requested. 2083 This sending and receiving of Database Description packets is 2084 called the "Database Exchange Process". During this process, 2085 the two routers form a master/slave relationship. Each Database 2086 Description Packet has a sequence number. Database Description 2087 Packets sent by the master (polls) are acknowledged by the slave 2088 through echoing of the sequence number. Both polls and their 2089 responses contain summaries of link state data. The master is 2090 the only one allowed to retransmit Database Description Packets. 2091 It does so only at fixed intervals, the length of which is the 2092 configured per-interface constant RxmtInterval. 2094 Each Database Description contains an indication that there are 2095 more packets to follow --- the M-bit. The Database Exchange 2096 Process is over when a router has received and sent Database 2097 Description Packets with the M-bit off. 2099 During and after the Database Exchange Process, each router has 2100 a list of those LSAs for which the neighbor has more up-to-date 2101 instances. These LSAs are requested in Link State Request 2102 Packets. Link State Request packets that are not satisfied are 2103 retransmitted at fixed intervals of time RxmtInterval. When the 2104 Database Description Process has completed and all Link State 2105 Requests have been satisfied, the databases are deemed 2106 synchronized and the routers are marked fully adjacent. At this 2107 time the adjacency is fully functional and is advertised in the 2108 two routers' router-LSAs. 2110 The adjacency is used by the flooding procedure as soon as the 2111 Database Exchange Process begins. This simplifies database 2112 synchronization, and guarantees that it finishes in a 2113 predictable period of time. 2115 7.3. The Designated Router 2117 Every broadcast and NBMA network has a Designated Router. The 2118 Designated Router performs two main functions for the routing 2119 protocol: 2121 o The Designated Router originates a network-LSA on behalf of 2122 the network. This LSA lists the set of routers (including 2123 the Designated Router itself) currently attached to the 2124 network. The Link State ID for this LSA (see Section 2125 12.1.4) is the IP interface address of the Designated 2126 Router. The IP network number can then be obtained by using 2127 the network's subnet/network mask. 2129 o The Designated Router becomes adjacent to all other routers 2130 on the network. Since the link state databases are 2131 synchronized across adjacencies (through adjacency bring-up 2132 and then the flooding procedure), the Designated Router 2133 plays a central part in the synchronization process. 2135 The Designated Router is elected by the Hello Protocol. A 2136 router's Hello Packet contains its Router Priority, which is 2137 configurable on a per-interface basis. In general, when a 2138 router's interface to a network first becomes functional, it 2139 checks to see whether there is currently a Designated Router for 2140 the network. If there is, it accepts that Designated Router, 2141 regardless of its Router Priority. (This makes it harder to 2142 predict the identity of the Designated Router, but ensures that 2143 the Designated Router changes less often. See below.) 2144 Otherwise, the router itself becomes Designated Router if it has 2145 the highest Router Priority on the network. A more detailed 2146 (and more accurate) description of Designated Router election is 2147 presented in Section 9.4. 2149 The Designated Router is the endpoint of many adjacencies. In 2150 order to optimize the flooding procedure on broadcast networks, 2151 the Designated Router multicasts its Link State Update Packets 2152 to the address AllSPFRouters, rather than sending separate 2153 packets over each adjacency. 2155 Section 2 of this document discusses the directed graph 2156 representation of an area. Router nodes are labelled with their 2157 Router ID. Transit network nodes are actually labelled with the 2158 IP address of their Designated Router. It follows that when the 2159 Designated Router changes, it appears as if the network node on 2160 the graph is replaced by an entirely new node. This will cause 2161 the network and all its attached routers to originate new LSAs. 2162 Until the link-state databases again converge, some temporary 2163 loss of connectivity may result. This may result in ICMP 2164 unreachable messages being sent in response to data traffic. 2165 For that reason, the Designated Router should change only 2166 infrequently. Router Priorities should be configured so that 2167 the most dependable router on a network eventually becomes 2168 Designated Router. 2170 7.4. The Backup Designated Router 2172 In order to make the transition to a new Designated Router 2173 smoother, there is a Backup Designated Router for each broadcast 2174 and NBMA network. The Backup Designated Router is also adjacent 2175 to all routers on the network, and becomes Designated Router 2176 when the previous Designated Router fails. If there were no 2177 Backup Designated Router, when a new Designated Router became 2178 necessary, new adjacencies would have to be formed between the 2179 new Designated Router and all other routers attached to the 2180 network. Part of the adjacency forming process is the 2181 synchronizing of link-state databases, which can potentially 2182 take quite a long time. During this time, the network would not 2183 be available for transit data traffic. The Backup Designated 2184 obviates the need to form these adjacencies, since they already 2185 exist. This means the period of disruption in transit traffic 2186 lasts only as long as it takes to flood the new LSAs (which 2187 announce the new Designated Router). 2189 The Backup Designated Router does not generate a network-LSA for 2190 the network. (If it did, the transition to a new Designated 2191 Router would be even faster. However, this is a tradeoff 2192 between database size and speed of convergence when the 2193 Designated Router disappears.) 2195 The Backup Designated Router is also elected by the Hello 2196 Protocol. Each Hello Packet has a field that specifies the 2197 Backup Designated Router for the network. 2199 In some steps of the flooding procedure, the Backup Designated 2200 Router plays a passive role, letting the Designated Router do 2201 more of the work. This cuts down on the amount of local routing 2202 traffic. See Section 13.3 for more information. 2204 7.5. The graph of adjacencies 2206 An adjacency is bound to the network that the two routers have 2207 in common. If two routers have multiple networks in common, 2208 they may have multiple adjacencies between them. 2210 One can picture the collection of adjacencies on a network as 2211 forming an undirected graph. The vertices consist of routers, 2212 with an edge joining two routers if they are adjacent. The 2213 graph of adjacencies describes the flow of routing protocol 2214 packets, and in particular Link State Update Packets, through 2215 the Autonomous System. 2217 Two graphs are possible, depending on whether a Designated 2218 Router is elected for the network. On physical point-to-point 2219 networks, Point-to-MultiPoint networks and virtual links, 2220 neighboring routers become adjacent whenever they can 2221 communicate directly. In contrast, on broadcast and NBMA 2222 networks only the Designated Router and the Backup Designated 2223 Router become adjacent to all other routers attached to the 2224 network. 2226 These graphs are shown in Figure 10. It is assumed that Router 2227 RT7 has become the Designated Router, and Router RT3 the Backup 2228 Designated Router, for the Network N2. The Backup Designated 2229 Router performs a lesser function during the flooding procedure 2230 than the Designated Router (see Section 13.3). This is the 2231 reason for the dashed lines connecting the Backup Designated 2232 Router RT3. 2234 +---+ +---+ 2235 |RT1|------------|RT2| o---------------o 2236 +---+ N1 +---+ RT1 RT2 2238 RT7 2239 o---------+ 2240 +---+ +---+ +---+ /|\ | 2241 |RT7| |RT3| |RT4| / | \ | 2242 +---+ +---+ +---+ / | \ | 2243 | | | / | \ | 2244 +-----------------------+ RT5o RT6o oRT4 | 2245 | | N2 * * * | 2246 +---+ +---+ * * * | 2247 |RT5| |RT6| * * * | 2248 +---+ +---+ *** | 2249 o---------+ 2250 RT3 2252 Figure 10: The graph of adjacencies 2253 8. Protocol Packet Processing 2255 This section discusses the general processing of OSPF routing 2256 protocol packets. It is very important that the router link-state 2257 databases remain synchronized. For this reason, routing protocol 2258 packets should get preferential treatment over ordinary data 2259 packets, both in sending and receiving. 2261 Routing protocol packets are sent along adjacencies only (with the 2262 exception of Hello packets, which are used to discover the 2263 adjacencies). This means that all routing protocol packets travel a 2264 single IP hop, except those sent over virtual links. 2266 All routing protocol packets begin with a standard header. The 2267 sections below provide details on how to fill in and verify this 2268 standard header. Then, for each packet type, the section giving 2269 more details on that particular packet type's processing is listed. 2271 8.1. Sending protocol packets 2273 When a router sends a routing protocol packet, it fills in the 2274 fields of the standard OSPF packet header as follows. For more 2275 details on the header format consult Section A.3.1: 2277 Version # 2278 Set to 2, the version number of the protocol as documented 2279 in this specification. 2281 Packet type 2282 The type of OSPF packet, such as Link state Update or Hello 2283 Packet. 2285 Packet length 2286 The length of the entire OSPF packet in bytes, including the 2287 standard OSPF packet header. 2289 Router ID 2290 The identity of the router itself (who is originating the 2291 packet). 2293 Area ID 2294 The OSPF area that the packet is being sent into. 2296 Checksum 2297 The standard IP 16-bit one's complement checksum of the 2298 entire OSPF packet, excluding the 64-bit authentication 2299 field. This checksum is calculated as part of the 2300 appropriate authentication procedure; for some OSPF 2301 authentication types, the checksum calculation is omitted. 2302 See Section D.4 for details. 2304 AuType and Authentication 2305 Each OSPF packet exchange is authenticated. Authentication 2306 types are assigned by the protocol and are documented in 2307 Appendix D. A different authentication procedure can be 2308 used for each IP network/subnet. Autype indicates the type 2309 of authentication procedure in use. The 64-bit 2310 authentication field is then for use by the chosen 2311 authentication procedure. This procedure should be the last 2312 called when forming the packet to be sent. See Section D.4 2313 for details. 2315 The IP destination address for the packet is selected as 2316 follows. On physical point-to-point networks, the IP 2317 destination is always set to the address AllSPFRouters. On all 2318 other network types (including virtual links), the majority of 2319 OSPF packets are sent as unicasts, i.e., sent directly to the 2320 other end of the adjacency. In this case, the IP destination is 2321 just the Neighbor IP address associated with the other end of 2322 the adjacency (see Section 10). The only packets not sent as 2323 unicasts are on broadcast networks; on these networks Hello 2324 packets are sent to the multicast destination AllSPFRouters, the 2325 Designated Router and its Backup send both Link State Update 2326 Packets and Link State Acknowledgment Packets to the multicast 2327 address AllSPFRouters, while all other routers send both their 2328 Link State Update and Link State Acknowledgment Packets to the 2329 multicast address AllDRouters. 2331 Retransmissions of Link State Update packets are ALWAYS sent 2332 directly to the neighbor. On multi-access networks, this means 2333 that retransmissions should be sent to the neighbor's IP 2334 address. 2336 The IP source address should be set to the IP address of the 2337 sending interface. Interfaces to unnumbered point-to-point 2338 networks have no associated IP address. On these interfaces, 2339 the IP source should be set to any of the other IP addresses 2340 belonging to the router. For this reason, there must be at 2341 least one IP address assigned to the router.[2] Note that, for 2342 most purposes, virtual links act precisely the same as 2343 unnumbered point-to-point networks. However, each virtual link 2344 does have an IP interface address (discovered during the routing 2345 table build process) which is used as the IP source when sending 2346 packets over the virtual link. 2348 For more information on the format of specific OSPF packet 2349 types, consult the sections listed in Table 10. 2351 Type Packet name detailed section (transmit) 2352 _________________________________________________________ 2353 1 Hello Section 9.5 2354 2 Database description Section 10.8 2355 3 Link state request Section 10.9 2356 4 Link state update Section 13.3 2357 5 Link state ack Section 13.5 2359 Table 10: Sections describing OSPF protocol packet transmission. 2361 8.2. Receiving protocol packets 2363 Whenever a protocol packet is received by the router it is 2364 marked with the interface it was received on. For routers that 2365 have virtual links configured, it may not be immediately obvious 2366 which interface to associate the packet with. For example, 2367 consider the Router RT11 depicted in Figure 6. If RT11 receives 2368 an OSPF protocol packet on its interface to Network N8, it may 2369 want to associate the packet with the interface to Area 2, or 2370 with the virtual link to Router RT10 (which is part of the 2371 backbone). In the following, we assume that the packet is 2372 initially associated with the non-virtual link.[3] 2374 In order for the packet to be accepted at the IP level, it must 2375 pass a number of tests, even before the packet is passed to OSPF 2376 for processing: 2378 o The IP checksum must be correct. 2380 o The packet's IP destination address must be the IP address 2381 of the receiving interface, or one of the IP multicast 2382 addresses AllSPFRouters or AllDRouters. 2384 o The IP protocol specified must be OSPF (89). 2386 o Locally originated packets should not be passed on to OSPF. 2387 That is, the source IP address should be examined to make 2388 sure this is not a multicast packet that the router itself 2389 generated. 2391 Next, the OSPF packet header is verified. The fields specified 2392 in the header must match those configured for the receiving 2393 interface. If they do not, the packet should be discarded: 2395 o The version number field must specify protocol version 2. 2397 o The Area ID found in the OSPF header must be verified. If 2398 both of the following cases fail, the packet should be 2399 discarded. The Area ID specified in the header must either: 2401 (1) Match the Area ID of the receiving interface. In this 2402 case, the packet has been sent over a single hop. 2403 Therefore, the packet's IP source address is required to 2404 be on the same network as the receiving interface. This 2405 can be verified by comparing the packet's IP source 2406 address to the interface's IP address, after masking 2407 both addresses with the interface mask. This comparison 2408 should not be performed on point-to-point networks. On 2409 point-to-point networks, the interface addresses of each 2410 end of the link are assigned independently, if they are 2411 assigned at all. 2413 (2) Indicate the backbone. In this case, the packet has 2414 been sent over a virtual link. The receiving router 2415 must be an area border router, and the Router ID 2416 specified in the packet (the source router) must be the 2417 other end of a configured virtual link. The receiving 2418 interface must also attach to the virtual link's 2419 configured Transit area. If all of these checks 2420 succeed, the packet is accepted and is from now on 2421 associated with the virtual link (and the backbone 2422 area). 2424 o Packets whose IP destination is AllDRouters should only be 2425 accepted if the state of the receiving interface is DR or 2426 Backup (see Section 9.1). 2428 o The AuType specified in the packet must match the AuType 2429 specified for the associated area. 2431 o The packet must be authenticated. The authentication 2432 procedure is indicated by the setting of AuType (see 2433 Appendix D). The authentication procedure may use one or 2434 more Authentication keys, which can be configured on a per- 2435 interface basis. The authentication procedure may also 2436 verify the checksum field in the OSPF packet header (which, 2437 when used, is set to the standard IP 16-bit one's complement 2438 checksum of the OSPF packet's contents after excluding the 2439 64-bit authentication field). If the authentication 2440 procedure fails, the packet should be discarded. 2442 If the packet type is Hello, it should then be further processed 2443 by the Hello Protocol (see Section 10.5). All other packet 2444 types are sent/received only on adjacencies. This means that 2445 the packet must have been sent by one of the router's active 2446 neighbors. If the receiving interface connects to a broadcast 2447 network, Point-to-MultiPoint network or NBMA network the sender 2448 is identified by the IP source address found in the packet's IP 2449 header. If the receiving interface connects to a point-to-point 2450 network or a virtual link, the sender is identified by the 2451 Router ID (source router) found in the packet's OSPF header. 2452 The data structure associated with the receiving interface 2453 contains the list of active neighbors. Packets not matching any 2454 active neighbor are discarded. 2456 At this point all received protocol packets are associated with 2457 an active neighbor. For the further input processing of 2458 specific packet types, consult the sections listed in Table 11. 2460 Type Packet name detailed section (receive) 2461 ________________________________________________________ 2462 1 Hello Section 10.5 2463 2 Database description Section 10.6 2464 3 Link state request Section 10.7 2465 4 Link state update Section 13 2466 5 Link state ack Section 13.7 2468 Table 11: Sections describing OSPF protocol packet reception. 2470 9. The Interface Data Structure 2472 An OSPF interface is the connection between a router and a network. 2473 We assume a single OSPF interface to each attached network/subnet, 2474 although supporting multiple interfaces on a single network is 2475 considered in Appendix F. Each interface structure has at most one 2476 IP interface address. 2478 An OSPF interface can be considered to belong to the area that 2479 contains the attached network. All routing protocol packets 2480 originated by the router over this interface are labelled with the 2481 interface's Area ID. One or more router adjacencies may develop 2482 over an interface. A router's LSAs reflect the state of its 2483 interfaces and their associated adjacencies. 2485 The following data items are associated with an interface. Note 2486 that a number of these items are actually configuration for the 2487 attached network; such items must be the same for all routers 2488 connected to the network. 2490 Type 2491 The OSPF interface type is either point-to-point, broadcast, 2492 NBMA, Point-to-MultiPoint or virtual link. 2494 State 2495 The functional level of an interface. State determines whether 2496 or not full adjacencies are allowed to form over the interface. 2497 State is also reflected in the router's LSAs. 2499 IP interface address 2500 The IP address associated with the interface. This appears as 2501 the IP source address in all routing protocol packets originated 2502 over this interface. Interfaces to unnumbered point-to-point 2503 networks do not have an associated IP address. 2505 IP interface mask 2506 Also referred to as the subnet mask, this indicates the portion 2507 of the IP interface address that identifies the attached 2508 network. Masking the IP interface address with the IP interface 2509 mask yields the IP network number of the attached network. On 2510 point-to-point networks and virtual links, the IP interface mask 2511 is not defined. On these networks, the link itself is not 2512 assigned an IP network number, and so the addresses of each side 2513 of the link are assigned independently, if they are assigned at 2514 all. 2516 Area ID 2517 The Area ID of the area to which the attached network belongs. 2518 All routing protocol packets originating from the interface are 2519 labelled with this Area ID. 2521 HelloInterval 2522 The length of time, in seconds, between the Hello packets that 2523 the router sends on the interface. Advertised in Hello packets 2524 sent out this interface. 2526 RouterDeadInterval 2527 The number of seconds before the router's neighbors will declare 2528 it down, when they stop hearing the router's Hello Packets. 2529 Advertised in Hello packets sent out this interface. 2531 InfTransDelay 2532 The estimated number of seconds it takes to transmit a Link 2533 State Update Packet over this interface. LSAs contained in the 2534 Link State Update packet will have their age incremented by this 2535 amount before transmission. This value should take into account 2536 transmission and propagation delays; it must be greater than 2537 zero. 2539 Router Priority 2540 An 8-bit unsigned integer. When two routers attached to a 2541 network both attempt to become Designated Router, the one with 2542 the highest Router Priority takes precedence. A router whose 2543 Router Priority is set to 0 is ineligible to become Designated 2544 Router on the attached network. Advertised in Hello packets 2545 sent out this interface. 2547 Hello Timer 2548 An interval timer that causes the interface to send a Hello 2549 packet. This timer fires every HelloInterval seconds. Note 2550 that on non-broadcast networks a separate Hello packet is sent 2551 to each qualified neighbor. 2553 Wait Timer 2554 A single shot timer that causes the interface to exit the 2555 Waiting state, and as a consequence select a Designated Router 2556 on the network. The length of the timer is RouterDeadInterval 2557 seconds. 2559 List of neighboring routers 2560 The other routers attached to this network. This list is formed 2561 by the Hello Protocol. Adjacencies will be formed to some of 2562 these neighbors. The set of adjacent neighbors can be 2563 determined by an examination of all of the neighbors' states. 2565 Designated Router 2566 The Designated Router selected for the attached network. The 2567 Designated Router is selected on all broadcast and NBMA networks 2568 by the Hello Protocol. Two pieces of identification are kept 2569 for the Designated Router: its Router ID and its IP interface 2570 address on the network. The Designated Router advertises link 2571 state for the network; this network-LSA is labelled with the 2572 Designated Router's IP address. The Designated Router is 2573 initialized to 0.0.0.0, which indicates the lack of a Designated 2574 Router. 2576 Backup Designated Router 2577 The Backup Designated Router is also selected on all broadcast 2578 and NBMA networks by the Hello Protocol. All routers on the 2579 attached network become adjacent to both the Designated Router 2580 and the Backup Designated Router. The Backup Designated Router 2581 becomes Designated Router when the current Designated Router 2582 fails. The Backup Designated Router is initialized to 0.0.0.0, 2583 indicating the lack of a Backup Designated Router. 2585 Interface output cost(s) 2586 The cost of sending a data packet on the interface, expressed in 2587 the link state metric. This is advertised as the link cost for 2588 this interface in the router-LSA. The cost of an interface must 2589 be greater than zero. 2591 RxmtInterval 2592 The number of seconds between LSA retransmissions, for 2593 adjacencies belonging to this interface. Also used when 2594 retransmitting Database Description and Link State Request 2595 Packets. 2597 AuType 2598 The type of authentication used on the attached network/subnet. 2599 Authentication types are defined in Appendix D. All OSPF packet 2600 exchanges are authenticated. Different authentication schemes 2601 may be used on different networks/subnets. 2603 Authentication key 2604 This configured data allows the authentication procedure to 2605 generate and/or verify OSPF protocol packets. The 2606 Authentication key can be configured on a per-interface basis. 2607 For example, if the AuType indicates simple password, the 2608 Authentication key would be a 64-bit clear password which is 2609 inserted into the OSPF packet header. If instead Autype 2610 indicates Cryptographic authentication, then the Authentication 2611 key is a shared secret which enables the generation/verification 2612 of message digests which are appended to the OSPF protocol 2613 packets. When Cryptographic authentication is used, multiple 2614 simultaneous keys are supported in order to achieve smooth key 2615 transition (see Section D.3). 2617 9.1. Interface states 2619 The various states that router interfaces may attain is 2620 documented in this section. The states are listed in order of 2621 progressing functionality. For example, the inoperative state 2622 is listed first, followed by a list of intermediate states 2623 before the final, fully functional state is achieved. The 2624 specification makes use of this ordering by sometimes making 2625 references such as "those interfaces in state greater than X". 2626 Figure 11 shows the graph of interface state changes. The arcs 2627 of the graph are labelled with the event causing the state 2628 change. These events are documented in Section 9.2. The 2629 interface state machine is described in more detail in Section 2630 9.3. 2632 Down 2633 This is the initial interface state. In this state, the 2634 lower-level protocols have indicated that the interface is 2635 unusable. No protocol traffic at all will be sent or 2636 received on such a interface. In this state, interface 2637 parameters should be set to their initial values. All 2639 +----+ UnloopInd +--------+ 2640 |Down|<--------------|Loopback| 2641 +----+ +--------+ 2642 | 2643 |InterfaceUp 2644 +-------+ | +--------------+ 2645 |Waiting|<-+-------------->|Point-to-point| 2646 +-------+ +--------------+ 2647 | 2648 WaitTimer|BackupSeen 2649 | 2650 | 2651 | NeighborChange 2652 +------+ +-+<---------------- +-------+ 2653 |Backup|<----------|?|----------------->|DROther| 2654 +------+---------->+-+<-----+ +-------+ 2655 Neighbor | | 2656 Change | |Neighbor 2657 | |Change 2658 | +--+ 2659 +---->|DR| 2660 +--+ 2662 Figure 11: Interface State changes 2664 In addition to the state transitions pictured, 2665 Event InterfaceDown always forces Down State, and 2666 Event LoopInd always forces Loopback State 2667 interface timers should be disabled, and there should be no 2668 adjacencies associated with the interface. 2670 Loopback 2671 In this state, the router's interface to the network is 2672 looped back. The interface may be looped back in hardware 2673 or software. The interface will be unavailable for regular 2674 data traffic. However, it may still be desirable to gain 2675 information on the quality of this interface, either through 2676 sending ICMP pings to the interface or through something 2677 like a bit error test. For this reason, IP packets may 2678 still be addressed to an interface in Loopback state. To 2679 facilitate this, such interfaces are advertised in router- 2680 LSAs as single host routes, whose destination is the IP 2681 interface address.[4] 2683 Waiting 2684 In this state, the router is trying to determine the 2685 identity of the (Backup) Designated Router for the network. 2686 To do this, the router monitors the Hello Packets it 2687 receives. The router is not allowed to elect a Backup 2688 Designated Router nor a Designated Router until it 2689 transitions out of Waiting state. This prevents unnecessary 2690 changes of (Backup) Designated Router. 2692 Point-to-point 2693 In this state, the interface is operational, and connects 2694 either to a physical point-to-point network or to a virtual 2695 link. Upon entering this state, the router attempts to form 2696 an adjacency with the neighboring router. Hello Packets are 2697 sent to the neighbor every HelloInterval seconds. 2699 DR Other 2700 The interface is to a broadcast or NBMA network on which 2701 another router has been selected to be the Designated 2702 Router. In this state, the router itself has not been 2703 selected Backup Designated Router either. The router forms 2704 adjacencies to both the Designated Router and the Backup 2705 Designated Router (if they exist). 2707 Backup 2708 In this state, the router itself is the Backup Designated 2709 Router on the attached network. It will be promoted to 2710 Designated Router when the present Designated Router fails. 2711 The router establishes adjacencies to all other routers 2712 attached to the network. The Backup Designated Router 2713 performs slightly different functions during the Flooding 2714 Procedure, as compared to the Designated Router (see Section 2715 13.3). See Section 7.4 for more details on the functions 2716 performed by the Backup Designated Router. 2718 DR In this state, this router itself is the Designated Router 2719 on the attached network. Adjacencies are established to all 2720 other routers attached to the network. The router must also 2721 originate a network-LSA for the network node. The network- 2722 LSA will contain links to all routers (including the 2723 Designated Router itself) attached to the network. See 2724 Section 7.3 for more details on the functions performed by 2725 the Designated Router. 2727 9.2. Events causing interface state changes 2729 State changes can be effected by a number of events. These 2730 events are pictured as the labelled arcs in Figure 11. The 2731 label definitions are listed below. For a detailed explanation 2732 of the effect of these events on OSPF protocol operation, 2733 consult Section 9.3. 2735 InterfaceUp 2736 Lower-level protocols have indicated that the network 2737 interface is operational. This enables the interface to 2738 transition out of Down state. On virtual links, the 2739 interface operational indication is actually a result of the 2740 shortest path calculation (see Section 16.7). 2742 WaitTimer 2743 The Wait Timer has fired, indicating the end of the waiting 2744 period that is required before electing a (Backup) 2745 Designated Router. 2747 BackupSeen 2748 The router has detected the existence or non-existence of a 2749 Backup Designated Router for the network. This is done in 2750 one of two ways. First, an Hello Packet may be received 2751 from a neighbor claiming to be itself the Backup Designated 2752 Router. Alternatively, an Hello Packet may be received from 2753 a neighbor claiming to be itself the Designated Router, and 2754 indicating that there is no Backup Designated Router. In 2755 either case there must be bidirectional communication with 2756 the neighbor, i.e., the router must also appear in the 2757 neighbor's Hello Packet. This event signals an end to the 2758 Waiting state. 2760 NeighborChange 2761 There has been a change in the set of bidirectional 2762 neighbors associated with the interface. The (Backup) 2763 Designated Router needs to be recalculated. The following 2764 neighbor changes lead to the NeighborChange event. For an 2765 explanation of neighbor states, see Section 10.1. 2767 o Bidirectional communication has been established to a 2768 neighbor. In other words, the state of the neighbor has 2769 transitioned to 2-Way or higher. 2771 o There is no longer bidirectional communication with a 2772 neighbor. In other words, the state of the neighbor has 2773 transitioned to Init or lower. 2775 o One of the bidirectional neighbors is newly declaring 2776 itself as either Designated Router or Backup Designated 2777 Router. This is detected through examination of that 2778 neighbor's Hello Packets. 2780 o One of the bidirectional neighbors is no longer 2781 declaring itself as Designated Router, or is no longer 2782 declaring itself as Backup Designated Router. This is 2783 again detected through examination of that neighbor's 2784 Hello Packets. 2786 o The advertised Router Priority for a bidirectional 2787 neighbor has changed. This is again detected through 2788 examination of that neighbor's Hello Packets. 2790 LoopInd 2791 An indication has been received that the interface is now 2792 looped back to itself. This indication can be received 2793 either from network management or from the lower level 2794 protocols. 2796 UnloopInd 2797 An indication has been received that the interface is no 2798 longer looped back. As with the LoopInd event, this 2799 indication can be received either from network management or 2800 from the lower level protocols. 2802 InterfaceDown 2803 Lower-level protocols indicate that this interface is no 2804 longer functional. No matter what the current interface 2805 state is, the new interface state will be Down. 2807 9.3. The Interface state machine 2809 A detailed description of the interface state changes follows. 2810 Each state change is invoked by an event (Section 9.2). This 2811 event may produce different effects, depending on the current 2812 state of the interface. For this reason, the state machine 2813 below is organized by current interface state and received 2814 event. Each entry in the state machine describes the resulting 2815 new interface state and the required set of additional actions. 2817 When an interface's state changes, it may be necessary to 2818 originate a new router-LSA. See Section 12.4 for more details. 2820 Some of the required actions below involve generating events for 2821 the neighbor state machine. For example, when an interface 2822 becomes inoperative, all neighbor connections associated with 2823 the interface must be destroyed. For more information on the 2824 neighbor state machine, see Section 10.3. 2826 State(s): Down 2828 Event: InterfaceUp 2830 New state: Depends upon action routine 2832 Action: Start the interval Hello Timer, enabling the 2833 periodic sending of Hello packets out the interface. 2834 If the attached network is a physical point-to-point 2835 network, Point-to-MultiPoint network or virtual 2836 link, the interface state transitions to Point-to- 2837 Point. Else, if the router is not eligible to 2838 become Designated Router the interface state 2839 transitions to DR Other. 2841 Otherwise, the attached network is a broadcast or 2842 NBMA network and the router is eligible to become 2843 Designated Router. In this case, in an attempt to 2844 discover the attached network's Designated Router 2845 the interface state is set to Waiting and the single 2846 shot Wait Timer is started. Additionally, if the 2847 network is an NBMA network examine the configured 2848 list of neighbors for this interface and generate 2849 the neighbor event Start for each neighbor that is 2850 also eligible to become Designated Router. 2852 State(s): Waiting 2854 Event: BackupSeen 2856 New state: Depends upon action routine. 2858 Action: Calculate the attached network's Backup Designated 2859 Router and Designated Router, as shown in Section 2860 9.4. As a result of this calculation, the new state 2861 of the interface will be either DR Other, Backup or 2862 DR. 2864 State(s): Waiting 2866 Event: WaitTimer 2868 New state: Depends upon action routine. 2870 Action: Calculate the attached network's Backup Designated 2871 Router and Designated Router, as shown in Section 2872 9.4. As a result of this calculation, the new state 2873 of the interface will be either DR Other, Backup or 2874 DR. 2876 State(s): DR Other, Backup or DR 2878 Event: NeighborChange 2880 New state: Depends upon action routine. 2882 Action: Recalculate the attached network's Backup Designated 2883 Router and Designated Router, as shown in Section 2884 9.4. As a result of this calculation, the new state 2885 of the interface will be either DR Other, Backup or 2886 DR. 2888 State(s): Any State 2890 Event: InterfaceDown 2892 New state: Down 2894 Action: All interface variables are reset, and interface 2895 timers disabled. Also, all neighbor connections 2896 associated with the interface are destroyed. This 2897 is done by generating the event KillNbr on all 2898 associated neighbors (see Section 10.2). 2900 State(s): Any State 2902 Event: LoopInd 2904 New state: Loopback 2906 Action: Since this interface is no longer connected to the 2907 attached network the actions associated with the 2908 above InterfaceDown event are executed. 2910 State(s): Loopback 2912 Event: UnloopInd 2914 New state: Down 2916 Action: No actions are necessary. For example, the 2917 interface variables have already been reset upon 2918 entering the Loopback state. Note that reception of 2919 an InterfaceUp event is necessary before the 2920 interface again becomes fully functional. 2922 9.4. Electing the Designated Router 2924 This section describes the algorithm used for calculating a 2925 network's Designated Router and Backup Designated Router. This 2926 algorithm is invoked by the Interface state machine. The 2927 initial time a router runs the election algorithm for a network, 2928 the network's Designated Router and Backup Designated Router are 2929 initialized to 0.0.0.0. This indicates the lack of both a 2930 Designated Router and a Backup Designated Router. 2932 The Designated Router election algorithm proceeds as follows: 2933 Call the router doing the calculation Router X. The list of 2934 neighbors attached to the network and having established 2935 bidirectional communication with Router X is examined. This 2936 list is precisely the collection of Router X's neighbors (on 2937 this network) whose state is greater than or equal to 2-Way (see 2938 Section 10.1). Router X itself is also considered to be on the 2939 list. Discard all routers from the list that are ineligible to 2940 become Designated Router. (Routers having Router Priority of 0 2941 are ineligible to become Designated Router.) The following 2942 steps are then executed, considering only those routers that 2943 remain on the list: 2945 (1) Note the current values for the network's Designated Router 2946 and Backup Designated Router. This is used later for 2947 comparison purposes. 2949 (2) Calculate the new Backup Designated Router for the network 2950 as follows. Only those routers on the list that have not 2951 declared themselves to be Designated Router are eligible to 2952 become Backup Designated Router. If one or more of these 2953 routers have declared themselves Backup Designated Router 2954 (i.e., they are currently listing themselves as Backup 2955 Designated Router, but not as Designated Router, in their 2956 Hello Packets) the one having highest Router Priority is 2957 declared to be Backup Designated Router. In case of a tie, 2958 the one having the highest Router ID is chosen. If no 2959 routers have declared themselves Backup Designated Router, 2960 choose the router having highest Router Priority, (again 2961 excluding those routers who have declared themselves 2962 Designated Router), and again use the Router ID to break 2963 ties. 2965 (3) Calculate the new Designated Router for the network as 2966 follows. If one or more of the routers have declared 2967 themselves Designated Router (i.e., they are currently 2968 listing themselves as Designated Router in their Hello 2969 Packets) the one having highest Router Priority is declared 2970 to be Designated Router. In case of a tie, the one having 2971 the highest Router ID is chosen. If no routers have 2972 declared themselves Designated Router, assign the Designated 2973 Router to be the same as the newly elected Backup Designated 2974 Router. 2976 (4) If Router X is now newly the Designated Router or newly the 2977 Backup Designated Router, or is now no longer the Designated 2978 Router or no longer the Backup Designated Router, repeat 2979 steps 2 and 3, and then proceed to step 5. For example, if 2980 Router X is now the Designated Router, when step 2 is 2981 repeated X will no longer be eligible for Backup Designated 2982 Router election. Among other things, this will ensure that 2983 no router will declare itself both Backup Designated Router 2984 and Designated Router.[5] 2986 (5) As a result of these calculations, the router itself may now 2987 be Designated Router or Backup Designated Router. See 2988 Sections 7.3 and 7.4 for the additional duties this would 2989 entail. The router's interface state should be set 2990 accordingly. If the router itself is now Designated Router, 2991 the new interface state is DR. If the router itself is now 2992 Backup Designated Router, the new interface state is Backup. 2993 Otherwise, the new interface state is DR Other. 2995 (6) If the attached network is an NBMA network, and the router 2996 itself has just become either Designated Router or Backup 2997 Designated Router, it must start sending Hello Packets to 2998 those neighbors that are not eligible to become Designated 2999 Router (see Section 9.5.1). This is done by invoking the 3000 neighbor event Start for each neighbor having a Router 3001 Priority of 0. 3003 (7) If the above calculations have caused the identity of either 3004 the Designated Router or Backup Designated Router to change, 3005 the set of adjacencies associated with this interface will 3006 need to be modified. Some adjacencies may need to be 3007 formed, and others may need to be broken. To accomplish 3008 this, invoke the event AdjOK? on all neighbors whose state 3009 is at least 2-Way. This will cause their eligibility for 3010 adjacency to be reexamined (see Sections 10.3 and 10.4). 3012 The reason behind the election algorithm's complexity is the 3013 desire for an orderly transition from Backup Designated Router 3014 to Designated Router, when the current Designated Router fails. 3015 This orderly transition is ensured through the introduction of 3016 hysteresis: no new Backup Designated Router can be chosen until 3017 the old Backup accepts its new Designated Router 3018 responsibilities. 3020 The above procedure may elect the same router to be both 3021 Designated Router and Backup Designated Router, although that 3022 router will never be the calculating router (Router X) itself. 3023 The elected Designated Router may not be the router having the 3024 highest Router Priority, nor will the Backup Designated Router 3025 necessarily have the second highest Router Priority. If Router 3026 X is not itself eligible to become Designated Router, it is 3027 possible that neither a Backup Designated Router nor a 3028 Designated Router will be selected in the above procedure. Note 3029 also that if Router X is the only attached router that is 3030 eligible to become Designated Router, it will select itself as 3031 Designated Router and there will be no Backup Designated Router 3032 for the network. 3034 9.5. Sending Hello packets 3036 Hello packets are sent out each functioning router interface. 3037 They are used to discover and maintain neighbor 3038 relationships.[6] On broadcast and NBMA networks, Hello Packets 3039 are also used to elect the Designated Router and Backup 3040 Designated Router. 3042 The format of an Hello packet is detailed in Section A.3.2. The 3043 Hello Packet contains the router's Router Priority (used in 3044 choosing the Designated Router), and the interval between Hello 3045 Packets sent out the interface (HelloInterval). The Hello 3046 Packet also indicates how often a neighbor must be heard from to 3047 remain active (RouterDeadInterval). Both HelloInterval and 3048 RouterDeadInterval must be the same for all routers attached to 3049 a common network. The Hello packet also contains the IP address 3050 mask of the attached network (Network Mask). On unnumbered 3051 point-to-point networks and on virtual links this field should 3052 be set to 0.0.0.0. 3054 The Hello packet's Options field describes the router's optional 3055 OSPF capabilities. One optional capability is defined in this 3056 specification (see Sections 4.5 and A.2). The E-bit of the 3057 Options field should be set if and only if the attached area is 3058 capable of processing AS-external-LSAs (i.e., it is not a stub 3059 area). If the E-bit is set incorrectly the neighboring routers 3060 will refuse to accept the Hello Packet (see Section 10.5). 3061 Unrecognized bits in the Hello Packet's Options field should be 3062 set to zero. 3064 In order to ensure two-way communication between adjacent 3065 routers, the Hello packet contains the list of all routers on 3066 the network from which Hello Packets have been seen recently. 3067 The Hello packet also contains the router's current choice for 3068 Designated Router and Backup Designated Router. A value of 3069 0.0.0.0 in these fields means that one has not yet been 3070 selected. 3072 On broadcast networks and physical point-to-point networks, 3073 Hello packets are sent every HelloInterval seconds to the IP 3074 multicast address AllSPFRouters. On virtual links, Hello 3075 packets are sent as unicasts (addressed directly to the other 3076 end of the virtual link) every HelloInterval seconds. On Point- 3077 to-MultiPoint networks, separate Hello packets are sent to each 3078 attached neighbor every HelloInterval seconds. Sending of Hello 3079 packets on NBMA networks is covered in the next section. 3081 9.5.1. Sending Hello packets on NBMA networks 3083 Static configuration information may be necessary in order 3084 for the Hello Protocol to function on non-broadcast networks 3085 (see Sections C.5 and C.6). On NBMA networks, every 3086 attached router which is eligible to become Designated 3087 Router becomes aware of all of its neighbors on the network 3088 (either through configuration or by some unspecified 3089 mechanism). Each neighbor is labelled with the neighbor's 3090 Designated Router eligibility. 3092 The interface state must be at least Waiting for any Hello 3093 Packets to be sent out the NBMA interface. Hello Packets 3094 are then sent directly (as unicasts) to some subset of a 3095 router's neighbors. Sometimes an Hello Packet is sent 3096 periodically on a timer; at other times it is sent as a 3097 response to a received Hello Packet. A router's hello- 3098 sending behavior varies depending on whether the router 3099 itself is eligible to become Designated Router. 3101 If the router is eligible to become Designated Router, it 3102 must periodically send Hello Packets to all neighbors that 3103 are also eligible. In addition, if the router is itself the 3104 Designated Router or Backup Designated Router, it must also 3105 send periodic Hello Packets to all other neighbors. This 3106 means that any two eligible routers are always exchanging 3107 Hello Packets, which is necessary for the correct operation 3108 of the Designated Router election algorithm. To minimize 3109 the number of Hello Packets sent, the number of eligible 3110 routers on an NBMA network should be kept small. 3112 If the router is not eligible to become Designated Router, 3113 it must periodically send Hello Packets to both the 3114 Designated Router and the Backup Designated Router (if they 3115 exist). It must also send an Hello Packet in reply to an 3116 Hello Packet received from any eligible neighbor (other than 3117 the current Designated Router and Backup Designated Router). 3118 This is needed to establish an initial bidirectional 3119 relationship with any potential Designated Router. 3121 When sending Hello packets periodically to any neighbor, the 3122 interval between Hello Packets is determined by the 3123 neighbor's state. If the neighbor is in state Down, Hello 3124 Packets are sent every PollInterval seconds. Otherwise, 3125 Hello Packets are sent every HelloInterval seconds. 3127 10. The Neighbor Data Structure 3129 An OSPF router converses with its neighboring routers. Each 3130 separate conversation is described by a "neighbor data structure". 3131 Each conversation is bound to a particular OSPF router interface, 3132 and is identified either by the neighboring router's OSPF Router ID 3133 or by its Neighbor IP address (see below). Thus if the OSPF router 3134 and another router have multiple attached networks in common, 3135 multiple conversations ensue, each described by a unique neighbor 3136 data structure. Each separate conversation is loosely referred to 3137 in the text as being a separate "neighbor". 3139 The neighbor data structure contains all information pertinent to 3140 the forming or formed adjacency between the two neighbors. 3141 (However, remember that not all neighbors become adjacent.) An 3142 adjacency can be viewed as a highly developed conversation between 3143 two routers. 3145 State 3146 The functional level of the neighbor conversation. This is 3147 described in more detail in Section 10.1. 3149 Inactivity Timer 3150 A single shot timer whose firing indicates that no Hello Packet 3151 has been seen from this neighbor recently. The length of the 3152 timer is RouterDeadInterval seconds. 3154 Master/Slave 3155 When the two neighbors are exchanging databases, they form a 3156 master/slave relationship. The master sends the first Database 3157 Description Packet, and is the only part that is allowed to 3158 retransmit. The slave can only respond to the master's Database 3159 Description Packets. The master/slave relationship is 3160 negotiated in state ExStart. 3162 DD Sequence Number 3163 The DD Sequence number of the Database Description packet that 3164 is currently being sent to the neighbor. 3166 Last received Database Description packet 3167 The initialize(I), more (M) and master(MS) bits, Options field, 3168 and DD sequence number contained in the last Database 3169 Description packet received from the neighbor. Used to determine 3170 whether the next Database Description packet received from the 3171 neighbor is a duplicate. 3173 Neighbor ID 3174 The OSPF Router ID of the neighboring router. The Neighbor ID 3175 is learned when Hello packets are received from the neighbor, or 3176 is configured if this is a virtual adjacency (see Section C.4). 3178 Neighbor Priority 3179 The Router Priority of the neighboring router. Contained in the 3180 neighbor's Hello packets, this item is used when selecting the 3181 Designated Router for the attached network. 3183 Neighbor IP address 3184 The IP address of the neighboring router's interface to the 3185 attached network. Used as the Destination IP address when 3186 protocol packets are sent as unicasts along this adjacency. 3187 Also used in router-LSAs as the Link ID for the attached network 3188 if the neighboring router is selected to be Designated Router 3189 (see Section 12.4.1). The Neighbor IP address is learned when 3190 Hello packets are received from the neighbor. For virtual 3191 links, the Neighbor IP address is learned during the routing 3192 table build process (see Section 15). 3194 Neighbor Options 3195 The optional OSPF capabilities supported by the neighbor. 3196 Learned during the Database Exchange process (see Section 10.6). 3197 The neighbor's optional OSPF capabilities are also listed in its 3198 Hello packets. This enables received Hello Packets to be 3199 rejected (i.e., neighbor relationships will not even start to 3200 form) if there is a mismatch in certain crucial OSPF 3201 capabilities (see Section 10.5). The optional OSPF capabilities 3202 are documented in Section 4.5. 3204 Neighbor's Designated Router 3205 The neighbor's idea of the Designated Router. If this is the 3206 neighbor itself, this is important in the local calculation of 3207 the Designated Router. Defined only on broadcast and NBMA 3208 networks. 3210 Neighbor's Backup Designated Router 3211 The neighbor's idea of the Backup Designated Router. If this is 3212 the neighbor itself, this is important in the local calculation 3213 of the Backup Designated Router. Defined only on broadcast and 3214 NBMA networks. 3216 The next set of variables are lists of LSAs. These lists describe 3217 subsets of the area link-state database. This memo defines five 3218 distinct types of LSAs, all of which may be present in an area 3219 link-state database: router-LSAs, network-LSAs, and Type 3 and 4 3220 summary-LSAs (all stored in the area data structure), and AS- 3221 external-LSAs (stored in the global data structure). 3223 Link state retransmission list 3224 The list of LSAs that have been flooded but not acknowledged on 3225 this adjacency. These will be retransmitted at intervals until 3226 they are acknowledged, or until the adjacency is destroyed. 3228 Database summary list 3229 The complete list of LSAs that make up the area link-state 3230 database, at the moment the neighbor goes into Database Exchange 3231 state. This list is sent to the neighbor in Database 3232 Description packets. 3234 Link state request list 3235 The list of LSAs that need to be received from this neighbor in 3236 order to synchronize the two neighbors' link-state databases. 3237 This list is created as Database Description packets are 3238 received, and is then sent to the neighbor in Link State Request 3239 packets. The list is depleted as appropriate Link State Update 3240 packets are received. 3242 10.1. Neighbor states 3244 The state of a neighbor (really, the state of a conversation 3245 being held with a neighboring router) is documented in the 3246 following sections. The states are listed in order of 3247 progressing functionality. For example, the inoperative state 3248 is listed first, followed by a list of intermediate states 3249 before the final, fully functional state is achieved. The 3250 specification makes use of this ordering by sometimes making 3251 references such as "those neighbors/adjacencies in state greater 3252 than X". Figures 12 and 13 show the graph of neighbor state 3253 changes. The arcs of the graphs are labelled with the event 3254 causing the state change. The neighbor events are documented in 3255 Section 10.2. 3257 The graph in Figure 12 shows the state changes effected by the 3258 Hello Protocol. The Hello Protocol is responsible for neighbor 3259 acquisition and maintenance, and for ensuring two way 3260 communication between neighbors. 3262 The graph in Figure 13 shows the forming of an adjacency. Not 3263 every two neighboring routers become adjacent (see Section 3264 10.4). The adjacency starts to form when the neighbor is in 3265 state ExStart. After the two routers discover their 3266 +----+ 3267 |Down| 3268 +----+ 3269 |\ 3270 | \Start 3271 | \ +-------+ 3272 Hello | +---->|Attempt| 3273 Received | +-------+ 3274 | | 3275 +----+<-+ |HelloReceived 3276 |Init|<---------------+ 3277 +----+<--------+ 3278 | | 3279 |2-Way |1-Way 3280 |Received |Received 3281 | | 3282 +-------+ | +-----+ 3283 |ExStart|<--------+------->|2-Way| 3284 +-------+ +-----+ 3286 Figure 12: Neighbor state changes (Hello Protocol) 3288 In addition to the state transitions pictured, 3289 Event KillNbr always forces Down State, 3290 Event InactivityTimer always forces Down State, 3291 Event LLDown always forces Down State 3292 +-------+ 3293 |ExStart| 3294 +-------+ 3295 | 3296 NegotiationDone| 3297 +->+--------+ 3298 |Exchange| 3299 +--+--------+ 3300 | 3301 Exchange| 3302 Done | 3303 +----+ | +-------+ 3304 |Full|<---------+----->|Loading| 3305 +----+<-+ +-------+ 3306 | LoadingDone | 3307 +------------------+ 3309 Figure 13: Neighbor state changes (Database Exchange) 3311 In addition to the state transitions pictured, 3312 Event SeqNumberMismatch forces ExStart state, 3313 Event BadLSReq forces ExStart state, 3314 Event 1-Way forces Init state, 3315 Event KillNbr always forces Down State, 3316 Event InactivityTimer always forces Down State, 3317 Event LLDown always forces Down State, 3318 Event AdjOK? leads to adjacency forming/breaking 3320 master/slave status, the state transitions to Exchange. At this 3321 point the neighbor starts to be used in the flooding procedure, 3322 and the two neighboring routers begin synchronizing their 3323 databases. When this synchronization is finished, the neighbor 3324 is in state Full and we say that the two routers are fully 3325 adjacent. At this point the adjacency is listed in LSAs. 3327 For a more detailed description of neighbor state changes, 3328 together with the additional actions involved in each change, 3329 see Section 10.3. 3331 Down 3332 This is the initial state of a neighbor conversation. It 3333 indicates that there has been no recent information received 3334 from the neighbor. On NBMA networks, Hello packets may 3335 still be sent to "Down" neighbors, although at a reduced 3336 frequency (see Section 9.5.1). 3338 Attempt 3339 This state is only valid for neighbors attached to NBMA 3340 networks. It indicates that no recent information has been 3341 received from the neighbor, but that a more concerted effort 3342 should be made to contact the neighbor. This is done by 3343 sending the neighbor Hello packets at intervals of 3344 HelloInterval (see Section 9.5.1). 3346 Init 3347 In this state, an Hello packet has recently been seen from 3348 the neighbor. However, bidirectional communication has not 3349 yet been established with the neighbor (i.e., the router 3350 itself did not appear in the neighbor's Hello packet). All 3351 neighbors in this state (or higher) are listed in the Hello 3352 packets sent from the associated interface. 3354 2-Way 3355 In this state, communication between the two routers is 3356 bidirectional. This has been assured by the operation of 3357 the Hello Protocol. This is the most advanced state short 3358 of beginning adjacency establishment. The (Backup) 3359 Designated Router is selected from the set of neighbors in 3360 state 2-Way or greater. 3362 ExStart 3363 This is the first step in creating an adjacency between the 3364 two neighboring routers. The goal of this step is to decide 3365 which router is the master, and to decide upon the initial 3366 DD sequence number. Neighbor conversations in this state or 3367 greater are called adjacencies. 3369 Exchange 3370 In this state the router is describing its entire link state 3371 database by sending Database Description packets to the 3372 neighbor. Each Database Description Packet has a DD 3373 sequence number, and is explicitly acknowledged. Only one 3374 Database Description Packet is allowed outstanding at any 3375 one time. In this state, Link State Request Packets may 3376 also be sent asking for the neighbor's more recent LSAs. 3377 All adjacencies in Exchange state or greater are used by the 3378 flooding procedure. In fact, these adjacencies are fully 3379 capable of transmitting and receiving all types of OSPF 3380 routing protocol packets. 3382 Loading 3383 In this state, Link State Request packets are sent to the 3384 neighbor asking for the more recent LSAs that have been 3385 discovered (but not yet received) in the Exchange state. 3387 Full 3388 In this state, the neighboring routers are fully adjacent. 3389 These adjacencies will now appear in router-LSAs and 3390 network-LSAs. 3392 10.2. Events causing neighbor state changes 3394 State changes can be effected by a number of events. These 3395 events are shown in the labels of the arcs in Figures 12 and 13. 3396 The label definitions are as follows: 3398 HelloReceived 3399 An Hello packet has been received from the neighbor. 3401 Start 3402 This is an indication that Hello Packets should now be sent 3403 to the neighbor at intervals of HelloInterval seconds. This 3404 event is generated only for neighbors associated with NBMA 3405 networks. 3407 2-WayReceived 3408 Bidirectional communication has been realized between the 3409 two neighboring routers. This is indicated by the router 3410 seeing itself in the neighbor's Hello packet. 3412 NegotiationDone 3413 The Master/Slave relationship has been negotiated, and DD 3414 sequence numbers have been exchanged. This signals the 3415 start of the sending/receiving of Database Description 3416 packets. For more information on the generation of this 3417 event, consult Section 10.8. 3419 ExchangeDone 3420 Both routers have successfully transmitted a full sequence 3421 of Database Description packets. Each router now knows what 3422 parts of its link state database are out of date. For more 3423 information on the generation of this event, consult Section 3424 10.8. 3426 BadLSReq 3427 A Link State Request has been received for an LSA not 3428 contained in the database. This indicates an error in the 3429 Database Exchange process. 3431 Loading Done 3432 Link State Updates have been received for all out-of-date 3433 portions of the database. This is indicated by the Link 3434 state request list becoming empty after the Database 3435 Exchange process has completed. 3437 AdjOK? 3438 A decision must be made as to whether an adjacency should be 3439 established/maintained with the neighbor. This event will 3440 start some adjacencies forming, and destroy others. 3442 The following events cause well developed neighbors to revert to 3443 lesser states. Unlike the above events, these events may occur 3444 when the neighbor conversation is in any of a number of states. 3446 SeqNumberMismatch 3447 A Database Description packet has been received that either 3448 a) has an unexpected DD sequence number, b) unexpectedly has 3449 the Init bit set or c) has an Options field differing from 3450 the last Options field received in a Database Description 3451 packet. Any of these conditions indicate that some error 3452 has occurred during adjacency establishment. 3454 1-Way 3455 An Hello packet has been received from the neighbor, in 3456 which the router is not mentioned. This indicates that 3457 communication with the neighbor is not bidirectional. 3459 KillNbr 3460 This is an indication that all communication with the 3461 neighbor is now impossible, forcing the neighbor to 3462 revert to Down state. 3464 InactivityTimer 3465 The inactivity Timer has fired. This means that no Hello 3466 packets have been seen recently from the neighbor. The 3467 neighbor reverts to Down state. 3469 LLDown 3470 This is an indication from the lower level protocols that 3471 the neighbor is now unreachable. For example, on an X.25 3472 network this could be indicated by an X.25 clear indication 3473 with appropriate cause and diagnostic fields. This event 3474 forces the neighbor into Down state. 3476 10.3. The Neighbor state machine 3478 A detailed description of the neighbor state changes follows. 3479 Each state change is invoked by an event (Section 10.2). This 3480 event may produce different effects, depending on the current 3481 state of the neighbor. For this reason, the state machine below 3482 is organized by current neighbor state and received event. Each 3483 entry in the state machine describes the resulting new neighbor 3484 state and the required set of additional actions. 3486 When a neighbor's state changes, it may be necessary to rerun 3487 the Designated Router election algorithm. This is determined by 3488 whether the interface NeighborChange event is generated (see 3489 Section 9.2). Also, if the Interface is in DR state (the router 3490 is itself Designated Router), changes in neighbor state may 3491 cause a new network-LSA to be originated (see Section 12.4). 3493 When the neighbor state machine needs to invoke the interface 3494 state machine, it should be done as a scheduled task (see 3495 Section 4.4). This simplifies things, by ensuring that neither 3496 state machine will be executed recursively. 3498 State(s): Down 3500 Event: Start 3502 New state: Attempt 3504 Action: Send an Hello Packet to the neighbor (this neighbor 3505 is always associated with an NBMA network) and start 3506 the Inactivity Timer for the neighbor. The timer's 3507 later firing would indicate that communication with 3508 the neighbor was not attained. 3510 State(s): Attempt 3512 Event: HelloReceived 3514 New state: Init 3516 Action: Restart the Inactivity Timer for the neighbor, since 3517 the neighbor has now been heard from. 3519 State(s): Down 3520 Event: HelloReceived 3522 New state: Init 3524 Action: Start the Inactivity Timer for the neighbor. The 3525 timer's later firing would indicate that the 3526 neighbor is dead. 3528 State(s): Init or greater 3530 Event: HelloReceived 3532 New state: No state change. 3534 Action: Restart the Inactivity Timer for the neighbor, since 3535 the neighbor has again been heard from. 3537 State(s): Init 3539 Event: 2-WayReceived 3541 New state: Depends upon action routine. 3543 Action: Determine whether an adjacency should be established 3544 with the neighbor (see Section 10.4). If not, the 3545 new neighbor state is 2-Way. 3547 Otherwise (an adjacency should be established) the 3548 neighbor state transitions to ExStart. Upon 3549 entering this state, the router increments the DD 3550 sequence number in the neighbor data structure. If 3551 this is the first time that an adjacency has been 3552 attempted, the DD sequence number should be assigned 3553 some unique value (like the time of day clock). It 3554 then declares itself master (sets the master/slave 3555 bit to master), and starts sending Database 3556 Description Packets, with the initialize (I), more 3557 (M) and master (MS) bits set. This Database 3558 Description Packet should be otherwise empty. This 3559 Database Description Packet should be retransmitted 3560 at intervals of RxmtInterval until the next state is 3561 entered (see Section 10.8). 3563 State(s): ExStart 3564 Event: NegotiationDone 3566 New state: Exchange 3568 Action: The router must list the contents of its entire area 3569 link state database in the neighbor Database summary 3570 list. The area link state database consists of the 3571 router-LSAs, network-LSAs and summary-LSAs contained 3572 in the area structure, along with the AS-external- 3573 LSAs contained in the global structure. AS- 3574 external-LSAs are omitted from a virtual neighbor's 3575 Database summary list. AS-external-LSAs are omitted 3576 from the Database summary list if the area has been 3577 configured as a stub (see Section 3.6). LSAs whose 3578 age is equal to MaxAge are instead added to the 3579 neighbor's Link state retransmission list. A 3580 summary of the Database summary list will be sent to 3581 the neighbor in Database Description packets. Each 3582 Database Description Packet has a DD sequence 3583 number, and is explicitly acknowledged. Only one 3584 Database Description Packet is allowed outstanding 3585 at any one time. For more detail on the sending and 3586 receiving of Database Description packets, see 3587 Sections 10.8 and 10.6. 3589 State(s): Exchange 3591 Event: ExchangeDone 3593 New state: Depends upon action routine. 3595 Action: If the neighbor Link state request list is empty, 3596 the new neighbor state is Full. No other action is 3597 required. This is an adjacency's final state. 3599 Otherwise, the new neighbor state is Loading. Start 3600 (or continue) sending Link State Request packets to 3601 the neighbor (see Section 10.9). These are requests 3602 for the neighbor's more recent LSAs (which were 3603 discovered but not yet received in the Exchange 3604 state). These LSAs are listed in the Link state 3605 request list associated with the neighbor. 3607 State(s): Loading 3608 Event: Loading Done 3610 New state: Full 3612 Action: No action required. This is an adjacency's final 3613 state. 3615 State(s): 2-Way 3617 Event: AdjOK? 3619 New state: Depends upon action routine. 3621 Action: Determine whether an adjacency should be formed with 3622 the neighboring router (see Section 10.4). If not, 3623 the neighbor state remains at 2-Way. Otherwise, 3624 transition the neighbor state to ExStart and perform 3625 the actions associated with the above state machine 3626 entry for state Init and event 2-WayReceived. 3628 State(s): ExStart or greater 3630 Event: AdjOK? 3632 New state: Depends upon action routine. 3634 Action: Determine whether the neighboring router should 3635 still be adjacent. If yes, there is no state change 3636 and no further action is necessary. 3638 Otherwise, the (possibly partially formed) adjacency 3639 must be destroyed. The neighbor state transitions 3640 to 2-Way. The Link state retransmission list, 3641 Database summary list and Link state request list 3642 are cleared of LSAs. 3644 State(s): Exchange or greater 3646 Event: SeqNumberMismatch 3648 New state: ExStart 3650 Action: The (possibly partially formed) adjacency is torn 3651 down, and then an attempt is made at 3652 reestablishment. The neighbor state first 3653 transitions to ExStart. The Link state 3654 retransmission list, Database summary list and Link 3655 state request list are cleared of LSAs. Then the 3656 router increments the DD sequence number in the 3657 neighbor data structure, declares itself master 3658 (sets the master/slave bit to master), and starts 3659 sending Database Description Packets, with the 3660 initialize (I), more (M) and master (MS) bits set. 3661 This Database Description Packet should be otherwise 3662 empty (see Section 10.8). 3664 State(s): Exchange or greater 3666 Event: BadLSReq 3668 New state: ExStart 3670 Action: The action for event BadLSReq is exactly the same as 3671 for the neighbor event SeqNumberMismatch. The 3672 (possibly partially formed) adjacency is torn down, 3673 and then an attempt is made at reestablishment. For 3674 more information, see the neighbor state machine 3675 entry that is invoked when event SeqNumberMismatch 3676 is generated in state Exchange or greater. 3678 State(s): Any state 3680 Event: KillNbr 3682 New state: Down 3684 Action: The Link state retransmission list, Database summary 3685 list and Link state request list are cleared of 3686 LSAs. Also, the Inactivity Timer is disabled. 3688 State(s): Any state 3690 Event: LLDown 3692 New state: Down 3694 Action: The Link state retransmission list, Database summary 3695 list and Link state request list are cleared of 3696 LSAs. Also, the Inactivity Timer is disabled. 3698 State(s): Any state 3700 Event: InactivityTimer 3702 New state: Down 3704 Action: The Link state retransmission list, Database summary 3705 list and Link state request list are cleared of 3706 LSAs. 3708 State(s): 2-Way or greater 3710 Event: 1-WayReceived 3712 New state: Init 3714 Action: The Link state retransmission list, Database summary 3715 list and Link state request list are cleared of 3716 LSAs. 3718 State(s): 2-Way or greater 3720 Event: 2-WayReceived 3722 New state: No state change. 3724 Action: No action required. 3726 State(s): Init 3728 Event: 1-WayReceived 3730 New state: No state change. 3732 Action: No action required. 3734 10.4. Whether to become adjacent 3736 Adjacencies are established with some subset of the router's 3737 neighbors. Routers connected by point-to-point networks, 3738 Point-to-MultiPoint networks and virtual links always become 3739 adjacent. On broadcast and NBMA networks, all routers become 3740 adjacent to both the Designated Router and the Backup Designated 3741 Router. 3743 The adjacency-forming decision occurs in two places in the 3744 neighbor state machine. First, when bidirectional communication 3745 is initially established with the neighbor, and secondly, when 3746 the identity of the attached network's (Backup) Designated 3747 Router changes. If the decision is made to not attempt an 3748 adjacency, the state of the neighbor communication stops at 2- 3749 Way. 3751 An adjacency should be established with a bidirectional neighbor 3752 when at least one of the following conditions holds: 3754 o The underlying network type is point-to-point 3756 o The underlying network type is Point-to-MultiPoint 3758 o The underlying network type is virtual link 3760 o The router itself is the Designated Router 3762 o The router itself is the Backup Designated Router 3764 o The neighboring router is the Designated Router 3766 o The neighboring router is the Backup Designated Router 3768 10.5. Receiving Hello Packets 3770 This section explains the detailed processing of a received 3771 Hello Packet. (See Section A.3.2 for the format of Hello 3772 packets.) The generic input processing of OSPF packets will 3773 have checked the validity of the IP header and the OSPF packet 3774 header. Next, the values of the Network Mask, HelloInterval, 3775 and RouterDeadInterval fields in the received Hello packet must 3776 be checked against the values configured for the receiving 3777 interface. Any mismatch causes processing to stop and the 3778 packet to be dropped. In other words, the above fields are 3779 really describing the attached network's configuration. However, 3780 there is one exception to the above rule: on point-to-point 3781 networks and on virtual links, the Network Mask in the received 3782 Hello Packet should be ignored. 3784 The receiving interface attaches to a single OSPF area (this 3785 could be the backbone). The setting of the E-bit found in the 3786 Hello Packet's Options field must match this area's 3787 ExternalRoutingCapability. If AS-external-LSAs are not flooded 3788 into/throughout the area (i.e, the area is a "stub") the E-bit 3789 must be clear in received Hello Packets, otherwise the E-bit 3790 must be set. A mismatch causes processing to stop and the 3791 packet to be dropped. The setting of the rest of the bits in 3792 the Hello Packet's Options field should be ignored. 3794 At this point, an attempt is made to match the source of the 3795 Hello Packet to one of the receiving interface's neighbors. If 3796 the receiving interface connects to a broadcast, Point-to- 3797 MultiPoint or NBMA network the source is identified by the IP 3798 source address found in the Hello's IP header. If the receiving 3799 interface connects to a point-to-point link or a virtual link, 3800 the source is identified by the Router ID found in the Hello's 3801 OSPF packet header. The interface's current list of neighbors 3802 is contained in the interface's data structure. If a matching 3803 neighbor structure cannot be found, (i.e., this is the first 3804 time the neighbor has been detected), one is created. The 3805 initial state of a newly created neighbor is set to Down. 3807 When receiving an Hello Packet from a neighbor on a broadcast, 3808 Point-to-MultiPoint or NBMA network, set the neighbor 3809 structure's Neighbor ID equal to the Router ID found in the 3810 packet's OSPF header. When receiving an Hello on a point-to- 3811 point network (but not on a virtual link) set the neighbor 3812 structure's Neighbor IP address to the packet's IP source 3813 address. 3815 Now the rest of the Hello Packet is examined, generating events 3816 to be given to the neighbor and interface state machines. These 3817 state machines are specified either to be executed or scheduled 3818 (see Section 4.4). For example, by specifying below that the 3819 neighbor state machine be executed in line, several neighbor 3820 state transitions may be effected by a single received Hello: 3822 o Each Hello Packet causes the neighbor state machine to be 3823 executed with the event HelloReceived. 3825 o Then the list of neighbors contained in the Hello Packet is 3826 examined. If the router itself appears in this list, the 3827 neighbor state machine should be executed with the event 2- 3828 WayReceived. Otherwise, the neighbor state machine should 3829 be executed with the event 1-WayReceived, and the processing 3830 of the packet stops. 3832 o Next, the Hello Packet's Router Priority field is examined. 3833 If this field is different than the one previously received 3834 from the neighbor, the receiving interface's state machine 3835 is scheduled with the event NeighborChange. In any case, 3836 the Router Priority field in the neighbor data structure 3837 should be updated accordingly. 3839 o Next the Designated Router field in the Hello Packet is 3840 examined. If the neighbor is both declaring itself to be 3841 Designated Router (Designated Router field = Neighbor IP 3842 address) and the Backup Designated Router field in the 3843 packet is equal to 0.0.0.0 and the receiving interface is in 3844 state Waiting, the receiving interface's state machine is 3845 scheduled with the event BackupSeen. Otherwise, if the 3846 neighbor is declaring itself to be Designated Router and it 3847 had not previously, or the neighbor is not declaring itself 3848 Designated Router where it had previously, the receiving 3849 interface's state machine is scheduled with the event 3850 NeighborChange. In any case, the Neighbors' Designated 3851 Router item in the neighbor structure is updated 3852 accordingly. 3854 o Finally, the Backup Designated Router field in the Hello 3855 Packet is examined. If the neighbor is declaring itself to 3856 be Backup Designated Router (Backup Designated Router field 3857 = Neighbor IP address) and the receiving interface is in 3858 state Waiting, the receiving interface's state machine is 3859 scheduled with the event BackupSeen. Otherwise, if the 3860 neighbor is declaring itself to be Backup Designated Router 3861 and it had not previously, or the neighbor is not declaring 3862 itself Backup Designated Router where it had previously, the 3863 receiving interface's state machine is scheduled with the 3864 event NeighborChange. In any case, the Neighbor's Backup 3865 Designated Router item in the neighbor structure is updated 3866 accordingly. 3868 On NBMA networks, receipt of an Hello Packet may also cause an 3869 Hello Packet to be sent back to the neighbor in response. See 3870 Section 9.5.1 for more details. 3872 10.6. Receiving Database Description Packets 3874 This section explains the detailed processing of a received 3875 Database Description Packet. The incoming Database Description 3876 Packet has already been associated with a neighbor and receiving 3877 interface by the generic input packet processing (Section 8.2). 3878 Whether the Database Description packet should be accepted, and 3879 if so, how it should be further processed depends upon the 3880 neighbor state. 3882 If a Database Description packet is accepted, the following 3883 packet fields should be saved in the corresponding neighbor data 3884 structure under "last received Database Description packet": 3885 the packet's initialize(I), more (M) and master(MS) bits, 3886 Options field, and DD sequence number. If these fields are set 3887 identically in two consecutive Database Description packets 3888 received from the neighbor, the second Database Description 3889 packet is considered to be a "duplicate" in the processing 3890 described below. 3892 If the Interface MTU field in the Database Description packet 3893 indicates an IP datagram size that is larger than the router can 3894 accept on the receiving interface without fragmentation, the 3895 Database Description packet is rejected. Otherwise, if the 3896 neighbor state is: 3898 Down 3899 The packet should be rejected. 3901 Attempt 3902 The packet should be rejected. 3904 Init 3905 The neighbor state machine should be executed with the event 3906 2-WayReceived. This causes an immediate state change to 3907 either state 2-Way or state ExStart. If the new state is 3908 ExStart, the processing of the current packet should then 3909 continue in this new state by falling through to case 3910 ExStart below. 3912 2-Way 3913 The packet should be ignored. Database Description Packets 3914 are used only for the purpose of bringing up adjacencies.[7] 3916 ExStart 3917 If the received packet matches one of the following cases, 3918 then the neighbor state machine should be executed with the 3919 event NegotiationDone (causing the state to transition to 3920 Exchange), the packet's Options field should be recorded in 3921 the neighbor structure's Neighbor Options field and the 3922 packet should be accepted as next in sequence and processed 3923 further (see below). Otherwise, the packet should be 3924 ignored. 3926 o The initialize(I), more (M) and master(MS) bits are set, 3927 the contents of the packet are empty, and the neighbor's 3928 Router ID is larger than the router's own. In this case 3929 the router is now Slave. Set the master/slave bit to 3930 slave, and set the neighbor data structure's DD sequence 3931 number to that specified by the master. 3933 o The initialize(I) and master(MS) bits are off, the 3934 packet's DD sequence number equals the neighbor data 3935 structure's DD sequence number (indicating 3936 acknowledgment) and the neighbor's Router ID is smaller 3937 than the router's own. In this case the router is 3938 Master. 3940 Exchange 3941 Duplicate Database Description packets are discarded by the 3942 master, and cause the slave to retransmit the last Database 3943 Description packet that it had sent. Otherwise (the packet 3944 is not a duplicate): 3946 o If the state of the MS-bit is inconsistent with the 3947 master/slave state of the connection, generate the 3948 neighbor event SeqNumberMismatch and stop processing the 3949 packet. 3951 o If the initialize(I) bit is set, generate the neighbor 3952 event SeqNumberMismatch and stop processing the packet. 3954 o If the packet's Options field indicates a different set 3955 of optional OSPF capabilities than were previously 3956 received from the neighbor (recorded in the Neighbor 3957 Options field of the neighbor structure), generate the 3958 neighbor event SeqNumberMismatch and stop processing the 3959 packet. 3961 o Database Description packets must be processed in 3962 sequence, as indicated by the packets' DD sequence 3963 numbers. If the router is master, the next packet 3964 received should have DD sequence number equal to the DD 3965 sequence number in the neighbor data structure. If the 3966 router is slave, the next packet received should have DD 3967 sequence number equal to one more than the DD sequence 3968 number stored in the neighbor data structure. In either 3969 case, if the packet is the next in sequence it should be 3970 accepted and its contents processed as specified below. 3972 o Else, generate the neighbor event SeqNumberMismatch and 3973 stop processing the packet. 3975 Loading or Full 3976 In this state, the router has sent and received an entire 3977 sequence of Database Description Packets. The only packets 3978 received should be duplicates (see above). In particular, 3979 the packet's Options field should match the set of optional 3980 OSPF capabilities previously indicated by the neighbor 3981 (stored in the neighbor structure's Neighbor Options field). 3982 Any other packets received, including the reception of a 3983 packet with the Initialize(I) bit set, should generate the 3984 neighbor event SeqNumberMismatch.[8] Duplicates should be 3985 discarded by the master. The slave must respond to 3986 duplicates by repeating the last Database Description packet 3987 that it had sent. 3989 When the router accepts a received Database Description Packet 3990 as the next in sequence the packet contents are processed as 3991 follows. For each LSA listed, the LSA's LS type is checked for 3992 validity. If the LS type is unknown (e.g., not one of the LS 3993 types 1-5 defined by this specification), or if this is an AS- 3994 external-LSA (LS type = 5) and the neighbor is associated with a 3995 stub area, generate the neighbor event SeqNumberMismatch and 3996 stop processing the packet. Otherwise, the router looks up the 3997 LSA in its database to see whether it also has an instance of 3998 the LSA. If it does not, or if the database copy is less recent 3999 (see Section 13.1), the LSA is put on the Link state request 4000 list so that it can be requested (immediately or at some later 4001 time) in Link State Request Packets. 4003 When the router accepts a received Database Description Packet 4004 as the next in sequence, it also performs the following actions, 4005 depending on whether it is master or slave: 4007 Master 4008 Increments the DD sequence number in the neighbor data 4009 structure. If the router has already sent its entire 4010 sequence of Database Description Packets, and the just 4011 accepted packet has the more bit (M) set to 0, the neighbor 4012 event ExchangeDone is generated. Otherwise, it should send 4013 a new Database Description to the slave. 4015 Slave 4016 Sets the DD sequence number in the neighbor data structure 4017 to the DD sequence number appearing in the received packet. 4018 The slave must send a Database Description Packet in reply. 4019 If the received packet has the more bit (M) set to 0, and 4020 the packet to be sent by the slave will also have the M-bit 4021 set to 0, the neighbor event ExchangeDone is generated. 4022 Note that the slave always generates this event before the 4023 master. 4025 10.7. Receiving Link State Request Packets 4027 This section explains the detailed processing of received Link 4028 State Request packets. Received Link State Request Packets 4029 specify a list of LSAs that the neighbor wishes to receive. 4030 Link State Request Packets should be accepted when the neighbor 4031 is in states Exchange, Loading, or Full. In all other states 4032 Link State Request Packets should be ignored. 4034 Each LSA specified in the Link State Request packet should be 4035 located in the router's database, and copied into Link State 4036 Update packets for transmission to the neighbor. These LSAs 4037 should NOT be placed on the Link state retransmission list for 4038 the neighbor. If an LSA cannot be found in the database, 4039 something has gone wrong with the Database Exchange process, and 4040 neighbor event BadLSReq should be generated. 4042 10.8. Sending Database Description Packets 4044 This section describes how Database Description Packets are sent 4045 to a neighbor. The Database Description packet's Interface MTU 4046 field is set to the size of the largest IP datagram that can be 4047 sent out the sending interface, without fragmentation. Common 4048 MTUs in use in the Internet can be found in Table 7-1 of 4049 [Ref22]. Interface MTU should be set to 0 in Database 4050 Description packets sent over virtual links. 4052 The router's optional OSPF capabilities (see Section 4.5) are 4053 transmitted to the neighbor in the Options field of the Database 4054 Description packet. The router should maintain the same set of 4055 optional capabilities throughout the Database Exchange and 4056 flooding procedures. If for some reason the router's optional 4057 capabilities change, the Database Exchange procedure should be 4058 restarted by reverting to neighbor state ExStart. One optional 4059 capability is defined in this specification (see Sections 4.5 4060 and A.2). The E-bit should be set if and only if the attached 4061 network belongs to a non-stub area. Unrecognized bits in the 4062 Options field should be set to zero. 4064 The sending of Database Description packets depends on the 4065 neighbor's state. In state ExStart the router sends empty 4066 Database Description packets, with the initialize (I), more (M) 4067 and master (MS) bits set. These packets are retransmitted every 4068 RxmtInterval seconds. 4070 In state Exchange the Database Description Packets actually 4071 contain summaries of the link state information contained in the 4072 router's database. Each LSA in the area's link-state database 4073 (at the time the neighbor transitions into Exchange state) is 4074 listed in the neighbor Database summary list. Each new Database 4075 Description Packet copies its DD sequence number from the 4076 neighbor data structure and then describes the current top of 4077 the Database summary list. Items are removed from the Database 4078 summary list when the previous packet is acknowledged. 4080 In state Exchange, the determination of when to send a Database 4081 Description packet depends on whether the router is master or 4082 slave: 4084 Master 4085 Database Description packets are sent when either a) the 4086 slave acknowledges the previous Database Description packet 4087 by echoing the DD sequence number or b) RxmtInterval seconds 4088 elapse without an acknowledgment, in which case the previous 4089 Database Description packet is retransmitted. 4091 Slave 4092 Database Description packets are sent only in response to 4093 Database Description packets received from the master. If 4094 the Database Description packet received from the master is 4095 new, a new Database Description packet is sent, otherwise 4096 the previous Database Description packet is resent. 4098 In states Loading and Full the slave must resend its last 4099 Database Description packet in response to duplicate Database 4100 Description packets received from the master. For this reason 4101 the slave must wait RouterDeadInterval seconds before freeing 4102 the last Database Description packet. Reception of a Database 4103 Description packet from the master after this interval will 4104 generate a SeqNumberMismatch neighbor event. 4106 10.9. Sending Link State Request Packets 4108 In neighbor states Exchange or Loading, the Link state request 4109 list contains a list of those LSAs that need to be obtained from 4110 the neighbor. To request these LSAs, a router sends the 4111 neighbor the beginning of the Link state request list, packaged 4112 in a Link State Request packet. 4114 When the neighbor responds to these requests with the proper 4115 Link State Update packet(s), the Link state request list is 4116 truncated and a new Link State Request packet is sent. This 4117 process continues until the Link state request list becomes 4118 empty. LSAs on the Link state request list that have been 4119 requested, but not yet received, are packaged into Link State 4120 Request packets for retransmission at intervals of RxmtInterval. 4121 There should be at most one Link State Request packet 4122 outstanding at any one time. 4124 When the Link state request list becomes empty, and the neighbor 4125 state is Loading (i.e., a complete sequence of Database 4126 Description packets has been sent to and received from the 4127 neighbor), the Loading Done neighbor event is generated. 4129 10.10. An Example 4131 Figure 14 shows an example of an adjacency forming. Routers RT1 4132 and RT2 are both connected to a broadcast network. It is 4133 assumed that RT2 is the Designated Router for the network, and 4134 that RT2 has a higher Router ID than Router RT1. 4136 The neighbor state changes realized by each router are listed on 4137 the sides of the figure. 4139 At the beginning of Figure 14, Router RT1's interface to the 4140 network becomes operational. It begins sending Hello Packets, 4141 although it doesn't know the identity of the Designated Router 4142 or of any other neighboring routers. Router RT2 hears this 4143 hello (moving the neighbor to Init state), and in its next Hello 4144 Packet indicates that it is itself the Designated Router and 4145 that it has heard Hello Packets from RT1. This in turn causes 4146 RT1 to go to state ExStart, as it starts to bring up the 4147 adjacency. 4149 RT1 begins by asserting itself as the master. When it sees that 4150 RT2 is indeed the master (because of RT2's higher Router ID), 4151 RT1 transitions to slave state and adopts its neighbor's DD 4152 sequence number. Database Description packets are then 4153 exchanged, with polls coming from the master (RT2) and responses 4154 from the slave (RT1). This sequence of Database Description 4155 Packets ends when both the poll and associated response has the 4156 M-bit off. 4158 In this example, it is assumed that RT2 has a completely up to 4159 date database. In that case, RT2 goes immediately into Full 4160 state. RT1 will go into Full state after updating the necessary 4161 parts of its database. This is done by sending Link State 4162 Request Packets, and receiving Link State Update Packets in 4163 response. Note that, while RT1 has waited until a complete set 4164 +---+ +---+ 4165 |RT1| |RT2| 4166 +---+ +---+ 4168 Down Down 4169 Hello(DR=0,seen=0) 4170 ------------------------------> 4171 Hello (DR=RT2,seen=RT1,...) Init 4172 <------------------------------ 4173 ExStart D-D (Seq=x,I,M,Master) 4174 ------------------------------> 4175 D-D (Seq=y,I,M,Master) ExStart 4176 <------------------------------ 4177 Exchange D-D (Seq=y,M,Slave) 4178 ------------------------------> 4179 D-D (Seq=y+1,M,Master) Exchange 4180 <------------------------------ 4181 D-D (Seq=y+1,M,Slave) 4182 ------------------------------> 4183 ... 4184 ... 4185 ... 4186 D-D (Seq=y+n, Master) 4187 <------------------------------ 4188 D-D (Seq=y+n, Slave) 4189 Loading ------------------------------> 4190 LS Request Full 4191 ------------------------------> 4192 LS Update 4193 <------------------------------ 4194 LS Request 4195 ------------------------------> 4196 LS Update 4197 <------------------------------ 4198 Full 4200 Figure 14: An adjacency bring-up example 4201 of Database Description Packets has been received (from RT2) 4202 before sending any Link State Request Packets, this need not be 4203 the case. RT1 could have interleaved the sending of Link State 4204 Request Packets with the reception of Database Description 4205 Packets. 4207 11. The Routing Table Structure 4209 The routing table data structure contains all the information 4210 necessary to forward an IP data packet toward its destination. Each 4211 routing table entry describes the collection of best paths to a 4212 particular destination. When forwarding an IP data packet, the 4213 routing table entry providing the best match for the packet's IP 4214 destination is located. The matching routing table entry then 4215 provides the next hop towards the packet's destination. OSPF also 4216 provides for the existence of a default route (Destination ID = 4217 DefaultDestination, Address Mask = 0x00000000). When the default 4218 route exists, it matches all IP destinations (although any other 4219 matching entry is a better match). Finding the routing table entry 4220 that best matches an IP destination is further described in Section 4221 11.1. 4223 There is a single routing table in each router. Two sample routing 4224 tables are described in Sections 11.2 and 11.3. The building of the 4225 routing table is discussed in Section 16. 4227 The rest of this section defines the fields found in a routing table 4228 entry. The first set of fields describes the routing table entry's 4229 destination. 4231 Destination Type 4232 Destination type is either "network" or "router". Only network 4233 entries are actually used when forwarding IP data traffic. 4234 Router routing table entries are used solely as intermediate 4235 steps in the routing table build process. 4237 A network is a range of IP addresses, to which IP data traffic 4238 may be forwarded. This includes IP networks (class A, B, or C), 4239 IP subnets, IP supernets and single IP hosts. The default route 4240 also falls into this category. 4242 Router entries are kept for area border routers and AS boundary 4243 routers. Routing table entries for area border routers are used 4244 when calculating the inter-area routes (see Section 16.2), and 4245 when maintaining configured virtual links (see Section 15). 4246 Routing table entries for AS boundary routers are used when 4247 calculating the AS external routes (see Section 16.4). 4249 Destination ID 4250 The destination's identifier or name. This depends on the 4251 Destination Type. For networks, the identifier is their 4252 associated IP address. For routers, the identifier is the OSPF 4253 Router ID.[9] 4255 Address Mask 4256 Only defined for networks. The network's IP address together 4257 with its address mask defines a range of IP addresses. For IP 4258 subnets, the address mask is referred to as the subnet mask. 4259 For host routes, the mask is "all ones" (0xffffffff). 4261 Optional Capabilities 4262 When the destination is a router this field indicates the 4263 optional OSPF capabilities supported by the destination router. 4264 The only optional capability defined by this specification is 4265 the ability to process AS-external-LSAs. For a further 4266 discussion of OSPF's optional capabilities, see Section 4.5. 4268 The set of paths to use for a destination may vary based on the OSPF 4269 area to which the paths belong. This means that there may be 4270 multiple routing table entries for the same destination, depending 4271 on the values of the next field. 4273 Area 4274 This field indicates the area whose link state information has 4275 led to the routing table entry's collection of paths. This is 4276 called the entry's associated area. For sets of AS external 4277 paths, this field is not defined. For destinations of type 4278 "router", there may be separate sets of paths (and therefore 4279 separate routing table entries) associated with each of several 4280 areas. For example, this will happen when two area border 4281 routers share multiple areas in common. For destinations of 4282 type "network", only the set of paths associated with the best 4283 area (the one providing the preferred route) is kept. 4285 The rest of the routing table entry describes the set of paths to 4286 the destination. The following fields pertain to the set of paths 4287 as a whole. In other words, each one of the paths contained in a 4288 routing table entry is of the same path-type and cost (see below). 4290 Path-type 4291 There are four possible types of paths used to route traffic to 4292 the destination, listed here in decreasing order of preference: 4293 intra-area, inter-area, type 1 external or type 2 external. 4294 Intra-area paths indicate destinations belonging to one of the 4295 router's attached areas. Inter-area paths are paths to 4296 destinations in other OSPF areas. These are discovered through 4297 the examination of received summary-LSAs. AS external paths are 4298 paths to destinations external to the AS. These are detected 4299 through the examination of received AS-external-LSAs. 4301 Cost 4302 The link state cost of the path to the destination. For all 4303 paths except type 2 external paths this describes the entire 4304 path's cost. For Type 2 external paths, this field describes 4305 the cost of the portion of the path internal to the AS. This 4306 cost is calculated as the sum of the costs of the path's 4307 constituent links. 4309 Type 2 cost 4310 Only valid for type 2 external paths. For these paths, this 4311 field indicates the cost of the path's external portion. This 4312 cost has been advertised by an AS boundary router, and is the 4313 most significant part of the total path cost. For example, a 4314 type 2 external path with type 2 cost of 5 is always preferred 4315 over a path with type 2 cost of 10, regardless of the cost of 4316 the two paths' internal components. 4318 Link State Origin 4319 Valid only for intra-area paths, this field indicates the LSA 4320 (router-LSA or network-LSA) that directly references the 4321 destination. For example, if the destination is a transit 4322 network, this is the transit network's network-LSA. If the 4323 destination is a stub network, this is the router-LSA for the 4324 attached router. The LSA is discovered during the shortest-path 4325 tree calculation (see Section 16.1). Multiple LSAs may 4326 reference the destination, however a tie-breaking scheme always 4327 reduces the choice to a single LSA. The Link State Origin field 4328 is not used by the OSPF protocol, but it is used by the routing 4329 table calculation in OSPF's Multicast routing extensions 4330 (MOSPF). 4332 When multiple paths of equal path-type and cost exist to a 4333 destination (called elsewhere "equal-cost" paths), they are stored 4334 in a single routing table entry. Each one of the "equal-cost" paths 4335 is distinguished by the following fields: 4337 Next hop 4338 The outgoing router interface to use when forwarding traffic to 4339 the destination. On broadcast, Point-to-MultiPoint and NBMA 4340 networks, the next hop also includes the IP address of the next 4341 router (if any) in the path towards the destination. 4343 Advertising router 4344 Valid only for inter-area and AS external paths. This field 4345 indicates the Router ID of the router advertising the summary- 4346 LSA or AS-external-LSA that led to this path. 4348 11.1. Routing table lookup 4350 When an IP data packet is received, an OSPF router finds the 4351 routing table entry that best matches the packet's destination. 4352 This routing table entry then provides the outgoing interface 4353 and next hop router to use in forwarding the packet. This 4354 section describes the process of finding the best matching 4355 routing table entry. 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 Several routing table entries may match the destination address. 4367 In this case, the "best match" is the routing table entry that 4368 provides the most specific (longest) match. Another way of 4369 saying this is to choose the entry that specifies the narrowest 4370 range of IP addresses.[11] For example, the entry for the 4371 address/mask pair of (128.185.1.0, 0xffffff00) is more specific 4372 than an entry for the pair (128.185.0.0, 0xffff0000). The 4373 default route is the least specific match, since it matches all 4374 destinations. (Note that for any single routing table entry, 4375 multiple paths may be possible. In these cases, the calculations 4376 in Sections 16.1, 16.2, and 16.4 always yield the paths having 4377 the most preferential path-type, as described in Section 11). 4379 If there is no matching routing table entry, or the best match 4380 routing table entry is one of the above "discard" routing table 4381 entries, then the packet's IP destination is considered 4382 unreachable. Instead of being forwarded, the packet should then 4383 be discarded and an ICMP destination unreachable message should 4384 be returned to the packet's source. 4386 11.2. Sample routing table, without areas 4388 Consider the Autonomous System pictured in Figure 2. No OSPF 4389 areas have been configured. A single metric is shown per 4390 outbound interface. The calculation of Router RT6's routing 4391 table proceeds as described in Section 2.2. The resulting 4392 routing table is shown in Table 12. Destination types are 4393 abbreviated: Network as "N", Router as "R". 4395 There are no instances of multiple equal-cost shortest paths in 4396 this example. Also, since there are no areas, there are no 4397 inter-area paths. 4399 Routers RT5 and RT7 are AS boundary routers. Intra-area routes 4400 have been calculated to Routers RT5 and RT7. This allows 4401 external routes to be calculated to the destinations advertised 4402 by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is 4403 assumed all AS-external-LSAs originated by RT5 and RT7 are 4404 advertising type 1 external metrics. This results in type 1 4405 external paths being calculated to destinations N12-N15. 4407 11.3. Sample routing table, with areas 4409 Consider the previous example, this time split into OSPF areas. 4410 An OSPF area configuration is pictured in Figure 6. Router 4411 RT4's routing table will be described for this area 4412 configuration. Router RT4 has a connection to Area 1 and a 4413 backbone connection. This causes Router RT4 to view the AS as 4414 the concatenation of the two graphs shown in Figures 7 and 8. 4415 The resulting routing table is displayed in Table 13. 4417 Again, Routers RT5 and RT7 are AS boundary routers. Routers 4418 RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 4419 there are two routing entries for the area border router RT3, 4420 since it has two areas in common with RT4 (Area 1 and the 4421 backbone). 4423 Backbone paths have been calculated to all area border routers. 4424 These are used when determining the inter-area routes. Note 4425 that all of the inter-area routes are associated with the 4426 backbone; this is always the case when the calculating router is 4427 itself an area border router. Routing information is condensed 4428 at area boundaries. In this example, we assume that Area 3 has 4429 been defined so that networks N9-N11 and the host route to H1 4430 Type Dest Area Path Type Cost Next Adv. 4431 Hop(s) Router(s) 4432 ____________________________________________________________ 4433 N N1 0 intra-area 10 RT3 * 4434 N N2 0 intra-area 10 RT3 * 4435 N N3 0 intra-area 7 RT3 * 4436 N N4 0 intra-area 8 RT3 * 4437 N Ib 0 intra-area 7 * * 4438 N Ia 0 intra-area 12 RT10 * 4439 N N6 0 intra-area 8 RT10 * 4440 N N7 0 intra-area 12 RT10 * 4441 N N8 0 intra-area 10 RT10 * 4442 N N9 0 intra-area 11 RT10 * 4443 N N10 0 intra-area 13 RT10 * 4444 N N11 0 intra-area 14 RT10 * 4445 N H1 0 intra-area 21 RT10 * 4446 R RT5 0 intra-area 6 RT5 * 4447 R RT7 0 intra-area 8 RT10 * 4448 ____________________________________________________________ 4449 N N12 * type 1 ext. 10 RT10 RT7 4450 N N13 * type 1 ext. 14 RT5 RT5 4451 N N14 * type 1 ext. 14 RT5 RT5 4452 N N15 * type 1 ext. 17 RT10 RT7 4454 Table 12: The routing table for Router RT6 4455 (no configured areas). 4457 are all condensed to a single route when advertised into the 4458 backbone (by Router RT11). Note that the cost of this route is 4459 the maximum of the set of costs to its individual components. 4461 There is a virtual link configured between Routers RT10 and 4462 RT11. Without this configured virtual link, RT11 would be 4463 unable to advertise a route for networks N9-N11 and Host H1 into 4464 the backbone, and there would not be an entry for these networks 4465 in Router RT4's routing table. 4467 In this example there are two equal-cost paths to Network N12. 4468 However, they both use the same next hop (Router RT5). 4470 Router RT4's routing table would improve (i.e., some of the 4471 paths in the routing table would become shorter) if an 4472 additional virtual link were configured between Router RT4 and 4473 Type Dest Area Path Type Cost Next Adv. 4474 Hops(s) Router(s) 4475 __________________________________________________________________ 4476 N N1 1 intra-area 4 RT1 * 4477 N N2 1 intra-area 4 RT2 * 4478 N N3 1 intra-area 1 * * 4479 N N4 1 intra-area 3 RT3 * 4480 R RT3 1 intra-area 1 * * 4481 __________________________________________________________________ 4482 N Ib 0 intra-area 22 RT5 * 4483 N Ia 0 intra-area 27 RT5 * 4484 R RT3 0 intra-area 21 RT5 * 4485 R RT5 0 intra-area 8 * * 4486 R RT7 0 intra-area 14 RT5 * 4487 R RT10 0 intra-area 22 RT5 * 4488 R RT11 0 intra-area 25 RT5 * 4489 __________________________________________________________________ 4490 N N6 0 inter-area 15 RT5 RT7 4491 N N7 0 inter-area 19 RT5 RT7 4492 N N8 0 inter-area 18 RT5 RT7 4493 N N9-N11,H1 0 inter-area 36 RT5 RT11 4494 __________________________________________________________________ 4495 N N12 * type 1 ext. 16 RT5 RT5,RT7 4496 N N13 * type 1 ext. 16 RT5 RT5 4497 N N14 * type 1 ext. 16 RT5 RT5 4498 N N15 * type 1 ext. 23 RT5 RT7 4500 Table 13: Router RT4's routing table 4501 in the presence of areas. 4503 Router RT3. The new virtual link would itself be associated 4504 with the first entry for area border router RT3 in Table 13 (an 4505 intra-area path through Area 1). This would yield a cost of 1 4506 for the virtual link. The routing table entries changes that 4507 would be caused by the addition of this virtual link are shown 4508 in Table 14. 4510 12. Link State Advertisements (LSAs) 4512 Each router in the Autonomous System originates one or more link 4513 state advertisements (LSAs). This memo defines five distinct types 4514 of LSAs, which are described in Section 4.3. The collection of LSAs 4515 forms the link-state database. Each separate type of LSA has a 4516 Type Dest Area Path Type Cost Next Adv. 4517 Hop(s) Router(s) 4518 ________________________________________________________________ 4519 N Ib 0 intra-area 16 RT3 * 4520 N Ia 0 intra-area 21 RT3 * 4521 R RT3 0 intra-area 1 * * 4522 R RT10 0 intra-area 16 RT3 * 4523 R RT11 0 intra-area 19 RT3 * 4524 ________________________________________________________________ 4525 N N9-N11,H1 0 inter-area 30 RT3 RT11 4527 Table 14: Changes resulting from an 4528 additional virtual link. 4530 separate function. Router-LSAs and network-LSAs describe how an 4531 area's routers and networks are interconnected. Summary-LSAs 4532 provide a way of condensing an area's routing information. AS- 4533 external-LSAs provide a way of transparently advertising 4534 externally-derived routing information throughout the Autonomous 4535 System. 4537 Each LSA begins with a standard 20-byte header. This LSA header is 4538 discussed below. 4540 12.1. The LSA Header 4542 The LSA header contains the LS type, Link State ID and 4543 Advertising Router fields. The combination of these three 4544 fields uniquely identifies the LSA. 4546 There may be several instances of an LSA present in the 4547 Autonomous System, all at the same time. It must then be 4548 determined which instance is more recent. This determination is 4549 made by examining the LS sequence, LS checksum and LS age 4550 fields. These fields are also contained in the 20-byte LSA 4551 header. 4553 Several of the OSPF packet types list LSAs. When the instance 4554 is not important, an LSA is referred to by its LS type, Link 4555 State ID and Advertising Router (see Link State Request 4556 Packets). Otherwise, the LS sequence number, LS age and LS 4557 checksum fields must also be referenced. 4559 A detailed explanation of the fields contained in the LSA header 4560 follows. 4562 12.1.1. LS age 4564 This field is the age of the LSA in seconds. It should be 4565 processed as an unsigned 16-bit integer. It is set to 0 4566 when the LSA is originated. It must be incremented by 4567 InfTransDelay on every hop of the flooding procedure. LSAs 4568 are also aged as they are held in each router's database. 4570 The age of an LSA is never incremented past MaxAge. LSAs 4571 having age MaxAge are not used in the routing table 4572 calculation. When an LSA's age first reaches MaxAge, it is 4573 reflooded. An LSA of age MaxAge is finally flushed from the 4574 database when it is no longer needed to ensure database 4575 synchronization. For more information on the aging of LSAs, 4576 consult Section 14. 4578 The LS age field is examined when a router receives two 4579 instances of an LSA, both having identical LS sequence 4580 numbers and LS checksums. An instance of age MaxAge is then 4581 always accepted as most recent; this allows old LSAs to be 4582 flushed quickly from the routing domain. Otherwise, if the 4583 ages differ by more than MaxAgeDiff, the instance having the 4584 smaller age is accepted as most recent.[12] See Section 13.1 4585 for more details. 4587 12.1.2. Options 4589 The Options field in the LSA header indicates which optional 4590 capabilities are associated with the LSA. OSPF's optional 4591 capabilities are described in Section 4.5. One optional 4592 capability is defined by this specification, represented by 4593 the E-bit found in the Options field. The unrecognized bits 4594 in the Options field should be set to zero. 4596 The E-bit represents OSPF's ExternalRoutingCapability. This 4597 bit should be set in all LSAs associated with the backbone, 4598 and all LSAs associated with non-stub areas (see Section 4599 3.6). It should also be set in all AS-external-LSAs. It 4600 should be reset in all router-LSAs, network-LSAs and 4601 summary-LSAs associated with a stub area. For all LSAs, the 4602 setting of the E-bit is for informational purposes only; it 4603 does not affect the routing table calculation. 4605 12.1.3. LS type 4607 The LS type field dictates the format and function of the 4608 LSA. LSAs of different types have different names (e.g., 4609 router-LSAs or network-LSAs). All LSA types defined by this 4610 memo, except the AS-external-LSAs (LS type = 5), are flooded 4611 throughout a single area only. AS-external-LSAs are flooded 4612 throughout the entire Autonomous System, excepting stub 4613 areas (see Section 3.6). Each separate LSA type is briefly 4614 described below in Table 15. 4616 LS Type LSA description 4617 ________________________________________________ 4618 1 These are the router-LSAs. 4619 They describe the collected 4620 states of the router's 4621 interfaces. For more information, 4622 consult Section 12.4.1. 4623 ________________________________________________ 4624 2 These are the network-LSAs. 4625 They describe the set of routers 4626 attached to the network. For 4627 more information, consult 4628 Section 12.4.2. 4629 ________________________________________________ 4630 3 or 4 These are the summary-LSAs. 4631 They describe inter-area routes, 4632 and enable the condensation of 4633 routing information at area 4634 borders. Originated by area border 4635 routers, the Type 3 summary-LSAs 4636 describe routes to networks while the 4637 Type 4 summary-LSAs describe routes to 4638 AS boundary routers. 4639 ________________________________________________ 4640 5 These are the AS-external-LSAs. 4641 Originated by AS boundary routers, 4642 they describe routes 4643 to destinations external to the 4644 Autonomous System. A default route for 4645 the Autonomous System can also be 4646 described by an AS-external-LSA. 4648 Table 15: OSPF link state advertisements (LSAs). 4650 12.1.4. Link State ID 4652 This field identifies the piece of the routing domain that 4653 is being described by the LSA. Depending on the LSA's LS 4654 type, the Link State ID takes on the values listed in Table 4655 16. 4657 Actually, for Type 3 summary-LSAs (LS type = 3) and AS- 4658 external-LSAs (LS type = 5), the Link State ID may 4659 additionally have one or more of the destination network's 4660 "host" bits set. For example, when originating an AS- 4661 external-LSA for the network 10.0.0.0 with mask of 4662 255.0.0.0, the Link State ID can be set to anything in the 4663 range 10.0.0.0 through 10.255.255.255 inclusive (although 4664 10.0.0.0 should be used whenever possible). The freedom to 4665 set certain host bits allows a router to originate separate 4666 LSAs for two networks having the same address but different 4667 masks. See Appendix E for details. 4669 When the LSA is describing a network (LS type = 2, 3 or 5), 4670 the network's IP address is easily derived by masking the 4671 Link State ID with the network/subnet mask contained in the 4672 body of the LSA. When the LSA is describing a router (LS 4673 type = 1 or 4), the Link State ID is always the described 4674 router's OSPF Router ID. 4676 When an AS-external-LSA (LS Type = 5) is describing a 4677 default route, its Link State ID is set to 4678 DefaultDestination (0.0.0.0). 4680 LS Type Link State ID 4681 _______________________________________________ 4682 1 The originating router's Router ID. 4683 2 The IP interface address of the 4684 network's Designated Router. 4685 3 The destination network's IP address. 4686 4 The Router ID of the described AS 4687 boundary router. 4688 5 The destination network's IP address. 4690 Table 16: The LSA's Link State ID. 4692 12.1.5. Advertising Router 4694 This field specifies the OSPF Router ID of the LSA's 4695 originator. For router-LSAs, this field is identical to the 4696 Link State ID field. Network-LSAs are originated by the 4697 network's Designated Router. Summary-LSAs originated by 4698 area border routers. AS-external-LSAs are originated by AS 4699 boundary routers. 4701 12.1.6. LS sequence number 4703 The sequence number field is a signed 32-bit integer. It is 4704 used to detect old and duplicate LSAs. The space of 4705 sequence numbers is linearly ordered. The larger the 4706 sequence number (when compared as signed 32-bit integers) 4707 the more recent the LSA. To describe to sequence number 4708 space more precisely, let N refer in the discussion below to 4709 the constant 2**31. 4711 The sequence number -N (0x80000000) is reserved (and 4712 unused). This leaves -N + 1 (0x80000001) as the smallest 4713 (and therefore oldest) sequence number; this sequence number 4714 is referred to as the constant InitialSequenceNumber. A 4715 router uses InitialSequenceNumber the first time it 4716 originates any LSA. Afterwards, the LSA's sequence number 4717 is incremented each time the router originates a new 4718 instance of the LSA. When an attempt is made to increment 4719 the sequence number past the maximum value of N - 1 4720 (0x7fffffff; also referred to as MaxSequenceNumber), the 4721 current instance of the LSA must first be flushed from the 4722 routing domain. This is done by prematurely aging the LSA 4723 (see Section 14.1) and reflooding it. As soon as this flood 4724 has been acknowledged by all adjacent neighbors, a new 4725 instance can be originated with sequence number of 4726 InitialSequenceNumber. 4728 The router may be forced to promote the sequence number of 4729 one of its LSAs when a more recent instance of the LSA is 4730 unexpectedly received during the flooding process. This 4731 should be a rare event. This may indicate that an out-of- 4732 date LSA, originated by the router itself before its last 4733 restart/reload, still exists in the Autonomous System. For 4734 more information see Section 13.4. 4736 12.1.7. LS checksum 4738 This field is the checksum of the complete contents of the 4739 LSA, excepting the LS age field. The LS age field is 4740 excepted so that an LSA's age can be incremented without 4741 updating the checksum. The checksum used is the same that 4742 is used for ISO connectionless datagrams; it is commonly 4743 referred to as the Fletcher checksum. It is documented in 4744 Annex B of [Ref6]. The LSA header also contains the length 4745 of the LSA in bytes; subtracting the size of the LS age 4746 field (two bytes) yields the amount of data to checksum. 4748 The checksum is used to detect data corruption of an LSA. 4749 This corruption can occur while an LSA is being flooded, or 4750 while it is being held in a router's memory. The LS 4751 checksum field cannot take on the value of zero; the 4752 occurrence of such a value should be considered a checksum 4753 failure. In other words, calculation of the checksum is not 4754 optional. 4756 The checksum of an LSA is verified in two cases: a) when it 4757 is received in a Link State Update Packet and b) at times 4758 during the aging of the link state database. The detection 4759 of a checksum failure leads to separate actions in each 4760 case. See Sections 13 and 14 for more details. 4762 Whenever the LS sequence number field indicates that two 4763 instances of an LSA are the same, the LS checksum field is 4764 examined. If there is a difference, the instance with the 4765 larger LS checksum is considered to be most recent.[13] See 4766 Section 13.1 for more details. 4768 12.2. The link state database 4770 A router has a separate link state database for every area to 4771 which it belongs. All routers belonging to the same area have 4772 identical link state databases for the area. 4774 The databases for each individual area are always dealt with 4775 separately. The shortest path calculation is performed 4776 separately for each area (see Section 16). Components of the 4777 area link-state database are flooded throughout the area only. 4778 Finally, when an adjacency (belonging to Area A) is being 4779 brought up, only the database for Area A is synchronized between 4780 the two routers. 4782 The area database is composed of router-LSAs, network-LSAs and 4783 summary-LSAs (all listed in the area data structure). In 4784 addition, external routes (AS-external-LSAs) are included in all 4785 non-stub area databases (see Section 3.6). 4787 An implementation of OSPF must be able to access individual 4788 pieces of an area database. This lookup function is based on an 4789 LSA's LS type, Link State ID and Advertising Router.[14] There 4790 will be a single instance (the most up-to-date) of each LSA in 4791 the database. The database lookup function is invoked during 4792 the LSA flooding procedure (Section 13) and the routing table 4793 calculation (Section 16). In addition, using this lookup 4794 function the router can determine whether it has itself ever 4795 originated a particular LSA, and if so, with what LS sequence 4796 number. 4798 An LSA is added to a router's database when either a) it is 4799 received during the flooding process (Section 13) or b) it is 4800 originated by the router itself (Section 12.4). An LSA is 4801 deleted from a router's database when either a) it has been 4802 overwritten by a newer instance during the flooding process 4803 (Section 13) or b) the router originates a newer instance of one 4804 of its self-originated LSAs (Section 12.4) or c) the LSA ages 4805 out and is flushed from the routing domain (Section 14). 4806 Whenever an LSA is deleted from the database it must also be 4807 removed from all neighbors' Link state retransmission lists (see 4808 Section 10). 4810 12.3. Representation of TOS 4812 For backward compatibility with previous versions of the OSPF 4813 specification ([Ref9]), TOS-specific information can be included 4814 in router-LSAs, summary-LSAs and AS-external-LSAs. The encoding 4815 of TOS in OSPF LSAs is specified in Table 17. That table relates 4816 the OSPF encoding to the IP packet header's TOS field (defined 4817 in [Ref12]). The OSPF encoding is expressed as a decimal 4818 integer, and the IP packet header's TOS field is expressed in 4819 the binary TOS values used in [Ref12]. 4821 OSPF encoding RFC 1349 TOS values 4822 ___________________________________________ 4823 0 0000 normal service 4824 2 0001 minimize monetary cost 4825 4 0010 maximize reliability 4826 6 0011 4827 8 0100 maximize throughput 4828 10 0101 4829 12 0110 4830 14 0111 4831 16 1000 minimize delay 4832 18 1001 4833 20 1010 4834 22 1011 4835 24 1100 4836 26 1101 4837 28 1110 4838 30 1111 4840 Table 17: Representing TOS in OSPF. 4842 12.4. Originating LSAs 4844 Into any given OSPF area, a router will originate several LSAs. 4845 Each router originates a router-LSA. If the router is also the 4846 Designated Router for any of the area's networks, it will 4847 originate network-LSAs for those networks. 4849 Area border routers originate a single summary-LSA for each 4850 known inter-area destination. AS boundary routers originate a 4851 single AS-external-LSA for each known AS external destination. 4852 Destinations are advertised one at a time so that the change in 4853 any single route can be flooded without reflooding the entire 4854 collection of routes. During the flooding procedure, many LSAs 4855 can be carried by a single Link State Update packet. 4857 As an example, consider Router RT4 in Figure 6. It is an area 4858 border router, having a connection to Area 1 and the backbone. 4859 Router RT4 originates 5 distinct LSAs into the backbone (one 4860 router-LSA, and one summary-LSA for each of the networks N1-N4). 4861 Router RT4 will also originate 8 distinct LSAs into Area 1 (one 4862 router-LSA and seven summary-LSAs as pictured in Figure 7). If 4863 RT4 has been selected as Designated Router for Network N3, it 4864 will also originate a network-LSA for N3 into Area 1. 4866 In this same figure, Router RT5 will be originating 3 distinct 4867 AS-external-LSAs (one for each of the networks N12-N14). These 4868 will be flooded throughout the entire AS, assuming that none of 4869 the areas have been configured as stubs. However, if area 3 has 4870 been configured as a stub area, the AS-external-LSAs for 4871 networks N12-N14 will not be flooded into area 3 (see Section 4872 3.6). Instead, Router RT11 would originate a default summary- 4873 LSA that would be flooded throughout area 3 (see Section 4874 12.4.3). This instructs all of area 3's internal routers to 4875 send their AS external traffic to RT11. 4877 Whenever a new instance of an LSA is originated, its LS sequence 4878 number is incremented, its LS age is set to 0, its LS checksum 4879 is calculated, and the LSA is added to the link state database 4880 and flooded out the appropriate interfaces. See Section 13.2 4881 for details concerning the installation of the LSA into the link 4882 state database. See Section 13.3 for details concerning the 4883 flooding of newly originated LSAs. 4885 The ten events that can cause a new instance of an LSA to be 4886 originated are: 4888 (1) The LS age field of one of the router's self-originated LSAs 4889 reaches the value LSRefreshTime. In this case, a new 4890 instance of the LSA is originated, even though the contents 4891 of the LSA (apart from the LSA header) will be the same. 4892 This guarantees periodic originations of all LSAs. This 4893 periodic updating of LSAs adds robustness to the link state 4894 algorithm. LSAs that solely describe unreachable 4895 destinations should not be refreshed, but should instead be 4896 flushed from the routing domain (see Section 14.1). 4898 When whatever is being described by an LSA changes, a new LSA is 4899 originated. However, two instances of the same LSA may not be 4900 originated within the time period MinLSInterval. This may 4901 require that the generation of the next instance be delayed by 4902 up to MinLSInterval. The following events may cause the 4903 contents of an LSA to change. These events should cause new 4904 originations if and only if the contents of the new LSA would be 4905 different: 4907 (2) An interface's state changes (see Section 9.1). This may 4908 mean that it is necessary to produce a new instance of the 4909 router-LSA. 4911 (3) An attached network's Designated Router changes. A new 4912 router-LSA should be originated. Also, if the router itself 4913 is now the Designated Router, a new network-LSA should be 4914 produced. If the router itself is no longer the Designated 4915 Router, any network-LSA that it might have originated for 4916 the network should be flushed from the routing domain (see 4917 Section 14.1). 4919 (4) One of the neighboring routers changes to/from the FULL 4920 state. This may mean that it is necessary to produce a new 4921 instance of the router-LSA. Also, if the router is itself 4922 the Designated Router for the attached network, a new 4923 network-LSA should be produced. 4925 The next four events concern area border routers only: 4927 (5) An intra-area route has been added/deleted/modified in the 4928 routing table. This may cause a new instance of a summary- 4929 LSA (for this route) to be originated in each attached area 4930 (possibly including the backbone). 4932 (6) An inter-area route has been added/deleted/modified in the 4933 routing table. This may cause a new instance of a summary- 4934 LSA (for this route) to be originated in each attached area 4935 (but NEVER for the backbone). 4937 (7) The router becomes newly attached to an area. The router 4938 must then originate summary-LSAs into the newly attached 4939 area for all pertinent intra-area and inter-area routes in 4940 the router's routing table. See Section 12.4.3 for more 4941 details. 4943 (8) When the state of one of the router's configured virtual 4944 links changes, it may be necessary to originate a new 4945 router-LSA into the virtual link's Transit area (see the 4946 discussion of the router-LSA's bit V in Section 12.4.1), as 4947 well as originating a new router-LSA into the backbone. 4949 The last two events concern AS boundary routers (and former AS 4950 boundary routers) only: 4952 (9) An external route gained through direct experience with an 4953 external routing protocol (like BGP) changes. This will 4954 cause an AS boundary router to originate a new instance of 4955 an AS-external-LSA. 4957 (10) 4958 A router ceases to be an AS boundary router, perhaps after 4959 restarting. In this situation the router should flush all 4960 AS-external-LSAs that it had previously originated. These 4961 LSAs can be flushed via the premature aging procedure 4962 specified in Section 14.1. 4964 The construction of each type of LSA is explained in detail 4965 below. In general, these sections describe the contents of the 4966 LSA body (i.e., the part coming after the 20-byte LSA header). 4967 For information concerning the building of the LSA header, see 4968 Section 12.1. 4970 12.4.1. Router-LSAs 4972 A router originates a router-LSA for each area that it 4973 belongs to. Such an LSA describes the collected states of 4975 .................................... 4976 . 192.1.2 Area 1 . 4977 . + . 4978 . | . 4979 . | 3+---+1 . 4980 . N1 |--|RT1|-----+ . 4981 . | +---+ \ . 4982 . | \ _______N3 . 4983 . + \/ \ . 1+---+ 4984 . * 192.1.1 *------|RT4| 4985 . + /\_______/ . +---+ 4986 . | / | . 4987 . | 3+---+1 / | . 4988 . N2 |--|RT2|-----+ 1| . 4989 . | +---+ +---+8 . 6+---+ 4990 . | |RT3|----------------|RT6| 4991 . + +---+ . +---+ 4992 . 192.1.3 |2 . 18.10.0.6|7 4993 . | . | 4994 . +------------+ . 4995 . 192.1.4 (N4) . 4996 .................................... 4998 Figure 15: Area 1 with IP addresses shown 4999 the router's links to the area. The LSA is flooded 5000 throughout the particular area, and no further. 5002 The format of a router-LSA is shown in Appendix A (Section 5003 A.4.2). The first 20 bytes of the LSA consist of the 5004 generic LSA header that was discussed in Section 12.1. 5005 router-LSAs have LS type = 1. 5007 A router also indicates whether it is an area border router, 5008 or an AS boundary router, by setting the appropriate bits 5009 (bit B and bit E, respectively) in its router-LSAs. This 5010 enables paths to those types of routers to be saved in the 5011 routing table, for later processing of summary-LSAs and AS- 5012 external-LSAs. Bit B should be set whenever the router is 5013 actively attached to two or more areas, even if the router 5014 is not currently attached to the OSPF backbone area. Bit E 5015 should never be set in a router-LSA for a stub area (stub 5016 areas cannot contain AS boundary routers). 5018 In addition, the router sets bit V in its router-LSA for 5019 Area A if and only if the router is the endpoint of one or 5020 more fully adjacent virtual links having Area A as their 5021 Transit area. The setting of bit V enables other routers in 5022 Area A to discover whether the area supports transit traffic 5023 (see TransitCapability in Section 6). 5025 The router-LSA then describes the router's working 5026 connections (i.e., interfaces or links) to the area. Each 5027 link is typed according to the kind of attached network. 5028 Each link is also labelled with its Link ID. This Link ID 5029 gives a name to the entity that is on the other end of the 5030 link. Table 18 summarizes the values used for the Type and 5031 Link ID fields. 5033 Link type Description Link ID 5034 __________________________________________________ 5035 1 Point-to-point Neighbor Router ID 5036 link 5037 2 Link to transit Interface address of 5038 network Designated Router 5039 3 Link to stub IP network number 5040 network 5041 4 Virtual link Neighbor Router ID 5043 Table 18: Link descriptions in the 5044 router-LSA. 5046 In addition, the Link Data field is specified for each link. 5047 This field gives 32 bits of extra information for the link. 5048 For links to transit networks, numbered point-to-point links 5049 and virtual links, this field specifies the IP interface 5050 address of the associated router interface (this is needed 5051 by the routing table calculation, see Section 16.1.1). For 5052 links to stub networks, this field specifies the stub 5053 network's IP address mask. For unnumbered point-to-point 5054 links, the Link Data field should be set to the unnumbered 5055 interface's MIB-II [Ref8] ifIndex value. 5057 Finally, the cost of using the link for output is specified. 5058 The output cost of a link is configurable. With the 5059 exception of links to stub networks, the output cost must 5060 always be non-zero. 5062 To further describe the process of building the list of link 5063 descriptions, suppose a router wishes to build a router-LSA 5064 for Area A. The router examines its collection of interface 5065 data structures. For each interface, the following steps 5066 are taken: 5068 o If the attached network does not belong to Area A, no 5069 links are added to the LSA, and the next interface 5070 should be examined. 5072 o If the state of the interface is Down, no links are 5073 added. 5075 o If the state of the interface is Loopback, add a Type 3 5076 link (stub network) as long as this is not an interface 5077 to an unnumbered point-to-point network. The Link ID 5078 should be set to the IP interface address, the Link Data 5079 set to the mask 0xffffffff (indicating a host route), 5080 and the cost set to 0. 5082 o Otherwise, the link descriptions added to the router-LSA 5083 depend on the OSPF interface type. Link descriptions 5084 used for point-to-point interfaces are specified in 5085 Section 12.4.1.1, for virtual links in Section 12.4.1.2, 5086 for broadcast and NBMA interfaces in 12.4.1.3, and for 5087 Point-to-MultiPoint interfaces in 12.4.1.4. 5089 After consideration of all the router interfaces, host links 5090 are added to the router-LSA by examining the list of 5091 attached hosts belonging to Area A. A host route is 5092 represented as a Type 3 link (stub network) whose Link ID is 5093 the host's IP address, Link Data is the mask of all ones 5094 (0xffffffff), and cost the host's configured cost (see 5095 Section C.7). 5097 12.4.1.1. Describing point-to-point interfaces 5099 For point-to-point interfaces, one or more link 5100 descriptions are added to the router-LSA as follows: 5102 o If the neighboring router is fully adjacent, add a 5103 Type 1 link (point-to-point). The Link ID should be 5104 set to the Router ID of the neighboring router. For 5105 numbered point-to-point networks, the Link Data 5106 should specify the IP interface address. For 5107 unnumbered point-to-point networks, the Link Data 5108 field should specify the interface's MIB-II [Ref8] 5109 ifIndex value. The cost should be set to the output 5110 cost of the point-to-point interface. 5112 o In addition, as long as the state of the interface 5113 is "Point-to-Point" (and regardless of the 5114 neighboring router state), a Type 3 link (stub 5115 network) should be added. There are two forms that 5116 this stub link can take: 5118 Option 1 5119 Assuming that the neighboring router's IP 5120 address is known, set the Link ID of the Type 3 5121 link to the neighbor's IP address, the Link Data 5122 to the mask 0xffffffff (indicating a host 5123 route), and the cost to the interface's 5124 configured output cost.[15] 5126 Option 2 5127 If a subnet has been assigned to the point-to- 5128 point link, set the Link ID of the Type 3 link 5129 to the subnet's IP address, the Link Data to the 5130 subnet's mask, and the cost to the interface's 5131 configured output cost.[16] 5133 12.4.1.2. Describing broadcast and NBMA interfaces 5135 For operational broadcast and NBMA interfaces, a single 5136 link description is added to the router-LSA as follows: 5138 o If the state of the interface is Waiting, add a Type 5139 3 link (stub network) with Link ID set to the IP 5140 network number of the attached network, Link Data 5141 set to the attached network's address mask, and cost 5142 equal to the interface's configured output cost. 5144 o Else, there has been a Designated Router elected for 5145 the attached network. If the router is fully 5146 adjacent to the Designated Router, or if the router 5147 itself is Designated Router and is fully adjacent to 5148 at least one other router, add a single Type 2 link 5149 (transit network) with Link ID set to the IP 5150 interface address of the attached network's 5151 Designated Router (which may be the router itself), 5152 Link Data set to the router's own IP interface 5153 address, and cost equal to the interface's 5154 configured output cost. Otherwise, add a link as if 5155 the interface state were Waiting (see above). 5157 12.4.1.3. Describing virtual links 5159 For virtual links, a link description is added to the 5160 router-LSA only when the virtual neighbor is fully 5161 adjacent. In this case, add a Type 4 link (virtual link) 5162 with Link ID set to the Router ID of the virtual 5163 neighbor, Link Data set to the IP interface address 5164 associated with the virtual link and cost set to the 5165 cost calculated for the virtual link during the routing 5166 table calculation (see Section 15). 5168 12.4.1.4. Describing Point-to-MultiPoint interfaces 5170 For operational Point-to-MultiPoint interfaces, one or 5171 more link descriptions are added to the router-LSA as 5172 follows: 5174 o A single Type 3 link (stub network) is added with 5175 Link ID set to the router's own IP interface 5176 address, Link Data set to the mask 0xffffffff 5177 (indicating a host route), and cost set to 0. 5179 o For each fully adjacent neighbor associated with the 5180 interface, add an additional Type 1 link (point-to- 5181 point) with Link ID set to the Router ID of the 5182 neighboring router, Link Data set to the IP 5183 interface address and cost equal to the interface's 5184 configured output cost. 5186 12.4.1.5. Examples of router-LSAs 5188 Consider the router-LSAs generated by Router RT3, as 5189 pictured in Figure 6. The area containing Router RT3 5190 (Area 1) has been redrawn, with actual network 5191 addresses, in Figure 15. Assume that the last byte of 5192 all of RT3's interface addresses is 3, giving it the 5193 interface addresses 192.1.1.3 and 192.1.4.3, and that 5194 the other routers have similar addressing schemes. In 5195 addition, assume that all links are functional, and that 5196 Router IDs are assigned as the smallest IP interface 5197 address. 5199 RT3 originates two router-LSAs, one for Area 1 and one 5200 for the backbone. Assume that Router RT4 has been 5201 selected as the Designated router for network 192.1.1.0. 5202 RT3's router-LSA for Area 1 is then shown below. It 5203 indicates that RT3 has two connections to Area 1, the 5204 first a link to the transit network 192.1.1.0 and the 5205 second a link to the stub network 192.1.4.0. Note that 5206 the transit network is identified by the IP interface of 5207 its Designated Router (i.e., the Link ID = 192.1.1.4 5208 which is the Designated Router RT4's IP interface to 5209 192.1.1.0). Note also that RT3 has indicated that it is 5210 an area border router. 5212 ; RT3's router-LSA for Area 1 5214 LS age = 0 ;always true on origination 5215 Options = (E-bit) ; 5216 LS type = 1 ;indicates router-LSA 5217 Link State ID = 192.1.1.3 ;RT3's Router ID 5218 Advertising Router = 192.1.1.3 ;RT3's Router ID 5219 bit E = 0 ;not an AS boundary router 5220 bit B = 1 ;area border router 5221 #links = 2 5222 Link ID = 192.1.1.4 ;IP address of Desig. Rtr. 5223 Link Data = 192.1.1.3 ;RT3's IP interface to net 5224 Type = 2 ;connects to transit network 5225 # TOS metrics = 0 5226 metric = 1 5228 Link ID = 192.1.4.0 ;IP Network number 5229 Link Data = 0xffffff00 ;Network mask 5230 Type = 3 ;connects to stub network 5231 # TOS metrics = 0 5232 metric = 2 5234 Next RT3's router-LSA for the backbone is shown. It 5235 indicates that RT3 has a single attachment to the 5236 backbone. This attachment is via an unnumbered point- 5237 to-point link to Router RT6. RT3 has again indicated 5238 that it is an area border router. 5240 ; RT3's router-LSA for the backbone 5242 LS age = 0 ;always true on origination 5243 Options = (E-bit) ; 5244 LS type = 1 ;indicates router-LSA 5245 Link State ID = 192.1.1.3 ;RT3's router ID 5246 Advertising Router = 192.1.1.3 ;RT3's router ID 5247 bit E = 0 ;not an AS boundary router 5248 bit B = 1 ;area border router 5249 #links = 1 5250 Link ID = 18.10.0.6 ;Neighbor's Router ID 5251 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5252 Type = 1 ;connects to router 5253 # TOS metrics = 0 5254 metric = 8 5256 12.4.2. Network-LSAs 5258 A network-LSA is generated for every transit broadcast or 5259 NBMA network. (A transit network is a network having two or 5260 more attached routers). The network-LSA describes all the 5261 routers that are attached to the network. 5263 The Designated Router for the network originates the LSA. 5264 The Designated Router originates the LSA only if it is fully 5265 adjacent to at least one other router on the network. The 5266 network-LSA is flooded throughout the area that contains the 5267 transit network, and no further. The network-LSA lists 5268 those routers that are fully adjacent to the Designated 5269 Router; each fully adjacent router is identified by its OSPF 5270 Router ID. The Designated Router includes itself in this 5271 list. 5273 The Link State ID for a network-LSA is the IP interface 5274 address of the Designated Router. This value, masked by the 5275 network's address mask (which is also contained in the 5276 network-LSA) yields the network's IP address. 5278 A router that has formerly been the Designated Router for a 5279 network, but is no longer, should flush the network-LSA that 5280 it had previously originated. This LSA is no longer used in 5281 the routing table calculation. It is flushed by prematurely 5282 incrementing the LSA's age to MaxAge and reflooding (see 5283 Section 14.1). In addition, in those rare cases where a 5284 router's Router ID has changed, any network-LSAs that were 5285 originated with the router's previous Router ID must be 5286 flushed. Since the router may have no idea what it's 5287 previous Router ID might have been, these network-LSAs are 5288 indicated by having their Link State ID equal to one of the 5289 router's IP interface addresses and their Advertising Router 5290 equal to some value other than the router's current Router 5291 ID (see Section 13.4 for more details). 5293 12.4.2.1. Examples of network-LSAs 5295 Again consider the area configuration in Figure 6. 5296 Network-LSAs are originated for Network N3 in Area 1, 5297 Networks N6 and N8 in Area 2, and Network N9 in Area 3. 5298 Assuming that Router RT4 has been selected as the 5299 Designated Router for Network N3, the following 5300 network-LSA is generated by RT4 on behalf of Network N3 5301 (see Figure 15 for the address assignments): 5303 ; Network-LSA for Network N3 5305 LS age = 0 ;always true on origination 5306 Options = (E-bit) ; 5307 LS type = 2 ;indicates network-LSA 5308 Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. 5309 Advertising Router = 192.1.1.4 ;RT4's Router ID 5310 Network Mask = 0xffffff00 5311 Attached Router = 192.1.1.4 ;Router ID 5312 Attached Router = 192.1.1.1 ;Router ID 5313 Attached Router = 192.1.1.2 ;Router ID 5314 Attached Router = 192.1.1.3 ;Router ID 5316 12.4.3. Summary-LSAs 5318 The destination described by a summary-LSA is either an IP 5319 network, an AS boundary router or a range of IP addresses. 5320 Summary-LSAs are flooded throughout a single area only. The 5321 destination described is one that is external to the area, 5322 yet still belongs to the Autonomous System. 5324 Summary-LSAs are originated by area border routers. The 5325 precise summary routes to advertise into an area are 5326 determined by examining the routing table structure (see 5327 Section 11) in accordance with the algorithm described 5328 below. Note that only intra-area routes are advertised into 5329 the backbone, while both intra-area and inter-area routes 5330 are advertised into the other areas. 5332 To determine which routes to advertise into an attached Area 5333 A, each routing table entry is processed as follows. 5334 Remember that each routing table entry describes a set of 5335 equal-cost best paths to a particular destination: 5337 o Only Destination Types of network and AS boundary router 5338 are advertised in summary-LSAs. If the routing table 5339 entry's Destination Type is area border router, examine 5340 the next routing table entry. 5342 o AS external routes are never advertised in summary-LSAs. 5343 If the routing table entry has Path-type of type 1 5344 external or type 2 external, examine the next routing 5345 table entry. 5347 o Else, if the area associated with this set of paths is 5348 the Area A itself, do not generate a summary-LSA for the 5349 route.[17] 5351 o Else, if the next hops associated with this set of paths 5352 belong to Area A itself, do not generate a summary-LSA 5353 for the route.[18] This is the logical equivalent of a 5354 Distance Vector protocol's split horizon logic. 5356 o Else, if the routing table cost equals or exceeds the 5357 value LSInfinity, a summary-LSA cannot be generated for 5358 this route. 5360 o Else, if the destination of this route is an AS boundary 5361 router, a summary-LSA should be originated if and only 5362 if the routing table entry describes the preferred path 5363 to the AS boundary router (see Step 3 of Section 16.4). 5364 If so, a Type 4 summary-LSA is originated for the 5365 destination, with Link State ID equal to the AS boundary 5366 router's Router ID and metric equal to the routing table 5367 entry's cost. Note: these LSAs should not be generated 5368 if Area A has been configured as a stub area. 5370 o Else, the Destination type is network. If this is an 5371 inter-area route, generate a Type 3 summary-LSA for the 5372 destination, with Link State ID equal to the network's 5373 address (if necessary, the Link State ID can also have 5374 one or more of the network's host bits set; see Appendix 5375 E for details) and metric equal to the routing table 5376 cost. 5378 o The one remaining case is an intra-area route to a 5379 network. This means that the network is contained in 5380 one of the router's directly attached areas. In 5381 general, this information must be condensed before 5382 appearing in summary-LSAs. Remember that an area has a 5383 configured list of address ranges, each range consisting 5384 of an [address,mask] pair and a status indication of 5385 either Advertise or DoNotAdvertise. At most a single 5386 Type 3 summary-LSA is originated for each range. When 5387 the range's status indicates Advertise, a Type 3 5388 summary-LSA is generated with Link State ID equal to the 5389 range's address (if necessary, the Link State ID can 5390 also have one or more of the range's "host" bits set; 5391 see Appendix E for details) and cost equal to the 5392 largest cost of any of the component networks. When the 5393 range's status indicates DoNotAdvertise, the Type 3 5394 summary-LSA is suppressed and the component networks 5395 remain hidden from other areas. 5397 By default, if a network is not contained in any 5398 explicitly configured address range, a Type 3 summary- 5399 LSA is generated with Link State ID equal to the 5400 network's address (if necessary, the Link State ID can 5401 also have one or more of the network's "host" bits set; 5402 see Appendix E for details) and metric equal to the 5403 network's routing table cost. 5405 If an area is capable of carrying transit traffic (i.e., 5406 its TransitCapability is set to TRUE), routing 5407 information concerning backbone networks should not be 5408 condensed before being summarized into the area. Nor 5409 should the advertisement of backbone networks into 5410 transit areas be suppressed. In other words, the 5411 backbone's configured ranges should be ignored when 5412 originating summary-LSAs into transit areas. 5414 If a router advertises a summary-LSA for a destination which 5415 then becomes unreachable, the router must then flush the LSA 5416 from the routing domain by setting its age to MaxAge and 5417 reflooding (see Section 14.1). Also, if the destination is 5418 still reachable, yet can no longer be advertised according 5419 to the above procedure (e.g., it is now an inter-area route, 5420 when it used to be an intra-area route associated with some 5421 non-backbone area; it would thus no longer be advertisable 5422 to the backbone), the LSA should also be flushed from the 5423 routing domain. 5425 12.4.3.1. Originating summary-LSAs into stub areas 5427 The algorithm in Section 12.4.3 is optional when Area A 5428 is an OSPF stub area. Area border routers connecting to 5429 a stub area can originate summary-LSAs into the area 5430 according to the Section 12.4.3's algorithm, or can 5431 choose to originate only a subset of the summary-LSAs, 5432 possibly under configuration control. The fewer LSAs 5433 originated, the smaller the stub area's link state 5434 database, further reducing the demands on its routers' 5435 resources. However, omitting LSAs may also lead to sub- 5436 optimal inter-area routing, although routing will 5437 continue to function. 5439 As specified in Section 12.4.3, Type 4 summary-LSAs 5440 (ASBR-summary-LSAs) are never originated into stub 5441 areas. 5443 In a stub area, instead of importing external routes 5444 each area border router originates a "default summary- 5445 LSA" into the area. The Link State ID for the default 5446 summary-LSA is set to DefaultDestination, and the metric 5447 set to the (per-area) configurable parameter 5448 StubDefaultCost. Note that StubDefaultCost need not be 5449 configured identically in all of the stub area's area 5450 border routers. 5452 12.4.3.2. Examples of summary-LSAs 5454 Consider again the area configuration in Figure 6. 5455 Routers RT3, RT4, RT7, RT10 and RT11 are all area border 5456 routers, and therefore are originating summary-LSAs. 5457 Consider in particular Router RT4. Its routing table 5458 was calculated as the example in Section 11.3. RT4 5459 originates summary-LSAs into both the backbone and Area 5460 1. Into the backbone, Router RT4 originates separate 5461 LSAs for each of the networks N1-N4. Into Area 1, 5462 Router RT4 originates separate LSAs for networks N6-N8 5463 and the AS boundary routers RT5,RT7. It also condenses 5464 host routes Ia and Ib into a single summary-LSA. 5465 Finally, the routes to networks N9,N10,N11 and Host H1 5466 are advertised by a single summary-LSA. This 5467 condensation was originally performed by the router 5468 RT11. 5470 These LSAs are illustrated graphically in Figures 7 and 5471 8. Two of the summary-LSAs originated by Router RT4 5472 follow. The actual IP addresses for the networks and 5473 routers in question have been assigned in Figure 15. 5475 ; Summary-LSA for Network N1, 5476 ; originated by Router RT4 into the backbone 5478 LS age = 0 ;always true on origination 5479 Options = (E-bit) ; 5480 LS type = 3 ;Type 3 summary-LSA 5481 Link State ID = 192.1.2.0 ;N1's IP network number 5482 Advertising Router = 192.1.1.4 ;RT4's ID 5483 metric = 4 5485 ; Summary-LSA for AS boundary router RT7 5486 ; originated by Router RT4 into Area 1 5488 LS age = 0 ;always true on origination 5489 Options = (E-bit) ; 5490 LS type = 4 ;Type 4 summary-LSA 5491 Link State ID = Router RT7's ID 5492 Advertising Router = 192.1.1.4 ;RT4's ID 5493 metric = 14 5495 12.4.4. AS-external-LSAs 5497 AS-external-LSAs describe routes to destinations external to 5498 the Autonomous System. Most AS-external-LSAs describe 5499 routes to specific external destinations; in these cases the 5500 LSA's Link State ID is set to the destination network's IP 5501 address (if necessary, the Link State ID can also have one 5502 or more of the network's "host" bits set; see Appendix E for 5503 details). However, a default route for the Autonomous 5504 System can be described in an AS-external-LSA by setting the 5505 LSA's Link State ID to DefaultDestination (0.0.0.0). AS- 5506 external-LSAs are originated by AS boundary routers. An AS 5507 boundary router originates a single AS-external-LSA for each 5508 external route that it has learned, either through another 5509 routing protocol (such as BGP), or through configuration 5510 information. 5512 AS-external-LSAs are the only type of LSAs that are flooded 5513 throughout the entire Autonomous System; all other types of 5514 LSAs are specific to a single area. However, AS-external- 5515 LSAs are not flooded into/throughout stub areas (see Section 5516 3.6). This enables a reduction in link state database size 5517 for routers internal to stub areas. 5519 The metric that is advertised for an external route can be 5520 one of two types. Type 1 metrics are comparable to the link 5521 state metric. Type 2 metrics are assumed to be larger than 5522 the cost of any intra-AS path. 5524 If a router advertises an AS-external-LSA for a destination 5525 which then becomes unreachable, the router must then flush 5526 the LSA from the routing domain by setting its age to MaxAge 5527 and reflooding (see Section 14.1). 5529 12.4.4.1. Examples of AS-external-LSAs 5531 Consider once again the AS pictured in Figure 6. There 5532 are two AS boundary routers: RT5 and RT7. Router RT5 5533 originates three AS-external-LSAs, for networks N12-N14. 5534 Router RT7 originates two AS-external-LSAs, for networks 5535 N12 and N15. Assume that RT7 has learned its route to 5536 N12 via BGP, and that it wishes to advertise a Type 2 5537 metric to the AS. RT7 would then originate the 5538 following LSA for N12: 5540 ; AS-external-LSA for Network N12, 5541 ; originated by Router RT7 5543 LS age = 0 ;always true on origination 5544 Options = (E-bit) ; 5545 LS type = 5 ;AS-external-LSA 5546 Link State ID = N12's IP network number 5547 Advertising Router = Router RT7's ID 5548 bit E = 1 ;Type 2 metric 5549 metric = 2 5550 Forwarding address = 0.0.0.0 5552 In the above example, the forwarding address field has 5553 been set to 0.0.0.0, indicating that packets for the 5554 external destination should be forwarded to the 5555 advertising OSPF router (RT7). This is not always 5556 desirable. Consider the example pictured in Figure 16. 5557 There are three OSPF routers (RTA, RTB and RTC) 5558 connected to a common network. Only one of these 5559 routers, RTA, is exchanging BGP information with the 5560 non-OSPF router RTX. RTA must then originate AS- 5561 external-LSAs for those destinations it has learned from 5562 RTX. By using the AS-external-LSA's forwarding address 5563 field, RTA can specify that packets for these 5564 destinations be forwarded directly to RTX. Without this 5565 feature, Routers RTB and RTC would take an extra hop to 5566 get to these destinations. 5568 Note that when the forwarding address field is non-zero, 5569 it should point to a router belonging to another 5570 Autonomous System. 5572 A forwarding address can also be specified for the 5573 default route. For example, in figure 16 RTA may want 5574 to specify that all externally-destined packets should 5575 by default be forwarded to its BGP peer RTX. The 5576 resulting AS-external-LSA is pictured below. Note that 5577 the Link State ID is set to DefaultDestination. 5579 ; Default route, originated by Router RTA 5580 ; Packets forwarded through RTX 5582 LS age = 0 ;always true on origination 5583 Options = (E-bit) ; 5584 LS type = 5 ;AS-external-LSA 5585 Link State ID = DefaultDestination ; default route 5586 Advertising Router = Router RTA's ID 5587 bit E = 1 ;Type 2 metric 5588 metric = 1 5589 Forwarding address = RTX's IP address 5591 In figure 16, suppose instead that both RTA and RTB 5592 exchange BGP information with RTX. In this case, RTA 5593 and RTB would originate the same set of AS-external- 5594 LSAs. These LSAs, if they specify the same metric, 5595 would be functionally equivalent since they would 5596 specify the same destination and forwarding address 5597 (RTX). This leads to a clear duplication of effort. If 5598 only one of RTA or RTB originated the set of AS- 5599 external-LSAs, the routing would remain the same, and 5600 the size of the link state database would decrease. 5601 However, it must be unambiguously defined as to which 5602 router originates the LSAs (otherwise neither may, or 5603 the identity of the originator may oscillate). The 5604 following rule is thereby established: if two routers, 5605 both reachable from one another, originate functionally 5606 equivalent AS-external-LSAs (i.e., same destination, 5607 cost and non-zero forwarding address), then the LSA 5608 originated by the router having the highest OSPF Router 5609 ID is used. The router having the lower OSPF Router ID 5610 can then flush its LSA. Flushing an LSA is discussed in 5611 Section 14.1. 5613 13. The Flooding Procedure 5615 Link State Update packets provide the mechanism for flooding LSAs. 5616 A Link State Update packet may contain several distinct LSAs, and 5617 floods each LSA one hop further from its point of origination. To 5618 make the flooding procedure reliable, each LSA must be acknowledged 5619 separately. Acknowledgments are transmitted in Link State 5620 Acknowledgment packets. Many separate acknowledgments can also be 5622 + 5623 | 5624 +---+.....|.BGP 5625 |RTA|-----|.....+---+ 5626 +---+ |-----|RTX| 5627 | +---+ 5628 +---+ | 5629 |RTB|-----| 5630 +---+ | 5631 | 5632 +---+ | 5633 |RTC|-----| 5634 +---+ | 5635 | 5636 + 5638 Figure 16: Forwarding address example 5639 grouped together into a single packet. 5641 The flooding procedure starts when a Link State Update packet has 5642 been received. Many consistency checks have been made on the 5643 received packet before being handed to the flooding procedure (see 5644 Section 8.2). In particular, the Link State Update packet has been 5645 associated with a particular neighbor, and a particular area. If 5646 the neighbor is in a lesser state than Exchange, the packet should 5647 be dropped without further processing. 5649 All types of LSAs, other than AS-external-LSAs, are associated with 5650 a specific area. However, LSAs do not contain an area field. An 5651 LSA's area must be deduced from the Link State Update packet header. 5653 For each LSA contained in a Link State Update packet, the following 5654 steps are taken: 5656 (1) Validate the LSA's LS checksum. If the checksum turns out to be 5657 invalid, discard the LSA and get the next one from the Link 5658 State Update packet. 5660 (2) Examine the LSA's LS type. If the LS type is unknown, discard 5661 the LSA and get the next one from the Link State Update Packet. 5662 This specification defines LS types 1-5 (see Section 4.3). 5664 (3) Else if this is an AS-external-LSA (LS type = 5), and the area 5665 has been configured as a stub area, discard the LSA and get the 5666 next one from the Link State Update Packet. AS-external-LSAs 5667 are not flooded into/throughout stub areas (see Section 3.6). 5669 (4) Else if the LSA's LS age is equal to MaxAge, and there is 5670 currently no instance of the LSA in the router's link state 5671 database, and none of router's neighbors are in states Exchange 5672 or Loading, then take the following actions: a) Acknowledge the 5673 receipt of the LSA by sending a Link State Acknowledgment packet 5674 back to the sending neighbor (see Section 13.5), and b) Discard 5675 the LSA and examine the next LSA (if any) listed in the Link 5676 State Update packet. 5678 (5) Otherwise, find the instance of this LSA that is currently 5679 contained in the router's link state database. If there is no 5680 database copy, or the received LSA is more recent than the 5681 database copy (see Section 13.1 below for the determination of 5682 which LSA is more recent) the following steps must be performed: 5684 (a) If there is already a database copy, and if the database 5685 copy was received via flooding and installed less than 5686 MinLSArrival seconds ago, discard the new LSA (without 5687 acknowledging it) and examine the next LSA (if any) listed 5688 in the Link State Update packet. 5690 (b) Otherwise immediately flood the new LSA out some subset of 5691 the router's interfaces (see Section 13.3). In some cases 5692 (e.g., the state of the receiving interface is DR and the 5693 LSA was received from a router other than the Backup DR) the 5694 LSA will be flooded back out the receiving interface. This 5695 occurrence should be noted for later use by the 5696 acknowledgment process (Section 13.5). 5698 (c) Remove the current database copy from all neighbors' Link 5699 state retransmission lists. 5701 (d) Install the new LSA in the link state database (replacing 5702 the current database copy). This may cause the routing 5703 table calculation to be scheduled. In addition, timestamp 5704 the new LSA with the current time (i.e., the time it was 5705 received). The flooding procedure cannot overwrite the 5706 newly installed LSA until MinLSArrival seconds have elapsed. 5707 The LSA installation process is discussed further in Section 5708 13.2. 5710 (e) Possibly acknowledge the receipt of the LSA by sending a 5711 Link State Acknowledgment packet back out the receiving 5712 interface. This is explained below in Section 13.5. 5714 (f) If this new LSA indicates that it was originated by the 5715 receiving router itself (i.e., is considered a self- 5716 originated LSA), the router must take special action, either 5717 updating the LSA or in some cases flushing it from the 5718 routing domain. For a description of how self-originated 5719 LSAs are detected and subsequently handled, see Section 5720 13.4. 5722 (6) Else, if there is an instance of the LSA on the sending 5723 neighbor's Link state request list, an error has occurred in the 5724 Database Exchange process. In this case, restart the Database 5725 Exchange process by generating the neighbor event BadLSReq for 5726 the sending neighbor and stop processing the Link State Update 5727 packet. 5729 (7) Else, if the received LSA is the same instance as the database 5730 copy (i.e., neither one is more recent) the following two steps 5731 should be performed: 5733 (a) If the LSA is listed in the Link state retransmission list 5734 for the receiving adjacency, the router itself is expecting 5735 an acknowledgment for this LSA. The router should treat the 5736 received LSA as an acknowledgment by removing the LSA from 5737 the Link state retransmission list. This is termed an 5738 "implied acknowledgment". Its occurrence should be noted 5739 for later use by the acknowledgment process (Section 13.5). 5741 (b) Possibly acknowledge the receipt of the LSA by sending a 5742 Link State Acknowledgment packet back out the receiving 5743 interface. This is explained below in Section 13.5. 5745 (8) Else, the database copy is more recent. If the database copy 5746 has LS age equal to MaxAge and LS sequence number equal to 5747 MaxSequenceNumber, simply discard the received LSA without 5748 acknowledging it. (In this case, the LSA's LS sequence number is 5749 wrapping, and the MaxSequenceNumber LSA must be completely 5750 flushed before any new LSA instance can be introduced). 5751 Otherwise, as long as the database copy has not been sent in a 5752 Link State Update within the last MinLSArrival seconds, send the 5753 database copy back to the sending neighbor, encapsulated within 5754 a Link State Update Packet. The Link State Update Packet should 5755 be sent directly to the neighbor. In so doing, do not put the 5756 database copy of the LSA on the neighbor's link state 5757 retransmission list, and do not acknowledge the received (less 5758 recent) LSA instance. 5760 13.1. Determining which LSA is newer 5762 When a router encounters two instances of an LSA, it must 5763 determine which is more recent. This occurred above when 5764 comparing a received LSA to its database copy. This comparison 5765 must also be done during the Database Exchange procedure which 5766 occurs during adjacency bring-up. 5768 An LSA is identified by its LS type, Link State ID and 5769 Advertising Router. For two instances of the same LSA, the LS 5770 sequence number, LS age, and LS checksum fields are used to 5771 determine which instance is more recent: 5773 o The LSA having the newer LS sequence number is more recent. 5774 See Section 12.1.6 for an explanation of the LS sequence 5775 number space. If both instances have the same LS sequence 5776 number, then: 5778 o If the two instances have different LS checksums, then the 5779 instance having the larger LS checksum (when considered as a 5780 16-bit unsigned integer) is considered more recent. 5782 o Else, if only one of the instances has its LS age field set 5783 to MaxAge, the instance of age MaxAge is considered to be 5784 more recent. 5786 o Else, if the LS age fields of the two instances differ by 5787 more than MaxAgeDiff, the instance having the smaller 5788 (younger) LS age is considered to be more recent. 5790 o Else, the two instances are considered to be identical. 5792 13.2. Installing LSAs in the database 5794 Installing a new LSA in the database, either as the result of 5795 flooding or a newly self-originated LSA, may cause the OSPF 5796 routing table structure to be recalculated. The contents of the 5797 new LSA should be compared to the old instance, if present. If 5798 there is no difference, there is no need to recalculate the 5799 routing table. When comparing an LSA to its previous instance, 5800 the following are all considered to be differences in contents: 5802 o The LSA's Options field has changed. 5804 o One of the LSA instances has LS age set to MaxAge, and 5805 the other does not. 5807 o The length field in the LSA header has changed. 5809 o The body of the LSA (i.e., anything outside the 20-byte 5810 LSA header) has changed. Note that this excludes changes 5811 in LS Sequence Number and LS Checksum. 5813 If the contents are different, the following pieces of the 5814 routing table must be recalculated, depending on the new LSA's 5815 LS type field: 5817 Router-LSAs and network-LSAs 5818 The entire routing table must be recalculated, starting with 5819 the shortest path calculations for each area (not just the 5820 area whose link-state database has changed). The reason 5821 that the shortest path calculation cannot be restricted to 5822 the single changed area has to do with the fact that AS 5823 boundary routers may belong to multiple areas. A change in 5824 the area currently providing the best route may force the 5825 router to use an intra-area route provided by a different 5826 area.[19] 5828 Summary-LSAs 5829 The best route to the destination described by the summary- 5830 LSA must be recalculated (see Section 16.5). If this 5831 destination is an AS boundary router, it may also be 5832 necessary to re-examine all the AS-external-LSAs. 5834 AS-external-LSAs 5835 The best route to the destination described by the AS- 5836 external-LSA must be recalculated (see Section 16.6). 5838 Also, any old instance of the LSA must be removed from the 5839 database when the new LSA is installed. This old instance must 5840 also be removed from all neighbors' Link state retransmission 5841 lists (see Section 10). 5843 13.3. Next step in the flooding procedure 5845 When a new (and more recent) LSA has been received, it must be 5846 flooded out some set of the router's interfaces. This section 5847 describes the second part of flooding procedure (the first part 5848 being the processing that occurred in Section 13), namely, 5849 selecting the outgoing interfaces and adding the LSA to the 5850 appropriate neighbors' Link state retransmission lists. Also 5851 included in this part of the flooding procedure is the 5852 maintenance of the neighbors' Link state request lists. 5854 This section is equally applicable to the flooding of an LSA 5855 that the router itself has just originated (see Section 12.4). 5856 For these LSAs, this section provides the entirety of the 5857 flooding procedure (i.e., the processing of Section 13 is not 5858 performed, since, for example, the LSA has not been received 5859 from a neighbor and therefore does not need to be acknowledged). 5861 Depending upon the LSA's LS type, the LSA can be flooded out 5862 only certain interfaces. These interfaces, defined by the 5863 following, are called the eligible interfaces: 5865 AS-external-LSAs (LS Type = 5) 5866 AS-external-LSAs are flooded throughout the entire AS, with 5867 the exception of stub areas (see Section 3.6). The eligible 5868 interfaces are all the router's interfaces, excluding 5869 virtual links and those interfaces attaching to stub areas. 5871 All other LS types 5872 All other types are specific to a single area (Area A). The 5873 eligible interfaces are all those interfaces attaching to 5874 the Area A. If Area A is the backbone, this includes all 5875 the virtual links. 5877 Link state databases must remain synchronized over all 5878 adjacencies associated with the above eligible interfaces. This 5879 is accomplished by executing the following steps on each 5880 eligible interface. It should be noted that this procedure may 5881 decide not to flood an LSA out a particular interface, if there 5882 is a high probability that the attached neighbors have already 5883 received the LSA. However, in these cases the flooding 5884 procedure must be absolutely sure that the neighbors eventually 5885 do receive the LSA, so the LSA is still added to each 5886 adjacency's Link state retransmission list. For each eligible 5887 interface: 5889 (1) Each of the neighbors attached to this interface are 5890 examined, to determine whether they must receive the new 5891 LSA. The following steps are executed for each neighbor: 5893 (a) If the neighbor is in a lesser state than Exchange, it 5894 does not participate in flooding, and the next neighbor 5895 should be examined. 5897 (b) Else, if the adjacency is not yet full (neighbor state 5898 is Exchange or Loading), examine the Link state request 5899 list associated with this adjacency. If there is an 5900 instance of the new LSA on the list, it indicates that 5901 the neighboring router has an instance of the LSA 5902 already. Compare the new LSA to the neighbor's copy: 5904 o If the new LSA is less recent, then examine the next 5905 neighbor. 5907 o If the two copies are the same instance, then delete 5908 the LSA from the Link state request list, and 5909 examine the next neighbor.[20] 5911 o Else, the new LSA is more recent. Delete the LSA 5912 from the Link state request list. 5914 (c) If the new LSA was received from this neighbor, examine 5915 the next neighbor. 5917 (d) At this point we are not positive that the neighbor has 5918 an up-to-date instance of this new LSA. Add the new LSA 5919 to the Link state retransmission list for the adjacency. 5920 This ensures that the flooding procedure is reliable; 5921 the LSA will be retransmitted at intervals until an 5922 acknowledgment is seen from the neighbor. 5924 (2) The router must now decide whether to flood the new LSA out 5925 this interface. If in the previous step, the LSA was NOT 5926 added to any of the Link state retransmission lists, there 5927 is no need to flood the LSA out the interface and the next 5928 interface should be examined. 5930 (3) If the new LSA was received on this interface, and it was 5931 received from either the Designated Router or the Backup 5932 Designated Router, chances are that all the neighbors have 5933 received the LSA already. Therefore, examine the next 5934 interface. 5936 (4) If the new LSA was received on this interface, and the 5937 interface state is Backup (i.e., the router itself is the 5938 Backup Designated Router), examine the next interface. The 5939 Designated Router will do the flooding on this interface. 5940 However, if the Designated Router fails the router (i.e., 5941 the Backup Designated Router) will end up retransmitting the 5942 updates. 5944 (5) If this step is reached, the LSA must be flooded out the 5945 interface. Send a Link State Update packet (including the 5946 new LSA as contents) out the interface. The LSA's LS age 5947 must be incremented by InfTransDelay (which must be > 0) 5948 when it is copied into the outgoing Link State Update packet 5949 (until the LS age field reaches the maximum value of 5950 MaxAge). 5952 On broadcast networks, the Link State Update packets are 5953 multicast. The destination IP address specified for the 5954 Link State Update Packet depends on the state of the 5955 interface. If the interface state is DR or Backup, the 5956 address AllSPFRouters should be used. Otherwise, the 5957 address AllDRouters should be used. 5959 On non-broadcast networks, separate Link State Update 5960 packets must be sent, as unicasts, to each adjacent neighbor 5961 (i.e., those in state Exchange or greater). The destination 5962 IP addresses for these packets are the neighbors' IP 5963 addresses. 5965 13.4. Receiving self-originated LSAs 5967 It is a common occurrence for a router to receive self- 5968 originated LSAs via the flooding procedure. A self-originated 5969 LSA is detected when either 1) the LSA's Advertising Router is 5970 equal to the router's own Router ID or 2) the LSA is a network- 5971 LSA and its Link State ID is equal to one of the router's own IP 5972 interface addresses. 5974 However, if the received self-originated LSA is newer than the 5975 last instance that the router actually originated, the router 5976 must take special action. The reception of such an LSA 5977 indicates that there are LSAs in the routing domain that were 5978 originated by the router before the last time it was restarted. 5979 In most cases, the router must then advance the LSA's LS 5980 sequence number one past the received LS sequence number, and 5981 originate a new instance of the LSA. 5983 It may be the case the router no longer wishes to originate the 5984 received LSA. Possible examples include: 1) the LSA is a 5985 summary-LSA or AS-external-LSA and the router no longer has an 5986 (advertisable) route to the destination, 2) the LSA is a 5987 network-LSA but the router is no longer Designated Router for 5988 the network or 3) the LSA is a network-LSA whose Link State ID 5989 is one of the router's own IP interface addresses but whose 5990 Advertising Router is not equal to the router's own Router ID 5991 (this latter case should be rare, and it indicates that the 5992 router's Router ID has changed since originating the LSA). In 5993 all these cases, instead of updating the LSA, the LSA should be 5994 flushed from the routing domain by incrementing the received 5995 LSA's LS age to MaxAge and reflooding (see Section 14.1). 5997 13.5. Sending Link State Acknowledgment packets 5999 Each newly received LSA must be acknowledged. This is usually 6000 done by sending Link State Acknowledgment packets. However, 6001 acknowledgments can also be accomplished implicitly by sending 6002 Link State Update packets (see step 7a of Section 13). 6004 Many acknowledgments may be grouped together into a single Link 6005 State Acknowledgment packet. Such a packet is sent back out the 6006 interface which received the LSAs. The packet can be sent in 6007 one of two ways: delayed and sent on an interval timer, or sent 6008 directly to a particular neighbor. The particular 6009 acknowledgment strategy used depends on the circumstances 6010 surrounding the receipt of the LSA. 6012 Sending delayed acknowledgments accomplishes several things: 1) 6013 it facilitates the packaging of multiple acknowledgments in a 6014 single Link State Acknowledgment packet, 2) it enables a single 6015 Link State Acknowledgment packet to indicate acknowledgments to 6016 several neighbors at once (through multicasting) and 3) it 6017 randomizes the Link State Acknowledgment packets sent by the 6018 various routers attached to a common network. The fixed 6019 interval between a router's delayed transmissions must be short 6020 (less than RxmtInterval) or needless retransmissions will ensue. 6022 Direct acknowledgments are sent directly to a particular 6023 neighbor in response to the receipt of duplicate LSAs. Direct 6024 acknowledgments are sent immediately when the duplicate is 6025 received. On multi-access networks, these acknowledgments are 6026 sent directly to the neighbor's IP address. 6028 The precise procedure for sending Link State Acknowledgment 6029 packets is described in Table 19. The circumstances surrounding 6030 the receipt of the LSA are listed in the left column. The 6031 acknowledgment action then taken is listed in one of the two 6032 right columns. This action depends on the state of the 6033 concerned interface; interfaces in state Backup behave 6034 differently from interfaces in all other states. Delayed 6035 acknowledgments must be delivered to all adjacent routers 6036 associated with the interface. On broadcast networks, this is 6037 accomplished by sending the delayed Link State Acknowledgment 6038 packets as multicasts. The Destination IP address used depends 6039 on the state of the interface. If the interface state is DR or 6040 Backup, the destination AllSPFRouters is used. In all other 6041 states, the destination AllDRouters is used. On non-broadcast 6042 networks, delayed Link State Acknowledgment packets must be 6043 unicast separately over each adjacency (i.e., neighbor whose 6044 state is >= Exchange). 6046 The reasoning behind sending the above packets as multicasts is 6047 best explained by an example. Consider the network 6048 configuration depicted in Figure 15. Suppose RT4 has been 6049 elected as Designated Router, and RT3 as Backup Designated 6050 Router for the network N3. When Router RT4 floods a new LSA to 6051 Network N3, it is received by routers RT1, RT2, and RT3. These 6052 routers will not flood the LSA back onto net N3, but they still 6053 must ensure that their link-state databases remain synchronized 6054 with their adjacent neighbors. So RT1, RT2, and RT4 are waiting 6055 to see an acknowledgment from RT3. Likewise, RT4 and RT3 are 6056 Action taken in state 6057 Circumstances Backup All other states 6058 _________________________________________________________________ 6059 LSA has No acknowledgment No acknowledgment 6060 been flooded back sent. sent. 6061 out receiving in- 6062 terface (see Sec- 6063 tion 13, step 5b). 6064 _________________________________________________________________ 6065 LSA is Delayed acknowledg- Delayed ack- 6066 more recent than ment sent if adver- nowledgment sent. 6067 database copy, but tisement received 6068 was not flooded from Designated 6069 back out receiving Router, otherwise 6070 interface do nothing 6071 _________________________________________________________________ 6072 LSA is a Delayed acknowledg- No acknowledgment 6073 duplicate, and was ment sent if adver- sent. 6074 treated as an im- tisement received 6075 plied acknowledg- from Designated 6076 ment (see Section Router, otherwise 6077 13, step 7a). do nothing 6078 _________________________________________________________________ 6079 LSA is a Direct acknowledg- Direct acknowledg- 6080 duplicate, and was ment sent. ment sent. 6081 not treated as an 6082 implied ack- 6083 nowledgment. 6084 _________________________________________________________________ 6085 LSA's LS Direct acknowledg- Direct acknowledg- 6086 age is equal to ment sent. ment sent. 6087 MaxAge, and there is 6088 no current instance 6089 of the LSA 6090 in the link state 6091 database, and none 6092 of router's neighbors 6093 are in states Exchange 6094 or Loading (see 6095 Section 13, step 4). 6097 Table 19: Sending link state acknowledgements. 6099 both waiting to see acknowledgments from RT1 and RT2. This is 6100 best achieved by sending the acknowledgments as multicasts. 6102 The reason that the acknowledgment logic for Backup DRs is 6103 slightly different is because they perform differently during 6104 the flooding of LSAs (see Section 13.3, step 4). 6106 13.6. Retransmitting LSAs 6108 LSAs flooded out an adjacency are placed on the adjacency's Link 6109 state retransmission list. In order to ensure that flooding is 6110 reliable, these LSAs are retransmitted until they are 6111 acknowledged. The length of time between retransmissions is a 6112 configurable per-interface value, RxmtInterval. If this is set 6113 too low for an interface, needless retransmissions will ensue. 6114 If the value is set too high, the speed of the flooding, in the 6115 face of lost packets, may be affected. 6117 Several retransmitted LSAs may fit into a single Link State 6118 Update packet. When LSAs are to be retransmitted, only the 6119 number fitting in a single Link State Update packet should be 6120 sent. Another packet of retransmissions can be sent whenever 6121 some of the LSAs are acknowledged, or on the next firing of the 6122 retransmission timer. 6124 Link State Update Packets carrying retransmissions are always 6125 sent directly to the neighbor. On multi-access networks, this 6126 means that retransmissions are sent directly to the neighbor's 6127 IP address. Each LSA's LS age must be incremented by 6128 InfTransDelay (which must be > 0) when it is copied into the 6129 outgoing Link State Update packet (until the LS age field 6130 reaches the maximum value of MaxAge). 6132 If an adjacent router goes down, retransmissions may occur until 6133 the adjacency is destroyed by OSPF's Hello Protocol. When the 6134 adjacency is destroyed, the Link state retransmission list is 6135 cleared. 6137 13.7. Receiving link state acknowledgments 6139 Many consistency checks have been made on a received Link State 6140 Acknowledgment packet before it is handed to the flooding 6141 procedure. In particular, it has been associated with a 6142 particular neighbor. If this neighbor is in a lesser state than 6143 Exchange, the Link State Acknowledgment packet is discarded. 6145 Otherwise, for each acknowledgment in the Link State 6146 Acknowledgment packet, the following steps are performed: 6148 o Does the LSA acknowledged have an instance on the Link state 6149 retransmission list for the neighbor? If not, examine the 6150 next acknowledgment. Otherwise: 6152 o If the acknowledgment is for the same instance that is 6153 contained on the list, remove the item from the list and 6154 examine the next acknowledgment. Otherwise: 6156 o Log the questionable acknowledgment, and examine the next 6157 one. 6159 14. Aging The Link State Database 6161 Each LSA has an LS age field. The LS age is expressed in seconds. 6162 An LSA's LS age field is incremented while it is contained in a 6163 router's database. Also, when copied into a Link State Update 6164 Packet for flooding out a particular interface, the LSA's LS age is 6165 incremented by InfTransDelay. 6167 An LSA's LS age is never incremented past the value MaxAge. LSAs 6168 having age MaxAge are not used in the routing table calculation. As 6169 a router ages its link state database, an LSA's LS age may reach 6170 MaxAge.[21] At this time, the router must attempt to flush the LSA 6171 from the routing domain. This is done simply by reflooding the 6172 MaxAge LSA just as if it was a newly originated LSA (see Section 6173 13.3). 6175 When creating a Database summary list for a newly forming adjacency, 6176 any MaxAge LSAs present in the link state database are added to the 6177 neighbor's Link state retransmission list instead of the neighbor's 6178 Database summary list. See Section 10.3 for more details. 6180 A MaxAge LSA must be removed immediately from the router's link 6181 state database as soon as both a) it is no longer contained on any 6182 neighbor Link state retransmission lists and b) none of the router's 6183 neighbors are in states Exchange or Loading. 6185 When, in the process of aging the link state database, an LSA's LS 6186 age hits a multiple of CheckAge, its LS checksum should be verified. 6187 If the LS checksum is incorrect, a program or memory error has been 6188 detected, and at the very least the router itself should be 6189 restarted. 6191 14.1. Premature aging of LSAs 6193 An LSA can be flushed from the routing domain by setting its LS 6194 age to MaxAge, while leaving its LS sequence number alone, and 6195 then reflooding the LSA. This procedure follows the same course 6196 as flushing an LSA whose LS age has naturally reached the value 6197 MaxAge (see Section 14). In particular, the MaxAge LSA is 6198 removed from the router's link state database as soon as a) it 6199 is no longer contained on any neighbor Link state retransmission 6200 lists and b) none of the router's neighbors are in states 6201 Exchange or Loading. We call the setting of an LSA's LS age to 6202 MaxAge "premature aging". 6204 Premature aging is used when it is time for a self-originated 6205 LSA's sequence number field to wrap. At this point, the current 6206 LSA instance (having LS sequence number MaxSequenceNumber) must 6207 be prematurely aged and flushed from the routing domain before a 6208 new instance with sequence number equal to InitialSequenceNumber 6209 can be originated. See Section 12.1.6 for more information. 6211 Premature aging can also be used when, for example, one of the 6212 router's previously advertised external routes is no longer 6213 reachable. In this circumstance, the router can flush its AS- 6214 external-LSA from the routing domain via premature aging. This 6215 procedure is preferable to the alternative, which is to 6216 originate a new LSA for the destination specifying a metric of 6217 LSInfinity. Premature aging is also be used when unexpectedly 6218 receiving self-originated LSAs during the flooding procedure 6219 (see Section 13.4). 6221 A router may only prematurely age its own self-originated LSAs. 6222 The router may not prematurely age LSAs that have been 6223 originated by other routers. An LSA is considered self- 6224 originated when either 1) the LSA's Advertising Router is equal 6225 to the router's own Router ID or 2) the LSA is a network-LSA and 6226 its Link State ID is equal to one of the router's own IP 6227 interface addresses. 6229 15. Virtual Links 6231 The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, 6232 or some areas of the Autonomous System will become unreachable. To 6233 establish/maintain connectivity of the backbone, virtual links can 6234 be configured through non-backbone areas. Virtual links serve to 6235 connect physically separate components of the backbone. The two 6236 endpoints of a virtual link are area border routers. The virtual 6237 link must be configured in both routers. The configuration 6238 information in each router consists of the other virtual endpoint 6239 (the other area border router), and the non-backbone area the two 6240 routers have in common (called the Transit area). Virtual links 6241 cannot be configured through stub areas (see Section 3.6). 6243 The virtual link is treated as if it were an unnumbered point-to- 6244 point network belonging to the backbone and joining the two area 6245 border routers. An attempt is made to establish an adjacency over 6246 the virtual link. When this adjacency is established, the virtual 6247 link will be included in backbone router-LSAs, and OSPF packets 6248 pertaining to the backbone area will flow over the adjacency. Such 6249 an adjacency has been referred to in this document as a "virtual 6250 adjacency". 6252 In each endpoint router, the cost and viability of the virtual link 6253 is discovered by examining the routing table entry for the other 6254 endpoint router. (The entry's associated area must be the 6255 configured Transit area). This is called the virtual link's 6256 corresponding routing table entry. The InterfaceUp event occurs for 6257 a virtual link when its corresponding routing table entry becomes 6258 reachable. Conversely, the InterfaceDown event occurs when its 6259 routing table entry becomes unreachable. In other words, the 6260 virtual link's viability is determined by the existence of an 6261 intra-area path, through the Transit area, between the two 6262 endpoints. Note that a virtual link whose underlying path has cost 6263 greater than hexadecimal 0xffff (the maximum size of an interface 6264 cost in a router-LSA) should be considered inoperational (i.e., 6265 treated the same as if the path did not exist). 6267 The other details concerning virtual links are as follows: 6269 o AS-external-LSAs are NEVER flooded over virtual adjacencies. 6270 This would be duplication of effort, since the same AS- 6271 external-LSAs are already flooded throughout the virtual link's 6272 Transit area. For this same reason, AS-external-LSAs are not 6273 summarized over virtual adjacencies during the Database Exchange 6274 process. 6276 o The cost of a virtual link is NOT configured. It is defined to 6277 be the cost of the intra-area path between the two defining area 6278 border routers. This cost appears in the virtual link's 6279 corresponding routing table entry. When the cost of a virtual 6280 link changes, a new router-LSA should be originated for the 6281 backbone area. 6283 o Just as the virtual link's cost and viability are determined by 6284 the routing table build process (through construction of the 6285 routing table entry for the other endpoint), so are the IP 6286 interface address for the virtual interface and the virtual 6287 neighbor's IP address. These are used when sending OSPF 6288 protocol packets over the virtual link. Note that when one (or 6289 both) of the virtual link endpoints connect to the Transit area 6290 via an unnumbered point-to-point link, it may be impossible to 6291 calculate either the virtual interface's IP address and/or the 6292 virtual neighbor's IP address, thereby causing the virtual link 6293 to fail. 6295 o In each endpoint's router-LSA for the backbone, the virtual link 6296 is represented as a Type 4 link whose Link ID is set to the 6297 virtual neighbor's OSPF Router ID and whose Link Data is set to 6298 the virtual interface's IP address. See Section 12.4.1 for more 6299 information. 6301 o A non-backbone area can carry transit data traffic (i.e., is 6302 considered a "transit area") if and only if it serves as the 6303 Transit area for one or more fully adjacent virtual links (see 6304 TransitCapability in Sections 6 and 16.1). Such an area requires 6305 special treatment when summarizing backbone networks into it 6306 (see Section 12.4.3), and during the routing calculation (see 6307 Section 16.3). 6309 o The time between link state retransmissions, RxmtInterval, is 6310 configured for a virtual link. This should be well over the 6311 expected round-trip delay between the two routers. This may be 6312 hard to estimate for a virtual link; it is better to err on the 6313 side of making it too large. 6315 16. Calculation of the routing table 6317 This section details the OSPF routing table calculation. Using its 6318 attached areas' link state databases as input, a router runs the 6319 following algorithm, building its routing table step by step. At 6320 each step, the router must access individual pieces of the link 6321 state databases (e.g., a router-LSA originated by a certain router). 6322 This access is performed by the lookup function discussed in Section 6323 12.2. The lookup process may return an LSA whose LS age is equal to 6324 MaxAge. Such an LSA should not be used in the routing table 6325 calculation, and is treated just as if the lookup process had 6326 failed. 6328 The OSPF routing table's organization is explained in Section 11. 6329 Two examples of the routing table build process are presented in 6330 Sections 11.2 and 11.3. This process can be broken into the 6331 following steps: 6333 (1) The present routing table is invalidated. The routing table is 6334 built again from scratch. The old routing table is saved so 6335 that changes in routing table entries can be identified. 6337 (2) The intra-area routes are calculated by building the shortest- 6338 path tree for each attached area. In particular, all routing 6339 table entries whose Destination Type is "area border router" are 6340 calculated in this step. This step is described in two parts. 6341 At first the tree is constructed by only considering those links 6342 between routers and transit networks. Then the stub networks 6343 are incorporated into the tree. During the area's shortest-path 6344 tree calculation, the area's TransitCapability is also 6345 calculated for later use in Step 4. 6347 (3) The inter-area routes are calculated, through examination of 6348 summary-LSAs. If the router is attached to multiple areas 6349 (i.e., it is an area border router), only backbone summary-LSAs 6350 are examined. 6352 (4) In area border routers connecting to one or more transit areas 6353 (i.e, non-backbone areas whose TransitCapability is found to be 6354 TRUE), the transit areas' summary-LSAs are examined to see 6355 whether better paths exist using the transit areas than were 6356 found in Steps 2-3 above. 6358 (5) Routes to external destinations are calculated, through 6359 examination of AS-external-LSAs. The locations of the AS 6360 boundary routers (which originate the AS-external-LSAs) have 6361 been determined in steps 2-4. 6363 Steps 2-5 are explained in further detail below. 6365 Changes made to routing table entries as a result of these 6366 calculations can cause the OSPF protocol to take further actions. 6367 For example, a change to an intra-area route will cause an area 6368 border router to originate new summary-LSAs (see Section 12.4). See 6369 Section 16.7 for a complete list of the OSPF protocol actions 6370 resulting from routing table changes. 6372 16.1. Calculating the shortest-path tree for an area 6374 This calculation yields the set of intra-area routes associated 6375 with an area (called hereafter Area A). A router calculates the 6376 shortest-path tree using itself as the root.[22] The formation 6377 of the shortest path tree is done here in two stages. In the 6378 first stage, only links between routers and transit networks are 6379 considered. Using the Dijkstra algorithm, a tree is formed from 6380 this subset of the link state database. In the second stage, 6381 leaves are added to the tree by considering the links to stub 6382 networks. 6384 The procedure will be explained using the graph terminology that 6385 was introduced in Section 2. The area's link state database is 6386 represented as a directed graph. The graph's vertices are 6387 routers, transit networks and stub networks. The first stage of 6388 the procedure concerns only the transit vertices (routers and 6389 transit networks) and their connecting links. Throughout the 6390 shortest path calculation, the following data is also associated 6391 with each transit vertex: 6393 Vertex (node) ID 6394 A 32-bit number which together with the vertex type (router 6395 or network) uniquely identifies the vertex. For router 6396 vertices the Vertex ID is the router's OSPF Router ID. For 6397 network vertices, it is the IP address of the network's 6398 Designated Router. 6400 An LSA 6401 Each transit vertex has an associated LSA. For router 6402 vertices, this is a router-LSA. For transit networks, this 6403 is a network-LSA (which is actually originated by the 6404 network's Designated Router). In any case, the LSA's Link 6405 State ID is always equal to the above Vertex ID. 6407 List of next hops 6408 The list of next hops for the current set of shortest paths 6409 from the root to this vertex. There can be multiple 6410 shortest paths due to the equal-cost multipath capability. 6411 Each next hop indicates the outgoing router interface to use 6412 when forwarding traffic to the destination. On broadcast, 6413 Point-to-MultiPoint and NBMA networks, the next hop also 6414 includes the IP address of the next router (if any) in the 6415 path towards the destination. 6417 Distance from root 6418 The link state cost of the current set of shortest paths 6419 from the root to the vertex. The link state cost of a path 6420 is calculated as the sum of the costs of the path's 6421 constituent links (as advertised in router-LSAs and 6422 network-LSAs). One path is said to be "shorter" than 6423 another if it has a smaller link state cost. 6425 The first stage of the procedure (i.e., the Dijkstra algorithm) 6426 can now be summarized as follows. At each iteration of the 6427 algorithm, there is a list of candidate vertices. Paths from 6428 the root to these vertices have been found, but not necessarily 6429 the shortest ones. However, the paths to the candidate vertex 6430 that is closest to the root are guaranteed to be shortest; this 6431 vertex is added to the shortest-path tree, removed from the 6432 candidate list, and its adjacent vertices are examined for 6433 possible addition to/modification of the candidate list. The 6434 algorithm then iterates again. It terminates when the candidate 6435 list becomes empty. 6437 The following steps describe the algorithm in detail. Remember 6438 that we are computing the shortest path tree for Area A. All 6439 references to link state database lookup below are from Area A's 6440 database. 6442 (1) Initialize the algorithm's data structures. Clear the list 6443 of candidate vertices. Initialize the shortest-path tree to 6444 only the root (which is the router doing the calculation). 6445 Set Area A's TransitCapability to FALSE. 6447 (2) Call the vertex just added to the tree vertex V. Examine 6448 the LSA associated with vertex V. This is a lookup in the 6449 Area A's link state database based on the Vertex ID. If 6450 this is a router-LSA, and bit V of the router-LSA (see 6451 Section A.4.2) is set, set Area A's TransitCapability to 6452 TRUE. In any case, each link described by the LSA gives the 6453 cost to an adjacent vertex. For each described link, (say 6454 it joins vertex V to vertex W): 6456 (a) If this is a link to a stub network, examine the next 6457 link in V's LSA. Links to stub networks will be 6458 considered in the second stage of the shortest path 6459 calculation. 6461 (b) Otherwise, W is a transit vertex (router or transit 6462 network). Look up the vertex W's LSA (router-LSA or 6463 network-LSA) in Area A's link state database. If the 6464 LSA does not exist, or its LS age is equal to MaxAge, or 6465 it does not have a link back to vertex V, examine the 6466 next link in V's LSA.[23] 6468 (c) If vertex W is already on the shortest-path tree, 6469 examine the next link in the LSA. 6471 (d) Calculate the link state cost D of the resulting path 6472 from the root to vertex W. D is equal to the sum of the 6473 link state cost of the (already calculated) shortest 6474 path to vertex V and the advertised cost of the link 6475 between vertices V and W. If D is: 6477 o Greater than the value that already appears for 6478 vertex W on the candidate list, then examine the 6479 next link. 6481 o Equal to the value that appears for vertex W on the 6482 candidate list, calculate the set of next hops that 6483 result from using the advertised link. Input to 6484 this calculation is the destination (W), and its 6485 parent (V). This calculation is shown in Section 6486 16.1.1. This set of hops should be added to the 6487 next hop values that appear for W on the candidate 6488 list. 6490 o Less than the value that appears for vertex W on the 6491 candidate list, or if W does not yet appear on the 6492 candidate list, then set the entry for W on the 6493 candidate list to indicate a distance of D from the 6494 root. Also calculate the list of next hops that 6495 result from using the advertised link, setting the 6496 next hop values for W accordingly. The next hop 6497 calculation is described in Section 16.1.1; it takes 6498 as input the destination (W) and its parent (V). 6500 (3) If at this step the candidate list is empty, the shortest- 6501 path tree (of transit vertices) has been completely built 6502 and this stage of the procedure terminates. Otherwise, 6503 choose the vertex belonging to the candidate list that is 6504 closest to the root, and add it to the shortest-path tree 6505 (removing it from the candidate list in the process). Note 6506 that when there is a choice of vertices closest to the root, 6507 network vertices must be chosen before router vertices in 6508 order to necessarily find all equal-cost paths. This is 6509 consistent with the tie-breakers that were introduced in the 6510 modified Dijkstra algorithm used by OSPF's Multicast routing 6511 extensions (MOSPF). 6513 (4) Possibly modify the routing table. For those routing table 6514 entries modified, the associated area will be set to Area A, 6515 the path type will be set to intra-area, and the cost will 6516 be set to the newly discovered shortest path's calculated 6517 distance. 6519 If the newly added vertex is an area border router or AS 6520 boundary router, a routing table entry is added whose 6521 destination type is "router". The Options field found in 6522 the associated router-LSA is copied into the routing table 6523 entry's Optional capabilities field. Call the newly added 6524 vertex Router X. If Router X is the endpoint of one of the 6525 calculating router's virtual links, and the virtual link 6526 uses Area A as Transit area: the virtual link is declared 6527 up, the IP address of the virtual interface is set to the IP 6528 address of the outgoing interface calculated above for 6529 Router X, and the virtual neighbor's IP address is set to 6530 Router X's interface address (contained in Router X's 6531 router-LSA) that points back to the root of the shortest- 6532 path tree; equivalently, this is the interface that points 6533 back to Router X's parent vertex on the shortest-path tree 6534 (similar to the calculation in Section 16.1.1). 6536 If the newly added vertex is a transit network, the routing 6537 table entry for the network is located. The entry's 6538 Destination ID is the IP network number, which can be 6539 obtained by masking the Vertex ID (Link State ID) with its 6540 associated subnet mask (found in the body of the associated 6541 network-LSA). If the routing table entry already exists 6542 (i.e., there is already an intra-area route to the 6543 destination installed in the routing table), multiple 6544 vertices have mapped to the same IP network. For example, 6545 this can occur when a new Designated Router is being 6546 established. In this case, the current routing table entry 6547 should be overwritten if and only if the newly found path is 6548 just as short and the current routing table entry's Link 6549 State Origin has a smaller Link State ID than the newly 6550 added vertex' LSA. 6552 If there is no routing table entry for the network (the 6553 usual case), a routing table entry for the IP network should 6554 be added. The routing table entry's Link State Origin 6555 should be set to the newly added vertex' LSA. 6557 (5) Iterate the algorithm by returning to Step 2. 6559 The stub networks are added to the tree in the procedure's 6560 second stage. In this stage, all router vertices are again 6561 examined. Those that have been determined to be unreachable in 6562 the above first phase are discarded. For each reachable router 6563 vertex (call it V), the associated router-LSA is found in the 6564 link state database. Each stub network link appearing in the 6565 LSA is then examined, and the following steps are executed: 6567 (1) Calculate the distance D of stub network from the root. D 6568 is equal to the distance from the root to the router vertex 6569 (calculated in stage 1), plus the stub network link's 6570 advertised cost. Compare this distance to the current best 6571 cost to the stub network. This is done by looking up the 6572 stub network's current routing table entry. If the 6573 calculated distance D is larger, go on to examine the next 6574 stub network link in the LSA. 6576 (2) If this step is reached, the stub network's routing table 6577 entry must be updated. Calculate the set of next hops that 6578 would result from using the stub network link. This 6579 calculation is shown in Section 16.1.1; input to this 6580 calculation is the destination (the stub network) and the 6581 parent vertex (the router vertex). If the distance D is the 6582 same as the current routing table cost, simply add this set 6583 of next hops to the routing table entry's list of next hops. 6584 In this case, the routing table already has a Link State 6585 Origin. If this Link State Origin is a router-LSA whose 6586 Link State ID is smaller than V's Router ID, reset the Link 6587 State Origin to V's router-LSA. 6589 Otherwise D is smaller than the routing table cost. 6590 Overwrite the current routing table entry by setting the 6591 routing table entry's cost to D, and by setting the entry's 6592 list of next hops to the newly calculated set. Set the 6593 routing table entry's Link State Origin to V's router-LSA. 6594 Then go on to examine the next stub network link. 6596 For all routing table entries added/modified in the second 6597 stage, the associated area will be set to Area A and the path 6598 type will be set to intra-area. When the list of reachable 6599 router-LSAs is exhausted, the second stage is completed. At 6600 this time, all intra-area routes associated with Area A have 6601 been determined. 6603 The specification does not require that the above two stage 6604 method be used to calculate the shortest path tree. However, if 6605 another algorithm is used, an identical tree must be produced. 6606 For this reason, it is important to note that links between 6607 transit vertices must be bidirectional in order to be included 6608 in the above tree. It should also be mentioned that more 6609 efficient algorithms exist for calculating the tree; for 6610 example, the incremental SPF algorithm described in [Ref1]. 6612 16.1.1. The next hop calculation 6614 This section explains how to calculate the current set of 6615 next hops to use for a destination. Each next hop consists 6616 of the outgoing interface to use in forwarding packets to 6617 the destination together with the IP address of the next hop 6618 router (if any). The next hop calculation is invoked each 6619 time a shorter path to the destination is discovered. This 6620 can happen in either stage of the shortest-path tree 6621 calculation (see Section 16.1). In stage 1 of the 6622 shortest-path tree calculation a shorter path is found as 6623 the destination is added to the candidate list, or when the 6624 destination's entry on the candidate list is modified (Step 6625 2d of Stage 1). In stage 2 a shorter path is discovered 6626 each time the destination's routing table entry is modified 6627 (Step 2 of Stage 2). 6629 The set of next hops to use for the destination may be 6630 recalculated several times during the shortest-path tree 6631 calculation, as shorter and shorter paths are discovered. 6632 In the end, the destination's routing table entry will 6633 always reflect the next hops resulting from the absolute 6634 shortest path(s). 6636 Input to the next hop calculation is a) the destination and 6637 b) its parent in the current shortest path between the root 6638 (the calculating router) and the destination. The parent is 6639 always a transit vertex (i.e., always a router or a transit 6640 network). 6642 If there is at least one intervening router in the current 6643 shortest path between the destination and the root, the 6644 destination simply inherits the set of next hops from the 6645 parent. Otherwise, there are two cases. In the first case, 6646 the parent vertex is the root (the calculating router 6647 itself). This means that the destination is either a 6648 directly connected network or directly connected router. 6649 The outgoing interface in this case is simply the OSPF 6650 interface connecting to the destination network/router. If 6651 the destination is a router which connects to the 6652 calculating router via a Point-to-MultiPoint network, the 6653 destination's next hop IP address(es) can be determined by 6654 examining the destination's router-LSA: each link pointing 6655 back to the calculating router and having a Link Data field 6656 belonging to the Point-to-MultiPoint network provides an IP 6657 address of the next hop router. If the destination is a 6658 directly connected network, or a router which connects to 6659 the calculating router via a point-to-point interface, no 6660 next hop IP address is required. If the destination is a 6661 router connected to the calculating router via a virtual 6662 link, the setting of the next hop should be deferred until 6663 the calculation in Section 16.3. 6665 In the second case, the parent vertex is a network that 6666 directly connects the calculating router to the destination 6667 router. The list of next hops is then determined by 6668 examining the destination's router-LSA. For each link in 6669 the router-LSA that points back to the parent network, the 6670 link's Link Data field provides the IP address of a next hop 6671 router. The outgoing interface to use can then be derived 6672 from the next hop IP address (or it can be inherited from 6673 the parent network). 6675 16.2. Calculating the inter-area routes 6677 The inter-area routes are calculated by examining summary-LSAs. 6678 If the router has active attachments to multiple areas, only 6679 backbone summary-LSAs are examined. Routers attached to a 6680 single area examine that area's summary-LSAs. In either case, 6681 the summary-LSAs examined below are all part of a single area's 6682 link state database (call it Area A). 6684 Summary-LSAs are originated by the area border routers. Each 6685 summary-LSA in Area A is considered in turn. Remember that the 6686 destination described by a summary-LSA is either a network (Type 6687 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). 6688 For each summary-LSA: 6690 (1) If the cost specified by the LSA is LSInfinity, or if the 6691 LSA's LS age is equal to MaxAge, then examine the the next 6692 LSA. 6694 (2) If the LSA was originated by the calculating router itself, 6695 examine the next LSA. 6697 (3) If it is a Type 3 summary-LSA, and the collection of 6698 destinations described by the summary-LSA equals one of the 6699 router's configured area address ranges (see Section 3.5), 6700 and the particular area address range is active, then the 6701 summary-LSA should be ignored. "Active" means that there 6702 are one or more reachable (by intra-area paths) networks 6703 contained in the area range. 6705 (4) Else, call the destination described by the LSA N (for Type 6706 3 summary-LSAs, N's address is obtained by masking the LSA's 6707 Link State ID with the network/subnet mask contained in the 6708 body of the LSA), and the area border originating the LSA 6709 BR. Look up the routing table entry for BR having Area A as 6710 its associated area. If no such entry exists for router BR 6711 (i.e., BR is unreachable in Area A), do nothing with this 6712 LSA and consider the next in the list. Else, this LSA 6713 describes an inter-area path to destination N, whose cost is 6714 the distance to BR plus the cost specified in the LSA. Call 6715 the cost of this inter-area path IAC. 6717 (5) Next, look up the routing table entry for the destination N. 6718 (If N is an AS boundary router, look up the "router" routing 6719 table entry associated with Area A). If no entry exists for 6720 N or if the entry's path type is "type 1 external" or "type 6721 2 external", then install the inter-area path to N, with 6722 associated area Area A, cost IAC, next hop equal to the list 6723 of next hops to router BR, and Advertising router equal to 6724 BR. 6726 (6) Else, if the paths present in the table are intra-area 6727 paths, do nothing with the LSA (intra-area paths are always 6728 preferred). 6730 (7) Else, the paths present in the routing table are also 6731 inter-area paths. Install the new path through BR if it is 6732 cheaper, overriding the paths in the routing table. 6733 Otherwise, if the new path is the same cost, add it to the 6734 list of paths that appear in the routing table entry. 6736 16.3. Examining transit areas' summary-LSAs 6738 This step is only performed by area border routers attached to 6739 one or more non-backbone areas that are capable of carrying 6740 transit traffic (i.e., "transit areas", or those areas whose 6741 TransitCapability parameter has been set to TRUE in Step 2 of 6742 the Dijkstra algorithm (see Section 16.1). 6744 The purpose of the calculation below is to examine the transit 6745 areas to see whether they provide any better (shorter) paths 6746 than the paths previously calculated in Sections 16.1 and 16.2. 6747 Any paths found that are better than or equal to previously 6748 discovered paths are installed in the routing table. 6750 The calculation also determines the actual next hop(s) for those 6751 destinations whose next hop was calculated as a virtual link in 6752 Sections 16.1 and 16.2. After completion of the calculation 6753 below, any paths calculated in Sections 16.1 and 16.2 that still 6754 have unresolved virtual next hops should be discarded. 6756 The calculation proceeds as follows. All the transit areas' 6757 summary-LSAs are examined in turn. Each such summary-LSA 6758 describes a route through a transit area Area A to a Network N 6759 (N's address is obtained by masking the LSA's Link State ID with 6760 the network/subnet mask contained in the body of the LSA) or in 6761 the case of a Type 4 summary-LSA, to an AS boundary router N. 6762 Suppose also that the summary-LSA was originated by an area 6763 border router BR. 6765 (1) If the cost advertised by the summary-LSA is LSInfinity, or 6766 if the LSA's LS age is equal to MaxAge, then examine the 6767 next LSA. 6769 (2) If the summary-LSA was originated by the calculating router 6770 itself, examine the next LSA. 6772 (3) Look up the routing table entry for N. (If N is an AS 6773 boundary router, look up the "router" routing table entry 6774 associated with the backbone area). If it does not exist, or 6775 if the route type is other than intra-area or inter-area, or 6776 if the area associated with the routing table entry is not 6777 the backbone area, then examine the next LSA. In other 6778 words, this calculation only updates backbone intra-area 6779 routes found in Section 16.1 and inter-area routes found in 6780 Section 16.2. 6782 (4) Look up the routing table entry for the advertising router 6783 BR associated with the Area A. If it is unreachable, examine 6784 the next LSA. Otherwise, the cost to destination N is the 6785 sum of the cost in BR's Area A routing table entry and the 6786 cost advertised in the LSA. Call this cost IAC. 6788 (5) If this cost is less than the cost occurring in N's routing 6789 table entry, overwrite N's list of next hops with those used 6790 for BR, and set N's routing table cost to IAC. Else, if IAC 6791 is the same as N's current cost, add BR's list of next hops 6792 to N's list of next hops. In any case, the area associated 6793 with N's routing table entry must remain the backbone area, 6794 and the path type (either intra-area or inter-area) must 6795 also remain the same. 6797 It is important to note that the above calculation never makes 6798 unreachable destinations reachable, but instead just potentially 6799 finds better paths to already reachable destinations. The 6800 ........................ 6801 . Area 1 (transit) . + 6802 . . | 6803 . +---+1 1+---+100 | 6804 . |RT2|----------|RT4|=========| 6805 . 1/+---+********* +---+ | 6806 . /******* . | 6807 . 1/*Virtual . | 6808 1+---+/* Link . Net|work 6809 =======|RT1|* . | N1 6810 +---+\ . | 6811 . \ . | 6812 . \ . | 6813 . 1\+---+1 1+---+20 | 6814 . |RT3|----------|RT5|=========| 6815 . +---+ +---+ | 6816 . . | 6817 ........................ + 6819 Figure 17: Routing through transit areas 6821 calculation installs any better cost found into the routing 6822 table entry, from which it may be readvertised in summary-LSAs 6823 to other areas. 6825 As an example of the calculation, consider the Autonomous System 6826 pictured in Figure 17. There is a single non-backbone area 6827 (Area 1) that physically divides the backbone into two separate 6828 pieces. To maintain connectivity of the backbone, a virtual link 6829 has been configured between routers RT1 and RT4. On the right 6830 side of the figure, Network N1 belongs to the backbone. The 6831 dotted lines indicate that there is a much shorter intra-area 6832 backbone path between router RT5 and Network N1 (cost 20) than 6833 there is between Router RT4 and Network N1 (cost 100). Both 6834 Router RT4 and Router RT5 will inject summary-LSAs for Network 6835 N1 into Area 1. 6837 After the shortest-path tree has been calculated for the 6838 backbone in Section 16.1, Router RT1 (left end of the virtual 6839 link) will have calculated a path through Router RT4 for all 6840 data traffic destined for Network N1. However, since Router RT5 6841 is so much closer to Network N1, all routers internal to Area 1 6842 (e.g., Routers RT2 and RT3) will forward their Network N1 6843 traffic towards Router RT5, instead of RT4. And indeed, after 6844 examining Area 1's summary-LSAs by the above calculation, Router 6845 RT1 will also forward Network N1 traffic towards RT5. Note that 6846 in this example the virtual link enables transit data traffic to 6847 be forwarded through Area 1, but the actual path the transit 6848 data traffic takes does not follow the virtual link. In other 6849 words, virtual links allow transit traffic to be forwarded 6850 through an area, but do not dictate the precise path that the 6851 traffic will take. 6853 16.4. Calculating AS external routes 6855 AS external routes are calculated by examining AS-external-LSAs. 6856 Each of the AS-external-LSAs is considered in turn. Most AS- 6857 external-LSAs describe routes to specific IP destinations. An 6858 AS-external-LSA can also describe a default route for the 6859 Autonomous System (Destination ID = DefaultDestination, 6860 network/subnet mask = 0x00000000). For each AS-external-LSA: 6862 (1) If the cost specified by the LSA is LSInfinity, or if the 6863 LSA's LS age is equal to MaxAge, then examine the next LSA. 6865 (2) If the LSA was originated by the calculating router itself, 6866 examine the next LSA. 6868 (3) Call the destination described by the LSA N. N's address is 6869 obtained by masking the LSA's Link State ID with the 6870 network/subnet mask contained in the body of the LSA. Look 6871 up the routing table entries (potentially one per attached 6872 area) for the AS boundary router (ASBR) that originated the 6873 LSA. If no entries exist for router ASBR (i.e., ASBR is 6874 unreachable), do nothing with this LSA and consider the next 6875 in the list. 6877 Else, this LSA describes an AS external path to destination 6878 N. Examine the forwarding address specified in the AS- 6879 external-LSA. This indicates the IP address to which 6880 packets for the destination should be forwarded. 6882 If the forwarding address is set to 0.0.0.0, packets should 6883 be sent to the ASBR itself. Among the multiple routing table 6884 entries for the ASBR, select the preferred entry as follows. 6885 If RFC1583Compatibility is set to "disabled", prune the set 6886 of routing table entries for the ASBR as described in 6887 Section 16.4.1. In any case, among the remaining routing 6888 table entries, select the routing table entry with the least 6889 cost; when there are multiple least cost routing table 6890 entries the entry whose associated area has the largest OSPF 6891 Area ID (when considered as an unsigned 32-bit integer) is 6892 chosen. 6894 If the forwarding address is non-zero, look up the 6895 forwarding address in the routing table.[24] The matching 6896 routing table entry must specify an intra-area or inter-area 6897 path; if no such path exists, do nothing with the LSA and 6898 consider the next in the list. 6900 (4) Let X be the cost specified by the preferred routing table 6901 entry for the ASBR/forwarding address, and Y the cost 6902 specified in the LSA. X is in terms of the link state 6903 metric, and Y is a type 1 or 2 external metric. 6905 (5) Look up the routing table entry for the destination N. If 6906 no entry exists for N, install the AS external path to N, 6907 with next hop equal to the list of next hops to the 6908 forwarding address, and advertising router equal to ASBR. 6909 If the external metric type is 1, then the path-type is set 6910 to type 1 external and the cost is equal to X+Y. If the 6911 external metric type is 2, the path-type is set to type 2 6912 external, the link state component of the route's cost is X, 6913 and the type 2 cost is Y. 6915 (6) Compare the AS external path described by the LSA with the 6916 existing paths in N's routing table entry, as follows. If 6917 the new path is preferred, it replaces the present paths in 6918 N's routing table entry. If the new path is of equal 6919 preference, it is added to N's routing table entry's list of 6920 paths. 6922 (a) Intra-area and inter-area paths are always preferred 6923 over AS external paths. 6925 (b) Type 1 external paths are always preferred over type 2 6926 external paths. When all paths are type 2 external 6927 paths, the paths with the smallest advertised type 2 6928 metric are always preferred. 6930 (c) If the new AS external path is still indistinguishable 6931 from the current paths in the N's routing table entry, 6932 and RFC1583Compatibility is set to "disabled", select 6933 the preferred paths based on the intra-AS paths to the 6934 ASBR/forwarding addresses, as specified in Section 6935 16.4.1. 6937 (d) If the new AS external path is still indistinguishable 6938 from the current paths in the N's routing table entry, 6939 select the preferred path based on a least cost 6940 comparison. Type 1 external paths are compared by 6941 looking at the sum of the distance to the forwarding 6942 address and the advertised type 1 metric (X+Y). Type 2 6943 external paths advertising equal type 2 metrics are 6944 compared by looking at the distance to the forwarding 6945 addresses. 6947 16.4.1. External path preferences 6949 When multiple intra-AS paths are available to 6950 ASBRs/forwarding addresses, the following rules indicate 6951 which paths are preferred. These rules apply when the same 6952 ASBR is reachable through multiple areas, or when trying to 6953 decide which of several AS-external-LSAs should be 6954 preferred. In the former case the paths all terminate at the 6955 same ASBR, while in the latter the paths terminate at 6956 separate ASBRs/forwarding addresses. In either case, each 6957 path is represented by a separate routing table entry as 6958 defined in Section 11. 6960 This section only applies when RFC1583Compatibility is set 6961 to "disabled". 6963 The path preference rules, stated from highest to lowest 6964 preference, are as follows. Note that as a result of these 6965 rules, there may still be multiple paths of the highest 6966 preference. In this case, the path to use must be determined 6967 based on cost, as described in Section 16.4. 6969 o Intra-area paths using non-backbone areas are always the 6970 most preferred. 6972 o The other paths, intra-area backbone paths and inter- 6973 area paths, are of equal preference. 6975 16.5. Incremental updates -- summary-LSAs 6977 When a new summary-LSA is received, it is not necessary to 6978 recalculate the entire routing table. Call the destination 6979 described by the summary-LSA N (N's address is obtained by 6980 masking the LSA's Link State ID with the network/subnet mask 6981 contained in the body of the LSA), and let Area A be the area to 6982 which the LSA belongs. There are then two separate cases: 6984 Case 1: Area A is the backbone and/or the router is not an area 6985 border router. 6986 In this case, the following calculations must be performed. 6987 First, if there is presently an inter-area route to the 6988 destination N, N's routing table entry is invalidated, 6989 saving the entry's values for later comparisons. Then the 6990 calculation in Section 16.2 is run again for the single 6991 destination N. In this calculation, all of Area A's 6992 summary-LSAs that describe a route to N are examined. In 6993 addition, if the router is an area border router attached to 6994 one or more transit areas, the calculation in Section 16.3 6995 must be run again for the single destination. If the 6996 results of these calculations have changed the cost/path to 6997 an AS boundary router (as would be the case for a Type 4 6998 summary-LSA) or to any forwarding addresses, all AS- 6999 external-LSAs will have to be reexamined by rerunning the 7000 calculation in Section 16.4. Otherwise, if N is now newly 7001 unreachable, the calculation in Section 16.4 must be rerun 7002 for the single destination N, in case an alternate external 7003 route to N exists. 7005 Case 2: Area A is a transit area and the router is an area 7006 border router. 7007 In this case, the following calculations must be performed. 7008 First, if N's routing table entry presently contains one or 7009 more inter-area paths that utilize the transit area Area A, 7010 these paths should be removed. If this removes all paths 7011 from the routing table entry, the entry should be 7012 invalidated. The entry's old values should be saved for 7013 later comparisons. Next the calculation in Section 16.3 must 7014 be run again for the single destination N. If the results of 7015 this calculation have caused the cost to N to increase, the 7016 complete routing table calculation must be rerun starting 7017 with the Dijkstra algorithm specified in Section 16.1. 7018 Otherwise, if the cost/path to an AS boundary router (as 7019 would be the case for a Type 4 summary-LSA) or to any 7020 forwarding addresses has changed, all AS-external-LSAs will 7021 have to be reexamined by rerunning the calculation in 7022 Section 16.4. Otherwise, if N is now newly unreachable, the 7023 calculation in Section 16.4 must be rerun for the single 7024 destination N, in case an alternate external route to N 7025 exists. 7027 16.6. Incremental updates -- AS-external-LSAs 7029 When a new AS-external-LSA is received, it is not necessary to 7030 recalculate the entire routing table. Call the destination 7031 described by the AS-external-LSA N. N's address is obtained by 7032 masking the LSA's Link State ID with the network/subnet mask 7033 contained in the body of the LSA. If there is already an intra- 7034 area or inter-area route to the destination, no recalculation is 7035 necessary (internal routes take precedence). 7037 Otherwise, the procedure in Section 16.4 will have to be 7038 performed, but only for those AS-external-LSAs whose destination 7039 is N. Before this procedure is performed, the present routing 7040 table entry for N should be invalidated. 7042 16.7. Events generated as a result of routing table changes 7044 Changes to routing table entries sometimes cause the OSPF area 7045 border routers to take additional actions. These routers need 7046 to act on the following routing table changes: 7048 o The cost or path type of a routing table entry has changed. 7049 If the destination described by this entry is a Network or 7050 AS boundary router, and this is not simply a change of AS 7051 external routes, new summary-LSAs may have to be generated 7052 (potentially one for each attached area, including the 7053 backbone). See Section 12.4.3 for more information. If a 7054 previously advertised entry has been deleted, or is no 7055 longer advertisable to a particular area, the LSA must be 7056 flushed from the routing domain by setting its LS age to 7057 MaxAge and reflooding (see Section 14.1). 7059 o A routing table entry associated with a configured virtual 7060 link has changed. The destination of such a routing table 7061 entry is an area border router. The change indicates a 7062 modification to the virtual link's cost or viability. 7064 If the entry indicates that the area border router is newly 7065 reachable, the corresponding virtual link is now 7066 operational. An InterfaceUp event should be generated for 7067 the virtual link, which will cause a virtual adjacency to 7068 begin to form (see Section 10.3). At this time the virtual 7069 link's IP interface address and the virtual neighbor's 7070 Neighbor IP address are also calculated. 7072 If the entry indicates that the area border router is no 7073 longer reachable, the virtual link and its associated 7074 adjacency should be destroyed. This means an InterfaceDown 7075 event should be generated for the associated virtual link. 7077 If the cost of the entry has changed, and there is a fully 7078 established virtual adjacency, a new router-LSA for the 7079 backbone must be originated. This in turn may cause further 7080 routing table changes. 7082 16.8. Equal-cost multipath 7084 The OSPF protocol maintains multiple equal-cost routes to all 7085 destinations. This can be seen in the steps used above to 7086 calculate the routing table, and in the definition of the 7087 routing table structure. 7089 Each one of the multiple routes will be of the same type 7090 (intra-area, inter-area, type 1 external or type 2 external), 7091 cost, and will have the same associated area. However, each 7092 route may specify a separate next hop and Advertising router. 7094 There is no requirement that a router running OSPF keep track of 7095 all possible equal-cost routes to a destination. An 7096 implementation may choose to keep only a fixed number of routes 7097 to any given destination. This does not affect any of the 7098 algorithms presented in this specification. 7100 Footnotes 7102 [1]The graph's vertices represent either routers, transit networks, 7103 or stub networks. Since routers may belong to multiple areas, it is 7104 not possible to color the graph's vertices. 7106 [2]It is possible for all of a router's interfaces to be unnumbered 7107 point-to-point links. In this case, an IP address must be assigned 7108 to the router. This address will then be advertised in the router's 7109 router-LSA as a host route. 7111 [3]Note that in these cases both interfaces, the non-virtual and the 7112 virtual, would have the same IP address. 7114 [4]Note that no host route is generated for, and no IP packets can 7115 be addressed to, interfaces to unnumbered point-to-point networks. 7116 This is regardless of such an interface's state. 7118 [5]It is instructive to see what happens when the Designated Router 7119 for the network crashes. Call the Designated Router for the network 7120 RT1, and the Backup Designated Router RT2. If Router RT1 crashes 7121 (or maybe its interface to the network dies), the other routers on 7122 the network will detect RT1's absence within RouterDeadInterval 7123 seconds. All routers may not detect this at precisely the same 7124 time; the routers that detect RT1's absence before RT2 does will, 7125 for a time, select RT2 to be both Designated Router and Backup 7126 Designated Router. When RT2 detects that RT1 is gone it will move 7127 itself to Designated Router. At this time, the remaining router 7128 having highest Router Priority will be selected as Backup Designated 7129 Router. 7131 [6]On point-to-point networks, the lower level protocols indicate 7132 whether the neighbor is up and running. Likewise, existence of the 7133 neighbor on virtual links is indicated by the routing table 7134 calculation. However, in both these cases, the Hello Protocol is 7135 still used. This ensures that communication between the neighbors 7136 is bidirectional, and that each of the neighbors has a functioning 7137 routing protocol layer. 7139 [7]When the identity of the Designated Router is changing, it may be 7140 quite common for a neighbor in this state to send the router a 7141 Database Description packet; this means that there is some momentary 7142 disagreement on the Designated Router's identity. 7144 [8]Note that it is possible for a router to resynchronize any of its 7145 fully established adjacencies by setting the adjacency's state back 7146 to ExStart. This will cause the other end of the adjacency to 7147 process a SeqNumberMismatch event, and therefore to also go back to 7148 ExStart state. 7150 [9]The address space of IP networks and the address space of OSPF 7151 Router IDs may overlap. That is, a network may have an IP address 7152 which is identical (when considered as a 32-bit number) to some 7153 router's Router ID. 7155 [10]"Discard" entries are necessary to ensure that route 7156 summarization at area boundaries will not cause packet looping. 7158 [11]It is assumed that, for two different address ranges matching 7159 the destination, one range is more specific than the other. Non- 7160 contiguous subnet masks can be configured to violate this 7161 assumption. Such subnet mask configurations cannot be handled by the 7162 OSPF protocol. 7164 [12]MaxAgeDiff is an architectural constant. It indicates the 7165 maximum dispersion of ages, in seconds, that can occur for a single 7166 LSA instance as it is flooded throughout the routing domain. If two 7167 LSAs differ by more than this, they are assumed to be different 7168 instances of the same LSA. This can occur when a router restarts 7169 and loses track of the LSA's previous LS sequence number. See 7170 Section 13.4 for more details. 7172 [13]When two LSAs have different LS checksums, they are assumed to 7173 be separate instances. This can occur when a router restarts, and 7174 loses track of the LSA's previous LS sequence number. In the case 7175 where the two LSAs have the same LS sequence number, it is not 7176 possible to determine which LSA is actually newer. However, if the 7177 wrong LSA is accepted as newer, the originating router will simply 7178 originate another instance. See Section 13.4 for further details. 7180 [14]There is one instance where a lookup must be done based on 7181 partial information. This is during the routing table calculation, 7182 when a network-LSA must be found based solely on its Link State ID. 7183 The lookup in this case is still well defined, since no two 7184 network-LSAs can have the same Link State ID. 7186 [15]This is the way RFC 1583 specified point-to-point 7187 representation. It has three advantages: a) it does not require 7188 allocating a subnet to the point-to-point link, b) it tends to bias 7189 the routing so that packets destined for the point-to-point 7190 interface will actually be received over the interface (which is 7191 useful for diagnostic purposes) and c) it allows network 7192 bootstrapping of a neighbor, without requiring that the bootstrap 7193 program contain an OSPF implementation. 7195 [16]This is the more traditional point-to-point representation used 7196 by protocols such as RIP. 7198 [17]This clause covers the case: Inter-area routes are not 7199 summarized to the backbone. This is because inter-area routes are 7200 always associated with the backbone area. 7202 [18]This clause is only invoked when a non-backbone Area A supports 7203 transit data traffic (i.e., has TransitCapability set to TRUE). For 7204 example, in the area configuration of Figure 6, Area 2 can support 7205 transit traffic due to the configured virtual link between Routers 7206 RT10 and RT11. As a result, Router RT11 need only originate a single 7207 summary-LSA into Area 2 (having the collapsed destination N9- 7208 N11,H1), since all of Router RT11's other eligible routes have next 7209 hops belonging to Area 2 itself (and as such only need be advertised 7210 by other area border routers; in this case, Routers RT10 and RT7). 7212 [19]By keeping more information in the routing table, it is possible 7213 for an implementation to recalculate the shortest path tree for only 7214 a single area. In fact, there are incremental algorithms that allow 7215 an implementation to recalculate only a portion of a single area's 7216 shortest path tree [Ref1]. However, these algorithms are beyond the 7217 scope of this specification. 7219 [20]This is how the Link state request list is emptied, which 7220 eventually causes the neighbor state to transition to Full. See 7221 Section 10.9 for more details. 7223 [21]It should be a relatively rare occurrence for an LSA's LS age to 7224 reach MaxAge in this fashion. Usually, the LSA will be replaced by 7225 a more recent instance before it ages out. 7227 [22]Strictly speaking, because of equal-cost multipath, the 7228 algorithm does not create a tree. We continue to use the "tree" 7229 terminology because that is what occurs most often in the existing 7230 literature. 7232 [23]Note that the presence of any link back to V is sufficient; it 7233 need not be the matching half of the link under consideration from V 7234 to W. This is enough to ensure that, before data traffic flows 7235 between a pair of neighboring routers, their link state databases 7236 will be synchronized. 7238 [24]When the forwarding address is non-zero, it should point to a 7239 router belonging to another Autonomous System. See Section 12.4.4 7240 for more details. 7242 References 7244 [Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing 7245 Algorithm Improvements", BBN Technical Report 3803, April 7246 1978. 7248 [Ref2] Digital Equipment Corporation, "Information processing 7249 systems -- Data communications -- Intermediate System to 7250 Intermediate System Intra-Domain Routing Protocol", October 7251 1987. 7253 [Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the 7254 ARPANET", IEEE Transactions on Communications, May 1980. 7256 [Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing 7257 Information", Computer Networks, December 1983. 7259 [Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, 7260 USC/Information Sciences Institute, September 1981. 7262 [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 7263 8073", RFC 905, ISO, April 1984. 7265 [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, 7266 RFC 1112, Stanford University, May 1988. 7268 [Ref8] McCloghrie, K., and M. Rose, "Management Information Base 7269 for network management of TCP/IP-based internets: MIB-II", 7270 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 7271 International, March 1991. 7273 [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 7274 1994. 7276 [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 7277 Inter-Domain Routing (CIDR): an Address Assignment and 7278 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 7279 OARnet, September 1993. 7281 [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 7282 1700, USC/Information Sciences Institute, October 1994. 7284 [Ref12] Almquist, P., "Type of Service in the Internet Protocol 7285 Suite", RFC 1349, July 1992. 7287 [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN 7288 Protocol Handbook, April 1985. 7290 [Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution 7291 Protocol", RFC 1293, January 1992. 7293 [Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 7294 Over Frame Relay Networks", RFC 1586, March 1994. 7296 [Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol 7297 Suite", ACM Computer Communications Review, Volume 19, 7298 Number 2, pp. 32-38, April 1989. 7300 [Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 7301 April 1992. 7303 [Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 7304 Inc., March 1994. 7306 [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 7307 RainbowBridge Communications, Stanford University, March 7308 1994. 7310 [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in 7311 progress. 7313 [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 7314 1793, Cascade, April 1995. 7316 [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 7317 DECWRL, Stanford University, November 1990. 7319 [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 7320 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 7321 Systems, March 1995. 7323 [Ref24] Hinden, R., "Internet Routing Protocol Standardization 7324 Criteria", BBN, October 1991. 7326 [Ref25] Moy, J., "OSPF Version 2", RFC 2178, Cascade Communications 7327 Corp., July 1997. 7329 [Ref26] Rosen, E., "Vulnerabilities of Network Control Protocols: An 7330 Example", Computer Communication Review, July 1981. 7332 A. OSPF data formats 7334 This appendix describes the format of OSPF protocol packets and OSPF 7335 LSAs. The OSPF protocol runs directly over the IP network layer. 7336 Before any data formats are described, the details of the OSPF 7337 encapsulation are explained. 7339 Next the OSPF Options field is described. This field describes 7340 various capabilities that may or may not be supported by pieces of 7341 the OSPF routing domain. The OSPF Options field is contained in OSPF 7342 Hello packets, Database Description packets and in OSPF LSAs. 7344 OSPF packet formats are detailed in Section A.3. A description of 7345 OSPF LSAs appears in Section A.4. 7347 A.1 Encapsulation of OSPF packets 7349 OSPF runs directly over the Internet Protocol's network layer. OSPF 7350 packets are therefore encapsulated solely by IP and local data-link 7351 headers. 7353 OSPF does not define a way to fragment its protocol packets, and 7354 depends on IP fragmentation when transmitting packets larger than 7355 the network MTU. If necessary, the length of OSPF packets can be up 7356 to 65,535 bytes (including the IP header). The OSPF packet types 7357 that are likely to be large (Database Description Packets, Link 7358 State Request, Link State Update, and Link State Acknowledgment 7359 packets) can usually be split into several separate protocol 7360 packets, without loss of functionality. This is recommended; IP 7361 fragmentation should be avoided whenever possible. Using this 7362 reasoning, an attempt should be made to limit the sizes of OSPF 7363 packets sent over virtual links to 576 bytes unless Path MTU 7364 Discovery is being performed (see [Ref22]). 7366 The other important features of OSPF's IP encapsulation are: 7368 o Use of IP multicast. Some OSPF messages are multicast, when 7369 sent over broadcast networks. Two distinct IP multicast 7370 addresses are used. Packets sent to these multicast addresses 7371 should never be forwarded; they are meant to travel a single hop 7372 only. To ensure that these packets will not travel multiple 7373 hops, their IP TTL must be set to 1. 7375 AllSPFRouters 7376 This multicast address has been assigned the value 7377 224.0.0.5. All routers running OSPF should be prepared to 7378 receive packets sent to this address. Hello packets are 7379 always sent to this destination. Also, certain OSPF 7380 protocol packets are sent to this address during the 7381 flooding procedure. 7383 AllDRouters 7384 This multicast address has been assigned the value 7385 224.0.0.6. Both the Designated Router and Backup Designated 7386 Router must be prepared to receive packets destined to this 7387 address. Certain OSPF protocol packets are sent to this 7388 address during the flooding procedure. 7390 o OSPF is IP protocol number 89. This number has been registered 7391 with the Network Information Center. IP protocol number 7392 assignments are documented in [Ref11]. 7394 o All OSPF routing protocol packets are sent using the normal 7395 service TOS value of binary 0000 defined in [Ref12]. 7397 o Routing protocol packets are sent with IP precedence set to 7398 Internetwork Control. OSPF protocol packets should be given 7399 precedence over regular IP data traffic, in both sending and 7400 receiving. Setting the IP precedence field in the IP header to 7401 Internetwork Control [Ref5] may help implement this objective. 7403 A.2 The Options field 7405 The OSPF Options field is present in OSPF Hello packets, Database 7406 Description packets and all LSAs. The Options field enables OSPF 7407 routers to support (or not support) optional capabilities, and to 7408 communicate their capability level to other OSPF routers. Through 7409 this mechanism routers of differing capabilities can be mixed within 7410 an OSPF routing domain. 7412 When used in Hello packets, the Options field allows a router to 7413 reject a neighbor because of a capability mismatch. Alternatively, 7414 when capabilities are exchanged in Database Description packets a 7415 router can choose not to forward certain LSAs to a neighbor because 7416 of its reduced functionality. Lastly, listing capabilities in LSAs 7417 allows routers to forward traffic around reduced functionality 7418 routers, by excluding them from parts of the routing table 7419 calculation. 7421 Five bits of the OSPF Options field have been assigned, although 7422 only one (the E-bit) is described completely by this memo. Each bit 7423 is described briefly below. Routers should reset (i.e. clear) 7424 unrecognized bits in the Options field when sending Hello packets or 7425 Database Description packets and when originating LSAs. Conversely, 7426 routers encountering unrecognized Option bits in received Hello 7427 Packets, Database Description packets or LSAs should ignore the 7428 capability and process the packet/LSA normally. 7430 +------------------------------------+ 7431 | * | * | DC | EA | N/P | MC | E | * | 7432 +------------------------------------+ 7434 The Options field 7436 E-bit 7437 This bit describes the way AS-external-LSAs are flooded, as 7438 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. 7440 MC-bit 7441 This bit describes whether IP multicast datagrams are forwarded 7442 according to the specifications in [Ref18]. 7444 N/P-bit 7445 This bit describes the handling of Type-7 LSAs, as specified in 7446 [Ref19]. 7448 EA-bit 7449 This bit describes the router's willingness to receive and 7450 forward External-Attributes-LSAs, as specified in [Ref20]. 7452 DC-bit 7453 This bit describes the router's handling of demand circuits, as 7454 specified in [Ref21]. 7456 A.3 OSPF Packet Formats 7458 There are five distinct OSPF packet types. All OSPF packet types 7459 begin with a standard 24 byte header. This header is described 7460 first. Each packet type is then described in a succeeding section. 7461 In these sections each packet's division into fields is displayed, 7462 and then the field definitions are enumerated. 7464 All OSPF packet types (other than the OSPF Hello packets) deal with 7465 lists of LSAs. For example, Link State Update packets implement the 7466 flooding of LSAs throughout the OSPF routing domain. Because of 7467 this, OSPF protocol packets cannot be parsed unless the format of 7468 LSAs is also understood. The format of LSAs is described in Section 7469 A.4. 7471 The receive processing of OSPF packets is detailed in Section 8.2. 7472 The sending of OSPF packets is explained in Section 8.1. 7474 A.3.1 The OSPF packet header 7476 Every OSPF packet starts with a standard 24 byte header. This 7477 header contains all the information necessary to determine whether 7478 the packet should be accepted for further processing. This 7479 determination is described in Section 8.2 of the specification. 7481 0 1 2 3 7482 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 7483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7484 | Version # | Type | Packet length | 7485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7486 | Router ID | 7487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7488 | Area ID | 7489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7490 | Checksum | AuType | 7491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7492 | Authentication | 7493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7494 | Authentication | 7495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7497 Version # 7498 The OSPF version number. This specification documents version 2 7499 of the protocol. 7501 Type 7502 The OSPF packet types are as follows. See Sections A.3.2 through 7503 A.3.6 for details. 7505 Type Description 7506 ________________________________ 7507 1 Hello 7508 2 Database Description 7509 3 Link State Request 7510 4 Link State Update 7511 5 Link State Acknowledgment 7512 Packet length 7513 The length of the OSPF protocol packet in bytes. This length 7514 includes the standard OSPF header. 7516 Router ID 7517 The Router ID of the packet's source. 7519 Area ID 7520 A 32 bit number identifying the area that this packet belongs 7521 to. All OSPF packets are associated with a single area. Most 7522 travel a single hop only. Packets travelling over a virtual 7523 link are labelled with the backbone Area ID of 0.0.0.0. 7525 Checksum 7526 The standard IP checksum of the entire contents of the packet, 7527 starting with the OSPF packet header but excluding the 64-bit 7528 authentication field. This checksum is calculated as the 16-bit 7529 one's complement of the one's complement sum of all the 16-bit 7530 words in the packet, excepting the authentication field. If the 7531 packet's length is not an integral number of 16-bit words, the 7532 packet is padded with a byte of zero before checksumming. The 7533 checksum is considered to be part of the packet authentication 7534 procedure; for some authentication types the checksum 7535 calculation is omitted. 7537 AuType 7538 Identifies the authentication procedure to be used for the 7539 packet. Authentication is discussed in Appendix D of the 7540 specification. Consult Appendix D for a list of the currently 7541 defined authentication types. 7543 Authentication 7544 A 64-bit field for use by the authentication scheme. See 7545 Appendix D for details. 7547 A.3.2 The Hello packet 7549 Hello packets are OSPF packet type 1. These packets are sent 7550 periodically on all interfaces (including virtual links) in order to 7551 establish and maintain neighbor relationships. In addition, Hello 7552 Packets are multicast on those physical networks having a multicast 7553 or broadcast capability, enabling dynamic discovery of neighboring 7554 routers. 7556 All routers connected to a common network must agree on certain 7557 parameters (Network mask, HelloInterval and RouterDeadInterval). 7558 These parameters are included in Hello packets, so that differences 7559 can inhibit the forming of neighbor relationships. A detailed 7560 explanation of the receive processing for Hello packets is presented 7561 in Section 10.5. The sending of Hello packets is covered in Section 7562 9.5. 7564 0 1 2 3 7565 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 7566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7567 | Version # | 1 | Packet length | 7568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7569 | Router ID | 7570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7571 | Area ID | 7572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7573 | Checksum | AuType | 7574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7575 | Authentication | 7576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7577 | Authentication | 7578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7579 | Network Mask | 7580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7581 | HelloInterval | Options | Rtr Pri | 7582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7583 | RouterDeadInterval | 7584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7585 | Designated Router | 7586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7587 | Backup Designated Router | 7588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7589 | Neighbor | 7590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7591 | ... | 7593 Network mask 7594 The network mask associated with this interface. For example, 7595 if the interface is to a class B network whose third byte is 7596 used for subnetting, the network mask is 0xffffff00. 7598 Options 7599 The optional capabilities supported by the router, as documented 7600 in Section A.2. 7602 HelloInterval 7603 The number of seconds between this router's Hello packets. 7605 Rtr Pri 7606 This router's Router Priority. Used in (Backup) Designated 7607 Router election. If set to 0, the router will be ineligible to 7608 become (Backup) Designated Router. 7610 RouterDeadInterval 7611 The number of seconds before declaring a silent router down. 7613 Designated Router 7614 The identity of the Designated Router for this network, in the 7615 view of the sending router. The Designated Router is identified 7616 here by its IP interface address on the network. Set to 0.0.0.0 7617 if there is no Designated Router. 7619 Backup Designated Router 7620 The identity of the Backup Designated Router for this network, 7621 in the view of the sending router. The Backup Designated Router 7622 is identified here by its IP interface address on the network. 7623 Set to 0.0.0.0 if there is no Backup Designated Router. 7625 Neighbor 7626 The Router IDs of each router from whom valid Hello packets have 7627 been seen recently on the network. Recently means in the last 7628 RouterDeadInterval seconds. 7630 A.3.3 The Database Description packet 7632 Database Description packets are OSPF packet type 2. These packets 7633 are exchanged when an adjacency is being initialized. They describe 7634 the contents of the link-state database. Multiple packets may be 7635 used to describe the database. For this purpose a poll-response 7636 procedure is used. One of the routers is designated to be the 7637 master, the other the slave. The master sends Database Description 7638 packets (polls) which are acknowledged by Database Description 7639 packets sent by the slave (responses). The responses are linked to 7640 the polls via the packets' DD sequence numbers. 7642 0 1 2 3 7643 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 7644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7645 | Version # | 2 | Packet length | 7646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7647 | Router ID | 7648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7649 | Area ID | 7650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7651 | Checksum | AuType | 7652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7653 | Authentication | 7654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7655 | Authentication | 7656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7657 | Interface MTU | Options |0|0|0|0|0|I|M|MS 7658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7659 | DD sequence number | 7660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7661 | | 7662 +- -+ 7663 | | 7664 +- An LSA Header -+ 7665 | | 7666 +- -+ 7667 | | 7668 +- -+ 7669 | | 7670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7671 | ... | 7673 The format of the Database Description packet is very similar to 7674 both the Link State Request and Link State Acknowledgment packets. 7675 The main part of all three is a list of items, each item describing 7676 a piece of the link-state database. The sending of Database 7677 Description Packets is documented in Section 10.8. The reception of 7678 Database Description packets is documented in Section 10.6. 7680 Interface MTU 7681 The size in bytes of the largest IP datagram that can be sent 7682 out the associated interface, without fragmentation. The MTUs 7683 of common Internet link types can be found in Table 7-1 of 7684 [Ref22]. Interface MTU should be set to 0 in Database 7685 Description packets sent over virtual links. 7687 Options 7688 The optional capabilities supported by the router, as documented 7689 in Section A.2. 7691 I-bit 7692 The Init bit. When set to 1, this packet is the first in the 7693 sequence of Database Description Packets. 7695 M-bit 7696 The More bit. When set to 1, it indicates that more Database 7697 Description Packets are to follow. 7699 MS-bit 7700 The Master/Slave bit. When set to 1, it indicates that the 7701 router is the master during the Database Exchange process. 7702 Otherwise, the router is the slave. 7704 DD sequence number 7705 Used to sequence the collection of Database Description Packets. 7706 The initial value (indicated by the Init bit being set) should 7707 be unique. The DD sequence number then increments until the 7708 complete database description has been sent. 7710 The rest of the packet consists of a (possibly partial) list of the 7711 link-state database's pieces. Each LSA in the database is described 7712 by its LSA header. The LSA header is documented in Section A.4.1. 7713 It contains all the information required to uniquely identify both 7714 the LSA and the LSA's current instance. 7716 A.3.4 The Link State Request packet 7718 Link State Request packets are OSPF packet type 3. After exchanging 7719 Database Description packets with a neighboring router, a router may 7720 find that parts of its link-state database are out-of-date. The 7721 Link State Request packet is used to request the pieces of the 7722 neighbor's database that are more up-to-date. Multiple Link State 7723 Request packets may need to be used. 7725 A router that sends a Link State Request packet has in mind the 7726 precise instance of the database pieces it is requesting. Each 7727 instance is defined by its LS sequence number, LS checksum, and LS 7728 age, although these fields are not specified in the Link State 7729 Request Packet itself. The router may receive even more recent 7730 instances in response. 7732 The sending of Link State Request packets is documented in Section 7733 10.9. The reception of Link State Request packets is documented in 7734 Section 10.7. 7736 0 1 2 3 7737 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 7738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7739 | Version # | 3 | Packet length | 7740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7741 | Router ID | 7742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7743 | Area ID | 7744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7745 | Checksum | AuType | 7746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7747 | Authentication | 7748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7749 | Authentication | 7750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7751 | LS type | 7752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7753 | Link State ID | 7754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7755 | Advertising Router | 7756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7757 | ... | 7759 Each LSA requested is specified by its LS type, Link State ID, and 7760 Advertising Router. This uniquely identifies the LSA, but not its 7761 instance. Link State Request packets are understood to be requests 7762 for the most recent instance (whatever that might be). 7764 A.3.5 The Link State Update packet 7766 Link State Update packets are OSPF packet type 4. These packets 7767 implement the flooding of LSAs. Each Link State Update packet 7768 carries a collection of LSAs one hop further from their origin. 7769 Several LSAs may be included in a single packet. 7771 Link State Update packets are multicast on those physical networks 7772 that support multicast/broadcast. In order to make the flooding 7773 procedure reliable, flooded LSAs are acknowledged in Link State 7774 Acknowledgment packets. If retransmission of certain LSAs is 7775 necessary, the retransmitted LSAs are always sent directly to the 7776 neighbor. For more information on the reliable flooding of LSAs, 7777 consult Section 13. 7779 0 1 2 3 7780 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 7781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7782 | Version # | 4 | Packet length | 7783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7784 | Router ID | 7785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7786 | Area ID | 7787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7788 | Checksum | AuType | 7789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7790 | Authentication | 7791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7792 | Authentication | 7793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7794 | # LSAs | 7795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7796 | | 7797 +- +-+ 7798 | LSAs | 7799 +- +-+ 7800 | ... | 7802 # LSAs 7803 The number of LSAs included in this update. 7805 The body of the Link State Update packet consists of a list of LSAs. 7806 Each LSA begins with a common 20 byte header, described in Section 7807 A.4.1. Detailed formats of the different types of LSAs are described 7808 in Section A.4. 7810 A.3.6 The Link State Acknowledgment packet 7812 Link State Acknowledgment Packets are OSPF packet type 5. To make 7813 the flooding of LSAs reliable, flooded LSAs are explicitly 7814 acknowledged. This acknowledgment is accomplished through the 7815 sending and receiving of Link State Acknowledgment packets. 7816 Multiple LSAs can be acknowledged in a single Link State 7817 Acknowledgment packet. 7819 Depending on the state of the sending interface and the sender of 7820 the corresponding Link State Update packet, a Link State 7821 Acknowledgment packet is sent either to the multicast address 7822 AllSPFRouters, to the multicast address AllDRouters, or as a 7823 unicast. The sending of Link State Acknowledgement packets is 7824 documented in Section 13.5. The reception of Link State 7825 Acknowledgement packets is documented in Section 13.7. 7827 The format of this packet is similar to that of the Data Description 7828 packet. The body of both packets is simply a list of LSA headers. 7830 0 1 2 3 7831 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 7832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7833 | Version # | 5 | Packet length | 7834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7835 | Router ID | 7836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7837 | Area ID | 7838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7839 | Checksum | AuType | 7840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7841 | Authentication | 7842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7843 | Authentication | 7844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7845 | | 7846 +- -+ 7847 | | 7848 +- An LSA Header -+ 7849 | | 7850 +- -+ 7851 | | 7852 +- -+ 7853 | | 7854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7855 | ... | 7857 Each acknowledged LSA is described by its LSA header. The LSA 7858 header is documented in Section A.4.1. It contains all the 7859 information required to uniquely identify both the LSA and the LSA's 7860 current instance. 7862 A.4 LSA formats 7864 This memo defines five distinct types of LSAs. Each LSA begins with 7865 a standard 20 byte LSA header. This header is explained in Section 7866 A.4.1. Succeeding sections then diagram the separate LSA types. 7868 Each LSA describes a piece of the OSPF routing domain. Every router 7869 originates a router-LSA. In addition, whenever the router is 7870 elected Designated Router, it originates a network-LSA. Other types 7871 of LSAs may also be originated (see Section 12.4). All LSAs are 7872 then flooded throughout the OSPF routing domain. The flooding 7873 algorithm is reliable, ensuring that all routers have the same 7874 collection of LSAs. (See Section 13 for more information concerning 7875 the flooding algorithm). This collection of LSAs is called the 7876 link-state database. 7878 From the link state database, each router constructs a shortest path 7879 tree with itself as root. This yields a routing table (see Section 7880 11). For the details of the routing table build process, see 7881 Section 16. 7883 A.4.1 The LSA header 7885 All LSAs begin with a common 20 byte header. This header contains 7886 enough information to uniquely identify the LSA (LS type, Link State 7887 ID, and Advertising Router). Multiple instances of the LSA may 7888 exist in the routing domain at the same time. It is then necessary 7889 to determine which instance is more recent. This is accomplished by 7890 examining the LS age, LS sequence number and LS checksum fields that 7891 are also contained in the LSA header. 7893 0 1 2 3 7894 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 7895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7896 | LS age | Options | LS type | 7897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7898 | Link State ID | 7899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7900 | Advertising Router | 7901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7902 | LS sequence number | 7903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7904 | LS checksum | length | 7905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7907 LS age 7908 The time in seconds since the LSA was originated. 7910 Options 7911 The optional capabilities supported by the described portion of 7912 the routing domain. OSPF's optional capabilities are documented 7913 in Section A.2. 7915 LS type 7916 The type of the LSA. Each LSA type has a separate advertisement 7917 format. The LSA types defined in this memo are as follows (see 7918 Section 12.1.3 for further explanation): 7920 LS Type Description 7921 ___________________________________ 7922 1 Router-LSAs 7923 2 Network-LSAs 7924 3 Summary-LSAs (IP network) 7925 4 Summary-LSAs (ASBR) 7926 5 AS-external-LSAs 7928 Link State ID 7929 This field identifies the portion of the internet environment 7930 that is being described by the LSA. The contents of this field 7931 depend on the LSA's LS type. For example, in network-LSAs the 7932 Link State ID is set to the IP interface address of the 7933 network's Designated Router (from which the network's IP address 7934 can be derived). The Link State ID is further discussed in 7935 Section 12.1.4. 7937 Advertising Router 7938 The Router ID of the router that originated the LSA. For 7939 example, in network-LSAs this field is equal to the Router ID of 7940 the network's Designated Router. 7942 LS sequence number 7943 Detects old or duplicate LSAs. Successive instances of an LSA 7944 are given successive LS sequence numbers. See Section 12.1.6 7945 for more details. 7947 LS checksum 7948 The Fletcher checksum of the complete contents of the LSA, 7949 including the LSA header but excluding the LS age field. See 7950 Section 12.1.7 for more details. 7952 length 7953 The length in bytes of the LSA. This includes the 20 byte LSA 7954 header. 7956 A.4.2 Router-LSAs 7958 Router-LSAs are the Type 1 LSAs. Each router in an area originates 7959 a router-LSA. The LSA describes the state and cost of the router's 7960 links (i.e., interfaces) to the area. All of the router's links to 7961 the area must be described in a single router-LSA. For details 7962 concerning the construction of router-LSAs, see Section 12.4.1. 7964 0 1 2 3 7965 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 7966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7967 | LS age | Options | 1 | 7968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7969 | Link State ID | 7970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7971 | Advertising Router | 7972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7973 | LS sequence number | 7974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7975 | LS checksum | length | 7976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7977 | 0 |V|E|B| 0 | # links | 7978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7979 | Link ID | 7980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7981 | Link Data | 7982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7983 | Type | # TOS | metric | 7984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7985 | ... | 7986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7987 | TOS | 0 | TOS metric | 7988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7989 | Link ID | 7990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7991 | Link Data | 7992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7993 | ... | 7995 In router-LSAs, the Link State ID field is set to the router's OSPF 7996 Router ID. Router-LSAs are flooded throughout a single area only. 7998 bit V 7999 When set, the router is an endpoint of one or more fully 8000 adjacent virtual links having the described area as Transit area 8001 (V is for virtual link endpoint). 8003 bit E 8004 When set, the router is an AS boundary router (E is for 8005 external). 8007 bit B 8008 When set, the router is an area border router (B is for border). 8010 # links 8011 The number of router links described in this LSA. This must be 8012 the total collection of router links (i.e., interfaces) to the 8013 area. 8015 The following fields are used to describe each router link (i.e., 8016 interface). Each router link is typed (see the below Type field). 8017 The Type field indicates the kind of link being described. It may 8018 be a link to a transit network, to another router or to a stub 8019 network. The values of all the other fields describing a router 8020 link depend on the link's Type. For example, each link has an 8021 associated 32-bit Link Data field. For links to stub networks this 8022 field specifies the network's IP address mask. For other link types 8023 the Link Data field specifies the router interface's IP address. 8025 Type 8026 A quick description of the router link. One of the following. 8027 Note that host routes are classified as links to stub networks 8028 with network mask of 0xffffffff. 8030 Type Description 8031 __________________________________________________ 8032 1 Point-to-point connection to another router 8033 2 Connection to a transit network 8034 3 Connection to a stub network 8035 4 Virtual link 8037 Link ID 8038 Identifies the object that this router link connects to. Value 8039 depends on the link's Type. When connecting to an object that 8040 also originates an LSA (i.e., another router or a transit 8041 network) the Link ID is equal to the neighboring LSA's Link 8042 State ID. This provides the key for looking up the neighboring 8043 LSA in the link state database during the routing table 8044 calculation. See Section 12.2 for more details. 8046 Type Link ID 8047 ______________________________________ 8048 1 Neighboring router's Router ID 8049 2 IP address of Designated Router 8050 3 IP network/subnet number 8051 4 Neighboring router's Router ID 8053 Link Data 8054 Value again depends on the link's Type field. For connections to 8055 stub networks, Link Data specifies the network's IP address 8056 mask. For unnumbered point-to-point connections, it specifies 8057 the interface's MIB-II [Ref8] ifIndex value. For the other link 8058 types it specifies the router interface's IP address. This 8059 latter piece of information is needed during the routing table 8060 build process, when calculating the IP address of the next hop. 8061 See Section 16.1.1 for more details. 8063 # TOS 8064 The number of different TOS metrics given for this link, not 8065 counting the required link metric (referred to as the TOS 0 8066 metric in [Ref9]). For example, if no additional TOS metrics 8067 are given, this field is set to 0. 8069 metric 8070 The cost of using this router link. 8072 Additional TOS-specific information may also be included, for 8073 backward compatibility with previous versions of the OSPF 8074 specification ([Ref9]). Within each link, and for each desired TOS, 8075 TOS TOS-specific link information may be encoded as follows: 8077 TOS IP Type of Service that this metric refers to. The encoding of 8078 TOS in OSPF LSAs is described in Section 12.3. 8080 TOS metric 8081 TOS-specific metric information. 8083 A.4.3 Network-LSAs 8085 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 8086 each broadcast and NBMA network in the area which supports two or 8087 more routers. The network-LSA is originated by the network's 8088 Designated Router. The LSA describes all routers attached to the 8089 network, including the Designated Router itself. The LSA's Link 8090 State ID field lists the IP interface address of the Designated 8091 Router. 8093 The distance from the network to all attached routers is zero. This 8094 is why metric fields need not be specified in the network-LSA. For 8095 details concerning the construction of network-LSAs, see Section 8096 12.4.2. 8098 0 1 2 3 8099 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 8100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8101 | LS age | Options | 2 | 8102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8103 | Link State ID | 8104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8105 | Advertising Router | 8106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8107 | LS sequence number | 8108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8109 | LS checksum | length | 8110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8111 | Network Mask | 8112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8113 | Attached Router | 8114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8115 | ... | 8117 Network Mask 8118 The IP address mask for the network. For example, a class A 8119 network would have the mask 0xff000000. 8121 Attached Router 8122 The Router IDs of each of the routers attached to the network. 8123 Actually, only those routers that are fully adjacent to the 8124 Designated Router are listed. The Designated Router includes 8125 itself in this list. The number of routers included can be 8126 deduced from the LSA header's length field. 8128 A.4.4 Summary-LSAs 8130 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated 8131 by area border routers. Summary-LSAs describe inter-area 8132 destinations. For details concerning the construction of summary- 8133 LSAs, see Section 12.4.3. 8135 Type 3 summary-LSAs are used when the destination is an IP network. 8136 In this case the LSA's Link State ID field is an IP network number 8137 (if necessary, the Link State ID can also have one or more of the 8138 network's "host" bits set; see Appendix E for details). When the 8139 destination is an AS boundary router, a Type 4 summary-LSA is used, 8140 and the Link State ID field is the AS boundary router's OSPF Router 8141 ID. (To see why it is necessary to advertise the location of each 8142 ASBR, consult Section 16.4.) Other than the difference in the Link 8143 State ID field, the format of Type 3 and 4 summary-LSAs is 8144 identical. 8146 0 1 2 3 8147 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 8148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8149 | LS age | Options | 3 or 4 | 8150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8151 | Link State ID | 8152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8153 | Advertising Router | 8154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8155 | LS sequence number | 8156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8157 | LS checksum | length | 8158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8159 | Network Mask | 8160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8161 | 0 | metric | 8162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8163 | TOS | TOS metric | 8164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8165 | ... | 8167 For stub areas, Type 3 summary-LSAs can also be used to describe a 8168 (per-area) default route. Default summary routes are used in stub 8169 areas instead of flooding a complete set of external routes. When 8170 describing a default summary route, the summary-LSA's Link State ID 8171 is always set to DefaultDestination (0.0.0.0) and the Network Mask 8172 is set to 0.0.0.0. 8174 Network Mask 8175 For Type 3 summary-LSAs, this indicates the destination 8176 network's IP address mask. For example, when advertising the 8177 location of a class A network the value 0xff000000 would be 8178 used. This field is not meaningful and must be zero for Type 4 8179 summary-LSAs. 8181 metric 8182 The cost of this route. Expressed in the same units as the 8183 interface costs in the router-LSAs. 8185 Additional TOS-specific information may also be included, for 8186 backward compatibility with previous versions of the OSPF 8187 specification ([Ref9]). For each desired TOS, TOS-specific 8188 information is encoded as follows: 8190 TOS IP Type of Service that this metric refers to. The encoding of 8191 TOS in OSPF LSAs is described in Section 12.3. 8193 TOS metric 8194 TOS-specific metric information. 8196 A.4.5 AS-external-LSAs 8198 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 8199 AS boundary routers, and describe destinations external to the AS. 8200 For details concerning the construction of AS-external-LSAs, see 8201 Section 12.4.3. 8203 AS-external-LSAs usually describe a particular external destination. 8204 For these LSAs the Link State ID field specifies an IP network 8205 number (if necessary, the Link State ID can also have one or more of 8206 the network's "host" bits set; see Appendix E for details). AS- 8207 external-LSAs are also used to describe a default route. Default 8208 routes are used when no specific route exists to the destination. 8209 When describing a default route, the Link State ID is always set to 8210 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8212 0 1 2 3 8213 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 8214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8215 | LS age | Options | 5 | 8216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8217 | Link State ID | 8218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8219 | Advertising Router | 8220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8221 | LS sequence number | 8222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8223 | LS checksum | length | 8224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8225 | Network Mask | 8226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8227 |E| 0 | metric | 8228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8229 | Forwarding address | 8230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8231 | External Route Tag | 8232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8233 |E| TOS | TOS metric | 8234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8235 | Forwarding address | 8236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8237 | External Route Tag | 8238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8239 | ... | 8241 Network Mask 8242 The IP address mask for the advertised destination. For 8243 example, when advertising a class A network the mask 0xff000000 8244 would be used. 8246 bit E 8247 The type of external metric. If bit E is set, the metric 8248 specified is a Type 2 external metric. This means the metric is 8249 considered larger than any link state path. If bit E is zero, 8250 the specified metric is a Type 1 external metric. This means 8251 that it is expressed in the same units as the link state metric 8252 (i.e., the same units as interface cost). 8254 metric 8255 The cost of this route. Interpretation depends on the external 8256 type indication (bit E above). 8258 Forwarding address 8259 Data traffic for the advertised destination will be forwarded to 8260 this address. If the Forwarding address is set to 0.0.0.0, data 8261 traffic will be forwarded instead to the LSA's originator (i.e., 8262 the responsible AS boundary router). 8264 External Route Tag 8265 A 32-bit field attached to each external route. This is not 8266 used by the OSPF protocol itself. It may be used to communicate 8267 information between AS boundary routers; the precise nature of 8268 such information is outside the scope of this specification. 8270 Additional TOS-specific information may also be included, for 8271 backward compatibility with previous versions of the OSPF 8272 specification ([Ref9]). For each desired TOS, TOS-specific 8273 information is encoded as follows: 8275 TOS The Type of Service that the following fields concern. The 8276 encoding of TOS in OSPF LSAs is described in Section 12.3. 8278 bit E 8279 For backward-compatibility with [Ref9]. 8281 TOS metric 8282 TOS-specific metric information. 8284 Forwarding address 8285 For backward-compatibility with [Ref9]. 8287 External Route Tag 8288 For backward-compatibility with [Ref9]. 8290 B. Architectural Constants 8292 Several OSPF protocol parameters have fixed architectural values. 8293 These parameters have been referred to in the text by names such as 8294 LSRefreshTime. The same naming convention is used for the 8295 configurable protocol parameters. They are defined in Appendix C. 8297 The name of each architectural constant follows, together with its 8298 value and a short description of its function. 8300 LSRefreshTime 8301 The maximum time between distinct originations of any particular 8302 LSA. If the LS age field of one of the router's self-originated 8303 LSAs reaches the value LSRefreshTime, a new instance of the LSA 8304 is originated, even though the contents of the LSA (apart from 8305 the LSA header) will be the same. The value of LSRefreshTime is 8306 set to 30 minutes. 8308 MinLSInterval 8309 The minimum time between distinct originations of any particular 8310 LSA. The value of MinLSInterval is set to 5 seconds. 8312 MinLSArrival 8313 For any particular LSA, the minimum time that must elapse 8314 between reception of new LSA instances during flooding. LSA 8315 instances received at higher frequencies are discarded. The 8316 value of MinLSArrival is set to 1 second. 8318 MaxAge 8319 The maximum age that an LSA can attain. When an LSA's LS age 8320 field reaches MaxAge, it is reflooded in an attempt to flush the 8321 LSA from the routing domain (See Section 14). LSAs of age MaxAge 8322 are not used in the routing table calculation. The value of 8323 MaxAge is set to 1 hour. 8325 CheckAge 8326 When the age of an LSA in the link state database hits a 8327 multiple of CheckAge, the LSA's checksum is verified. An 8328 incorrect checksum at this time indicates a serious error. The 8329 value of CheckAge is set to 5 minutes. 8331 MaxAgeDiff 8332 The maximum time dispersion that can occur, as an LSA is flooded 8333 throughout the AS. Most of this time is accounted for by the 8334 LSAs sitting on router output queues (and therefore not aging) 8335 during the flooding process. The value of MaxAgeDiff is set to 8336 15 minutes. 8338 LSInfinity 8339 The metric value indicating that the destination described by an 8340 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as 8341 an alternative to premature aging (see Section 14.1). It is 8342 defined to be the 24-bit binary value of all ones: 0xffffff. 8344 DefaultDestination 8345 The Destination ID that indicates the default route. This route 8346 is used when no other matching routing table entry can be found. 8347 The default destination can only be advertised in AS-external- 8348 LSAs and in stub areas' type 3 summary-LSAs. Its value is the 8349 IP address 0.0.0.0. Its associated Network Mask is also always 8350 0.0.0.0. 8352 InitialSequenceNumber 8353 The value used for LS Sequence Number when originating the first 8354 instance of any LSA. Its value is the signed 32-bit integer 8355 0x80000001. 8357 MaxSequenceNumber 8358 The maximum value that LS Sequence Number can attain. Its value 8359 is the signed 32-bit integer 0x7fffffff. 8361 C. Configurable Constants 8363 The OSPF protocol has quite a few configurable parameters. These 8364 parameters are listed below. They are grouped into general 8365 functional categories (area parameters, interface parameters, etc.). 8366 Sample values are given for some of the parameters. 8368 Some parameter settings need to be consistent among groups of 8369 routers. For example, all routers in an area must agree on that 8370 area's parameters, and all routers attached to a network must agree 8371 on that network's IP network number and mask. 8373 Some parameters may be determined by router algorithms outside of 8374 this specification (e.g., the address of a host connected to the 8375 router via a SLIP line). From OSPF's point of view, these items are 8376 still configurable. 8378 C.1 Global parameters 8380 In general, a separate copy of the OSPF protocol is run for each 8381 area. Because of this, most configuration parameters are 8382 defined on a per-area basis. The few global configuration 8383 parameters are listed below. 8385 Router ID 8386 This is a 32-bit number that uniquely identifies the router 8387 in the Autonomous System. One algorithm for Router ID 8388 assignment is to choose the largest or smallest IP address 8389 assigned to the router. If a router's OSPF Router ID is 8390 changed, the router's OSPF software should be restarted 8391 before the new Router ID takes effect. Before restarting in 8392 order to change its Router ID, the router should flush its 8393 self-originated LSAs from the routing domain (see Section 8394 14.1), or they will persist for up to MaxAge minutes. 8396 RFC1583Compatibility 8397 Controls the preference rules used in Section 16.4 when 8398 choosing among multiple AS-external-LSAs advertising the 8399 same destination. When set to "enabled", the preference 8400 rules remain those specified by RFC 1583 ([Ref9]). When set 8401 to "disabled", the preference rules are those stated in 8402 Section 16.4.1, which prevent routing loops when AS- 8403 external-LSAs for the same destination have been originated 8404 from different areas. Set to "enabled" by default. 8406 In order to minimize the chance of routing loops, all OSPF 8407 routers in an OSPF routing domain should have 8408 RFC1583Compatibility set identically. When there are routers 8409 present that have not been updated with the functionality 8410 specified in Section 16.4.1 of this memo, all routers should 8411 have RFC1583Compatibility set to "enabled". Otherwise, all 8412 routers should have RFC1583Compatibility set to "disabled", 8413 preventing all routing loops. 8415 C.2 Area parameters 8417 All routers belonging to an area must agree on that area's 8418 configuration. Disagreements between two routers will lead to 8419 an inability for adjacencies to form between them, with a 8420 resulting hindrance to the flow of routing protocol and data 8421 traffic. The following items must be configured for an area: 8423 Area ID 8424 This is a 32-bit number that identifies the area. The Area 8425 ID of 0.0.0.0 is reserved for the backbone. If the area 8426 represents a subnetted network, the IP network number of the 8427 subnetted network may be used for the Area ID. 8429 List of address ranges 8430 An OSPF area is defined as a list of address ranges. Each 8431 address range consists of the following items: 8433 [IP address, mask] 8434 Describes the collection of IP addresses contained 8435 in the address range. Networks and hosts are 8436 assigned to an area depending on whether their 8437 addresses fall into one of the area's defining 8438 address ranges. Routers are viewed as belonging to 8439 multiple areas, depending on their attached 8440 networks' area membership. 8442 Status Set to either Advertise or DoNotAdvertise. Routing 8443 information is condensed at area boundaries. 8444 External to the area, at most a single route is 8445 advertised (via a summary-LSA) for each address 8446 range. The route is advertised if and only if the 8447 address range's Status is set to Advertise. 8448 Unadvertised ranges allow the existence of certain 8449 networks to be intentionally hidden from other 8450 areas. Status is set to Advertise by default. 8452 As an example, suppose an IP subnetted network is to be its 8453 own OSPF area. The area would be configured as a single 8454 address range, whose IP address is the address of the 8455 subnetted network, and whose mask is the natural class A, B, 8456 or C address mask. A single route would be advertised 8457 external to the area, describing the entire subnetted 8458 network. 8460 ExternalRoutingCapability 8461 Whether AS-external-LSAs will be flooded into/throughout the 8462 area. If AS-external-LSAs are excluded from the area, the 8463 area is called a "stub". Internal to stub areas, routing to 8464 external destinations will be based solely on a default 8465 summary route. The backbone cannot be configured as a stub 8466 area. Also, virtual links cannot be configured through stub 8467 areas. For more information, see Section 3.6. 8469 StubDefaultCost 8470 If the area has been configured as a stub area, and the 8471 router itself is an area border router, then the 8472 StubDefaultCost indicates the cost of the default summary- 8473 LSA that the router should advertise into the area. 8475 C.3 Router interface parameters 8477 Some of the configurable router interface parameters (such as IP 8478 interface address and subnet mask) actually imply properties of 8479 the attached networks, and therefore must be consistent across 8480 all the routers attached to that network. The parameters that 8481 must be configured for a router interface are: 8483 IP interface address 8484 The IP protocol address for this interface. This uniquely 8485 identifies the router over the entire internet. An IP 8486 address is not required on point-to-point networks. Such a 8487 point-to-point network is called "unnumbered". 8489 IP interface mask 8490 Also referred to as the subnet/network mask, this indicates 8491 the portion of the IP interface address that identifies the 8492 attached network. Masking the IP interface address with the 8493 IP interface mask yields the IP network number of the 8494 attached network. On point-to-point networks and virtual 8495 links, the IP interface mask is not defined. On these 8496 networks, the link itself is not assigned an IP network 8497 number, and so the addresses of each side of the link are 8498 assigned independently, if they are assigned at all. 8500 Area ID 8501 The OSPF area to which the attached network belongs. 8503 Interface output cost 8504 The cost of sending a packet on the interface, expressed in 8505 the link state metric. This is advertised as the link cost 8506 for this interface in the router's router-LSA. The interface 8507 output cost must always be greater than 0. 8509 RxmtInterval 8510 The number of seconds between LSA retransmissions, for 8511 adjacencies belonging to this interface. Also used when 8512 retransmitting Database Description and Link State Request 8513 Packets. This should be well over the expected round-trip 8514 delay between any two routers on the attached network. The 8515 setting of this value should be conservative or needless 8516 retransmissions will result. Sample value for a local area 8517 network: 5 seconds. 8519 InfTransDelay 8520 The estimated number of seconds it takes to transmit a Link 8521 State Update Packet over this interface. LSAs contained in 8522 the update packet must have their age incremented by this 8523 amount before transmission. This value should take into 8524 account the transmission and propagation delays of the 8525 interface. It must be greater than 0. Sample value for a 8526 local area network: 1 second. 8528 Router Priority 8529 An 8-bit unsigned integer. When two routers attached to a 8530 network both attempt to become Designated Router, the one 8531 with the highest Router Priority takes precedence. If there 8532 is still a tie, the router with the highest Router ID takes 8533 precedence. A router whose Router Priority is set to 0 is 8534 ineligible to become Designated Router on the attached 8535 network. Router Priority is only configured for interfaces 8536 to broadcast and NBMA networks. 8538 HelloInterval 8539 The length of time, in seconds, between the Hello Packets 8540 that the router sends on the interface. This value is 8541 advertised in the router's Hello Packets. It must be the 8542 same for all routers attached to a common network. The 8543 smaller the HelloInterval, the faster topological changes 8544 will be detected; however, more OSPF routing protocol 8545 traffic will ensue. Sample value for a X.25 PDN network: 30 8546 seconds. Sample value for a local area network: 10 seconds. 8548 RouterDeadInterval 8549 After ceasing to hear a router's Hello Packets, the number 8550 of seconds before its neighbors declare the router down. 8552 This is also advertised in the router's Hello Packets in 8553 their RouterDeadInterval field. This should be some 8554 multiple of the HelloInterval (say 4). This value again 8555 must be the same for all routers attached to a common 8556 network. 8558 AuType 8559 Identifies the authentication procedure to be used on the 8560 attached network. This value must be the same for all 8561 routers attached to the network. See Appendix D for a 8562 discussion of the defined authentication types. 8564 Authentication key 8565 This configured data allows the authentication procedure to 8566 verify OSPF protocol packets received over the interface. 8567 For example, if the AuType indicates simple password, the 8568 Authentication key would be a clear 64-bit password. 8569 Authentication keys associated with the other OSPF 8570 authentication types are discussed in Appendix D. 8572 C.4 Virtual link parameters 8574 Virtual links are used to restore/increase connectivity of the 8575 backbone. Virtual links may be configured between any pair of 8576 area border routers having interfaces to a common (non-backbone) 8577 area. The virtual link appears as an unnumbered point-to-point 8578 link in the graph for the backbone. The virtual link must be 8579 configured in both of the area border routers. 8581 A virtual link appears in router-LSAs (for the backbone) as if 8582 it were a separate router interface to the backbone. As such, 8583 it has all of the parameters associated with a router interface 8584 (see Section C.3). Although a virtual link acts like an 8585 unnumbered point-to-point link, it does have an associated IP 8586 interface address. This address is used as the IP source in 8587 OSPF protocol packets it sends along the virtual link, and is 8588 set dynamically during the routing table build process. 8589 Interface output cost is also set dynamically on virtual links 8590 to be the cost of the intra-area path between the two routers. 8591 The parameter RxmtInterval must be configured, and should be 8592 well over the expected round-trip delay between the two routers. 8593 This may be hard to estimate for a virtual link; it is better to 8594 err on the side of making it too large. Router Priority is not 8595 used on virtual links. 8597 A virtual link is defined by the following two configurable 8598 parameters: the Router ID of the virtual link's other endpoint, 8599 and the (non-backbone) area through which the virtual link runs 8600 (referred to as the virtual link's Transit area). Virtual links 8601 cannot be configured through stub areas. 8603 C.5 NBMA network parameters 8605 OSPF treats an NBMA network much like it treats a broadcast 8606 network. Since there may be many routers attached to the 8607 network, a Designated Router is selected for the network. This 8608 Designated Router then originates a network-LSA, which lists all 8609 routers attached to the NBMA network. 8611 However, due to the lack of broadcast capabilities, it may be 8612 necessary to use configuration parameters in the Designated 8613 Router selection. These parameters will only need to be 8614 configured in those routers that are themselves eligible to 8615 become Designated Router (i.e., those router's whose Router 8616 Priority for the network is non-zero), and then only if no 8617 automatic procedure for discovering neighbors exists: 8619 List of all other attached routers 8620 The list of all other routers attached to the NBMA network. 8621 Each router is listed by its IP interface address on the 8622 network. Also, for each router listed, that router's 8623 eligibility to become Designated Router must be defined. 8624 When an interface to a NBMA network comes up, the router 8625 sends Hello Packets only to those neighbors eligible to 8626 become Designated Router, until the identity of the 8627 Designated Router is discovered. 8629 PollInterval 8630 If a neighboring router has become inactive (Hello Packets 8631 have not been seen for RouterDeadInterval seconds), it may 8632 still be necessary to send Hello Packets to the dead 8633 neighbor. These Hello Packets will be sent at the reduced 8634 rate PollInterval, which should be much larger than 8635 HelloInterval. Sample value for a PDN X.25 network: 2 8636 minutes. 8638 C.6 Point-to-MultiPoint network parameters 8640 On Point-to-MultiPoint networks, it may be necessary to 8641 configure the set of neighbors that are directly reachable over 8642 the Point-to-MultiPoint network. Each neighbor is identified by 8643 its IP address on the Point-to-MultiPoint network. Designated 8644 Routers are not elected on Point-to-MultiPoint networks, so the 8645 Designated Router eligibility of configured neighbors is 8646 undefined. 8648 Alternatively, neighbors on Point-to-MultiPoint networks may be 8649 dynamically discovered by lower-level protocols such as Inverse 8650 ARP ([Ref14]). 8652 C.7 Host route parameters 8654 Host routes are advertised in router-LSAs as stub networks with 8655 mask 0xffffffff. They indicate either router interfaces to 8656 point-to-point networks, looped router interfaces, or IP hosts 8657 that are directly connected to the router (e.g., via a SLIP 8658 line). For each host directly connected to the router, the 8659 following items must be configured: 8661 Host IP address 8662 The IP address of the host. 8664 Cost of link to host 8665 The cost of sending a packet to the host, in terms of the 8666 link state metric. However, since the host probably has 8667 only a single connection to the internet, the actual 8668 configured cost in many cases is unimportant (i.e., will 8669 have no effect on routing). 8671 Area ID 8672 The OSPF area to which the host belongs. 8674 D. Authentication 8676 All OSPF protocol exchanges are authenticated. The OSPF packet 8677 header (see Section A.3.1) includes an authentication type field, 8678 and 64-bits of data for use by the appropriate authentication scheme 8679 (determined by the type field). 8681 The authentication type is configurable on a per-interface (or 8682 equivalently, on a per-network/subnet) basis. Additional 8683 authentication data is also configurable on a per-interface basis. 8685 Authentication types 0, 1 and 2 are defined by this specification. 8686 All other authentication types are reserved for definition by the 8687 IANA (iana@ISI.EDU). The current list of authentication types is 8688 described below in Table 20. 8690 AuType Description 8691 ___________________________________________ 8692 0 Null authentication 8693 1 Simple password 8694 2 Cryptographic authentication 8695 All others Reserved for assignment by the 8696 IANA (iana@ISI.EDU) 8698 Table 20: OSPF authentication types. 8700 D.1 Null authentication 8702 Use of this authentication type means that routing exchanges 8703 over the network/subnet are not authenticated. The 64-bit 8704 authentication field in the OSPF header can contain anything; it 8705 is not examined on packet reception. When employing Null 8706 authentication, the entire contents of each OSPF packet (other 8707 than the 64-bit authentication field) are checksummed in order 8708 to detect data corruption. 8710 D.2 Simple password authentication 8712 Using this authentication type, a 64-bit field is configured on 8713 a per-network basis. All packets sent on a particular network 8714 must have this configured value in their OSPF header 64-bit 8715 authentication field. This essentially serves as a "clear" 64- 8716 bit password. In addition, the entire contents of each OSPF 8717 packet (other than the 64-bit authentication field) are 8718 checksummed in order to detect data corruption. 8720 Simple password authentication guards against routers 8721 inadvertently joining the routing domain; each router must first 8722 be configured with its attached networks' passwords before it 8723 can participate in routing. However, simple password 8724 authentication is vulnerable to passive attacks currently 8725 widespread in the Internet (see [Ref16]). Anyone with physical 8726 access to the network can learn the password and compromise the 8727 security of the OSPF routing domain. 8729 D.3 Cryptographic authentication 8731 Using this authentication type, a shared secret key is 8732 configured in all routers attached to a common network/subnet. 8733 For each OSPF protocol packet, the key is used to 8734 generate/verify a "message digest" that is appended to the end 8735 of the OSPF packet. The message digest is a one-way function of 8736 the OSPF protocol packet and the secret key. Since the secret 8737 key is never sent over the network in the clear, protection is 8738 provided against passive attacks. 8740 The algorithms used to generate and verify the message digest 8741 are specified implicitly by the secret key. This specification 8742 completely defines the use of OSPF Cryptographic authentication 8743 when the MD5 algorithm is used. 8745 In addition, a non-decreasing sequence number is included in 8746 each OSPF protocol packet to protect against replay attacks. 8747 This provides long term protection; however, it is still 8748 possible to replay an OSPF packet until the sequence number 8749 changes. To implement this feature, each neighbor data structure 8751 0 1 2 3 8752 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 8753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8754 | 0 | Key ID | Auth Data Len | 8755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8756 | Cryptographic sequence number | 8757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8759 Figure 18: Usage of the Authentication field 8760 in the OSPF packet header when Cryptographic 8761 Authentication is employed 8762 contains a new field called the "cryptographic sequence number". 8763 This field is initialized to zero, and is also set to zero 8764 whenever the neighbor's state transitions to "Down". Whenever an 8765 OSPF packet is accepted as authentic, the cryptographic sequence 8766 number is set to the received packet's sequence number. 8768 This specification does not provide a rollover procedure for the 8769 cryptographic sequence number. When the cryptographic sequence 8770 number that the router is sending hits the maximum value, the 8771 router should reset the cryptographic sequence number that it is 8772 sending back to 0. After this is done, the router's neighbors 8773 will reject the router's OSPF packets for a period of 8774 RouterDeadInterval, and then the router will be forced to 8775 reestablish all adjacencies over the interface. However, it is 8776 expected that many implementations will use "seconds since 8777 reboot" (or "seconds since 1960", etc.) as the cryptographic 8778 sequence number. Such a choice will essentially prevent 8779 rollover, since the cryptographic sequence number field is 32 8780 bits in length. 8782 The OSPF Cryptographic authentication option does not provide 8783 confidentiality. 8785 When cryptographic authentication is used, the 64-bit 8786 Authentication field in the standard OSPF packet header is 8787 redefined as shown in Figure 18. The new field definitions are 8788 as follows: 8790 Key ID 8791 This field identifies the algorithm and secret key used to 8792 create the message digest appended to the OSPF packet. Key 8793 Identifiers are unique per-interface (or equivalently, per- 8794 subnet). 8796 Auth Data Len 8797 The length in bytes of the message digest appended to the 8798 OSPF packet. 8800 Cryptographic sequence number 8801 An unsigned 32-bit non-decreasing sequence number. Used to 8802 guard against replay attacks. 8804 The message digest appended to the OSPF packet is not actually 8805 considered part of the OSPF protocol packet: the message digest 8806 is not included in the OSPF header's packet length, although it 8807 is included in the packet's IP header length field. 8809 Each key is identified by the combination of interface and Key 8810 ID. An interface may have multiple keys active at any one time. 8811 This enables smooth transition from one key to another. Each key 8812 has four time constants associated with it. These time constants 8813 can be expressed in terms of a time-of-day clock, or in terms of 8814 a router's local clock (e.g., number of seconds since last 8815 reboot): 8817 KeyStartAccept 8818 The time that the router will start accepting packets that 8819 have been created with the given key. 8821 KeyStartGenerate 8822 The time that the router will start using the key for packet 8823 generation. 8825 KeyStopGenerate 8826 The time that the router will stop using the key for packet 8827 generation. 8829 KeyStopAccept 8830 The time that the router will stop accepting packets that 8831 have been created with the given key. 8833 In order to achieve smooth key transition, KeyStartAccept should 8834 be less than KeyStartGenerate and KeyStopGenerate should be less 8835 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are 8836 left unspecified, the key's lifetime is infinite. When a new key 8837 replaces an old, the KeyStartGenerate time for the new key must 8838 be less than or equal to the KeyStopGenerate time of the old 8839 key. 8841 Key storage should persist across a system restart, warm or 8842 cold, to avoid operational issues. In the event that the last 8843 key associated with an interface expires, it is unacceptable to 8844 revert to an unauthenticated condition, and not advisable to 8845 disrupt routing. Therefore, the router should send a "last 8846 authentication key expiration" notification to the network 8847 manager and treat the key as having an infinite lifetime until 8848 the lifetime is extended, the key is deleted by network 8849 management, or a new key is configured. 8851 D.4 Message generation 8853 After building the contents of an OSPF packet, the 8854 authentication procedure indicated by the sending interface's 8855 Autype value is called before the packet is sent. The 8856 authentication procedure modifies the OSPF packet as follows. 8858 D.4.1 Generating Null authentication 8860 When using Null authentication, the packet is modified as 8861 follows: 8863 (1) The Autype field in the standard OSPF header is set to 8864 0. 8866 (2) The checksum field in the standard OSPF header is set to 8867 the standard IP checksum of the entire contents of the 8868 packet, starting with the OSPF packet header but 8869 excluding the 64-bit authentication field. This 8870 checksum is calculated as the 16-bit one's complement of 8871 the one's complement sum of all the 16-bit words in the 8872 packet, excepting the authentication field. If the 8873 packet's length is not an integral number of 16-bit 8874 words, the packet is padded with a byte of zero before 8875 checksumming. 8877 D.4.2 Generating Simple password authentication 8879 When using Simple password authentication, the packet is 8880 modified as follows: 8882 (1) The Autype field in the standard OSPF header is set to 8883 1. 8885 (2) The checksum field in the standard OSPF header is set to 8886 the standard IP checksum of the entire contents of the 8887 packet, starting with the OSPF packet header but 8888 excluding the 64-bit authentication field. This 8889 checksum is calculated as the 16-bit one's complement of 8890 the one's complement sum of all the 16-bit words in the 8891 packet, excepting the authentication field. If the 8892 packet's length is not an integral number of 16-bit 8893 words, the packet is padded with a byte of zero before 8894 checksumming. 8896 (3) The 64-bit authentication field in the OSPF packet 8897 header is set to the 64-bit password (i.e., 8898 authentication key) that has been configured for the 8899 interface. 8901 D.4.3 Generating Cryptographic authentication 8903 When using Cryptographic authentication, there may be 8904 multiple keys configured for the interface. In this case, 8905 among the keys that are valid for message generation (i.e, 8906 that have KeyStartGenerate <= current time < 8907 KeyStopGenerate) choose the one with the most recent 8908 KeyStartGenerate time. Using this key, modify the packet as 8909 follows: 8911 (1) The Autype field in the standard OSPF header is set to 8912 2. 8914 (2) The checksum field in the standard OSPF header is not 8915 calculated, but is instead set to 0. 8917 (3) The Key ID (see Figure 18) is set to the chosen key's 8918 Key ID. 8920 (4) The Auth Data Len field is set to the length in bytes of 8921 the message digest that will be appended to the OSPF 8922 packet. When using MD5 as the authentication algorithm, 8923 Auth Data Len will be 16. 8925 (5) The 32-bit Cryptographic sequence number (see Figure 18) 8926 is set to a non-decreasing value (i.e., a value at least 8927 as large as the last value sent out the interface). The 8928 precise values to use in the cryptographic sequence 8929 number field are implementation-specific. For example, 8930 it may be based on a simple counter, or be based on the 8931 system's clock. 8933 (6) The message digest is then calculated and appended to 8934 the OSPF packet. The authentication algorithm to be 8935 used in calculating the digest is indicated by the key 8936 itself. Input to the authentication algorithm consists 8937 of the OSPF packet and the secret key. When using MD5 as 8938 the authentication algorithm, the message digest 8939 calculation proceeds as follows: 8941 (a) The 16 byte MD5 key is appended to the OSPF packet. 8943 (b) Trailing pad and length fields are added, as 8944 specified in [Ref17]. 8946 (c) The MD5 authentication algorithm is run over the 8947 concatenation of the OSPF packet, secret key, pad 8948 and length fields, producing a 16 byte message 8949 digest (see [Ref17]). 8951 (d) The MD5 digest is written over the OSPF key (i.e., 8952 appended to the original OSPF packet). The digest is 8953 not counted in the OSPF packet's length field, but 8954 is included in the packet's IP length field. Any 8955 trailing pad or length fields beyond the digest are 8956 not counted or transmitted. 8958 D.5 Message verification 8960 When an OSPF packet has been received on an interface, it must 8961 be authenticated. The authentication procedure is indicated by 8962 the setting of Autype in the standard OSPF packet header, which 8963 matches the setting of Autype for the receiving OSPF interface. 8965 If an OSPF protocol packet is accepted as authentic, processing 8966 of the packet continues as specified in Section 8.2. Packets 8967 which fail authentication are discarded. 8969 D.5.1 Verifying Null authentication 8971 When using Null authentication, the checksum field in the 8972 OSPF header must be verified. It must be set to the 16-bit 8973 one's complement of the one's complement sum of all the 16- 8974 bit words in the packet, excepting the authentication field. 8975 (If the packet's length is not an integral number of 16-bit 8976 words, the packet is padded with a byte of zero before 8977 checksumming.) 8979 D.5.2 Verifying Simple password authentication 8981 When using Simple password authentication, the received OSPF 8982 packet is authenticated as follows: 8984 (1) The checksum field in the OSPF header must be verified. 8985 It must be set to the 16-bit one's complement of the 8986 one's complement sum of all the 16-bit words in the 8987 packet, excepting the authentication field. (If the 8988 packet's length is not an integral number of 16-bit 8989 words, the packet is padded with a byte of zero before 8990 checksumming.) 8992 (2) The 64-bit authentication field in the OSPF packet 8993 header must be equal to the 64-bit password (i.e., 8994 authentication key) that has been configured for the 8995 interface. 8997 D.5.3 Verifying Cryptographic authentication 8999 When using Cryptographic authentication, the received OSPF 9000 packet is authenticated as follows: 9002 (1) Locate the receiving interface's configured key having 9003 Key ID equal to that specified in the received OSPF 9004 packet (see Figure 18). If the key is not found, or if 9005 the key is not valid for reception (i.e., current time < 9006 KeyStartAccept or current time >= KeyStopAccept), the 9007 OSPF packet is discarded. 9009 (2) If the cryptographic sequence number found in the OSPF 9010 header (see Figure 18) is less than the cryptographic 9011 sequence number recorded in the sending neighbor's data 9012 structure, the OSPF packet is discarded. 9014 (3) Verify the appended message digest in the following 9015 steps: 9017 (a) The received digest is set aside. 9019 (b) A new digest is calculated, as specified in Step 6 9020 of Section D.4.3. 9022 (c) The calculated and received digests are compared. If 9023 they do not match, the OSPF packet is discarded. If 9024 they do match, the OSPF protocol packet is accepted 9025 as authentic, and the "cryptographic sequence 9026 number" in the neighbor's data structure is set to 9027 the sequence number found in the packet's OSPF 9028 header. 9030 E. An algorithm for assigning Link State IDs 9032 The Link State ID in AS-external-LSAs and summary-LSAs is usually 9033 set to the described network's IP address. However, if necessary one 9034 or more of the network's host bits may be set in the Link State ID. 9035 This allows the router to originate separate LSAs for networks 9036 having the same address, yet different masks. Such networks can 9037 occur in the presence of supernetting and subnet 0s (see [Ref10]). 9039 This appendix gives one possible algorithm for setting the host bits 9040 in Link State IDs. The choice of such an algorithm is a local 9041 decision. Separate routers are free to use different algorithms, 9042 since the only LSAs affected are the ones that the router itself 9043 originates. The only requirement on the algorithms used is that the 9044 network's IP address should be used as the Link State ID whenever 9045 possible; this maximizes interoperability with OSPF implementations 9046 predating RFC 1583. 9048 The algorithm below is stated for AS-external-LSAs. This is only 9049 for clarity; the exact same algorithm can be used for summary-LSAs. 9050 Suppose that the router wishes to originate an AS-external-LSA for a 9051 network having address NA and mask NM1. The following steps are then 9052 used to determine the LSA's Link State ID: 9054 (1) Determine whether the router is already originating an AS- 9055 external-LSA with Link State ID equal to NA (in such an LSA the 9056 router itself will be listed as the LSA's Advertising Router). 9057 If not, the Link State ID is set equal to NA and the algorithm 9058 terminates. Otherwise, 9060 (2) Obtain the network mask from the body of the already existing 9061 AS-external-LSA. Call this mask NM2. There are then two cases: 9063 o NM1 is longer (i.e., more specific) than NM2. In this case, 9064 set the Link State ID in the new LSA to be the network 9065 [NA,NM1] with all the host bits set (i.e., equal to NA or'ed 9066 together with all the bits that are not set in NM1, which is 9067 network [NA,NM1]'s broadcast address). 9069 o NM2 is longer than NM1. In this case, change the existing 9070 LSA (having Link State ID of NA) to reference the new 9071 network [NA,NM1] by incrementing the sequence number, 9072 changing the mask in the body to NM1 and inserting the cost 9073 of the new network. Then originate a new LSA for the old 9074 network [NA,NM2], with Link State ID equal to NA or'ed 9075 together with the bits that are not set in NM2 (i.e., 9076 network [NA,NM2]'s broadcast address). 9078 The above algorithm assumes that all masks are contiguous; this 9079 ensures that when two networks have the same address, one mask is 9080 more specific than the other. The algorithm also assumes that no 9081 network exists having an address equal to another network's 9082 broadcast address. Given these two assumptions, the above algorithm 9083 always produces unique Link State IDs. The above algorithm can also 9084 be reworded as follows: When originating an AS-external-LSA, try to 9085 use the network number as the Link State ID. If that produces a 9086 conflict, examine the two networks in conflict. One will be a subset 9087 of the other. For the less specific network, use the network number 9088 as the Link State ID and for the more specific use the network's 9089 broadcast address instead (i.e., flip all the "host" bits to 1). If 9090 the most specific network was originated first, this will cause you 9091 to originate two LSAs at once. 9093 As an example of the algorithm, consider its operation when the 9094 following sequence of events occurs in a single router (Router A). 9096 (1) Router A wants to originate an AS-external-LSA for 9097 [10.0.0.0,255.255.255.0]: 9099 (a) A Link State ID of 10.0.0.0 is used. 9101 (2) Router A then wants to originate an AS-external-LSA for 9102 [10.0.0.0,255.255.0.0]: 9104 (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a 9105 new Link State ID of 10.0.0.255. 9107 (b) A Link State ID of 10.0.0.0 is used for 9108 [10.0.0.0,255.255.0.0]. 9110 (3) Router A then wants to originate an AS-external-LSA for 9111 [10.0.0.0,255.0.0.0]: 9113 (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a 9114 new Link State ID of 10.0.255.255. 9116 (b) A Link State ID of 10.0.0.0 is used for 9117 [10.0.0.0,255.0.0.0]. 9119 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID 9120 of 10.0.0.255. 9122 F. Multiple interfaces to the same network/subnet 9124 There are at least two ways to support multiple physical interfaces 9125 to the same IP subnet. Both methods will interoperate with 9126 implementations of RFC 1583 (and of course this memo). The two 9127 methods are sketched briefly below. An assumption has been made that 9128 each interface has been assigned a separate IP address (otherwise, 9129 support for multiple interfaces is more of a link-level or ARP issue 9130 than an OSPF issue). 9132 Method 1: 9133 Run the entire OSPF functionality over both interfaces, sending 9134 and receiving hellos, flooding, supporting separate interface 9135 and neighbor FSMs for each interface, etc. When doing this all 9136 other routers on the subnet will treat the two interfaces as 9137 separate neighbors, since neighbors are identified (on broadcast 9138 and NBMA networks) by their IP address. 9140 Method 1 has the following disadvantages: 9142 (1) You increase the total number of neighbors and adjacencies. 9144 (2) You lose the bidirectionality test on both interfaces, since 9145 bidirectionality is based on Router ID. 9147 (3) You have to consider both interfaces together during the 9148 Designated Router election, since if you declare both to be 9149 DR simultaneously you can confuse the tie-breaker (which is 9150 Router ID). 9152 Method 2: 9153 Run OSPF over only one interface (call it the primary 9154 interface), but include both the primary and secondary 9155 interfaces in your Router-LSA. 9157 Method 2 has the following disadvantages: 9159 (1) You lose the bidirectionality test on the secondary 9160 interface. 9162 (2) When the primary interface fails, you need to promote the 9163 secondary interface to primary status. 9165 G. Differences from RFC 2178 9167 This section documents the differences between this memo and RFC 9168 2178. All differences are backward-compatible. Implementations of 9169 this memo and of RFCs 2178, 1583, and 1247 will interoperate. 9171 G.1 Flooding modifications 9173 Three changes have been made to the flooding procedure in 9174 Section 13. 9176 The first change is to step 4 in Section 13. Now MaxAge LSAs are 9177 acknowledged and then discarded only when both a) there is no 9178 database copy of the LSA and b) none of router's neighbors are 9179 in states Exchange or Loading. In all other cases, the MaxAge 9180 LSA is processed like any other LSA, installing the LSA in the 9181 database and flooding it out the appropriate interfaces when the 9182 LSA is more recent than the database copy (Step 5 of Section 9183 13). This change also affects the contents of Table 19. 9185 The second change is to step 5a in Section 13. The MinLSArrival 9186 check is meant only for LSAs received during flooding, and 9187 should not be performed on those LSAs that the router itself 9188 originates. 9190 The third change is to step 8 in Section 13. Confusion between 9191 routers as to which LSA instance is more recent can cause a 9192 disastrous amount of flooding in a link-state protocol (see 9193 [Ref26]). OSPF guards against this problem in two ways: a) the 9194 LS age field is used like a TTL field in flooding, to eventually 9195 remove looping LSAs from the network (see Section 13.3), and b) 9196 routers refuse to accept LSA updates more frequently than once 9197 every MinLSArrival seconds (see Section 13). However, there is 9198 still one case in RFC 2178 where disagreements regarding which 9199 LSA is more recent can cause a lot of flooding traffic: 9200 responding to old LSAs by reflooding the database copy. For 9201 this reason, Step 8 of Section 13 has been amended to only 9202 respond with the database copy when that copy has not been sent 9203 in any Link State Update within the last MinLSArrival seconds. 9205 G.2 Changes to external path preferences 9207 There is still the possibility of a routing loop in RFC 2178 9208 when both a) virtual links are in use and b) the same external 9209 route is being imported by multiple ASBRs, each of which is in a 9210 separate area. To fix this problem, Section 16.4.1 has been 9211 revised. To choose the correct ASBR/forwarding address, intra- 9212 area paths through non-backbone areas are always preferred. 9214 However, intra-area paths through the backbone area (Area 0) and 9215 inter-area paths are now of equal preference, and must be 9216 compared solely based on cost. 9218 The reasoning behind this change is as follows. When virtual 9219 links are in use, an intra-area backbone path for one router can 9220 turn into an inter-area path in a router several hops closer to 9221 the destination. Hence, intra-area backbone paths and inter-area 9222 paths must be of equal preference. We can safely compare their 9223 costs, preferring the path with the smallest cost, due to the 9224 calculations in Section 16.3. 9226 Thanks to Michael Briggs and Jeremy McCooey of the UNH 9227 InterOperability Lab for pointing out this problem. 9229 G.3 Incomplete resolution of virtual next hops 9231 One of the functions of the calculation in Section 16.3 is to 9232 determine the actual next hop(s) for those destinations whose 9233 next hop was calculated as a virtual link in Sections 16.1 and 9234 16.2. After completion of the calculation in Section 16.3, any 9235 paths calculated in Sections 16.1 and 16.2 that still have 9236 unresolved virtual next hops should be discarded. 9238 G.4 Routing table lookup 9240 The routing table lookup algorithm in Section 11.1 has been 9241 modified to reflect current practice. The "best match" routing 9242 table entry is now always selected to be the one providing the 9243 most specific (longest) match. Suppose for example a router is 9244 forwarding packets to the destination 192.9.1.1. A routing table 9245 entry for 192.9.1/24 will always be a better match than the 9246 routing table entry for 192.9/16, regardless of the routing 9247 table entries' path-types. Note however that when multiple paths 9248 are available for a given routing table entry, the calculations 9249 in Sections 16.1, 16.2, and 16.4 always yield the paths having 9250 the most preferential path-type. (Intra-area paths are the most 9251 preferred, followed in order by inter-area, type 1 external and 9252 type 2 external paths; see Section 11). 9254 Security Considerations 9256 All OSPF protocol exchanges are authenticated. OSPF supports 9257 multiple types of authentication; the type of authentication in use 9258 can be configured on a per network segment basis. One of OSPF's 9259 authentication types, namely the Cryptographic authentication 9260 option, is believed to be secure against passive attacks and provide 9261 significant protection against active attacks. When using the 9262 Cryptographic authentication option, each router appends a "message 9263 digest" to its transmitted OSPF packets. Receivers then use the 9264 shared secret key and received digest to verify that each received 9265 OSPF packet is authentic. 9267 The quality of the security provided by the Cryptographic 9268 authentication option depends completely on the strength of the 9269 message digest algorithm (MD5 is currently the only message digest 9270 algorithm specified), the strength of the key being used, and the 9271 correct implementation of the security mechanism in all 9272 communicating OSPF implementations. It also requires that all 9273 parties maintain the secrecy of the shared secret key. 9275 None of the OSPF authentication types provide confidentiality. Nor 9276 do they protect against traffic analysis. Key management is also not 9277 addressed by this memo. 9279 For more information, see Sections 8.1, 8.2, and Appendix D. 9281 Author's Address 9283 John Moy 9284 Ascend Communications, Inc. 9285 1 Robbins Road 9286 Westford, MA 01886 9288 Phone: 978-952-1367 9289 Fax: 978-392-2075 9290 Email: jmoy@casc.com 9292 This document expires in July 1998.