idnits 2.17.1 draft-ietf-ospf-version2-06.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-24) 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 7431 instances of lines with control characters in the document. == There are 49 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1376 has weird spacing: '... Area borde...' == Line 1676 has weird spacing: '... Packet name ...' == Line 1678 has weird spacing: '...aintain neigh...' == Line 1709 has weird spacing: '... type name...' == Line 2433 has weird spacing: '...virtual link....' == (13 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10388 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 1558 -- Looks like a reference, but probably isn't: '2' on line 2402 -- Looks like a reference, but probably isn't: '3' on line 2433 -- Looks like a reference, but probably isn't: '4' on line 2743 -- Looks like a reference, but probably isn't: '5' on line 3046 -- Looks like a reference, but probably isn't: '6' on line 3101 -- Looks like a reference, but probably isn't: '7' on line 3959 -- Looks like a reference, but probably isn't: '8' on line 4032 -- Looks like a reference, but probably isn't: '9' on line 4299 -- Looks like a reference, but probably isn't: '10' on line 4421 -- Looks like a reference, but probably isn't: '11' on line 4451 -- Looks like a reference, but probably isn't: '12' on line 4672 -- Looks like a reference, but probably isn't: '13' on line 4866 -- Looks like a reference, but probably isn't: '14' on line 4890 -- Looks like a reference, but probably isn't: '15' on line 5241 -- Looks like a reference, but probably isn't: '16' on line 5248 -- Looks like a reference, but probably isn't: '17' on line 5503 -- Looks like a reference, but probably isn't: '18' on line 5507 -- Looks like a reference, but probably isn't: '19' on line 6005 -- Looks like a reference, but probably isn't: '20' on line 6088 -- Looks like a reference, but probably isn't: '21' on line 6344 -- Looks like a reference, but probably isn't: '22' on line 6433 -- Looks like a reference, but probably isn't: '23' on line 6544 -- Looks like a reference, but probably isn't: '24' on line 6558 -- Looks like a reference, but probably isn't: '25' on line 6647 -- Looks like a reference, but probably isn't: '26' on line 7070 == Missing Reference: 'NA' is mentioned on line 9269, but not defined == Missing Reference: 'NM1' is mentioned on line 9266, but not defined == Missing Reference: 'NM2' is mentioned on line 9269, but not defined == Unused Reference: 'Ref9' is defined on line 7494, but no explicit reference was found in the text == Unused Reference: 'Ref19' is defined on line 7666, but no explicit reference was found in the text == Unused Reference: 'NA,NM1' is defined on line 9260, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref4' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref5' ** Downref: Normative reference to an Unknown state RFC: RFC 905 (ref. 'Ref6') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref7' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref8' ** Obsolete normative reference: RFC 1583 (ref. 'Ref9') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 1519 (ref. 'Ref10') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1700 (ref. 'Ref11') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref12' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref13' ** Obsolete normative reference: RFC 1293 (ref. 'Ref14') (Obsoleted by RFC 2390) ** Downref: Normative reference to an Informational RFC: RFC 1586 (ref. 'Ref15') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref16' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref17' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'Ref18') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref19' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref20' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref22' ** Obsolete normative reference: RFC 1771 (ref. 'Ref23') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'NA,NM1' Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 44 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy 3 Internet Draft Cascade 4 Expiration Date: May 1996 November 1995 5 File name: draft-ietf-ospf-version2-06.txt 7 OSPF Version 2 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This memo documents version 2 of the OSPF protocol. OSPF is a 30 link-state routing protocol. It is designed to be run internal to a 31 single Autonomous System. Each OSPF router maintains an identical 32 database describing the Autonomous System's topology. From this 33 database, a routing table is calculated by constructing a shortest- 34 path tree. 36 OSPF recalculates routes quickly in the face of topological changes, 37 utilizing a minimum of routing protocol traffic. OSPF provides 38 support for equal-cost multipath. Separate routes can be calculated 39 for each IP Type of Service. An area routing capability is 40 provided, enabling an additional level of routing protection and a 41 reduction in routing protocol traffic. In addition, all OSPF 42 routing protocol exchanges are authenticated. 44 The differences between this memo and RFC 1583 are explained in 45 Appendix F. All differences are backward-compatible in nature. 46 Implementations of this memo and of RFC 1583 will interoperate. 48 Please send comments to ospf@gated.cornell.edu. 50 Table of Contents 52 1 Introduction ........................................... 7 53 1.1 Protocol Overview ...................................... 7 54 1.2 Definitions of commonly used terms ..................... 8 55 1.3 Brief history of link-state routing technology ........ 11 56 1.4 Organization of this document ......................... 12 57 1.5 Acknowledgments ....................................... 13 58 2 The link-state database: organization and calculations 13 59 2.1 Representation of routers and networks ................ 13 60 2.1.1 Representation of non-broadcast networks .............. 15 61 2.1.2 An example link-state database ........................ 16 62 2.2 The shortest-path tree ................................ 20 63 2.3 Use of external routing information ................... 22 64 2.4 Equal-cost multipath .................................. 24 65 2.5 TOS-based routing ..................................... 25 66 3 Splitting the AS into Areas ........................... 25 67 3.1 The backbone of the Autonomous System ................. 26 68 3.2 Inter-area routing .................................... 27 69 3.3 Classification of routers ............................. 27 70 3.4 A sample area configuration ........................... 28 71 3.5 IP subnetting support ................................. 34 72 3.6 Supporting stub areas ................................. 35 73 3.7 Partitions of areas ................................... 36 74 4 Functional Summary .................................... 38 75 4.1 Inter-area routing .................................... 38 76 4.2 AS external routes .................................... 39 77 4.3 Routing protocol packets .............................. 39 78 4.4 Basic implementation requirements ..................... 42 79 4.5 Optional OSPF capabilities ............................ 43 80 5 Protocol data structures .............................. 44 81 6 The Area Data Structure ............................... 46 82 7 Bringing Up Adjacencies ............................... 49 83 7.1 The Hello Protocol .................................... 49 84 7.2 The Synchronization of Databases ...................... 50 85 7.3 The Designated Router ................................. 51 86 7.4 The Backup Designated Router .......................... 52 87 7.5 The graph of adjacencies .............................. 53 88 8 Protocol Packet Processing ............................ 53 89 8.1 Sending protocol packets .............................. 54 90 8.2 Receiving protocol packets ............................ 56 91 9 The Interface Data Structure .......................... 59 92 9.1 Interface states ...................................... 62 93 9.2 Events causing interface state changes ................ 64 94 9.3 The Interface state machine ........................... 66 95 9.4 Electing the Designated Router ........................ 68 96 9.5 Sending Hello packets ................................. 71 97 9.5.1 Sending Hello packets on NBMA networks ................ 72 98 10 The Neighbor Data Structure ........................... 73 99 10.1 Neighbor states ....................................... 75 100 10.2 Events causing neighbor state changes ................. 79 101 10.3 The Neighbor state machine ............................ 80 102 10.4 Whether to become adjacent ............................ 86 103 10.5 Receiving Hello Packets ............................... 87 104 10.6 Receiving Database Description Packets ................ 89 105 10.7 Receiving Link State Request Packets .................. 92 106 10.8 Sending Database Description Packets .................. 92 107 10.9 Sending Link State Request Packets .................... 94 108 10.10 An Example ............................................ 94 109 11 The Routing Table Structure ........................... 96 110 11.1 Routing table lookup .................................. 99 111 11.2 Sample routing table, without areas .................. 101 112 11.3 Sample routing table, with areas ..................... 101 113 12 Link State Advertisements (LSAs) ..................... 104 114 12.1 The LSA Header ....................................... 104 115 12.1.1 LS age ............................................... 105 116 12.1.2 Options .............................................. 105 117 12.1.3 LS type .............................................. 106 118 12.1.4 Link State ID ........................................ 106 119 12.1.5 Advertising Router ................................... 108 120 12.1.6 LS sequence number ................................... 108 121 12.1.7 LS checksum .......................................... 109 122 12.2 The link state database .............................. 110 123 12.3 Representation of TOS ................................ 111 124 12.4 Originating LSAs ..................................... 112 125 12.4.1 Router-LSAs .......................................... 115 126 12.4.1.1 Describing point-to-point interfaces ................. 117 127 12.4.1.2 Describing broadcast and NBMA interfaces ............. 118 128 12.4.1.3 Describing virtual links ............................. 119 129 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 119 130 12.4.1.5 Examples of router-LSAs .............................. 119 131 12.4.2 Network-LSAs ......................................... 122 132 12.4.2.1 Examples of network-LSAs ............................. 122 133 12.4.3 Summary-LSAs ......................................... 123 134 12.4.3.1 Originating summary-LSAs into stub areas ............. 125 135 12.4.3.2 Examples of summary-LSAs ............................. 126 136 12.4.4 AS-external-LSAs ..................................... 127 137 12.4.4.1 Examples of AS-external-LSAs ......................... 128 138 13 The Flooding Procedure ............................... 130 139 13.1 Determining which LSA is newer ....................... 133 140 13.2 Installing LSAs in the database ...................... 134 141 13.3 Next step in the flooding procedure .................. 135 142 13.4 Receiving self-originated LSAs ....................... 137 143 13.5 Sending Link State Acknowledgment packets ............ 138 144 13.6 Retransmitting LSAs .................................. 139 145 13.7 Receiving link state acknowledgments ................. 141 146 14 Aging The Link State Database ........................ 142 147 14.1 Premature aging of LSAs .............................. 142 148 15 Virtual Links ........................................ 143 149 16 Calculation of the routing table ..................... 145 150 16.1 Calculating the shortest-path tree for an area ....... 146 151 16.1.1 The next hop calculation ............................. 152 152 16.2 Calculating the inter-area routes .................... 153 153 16.3 Examining transit areas' summary-LSAs ................ 154 154 16.4 Calculating AS external routes ....................... 157 155 16.5 Incremental updates -- summary-LSAs .................. 158 156 16.6 Incremental updates -- AS-external-LSAs .............. 159 157 16.7 Events generated as a result of routing table changes 160 158 16.8 Equal-cost multipath ................................. 160 159 16.9 Building the non-zero-TOS portion of the routing table 161 160 Footnotes ............................................ 163 161 References ........................................... 167 162 A OSPF data formats .................................... 169 163 A.1 Encapsulation of OSPF packets ........................ 169 164 A.2 The Options field .................................... 171 165 A.3 OSPF Packet Formats .................................. 173 166 A.3.1 The OSPF packet header ............................... 174 167 A.3.2 The Hello packet ..................................... 176 168 A.3.3 The Database Description packet ...................... 178 169 A.3.4 The Link State Request packet ........................ 180 170 A.3.5 The Link State Update packet ......................... 182 171 A.3.6 The Link State Acknowledgment packet ................. 184 172 A.4 LSA formats .......................................... 186 173 A.4.1 The LSA header ....................................... 187 174 A.4.2 Router-LSAs .......................................... 189 175 A.4.3 Network-LSAs ......................................... 193 176 A.4.4 Summary-LSAs ......................................... 194 177 A.4.5 AS-external-LSAs ..................................... 296 178 B Architectural Constants .............................. 198 179 C Configurable Constants ............................... 200 180 C.1 Global parameters .................................... 200 181 C.2 Area parameters ...................................... 200 182 C.3 Router interface parameters .......................... 202 183 C.4 Virtual link parameters .............................. 204 184 C.5 NBMA network parameters .............................. 204 185 C.6 Point-to-MultiPoint network parameters ............... 205 186 C.7 Host route parameters ................................ 205 187 D Authentication ....................................... 207 188 D.1 Null authentication .................................. 207 189 D.2 Simple password authentication ....................... 207 190 D.3 Cryptographic authentication ......................... 208 191 D.4 Message generation ................................... 210 192 D.4.1 Generating Null authentication ....................... 210 193 D.4.2 Generating Simple password authentication ............ 211 194 D.4.3 Generating Cryptographic authentication .............. 211 195 D.5 Message verification ................................. 212 196 D.5.1 Verifying Null authentication ........................ 213 197 D.5.2 Verifying Simple password authentication ............. 213 198 D.5.3 Verifying Cryptographic authentication ............... 213 199 E An algorithm for assigning Link State IDs ............ 215 200 F Differences from RFC 1583 ............................ 217 201 F.1 Enhancements to OSPF authentication .................. 217 202 F.2 Addition of Point-to-MultiPoint interface ............ 217 203 F.3 Support for overlapping area ranges .................. 218 204 F.4 A modification to the flooding algorithm ............. 219 205 F.5 Introduction of the MinLSArrival constant ............ 219 206 F.6 Optionally advertising point-to-point links as subnets 220 207 Security Considerations .............................. 221 208 Author's Address ..................................... 221 209 1. Introduction 211 This document is a specification of the Open Shortest Path First 212 (OSPF) TCP/IP internet routing protocol. OSPF is classified as an 213 Interior Gateway Protocol (IGP). This means that it distributes 214 routing information between routers belonging to a single Autonomous 215 System. The OSPF protocol is based on link-state or SPF technology. 216 This is a departure from the Bellman-Ford base used by traditional 217 TCP/IP internet routing protocols. 219 The OSPF protocol was developed by the OSPF working group of the 220 Internet Engineering Task Force. It has been designed expressly for 221 the TCP/IP internet environment, including explicit support for IP 222 subnetting, TOS-based routing and the tagging of externally-derived 223 routing information. OSPF also provides for the authentication of 224 routing updates, and utilizes IP multicast when sending/receiving 225 the updates. In addition, much work has been done to produce a 226 protocol that responds quickly to topology changes, yet involves 227 small amounts of routing protocol traffic. 229 1.1. Protocol overview 231 OSPF routes IP packets based solely on the destination IP 232 address and IP Type of Service found in the IP packet header. 233 IP packets are routed "as is" -- they are not encapsulated in 234 any further protocol headers as they transit the Autonomous 235 System. OSPF is a dynamic routing protocol. It quickly detects 236 topological changes in the AS (such as router interface 237 failures) and calculates new loop-free routes after a period of 238 convergence. This period of convergence is short and involves a 239 minimum of routing traffic. 241 In a link-state routing protocol, each router maintains a 242 database describing the Autonomous System's topology. This 243 database is referred to as the link-state database. Each 244 participating router has an identical database. Each individual 245 piece of this database is a particular router's local state 246 (e.g., the router's usable interfaces and reachable neighbors). 247 The router distributes its local state throughout the Autonomous 248 System by flooding. 250 All routers run the exact same algorithm, in parallel. From the 251 link-state database, each router constructs a tree of shortest 252 paths with itself as root. This shortest-path tree gives the 253 route to each destination in the Autonomous System. Externally 254 derived routing information appears on the tree as leaves. 256 OSPF calculates separate routes for each Type of Service (TOS). 258 When several equal-cost routes to a destination exist, traffic 259 is distributed equally among them. The cost of a route is 260 described by a single dimensionless metric. 262 OSPF allows sets of networks to be grouped together. Such a 263 grouping is called an area. The topology of an area is hidden 264 from the rest of the Autonomous System. This information hiding 265 enables a significant reduction in routing traffic. Also, 266 routing within the area is determined only by the area's own 267 topology, lending the area protection from bad routing data. An 268 area is a generalization of an IP subnetted network. 270 OSPF enables the flexible configuration of IP subnets. Each 271 route distributed by OSPF has a destination and mask. Two 272 different subnets of the same IP network number may have 273 different sizes (i.e., different masks). This is commonly 274 referred to as variable length subnetting. A packet is routed 275 to the best (i.e., longest or most specific) match. Host routes 276 are considered to be subnets whose masks are "all ones" 277 (0xffffffff). 279 All OSPF protocol exchanges are authenticated. This means that 280 only trusted routers can participate in the Autonomous System's 281 routing. A variety of authentication schemes can be used; in 282 fact, separate authentication schemes can be configured for each 283 IP subnet. 285 Externally derived routing data (e.g., routes learned from an 286 Exterior Gateway Protocol such as BGP; see [Ref23]) is 287 advertised throughout the Autonomous System. This externally 288 derived data is kept separate from the OSPF protocol's link 289 state data. Each external route can also be tagged by the 290 advertising router, enabling the passing of additional 291 information between routers on the boundary of the Autonomous 292 System. 294 1.2. Definitions of commonly used terms 296 This section provides definitions for terms that have a specific 297 meaning to the OSPF protocol and that are used throughout the 298 text. The reader unfamiliar with the Internet Protocol Suite is 299 referred to [Ref13] for an introduction to IP. 301 Router 302 A level three Internet Protocol packet switch. Formerly 303 called a gateway in much of the IP literature. 305 Autonomous System 306 A group of routers exchanging routing information via a 307 common routing protocol. Abbreviated as AS. 309 Interior Gateway Protocol 310 The routing protocol spoken by the routers belonging to an 311 Autonomous system. Abbreviated as IGP. Each Autonomous 312 System has a single IGP. Separate Autonomous Systems may be 313 running different IGPs. 315 Router ID 316 A 32-bit number assigned to each router running the OSPF 317 protocol. This number uniquely identifies the router within 318 an Autonomous System. 320 Network 321 In this memo, an IP network/subnet/supernet. It is possible 322 for one physical network to be assigned multiple IP 323 network/subnet numbers. We consider these to be separate 324 networks. Point-to-point physical networks are an exception 325 - they are considered a single network no matter how many 326 (if any at all) IP network/subnet numbers are assigned to 327 them. 329 Network mask 330 A 32-bit number indicating the range of IP addresses 331 residing on a single IP network/subnet/supernet. This 332 specification displays network masks as hexadecimal numbers. 333 For example, the network mask for a class C IP network is 334 displayed as 0xffffff00. Such a mask is often displayed 335 elsewhere in the literature as 255.255.255.0. 337 Point-to-point networks 338 A network that joins a single pair of routers. A 56Kb 339 serial line is an example of a point-to-point network. 341 Broadcast networks 342 Networks supporting many (more than two) attached routers, 343 together with the capability to address a single physical 344 message to all of the attached routers (broadcast). 345 Neighboring routers are discovered dynamically on these nets 346 using OSPF's Hello Protocol. The Hello Protocol itself 347 takes advantage of the broadcast capability. The OSPF 348 protocol makes further use of multicast capabilities, if 349 they exist. Each pair of routers on a broadcast network is 350 assumed to be able to communicate directly. An ethernet is 351 an example of a broadcast network. 353 Non-broadcast networks 354 Networks supporting many (more than two) routers, but having 355 no broadcast capability. Neighboring routers are maintained 356 on these nets using OSPF's Hello Protocol. However, due to 357 the lack of broadcast capability, some configuration 358 information may be necessary to aid in the discovery of 359 neighbors. On non-broadcast networks, OSPF protocol packets 360 that are normally multicast need to be sent to each 361 neighboring router, in turn. An X.25 Public Data Network 362 (PDN) is an example of a non-broadcast network. 364 OSPF runs in one of two modes over non-broadcast networks. 365 The first mode, called non-broadcast multi-access or NBMA, 366 simulates the operation of OSPF on a broadcast network. The 367 second mode, called Point-to-MultiPoint, treats the non- 368 broadcast network as a collection of point-to-point links. 369 Non-broadcast networks are referred to as NBMA networks or 370 Point-to-MultiPoint networks, depending on OSPF's mode of 371 operation over the network. 373 Interface 374 The connection between a router and one of its attached 375 networks. An interface has state information associated 376 with it, which is obtained from the underlying lower level 377 protocols and the routing protocol itself. An interface to 378 a network has associated with it a single IP address and 379 mask (unless the network is an unnumbered point-to-point 380 network). An interface is sometimes also referred to as a 381 link. 383 Neighboring routers 384 Two routers that have interfaces to a common network. 385 Neighbor relationships are maintained by, and usually 386 dynamically discovered by, OSPF's Hello Protocol. 388 Adjacency 389 A relationship formed between selected neighboring routers 390 for the purpose of exchanging routing information. Not 391 every pair of neighboring routers become adjacent. 393 Link state advertisement 394 Unit of data describing the local state of a router or 395 network. For a router, this includes the state of the 396 router's interfaces and adjacencies. Each link state 397 advertisement is flooded throughout the routing domain. The 398 collected link state advertisements of all routers and 399 networks forms the protocol's link state database. 400 Throughout this memo, link state advertisement is 401 abbreviated as LSA. 403 Hello Protocol 404 The part of the OSPF protocol used to establish and maintain 405 neighbor relationships. On broadcast networks the Hello 406 Protocol can also dynamically discover neighboring routers. 408 Flooding 409 The part of the OSPF protocol that distributes and 410 synchronizes the link-state database between OSPF routers. 412 Designated Router 413 Each broadcast and NBMA network that has at least two 414 attached routers has a Designated Router. The Designated 415 Router generates an LSA for the network and has other 416 special responsibilities in the running of the protocol. 417 The Designated Router is elected by the Hello Protocol. 419 The Designated Router concept enables a reduction in the 420 number of adjacencies required on a broadcast or NBMA 421 network. This in turn reduces the amount of routing 422 protocol traffic and the size of the link-state database. 424 Lower-level protocols 425 The underlying network access protocols that provide 426 services to the Internet Protocol and in turn the OSPF 427 protocol. Examples of these are the X.25 packet and frame 428 levels for X.25 PDNs, and the ethernet data link layer for 429 ethernets. 431 1.3. Brief history of link-state routing technology 433 OSPF is a link state routing protocol. Such protocols are also 434 referred to in the literature as SPF-based or distributed- 435 database protocols. This section gives a brief description of 436 the developments in link-state technology that have influenced 437 the OSPF protocol. 439 The first link-state routing protocol was developed for use in 440 the ARPANET packet switching network. This protocol is 441 described in [Ref3]. It has formed the starting point for all 442 other link-state protocols. The homogeneous ARPANET 443 environment, i.e., single-vendor packet switches connected by 444 synchronous serial lines, simplified the design and 445 implementation of the original protocol. 447 Modifications to this protocol were proposed in [Ref4]. These 448 modifications dealt with increasing the fault tolerance of the 449 routing protocol through, among other things, adding a checksum 450 to the LSAs (thereby detecting database corruption). The paper 451 also included means for reducing the routing traffic overhead in 452 a link-state protocol. This was accomplished by introducing 453 mechanisms which enabled the interval between LSA originations 454 to be increased by an order of magnitude. 456 A link-state algorithm has also been proposed for use as an ISO 457 IS-IS routing protocol. This protocol is described in [Ref2]. 458 The protocol includes methods for data and routing traffic 459 reduction when operating over broadcast networks. This is 460 accomplished by election of a Designated Router for each 461 broadcast network, which then originates an LSA for the network. 463 The OSPF Working Group of the IETF has extended this work in 464 developing the OSPF protocol. The Designated Router concept has 465 been greatly enhanced to further reduce the amount of routing 466 traffic required. Multicast capabilities are utilized for 467 additional routing bandwidth reduction. An area routing scheme 468 has been developed enabling information 469 hiding/protection/reduction. Finally, the algorithms have been 470 tailored for efficient operation in TCP/IP internets. 472 1.4. Organization of this document 474 The first three sections of this specification give a general 475 overview of the protocol's capabilities and functions. Sections 476 4-16 explain the protocol's mechanisms in detail. Packet 477 formats, protocol constants and configuration items are 478 specified in the appendices. 480 Labels such as HelloInterval encountered in the text refer to 481 protocol constants. They may or may not be configurable. 482 Architectural constants are summarized in Appendix B. 483 Configurable constants are summarized in Appendix C. 485 The detailed specification of the protocol is presented in terms 486 of data structures. This is done in order to make the 487 explanation more precise. Implementations of the protocol are 488 required to support the functionality described, but need not 489 use the precise data structures that appear in this memo. 491 1.5. Acknowledgments 493 The author would like to thank Ran Atkinson, Fred Baker, Jeffrey 494 Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra 495 Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui 496 Zhang and the rest of the OSPF Working Group for the ideas and 497 support they have given to this project. 499 The OSPF Point-to-MultiPoint interface is based on work done by 500 Fred Baker. 502 The OSPF Cryptographic Authentication option was developed by 503 Fred Baker and Ran Atkinson. 505 2. The Link-state Database: organization and calculations 507 The following subsections describe the organization of OSPF's link- 508 state database, and the routing calculations that are performed on 509 the database in order to produce a router's routing table. 511 2.1. Representation of routers and networks 513 The Autonomous System's link-state database describes a directed 514 graph. The vertices of the graph consist of routers and 515 networks. A graph edge connects two routers when they are 516 attached via a physical point-to-point network. An edge 517 connecting a router to a network indicates that the router has 518 an interface on the network. Networks can be either transit or 519 stub networks. Transit networks are those capable of carrying 520 data traffic that is neither locally originated nor locally 521 destined. A transit network is represented by a graph vertex 522 having both incoming and outgoing edges. A stub network's vertex 523 has only incoming edges. 525 The neighborhood of each network node in the graph depends on 526 the network's type (point-to-point, broadcast, NBMA or Point- 527 to-MultiPoint) and the number of routers having an interface to 528 the network. Three cases are depicted in Figure 1a. Rectangles 529 indicate routers. Circles and oblongs indicate networks. 530 Router names are prefixed with the letters RT and network names 531 with the letter N. Router interface names are prefixed by the 532 letter I. Lines between routers indicate point-to-point 533 networks. The left side of the figure shows networks with their 534 connected routers, with the resulting graphs shown on the right. 536 **FROM** 538 * |RT1|RT2| 539 +---+Ia +---+ * ------------ 540 |RT1|------|RT2| T RT1| | X | 541 +---+ Ib+---+ O RT2| X | | 542 * Ia| | X | 543 * Ib| X | | 545 Physical point-to-point networks 547 **FROM** 548 +---+ * 549 |RT7| * |RT7| N3| 550 +---+ T ------------ 551 | O RT7| | | 552 +----------------------+ * N3| X | | 553 N3 * 555 Stub networks 557 **FROM** 558 +---+ +---+ 559 |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | 560 +---+ +---+ * ------------------------ 561 | N2 | * RT3| | | | | X | 562 +----------------------+ T RT4| | | | | X | 563 | | O RT5| | | | | X | 564 +---+ +---+ * RT6| | | | | X | 565 |RT5| |RT6| * N2| X | X | X | X | | 566 +---+ +---+ 568 Broadcast or NBMA networks 570 Figure 1a: Network map components 572 Networks and routers are represented by vertices. 573 An edge connects Vertex A to Vertex B iff the 574 intersection of Column A and Row B is marked with 575 an X. 577 The top of Figure 1a shows two routers connected by a point-to- 578 point link. In the resulting link-state database graph, the two 579 router vertices are directly connected by a pair of edges, one 580 in each direction. Interfaces to point-to-point networks need 581 not be assigned IP addresses. When interface addresses are 582 assigned, they are modelled as stub links, with each router 583 advertising a stub connection to the other router's interface 584 address. Optionally, an IP subnet can be assigned to the point- 585 to-point network. In this case, both routers advertise a stub 586 link to the IP subnet, instead of advertising each others' IP 587 interface addresses. 589 The middle of Figure 1a shows a network with only one attached 590 router (i.e., a stub network). In this case, the network appears 591 on the end of a stub connection in the link-state database's 592 graph. 594 When multiple routers are attached to a broadcast network, the 595 link-state database graph shows all routers bidirectionally 596 connected to the network vertex. This is pictured at the bottom 597 of Figure 1a. 599 Each network (stub or transit) in the graph has an IP address 600 and associated network mask. The mask indicates the number of 601 nodes on the network. Hosts attached directly to routers 602 (referred to as host routes) appear on the graph as stub 603 networks. The network mask for a host route is always 604 0xffffffff, which indicates the presence of a single node. 606 2.1.1. Representation of non-broadcast networks 608 As mentioned previously, OSPF can run over non-broadcast 609 networks in one of two modes: NBMA or Point-to-MultiPoint. 610 The choice of mode determines the way that the Hello 611 protocol and flooding work over the non-broadcast network, 612 and the way that the network is represented in the link- 613 state database. 615 In NBMA mode, OSPF emulates operation over a broadcast 616 network: a Designated Router is elected for the NBMA 617 network, and the Designated Router originates an LSA for the 618 network. The graph representation for broadcast networks and 619 NBMA networks is identical. This representation is pictured 620 in the middle of Figure 1a. 622 NBMA mode is the most efficient way to run OSPF over non- 623 broadcast networks, both in terms of link-state database 624 size and in terms of the amount of routing protocol traffic. 625 However, it has one significant restriction: it requires all 626 routers attached to the NBMA network to be able to 627 communicate directly. This restriction may be met on some 628 non-broadcast networks, such as an ATM subnet utilizing 629 SVCs. But it is often not met on other non-broadcast 630 networks, such as PVC-only Frame Relay networks. On non- 631 broadcast networks where not all routers can communicate 632 directly you can break the non-broadcast network into 633 logical subnets, with the routers on each subnet being able 634 to communicate directly, and then run each separate subnet 635 as an NBMA network (see [Ref15]). This however requires 636 quite a bit of administrative overhead, and is prone to 637 misconfiguration. It is probably better to run such a non- 638 broadcast network in Point-to-Multipoint mode. 640 In Point-to-MultiPoint mode, OSPF treats all router-to- 641 router connections over the non-broadcast network as if they 642 were point-to-point links. No Designated Router is elected 643 for the network, nor is there an LSA generated for the 644 network. In fact, a vertex for the Point-to-MultiPoint 645 network does not appear in the graph of the link-state 646 database. 648 Figure 1b illustrates the link-state database representation 649 of a Point-to-MultiPoint network. On the left side of the 650 figure, a Point-to-MultiPoint network is pictured. It is 651 assumed that all routers can communicate directly, except 652 for routers RT4 and RT5. I3 though I6 indicate the routers' 653 IP interface addresses on the Point-to-MultiPoint network. 654 In the graphical representation of the link-state database, 655 routers that can communicate directly over the Point-to- 656 MultiPoint network are joined by bidirectional edges, and 657 each router also has a stub connection to its own IP 658 interface address (which is in contrast to the 659 representation of real point-to-point links; see Figure 1a). 661 On some non-broadcast networks, use of Point-to-MultiPoint 662 mode and data-link protocols such as Inverse ARP (see 663 [Ref14]) will allow autodiscovery of OSPF neighbors even 664 though broadcast support is not available. 666 2.1.2. An example link-state database 668 Figure 2 shows a sample map of an Autonomous System. The 669 rectangle labelled H1 indicates a host, which has a SLIP 670 **FROM** 671 +---+ +---+ 672 |RT3| |RT4| |RT3|RT4|RT5|RT6| 673 +---+ +---+ * -------------------- 674 I3| N2 |I4 * RT3| | X | X | X | 675 +----------------------+ T RT4| X | | | X | 676 I5| |I6 O RT5| X | | | X | 677 +---+ +---+ * RT6| X | X | X | | 678 |RT5| |RT6| * I3| X | | | | 679 +---+ +---+ I4| | X | | | 680 I5| | | X | | 681 I6| | | | X | 683 Figure 1b: Network map components 684 Point-to-MultiPoint networks 686 All routers can communicate directly over N2, except 687 routers RT4 and RT5. I3 through I6 indicate IP 688 interface addresses 690 connection to Router RT12. Router RT12 is therefore 691 advertising a host route. Lines between routers indicate 692 physical point-to-point networks. The only point-to-point 693 network that has been assigned interface addresses is the 694 one joining Routers RT6 and RT10. Routers RT5 and RT7 have 695 BGP connections to other Autonomous Systems. A set of BGP- 696 learned routes have been displayed for both of these 697 routers. 699 A cost is associated with the output side of each router 700 interface. This cost is configurable by the system 701 administrator. The lower the cost, the more likely the 702 interface is to be used to forward data traffic. Costs are 703 also associated with the externally derived routing data 704 (e.g., the BGP-learned routes). 706 The directed graph resulting from the map in Figure 2 is 707 depicted in Figure 3. Arcs are labelled with the cost of 708 the corresponding router output interface. Arcs having no 709 labelled cost have a cost of 0. Note that arcs leading from 710 networks to routers always have cost 0; they are significant 711 nonetheless. Note also that the externally derived routing 712 data appears on the graph as stubs. 714 + 715 | 3+---+ N12 N14 716 N1|--|RT1|\ 1 \ N13 / 717 | +---+ \ 8\ |8/8 718 + \ ____ \|/ 719 / \ 1+---+8 8+---+6 720 * N3 *---|RT4|------|RT5|--------+ 721 \____/ +---+ +---+ | 722 + / | |7 | 723 | 3+---+ / | | | 724 N2|--|RT2|/1 |1 |6 | 725 | +---+ +---+8 6+---+ | 726 + |RT3|--------------|RT6| | 727 +---+ +---+ | 728 |2 Ia|7 | 729 | | | 730 +---------+ | | 731 N4 | | 732 | | 733 | | 734 N11 | | 735 +---------+ | | 736 | | | N12 737 |3 | |6 2/ 738 +---+ | +---+/ 739 |RT9| | |RT7|---N15 740 +---+ | +---+ 9 741 |1 + | |1 742 _|__ | Ib|5 __|_ 743 / \ 1+----+2 | 3+----+1 / \ 744 * N9 *------|RT11|----|---|RT10|---* N6 * 745 \____/ +----+ | +----+ \____/ 746 | | | 747 |1 + |1 748 +--+ 10+----+ N8 +---+ 749 |H1|-----|RT12| |RT8| 750 +--+SLIP +----+ +---+ 751 |2 |4 752 | | 753 +---------+ +--------+ 754 N10 N7 756 Figure 2: A sample Autonomous System 757 **FROM** 759 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| 760 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| 761 ----- --------------------------------------------- 762 RT1| | | | | | | | | | | | |0 | | | | 763 RT2| | | | | | | | | | | | |0 | | | | 764 RT3| | | | | |6 | | | | | | |0 | | | | 765 RT4| | | | |8 | | | | | | | |0 | | | | 766 RT5| | | |8 | |6 |6 | | | | | | | | | | 767 RT6| | |8 | |7 | | | | |5 | | | | | | | 768 RT7| | | | |6 | | | | | | | | |0 | | | 769 * RT8| | | | | | | | | | | | | |0 | | | 770 * RT9| | | | | | | | | | | | | | | |0 | 771 T RT10| | | | | |7 | | | | | | | |0 |0 | | 772 O RT11| | | | | | | | | | | | | | |0 |0 | 773 * RT12| | | | | | | | | | | | | | | |0 | 774 * N1|3 | | | | | | | | | | | | | | | | 775 N2| |3 | | | | | | | | | | | | | | | 776 N3|1 |1 |1 |1 | | | | | | | | | | | | | 777 N4| | |2 | | | | | | | | | | | | | | 778 N6| | | | | | |1 |1 | |1 | | | | | | | 779 N7| | | | | | | |4 | | | | | | | | | 780 N8| | | | | | | | | |3 |2 | | | | | | 781 N9| | | | | | | | |1 | |1 |1 | | | | | 782 N10| | | | | | | | | | | |2 | | | | | 783 N11| | | | | | | | |3 | | | | | | | | 784 N12| | | | |8 | |2 | | | | | | | | | | 785 N13| | | | |8 | | | | | | | | | | | | 786 N14| | | | |8 | | | | | | | | | | | | 787 N15| | | | | | |9 | | | | | | | | | | 788 H1| | | | | | | | | | | |10| | | | | 790 Figure 3: The resulting directed graph 792 Networks and routers are represented by vertices. 793 An edge of cost X connects Vertex A to Vertex B iff 794 the intersection of Column A and Row B is marked 795 with an X. 797 The link-state database is pieced together from LSAs 798 generated by the routers. In the associated graphical 799 representation, the neighborhood of each router or transit 800 network is represented in a single, separate LSA. Figure 4 801 shows these LSAs graphically. Router RT12 has an interface 802 to two broadcast networks and a SLIP line to a host. 803 Network N6 is a broadcast network with three attached 804 routers. The cost of all links from Network N6 to its 805 attached routers is 0. Note that the LSA for Network N6 is 806 actually generated by one of the network's attached routers: 807 the router that has been elected Designated Router for the 808 network. 810 2.2. The shortest-path tree 812 When no OSPF areas are configured, each router in the Autonomous 813 System has an identical link-state database, leading to an 814 identical graphical representation. A router generates its 815 routing table from this graph by calculating a tree of shortest 816 paths with the router itself as root. Obviously, the shortest- 817 path tree depends on the router doing the calculation. The 818 shortest-path tree for Router RT6 in our example is depicted in 819 Figure 5. 821 The tree gives the entire path to any destination network or 822 host. However, only the next hop to the destination is used in 823 the forwarding process. Note also that the best route to any 824 router has also been calculated. For the processing of external 825 data, we note the next hop and distance to any router 826 advertising external routes. The resulting routing table for 827 Router RT6 is pictured in Table 2. Note that there is a 828 separate route for each end of a numbered point-to-point network 829 (in this case, the serial line between Routers RT6 and RT10). 831 **FROM** **FROM** 833 |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| 834 * -------------------- * ---------------------- 835 * RT12| | | | | * RT9| | | |0 | 836 T N9|1 | | | | T RT11| | | |0 | 837 O N10|2 | | | | O RT12| | | |0 | 838 * H1|10 | | | | * N9| | | | | 839 * * 840 RT12's router-LSA N9's network-LSA 842 Figure 4: Individual link state components 844 Networks and routers are represented by vertices. 845 An edge of cost X connects Vertex A to Vertex B iff 846 the intersection of Column A and Row B is marked 847 with an X. 849 RT6(origin) 850 RT5 o------------o-----------o Ib 851 /|\ 6 |\ 7 852 8/8|8\ | \ 853 / | \ | \ 854 o | o | \7 855 N12 o N14 | \ 856 N13 2 | \ 857 N4 o-----o RT3 \ 858 / \ 5 859 1/ RT10 o-------o Ia 860 / |\ 861 RT4 o-----o N3 3| \1 862 /| | \ N6 RT7 863 / | N8 o o---------o 864 / | | | /| 865 RT2 o o RT1 | | 2/ |9 866 / | | |RT8 / | 867 /3 |3 RT11 o o o o 868 / | | | N12 N15 869 N2 o o N1 1| |4 870 | | 871 N9 o o N7 872 /| 873 / | 874 N11 RT9 / |RT12 875 o--------o-------o o--------o H1 876 3 | 10 877 |2 878 | 879 o N10 881 Figure 5: The SPF tree for Router RT6 883 Edges that are not marked with a cost have a cost of 884 of zero (these are network-to-router links). Routes 885 to networks N12-N15 are external information that is 886 considered in Section 2.3 887 Destination Next Hop Distance 888 __________________________________ 889 N1 RT3 10 890 N2 RT3 10 891 N3 RT3 7 892 N4 RT3 8 893 Ib * 7 894 Ia RT10 12 895 N6 RT10 8 896 N7 RT10 12 897 N8 RT10 10 898 N9 RT10 11 899 N10 RT10 13 900 N11 RT10 14 901 H1 RT10 21 902 __________________________________ 903 RT5 RT5 6 904 RT7 RT10 8 906 Table 2: The portion of Router RT6's routing table listing local 907 destinations. 909 Routes to networks belonging to other AS'es (such as N12) appear 910 as dashed lines on the shortest path tree in Figure 5. Use of 911 this externally derived routing information is considered in the 912 next section. 914 2.3. Use of external routing information 916 After the tree is created the external routing information is 917 examined. This external routing information may originate from 918 another routing protocol such as BGP, or be statically 919 configured (static routes). Default routes can also be included 920 as part of the Autonomous System's external routing information. 922 External routing information is flooded unaltered throughout the 923 AS. In our example, all the routers in the Autonomous System 924 know that Router RT7 has two external routes, with metrics 2 and 925 9. 927 OSPF supports two types of external metrics. Type 1 external 928 metrics are expressed in the same units as OSPF interface cost 929 (i.e., in terms of the link state metric). Type 2 external 930 metrics are an order of magnitude larger; any Type 2 metric is 931 considered greater than the cost of any path internal to the AS. 932 Use of Type 2 external metrics assumes that routing between 933 AS'es is the major cost of routing a packet, and eliminates the 934 need for conversion of external costs to internal link state 935 metrics. 937 As an example of Type 1 external metric processing, suppose that 938 the Routers RT7 and RT5 in Figure 2 are advertising Type 1 939 external metrics. For each advertised external route, the total 940 cost from Router RT6 is calculated as the sum of the external 941 route's advertised cost and the distance from Router RT6 to the 942 advertising router. When two routers are advertising the same 943 external destination, RT6 picks the advertising router providing 944 the minimum total cost. RT6 then sets the next hop to the 945 external destination equal to the next hop that would be used 946 when routing packets to the chosen advertising router. 948 In Figure 2, both Router RT5 and RT7 are advertising an external 949 route to destination Network N12. Router RT7 is preferred since 950 it is advertising N12 at a distance of 10 (8+2) to Router RT6, 951 which is better than Router RT5's 14 (6+8). Table 3 shows the 952 entries that are added to the routing table when external routes 953 are examined: 955 Destination Next Hop Distance 956 __________________________________ 957 N12 RT10 10 958 N13 RT5 14 959 N14 RT5 14 960 N15 RT10 17 962 Table 3: The portion of Router RT6's routing table 963 listing external destinations. 965 Processing of Type 2 external metrics is simpler. The AS 966 boundary router advertising the smallest external metric is 967 chosen, regardless of the internal distance to the AS boundary 968 router. Suppose in our example both Router RT5 and Router RT7 969 were advertising Type 2 external routes. Then all traffic 970 destined for Network N12 would be forwarded to Router RT7, since 971 2 < 8. When several equal-cost Type 2 routes exist, the 972 internal distance to the advertising routers is used to break 973 the tie. 975 Both Type 1 and Type 2 external metrics can be present in the AS 976 at the same time. In that event, Type 1 external metrics always 977 take precedence. 979 This section has assumed that packets destined for external 980 destinations are always routed through the advertising AS 981 boundary router. This is not always desirable. For example, 982 suppose in Figure 2 there is an additional router attached to 983 Network N6, called Router RTX. Suppose further that RTX does 984 not participate in OSPF routing, but does exchange BGP 985 information with the AS boundary router RT7. Then, Router RT7 986 would end up advertising OSPF external routes for all 987 destinations that should be routed to RTX. An extra hop will 988 sometimes be introduced if packets for these destinations need 989 always be routed first to Router RT7 (the advertising router). 991 To deal with this situation, the OSPF protocol allows an AS 992 boundary router to specify a "forwarding address" in its AS- 993 external-LSAs. In the above example, Router RT7 would specify 994 RTX's IP address as the "forwarding address" for all those 995 destinations whose packets should be routed directly to RTX. 997 The "forwarding address" has one other application. It enables 998 routers in the Autonomous System's interior to function as 999 "route servers". For example, in Figure 2 the router RT6 could 1000 become a route server, gaining external routing information 1001 through a combination of static configuration and external 1002 routing protocols. RT6 would then start advertising itself as 1003 an AS boundary router, and would originate a collection of OSPF 1004 AS-external-LSAs. In each AS-external-LSA, Router RT6 would 1005 specify the correct Autonomous System exit point to use for the 1006 destination through appropriate setting of the LSA's "forwarding 1007 address" field. 1009 2.4. Equal-cost multipath 1011 The above discussion has been simplified by considering only a 1012 single route to any destination. In reality, if multiple 1013 equal-cost routes to a destination exist, they are all 1014 discovered and used. This requires no conceptual changes to the 1015 algorithm, and its discussion is postponed until we consider the 1016 tree-building process in more detail. 1018 With equal cost multipath, a router potentially has several 1019 available next hops towards any given destination. 1021 2.5. TOS-based routing 1023 OSPF can calculate a separate set of routes for each IP Type of 1024 Service. This means that, for any destination, there can 1025 potentially be multiple routing table entries, one for each IP 1026 TOS. The IP TOS values are represented in OSPF exactly as they 1027 appear in the IP packet header. 1029 Up to this point, all examples shown have assumed that routes do 1030 not vary on TOS. In order to differentiate routes based on TOS, 1031 separate interface costs can be configured for each TOS. For 1032 example, in Figure 2 there could be multiple costs (one for each 1033 TOS) listed for each interface. A cost for TOS 0 must always be 1034 specified. 1036 When interface costs vary based on TOS, a separate shortest path 1037 tree is calculated for each TOS (see Section 2.2). In addition, 1038 external costs can vary based on TOS. For example, in Figure 2 1039 Router RT7 could advertise a separate type 1 external metric for 1040 each TOS. Then, when calculating the TOS X distance to Network 1041 N15 the cost of the shortest TOS X path to RT7 would be added to 1042 the TOS X cost advertised by RT7 for Network N15 (see Section 1043 2.3). 1045 All OSPF implementations must be capable of calculating routes 1046 based on TOS. However, OSPF routers can be configured to route 1047 all packets on the TOS 0 path (see Appendix C), eliminating the 1048 need to calculate non-zero TOS paths. This can be used to 1049 conserve routing table space and processing resources in the 1050 router. These TOS-0-only routers can be mixed with routers that 1051 do route based on TOS. TOS-0-only routers will be avoided as 1052 much as possible when forwarding traffic requesting a non-zero 1053 TOS. 1055 It may be the case that no path exists for some non-zero TOS, 1056 even if the router is calculating non-zero TOS paths. In that 1057 case, packets requesting that non-zero TOS are routed along the 1058 TOS 0 path (see Section 11.1). 1060 3. Splitting the AS into Areas 1062 OSPF allows collections of contiguous networks and hosts to be 1063 grouped together. Such a group, together with the routers having 1064 interfaces to any one of the included networks, is called an area. 1065 Each area runs a separate copy of the basic link-state routing 1066 algorithm. This means that each area has its own link-state 1067 database and corresponding graph, as explained in the previous 1068 section. 1070 The topology of an area is invisible from the outside of the area. 1071 Conversely, routers internal to a given area know nothing of the 1072 detailed topology external to the area. This isolation of knowledge 1073 enables the protocol to effect a marked reduction in routing traffic 1074 as compared to treating the entire Autonomous System as a single 1075 link-state domain. 1077 With the introduction of areas, it is no longer true that all 1078 routers in the AS have an identical link-state database. A router 1079 actually has a separate link-state database for each area it is 1080 connected to. (Routers connected to multiple areas are called area 1081 border routers). Two routers belonging to the same area have, for 1082 that area, identical area link-state databases. 1084 Routing in the Autonomous System takes place on two levels, 1085 depending on whether the source and destination of a packet reside 1086 in the same area (intra-area routing is used) or different areas 1087 (inter-area routing is used). In intra-area routing, the packet is 1088 routed solely on information obtained within the area; no routing 1089 information obtained from outside the area can be used. This 1090 protects intra-area routing from the injection of bad routing 1091 information. We discuss inter-area routing in Section 3.2. 1093 3.1. The backbone of the Autonomous System 1095 The OSPF backbone is the special OSPF Area 0 (often written as 1096 Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP 1097 addresses). The OSPF backbone always contains all area border 1098 routers. The backbone is responsible for distributing routing 1099 information between non-backbone areas. The backbone must be 1100 contiguous. However, it need not be physically contiguous; 1101 backbone connectivity can be established/maintained through the 1102 configuration of virtual links. 1104 Virtual links can be configured between any two backbone routers 1105 that have an interface to a common non-backbone area. Virtual 1106 links belong to the backbone. The protocol treats two routers 1107 joined by a virtual link as if they were connected by an 1108 unnumbered point-to-point backbone network. On the graph of the 1109 backbone, two such routers are joined by arcs whose costs are 1110 the intra-area distances between the two routers. The routing 1111 protocol traffic that flows along the virtual link uses intra- 1112 area routing only. 1114 3.2. Inter-area routing 1116 When routing a packet between two non-backbone areas the 1117 backbone is used. The path that the packet will travel can be 1118 broken up into three contiguous pieces: an intra-area path from 1119 the source to an area border router, a backbone path between the 1120 source and destination areas, and then another intra-area path 1121 to the destination. The algorithm finds the set of such paths 1122 that have the smallest cost. 1124 Looking at this another way, inter-area routing can be pictured 1125 as forcing a star configuration on the Autonomous System, with 1126 the backbone as hub and each of the non-backbone areas as 1127 spokes. 1129 The topology of the backbone dictates the backbone paths used 1130 between areas. The topology of the backbone can be enhanced by 1131 adding virtual links. This gives the system administrator some 1132 control over the routes taken by inter-area traffic. 1134 The correct area border router to use as the packet exits the 1135 source area is chosen in exactly the same way routers 1136 advertising external routes are chosen. Each area border router 1137 in an area summarizes for the area its cost to all networks 1138 external to the area. After the SPF tree is calculated for the 1139 area, routes to all inter-area destinations are calculated by 1140 examining the summaries of the area border routers. 1142 3.3. Classification of routers 1144 Before the introduction of areas, the only OSPF routers having a 1145 specialized function were those advertising external routing 1146 information, such as Router RT5 in Figure 2. When the AS is 1147 split into OSPF areas, the routers are further divided according 1148 to function into the following four overlapping categories: 1150 Internal routers 1151 A router with all directly connected networks belonging to 1152 the same area. These routers run a single copy of the basic 1153 routing algorithm. 1155 Area border routers 1156 A router that attaches to multiple areas. Area border 1157 routers run multiple copies of the basic algorithm, one copy 1158 for each attached area. Area border routers condense the 1159 topological information of their attached areas for 1160 distribution to the backbone. The backbone in turn 1161 distributes the information to the other areas. 1163 Backbone routers 1164 A router that has an interface to the backbone area. This 1165 includes all routers that interface to more than one area 1166 (i.e., area border routers). However, backbone routers do 1167 not have to be area border routers. Routers with all 1168 interfaces connecting to the backbone area are supported. 1170 AS boundary routers 1171 A router that exchanges routing information with routers 1172 belonging to other Autonomous Systems. Such a router 1173 advertises AS external routing information throughout the 1174 Autonomous System. The path to each AS boundary router is 1175 known by every router in the AS. This classification is 1176 completely independent of the previous classifications: AS 1177 boundary routers may be internal or area border routers, and 1178 may or may not participate in the backbone. 1180 3.4. A sample area configuration 1182 Figure 6 shows a sample area configuration. The first area 1183 consists of networks N1-N4, along with their attached routers 1184 RT1-RT4. The second area consists of networks N6-N8, along with 1185 their attached routers RT7, RT8, RT10 and RT11. The third area 1186 consists of networks N9-N11 and Host H1, along with their 1187 attached routers RT9, RT11 and RT12. The third area has been 1188 configured so that networks N9-N11 and Host H1 will all be 1189 grouped into a single route, when advertised external to the 1190 area (see Section 3.5 for more details). 1192 In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are 1193 internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area 1194 border routers. Finally, as before, Routers RT5 and RT7 are AS 1195 boundary routers. 1197 Figure 7 shows the resulting link-state database for the Area 1. 1198 The figure completely describes that area's intra-area routing. 1199 It also shows the complete view of the internet for the two 1200 internal routers RT1 and RT2. It is the job of the area border 1201 routers, RT3 and RT4, to advertise into Area 1 the distances to 1202 all destinations external to the area. These are indicated in 1203 Figure 7 by the dashed stub routes. Also, RT3 and RT4 must 1204 advertise into Area 1 the location of the AS boundary routers 1205 RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are 1206 flooded throughout the entire AS, and in particular throughout 1207 ........................... 1208 . + . 1209 . | 3+---+ . N12 N14 1210 . N1|--|RT1|\ 1 . \ N13 / 1211 . | +---+ \ . 8\ |8/8 1212 . + \ ____ . \|/ 1213 . / \ 1+---+8 8+---+6 1214 . * N3 *---|RT4|------|RT5|--------+ 1215 . \____/ +---+ +---+ | 1216 . + / \ . |7 | 1217 . | 3+---+ / \ . | | 1218 . N2|--|RT2|/1 1\ . |6 | 1219 . | +---+ +---+8 6+---+ | 1220 . + |RT3|------|RT6| | 1221 . +---+ +---+ | 1222 . 2/ . Ia|7 | 1223 . / . | | 1224 . +---------+ . | | 1225 .Area 1 N4 . | | 1226 ........................... | | 1227 .......................... | | 1228 . N11 . | | 1229 . +---------+ . | | 1230 . | . | | N12 1231 . |3 . Ib|5 |6 2/ 1232 . +---+ . +----+ +---+/ 1233 . |RT9| . .........|RT10|.....|RT7|---N15. 1234 . +---+ . . +----+ +---+ 9 . 1235 . |1 . . + /3 1\ |1 . 1236 . _|__ . . | / \ __|_ . 1237 . / \ 1+----+2 |/ \ / \ . 1238 . * N9 *------|RT11|----| * N6 * . 1239 . \____/ +----+ | \____/ . 1240 . | . . | | . 1241 . |1 . . + |1 . 1242 . +--+ 10+----+ . . N8 +---+ . 1243 . |H1|-----|RT12| . . |RT8| . 1244 . +--+SLIP +----+ . . +---+ . 1245 . |2 . . |4 . 1246 . | . . | . 1247 . +---------+ . . +--------+ . 1248 . N10 . . N7 . 1249 . . .Area 2 . 1250 .Area 3 . ................................ 1251 .......................... 1253 Figure 6: A sample OSPF area configuration 1254 Area 1. These LSAs are included in Area 1's database, and yield 1255 routes to Networks N12-N15. 1257 Routers RT3 and RT4 must also summarize Area 1's topology for 1258 distribution to the backbone. Their backbone LSAs are shown in 1259 Table 4. These summaries show which networks are contained in 1260 Area 1 (i.e., Networks N1-N4), and the distance to these 1261 networks from the routers RT3 and RT4 respectively. 1263 The link-state database for the backbone is shown in Figure 8. 1264 The set of routers pictured are the backbone routers. Router 1265 RT11 is a backbone router because it belongs to two areas. In 1266 order to make the backbone connected, a virtual link has been 1267 configured between Routers R10 and R11. 1269 The area border routers RT3, RT4, RT7, RT10 and RT11 condense 1270 the routing information of their attached non-backbone areas for 1271 distribution via the backbone; these are the dashed stubs that 1272 appear in Figure 8. Remember that the third area has been 1273 configured to condense Networks N9-N11 and Host H1 into a single 1274 route. This yields a single dashed line for networks N9-N11 and 1275 Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary 1276 routers; their externally derived information also appears on 1277 the graph in Figure 8 as stubs. 1279 The backbone enables the exchange of summary information between 1280 area border routers. Every area border router hears the area 1281 summaries from all other area border routers. It then forms a 1282 picture of the distance to all networks outside of its area by 1283 examining the collected LSAs, and adding in the backbone 1284 distance to each advertising router. 1286 Again using Routers RT3 and RT4 as an example, the procedure 1288 Network RT3 adv. RT4 adv. 1289 _____________________________ 1290 N1 4 4 1291 N2 4 4 1292 N3 1 1 1293 N4 2 3 1295 Table 4: Networks advertised to the backbone 1296 by Routers RT3 and RT4. 1298 **FROM** 1300 |RT|RT|RT|RT|RT|RT| 1301 |1 |2 |3 |4 |5 |7 |N3| 1302 ----- ------------------- 1303 RT1| | | | | | |0 | 1304 RT2| | | | | | |0 | 1305 RT3| | | | | | |0 | 1306 * RT4| | | | | | |0 | 1307 * RT5| | |14|8 | | | | 1308 T RT7| | |20|14| | | | 1309 O N1|3 | | | | | | | 1310 * N2| |3 | | | | | | 1311 * N3|1 |1 |1 |1 | | | | 1312 N4| | |2 | | | | | 1313 Ia,Ib| | |15|22| | | | 1314 N6| | |16|15| | | | 1315 N7| | |20|19| | | | 1316 N8| | |18|18| | | | 1317 N9-N11,H1| | |19|16| | | | 1318 N12| | | | |8 |2 | | 1319 N13| | | | |8 | | | 1320 N14| | | | |8 | | | 1321 N15| | | | | |9 | | 1323 Figure 7: Area 1's Database. 1325 Networks and routers are represented by vertices. 1326 An edge of cost X connects Vertex A to Vertex B iff 1327 the intersection of Column A and Row B is marked 1328 with an X. 1330 **FROM** 1332 |RT|RT|RT|RT|RT|RT|RT 1333 |3 |4 |5 |6 |7 |10|11| 1334 ------------------------ 1335 RT3| | | |6 | | | | 1336 RT4| | |8 | | | | | 1337 RT5| |8 | |6 |6 | | | 1338 RT6|8 | |7 | | |5 | | 1339 RT7| | |6 | | | | | 1340 * RT10| | | |7 | | |2 | 1341 * RT11| | | | | |3 | | 1342 T N1|4 |4 | | | | | | 1343 O N2|4 |4 | | | | | | 1344 * N3|1 |1 | | | | | | 1345 * N4|2 |3 | | | | | | 1346 Ia| | | | | |5 | | 1347 Ib| | | |7 | | | | 1348 N6| | | | |1 |1 |3 | 1349 N7| | | | |5 |5 |7 | 1350 N8| | | | |4 |3 |2 | 1351 N9-N11,H1| | | | | | |1 | 1352 N12| | |8 | |2 | | | 1353 N13| | |8 | | | | | 1354 N14| | |8 | | | | | 1355 N15| | | | |9 | | | 1357 Figure 8: The backbone's database. 1359 Networks and routers are represented by vertices. 1360 An edge of cost X connects Vertex A to Vertex B iff 1361 the intersection of Column A and Row B is marked 1362 with an X. 1364 goes as follows: They first calculate the SPF tree for the 1365 backbone. This gives the distances to all other area border 1366 routers. Also noted are the distances to networks (Ia and Ib) 1367 and AS boundary routers (RT5 and RT7) that belong to the 1368 backbone. This calculation is shown in Table 5. 1370 Next, by looking at the area summaries from these area border 1371 routers, RT3 and RT4 can determine the distance to all networks 1372 outside their area. These distances are then advertised 1373 internally to the area by RT3 and RT4. The advertisements that 1374 Router RT3 and RT4 will make into Area 1 are shown in Table 6. 1375 Note that Table 6 assumes that an area range has been configured 1376 Area border dist from dist from 1377 router RT3 RT4 1378 ______________________________________ 1379 to RT3 * 21 1380 to RT4 22 * 1381 to RT7 20 14 1382 to RT10 15 22 1383 to RT11 18 25 1384 ______________________________________ 1385 to Ia 20 27 1386 to Ib 15 22 1387 ______________________________________ 1388 to RT5 14 8 1389 to RT7 20 14 1391 Table 5: Backbone distances calculated 1392 by Routers RT3 and RT4. 1394 for the backbone which groups Ia and Ib into a single LSA. 1396 The information imported into Area 1 by Routers RT3 and RT4 1397 enables an internal router, such as RT1, to choose an area 1398 border router intelligently. Router RT1 would use RT4 for 1399 traffic to Network N6, RT3 for traffic to Network N10, and would 1400 load share between the two for traffic to Network N8. 1402 Destination RT3 adv. RT4 adv. 1403 _________________________________ 1404 Ia,Ib 15 22 1405 N6 16 15 1406 N7 20 19 1407 N8 18 18 1408 N9-N11,H1 19 26 1409 _________________________________ 1410 RT5 14 8 1411 RT7 20 14 1413 Table 6: Destinations advertised into Area 1 1414 by Routers RT3 and RT4. 1416 Router RT1 can also determine in this manner the shortest path 1417 to the AS boundary routers RT5 and RT7. Then, by looking at RT5 1418 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or 1419 RT7 when sending to a destination in another Autonomous System 1420 (one of the networks N12-N15). 1422 Note that a failure of the line between Routers RT6 and RT10 1423 will cause the backbone to become disconnected. Configuring a 1424 virtual link between Routers RT7 and RT10 will give the backbone 1425 more connectivity and more resistance to such failures. 1427 3.5. IP subnetting support 1429 OSPF attaches an IP address mask to each advertised route. The 1430 mask indicates the range of addresses being described by the 1431 particular route. For example, a summary-LSA for the 1432 destination 128.185.0.0 with a mask of 0xffff0000 actually is 1433 describing a single route to the collection of destinations 1434 128.185.0.0 - 128.185.255.255. Similarly, host routes are 1435 always advertised with a mask of 0xffffffff, indicating the 1436 presence of only a single destination. 1438 Including the mask with each advertised destination enables the 1439 implementation of what is commonly referred to as variable- 1440 length subnetting. This means that a single IP class A, B, or C 1441 network number can be broken up into many subnets of various 1442 sizes. For example, the network 128.185.0.0 could be broken up 1443 into 62 variable-sized subnets: 15 subnets of size 4K, 15 1444 subnets of size 256, and 32 subnets of size 8. Table 7 shows 1445 some of the resulting network addresses together with their 1446 masks. 1448 Network address IP address mask Subnet size 1449 _______________________________________________ 1450 128.185.16.0 0xfffff000 4K 1451 128.185.1.0 0xffffff00 256 1452 128.185.0.8 0xfffffff8 8 1454 Table 7: Some sample subnet sizes. 1456 There are many possible ways of dividing up a class A, B, and C 1457 network into variable sized subnets. The precise procedure for 1458 doing so is beyond the scope of this specification. This 1459 specification however establishes the following guideline: When 1460 an IP packet is forwarded, it is always forwarded to the network 1461 that is the best match for the packet's destination. Here best 1462 match is synonymous with the longest or most specific match. 1463 For example, the default route with destination of 0.0.0.0 and 1464 mask 0x00000000 is always a match for every IP destination. Yet 1465 it is always less specific than any other match. Subnet masks 1466 must be assigned so that the best match for any IP destination 1467 is unambiguous. 1469 Attaching an address mask to each route also enables the support 1470 of IP supernetting. For example, a single physical network 1471 segment could be assigned the [address,mask] pair 1472 [192.9.4.0,0xfffffc00]. The segment would then be single IP 1473 network, containing addresses from the four consecutive class C 1474 network numbers 192.9.4.0 through 192.9.7.0. Such addressing is 1475 now becoming commonplace with the advent of CIDR (see [Ref10]). 1477 In order to get better aggregation at area boundaries, area 1478 address ranges can be employed (see Section C.2 for more 1479 details). Each address range is defined as an [address,mask] 1480 pair. Many separate networks may then be contained in a single 1481 address range, just as a subnetted network is composed of many 1482 separate subnets. Area border routers then summarize the area 1483 contents (for distribution to the backbone) by advertising a 1484 single route for each address range. The cost of the route is 1485 the minimum cost to any of the networks falling in the specified 1486 range. 1488 For example, an IP subnetted network might be configured as a 1489 single OSPF area. In that case, a single address range could be 1490 configured: a class A, B, or C network number along with its 1491 natural IP mask. Inside the area, any number of variable sized 1492 subnets could be defined. However, external to the area a 1493 single route for the entire subnetted network would be 1494 distributed, hiding even the fact that the network is subnetted 1495 at all. The cost of this route is the minimum of the set of 1496 costs to the component subnets. 1498 3.6. Supporting stub areas 1500 In some Autonomous Systems, the majority of the link-state 1501 database may consist of AS-external-LSAs. An OSPF AS-external- 1502 LSA is usually flooded throughout the entire AS. However, OSPF 1503 allows certain areas to be configured as "stub areas". AS- 1504 external-LSAs are not flooded into/throughout stub areas; 1505 routing to AS external destinations in these areas is based on a 1506 (per-area) default only. This reduces the link-state database 1507 size, and therefore the memory requirements, for a stub area's 1508 internal routers. 1510 In order to take advantage of the OSPF stub area support, 1511 default routing must be used in the stub area. This is 1512 accomplished as follows. One or more of the stub area's area 1513 border routers must advertise a default route into the stub area 1514 via summary-LSAs. These summary defaults are flooded throughout 1515 the stub area, but no further. (For this reason these defaults 1516 pertain only to the particular stub area). These summary 1517 default routes will be used for any destination that is not 1518 explicitly reachable by an intra-area or inter-area path (i.e., 1519 AS external destinations). 1521 An area can be configured as a stub when there is a single exit 1522 point from the area, or when the choice of exit point need not 1523 be made on a per-external-destination basis. For example, Area 1524 3 in Figure 6 could be configured as a stub area, because all 1525 external traffic must travel though its single area border 1526 router RT11. If Area 3 were configured as a stub, Router RT11 1527 would advertise a default route for distribution inside Area 3 1528 (in a summary-LSA), instead of flooding the AS-external-LSAs for 1529 Networks N12-N15 into/throughout the area. 1531 The OSPF protocol ensures that all routers belonging to an area 1532 agree on whether the area has been configured as a stub. This 1533 guarantees that no confusion will arise in the flooding of AS- 1534 external-LSAs. 1536 There are a couple of restrictions on the use of stub areas. 1537 Virtual links cannot be configured through stub areas. In 1538 addition, AS boundary routers cannot be placed internal to stub 1539 areas. 1541 3.7. Partitions of areas 1543 OSPF does not actively attempt to repair area partitions. When 1544 an area becomes partitioned, each component simply becomes a 1545 separate area. The backbone then performs routing between the 1546 new areas. Some destinations reachable via intra-area routing 1547 before the partition will now require inter-area routing. 1549 However, in order to maintain full routing after the partition, 1550 an address range must not be split across multiple components of 1551 the area partition. Also, the backbone itself must not 1552 partition. If it does, parts of the Autonomous System will 1553 become unreachable. Backbone partitions can be repaired by 1554 configuring virtual links (see Section 15). 1556 Another way to think about area partitions is to look at the 1557 Autonomous System graph that was introduced in Section 2. Area 1558 IDs can be viewed as colors for the graph's edges.[1] Each edge 1559 of the graph connects to a network, or is itself a point-to- 1560 point network. In either case, the edge is colored with the 1561 network's Area ID. 1563 A group of edges, all having the same color, and interconnected 1564 by vertices, represents an area. If the topology of the 1565 Autonomous System is intact, the graph will have several regions 1566 of color, each color being a distinct Area ID. 1568 When the AS topology changes, one of the areas may become 1569 partitioned. The graph of the AS will then have multiple 1570 regions of the same color (Area ID). The routing in the 1571 Autonomous System will continue to function as long as these 1572 regions of same color are connected by the single backbone 1573 region. 1575 4. Functional Summary 1577 A separate copy of OSPF's basic routing algorithm runs in each area. 1578 Routers having interfaces to multiple areas run multiple copies of 1579 the algorithm. A brief summary of the routing algorithm follows. 1581 When a router starts, it first initializes the routing protocol data 1582 structures. The router then waits for indications from the lower- 1583 level protocols that its interfaces are functional. 1585 A router then uses the OSPF's Hello Protocol to acquire neighbors. 1586 The router sends Hello packets to its neighbors, and in turn 1587 receives their Hello packets. On broadcast and point-to-point 1588 networks, the router dynamically detects its neighboring routers by 1589 sending its Hello packets to the multicast address AllSPFRouters. 1590 On non-broadcast networks, some configuration information may be 1591 necessary in order to discover neighbors. On broadcast and NBMA 1592 networks the Hello Protocol also elects a Designated router for the 1593 network. 1595 The router will attempt to form adjacencies with some of its newly 1596 acquired neighbors. Link-state databases are synchronized between 1597 pairs of adjacent routers. On broadcast and NBMA networks, the 1598 Designated Router determines which routers should become adjacent. 1600 Adjacencies control the distribution of routing information. 1601 Routing updates are sent and received only on adjacencies. 1603 A router periodically advertises its state, which is also called 1604 link state. Link state is also advertised when a router's state 1605 changes. A router's adjacencies are reflected in the contents of 1606 its LSAs. This relationship between adjacencies and link state 1607 allows the protocol to detect dead routers in a timely fashion. 1609 LSAs are flooded throughout the area. The flooding algorithm is 1610 reliable, ensuring that all routers in an area have exactly the same 1611 link-state database. This database consists of the collection of 1612 LSAs originated by each router belonging to the area. From this 1613 database each router calculates a shortest-path tree, with itself as 1614 root. This shortest-path tree in turn yields a routing table for 1615 the protocol. 1617 4.1. Inter-area routing 1619 The previous section described the operation of the protocol 1620 within a single area. For intra-area routing, no other routing 1621 information is pertinent. In order to be able to route to 1622 destinations outside of the area, the area border routers inject 1623 additional routing information into the area. This additional 1624 information is a distillation of the rest of the Autonomous 1625 System's topology. 1627 This distillation is accomplished as follows: Each area border 1628 router is by definition connected to the backbone. Each area 1629 border router summarizes the topology of its attached non- 1630 backbone areas for transmission on the backbone, and hence to 1631 all other area border routers. An area border router then has 1632 complete topological information concerning the backbone, and 1633 the area summaries from each of the other area border routers. 1634 From this information, the router calculates paths to all 1635 inter-area destinations. The router then advertises these paths 1636 into its attached areas. This enables the area's internal 1637 routers to pick the best exit router when forwarding traffic 1638 inter-area destinations. 1640 4.2. AS external routes 1642 Routers that have information regarding other Autonomous Systems 1643 can flood this information throughout the AS. This external 1644 routing information is distributed verbatim to every 1645 participating router. There is one exception: external routing 1646 information is not flooded into "stub" areas (see Section 3.6). 1648 To utilize external routing information, the path to all routers 1649 advertising external information must be known throughout the AS 1650 (excepting the stub areas). For that reason, the locations of 1651 these AS boundary routers are summarized by the (non-stub) area 1652 border routers. 1654 4.3. Routing protocol packets 1656 The OSPF protocol runs directly over IP, using IP protocol 89. 1657 OSPF does not provide any explicit fragmentation/reassembly 1658 support. When fragmentation is necessary, IP 1659 fragmentation/reassembly is used. OSPF protocol packets have 1660 been designed so that large protocol packets can generally be 1661 split into several smaller protocol packets. This practice is 1662 recommended; IP fragmentation should be avoided whenever 1663 possible. 1665 Routing protocol packets should always be sent with the IP TOS 1666 field set to 0. If at all possible, routing protocol packets 1667 should be given preference over regular IP data traffic, both 1668 when being sent and received. As an aid to accomplishing this, 1669 OSPF protocol packets should have their IP precedence field set 1670 to the value Internetwork Control (see [Ref5]). 1672 All OSPF protocol packets share a common protocol header that is 1673 described in Appendix A. The OSPF packet types are listed below 1674 in Table 8. Their formats are also described in Appendix A. 1676 Type Packet name Protocol function 1677 __________________________________________________________ 1678 1 Hello Discover/maintain neighbors 1679 2 Database Description Summarize database contents 1680 3 Link State Request Database download 1681 4 Link State Update Database update 1682 5 Link State Ack Flooding acknowledgment 1684 Table 8: OSPF packet types. 1686 OSPF's Hello protocol uses Hello packets to discover and 1687 maintain neighbor relationships. The Database Description and 1688 Link State Request packets are used in the forming of 1689 adjacencies. OSPF's reliable update mechanism is implemented by 1690 the Link State Update and Link State Acknowledgment packets. 1692 Each Link State Update packet carries a set of new link state 1693 advertisements (LSAs) one hop further away from their point of 1694 origination. A single Link State Update packet may contain the 1695 LSAs of several routers. Each LSA is tagged with the ID of the 1696 originating router and a checksum of its link state contents. 1697 Each LSA also has a type field; the different types of OSPF LSAs 1698 are listed below in Table 9. 1700 OSPF routing packets (with the exception of Hellos) are sent 1701 only over adjacencies. This means that all OSPF protocol 1702 packets travel a single IP hop, except those that are sent over 1703 virtual adjacencies. The IP source address of an OSPF protocol 1704 packet is one end of a router adjacency, and the IP destination 1705 address is either the other end of the adjacency or an IP 1706 multicast address. 1708 LS LSA LSA description 1709 type name 1710 ________________________________________________________ 1711 1 Router-LSAs Originated by all routers. 1712 This LSA describes 1713 the collected states of the 1714 router's interfaces to an 1715 area. Flooded throughout a 1716 single area only. 1717 ________________________________________________________ 1718 2 Network-LSAs Originated for broadcast 1719 and NBMA networks by 1720 the Designated Router. This 1721 LSA contains the 1722 list of routers connected 1723 to the network. Flooded 1724 throughout a single area only. 1725 ________________________________________________________ 1726 3,4 Summary-LSAs Originated by area border 1727 routers, and flooded through- 1728 out the LSA's associated 1729 area. Each summary-LSA 1730 describes a route to a 1731 destination outside the area, 1732 yet still inside the AS 1733 (i.e., an inter-area route). 1734 Type 3 summary-LSAs describe 1735 routes to networks. Type 4 1736 summary-LSAs describe 1737 routes to AS boundary routers. 1738 ________________________________________________________ 1739 5 AS-external-LSAs Originated by AS boundary 1740 routers, and flooded through- 1741 out the AS. Each 1742 AS-external-LSA describes 1743 a route to a destination in 1744 another Autonomous System. 1745 Default routes for the AS can 1746 also be described by 1747 AS-external-LSAs. 1749 Table 9: OSPF link state advertisements (LSAs). 1751 4.4. Basic implementation requirements 1753 An implementation of OSPF requires the following pieces of 1754 system support: 1756 Timers 1757 Two different kind of timers are required. The first kind, 1758 called "single shot timers", fire once and cause a protocol 1759 event to be processed. The second kind, called "interval 1760 timers", fire at continuous intervals. These are used for 1761 the sending of packets at regular intervals. A good example 1762 of this is the regular broadcast of Hello packets. The 1763 granularity of both kinds of timers is one second. 1765 Interval timers should be implemented to avoid drift. In 1766 some router implementations, packet processing can affect 1767 timer execution. When multiple routers are attached to a 1768 single network, all doing broadcasts, this can lead to the 1769 synchronization of routing packets (which should be 1770 avoided). If timers cannot be implemented to avoid drift, 1771 small random amounts should be added to/subtracted from the 1772 interval timer at each firing. 1774 IP multicast 1775 Certain OSPF packets take the form of IP multicast 1776 datagrams. Support for receiving and sending IP multicast 1777 datagrams, along with the appropriate lower-level protocol 1778 support, is required. The IP multicast datagrams used by 1779 OSPF never travel more than one hop. For this reason, the 1780 ability to forward IP multicast datagrams is not required. 1781 For information on IP multicast, see [Ref7]. 1783 Variable-length subnet support 1784 The router's IP protocol support must include the ability to 1785 divide a single IP class A, B, or C network number into many 1786 subnets of various sizes. This is commonly called 1787 variable-length subnetting; see Section 3.5 for details. 1789 IP supernetting support 1790 The router's IP protocol support must include the ability to 1791 aggregate contiguous collections of IP class A, B, and C 1792 networks into larger quantities called supernets. 1793 Supernetting has been proposed as one way to improve the 1794 scaling of IP routing in the worldwide Internet. For more 1795 information on IP supernetting, see [Ref10]. 1797 Lower-level protocol support 1798 The lower level protocols referred to here are the network 1799 access protocols, such as the Ethernet data link layer. 1800 Indications must be passed from these protocols to OSPF as 1801 the network interface goes up and down. For example, on an 1802 ethernet it would be valuable to know when the ethernet 1803 transceiver cable becomes unplugged. 1805 Non-broadcast lower-level protocol support 1806 On non-broadcast networks, the OSPF Hello Protocol can be 1807 aided by providing an indication when an attempt is made to 1808 send a packet to a dead or non-existent router. For 1809 example, on an X.25 PDN a dead neighboring router may be 1810 indicated by the reception of a X.25 clear with an 1811 appropriate cause and diagnostic, and this information would 1812 be passed to OSPF. 1814 List manipulation primitives 1815 Much of the OSPF functionality is described in terms of its 1816 operation on lists of LSAs. For example, the collection of 1817 LSAs that will be retransmitted to an adjacent router until 1818 acknowledged are described as a list. Any particular LSA 1819 may be on many such lists. An OSPF implementation needs to 1820 be able to manipulate these lists, adding and deleting 1821 constituent LSAs as necessary. 1823 Tasking support 1824 Certain procedures described in this specification invoke 1825 other procedures. At times, these other procedures should 1826 be executed in-line, that is, before the current procedure 1827 is finished. This is indicated in the text by instructions 1828 to execute a procedure. At other times, the other 1829 procedures are to be executed only when the current 1830 procedure has finished. This is indicated by instructions 1831 to schedule a task. 1833 4.5. Optional OSPF capabilities 1835 The OSPF protocol defines several optional capabilities. A 1836 router indicates the optional capabilities that it supports in 1837 its OSPF Hello packets, Database Description packets and in its 1838 LSAs. This enables routers supporting a mix of optional 1839 capabilities to coexist in a single Autonomous System. 1841 Some capabilities must be supported by all routers attached to a 1842 specific area. In this case, a router will not accept a 1843 neighbor's Hello Packet unless there is a match in reported 1844 capabilities (i.e., a capability mismatch prevents a neighbor 1845 relationship from forming). An example of this is the 1846 ExternalRoutingCapability (see below). 1848 Other capabilities can be negotiated during the Database 1849 Exchange process. This is accomplished by specifying the 1850 optional capabilities in Database Description packets. A 1851 capability mismatch with a neighbor in this case will result in 1852 only a subset of the link state database being exchanged between 1853 the two neighbors. 1855 The routing table build process can also be affected by the 1856 presence/absence of optional capabilities. For example, since 1857 the optional capabilities are reported in LSAs, routers 1858 incapable of certain functions can be avoided when building the 1859 shortest path tree. An example of this is the TOS routing 1860 capability (see below). 1862 The OSPF optional capabilities defined in this memo are listed 1863 below. See Section A.2 for more information. 1865 ExternalRoutingCapability 1866 Entire OSPF areas can be configured as "stubs" (see Section 1867 3.6). AS-external-LSAs will not be flooded into stub areas. 1868 This capability is represented by the E-bit in the OSPF 1869 Options field (see Section A.2). In order to ensure 1870 consistent configuration of stub areas, all routers 1871 interfacing to such an area must have the E-bit clear in 1872 their Hello packets (see Sections 9.5 and 10.5). 1874 TOS capability 1875 All OSPF implementations must be able to calculate separate 1876 routes based on IP Type of Service. However, to save 1877 routing table space and processing resources, an OSPF router 1878 can be configured to ignore TOS when forwarding packets. In 1879 this case, the router calculates routes for TOS 0 only. 1880 This capability is represented by the T-bit in the OSPF 1881 Options field (see Section A.2). TOS-capable routers will 1882 attempt to avoid non-TOS-capable routers when calculating 1883 non-zero TOS paths. 1885 5. Protocol Data Structures 1887 The OSPF protocol is described herein in terms of its operation on 1888 various protocol data structures. The following list comprises the 1889 top-level OSPF data structures. Any initialization that needs to be 1890 done is noted. OSPF areas, interfaces and neighbors also have 1891 associated data structures that are described later in this 1892 specification. 1894 Router ID 1895 A 32-bit number that uniquely identifies this router in the AS. 1896 One possible implementation strategy would be to use the 1897 smallest IP interface address belonging to the router. If a 1898 router's OSPF Router ID is changed, the router's OSPF software 1899 should be restarted before the new Router ID takes effect. In 1900 this case the router should flush its self-originated LSAs from 1901 the routing domain (see Section 14.1) before restarting, or they 1902 will persist for up to MaxAge minutes. 1904 Area structures 1905 Each one of the areas to which the router is connected has its 1906 own data structure. This data structure describes the working 1907 of the basic OSPF algorithm. Remember that each area runs a 1908 separate copy of the basic OSPF algorithm. 1910 Backbone (area) structure 1911 The OSPF backbone area is responsible for the dissemination of 1912 inter-area routing information. 1914 Virtual links configured 1915 The virtual links configured with this router as one endpoint. 1916 In order to have configured virtual links, the router itself 1917 must be an area border router. Virtual links are identified by 1918 the Router ID of the other endpoint -- which is another area 1919 border router. These two endpoint routers must be attached to a 1920 common area, called the virtual link's Transit area. Virtual 1921 links are part of the backbone, and behave as if they were 1922 unnumbered point-to-point networks between the two routers. A 1923 virtual link uses the intra-area routing of its Transit area to 1924 forward packets. Virtual links are brought up and down through 1925 the building of the shortest-path trees for the Transit area. 1927 List of external routes 1928 These are routes to destinations external to the Autonomous 1929 System, that have been gained either through direct experience 1930 with another routing protocol (such as BGP), or through 1931 configuration information, or through a combination of the two 1932 (e.g., dynamic external information to be advertised by OSPF 1933 with configured metric). Any router having these external routes 1934 is called an AS boundary router. These routes are advertised by 1935 the router into the OSPF routing domain via AS-external-LSAs. 1937 List of AS-external-LSAs 1938 Part of the link-state database. These have originated from the 1939 AS boundary routers. They comprise routes to destinations 1940 external to the Autonomous System. Note that, if the router is 1941 itself an AS boundary router, some of these AS-external-LSAs 1942 have been self-originated. 1944 The routing table 1945 Derived from the link-state database. Each entry in the routing 1946 table is indexed by a destination, and contains the 1947 destination's cost and a set of paths to use in forwarding 1948 packets to the destination. A path is described by its type and 1949 next hop. For more information, see Section 11. 1951 TOS capability 1952 This item indicates whether the router will calculate separate 1953 routes based on TOS. This is a configurable parameter. For 1954 more information, see Sections 4.5 and 16.9. 1956 Figure 9 shows the collection of data structures present in a 1957 typical router. The router pictured is RT10, from the map in Figure 1958 6. Note that Router RT10 has a virtual link configured to Router 1959 RT11, with Area 2 as the link's Transit area. This is indicated by 1960 the dashed line in Figure 9. When the virtual link becomes active, 1961 through the building of the shortest path tree for Area 2, it 1962 becomes an interface to the backbone (see the two backbone 1963 interfaces depicted in Figure 9). 1965 6. The Area Data Structure 1967 The area data structure contains all the information used to run the 1968 basic OSPF routing algorithm. Each area maintains its own link-state 1969 database. A network belongs to a single area, and a router interface 1970 connects to a single area. Each router adjacency also belongs to a 1971 single area. 1973 The OSPF backbone is the special OSPF area responsible for 1974 disseminating inter-area routing information. 1976 The area link-state database consists of the collection of router- 1977 LSAs, network-LSAs and summary-LSAs that have originated from the 1978 area's routers. This information is flooded throughout a single 1979 area only. The list of AS-external-LSAs (see Section 5) is also 1980 considered to be part of each area's link-state database. 1982 +----+ 1983 |RT10|------+ 1984 +----+ \+-------------+ 1985 / \ |Routing Table| 1986 / \ +-------------+ 1987 / \ 1988 +------+ / \ +--------+ 1989 |Area 2|---+ +---|Backbone| 1990 +------+***********+ +--------+ 1991 / \ * / \ 1992 / \ * / \ 1993 +---------+ +---------+ +------------+ +------------+ 1994 |Interface| |Interface| |Virtual Link| |Interface Ib| 1995 | to N6 | | to N8 | | to RT11 | +------------+ 1996 +---------+ +---------+ +------------+ | 1997 / \ | | | 1998 / \ | | | 1999 +--------+ +--------+ | +-------------+ +------------+ 2000 |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| 2001 | RT8 | | RT7 | | +-------------+ +------------+ 2002 +--------+ +--------+ | 2003 | 2004 +-------------+ 2005 |Neighbor RT11| 2006 +-------------+ 2008 Figure 9: Router RT10's Data structures 2010 Area ID 2011 A 32-bit number identifying the area. The Area ID of 0.0.0.0 is 2012 reserved for the backbone. 2014 List of area address ranges 2015 In order to aggregate routing information at area boundaries, 2016 area address ranges can be employed. Each address range is 2017 specified by an [address,mask] pair and a status indication of 2018 either Advertise or DoNotAdvertise (see Section 12.4.3). 2020 Associated router interfaces 2021 This router's interfaces connecting to the area. A router 2022 interface belongs to one and only one area (or the backbone). 2023 For the backbone area this list includes all the virtual links. 2024 A virtual link is identified by the Router ID of its other 2025 endpoint; its cost is the cost of the shortest intra-area path 2026 through the Transit area that exists between the two routers. 2028 List of router-LSAs 2029 A router-LSA is generated by each router in the area. It 2030 describes the state of the router's interfaces to the area. 2032 List of network-LSAs 2033 One network-LSA is generated for each transit broadcast and NBMA 2034 network in the area. A network-LSA describes the set of routers 2035 currently connected to the network. 2037 List of summary-LSAs 2038 Summary-LSAs originate from the area's area border routers. 2039 They describe routes to destinations internal to the Autonomous 2040 System, yet external to the area (i.e., inter-area 2041 destinations). 2043 Shortest-path tree 2044 The shortest-path tree for the area, with this router itself as 2045 root. Derived from the collected router-LSAs and network-LSAs 2046 by the Dijkstra algorithm (see Section 16.1). 2048 TransitCapability 2049 This parameter indicates whether the area can carry data traffic 2050 that neither originates nor terminates in the area itself. This 2051 parameter is calculated when the area's shortest-path tree is 2052 built (see Section 16.1, where TransitCapability is set to TRUE 2053 if and only if there are one or more fully adjacent virtual 2054 links using the area as Transit area), and is used as an input 2055 to a subsequent step of the routing table build process (see 2056 Section 16.3). When an area's TransitCapability is set to TRUE, 2057 the area is said to be a "transit area". 2059 ExternalRoutingCapability 2060 Whether AS-external-LSAs will be flooded into/throughout the 2061 area. This is a configurable parameter. If AS-external-LSAs 2062 are excluded from the area, the area is called a "stub". Within 2063 stub areas, routing to AS external destinations will be based 2064 solely on a default summary route. The backbone cannot be 2065 configured as a stub area. Also, virtual links cannot be 2066 configured through stub areas. For more information, see 2067 Section 3.6. 2069 StubDefaultCost 2070 If the area has been configured as a stub area, and the router 2071 itself is an area border router, then the StubDefaultCost 2072 indicates the cost of the default summary-LSA that the router 2073 should advertise into the area. There can be a separate cost 2074 configured for each IP TOS. See Section 12.4.3 for more 2075 information. 2077 Unless otherwise specified, the remaining sections of this document 2078 refer to the operation of the OSPF protocol within a single area. 2080 7. Bringing Up Adjacencies 2082 OSPF creates adjacencies between neighboring routers for the purpose 2083 of exchanging routing information. Not every two neighboring 2084 routers will become adjacent. This section covers the generalities 2085 involved in creating adjacencies. For further details consult 2086 Section 10. 2088 7.1. The Hello Protocol 2090 The Hello Protocol is responsible for establishing and 2091 maintaining neighbor relationships. It also ensures that 2092 communication between neighbors is bidirectional. Hello packets 2093 are sent periodically out all router interfaces. Bidirectional 2094 communication is indicated when the router sees itself listed in 2095 the neighbor's Hello Packet. On broadcast and NBMA networks, 2096 the Hello Protocol elects a Designated Router for the network. 2098 The Hello Protocol works differently on broadcast networks, NBMA 2099 networks and Point-to-MultiPoint networks. On broadcast 2100 networks, each router advertises itself by periodically 2101 multicasting Hello Packets. This allows neighbors to be 2102 discovered dynamically. These Hello Packets contain the 2103 router's view of the Designated Router's identity, and the list 2104 of routers whose Hello Packets have been seen recently. 2106 On NBMA networks some configuration information may be necessary 2107 for the operation of the Hello Protocol. Each router that may 2108 potentially become Designated Router has a list of all other 2109 routers attached to the network. A router, having Designated 2110 Router potential, sends Hello Packets to all other potential 2111 Designated Routers when its interface to the NBMA network first 2112 becomes operational. This is an attempt to find the Designated 2113 Router for the network. If the router itself is elected 2114 Designated Router, it begins sending Hello Packets to all other 2115 routers attached to the network. 2117 On Point-to-MultiPoint networks, a router sends Hello Packets to 2118 all neighbors with which it can communicate directly. These 2119 neighbors may be discovered dynamically through a protocol such 2120 as Inverse ARP (see [Ref14]), or they may be configured. 2122 After a neighbor has been discovered, bidirectional 2123 communication ensured, and (if on a broadcast or NBMA network) a 2124 Designated Router elected, a decision is made regarding whether 2125 or not an adjacency should be formed with the neighbor (see 2126 Section 10.4). If an adjacency is to be formed, the first step 2127 is to synchronize the neighbors' link-state databases. This is 2128 covered in the next section. 2130 7.2. The Synchronization of Databases 2132 In a link-state routing algorithm, it is very important for all 2133 routers' link-state databases to stay synchronized. OSPF 2134 simplifies this by requiring only adjacent routers to remain 2135 synchronized. The synchronization process begins as soon as the 2136 routers attempt to bring up the adjacency. Each router 2137 describes its database by sending a sequence of Database 2138 Description packets to its neighbor. Each Database Description 2139 Packet describes a set of LSAs belonging to the router's 2140 database. When the neighbor sees an LSA that is more recent 2141 than its own database copy, it makes a note that this newer LSA 2142 should be requested. 2144 This sending and receiving of Database Description packets is 2145 called the "Database Exchange Process". During this process, 2146 the two routers form a master/slave relationship. Each Database 2147 Description Packet has a sequence number. Database Description 2148 Packets sent by the master (polls) are acknowledged by the slave 2149 through echoing of the sequence number. Both polls and their 2150 responses contain summaries of link state data. The master is 2151 the only one allowed to retransmit Database Description Packets. 2152 It does so only at fixed intervals, the length of which is the 2153 configured per-interface constant RxmtInterval. 2155 Each Database Description contains an indication that there are 2156 more packets to follow --- the M-bit. The Database Exchange 2157 Process is over when a router has received and sent Database 2158 Description Packets with the M-bit off. 2160 During and after the Database Exchange Process, each router has 2161 a list of those LSAs for which the neighbor has more up-to-date 2162 instances. These LSAs are requested in Link State Request 2163 Packets. Link State Request packets that are not satisfied are 2164 retransmitted at fixed intervals of time RxmtInterval. When the 2165 Database Description Process has completed and all Link State 2166 Requests have been satisfied, the databases are deemed 2167 synchronized and the routers are marked fully adjacent. At this 2168 time the adjacency is fully functional and is advertised in the 2169 two routers' router-LSAs. 2171 The adjacency is used by the flooding procedure as soon as the 2172 Database Exchange Process begins. This simplifies database 2173 synchronization, and guarantees that it finishes in a 2174 predictable period of time. 2176 7.3. The Designated Router 2178 Every broadcast and NBMA network has a Designated Router. The 2179 Designated Router performs two main functions for the routing 2180 protocol: 2182 o The Designated Router originates a network-LSA on behalf of 2183 the network. This LSA lists the set of routers (including 2184 the Designated Router itself) currently attached to the 2185 network. The Link State ID for this LSA (see Section 2186 12.1.4) is the IP interface address of the Designated 2187 Router. The IP network number can then be obtained by using 2188 the network's subnet/network mask. 2190 o The Designated Router becomes adjacent to all other routers 2191 on the network. Since the link state databases are 2192 synchronized across adjacencies (through adjacency bring-up 2193 and then the flooding procedure), the Designated Router 2194 plays a central part in the synchronization process. 2196 The Designated Router is elected by the Hello Protocol. A 2197 router's Hello Packet contains its Router Priority, which is 2198 configurable on a per-interface basis. In general, when a 2199 router's interface to a network first becomes functional, it 2200 checks to see whether there is currently a Designated Router for 2201 the network. If there is, it accepts that Designated Router, 2202 regardless of its Router Priority. (This makes it harder to 2203 predict the identity of the Designated Router, but ensures that 2204 the Designated Router changes less often. See below.) 2205 Otherwise, the router itself becomes Designated Router if it has 2206 the highest Router Priority on the network. A more detailed 2207 (and more accurate) description of Designated Router election is 2208 presented in Section 9.4. 2210 The Designated Router is the endpoint of many adjacencies. In 2211 order to optimize the flooding procedure on broadcast networks, 2212 the Designated Router multicasts its Link State Update Packets 2213 to the address AllSPFRouters, rather than sending separate 2214 packets over each adjacency. 2216 Section 2 of this document discusses the directed graph 2217 representation of an area. Router nodes are labelled with their 2218 Router ID. Transit network nodes are actually labelled with the 2219 IP address of their Designated Router. It follows that when the 2220 Designated Router changes, it appears as if the network node on 2221 the graph is replaced by an entirely new node. This will cause 2222 the network and all its attached routers to originate new LSAs. 2223 Until the link-state databases again converge, some temporary 2224 loss of connectivity may result. This may result in ICMP 2225 unreachable messages being sent in response to data traffic. 2226 For that reason, the Designated Router should change only 2227 infrequently. Router Priorities should be configured so that 2228 the most dependable router on a network eventually becomes 2229 Designated Router. 2231 7.4. The Backup Designated Router 2233 In order to make the transition to a new Designated Router 2234 smoother, there is a Backup Designated Router for each broadcast 2235 and NBMA network. The Backup Designated Router is also adjacent 2236 to all routers on the network, and becomes Designated Router 2237 when the previous Designated Router fails. If there were no 2238 Backup Designated Router, when a new Designated Router became 2239 necessary, new adjacencies would have to be formed between the 2240 new Designated Router and all other routers attached to the 2241 network. Part of the adjacency forming process is the 2242 synchronizing of link-state databases, which can potentially 2243 take quite a long time. During this time, the network would not 2244 be available for transit data traffic. The Backup Designated 2245 obviates the need to form these adjacencies, since they already 2246 exist. This means the period of disruption in transit traffic 2247 lasts only as long as it takes to flood the new LSAs (which 2248 announce the new Designated Router). 2250 The Backup Designated Router does not generate a network-LSA for 2251 the network. (If it did, the transition to a new Designated 2252 Router would be even faster. However, this is a tradeoff 2253 between database size and speed of convergence when the 2254 Designated Router disappears.) 2256 The Backup Designated Router is also elected by the Hello 2257 Protocol. Each Hello Packet has a field that specifies the 2258 Backup Designated Router for the network. 2260 In some steps of the flooding procedure, the Backup Designated 2261 Router plays a passive role, letting the Designated Router do 2262 more of the work. This cuts down on the amount of local routing 2263 traffic. See Section 13.3 for more information. 2265 7.5. The graph of adjacencies 2267 An adjacency is bound to the network that the two routers have 2268 in common. If two routers have multiple networks in common, 2269 they may have multiple adjacencies between them. 2271 One can picture the collection of adjacencies on a network as 2272 forming an undirected graph. The vertices consist of routers, 2273 with an edge joining two routers if they are adjacent. The 2274 graph of adjacencies describes the flow of routing protocol 2275 packets, and in particular Link State Update Packets, through 2276 the Autonomous System. 2278 Two graphs are possible, depending on whether a Designated 2279 Router is elected for the network. On physical point-to-point 2280 networks, Point-to-MultiPoint networks and virtual links, 2281 neighboring routers become adjacent whenever they can 2282 communicate directly. In contrast, on broadcast and NBMA 2283 networks only the Designated Router and the Backup Designated 2284 Router become adjacent to all other routers attached to the 2285 network. 2287 These graphs are shown in Figure 10. It is assumed that Router 2288 RT7 has become the Designated Router, and Router RT3 the Backup 2289 Designated Router, for the Network N2. The Backup Designated 2290 Router performs a lesser function during the flooding procedure 2291 than the Designated Router (see Section 13.3). This is the 2292 reason for the dashed lines connecting the Backup Designated 2293 Router RT3. 2295 8. Protocol Packet Processing 2297 This section discusses the general processing of OSPF routing 2298 protocol packets. It is very important that the router link-state 2299 databases remain synchronized. For this reason, routing protocol 2300 packets should get preferential treatment over ordinary data 2301 packets, both in sending and receiving. 2303 Routing protocol packets are sent along adjacencies only (with the 2304 exception of Hello packets, which are used to discover the 2305 adjacencies). This means that all routing protocol packets travel a 2307 +---+ +---+ 2308 |RT1|------------|RT2| o---------------o 2309 +---+ N1 +---+ RT1 RT2 2311 RT7 2312 o---------+ 2313 +---+ +---+ +---+ /|\ | 2314 |RT7| |RT3| |RT4| / | \ | 2315 +---+ +---+ +---+ / | \ | 2316 | | | / | \ | 2317 +-----------------------+ RT5o RT6o oRT4 | 2318 | | N2 * * * | 2319 +---+ +---+ * * * | 2320 |RT5| |RT6| * * * | 2321 +---+ +---+ *** | 2322 o---------+ 2323 RT3 2325 Figure 10: The graph of adjacencies 2327 single IP hop, except those sent over virtual links. 2329 All routing protocol packets begin with a standard header. The 2330 sections below provide details on how to fill in and verify this 2331 standard header. Then, for each packet type, the section giving 2332 more details on that particular packet type's processing is listed. 2334 8.1. Sending protocol packets 2336 When a router sends a routing protocol packet, it fills in the 2337 fields of the standard OSPF packet header as follows. For more 2338 details on the header format consult Section A.3.1: 2340 Version # 2341 Set to 2, the version number of the protocol as documented 2342 in this specification. 2344 Packet type 2345 The type of OSPF packet, such as Link state Update or Hello 2346 Packet. 2348 Packet length 2349 The length of the entire OSPF packet in bytes, including the 2350 standard OSPF packet header. 2352 Router ID 2353 The identity of the router itself (who is originating the 2354 packet). 2356 Area ID 2357 The OSPF area that the packet is being sent into. 2359 Checksum 2360 The standard IP 16-bit one's complement checksum of the 2361 entire OSPF packet, excluding the 64-bit authentication 2362 field. This checksum is calculated as part of the 2363 appropriate authentication procedure; for some OSPF 2364 authentication types, the checksum calculation is omitted. 2365 See Section D.4 for details. 2367 AuType and Authentication 2368 Each OSPF packet exchange is authenticated. Authentication 2369 types are assigned by the protocol and are documented in 2370 Appendix D. A different authentication procedure can be 2371 used for each IP network/subnet. Autype indicates the type 2372 of authentication procedure in use. The 64-bit 2373 authentication field is then for use by the chosen 2374 authentication procedure. This procedure should be the last 2375 called when forming the packet to be sent. See Section D.4 2376 for details. 2378 The IP destination address for the packet is selected as 2379 follows. On physical point-to-point networks, the IP 2380 destination is always set to the address AllSPFRouters. On all 2381 other network types (including virtual links), the majority of 2382 OSPF packets are sent as unicasts, i.e., sent directly to the 2383 other end of the adjacency. In this case, the IP destination is 2384 just the Neighbor IP address associated with the other end of 2385 the adjacency (see Section 10). The only packets not sent as 2386 unicasts are on broadcast networks; on these networks Hello 2387 packets are sent to the multicast destination AllSPFRouters, the 2388 Designated Router and its Backup send both Link State Update 2389 Packets and Link State Acknowledgment Packets to the multicast 2390 address AllSPFRouters, while all other routers send both their 2391 Link State Update and Link State Acknowledgment Packets to the 2392 multicast address AllDRouters. 2394 Retransmissions of Link State Update packets are ALWAYS sent as 2395 unicasts. 2397 The IP source address should be set to the IP address of the 2398 sending interface. Interfaces to unnumbered point-to-point 2399 networks have no associated IP address. On these interfaces, 2400 the IP source should be set to any of the other IP addresses 2401 belonging to the router. For this reason, there must be at 2402 least one IP address assigned to the router.[2] Note that, for 2403 most purposes, virtual links act precisely the same as 2404 unnumbered point-to-point networks. However, each virtual link 2405 does have an IP interface address (discovered during the routing 2406 table build process) which is used as the IP source when sending 2407 packets over the virtual link. 2409 For more information on the format of specific OSPF packet 2410 types, consult the sections listed in Table 10. 2412 Type Packet name detailed section (transmit) 2413 _________________________________________________________ 2414 1 Hello Section 9.5 2415 2 Database description Section 10.8 2416 3 Link state request Section 10.9 2417 4 Link state update Section 13.3 2418 5 Link state ack Section 13.5 2420 Table 10: Sections describing OSPF protocol packet transmission. 2422 8.2. Receiving protocol packets 2424 Whenever a protocol packet is received by the router it is 2425 marked with the interface it was received on. For routers that 2426 have virtual links configured, it may not be immediately obvious 2427 which interface to associate the packet with. For example, 2428 consider the Router RT11 depicted in Figure 6. If RT11 receives 2429 an OSPF protocol packet on its interface to Network N8, it may 2430 want to associate the packet with the interface to Area 2, or 2431 with the virtual link to Router RT10 (which is part of the 2432 backbone). In the following, we assume that the packet is 2433 initially associated with the non-virtual link.[3] 2435 In order for the packet to be accepted at the IP level, it must 2436 pass a number of tests, even before the packet is passed to OSPF 2437 for processing: 2439 o The IP checksum must be correct. 2441 o The packet's IP destination address must be the IP address 2442 of the receiving interface, or one of the IP multicast 2443 addresses AllSPFRouters or AllDRouters. 2445 o The IP protocol specified must be OSPF (89). 2447 o Locally originated packets should not be passed on to OSPF. 2448 That is, the source IP address should be examined to make 2449 sure this is not a multicast packet that the router itself 2450 generated. 2452 Next, the OSPF packet header is verified. The fields specified 2453 in the header must match those configured for the receiving 2454 interface. If they do not, the packet should be discarded: 2456 o The version number field must specify protocol version 2. 2458 o The Area ID found in the OSPF header must be verified. If 2459 both of the following cases fail, the packet should be 2460 discarded. The Area ID specified in the header must either: 2462 (1) Match the Area ID of the receiving interface. In this 2463 case, the packet has been sent over a single hop. 2464 Therefore, the packet's IP source address is required to 2465 be on the same network as the receiving interface. This 2466 can be verified by comparing the packet's IP source 2467 address to the interface's IP address, after masking 2468 both addresses with the interface mask. This comparison 2469 should not be performed on point-to-point networks. On 2470 point-to-point networks, the interface addresses of each 2471 end of the link are assigned independently, if they are 2472 assigned at all. 2474 (2) Indicate the backbone. In this case, the packet has 2475 been sent over a virtual link. The receiving router 2476 must be an area border router, and the Router ID 2477 specified in the packet (the source router) must be the 2478 other end of a configured virtual link. The receiving 2479 interface must also attach to the virtual link's 2480 configured Transit area. If all of these checks 2481 succeed, the packet is accepted and is from now on 2482 associated with the virtual link (and the backbone 2483 area). 2485 o Packets whose IP destination is AllDRouters should only be 2486 accepted if the state of the receiving interface is DR or 2487 Backup (see Section 9.1). 2489 o The AuType specified in the packet must match the AuType 2490 specified for the associated area. 2492 o The packet must be authenticated. The authentication 2493 procedure is indicated by the setting of AuType (see 2494 Appendix D). The authentication procedure may use one or 2495 more Authentication keys, which can be configured on a per- 2496 interface basis. The authentication procedure may also 2497 verify the checksum field in the OSPF packet header (which, 2498 when used, is set to the standard IP 16-bit one's complement 2499 checksum of the OSPF packet's contents after excluding the 2500 64-bit authentication field). If the authentication 2501 procedure fails, the packet should be discarded. 2503 If the packet type is Hello, it should then be further processed 2504 by the Hello Protocol (see Section 10.5). All other packet 2505 types are sent/received only on adjacencies. This means that 2506 the packet must have been sent by one of the router's active 2507 neighbors. If the receiving interface connects to a broadcast 2508 network, Point-to-MultiPoint network or NBMA network the sender 2509 is identified by the IP source address found in the packet's IP 2510 header. If the receiving interface connects to a point-to-point 2511 network or a virtual link, the sender is identified by the 2512 Router ID (source router) found in the packet's OSPF header. 2513 The data structure associated with the receiving interface 2514 contains the list of active neighbors. Packets not matching any 2515 active neighbor are discarded. 2517 At this point all received protocol packets are associated with 2518 an active neighbor. For the further input processing of 2519 specific packet types, consult the sections listed in Table 11. 2521 Type Packet name detailed section (receive) 2522 ________________________________________________________ 2523 1 Hello Section 10.5 2524 2 Database description Section 10.6 2525 3 Link state request Section 10.7 2526 4 Link state update Section 13 2527 5 Link state ack Section 13.7 2529 Table 11: Sections describing OSPF protocol packet reception. 2531 9. The Interface Data Structure 2533 An OSPF interface is the connection between a router and a network. 2534 There is a single OSPF interface structure for each attached 2535 network; each interface structure has at most one IP interface 2536 address (see below). The support for multiple addresses on a single 2537 network is a matter for future consideration. 2539 An OSPF interface can be considered to belong to the area that 2540 contains the attached network. All routing protocol packets 2541 originated by the router over this interface are labelled with the 2542 interface's Area ID. One or more router adjacencies may develop 2543 over an interface. A router's LSAs reflect the state of its 2544 interfaces and their associated adjacencies. 2546 The following data items are associated with an interface. Note 2547 that a number of these items are actually configuration for the 2548 attached network; such items must be the same for all routers 2549 connected to the network. 2551 Type 2552 The OSPF interface type is either point-to-point, broadcast, 2553 NBMA, Point-to-MultiPoint or virtual link. 2555 State 2556 The functional level of an interface. State determines whether 2557 or not full adjacencies are allowed to form over the interface. 2558 State is also reflected in the router's LSAs. 2560 IP interface address 2561 The IP address associated with the interface. This appears as 2562 the IP source address in all routing protocol packets originated 2563 over this interface. Interfaces to unnumbered point-to-point 2564 networks do not have an associated IP address. 2566 IP interface mask 2567 Also referred to as the subnet mask, this indicates the portion 2568 of the IP interface address that identifies the attached 2569 network. Masking the IP interface address with the IP interface 2570 mask yields the IP network number of the attached network. On 2571 point-to-point networks and virtual links, the IP interface mask 2572 is not defined. On these networks, the link itself is not 2573 assigned an IP network number, and so the addresses of each side 2574 of the link are assigned independently, if they are assigned at 2575 all. 2577 Area ID 2578 The Area ID of the area to which the attached network belongs. 2579 All routing protocol packets originating from the interface are 2580 labelled with this Area ID. 2582 HelloInterval 2583 The length of time, in seconds, between the Hello packets that 2584 the router sends on the interface. Advertised in Hello packets 2585 sent out this interface. 2587 RouterDeadInterval 2588 The number of seconds before the router's neighbors will declare 2589 it down, when they stop hearing the router's Hello Packets. 2590 Advertised in Hello packets sent out this interface. 2592 InfTransDelay 2593 The estimated number of seconds it takes to transmit a Link 2594 State Update Packet over this interface. LSAs contained in the 2595 Link State Update packet will have their age incremented by this 2596 amount before transmission. This value should take into account 2597 transmission and propagation delays; it must be greater than 2598 zero. 2600 Router Priority 2601 An 8-bit unsigned integer. When two routers attached to a 2602 network both attempt to become Designated Router, the one with 2603 the highest Router Priority takes precedence. A router whose 2604 Router Priority is set to 0 is ineligible to become Designated 2605 Router on the attached network. Advertised in Hello packets 2606 sent out this interface. 2608 Hello Timer 2609 An interval timer that causes the interface to send a Hello 2610 packet. This timer fires every HelloInterval seconds. Note 2611 that on non-broadcast networks a separate Hello packet is sent 2612 to each qualified neighbor. 2614 Wait Timer 2615 A single shot timer that causes the interface to exit the 2616 Waiting state, and as a consequence select a Designated Router 2617 on the network. The length of the timer is RouterDeadInterval 2618 seconds. 2620 List of neighboring routers 2621 The other routers attached to this network. This list is formed 2622 by the Hello Protocol. Adjacencies will be formed to some of 2623 these neighbors. The set of adjacent neighbors can be 2624 determined by an examination of all of the neighbors' states. 2626 Designated Router 2627 The Designated Router selected for the attached network. The 2628 Designated Router is selected on all broadcast and NBMA networks 2629 by the Hello Protocol. Two pieces of identification are kept 2630 for the Designated Router: its Router ID and its IP interface 2631 address on the network. The Designated Router advertises link 2632 state for the network; this network-LSA is labelled with the 2633 Designated Router's IP address. The Designated Router is 2634 initialized to 0.0.0.0, which indicates the lack of a Designated 2635 Router. 2637 Backup Designated Router 2638 The Backup Designated Router is also selected on all broadcast 2639 and NBMA networks by the Hello Protocol. All routers on the 2640 attached network become adjacent to both the Designated Router 2641 and the Backup Designated Router. The Backup Designated Router 2642 becomes Designated Router when the current Designated Router 2643 fails. The Backup Designated Router is initialized to 0.0.0.0, 2644 indicating the lack of a Backup Designated Router. 2646 Interface output cost(s) 2647 The cost of sending a data packet on the interface, expressed in 2648 the link state metric. This is advertised as the link cost for 2649 this interface in the router-LSA. There may be a separate cost 2650 for each IP Type of Service. The cost of an interface must be 2651 greater than zero. 2653 RxmtInterval 2654 The number of seconds between LSA retransmissions, for 2655 adjacencies belonging to this interface. Also used when 2656 retransmitting Database Description and Link State Request 2657 Packets. 2659 AuType 2660 The type of authentication used on the attached network/subnet. 2661 Authentication types are defined in Appendix D. All OSPF packet 2662 exchanges are authenticated. Different authentication schemes 2663 may be used on different networks/subnets. 2665 Authentication key 2666 This configured data allows the authentication procedure to 2667 generate and/or verify OSPF protocol packets. The 2668 Authentication key can be configured on a per-interface basis. 2669 For example, if the AuType indicates simple password, the 2670 Authentication key would be a 64-bit clear password which is 2671 inserted into the OSPF packet header. If instead Autype 2672 indicates Cryptographic authentication, then the Authentication 2673 key is a shared secret which enables the generation/verification 2674 of message digests which are appended to the OSPF protocol 2675 packets. When Cryptographic authentication is used, multiple 2676 simultaneous keys are supported in order to achieve smooth key 2677 transition (see Section D.3). 2679 9.1. Interface states 2681 The various states that router interfaces may attain is 2682 documented in this section. The states are listed in order of 2683 progressing functionality. For example, the inoperative state 2684 is listed first, followed by a list of intermediate states 2685 before the final, fully functional state is achieved. The 2686 specification makes use of this ordering by sometimes making 2687 references such as "those interfaces in state greater than X". 2688 Figure 11 shows the graph of interface state changes. The arcs 2690 +----+ UnloopInd +--------+ 2691 |Down|<--------------|Loopback| 2692 +----+ +--------+ 2693 | 2694 |InterfaceUp 2695 +-------+ | +--------------+ 2696 |Waiting|<-+-------------->|Point-to-point| 2697 +-------+ +--------------+ 2698 | 2699 WaitTimer|BackupSeen 2700 | 2701 | 2702 | NeighborChange 2703 +------+ +-+<---------------- +-------+ 2704 |Backup|<----------|?|----------------->|DROther| 2705 +------+---------->+-+<-----+ +-------+ 2706 Neighbor | | 2707 Change | |Neighbor 2708 | |Change 2709 | +--+ 2710 +---->|DR| 2711 +--+ 2713 Figure 11: Interface State changes 2715 In addition to the state transitions pictured, 2716 Event InterfaceDown always forces Down State, and 2717 Event LoopInd always forces Loopback State 2718 of the graph are labelled with the event causing the state 2719 change. These events are documented in Section 9.2. The 2720 interface state machine is described in more detail in Section 2721 9.3. 2723 Down 2724 This is the initial interface state. In this state, the 2725 lower-level protocols have indicated that the interface is 2726 unusable. No protocol traffic at all will be sent or 2727 received on such a interface. In this state, interface 2728 parameters should be set to their initial values. All 2729 interface timers should be disabled, and there should be no 2730 adjacencies associated with the interface. 2732 Loopback 2733 In this state, the router's interface to the network is 2734 looped back. The interface may be looped back in hardware 2735 or software. The interface will be unavailable for regular 2736 data traffic. However, it may still be desirable to gain 2737 information on the quality of this interface, either through 2738 sending ICMP pings to the interface or through something 2739 like a bit error test. For this reason, IP packets may 2740 still be addressed to an interface in Loopback state. To 2741 facilitate this, such interfaces are advertised in router- 2742 LSAs as single host routes, whose destination is the IP 2743 interface address.[4] 2745 Waiting 2746 In this state, the router is trying to determine the 2747 identity of the (Backup) Designated Router for the network. 2748 To do this, the router monitors the Hello Packets it 2749 receives. The router is not allowed to elect a Backup 2750 Designated Router nor a Designated Router until it 2751 transitions out of Waiting state. This prevents unnecessary 2752 changes of (Backup) Designated Router. 2754 Point-to-point 2755 In this state, the interface is operational, and connects 2756 either to a physical point-to-point network or to a virtual 2757 link. Upon entering this state, the router attempts to form 2758 an adjacency with the neighboring router. Hello Packets are 2759 sent to the neighbor every HelloInterval seconds. 2761 DR Other 2762 The interface is to a broadcast or NBMA network on which 2763 another router has been selected to be the Designated 2764 Router. In this state, the router itself has not been 2765 selected Backup Designated Router either. The router forms 2766 adjacencies to both the Designated Router and the Backup 2767 Designated Router (if they exist). 2769 Backup 2770 In this state, the router itself is the Backup Designated 2771 Router on the attached network. It will be promoted to 2772 Designated Router when the present Designated Router fails. 2773 The router establishes adjacencies to all other routers 2774 attached to the network. The Backup Designated Router 2775 performs slightly different functions during the Flooding 2776 Procedure, as compared to the Designated Router (see Section 2777 13.3). See Section 7.4 for more details on the functions 2778 performed by the Backup Designated Router. 2780 DR In this state, this router itself is the Designated Router 2781 on the attached network. Adjacencies are established to all 2782 other routers attached to the network. The router must also 2783 originate a network-LSA for the network node. The network- 2784 LSA will contain links to all routers (including the 2785 Designated Router itself) attached to the network. See 2786 Section 7.3 for more details on the functions performed by 2787 the Designated Router. 2789 9.2. Events causing interface state changes 2791 State changes can be effected by a number of events. These 2792 events are pictured as the labelled arcs in Figure 11. The 2793 label definitions are listed below. For a detailed explanation 2794 of the effect of these events on OSPF protocol operation, 2795 consult Section 9.3. 2797 InterfaceUp 2798 Lower-level protocols have indicated that the network 2799 interface is operational. This enables the interface to 2800 transition out of Down state. On virtual links, the 2801 interface operational indication is actually a result of the 2802 shortest path calculation (see Section 16.7). 2804 WaitTimer 2805 The Wait Timer has fired, indicating the end of the waiting 2806 period that is required before electing a (Backup) 2807 Designated Router. 2809 BackupSeen 2810 The router has detected the existence or non-existence of a 2811 Backup Designated Router for the network. This is done in 2812 one of two ways. First, an Hello Packet may be received 2813 from a neighbor claiming to be itself the Backup Designated 2814 Router. Alternatively, an Hello Packet may be received from 2815 a neighbor claiming to be itself the Designated Router, and 2816 indicating that there is no Backup Designated Router. In 2817 either case there must be bidirectional communication with 2818 the neighbor, i.e., the router must also appear in the 2819 neighbor's Hello Packet. This event signals an end to the 2820 Waiting state. 2822 NeighborChange 2823 There has been a change in the set of bidirectional 2824 neighbors associated with the interface. The (Backup) 2825 Designated Router needs to be recalculated. The following 2826 neighbor changes lead to the NeighborChange event. For an 2827 explanation of neighbor states, see Section 10.1. 2829 o Bidirectional communication has been established to a 2830 neighbor. In other words, the state of the neighbor has 2831 transitioned to 2-Way or higher. 2833 o There is no longer bidirectional communication with a 2834 neighbor. In other words, the state of the neighbor has 2835 transitioned to Init or lower. 2837 o One of the bidirectional neighbors is newly declaring 2838 itself as either Designated Router or Backup Designated 2839 Router. This is detected through examination of that 2840 neighbor's Hello Packets. 2842 o One of the bidirectional neighbors is no longer 2843 declaring itself as Designated Router, or is no longer 2844 declaring itself as Backup Designated Router. This is 2845 again detected through examination of that neighbor's 2846 Hello Packets. 2848 o The advertised Router Priority for a bidirectional 2849 neighbor has changed. This is again detected through 2850 examination of that neighbor's Hello Packets. 2852 LoopInd 2853 An indication has been received that the interface is now 2854 looped back to itself. This indication can be received 2855 either from network management or from the lower level 2856 protocols. 2858 UnloopInd 2859 An indication has been received that the interface is no 2860 longer looped back. As with the LoopInd event, this 2861 indication can be received either from network management or 2862 from the lower level protocols. 2864 InterfaceDown 2865 Lower-level protocols indicate that this interface is no 2866 longer functional. No matter what the current interface 2867 state is, the new interface state will be Down. 2869 9.3. The Interface state machine 2871 A detailed description of the interface state changes follows. 2872 Each state change is invoked by an event (Section 9.2). This 2873 event may produce different effects, depending on the current 2874 state of the interface. For this reason, the state machine 2875 below is organized by current interface state and received 2876 event. Each entry in the state machine describes the resulting 2877 new interface state and the required set of additional actions. 2879 When an interface's state changes, it may be necessary to 2880 originate a new router-LSA. See Section 12.4 for more details. 2882 Some of the required actions below involve generating events for 2883 the neighbor state machine. For example, when an interface 2884 becomes inoperative, all neighbor connections associated with 2885 the interface must be destroyed. For more information on the 2886 neighbor state machine, see Section 10.3. 2888 State(s): Down 2890 Event: InterfaceUp 2892 New state: Depends upon action routine 2894 Action: Start the interval Hello Timer, enabling the 2895 periodic sending of Hello packets out the interface. 2896 If the attached network is a physical point-to-point 2897 network, Point-to-MultiPoint network or virtual 2898 link, the interface state transitions to Point-to- 2899 Point. Else, if the router is not eligible to 2900 become Designated Router the interface state 2901 transitions to DR Other. 2903 Otherwise, the attached network is a broadcast or 2904 NBMA network and the router is eligible to become 2905 Designated Router. In this case, in an attempt to 2906 discover the attached network's Designated Router 2907 the interface state is set to Waiting and the single 2908 shot Wait Timer is started. Additionally, if the 2909 network is an NBMA network examine the configured 2910 list of neighbors for this interface and generate 2911 the neighbor event Start for each neighbor that is 2912 also eligible to become Designated Router. 2914 State(s): Waiting 2916 Event: BackupSeen 2918 New state: Depends upon action routine. 2920 Action: Calculate the attached network's Backup Designated 2921 Router and Designated Router, as shown in Section 2922 9.4. As a result of this calculation, the new state 2923 of the interface will be either DR Other, Backup or 2924 DR. 2926 State(s): Waiting 2928 Event: WaitTimer 2930 New state: Depends upon action routine. 2932 Action: Calculate the attached network's Backup Designated 2933 Router and Designated Router, as shown in Section 2934 9.4. As a result of this calculation, the new state 2935 of the interface will be either DR Other, Backup or 2936 DR. 2938 State(s): DR Other, Backup or DR 2940 Event: NeighborChange 2942 New state: Depends upon action routine. 2944 Action: Recalculate the attached network's Backup Designated 2945 Router and Designated Router, as shown in Section 2946 9.4. As a result of this calculation, the new state 2947 of the interface will be either DR Other, Backup or 2948 DR. 2950 State(s): Any State 2952 Event: InterfaceDown 2954 New state: Down 2956 Action: All interface variables are reset, and interface 2957 timers disabled. Also, all neighbor connections 2958 associated with the interface are destroyed. This 2959 is done by generating the event KillNbr on all 2960 associated neighbors (see Section 10.2). 2962 State(s): Any State 2964 Event: LoopInd 2966 New state: Loopback 2968 Action: Since this interface is no longer connected to the 2969 attached network the actions associated with the 2970 above InterfaceDown event are executed. 2972 State(s): Loopback 2974 Event: UnloopInd 2976 New state: Down 2978 Action: No actions are necessary. For example, the 2979 interface variables have already been reset upon 2980 entering the Loopback state. Note that reception of 2981 an InterfaceUp event is necessary before the 2982 interface again becomes fully functional. 2984 9.4. Electing the Designated Router 2986 This section describes the algorithm used for calculating a 2987 network's Designated Router and Backup Designated Router. This 2988 algorithm is invoked by the Interface state machine. The 2989 initial time a router runs the election algorithm for a network, 2990 the network's Designated Router and Backup Designated Router are 2991 initialized to 0.0.0.0. This indicates the lack of both a 2992 Designated Router and a Backup Designated Router. 2994 The Designated Router election algorithm proceeds as follows: 2995 Call the router doing the calculation Router X. The list of 2996 neighbors attached to the network and having established 2997 bidirectional communication with Router X is examined. This 2998 list is precisely the collection of Router X's neighbors (on 2999 this network) whose state is greater than or equal to 2-Way (see 3000 Section 10.1). Router X itself is also considered to be on the 3001 list. Discard all routers from the list that are ineligible to 3002 become Designated Router. (Routers having Router Priority of 0 3003 are ineligible to become Designated Router.) The following 3004 steps are then executed, considering only those routers that 3005 remain on the list: 3007 (1) Note the current values for the network's Designated Router 3008 and Backup Designated Router. This is used later for 3009 comparison purposes. 3011 (2) Calculate the new Backup Designated Router for the network 3012 as follows. Only those routers on the list that have not 3013 declared themselves to be Designated Router are eligible to 3014 become Backup Designated Router. If one or more of these 3015 routers have declared themselves Backup Designated Router 3016 (i.e., they are currently listing themselves as Backup 3017 Designated Router, but not as Designated Router, in their 3018 Hello Packets) the one having highest Router Priority is 3019 declared to be Backup Designated Router. In case of a tie, 3020 the one having the highest Router ID is chosen. If no 3021 routers have declared themselves Backup Designated Router, 3022 choose the router having highest Router Priority, (again 3023 excluding those routers who have declared themselves 3024 Designated Router), and again use the Router ID to break 3025 ties. 3027 (3) Calculate the new Designated Router for the network as 3028 follows. If one or more of the routers have declared 3029 themselves Designated Router (i.e., they are currently 3030 listing themselves as Designated Router in their Hello 3031 Packets) the one having highest Router Priority is declared 3032 to be Designated Router. In case of a tie, the one having 3033 the highest Router ID is chosen. If no routers have 3034 declared themselves Designated Router, assign the Designated 3035 Router to be the same as the newly elected Backup Designated 3036 Router. 3038 (4) If Router X is now newly the Designated Router or newly the 3039 Backup Designated Router, or is now no longer the Designated 3040 Router or no longer the Backup Designated Router, repeat 3041 steps 2 and 3, and then proceed to step 5. For example, if 3042 Router X is now the Designated Router, when step 2 is 3043 repeated X will no longer be eligible for Backup Designated 3044 Router election. Among other things, this will ensure that 3045 no router will declare itself both Backup Designated Router 3046 and Designated Router.[5] 3048 (5) As a result of these calculations, the router itself may now 3049 be Designated Router or Backup Designated Router. See 3050 Sections 7.3 and 7.4 for the additional duties this would 3051 entail. The router's interface state should be set 3052 accordingly. If the router itself is now Designated Router, 3053 the new interface state is DR. If the router itself is now 3054 Backup Designated Router, the new interface state is Backup. 3055 Otherwise, the new interface state is DR Other. 3057 (6) If the attached network is an NBMA network, and the router 3058 itself has just become either Designated Router or Backup 3059 Designated Router, it must start sending Hello Packets to 3060 those neighbors that are not eligible to become Designated 3061 Router (see Section 9.5.1). This is done by invoking the 3062 neighbor event Start for each neighbor having a Router 3063 Priority of 0. 3065 (7) If the above calculations have caused the identity of either 3066 the Designated Router or Backup Designated Router to change, 3067 the set of adjacencies associated with this interface will 3068 need to be modified. Some adjacencies may need to be 3069 formed, and others may need to be broken. To accomplish 3070 this, invoke the event AdjOK? on all neighbors whose state 3071 is at least 2-Way. This will cause their eligibility for 3072 adjacency to be reexamined (see Sections 10.3 and 10.4). 3074 The reason behind the election algorithm's complexity is the 3075 desire for an orderly transition from Backup Designated Router 3076 to Designated Router, when the current Designated Router fails. 3077 This orderly transition is ensured through the introduction of 3078 hysteresis: no new Backup Designated Router can be chosen until 3079 the old Backup accepts its new Designated Router 3080 responsibilities. 3082 The above procedure may elect the same router to be both 3083 Designated Router and Backup Designated Router, although that 3084 router will never be the calculating router (Router X) itself. 3086 The elected Designated Router may not be the router having the 3087 highest Router Priority, nor will the Backup Designated Router 3088 necessarily have the second highest Router Priority. If Router 3089 X is not itself eligible to become Designated Router, it is 3090 possible that neither a Backup Designated Router nor a 3091 Designated Router will be selected in the above procedure. Note 3092 also that if Router X is the only attached router that is 3093 eligible to become Designated Router, it will select itself as 3094 Designated Router and there will be no Backup Designated Router 3095 for the network. 3097 9.5. Sending Hello packets 3099 Hello packets are sent out each functioning router interface. 3100 They are used to discover and maintain neighbor 3101 relationships.[6] On broadcast and NBMA networks, Hello Packets 3102 are also used to elect the Designated Router and Backup 3103 Designated Router. 3105 The format of an Hello packet is detailed in Section A.3.2. The 3106 Hello Packet contains the router's Router Priority (used in 3107 choosing the Designated Router), and the interval between Hello 3108 Packets sent out the interface (HelloInterval). The Hello 3109 Packet also indicates how often a neighbor must be heard from to 3110 remain active (RouterDeadInterval). Both HelloInterval and 3111 RouterDeadInterval must be the same for all routers attached to 3112 a common network. The Hello packet also contains the IP address 3113 mask of the attached network (Network Mask). On unnumbered 3114 point-to-point networks and on virtual links this field should 3115 be set to 0.0.0.0. 3117 The Hello packet's Options field describes the router's optional 3118 OSPF capabilities. Two optional capabilities are defined in 3119 this specification (see Sections 4.5 and A.2). The T-bit of the 3120 Options field should be set if the router is capable of 3121 calculating separate routes for each IP TOS. The E-bit should 3122 be set if and only if the attached area is capable of processing 3123 AS-external-LSAs (i.e., it is not a stub area). If the E-bit is 3124 set incorrectly the neighboring routers will refuse to accept 3125 the Hello Packet (see Section 10.5). Unrecognized bits in the 3126 Hello Packet's Options field should be set to zero. 3128 In order to ensure two-way communication between adjacent 3129 routers, the Hello packet contains the list of all routers on 3130 the network from which Hello Packets have been seen recently. 3131 The Hello packet also contains the router's current choice for 3132 Designated Router and Backup Designated Router. A value of 3133 0.0.0.0 in these fields means that one has not yet been 3134 selected. 3136 On broadcast networks and physical point-to-point networks, 3137 Hello packets are sent every HelloInterval seconds to the IP 3138 multicast address AllSPFRouters. On virtual links, Hello 3139 packets are sent as unicasts (addressed directly to the other 3140 end of the virtual link) every HelloInterval seconds. On Point- 3141 to-MultiPoint networks, separate Hello packets are sent to each 3142 attached neighbor every HelloInterval seconds. Sending of Hello 3143 packets on NBMA networks is covered in the next section. 3145 9.5.1. Sending Hello packets on NBMA networks 3147 Static configuration information may be necessary in order 3148 for the Hello Protocol to function on non-broadcast networks 3149 (see Sections C.5 and C.6). On NBMA networks, every 3150 attached router which is eligible to become Designated 3151 Router becomes aware of all of its neighbors on the network 3152 (either through configuration or by some unspecified 3153 mechanism). Each neighbor is labelled with the neighbor's 3154 Designated Router eligibility. 3156 The interface state must be at least Waiting for any Hello 3157 Packets to be sent out the NBMA interface. Hello Packets 3158 are then sent directly (as unicasts) to some subset of a 3159 router's neighbors. Sometimes an Hello Packet is sent 3160 periodically on a timer; at other times it is sent as a 3161 response to a received Hello Packet. A router's hello- 3162 sending behavior varies depending on whether the router 3163 itself is eligible to become Designated Router. 3165 If the router is eligible to become Designated Router, it 3166 must periodically send Hello Packets to all neighbors that 3167 are also eligible. In addition, if the router is itself the 3168 Designated Router or Backup Designated Router, it must also 3169 send periodic Hello Packets to all other neighbors. This 3170 means that any two eligible routers are always exchanging 3171 Hello Packets, which is necessary for the correct operation 3172 of the Designated Router election algorithm. To minimize 3173 the number of Hello Packets sent, the number of eligible 3174 routers on an NBMA network should be kept small. 3176 If the router is not eligible to become Designated Router, 3177 it must periodically send Hello Packets to both the 3178 Designated Router and the Backup Designated Router (if they 3179 exist). It must also send an Hello Packet in reply to an 3180 Hello Packet received from any eligible neighbor (other than 3181 the current Designated Router and Backup Designated Router). 3182 This is needed to establish an initial bidirectional 3183 relationship with any potential Designated Router. 3185 When sending Hello packets periodically to any neighbor, the 3186 interval between Hello Packets is determined by the 3187 neighbor's state. If the neighbor is in state Down, Hello 3188 Packets are sent every PollInterval seconds. Otherwise, 3189 Hello Packets are sent every HelloInterval seconds. 3191 10. The Neighbor Data Structure 3193 An OSPF router converses with its neighboring routers. Each 3194 separate conversation is described by a "neighbor data structure". 3195 Each conversation is bound to a particular OSPF router interface, 3196 and is identified either by the neighboring router's OSPF Router ID 3197 or by its Neighbor IP address (see below). Thus if the OSPF router 3198 and another router have multiple attached networks in common, 3199 multiple conversations ensue, each described by a unique neighbor 3200 data structure. Each separate conversation is loosely referred to 3201 in the text as being a separate "neighbor". 3203 The neighbor data structure contains all information pertinent to 3204 the forming or formed adjacency between the two neighbors. 3205 (However, remember that not all neighbors become adjacent.) An 3206 adjacency can be viewed as a highly developed conversation between 3207 two routers. 3209 State 3210 The functional level of the neighbor conversation. This is 3211 described in more detail in Section 10.1. 3213 Inactivity Timer 3214 A single shot timer whose firing indicates that no Hello Packet 3215 has been seen from this neighbor recently. The length of the 3216 timer is RouterDeadInterval seconds. 3218 Master/Slave 3219 When the two neighbors are exchanging databases, they form a 3220 master/slave relationship. The master sends the first Database 3221 Description Packet, and is the only part that is allowed to 3222 retransmit. The slave can only respond to the master's Database 3223 Description Packets. The master/slave relationship is 3224 negotiated in state ExStart. 3226 DD Sequence Number 3227 A 32-bit number identifying individual Database Description 3228 packets. When the neighbor state ExStart is entered, the DD 3229 sequence number should be set to a value not previously seen by 3230 the neighboring router. One possible scheme is to use the 3231 machine's time of day counter. The DD sequence number is then 3232 incremented by the master with each new Database Description 3233 packet sent. The slave's DD sequence number indicates the last 3234 packet received from the master. Only one packet is allowed 3235 outstanding at a time. 3237 Neighbor ID 3238 The OSPF Router ID of the neighboring router. The Neighbor ID 3239 is learned when Hello packets are received from the neighbor, or 3240 is configured if this is a virtual adjacency (see Section C.4). 3242 Neighbor Priority 3243 The Router Priority of the neighboring router. Contained in the 3244 neighbor's Hello packets, this item is used when selecting the 3245 Designated Router for the attached network. 3247 Neighbor IP address 3248 The IP address of the neighboring router's interface to the 3249 attached network. Used as the Destination IP address when 3250 protocol packets are sent as unicasts along this adjacency. 3251 Also used in router-LSAs as the Link ID for the attached network 3252 if the neighboring router is selected to be Designated Router 3253 (see Section 12.4.1). The Neighbor IP address is learned when 3254 Hello packets are received from the neighbor. For virtual 3255 links, the Neighbor IP address is learned during the routing 3256 table build process (see Section 15). 3258 Neighbor Options 3259 The optional OSPF capabilities supported by the neighbor. 3260 Learned during the Database Exchange process (see Section 10.6). 3261 The neighbor's optional OSPF capabilities are also listed in its 3262 Hello packets. This enables received Hello Packets to be 3263 rejected (i.e., neighbor relationships will not even start to 3264 form) if there is a mismatch in certain crucial OSPF 3265 capabilities (see Section 10.5). The optional OSPF capabilities 3266 are documented in Section 4.5. 3268 Neighbor's Designated Router 3269 The neighbor's idea of the Designated Router. If this is the 3270 neighbor itself, this is important in the local calculation of 3271 the Designated Router. Defined only on broadcast and NBMA 3272 networks. 3274 Neighbor's Backup Designated Router 3275 The neighbor's idea of the Backup Designated Router. If this is 3276 the neighbor itself, this is important in the local calculation 3277 of the Backup Designated Router. Defined only on broadcast and 3278 NBMA networks. 3280 The next set of variables are lists of LSAs. These lists describe 3281 subsets of the area link-state database. This memo defines five 3282 distinct types of LSAs, all of which may be present in an area 3283 link-state database: router-LSAs, network-LSAs, and Type 3 and 4 3284 summary-LSAs (all stored in the area data structure), and AS- 3285 external-LSAs (stored in the global data structure). 3287 Link state retransmission list 3288 The list of LSAs that have been flooded but not acknowledged on 3289 this adjacency. These will be retransmitted at intervals until 3290 they are acknowledged, or until the adjacency is destroyed. 3292 Database summary list 3293 The complete list of LSAs that make up the area link-state 3294 database, at the moment the neighbor goes into Database Exchange 3295 state. This list is sent to the neighbor in Database 3296 Description packets. 3298 Link state request list 3299 The list of LSAs that need to be received from this neighbor in 3300 order to synchronize the two neighbors' link-state databases. 3301 This list is created as Database Description packets are 3302 received, and is then sent to the neighbor in Link State Request 3303 packets. The list is depleted as appropriate Link State Update 3304 packets are received. 3306 10.1. Neighbor states 3308 The state of a neighbor (really, the state of a conversation 3309 being held with a neighboring router) is documented in the 3310 following sections. The states are listed in order of 3311 progressing functionality. For example, the inoperative state 3312 is listed first, followed by a list of intermediate states 3313 before the final, fully functional state is achieved. The 3314 specification makes use of this ordering by sometimes making 3315 references such as "those neighbors/adjacencies in state greater 3316 than X". Figures 12 and 13 show the graph of neighbor state 3317 changes. The arcs of the graphs are labelled with the event 3318 causing the state change. The neighbor events are documented in 3319 Section 10.2. 3321 The graph in Figure 12 shows the state changes effected by the 3322 Hello Protocol. The Hello Protocol is responsible for neighbor 3323 acquisition and maintenance, and for ensuring two way 3324 communication between neighbors. 3326 The graph in Figure 13 shows the forming of an adjacency. Not 3327 every two neighboring routers become adjacent (see Section 3328 10.4). The adjacency starts to form when the neighbor is in 3329 state ExStart. After the two routers discover their 3330 master/slave status, the state transitions to Exchange. At this 3331 point the neighbor starts to be used in the flooding procedure, 3332 and the two neighboring routers begin synchronizing their 3333 databases. When this synchronization is finished, the neighbor 3334 is in state Full and we say that the two routers are fully 3335 adjacent. At this point the adjacency is listed in LSAs. 3337 For a more detailed description of neighbor state changes, 3338 together with the additional actions involved in each change, 3340 +----+ 3341 |Down| 3342 +----+ 3343 | | rt 3344 | +-------+ 3345 Hello | +---->|Attempt| 3346 Received | +-------+ 3347 | | 3348 +----+<-+ |HelloReceived 3349 |Init|<---------------+ 3350 +----+<--------+ 3351 | | 3352 |2-Way |1-Way 3353 |Received |Received 3354 | | 3355 +-------+ | +-----+ 3356 |ExStart|<--------+------->|2-Way| 3357 +-------+ +-----+ 3359 Figure 12: Neighbor state changes (Hello Protocol) 3361 In addition to the state transitions pictured, 3362 Event KillNbr always forces Down State, 3363 Event InactivityTimer always forces Down State, 3364 Event LLDown always forces Down State 3365 +-------+ 3366 |ExStart| 3367 +-------+ 3368 | 3369 NegotiationDone| 3370 +->+--------+ 3371 |Exchange| 3372 +--+--------+ 3373 | 3374 Exchange| 3375 Done | 3376 +----+ | +-------+ 3377 |Full|<---------+----->|Loading| 3378 +----+<-+ +-------+ 3379 | LoadingDone | 3380 +------------------+ 3382 Figure 13: Neighbor state changes (Database Exchange) 3384 In addition to the state transitions pictured, 3385 Event SeqNumberMismatch forces ExStart state, 3386 Event BadLSReq forces ExStart state, 3387 Event 1-Way forces Init state, 3388 Event KillNbr always forces Down State, 3389 Event InactivityTimer always forces Down State, 3390 Event LLDown always forces Down State, 3391 Event AdjOK? leads to adjacency forming/breaking 3393 see Section 10.3. 3395 Down 3396 This is the initial state of a neighbor conversation. It 3397 indicates that there has been no recent information received 3398 from the neighbor. On NBMA networks, Hello packets may 3399 still be sent to "Down" neighbors, although at a reduced 3400 frequency (see Section 9.5.1). 3402 Attempt 3403 This state is only valid for neighbors attached to NBMA 3404 networks. It indicates that no recent information has been 3405 received from the neighbor, but that a more concerted effort 3406 should be made to contact the neighbor. This is done by 3407 sending the neighbor Hello packets at intervals of 3408 HelloInterval (see Section 9.5.1). 3410 Init 3411 In this state, an Hello packet has recently been seen from 3412 the neighbor. However, bidirectional communication has not 3413 yet been established with the neighbor (i.e., the router 3414 itself did not appear in the neighbor's Hello packet). All 3415 neighbors in this state (or higher) are listed in the Hello 3416 packets sent from the associated interface. 3418 2-Way 3419 In this state, communication between the two routers is 3420 bidirectional. This has been assured by the operation of 3421 the Hello Protocol. This is the most advanced state short 3422 of beginning adjacency establishment. The (Backup) 3423 Designated Router is selected from the set of neighbors in 3424 state 2-Way or greater. 3426 ExStart 3427 This is the first step in creating an adjacency between the 3428 two neighboring routers. The goal of this step is to decide 3429 which router is the master, and to decide upon the initial 3430 DD sequence number. Neighbor conversations in this state or 3431 greater are called adjacencies. 3433 Exchange 3434 In this state the router is describing its entire link state 3435 database by sending Database Description packets to the 3436 neighbor. Each Database Description Packet has a DD 3437 sequence number, and is explicitly acknowledged. Only one 3438 Database Description Packet is allowed outstanding at any 3439 one time. In this state, Link State Request Packets may 3440 also be sent asking for the neighbor's more recent LSAs. 3441 All adjacencies in Exchange state or greater are used by the 3442 flooding procedure. In fact, these adjacencies are fully 3443 capable of transmitting and receiving all types of OSPF 3444 routing protocol packets. 3446 Loading 3447 In this state, Link State Request packets are sent to the 3448 neighbor asking for the more recent LSAs that have been 3449 discovered (but not yet received) in the Exchange state. 3451 Full 3452 In this state, the neighboring routers are fully adjacent. 3453 These adjacencies will now appear in router-LSAs and 3454 network-LSAs. 3456 10.2. Events causing neighbor state changes 3458 State changes can be effected by a number of events. These 3459 events are shown in the labels of the arcs in Figures 12 and 13. 3460 The label definitions are as follows: 3462 HelloReceived 3463 An Hello packet has been received from the neighbor. 3465 Start 3466 This is an indication that Hello Packets should now be sent 3467 to the neighbor at intervals of HelloInterval seconds. This 3468 event is generated only for neighbors associated with NBMA 3469 networks. 3471 2-WayReceived 3472 Bidirectional communication has been realized between the 3473 two neighboring routers. This is indicated by the router 3474 seeing itself in the neighbor's Hello packet. 3476 NegotiationDone 3477 The Master/Slave relationship has been negotiated, and DD 3478 sequence numbers have been exchanged. This signals the 3479 start of the sending/receiving of Database Description 3480 packets. For more information on the generation of this 3481 event, consult Section 10.8. 3483 ExchangeDone 3484 Both routers have successfully transmitted a full sequence 3485 of Database Description packets. Each router now knows what 3486 parts of its link state database are out of date. For more 3487 information on the generation of this event, consult Section 3488 10.8. 3490 BadLSReq 3491 A Link State Request has been received for an LSA not 3492 contained in the database. This indicates an error in the 3493 Database Exchange process. 3495 Loading Done 3496 Link State Updates have been received for all out-of-date 3497 portions of the database. This is indicated by the Link 3498 state request list becoming empty after the Database 3499 Exchange process has completed. 3501 AdjOK? 3502 A decision must be made as to whether an adjacency should be 3503 established/maintained with the neighbor. This event will 3504 start some adjacencies forming, and destroy others. 3506 The following events cause well developed neighbors to revert to 3507 lesser states. Unlike the above events, these events may occur 3508 when the neighbor conversation is in any of a number of states. 3510 SeqNumberMismatch 3511 A Database Description packet has been received that either 3512 a) has an unexpected DD sequence number, b) unexpectedly has 3513 the Init bit set or c) has an Options field differing from 3514 the last Options field received in a Database Description 3515 packet. Any of these conditions indicate that some error 3516 has occurred during adjacency establishment. 3518 1-Way 3519 An Hello packet has been received from the neighbor, in 3520 which the router is not mentioned. This indicates that 3521 communication with the neighbor is not bidirectional. 3523 KillNbr 3524 This is an indication that all communication with the 3525 neighbor is now impossible, forcing the neighbor to 3526 revert to Down state. 3528 InactivityTimer 3529 The inactivity Timer has fired. This means that no Hello 3530 packets have been seen recently from the neighbor. The 3531 neighbor reverts to Down state. 3533 LLDown 3534 This is an indication from the lower level protocols that 3535 the neighbor is now unreachable. For example, on an X.25 3536 network this could be indicated by an X.25 clear indication 3537 with appropriate cause and diagnostic fields. This event 3538 forces the neighbor into Down state. 3540 10.3. The Neighbor state machine 3542 A detailed description of the neighbor state changes follows. 3543 Each state change is invoked by an event (Section 10.2). This 3544 event may produce different effects, depending on the current 3545 state of the neighbor. For this reason, the state machine below 3546 is organized by current neighbor state and received event. Each 3547 entry in the state machine describes the resulting new neighbor 3548 state and the required set of additional actions. 3550 When a neighbor's state changes, it may be necessary to rerun 3551 the Designated Router election algorithm. This is determined by 3552 whether the interface NeighborChange event is generated (see 3553 Section 9.2). Also, if the Interface is in DR state (the router 3554 is itself Designated Router), changes in neighbor state may 3555 cause a new network-LSA to be originated (see Section 12.4). 3557 When the neighbor state machine needs to invoke the interface 3558 state machine, it should be done as a scheduled task (see 3559 Section 4.4). This simplifies things, by ensuring that neither 3560 state machine will be executed recursively. 3562 State(s): Down 3564 Event: Start 3566 New state: Attempt 3568 Action: Send an Hello Packet to the neighbor (this neighbor 3569 is always associated with an NBMA network) and start 3570 the Inactivity Timer for the neighbor. The timer's 3571 later firing would indicate that communication with 3572 the neighbor was not attained. 3574 State(s): Attempt 3576 Event: HelloReceived 3578 New state: Init 3580 Action: Restart the Inactivity Timer for the neighbor, since 3581 the neighbor has now been heard from. 3583 State(s): Down 3585 Event: HelloReceived 3587 New state: Init 3589 Action: Start the Inactivity Timer for the neighbor. The 3590 timer's later firing would indicate that the 3591 neighbor is dead. 3593 State(s): Init or greater 3595 Event: HelloReceived 3597 New state: No state change. 3599 Action: Restart the Inactivity Timer for the neighbor, since 3600 the neighbor has again been heard from. 3602 State(s): Init 3604 Event: 2-WayReceived 3606 New state: Depends upon action routine. 3608 Action: Determine whether an adjacency should be established 3609 with the neighbor (see Section 10.4). If not, the 3610 new neighbor state is 2-Way. 3612 Otherwise (an adjacency should be established) the 3613 neighbor state transitions to ExStart. Upon 3614 entering this state, the router increments the DD 3615 sequence number for this neighbor. If this is the 3616 first time that an adjacency has been attempted, the 3617 DD sequence number should be assigned some unique 3618 value (like the time of day clock). It then 3619 declares itself master (sets the master/slave bit to 3620 master), and starts sending Database Description 3621 Packets, with the initialize (I), more (M) and 3622 master (MS) bits set. This Database Description 3623 Packet should be otherwise empty. This Database 3624 Description Packet should be retransmitted at 3625 intervals of RxmtInterval until the next state is 3626 entered (see Section 10.8). 3628 State(s): ExStart 3630 Event: NegotiationDone 3632 New state: Exchange 3634 Action: The router must list the contents of its entire area 3635 link state database in the neighbor Database summary 3636 list. The area link state database consists of the 3637 router-LSAs, network-LSAs and summary-LSAs contained 3638 in the area structure, along with the AS-external- 3639 LSAs contained in the global structure. AS- 3640 external-LSAs are omitted from a virtual neighbor's 3641 Database summary list. AS-external-LSAs are omitted 3642 from the Database summary list if the area has been 3643 configured as a stub (see Section 3.6). LSAs whose 3644 age is equal to MaxAge are instead added to the 3645 neighbor's Link state retransmission list. A 3646 summary of the Database summary list will be sent to 3647 the neighbor in Database Description packets. Each 3648 Database Description Packet has a DD sequence 3649 number, and is explicitly acknowledged. Only one 3650 Database Description Packet is allowed outstanding 3651 at any one time. For more detail on the sending and 3652 receiving of Database Description packets, see 3653 Sections 10.8 and 10.6. 3655 State(s): Exchange 3657 Event: ExchangeDone 3659 New state: Depends upon action routine. 3661 Action: If the neighbor Link state request list is empty, 3662 the new neighbor state is Full. No other action is 3663 required. This is an adjacency's final state. 3665 Otherwise, the new neighbor state is Loading. Start 3666 (or continue) sending Link State Request packets to 3667 the neighbor (see Section 10.9). These are requests 3668 for the neighbor's more recent LSAs (which were 3669 discovered but not yet received in the Exchange 3670 state). These LSAs are listed in the Link state 3671 request list associated with the neighbor. 3673 State(s): Loading 3675 Event: Loading Done 3677 New state: Full 3679 Action: No action required. This is an adjacency's final 3680 state. 3682 State(s): 2-Way 3683 Event: AdjOK? 3685 New state: Depends upon action routine. 3687 Action: Determine whether an adjacency should be formed with 3688 the neighboring router (see Section 10.4). If not, 3689 the neighbor state remains at 2-Way. Otherwise, 3690 transition the neighbor state to ExStart and perform 3691 the actions associated with the above state machine 3692 entry for state Init and event 2-WayReceived. 3694 State(s): ExStart or greater 3696 Event: AdjOK? 3698 New state: Depends upon action routine. 3700 Action: Determine whether the neighboring router should 3701 still be adjacent. If yes, there is no state change 3702 and no further action is necessary. 3704 Otherwise, the (possibly partially formed) adjacency 3705 must be destroyed. The neighbor state transitions 3706 to 2-Way. The Link state retransmission list, 3707 Database summary list and Link state request list 3708 are cleared of LSAs. 3710 State(s): Exchange or greater 3712 Event: SeqNumberMismatch 3714 New state: ExStart 3716 Action: The (possibly partially formed) adjacency is torn 3717 down, and then an attempt is made at 3718 reestablishment. The neighbor state first 3719 transitions to ExStart. The Link state 3720 retransmission list, Database summary list and Link 3721 state request list are cleared of LSAs. Then the 3722 router increments the DD sequence number for this 3723 neighbor, declares itself master (sets the 3724 master/slave bit to master), and starts sending 3725 Database Description Packets, with the initialize 3726 (I), more (M) and master (MS) bits set. This 3727 Database Description Packet should be otherwise 3728 empty (see Section 10.8). 3730 State(s): Exchange or greater 3732 Event: BadLSReq 3734 New state: ExStart 3736 Action: The action for event BadLSReq is exactly the same as 3737 for the neighbor event SeqNumberMismatch. The 3738 (possibly partially formed) adjacency is torn down, 3739 and then an attempt is made at reestablishment. For 3740 more information, see the neighbor state machine 3741 entry that is invoked when event SeqNumberMismatch 3742 is generated in state Exchange or greater. 3744 State(s): Any state 3746 Event: KillNbr 3748 New state: Down 3750 Action: The Link state retransmission list, Database summary 3751 list and Link state request list are cleared of 3752 LSAs. Also, the Inactivity Timer is disabled. 3754 State(s): Any state 3756 Event: LLDown 3758 New state: Down 3760 Action: The Link state retransmission list, Database summary 3761 list and Link state request list are cleared of 3762 LSAs. Also, the Inactivity Timer is disabled. 3764 State(s): Any state 3766 Event: InactivityTimer 3768 New state: Down 3770 Action: The Link state retransmission list, Database summary 3771 list and Link state request list are cleared of 3772 LSAs. 3774 State(s): 2-Way or greater 3776 Event: 1-WayReceived 3778 New state: Init 3780 Action: The Link state retransmission list, Database summary 3781 list and Link state request list are cleared of 3782 LSAs. 3784 State(s): 2-Way or greater 3786 Event: 2-WayReceived 3788 New state: No state change. 3790 Action: No action required. 3792 State(s): Init 3794 Event: 1-WayReceived 3796 New state: No state change. 3798 Action: No action required. 3800 10.4. Whether to become adjacent 3802 Adjacencies are established with some subset of the router's 3803 neighbors. Routers connected by point-to-point networks, 3804 Point-to-MultiPoint networks and virtual links always become 3805 adjacent. On broadcast and NBMA networks, all routers become 3806 adjacent to both the Designated Router and the Backup Designated 3807 Router. 3809 The adjacency-forming decision occurs in two places in the 3810 neighbor state machine. First, when bidirectional communication 3811 is initially established with the neighbor, and secondly, when 3812 the identity of the attached network's (Backup) Designated 3813 Router changes. If the decision is made to not attempt an 3814 adjacency, the state of the neighbor communication stops at 2- 3815 Way. 3817 An adjacency should be established with a bidirectional neighbor 3818 when at least one of the following conditions holds: 3820 o The underlying network type is point-to-point 3822 o The underlying network type is Point-to-MultiPoint 3824 o The underlying network type is virtual link 3826 o The router itself is the Designated Router 3828 o The router itself is the Backup Designated Router 3830 o The neighboring router is the Designated Router 3832 o The neighboring router is the Backup Designated Router 3834 10.5. Receiving Hello Packets 3836 This section explains the detailed processing of a received 3837 Hello Packet. (See Section A.3.2 for the format of Hello 3838 packets.) The generic input processing of OSPF packets will 3839 have checked the validity of the IP header and the OSPF packet 3840 header. Next, the values of the Network Mask, HelloInterval, 3841 and RouterDeadInterval fields in the received Hello packet must 3842 be checked against the values configured for the receiving 3843 interface. Any mismatch causes processing to stop and the 3844 packet to be dropped. In other words, the above fields are 3845 really describing the attached network's configuration. However, 3846 there is one exception to the above rule: on point-to-point 3847 networks and on virtual links, the Network Mask in the received 3848 Hello Packet should be ignored. 3850 The receiving interface attaches to a single OSPF area (this 3851 could be the backbone). The setting of the E-bit found in the 3852 Hello Packet's Options field must match this area's 3853 ExternalRoutingCapability. If AS-external-LSAs are not flooded 3854 into/throughout the area (i.e, the area is a "stub") the E-bit 3855 must be clear in received Hello Packets, otherwise the E-bit 3856 must be set. A mismatch causes processing to stop and the 3857 packet to be dropped. The setting of the rest of the bits in 3858 the Hello Packet's Options field should be ignored. 3860 At this point, an attempt is made to match the source of the 3861 Hello Packet to one of the receiving interface's neighbors. If 3862 the receiving interface connects to a broadcast, Point-to- 3863 MultiPoint or NBMA network the source is identified by the IP 3864 source address found in the Hello's IP header. If the receiving 3865 interface connects to a point-to-point link or a virtual link, 3866 the source is identified by the Router ID found in the Hello's 3867 OSPF packet header. The interface's current list of neighbors 3868 is contained in the interface's data structure. If a matching 3869 neighbor structure cannot be found, (i.e., this is the first 3870 time the neighbor has been detected), one is created. The 3871 initial state of a newly created neighbor is set to Down. 3873 When receiving an Hello Packet from a neighbor on a broadcast, 3874 Point-to-MultiPoint or NBMA network, set the neighbor 3875 structure's Neighbor ID equal to the Router ID found in the 3876 packet's OSPF header. When receiving an Hello on a point-to- 3877 point network (but not on a virtual link) set the neighbor 3878 structure's Neighbor IP address to the packet's IP source 3879 address. 3881 Now the rest of the Hello Packet is examined, generating events 3882 to be given to the neighbor and interface state machines. These 3883 state machines are specified either to be executed or scheduled 3884 (see Section 4.4). For example, by specifying below that the 3885 neighbor state machine be executed in line, several neighbor 3886 state transitions may be effected by a single received Hello: 3888 o Each Hello Packet causes the neighbor state machine to be 3889 executed with the event HelloReceived. 3891 o Then the list of neighbors contained in the Hello Packet is 3892 examined. If the router itself appears in this list, the 3893 neighbor state machine should be executed with the event 2- 3894 WayReceived. Otherwise, the neighbor state machine should 3895 be executed with the event 1-WayReceived, and the processing 3896 of the packet stops. 3898 o Next, the Hello Packet's Router Priority field is examined. 3899 If this field is different than the one previously received 3900 from the neighbor, the receiving interface's state machine 3901 is scheduled with the event NeighborChange. In any case, 3902 the Router Priority field in the neighbor data structure 3903 should be updated accordingly. 3905 o Next the Designated Router field in the Hello Packet is 3906 examined. If the neighbor is both declaring itself to be 3907 Designated Router (Designated Router field = Neighbor IP 3908 address) and the Backup Designated Router field in the 3909 packet is equal to 0.0.0.0 and the receiving interface is in 3910 state Waiting, the receiving interface's state machine is 3911 scheduled with the event BackupSeen. Otherwise, if the 3912 neighbor is declaring itself to be Designated Router and it 3913 had not previously, or the neighbor is not declaring itself 3914 Designated Router where it had previously, the receiving 3915 interface's state machine is scheduled with the event 3916 NeighborChange. In any case, the Neighbors' Designated 3917 Router item in the neighbor structure is updated 3918 accordingly. 3920 o Finally, the Backup Designated Router field in the Hello 3921 Packet is examined. If the neighbor is declaring itself to 3922 be Backup Designated Router (Backup Designated Router field 3923 = Neighbor IP address) and the receiving interface is in 3924 state Waiting, the receiving interface's state machine is 3925 scheduled with the event BackupSeen. Otherwise, if the 3926 neighbor is declaring itself to be Backup Designated Router 3927 and it had not previously, or the neighbor is not declaring 3928 itself Backup Designated Router where it had previously, the 3929 receiving interface's state machine is scheduled with the 3930 event NeighborChange. In any case, the Neighbor's Backup 3931 Designated Router item in the neighbor structure is updated 3932 accordingly. 3934 On NBMA networks, receipt of an Hello Packet may also cause an 3935 Hello Packet to be sent back to the neighbor in response. See 3936 Section 9.5.1 for more details. 3938 10.6. Receiving Database Description Packets 3940 This section explains the detailed processing of a received 3941 Database Description Packet. The incoming Database Description 3942 Packet has already been associated with a neighbor and receiving 3943 interface by the generic input packet processing (Section 8.2). 3944 The further processing of the Database Description Packet 3945 depends on the neighbor state. If the neighbor's state is Down 3946 or Attempt the packet should be ignored. Otherwise, if the 3947 state is: 3949 Init 3950 The neighbor state machine should be executed with the event 3951 2-WayReceived. This causes an immediate state change to 3952 either state 2-Way or state ExStart. If the new state is 3953 ExStart, the processing of the current packet should then 3954 continue in this new state by falling through to case 3955 ExStart below. 3957 2-Way 3958 The packet should be ignored. Database Description Packets 3959 are used only for the purpose of bringing up adjacencies.[7] 3960 ExStart 3961 If the received packet matches one of the following cases, 3962 then the neighbor state machine should be executed with the 3963 event NegotiationDone (causing the state to transition to 3964 Exchange), the packet's Options field should be recorded in 3965 the neighbor structure's Neighbor Options field and the 3966 packet should be accepted as next in sequence and processed 3967 further (see below). Otherwise, the packet should be 3968 ignored. 3970 o The initialize(I), more (M) and master(MS) bits are set, 3971 the contents of the packet are empty, and the neighbor's 3972 Router ID is larger than the router's own. In this case 3973 the router is now Slave. Set the master/slave bit to 3974 slave, and set the DD sequence number to that specified 3975 by the master. 3977 o The initialize(I) and master(MS) bits are off, the 3978 packet's DD sequence number equals the router's own DD 3979 sequence number (indicating acknowledgment) and the 3980 neighbor's Router ID is smaller than the router's own. 3981 In this case the router is Master. 3983 Exchange 3984 If the state of the MS-bit is inconsistent with the 3985 master/slave state of the connection, generate the neighbor 3986 event SeqNumberMismatch and stop processing the packet. 3987 Otherwise: 3989 o If the initialize(I) bit is set, generate the neighbor 3990 event SeqNumberMismatch and stop processing the packet. 3992 o If the packet's Options field indicates a different set 3993 of optional OSPF capabilities than were previously 3994 received from the neighbor (recorded in the Neighbor 3995 Options field of the neighbor structure), generate the 3996 neighbor event SeqNumberMismatch and stop processing the 3997 packet. 3999 o If the router is master, and the packet's DD sequence 4000 number equals the router's own DD sequence number (this 4001 packet is the next in sequence) the packet should be 4002 accepted and its contents processed (below). 4004 o If the router is master, and the packet's DD sequence 4005 number is one less than the router's DD sequence number, 4006 the packet is a duplicate. Duplicates should be 4007 discarded by the master. 4009 o If the router is slave, and the packet's DD sequence 4010 number is one more than the router's own DD sequence 4011 number (this packet is the next in sequence) the packet 4012 should be accepted and its contents processed (below). 4014 o If the router is slave, and the packet's DD sequence 4015 number is equal to the router's DD sequence number, the 4016 packet is a duplicate. The slave must respond to 4017 duplicates by repeating the last Database Description 4018 packet that it had sent. 4020 o Else, generate the neighbor event SeqNumberMismatch and 4021 stop processing the packet. 4023 Loading or Full 4024 In this state, the router has sent and received an entire 4025 sequence of Database Description Packets. The only packets 4026 received should be duplicates (see above). In particular, 4027 the packet's Options field should match the set of optional 4028 OSPF capabilities previously indicated by the neighbor 4029 (stored in the neighbor structure's Neighbor Options field). 4030 Any other packets received, including the reception of a 4031 packet with the Initialize(I) bit set, should generate the 4032 neighbor event SeqNumberMismatch.[8] Duplicates should be 4033 discarded by the master. The slave must respond to 4034 duplicates by repeating the last Database Description packet 4035 that it had sent. 4037 When the router accepts a received Database Description Packet 4038 as the next in sequence the packet contents are processed as 4039 follows. For each LSA listed, the LSA's LS type is checked for 4040 validity. If the LS type is unknown (e.g., not one of the LS 4041 types 1-5 defined by this specification), or if this is an AS- 4042 external-LSA (LS type = 5) and the neighbor is associated with a 4043 stub area, generate the neighbor event SeqNumberMismatch and 4044 stop processing the packet. Otherwise, the router looks up the 4045 LSA in its database to see whether it also has an instance of 4046 the LSA. If it does not, or if the database copy is less recent 4047 (see Section 13.1), the LSA is put on the Link state request 4048 list so that it can be requested (immediately or at some later 4049 time) in Link State Request Packets. 4051 When the router accepts a received Database Description Packet 4052 as the next in sequence, it also performs the following actions, 4053 depending on whether it is master or slave: 4055 Master 4056 Increments the DD sequence number. If the router has 4057 already sent its entire sequence of Database Description 4058 Packets, and the just accepted packet has the more bit (M) 4059 set to 0, the neighbor event ExchangeDone is generated. 4060 Otherwise, it should send a new Database Description to the 4061 slave. 4063 Slave 4064 Sets the DD sequence number to the DD sequence number 4065 appearing in the received packet. The slave must send a 4066 Database Description Packet in reply. If the received 4067 packet has the more bit (M) set to 0, and the packet to be 4068 sent by the slave will also have the M-bit set to 0, the 4069 neighbor event ExchangeDone is generated. Note that the 4070 slave always generates this event before the master. 4072 10.7. Receiving Link State Request Packets 4074 This section explains the detailed processing of received Link 4075 State Request packets. Received Link State Request Packets 4076 specify a list of LSAs that the neighbor wishes to receive. 4077 Link State Request Packets should be accepted when the neighbor 4078 is in states Exchange, Loading, or Full. In all other states 4079 Link State Request Packets should be ignored. 4081 Each LSA specified in the Link State Request packet should be 4082 located in the router's database, and copied into Link State 4083 Update packets for transmission to the neighbor. These LSAs 4084 should NOT be placed on the Link state retransmission list for 4085 the neighbor. If an LSA cannot be found in the database, 4086 something has gone wrong with the Database Exchange process, and 4087 neighbor event BadLSReq should be generated. 4089 10.8. Sending Database Description Packets 4091 This section describes how Database Description Packets are sent 4092 to a neighbor. The router's optional OSPF capabilities (see 4093 Section 4.5) are transmitted to the neighbor in the Options 4094 field of the Database Description packet. The router should 4095 maintain the same set of optional capabilities throughout the 4096 Database Exchange and flooding procedures. If for some reason 4097 the router's optional capabilities change, the Database Exchange 4098 procedure should be restarted by reverting to neighbor state 4099 ExStart. There are currently two optional capabilities defined. 4100 The T-bit should be set if and only if the router is capable of 4101 calculating separate routes for each IP TOS. The E-bit should 4102 be set if and only if the attached network belongs to a non-stub 4103 area. The rest of the Options field should be set to zero. 4105 The sending of Database Description packets depends on the 4106 neighbor's state. In state ExStart the router sends empty 4107 Database Description packets, with the initialize (I), more (M) 4108 and master (MS) bits set. These packets are retransmitted every 4109 RxmtInterval seconds. 4111 In state Exchange the Database Description Packets actually 4112 contain summaries of the link state information contained in the 4113 router's database. Each LSA in the area's link-state database 4114 (at the time the neighbor transitions into Exchange state) is 4115 listed in the neighbor Database summary list. When a new 4116 Database Description Packet is to be sent, the packet's DD 4117 sequence number is incremented, and the (new) top of the 4118 Database summary list is described by the packet. Items are 4119 removed from the Database summary list when the previous packet 4120 is acknowledged. 4122 In state Exchange, the determination of when to send a Database 4123 Description packet depends on whether the router is master or 4124 slave: 4126 Master 4127 Database Description packets are sent when either a) the 4128 slave acknowledges the previous Database Description packet 4129 by echoing the DD sequence number or b) RxmtInterval seconds 4130 elapse without an acknowledgment, in which case the previous 4131 Database Description packet is retransmitted. 4133 Slave 4134 Database Description packets are sent only in response to 4135 Database Description packets received from the master. If 4136 the Database Description packet received from the master is 4137 new, a new Database Description packet is sent, otherwise 4138 the previous Database Description packet is resent. 4140 In states Loading and Full the slave must resend its last 4141 Database Description packet in response to duplicate Database 4142 Description packets received from the master. For this reason 4143 the slave must wait RouterDeadInterval seconds before freeing 4144 the last Database Description packet. Reception of a Database 4145 Description packet from the master after this interval will 4146 generate a SeqNumberMismatch neighbor event. 4148 10.9. Sending Link State Request Packets 4150 In neighbor states Exchange or Loading, the Link state request 4151 list contains a list of those LSAs that need to be obtained from 4152 the neighbor. To request these LSAs, a router sends the 4153 neighbor the beginning of the Link state request list, packaged 4154 in a Link State Request packet. 4156 When the neighbor responds to these requests with the proper 4157 Link State Update packet(s), the Link state request list is 4158 truncated and a new Link State Request packet is sent. This 4159 process continues until the Link state request list becomes 4160 empty. Unsatisfied Link State Request packets are retransmitted 4161 at intervals of RxmtInterval. There should be at most one Link 4162 State Request packet outstanding at any one time. 4164 When the Link state request list becomes empty, and the neighbor 4165 state is Loading (i.e., a complete sequence of Database 4166 Description packets has been sent to and received from the 4167 neighbor), the Loading Done neighbor event is generated. 4169 10.10. An Example 4171 Figure 14 shows an example of an adjacency forming. Routers RT1 4172 and RT2 are both connected to a broadcast network. It is 4173 assumed that RT2 is the Designated Router for the network, and 4174 that RT2 has a higher Router ID than Router RT1. 4176 The neighbor state changes realized by each router are listed on 4177 the sides of the figure. 4179 At the beginning of Figure 14, Router RT1's interface to the 4180 network becomes operational. It begins sending Hello Packets, 4181 although it doesn't know the identity of the Designated Router 4182 or of any other neighboring routers. Router RT2 hears this 4183 hello (moving the neighbor to Init state), and in its next Hello 4184 Packet indicates that it is itself the Designated Router and 4185 that it has heard Hello Packets from RT1. This in turn causes 4186 RT1 to go to state ExStart, as it starts to bring up the 4187 adjacency. 4189 RT1 begins by asserting itself as the master. When it sees that 4190 RT2 is indeed the master (because of RT2's higher Router ID), 4191 RT1 transitions to slave state and adopts its neighbor's DD 4192 sequence number. Database Description packets are then 4193 exchanged, with polls coming from the master (RT2) and responses 4194 from the slave (RT1). This sequence of Database Description 4195 +---+ +---+ 4196 |RT1| |RT2| 4197 +---+ +---+ 4199 Down Down 4200 Hello(DR=0,seen=0) 4201 ------------------------------> 4202 Hello (DR=RT2,seen=RT1,...) Init 4203 <------------------------------ 4204 ExStart D-D (Seq=x,I,M,Master) 4205 ------------------------------> 4206 D-D (Seq=y,I,M,Master) ExStart 4207 <------------------------------ 4208 Exchange D-D (Seq=y,M,Slave) 4209 ------------------------------> 4210 D-D (Seq=y+1,M,Master) Exchange 4211 <------------------------------ 4212 D-D (Seq=y+1,M,Slave) 4213 ------------------------------> 4214 ... 4215 ... 4216 ... 4217 D-D (Seq=y+n, Master) 4218 <------------------------------ 4219 D-D (Seq=y+n, Slave) 4220 Loading ------------------------------> 4221 LS Request Full 4222 ------------------------------> 4223 LS Update 4224 <------------------------------ 4225 LS Request 4226 ------------------------------> 4227 LS Update 4228 <------------------------------ 4229 Full 4231 Figure 14: An adjacency bring-up example 4232 Packets ends when both the poll and associated response has the 4233 M-bit off. 4235 In this example, it is assumed that RT2 has a completely up to 4236 date database. In that case, RT2 goes immediately into Full 4237 state. RT1 will go into Full state after updating the necessary 4238 parts of its database. This is done by sending Link State 4239 Request Packets, and receiving Link State Update Packets in 4240 response. Note that, while RT1 has waited until a complete set 4241 of Database Description Packets has been received (from RT2) 4242 before sending any Link State Request Packets, this need not be 4243 the case. RT1 could have interleaved the sending of Link State 4244 Request Packets with the reception of Database Description 4245 Packets. 4247 11. The Routing Table Structure 4249 The routing table data structure contains all the information 4250 necessary to forward an IP data packet toward its destination. Each 4251 routing table entry describes the collection of best paths to a 4252 particular destination. When forwarding an IP data packet, the 4253 routing table entry providing the best match for the packet's IP 4254 destination is located. The matching routing table entry then 4255 provides the next hop towards the packet's destination. OSPF also 4256 provides for the existence of a default route (Destination ID = 4257 DefaultDestination, Address Mask = 0x00000000). When the default 4258 route exists, it matches all IP destinations (although any other 4259 matching entry is a better match). Finding the routing table entry 4260 that best matches an IP destination is further described in Section 4261 11.1. 4263 There is a single routing table in each router. Two sample routing 4264 tables are described in Sections 11.2 and 11.3. The building of the 4265 routing table is discussed in Section 16. 4267 The rest of this section defines the fields found in a routing table 4268 entry. The first set of fields describes the routing table entry's 4269 destination. 4271 Destination Type 4272 The destination can be one of three types. Only the first type, 4273 Network, is actually used when forwarding IP data traffic. The 4274 other destinations are used solely as intermediate steps in the 4275 routing table build process. 4277 Network 4278 A range of IP addresses, to which IP data traffic may be 4279 forwarded. This includes IP networks (class A, B, or C), IP 4280 subnets, IP supernets and single IP hosts. The default 4281 route also falls in this category. 4283 Area border router 4284 Routers that are connected to multiple OSPF areas. Such 4285 routers originate summary-LSAs. These routing table entries 4286 are used when calculating the inter-area routes (see Section 4287 16.2). These routing table entries may also be associated 4288 with configured virtual links. 4290 AS boundary router 4291 Routers that originate AS-external-LSAs. These routing 4292 table entries are used when calculating the AS external 4293 routes (see Section 16.4). 4295 Destination ID 4296 The destination's identifier or name. This depends on the 4297 Destination Type. For networks, the identifier is their 4298 associated IP address. For all other types, the identifier is 4299 the OSPF Router ID.[9] 4301 Address Mask 4302 Only defined for networks. The network's IP address together 4303 with its address mask defines a range of IP addresses. For IP 4304 subnets, the address mask is referred to as the subnet mask. 4305 For host routes, the mask is "all ones" (0xffffffff). 4307 Optional Capabilities 4308 When the destination is a router (either an area border router 4309 or an AS boundary router) this field indicates the optional OSPF 4310 capabilities supported by the destination router. The two 4311 optional capabilities currently defined by this specification 4312 are the ability to route based on IP TOS and the ability to 4313 process AS-external-LSAs. For a further discussion of OSPF's 4314 optional capabilities, see Section 4.5. 4316 The set of paths to use for a destination may vary based on IP Type 4317 of Service and the OSPF area to which the paths belong. This means 4318 that there may be multiple routing table entries for the same 4319 destination, depending on the values of the next two fields. 4321 Type of Service 4322 There can be a separate set of routes for each IP Type of 4323 Service. The encoding of TOS in OSPF LSAs is described in 4324 Section 12.3. 4326 Area 4327 This field indicates the area whose link state information has 4328 led to the routing table entry's collection of paths. This is 4329 called the entry's associated area. For sets of AS external 4330 paths, this field is not defined. For destinations of type 4331 "area border router", there may be separate sets of paths (and 4332 therefore separate routing table entries) associated with each 4333 of several areas. This will happen when two area border routers 4334 share multiple areas in common. For all other destination 4335 types, only the set of paths associated with the best area (the 4336 one providing the shortest route) is kept. 4338 The rest of the routing table entry describes the set of paths to 4339 the destination. The following fields pertain to the set of paths 4340 as a whole. In other words, each one of the paths contained in a 4341 routing table entry is of the same path-type and cost (see below). 4343 Path-type 4344 There are four possible types of paths used to route traffic to 4345 the destination, listed here in order of preference: intra-area, 4346 inter-area, type 1 external or type 2 external. Intra-area 4347 paths indicate destinations belonging to one of the router's 4348 attached areas. Inter-area paths are paths to destinations in 4349 other OSPF areas. These are discovered through the examination 4350 of received summary-LSAs. AS external paths are paths to 4351 destinations external to the AS. These are detected through the 4352 examination of received AS-external-LSAs. 4354 Cost 4355 The link state cost of the path to the destination. For all 4356 paths except type 2 external paths this describes the entire 4357 path's cost. For Type 2 external paths, this field describes 4358 the cost of the portion of the path internal to the AS. This 4359 cost is calculated as the sum of the costs of the path's 4360 constituent links. 4362 Type 2 cost 4363 Only valid for type 2 external paths. For these paths, this 4364 field indicates the cost of the path's external portion. This 4365 cost has been advertised by an AS boundary router, and is the 4366 most significant part of the total path cost. For example, a 4367 type 2 external path with type 2 cost of 5 is always preferred 4368 over a path with type 2 cost of 10, regardless of the cost of 4369 the two paths' internal components. 4371 Link State Origin 4372 Valid only for intra-area paths, this field indicates the LSA 4373 (router-LSA or network-LSA) that directly references the 4374 destination. For example, if the destination is a transit 4375 network, this is the transit network's network-LSA. If the 4376 destination is a stub network, this is the router-LSA for the 4377 attached router. The LSA is discovered during the shortest-path 4378 tree calculation (see Section 16.1). Multiple LSAs may 4379 reference the destination, however a tie-breaking scheme always 4380 reduces the choice to a single LSA. The Link State Origin field 4381 is not used by the OSPF protocol, but it is used by the routing 4382 table calculation in OSPF's Multicast routing extensions 4383 (MOSPF). 4385 When multiple paths of equal path-type and cost exist to a 4386 destination (called elsewhere "equal-cost" paths), they are stored 4387 in a single routing table entry. Each one of the "equal-cost" paths 4388 is distinguished by the following fields: 4390 Next hop 4391 The outgoing router interface to use when forwarding traffic to 4392 the destination. On broadcast, Point-to-MultiPoint and NBMA 4393 networks, the next hop also includes the IP address of the next 4394 router (if any) in the path towards the destination. This next 4395 router will always be one of the adjacent neighbors. 4397 Advertising router 4398 Valid only for inter-area and AS external paths. This field 4399 indicates the Router ID of the router advertising the summary- 4400 LSA or AS-external-LSA that led to this path. 4402 11.1. Routing table lookup 4404 When an IP data packet is received, an OSPF router finds the 4405 routing table entry that best matches the packet's destination. 4406 This routing table entry then provides the outgoing interface 4407 and next hop router to use in forwarding the packet. This 4408 section describes the process of finding the best matching 4409 routing table entry. The process consists of a number of steps, 4410 wherein the collection of routing table entries is progressively 4411 pruned. In the end, the single routing table entry remaining is 4412 called the "best match". 4414 Before the lookup begins, "discard" routing table entries should 4415 be inserted into the routing table for each of the router's 4416 active area address ranges (see Section 3.5). (An area range is 4417 considered "active" if the range contains one or more networks 4418 reachable by intra-area paths.) The destination of a "discard" 4419 entry is the set of addresses described by its associated active 4420 area address range, and the path type of each "discard" entry is 4421 set to "inter-area".[10] 4423 Note that the steps described below may fail to produce a best 4424 match routing table entry (i.e., all existing routing table 4425 entries are pruned for some reason or another), or the best 4426 match routing table entry may be one of the above "discard" 4427 routing table entries. In these cases, the packet's IP 4428 destination is considered unreachable. Instead of being 4429 forwarded, the packet should be discarded and an ICMP 4430 destination unreachable message should be returned to the 4431 packet's source. 4433 (1) Select the complete set of "matching" routing table entries 4434 from the routing table. Each routing table entry describes 4435 a (set of) path(s) to a range of IP addresses. If the data 4436 packet's IP destination falls into an entry's range of IP 4437 addresses, the routing table entry is called a match. (It is 4438 quite likely that multiple entries will match the data 4439 packet. For example, a default route will match all 4440 packets.) 4442 (2) Reduce the set of matching entries to those having the most 4443 preferential path-type (see Section 11). OSPF has a four 4444 level hierarchy of paths. Intra-area paths are the most 4445 preferred, followed in order by inter-area, type 1 external 4446 and type 2 external paths. 4448 (3) Select the remaining routing table entry that provides the 4449 most specific (longest) match. Another way of saying this is 4450 to choose the remaining entry that specifies the narrowest 4451 range of IP addresses.[11] For example, the entry for the 4452 address/mask pair of (128.185.1.0, 0xffffff00) is more 4453 specific than an entry for the pair (128.185.0.0, 4454 0xffff0000). The default route is the least specific match, 4455 since it matches all destinations. 4457 (4) At this point, there may still be multiple routing table 4458 entries remaining. Each routing entry will specify the same 4459 range of IP addresses, but a different IP Type of Service. 4460 Select the routing table entry whose TOS value matches the 4461 TOS found in the packet header. If there is no routing table 4462 entry for this TOS, select the routing table entry for TOS 4463 0. In other words, packets requesting TOS X are routed along 4464 the TOS 0 path if a TOS X path does not exist. 4466 11.2. Sample routing table, without areas 4468 Consider the Autonomous System pictured in Figure 2. No OSPF 4469 areas have been configured. A single metric is shown per 4470 outbound interface, indicating that routes will not vary based 4471 on TOS. The calculation of Router RT6's routing table proceeds 4472 as described in Section 2.2. The resulting routing table is 4473 shown in Table 12. Destination types are abbreviated: Network 4474 as "N", area border router as "BR" and AS boundary router as 4475 "ASBR". 4477 There are no instances of multiple equal-cost shortest paths in 4478 this example. Also, since there are no areas, there are no 4479 inter-area paths. 4481 Routers RT5 and RT7 are AS boundary routers. Intra-area routes 4482 have been calculated to Routers RT5 and RT7. This allows 4483 external routes to be calculated to the destinations advertised 4484 by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is 4485 assumed all AS-external-LSAs originated by RT5 and RT7 are 4486 advertising type 1 external metrics. This results in type 1 4487 external paths being calculated to destinations N12-N15. 4489 11.3. Sample routing table, with areas 4491 Consider the previous example, this time split into OSPF areas. 4492 An OSPF area configuration is pictured in Figure 6. Router 4493 RT4's routing table will be described for this area 4494 configuration. Router RT4 has a connection to Area 1 and a 4495 backbone connection. This causes Router RT4 to view the AS as 4496 the concatenation of the two graphs shown in Figures 7 and 8. 4497 The resulting routing table is displayed in Table 13. 4499 Again, Routers RT5 and RT7 are AS boundary routers. Routers 4500 RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 4501 there are two routing table entries (in this case having 4502 identical paths) for Router RT7, in its dual capacities as an 4503 area border router and an AS boundary router. Note also that 4504 there are two routing entries for the area border router RT3, 4505 since it has two areas in common with RT4 (Area 1 and the 4506 Type Dest Area Path Type Cost Next Adv. 4507 Hop(s) Router(s) 4508 ____________________________________________________________ 4509 N N1 0 intra-area 10 RT3 * 4510 N N2 0 intra-area 10 RT3 * 4511 N N3 0 intra-area 7 RT3 * 4512 N N4 0 intra-area 8 RT3 * 4513 N Ib 0 intra-area 7 * * 4514 N Ia 0 intra-area 12 RT10 * 4515 N N6 0 intra-area 8 RT10 * 4516 N N7 0 intra-area 12 RT10 * 4517 N N8 0 intra-area 10 RT10 * 4518 N N9 0 intra-area 11 RT10 * 4519 N N10 0 intra-area 13 RT10 * 4520 N N11 0 intra-area 14 RT10 * 4521 N H1 0 intra-area 21 RT10 * 4522 ASBR RT5 0 intra-area 6 RT5 * 4523 ASBR RT7 0 intra-area 8 RT10 * 4524 ____________________________________________________________ 4525 N N12 * type 1 ext. 10 RT10 RT7 4526 N N13 * type 1 ext. 14 RT5 RT5 4527 N N14 * type 1 ext. 14 RT5 RT5 4528 N N15 * type 1 ext. 17 RT10 RT7 4530 Table 12: The routing table for Router RT6 4531 (no configured areas). 4533 backbone). 4535 Backbone paths have been calculated to all area border routers 4536 (BR). These are used when determining the inter-area routes. 4537 Note that all of the inter-area routes are associated with the 4538 backbone; this is always the case when the calculating router is 4539 itself an area border router. Routing information is condensed 4540 at area boundaries. In this example, we assume that Area 3 has 4541 been defined so that networks N9-N11 and the host route to H1 4542 are all condensed to a single route when advertised into the 4543 backbone (by Router RT11). Note that the cost of this route is 4544 the minimum of the set of costs to its individual components. 4546 There is a virtual link configured between Routers RT10 and 4547 RT11. Without this configured virtual link, RT11 would be 4548 unable to advertise a route for networks N9-N11 and Host H1 into 4549 the backbone, and there would not be an entry for these networks 4550 in Router RT4's routing table. 4552 In this example there are two equal-cost paths to Network N12. 4553 However, they both use the same next hop (Router RT5). 4555 Router RT4's routing table would improve (i.e., some of the 4556 paths in the routing table would become shorter) if an 4557 additional virtual link were configured between Router RT4 and 4558 Router RT3. The new virtual link would itself be associated 4559 with the first entry for area border router RT3 in Table 13 (an 4560 intra-area path through Area 1). This would yield a cost of 1 4561 for the virtual link. The routing table entries changes that 4562 would be caused by the addition of this virtual link are shown 4564 Type Dest Area Path Type Cost Next Adv. 4565 Hops(s) Router(s) 4566 __________________________________________________________________ 4567 N N1 1 intra-area 4 RT1 * 4568 N N2 1 intra-area 4 RT2 * 4569 N N3 1 intra-area 1 * * 4570 N N4 1 intra-area 3 RT3 * 4571 BR RT3 1 intra-area 1 * * 4572 __________________________________________________________________ 4573 N Ib 0 intra-area 22 RT5 * 4574 N Ia 0 intra-area 27 RT5 * 4575 BR RT3 0 intra-area 21 RT5 * 4576 BR RT7 0 intra-area 14 RT5 * 4577 BR RT10 0 intra-area 22 RT5 * 4578 BR RT11 0 intra-area 25 RT5 * 4579 ASBR RT5 0 intra-area 8 * * 4580 ASBR RT7 0 intra-area 14 RT5 * 4581 __________________________________________________________________ 4582 N N6 0 inter-area 15 RT5 RT7 4583 N N7 0 inter-area 19 RT5 RT7 4584 N N8 0 inter-area 18 RT5 RT7 4585 N N9-N11,H1 0 inter-area 26 RT5 RT11 4586 __________________________________________________________________ 4587 N N12 * type 1 ext. 16 RT5 RT5,RT7 4588 N N13 * type 1 ext. 16 RT5 RT5 4589 N N14 * type 1 ext. 16 RT5 RT5 4590 N N15 * type 1 ext. 23 RT5 RT7 4592 Table 13: Router RT4's routing table 4593 in the presence of areas. 4595 in Table 14. 4597 12. Link State Advertisements (LSAs) 4599 Each router in the Autonomous System originates one or more link 4600 state advertisements (LSAs). This memo defines five distinct types 4601 of LSAs, which are described in Section 4.3. The collection of LSAs 4602 forms the link-state database. Each separate type of LSA has a 4603 separate function. Router-LSAs and network-LSAs describe how an 4604 area's routers and networks are interconnected. Summary-LSAs 4605 provide a way of condensing an area's routing information. AS- 4606 external-LSAs provide a way of transparently advertising 4607 externally-derived routing information throughout the Autonomous 4608 System. 4610 Each LSA begins with a standard 20-byte header. This LSA header is 4611 discussed below. 4613 12.1. The LSA Header 4615 The LSA header contains the LS type, Link State ID and 4616 Advertising Router fields. The combination of these three 4617 fields uniquely identifies the LSA. 4619 There may be several instances of an LSA present in the 4620 Autonomous System, all at the same time. It must then be 4621 determined which instance is more recent. This determination is 4623 Type Dest Area Path Type Cost Next Adv. 4624 Hop(s) Router(s) 4625 ________________________________________________________________ 4626 N Ib 0 intra-area 16 RT3 * 4627 N Ia 0 intra-area 21 RT3 * 4628 BR RT3 0 intra-area 1 * * 4629 BR RT10 0 intra-area 16 RT3 * 4630 BR RT11 0 intra-area 19 RT3 * 4631 ________________________________________________________________ 4632 N N9-N11,H1 0 inter-area 20 RT3 RT11 4634 Table 14: Changes resulting from an 4635 additional virtual link. 4637 made by examining the LS sequence, LS checksum and LS age 4638 fields. These fields are also contained in the 20-byte LSA 4639 header. 4641 Several of the OSPF packet types list LSAs. When the instance 4642 is not important, an LSA is referred to by its LS type, Link 4643 State ID and Advertising Router (see Link State Request 4644 Packets). Otherwise, the LS sequence number, LS age and LS 4645 checksum fields must also be referenced. 4647 A detailed explanation of the fields contained in the LSA header 4648 follows. 4650 12.1.1. LS age 4652 This field is the age of the LSA in seconds. It should be 4653 processed as an unsigned 16-bit integer. It is set to 0 4654 when the LSA is originated. It must be incremented by 4655 InfTransDelay on every hop of the flooding procedure. LSAs 4656 are also aged as they are held in each router's database. 4658 The age of an LSA is never incremented past MaxAge. LSAs 4659 having age MaxAge are not used in the routing table 4660 calculation. When an LSA's age first reaches MaxAge, it is 4661 reflooded. An LSA of age MaxAge is finally flushed from the 4662 database when it is no longer needed to ensure database 4663 synchronization. For more information on the aging of LSAs, 4664 consult Section 14. 4666 The LS age field is examined when a router receives two 4667 instances of an LSA, both having identical LS sequence 4668 numbers and LS checksums. An instance of age MaxAge is then 4669 always accepted as most recent; this allows old LSAs to be 4670 flushed quickly from the routing domain. Otherwise, if the 4671 ages differ by more than MaxAgeDiff, the instance having the 4672 smaller age is accepted as most recent.[12] See Section 13.1 4673 for more details. 4675 12.1.2. Options 4677 The Options field in the LSA header indicates which optional 4678 capabilities are associated with the LSA. OSPF's optional 4679 capabilities are described in Section 4.5. There are 4680 currently two optional capabilities defined; they are 4681 represented by the T-bit and E-bit found in the Options 4682 field. The rest of the Options field should be set to zero. 4684 The E-bit represents OSPF's ExternalRoutingCapability. This 4685 bit should be set in all LSAs associated with the backbone, 4686 and all LSAs associated with non-stub areas (see Section 4687 3.6). It should also be set in all AS-external-LSAs. It 4688 should be reset in all router-LSAs, network-LSAs and 4689 summary-LSAs associated with a stub area. For all LSAs, the 4690 setting of the E-bit is for informational purposes only; it 4691 does not affect the routing table calculation. 4693 The T-bit represents OSPF's TOS routing capability. This 4694 bit should be set in a router-LSA if and only if the router 4695 is capable of calculating separate routes for each IP TOS 4696 (see Section 2.5). The T-bit should always be set in 4697 network-LSAs. It should be set in summary-LSAs and AS- 4698 external-LSAs if and only if the LSA describes paths for all 4699 TOS values, instead of just the TOS 0 path. Note that, with 4700 the T-bit set, there may still be only a single metric in 4701 the LSA (the TOS 0 metric). This would mean that paths for 4702 non-zero TOS exist, but are equivalent to the TOS 0 path. 4703 An LSA's T-bit is examined when calculating the routing 4704 table's non-zero TOS paths (see Section 16.9). 4706 12.1.3. LS type 4708 The LS type field dictates the format and function of the 4709 LSA. LSAs of different types have different names (e.g., 4710 router-LSAs or network-LSAs). All LSA types defined by this 4711 memo, except the AS-external-LSAs (LS type = 5), are flooded 4712 throughout a single area only. AS-external-LSAs are flooded 4713 throughout the entire Autonomous System, excepting stub 4714 areas (see Section 3.6). Each separate LSA type is briefly 4715 described below in Table 15. 4717 12.1.4. Link State ID 4719 This field identifies the piece of the routing domain that 4720 is being described by the LSA. Depending on the LSA's LS 4721 type, the Link State ID takes on the values listed in Table 4722 16. 4724 Actually, for Type 3 summary-LSAs (LS type = 3) and AS- 4725 external-LSAs (LS type = 5), the Link State ID may 4726 additionally have one or more of the destination network's 4727 "host" bits set. For example, when originating an AS- 4728 external-LSA for the network 10.0.0.0 with mask of 4729 255.0.0.0, the Link State ID can be set to anything in the 4730 LS Type LSA description 4731 ________________________________________________ 4732 1 These are the router-LSAs. 4733 They describe the collected 4734 states of the router's 4735 interfaces. For more information, 4736 consult Section 12.4.1. 4737 ________________________________________________ 4738 2 These are the network-LSAs. 4739 They describe the set of routers 4740 attached to the network. For 4741 more information, consult 4742 Section 12.4.2. 4743 ________________________________________________ 4744 3 or 4 These are the summary-LSAs. 4745 They describe inter-area routes, 4746 and enable the condensation of 4747 routing information at area 4748 borders. Originated by area border 4749 routers, the Type 3 summary-LSAs 4750 describe routes to networks while the 4751 Type 4 summary-LSAs describe routes to 4752 AS boundary routers. 4753 ________________________________________________ 4754 5 These are the AS-external-LSAs. 4755 Originated by AS boundary routers, 4756 they describe routes 4757 to destinations external to the 4758 Autonomous System. A default route for 4759 the Autonomous System can also be 4760 described by an AS-external-LSA. 4762 Table 15: OSPF link state advertisements (LSAs). 4764 LS Type Link State ID 4765 _______________________________________________ 4766 1 The originating router's Router ID. 4767 2 The IP interface address of the 4768 network's Designated Router. 4769 3 The destination network's IP address. 4770 4 The Router ID of the described AS 4771 boundary router. 4772 5 The destination network's IP address. 4774 Table 16: The LSA's Link State ID. 4776 range 10.0.0.0 through 10.255.255.255 inclusive (although 4777 10.0.0.0 should be used whenever possible). The freedom to 4778 set certain host bits allows a router to originate separate 4779 LSAs for two networks having the same address but different 4780 masks. See Appendix E for details. 4782 When the LSA is describing a network (LS type = 2, 3 or 5), 4783 the network's IP address is easily derived by masking the 4784 Link State ID with the network/subnet mask contained in the 4785 body of the LSA. When the LSA is describing a router (LS 4786 type = 1 or 4), the Link State ID is always the described 4787 router's OSPF Router ID. 4789 When an AS-external-LSA (LS Type = 5) is describing a 4790 default route, its Link State ID is set to 4791 DefaultDestination (0.0.0.0). 4793 12.1.5. Advertising Router 4795 This field specifies the OSPF Router ID of the LSA's 4796 originator. For router-LSAs, this field is identical to the 4797 Link State ID field. Network-LSAs are originated by the 4798 network's Designated Router. Summary-LSAs originated by 4799 area border routers. AS-external-LSAs are originated by AS 4800 boundary routers. 4802 12.1.6. LS sequence number 4804 The sequence number field is a signed 32-bit integer. It is 4805 used to detect old and duplicate LSAs. The space of 4806 sequence numbers is linearly ordered. The larger the 4807 sequence number (when compared as signed 32-bit integers) 4808 the more recent the LSA. To describe to sequence number 4809 space more precisely, let N refer in the discussion below to 4810 the constant 2**31. 4812 The sequence number -N (0x80000000) is reserved (and 4813 unused). This leaves -N + 1 (0x80000001) as the smallest 4814 (and therefore oldest) sequence number; this sequence number 4815 is referred to as the constant InitialSequenceNumber. A 4816 router uses InitialSequenceNumber the first time it 4817 originates any LSA. Afterwards, the LSA's sequence number 4818 is incremented each time the router originates a new 4819 instance of the LSA. When an attempt is made to increment 4820 the sequence number past the maximum value of N - 1 4821 (0x7fffffff; also referred to as MaxSequenceNumber), the 4822 current instance of the LSA must first be flushed from the 4823 routing domain. This is done by prematurely aging the LSA 4824 (see Section 14.1) and reflooding it. As soon as this flood 4825 has been acknowledged by all adjacent neighbors, a new 4826 instance can be originated with sequence number of 4827 InitialSequenceNumber. 4829 The router may be forced to promote the sequence number of 4830 one of its LSAs when a more recent instance of the LSA is 4831 unexpectedly received during the flooding process. This 4832 should be a rare event. This may indicate that an out-of- 4833 date LSA, originated by the router itself before its last 4834 restart/reload, still exists in the Autonomous System. For 4835 more information see Section 13.4. 4837 12.1.7. LS checksum 4839 This field is the checksum of the complete contents of the 4840 LSA, excepting the LS age field. The LS age field is 4841 excepted so that an LSA's age can be incremented without 4842 updating the checksum. The checksum used is the same that 4843 is used for ISO connectionless datagrams; it is commonly 4844 referred to as the Fletcher checksum. It is documented in 4845 Annex B of [Ref6]. The LSA header also contains the length 4846 of the LSA in bytes; subtracting the size of the LS age 4847 field (two bytes) yields the amount of data to checksum. 4849 The checksum is used to detect data corruption of an LSA. 4850 This corruption can occur while an LSA is being flooded, or 4851 while it is being held in a router's memory. The LS 4852 checksum field cannot take on the value of zero; the 4853 occurrence of such a value should be considered a checksum 4854 failure. In other words, calculation of the checksum is not 4855 optional. 4857 The checksum of an LSA is verified in two cases: a) when it 4858 is received in a Link State Update Packet and b) at times 4859 during the aging of the link state database. The detection 4860 of a checksum failure leads to separate actions in each 4861 case. See Sections 13 and 14 for more details. 4863 Whenever the LS sequence number field indicates that two 4864 instances of an LSA are the same, the LS checksum field is 4865 examined. If there is a difference, the instance with the 4866 larger LS checksum is considered to be most recent.[13] See 4867 Section 13.1 for more details. 4869 12.2. The link state database 4871 A router has a separate link state database for every area to 4872 which it belongs. All routers belonging to the same area have 4873 identical link state databases for the area. 4875 The databases for each individual area are always dealt with 4876 separately. The shortest path calculation is performed 4877 separately for each area (see Section 16). Components of the 4878 area link-state database are flooded throughout the area only. 4879 Finally, when an adjacency (belonging to Area A) is being 4880 brought up, only the database for Area A is synchronized between 4881 the two routers. 4883 The area database is composed of router-LSAs, network-LSAs and 4884 summary-LSAs (all listed in the area data structure). In 4885 addition, external routes (AS-external-LSAs) are included in all 4886 non-stub area databases (see Section 3.6). 4888 An implementation of OSPF must be able to access individual 4889 pieces of an area database. This lookup function is based on an 4890 LSA's LS type, Link State ID and Advertising Router.[14] There 4891 will be a single instance (the most up-to-date) of each LSA in 4892 the database. The database lookup function is invoked during 4893 the LSA flooding procedure (Section 13) and the routing table 4894 calculation (Section 16). In addition, using this lookup 4895 function the router can determine whether it has itself ever 4896 originated a particular LSA, and if so, with what LS sequence 4897 number. 4899 An LSA is added to a router's database when either a) it is 4900 received during the flooding process (Section 13) or b) it is 4901 originated by the router itself (Section 12.4). An LSA is 4902 deleted from a router's database when either a) it has been 4903 overwritten by a newer instance during the flooding process 4904 (Section 13) or b) the router originates a newer instance of one 4905 of its self-originated LSAs (Section 12.4) or c) the LSA ages 4906 out and is flushed from the routing domain (Section 14). 4907 Whenever an LSA is deleted from the database it must also be 4908 removed from all neighbors' Link state retransmission lists (see 4909 Section 10). 4911 12.3. Representation of TOS 4913 All OSPF LSAs (with the exception of network-LSAs) specify 4914 metrics. In router-LSAs, the metrics indicate the costs of the 4915 described interfaces. In summary-LSAs and AS-external-LSAs, the 4916 metric indicates the cost of the described path. In all of 4917 these LSAs, a separate metric can be specified for each IP TOS. 4918 The encoding of TOS in OSPF LSAs is specified in Table 17. That 4919 table relates the OSPF encoding to the IP packet header's TOS 4920 field (defined in [Ref12]). The OSPF encoding is expressed as a 4921 decimal integer, and the IP packet header's TOS field is 4922 expressed in the binary TOS values used in [Ref12]. 4924 OSPF encoding RFC 1349 TOS values 4925 ___________________________________________ 4926 0 0000 normal service 4927 2 0001 minimize monetary cost 4928 4 0010 maximize reliability 4929 6 0011 4930 8 0100 maximize throughput 4931 10 0101 4932 12 0110 4933 14 0111 4934 16 1000 minimize delay 4935 18 1001 4936 20 1010 4937 22 1011 4938 24 1100 4939 26 1101 4940 28 1110 4941 30 1111 4943 Table 17: Representing TOS in OSPF. 4945 Each OSPF LSA must specify the TOS 0 metric. Other TOS metrics, 4946 if they appear, must appear in order of increasing TOS encoding. 4948 For example, the TOS 8 (maximize throughput) metric must always 4949 appear before the TOS 16 (minimize delay) metric when both are 4950 specified. If a metric for some non-zero TOS is not specified, 4951 its cost defaults to the cost for TOS 0, unless the T-bit is 4952 reset in the LSA's Options field (see Section 12.1.2 for more 4953 details). 4955 12.4. Originating LSAs 4957 Into any given OSPF area, a router will originate several LSAs. 4958 Each router originates a router-LSA. If the router is also the 4959 Designated Router for any of the area's networks, it will 4960 originate network-LSAs for those networks. 4962 Area border routers originate a single summary-LSA for each 4963 known inter-area destination. AS boundary routers originate a 4964 single AS-external-LSA for each known AS external destination. 4965 Destinations are advertised one at a time so that the change in 4966 any single route can be flooded without reflooding the entire 4967 collection of routes. During the flooding procedure, many LSAs 4968 can be carried by a single Link State Update packet. 4970 As an example, consider Router RT4 in Figure 6. It is an area 4971 border router, having a connection to Area 1 and the backbone. 4972 Router RT4 originates 5 distinct LSAs into the backbone (one 4973 router-LSA, and one summary-LSA for each of the networks N1-N4). 4974 Router RT4 will also originate 8 distinct LSAs into Area 1 (one 4975 router-LSA and seven summary-LSAs as pictured in Figure 7). If 4976 RT4 has been selected as Designated Router for Network N3, it 4977 will also originate a network-LSA for N3 into Area 1. 4979 In this same figure, Router RT5 will be originating 3 distinct 4980 AS-external-LSAs (one for each of the networks N12-N14). These 4981 will be flooded throughout the entire AS, assuming that none of 4982 the areas have been configured as stubs. However, if area 3 has 4983 been configured as a stub area, the AS-external-LSAs for 4984 networks N12-N14 will not be flooded into area 3 (see Section 4985 3.6). Instead, Router RT11 would originate a default summary- 4986 LSA that would be flooded throughout area 3 (see Section 4987 12.4.3). This instructs all of area 3's internal routers to 4988 send their AS external traffic to RT11. 4990 Whenever a new instance of an LSA is originated, its LS sequence 4991 number is incremented, its LS age is set to 0, its LS checksum 4992 is calculated, and the LSA is added to the link state database 4993 and flooded out the appropriate interfaces. See Section 13.2 4994 for details concerning the installation of the LSA into the link 4995 state database. See Section 13.3 for details concerning the 4996 flooding of newly originated LSAs. 4998 The ten events that can cause a new instance of an LSA to be 4999 originated are: 5001 (1) The LS age field of one of the router's self-originated LSAs 5002 reaches the value LSRefreshTime. In this case, a new 5003 instance of the LSA is originated, even though the contents 5004 of the LSA (apart from the LSA header) will be the same. 5005 This guarantees periodic originations of all LSAs. This 5006 periodic updating of LSAs adds robustness to the link state 5007 algorithm. LSAs that solely describe unreachable 5008 destinations should not be refreshed, but should instead be 5009 flushed from the routing domain (see Section 14.1). 5011 When whatever is being described by an LSA changes, a new LSA is 5012 originated. However, two instances of the same LSA may not be 5013 originated within the time period MinLSInterval. This may 5014 require that the generation of the next instance be delayed by 5015 up to MinLSInterval. The following events may cause the 5016 contents of an LSA to change. These events should cause new 5017 originations if and only if the contents of the new LSA would be 5018 different: 5020 (2) An interface's state changes (see Section 9.1). This may 5021 mean that it is necessary to produce a new instance of the 5022 router-LSA. 5024 (3) An attached network's Designated Router changes. A new 5025 router-LSA should be originated. Also, if the router itself 5026 is now the Designated Router, a new network-LSA should be 5027 produced. If the router itself is no longer the Designated 5028 Router, any network-LSA that it might have originated for 5029 the network should be flushed from the routing domain (see 5030 Section 14.1). 5032 (4) One of the neighboring routers changes to/from the FULL 5033 state. This may mean that it is necessary to produce a new 5034 instance of the router-LSA. Also, if the router is itself 5035 the Designated Router for the attached network, a new 5036 network-LSA should be produced. 5038 The next four events concern area border routers only: 5040 (5) An intra-area route has been added/deleted/modified in the 5041 routing table. This may cause a new instance of a summary- 5042 LSA (for this route) to be originated in each attached area 5043 (possibly including the backbone). 5045 (6) An inter-area route has been added/deleted/modified in the 5046 routing table. This may cause a new instance of a summary- 5047 LSA (for this route) to be originated in each attached area 5048 (but NEVER for the backbone). 5050 (7) The router becomes newly attached to an area. The router 5051 must then originate summary-LSAs into the newly attached 5052 area for all pertinent intra-area and inter-area routes in 5053 the router's routing table. See Section 12.4.3 for more 5054 details. 5056 (8) When the state of one of the router's configured virtual 5057 links changes, it may be necessary to originate a new 5058 router-LSA into the virtual link's Transit area (see the 5059 discussion of the router-LSA's bit V in Section 12.4.1), as 5060 well as originating a new router-LSA into the backbone. 5062 The last two events concern AS boundary routers (and former AS 5063 boundary routers) only: 5065 (9) An external route gained through direct experience with an 5066 external routing protocol (like BGP) changes. This will 5067 cause an AS boundary router to originate a new instance of 5068 an AS-external-LSA. 5070 (10) 5071 A router ceases to be an AS boundary router, perhaps after 5072 restarting. In this situation the router should flush all 5073 AS-external-LSAs that it had previously originated. These 5074 LSAs can be flushed via the premature aging procedure 5075 specified in Section 14.1. 5077 The construction of each type of LSA is explained in detail 5078 below. In general, these sections describe the contents of the 5079 LSA body (i.e., the part coming after the 20-byte LSA header). 5080 For information concerning the building of the LSA header, see 5081 Section 12.1. 5083 .................................... 5084 . 192.1.2 Area 1 . 5085 . + . 5086 . | . 5087 . | 3+---+1 . 5088 . N1 |--|RT1|-----+ . 5089 . | +---+ . 5090 . | _______N3 . 5091 . + / . 1+---+ 5092 . * 192.1.1 *------|RT4| 5093 . + /_______/ . +---+ 5094 . | / | . 5095 . | 3+---+1 / | . 5096 . N2 |--|RT2|-----+ 1| . 5097 . | +---+ +---+8 . 6+---+ 5098 . | |RT3|----------------|RT6| 5099 . + +---+ . +---+ 5100 . 192.1.3 |2 . 18.10.0.6|7 5101 . | . | 5102 . +------------+ . 5103 . 192.1.4 (N4) . 5104 .................................... 5106 Figure 15: Area 1 with IP addresses shown 5108 12.4.1. Router-LSAs 5110 A router originates a router-LSA for each area that it 5111 belongs to. Such an LSA describes the collected states of 5112 the router's links to the area. The LSA is flooded 5113 throughout the particular area, and no further. 5115 The format of a router-LSA is shown in Appendix A (Section 5116 A.4.2). The first 20 bytes of the LSA consist of the 5117 generic LSA header that was discussed in Section 12.1. 5118 router-LSAs have LS type = 1. The router indicates whether 5119 it is willing to calculate separate routes for each IP TOS 5120 by setting (or resetting) the T-bit of the LSA's Options 5121 field. 5123 A router also indicates whether it is an area border router, 5124 or an AS boundary router, by setting the appropriate bits 5125 (bit B and bit E, respectively) in its router-LSAs. This 5126 enables paths to those types of routers to be saved in the 5127 routing table, for later processing of summary-LSAs and AS- 5128 external-LSAs. Bit B should be set whenever the router is 5129 actively attached to two or more areas, even if the router 5130 is not currently attached to the OSPF backbone area. Bit E 5131 should never be set in a router-LSA for a stub area (stub 5132 areas cannot contain AS boundary routers). 5134 In addition, the router sets bit V in its router-LSA for 5135 Area A if and only if the router is the endpoint of one or 5136 more fully adjacent virtual links having Area A as their 5137 Transit area. The setting of bit V enables other routers in 5138 Area A to discover whether the area supports transit traffic 5139 (see TransitCapability in Section 6). 5141 The router-LSA then describes the router's working 5142 connections (i.e., interfaces or links) to the area. Each 5143 link is typed according to the kind of attached network. 5144 Each link is also labelled with its Link ID. This Link ID 5145 gives a name to the entity that is on the other end of the 5146 link. Table 18 summarizes the values used for the Type and 5147 Link ID fields. 5149 Link type Description Link ID 5150 __________________________________________________ 5151 1 Point-to-point Neighbor Router ID 5152 link 5153 2 Link to transit Interface address of 5154 network Designated Router 5155 3 Link to stub IP network number 5156 network 5157 4 Virtual link Neighbor Router ID 5159 Table 18: Link descriptions in the 5160 router-LSA. 5162 In addition, the Link Data field is specified for each link. 5163 This field gives 32 bits of extra information for the link. 5164 For links to transit networks, numbered point-to-point links 5165 and virtual links, this field specifies the IP interface 5166 address of the associated router interface (this is needed 5167 by the routing table calculation, see Section 16.1.1). For 5168 links to stub networks, this field specifies the stub 5169 network's IP address mask. For unnumbered point-to-point 5170 links, the Link Data field should be set to the unnumbered 5171 interface's MIB-II [Ref8] ifIndex value. 5173 Finally, the cost of using the link for output (possibly 5174 specifying a different cost for each Type of Service) is 5175 specified. The output cost of a link is configurable. With 5176 the exception of links to stub networks, the output cost 5177 must always be non-zero. 5179 To further describe the process of building the list of link 5180 descriptions, suppose a router wishes to build a router-LSA 5181 for Area A. The router examines its collection of interface 5182 data structures. For each interface, the following steps 5183 are taken: 5185 o If the attached network does not belong to Area A, no 5186 links are added to the LSA, and the next interface 5187 should be examined. 5189 o If the state of the interface is Down, no links are 5190 added. 5192 o If the state of the interface is Loopback, add a Type 3 5193 link (stub network) as long as this is not an interface 5194 to an unnumbered point-to-point network. The Link ID 5195 should be set to the IP interface address, the Link Data 5196 set to the mask 0xffffffff (indicating a host route), 5197 and the cost set to 0. 5199 o Otherwise, the link descriptions added to the router-LSA 5200 depend on the OSPF interface type. Link descriptions 5201 used for point-to-point interfaces are specified in 5202 Section 12.4.1.1, for virtual links in Section 12.4.1.2, 5203 for broadcast and NBMA interfaces in 12.4.1.3, and for 5204 Point-to-MultiPoint interfaces in 12.4.1.4. 5206 After consideration of all the router interfaces, host links 5207 are added to the router-LSA by examining the list of 5208 attached hosts belonging to Area A. A host route is 5209 represented as a Type 3 link (stub network) whose Link ID is 5210 the host's IP address, Link Data is the mask of all ones 5211 (0xffffffff), and cost the host's configured cost (see 5212 Section C.7). 5214 12.4.1.1. Describing point-to-point interfaces 5216 For point-to-point interfaces, one or more link 5217 descriptions are added to the router-LSA as follows: 5219 o If the neighboring router is fully adjacent, add a 5220 Type 1 link (point-to-point). The Link ID should be 5221 set to the Router ID of the neighboring router. For 5222 numbered point-to-point networks, the Link Data 5223 should specify the IP interface address. For 5224 unnumbered point-to-point networks, the Link Data 5225 field should specify the interface's MIB-II [Ref8] 5226 ifIndex value. The cost should be set to the output 5227 cost of the point-to-point interface. 5229 o In addition, as long as the state of the interface 5230 is "Point-to-Point" (and regardless of the 5231 neighboring router state), a Type 3 link (stub 5232 network) should be added. There are two forms that 5233 this stub link can take: 5235 Option 1 5236 Assuming that the neighboring router's IP 5237 address is known, set the Link ID of the Type 3 5238 link to the neighbor's IP address, the Link Data 5239 to the mask 0xffffffff (indicating a host 5240 route), and the cost to the interface's 5241 configured output cost.[15] 5243 Option 2 5244 If a subnet has been assigned to the point-to- 5245 point link, set the Link ID of the Type 3 link 5246 to the subnet's IP address, the Link Data to the 5247 subnet's mask, and the cost to the interface's 5248 configured output cost.[16] 5250 12.4.1.2. Describing broadcast and NBMA interfaces 5252 For operational broadcast and NBMA interfaces, a single 5253 link description is added to the router-LSA as follows: 5255 o If the state of the interface is Waiting, add a Type 5256 3 link (stub network) with Link ID set to the IP 5257 network number of the attached network, Link Data 5258 set to the attached network's address mask, and cost 5259 equal to the interface's configured output cost. 5261 o Else, there has been a Designated Router elected for 5262 the attached network. If the router is fully 5263 adjacent to the Designated Router, or if the router 5264 itself is Designated Router and is fully adjacent to 5265 at least one other router, add a single Type 2 link 5266 (transit network) with Link ID set to the IP 5267 interface address of the attached network's 5268 Designated Router (which may be the router itself), 5269 Link Data set to the router's own IP interface 5270 address, and cost equal to the interface's 5271 configured output cost. Otherwise, add a link as if 5272 the interface state were Waiting (see above). 5274 12.4.1.3. Describing virtual links 5276 For virtual links, a link description is added to the 5277 router-LSA only when the virtual neighbor is fully 5278 adjacent. In this case, add a Type 4 link (virtual link) 5279 with Link ID set to the Router ID of the virtual 5280 neighbor, Link Data set to the IP interface address 5281 associated with the virtual link and cost set to the 5282 cost calculated for the virtual link during the routing 5283 table calculation (see Section 15). 5285 12.4.1.4. Describing Point-to-MultiPoint interfaces 5287 For operational Point-to-MultiPoint interfaces, one or 5288 more link descriptions are added to the router-LSA as 5289 follows: 5291 o A single Type 3 link (stub network) is added with 5292 Link ID set to the router's own IP interface 5293 address, Link Data set to the mask 0xffffffff 5294 (indicating a host route), and cost set to 0. 5296 o For each fully adjacent neighbor associated with the 5297 interface, add an additional Type 1 link (point-to- 5298 point) with Link ID set to the Router ID of the 5299 neighboring router, Link Data set to the IP 5300 interface address and cost equal to the interface's 5301 configured output cost. 5303 12.4.1.5. Examples of router-LSAs 5305 Consider the router-LSAs generated by Router RT3, as 5306 pictured in Figure 6. The area containing Router RT3 5307 (Area 1) has been redrawn, with actual network 5308 addresses, in Figure 15. Assume that the last byte of 5309 all of RT3's interface addresses is 3, giving it the 5310 interface addresses 192.1.1.3 and 192.1.4.3, and that 5311 the other routers have similar addressing schemes. In 5312 addition, assume that all links are functional, and that 5313 Router IDs are assigned as the smallest IP interface 5314 address. 5316 RT3 originates two router-LSAs, one for Area 1 and one 5317 for the backbone. Assume that Router RT4 has been 5318 selected as the Designated router for network 192.1.1.0. 5319 RT3's router-LSA for Area 1 is then shown below. It 5320 indicates that RT3 has two connections to Area 1, the 5321 first a link to the transit network 192.1.1.0 and the 5322 second a link to the stub network 192.1.4.0. Note that 5323 the transit network is identified by the IP interface of 5324 its Designated Router (i.e., the Link ID = 192.1.1.4 5325 which is the Designated Router RT4's IP interface to 5326 192.1.1.0). Note also that RT3 has indicated that it is 5327 capable of calculating separate routes based on IP TOS, 5328 through setting the T-bit in the Options field. It has 5329 also indicated that it is an area border router. 5331 ; RT3's router-LSA for Area 1 5333 LS age = 0 ;always true on origination 5334 Options = (T-bit|E-bit) ;TOS-capable 5335 LS type = 1 ;indicates router-LSA 5336 Link State ID = 192.1.1.3 ;RT3's Router ID 5337 Advertising Router = 192.1.1.3 ;RT3's Router ID 5338 bit E = 0 ;not an AS boundary router 5339 bit B = 1 ;area border router 5340 #links = 2 5341 Link ID = 192.1.1.4 ;IP address of Desig. Rtr. 5342 Link Data = 192.1.1.3 ;RT3's IP interface to net 5343 Type = 2 ;connects to transit network 5344 # other metrics = 0 5345 TOS 0 metric = 1 5347 Link ID = 192.1.4.0 ;IP Network number 5348 Link Data = 0xffffff00 ;Network mask 5349 Type = 3 ;connects to stub network 5350 # other metrics = 0 5351 TOS 0 metric = 2 5353 Next RT3's router-LSA for the backbone is shown. It 5354 indicates that RT3 has a single attachment to the 5355 backbone. This attachment is via an unnumbered point- 5356 to-point link to Router RT6. RT3 has again indicated 5357 that it is TOS-capable, and that it is an area border 5358 router. 5360 ; RT3's router-LSA for the backbone 5362 LS age = 0 ;always true on origination 5363 Options = (T-bit|E-bit) ;TOS-capable 5364 LS type = 1 ;indicates router-LSA 5365 Link State ID = 192.1.1.3 ;RT3's router ID 5366 Advertising Router = 192.1.1.3 ;RT3's router ID 5367 bit E = 0 ;not an AS boundary router 5368 bit B = 1 ;area border router 5369 #links = 1 5370 Link ID = 18.10.0.6 ;Neighbor's Router ID 5371 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5372 Type = 1 ;connects to router 5373 # other metrics = 0 5374 TOS 0 metric = 8 5376 Even though Router RT3 has indicated that it is TOS- 5377 capable in the above examples, only a single metric (the 5378 TOS 0 metric) has been specified for each interface. 5379 Different metrics can be specified for each TOS. The 5380 encoding of TOS in OSPF LSAs is described in Section 5381 12.3. 5383 As an example, suppose the point-to-point link between 5384 Routers RT3 and RT6 in Figure 15 is a satellite link. 5385 The AS administrator may want to encourage the use of 5386 the line for high bandwidth traffic. This would be done 5387 by setting the metric artificially low for the 5388 appropriate TOS value. Router RT3 would then originate 5389 the following router-LSA for the backbone (TOS 8 = 5390 maximize throughput): 5392 ; RT3's router-LSA for the backbone 5394 LS age = 0 ;always true on origination 5395 Options = (T-bit|E-bit) ;TOS-capable 5396 LS type = 1 ;indicates router-LSA 5397 Link State ID = 192.1.1.3 ;RT3's Router ID 5398 Advertising Router = 192.1.1.3 5399 bit E = 0 ;not an AS boundary router 5400 bit B = 1 ;area border router 5401 #links = 1 5402 Link ID = 18.10.0.6 ;Neighbor's Router ID 5403 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5404 Type = 1 ;connects to router 5405 # other metrics = 1 5406 TOS 0 metric = 8 5407 TOS = 8 ;maximize throughput 5408 metric = 1 ;traffic preferred 5410 12.4.2. Network-LSAs 5412 A network-LSA is generated for every transit broadcast or 5413 NBMA network. (A transit network is a network having two or 5414 more attached routers). The network-LSA describes all the 5415 routers that are attached to the network. 5417 The Designated Router for the network originates the LSA. 5418 The Designated Router originates the LSA only if it is fully 5419 adjacent to at least one other router on the network. The 5420 network-LSA is flooded throughout the area that contains the 5421 transit network, and no further. The network-LSA lists 5422 those routers that are fully adjacent to the Designated 5423 Router; each fully adjacent router is identified by its OSPF 5424 Router ID. The Designated Router includes itself in this 5425 list. 5427 The Link State ID for a network-LSA is the IP interface 5428 address of the Designated Router. This value, masked by the 5429 network's address mask (which is also contained in the 5430 network-LSA) yields the network's IP address. 5432 A router that has formerly been the Designated Router for a 5433 network, but is no longer, should flush the network-LSA that 5434 it had previously originated. This LSA is no longer used in 5435 the routing table calculation. It is flushed by prematurely 5436 incrementing the LSA's age to MaxAge and reflooding (see 5437 Section 14.1). In addition, in those rare cases where a 5438 router's Router ID has changed, any network-LSAs that were 5439 originated with the router's previous Router ID must be 5440 flushed. Since the router may have no idea what it's 5441 previous Router ID might have been, these network-LSAs are 5442 indicated by having their Link State ID equal to one of the 5443 router's IP interface addresses and their Advertising Router 5444 equal to some value other than the router's current Router 5445 ID (see Section 13.4 for more details). 5447 12.4.2.1. Examples of network-LSAs 5449 Again consider the area configuration in Figure 6. 5450 Network-LSAs are originated for Network N3 in Area 1, 5451 Networks N6 and N8 in Area 2, and Network N9 in Area 3. 5452 Assuming that Router RT4 has been selected as the 5453 Designated Router for Network N3, the following 5454 network-LSA is generated by RT4 on behalf of Network N3 5455 (see Figure 15 for the address assignments): 5457 ; Network-LSA for Network N3 5459 LS age = 0 ;always true on origination 5460 Options = (T-bit|E-bit) ;TOS-capable 5461 LS type = 2 ;indicates network-LSA 5462 Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. 5463 Advertising Router = 192.1.1.4 ;RT4's Router ID 5464 Network Mask = 0xffffff00 5465 Attached Router = 192.1.1.4 ;Router ID 5466 Attached Router = 192.1.1.1 ;Router ID 5467 Attached Router = 192.1.1.2 ;Router ID 5468 Attached Router = 192.1.1.3 ;Router ID 5470 12.4.3. Summary-LSAs 5472 The destination described by a summary-LSA is either an IP 5473 network, an AS boundary router or a range of IP addresses. 5474 Summary-LSAs are flooded throughout a single area only. The 5475 destination described is one that is external to the area, 5476 yet still belongs to the Autonomous System. 5478 Summary-LSAs are originated by area border routers. The 5479 precise summary routes to advertise into an area are 5480 determined by examining the routing table structure (see 5481 Section 11) in accordance with the algorithm described 5482 below. Note that only intra-area routes are advertised into 5483 the backbone, while both intra-area and inter-area routes 5484 are advertised into the other areas. 5486 To determine which routes to advertise into an attached Area 5487 A, each routing table entry is processed as follows. 5488 Remember that each routing table entry describes a set of 5489 equal-cost best paths to a particular destination: 5491 o Only Destination Types of network and AS boundary router 5492 are advertised in summary-LSAs. If the routing table 5493 entry's Destination Type is area border router, examine 5494 the next routing table entry. 5496 o AS external routes are never advertised in summary-LSAs. 5497 If the routing table entry has Path-type of type 1 5498 external or type 2 external, examine the next routing 5499 table entry. 5501 o Else, if the area associated with this set of paths is 5502 the Area A itself, do not generate a summary-LSA for the 5503 route.[17] 5505 o Else, if the next hops associated with this set of paths 5506 belong to Area A itself, do not generate a summary-LSA 5507 for the route.[18] This is the logical equivalent of a 5508 Distance Vector protocol's split horizon logic. 5510 o Else, if the routing table cost equals or exceeds the 5511 value LSInfinity, a summary-LSA cannot be generated for 5512 this route. 5514 o Else, if the destination of this route is an AS boundary 5515 router, generate a Type 4 summary-LSA for the 5516 destination, with Link State ID equal to the AS boundary 5517 router's Router ID and metric equal to the routing table 5518 entry's cost. These LSAs should not be generated if 5519 Area A has been configured as a stub area. 5521 o Else, the Destination type is network. If this is an 5522 inter-area route, generate a Type 3 summary-LSA for the 5523 destination, with Link State ID equal to the network's 5524 address (if necessary, the Link State ID can also have 5525 one or more of the network's host bits set; see Appendix 5526 E for details) and metric equal to the routing table 5527 cost. 5529 o The one remaining case is an intra-area route to a 5530 network. This means that the network is contained in 5531 one of the router's directly attached areas. In 5532 general, this information must be condensed before 5533 appearing in summary-LSAs. Remember that an area has a 5534 configured list of address ranges, each range consisting 5535 of an [address,mask] pair and a status indication of 5536 either Advertise or DoNotAdvertise. At most a single 5537 Type 3 summary-LSA is originated for each range. When 5538 the range's status indicates Advertise, a Type 3 5539 summary-LSA is generated with Link State ID equal to the 5540 range's address (if necessary, the Link State ID can 5541 also have one or more of the range's "host" bits set; 5542 see Appendix E for details) and cost equal to the 5543 smallest cost of any of the component networks. When the 5544 range's status indicates DoNotAdvertise, the Type 3 5545 summary-LSA is suppressed and the component networks 5546 remain hidden from other areas. 5548 By default, if a network is not contained in any 5549 explicitly configured address range, a Type 3 summary- 5550 LSA is generated with Link State ID equal to the 5551 network's address (if necessary, the Link State ID can 5552 also have one or more of the network's "host" bits set; 5553 see Appendix E for details) and metric equal to the 5554 network's routing table cost. 5556 If an area is capable of carrying transit traffic (i.e., 5557 its TransitCapability is set to TRUE), routing 5558 information concerning backbone networks should not be 5559 condensed before being summarized into the area. Nor 5560 should the advertisement of backbone networks into 5561 transit areas be suppressed. In other words, the 5562 backbone's configured ranges should be ignored when 5563 originating summary-LSAs into transit areas. 5565 If a router advertises a summary-LSA for a destination which 5566 then becomes unreachable, the router must then flush the LSA 5567 from the routing domain by setting its age to MaxAge and 5568 reflooding (see Section 14.1). Also, if the destination is 5569 still reachable, yet can no longer be advertised according 5570 to the above procedure (e.g., it is now an inter-area route, 5571 when it used to be an intra-area route associated with some 5572 non-backbone area; it would thus no longer be advertisable 5573 to the backbone), the LSA should also be flushed from the 5574 routing domain. 5576 For the destination described by a summary-LSA there may be 5577 separate sets of paths, and therefore separate routing table 5578 entries, for each Type of Service. All these entries must 5579 be considered when building the summary-LSA for the 5580 destination; a single LSA must specify the separate costs 5581 (if they exist) for each TOS. The encoding of TOS in OSPF 5582 LSAs is described in Section 12.3. 5584 Clearing the T-bit in the Options field of a summary-LSA 5585 indicates that there is a TOS 0 path to the destination, but 5586 no paths for non-zero TOS. This can happen when non-TOS- 5587 capable routers exist in the routing domain (see Section 5588 2.5). 5590 12.4.3.1. Originating summary-LSAs into stub areas 5592 The algorithm in Section 12.4.3 is optional when Area A 5593 is an OSPF stub area. Area border routers connecting to 5594 a stub area can originate summary-LSAs into the area 5595 according to the Section 12.4.3's algorithm, or can 5596 choose to originate only a subset of the summary-LSAs, 5597 possibly under configuration control. The fewer LSAs 5598 originated, the smaller the stub area's link state 5599 database, further reducing the demands on its routers' 5600 resources. However, omitting LSAs may also lead to sub- 5601 optimal inter-area routing, although routing will 5602 continue to function. 5604 As specified in Section 12.4.3, Type 4 summary-LSAs 5605 (ASBR-summary-LSAs) are never originated into stub 5606 areas. 5608 In a stub area, instead of importing external routes 5609 each area border router originates a "default summary- 5610 LSA" into the area. The Link State ID for the default 5611 summary-LSA is set to DefaultDestination, and the metric 5612 set to the (per-area) configurable parameter 5613 StubDefaultCost. Note that StubDefaultCost need not be 5614 configured identically in all of the stub area's area 5615 border routers. 5617 12.4.3.2. Examples of summary-LSAs 5619 Consider again the area configuration in Figure 6. 5620 Routers RT3, RT4, RT7, RT10 and RT11 are all area border 5621 routers, and therefore are originating summary-LSAs. 5622 Consider in particular Router RT4. Its routing table 5623 was calculated as the example in Section 11.3. RT4 5624 originates summary-LSAs into both the backbone and Area 5625 1. Into the backbone, Router RT4 originates separate 5626 LSAs for each of the networks N1-N4. Into Area 1, 5627 Router RT4 originates separate LSAs for networks N6-N8 5628 and the AS boundary routers RT5,RT7. It also condenses 5629 host routes Ia and Ib into a single summary-LSA. 5630 Finally, the routes to networks N9,N10,N11 and Host H1 5631 are advertised by a single summary-LSA. This 5632 condensation was originally performed by the router 5633 RT11. 5635 These LSAs are illustrated graphically in Figures 7 and 5636 8. Two of the summary-LSAs originated by Router RT4 5637 follow. The actual IP addresses for the networks and 5638 routers in question have been assigned in Figure 15. 5640 ; Summary-LSA for Network N1, 5641 ; originated by Router RT4 into the backbone 5642 LS age = 0 ;always true on origination 5643 Options = (T-bit|E-bit) ;TOS-capable 5644 LS type = 3 ;Type 3 summary-LSA 5645 Link State ID = 192.1.2.0 ;N1's IP network number 5646 Advertising Router = 192.1.1.4 ;RT4's ID 5647 TOS = 0 5648 metric = 4 5650 ; Summary-LSA for AS boundary router RT7 5651 ; originated by Router RT4 into Area 1 5653 LS age = 0 ;always true on origination 5654 Options = (T-bit|E-bit) ;TOS-capable 5655 LS type = 4 ;Type 4 summary-LSA 5656 Link State ID = Router RT7's ID 5657 Advertising Router = 192.1.1.4 ;RT4's ID 5658 TOS = 0 5659 metric = 14 5661 12.4.4. AS-external-LSAs 5663 AS-external-LSAs describe routes to destinations external to 5664 the Autonomous System. Most AS-external-LSAs describe 5665 routes to specific external destinations; in these cases the 5666 LSA's Link State ID is set to the destination network's IP 5667 address (if necessary, the Link State ID can also have one 5668 or more of the network's "host" bits set; see Appendix E for 5669 details). However, a default route for the Autonomous 5670 System can be described in an AS-external-LSA by setting the 5671 LSA's Link State ID to DefaultDestination (0.0.0.0). AS- 5672 external-LSAs are originated by AS boundary routers. An AS 5673 boundary router originates a single AS-external-LSA for each 5674 external route that it has learned, either through another 5675 routing protocol (such as BGP), or through configuration 5676 information. 5678 AS-external-LSAs are the only type of LSAs that are flooded 5679 throughout the entire Autonomous System; all other types of 5680 LSAs are specific to a single area. However, AS-external- 5681 LSAs are not flooded into/throughout stub areas (see Section 5682 3.6). This enables a reduction in link state database size 5683 for routers internal to stub areas. 5685 The metric that is advertised for an external route can be 5686 one of two types. Type 1 metrics are comparable to the link 5687 state metric. Type 2 metrics are assumed to be larger than 5688 the cost of any intra-AS path. As with summary-LSAs, if 5689 separate paths exist based on TOS, separate TOS costs can be 5690 included in the AS-external-LSA The encoding of TOS in OSPF 5691 LSAs is described in Section 12.3. If the T-bit of the 5692 LSA's Options field is clear, no non-zero TOS paths to the 5693 destination exist. 5695 If a router advertises an AS-external-LSA for a destination 5696 which then becomes unreachable, the router must then flush 5697 the LSA from the routing domain by setting its age to MaxAge 5698 and reflooding (see Section 14.1). 5700 12.4.4.1. Examples of AS-external-LSAs 5702 Consider once again the AS pictured in Figure 6. There 5703 are two AS boundary routers: RT5 and RT7. Router RT5 5704 originates three AS-external-LSAs, for networks N12-N14. 5705 Router RT7 originates two AS-external-LSAs, for networks 5706 N12 and N15. Assume that RT7 has learned its route to 5707 N12 via BGP, and that it wishes to advertise a Type 2 5708 metric to the AS. RT7 would then originate the 5709 following LSA for N12: 5711 ; AS-external-LSA for Network N12, 5712 ; originated by Router RT7 5714 LS age = 0 ;always true on origination 5715 Options = (T-bit|E-bit) ;TOS-capable 5716 LS type = 5 ;AS-external-LSA 5717 Link State ID = N12's IP network number 5718 Advertising Router = Router RT7's ID 5719 bit E = 1 ;Type 2 metric 5720 TOS = 0 5721 metric = 2 5722 Forwarding address = 0.0.0.0 5724 In the above example, the forwarding address field has 5725 been set to 0.0.0.0, indicating that packets for the 5726 external destination should be forwarded to the 5727 advertising OSPF router (RT7). This is not always 5728 desirable. Consider the example pictured in Figure 16. 5729 There are three OSPF routers (RTA, RTB and RTC) 5730 connected to a common network. Only one of these 5731 routers, RTA, is exchanging BGP information with the 5732 non-OSPF router RTX. RTA must then originate AS- 5733 external-LSAs for those destinations it has learned from 5734 RTX. By using the AS-external-LSA's forwarding address 5735 field, RTA can specify that packets for these 5736 destinations be forwarded directly to RTX. Without this 5737 feature, Routers RTB and RTC would take an extra hop to 5738 get to these destinations. 5740 Note that when the forwarding address field is non-zero, 5741 it should point to a router belonging to another 5742 Autonomous System. 5744 A forwarding address can also be specified for the 5745 default route. For example, in figure 16 RTA may want 5746 to specify that all externally-destined packets should 5747 by default be forwarded to its BGP peer RTX. The 5748 resulting AS-external-LSA is pictured below. Note that 5749 the Link State ID is set to DefaultDestination. 5751 ; Default route, originated by Router RTA 5752 ; Packets forwarded through RTX 5754 LS age = 0 ;always true on origination 5755 Options = (T-bit|E-bit) ;TOS-capable 5756 LS type = 5 ;AS-external-LSA 5757 Link State ID = DefaultDestination ; default route 5758 Advertising Router = Router RTA's ID 5759 bit E = 1 ;Type 2 metric 5760 TOS = 0 5761 metric = 1 5762 Forwarding address = RTX's IP address 5764 In figure 16, suppose instead that both RTA and RTB 5765 exchange BGP information with RTX. In this case, RTA 5766 and RTB would originate the same set of AS-external- 5767 LSAs. These LSAs, if they specify the same metric, 5768 would be functionally equivalent since they would 5769 specify the same destination and forwarding address 5770 (RTX). This leads to a clear duplication of effort. If 5771 only one of RTA or RTB originated the set of AS- 5772 external-LSAs, the routing would remain the same, and 5773 the size of the link state database would decrease. 5774 However, it must be unambiguously defined as to which 5775 router originates the LSAs (otherwise neither may, or 5776 the identity of the originator may oscillate). The 5777 following rule is thereby established: if two routers, 5778 both reachable from one another, originate functionally 5779 equivalent AS-external-LSAs (i.e., same destination, 5780 cost and non-zero forwarding address), then the LSA 5781 originated by the router having the highest OSPF Router 5782 ID is used. The router having the lower OSPF Router ID 5783 can then flush its LSA. Flushing an LSA is discussed in 5784 Section 14.1. 5786 13. The Flooding Procedure 5788 Link State Update packets provide the mechanism for flooding LSAs. 5789 A Link State Update packet may contain several distinct LSAs, and 5790 floods each LSA one hop further from its point of origination. To 5791 make the flooding procedure reliable, each LSA must be acknowledged 5792 separately. Acknowledgments are transmitted in Link State 5793 Acknowledgment packets. Many separate acknowledgments can also be 5794 grouped together into a single packet. 5796 The flooding procedure starts when a Link State Update packet has 5797 been received. Many consistency checks have been made on the 5798 received packet before being handed to the flooding procedure (see 5799 Section 8.2). In particular, the Link State Update packet has been 5800 associated with a particular neighbor, and a particular area. If 5801 the neighbor is in a lesser state than Exchange, the packet should 5802 be dropped without further processing. 5804 All types of LSAs, other than AS-external-LSAs, are associated with 5805 a specific area. However, LSAs do not contain an area field. An 5806 LSA's area must be deduced from the Link State Update packet header. 5808 For each LSA contained in a Link State Update packet, the following 5809 steps are taken: 5811 + 5812 | 5813 +---+.....|.BGP 5814 |RTA|-----|.....+---+ 5815 +---+ |-----|RTX| 5816 | +---+ 5817 +---+ | 5818 |RTB|-----| 5819 +---+ | 5820 | 5821 +---+ | 5822 |RTC|-----| 5823 +---+ | 5824 | 5825 + 5827 Figure 16: Forwarding address example 5828 (1) Validate the LSA's LS checksum. If the checksum turns out to be 5829 invalid, discard the LSA and get the next one from the Link 5830 State Update packet. 5832 (2) Examine the LSA's LS type. If the LS type is unknown, discard 5833 the LSA and get the next one from the Link State Update Packet. 5834 This specification defines LS types 1-5 (see Section 4.3). 5836 (3) Else if this is an AS-external-LSA (LS type = 5), and the area 5837 has been configured as a stub area, discard the LSA and get the 5838 next one from the Link State Update Packet. AS-external-LSAs 5839 are not flooded into/throughout stub areas (see Section 3.6). 5841 (4) Else if the LSA's LS age is equal to MaxAge, and there is 5842 currently no instance of the LSA in the router's link state 5843 database, then take the following actions: 5845 (a) Acknowledge the receipt of the LSA by sending a Link State 5846 Acknowledgment packet back to the sending neighbor (see 5847 Section 13.5). 5849 (b) Purge all outstanding requests for equal or previous 5850 instances of the LSA from the sending neighbor's Link State 5851 Request list (see Section 10). 5853 (c) If the sending neighbor is in state Exchange or in state 5854 Loading, then install the MaxAge LSA in the link state 5855 database. Otherwise, simply discard the LSA. In either 5856 case, examine the next LSA (if any) listed in the Link State 5857 Update packet. 5859 (5) Otherwise, find the instance of this LSA that is currently 5860 contained in the router's link state database. If there is no 5861 database copy, or the received LSA is more recent than the 5862 database copy (see Section 13.1 below for the determination of 5863 which LSA is more recent) the following steps must be performed: 5865 (a) If there is already a database copy, and if the database 5866 copy was installed less than MinLSArrival seconds ago, 5867 discard the new LSA (without acknowledging it) and examine 5868 the next LSA (if any) listed in the Link State Update 5869 packet. 5871 (b) Otherwise immediately flood the new LSA out some subset of 5872 the router's interfaces (see Section 13.3). In some cases 5873 (e.g., the state of the receiving interface is DR and the 5874 LSA was received from a router other than the Backup DR) the 5875 LSA will be flooded back out the receiving interface. This 5876 occurrence should be noted for later use by the 5877 acknowledgment process (Section 13.5). 5879 (c) Remove the current database copy from all neighbors' Link 5880 state retransmission lists. 5882 (d) Install the new LSA in the link state database (replacing 5883 the current database copy). This may cause the routing 5884 table calculation to be scheduled. In addition, timestamp 5885 the new LSA with the current time (i.e., the time it was 5886 received). The flooding procedure cannot overwrite the 5887 newly installed LSA until MinLSArrival seconds have elapsed. 5888 The LSA installation process is discussed further in Section 5889 13.2. 5891 (e) Possibly acknowledge the receipt of the LSA by sending a 5892 Link State Acknowledgment packet back out the receiving 5893 interface. This is explained below in Section 13.5. 5895 (f) If this new LSA indicates that it was originated by the 5896 receiving router itself (i.e., is considered a self- 5897 originated LSA), the router must take special action, either 5898 updating the LSA or in some cases flushing it from the 5899 routing domain. For a description of how self-originated 5900 LSAs are detected and subsequently handled, see Section 5901 13.4. 5903 (6) Else, if there is an instance of the LSA on the sending 5904 neighbor's Link state request list, an error has occurred in the 5905 Database Exchange process. In this case, restart the Database 5906 Exchange process by generating the neighbor event BadLSReq for 5907 the sending neighbor and stop processing the Link State Update 5908 packet. 5910 (7) Else, if the received LSA is the same instance as the database 5911 copy (i.e., neither one is more recent) the following two steps 5912 should be performed: 5914 (a) If the LSA is listed in the Link state retransmission list 5915 for the receiving adjacency, the router itself is expecting 5916 an acknowledgment for this LSA. The router should treat the 5917 received LSA as an acknowledgment by removing the LSA from 5918 the Link state retransmission list. This is termed an 5919 "implied acknowledgment". Its occurrence should be noted 5920 for later use by the acknowledgment process (Section 13.5). 5922 (b) Possibly acknowledge the receipt of the LSA by sending a 5923 Link State Acknowledgment packet back out the receiving 5924 interface. This is explained below in Section 13.5. 5926 (8) Else, the database copy is more recent. If the database copy 5927 has LS age equal to MaxAge and LS sequence number equal to 5928 MaxSequenceNumber, simply discard the received LSA without 5929 acknowledging it. (In this case, the LSA's LS sequence number is 5930 wrapping, and the MaxSequenceNumber LSA must be completely 5931 flushed before any new LSA instance can be introduced). 5932 Otherwise, send the database copy back to the sending neighbor, 5933 encapsulated within a Link State Update Packet. The Link State 5934 Update Packet should be unicast to the neighbor. In so doing, do 5935 not put the database copy of the LSA on the neighbor's link 5936 state retransmission list, and do not acknowledge the received 5937 (less recent) LSA instance. 5939 13.1. Determining which LSA is newer 5941 When a router encounters two instances of an LSA, it must 5942 determine which is more recent. This occurred above when 5943 comparing a received LSA to its database copy. This comparison 5944 must also be done during the Database Exchange procedure which 5945 occurs during adjacency bring-up. 5947 An LSA is identified by its LS type, Link State ID and 5948 Advertising Router. For two instances of the same LSA, the LS 5949 sequence number, LS age, and LS checksum fields are used to 5950 determine which instance is more recent: 5952 o The LSA having the newer LS sequence number is more recent. 5953 See Section 12.1.6 for an explanation of the LS sequence 5954 number space. If both instances have the same LS sequence 5955 number, then: 5957 o If the two instances have different LS checksums, then the 5958 instance having the larger LS checksum (when considered as a 5959 16-bit unsigned integer) is considered more recent. 5961 o Else, if only one of the instances has its LS age field set 5962 to MaxAge, the instance of age MaxAge is considered to be 5963 more recent. 5965 o Else, if the LS age fields of the two instances differ by 5966 more than MaxAgeDiff, the instance having the smaller 5967 (younger) LS age is considered to be more recent. 5969 o Else, the two instances are considered to be identical. 5971 13.2. Installing LSAs in the database 5973 Installing a new LSA in the database, either as the result of 5974 flooding or a newly self-originated LSA, may cause the OSPF 5975 routing table structure to be recalculated. The contents of the 5976 new LSA should be compared to the old instance, if present. If 5977 there is no difference, there is no need to recalculate the 5978 routing table. When comparing an LSA to its previous instance, 5979 the following are all considered to be differences in contents: 5981 o The LSA's Options field has changed. 5983 o One of the LSA instances has LS age set to MaxAge, and 5984 the other does not. 5986 o The length field in the LSA header has changed. 5988 o The body of the LSA (i.e., anything outside the 20-byte 5989 LSA header) has changed. Note that this excludes changes 5990 in LS Sequence Number and LS Checksum. 5992 If the contents are different, the following pieces of the 5993 routing table must be recalculated, depending on the new LSA's 5994 LS type field: 5996 Router-LSAs and network-LSAs 5997 The entire routing table must be recalculated, starting with 5998 the shortest path calculations for each area (not just the 5999 area whose link-state database has changed). The reason 6000 that the shortest path calculation cannot be restricted to 6001 the single changed area has to do with the fact that AS 6002 boundary routers may belong to multiple areas. A change in 6003 the area currently providing the best route may force the 6004 router to use an intra-area route provided by a different 6005 area.[19] 6007 Summary-LSAs 6008 The best route to the destination described by the summary- 6009 LSA must be recalculated (see Section 16.5). If this 6010 destination is an AS boundary router, it may also be 6011 necessary to re-examine all the AS-external-LSAs. 6013 AS-external-LSAs 6014 The best route to the destination described by the AS- 6015 external-LSA must be recalculated (see Section 16.6). 6017 Also, any old instance of the LSA must be removed from the 6018 database when the new LSA is installed. This old instance must 6019 also be removed from all neighbors' Link state retransmission 6020 lists (see Section 10). 6022 13.3. Next step in the flooding procedure 6024 When a new (and more recent) LSA has been received, it must be 6025 flooded out some set of the router's interfaces. This section 6026 describes the second part of flooding procedure (the first part 6027 being the processing that occurred in Section 13), namely, 6028 selecting the outgoing interfaces and adding the LSA to the 6029 appropriate neighbors' Link state retransmission lists. Also 6030 included in this part of the flooding procedure is the 6031 maintenance of the neighbors' Link state request lists. 6033 This section is equally applicable to the flooding of an LSA 6034 that the router itself has just originated (see Section 12.4). 6035 For these LSAs, this section provides the entirety of the 6036 flooding procedure (i.e., the processing of Section 13 is not 6037 performed, since, for example, the LSA has not been received 6038 from a neighbor and therefore does not need to be acknowledged). 6040 Depending upon the LSA's LS type, the LSA can be flooded out 6041 only certain interfaces. These interfaces, defined by the 6042 following, are called the eligible interfaces: 6044 AS-external-LSAs (LS Type = 5) 6045 AS-external-LSAs are flooded throughout the entire AS, with 6046 the exception of stub areas (see Section 3.6). The eligible 6047 interfaces are all the router's interfaces, excluding 6048 virtual links and those interfaces attaching to stub areas. 6050 All other LS types 6051 All other types are specific to a single area (Area A). The 6052 eligible interfaces are all those interfaces attaching to 6053 the Area A. If Area A is the backbone, this includes all 6054 the virtual links. 6056 Link state databases must remain synchronized over all 6057 adjacencies associated with the above eligible interfaces. This 6058 is accomplished by executing the following steps on each 6059 eligible interface. It should be noted that this procedure may 6060 decide not to flood an LSA out a particular interface, if there 6061 is a high probability that the attached neighbors have already 6062 received the LSA. However, in these cases the flooding 6063 procedure must be absolutely sure that the neighbors eventually 6064 do receive the LSA, so the LSA is still added to each 6065 adjacency's Link state retransmission list. For each eligible 6066 interface: 6068 (1) Each of the neighbors attached to this interface are 6069 examined, to determine whether they must receive the new 6070 LSA. The following steps are executed for each neighbor: 6072 (a) If the neighbor is in a lesser state than Exchange, it 6073 does not participate in flooding, and the next neighbor 6074 should be examined. 6076 (b) Else, if the adjacency is not yet full (neighbor state 6077 is Exchange or Loading), examine the Link state request 6078 list associated with this adjacency. If there is an 6079 instance of the new LSA on the list, it indicates that 6080 the neighboring router has an instance of the LSA 6081 already. Compare the new LSA to the neighbor's copy: 6083 o If the new LSA is less recent, then examine the next 6084 neighbor. 6086 o If the two copies are the same instance, then delete 6087 the LSA from the Link state request list, and 6088 examine the next neighbor.[20] 6090 o Else, the new LSA is more recent. Delete the LSA 6091 from the Link state request list. 6093 (c) If the new LSA was received from this neighbor, examine 6094 the next neighbor. 6096 (d) At this point we are not positive that the neighbor has 6097 an up-to-date instance of this new LSA. Add the new LSA 6098 to the Link state retransmission list for the adjacency. 6099 This ensures that the flooding procedure is reliable; 6100 the LSA will be retransmitted at intervals until an 6101 acknowledgment is seen from the neighbor. 6103 (2) The router must now decide whether to flood the new LSA out 6104 this interface. If in the previous step, the LSA was NOT 6105 added to any of the Link state retransmission lists, there 6106 is no need to flood the LSA out the interface and the next 6107 interface should be examined. 6109 (3) If the new LSA was received on this interface, and it was 6110 received from either the Designated Router or the Backup 6111 Designated Router, chances are that all the neighbors have 6112 received the LSA already. Therefore, examine the next 6113 interface. 6115 (4) If the new LSA was received on this interface, and the 6116 interface state is Backup (i.e., the router itself is the 6117 Backup Designated Router), examine the next interface. The 6118 Designated Router will do the flooding on this interface. 6119 However, if the Designated Router fails the router (i.e., 6120 the Backup Designated Router) will end up retransmitting the 6121 updates. 6123 (5) If this step is reached, the LSA must be flooded out the 6124 interface. Send a Link State Update packet (including the 6125 new LSA as contents) out the interface. The LSA's LS age 6126 must be incremented by InfTransDelay (which must be > 0) 6127 when it is copied into the outgoing Link State Update packet 6128 (until the LS age field reaches the maximum value of 6129 MaxAge). 6131 On broadcast networks, the Link State Update packets are 6132 multicast. The destination IP address specified for the 6133 Link State Update Packet depends on the state of the 6134 interface. If the interface state is DR or Backup, the 6135 address AllSPFRouters should be used. Otherwise, the 6136 address AllDRouters should be used. 6138 On non-broadcast networks, separate Link State Update 6139 packets must be sent, as unicasts, to each adjacent neighbor 6140 (i.e., those in state Exchange or greater). The destination 6141 IP addresses for these packets are the neighbors' IP 6142 addresses. 6144 13.4. Receiving self-originated LSAs 6146 It is a common occurrence for a router to receive self- 6147 originated LSAs via the flooding procedure. A self-originated 6148 LSA is detected when either 1) the LSA's Advertising Router is 6149 equal to the router's own Router ID or 2) the LSA is a network- 6150 LSA and its Link State ID is equal to one of the router's own IP 6151 interface addresses. 6153 However, if the received self-originated LSA is newer than the 6154 last instance that the router actually originated, the router 6155 must take special action. The reception of such an LSA 6156 indicates that there are LSAs in the routing domain that were 6157 originated by the router before the last time it was restarted. 6158 In most cases, the router must then advance the LSA's LS 6159 sequence number one past the received LS sequence number, and 6160 originate a new instance of the LSA. 6162 It may be the case the router no longer wishes to originate the 6163 received LSA. Possible examples include: 1) the LSA is a 6164 summary-LSA or AS-external-LSA and the router no longer has an 6165 (advertisable) route to the destination, 2) the LSA is a 6166 network-LSA but the router is no longer Designated Router for 6167 the network or 3) the LSA is a network-LSA whose Link State ID 6168 is one of the router's own IP interface addresses but whose 6169 Advertising Router is not equal to the router's own Router ID 6170 (this latter case should be rare, and it indicates that the 6171 router's Router ID has changed since originating the LSA). In 6172 all these cases, instead of updating the LSA, the LSA should be 6173 flushed from the routing domain by incrementing the received 6174 LSA's LS age to MaxAge and reflooding (see Section 14.1). 6176 13.5. Sending Link State Acknowledgment packets 6178 Each newly received LSA must be acknowledged. This is usually 6179 done by sending Link State Acknowledgment packets. However, 6180 acknowledgments can also be accomplished implicitly by sending 6181 Link State Update packets (see step 7a of Section 13). 6183 Many acknowledgments may be grouped together into a single Link 6184 State Acknowledgment packet. Such a packet is sent back out the 6185 interface which received the LSAs. The packet can be sent in 6186 one of two ways: delayed and sent on an interval timer, or sent 6187 directly (as a unicast) to a particular neighbor. The 6188 particular acknowledgment strategy used depends on the 6189 circumstances surrounding the receipt of the LSA. 6191 Sending delayed acknowledgments accomplishes several things: 1) 6192 it facilitates the packaging of multiple acknowledgments in a 6193 single Link State Acknowledgment packet, 2) it enables a single 6194 Link State Acknowledgment packet to indicate acknowledgments to 6195 several neighbors at once (through multicasting) and 3) it 6196 randomizes the Link State Acknowledgment packets sent by the 6197 various routers attached to a common network. The fixed 6198 interval between a router's delayed transmissions must be short 6199 (less than RxmtInterval) or needless retransmissions will ensue. 6201 Direct acknowledgments are sent to a particular neighbor in 6202 response to the receipt of duplicate LSAs. These 6203 acknowledgments are sent as unicasts, and are sent immediately 6204 when the duplicate is received. 6206 The precise procedure for sending Link State Acknowledgment 6207 packets is described in Table 19. The circumstances surrounding 6208 the receipt of the LSA are listed in the left column. The 6209 acknowledgment action then taken is listed in one of the two 6210 right columns. This action depends on the state of the 6211 concerned interface; interfaces in state Backup behave 6212 differently from interfaces in all other states. Delayed 6213 acknowledgments must be delivered to all adjacent routers 6214 associated with the interface. On broadcast networks, this is 6215 accomplished by sending the delayed Link State Acknowledgment 6216 packets as multicasts. The Destination IP address used depends 6217 on the state of the interface. If the interface state is DR or 6218 Backup, the destination AllSPFRouters is used. In all other 6219 states, the destination AllDRouters is used. On non-broadcast 6220 networks, delayed Link State Acknowledgment packets must be 6221 unicast separately over each adjacency (i.e., neighbor whose 6222 state is >= Exchange). 6224 The reasoning behind sending the above packets as multicasts is 6225 best explained by an example. Consider the network 6226 configuration depicted in Figure 15. Suppose RT4 has been 6227 elected as Designated Router, and RT3 as Backup Designated 6228 Router for the network N3. When Router RT4 floods a new LSA to 6229 Network N3, it is received by routers RT1, RT2, and RT3. These 6230 routers will not flood the LSA back onto net N3, but they still 6231 must ensure that their link-state databases remain synchronized 6232 with their adjacent neighbors. So RT1, RT2, and RT4 are waiting 6233 to see an acknowledgment from RT3. Likewise, RT4 and RT3 are 6234 both waiting to see acknowledgments from RT1 and RT2. This is 6235 best achieved by sending the acknowledgments as multicasts. 6237 The reason that the acknowledgment logic for Backup DRs is 6238 slightly different is because they perform differently during 6239 the flooding of LSAs (see Section 13.3, step 4). 6241 13.6. Retransmitting LSAs 6243 LSAs flooded out an adjacency are placed on the adjacency's Link 6244 state retransmission list. In order to ensure that flooding is 6245 reliable, these LSAs are retransmitted until they are 6246 acknowledged. The length of time between retransmissions is a 6247 Action taken in state 6248 Circumstances Backup All other states 6249 _______________________________________________________________ 6250 LSA has No acknowledgment No acknowledgment 6251 been flooded back sent. sent. 6252 out receiving in- 6253 terface (see Sec- 6254 tion 13, step 5b). 6255 _______________________________________________________________ 6256 LSA is Delayed acknowledg- Delayed ack- 6257 more recent than ment sent if adver- nowledgment sent. 6258 database copy, but tisement received 6259 was not flooded from Designated 6260 back out receiving Router, otherwise 6261 interface do nothing 6262 _______________________________________________________________ 6263 LSA is a Delayed acknowledg- No acknowledgment 6264 duplicate, and was ment sent if adver- sent. 6265 treated as an im- tisement received 6266 plied acknowledg- from Designated 6267 ment (see Section Router, otherwise 6268 13, step 7a). do nothing 6269 _______________________________________________________________ 6270 LSA is a Direct acknowledg- Direct acknowledg- 6271 duplicate, and was ment sent. ment sent. 6272 not treated as an 6273 implied ack- 6274 nowledgment. 6275 _______________________________________________________________ 6276 LSA's LS Direct acknowledg- Direct acknowledg- 6277 age is equal to ment sent. ment sent. 6278 MaxAge, and there is 6279 no current instance 6280 of the LSA 6281 in the link state 6282 database (see 6283 Section 13, step 4). 6285 Table 19: Sending link state acknowledgements. 6287 configurable per-interface value, RxmtInterval. If this is set 6288 too low for an interface, needless retransmissions will ensue. 6289 If the value is set too high, the speed of the flooding, in the 6290 face of lost packets, may be affected. 6292 Several retransmitted LSAs may fit into a single Link State 6293 Update packet. When LSAs are to be retransmitted, only the 6294 number fitting in a single Link State Update packet should be 6295 sent. Another packet of retransmissions can be sent whenever 6296 some of the LSAs are acknowledged, or on the next firing of the 6297 retransmission timer. 6299 Link State Update Packets carrying retransmissions are always 6300 sent as unicasts (directly to the physical address of the 6301 neighbor). They are never sent as multicasts. Each LSA's LS 6302 age must be incremented by InfTransDelay (which must be > 0) 6303 when it is copied into the outgoing Link State Update packet 6304 (until the LS age field reaches the maximum value of MaxAge). 6306 If an adjacent router goes down, retransmissions may occur until 6307 the adjacency is destroyed by OSPF's Hello Protocol. When the 6308 adjacency is destroyed, the Link state retransmission list is 6309 cleared. 6311 13.7. Receiving link state acknowledgments 6313 Many consistency checks have been made on a received Link State 6314 Acknowledgment packet before it is handed to the flooding 6315 procedure. In particular, it has been associated with a 6316 particular neighbor. If this neighbor is in a lesser state than 6317 Exchange, the Link State Acknowledgment packet is discarded. 6319 Otherwise, for each acknowledgment in the Link State 6320 Acknowledgment packet, the following steps are performed: 6322 o Does the LSA acknowledged have an instance on the Link state 6323 retransmission list for the neighbor? If not, examine the 6324 next acknowledgment. Otherwise: 6326 o If the acknowledgment is for the same instance that is 6327 contained on the list, remove the item from the list and 6328 examine the next acknowledgment. Otherwise: 6330 o Log the questionable acknowledgment, and examine the next 6331 one. 6333 14. Aging The Link State Database 6335 Each LSA has an LS age field. The LS age is expressed in seconds. 6336 An LSA's LS age field is incremented while it is contained in a 6337 router's database. Also, when copied into a Link State Update 6338 Packet for flooding out a particular interface, the LSA's LS age is 6339 incremented by InfTransDelay. 6341 An LSA's LS age is never incremented past the value MaxAge. LSAs 6342 having age MaxAge are not used in the routing table calculation. As 6343 a router ages its link state database, an LSA's LS age may reach 6344 MaxAge.[21] At this time, the router must attempt to flush the LSA 6345 from the routing domain. This is done simply by reflooding the 6346 MaxAge LSA just as if it was a newly originated LSA (see Section 6347 13.3). 6349 When creating a Database summary list for a newly forming adjacency, 6350 any MaxAge LSAs present in the link state database are added to the 6351 neighbor's Link state retransmission list instead of the neighbor's 6352 Database summary list. See Section 10.3 for more details. 6354 A MaxAge LSA must be removed immediately from the router's link 6355 state database as soon as both a) it is no longer contained on any 6356 neighbor Link state retransmission lists and b) none of the router's 6357 neighbors are in states Exchange or Loading. 6359 When, in the process of aging the link state database, an LSA's LS 6360 age hits a multiple of CheckAge, its LS checksum should be verified. 6361 If the LS checksum is incorrect, a program or memory error has been 6362 detected, and at the very least the router itself should be 6363 restarted. 6365 14.1. Premature aging of LSAs 6367 An LSA can be flushed from the routing domain by setting its LS 6368 age to MaxAge and reflooding the LSA. This procedure follows 6369 the same course as flushing an LSA whose LS age has naturally 6370 reached the value MaxAge (see Section 14). In particular, the 6371 MaxAge LSA is removed from the router's link state database as 6372 soon as a) it is no longer contained on any neighbor Link state 6373 retransmission lists and b) none of the router's neighbors are 6374 in states Exchange or Loading. We call the setting of an LSA's 6375 LS age to MaxAge "premature aging". 6377 Premature aging is used when it is time for a self-originated 6378 LSA's sequence number field to wrap. At this point, the current 6379 LSA instance (having LS sequence number MaxSequenceNumber) must 6380 be prematurely aged and flushed from the routing domain before a 6381 new instance with sequence number equal to InitialSequenceNumber 6382 can be originated. See Section 12.1.6 for more information. 6384 Premature aging can also be used when, for example, one of the 6385 router's previously advertised external routes is no longer 6386 reachable. In this circumstance, the router can flush its AS- 6387 external-LSA from the routing domain via premature aging. This 6388 procedure is preferable to the alternative, which is to 6389 originate a new LSA for the destination specifying a metric of 6390 LSInfinity. Premature aging is also be used when unexpectedly 6391 receiving self-originated LSAs during the flooding procedure 6392 (see Section 13.4). 6394 A router may only prematurely age its own self-originated LSAs. 6395 The router may not prematurely age LSAs that have been 6396 originated by other routers. An LSA is considered self- 6397 originated when either 1) the LSA's Advertising Router is equal 6398 to the router's own Router ID or 2) the LSA is a network-LSA and 6399 its Link State ID is equal to one of the router's own IP 6400 interface addresses. 6402 15. Virtual Links 6404 The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, 6405 or some areas of the Autonomous System will become unreachable. To 6406 establish/maintain connectivity of the backbone, virtual links can 6407 be configured through non-backbone areas. Virtual links serve to 6408 connect physically separate components of the backbone. The two 6409 endpoints of a virtual link are area border routers. The virtual 6410 link must be configured in both routers. The configuration 6411 information in each router consists of the other virtual endpoint 6412 (the other area border router), and the non-backbone area the two 6413 routers have in common (called the Transit area). Virtual links 6414 cannot be configured through stub areas (see Section 3.6). 6416 The virtual link is treated as if it were an unnumbered point-to- 6417 point network belonging to the backbone and joining the two area 6418 border routers. An attempt is made to establish an adjacency over 6419 the virtual link. When this adjacency is established, the virtual 6420 link will be included in backbone router-LSAs, and OSPF packets 6421 pertaining to the backbone area will flow over the adjacency. Such 6422 an adjacency has been referred to in this document as a "virtual 6423 adjacency". 6425 In each endpoint router, the cost and viability of the virtual link 6426 is discovered by examining the routing table entry for the other 6427 endpoint router. (The entry's associated area must be the 6428 configured Transit area). Actually, there may be a separate routing 6429 table entry for each Type of Service. These are called the virtual 6430 link's corresponding routing table entries. The InterfaceUp event 6431 occurs for a virtual link when its corresponding TOS 0 routing table 6432 entry becomes reachable. Conversely, the InterfaceDown event occurs 6433 when its TOS 0 routing table entry becomes unreachable.[22] In other 6434 words, the virtual link's viability is determined by the existence 6435 of an intra-area path, through the Transit area, between the two 6436 endpoints. Note that a virtual link whose underlying path has cost 6437 greater than hexadecimal 0xffff (the maximum size of an interface 6438 cost in a router-LSA) should be considered inoperational (i.e., 6439 treated the same as if the path did not exist). 6441 The other details concerning virtual links are as follows: 6443 o AS-external-LSAs are NEVER flooded over virtual adjacencies. 6444 This would be duplication of effort, since the same AS- 6445 external-LSAs are already flooded throughout the virtual link's 6446 Transit area. For this same reason, AS-external-LSAs are not 6447 summarized over virtual adjacencies during the Database Exchange 6448 process. 6450 o The cost of a virtual link is NOT configured. It is defined to 6451 be the cost of the intra-area path between the two defining area 6452 border routers. This cost appears in the virtual link's 6453 corresponding routing table entry. When the cost of a virtual 6454 link changes, a new router-LSA should be originated for the 6455 backbone area. 6457 o Just as the virtual link's cost and viability are determined by 6458 the routing table build process (through construction of the 6459 routing table entry for the other endpoint), so are the IP 6460 interface address for the virtual interface and the virtual 6461 neighbor's IP address. These are used when sending OSPF 6462 protocol packets over the virtual link. Note that when one (or 6463 both) of the virtual link endpoints connect to the Transit area 6464 via an unnumbered point-to-point link, it may be impossible to 6465 calculate either the virtual interface's IP address and/or the 6466 virtual neighbor's IP address, thereby causing the virtual link 6467 to fail. 6469 o In each endpoint's router-LSA for the backbone, the virtual link 6470 is represented as a Type 4 link whose Link ID is set to the 6471 virtual neighbor's OSPF Router ID and whose Link Data is set to 6472 the virtual interface's IP address. See Section 12.4.1 for more 6473 information. Note that it may be the case that there is a TOS 0 6474 path, but no non-zero TOS paths, between the two endpoint 6475 routers. In this case, both routers must revert to being non- 6476 TOS-capable, clearing the T-bit in the Options field of their 6477 backbone router-LSAs. 6479 o A non-backbone area can carry transit data traffic (i.e., is 6480 considered a "transit area") if and only if it serves as the 6481 Transit area for one or more fully adjacent virtual links (see 6482 TransitCapability in Sections 6 and 16.1). Such an area requires 6483 special treatment when summarizing backbone networks into it 6484 (see Section 12.4.3), and during the routing calculation (see 6485 Section 16.3). 6487 o The time between link state retransmissions, RxmtInterval, is 6488 configured for a virtual link. This should be well over the 6489 expected round-trip delay between the two routers. This may be 6490 hard to estimate for a virtual link; it is better to err on the 6491 side of making it too large. 6493 16. Calculation of the routing table 6495 This section details the OSPF routing table calculation. Using its 6496 attached areas' link state databases as input, a router runs the 6497 following algorithm, building its routing table step by step. At 6498 each step, the router must access individual pieces of the link 6499 state databases (e.g., a router-LSA originated by a certain router). 6500 This access is performed by the lookup function discussed in Section 6501 12.2. The lookup process may return an LSA whose LS age is equal to 6502 MaxAge. Such an LSA should not be used in the routing table 6503 calculation, and is treated just as if the lookup process had 6504 failed. 6506 The OSPF routing table's organization is explained in Section 11. 6507 Two examples of the routing table build process are presented in 6508 Sections 11.2 and 11.3. This process can be broken into the 6509 following steps: 6511 (1) The present routing table is invalidated. The routing table is 6512 built again from scratch. The old routing table is saved so 6513 that changes in routing table entries can be identified. 6515 (2) The intra-area routes are calculated by building the shortest- 6516 path tree for each attached area. In particular, all routing 6517 table entries whose Destination Type is "area border router" are 6518 calculated in this step. This step is described in two parts. 6519 At first the tree is constructed by only considering those links 6520 between routers and transit networks. Then the stub networks 6521 are incorporated into the tree. During the area's shortest-path 6522 tree calculation, the area's TransitCapability is also 6523 calculated for later use in Step 4. 6525 (3) The inter-area routes are calculated, through examination of 6526 summary-LSAs. If the router is attached to multiple areas 6527 (i.e., it is an area border router), only backbone summary-LSAs 6528 are examined. 6530 (4) In area border routers connecting to one or more transit areas 6531 (i.e, non-backbone areas whose TransitCapability is found to be 6532 TRUE), the transit areas' summary-LSAs are examined to see 6533 whether better paths exist using the transit areas than were 6534 found in Steps 2-3 above. 6536 (5) Routes to external destinations are calculated, through 6537 examination of AS-external-LSAs. The locations of the AS 6538 boundary routers (which originate the AS-external-LSAs) have 6539 been determined in steps 2-4. 6541 Steps 2-5 are explained in further detail below. The explanations 6542 describe the calculations for TOS 0 only. It may also be necessary 6543 to perform each step (separately) for each of the non-zero TOS 6544 values.[23] For more information concerning the building of non-zero 6545 TOS routes see Section 16.9. 6547 Changes made to routing table entries as a result of these 6548 calculations can cause the OSPF protocol to take further actions. 6549 For example, a change to an intra-area route will cause an area 6550 border router to originate new summary-LSAs (see Section 12.4). See 6551 Section 16.7 for a complete list of the OSPF protocol actions 6552 resulting from routing table changes. 6554 16.1. Calculating the shortest-path tree for an area 6556 This calculation yields the set of intra-area routes associated 6557 with an area (called hereafter Area A). A router calculates the 6558 shortest-path tree using itself as the root.[24] The formation 6559 of the shortest path tree is done here in two stages. In the 6560 first stage, only links between routers and transit networks are 6561 considered. Using the Dijkstra algorithm, a tree is formed from 6562 this subset of the link state database. In the second stage, 6563 leaves are added to the tree by considering the links to stub 6564 networks. 6566 The procedure will be explained using the graph terminology that 6567 was introduced in Section 2. The area's link state database is 6568 represented as a directed graph. The graph's vertices are 6569 routers, transit networks and stub networks. The first stage of 6570 the procedure concerns only the transit vertices (routers and 6571 transit networks) and their connecting links. Throughout the 6572 shortest path calculation, the following data is also associated 6573 with each transit vertex: 6575 Vertex (node) ID 6576 A 32-bit number uniquely identifying the vertex. For router 6577 vertices this is the router's OSPF Router ID. For network 6578 vertices, this is the IP address of the network's Designated 6579 Router. 6581 An LSA 6582 Each transit vertex has an associated LSA. For router 6583 vertices, this is a router-LSA. For transit networks, this 6584 is a network-LSA (which is actually originated by the 6585 network's Designated Router). In any case, the LSA's Link 6586 State ID is always equal to the above Vertex ID. 6588 List of next hops 6589 The list of next hops for the current set of shortest paths 6590 from the root to this vertex. There can be multiple 6591 shortest paths due to the equal-cost multipath capability. 6592 Each next hop indicates the outgoing router interface to use 6593 when forwarding traffic to the destination. On broadcast, 6594 Point-to-MultiPoint and NBMA networks, the next hop also 6595 includes the IP address of the next router (if any) in the 6596 path towards the destination. 6598 Distance from root 6599 The link state cost of the current set of shortest paths 6600 from the root to the vertex. The link state cost of a path 6601 is calculated as the sum of the costs of the path's 6602 constituent links (as advertised in router-LSAs and 6603 network-LSAs). One path is said to be "shorter" than 6604 another if it has a smaller link state cost. 6606 The first stage of the procedure (i.e., the Dijkstra algorithm) 6607 can now be summarized as follows. At each iteration of the 6608 algorithm, there is a list of candidate vertices. Paths from 6609 the root to these vertices have been found, but not necessarily 6610 the shortest ones. However, the paths to the candidate vertex 6611 that is closest to the root are guaranteed to be shortest; this 6612 vertex is added to the shortest-path tree, removed from the 6613 candidate list, and its adjacent vertices are examined for 6614 possible addition to/modification of the candidate list. The 6615 algorithm then iterates again. It terminates when the candidate 6616 list becomes empty. 6618 The following steps describe the algorithm in detail. Remember 6619 that we are computing the shortest path tree for Area A. All 6620 references to link state database lookup below are from Area A's 6621 database. 6623 (1) Initialize the algorithm's data structures. Clear the list 6624 of candidate vertices. Initialize the shortest-path tree to 6625 only the root (which is the router doing the calculation). 6626 Set Area A's TransitCapability to FALSE. 6628 (2) Call the vertex just added to the tree vertex V. Examine 6629 the LSA associated with vertex V. This is a lookup in the 6630 Area A's link state database based on the Vertex ID. If 6631 this is a router-LSA, and bit V of the router-LSA (see 6632 Section A.4.2) is set, set Area A's TransitCapability to 6633 TRUE. In any case, each link described by the LSA gives the 6634 cost to an adjacent vertex. For each described link, (say 6635 it joins vertex V to vertex W): 6637 (a) If this is a link to a stub network, examine the next 6638 link in V's LSA. Links to stub networks will be 6639 considered in the second stage of the shortest path 6640 calculation. 6642 (b) Otherwise, W is a transit vertex (router or transit 6643 network). Look up the vertex W's LSA (router-LSA or 6644 network-LSA) in Area A's link state database. If the 6645 LSA does not exist, or its LS age is equal to MaxAge, or 6646 it does not have a link back to vertex V, examine the 6647 next link in V's LSA.[25] 6649 (c) If vertex W is already on the shortest-path tree, 6650 examine the next link in the LSA. 6652 (d) Calculate the link state cost D of the resulting path 6653 from the root to vertex W. D is equal to the sum of the 6654 link state cost of the (already calculated) shortest 6655 path to vertex V and the advertised cost of the link 6656 between vertices V and W. If D is: 6658 o Greater than the value that already appears for 6659 vertex W on the candidate list, then examine the 6660 next link. 6662 o Equal to the value that appears for vertex W on the 6663 candidate list, calculate the set of next hops that 6664 result from using the advertised link. Input to 6665 this calculation is the destination (W), and its 6666 parent (V). This calculation is shown in Section 6667 16.1.1. This set of hops should be added to the 6668 next hop values that appear for W on the candidate 6669 list. 6671 o Less than the value that appears for vertex W on the 6672 candidate list, or if W does not yet appear on the 6673 candidate list, then set the entry for W on the 6674 candidate list to indicate a distance of D from the 6675 root. Also calculate the list of next hops that 6676 result from using the advertised link, setting the 6677 next hop values for W accordingly. The next hop 6678 calculation is described in Section 16.1.1; it takes 6679 as input the destination (W) and its parent (V). 6681 (3) If at this step the candidate list is empty, the shortest- 6682 path tree (of transit vertices) has been completely built 6683 and this stage of the procedure terminates. Otherwise, 6684 choose the vertex belonging to the candidate list that is 6685 closest to the root, and add it to the shortest-path tree 6686 (removing it from the candidate list in the process). Note 6687 that when there is a choice of vertices closest to the root, 6688 network vertices must be chosen before router vertices in 6689 order to necessarily find all equal-cost paths. This is 6690 consistent with the tie-breakers that were introduced in the 6691 modified Dijkstra algorithm used by OSPF's Multicast routing 6692 extensions (MOSPF). 6694 (4) Possibly modify the routing table. For those routing table 6695 entries modified, the associated area will be set to Area A, 6696 the path type will be set to intra-area, and the cost will 6697 be set to the newly discovered shortest path's calculated 6698 distance. 6700 If the newly added vertex is an area border router (call it 6701 ABR), a routing table entry is added whose destination type 6702 is "area border router". The Options field found in the 6703 associated router-LSA is copied into the routing table 6704 entry's Optional capabilities field. If in addition ABR is 6705 the endpoint of one of the calculating router's configured 6706 virtual links that uses Area A as its Transit area: the 6707 virtual link is declared up, the IP address of the virtual 6708 interface is set to the IP address of the outgoing interface 6709 calculated above for ABR, and the virtual neighbor's IP 6710 address is set to the ABR interface address (contained in 6711 ABR's router-LSA) that points back to the root of the 6712 shortest-path tree; equivalently, this is the interface that 6713 points back to ABR's parent vertex on the shortest-path tree 6714 (similar to the calculation in Section 16.1.1). 6716 If the newly added vertex is an AS boundary router, the 6717 routing table entry of type "AS boundary router" for the 6718 destination is located. Since routers can belong to more 6719 than one area, it is possible that several sets of intra- 6720 area paths exist to the AS boundary router, each set using a 6721 different area. However, the AS boundary router's routing 6722 table entry must indicate a set of paths which utilize a 6723 single area. The area leading to the routing table entry is 6724 selected as follows: The area providing the shortest path 6725 is always chosen; if more than one area provides paths with 6726 the same minimum cost, the area with the largest OSPF Area 6727 ID (when considered as an unsigned 32-bit integer) is 6728 chosen. Note that whenever an AS boundary router's routing 6729 table entry is added/modified, the Options found in the 6730 associated router-LSA is copied into the routing table 6731 entry's Optional capabilities field. 6733 If the newly added vertex is a transit network, the routing 6734 table entry for the network is located. The entry's 6735 Destination ID is the IP network number, which can be 6736 obtained by masking the Vertex ID (Link State ID) with its 6737 associated subnet mask (found in the body of the associated 6738 network-LSA). If the routing table entry already exists 6739 (i.e., there is already an intra-area route to the 6740 destination installed in the routing table), multiple 6741 vertices have mapped to the same IP network. For example, 6742 this can occur when a new Designated Router is being 6743 established. In this case, the current routing table entry 6744 should be overwritten if and only if the newly found path is 6745 just as short and the current routing table entry's Link 6746 State Origin has a smaller Link State ID than the newly 6747 added vertex' LSA. 6749 If there is no routing table entry for the network (the 6750 usual case), a routing table entry for the IP network should 6751 be added. The routing table entry's Link State Origin 6752 should be set to the newly added vertex' LSA. 6754 (5) Iterate the algorithm by returning to Step 2. 6756 The stub networks are added to the tree in the procedure's 6757 second stage. In this stage, all router vertices are again 6758 examined. Those that have been determined to be unreachable in 6759 the above first phase are discarded. For each reachable router 6760 vertex (call it V), the associated router-LSA is found in the 6761 link state database. Each stub network link appearing in the 6762 LSA is then examined, and the following steps are executed: 6764 (1) Calculate the distance D of stub network from the root. D 6765 is equal to the distance from the root to the router vertex 6766 (calculated in stage 1), plus the stub network link's 6767 advertised cost. Compare this distance to the current best 6768 cost to the stub network. This is done by looking up the 6769 stub network's current routing table entry. If the 6770 calculated distance D is larger, go on to examine the next 6771 stub network link in the LSA. 6773 (2) If this step is reached, the stub network's routing table 6774 entry must be updated. Calculate the set of next hops that 6775 would result from using the stub network link. This 6776 calculation is shown in Section 16.1.1; input to this 6777 calculation is the destination (the stub network) and the 6778 parent vertex (the router vertex). If the distance D is the 6779 same as the current routing table cost, simply add this set 6780 of next hops to the routing table entry's list of next hops. 6781 In this case, the routing table already has a Link State 6782 Origin. If this Link State Origin is a router-LSA whose 6783 Link State ID is smaller than V's Router ID, reset the Link 6784 State Origin to V's router-LSA. 6786 Otherwise D is smaller than the routing table cost. 6787 Overwrite the current routing table entry by setting the 6788 routing table entry's cost to D, and by setting the entry's 6789 list of next hops to the newly calculated set. Set the 6790 routing table entry's Link State Origin to V's router-LSA. 6791 Then go on to examine the next stub network link. 6793 For all routing table entries added/modified in the second 6794 stage, the associated area will be set to Area A and the path 6795 type will be set to intra-area. When the list of reachable 6796 router-LSAs is exhausted, the second stage is completed. At 6797 this time, all intra-area routes associated with Area A have 6798 been determined. 6800 The specification does not require that the above two stage 6801 method be used to calculate the shortest path tree. However, if 6802 another algorithm is used, an identical tree must be produced. 6803 For this reason, it is important to note that links between 6804 transit vertices must be bidirectional in order to be included 6805 in the above tree. It should also be mentioned that more 6806 efficient algorithms exist for calculating the tree; for 6807 example, the incremental SPF algorithm described in [Ref1]. 6809 16.1.1. The next hop calculation 6811 This section explains how to calculate the current set of 6812 next hops to use for a destination. Each next hop consists 6813 of the outgoing interface to use in forwarding packets to 6814 the destination together with the IP address of the next hop 6815 router (if any). The next hop calculation is invoked each 6816 time a shorter path to the destination is discovered. This 6817 can happen in either stage of the shortest-path tree 6818 calculation (see Section 16.1). In stage 1 of the 6819 shortest-path tree calculation a shorter path is found as 6820 the destination is added to the candidate list, or when the 6821 destination's entry on the candidate list is modified (Step 6822 2d of Stage 1). In stage 2 a shorter path is discovered 6823 each time the destination's routing table entry is modified 6824 (Step 2 of Stage 2). 6826 The set of next hops to use for the destination may be 6827 recalculated several times during the shortest-path tree 6828 calculation, as shorter and shorter paths are discovered. 6829 In the end, the destination's routing table entry will 6830 always reflect the next hops resulting from the absolute 6831 shortest path(s). 6833 Input to the next hop calculation is a) the destination and 6834 b) its parent in the current shortest path between the root 6835 (the calculating router) and the destination. The parent is 6836 always a transit vertex (i.e., always a router or a transit 6837 network). 6839 If there is at least one intervening router in the current 6840 shortest path between the destination and the root, the 6841 destination simply inherits the set of next hops from the 6842 parent. Otherwise, there are two cases. In the first case, 6843 the parent vertex is the root (the calculating router 6844 itself). This means that the destination is either a 6845 directly connected network or directly connected router. 6846 The outgoing interface in this case is simply the OSPF 6847 interface connecting to the destination network/router. If 6848 the destination is a router which connects to the 6849 calculating router via a Point-to-MultiPoint network, the 6850 destination's next hop IP address(es) can be determined by 6851 examining the destination's router-LSA: each link pointing 6852 back to the calculating router and having a Link Data field 6853 belonging to the Point-to-MultiPoint network provides an IP 6854 address of the next hop router. If the destination is a 6855 directly connected network, or a router which connects to 6856 the calculating router via a point-to-point interface, no 6857 next hop IP address is required. If the destination is a 6858 router connected to the calculating router via a virtual 6859 link, the setting of the next hop should be deferred until 6860 the calculation in Section 16.3. 6862 In the second case, the parent vertex is a network that 6863 directly connects the calculating router to the destination 6864 router. The list of next hops is then determined by 6865 examining the destination's router-LSA. For each link in 6866 the router-LSA that points back to the parent network, the 6867 link's Link Data field provides the IP address of a next hop 6868 router. The outgoing interface to use can then be derived 6869 from the next hop IP address (or it can be inherited from 6870 the parent network). 6872 16.2. Calculating the inter-area routes 6874 The inter-area routes are calculated by examining summary-LSAs. 6875 If the router has active attachments to multiple areas, only 6876 backbone summary-LSAs are examined. Routers attached to a 6877 single area examine that area's summary-LSAs. In either case, 6878 the summary-LSAs examined below are all part of a single area's 6879 link state database (call it Area A). 6881 Summary-LSAs are originated by the area border routers. Each 6882 summary-LSA in Area A is considered in turn. Remember that the 6883 destination described by a summary-LSA is either a network (Type 6884 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). 6885 For each summary-LSA: 6887 (1) If the cost specified by the LSA is LSInfinity, or if the 6888 LSA's LS age is equal to MaxAge, then examine the the next 6889 LSA. 6891 (2) If the LSA was originated by the calculating router itself, 6892 examine the next LSA. 6894 (3) If it is a Type 3 summary-LSA, and the collection of 6895 destinations described by the summary-LSA equals one of the 6896 router's configured area address ranges (see Section 3.5), 6897 and the particular area address range is active, then the 6898 summary-LSA should be ignored. "Active" means that there 6899 are one or more reachable (by intra-area paths) networks 6900 contained in the area range. 6902 (4) Else, call the destination described by the LSA N (for Type 6903 3 summary-LSAs, N's address is obtained by masking the LSA's 6904 Link State ID with the network/subnet mask contained in the 6905 body of the LSA), and the area border originating the LSA 6906 BR. Look up the routing table entry for BR having Area A as 6907 its associated area. If no such entry exists for router BR 6908 (i.e., BR is unreachable in Area A), do nothing with this 6909 LSA and consider the next in the list. Else, this LSA 6910 describes an inter-area path to destination N, whose cost is 6911 the distance to BR plus the cost specified in the LSA. Call 6912 the cost of this inter-area path IAC. 6914 (5) Next, look up the routing table entry for the destination N. 6915 (The entry's Destination Type is either Network or AS 6916 boundary router.) If no entry exists for N or if the 6917 entry's path type is "type 1 external" or "type 2 external", 6918 then install the inter-area path to N, with associated area 6919 Area A, cost IAC, next hop equal to the list of next hops to 6920 router BR, and Advertising router equal to BR. 6922 (6) Else, if the paths present in the table are intra-area 6923 paths, do nothing with the LSA (intra-area paths are always 6924 preferred). 6926 (7) Else, the paths present in the routing table are also 6927 inter-area paths. Install the new path through BR if it is 6928 cheaper, overriding the paths in the routing table. 6929 Otherwise, if the new path is the same cost, add it to the 6930 list of paths that appear in the routing table entry. 6932 16.3. Examining transit areas' summary-LSAs 6934 This step is only performed by area border routers attached to 6935 one or more non-backbone areas that are capable of carrying 6936 transit traffic (i.e., "transit areas", or those areas whose 6937 TransitCapability parameter has been set to TRUE in Step 2 of 6938 the Dijkstra algorithm (see Section 16.1). 6940 The purpose of the calculation below is to examine the transit 6941 areas to see whether they provide any better (shorter) paths 6942 than the paths previously calculated in Sections 16.1 and 16.2. 6943 Any paths found that are better than or equal to previously 6944 discovered paths are installed in the routing table. 6946 The calculation proceeds as follows. All the transit areas' 6947 summary-LSAs are examined in turn. Each such summary-LSA 6948 describes a route through a transit area Area A to a Network N 6949 (N's address is obtained by masking the LSA's Link State ID with 6950 the network/subnet mask contained in the body of the LSA) or in 6951 the case of a Type 4 summary-LSA, to an AS boundary router N. 6952 Suppose also that the summary-LSA was originated by an area 6953 border router BR. 6955 (1) If the cost advertised by the summary-LSA is LSInfinity, or 6956 if the LSA's LS age is equal to MaxAge, then examine the 6957 next LSA. 6959 (2) If the summary-LSA was originated by the calculating router 6960 itself, examine the next LSA. 6962 (3) Look up the routing table entry for N. If it does not exist, 6963 or if the route type is other than intra-area or inter-area, 6964 or if the area associated with the routing table entry is 6965 not the backbone area, then examine the next LSA. In other 6966 words, this calculation only updates backbone intra-area 6967 routes found in Section 16.1 and inter-area routes found in 6968 Section 16.2. 6970 (4) Look up the routing table entry for the advertising router 6971 BR associated with the Area A. If it is unreachable, examine 6972 the next LSA. Otherwise, the cost to destination N is the 6973 sum of the cost in BR's Area A routing table entry and the 6974 cost advertised in the LSA. Call this cost IAC. 6976 (5) If this cost is less than the cost occurring in N's routing 6977 table entry, overwrite N's list of next hops with those used 6978 for BR, and set N's routing table cost to IAC. Else, if IAC 6979 is the same as N's current cost, add BR's list of next hops 6980 to N's list of next hops. In any case, the area associated 6981 with N's routing table entry must remain the backbone area, 6982 and the path type (either intra-area or inter-area) must 6983 also remain the same. 6985 It is important to note that the above calculation never makes 6986 unreachable destinations reachable, but instead just potentially 6987 finds better paths to already reachable destinations. The 6988 ........................ 6989 . Area 1 (transit) . + 6990 . . | 6991 . +---+1 1+---+100 | 6992 . |RT2|----------|RT4|=========| 6993 . 1/+---+********* +---+ | 6994 . /******* . | 6995 . 1/*Virtual . | 6996 1+---+/* Link . Net|work 6997 =======|RT1|* . | N1 6998 +---+\ . | 6999 . \ . | 7000 . \ . | 7001 . 1\+---+1 1+---+20 | 7002 . |RT3|----------|RT5|=========| 7003 . +---+ +---+ | 7004 . . | 7005 ........................ + 7007 Figure 17: Routing through transit areas 7009 calculation installs any better cost found into the routing 7010 table entry, from which it may be readvertised in summary-LSAs 7011 to other areas. 7013 As an example of the calculation, consider the Autonomous System 7014 pictured in Figure 17. There is a single non-backbone area 7015 (Area 1) that physically divides the backbone into two separate 7016 pieces. To maintain connectivity of the backbone, a virtual link 7017 has been configured between routers RT1 and RT4. On the right 7018 side of the figure, Network N1 belongs to the backbone. The 7019 dotted lines indicate that there is a much shorter intra-area 7020 backbone path between router RT5 and Network N1 (cost 20) than 7021 there is between Router RT4 and Network N1 (cost 100). Both 7022 Router RT4 and Router RT5 will inject summary-LSAs for Network 7023 N1 into Area 1. 7025 After the shortest-path tree has been calculated for the 7026 backbone in Section 16.1, Router RT1 (left end of the virtual 7027 link) will have calculated a path through Router RT4 for all 7028 data traffic destined for Network N1. However, since Router RT5 7029 is so much closer to Network N1, all routers internal to Area 1 7030 (e.g., Routers RT2 and RT3) will forward their Network N1 7031 traffic towards Router RT5, instead of RT4. And indeed, after 7032 examining Area 1's summary-LSAs by the above calculation, Router 7033 RT1 will also forward Network N1 traffic towards RT5. Note that 7034 in this example the virtual link enables transit data traffic to 7035 be forwarded through Area 1, but the actual path the transit 7036 data traffic takes does not follow the virtual link. In other 7037 words, virtual links allow transit traffic to be forwarded 7038 through an area, but do not dictate the precise path that the 7039 traffic will take. 7041 16.4. Calculating AS external routes 7043 AS external routes are calculated by examining AS-external-LSAs. 7044 Each of the AS-external-LSAs is considered in turn. Most AS- 7045 external-LSAs describe routes to specific IP destinations. An 7046 AS-external-LSA can also describe a default route for the 7047 Autonomous System (Destination ID = DefaultDestination, 7048 network/subnet mask = 0x00000000). For each AS-external-LSA: 7050 (1) If the cost specified by the LSA is LSInfinity, or if the 7051 LSA's LS age is equal to MaxAge, then examine the next LSA. 7053 (2) If the LSA was originated by the calculating router itself, 7054 examine the next LSA. 7056 (3) Call the destination described by the LSA N. N's address is 7057 obtained by masking the LSA's Link State ID with the 7058 network/subnet mask contained in the body of the LSA. Look 7059 up the routing table entry for the AS boundary router (ASBR) 7060 that originated the LSA. If no entry exists for router ASBR 7061 (i.e., ASBR is unreachable), do nothing with this LSA and 7062 consider the next in the list. 7064 Else, this LSA describes an AS external path to destination 7065 N. Examine the forwarding address specified in the AS- 7066 external-LSA. This indicates the IP address to which 7067 packets for the destination should be forwarded. If the 7068 forwarding address is set to 0.0.0.0, packets should be sent 7069 to the ASBR itself. Otherwise, look up the forwarding 7070 address in the routing table.[26] An intra-area or inter- 7071 area path must exist to the forwarding address. If no such 7072 path exists, do nothing with the LSA and consider the next 7073 in the list. 7075 Call the routing table distance to the forwarding address X 7076 (when the forwarding address is set to 0.0.0.0, this is the 7077 distance to the ASBR itself), and the cost specified in the 7078 LSA Y. X is in terms of the link state metric, and Y is a 7079 type 1 or 2 external metric. 7081 (4) Next, look up the routing table entry for the destination N. 7082 If no entry exists for N, install the AS external path to N, 7083 with next hop equal to the list of next hops to the 7084 forwarding address, and advertising router equal to ASBR. 7085 If the external metric type is 1, then the path-type is set 7086 to type 1 external and the cost is equal to X+Y. If the 7087 external metric type is 2, the path-type is set to type 2 7088 external, the link state component of the route's cost is X, 7089 and the type 2 cost is Y. 7091 (5) Else, if the paths present in the table are not type 1 or 7092 type 2 external paths, do nothing (AS external paths have 7093 the lowest priority). 7095 (6) Otherwise, compare the cost of this new AS external path to 7096 the ones present in the table. Type 1 external paths are 7097 always shorter than type 2 external paths. Type 1 external 7098 paths are compared by looking at the sum of the distance to 7099 the forwarding address and the advertised type 1 metric 7100 (X+Y). Type 2 external paths are compared by looking at the 7101 advertised type 2 metrics, and then if necessary, the 7102 distance to the forwarding addresses. 7104 If the new path is shorter, it replaces the present paths in 7105 the routing table entry. If the new path is the same cost, 7106 it is added to the routing table entry's list of paths. 7108 16.5. Incremental updates -- summary-LSAs 7110 When a new summary-LSA is received, it is not necessary to 7111 recalculate the entire routing table. Call the destination 7112 described by the summary-LSA N (N's address is obtained by 7113 masking the LSA's Link State ID with the network/subnet mask 7114 contained in the body of the LSA), and let Area A be the area to 7115 which the LSA belongs. There are then two separate cases: 7117 Case 1: Area A is the backbone and/or the router is not an area 7118 border router. 7119 In this case, the following calculations must be performed. 7120 First, if there is presently an inter-area route to the 7121 destination N, N's routing table entry is invalidated, 7122 saving the entry's values for later comparisons. Then the 7123 calculation in Section 16.2 is run again for the single 7124 destination N. In this calculation, all of Area A's 7125 summary-LSAs that describe a route to N are examined. In 7126 addition, if the router is an area border router attached to 7127 one or more transit areas, the calculation in Section 16.3 7128 must be run again for the single destination. If the 7129 results of these calculations have changed the cost/path to 7130 an AS boundary router (as would be the case for a Type 4 7131 summary-LSA) or to any forwarding addresses, all AS- 7132 external-LSAs will have to be reexamined by rerunning the 7133 calculation in Section 16.4. Otherwise, if N is now newly 7134 unreachable, the calculation in Section 16.4 must be rerun 7135 for the single destination N, in case an alternate external 7136 route to N exists. 7138 Case 2: Area A is a transit area and the router is an area 7139 border router. 7140 In this case, the following calculations must be performed. 7141 First, if N's routing table entry presently contains one or 7142 more inter-area paths that utilize the transit area Area A, 7143 these paths should be removed. If this removes all paths 7144 from the routing table entry, the entry should be 7145 invalidated. The entry's old values should be saved for 7146 later comparisons. Next the calculation in Section 16.3 must 7147 be run again for the single destination N. If the results of 7148 this calculation have caused the cost to N to increase, the 7149 complete routing table calculation must be rerun starting 7150 with the Dijkstra algorithm specified in Section 16.1. 7151 Otherwise, if the cost/path to an AS boundary router (as 7152 would be the case for a Type 4 summary-LSA) or to any 7153 forwarding addresses has changed, all AS-external-LSAs will 7154 have to be reexamined by rerunning the calculation in 7155 Section 16.4. Otherwise, if N is now newly unreachable, the 7156 calculation in Section 16.4 must be rerun for the single 7157 destination N, in case an alternate external route to N 7158 exists. 7160 16.6. Incremental updates -- AS-external-LSAs 7162 When a new AS-external-LSA is received, it is not necessary to 7163 recalculate the entire routing table. Call the destination 7164 described by the AS-external-LSA N. N's address is obtained by 7165 masking the LSA's Link State ID with the network/subnet mask 7166 contained in the body of the LSA. If there is already an intra- 7167 area or inter-area route to the destination, no recalculation is 7168 necessary (internal routes take precedence). 7170 Otherwise, the procedure in Section 16.4 will have to be 7171 performed, but only for those AS-external-LSAs whose destination 7172 is N. Before this procedure is performed, the present routing 7173 table entry for N should be invalidated. 7175 16.7. Events generated as a result of routing table changes 7177 Changes to routing table entries sometimes cause the OSPF area 7178 border routers to take additional actions. These routers need 7179 to act on the following routing table changes: 7181 o The cost or path type of a routing table entry has changed. 7182 If the destination described by this entry is a Network or 7183 AS boundary router, and this is not simply a change of AS 7184 external routes, new summary-LSAs may have to be generated 7185 (potentially one for each attached area, including the 7186 backbone). See Section 12.4.3 for more information. If a 7187 previously advertised entry has been deleted, or is no 7188 longer advertisable to a particular area, the LSA must be 7189 flushed from the routing domain by setting its LS age to 7190 MaxAge and reflooding (see Section 14.1). 7192 o A routing table entry associated with a configured virtual 7193 link has changed. The destination of such a routing table 7194 entry is an area border router. The change indicates a 7195 modification to the virtual link's cost or viability. 7197 If the entry indicates that the area border router is newly 7198 reachable (via TOS 0), the corresponding virtual link is now 7199 operational. An InterfaceUp event should be generated for 7200 the virtual link, which will cause a virtual adjacency to 7201 begin to form (see Section 10.3). At this time the virtual 7202 link's IP interface address and the virtual neighbor's 7203 Neighbor IP address are also calculated. 7205 If the entry indicates that the area border router is no 7206 longer reachable (via TOS 0), the virtual link and its 7207 associated adjacency should be destroyed. This means an 7208 InterfaceDown event should be generated for the associated 7209 virtual link. 7211 If the cost of the entry has changed, and there is a fully 7212 established virtual adjacency, a new router-LSA for the 7213 backbone must be originated. This in turn may cause further 7214 routing table changes. 7216 16.8. Equal-cost multipath 7218 The OSPF protocol maintains multiple equal-cost routes to all 7219 destinations. This can be seen in the steps used above to 7220 calculate the routing table, and in the definition of the 7221 routing table structure. 7223 Each one of the multiple routes will be of the same type 7224 (intra-area, inter-area, type 1 external or type 2 external), 7225 cost, and will have the same associated area. However, each 7226 route specifies a separate next hop and Advertising router. 7228 There is no requirement that a router running OSPF keep track of 7229 all possible equal-cost routes to a destination. An 7230 implementation may choose to keep only a fixed number of routes 7231 to any given destination. This does not affect any of the 7232 algorithms presented in this specification. 7234 16.9. Building the non-zero-TOS portion of the routing table 7236 The OSPF protocol can calculate a different set of routes for 7237 each IP TOS (see Section 2.5). Support for TOS-based routing is 7238 optional. TOS-capable and non-TOS-capable routers can be mixed 7239 in an OSPF routing domain. Routers not supporting TOS calculate 7240 only the TOS 0 route to each destination. These routes are then 7241 used to forward all data traffic, regardless of the TOS 7242 indications in the data packet's IP header. A router that does 7243 not support TOS indicates this fact to the other OSPF routers by 7244 clearing the T-bit in the Options field of its router-LSA. 7246 The above sections detailing the routing table calculations 7247 handle the TOS 0 case only. In general, for routers supporting 7248 TOS-based routing, each piece of the routing table calculation 7249 must be rerun separately for the non-zero TOS values. When 7250 calculating routes for TOS X, only TOS X metrics can be used. 7251 Any LSA may specify a separate cost for each TOS (a cost for TOS 7252 0 must always be specified). The encoding of TOS in OSPF LSAs 7253 is described in Section 12.3. 7255 An LSA can specify that it is restricted to TOS 0 (i.e., non- 7256 zero TOS is not handled) by clearing the T-bit in the LSA's 7257 Option field. Such LSAs are not used when calculating routes 7258 for non-zero TOS. For this reason, it is possible that a 7259 destination is unreachable for some non-zero TOS. In this case, 7260 the TOS 0 path is used when forwarding packets (see Section 7261 11.1). 7263 The following lists the modifications needed when running the 7264 routing table calculation for a non-zero TOS value (called TOS 7265 X). In general, routers and LSAs that do not support TOS are 7266 omitted from the calculation. 7268 Calculating the shortest-path tree (Section 16.1). 7269 Routers that do not support TOS-based routing should be 7270 omitted from the shortest-path tree calculation. These 7271 routers are identified as those having the T-bit reset in 7272 the Options field of their router-LSAs. Such routers should 7273 never be added to the Dijktra algorithm's candidate list, 7274 nor should their router-LSAs be examined when adding the 7275 stub networks to the tree. In particular, if the T-bit is 7276 reset in the calculating router's own router-LSA, it does 7277 not run the shortest-path tree calculation for non-zero TOS 7278 values. 7280 Calculating the inter-area routes (Section 16.2). 7281 Inter-area paths are the concatenation of a path to an area 7282 border router with a summary link. When calculating TOS X 7283 routes, both path components must also specify TOS X. In 7284 other words, only TOS X paths to the area border router are 7285 examined, and the area border router must be advertising a 7286 TOS X route to the destination. Note that this means that 7287 summary-LSAs having the T-bit reset in their Options field 7288 are not considered. 7290 Examining transit areas' summary-LSAs (Section 16.3). 7291 This calculation again considers the concatenation of a path 7292 to an area border router with a summary link. As with 7293 inter-area routes, only TOS X paths to the area border 7294 router are examined, and the area border router must be 7295 advertising a TOS X route to the destination. 7297 Calculating AS external routes (Section 16.4). 7298 This calculation considers the concatenation of a path to a 7299 forwarding address with an AS external link. Only TOS X 7300 paths to the forwarding address are examined, and the AS 7301 boundary router must be advertising a TOS X route to the 7302 destination. Note that this means that AS-external-LSAs 7303 having the T-bit reset in their Options field are not 7304 considered. 7306 In addition, the advertising AS boundary router must also be 7307 reachable for its LSAs to be considered (see Section 16.4). 7308 However, if the advertising router and the forwarding 7309 address are not one in the same, the advertising router need 7310 only be reachable via TOS 0. 7312 Footnotes 7314 [1]The graph's vertices represent either routers, transit networks, 7315 or stub networks. Since routers may belong to multiple areas, it is 7316 not possible to color the graph's vertices. 7318 [2]It is possible for all of a router's interfaces to be unnumbered 7319 point-to-point links. In this case, an IP address must be assigned 7320 to the router. This address will then be advertised in the router's 7321 router-LSA as a host route. 7323 [3]Note that in these cases both interfaces, the non-virtual and the 7324 virtual, would have the same IP address. 7326 [4]Note that no host route is generated for, and no IP packets can 7327 be addressed to, interfaces to unnumbered point-to-point networks. 7328 This is regardless of such an interface's state. 7330 [5]It is instructive to see what happens when the Designated Router 7331 for the network crashes. Call the Designated Router for the network 7332 RT1, and the Backup Designated Router RT2. If Router RT1 crashes 7333 (or maybe its interface to the network dies), the other routers on 7334 the network will detect RT1's absence within RouterDeadInterval 7335 seconds. All routers may not detect this at precisely the same 7336 time; the routers that detect RT1's absence before RT2 does will, 7337 for a time, select RT2 to be both Designated Router and Backup 7338 Designated Router. When RT2 detects that RT1 is gone it will move 7339 itself to Designated Router. At this time, the remaining router 7340 having highest Router Priority will be selected as Backup Designated 7341 Router. 7343 [6]On point-to-point networks, the lower level protocols indicate 7344 whether the neighbor is up and running. Likewise, existence of the 7345 neighbor on virtual links is indicated by the routing table 7346 calculation. However, in both these cases, the Hello Protocol is 7347 still used. This ensures that communication between the neighbors 7348 is bidirectional, and that each of the neighbors has a functioning 7349 routing protocol layer. 7351 [7]When the identity of the Designated Router is changing, it may be 7352 quite common for a neighbor in this state to send the router a 7353 Database Description packet; this means that there is some momentary 7354 disagreement on the Designated Router's identity. 7356 [8]Note that it is possible for a router to resynchronize any of its 7357 fully established adjacencies by setting the adjacency's state back 7358 to ExStart. This will cause the other end of the adjacency to 7359 process a SeqNumberMismatch event, and therefore to also go back to 7360 ExStart state. 7362 [9]The address space of IP networks and the address space of OSPF 7363 Router IDs may overlap. That is, a network may have an IP address 7364 which is identical (when considered as a 32-bit number) to some 7365 router's Router ID. 7367 [10]"Discard" entries are necessary to ensure that route 7368 summarization at area boundaries will not cause packet looping. 7370 [11]It is assumed that, for two different address ranges matching 7371 the destination, one range is more specific than the other. Non- 7372 contiguous subnet masks can be configured to violate this 7373 assumption. Such subnet mask configurations cannot be handled by the 7374 OSPF protocol. 7376 [12]MaxAgeDiff is an architectural constant. It indicates the 7377 maximum dispersion of ages, in seconds, that can occur for a single 7378 LSA instance as it is flooded throughout the routing domain. If two 7379 LSAs differ by more than this, they are assumed to be different 7380 instances of the same LSA. This can occur when a router restarts 7381 and loses track of the LSA's previous LS sequence number. See 7382 Section 13.4 for more details. 7384 [13]When two LSAs have different LS checksums, they are assumed to 7385 be separate instances. This can occur when a router restarts, and 7386 loses track of the LSA's previous LS sequence number. In the case 7387 where the two LSAs have the same LS sequence number, it is not 7388 possible to determine which LSA is actually newer. However, if the 7389 wrong LSA is accepted as newer, the originating router will simply 7390 originate another instance. See Section 13.4 for further details. 7392 [14]There is one instance where a lookup must be done based on 7393 partial information. This is during the routing table calculation, 7394 when a network-LSA must be found based solely on its Link State ID. 7395 The lookup in this case is still well defined, since no two 7396 network-LSAs can have the same Link State ID. 7398 [15]This is the way RFC 1583 specified point-to-point 7399 representation. It has three advantages: a) it does not require 7400 allocating a subnet to the point-to-point link, b) it tends to bias 7401 the routing so that packets destined for the point-to-point 7402 interface will actually be received over the interface (which is 7403 useful for diagnostic purposes) and c) it allows network 7404 bootstrapping of a neighbor, without requiring that the bootstrap 7405 program contain an OSPF implementation. 7407 [16]This is the more traditional point-to-point representation used 7408 by protocols such as RIP. 7410 [17]This clause covers the case: Inter-area routes are not 7411 summarized to the backbone. This is because inter-area routes are 7412 always associated with the backbone area. 7414 [18]This clause is only invoked when a non-backbone Area A supports 7415 transit data traffic (i.e., has TransitCapability set to TRUE). For 7416 example, in the area configuration of Figure 6, Area 2 can support 7417 transit traffic due to the configured virtual link between Routers 7418 RT10 and RT11. As a result, Router RT11 need only originate a single 7419 summary-LSA into Area 2 (having the collapsed destination N9- 7420 N11,H1), since all of Router RT11's other eligible routes have next 7421 hops belonging to Area 2 itself (and as such only need be advertised 7422 by other area border routers; in this case, Routers RT10 and RT7). 7424 [19]By keeping more information in the routing table, it is possible 7425 for an implementation to recalculate the shortest path tree for only 7426 a single area. In fact, there are incremental algorithms that allow 7427 an implementation to recalculate only a portion of a single area's 7428 shortest path tree [Ref1]. However, these algorithms are beyond the 7429 scope of this specification. 7431 [20]This is how the Link state request list is emptied, which 7432 eventually causes the neighbor state to transition to Full. See 7433 Section 10.9 for more details. 7435 [21]It should be a relatively rare occurrence for an LSA's LS age to 7436 reach MaxAge in this fashion. Usually, the LSA will be replaced by 7437 a more recent instance before it ages out. 7439 [22]Only the TOS 0 routes are important here because all OSPF 7440 protocol packets are sent with TOS = 0. See Appendix A. 7442 [23]It may be the case that paths to certain destinations do not 7443 vary based on TOS. For these destinations, the routing calculation 7444 need not be repeated for each TOS value. In addition, there need 7445 only be a single routing table entry for these destinations (instead 7446 of a separate entry for each TOS value). 7448 [24]Strictly speaking, because of equal-cost multipath, the 7449 algorithm does not create a tree. We continue to use the "tree" 7450 terminology because that is what occurs most often in the existing 7451 literature. 7453 [25]Note that the presence of any link back to V is sufficient; it 7454 need not be the matching half of the link under consideration from V 7455 to W. This is enough to ensure that, before data traffic flows 7456 between a pair of neighboring routers, their link state databases 7457 will be synchronized. 7459 [26]When the forwarding address is non-zero, it should point to a 7460 router belonging to another Autonomous System. See Section 12.4.4 7461 for more details. 7463 References 7465 [Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing 7466 Algorithm Improvements", BBN Technical Report 3803, April 7467 1978. 7469 [Ref2] Digital Equipment Corporation, "Information processing 7470 systems -- Data communications -- Intermediate System to 7471 Intermediate System Intra-Domain Routing Protocol", October 7472 1987. 7474 [Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the 7475 ARPANET", IEEE Transactions on Communications, May 1980. 7477 [Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing 7478 Information", Computer Networks, December 1983. 7480 [Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, 7481 USC/Information Sciences Institute, September 1981. 7483 [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 7484 8073", RFC 905, ISO, April 1984. 7486 [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, 7487 RFC 1112, Stanford University, May 1988. 7489 [Ref8] McCloghrie, K., and M. Rose, "Management Information Base 7490 for network management of TCP/IP-based internets: MIB-II", 7491 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 7492 International, March 1991. 7494 [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 7495 1994. 7497 [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 7498 Inter-Domain Routing (CIDR): an Address Assignment and 7499 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 7500 OARnet, September 1993. 7502 [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 7503 1700, USC/Information Sciences Institute, October 1994. 7505 [Ref12] Almquist, P., "Type of Service in the Internet Protocol 7506 Suite", RFC 1349, July 1992. 7508 [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN 7509 Protocol Handbook, April 1985. 7511 [Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution 7512 Protocol", RFC 1293, January 1992. 7514 [Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 7515 Over Frame Relay Networks", RFC 1586, March 1994. 7517 [Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol 7518 Suite", ACM Computer Communications Review, Volume 19, 7519 Number 2, pp. 32-38, April 1989. 7521 [Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 7522 April 1992. 7524 [Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 7525 Inc., March 1994. 7527 [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 7528 RainbowBridge Communications, Stanford University, March 7529 1994. 7531 [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in 7532 progress. 7534 [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 7535 1793, Cascade, April 1995. 7537 [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 7538 DECWRL, Stanford University, November 1990. 7540 [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 7541 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 7542 Systems, March 1995. 7544 A. OSPF data formats 7546 This appendix describes the format of OSPF protocol packets and OSPF 7547 LSAs. The OSPF protocol runs directly over the IP network layer. 7548 Before any data formats are described, the details of the OSPF 7549 encapsulation are explained. 7551 Next the OSPF Options field is described. This field describes 7552 various capabilities that may or may not be supported by pieces of 7553 the OSPF routing domain. The OSPF Options field is contained in OSPF 7554 Hello packets, Database Description packets and in OSPF LSAs. 7556 OSPF packet formats are detailed in Section A.3. A description of 7557 OSPF LSAs appears in Section A.4. 7559 A.1 Encapsulation of OSPF packets 7561 OSPF runs directly over the Internet Protocol's network layer. OSPF 7562 packets are therefore encapsulated solely by IP and local data-link 7563 headers. 7565 OSPF does not define a way to fragment its protocol packets, and 7566 depends on IP fragmentation when transmitting packets larger than 7567 the network MTU. If necessary, the length of OSPF packets can be up 7568 to 65,535 bytes (including the IP header). The OSPF packet types 7569 that are likely to be large (Database Description Packets, Link 7570 State Request, Link State Update, and Link State Acknowledgment 7571 packets) can usually be split into several separate protocol 7572 packets, without loss of functionality. This is recommended; IP 7573 fragmentation should be avoided whenever possible. Using this 7574 reasoning, an attempt should be made to limit the sizes of OSPF 7575 packets sent over virtual links to 576 bytes unless Path MTU 7576 Discovery is being performed (see [Ref22]). 7578 The other important features of OSPF's IP encapsulation are: 7580 o Use of IP multicast. Some OSPF messages are multicast, when 7581 sent over broadcast networks. Two distinct IP multicast 7582 addresses are used. Packets sent to these multicast addresses 7583 should never be forwarded; they are meant to travel a single hop 7584 only. To ensure that these packets will not travel multiple 7585 hops, their IP TTL must be set to 1. 7587 AllSPFRouters 7588 This multicast address has been assigned the value 7589 224.0.0.5. All routers running OSPF should be prepared to 7590 receive packets sent to this address. Hello packets are 7591 always sent to this destination. Also, certain OSPF 7592 protocol packets are sent to this address during the 7593 flooding procedure. 7595 AllDRouters 7596 This multicast address has been assigned the value 7597 224.0.0.6. Both the Designated Router and Backup Designated 7598 Router must be prepared to receive packets destined to this 7599 address. Certain OSPF protocol packets are sent to this 7600 address during the flooding procedure. 7602 o OSPF is IP protocol number 89. This number has been registered 7603 with the Network Information Center. IP protocol number 7604 assignments are documented in [Ref11]. 7606 o Routing protocol packets are sent with IP TOS of 0. The OSPF 7607 protocol supports TOS-based routing. Routes to any particular 7608 destination may vary based on TOS. However, all OSPF routing 7609 protocol packets are sent using the normal service TOS value of 7610 binary 0000 defined in [Ref12]. 7612 o Routing protocol packets are sent with IP precedence set to 7613 Internetwork Control. OSPF protocol packets should be given 7614 precedence over regular IP data traffic, in both sending and 7615 receiving. Setting the IP precedence field in the IP header to 7616 Internetwork Control [Ref5] may help implement this objective. 7618 A.2 The Options field 7620 The OSPF Options field is present in OSPF Hello packets, Database 7621 Description packets and all LSAs. The Options field enables OSPF 7622 routers to support (or not support) optional capabilities, and to 7623 communicate their capability level to other OSPF routers. Through 7624 this mechanism routers of differing capabilities can be mixed within 7625 an OSPF routing domain. 7627 When used in Hello packets, the Options field allows a router to 7628 reject a neighbor because of a capability mismatch. Alternatively, 7629 when capabilities are exchanged in Database Description packets a 7630 router can choose not to forward certain LSAs to a neighbor because 7631 of its reduced functionality. Lastly, listing capabilities in LSAs 7632 allows routers to forward traffic around reduced functionality 7633 routers, by excluding them from parts of the routing table 7634 calculation. 7636 Six bits of the OSPF Options field have been assigned, although only 7637 two (the T-bit and E-bit) are described completely by this memo. 7638 Each bit is described briefly below. Routers should reset (i.e. 7639 clear) unrecognized bits in the Options field when sending Hello 7640 packets or Database Description packets and when originating LSAs. 7641 Conversely, routers encountering unrecognized Option bits in 7642 received Hello Packets, Database Description packets or LSAs should 7643 ignore the capability and process the packet/LSA normally. 7645 +------------------------------------+ 7646 | * | * | DC | EA | N/P | MC | E | T | 7647 +------------------------------------+ 7649 The Options field 7651 T-bit 7652 This bit describes the router's TOS-based routing capability, as 7653 specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of this memo. 7655 E-bit 7656 This bit describes the way AS-external-LSAs are flooded, as 7657 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. 7659 MC-bit 7660 This bit describes whether IP multicast datagrams are forwarded 7661 according to the specifications in [Ref18]. 7663 N/P-bit 7664 This bit describes the handling of Type-7 LSAs, as specified in 7666 [Ref19]. 7668 EA-bit 7669 This bit describes the router's willingness to receive and 7670 forward External-Attributes-LSAs, as specified in [Ref20]. 7672 DC-bit 7673 This bit describes the router's handling of demand circuits, as 7674 specified in [Ref21]. 7676 A.3 OSPF Packet Formats 7678 There are five distinct OSPF packet types. All OSPF packet types 7679 begin with a standard 24 byte header. This header is described 7680 first. Each packet type is then described in a succeeding section. 7681 In these sections each packet's division into fields is displayed, 7682 and then the field definitions are enumerated. 7684 All OSPF packet types (other than the OSPF Hello packets) deal with 7685 lists of LSAs. For example, Link State Update packets implement the 7686 flooding of LSAs throughout the OSPF routing domain. Because of 7687 this, OSPF protocol packets cannot be parsed unless the format of 7688 LSAs is also understood. The format of LSAs is described in Section 7689 A.4. 7691 The receive processing of OSPF packets is detailed in Section 8.2. 7692 The sending of OSPF packets is explained in Section 8.1. 7694 A.3.1 The OSPF packet header 7696 Every OSPF packet starts with a standard 24 byte header. This 7697 header contains all the information necessary to determine whether 7698 the packet should be accepted for further processing. This 7699 determination is described in Section 8.2 of the specification. 7701 0 1 2 3 7702 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 7703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7704 | Version # | Type | Packet length | 7705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7706 | Router ID | 7707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7708 | Area ID | 7709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7710 | Checksum | AuType | 7711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7712 | Authentication | 7713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7714 | Authentication | 7715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7717 Version # 7718 The OSPF version number. This specification documents version 2 7719 of the protocol. 7721 Type 7722 The OSPF packet types are as follows. See Sections A.3.2 through 7723 A.3.6 for details. 7725 Type Description 7726 ________________________________ 7727 1 Hello 7728 2 Database Description 7729 3 Link State Request 7730 4 Link State Update 7731 5 Link State Acknowledgment 7732 Packet length 7733 The length of the OSPF protocol packet in bytes. This length 7734 includes the standard OSPF header. 7736 Router ID 7737 The Router ID of the packet's source. 7739 Area ID 7740 A 32 bit number identifying the area that this packet belongs 7741 to. All OSPF packets are associated with a single area. Most 7742 travel a single hop only. Packets travelling over a virtual 7743 link are labelled with the backbone Area ID of 0.0.0.0. 7745 Checksum 7746 The standard IP checksum of the entire contents of the packet, 7747 starting with the OSPF packet header but excluding the 64-bit 7748 authentication field. This checksum is calculated as the 16-bit 7749 one's complement of the one's complement sum of all the 16-bit 7750 words in the packet, excepting the authentication field. If the 7751 packet's length is not an integral number of 16-bit words, the 7752 packet is padded with a byte of zero before checksumming. The 7753 checksum is considered to be part of the packet authentication 7754 procedure; for some authentication types the checksum 7755 calculation is omitted. 7757 AuType 7758 Identifies the authentication procedure to be used for the 7759 packet. Authentication is discussed in Appendix D of the 7760 specification. Consult Appendix D for a list of the currently 7761 defined authentication types. 7763 Authentication 7764 A 64-bit field for use by the authentication scheme. See 7765 Appendix D for details. 7767 A.3.2 The Hello packet 7769 Hello packets are OSPF packet type 1. These packets are sent 7770 periodically on all interfaces (including virtual links) in order to 7771 establish and maintain neighbor relationships. In addition, Hello 7772 Packets are multicast on those physical networks having a multicast 7773 or broadcast capability, enabling dynamic discovery of neighboring 7774 routers. 7776 All routers connected to a common network must agree on certain 7777 parameters (Network mask, HelloInterval and RouterDeadInterval). 7778 These parameters are included in Hello packets, so that differences 7779 can inhibit the forming of neighbor relationships. A detailed 7780 explanation of the receive processing for Hello packets is presented 7781 in Section 10.5. The sending of Hello packets is covered in Section 7782 9.5. 7784 0 1 2 3 7785 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 7786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7787 | Version # | 1 | Packet length | 7788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7789 | Router ID | 7790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7791 | Area ID | 7792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7793 | Checksum | AuType | 7794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7795 | Authentication | 7796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7797 | Authentication | 7798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7799 | Network Mask | 7800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7801 | HelloInterval | Options | Rtr Pri | 7802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7803 | RouterDeadInterval | 7804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7805 | Designated Router | 7806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7807 | Backup Designated Router | 7808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7809 | Neighbor | 7810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7811 | ... | 7813 Network mask 7814 The network mask associated with this interface. For example, 7815 if the interface is to a class B network whose third byte is 7816 used for subnetting, the network mask is 0xffffff00. 7818 Options 7819 The optional capabilities supported by the router, as documented 7820 in Section A.2. 7822 HelloInterval 7823 The number of seconds between this router's Hello packets. 7825 Rtr Pri 7826 This router's Router Priority. Used in (Backup) Designated 7827 Router election. If set to 0, the router will be ineligible to 7828 become (Backup) Designated Router. 7830 RouterDeadInterval 7831 The number of seconds before declaring a silent router down. 7833 Designated Router 7834 The identity of the Designated Router for this network, in the 7835 view of the sending router. The Designated Router is identified 7836 here by its IP interface address on the network. Set to 0.0.0.0 7837 if there is no Designated Router. 7839 Backup Designated Router 7840 The identity of the Backup Designated Router for this network, 7841 in the view of the sending router. The Backup Designated Router 7842 is identified here by its IP interface address on the network. 7843 Set to 0.0.0.0 if there is no Backup Designated Router. 7845 Neighbor 7846 The Router IDs of each router from whom valid Hello packets have 7847 been seen recently on the network. Recently means in the last 7848 RouterDeadInterval seconds. 7850 A.3.3 The Database Description packet 7852 Database Description packets are OSPF packet type 2. These packets 7853 are exchanged when an adjacency is being initialized. They describe 7854 the contents of the link-state database. Multiple packets may be 7855 used to describe the database. For this purpose a poll-response 7856 procedure is used. One of the routers is designated to be the 7857 master, the other the slave. The master sends Database Description 7858 packets (polls) which are acknowledged by Database Description 7859 packets sent by the slave (responses). The responses are linked to 7860 the polls via the packets' DD sequence numbers. 7862 0 1 2 3 7863 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 7864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7865 | Version # | 2 | Packet length | 7866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7867 | Router ID | 7868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7869 | Area ID | 7870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7871 | Checksum | AuType | 7872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7873 | Authentication | 7874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7875 | Authentication | 7876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7877 | 0 | 0 | Options |0|0|0|0|0|I|M|MS 7878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7879 | DD sequence number | 7880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7881 | | 7882 +- -+ 7883 | | 7884 +- An LSA Header -+ 7885 | | 7886 +- -+ 7887 | | 7888 +- -+ 7889 | | 7890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7891 | ... | 7893 The format of the Database Description packet is very similar to 7894 both the Link State Request and Link State Acknowledgment packets. 7895 The main part of all three is a list of items, each item describing 7896 a piece of the link-state database. The sending of Database 7897 Description Packets is documented in Section 10.8. The reception of 7898 Database Description packets is documented in Section 10.6. 7900 0 These fields are reserved. They must be 0. 7902 Options 7903 The optional capabilities supported by the router, as documented 7904 in Section A.2. 7906 I-bit 7907 The Init bit. When set to 1, this packet is the first in the 7908 sequence of Database Description Packets. 7910 M-bit 7911 The More bit. When set to 1, it indicates that more Database 7912 Description Packets are to follow. 7914 MS-bit 7915 The Master/Slave bit. When set to 1, it indicates that the 7916 router is the master during the Database Exchange process. 7917 Otherwise, the router is the slave. 7919 DD sequence number 7920 Used to sequence the collection of Database Description Packets. 7921 The initial value (indicated by the Init bit being set) should 7922 be unique. The DD sequence number then increments until the 7923 complete database description has been sent. 7925 The rest of the packet consists of a (possibly partial) list of the 7926 link-state database's pieces. Each LSA in the database is described 7927 by its LSA header. The LSA header is documented in Section A.4.1. 7928 It contains all the information required to uniquely identify both 7929 the LSA and the LSA's current instance. 7931 A.3.4 The Link State Request packet 7933 Link State Request packets are OSPF packet type 3. After exchanging 7934 Database Description packets with a neighboring router, a router may 7935 find that parts of its link-state database are out-of-date. The 7936 Link State Request packet is used to request the pieces of the 7937 neighbor's database that are more up-to-date. Multiple Link State 7938 Request packets may need to be used. 7940 A router that sends a Link State Request packet has in mind the 7941 precise instance of the database pieces it is requesting. Each 7942 instance is defined by its LS sequence number, LS checksum, and LS 7943 age, although these fields are not specified in the Link State 7944 Request Packet itself. The router may receive even more recent 7945 instances in response. 7947 The sending of Link State Request packets is documented in Section 7948 10.9. The reception of Link State Request packets is documented in 7949 Section 10.7. 7951 0 1 2 3 7952 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 7953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7954 | Version # | 3 | Packet length | 7955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7956 | Router ID | 7957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7958 | Area ID | 7959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7960 | Checksum | AuType | 7961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7962 | Authentication | 7963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7964 | Authentication | 7965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7966 | LS type | 7967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7968 | Link State ID | 7969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7970 | Advertising Router | 7971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7972 | ... | 7974 Each LSA requested is specified by its LS type, Link State ID, and 7975 Advertising Router. This uniquely identifies the LSA, but not its 7976 instance. Link State Request packets are understood to be requests 7977 for the most recent instance (whatever that might be). 7979 A.3.5 The Link State Update packet 7981 Link State Update packets are OSPF packet type 4. These packets 7982 implement the flooding of LSAs. Each Link State Update packet 7983 carries a collection of LSAs one hop further from their origin. 7984 Several LSAs may be included in a single packet. 7986 Link State Update packets are multicast on those physical networks 7987 that support multicast/broadcast. In order to make the flooding 7988 procedure reliable, flooded LSAs are acknowledged in Link State 7989 Acknowledgment packets. If retransmission of certain LSAs is 7990 necessary, the retransmitted LSAs are always carried by unicast Link 7991 State Update packets. For more information on the reliable flooding 7992 of LSAs, consult Section 13. 7994 0 1 2 3 7995 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 7996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7997 | Version # | 4 | Packet length | 7998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7999 | Router ID | 8000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8001 | Area ID | 8002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8003 | Checksum | AuType | 8004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8005 | Authentication | 8006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8007 | Authentication | 8008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8009 | # LSAs | 8010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8011 | | 8012 +- +-+ 8013 | LSAs | 8014 +- +-+ 8015 | ... | 8017 # LSAs 8018 The number of LSAs included in this update. 8020 The body of the Link State Update packet consists of a list of LSAs. 8021 Each LSA begins with a common 20 byte header, described in Section 8022 A.4.1. Detailed formats of the different types of LSAs are described 8023 in Section A.4. 8025 A.3.6 The Link State Acknowledgment packet 8027 Link State Acknowledgment Packets are OSPF packet type 5. To make 8028 the flooding of LSAs reliable, flooded LSAs are explicitly 8029 acknowledged. This acknowledgment is accomplished through the 8030 sending and receiving of Link State Acknowledgment packets. 8031 Multiple LSAs can be acknowledged in a single Link State 8032 Acknowledgment packet. 8034 Depending on the state of the sending interface and the sender of 8035 the corresponding Link State Update packet, a Link State 8036 Acknowledgment packet is sent either to the multicast address 8037 AllSPFRouters, to the multicast address AllDRouters, or as a 8038 unicast. The sending of Link State Acknowledgement packets is 8039 documented in Section 13.5. The reception of Link State 8040 Acknowledgement packets is documented in Section 13.7. 8042 The format of this packet is similar to that of the Data Description 8043 packet. The body of both packets is simply a list of LSA headers. 8045 0 1 2 3 8046 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 8047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8048 | Version # | 5 | Packet length | 8049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8050 | Router ID | 8051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8052 | Area ID | 8053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8054 | Checksum | AuType | 8055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8056 | Authentication | 8057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8058 | Authentication | 8059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8060 | | 8061 +- -+ 8062 | | 8063 +- An LSA Header -+ 8064 | | 8065 +- -+ 8066 | | 8067 +- -+ 8068 | | 8069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8070 | ... | 8072 Each acknowledged LSA is described by its LSA header. The LSA 8073 header is documented in Section A.4.1. It contains all the 8074 information required to uniquely identify both the LSA and the LSA's 8075 current instance. 8077 A.4 LSA formats 8079 This memo defines five distinct types of LSAs. Each LSA begins with 8080 a standard 20 byte LSA header. This header is explained in Section 8081 A.4.1. Succeeding sections then diagram the separate LSA types. 8083 Each LSA describes a piece of the OSPF routing domain. Every router 8084 originates a router-LSA. In addition, whenever the router is 8085 elected Designated Router, it originates a network-LSA. Other types 8086 of LSAs may also be originated (see Section 12.4). All LSAs are 8087 then flooded throughout the OSPF routing domain. The flooding 8088 algorithm is reliable, ensuring that all routers have the same 8089 collection of LSAs. (See Section 13 for more information concerning 8090 the flooding algorithm). This collection of LSAs is called the 8091 link-state database. 8093 From the link state database, each router constructs a shortest path 8094 tree with itself as root. This yields a routing table (see Section 8095 11). For the details of the routing table build process, see 8096 Section 16. 8098 A.4.1 The LSA header 8100 All LSAs begin with a common 20 byte header. This header contains 8101 enough information to uniquely identify the LSA (LS type, Link State 8102 ID, and Advertising Router). Multiple instances of the LSA may 8103 exist in the routing domain at the same time. It is then necessary 8104 to determine which instance is more recent. This is accomplished by 8105 examining the LS age, LS sequence number and LS checksum fields that 8106 are also contained in the LSA header. 8108 0 1 2 3 8109 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 8110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8111 | LS age | Options | LS type | 8112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8113 | Link State ID | 8114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8115 | Advertising Router | 8116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8117 | LS sequence number | 8118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8119 | LS checksum | length | 8120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8122 LS age 8123 The time in seconds since the LSA was originated. 8125 Options 8126 The optional capabilities supported by the described portion of 8127 the routing domain. OSPF's optional capabilities are documented 8128 in Section A.2. 8130 LS type 8131 The type of the LSA. Each LSA type has a separate advertisement 8132 format. The LSA types defined in this memo are as follows (see 8133 Section 12.1.3 for further explanation): 8135 LS Type Description 8136 ___________________________________ 8137 1 Router-LSAs 8138 2 Network-LSAs 8139 3 Summary-LSAs (IP network) 8140 4 Summary-LSAs (ASBR) 8141 5 AS-external-LSAs 8143 Link State ID 8144 This field identifies the portion of the internet environment 8145 that is being described by the LSA. The contents of this field 8146 depend on the LSA's LS type. For example, in network-LSAs the 8147 Link State ID is set to the IP interface address of the 8148 network's Designated Router (from which the network's IP address 8149 can be derived). The Link State ID is further discussed in 8150 Section 12.1.4. 8152 Advertising Router 8153 The Router ID of the router that originated the LSA. For 8154 example, in network-LSAs this field is equal to the Router ID of 8155 the network's Designated Router. 8157 LS sequence number 8158 Detects old or duplicate LSAs. Successive instances of an LSA 8159 are given successive LS sequence numbers. See Section 12.1.6 8160 for more details. 8162 LS checksum 8163 The Fletcher checksum of the complete contents of the LSA, 8164 including the LSA header but excluding the LS age field. See 8165 Section 12.1.7 for more details. 8167 length 8168 The length in bytes of the LSA. This includes the 20 byte LSA 8169 header. 8171 A.4.2 Router-LSAs 8173 Router-LSAs are the Type 1 LSAs. Each router in an area originates 8174 a router-LSA. The LSA describes the state and cost of the router's 8175 links (i.e., interfaces) to the area. All of the router's links to 8176 the area must be described in a single router-LSA. For details 8177 concerning the construction of router-LSAs, see Section 12.4.1. 8179 0 1 2 3 8180 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 8181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8182 | LS age | Options | 1 | 8183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8184 | Link State ID | 8185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8186 | Advertising Router | 8187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8188 | LS sequence number | 8189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8190 | LS checksum | length | 8191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8192 | 0 |V|E|B| 0 | # links | 8193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8194 | Link ID | 8195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8196 | Link Data | 8197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8198 | Type | # TOS | TOS 0 metric | 8199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8200 | TOS | 0 | metric | 8201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8202 | ... | 8203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8204 | TOS | 0 | metric | 8205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8206 | Link ID | 8207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8208 | Link Data | 8209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8210 | ... | 8212 In router-LSAs, the Link State ID field is set to the router's OSPF 8213 Router ID. The T-bit is set in the LSA's Option field if and only 8214 if the router is able to calculate a separate set of routes for each 8215 IP TOS. Router-LSAs are flooded throughout a single area only. 8217 bit V 8218 When set, the router is an endpoint of one or more fully 8219 adjacent virtual links having the described area as Transit area 8220 (V is for virtual link endpoint). 8222 bit E 8223 When set, the router is an AS boundary router (E is for 8224 external). 8226 bit B 8227 When set, the router is an area border router (B is for border). 8229 # links 8230 The number of router links described in this LSA. This must be 8231 the total collection of router links (i.e., interfaces) to the 8232 area. 8234 The following fields are used to describe each router link (i.e., 8235 interface). Each router link is typed (see the below Type field). 8236 The Type field indicates the kind of link being described. It may 8237 be a link to a transit network, to another router or to a stub 8238 network. The values of all the other fields describing a router 8239 link depend on the link's Type. For example, each link has an 8240 associated 32-bit Link Data field. For links to stub networks this 8241 field specifies the network's IP address mask. For other link types 8242 the Link Data field specifies the router interface's IP address. 8244 Type 8245 A quick description of the router link. One of the following. 8246 Note that host routes are classified as links to stub networks 8247 with network mask of 0xffffffff. 8249 Type Description 8250 __________________________________________________ 8251 1 Point-to-point connection to another router 8252 2 Connection to a transit network 8253 3 Connection to a stub network 8254 4 Virtual link 8256 Link ID 8257 Identifies the object that this router link connects to. Value 8258 depends on the link's Type. When connecting to an object that 8259 also originates an LSA (i.e., another router or a transit 8260 network) the Link ID is equal to the neighboring LSA's Link 8261 State ID. This provides the key for looking up the neighboring 8262 LSA in the link state database during the routing table 8263 calculation. See Section 12.2 for more details. 8265 Type Link ID 8266 ______________________________________ 8267 1 Neighboring router's Router ID 8268 2 IP address of Designated Router 8269 3 IP network/subnet number 8270 4 Neighboring router's Router ID 8272 Link Data 8273 Value again depends on the link's Type field. For connections to 8274 stub networks, Link Data specifies the network's IP address 8275 mask. For unnumbered point-to-point connections, it specifies 8276 the interface's MIB-II [Ref8] ifIndex value. For the other link 8277 types it specifies the router interface's IP address. This 8278 latter piece of information is needed during the routing table 8279 build process, when calculating the IP address of the next hop. 8280 See Section 16.1.1 for more details. 8282 # TOS 8283 The number of different TOS metrics given for this link, not 8284 counting the required metric for TOS 0. For example, if no 8285 additional TOS metrics are given, this field is set to 0. 8287 TOS 0 metric 8288 The cost of using this router link for TOS 0. 8290 For each link, separate metrics may be specified for each Type of 8291 Service (TOS). The metric for TOS 0 must always be included, and 8292 was discussed above. Metrics for non-zero TOS are described below. 8293 The encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8294 that the cost for non-zero TOS values that are not specified 8295 defaults to the TOS 0 cost. Metrics must be listed in order of 8296 increasing TOS encoding. For example, the metric for TOS 16 must 8297 always follow the metric for TOS 8 when both are specified. 8299 TOS IP Type of Service that this metric refers to. The encoding of 8300 TOS in OSPF LSAs is described in Section 12.3. 8302 metric 8303 The cost of using this outbound router link, for traffic of the 8304 specified TOS. 8306 A.4.3 Network-LSAs 8308 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 8309 each broadcast and NBMA network in the area which supports two or 8310 more routers. The network-LSA is originated by the network's 8311 Designated Router. The LSA describes all routers attached to the 8312 network, including the Designated Router itself. The LSA's Link 8313 State ID field lists the IP interface address of the Designated 8314 Router. 8316 The distance from the network to all attached routers is zero, for 8317 all Types of Service. This is why the TOS and metric fields need 8318 not be specified in the network-LSA. For details concerning the 8319 construction of network-LSAs, see Section 12.4.2. 8321 0 1 2 3 8322 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 8323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8324 | LS age | Options | 2 | 8325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8326 | Link State ID | 8327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8328 | Advertising Router | 8329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8330 | LS sequence number | 8331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8332 | LS checksum | length | 8333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8334 | Network Mask | 8335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8336 | Attached Router | 8337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8338 | ... | 8340 Network Mask 8341 The IP address mask for the network. For example, a class A 8342 network would have the mask 0xff000000. 8344 Attached Router 8345 The Router IDs of each of the routers attached to the network. 8346 Actually, only those routers that are fully adjacent to the 8347 Designated Router are listed. The Designated Router includes 8348 itself in this list. The number of routers included can be 8349 deduced from the LSA header's length field. 8351 A.4.4 Summary-LSAs 8353 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated 8354 by area border routers. Summary-LSAs describe inter-area 8355 destinations. For details concerning the construction of summary- 8356 LSAs, see Section 12.4.3. 8358 Type 3 summary-LSAs are used when the destination is an IP network. 8359 In this case the LSA's Link State ID field is an IP network number 8360 (if necessary, the Link State ID can also have one or more of the 8361 network's "host" bits set; see Appendix E for details). When the 8362 destination is an AS boundary router, a Type 4 summary-LSA is used, 8363 and the Link State ID field is the AS boundary router's OSPF Router 8364 ID. (To see why it is necessary to advertise the location of each 8365 ASBR, consult Section 16.4.) Other than the difference in the Link 8366 State ID field, the format of Type 3 and 4 summary-LSAs is 8367 identical. 8369 0 1 2 3 8370 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 8371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8372 | LS age | Options | 3 or 4 | 8373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8374 | Link State ID | 8375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8376 | Advertising Router | 8377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8378 | LS sequence number | 8379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8380 | LS checksum | length | 8381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8382 | Network Mask | 8383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8384 | TOS | metric | 8385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8386 | ... | 8388 For stub areas, Type 3 summary-LSAs can also be used to describe a 8389 (per-area) default route. Default summary routes are used in stub 8390 areas instead of flooding a complete set of external routes. When 8391 describing a default summary route, the summary-LSA's Link State ID 8392 is always set to DefaultDestination (0.0.0.0) and the Network Mask 8393 is set to 0.0.0.0. 8395 Separate costs may be advertised for each IP Type of Service. The 8396 encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8397 that the cost for TOS 0 must be included, and is always listed 8398 first. If the T-bit is reset in the LSA's Option field, only a 8399 route for TOS 0 is described by the LSA. Otherwise, routes for the 8400 other TOS values are also described; if a cost for a certain TOS is 8401 not included, its cost defaults to that specified for TOS 0. 8403 Network Mask 8404 For Type 3 summary-LSAs, this indicates the destination 8405 network's IP address mask. For example, when advertising the 8406 location of a class A network the value 0xff000000 would be 8407 used. This field is not meaningful and must be zero for Type 4 8408 summary-LSAs. 8410 For each specified Type of Service, the following fields are 8411 defined. The number of TOS routes included can be calculated from 8412 the LSA header's length field. A value for TOS 0 must be specified; 8413 it is listed first. Other values must be listed in order of 8414 increasing TOS encoding. For example, the cost for TOS 16 must 8415 always follow the cost for TOS 8 when both are specified. 8417 TOS The Type of Service that the following cost concerns. The 8418 encoding of TOS in OSPF LSAs is described in Section 12.3. 8420 metric 8421 The cost of this route. Expressed in the same units as the 8422 interface costs in the router-LSAs. 8424 A.4.5 AS-external-LSAs 8426 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 8427 AS boundary routers, and describe destinations external to the AS. 8428 For details concerning the construction of AS-external-LSAs, see 8429 Section 12.4.3. 8431 AS-external-LSAs usually describe a particular external destination. 8432 For these LSAs the Link State ID field specifies an IP network 8433 number (if necessary, the Link State ID can also have one or more of 8434 the network's "host" bits set; see Appendix E for details). AS- 8435 external-LSAs are also used to describe a default route. Default 8436 routes are used when no specific route exists to the destination. 8437 When describing a default route, the Link State ID is always set to 8438 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8440 0 1 2 3 8441 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 8442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8443 | LS age | Options | 5 | 8444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8445 | Link State ID | 8446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8447 | Advertising Router | 8448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8449 | LS sequence number | 8450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8451 | LS checksum | length | 8452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8453 | Network Mask | 8454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8455 |E| TOS | metric | 8456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8457 | Forwarding address | 8458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8459 | External Route Tag | 8460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8461 | ... | 8463 Separate costs may be advertised for each IP Type of Service. The 8464 encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8465 that the cost for TOS 0 must be included, and is always listed 8466 first. If the T-bit is reset in the LSA's Option field, only a 8467 route for TOS 0 is described by the LSA. Otherwise, routes for the 8468 other TOS values are also described; if a cost for a certain TOS is 8469 not included, its cost defaults to that specified for TOS 0. 8471 Network Mask 8472 The IP address mask for the advertised destination. For 8473 example, when advertising a class A network the mask 0xff000000 8474 would be used. 8476 For each specified Type of Service, the following fields are 8477 defined. The number of TOS routes included can be calculated from 8478 the LSA header's length field. A value for TOS 0 must be specified; 8479 it is listed first. Other values must be listed in order of 8480 increasing TOS encoding. For example, the cost for TOS 16 must 8481 always follow the cost for TOS 8 when both are specified. 8483 TOS The Type of Service that the following fields concern. The 8484 encoding of TOS in OSPF LSAs is described in Section 12.3. 8486 bit E 8487 The type of external metric. If bit E is set, the metric 8488 specified is a Type 2 external metric. This means the metric is 8489 considered larger than any link state path. If bit E is zero, 8490 the specified metric is a Type 1 external metric. This means 8491 that it is expressed in the same units as the link state metric 8492 (i.e., the same units as interface cost). 8494 metric 8495 The cost of this route. Interpretation depends on the external 8496 type indication (bit E above). 8498 Forwarding address 8499 Data traffic for the advertised destination and TOS will be 8500 forwarded to this address. If the Forwarding address is set to 8501 0.0.0.0, data traffic will be forwarded instead to the LSA's 8502 originator (i.e., the responsible AS boundary router). 8504 External Route Tag 8505 A 32-bit field attached to each external route. This is not 8506 used by the OSPF protocol itself. It may be used to communicate 8507 information between AS boundary routers; the precise nature of 8508 such information is outside the scope of this specification. 8510 B. Architectural Constants 8512 Several OSPF protocol parameters have fixed architectural values. 8513 These parameters have been referred to in the text by names such as 8514 LSRefreshTime. The same naming convention is used for the 8515 configurable protocol parameters. They are defined in Appendix C. 8517 The name of each architectural constant follows, together with its 8518 value and a short description of its function. 8520 LSRefreshTime 8521 The maximum time between distinct originations of any particular 8522 LSA. If the LS age field of one of the router's self-originated 8523 LSAs reaches the value LSRefreshTime, a new instance of the LSA 8524 is originated, even though the contents of the LSA (apart from 8525 the LSA header) will be the same. The value of LSRefreshTime is 8526 set to 30 minutes. 8528 MinLSInterval 8529 The minimum time between distinct originations of any particular 8530 LSA. The value of MinLSInterval is set to 5 seconds. 8532 MinLSArrival 8533 For any particular LSA, the minimum time that must elapse 8534 between reception of new LSA instances during flooding. LSA 8535 instances received at higher frequencies are discarded. The 8536 value of MinLSArrival is set to 1 second. 8538 MaxAge 8539 The maximum age that an LSA can attain. When an LSA's LS age 8540 field reaches MaxAge, it is reflooded in an attempt to flush the 8541 LSA from the routing domain (See Section 14). LSAs of age MaxAge 8542 are not used in the routing table calculation. The value of 8543 MaxAge is set to 1 hour. 8545 CheckAge 8546 When the age of an LSA in the link state database hits a 8547 multiple of CheckAge, the LSA's checksum is verified. An 8548 incorrect checksum at this time indicates a serious error. The 8549 value of CheckAge is set to 5 minutes. 8551 MaxAgeDiff 8552 The maximum time dispersion that can occur, as an LSA is flooded 8553 throughout the AS. Most of this time is accounted for by the 8554 LSAs sitting on router output queues (and therefore not aging) 8555 during the flooding process. The value of MaxAgeDiff is set to 8556 15 minutes. 8558 LSInfinity 8559 The metric value indicating that the destination described by an 8560 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as 8561 an alternative to premature aging (see Section 14.1). It is 8562 defined to be the 24-bit binary value of all ones: 0xffffff. 8564 DefaultDestination 8565 The Destination ID that indicates the default route. This route 8566 is used when no other matching routing table entry can be found. 8567 The default destination can only be advertised in AS-external- 8568 LSAs and in stub areas' type 3 summary-LSAs. Its value is the 8569 IP address 0.0.0.0. Its associated Network Mask is also always 8570 0.0.0.0. 8572 InitialSequenceNumber 8573 The value used for LS Sequence Number when originating the first 8574 instance of any LSA. Its value is the signed 32-bit integer 8575 0x80000001. 8577 MaxSequenceNumber 8578 The maximum value that LS Sequence Number can attain. Its value 8579 is the signed 32-bit integer 0x7fffffff. 8581 C. Configurable Constants 8583 The OSPF protocol has quite a few configurable parameters. These 8584 parameters are listed below. They are grouped into general 8585 functional categories (area parameters, interface parameters, etc.). 8586 Sample values are given for some of the parameters. 8588 Some parameter settings need to be consistent among groups of 8589 routers. For example, all routers in an area must agree on that 8590 area's parameters, and all routers attached to a network must agree 8591 on that network's IP network number and mask. 8593 Some parameters may be determined by router algorithms outside of 8594 this specification (e.g., the address of a host connected to the 8595 router via a SLIP line). From OSPF's point of view, these items are 8596 still configurable. 8598 C.1 Global parameters 8600 In general, a separate copy of the OSPF protocol is run for each 8601 area. Because of this, most configuration parameters are 8602 defined on a per-area basis. The few global configuration 8603 parameters are listed below. 8605 Router ID 8606 This is a 32-bit number that uniquely identifies the router 8607 in the Autonomous System. One algorithm for Router ID 8608 assignment is to choose the largest or smallest IP address 8609 assigned to the router. If a router's OSPF Router ID is 8610 changed, the router's OSPF software should be restarted 8611 before the new Router ID takes effect. Before restarting in 8612 order to change its Router ID, the router should flush its 8613 self-originated LSAs from the routing domain (see Section 8614 14.1), or they will persist for up to MaxAge minutes. 8616 TOS capability 8617 This item indicates whether the router will calculate 8618 separate routes based on TOS. For more information, see 8619 Sections 4.5 and 16.9. 8621 C.2 Area parameters 8623 All routers belonging to an area must agree on that area's 8624 configuration. Disagreements between two routers will lead to 8625 an inability for adjacencies to form between them, with a 8626 resulting hindrance to the flow of routing protocol and data 8627 traffic. The following items must be configured for an area: 8629 Area ID 8630 This is a 32-bit number that identifies the area. The Area 8631 ID of 0.0.0.0 is reserved for the backbone. If the area 8632 represents a subnetted network, the IP network number of the 8633 subnetted network may be used for the Area ID. 8635 List of address ranges 8636 An OSPF area is defined as a list of address ranges. Each 8637 address range consists of the following items: 8639 [IP address, mask] 8640 Describes the collection of IP addresses contained 8641 in the address range. Networks and hosts are 8642 assigned to an area depending on whether their 8643 addresses fall into one of the area's defining 8644 address ranges. Routers are viewed as belonging to 8645 multiple areas, depending on their attached 8646 networks' area membership. 8648 Status Set to either Advertise or DoNotAdvertise. Routing 8649 information is condensed at area boundaries. 8650 External to the area, at most a single route is 8651 advertised (via a summary-LSA) for each address 8652 range. The route is advertised if and only if the 8653 address range's Status is set to Advertise. 8654 Unadvertised ranges allow the existence of certain 8655 networks to be intentionally hidden from other 8656 areas. Status is set to Advertise by default. 8658 As an example, suppose an IP subnetted network is to be its 8659 own OSPF area. The area would be configured as a single 8660 address range, whose IP address is the address of the 8661 subnetted network, and whose mask is the natural class A, B, 8662 or C address mask. A single route would be advertised 8663 external to the area, describing the entire subnetted 8664 network. 8666 ExternalRoutingCapability 8667 Whether AS-external-LSAs will be flooded into/throughout the 8668 area. If AS-external-LSAs are excluded from the area, the 8669 area is called a "stub". Internal to stub areas, routing to 8670 external destinations will be based solely on a default 8671 summary route. The backbone cannot be configured as a stub 8672 area. Also, virtual links cannot be configured through stub 8673 areas. For more information, see Section 3.6. 8675 StubDefaultCost 8676 If the area has been configured as a stub area, and the 8677 router itself is an area border router, then the 8678 StubDefaultCost indicates the cost of the default summary- 8679 LSA that the router should advertise into the area. There 8680 can be a separate cost configured for each IP TOS. See 8681 Section 12.4.3 for more information. 8683 C.3 Router interface parameters 8685 Some of the configurable router interface parameters (such as IP 8686 interface address and subnet mask) actually imply properties of 8687 the attached networks, and therefore must be consistent across 8688 all the routers attached to that network. The parameters that 8689 must be configured for a router interface are: 8691 IP interface address 8692 The IP protocol address for this interface. This uniquely 8693 identifies the router over the entire internet. An IP 8694 address is not required on point-to-point networks. Such a 8695 point-to-point network is called "unnumbered". 8697 IP interface mask 8698 Also referred to as the subnet/network mask, this indicates 8699 the portion of the IP interface address that identifies the 8700 attached network. Masking the IP interface address with the 8701 IP interface mask yields the IP network number of the 8702 attached network. On point-to-point networks and virtual 8703 links, the IP interface mask is not defined. On these 8704 networks, the link itself is not assigned an IP network 8705 number, and so the addresses of each side of the link are 8706 assigned independently, if they are assigned at all. 8708 Area ID 8709 The OSPF area to which the attached network belongs. 8711 Interface output cost(s) 8712 The cost of sending a packet on the interface, expressed in 8713 the link state metric. This is advertised as the link cost 8714 for this interface in the router's router-LSA. There may be 8715 a separate cost for each IP Type of Service. The interface 8716 output cost(s) must always be greater than 0. 8718 RxmtInterval 8719 The number of seconds between LSA retransmissions, for 8720 adjacencies belonging to this interface. Also used when 8721 retransmitting Database Description and Link State Request 8722 Packets. This should be well over the expected round-trip 8723 delay between any two routers on the attached network. The 8724 setting of this value should be conservative or needless 8725 retransmissions will result. Sample value for a local area 8726 network: 5 seconds. 8728 InfTransDelay 8729 The estimated number of seconds it takes to transmit a Link 8730 State Update Packet over this interface. LSAs contained in 8731 the update packet must have their age incremented by this 8732 amount before transmission. This value should take into 8733 account the transmission and propagation delays of the 8734 interface. It must be greater than 0. Sample value for a 8735 local area network: 1 second. 8737 Router Priority 8738 An 8-bit unsigned integer. When two routers attached to a 8739 network both attempt to become Designated Router, the one 8740 with the highest Router Priority takes precedence. If there 8741 is still a tie, the router with the highest Router ID takes 8742 precedence. A router whose Router Priority is set to 0 is 8743 ineligible to become Designated Router on the attached 8744 network. Router Priority is only configured for interfaces 8745 to broadcast and NBMA networks. 8747 HelloInterval 8748 The length of time, in seconds, between the Hello Packets 8749 that the router sends on the interface. This value is 8750 advertised in the router's Hello Packets. It must be the 8751 same for all routers attached to a common network. The 8752 smaller the HelloInterval, the faster topological changes 8753 will be detected; however, more OSPF routing protocol 8754 traffic will ensue. Sample value for a X.25 PDN network: 30 8755 seconds. Sample value for a local area network: 10 seconds. 8757 RouterDeadInterval 8758 After ceasing to hear a router's Hello Packets, the number 8759 of seconds before its neighbors declare the router down. 8760 This is also advertised in the router's Hello Packets in 8761 their RouterDeadInterval field. This should be some 8762 multiple of the HelloInterval (say 4). This value again 8763 must be the same for all routers attached to a common 8764 network. 8766 AuType 8767 Identifies the authentication procedure to be used on the 8768 attached network. This value must be the same for all 8769 routers attached to the network. See Appendix D for a 8770 discussion of the defined authentication types. 8772 Authentication key 8773 This configured data allows the authentication procedure to 8774 verify OSPF protocol packets received over the interface. 8775 For example, if the AuType indicates simple password, the 8776 Authentication key would be a clear 64-bit password. 8777 Authentication keys associated with the other OSPF 8778 authentication types are discussed in Appendix D. 8780 C.4 Virtual link parameters 8782 Virtual links are used to restore/increase connectivity of the 8783 backbone. Virtual links may be configured between any pair of 8784 area border routers having interfaces to a common (non-backbone) 8785 area. The virtual link appears as an unnumbered point-to-point 8786 link in the graph for the backbone. The virtual link must be 8787 configured in both of the area border routers. 8789 A virtual link appears in router-LSAs (for the backbone) as if 8790 it were a separate router interface to the backbone. As such, 8791 it has all of the parameters associated with a router interface 8792 (see Section C.3). Although a virtual link acts like an 8793 unnumbered point-to-point link, it does have an associated IP 8794 interface address. This address is used as the IP source in 8795 OSPF protocol packets it sends along the virtual link, and is 8796 set dynamically during the routing table build process. 8797 Interface output cost is also set dynamically on virtual links 8798 to be the cost of the intra-area path between the two routers. 8799 The parameter RxmtInterval must be configured, and should be 8800 well over the expected round-trip delay between the two routers. 8801 This may be hard to estimate for a virtual link; it is better to 8802 err on the side of making it too large. Router Priority is not 8803 used on virtual links. 8805 A virtual link is defined by the following two configurable 8806 parameters: the Router ID of the virtual link's other endpoint, 8807 and the (non-backbone) area through which the virtual link runs 8808 (referred to as the virtual link's Transit area). Virtual links 8809 cannot be configured through stub areas. 8811 C.5 NBMA network parameters 8813 OSPF treats an NBMA network much like it treats a broadcast 8814 network. Since there may be many routers attached to the 8815 network, a Designated Router is selected for the network. This 8816 Designated Router then originates a network-LSA, which lists all 8817 routers attached to the NBMA network. 8819 However, due to the lack of broadcast capabilities, it may be 8820 necessary to use configuration parameters in the Designated 8821 Router selection. These parameters will only need to be 8822 configured in those routers that are themselves eligible to 8823 become Designated Router (i.e., those router's whose Router 8824 Priority for the network is non-zero), and then only if no 8825 automatic procedure for discovering neighbors exists: 8827 List of all other attached routers 8828 The list of all other routers attached to the NBMA network. 8829 Each router is listed by its IP interface address on the 8830 network. Also, for each router listed, that router's 8831 eligibility to become Designated Router must be defined. 8832 When an interface to a NBMA network comes up, the router 8833 sends Hello Packets only to those neighbors eligible to 8834 become Designated Router, until the identity of the 8835 Designated Router is discovered. 8837 PollInterval 8838 If a neighboring router has become inactive (Hello Packets 8839 have not been seen for RouterDeadInterval seconds), it may 8840 still be necessary to send Hello Packets to the dead 8841 neighbor. These Hello Packets will be sent at the reduced 8842 rate PollInterval, which should be much larger than 8843 HelloInterval. Sample value for a PDN X.25 network: 2 8844 minutes. 8846 C.6 Point-to-MultiPoint network parameters 8848 On Point-to-MultiPoint networks, it may be necessary to 8849 configure the set of neighbors that are directly reachable over 8850 the Point-to-MultiPoint network. Each neighbor is identified by 8851 its IP address on the Point-to-MultiPoint network. Designated 8852 Routers are not elected on Point-to-MultiPoint networks, so the 8853 Designated Router eligibility of configured neighbors is 8854 undefined. 8856 Alternatively, neighbors on Point-to-MultiPoint networks may be 8857 dynamically discovered by lower-level protocols such as Inverse 8858 ARP ([Ref14]). 8860 C.7 Host route parameters 8862 Host routes are advertised in router-LSAs as stub networks with 8863 mask 0xffffffff. They indicate either router interfaces to 8864 point-to-point networks, looped router interfaces, or IP hosts 8865 that are directly connected to the router (e.g., via a SLIP 8866 line). For each host directly connected to the router, the 8867 following items must be configured: 8869 Host IP address 8870 The IP address of the host. 8872 Cost of link to host 8873 The cost of sending a packet to the host, in terms of the 8874 link state metric. There may be multiple costs configured, 8875 one for each IP TOS. However, since the host probably has 8876 only a single connection to the internet, the actual 8877 configured cost(s) in many cases is unimportant (i.e., will 8878 have no effect on routing). 8880 Area ID 8881 The OSPF area to which the host belongs. 8883 D. Authentication 8885 All OSPF protocol exchanges are authenticated. The OSPF packet 8886 header (see Section A.3.1) includes an authentication type field, 8887 and 64-bits of data for use by the appropriate authentication scheme 8888 (determined by the type field). 8890 The authentication type is configurable on a per-interface (or 8891 equivalently, on a per-network/subnet) basis. Additional 8892 authentication data is also configurable on a per-interface basis. 8894 Authentication types 0, 1 and 2 are defined by this specification. 8895 All other authentication types are reserved for definition by the 8896 IANA (iana@ISI.EDU). The current list of authentication types is 8897 described below in Table 20. 8899 AuType Description 8900 ___________________________________________ 8901 0 Null authentication 8902 1 Simple password 8903 2 Cryptographic authentication 8904 All others Reserved for assignment by the 8905 IANA (iana@ISI.EDU) 8907 Table 20: OSPF authentication types. 8909 D.1 Null authentication 8911 Use of this authentication type means that routing exchanges 8912 over the network/subnet are not authenticated. The 64-bit 8913 authentication field in the OSPF header can contain anything; it 8914 is not examined on packet reception. When employing Null 8915 authentication, the entire contents of each OSPF packet (other 8916 than the 64-bit authentication field) are checksummed in order 8917 to detect data corruption. 8919 D.2 Simple password authentication 8921 Using this authentication type, a 64-bit field is configured on 8922 a per-network basis. All packets sent on a particular network 8923 must have this configured value in their OSPF header 64-bit 8924 authentication field. This essentially serves as a "clear" 64- 8925 bit password. In addition, the entire contents of each OSPF 8926 packet (other than the 64-bit authentication field) are 8927 checksummed in order to detect data corruption. 8929 Simple password authentication guards against routers 8930 inadvertently joining the routing domain; each router must first 8931 be configured with its attached networks' passwords before it 8932 can participate in routing. However, simple password 8933 authentication is vulnerable to passive attacks currently 8934 widespread in the Internet (see [Ref16]). Anyone with physical 8935 access to the network can learn the password and compromise the 8936 security of the OSPF routing domain. 8938 D.3 Cryptographic authentication 8940 Using this authentication type, a shared secret key is 8941 configured in all routers attached to a common network/subnet. 8942 For each OSPF protocol packet, the key is used to 8943 generate/verify a "message digest" that is appended to the end 8944 of the OSPF packet. The message digest is a one-way function of 8945 the OSPF protocol packet and the secret key. Since the secret 8946 key is never sent over the network in the clear, protection is 8947 provided against passive attacks. 8949 The algorithms used to generate and verify the message digest 8950 are specified implicitly by the secret key. This specification 8951 completely defines the use of OSPF Cryptographic authentication 8952 when the MD5 algorithm is used. 8954 In addition, a non-decreasing sequence number is included in 8955 each OSPF protocol packet to protect against replay attacks. 8956 This provides long term protection; however, it is still 8957 possible to replay an OSPF packet until the sequence number 8958 changes. To implement this feature, each neighbor data structure 8960 0 1 2 3 8961 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 8962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8963 | 0 | Key ID | Auth Data Len | 8964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8965 | Cryptographic sequence number | 8966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8968 Figure 18: Usage of the Authentication field 8969 in the OSPF packet header when Cryptographic 8970 Authentication is employed 8971 contains a new field called the "cryptographic sequence number". 8972 This field is initialized to zero, and is also set to zero 8973 whenever the neighbor's state transitions to "Down". Whenever an 8974 OSPF packet is accepted as authentic, the cryptographic sequence 8975 number is set to the received packet's sequence number. 8977 The OSPF Cryptographic authentication option does not provide 8978 confidentiality. 8980 When cryptographic authentication is used, the 64-bit 8981 Authentication field in the standard OSPF packet header is 8982 redefined as shown in Figure 18. The new field definitions are 8983 as follows: 8985 Key ID 8986 This field identifies the algorithm and secret key used to 8987 create the message digest appended to the OSPF packet. Key 8988 Identifiers are unique per-interface (or equivalently, per- 8989 subnet). 8991 Auth Data Len 8992 The length in bytes of the message digest appended to the 8993 OSPF packet. 8995 Cryptographic sequence number 8996 An unsigned 32-bit non-decreasing sequence number. Used to 8997 guard against replay attacks. 8999 The message digest appended to the OSPF packet is not actually 9000 considered part of the OSPF protocol packet: the message digest 9001 is not included in the OSPF header's packet length, although it 9002 is included in the packet's IP header length field. 9004 Each key is identified by the combination of interface and Key 9005 ID. An interface may have multiple keys active at any one time. 9006 This enables smooth transition from one key to another. Each key 9007 has four time constants associated with it. These time constants 9008 can be expressed in terms of a time-of-day clock, or in terms of 9009 a router's local clock (e.g., number of seconds since last 9010 reboot): 9012 KeyStartAccept 9013 The time that the router will start accepting packets that 9014 have been created with the given key. 9016 KeyStartGenerate 9017 The time that the router will start using the key for packet 9018 generation. 9020 KeyStopGenerate 9021 The time that the router will stop using the key for packet 9022 generation. 9024 KeyStopAccept 9025 The time that the router will stop accepting packets that 9026 have been created with the given key. 9028 In order to achieve smooth key transition, KeyStartAccept should 9029 be less than KeyStartGenerate and KeyStopGenerate should be less 9030 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are 9031 left unspecified, the key's lifetime is infinite. When a new key 9032 replaces an old, the KeyStartGenerate time for the new key must 9033 be less than or equal to the KeyStopGenerate time of the old 9034 key. 9036 Key storage should persist across a system restart, warm or 9037 cold, to avoid operational issues. In the event that the last 9038 key associated with an interface expires, it is unacceptable to 9039 revert to an unauthenticated condition, and not advisable to 9040 disrupt routing. Therefore, the router should send a "last 9041 authentication key expiration" notification to the network 9042 manager and treat the key as having an infinite lifetime until 9043 the lifetime is extended, the key is deleted by network 9044 management, or a new key is configured. 9046 D.4 Message generation 9048 After building the contents of an OSPF packet, the 9049 authentication procedure indicated by the sending interface's 9050 Autype value is called before the packet is sent. The 9051 authentication procedure modifies the OSPF packet as follows. 9053 D.4.1 Generating Null authentication 9055 When using Null authentication, the packet is modified as 9056 follows: 9058 (1) The Autype field in the standard OSPF header is set to 9059 0. 9061 (2) The checksum field in the standard OSPF header is set to 9062 the standard IP checksum of the entire contents of the 9063 packet, starting with the OSPF packet header but 9064 excluding the 64-bit authentication field. This 9065 checksum is calculated as the 16-bit one's complement of 9066 the one's complement sum of all the 16-bit words in the 9067 packet, excepting the authentication field. If the 9068 packet's length is not an integral number of 16-bit 9069 words, the packet is padded with a byte of zero before 9070 checksumming. 9072 D.4.2 Generating Simple password authentication 9074 When using Simple password authentication, the packet is 9075 modified as follows: 9077 (1) The Autype field in the standard OSPF header is set to 9078 1. 9080 (2) The checksum field in the standard OSPF header is set to 9081 the standard IP checksum of the entire contents of the 9082 packet, starting with the OSPF packet header but 9083 excluding the 64-bit authentication field. This 9084 checksum is calculated as the 16-bit one's complement of 9085 the one's complement sum of all the 16-bit words in the 9086 packet, excepting the authentication field. If the 9087 packet's length is not an integral number of 16-bit 9088 words, the packet is padded with a byte of zero before 9089 checksumming. 9091 (3) The 64-bit authentication field in the OSPF packet 9092 header is set to the 64-bit password (i.e., 9093 authentication key) that has been configured for the 9094 interface. 9096 D.4.3 Generating Cryptographic authentication 9098 When using Cryptographic authentication, there may be 9099 multiple keys configured for the interface. In this case, 9100 among the keys that are valid for message generation (i.e, 9101 that have KeyStartGenerate <= current time < 9102 KeyStopGenerate) choose the one with the most recent 9103 KeyStartGenerate time. Using this key, modify the packet as 9104 follows: 9106 (1) The Autype field in the standard OSPF header is set to 9107 2. 9109 (2) The checksum field in the standard OSPF header is not 9110 calculated, but is instead set to 0. 9112 (3) The Key ID (see Figure 18) is set to the chosen key's 9113 Key ID. 9115 (4) The Auth Data Len field is set to the length in bytes of 9116 the message digest that will be appended to the OSPF 9117 packet. When using MD5 as the authentication algorithm, 9118 Auth Data Len will be 16. 9120 (5) The 32-bit Cryptographic sequence number (see Figure 18) 9121 is set to a non-decreasing value (i.e., a value at least 9122 as large as the last value sent out the interface). The 9123 precise values to use in the cryptographic sequence 9124 number field are implementation-specific. For example, 9125 it may be based on a simple counter, or be based on the 9126 system's clock. 9128 (6) The message digest is then calculated and appended to 9129 the OSPF packet. The authentication algorithm to be 9130 used in calculating the digest is indicated by the key 9131 itself. Input to the authentication algorithm consists 9132 of the OSPF packet and the secret key. When using MD5 as 9133 the authentication algorithm, the message digest 9134 calculation proceeds as follows: 9136 (a) The 16 byte MD5 key is appended to the OSPF packet. 9138 (b) Trailing pad and length fields are added, as 9139 specified in [Ref17]. 9141 (c) The MD5 authentication algorithm is run over the 9142 concatenation of the OSPF packet, secret key, pad 9143 and length fields, producing a 16 byte message 9144 digest (see [Ref17]). 9146 (d) The MD5 digest is written over the OSPF key (i.e., 9147 appended to the original OSPF packet). The digest is 9148 not counted in the OSPF packet's length field, but 9149 is included in the packet's IP length field. Any 9150 trailing pad or length fields beyond the digest are 9151 not counted or transmitted. 9153 D.5 Message verification 9155 When an OSPF packet has been received on an interface, it must 9156 be authenticated. The authentication procedure is indicated by 9157 the setting of Autype in the standard OSPF packet header, which 9158 matches the setting of Autype for the receiving OSPF interface. 9160 If an OSPF protocol packet is accepted as authentic, processing 9161 of the packet continues as specified in Section 8.2. Packets 9162 which fail authentication are discarded. 9164 D.5.1 Verifying Null authentication 9166 When using Null authentication, the checksum field in the 9167 OSPF header must be verified. It must be set to the 16-bit 9168 one's complement of the one's complement sum of all the 16- 9169 bit words in the packet, excepting the authentication field. 9170 (If the packet's length is not an integral number of 16-bit 9171 words, the packet is padded with a byte of zero before 9172 checksumming.) 9174 D.5.2 Verifying Simple password authentication 9176 When using Simple password authentication, the received OSPF 9177 packet is authenticated as follows: 9179 (1) The checksum field in the OSPF header must be verified. 9180 It must be set to the 16-bit one's complement of the 9181 one's complement sum of all the 16-bit words in the 9182 packet, excepting the authentication field. (If the 9183 packet's length is not an integral number of 16-bit 9184 words, the packet is padded with a byte of zero before 9185 checksumming.) 9187 (2) The 64-bit authentication field in the OSPF packet 9188 header must be equal to the 64-bit password (i.e., 9189 authentication key) that has been configured for the 9190 interface. 9192 D.5.3 Verifying Cryptographic authentication 9194 When using Cryptographic authentication, the received OSPF 9195 packet is authenticated as follows: 9197 (1) Locate the receiving interface's configured key having 9198 Key ID equal to that specified in the received OSPF 9199 packet (see Figure 18). If the key is not found, or if 9200 the key is not valid for reception (i.e., current time < 9201 KeyStartAccept or current time >= KeyStopAccept), the 9202 OSPF packet is discarded. 9204 (2) If the cryptographic sequence number found in the OSPF 9205 header (see Figure 18) is less than the cryptographic 9206 sequence number recorded in the sending neighbor's data 9207 structure, the OSPF packet is discarded. 9209 (3) Verify the appended message digest in the following 9210 steps: 9212 (a) The received digest is set aside. 9214 (b) A new digest is calculated, as specified in Step 6 9215 of Section D.4.3. 9217 (c) The calculated and received digests are compared. If 9218 they do not match, the OSPF packet is discarded. If 9219 they do match, the OSPF protocol packet is accepted 9220 as authentic, and the "cryptographic sequence 9221 number" in the neighbor's data structure is set to 9222 the sequence number found in the packet's OSPF 9223 header. 9225 E. An algorithm for assigning Link State IDs 9227 The Link State ID in AS-external-LSAs and summary-LSAs is usually 9228 set to the described network's IP address. However, if necessary one 9229 or more of the network's host bits may be set in the Link State ID. 9230 This allows the router to originate separate LSAs for networks 9231 having the same address, yet different masks. Such networks can 9232 occur in the presence of supernetting and subnet 0s (see [Ref10]). 9234 This appendix gives one possible algorithm for setting the host bits 9235 in Link State IDs. The choice of such an algorithm is a local 9236 decision. Separate routers are free to use different algorithms, 9237 since the only LSAs affected are the ones that the router itself 9238 originates. The only requirement on the algorithms used is that the 9239 network's IP address should be used as the Link State ID whenever 9240 possible; this maximizes interoperability with OSPF implementations 9241 predating RFC 1583. 9243 The algorithm below is stated for AS-external-LSAs. This is only 9244 for clarity; the exact same algorithm can be used for summary-LSAs. 9245 Suppose that the router wishes to originate an AS-external-LSA for a 9246 network having address NA and mask NM1. The following steps are then 9247 used to determine the LSA's Link State ID: 9249 (1) Determine whether the router is already originating an AS- 9250 external-LSA with Link State ID equal to NA (in such an LSA the 9251 router itself will be listed as the LSA's Advertising Router). 9252 If not, the Link State ID is set equal to NA and the algorithm 9253 terminates. Otherwise, 9255 (2) Obtain the network mask from the body of the already existing 9256 AS-external-LSA. Call this mask NM2. There are then two cases: 9258 o NM1 is longer (i.e., more specific) than NM2. In this case, 9259 set the Link State ID in the new LSA to be the network 9260 [NA,NM1] with all the host bits set (i.e., equal to NA or'ed 9261 together with all the bits that are not set in NM1, which is 9262 network [NA,NM1]'s broadcast address). 9264 o NM2 is longer than NM1. In this case, change the existing 9265 LSA (having Link State ID of NA) to reference the new 9266 network [NA,NM1] by incrementing the sequence number, 9267 changing the mask in the body to NM1 and inserting the cost 9268 of the new network. Then originate a new LSA for the old 9269 network [NA,NM2], with Link State ID equal to NA or'ed 9270 together with the bits that are not set in NM2 (i.e., 9271 network [NA,NM2]'s broadcast address). 9273 The above algorithm assumes that all masks are contiguous; this 9274 ensures that when two networks have the same address, one mask is 9275 more specific than the other. The algorithm also assumes that no 9276 network exists having an address equal to another network's 9277 broadcast address. Given these two assumptions, the above algorithm 9278 always produces unique Link State IDs. The above algorithm can also 9279 be reworded as follows: When originating an AS-external-LSA, try to 9280 use the network number as the Link State ID. If that produces a 9281 conflict, examine the two networks in conflict. One will be a subset 9282 of the other. For the less specific network, use the network number 9283 as the Link State ID and for the more specific use the network's 9284 broadcast address instead (i.e., flip all the "host" bits to 1). If 9285 the most specific network was originated first, this will cause you 9286 to originate two LSAs at once. 9288 As an example of the algorithm, consider its operation when the 9289 following sequence of events occurs in a single router (Router A). 9291 (1) Router A wants to originate an AS-external-LSA for 9292 [10.0.0.0,255.255.255.0]: 9294 (a) A Link State ID of 10.0.0.0 is used. 9296 (2) Router A then wants to originate an AS-external-LSA for 9297 [10.0.0.0,255.255.0.0]: 9299 (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a 9300 new Link State ID of 10.0.0.255. 9302 (b) A Link State ID of 10.0.0.0 is used for 9303 [10.0.0.0,255.255.0.0]. 9305 (3) Router A then wants to originate an AS-external-LSA for 9306 [10.0.0.0,255.0.0.0]: 9308 (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a 9309 new Link State ID of 10.0.255.255. 9311 (b) A Link State ID of 10.0.0.0 is used for 9312 [10.0.0.0,255.0.0.0]. 9314 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID 9315 of 10.0.0.255. 9317 F. Differences from RFC 1583 9319 This section documents the differences between this memo and RFC 9320 1583. All differences are backward-compatible. Implementations of 9321 this memo and of RFC 1583 will interoperate. 9323 F.1 Enhancements to OSPF authentication 9325 An additional OSPF authentication type has been added: the 9326 Cryptographic authentication type. This has been defined so that 9327 any arbitrary "Keyed Message Digest" algorithm can be used for 9328 packet authentication. Operation using the MD5 algorithm is 9329 completely specified (see Appendix D). 9331 A number of other changes were also made to OSPF packet 9332 authentication, affecting the following Sections: 9334 o The authentication type is now specified per-interface, 9335 rather than per-area (Sections 6, 9, C.2 and C.3). 9337 o The OSPF packet header checksum is now considered part of 9338 the authentication procedure, and so has been moved out of 9339 the packet send and receive logic (Sections 8.1 and 8.2) and 9340 into the description of authentication types (Appendix D). 9342 o In Appendix D, sections detailing message generation and 9343 message verification have been added. 9345 o For the OSPF Cryptographic authentication type, a discussion 9346 of key management, including the requirement for 9347 simultaneous support of multiple keys, key lifetimes and 9348 smooth key transition, has been added to Appendix D. 9350 F.2 Addition of Point-to-MultiPoint interface 9352 This memo adds an additional method for running OSPF over non- 9353 broadcast networks: the Point-to-Multipoint network. To 9354 implement this addition, the language of RFC 1583 has been 9355 altered slightly. References to "multi-access" networks have 9356 been deleted. The term "non-broadcast networks" is now used to 9357 describe networks which can connect many routers, but which do 9358 not natively support broadcast/multicast (such as a public Frame 9359 relay network). Over non-broadcast networks, there are two 9360 options for running OSPF: modelling them as "NBMA networks" or 9361 as "Point-to-MultiPoint networks". NBMA networks require full 9362 mesh connectivity between routers; when employing NBMA networks 9363 in the presence of partial mesh connectivity, multiple NBMA 9364 networks must be configured, as described in [Ref15]. In 9365 contrast, Point-to-Multipoint networks have been designed to 9366 work simply and naturally when faced with partial mesh 9367 connectivity. 9369 The addition of Point-to-MultiPoint networks has impacted the 9370 text in many places, which are briefly summarized below: 9372 o Section 2 describing the OSPF link-state database has been 9373 split into additional subsections, with one of the 9374 subsections (Section 2.1.1) describing the differing map 9375 representations of the two non-broadcast network options. 9376 This subsection also contrasts the NBMA network and Point- 9377 to-MultiPoint network options, and describes the situations 9378 when one is preferable to the other. 9380 o In contrast to NBMA networks, Point-to-MultiPoint networks 9381 have the following properties. Adjacencies are established 9382 between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 9383 and 10.4). There is no Designated Router or Backup 9384 Designated Router for a Point-to-MultiPoint network 9385 (Sections 7.3 and 7.4). No network-LSA is originated for 9386 Point-to-MultiPoint networks (Sections 12.4.2 and A.4.3). 9387 Router Priority is not configured for Point-to-MultiPoint 9388 interfaces, nor for neighbors on Point-to-MultiPoint 9389 networks (Sections C.3 and C.6). 9391 o The Interface FSM for a Point-to-MultiPoint interface is 9392 identical to that used for point-to-point interfaces. Two 9393 states are possible: "Down" and "Point-to-Point" (Section 9394 9.3). 9396 o When originating a router-LSA, and Point-to-MultiPoint 9397 interface is reported as a collection of "point-to-point 9398 links" to all of the interface's adjacent neighbors, 9399 together with a single stub link advertising the interface's 9400 IP address with a cost of 0 (Section 12.4.1.4). 9402 o When flooding out a non-broadcast interface (when either in 9403 NBMA or Point-to-MultiPoint mode) the Link State Update or 9404 Link State Acknowledgment packet must be replicated in order 9405 to be sent to each of the interface's neighbors (see 9406 Sections 13.3 and 13.5). 9408 F.3 Support for overlapping area ranges 9410 RFC 1583 requires that all networks falling into a given area 9411 range actually belong to a single area. This memo relaxes that 9412 restriction. This is useful in the following example. Suppose 9413 that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of 9414 these subnets are assigned to a single OSPF area (call it Area 9415 X), while a few subnets are assigned to other areas. In order to 9416 get this configuration to work with RFC 1583, you must not 9417 summarize the subnets of Area X with the single range [10.0.0.0, 9418 255.0.0.0], because then the subnets of 10.0.0.0 belonging to 9419 other areas would become unreachable. However, with this memo 9420 you can summarize the subnets in Area X, provided that the 9421 subnets belonging to other areas are not summarized. 9423 Implementation details for this change can be found in Sections 9424 11.1 and 16.2. 9426 F.4 A modification to the flooding algorithm 9428 The OSPF flooding algorithm has been modified as follows. When a 9429 Link State Update Packet is received that contains an LSA 9430 instance which is actually less recent than the the router's 9431 current database copy, the router will now in most cases respond 9432 by flooding back its database copy. This is in contrast to the 9433 RFC 1583 behavior, which was to simply throw the received LSA 9434 away. 9436 Detailed description of the change can be found in Step 8 of 9437 Section 13. 9439 This change improves MaxAge processing. There are times when 9440 MaxAge LSAs stay in a router's database for extended intervals: 9441 1) when they are stuck in a retransmission queue on a slow link 9442 or 2) when a router is not properly flushing them from its 9443 database, due to software bugs. The prolonged existence of these 9444 MaxAge LSAs can inhibit the flooding of new instances of the 9445 LSA. New instances typically start with LS sequence number equal 9446 to InitialSequenceNumber, and are treated as less recent (and 9447 hence were discarded according to RFC 1583) by routers still 9448 holding MaxAge instances. However, with the above change to 9449 flooding, a router holding a MaxAge instance will flood back the 9450 MaxAge instance. When this flood reaches the LSA's originator, 9451 it will then pick the next highest LS sequence number and 9452 reflood, overwriting the MaxAge instance. 9454 F.5 Introduction of the MinLSArrival constant 9456 OSPF limits the frequency that new instances of any particular 9457 LSA can be accepted during flooding. This is extra protection, 9458 just in case a neighboring router is violating the mandated 9459 limit on LSA (re)originations (namely, one per LSA in any 9460 MinLSInterval). 9462 In RFC 1583, the frequency at which new LSA instances were 9463 accepted was also set equal to once every MinLSInterval seconds. 9464 However, in some circumstances this led to unwanted link state 9465 retransmissions, even when the LSA originator was obeying the 9466 MinLSInterval limit on originations. This was due to either 1) 9467 choice of clock granularity in some OSPF implementations or 2) 9468 differing clock speed in neighboring routers. 9470 To alleviate this problem, the frequency at which new LSA 9471 instances are accepted during flooding has now been increased to 9472 once every MinLSArrival seconds, whose value is set to 1. This 9473 change is reflected in Steps 5a and 5d of Section 13, and in 9474 Appendix B. 9476 F.6 Optionally advertising point-to-point links as subnets 9478 When describing a point-to-point interface in its router-LSA, a 9479 router may now advertise a stub link to the point-to-point 9480 network's subnet. This is specified as an alternative to the RFC 9481 1583 behavior, which is to advertise a stub link to the 9482 neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for 9483 details. 9485 Security Considerations 9487 All OSPF protocol exchanges are authenticated. OSPF supports 9488 multiple types of authentication; the type of authentication in use 9489 can be configured on a per network segment basis. One of OSPF's 9490 authentication types, namely the Cryptographic authentication 9491 option, is believed to be secure against active and passive attacks. 9492 When using the Cryptographic authentication option, each router 9493 appends a "message digest" to its transmitted OSPF packets. 9494 Receivers then use the shared secret key and received digest to 9495 verify that each received OSPF packet is authentic. 9497 The quality of the security provided by the Cryptographic 9498 authentication option depends completely on the strength of the 9499 message digest algorithm (MD5 is currently the only message digest 9500 algorithm specified), the strength of the key being used, and the 9501 correct implementation of the security mechanism in all 9502 communicating OSPF implementations. It also requires that all 9503 parties maintain the secrecy of the shared secret key. 9505 None of the OSPF authentication types provide confidentiality. Nor 9506 do they protect against traffic analysis. Key management is also not 9507 addressed by this memo. 9509 For more information, see Sections 8.1, 8.2, and Appendix D. 9511 Author's Address 9513 John Moy 9514 Cascade Communications Corp. 9515 5 Carlisle Road 9516 Westford, MA 01886 9518 Phone: 508-952-1367 9519 Fax: 508-692-9214 9520 Email: jmoy@casc.com 9522 This document expires in May 1996.