From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2178.txt | 11819 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 11819 insertions(+) create mode 100644 doc/rfc/rfc2178.txt (limited to 'doc/rfc/rfc2178.txt') diff --git a/doc/rfc/rfc2178.txt b/doc/rfc/rfc2178.txt new file mode 100644 index 0000000..67fe708 --- /dev/null +++ b/doc/rfc/rfc2178.txt @@ -0,0 +1,11819 @@ + + + + + + +Network Working Group J. Moy +Request for Comments: 2178 Cascade Communications Corp. +Obsoletes: 1583 July 1997 +Category: Standards Track + + + OSPF Version 2 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo documents version 2 of the OSPF protocol. OSPF is a link- + state routing protocol. It is designed to be run internal to a + single Autonomous System. Each OSPF router maintains an identical + database describing the Autonomous System's topology. From this + database, a routing table is calculated by constructing a shortest- + path tree. + + OSPF recalculates routes quickly in the face of topological changes, + utilizing a minimum of routing protocol traffic. OSPF provides + support for equal-cost multipath. An area routing capability is + provided, enabling an additional level of routing protection and a + reduction in routing protocol traffic. In addition, all OSPF routing + protocol exchanges are authenticated. + + The differences between this memo and RFC 1583 are explained in + Appendix G. All differences are backward-compatible in nature. + Implementations of this memo and of RFC 1583 will interoperate. + + Please send comments to ospf@gated.cornell.edu. + +Table of Contents + + 1 Introduction ........................................... 5 + 1.1 Protocol Overview ...................................... 5 + 1.2 Definitions of commonly used terms ..................... 6 + 1.3 Brief history of link-state routing technology ........ 9 + 1.4 Organization of this document ......................... 10 + 1.5 Acknowledgments ....................................... 11 + 2 The link-state database: organization and calculations 11 + 2.1 Representation of routers and networks ................ 11 + + + +Moy Standards Track [Page 1] + +RFC 2178 OSPF Version 2 July 1997 + + + 2.1.1 Representation of non-broadcast networks .............. 13 + 2.1.2 An example link-state database ........................ 14 + 2.2 The shortest-path tree ................................ 18 + 2.3 Use of external routing information ................... 20 + 2.4 Equal-cost multipath .................................. 22 + 3 Splitting the AS into Areas ........................... 22 + 3.1 The backbone of the Autonomous System ................. 23 + 3.2 Inter-area routing .................................... 23 + 3.3 Classification of routers ............................. 24 + 3.4 A sample area configuration ........................... 25 + 3.5 IP subnetting support ................................. 31 + 3.6 Supporting stub areas ................................. 32 + 3.7 Partitions of areas ................................... 33 + 4 Functional Summary .................................... 34 + 4.1 Inter-area routing .................................... 35 + 4.2 AS external routes .................................... 35 + 4.3 Routing protocol packets .............................. 35 + 4.4 Basic implementation requirements ..................... 38 + 4.5 Optional OSPF capabilities ............................ 39 + 5 Protocol data structures .............................. 40 + 6 The Area Data Structure ............................... 42 + 7 Bringing Up Adjacencies ............................... 44 + 7.1 The Hello Protocol .................................... 44 + 7.2 The Synchronization of Databases ...................... 45 + 7.3 The Designated Router ................................. 46 + 7.4 The Backup Designated Router .......................... 47 + 7.5 The graph of adjacencies .............................. 48 + 8 Protocol Packet Processing ............................ 49 + 8.1 Sending protocol packets .............................. 49 + 8.2 Receiving protocol packets ............................ 51 + 9 The Interface Data Structure .......................... 54 + 9.1 Interface states ...................................... 57 + 9.2 Events causing interface state changes ................ 59 + 9.3 The Interface state machine ........................... 61 + 9.4 Electing the Designated Router ........................ 64 + 9.5 Sending Hello packets ................................. 66 + 9.5.1 Sending Hello packets on NBMA networks ................ 67 + 10 The Neighbor Data Structure ........................... 68 + 10.1 Neighbor states ....................................... 70 + 10.2 Events causing neighbor state changes ................. 75 + 10.3 The Neighbor state machine ............................ 76 + 10.4 Whether tocome adjacent ............................ 82 + 10.5 Receiving Hello Packets ............................... 83 + 10.6 Receiving Database Description Packets ................ 85 + 10.7 Receiving Link State Request Packets .................. 88 + 10.8 Sending Database Description Packets .................. 89 + 10.9 Sending Link State Request Packets .................... 90 + 10.10 An Example ............................................ 91 + + + +Moy Standards Track [Page 2] + +RFC 2178 OSPF Version 2 July 1997 + + + 11 The Routing Table Structure ........................... 93 + 11.1 Routing table lookup .................................. 96 + 11.2 Sample routing table, without areas ................... 97 + 11.3 Sample routing table, with areas ...................... 97 + 12 Link State Advertisements (LSAs) ......................100 + 12.1 The LSA Header ........................................100 + 12.1.1 LS age ............................................... 101 + 12.1.2 Options .............................................. 101 + 12.1.3 LS type .............................................. 102 + 12.1.4 Link State ID ........................................ 102 + 12.1.5 Advertising Router ................................... 104 + 12.1.6 LS sequence number ................................... 104 + 12.1.7 LS checksum .......................................... 105 + 12.2 The link state database .............................. 105 + 12.3 Representation of TOS ................................ 106 + 12.4 Originating LSAs ..................................... 107 + 12.4.1 Router-LSAs .......................................... 110 + 12.4.1.1 Describing point-to-point interfaces ................. 112 + 12.4.1.2 Describing broadcast and NBMA interfaces ............. 113 + 12.4.1.3 Describing virtual links ............................. 113 + 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 114 + 12.4.1.5 Examples of router-LSAs .............................. 114 + 12.4.2 Network-LSAs ......................................... 116 + 12.4.2.1 Examples of network-LSAs ............................. 116 + 12.4.3 Summary-LSAs ......................................... 117 + 12.4.3.1 Originating summary-LSAs into stub areas ............. 119 + 12.4.3.2 Examples of summary-LSAs ............................. 119 + 12.4.4 AS-external-LSAs ..................................... 120 + 12.4.4.1 Examples of AS-external-LSAs ......................... 121 + 13 The Flooding Procedure ............................... 122 + 13.1 Determining which LSA is newer ....................... 126 + 13.2 Installing LSAs in the database ...................... 127 + 13.3 Next step in the flooding procedure .................. 128 + 13.4 Receiving self-originated LSAs ....................... 130 + 13.5 Sending Link State Acknowledgment packets ............ 131 + 13.6 Retransmitting LSAs .................................. 133 + 13.7 Receiving link state acknowledgments ................. 134 + 14 Aging The Link State Database ........................ 134 + 14.1 Premature aging of LSAs .............................. 135 + 15 Virtual Links ........................................ 135 + 16 Calculation of the routing table ..................... 137 + 16.1 Calculating the shortest-path tree for an area ....... 138 + 16.1.1 The next hop calculation ............................. 144 + 16.2 Calculating the inter-area routes .................... 145 + 16.3 Examining transit areas' summary-LSAs ................ 146 + 16.4 Calculating AS external routes ....................... 149 + 16.4.1 External path preferences ............................ 151 + 16.5 Incremental updates -- summary-LSAs .................. 151 + + + +Moy Standards Track [Page 3] + +RFC 2178 OSPF Version 2 July 1997 + + + 16.6 Incremental updates -- AS-external-LSAs .............. 152 + 16.7 Events generated as a result of routing table changes 153 + 16.8 Equal-cost multipath ................................. 154 + Footnotes ............................................ 155 + References ........................................... 158 + A OSPF data formats .................................... 160 + A.1 Encapsulation of OSPF packets ........................ 160 + A.2 The Options field .................................... 162 + A.3 OSPF Packet Formats .................................. 163 + A.3.1 The OSPF packet header ............................... 164 + A.3.2 The Hello packet ..................................... 166 + A.3.3 The Database Description packet ...................... 168 + A.3.4 The Link State Request packet ........................ 170 + A.3.5 The Link State Update packet ......................... 171 + A.3.6 The Link State Acknowledgment packet ................. 172 + A.4 LSA formats .......................................... 173 + A.4.1 The LSA header ....................................... 174 + A.4.2 Router-LSAs .......................................... 176 + A.4.3 Network-LSAs ......................................... 179 + A.4.4 Summary-LSAs ......................................... 180 + A.4.5 AS-external-LSAs ..................................... 182 + B Architectural Constants .............................. 184 + C Configurable Constants ............................... 186 + C.1 Global parameters .................................... 186 + C.2 Area parameters ...................................... 187 + C.3 Router interface parameters .......................... 188 + C.4 Virtual link parameters .............................. 190 + C.5 NBMA network parameters .............................. 191 + C.6 Point-to-MultiPoint network parameters ............... 191 + C.7 Host route parameters ................................ 192 + D Authentication ....................................... 193 + D.1 Null authentication .................................. 193 + D.2 Simple password authentication ....................... 193 + D.3 Cryptographic authentication ......................... 194 + D.4 Message generation ................................... 196 + D.4.1 Generating Null authentication ....................... 196 + D.4.2 Generating Simple password authentication ............ 197 + D.4.3 Generating Cryptographic authentication .............. 197 + D.5 Message verification ................................. 198 + D.5.1 Verifying Null authentication ........................ 199 + D.5.2 Verifying Simple password authentication ............. 199 + D.5.3 Verifying Cryptographic authentication ............... 199 + E An algorithm for assigning Link State IDs ............ 201 + F Multiple interfaces to the same network/subnet ....... 203 + G Differences from RFC 1583 ............................ 204 + G.1 Enhancements to OSPF authentication .................. 204 + G.2 Addition of Point-to-MultiPoint interface ............ 204 + G.3 Support for overlapping area ranges .................. 205 + + + +Moy Standards Track [Page 4] + +RFC 2178 OSPF Version 2 July 1997 + + + G.4 A modification to the flooding algorithm ............. 206 + G.5 Introduction of the MinLSArrival constant ............ 206 + G.6 Optionally advertising point-to-point links as subnets 207 + G.7 Advertising same external route from multiple areas .. 207 + G.8 Retransmission of initial Database Description packets 209 + G.9 Detecting interface MTU mismatches ................... 209 + G.10 Deleting the TOS routing option ...................... 209 + Security Considerations .............................. 210 + Author's Address ..................................... 211 + +1. Introduction + + This document is a specification of the Open Shortest Path First + (OSPF) TCP/IP internet routing protocol. OSPF is classified as an + Interior Gateway Protocol (IGP). This means that it distributes + routing information between routers belonging to a single Autonomous + System. The OSPF protocol is based on link-state or SPF technology. + This is a departure from the Bellman-Ford base used by traditional + TCP/IP internet routing protocols. + + The OSPF protocol was developed by the OSPF working group of the + Internet Engineering Task Force. It has been designed expressly for + the TCP/IP internet environment, including explicit support for CIDR + and the tagging of externally-derived routing information. OSPF also + provides for the authentication of routing updates, and utilizes IP + multicast when sending/receiving the updates. In addition, much work + has been done to produce a protocol that responds quickly to topology + changes, yet involves small amounts of routing protocol traffic. + +1.1. Protocol overview + + OSPF routes IP packets based solely on the destination IP address + found in the IP packet header. IP packets are routed "as is" -- they + are not encapsulated in any further protocol headers as they transit + the Autonomous System. OSPF is a dynamic routing protocol. It + quickly detects topological changes in the AS (such as router + interface failures) and calculates new loop-free routes after a + period of convergence. This period of convergence is short and + involves a minimum of routing traffic. + + In a link-state routing protocol, each router maintains a database + describing the Autonomous System's topology. This database is + referred to as the link-state database. Each participating router has + an identical database. Each individual piece of this database is a + particular router's local state (e.g., the router's usable interfaces + and reachable neighbors). The router distributes its local state + throughout the Autonomous System by flooding. + + + + +Moy Standards Track [Page 5] + +RFC 2178 OSPF Version 2 July 1997 + + + All routers run the exact same algorithm, in parallel. From the + link-state database, each router constructs a tree of shortest paths + with itself as root. This shortest-path tree gives the route to each + destination in the Autonomous System. Externally derived routing + information appears on the tree as leaves. + + When several equal-cost routes to a destination exist, traffic is + distributed equally among them. The cost of a route is described by + a single dimensionless metric. + + OSPF allows sets of networks to be grouped together. Such a grouping + is called an area. The topology of an area is hidden from the rest + of the Autonomous System. This information hiding enables a + significant reduction in routing traffic. Also, routing within the + area is determined only by the area's own topology, lending the area + protection from bad routing data. An area is a generalization of an + IP subnetted network. + + OSPF enables the flexible configuration of IP subnets. Each route + distributed by OSPF has a destination and mask. Two different + subnets of the same IP network number may have different sizes (i.e., + different masks). This is commonly referred to as variable length + subnetting. A packet is routed to the best (i.e., longest or most + specific) match. Host routes are considered to be subnets whose + masks are "all ones" (0xffffffff). + + All OSPF protocol exchanges are authenticated. This means that only + trusted routers can participate in the Autonomous System's routing. + A variety of authentication schemes can be used; in fact, separate + authentication schemes can be configured for each IP subnet. + + Externally derived routing data (e.g., routes learned from an + Exterior Gateway Protocol such as BGP; see [Ref23]) is advertised + throughout the Autonomous System. This externally derived data is + kept separate from the OSPF protocol's link state data. Each + external route can also be tagged by the advertising router, enabling + the passing of additional information between routers on the boundary + of the Autonomous System. + +1.2. Definitions of commonly used terms + + This section provides definitions for terms that have a specific + meaning to the OSPF protocol and that are used throughout the text. + The reader unfamiliar with the Internet Protocol Suite is referred to + [Ref13] for an introduction to IP. + + + + + + +Moy Standards Track [Page 6] + +RFC 2178 OSPF Version 2 July 1997 + + + Router + A level three Internet Protocol packet switch. Formerly called a + gateway in much of the IP literature. + + Autonomous System + A group of routers exchanging routing information via a common + routing protocol. Abbreviated as AS. + + Interior Gateway Protocol + The routing protocol spoken by the routers belonging to an + Autonomous system. Abbreviated as IGP. Each Autonomous System has + a single IGP. Separate Autonomous Systems may be running + different IGPs. + + Router ID + A 32-bit number assigned to each router running the OSPF protocol. + This number uniquely identifies the router within an Autonomous + System. + + Network + In this memo, an IP network/subnet/supernet. It is possible for + one physical network to be assigned multiple IP network/subnet + numbers. We consider these to be separate networks. Point-to- + point physical networks are an exception - they are considered a + single network no matter how many (if any at all) IP + network/subnet numbers are assigned to them. + + Network mask + A 32-bit number indicating the range of IP addresses residing on a + single IP network/subnet/supernet. This specification displays + network masks as hexadecimal numbers. For example, the network + mask for a class C IP network is displayed as 0xffffff00. Such a + mask is often displayed elsewhere in the literature as + 255.255.255.0. + + Point-to-point networks + A network that joins a single pair of routers. A 56Kb serial line + is an example of a point-to-point network. + + + + + + + + + + + + + +Moy Standards Track [Page 7] + +RFC 2178 OSPF Version 2 July 1997 + + + Broadcast networks + Networks supporting many (more than two) attached routers, + together with the capability to address a single physical message + to all of the attached routers (broadcast). Neighboring routers + are discovered dynamically on these nets using OSPF's Hello + Protocol. The Hello Protocol itself takes advantage of the + broadcast capability. The OSPF protocol makes further use of + multicast capabilities, if they exist. Each pair of routers on a + broadcast network is assumed to be able to communicate directly. + An ethernet is an example of a broadcast network. + + Non-broadcast networks + Networks supporting many (more than two) routers, but having no + broadcast capability. Neighboring routers are maintained on these + nets using OSPF's Hello Protocol. However, due to the lack of + broadcast capability, some configuration information may be + necessary to aid in the discovery of neighbors. On non-broadcast + networks, OSPF protocol packets that are normally multicast need + to be sent to each neighboring router, in turn. An X.25 Public + Data Network (PDN) is an example of a non-broadcast network. + + OSPF runs in one of two modes over non-broadcast networks. The + first mode, called non-broadcast multi-access or NBMA, simulates + the operation of OSPF on a broadcast network. The second mode, + called Point-to-MultiPoint, treats the non-broadcast network as a + collection of point-to-point links. Non-broadcast networks are + referred to as NBMA networks or Point-to-MultiPoint networks, + depending on OSPF's mode of operation over the network. + + Interface + The connection between a router and one of its attached networks. + An interface has state information associated with it, which is + obtained from the underlying lower level protocols and the routing + protocol itself. An interface to a network has associated with it + a single IP address and mask (unless the network is an unnumbered + point-to-point network). An interface is sometimes also referred + to as a link. + + Neighboring routers + Two routers that have interfaces to a common network. Neighbor + relationships are maintained by, and usually dynamically + discovered by, OSPF's Hello Protocol. + + Adjacency + A relationship formed between selected neighboring routers for the + purpose of exchanging routing information. Not every pair of + neighboring routers become adjacent. + + + + +Moy Standards Track [Page 8] + +RFC 2178 OSPF Version 2 July 1997 + + + Link state advertisement + Unit of data describing the local state of a router or network. + For a router, this includes the state of the router's interfaces + and adjacencies. Each link state advertisement is flooded + throughout the routing domain. The collected link state + advertisements of all routers and networks forms the protocol's + link state database. Throughout this memo, link state + advertisement is abbreviated as LSA. + + Hello Protocol + The part of the OSPF protocol used to establish and maintain + neighbor relationships. On broadcast networks the Hello Protocol + can also dynamically discover neighboring routers. + + Flooding + The part of the OSPF protocol that distributes and synchronizes + the link-state database between OSPF routers. + + Designated Router + Each broadcast and NBMA network that has at least two attached + routers has a Designated Router. The Designated Router generates + an LSA for the network and has other special responsibilities in + the running of the protocol. The Designated Router is elected by + the Hello Protocol. + + The Designated Router concept enables a reduction in the number of + adjacencies required on a broadcast or NBMA network. This in turn + reduces the amount of routing protocol traffic and the size of the + link-state database. + + Lower-level protocols + The underlying network access protocols that provide services to + the Internet Protocol and in turn the OSPF protocol. Examples of + these are the X.25 packet and frame levels for X.25 PDNs, and the + ethernet data link layer for ethernets. + +1.3. Brief history of link-state routing technology + + OSPF is a link state routing protocol. Such protocols are also + referred to in the literature as SPF-based or distributed-database + protocols. This section gives a brief description of the + developments in link-state technology that have influenced the OSPF + protocol. + + The first link-state routing protocol was developed for use in the + ARPANET packet switching network. This protocol is described in + [Ref3]. It has formed the starting point for all other link-state + protocols. The homogeneous ARPANET environment, i.e., single-vendor + + + +Moy Standards Track [Page 9] + +RFC 2178 OSPF Version 2 July 1997 + + + packet switches connected by synchronous serial lines, simplified the + design and implementation of the original protocol. + + Modifications to this protocol were proposed in [Ref4]. These + modifications dealt with increasing the fault tolerance of the + routing protocol through, among other things, adding a checksum to + the LSAs (thereby detecting database corruption). The paper also + included means for reducing the routing traffic overhead in a link- + state protocol. This was accomplished by introducing mechanisms + which enabled the interval between LSA originations to be increased + by an order of magnitude. + + A link-state algorithm has also been proposed for use as an ISO IS-IS + routing protocol. This protocol is described in [Ref2]. The + protocol includes methods for data and routing traffic reduction when + operating over broadcast networks. This is accomplished by election + of a Designated Router for each broadcast network, which then + originates an LSA for the network. + + The OSPF Working Group of the IETF has extended this work in + developing the OSPF protocol. The Designated Router concept has been + greatly enhanced to further reduce the amount of routing traffic + required. Multicast capabilities are utilized for additional routing + bandwidth reduction. An area routing scheme has been developed + enabling information hiding/protection/reduction. Finally, the + algorithms have been tailored for efficient operation in TCP/IP + internets. + +1.4. Organization of this document + + The first three sections of this specification give a general + overview of the protocol's capabilities and functions. Sections 4-16 + explain the protocol's mechanisms in detail. Packet formats, + protocol constants and configuration items are specified in the + appendices. + + Labels such as HelloInterval encountered in the text refer to + protocol constants. They may or may not be configurable. + Architectural constants are summarized in Appendix B. Configurable + constants are summarized in Appendix C. + + The detailed specification of the protocol is presented in terms of + data structures. This is done in order to make the explanation more + precise. Implementations of the protocol are required to support the + functionality described, but need not use the precise data structures + that appear in this memo. + + + + + +Moy Standards Track [Page 10] + +RFC 2178 OSPF Version 2 July 1997 + + +1.5. Acknowledgments + + The author would like to thank Ran Atkinson, Fred Baker, Jeffrey + Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra + Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui Zhang + and the rest of the OSPF Working Group for the ideas and support they + have given to this project. + + The OSPF Point-to-MultiPoint interface is based on work done by Fred + Baker. + + The OSPF Cryptographic Authentication option was developed by Fred + Baker and Ran Atkinson. + +2. The Link-state Database: organization and calculations + + The following subsections describe the organization of OSPF's link- + state database, and the routing calculations that are performed on + the database in order to produce a router's routing table. + +2.1. Representation of routers and networks + + The Autonomous System's link-state database describes a directed + graph. The vertices of the graph consist of routers and networks. A + graph edge connects two routers when they are attached via a physical + point-to-point network. An edge connecting a router to a network + indicates that the router has an interface on the network. Networks + can be either transit or stub networks. Transit networks are those + capable of carrying data traffic that is neither locally originated + nor locally destined. A transit network is represented by a graph + vertex having both incoming and outgoing edges. A stub network's + vertex has only incoming edges. + + The neighborhood of each network node in the graph depends on the + network's type (point-to-point, broadcast, NBMA or Point-to- + MultiPoint) and the number of routers having an interface to the + network. Three cases are depicted in Figure 1a. Rectangles indicate + routers. Circles and oblongs indicate networks. Router names are + prefixed with the letters RT and network names with the letter N. + Router interface names are prefixed by the letter I. Lines between + routers indicate point-to-point networks. The left side of the + figure shows networks with their connected routers, with the + resulting graphs shown on the right. + + + + + + + + +Moy Standards Track [Page 11] + +RFC 2178 OSPF Version 2 July 1997 + + + **FROM** + + * |RT1|RT2| + +---+Ia +---+ * ------------ + |RT1|------|RT2| T RT1| | X | + +---+ Ib+---+ O RT2| X | | + * Ia| | X | + * Ib| X | | + + Physical point-to-point networks + + **FROM** + +---+ * + |RT7| * |RT7| N3| + +---+ T ------------ + | O RT7| | | + +----------------------+ * N3| X | | + N3 * + + Stub networks + + +---+ +---+ + |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | + +---+ +---+ * ------------------------ + | N2 | * RT3| | | | | X | + +----------------------+ T RT4| | | | | X | + | | O RT5| | | | | X | + +---+ +---+ * RT6| | | | | X | + |RT5| |RT6| * N2| X | X | X | X | | + +---+ +---+ + + Broadcast or NBMA networks + + Figure 1a: Network map components + + Networks and routers are represented by vertices. An edge connects + Vertex A to Vertex B iff the intersection of Column A and Row B is + marked with an X. + + The top of Figure 1a shows two routers connected by a point-to-point + link. In the resulting link-state database graph, the two router + vertices are directly connected by a pair of edges, one in each + direction. Interfaces to point-to-point networks need not be assigned + IP addresses. When interface addresses are assigned, they are + modelled as stub links, with each router advertising a stub + connection to the other router's interface address. Optionally, an IP + + + + + +Moy Standards Track [Page 12] + +RFC 2178 OSPF Version 2 July 1997 + + + subnet can be assigned to the point-to-point network. In this case, + both routers advertise a stub link to the IP subnet, instead of + advertising each others' IP interface addresses. + + The middle of Figure 1a shows a network with only one attached router + (i.e., a stub network). In this case, the network appears on the end + of a stub connection in the link-state database's graph. + + When multiple routers are attached to a broadcast network, the link- + state database graph shows all routers bidirectionally connected to + the network vertex. This is pictured at the bottom of Figure 1a. + + Each network (stub or transit) in the graph has an IP address and + associated network mask. The mask indicates the number of nodes on + the network. Hosts attached directly to routers (referred to as host + routes) appear on the graph as stub networks. The network mask for a + host route is always 0xffffffff, which indicates the presence of a + single node. + +2.1.1. Representation of non-broadcast networks + + As mentioned previously, OSPF can run over non-broadcast networks in + one of two modes: NBMA or Point-to-MultiPoint. The choice of mode + determines the way that the Hello protocol and flooding work over the + non-broadcast network, and the way that the network is represented in + the link-state database. + + In NBMA mode, OSPF emulates operation over a broadcast network: a + Designated Router is elected for the NBMA network, and the Designated + Router originates an LSA for the network. The graph representation + for broadcast networks and NBMA networks is identical. This + representation is pictured in the middle of Figure 1a. + + NBMA mode is the most efficient way to run OSPF over non-broadcast + networks, both in terms of link-state database size and in terms of + the amount of routing protocol traffic. However, it has one + significant restriction: it requires all routers attached to the NBMA + network to be able to communicate directly. This restriction may be + met on some non-broadcast networks, such as an ATM subnet utilizing + SVCs. But it is often not met on other non-broadcast networks, such + as PVC-only Frame Relay networks. On non-broadcast networks where not + all routers can communicate directly you can break the non-broadcast + network into logical subnets, with the routers on each subnet being + able to communicate directly, and then run each separate subnet as an + NBMA network (see [Ref15]). This however requires quite a bit of + administrative overhead, and is prone to misconfiguration. It is + probably better to run such a non-broadcast network in Point-to- + Multipoint mode. + + + +Moy Standards Track [Page 13] + +RFC 2178 OSPF Version 2 July 1997 + + + In Point-to-MultiPoint mode, OSPF treats all router-to-router + connections over the non-broadcast network as if they were point-to- + point links. No Designated Router is elected for the network, nor is + there an LSA generated for the network. In fact, a vertex for the + Point-to-MultiPoint network does not appear in the graph of the + link-state database. + + Figure 1b illustrates the link-state database representation of a + Point-to-MultiPoint network. On the left side of the figure, a + Point-to-MultiPoint network is pictured. It is assumed that all + routers can communicate directly, except for routers RT4 and RT5. I3 + though I6 indicate the routers' IP interface addresses on the Point- + to-MultiPoint network. In the graphical representation of the link- + state database, routers that can communicate directly over the + Point-to-MultiPoint network are joined by bidirectional edges, and + each router also has a stub connection to its own IP interface + address (which is in contrast to the representation of real point- + to-point links; see Figure 1a). + + On some non-broadcast networks, use of Point-to-MultiPoint mode and + data-link protocols such as Inverse ARP (see [Ref14]) will allow + autodiscovery of OSPF neighbors even though broadcast support is not + available. + +2.1.2. An example link-state database + + Figure 2 shows a sample map of an Autonomous System. The rectangle + labelled H1 indicates a host, which has a SLIP connection to Router + RT12. Router RT12 is therefore advertising a host route. Lines + between routers indicate physical point-to-point networks. The only + point-to-point network that has been assigned interface addresses is + the one joining Routers RT6 and RT10. Routers RT5 and RT7 have BGP + connections to other Autonomous Systems. A set of BGP-learned routes + have been displayed for both of these routers. + + A cost is associated with the output side of each router interface. + This cost is configurable by the system administrator. The lower the + cost,the more likely the interface is to be used to forward data + traffic. Costs are also associated with the externally derived + routing data (e.g., the BGP-learned routes). + + The directed graph resulting from the map in Figure 2 is depicted in + Figure 3. Arcs are labelled with the cost of the corresponding + router output interface. Arcs having no labelled cost have a cost of + 0. Note that arcs leading from networks to routers always have cost + 0; they are significant nonetheless. Note also that the externally + derived routing data appears on the graph as stubs. + + + + +Moy Standards Track [Page 14] + +RFC 2178 OSPF Version 2 July 1997 + + + **FROM** + +---+ +---+ + |RT3| |RT4| |RT3|RT4|RT5|RT6| + +---+ +---+ * -------------------- + I3| N2 |I4 * RT3| | X | X | X | + +----------------------+ T RT4| X | | | X | + I5| |I6 O RT5| X | | | X | + +---+ +---+ * RT6| X | X | X | | + |RT5| |RT6| * I3| X | | | | + +---+ +---+ I4| | X | | | + I5| | | X | | + I6| | | | X | + + + Figure 1b: Network map components + Point-to-MultiPoint networks + + All routers can communicate directly over N2, except + routers RT4 and RT5. I3 through I6 indicate IP + interface addresses + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 15] + +RFC 2178 OSPF Version 2 July 1997 + + + + + | 3+---+ N12 N14 + N1|--|RT1|\ 1 \ N13 / + | +---+ \ 8\ |8/8 + + \ ____ \|/ + / \ 1+---+8 8+---+6 + * N3 *---|RT4|------|RT5|--------+ + \____/ +---+ +---+ | + + / | |7 | + | 3+---+ / | | | + N2|--|RT2|/1 |1 |6 | + | +---+ +---+8 6+---+ | + + |RT3|--------------|RT6| | + +---+ +---+ | + |2 Ia|7 | + | | | + +---------+ | | + N4 | | + | | + | | + N11 | | + +---------+ | | + | | | N12 + |3 | |6 2/ + +---+ | +---+/ + |RT9| | |RT7|---N15 + +---+ | +---+ 9 + |1 + | |1 + _|__ | Ib|5 __|_ + / \ 1+----+2 | 3+----+1 / \ + * N9 *------|RT11|----|---|RT10|---* N6 * + \____/ +----+ | +----+ \____/ + | | | + |1 + |1 + +--+ 10+----+ N8 +---+ + |H1|-----|RT12| |RT8| + +--+SLIP +----+ +---+ + |2 |4 + | | + +---------+ +--------+ + N10 N7 + + Figure 2: A sample Autonomous System + + + + + + + + +Moy Standards Track [Page 16] + +RFC 2178 OSPF Version 2 July 1997 + + + **FROM** + + |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| + |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| + ----- --------------------------------------------- + RT1| | | | | | | | | | | | |0 | | | | + RT2| | | | | | | | | | | | |0 | | | | + RT3| | | | | |6 | | | | | | |0 | | | | + RT4| | | | |8 | | | | | | | |0 | | | | + RT5| | | |8 | |6 |6 | | | | | | | | | | + RT6| | |8 | |7 | | | | |5 | | | | | | | + RT7| | | | |6 | | | | | | | | |0 | | | + * RT8| | | | | | | | | | | | | |0 | | | + * RT9| | | | | | | | | | | | | | | |0 | + T RT10| | | | | |7 | | | | | | | |0 |0 | | + O RT11| | | | | | | | | | | | | | |0 |0 | + * RT12| | | | | | | | | | | | | | | |0 | + * N1|3 | | | | | | | | | | | | | | | | + N2| |3 | | | | | | | | | | | | | | | + N3|1 |1 |1 |1 | | | | | | | | | | | | | + N4| | |2 | | | | | | | | | | | | | | + N6| | | | | | |1 |1 | |1 | | | | | | | + N7| | | | | | | |4 | | | | | | | | | + N8| | | | | | | | | |3 |2 | | | | | | + N9| | | | | | | | |1 | |1 |1 | | | | | + N10| | | | | | | | | | | |2 | | | | | + N11| | | | | | | | |3 | | | | | | | | + N12| | | | |8 | |2 | | | | | | | | | | + N13| | | | |8 | | | | | | | | | | | | + N14| | | | |8 | | | | | | | | | | | | + N15| | | | | | |9 | | | | | | | | | | + H1| | | | | | | | | | | |10| | | | | + + + Figure 3: The resulting directed graph + + Networks and routers are represented by vertices. + An edge of cost X connects Vertex A to Vertex B iff + the intersection of Column A and Row B is marked + with an X. + + The link-state database is pieced together from LSAs generated by the + routers. In the associated graphical representation, the + neighborhood of each router or transit network is represented in a + single, separate LSA. Figure 4 shows these LSAs graphically. Router + RT12 has an interface to two broadcast networks and a SLIP line to a + host. Network N6 is a broadcast network with three attached routers. + The cost of all links from Network N6 to its attached routers is 0. + + + +Moy Standards Track [Page 17] + +RFC 2178 OSPF Version 2 July 1997 + + + Note that the LSA for Network N6 is actually generated by one of the + network's attached routers: the router that has been elected + Designated Router for the network. + +2.2. The shortest-path tree + + When no OSPF areas are configured, each router in the Autonomous + System has an identical link-state database, leading to an identical + graphical representation. A router generates its routing table from + this graph by calculating a tree of shortest paths with the router + itself as root. Obviously, the shortest- path tree depends on the + router doing the calculation. The shortest-path tree for Router RT6 + in our example is depicted in Figure 5. + + The tree gives the entire path to any destination network or host. + However, only the next hop to the destination is used in the + forwarding process. Note also that the best route to any router has + also been calculated. For the processing of external data, we note + the next hop and distance to any router advertising external routes. + The resulting routing table for Router RT6 is pictured in Table 2. + Note that there is a separate route for each end of a numbered + point-to-point network (in this case, the serial line between Routers + RT6 and RT10). + + + **FROM** **FROM** + + |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| + * -------------------- * ---------------------- + * RT12| | | | | * RT9| | | |0 | + T N9|1 | | | | T RT11| | | |0 | + O N10|2 | | | | O RT12| | | |0 | + * H1|10 | | | | * N9| | | | | + * * + RT12's router-LSA N9's network-LSA + + Figure 4: Individual link state components + + Networks and routers are represented by vertices. + An edge of cost X connects Vertex A to Vertex B iff + the intersection of Column A and Row B is marked + with an X. + + + + + + + + + +Moy Standards Track [Page 18] + +RFC 2178 OSPF Version 2 July 1997 + + + RT6(origin) + RT5 o------------o-----------o Ib + /|\ 6 |\ 7 + 8/8|8\ | \ + / | \ 6| \ + o | o | \7 + N12 o N14 | \ + N13 2 | \ + N4 o-----o RT3 \ + / \ 5 + 1/ RT10 o-------o Ia + / |\ + RT4 o-----o N3 3| \1 + /| | \ N6 RT7 + / | N8 o o---------o + / | | | /| + RT2 o o RT1 | | 2/ |9 + / | | |RT8 / | + /3 |3 RT11 o o o o + / | | | N12 N15 + N2 o o N1 1| |4 + | | + N9 o o N7 + /| + / | + N11 RT9 / |RT12 + o--------o-------o o--------o H1 + 3 | 10 + |2 + | + o N10 + + + Figure 5: The SPF tree for Router RT6 + + Edges that are not marked with a cost have a cost of of zero (these + are network-to-router links). Routes to networks N12-N15 are external + information that is considered in Section 2.3 + + + + + + + + + + + + + +Moy Standards Track [Page 19] + +RFC 2178 OSPF Version 2 July 1997 + + + Destination Next Hop Distance + __________________________________ + N1 RT3 10 + N2 RT3 10 + N3 RT3 7 + N4 RT3 8 + Ib * 7 + Ia RT10 12 + N6 RT10 8 + N7 RT10 12 + N8 RT10 10 + N9 RT10 11 + N10 RT10 13 + N11 RT10 14 + H1 RT10 21 + __________________________________ + RT5 RT5 6 + RT7 RT10 8 + + Table 2: The portion of Router RT6's routing table listing local + destinations. + + Routes to networks belonging to other AS'es (such as N12) appear as + dashed lines on the shortest path tree in Figure 5. Use of this + externally derived routing information is considered in the next + section. + +2.3. Use of external routing information + + After the tree is created the external routing information is + examined. This external routing information may originate from + another routing protocol such as BGP, or be statically configured + (static routes). Default routes can also be included as part of the + Autonomous System's external routing information. + + External routing information is flooded unaltered throughout the AS. + In our example, all the routers in the Autonomous System know that + Router RT7 has two external routes, with metrics 2 and 9. + + OSPF supports two types of external metrics. Type 1 external metrics + are expressed in the same units as OSPF interface cost (i.e., in + terms of the link state metric). Type 2 external metrics are an + order of magnitude larger; any Type 2 metric is considered greater + than the cost of any path internal to the AS. Use of Type 2 external + metrics assumes that routing between AS'es is the major cost of + routing a packet, and eliminates the need for conversion of external + costs to internal link state metrics. + + + + +Moy Standards Track [Page 20] + +RFC 2178 OSPF Version 2 July 1997 + + + As an example of Type 1 external metric processing, suppose that the + Routers RT7 and RT5 in Figure 2 are advertising Type 1 external + metrics. For each advertised external route, the total cost from + Router RT6 is calculated as the sum of the external route's + advertised cost and the distance from Router RT6 to the advertising + router. When two routers are advertising the same external + destination, RT6 picks the advertising router providing the minimum + total cost. RT6 then sets the next hop to the external destination + equal to the next hop that would be used when routing packets to the + chosen advertising router. + + In Figure 2, both Router RT5 and RT7 are advertising an external + route to destination Network N12. Router RT7 is preferred since it + is advertising N12 at a distance of 10 (8+2) to Router RT6, which is + better than Router RT5's 14 (6+8). Table 3 shows the entries that + are added to the routing table when external routes are examined: + + + + Destination Next Hop Distance + __________________________________ + N12 RT10 10 + N13 RT5 14 + N14 RT5 14 + N15 RT10 17 + + + Table 3: The portion of Router RT6's routing table + listing external destinations. + + Processing of Type 2 external metrics is simpler. The AS boundary + router advertising the smallest external metric is chosen, regardless + of the internal distance to the AS boundary router. Suppose in our + example both Router RT5 and Router RT7 were advertising Type 2 + external routes. Then all traffic destined for Network N12 would be + forwarded to Router RT7, since 2 < 8. When several equal-cost Type 2 + routes exist, the internal distance to the advertising routers is + used to break the tie. + + Both Type 1 and Type 2 external metrics can be present in the AS at + the same time. In that event, Type 1 external metrics always take + precedence. + + This section has assumed that packets destined for external + destinations are always routed through the advertising AS boundary + router. This is not always desirable. For example, suppose in + Figure 2 there is an additional router attached to Network N6, called + Router RTX. Suppose further that RTX does not participate in OSPF + + + +Moy Standards Track [Page 21] + +RFC 2178 OSPF Version 2 July 1997 + + + routing, but does exchange BGP information with the AS boundary + router RT7. Then, Router RT7 would end up advertising OSPF external + routes for all destinations that should be routed to RTX. An extra + hop will sometimes be introduced if packets for these destinations + need always be routed first to Router RT7 (the advertising router). + + To deal with this situation, the OSPF protocol allows an AS boundary + router to specify a "forwarding address" in its AS- external-LSAs. In + the above example, Router RT7 would specify RTX's IP address as the + "forwarding address" for all those destinations whose packets should + be routed directly to RTX. + + The "forwarding address" has one other application. It enables + routers in the Autonomous System's interior to function as "route + servers". For example, in Figure 2 the router RT6 could become a + route server, gaining external routing information through a + combination of static configuration and external routing protocols. + RT6 would then start advertising itself as an AS boundary router, and + would originate a collection of OSPF AS-external-LSAs. In each AS- + external-LSA, Router RT6 would specify the correct Autonomous System + exit point to use for the destination through appropriate setting of + the LSA's "forwarding address" field. + +2.4. Equal-cost multipath + + The above discussion has been simplified by considering only a single + route to any destination. In reality, if multiple equal-cost routes + to a destination exist, they are all discovered and used. This + requires no conceptual changes to the algorithm, and its discussion + is postponed until we consider the tree-building process in more + detail. + + With equal cost multipath, a router potentially has several available + next hops towards any given destination. + +3. Splitting the AS into Areas + + OSPF allows collections of contiguous networks and hosts to be + grouped together. Such a group, together with the routers having + interfaces to any one of the included networks, is called an area. + Each area runs a separate copy of the basic link-state routing + algorithm. This means that each area has its own link-state database + and corresponding graph, as explained in the previous section. + + The topology of an area is invisible from the outside of the area. + Conversely, routers internal to a given area know nothing of the + detailed topology external to the area. This isolation of knowledge + enables the protocol to effect a marked reduction in routing traffic + + + +Moy Standards Track [Page 22] + +RFC 2178 OSPF Version 2 July 1997 + + + as compared to treating the entire Autonomous System as a single + link-state domain. + + With the introduction of areas, it is no longer true that all routers + in the AS have an identical link-state database. A router actually + has a separate link-state database for each area it is connected to. + (Routers connected to multiple areas are called area border routers). + Two routers belonging to the same area have, for that area, identical + area link-state databases. + + Routing in the Autonomous System takes place on two levels, depending + on whether the source and destination of a packet reside in the same + area (intra-area routing is used) or different areas (inter-area + routing is used). In intra-area routing, the packet is routed solely + on information obtained within the area; no routing information + obtained from outside the area can be used. This protects intra-area + routing from the injection of bad routing information. We discuss + inter-area routing in Section 3.2. + +3.1. The backbone of the Autonomous System + + The OSPF backbone is the special OSPF Area 0 (often written as Area + 0.0.0.0, since OSPF Area ID's are typically formatted as IP + addresses). The OSPF backbone always contains all area border + routers. The backbone is responsible for distributing routing + information between non-backbone areas. The backbone must be + contiguous. However, it need not be physically contiguous; backbone + connectivity can be established/maintained through the configuration + of virtual links. + + Virtual links can be configured between any two backbone routers that + have an interface to a common non-backbone area. Virtual links + belong to the backbone. The protocol treats two routers joined by a + virtual link as if they were connected by an unnumbered point-to- + point backbone network. On the graph of the backbone, two such + routers are joined by arcs whose costs are the intra-area distances + between the two routers. The routing protocol traffic that flows + along the virtual link uses intra-area routing only. + +3.2. Inter-area routing + + When routing a packet between two non-backbone areas the backbone is + used. The path that the packet will travel can be broken up into + three contiguous pieces: an intra-area path from the source to an + area border router, a backbone path between the source and + destination areas, and then another intra-area path to the + destination. The algorithm finds the set of such paths that have the + smallest cost. + + + +Moy Standards Track [Page 23] + +RFC 2178 OSPF Version 2 July 1997 + + + Looking at this another way, inter-area routing can be pictured as + forcing a star configuration on the Autonomous System, with the + backbone as hub and each of the non-backbone areas as spokes. + + The topology of the backbone dictates the backbone paths used between + areas. The topology of the backbone can be enhanced by adding + virtual links. This gives the system administrator some control over + the routes taken by inter-area traffic. + + The correct area border router to use as the packet exits the source + area is chosen in exactly the same way routers advertising external + routes are chosen. Each area border router in an area summarizes for + the area its cost to all networks external to the area. After the + SPF tree is calculated for the area, routes to all inter-area + destinations are calculated by examining the summaries of the area + border routers. + +3.3. Classification of routers + + Before the introduction of areas, the only OSPF routers having a + specialized function were those advertising external routing + information, such as Router RT5 in Figure 2. When the AS is split + into OSPF areas, the routers are further divided according to + function into the following four overlapping categories: + + + Internal routers + A router with all directly connected networks belonging to the + same area. These routers run a single copy of the basic routing + algorithm. + + Area border routers + A router that attaches to multiple areas. Area border routers run + multiple copies of the basic algorithm, one copy for each attached + area. Area border routers condense the topological information of + their attached areas for distribution to the backbone. The + backbone in turn distributes the information to the other areas. + + Backbone routers + A router that has an interface to the backbone area. This + includes all routers that interface to more than one area (i.e., + area border routers). However, backbone routers do not have to be + area border routers. Routers with all interfaces connecting to + the backbone area are supported. + + + + + + + +Moy Standards Track [Page 24] + +RFC 2178 OSPF Version 2 July 1997 + + + AS boundary routers + A router that exchanges routing information with routers belonging + to other Autonomous Systems. Such a router advertises AS external + routing information throughout the Autonomous System. The paths + to each AS boundary router are known by every router in the AS. + This classification is completely independent of the previous + classifications: AS boundary routers may be internal or area + border routers, and may or may not participate in the backbone. + +3.4. A sample area configuration + + Figure 6 shows a sample area configuration. The first area consists + of networks N1-N4, along with their attached routers RT1-RT4. The + second area consists of networks N6-N8, along with their attached + routers RT7, RT8, RT10 and RT11. The third area consists of networks + N9-N11 and Host H1, along with their attached routers RT9, RT11 and + RT12. The third area has been configured so that networks N9-N11 and + Host H1 will all be grouped into a single route, when advertised + external to the area (see Section 3.5 for more details). + + In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are + internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area + border routers. Finally, as before, Routers RT5 and RT7 are AS + boundary routers. + + Figure 7 shows the resulting link-state database for the Area 1. The + figure completely describes that area's intra-area routing. + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 25] + +RFC 2178 OSPF Version 2 July 1997 + + + ........................... + . + . + . | 3+---+ . N12 N14 + . N1|--|RT1|\ 1 . \ N13 / + . | +---+ \ . 8\ |8/8 + . + \ ____ . \|/ + . / \ 1+---+8 8+---+6 + . * N3 *---|RT4|------|RT5|--------+ + . \____/ +---+ +---+ | + . + / \ . |7 | + . | 3+---+ / \ . | | + . N2|--|RT2|/1 1\ . |6 | + . | +---+ +---+8 6+---+ | + . + |RT3|------|RT6| | + . +---+ +---+ | + . 2/ . Ia|7 | + . / . | | + . +---------+ . | | + .Area 1 N4 . | | + ........................... | | + .......................... | | + . N11 . | | + . +---------+ . | | + . | . | | N12 + . |3 . Ib|5 |6 2/ + . +---+ . +----+ +---+/ + . |RT9| . .........|RT10|.....|RT7|---N15. + . +---+ . . +----+ +---+ 9 . + . |1 . . + /3 1\ |1 . + . _|__ . . | / \ __|_ . + . / \ 1+----+2 |/ \ / \ . + . * N9 *------|RT11|----| * N6 * . + . \____/ +----+ | \____/ . + . | . . | | . + . |1 . . + |1 . + . +--+ 10+----+ . . N8 +---+ . + . |H1|-----|RT12| . . |RT8| . + . +--+SLIP +----+ . . +---+ . + . |2 . . |4 . + . | . . | . + . +---------+ . . +--------+ . + . N10 . . N7 . + . . .Area 2 . + .Area 3 . ................................ + .......................... + + Figure 6: A sample OSPF area configuration + + + + +Moy Standards Track [Page 26] + +RFC 2178 OSPF Version 2 July 1997 + + + It also shows the complete view of the internet for the two internal + routers RT1 and RT2. It is the job of the area border routers, RT3 + and RT4, to advertise into Area 1 the distances to all destinations + external to the area. These are indicated in Figure 7 by the dashed + stub routes. Also, RT3 and RT4 must advertise into Area 1 the + location of the AS boundary routers RT5 and RT7. Finally, AS- + external-LSAs from RT5 and RT7 are flooded throughout the entire AS, + and in particular throughout Area 1. These LSAs are included in Area + 1's database, and yield routes to Networks N12-N15. + + Routers RT3 and RT4 must also summarize Area 1's topology for + distribution to the backbone. Their backbone LSAs are shown in Table + 4. These summaries show which networks are contained in Area 1 + (i.e., Networks N1-N4), and the distance to these networks from the + routers RT3 and RT4 respectively. + + The link-state database for the backbone is shown in Figure 8. The + set of routers pictured are the backbone routers. Router RT11 is a + backbone router because it belongs to two areas. In order to make + the backbone connected, a virtual link has been configured between + Routers R10 and R11. + + The area border routers RT3, RT4, RT7, RT10 and RT11 condense the + routing information of their attached non-backbone areas for + distribution via the backbone; these are the dashed stubs that appear + in Figure 8. Remember that the third area has been configured to + condense Networks N9-N11 and Host H1 into a single route. This + yields a single dashed line for networks N9-N11 and Host H1 in Figure + 8. Routers RT5 and RT7 are AS boundary routers; their externally + derived information also appears on the graph in Figure 8 as stubs. + + + Network RT3 adv. RT4 adv. + _____________________________ + N1 4 4 + N2 4 4 + N3 1 1 + N4 2 3 + + Table 4: Networks advertised to the backbone + by Routers RT3 and RT4. + + + + + + + + + + +Moy Standards Track [Page 27] + +RFC 2178 OSPF Version 2 July 1997 + + + |RT|RT|RT|RT|RT|RT| + |1 |2 |3 |4 |5 |7 |N3| + ----- ------------------- + RT1| | | | | | |0 | + RT2| | | | | | |0 | + RT3| | | | | | |0 | + * RT4| | | | | | |0 | + * RT5| | |14|8 | | | | + T RT7| | |20|14| | | | + O N1|3 | | | | | | | + * N2| |3 | | | | | | + * N3|1 |1 |1 |1 | | | | + N4| | |2 | | | | | + Ia,Ib| | |20|27| | | | + N6| | |16|15| | | | + N7| | |20|19| | | | + N8| | |18|18| | | | + N9-N11,H1| | |29|36| | | | + N12| | | | |8 |2 | | + N13| | | | |8 | | | + N14| | | | |8 | | | + N15| | | | | |9 | | + + Figure 7: Area 1's Database. + + Networks and routers are represented by vertices. + An edge of cost X connects Vertex A to Vertex B iff + the intersection of Column A and Row B is marked + with an X. + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 28] + +RFC 2178 OSPF Version 2 July 1997 + + + **FROM** + + |RT|RT|RT|RT|RT|RT|RT + |3 |4 |5 |6 |7 |10|11| + ------------------------ + RT3| | | |6 | | | | + RT4| | |8 | | | | | + RT5| |8 | |6 |6 | | | + RT6|8 | |7 | | |5 | | + RT7| | |6 | | | | | + * RT10| | | |7 | | |2 | + * RT11| | | | | |3 | | + T N1|4 |4 | | | | | | + O N2|4 |4 | | | | | | + * N3|1 |1 | | | | | | + * N4|2 |3 | | | | | | + Ia| | | | | |5 | | + Ib| | | |7 | | | | + N6| | | | |1 |1 |3 | + N7| | | | |5 |5 |7 | + N8| | | | |4 |3 |2 | + N9-N11,H1| | | | | | |11| + N12| | |8 | |2 | | | + N13| | |8 | | | | | + N14| | |8 | | | | | + N15| | | | |9 | | | + + Figure 8: The backbone's database. + + Networks and routers are represented by vertices. + An edge of cost X connects Vertex A to Vertex B iff + the intersection of Column A and Row B is marked + with an X. + + The backbone enables the exchange of summary information between area + border routers. Every area border router hears the area summaries + from all other area border routers. It then forms a picture of the + distance to all networks outside of its area by examining the + collected LSAs, and adding in the backbone distance to each + advertising router. + + Again using Routers RT3 and RT4 as an example, the procedure goes as + follows: They first calculate the SPF tree for the backbone. This + gives the distances to all other area border routers. Also noted are + the distances to networks (Ia and Ib) and AS boundary routers (RT5 + and RT7) that belong to the backbone. This calculation is shown in + Table 5. + + + + +Moy Standards Track [Page 29] + +RFC 2178 OSPF Version 2 July 1997 + + + Next, by looking at the area summaries from these area border + routers, RT3 and RT4 can determine the distance to all networks + outside their area. These distances are then advertised internally + to the area by RT3 and RT4. The advertisements that Router RT3 and + RT4 will make into Area 1 are shown in Table 6. Note that Table 6 + assumes that an area range has been configured for the backbone which + groups Ia and Ib into a single LSA. + + The information imported into Area 1 by Routers RT3 and RT4 enables + an internal router, such as RT1, to choose an area border router + intelligently. Router RT1 would use RT4 for traffic to Network N6, + RT3 for traffic to Network N10, and would load share between the two + for traffic to Network N8. + + dist from dist from + RT3 RT4 + __________________________________ + to RT3 * 21 + to RT4 22 * + to RT7 20 14 + to RT10 15 22 + to RT11 18 25 + __________________________________ + to Ia 20 27 + to Ib 15 22 + __________________________________ + to RT5 14 8 + to RT7 20 14 + + Table 5: Backbone distances calculated + by Routers RT3 and RT4. + + + Destination RT3 adv. RT4 adv. + _________________________________ + Ia,Ib 20 27 + N6 16 15 + N7 20 19 + N8 18 18 + N9-N11,H1 29 36 + _________________________________ + RT5 14 8 + RT7 20 14 + + Table 6: Destinations advertised into Area 1 + by Routers RT3 and RT4. + + + + + +Moy Standards Track [Page 30] + +RFC 2178 OSPF Version 2 July 1997 + + + Router RT1 can also determine in this manner the shortest path to the + AS boundary routers RT5 and RT7. Then, by looking at RT5 and RT7's + AS-external-LSAs, Router RT1 can decide between RT5 or RT7 when + sending to a destination in another Autonomous System (one of the + networks N12-N15). + + Note that a failure of the line between Routers RT6 and RT10 will + cause the backbone to become disconnected. Configuring a virtual + link between Routers RT7 and RT10 will give the backbone more + connectivity and more resistance to such failures. + +3.5. IP subnetting support + + OSPF attaches an IP address mask to each advertised route. The mask + indicates the range of addresses being described by the particular + route. For example, a summary-LSA for the destination 128.185.0.0 + with a mask of 0xffff0000 actually is describing a single route to + the collection of destinations 128.185.0.0 - 128.185.255.255. + Similarly, host routes are always advertised with a mask of + 0xffffffff, indicating the presence of only a single destination. + + Including the mask with each advertised destination enables the + implementation of what is commonly referred to as variable-length + subnetting. This means that a single IP class A, B, or C network + number can be broken up into many subnets of various sizes. For + example, the network 128.185.0.0 could be broken up into 62 + variable-sized subnets: 15 subnets of size 4K, 15 subnets of size + 256, and 32 subnets of size 8. Table 7 shows some of the resulting + network addresses together with their masks. + + + Network address IP address mask Subnet size + _______________________________________________ + 128.185.16.0 0xfffff000 4K + 128.185.1.0 0xffffff00 256 + 128.185.0.8 0xfffffff8 8 + + + Table 7: Some sample subnet sizes. + + + There are many possible ways of dividing up a class A, B, and C + network into variable sized subnets. The precise procedure for doing + so is beyond the scope of this specification. This specification + however establishes the following guideline: When an IP packet is + forwarded, it is always forwarded to the network that is the best + match for the packet's destination. Here best match is synonymous + with the longest or most specific match. For example, the default + + + +Moy Standards Track [Page 31] + +RFC 2178 OSPF Version 2 July 1997 + + + route with destination of 0.0.0.0 and mask 0x00000000 is always a + match for every IP destination. Yet it is always less specific than + any other match. Subnet masks must be assigned so that the best + match for any IP destination is unambiguous. + + Attaching an address mask to each route also enables the support of + IP supernetting. For example, a single physical network segment could + be assigned the [address,mask] pair [192.9.4.0,0xfffffc00]. The + segment would then be single IP network, containing addresses from + the four consecutive class C network numbers 192.9.4.0 through + 192.9.7.0. Such addressing is now becoming commonplace with the + advent of CIDR (see [Ref10]). + + In order to get better aggregation at area boundaries, area address + ranges can be employed (see Section C.2 for more details). Each + address range is defined as an [address,mask] pair. Many separate + networks may then be contained in a single address range, just as a + subnetted network is composed of many separate subnets. Area border + routers then summarize the area contents (for distribution to the + backbone) by advertising a single route for each address range. The + cost of the route is the maximum cost to any of the networks falling + in the specified range. + + For example, an IP subnetted network might be configured as a single + OSPF area. In that case, a single address range could be configured: + a class A, B, or C network number along with its natural IP mask. + Inside the area, any number of variable sized subnets could be + defined. However, external to the area a single route for the entire + subnetted network would be distributed, hiding even the fact that the + network is subnetted at all. The cost of this route is the maximum + of the set of costs to the component subnets. + +3.6. Supporting stub areas + + In some Autonomous Systems, the majority of the link-state database + may consist of AS-external-LSAs. An OSPF AS-external-LSA is usually + flooded throughout the entire AS. However, OSPF allows certain areas + to be configured as "stub areas". AS-external-LSAs are not flooded + into/throughout stub areas; routing to AS external destinations in + these areas is based on a (per-area) default only. This reduces the + link-state database size, and therefore the memory requirements, for + a stub area's internal routers. + + In order to take advantage of the OSPF stub area support, default + routing must be used in the stub area. This is accomplished as + follows. One or more of the stub area's area border routers must + advertise a default route into the stub area via summary-LSAs. These + summary defaults are flooded throughout the stub area, but no + + + +Moy Standards Track [Page 32] + +RFC 2178 OSPF Version 2 July 1997 + + + further. (For this reason these defaults pertain only to the + particular stub area). These summary default routes will be used for + any destination that is not explicitly reachable by an intra-area or + inter-area path (i.e., AS external destinations). + + An area can be configured as a stub when there is a single exit point + from the area, or when the choice of exit point need not be made on a + per-external-destination basis. For example, Area 3 in Figure 6 + could be configured as a stub area, because all external traffic must + travel though its single area border router RT11. If Area 3 were + configured as a stub, Router RT11 would advertise a default route for + distribution inside Area 3 (in a summary-LSA), instead of flooding + the AS-external-LSAs for Networks N12-N15 into/throughout the area. + + The OSPF protocol ensures that all routers belonging to an area agree + on whether the area has been configured as a stub. This guarantees + that no confusion will arise in the flooding of AS-external-LSAs. + + There are a couple of restrictions on the use of stub areas. Virtual + links cannot be configured through stub areas. In addition, AS + boundary routers cannot be placed internal to stub areas. + +3.7. Partitions of areas + + OSPF does not actively attempt to repair area partitions. When an + area becomes partitioned, each component simply becomes a separate + area. The backbone then performs routing between the new areas. + Some destinations reachable via intra-area routing before the + partition will now require inter-area routing. + + However, in order to maintain full routing after the partition, an + address range must not be split across multiple components of the + area partition. Also, the backbone itself must not partition. If it + does, parts of the Autonomous System will become unreachable. + Backbone partitions can be repaired by configuring virtual links (see + Section 15). + + Another way to think about area partitions is to look at the + Autonomous System graph that was introduced in Section 2. Area IDs + can be viewed as colors for the graph's edges.[1] Each edge of the + graph connects to a network, or is itself a point-to-point network. + In either case, the edge is colored with the network's Area ID. + + A group of edges, all having the same color, and interconnected by + vertices, represents an area. If the topology of the Autonomous + System is intact, the graph will have several regions of color, each + color being a distinct Area ID. + + + + +Moy Standards Track [Page 33] + +RFC 2178 OSPF Version 2 July 1997 + + + When the AS topology changes, one of the areas may become + partitioned. The graph of the AS will then have multiple regions of + the same color (Area ID). The routing in the Autonomous System will + continue to function as long as these regions of same color are + connected by the single backbone region. + +4. Functional Summary + + A separate copy of OSPF's basic routing algorithm runs in each area. + Routers having interfaces to multiple areas run multiple copies of + the algorithm. A brief summary of the routing algorithm follows. + + When a router starts, it first initializes the routing protocol data + structures. The router then waits for indications from the lower- + level protocols that its interfaces are functional. + + A router then uses the OSPF's Hello Protocol to acquire neighbors. + The router sends Hello packets to its neighbors, and in turn receives + their Hello packets. On broadcast and point-to-point networks, the + router dynamically detects its neighboring routers by sending its + Hello packets to the multicast address AllSPFRouters. On non- + broadcast networks, some configuration information may be necessary + in order to discover neighbors. On broadcast and NBMA networks the + Hello Protocol also elects a Designated router for the network. + + The router will attempt to form adjacencies with some of its newly + acquired neighbors. Link-state databases are synchronized between + pairs of adjacent routers. On broadcast and NBMA networks, the + Designated Router determines which routers should become adjacent. + + Adjacencies control the distribution of routing information. Routing + updates are sent and received only on adjacencies. + + A router periodically advertises its state, which is also called link + state. Link state is also advertised when a router's state changes. + A router's adjacencies are reflected in the contents of its LSAs. + This relationship between adjacencies and link state allows the + protocol to detect dead routers in a timely fashion. + + LSAs are flooded throughout the area. The flooding algorithm is + reliable, ensuring that all routers in an area have exactly the same + link-state database. This database consists of the collection of + LSAs originated by each router belonging to the area. From this + database each router calculates a shortest-path tree, with itself as + root. This shortest-path tree in turn yields a routing table for the + protocol. + + + + + +Moy Standards Track [Page 34] + +RFC 2178 OSPF Version 2 July 1997 + + +4.1. Inter-area routing + + The previous section described the operation of the protocol within a + single area. For intra-area routing, no other routing information is + pertinent. In order to be able to route to destinations outside of + the area, the area border routers inject additional routing + information into the area. This additional information is a + distillation of the rest of the Autonomous System's topology. + + This distillation is accomplished as follows: Each area border router + is by definition connected to the backbone. Each area border router + summarizes the topology of its attached non-backbone areas for + transmission on the backbone, and hence to all other area border + routers. An area border router then has complete topological + information concerning the backbone, and the area summaries from each + of the other area border routers. From this information, the router + calculates paths to all inter-area destinations. The router then + advertises these paths into its attached areas. This enables the + area's internal routers to pick the best exit router when forwarding + traffic inter-area destinations. + +4.2. AS external routes + + Routers that have information regarding other Autonomous Systems can + flood this information throughout the AS. This external routing + information is distributed verbatim to every participating router. + There is one exception: external routing information is not flooded + into "stub" areas (see Section 3.6). + + To utilize external routing information, the path to all routers + advertising external information must be known throughout the AS + (excepting the stub areas). For that reason, the locations of these + AS boundary routers are summarized by the (non-stub) area border + routers. + +4.3. Routing protocol packets + + The OSPF protocol runs directly over IP, using IP protocol 89. OSPF + does not provide any explicit fragmentation/reassembly support. When + fragmentation is necessary, IP fragmentation/reassembly is used. + OSPF protocol packets have been designed so that large protocol + packets can generally be split into several smaller protocol packets. + This practice is recommended; IP fragmentation should be avoided + whenever possible. + + Routing protocol packets should always be sent with the IP TOS field + set to 0. If at all possible, routing protocol packets should be + given preference over regular IP data traffic, both when being sent + + + +Moy Standards Track [Page 35] + +RFC 2178 OSPF Version 2 July 1997 + + + and received. As an aid to accomplishing this, OSPF protocol packets + should have their IP precedence field set to the value Internetwork + Control (see [Ref5]). + + All OSPF protocol packets share a common protocol header that is + described in Appendix A. The OSPF packet types are listed below in + Table 8. Their formats are also described in Appendix A. + + + Type Packet name + Protocol function + __________________________________________________________ + 1 Hello Discover/maintain neighbors + 2 Database Description Summarize database contents + 3 Link State Request Database download + 4 Link State Update Database update + 5 Link State Ack Flooding acknowledgment + + + Table 8: OSPF packet types. + + OSPF's Hello protocol uses Hello packets to discover and maintain + neighbor relationships. The Database Description and Link State + Request packets are used in the forming of adjacencies. OSPF's + reliable update mechanism is implemented by the Link State Update and + Link State Acknowledgment packets. + + Each Link State Update packet carries a set of new link state + advertisements (LSAs) one hop further away from their point of + origination. A single Link State Update packet may contain the LSAs + of several routers. Each LSA is tagged with the ID of the + originating router and a checksum of its link state contents. Each + LSA also has a type field; the different types of OSPF LSAs are + listed below in Table 9. + + OSPF routing packets (with the exception of Hellos) are sent only + over adjacencies. This means that all OSPF protocol packets travel a + single IP hop, except those that are sent over virtual adjacencies. + The IP source address of an OSPF protocol packet is one end of a + router adjacency, and the IP destination address is either the other + end of the adjacency or an IP multicast address. + + + + + + + + + + +Moy Standards Track [Page 36] + +RFC 2178 OSPF Version 2 July 1997 + + + LS LSA LSA description + type name + ________________________________________________________ + 1 Router-LSAs Originated by all routers. + This LSA describes + the collected states of the + router's interfaces to an + area. Flooded throughout a + single area only. + ________________________________________________________ + 2 Network-LSAs Originated for broadcast + and NBMA networks by + the Designated Router. This + LSA contains the + list of routers connected + to the network. Flooded + throughout a single area only. + ________________________________________________________ + 3,4 Summary-LSAs Originated by area border + routers, and flooded through- + out the LSA's associated + area. Each summary-LSA + describes a route to a + destination outside the area, + yet still inside the AS + (i.e., an inter-area route). + Type 3 summary-LSAs describe + routes to networks. Type 4 + summary-LSAs describe + routes to AS boundary routers. + ________________________________________________________ + 5 AS-external-LSAs Originated by AS boundary + routers, and flooded through- + out the AS. Each + AS-external-LSA describes + a route to a destination in + another Autonomous System. + Default routes for the AS can + also be described by + AS-external-LSAs. + + Table 9: OSPF link state advertisements (LSAs). + + + + + + + + + +Moy Standards Track [Page 37] + +RFC 2178 OSPF Version 2 July 1997 + + +4.4. Basic implementation requirements + + An implementation of OSPF requires the following pieces of system + support: + + Timers + Two different kind of timers are required. The first kind, called + "single shot timers", fire once and cause a protocol event to be + processed. The second kind, called "interval timers", fire at + continuous intervals. These are used for the sending of packets + at regular intervals. A good example of this is the regular + broadcast of Hello packets. The granularity of both kinds of + timers is one second. + + Interval timers should be implemented to avoid drift. In some + router implementations, packet processing can affect timer + execution. When multiple routers are attached to a single + network, all doing broadcasts, this can lead to the + synchronization of routing packets (which should be avoided). If + timers cannot be implemented to avoid drift, small random amounts + should be added to/subtracted from the interval timer at each + firing. + + IP multicast + Certain OSPF packets take the form of IP multicast datagrams. + Support for receiving and sending IP multicast datagrams, along + with the appropriate lower-level protocol support, is required. + The IP multicast datagrams used by OSPF never travel more than one + hop. For this reason, the ability to forward IP multicast + datagrams is not required. For information on IP multicast, see + [Ref7]. + + Variable-length subnet support + The router's IP protocol support must include the ability to + divide a single IP class A, B, or C network number into many + subnets of various sizes. This is commonly called variable-length + subnetting; see Section 3.5 for details. + + IP supernetting support + The router's IP protocol support must include the ability to + aggregate contiguous collections of IP class A, B, and C networks + into larger quantities called supernets. Supernetting has been + proposed as one way to improve the scaling of IP routing in the + worldwide Internet. For more information on IP supernetting, see + [Ref10]. + + + + + + +Moy Standards Track [Page 38] + +RFC 2178 OSPF Version 2 July 1997 + + + Lower-level protocol support + The lower level protocols referred to here are the network access + protocols, such as the Ethernet data link layer. Indications must + be passed from these protocols to OSPF as the network interface + goes up and down. For example, on an ethernet it would be + valuable to know when the ethernet transceiver cable becomes + unplugged. + + Non-broadcast lower-level protocol support + On non-broadcast networks, the OSPF Hello Protocol can be aided by + providing an indication when an attempt is made to send a packet + to a dead or non-existent router. For example, on an X.25 PDN a + dead neighboring router may be indicated by the reception of a + X.25 clear with an appropriate cause and diagnostic, and this + information would be passed to OSPF. + + List manipulation primitives + Much of the OSPF functionality is described in terms of its + operation on lists of LSAs. For example, the collection of LSAs + that will be retransmitted to an adjacent router until + acknowledged are described as a list. Any particular LSA may be + on many such lists. An OSPF implementation needs to be able to + manipulate these lists, adding and deleting constituent LSAs as + necessary. + + Tasking support + Certain procedures described in this specification invoke other + procedures. At times, these other procedures should be executed + in-line, that is, before the current procedure is finished. This + is indicated in the text by instructions to execute a procedure. + At other times, the other procedures are to be executed only when + the current procedure has finished. This is indicated by + instructions to schedule a task. + +4.5. Optional OSPF capabilities + + The OSPF protocol defines several optional capabilities. A router + indicates the optional capabilities that it supports in its OSPF + Hello packets, Database Description packets and in its LSAs. This + enables routers supporting a mix of optional capabilities to coexist + in a single Autonomous System. + + Some capabilities must be supported by all routers attached to a + specific area. In this case, a router will not accept a neighbor's + Hello Packet unless there is a match in reported capabilities (i.e., + a capability mismatch prevents a neighbor relationship from forming). + An example of this is the ExternalRoutingCapability (see below). + + + + +Moy Standards Track [Page 39] + +RFC 2178 OSPF Version 2 July 1997 + + + Other capabilities can be negotiated during the Database Exchange + process. This is accomplished by specifying the optional + capabilities in Database Description packets. A capability mismatch + with a neighbor in this case will result in only a subset of the link + state database being exchanged between the two neighbors. + + The routing table build process can also be affected by the + presence/absence of optional capabilities. For example, since the + optional capabilities are reported in LSAs, routers incapable of + certain functions can be avoided when building the shortest path + tree. + + The OSPF optional capabilities defined in this memo are listed below. + See Section A.2 for more information. + + ExternalRoutingCapability + Entire OSPF areas can be configured as "stubs" (see Section 3.6). + AS-external-LSAs will not be flooded into stub areas. This + capability is represented by the E-bit in the OSPF Options field + (see Section A.2). In order to ensure consistent configuration of + stub areas, all routers interfacing to such an area must have the + E-bit clear in their Hello packets (see Sections 9.5 and 10.5). + +5. Protocol Data Structures + + The OSPF protocol is described herein in terms of its operation on + various protocol data structures. The following list comprises the + top-level OSPF data structures. Any initialization that needs to be + done is noted. OSPF areas, interfaces and neighbors also have + associated data structures that are described later in this + specification. + + Router ID + A 32-bit number that uniquely identifies this router in the AS. + One possible implementation strategy would be to use the smallest + IP interface address belonging to the router. If a router's OSPF + Router ID is changed, the router's OSPF software should be + restarted before the new Router ID takes effect. In this case the + router should flush its self-originated LSAs from the routing + domain (see Section 14.1) before restarting, or they will persist + for up to MaxAge minutes. + + Area structures + Each one of the areas to which the router is connected has its own + data structure. This data structure describes the working of the + basic OSPF algorithm. Remember that each area runs a separate + copy of the basic OSPF algorithm. + + + + +Moy Standards Track [Page 40] + +RFC 2178 OSPF Version 2 July 1997 + + + Backbone (area) structure + The OSPF backbone area is responsible for the dissemination of + inter-area routing information. + + Virtual links configured + The virtual links configured with this router as one endpoint. In + order to have configured virtual links, the router itself must be + an area border router. Virtual links are identified by the Router + ID of the other endpoint -- which is another area border router. + These two endpoint routers must be attached to a common area, + called the virtual link's Transit area. Virtual links are part of + the backbone, and behave as if they were unnumbered point-to-point + networks between the two routers. A virtual link uses the intra- + area routing of its Transit area to forward packets. Virtual + links are brought up and down through the building of the + shortest-path trees for the Transit area. + + List of external routes + These are routes to destinations external to the Autonomous + System, that have been gained either through direct experience + with another routing protocol (such as BGP), or through + configuration information, or through a combination of the two + (e.g., dynamic external information to be advertised by OSPF with + configured metric). Any router having these external routes is + called an AS boundary router. These routes are advertised by the + router into the OSPF routing domain via AS-external-LSAs. + + List of AS-external-LSAs + Part of the link-state database. These have originated from the + AS boundary routers. They comprise routes to destinations + external to the Autonomous System. Note that, if the router is + itself an AS boundary router, some of these AS-external-LSAs have + been self-originated. + + The routing table + Derived from the link-state database. Each entry in the routing + table is indexed by a destination, and contains the destination's + cost and a set of paths to use in forwarding packets to the + destination. A path is described by its type and next hop. For + more information, see Section 11. + + + + + + + + + + + +Moy Standards Track [Page 41] + +RFC 2178 OSPF Version 2 July 1997 + + + Figure 9 shows the collection of data structures present in a typical + router. The router pictured is RT10, from the map in Figure 6. Note + that Router RT10 has a virtual link configured to Router RT11, with + Area 2 as the link's Transit area. This is indicated by the dashed + line in Figure 9. When the virtual link becomes active, through the + building of the shortest path tree for Area 2, it becomes an + interface to the backbone (see the two backbone interfaces depicted + in Figure 9). + + + +----+ + |RT10|------+ + +----+ \+-------------+ + / \ |Routing Table| + / \ +-------------+ + / \ + +------+ / \ +--------+ + |Area 2|---+ +---|Backbone| + +------+***********+ +--------+ + / \ * / \ + / \ * / \ + +---------+ +---------+ +------------+ +------------+ + |Interface| |Interface| |Virtual Link| |Interface Ib| + | to N6 | | to N8 | | to RT11 | +------------+ + +---------+ +---------+ +------------+ | + / \ | | | + / \ | | | + +--------+ +--------+ | +-------------+ +------------+ + |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| + | RT8 | | RT7 | | +-------------+ +------------+ + +--------+ +--------+ | + | + +-------------+ + |Neighbor RT11| + +-------------+ + + + Figure 9: Router RT10's Data structures + +6. The Area Data Structure + + The area data structure contains all the information used to run the + basic OSPF routing algorithm. Each area maintains its own link-state + database. A network belongs to a single area, and a router interface + connects to a single area. Each router adjacency also belongs to a + single area. + + + + + +Moy Standards Track [Page 42] + +RFC 2178 OSPF Version 2 July 1997 + + + The OSPF backbone is the special OSPF area responsible for + disseminating inter-area routing information. + + The area link-state database consists of the collection of router- + LSAs, network-LSAs and summary-LSAs that have originated from the + area's routers. This information is flooded throughout a single area + only. The list of AS-external-LSAs (see Section 5) is also considered + to be part of each area's link-state database. + + Area ID + A 32-bit number identifying the area. The Area ID of 0.0.0.0 is + reserved for the backbone. + + List of area address ranges + In order to aggregate routing information at area boundaries, area + address ranges can be employed. Each address range is specified by + an [address,mask] pair and a status indication of either Advertise + or DoNotAdvertise (see Section 12.4.3). + + Associated router interfaces + This router's interfaces connecting to the area. A router + interface belongs to one and only one area (or the backbone). For + the backbone area this list includes all the virtual links. A + virtual link is identified by the Router ID of its other endpoint; + its cost is the cost of the shortest intra-area path through the + Transit area that exists between the two routers. + + List of router-LSAs + A router-LSA is generated by each router in the area. It + describes the state of the router's interfaces to the area. + + List of network-LSAs + One network-LSA is generated for each transit broadcast and NBMA + network in the area. A network-LSA describes the set of routers + currently connected to the network. + + List of summary-LSAs + Summary-LSAs originate from the area's area border routers. They + describe routes to destinations internal to the Autonomous System, + yet external to the area (i.e., inter-area destinations). + + Shortest-path tree + The shortest-path tree for the area, with this router itself as + root. Derived from the collected router-LSAs and network-LSAs by + the Dijkstra algorithm (see Section 16.1). + + + + + + +Moy Standards Track [Page 43] + +RFC 2178 OSPF Version 2 July 1997 + + + TransitCapability + This parameter indicates whether the area can carry data traffic + that neither originates nor terminates in the area itself. This + parameter is calculated when the area's shortest-path tree is + built (see Section 16.1, where TransitCapability is set to TRUE if + and only if there are one or more fully adjacent virtual links + using the area as Transit area), and is used as an input to a + subsequent step of the routing table build process (see Section + 16.3). When an area's TransitCapability is set to TRUE, the area + is said to be a "transit area". + + ExternalRoutingCapability + Whether AS-external-LSAs will be flooded into/throughout the area. + This is a configurable parameter. If AS-external-LSAs are + excluded from the area, the area is called a "stub". Within stub + areas, routing to AS external destinations will be based solely on + a default summary route. The backbone cannot be configured as a + stub area. Also, virtual links cannot be configured through stub + areas. For more information, see Section 3.6. + + StubDefaultCost + If the area has been configured as a stub area, and the router + itself is an area border router, then the StubDefaultCost + indicates the cost of the default summary-LSA that the router + should advertise into the area. See Section 12.4.3 for more + information. + + Unless otherwise specified, the remaining sections of this document + refer to the operation of the OSPF protocol within a single area. + +7. Bringing Up Adjacencies + + OSPF creates adjacencies between neighboring routers for the purpose + of exchanging routing information. Not every two neighboring routers + will become adjacent. This section covers the generalities involved + in creating adjacencies. For further details consult Section 10. + +7.1. The Hello Protocol + + The Hello Protocol is responsible for establishing and maintaining + neighbor relationships. It also ensures that communication between + neighbors is bidirectional. Hello packets are sent periodically out + all router interfaces. Bidirectional communication is indicated when + the router sees itself listed in the neighbor's Hello Packet. On + broadcast and NBMA networks, the Hello Protocol elects a Designated + Router for the network. + + + + + +Moy Standards Track [Page 44] + +RFC 2178 OSPF Version 2 July 1997 + + + The Hello Protocol works differently on broadcast networks, NBMA + networks and Point-to-MultiPoint networks. On broadcast networks, + each router advertises itself by periodically multicasting Hello + Packets. This allows neighbors to be discovered dynamically. These + Hello Packets contain the router's view of the Designated Router's + identity, and the list of routers whose Hello Packets have been seen + recently. + + On NBMA networks some configuration information may be necessary for + the operation of the Hello Protocol. Each router that may + potentially become Designated Router has a list of all other routers + attached to the network. A router, having Designated Router + potential, sends Hello Packets to all other potential Designated + Routers when its interface to the NBMA network first becomes + operational. This is an attempt to find the Designated Router for + the network. If the router itself is elected Designated Router, it + begins sending Hello Packets to all other routers attached to the + network. + + On Point-to-MultiPoint networks, a router sends Hello Packets to all + neighbors with which it can communicate directly. These neighbors may + be discovered dynamically through a protocol such as Inverse ARP (see + [Ref14]), or they may be configured. + + After a neighbor has been discovered, bidirectional communication + ensured, and (if on a broadcast or NBMA network) a Designated Router + elected, a decision is made regarding whether or not an adjacency + should be formed with the neighbor (see Section 10.4). If an + adjacency is to be formed, the first step is to synchronize the + neighbors' link-state databases. This is covered in the next + section. + +7.2. The Synchronization of Databases + + In a link-state routing algorithm, it is very important for all + routers' link-state databases to stay synchronized. OSPF simplifies + this by requiring only adjacent routers to remain synchronized. The + synchronization process begins as soon as the routers attempt to + bring up the adjacency. Each router describes its database by + sending a sequence of Database Description packets to its neighbor. + Each Database Description Packet describes a set of LSAs belonging to + the router's database. When the neighbor sees an LSA that is more + recent than its own database copy, it makes a note that this newer + LSA should be requested. + + This sending and receiving of Database Description packets is called + the "Database Exchange Process". During this process, the two + routers form a master/slave relationship. Each Database Description + + + +Moy Standards Track [Page 45] + +RFC 2178 OSPF Version 2 July 1997 + + + Packet has a sequence number. Database Description Packets sent by + the master (polls) are acknowledged by the slave through echoing of + the sequence number. Both polls and their responses contain + summaries of link state data. The master is the only one allowed to + retransmit Database Description Packets. It does so only at fixed + intervals, the length of which is the configured per-interface + constant RxmtInterval. + + Each Database Description contains an indication that there are more + packets to follow --- the M-bit. The Database Exchange Process is + over when a router has received and sent Database Description Packets + with the M-bit off. + + During and after the Database Exchange Process, each router has a + list of those LSAs for which the neighbor has more up-to-date + instances. These LSAs are requested in Link State Request Packets. + Link State Request packets that are not satisfied are retransmitted + at fixed intervals of time RxmtInterval. When the Database + Description Process has completed and all Link State Requests have + been satisfied, the databases are deemed synchronized and the routers + are marked fully adjacent. At this time the adjacency is fully + functional and is advertised in the two routers' router-LSAs. + + The adjacency is used by the flooding procedure as soon as the + Database Exchange Process begins. This simplifies database + synchronization, and guarantees that it finishes in a predictable + period of time. + +7.3. The Designated Router + + Every broadcast and NBMA network has a Designated Router. The + Designated Router performs two main functions for the routing + protocol: + + o The Designated Router originates a network-LSA on behalf of + the network. This LSA lists the set of routers (including + the Designated Router itself) currently attached to the + network. The Link State ID for this LSA (see Section + 12.1.4) is the IP interface address of the Designated + Router. The IP network number can then be obtained by using + the network's subnet/network mask. + + o The Designated Router becomes adjacent to all other routers + on the network. Since the link state databases are + synchronized across adjacencies (through adjacency bring-up + and then the flooding procedure), the Designated Router + plays a central part in the synchronization process. + + + + +Moy Standards Track [Page 46] + +RFC 2178 OSPF Version 2 July 1997 + + + The Designated Router is elected by the Hello Protocol. A router's + Hello Packet contains its Router Priority, which is configurable on a + per-interface basis. In general, when a router's interface to a + network first becomes functional, it checks to see whether there is + currently a Designated Router for the network. If there is, it + accepts that Designated Router, regardless of its Router Priority. + (This makes it harder to predict the identity of the Designated + Router, but ensures that the Designated Router changes less often. + See below.) Otherwise, the router itself becomes Designated Router + if it has the highest Router Priority on the network. A more + detailed (and more accurate) description of Designated Router + election is presented in Section 9.4. + + The Designated Router is the endpoint of many adjacencies. In order + to optimize the flooding procedure on broadcast networks, the + Designated Router multicasts its Link State Update Packets to the + address AllSPFRouters, rather than sending separate packets over each + adjacency. + + Section 2 of this document discusses the directed graph + representation of an area. Router nodes are labelled with their + Router ID. Transit network nodes are actually labelled with the IP + address of their Designated Router. It follows that when the + Designated Router changes, it appears as if the network node on the + graph is replaced by an entirely new node. This will cause the + network and all its attached routers to originate new LSAs. Until + the link-state databases again converge, some temporary loss of + connectivity may result. This may result in ICMP unreachable + messages being sent in response to data traffic. For that reason, + the Designated Router should change only infrequently. Router + Priorities should be configured so that the most dependable router on + a network eventually becomes Designated Router. + +7.4. The Backup Designated Router + + In order to make the transition to a new Designated Router smoother, + there is a Backup Designated Router for each broadcast and NBMA + network. The Backup Designated Router is also adjacent to all + routers on the network, and becomes Designated Router when the + previous Designated Router fails. If there were no Backup Designated + Router, when a new Designated Router became necessary, new + adjacencies would have to be formed between the new Designated Router + and all other routers attached to the network. Part of the adjacency + forming process is the synchronizing of link-state databases, which + can potentially take quite a long time. During this time, the + network would not be available for transit data traffic. The Backup + Designated obviates the need to form these adjacencies, since they + already exist. This means the period of disruption in transit + + + +Moy Standards Track [Page 47] + +RFC 2178 OSPF Version 2 July 1997 + + + traffic lasts only as long as it takes to flood the new LSAs (which + announce the new Designated Router). + + The Backup Designated Router does not generate a network-LSA for the + network. (If it did, the transition to a new Designated Router would + be even faster. However, this is a tradeoff between database size + and speed of convergence when the Designated Router disappears.) + + The Backup Designated Router is also elected by the Hello Protocol. + Each Hello Packet has a field that specifies the Backup Designated + Router for the network. + + In some steps of the flooding procedure, the Backup Designated Router + plays a passive role, letting the Designated Router do more of the + work. This cuts down on the amount of local routing traffic. See + Section 13.3 for more information. + +7.5. The graph of adjacencies + + An adjacency is bound to the network that the two routers have in + common. If two routers have multiple networks in common, they may + have multiple adjacencies between them. + + One can picture the collection of adjacencies on a network as forming + an undirected graph. The vertices consist of routers, with an edge + joining two routers if they are adjacent. The graph of adjacencies + describes the flow of routing protocol packets, and in particular + Link State Update Packets, through the Autonomous System. + + Two graphs are possible, depending on whether a Designated Router is + elected for the network. On physical point-to-point networks, + Point-to-MultiPoint networks and virtual links, neighboring routers + become adjacent whenever they can communicate directly. In contrast, + on broadcast and NBMA networks only the Designated Router and the + Backup Designated Router become adjacent to all other routers + attached to the network. + + These graphs are shown in Figure 10. It is assumed that Router RT7 + has become the Designated Router, and Router RT3 the Backup + Designated Router, for the Network N2. The Backup Designated Router + performs a lesser function during the flooding procedure than the + Designated Router (see Section 13.3). This is the reason for the + dashed lines connecting the Backup Designated Router RT3. + + + + + + + + +Moy Standards Track [Page 48] + +RFC 2178 OSPF Version 2 July 1997 + + + +---+ +---+ + |RT1|------------|RT2| o---------------o + +---+ N1 +---+ RT1 RT2 + + + + RT7 + o---------+ + +---+ +---+ +---+ /|\ | + |RT7| |RT3| |RT4| / | \ | + +---+ +---+ +---+ / | \ | + | | | / | \ | + +-----------------------+ RT5o RT6o oRT4 | + | | N2 * * * | + +---+ +---+ * * * | + |RT5| |RT6| * * * | + +---+ +---+ *** | + o---------+ + RT3 + + + Figure 10: The graph of adjacencies + +8. Protocol Packet Processing + + This section discusses the general processing of OSPF routing + protocol packets. It is very important that the router link-state + databases remain synchronized. For this reason, routing protocol + packets should get preferential treatment over ordinary data packets, + both in sending and receiving. + + Routing protocol packets are sent along adjacencies only (with the + exception of Hello packets, which are used to discover the + adjacencies). This means that all routing protocol packets travel a + single IP hop, except those sent over virtual links. + + All routing protocol packets begin with a standard header. The + sections below provide details on how to fill in and verify this + standard header. Then, for each packet type, the section giving more + details on that particular packet type's processing is listed. + +8.1. Sending protocol packets + + When a router sends a routing protocol packet, it fills in the fields + of the standard OSPF packet header as follows. For more details on + the header format consult Section A.3.1: + + + + + +Moy Standards Track [Page 49] + +RFC 2178 OSPF Version 2 July 1997 + + + Version # + Set to 2, the version number of the protocol as documented in this + specification. + + Packet type + The type of OSPF packet, such as Link state Update or Hello + Packet. + + Packet length + The length of the entire OSPF packet in bytes, including the + standard OSPF packet header. + + Router ID + The identity of the router itself (who is originating the packet). + + Area ID + The OSPF area that the packet is being sent into. + + Checksum + The standard IP 16-bit one's complement checksum of the entire + OSPF packet, excluding the 64-bit authentication field. This + checksum is calculated as part of the appropriate authentication + procedure; for some OSPF authentication types, the checksum + calculation is omitted. See Section D.4 for details. + + AuType and Authentication + Each OSPF packet exchange is authenticated. Authentication types + are assigned by the protocol and are documented in Appendix D. A + different authentication procedure can be used for each IP + network/subnet. Autype indicates the type of authentication + procedure in use. The 64-bit authentication field is then for use + by the chosen authentication procedure. This procedure should be + the last called when forming the packet to be sent. See Section + D.4 for details. + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 50] + +RFC 2178 OSPF Version 2 July 1997 + + + The IP destination address for the packet is selected as follows. On + physical point-to-point networks, the IP destination is always set to + the address AllSPFRouters. On all other network types (including + virtual links), the majority of OSPF packets are sent as unicasts, + i.e., sent directly to the other end of the adjacency. In this case, + the IP destination is just the Neighbor IP address associated with + the other end of the adjacency (see Section 10). The only packets + not sent as unicasts are on broadcast networks; on these networks + Hello packets are sent to the multicast destination AllSPFRouters, + the Designated Router and its Backup send both Link State Update + Packets and Link State Acknowledgment Packets to the multicast + address AllSPFRouters, while all other routers send both their Link + State Update and Link State Acknowledgment Packets to the multicast + address AllDRouters. + + Retransmissions of Link State Update packets are ALWAYS sent as + unicasts. + + The IP source address should be set to the IP address of the sending + interface. Interfaces to unnumbered point-to-point networks have no + associated IP address. On these interfaces, the IP source should be + set to any of the other IP addresses belonging to the router. For + this reason, there must be at least one IP address assigned to the + router.[2] Note that, for most purposes, virtual links act precisely + the same as unnumbered point-to-point networks. However, each + virtual link does have an IP interface address (discovered during the + routing table build process) which is used as the IP source when + sending packets over the virtual link. + + For more information on the format of specific OSPF packet types, + consult the sections listed in Table 10. + + + Type Packet name detailed section (transmit) + _________________________________________________________ + 1 Hello Section 9.5 + 2 Database description Section 10.8 + 3 Link state request Section 10.9 + 4 Link state update Section 13.3 + 5 Link state ack Section 13.5 + + Table 10: Sections describing OSPF protocol packet transmission. + +8.2. Receiving protocol packets + + Whenever a protocol packet is received by the router it is marked + with the interface it was received on. For routers that have virtual + links configured, it may not be immediately obvious which interface + + + +Moy Standards Track [Page 51] + +RFC 2178 OSPF Version 2 July 1997 + + + to associate the packet with. For example, consider the Router RT11 + depicted in Figure 6. If RT11 receives an OSPF protocol packet on + its interface to Network N8, it may want to associate the packet with + the interface to Area 2, or with the virtual link to Router RT10 + (which is part of the backbone). In the following, we assume that + the packet is initially associated with the non-virtual link.[3] + + In order for the packet to be accepted at the IP level, it must pass + a number of tests, even before the packet is passed to OSPF for + processing: + + o The IP checksum must be correct. + + o The packet's IP destination address must be the IP address + of the receiving interface, or one of the IP multicast + addresses AllSPFRouters or AllDRouters. + + o The IP protocol specified must be OSPF (89). + + o Locally originated packets should not be passed on to OSPF. + That is, the source IP address should be examined to make + sure this is not a multicast packet that the router itself + generated. + + Next, the OSPF packet header is verified. The fields specified + in the header must match those configured for the receiving + interface. If they do not, the packet should be discarded: + + + o The version number field must specify protocol version 2. + + o The Area ID found in the OSPF header must be verified. If + both of the following cases fail, the packet should be + discarded. The Area ID specified in the header must either: + + (1) Match the Area ID of the receiving interface. In this + case, the packet has been sent over a single hop. + Therefore, the packet's IP source address is required to + be on the same network as the receiving interface. This + can be verified by comparing the packet's IP source + address to the interface's IP address, after masking + both addresses with the interface mask. This comparison + should not be performed on point-to-point networks. On + point-to-point networks, the interface addresses of each + end of the link are assigned independently, if they are + assigned at all. + + + + + +Moy Standards Track [Page 52] + +RFC 2178 OSPF Version 2 July 1997 + + + (2) Indicate the backbone. In this case, the packet has + been sent over a virtual link. The receiving router + must be an area border router, and the Router ID + specified in the packet (the source router) must be the + other end of a configured virtual link. The receiving + interface must also attach to the virtual link's + configured Transit area. If all of these checks + succeed, the packet is accepted and is from now on + associated with the virtual link (and the backbone + area). + + o Packets whose IP destination is AllDRouters should only be + accepted if the state of the receiving interface is DR or + Backup (see Section 9.1). + + o The AuType specified in the packet must match the AuType + specified for the associated area. + + o The packet must be authenticated. The authentication + procedure is indicated by the setting of AuType (see + Appendix D). The authentication procedure may use one or + more Authentication keys, which can be configured on a per- + interface basis. The authentication procedure may also + verify the checksum field in the OSPF packet header (which, + when used, is set to the standard IP 16-bit one's complement + checksum of the OSPF packet's contents after excluding the + 64-bit authentication field). If the authentication + procedure fails, the packet should be discarded. + + If the packet type is Hello, it should then be further processed by + the Hello Protocol (see Section 10.5). All other packet types are + sent/received only on adjacencies. This means that the packet must + have been sent by one of the router's active neighbors. If the + receiving interface connects to a broadcast network, Point-to- + MultiPoint network or NBMA network the sender is identified by the IP + source address found in the packet's IP header. If the receiving + interface connects to a point-to-point network or a virtual link, the + sender is identified by the Router ID (source router) found in the + packet's OSPF header. The data structure associated with the + receiving interface contains the list of active neighbors. Packets + not matching any active neighbor are discarded. + + At this point all received protocol packets are associated with an + active neighbor. For the further input processing of specific packet + types, consult the sections listed in Table 11. + + + + + + +Moy Standards Track [Page 53] + +RFC 2178 OSPF Version 2 July 1997 + + + Type Packet name detailed section (receive) + ________________________________________________________ + 1 Hello Section 10.5 + 2 Database description Section 10.6 + 3 Link state request Section 10.7 + 4 Link state update Section 13 + 5 Link state ack Section 13.7 + + Table 11: Sections describing OSPF protocol packet reception. + +9. The Interface Data Structure + + An OSPF interface is the connection between a router and a network. + We assume a single OSPF interface to each attached network/subnet, + although supporting multiple interfaces on a single network is + considered in Appendix F. Each interface structure has at most one IP + interface address. + + An OSPF interface can be considered to belong to the area that + contains the attached network. All routing protocol packets + originated by the router over this interface are labelled with the + interface's Area ID. One or more router adjacencies may develop over + an interface. A router's LSAs reflect the state of its interfaces and + their associated adjacencies. + + The following data items are associated with an interface. Note that + a number of these items are actually configuration for the attached + network; such items must be the same for all routers connected to the + network. + + Type + The OSPF interface type is either point-to-point, broadcast, NBMA, + Point-to-MultiPoint or virtual link. + + State + The functional level of an interface. State determines whether or + not full adjacencies are allowed to form over the interface. + State is also reflected in the router's LSAs. + + IP interface address + The IP address associated with the interface. This appears as the + IP source address in all routing protocol packets originated over + this interface. Interfaces to unnumbered point-to-point networks + do not have an associated IP address. + + IP interface mask + Also referred to as the subnet mask, this indicates the portion of + the IP interface address that identifies the attached network. + + + +Moy Standards Track [Page 54] + +RFC 2178 OSPF Version 2 July 1997 + + + Masking the IP interface address with the IP interface mask yields + the IP network number of the attached network. On point-to-point + networks and virtual links, the IP interface mask is not defined. + On these networks, the link itself is not assigned an IP network + number, and so the addresses of each side of the link are assigned + independently, if they are assigned at all. + + Area ID + The Area ID of the area to which the attached network belongs. + All routing protocol packets originating from the interface are + labelled with this Area ID. + + HelloInterval + The length of time, in seconds, between the Hello packets that the + router sends on the interface. Advertised in Hello packets sent + out this interface. + + RouterDeadInterval + The number of seconds before the router's neighbors will declare + it down, when they stop hearing the router's Hello Packets. + Advertised in Hello packets sent out this interface. + + InfTransDelay + The estimated number of seconds it takes to transmit a Link State + Update Packet over this interface. LSAs contained in the Link + State Update packet will have their age incremented by this amount + before transmission. This value should take into account + transmission and propagation delays; it must be greater than zero. + + Router Priority + An 8-bit unsigned integer. When two routers attached to a network + both attempt to become Designated Router, the one with the highest + Router Priority takes precedence. A router whose Router Priority + is set to 0 is ineligible to become Designated Router on the + attached network. Advertised in Hello packets sent out this + interface. + + Hello Timer + An interval timer that causes the interface to send a Hello + packet. This timer fires every HelloInterval seconds. Note that + on non-broadcast networks a separate Hello packet is sent to each + qualified neighbor. + + Wait Timer + A single shot timer that causes the interface to exit the Waiting + state, and as a consequence select a Designated Router on the + network. The length of the timer is RouterDeadInterval seconds. + + + + +Moy Standards Track [Page 55] + +RFC 2178 OSPF Version 2 July 1997 + + + List of neighboring routers + The other routers attached to this network. This list is formed + by the Hello Protocol. Adjacencies will be formed to some of + these neighbors. The set of adjacent neighbors can be determined + by an examination of all of the neighbors' states. + + Designated Router + The Designated Router selected for the attached network. The + Designated Router is selected on all broadcast and NBMA networks + by the Hello Protocol. Two pieces of identification are kept for + the Designated Router: its Router ID and its IP interface address + on the network. The Designated Router advertises link state for + the network; this network-LSA is labelled with the Designated + Router's IP address. The Designated Router is initialized to + 0.0.0.0, which indicates the lack of a Designated Router. + + Backup Designated Router + The Backup Designated Router is also selected on all broadcast and + NBMA networks by the Hello Protocol. All routers on the attached + network become adjacent to both the Designated Router and the + Backup Designated Router. The Backup Designated Router becomes + Designated Router when the current Designated Router fails. The + Backup Designated Router is initialized to 0.0.0.0, indicating the + lack of a Backup Designated Router. + + Interface output cost(s) + The cost of sending a data packet on the interface, expressed in + the link state metric. This is advertised as the link cost for + this interface in the router-LSA. The cost of an interface must be + greater than zero. + + RxmtInterval + The number of seconds between LSA retransmissions, for adjacencies + belonging to this interface. Also used when retransmitting + Database Description and Link State Request Packets. + + AuType + The type of authentication used on the attached network/subnet. + Authentication types are defined in Appendix D. All OSPF packet + exchanges are authenticated. Different authentication schemes may + be used on different networks/subnets. + + + + + + + + + + +Moy Standards Track [Page 56] + +RFC 2178 OSPF Version 2 July 1997 + + + Authentication key + This configured data allows the authentication procedure to + generate and/or verify OSPF protocol packets. The Authentication + key can be configured on a per-interface basis. For example, if + the AuType indicates simple password, the Authentication key would + be a 64-bit clear password which is inserted into the OSPF packet + header. If instead Autype indicates Cryptographic authentication, + then the Authentication key is a shared secret which enables the + generation/verification of message digests which are appended to + the OSPF protocol packets. When Cryptographic authentication is + used, multiple simultaneous keys are supported in order to achieve + smooth key transition (see Section D.3). + +9.1. Interface states + + The various states that router interfaces may attain is documented in + this section. The states are listed in order of progressing + functionality. For example, the inoperative state is listed first, + followed by a list of intermediate states before the final, fully + functional state is achieved. The specification makes use of this + ordering by sometimes making references such as "those interfaces in + state greater than X". Figure 11 shows the graph of interface state + changes. The arcs of the graph are labelled with the event causing + the state change. These events are documented in Section 9.2. The + interface state machine is described in more detail in Section 9.3. + + Down + This is the initial interface state. In this state, the lower- + level protocols have indicated that the interface is unusable. No + protocol traffic at all will be sent or received on such a + interface. In this state, interface parameters should be set to + their initial values. + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 57] + +RFC 2178 OSPF Version 2 July 1997 + + + +----+ UnloopInd +--------+ + |Down|<--------------|Loopback| + +----+ +--------+ + | + |InterfaceUp + +-------+ | +--------------+ + |Waiting|<-+-------------->|Point-to-point| + +-------+ +--------------+ + | + WaitTimer|BackupSeen + | + | + | NeighborChange + +------+ +-+<---------------- +-------+ + |Backup|<----------|?|----------------->|DROther| + +------+---------->+-+<-----+ +-------+ + Neighbor | | + Change | |Neighbor + | |Change + | +--+ + +---->|DR| + +--+ + + Figure 11: Interface State changes + + In addition to the state transitions pictured, + Event InterfaceDown always forces Down State, and + Event LoopInd always forces Loopback State + + All interface timers should be disabled, and there should be no + adjacencies associated with the interface. + + Loopback + In this state, the router's interface to the network is looped + back. The interface may be looped back in hardware or software. + The interface will be unavailable for regular data traffic. + However, it may still be desirable to gain information on the + quality of this interface, either through sending ICMP pings to + the interface or through something like a bit error test. For + this reason, IP packets may still be addressed to an interface in + Loopback state. To facilitate this, such interfaces are + advertised in router-LSAs as single host routes, whose destination + is the IP interface address.[4] + + + + + + + + +Moy Standards Track [Page 58] + +RFC 2178 OSPF Version 2 July 1997 + + + Waiting + In this state, the router is trying to determine the identity of + the (Backup) Designated Router for the network. To do this, the + router monitors the Hello Packets it receives. The router is not + allowed to elect a Backup Designated Router nor a Designated + Router until it transitions out of Waiting state. This prevents + unnecessary changes of (Backup) Designated Router. + + Point-to-point + In this state, the interface is operational, and connects either + to a physical point-to-point network or to a virtual link. Upon + entering this state, the router attempts to form an adjacency with + the neighboring router. Hello Packets are sent to the neighbor + every HelloInterval seconds. + + DR Other + The interface is to a broadcast or NBMA network on which another + router has been selected to be the Designated Router. In this + state, the router itself has not been selected Backup Designated + Router either. The router forms adjacencies to both the + Designated Router and the Backup Designated Router (if they + exist). + + Backup + In this state, the router itself is the Backup Designated Router + on the attached network. It will be promoted to Designated Router + when the present Designated Router fails. The router establishes + adjacencies to all other routers attached to the network. The + Backup Designated Router performs slightly different functions + during the Flooding Procedure, as compared to the Designated + Router (see Section 13.3). See Section 7.4 for more details on + the functions performed by the Backup Designated Router. + + DR In this state, this router itself is the Designated Router + on the attached network. Adjacencies are established to all other + routers attached to the network. The router must also originate a + network-LSA for the network node. The network-LSA will contain + links to all routers (including the Designated Router itself) + attached to the network. See Section 7.3 for more details on the + functions performed by the Designated Router. + +9.2. Events causing interface state changes + + State changes can be effected by a number of events. These events + are pictured as the labelled arcs in Figure 11. The label + definitions are listed below. For a detailed explanation of the + effect of these events on OSPF protocol operation, consult Section + 9.3. + + + +Moy Standards Track [Page 59] + +RFC 2178 OSPF Version 2 July 1997 + + + InterfaceUp + Lower-level protocols have indicated that the network interface is + operational. This enables the interface to transition out of Down + state. On virtual links, the interface operational indication is + actually a result of the shortest path calculation (see Section + 16.7). + + WaitTimer + The Wait Timer has fired, indicating the end of the waiting period + that is required before electing a (Backup) Designated Router. + + BackupSeen + The router has detected the existence or non-existence of a Backup + Designated Router for the network. This is done in one of two + ways. First, an Hello Packet may be received from a neighbor + claiming to be itself the Backup Designated Router. + Alternatively, an Hello Packet may be received from a neighbor + claiming to be itself the Designated Router, and indicating that + there is no Backup Designated Router. In either case there must + be bidirectional communication with the neighbor, i.e., the router + must also appear in the neighbor's Hello Packet. This event + signals an end to the Waiting state. + + NeighborChange + There has been a change in the set of bidirectional neighbors + associated with the interface. The (Backup) Designated Router + needs to be recalculated. The following neighbor changes lead to + the NeighborChange event. For an explanation of neighbor states, + see Section 10.1. + + o Bidirectional communication has been established to a + neighbor. In other words, the state of the neighbor has + transitioned to 2-Way or higher. + + o There is no longer bidirectional communication with a + neighbor. In other words, the state of the neighbor has + transitioned to Init or lower. + + o One of the bidirectional neighbors is newly declaring + itself as either Designated Router or Backup Designated + Router. This is detected through examination of that + neighbor's Hello Packets. + + o One of the bidirectional neighbors is no longer + declaring itself as Designated Router, or is no longer + declaring itself as Backup Designated Router. This is + again detected through examination of that neighbor's + Hello Packets. + + + +Moy Standards Track [Page 60] + +RFC 2178 OSPF Version 2 July 1997 + + + o The advertised Router Priority for a bidirectional + neighbor has changed. This is again detected through + examination of that neighbor's Hello Packets. + + LoopInd + An indication has been received that the interface is now looped + back to itself. This indication can be received either from + network management or from the lower level protocols. + + UnloopInd + An indication has been received that the interface is no longer + looped back. As with the LoopInd event, this indication can be + received either from network management or from the lower level + protocols. + + InterfaceDown + Lower-level protocols indicate that this interface is no longer + functional. No matter what the current interface state is, the new + interface state will be Down. + +9.3. The Interface state machine + + A detailed description of the interface state changes follows. Each + state change is invoked by an event (Section 9.2). This event may + produce different effects, depending on the current state of the + interface. For this reason, the state machine below is organized by + current interface state and received event. Each entry in the state + machine describes the resulting new interface state and the required + set of additional actions. + + When an interface's state changes, it may be necessary to originate a + new router-LSA. See Section 12.4 for more details. + + Some of the required actions below involve generating events for the + neighbor state machine. For example, when an interface becomes + inoperative, all neighbor connections associated with the interface + must be destroyed. For more information on the neighbor state + machine, see Section 10.3. + + + + + + + + + + + + + +Moy Standards Track [Page 61] + +RFC 2178 OSPF Version 2 July 1997 + + + State(s): Down + + Event: InterfaceUp + + New state: Depends upon action routine + + Action: Start the interval Hello Timer, enabling the + periodic sending of Hello packets out the interface. + If the attached network is a physical point-to-point + network, Point-to-MultiPoint network or virtual + link, the interface state transitions to Point-to- + Point. Else, if the router is not eligible to + become Designated Router the interface state + transitions to DR Other. + + Otherwise, the attached network is a broadcast or + NBMA network and the router is eligible to become + Designated Router. In this case, in an attempt to + discover the attached network's Designated Router + the interface state is set to Waiting and the single + shot Wait Timer is started. Additionally, if the + network is an NBMA network examine the configured + list of neighbors for this interface and generate + the neighbor event Start for each neighbor that is + also eligible to become Designated Router. + + State(s): Waiting + + Event: BackupSeen + + New state: Depends upon action routine. + + Action: Calculate the attached network's Backup Designated + Router and Designated Router, as shown in Section + 9.4. As a result of this calculation, the new state + of the interface will be either DR Other, Backup or + DR. + + + State(s): Waiting + + Event: WaitTimer + + New state: Depends upon action routine. + + + + + + + +Moy Standards Track [Page 62] + +RFC 2178 OSPF Version 2 July 1997 + + + Action: Calculate the attached network's Backup Designated + Router and Designated Router, as shown in Section + 9.4. As a result of this calculation, the new state + of the interface will be either DR Other, Backup or + DR. + + + State(s): DR Other, Backup or DR + + Event: NeighborChange + + New state: Depends upon action routine. + + Action: Recalculate the attached network's Backup Designated + Router and Designated Router, as shown in Section + 9.4. As a result of this calculation, the new state + of the interface will be either DR Other, Backup or + DR. + + + State(s): Any State + + Event: InterfaceDown + + New state: Down + + Action: All interface variables are reset, and interface + timers disabled. Also, all neighbor connections + associated with the interface are destroyed. This + is done by generating the event KillNbr on all + associated neighbors (see Section 10.2). + + + State(s): Any State + + Event: LoopInd + + New state: Loopback + + Action: Since this interface is no longer connected to the + attached network the actions associated with the + above InterfaceDown event are executed. + + + State(s): Loopback + + Event: UnloopInd + + + + +Moy Standards Track [Page 63] + +RFC 2178 OSPF Version 2 July 1997 + + + New state: Down + + Action: No actions are necessary. For example, the + interface variables have already been reset upon + entering the Loopback state. Note that reception of + an InterfaceUp event is necessary before the + interface again becomes fully functional. + +9.4. Electing the Designated Router + + This section describes the algorithm used for calculating a network's + Designated Router and Backup Designated Router. This algorithm is + invoked by the Interface state machine. The initial time a router + runs the election algorithm for a network, the network's Designated + Router and Backup Designated Router are initialized to 0.0.0.0. This + indicates the lack of both a Designated Router and a Backup + Designated Router. + + The Designated Router election algorithm proceeds as follows: Call + the router doing the calculation Router X. The list of neighbors + attached to the network and having established bidirectional + communication with Router X is examined. This list is precisely the + collection of Router X's neighbors (on this network) whose state is + greater than or equal to 2-Way (see Section 10.1). Router X itself + is also considered to be on the list. Discard all routers from the + list that are ineligible to become Designated Router. (Routers + having Router Priority of 0 are ineligible to become Designated + Router.) The following steps are then executed, considering only + those routers that remain on the list: + + (1) Note the current values for the network's Designated Router + and Backup Designated Router. This is used later for + comparison purposes. + + (2) Calculate the new Backup Designated Router for the network + as follows. Only those routers on the list that have not + declared themselves to be Designated Router are eligible to + become Backup Designated Router. If one or more of these + routers have declared themselves Backup Designated Router + (i.e., they are currently listing themselves as Backup + Designated Router, but not as Designated Router, in their + Hello Packets) the one having highest Router Priority is + declared to be Backup Designated Router. In case of a tie, + the one having the highest Router ID is chosen. If no + routers have declared themselves Backup Designated Router, + + + + + + +Moy Standards Track [Page 64] + +RFC 2178 OSPF Version 2 July 1997 + + + choose the router having highest Router Priority, (again + excluding those routers who have declared themselves + Designated Router), and again use the Router ID to break + ties. + + (3) Calculate the new Designated Router for the network as + follows. If one or more of the routers have declared + themselves Designated Router (i.e., they are currently + listing themselves as Designated Router in their Hello + Packets) the one having highest Router Priority is declared + to be Designated Router. In case of a tie, the one having + the highest Router ID is chosen. If no routers have + declared themselves Designated Router, assign the Designated + Router to be the same as the newly elected Backup Designated + Router. + + (4) If Router X is now newly the Designated Router or newly the + Backup Designated Router, or is now no longer the Designated + Router or no longer the Backup Designated Router, repeat + steps 2 and 3, and then proceed to step 5. For example, if + Router X is now the Designated Router, when step 2 is + repeated X will no longer be eligible for Backup Designated + Router election. Among other things, this will ensure that + no router will declare itself both Backup Designated Router + and Designated Router.[5] + + (5) As a result of these calculations, the router itself may now + be Designated Router or Backup Designated Router. See + Sections 7.3 and 7.4 for the additional duties this would + entail. The router's interface state should be set + accordingly. If the router itself is now Designated Router, + the new interface state is DR. If the router itself is now + Backup Designated Router, the new interface state is Backup. + Otherwise, the new interface state is DR Other. + + (6) If the attached network is an NBMA network, and the router + itself has just become either Designated Router or Backup + Designated Router, it must start sending Hello Packets to + those neighbors that are not eligible to become Designated + Router (see Section 9.5.1). This is done by invoking the + neighbor event Start for each neighbor having a Router + Priority of 0. + + (7) If the above calculations have caused the identity of either + the Designated Router or Backup Designated Router to change, + the set of adjacencies associated with this interface will + need to be modified. Some adjacencies may need to be + formed, and others may need to be broken. To accomplish + + + +Moy Standards Track [Page 65] + +RFC 2178 OSPF Version 2 July 1997 + + + this, invoke the event AdjOK? on all neighbors whose state + is at least 2-Way. This will cause their eligibility for + adjacency to be reexamined (see Sections 10.3 and 10.4). + + + The reason behind the election algorithm's complexity is the desire + for an orderly transition from Backup Designated Router to Designated + Router, when the current Designated Router fails. This orderly + transition is ensured through the introduction of hysteresis: no new + Backup Designated Router can be chosen until the old Backup accepts + its new Designated Router responsibilities. + + The above procedure may elect the same router to be both Designated + Router and Backup Designated Router, although that router will never + be the calculating router (Router X) itself. The elected Designated + Router may not be the router having the highest Router Priority, nor + will the Backup Designated Router necessarily have the second highest + Router Priority. If Router X is not itself eligible to become + Designated Router, it is possible that neither a Backup Designated + Router nor a Designated Router will be selected in the above + procedure. Note also that if Router X is the only attached router + that is eligible to become Designated Router, it will select itself + as Designated Router and there will be no Backup Designated Router + for the network. + +9.5. Sending Hello packets + + Hello packets are sent out each functioning router interface. They + are used to discover and maintain neighbor relationships.[6] On + broadcast and NBMA networks, Hello Packets are also used to elect the + Designated Router and Backup Designated Router. + + The format of an Hello packet is detailed in Section A.3.2. The + Hello Packet contains the router's Router Priority (used in choosing + the Designated Router), and the interval between Hello Packets sent + out the interface (HelloInterval). The Hello Packet also indicates + how often a neighbor must be heard from to remain active + (RouterDeadInterval). Both HelloInterval and RouterDeadInterval must + be the same for all routers attached to a common network. The Hello + packet also contains the IP address mask of the attached network + (Network Mask). On unnumbered point-to-point networks and on virtual + links this field should be set to 0.0.0.0. + + The Hello packet's Options field describes the router's optional OSPF + capabilities. One optional capability is defined in this + specification (see Sections 4.5 and A.2). The E-bit of the Options + field should be set if and only if the attached area is capable of + processing AS-external-LSAs (i.e., it is not a stub area). If the E- + + + +Moy Standards Track [Page 66] + +RFC 2178 OSPF Version 2 July 1997 + + + bit is set incorrectly the neighboring routers will refuse to accept + the Hello Packet (see Section 10.5). Unrecognized bits in the Hello + Packet's Options field should be set to zero. + + In order to ensure two-way communication between adjacent routers, + the Hello packet contains the list of all routers on the network from + which Hello Packets have been seen recently. The Hello packet also + contains the router's current choice for Designated Router and Backup + Designated Router. A value of 0.0.0.0 in these fields means that one + has not yet been selected. + + On broadcast networks and physical point-to-point networks, Hello + packets are sent every HelloInterval seconds to the IP multicast + address AllSPFRouters. On virtual links, Hello packets are sent as + unicasts (addressed directly to the other end of the virtual link) + every HelloInterval seconds. On Point-to-MultiPoint networks, + separate Hello packets are sent to each attached neighbor every + HelloInterval seconds. Sending of Hello packets on NBMA networks is + covered in the next section. + +9.5.1. Sending Hello packets on NBMA networks + + Static configuration information may be necessary in order for the + Hello Protocol to function on non-broadcast networks (see Sections + C.5 and C.6). On NBMA networks, every attached router which is + eligible to become Designated Router becomes aware of all of its + neighbors on the network (either through configuration or by some + unspecified mechanism). Each neighbor is labelled with the + neighbor's Designated Router eligibility. + + The interface state must be at least Waiting for any Hello Packets to + be sent out the NBMA interface. Hello Packets are then sent directly + (as unicasts) to some subset of a router's neighbors. Sometimes an + Hello Packet is sent periodically on a timer; at other times it is + sent as a response to a received Hello Packet. A router's hello- + sending behavior varies depending on whether the router itself is + eligible to become Designated Router. + + If the router is eligible to become Designated Router, it must + periodically send Hello Packets to all neighbors that are also + eligible. In addition, if the router is itself the Designated Router + or Backup Designated Router, it must also send periodic Hello Packets + to all other neighbors. This means that any two eligible routers are + always exchanging Hello Packets, which is necessary for the correct + operation of the Designated Router election algorithm. To minimize + the number of Hello Packets sent, the number of eligible routers on + an NBMA network should be kept small. + + + + +Moy Standards Track [Page 67] + +RFC 2178 OSPF Version 2 July 1997 + + + If the router is not eligible to become Designated Router, it must + periodically send Hello Packets to both the Designated Router and the + Backup Designated Router (if they exist). It must also send an Hello + Packet in reply to an Hello Packet received from any eligible + neighbor (other than the current Designated Router and Backup + Designated Router). This is needed to establish an initial + bidirectional relationship with any potential Designated Router. + + When sending Hello packets periodically to any neighbor, the interval + between Hello Packets is determined by the neighbor's state. If the + neighbor is in state Down, Hello Packets are sent every PollInterval + seconds. Otherwise, Hello Packets are sent every HelloInterval + seconds. + +10. The Neighbor Data Structure + + An OSPF router converses with its neighboring routers. Each separate + conversation is described by a "neighbor data structure". Each + conversation is bound to a particular OSPF router interface, and is + identified either by the neighboring router's OSPF Router ID or by + its Neighbor IP address (see below). Thus if the OSPF router and + another router have multiple attached networks in common, multiple + conversations ensue, each described by a unique neighbor data + structure. Each separate conversation is loosely referred to in the + text as being a separate "neighbor". + + The neighbor data structure contains all information pertinent to the + forming or formed adjacency between the two neighbors. (However, + remember that not all neighbors become adjacent.) An adjacency can + be viewed as a highly developed conversation between two routers. + + State + The functional level of the neighbor conversation. This is + described in more detail in Section 10.1. + + Inactivity Timer + A single shot timer whose firing indicates that no Hello Packet + has been seen from this neighbor recently. The length of the + timer is RouterDeadInterval seconds. + + Master/Slave + When the two neighbors are exchanging databases, they form a + master/slave relationship. The master sends the first Database + Description Packet, and is the only part that is allowed to + retransmit. The slave can only respond to the master's Database + Description Packets. The master/slave relationship is negotiated + in state ExStart. + + + + +Moy Standards Track [Page 68] + +RFC 2178 OSPF Version 2 July 1997 + + + DD Sequence Number + The DD Sequence number of the Database Description packet that is + currently being sent to the neighbor. + + Last received Database Description packet + The initialize(I), more (M) and master(MS) bits, Options field, + and DD sequence number contained in the last Database Description + packet received from the neighbor. Used to determine whether the + next Database Description packet received from the neighbor is a + duplicate. + + Neighbor ID + The OSPF Router ID of the neighboring router. The Neighbor ID is + learned when Hello packets are received from the neighbor, or is + configured if this is a virtual adjacency (see Section C.4). + + Neighbor Priority + The Router Priority of the neighboring router. Contained in the + neighbor's Hello packets, this item is used when selecting the + Designated Router for the attached network. + + Neighbor IP address + The IP address of the neighboring router's interface to the + attached network. Used as the Destination IP address when + protocol packets are sent as unicasts along this adjacency. Also + used in router-LSAs as the Link ID for the attached network if the + neighboring router is selected to be Designated Router (see + Section 12.4.1). The Neighbor IP address is learned when Hello + packets are received from the neighbor. For virtual links, the + Neighbor IP address is learned during the routing table build + process (see Section 15). + + Neighbor Options + The optional OSPF capabilities supported by the neighbor. Learned + during the Database Exchange process (see Section 10.6). The + neighbor's optional OSPF capabilities are also listed in its Hello + packets. This enables received Hello Packets to be rejected (i.e., + neighbor relationships will not even start to form) if there is a + mismatch in certain crucial OSPF capabilities (see Section 10.5). + The optional OSPF capabilities are documented in Section 4.5. + + Neighbor's Designated Router + The neighbor's idea of the Designated Router. If this is the + neighbor itself, this is important in the local calculation of the + Designated Router. Defined only on broadcast and NBMA networks. + + + + + + +Moy Standards Track [Page 69] + +RFC 2178 OSPF Version 2 July 1997 + + + Neighbor's Backup Designated Router + The neighbor's idea of the Backup Designated Router. If this is + the neighbor itself, this is important in the local calculation of + the Backup Designated Router. Defined only on broadcast and NBMA + networks. + + The next set of variables are lists of LSAs. These lists describe + subsets of the area link-state database. This memo defines five + distinct types of LSAs, all of which may be present in an area link- + state database: router-LSAs, network-LSAs, and Type 3 and 4 summary- + LSAs (all stored in the area data structure), and AS- external-LSAs + (stored in the global data structure). + + Link state retransmission list + The list of LSAs that have been flooded but not acknowledged on + this adjacency. These will be retransmitted at intervals until + they are acknowledged, or until the adjacency is destroyed. + + Database summary list + The complete list of LSAs that make up the area link-state + database, at the moment the neighbor goes into Database Exchange + state. This list is sent to the neighbor in Database Description + packets. + + Link state request list + The list of LSAs that need to be received from this neighbor in + order to synchronize the two neighbors' link-state databases. + This list is created as Database Description packets are received, + and is then sent to the neighbor in Link State Request packets. + The list is depleted as appropriate Link State Update packets are + received. + +10.1. Neighbor states + + The state of a neighbor (really, the state of a conversation being + held with a neighboring router) is documented in the following + sections. The states are listed in order of progressing + functionality. For example, the inoperative state is listed first, + followed by a list of intermediate states before the final, fully + functional state is achieved. The specification makes use of this + ordering by sometimes making references such as "those + neighbors/adjacencies in state greater than X". Figures 12 and 13 + show the graph of neighbor state changes. The arcs of the graphs are + labelled with the event causing the state change. The neighbor + events are documented in Section 10.2. + + + + + + +Moy Standards Track [Page 70] + +RFC 2178 OSPF Version 2 July 1997 + + + The graph in Figure 12 shows the state changes effected by the Hello + Protocol. The Hello Protocol is responsible for neighbor acquisition + and maintenance, and for ensuring two way communication between + neighbors. + + The graph in Figure 13 shows the forming of an adjacency. Not every + two neighboring routers become adjacent (see Section 10.4). The + adjacency starts to form when the neighbor is in state ExStart. + After the two routers discover their master/slave status, the state + transitions to Exchange. At this point the neighbor starts to be + used in the flooding procedure, and the two neighboring routers begin + synchronizing their databases. When this synchronization is + finished, the neighbor is in state Full and we say that the two + routers are fully adjacent. At this point the adjacency is listed in + LSAs. + + For a more detailed description of neighbor state changes, together + with the additional actions involved in each change, see Section + 10.3. + + Down + This is the initial state of a neighbor conversation. It + indicates that there has been no recent information received from + the neighbor. On NBMA networks, Hello packets may still be sent to + "Down" neighbors, although at a reduced frequency (see Section + 9.5.1). + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 71] + +RFC 2178 OSPF Version 2 July 1997 + + + +----+ + |Down| + +----+ + |\ + | \Start + | \ +-------+ + Hello | +---->|Attempt| + Received | +-------+ + | | + +----+<-+ |HelloReceived + |Init|<---------------+ + +----+<--------+ + | | + |2-Way |1-Way + |Received |Received + | | + +-------+ | +-----+ + |ExStart|<--------+------->|2-Way| + +-------+ +-----+ + + Figure 12: Neighbor state changes (Hello Protocol) + + In addition to the state transitions pictured, + Event KillNbr always forces Down State, + Event Inactivity Timer always forces Down State, + Event LLDown always forces Down State + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 72] + +RFC 2178 OSPF Version 2 July 1997 + + + +-------+ + |ExStart| + +-------+ + | + NegotiationDone| + +->+--------+ + |Exchange| + +--+--------+ + | + Exchange| + Done | + +----+ | +-------+ + |Full|<---------+----->|Loading| + +----+<-+ +-------+ + | LoadingDone | + +------------------+ + + Figure 13: Neighbor state changes (Database Exchange) + + In addition to the state transitions pictured, + Event SeqNumberMismatch forces ExStart state, + Event BadLSReq forces ExStart state, + Event 1-Way forces Init state, + Event KillNbr always forces Down State, + Event InactivityTimer always forces Down State, + Event LLDown always forces Down State, + Event AdjOK? leads to adjacency forming/breaking + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 73] + +RFC 2178 OSPF Version 2 July 1997 + + + Attempt + This state is only valid for neighbors attached to NBMA networks. + It indicates that no recent information has been received from the + neighbor, but that a more concerted effort should be made to + contact the neighbor. This is done by sending the neighbor Hello + packets at intervals of HelloInterval (see Section 9.5.1). + + Init + In this state, an Hello packet has recently been seen from the + neighbor. However, bidirectional communication has not yet been + established with the neighbor (i.e., the router itself did not + appear in the neighbor's Hello packet). All neighbors in this + state (or higher) are listed in the Hello packets sent from the + associated interface. + + 2-Way + In this state, communication between the two routers is + bidirectional. This has been assured by the operation of the + Hello Protocol. This is the most advanced state short of + beginning adjacency establishment. The (Backup) Designated Router + is selected from the set of neighbors in state 2-Way or greater. + + ExStart + This is the first step in creating an adjacency between the two + neighboring routers. The goal of this step is to decide which + router is the master, and to decide upon the initial DD sequence + number. Neighbor conversations in this state or greater are + called adjacencies. + + Exchange + In this state the router is describing its entire link state + database by sending Database Description packets to the neighbor. + Each Database Description Packet has a DD sequence number, and is + explicitly acknowledged. Only one Database Description Packet is + allowed outstanding at any one time. In this state, Link State + Request Packets may also be sent asking for the neighbor's more + recent LSAs. All adjacencies in Exchange state or greater are + used by the flooding procedure. In fact, these adjacencies are + fully capable of transmitting and receiving all types of OSPF + routing protocol packets. + + Loading + In this state, Link State Request packets are sent to the neighbor + asking for the more recent LSAs that have been discovered (but not + yet received) in the Exchange state. + + + + + + +Moy Standards Track [Page 74] + +RFC 2178 OSPF Version 2 July 1997 + + + Full + In this state, the neighboring routers are fully adjacent. These + adjacencies will now appear in router-LSAs and network-LSAs. + +10.2. Events causing neighbor state changes + + State changes can be effected by a number of events. These events + are shown in the labels of the arcs in Figures 12 and 13. The label + definitions are as follows: + + HelloReceived + An Hello packet has been received from the neighbor. + + Start + This is an indication that Hello Packets should now be sent to the + neighbor at intervals of HelloInterval seconds. This event is + generated only for neighbors associated with NBMA networks. + + 2-WayReceived + Bidirectional communication has been realized between the two + neighboring routers. This is indicated by the router seeing + itself in the neighbor's Hello packet. + + NegotiationDone + The Master/Slave relationship has been negotiated, and DD sequence + numbers have been exchanged. This signals the start of the + sending/receiving of Database Description packets. For more + information on the generation of this event, consult Section 10.8. + + ExchangeDone + Both routers have successfully transmitted a full sequence of + Database Description packets. Each router now knows what parts of + its link state database are out of date. For more information on + the generation of this event, consult Section 10.8. + + BadLSReq + A Link State Request has been received for an LSA not contained in + the database. This indicates an error in the Database Exchange + process. + + Loading Done + Link State Updates have been received for all out-of-date portions + of the database. This is indicated by the Link state request list + becoming empty after the Database Exchange process has completed. + + + + + + + +Moy Standards Track [Page 75] + +RFC 2178 OSPF Version 2 July 1997 + + + AdjOK? + A decision must be made as to whether an adjacency should be + established/maintained with the neighbor. This event will start + some adjacencies forming, and destroy others. + + The following events cause well developed neighbors to revert to + lesser states. Unlike the above events, these events may occur when + the neighbor conversation is in any of a number of states. + + SeqNumberMismatch + A Database Description packet has been received that either a) has + an unexpected DD sequence number, b) unexpectedly has the Init bit + set or c) has an Options field differing from the last Options + field received in a Database Description packet. Any of these + conditions indicate that some error has occurred during adjacency + establishment. + + 1-Way + An Hello packet has been received from the neighbor, in which the + router is not mentioned. This indicates that communication with + the neighbor is not bidirectional. + + KillNbr + This is an indication that all communication with the neighbor is + now impossible, forcing the neighbor to revert to Down state. + + InactivityTimer + The inactivity Timer has fired. This means that no Hello packets + have been seen recently from the neighbor. The neighbor reverts to + Down state. + + LLDown + This is an indication from the lower level protocols that the + neighbor is now unreachable. For example, on an X.25 network this + could be indicated by an X.25 clear indication with appropriate + cause and diagnostic fields. This event forces the neighbor into + Down state. + +10.3. The Neighbor state machine + + A detailed description of the neighbor state changes follows. Each + state change is invoked by an event (Section 10.2). This event may + produce different effects, depending on the current state of the + neighbor. For this reason, the state machine below is organized by + current neighbor state and received event. Each entry in the state + machine describes the resulting new neighbor state and the required + set of additional actions. + + + + +Moy Standards Track [Page 76] + +RFC 2178 OSPF Version 2 July 1997 + + + When a neighbor's state changes, it may be necessary to rerun the + Designated Router election algorithm. This is determined by whether + the interface NeighborChange event is generated (see Section 9.2). + Also, if the Interface is in DR state (the router is itself + Designated Router), changes in neighbor state may cause a new + network-LSA to be originated (see Section 12.4). + + When the neighbor state machine needs to invoke the interface state + machine, it should be done as a scheduled task (see Section 4.4). + This simplifies things, by ensuring that neither state machine will + be executed recursively. + + + State(s): Down + + Event: Start + + New state: Attempt + + Action: Send an Hello Packet to the neighbor (this neighbor + is always associated with an NBMA network) and start + the Inactivity Timer for the neighbor. The timer's + later firing would indicate that communication with + the neighbor was not attained. + + + State(s): Attempt + + Event: HelloReceived + + New state: Init + + Action: Restart the Inactivity Timer for the neighbor, since + the neighbor has now been heard from. + + + State(s): Down + + Event: HelloReceived + + New state: Init + + Action: Start the Inactivity Timer for the neighbor. The + timer's later firing would indicate that the neighbor + is dead. + + + + + + +Moy Standards Track [Page 77] + +RFC 2178 OSPF Version 2 July 1997 + + + State(s): Init or greater + + Event: HelloReceived + + New state: No state change. + + Action: Restart the Inactivity Timer for the neighbor, since + the neighbor has again been heard from. + + + State(s): Init + + Event: 2-WayReceived + + New state: Depends upon action routine. + + Action: Determine whether an adjacency should be established + with the neighbor (see Section 10.4). If not, the + new neighbor state is 2-Way. + + Otherwise (an adjacency should be established) the + neighbor state transitions to ExStart. Upon + entering this state, the router increments the DD + sequence number in the neighbor data structure. If + this is the first time that an adjacency has been + attempted, the DD sequence number should be assigned + some unique value (like the time of day clock). It + then declares itself master (sets the master/slave + bit to master), and starts sending Database + Description Packets, with the initialize (I), more + (M) and master (MS) bits set. This Database + Description Packet should be otherwise empty. This + Database Description Packet should be retransmitted + at intervals of RxmtInterval until the next state is + entered (see Section 10.8). + + + State(s): ExStart + + Event: NegotiationDone + + New state: Exchange + + Action: The router must list the contents of its entire area + link state database in the neighbor Database summary + list. The area link state database consists of the + router-LSAs, network-LSAs and summary-LSAs contained + in the area structure, along with the AS-external- + + + +Moy Standards Track [Page 78] + +RFC 2178 OSPF Version 2 July 1997 + + + LSAs contained in the global structure. AS- + external-LSAs are omitted from a virtual neighbor's + Database summary list. AS-external-LSAs are omitted + from the Database summary list if the area has been + configured as a stub (see Section 3.6). LSAs whose + age is equal to MaxAge are instead added to the + neighbor's Link state retransmission list. A + summary of the Database summary list will be sent to + the neighbor in Database Description packets. Each + Database Description Packet has a DD sequence + number, and is explicitly acknowledged. Only one + Database Description Packet is allowed outstanding + at any one time. For more detail on the sending and + receiving of Database Description packets, see + Sections 10.8 and 10.6. + + + State(s): Exchange + + Event: ExchangeDone + + New state: Depends upon action routine. + + Action: If the neighbor Link state request list is empty, + the new neighbor state is Full. No other action is + required. This is an adjacency's final state. + + Otherwise, the new neighbor state is Loading. Start + (or continue) sending Link State Request packets to + the neighbor (see Section 10.9). These are requests + for the neighbor's more recent LSAs (which were + discovered but not yet received in the Exchange + state). These LSAs are listed in the Link state + request list associated with the neighbor. + + + State(s): Loading + + Event: Loading Done + + New state: Full + + Action: No action required. This is an adjacency's final + state. + + + + + + + +Moy Standards Track [Page 79] + +RFC 2178 OSPF Version 2 July 1997 + + + State(s): 2-Way + + Event: AdjOK? + + New state: Depends upon action routine. + + Action: Determine whether an adjacency should be formed with + the neighboring router (see Section 10.4). If not, + the neighbor state remains at 2-Way. Otherwise, + transition the neighbor state to ExStart and perform + the actions associated with the above state machine + entry for state Init and event 2-WayReceived. + + + State(s): ExStart or greater + + Event: AdjOK? + + New state: Depends upon action routine. + + Action: Determine whether the neighboring router should + still be adjacent. If yes, there is no state change + and no further action is necessary. + + Otherwise, the (possibly partially formed) adjacency + must be destroyed. The neighbor state transitions + to 2-Way. The Link state retransmission list, + Database summary list and Link state request list + are cleared of LSAs. + + + State(s): Exchange or greater + + Event: SeqNumberMismatch + + New state: ExStart + + Action: The (possibly partially formed) adjacency is torn + down, and then an attempt is made at + reestablishment. The neighbor state first + transitions to ExStart. The Link state + retransmission list, Database summary list and Link + state request list are cleared of LSAs. Then the + router increments the DD sequence number in the + neighbor data structure, declares itself master + (sets the master/slave bit to master), and starts + sending Database Description Packets, with the + initialize (I), more (M) and master (MS) bits set. + + + +Moy Standards Track [Page 80] + +RFC 2178 OSPF Version 2 July 1997 + + + This Database Description Packet should be otherwise + empty (see Section 10.8). + + + State(s): Exchange or greater + + Event: BadLSReq + + New state: ExStart + + Action: The action for event BadLSReq is exactly the same as + for the neighbor event SeqNumberMismatch. The + (possibly partially formed) adjacency is torn down, + and then an attempt is made at reestablishment. For + more information, see the neighbor state machine + entry that is invoked when event SeqNumberMismatch + is generated in state Exchange or greater. + + + State(s): Any state + + Event: KillNbr + + New state: Down + + Action: The Link state retransmission list, Database summary + list and Link state request list are cleared of + LSAs. Also, the Inactivity Timer is disabled. + + + State(s): Any state + + Event: LLDown + + New state: Down + + Action: The Link state retransmission list, Database summary + list and Link state request list are cleared of + LSAs. Also, the Inactivity Timer is disabled. + + + + + + + + + + + + +Moy Standards Track [Page 81] + +RFC 2178 OSPF Version 2 July 1997 + + + State(s): Any state + + Event: InactivityTimer + + New state: Down + + Action: The Link state retransmission list, Database summary + list and Link state request list are cleared of + LSAs. + + + State(s): 2-Way or greater + + Event: 1-WayReceived + + New state: Init + + Action: The Link state retransmission list, Database summary + list and Link state request list are cleared of + LSAs. + + + State(s): 2-Way or greater + + Event: 2-WayReceived + + New state: No state change. + + Action: No action required. + + + State(s): Init + + Event: 1-WayReceived + + New state: No state change. + + Action: No action required. + + +10.4. Whether to become adjacent + + Adjacencies are established with some subset of the router's + neighbors. Routers connected by point-to-point networks, Point-to- + MultiPoint networks and virtual links always become adjacent. On + broadcast and NBMA networks, all routers become adjacent to both the + Designated Router and the Backup Designated Router. + + + + +Moy Standards Track [Page 82] + +RFC 2178 OSPF Version 2 July 1997 + + + The adjacency-forming decision occurs in two places in the neighbor + state machine. First, when bidirectional communication is initially + established with the neighbor, and secondly, when the identity of the + attached network's (Backup) Designated Router changes. If the + decision is made to not attempt an adjacency, the state of the + neighbor communication stops at 2-Way. + + An adjacency should be established with a bidirectional neighbor when + at least one of the following conditions holds: + + o The underlying network type is point-to-point + + o The underlying network type is Point-to-MultiPoint + + o The underlying network type is virtual link + + o The router itself is the Designated Router + + o The router itself is the Backup Designated Router + + o The neighboring router is the Designated Router + + o The neighboring router is the Backup Designated Router + +10.5. Receiving Hello Packets + + This section explains the detailed processing of a received Hello + Packet. (See Section A.3.2 for the format of Hello packets.) The + generic input processing of OSPF packets will have checked the + validity of the IP header and the OSPF packet header. Next, the + values of the Network Mask, HelloInterval, and RouterDeadInterval + fields in the received Hello packet must be checked against the + values configured for the receiving interface. Any mismatch causes + processing to stop and the packet to be dropped. In other words, the + above fields are really describing the attached network's + configuration. However, there is one exception to the above rule: on + point-to-point networks and on virtual links, the Network Mask in the + received Hello Packet should be ignored. + + The receiving interface attaches to a single OSPF area (this could be + the backbone). The setting of the E-bit found in the Hello Packet's + Options field must match this area's ExternalRoutingCapability. If + AS-external-LSAs are not flooded into/throughout the area (i.e, the + area is a "stub") the E-bit must be clear in received Hello Packets, + otherwise the E-bit must be set. A mismatch causes processing to + stop and the packet to be dropped. The setting of the rest of the + bits in the Hello Packet's Options field should be ignored. + + + + +Moy Standards Track [Page 83] + +RFC 2178 OSPF Version 2 July 1997 + + + At this point, an attempt is made to match the source of the Hello + Packet to one of the receiving interface's neighbors. If the + receiving interface connects to a broadcast, Point-to-MultiPoint or + NBMA network the source is identified by the IP source address found + in the Hello's IP header. If the receiving interface connects to a + point-to-point link or a virtual link, the source is identified by + the Router ID found in the Hello's OSPF packet header. The + interface's current list of neighbors is contained in the interface's + data structure. If a matching neighbor structure cannot be found, + (i.e., this is the first time the neighbor has been detected), one is + created. The initial state of a newly created neighbor is set to + Down. + + When receiving an Hello Packet from a neighbor on a broadcast, + Point-to-MultiPoint or NBMA network, set the neighbor structure's + Neighbor ID equal to the Router ID found in the packet's OSPF header. + When receiving an Hello on a point-to-point network (but not on a + virtual link) set the neighbor structure's Neighbor IP address to the + packet's IP source address. + + Now the rest of the Hello Packet is examined, generating events to be + given to the neighbor and interface state machines. These state + machines are specified either to be executed or scheduled (see + Section 4.4). For example, by specifying below that the neighbor + state machine be executed in line, several neighbor state transitions + may be effected by a single received Hello: + + o Each Hello Packet causes the neighbor state machine to be + executed with the event HelloReceived. + + o Then the list of neighbors contained in the Hello Packet is + examined. If the router itself appears in this list, the + neighbor state machine should be executed with the event 2- + WayReceived. Otherwise, the neighbor state machine should + be executed with the event 1-WayReceived, and the processing + of the packet stops. + + o Next, the Hello Packet's Router Priority field is examined. + If this field is different than the one previously received + from the neighbor, the receiving interface's state machine + is scheduled with the event NeighborChange. In any case, + the Router Priority field in the neighbor data structure + should be updated accordingly. + + o Next the Designated Router field in the Hello Packet is + examined. If the neighbor is both declaring itself to be + Designated Router (Designated Router field = Neighbor IP + address) and the Backup Designated Router field in the + + + +Moy Standards Track [Page 84] + +RFC 2178 OSPF Version 2 July 1997 + + + packet is equal to 0.0.0.0 and the receiving interface is in + state Waiting, the receiving interface's state machine is + scheduled with the event BackupSeen. Otherwise, if the + neighbor is declaring itself to be Designated Router and it + had not previously, or the neighbor is not declaring itself + Designated Router where it had previously, the receiving + interface's state machine is scheduled with the event + NeighborChange. In any case, the Neighbors' Designated + Router item in the neighbor structure is updated + accordingly. + + o Finally, the Backup Designated Router field in the Hello + Packet is examined. If the neighbor is declaring itself to + be Backup Designated Router (Backup Designated Router field + = Neighbor IP address) and the receiving interface is in + state Waiting, the receiving interface's state machine is + scheduled with the event BackupSeen. Otherwise, if the + neighbor is declaring itself to be Backup Designated Router + and it had not previously, or the neighbor is not declaring + itself Backup Designated Router where it had previously, the + receiving interface's state machine is scheduled with the + event NeighborChange. In any case, the Neighbor's Backup + Designated Router item in the neighbor structure is updated + accordingly. + + On NBMA networks, receipt of an Hello Packet may also cause an Hello + Packet to be sent back to the neighbor in response. See Section 9.5.1 + for more details. + +10.6. Receiving Database Description Packets + + This section explains the detailed processing of a received Database + Description Packet. The incoming Database Description Packet has + already been associated with a neighbor and receiving interface by + the generic input packet processing (Section 8.2). Whether the + Database Description packet should be accepted, and if so, how it + should be further processed depends upon the neighbor state. + + If a Database Description packet is accepted, the following packet + fields should be saved in the corresponding neighbor data structure + under "last received Database Description packet": the packet's + initialize(I), more (M) and master(MS) bits, Options field, and DD + sequence number. If these fields are set identically in two + consecutive Database Description packets received from the neighbor, + the second Database Description packet is considered to be a + "duplicate" in the processing described below. + + + + + +Moy Standards Track [Page 85] + +RFC 2178 OSPF Version 2 July 1997 + + + If the Interface MTU field in the Database Description packet + indicates an IP datagram size that is larger than the router can + accept on the receiving interface without fragmentation, the Database + Description packet is rejected. Otherwise, if the neighbor state is: + + Down + The packet should be rejected. + + Attempt + The packet should be rejected. + + Init + The neighbor state machine should be executed with the event 2- + WayReceived. This causes an immediate state change to either + state 2-Way or state ExStart. If the new state is ExStart, the + processing of the current packet should then continue in this new + state by falling through to case ExStart below. + + 2-Way + The packet should be ignored. Database Description Packets are + used only for the purpose of bringing up adjacencies.[7] + + ExStart + If the received packet matches one of the following cases, then + the neighbor state machine should be executed with the event + NegotiationDone (causing the state to transition to Exchange), the + packet's Options field should be recorded in the neighbor + structure's Neighbor Options field and the packet should be + accepted as next in sequence and processed further (see below). + Otherwise, the packet should be ignored. + + o The initialize(I), more (M) and master(MS) bits are set, + the contents of the packet are empty, and the neighbor's + Router ID is larger than the router's own. In this case + the router is now Slave. Set the master/slave bit to + slave, and set the neighbor data structure's DD sequence + number to that specified by the master. + + o The initialize(I) and master(MS) bits are off, the + packet's DD sequence number equals the neighbor data + structure's DD sequence number (indicating + acknowledgment) and the neighbor's Router ID is smaller + than the router's own. In this case the router is + Master. + + + + + + + +Moy Standards Track [Page 86] + +RFC 2178 OSPF Version 2 July 1997 + + + Exchange + Duplicate Database Description packets are discarded by the + master, and cause the slave to retransmit the last Database + Description packet that it had sent. Otherwise (the packet is not + a duplicate): + + o If the state of the MS-bit is inconsistent with the + master/slave state of the connection, generate the + neighbor event SeqNumberMismatch and stop processing the + packet. + + o If the initialize(I) bit is set, generate the neighbor + event SeqNumberMismatch and stop processing the packet. + + o If the packet's Options field indicates a different set + of optional OSPF capabilities than were previously + received from the neighbor (recorded in the Neighbor + Options field of the neighbor structure), generate the + neighbor event SeqNumberMismatch and stop processing the + packet. + + o Database Description packets must be processed in + sequence, as indicated by the packets' DD sequence + numbers. If the router is master, the next packet + received should have DD sequence number equal to the DD + sequence number in the neighbor data structure. If the + router is slave, the next packet received should have DD + sequence number equal to one more than the DD sequence + number stored in the neighbor data structure. In either + case, if the packet is the next in sequence it should be + accepted and its contents processed as specified below. + + o Else, generate the neighbor event SeqNumberMismatch and + stop processing the packet. + + Loading or Full + In this state, the router has sent and received an entire sequence + of Database Description Packets. The only packets received should + be duplicates (see above). In particular, the packet's Options + field should match the set of optional OSPF capabilities + previously indicated by the neighbor (stored in the neighbor + structure's Neighbor Options field). Any other packets received, + including the reception of a packet with the Initialize(I) bit + set, should generate the neighbor event SeqNumberMismatch.[8] + Duplicates should be discarded by the master. The slave must + respond to duplicates by repeating the last Database Description + packet that it had sent. + + + + +Moy Standards Track [Page 87] + +RFC 2178 OSPF Version 2 July 1997 + + + When the router accepts a received Database Description Packet as the + next in sequence the packet contents are processed as follows. For + each LSA listed, the LSA's LS type is checked for validity. If the + LS type is unknown (e.g., not one of the LS types 1-5 defined by this + specification), or if this is an AS-external-LSA (LS type = 5) and + the neighbor is associated with a stub area, generate the neighbor + event SeqNumberMismatch and stop processing the packet. Otherwise, + the router looks up the LSA in its database to see whether it also + has an instance of the LSA. If it does not, or if the database copy + is less recent (see Section 13.1), the LSA is put on the Link state + request list so that it can be requested (immediately or at some + later time) in Link State Request Packets. + + When the router accepts a received Database Description Packet as the + next in sequence, it also performs the following actions, depending + on whether it is master or slave: + + Master + Increments the DD sequence number in the neighbor data structure. + If the router has already sent its entire sequence of Database + Description Packets, and the just accepted packet has the more bit + (M) set to 0, the neighbor event ExchangeDone is generated. + Otherwise, it should send a new Database Description to the slave. + + Slave + Sets the DD sequence number in the neighbor data structure to the + DD sequence number appearing in the received packet. The slave + must send a Database Description Packet in reply. If the received + packet has the more bit (M) set to 0, and the packet to be sent by + the slave will also have the M-bit set to 0, the neighbor event + ExchangeDone is generated. Note that the slave always generates + this event before the master. + +10.7. Receiving Link State Request Packets + + This section explains the detailed processing of received Link State + Request packets. Received Link State Request Packets specify a list + of LSAs that the neighbor wishes to receive. Link State Request + Packets should be accepted when the neighbor is in states Exchange, + Loading, or Full. In all other states Link State Request Packets + should be ignored. + + + + + + + + + + +Moy Standards Track [Page 88] + +RFC 2178 OSPF Version 2 July 1997 + + + Each LSA specified in the Link State Request packet should be located + in the router's database, and copied into Link State Update packets + for transmission to the neighbor. These LSAs should NOT be placed on + the Link state retransmission list for the neighbor. If an LSA + cannot be found in the database, something has gone wrong with the + Database Exchange process, and neighbor event BadLSReq should be + generated. + +10.8. Sending Database Description Packets + + This section describes how Database Description Packets are sent to a + neighbor. The Database Description packet's Interface MTU field is + set to the size of the largest IP datagram that can be sent out the + sending interface, without fragmentation. Common MTUs in use in the + Internet can be found in Table 7-1 of [Ref22]. Interface MTU should + be set to 0 in Database Description packets sent over virtual links. + + The router's optional OSPF capabilities (see Section 4.5) are + transmitted to the neighbor in the Options field of the Database + Description packet. The router should maintain the same set of + optional capabilities throughout the Database Exchange and flooding + procedures. If for some reason the router's optional capabilities + change, the Database Exchange procedure should be restarted by + reverting to neighbor state ExStart. One optional capability is + defined in this specification (see Sections 4.5 and A.2). The E-bit + should be set if and only if the attached network belongs to a non- + stub area. Unrecognized bits in the Options field should be set to + zero. The sending of Database Description packets depends on the + neighbor's state. In state ExStart the router sends empty Database + Description packets, with the initialize (I), more (M) and master + (MS) bits set. These packets are retransmitted every RxmtInterval + seconds. + + In state Exchange the Database Description Packets actually contain + summaries of the link state information contained in the router's + database. Each LSA in the area's link-state database (at the time + the neighbor transitions into Exchange state) is listed in the + neighbor Database summary list. Each new Database Description Packet + copies its DD sequence number from the neighbor data structure and + then describes the current top of the Database summary list. Items + are removed from the Database summary list when the previous packet + is acknowledged. + + In state Exchange, the determination of when to send a Database + Description packet depends on whether the router is master or slave: + + + + + + +Moy Standards Track [Page 89] + +RFC 2178 OSPF Version 2 July 1997 + + + Master + Database Description packets are sent when either a) the slave + acknowledges the previous Database Description packet by echoing + the DD sequence number or b) RxmtInterval seconds elapse without + an acknowledgment, in which case the previous Database Description + packet is retransmitted. + + Slave + Database Description packets are sent only in response to Database + Description packets received from the master. If the Database + Description packet received from the master is new, a new Database + Description packet is sent, otherwise the previous Database + Description packet is resent. + + In states Loading and Full the slave must resend its last Database + Description packet in response to duplicate Database Description + packets received from the master. For this reason the slave must + wait RouterDeadInterval seconds before freeing the last Database + Description packet. Reception of a Database Description packet from + the master after this interval will generate a SeqNumberMismatch + neighbor event. + +10.9. Sending Link State Request Packets + + In neighbor states Exchange or Loading, the Link state request list + contains a list of those LSAs that need to be obtained from the + neighbor. To request these LSAs, a router sends the neighbor the + beginning of the Link state request list, packaged in a Link State + Request packet. + + When the neighbor responds to these requests with the proper Link + State Update packet(s), the Link state request list is truncated and + a new Link State Request packet is sent. This process continues + until the Link state request list becomes empty. Unsatisfied Link + State Request packets are retransmitted at intervals of RxmtInterval. + There should be at most one Link State Request packet outstanding at + any one time. + + When the Link state request list becomes empty, and the neighbor + state is Loading (i.e., a complete sequence of Database Description + packets has been sent to and received from the neighbor), the Loading + Done neighbor event is generated. + + + + + + + + + +Moy Standards Track [Page 90] + +RFC 2178 OSPF Version 2 July 1997 + + +10.10. An Example + + Figure 14 shows an example of an adjacency forming. Routers RT1 and + RT2 are both connected to a broadcast network. It is assumed that + RT2 is the Designated Router for the network, and that RT2 has a + higher Router ID than Router RT1. + + The neighbor state changes realized by each router are listed on the + sides of the figure. + + At the beginning of Figure 14, Router RT1's interface to the network + becomes operational. It begins sending Hello Packets, although it + doesn't know the identity of the Designated Router or of any other + neighboring routers. Router RT2 hears this hello (moving the + neighbor to Init state), and in its next Hello Packet indicates that + it is itself the Designated Router and that it has heard Hello + Packets from RT1. This in turn causes RT1 to go to state ExStart, as + it starts to bring up the adjacency. + + RT1 begins by asserting itself as the master. When it sees that RT2 + is indeed the master (because of RT2's higher Router ID), RT1 + transitions to slave state and adopts its neighbor's DD sequence + number. Database Description packets are then exchanged, with polls + coming from the master (RT2) and responses from the slave (RT1). + This sequence of Database Description Packets ends when both the poll + and associated response has the M-bit off. + + In this example, it is assumed that RT2 has a completely up to date + database. In that case, RT2 goes immediately into Full state. RT1 + will go into Full state after updating the necessary parts of its + database. This is done by sending Link State Request Packets, and + receiving Link State Update Packets in response. Note that, while + RT1 has waited until a complete set of Database Description Packets + has been received (from RT2) before sending any Link State Request + Packets, this need not be the case. RT1 could have interleaved the + sending of Link State Request Packets with the reception of Database + Description Packets. + + + + + + + + + + + + + + +Moy Standards Track [Page 91] + +RFC 2178 OSPF Version 2 July 1997 + + + +---+ +---+ + |RT1| |RT2| + +---+ +---+ + + Down Down + Hello(DR=0,seen=0) + ------------------------------> + Hello (DR=RT2,seen=RT1,...) Init + <------------------------------ + ExStart D-D (Seq=x,I,M,Master) + ------------------------------> + D-D (Seq=y,I,M,Master) ExStart + <------------------------------ + Exchange D-D (Seq=y,M,Slave) + ------------------------------> + D-D (Seq=y+1,M,Master) Exchange + <------------------------------ + D-D (Seq=y+1,M,Slave) + ------------------------------> + ... + ... + ... + D-D (Seq=y+n, Master) + <------------------------------ + D-D (Seq=y+n, Slave) + Loading ------------------------------> + LS Request Full + ------------------------------> + LS Update + <------------------------------ + LS Request + ------------------------------> + LS Update + <------------------------------ + Full + + + Figure 14: An adjacency bring-up example + + + + + + + + + + + + + +Moy Standards Track [Page 92] + +RFC 2178 OSPF Version 2 July 1997 + + +11. The Routing Table Structure + + The routing table data structure contains all the information + necessary to forward an IP data packet toward its destination. Each + routing table entry describes the collection of best paths to a + particular destination. When forwarding an IP data packet, the + routing table entry providing the best match for the packet's IP + destination is located. The matching routing table entry then + provides the next hop towards the packet's destination. OSPF also + provides for the existence of a default route (Destination ID = + DefaultDestination, Address Mask = 0x00000000). When the default + route exists, it matches all IP destinations (although any other + matching entry is a better match). Finding the routing table entry + that best matches an IP destination is further described in Section + 11.1. + + There is a single routing table in each router. Two sample routing + tables are described in Sections 11.2 and 11.3. The building of the + routing table is discussed in Section 16. + + The rest of this section defines the fields found in a routing table + entry. The first set of fields describes the routing table entry's + destination. + + Destination Type + Destination type is either "network" or "router". Only network entries + are actually used when forwarding IP data traffic. Router routing + table entries are used solely as intermediate steps in the routing + table build process. + + A network is a range of IP addresses, to which IP data traffic may be + forwarded. This includes IP networks (class A, B, or C), IP subnets, + IP supernets and single IP hosts. The default route also falls into + this category. + + Router entries are kept for area border routers and AS boundary + routers. Routing table entries for area border routers are used when + calculating the inter-area routes (see Section 16.2), and when + maintaining configured virtual links (see Section 15). Routing table + entries for AS boundary routers are used when calculating the AS + external routes (see Section 16.4). + + Destination ID + The destination's identifier or name. This depends on the + Destination Type. For networks, the identifier is their associated IP + address. For routers, the identifier is the OSPF Router ID.[9] + + + + + +Moy Standards Track [Page 93] + +RFC 2178 OSPF Version 2 July 1997 + + + Address Mask + Only defined for networks. The network's IP address together with its + address mask defines a range of IP addresses. For IP subnets, the + address mask is referred to as the subnet mask. For host routes, the + mask is "all ones" (0xffffffff). + + Optional Capabilities + When the destination is a router this field indicates the optional + OSPF capabilities supported by the destination router. The only + optional capability defined by this specification is the ability to + process AS-external-LSAs. For a further discussion of OSPF's optional + capabilities, see Section 4.5. + + The set of paths to use for a destination may vary based on the OSPF + area to which the paths belong. This means that there may be + multiple routing table entries for the same destination, depending on + the values of the next field. + + Area + This field indicates the area whose link state information has led + to the routing table entry's collection of paths. This is called + the entry's associated area. For sets of AS external paths, this + field is not defined. For destinations of type "router", there + may be separate sets of paths (and therefore separate routing + table entries) associated with each of several areas. For example, + this will happen when two area border routers share multiple areas + in common. For destinations of type "network", only the set of + paths associated with the best area (the one providing the + preferred route) is kept. + + The rest of the routing table entry describes the set of paths to the + destination. The following fields pertain to the set of paths as a + whole. In other words, each one of the paths contained in a routing + table entry is of the same path-type and cost (see below). + + Path-type + There are four possible types of paths used to route traffic to + the destination, listed here in order of preference: intra-area, + inter-area, type 1 external or type 2 external. Intra-area paths + indicate destinations belonging to one of the router's attached + areas. Inter-area paths are paths to destinations in other OSPF + areas. These are discovered through the examination of received + summary-LSAs. AS external paths are paths to destinations + external to the AS. These are detected through the examination of + received AS-external-LSAs. + + + + + + +Moy Standards Track [Page 94] + +RFC 2178 OSPF Version 2 July 1997 + + + Cost + The link state cost of the path to the destination. For all paths + except type 2 external paths this describes the entire path's + cost. For Type 2 external paths, this field describes the cost of + the portion of the path internal to the AS. This cost is + calculated as the sum of the costs of the path's constituent + links. + + Type 2 cost + Only valid for type 2 external paths. For these paths, this field + indicates the cost of the path's external portion. This cost has + been advertised by an AS boundary router, and is the most + significant part of the total path cost. For example, a type 2 + external path with type 2 cost of 5 is always preferred over a + path with type 2 cost of 10, regardless of the cost of the two + paths' internal components. + + Link State Origin + Valid only for intra-area paths, this field indicates the LSA + (router-LSA or network-LSA) that directly references the + destination. For example, if the destination is a transit + network, this is the transit network's network-LSA. If the + destination is a stub network, this is the router-LSA for the + attached router. The LSA is discovered during the shortest-path + tree calculation (see Section 16.1). Multiple LSAs may reference + the destination, however a tie-breaking scheme always reduces the + choice to a single LSA. The Link State Origin field is not used by + the OSPF protocol, but it is used by the routing table calculation + in OSPF's Multicast routing extensions (MOSPF). + + When multiple paths of equal path-type and cost exist to a + destination (called elsewhere "equal-cost" paths), they are stored in + a single routing table entry. Each one of the "equal-cost" paths is + distinguished by the following fields: + + Next hop + The outgoing router interface to use when forwarding traffic to + the destination. On broadcast, Point-to-MultiPoint and NBMA + networks, the next hop also includes the IP address of the next + router (if any) in the path towards the destination. + + Advertising router + Valid only for inter-area and AS external paths. This field + indicates the Router ID of the router advertising the summary-LSA + or AS-external-LSA that led to this path. + + + + + + +Moy Standards Track [Page 95] + +RFC 2178 OSPF Version 2 July 1997 + + +11.1. Routing table lookup + + When an IP data packet is received, an OSPF router finds the routing + table entry that best matches the packet's destination. This routing + table entry then provides the outgoing interface and next hop router + to use in forwarding the packet. This section describes the process + of finding the best matching routing table entry. The process + consists of a number of steps, wherein the collection of routing + table entries is progressively pruned. In the end, the single + routing table entry remaining is called the "best match". + + Before the lookup begins, "discard" routing table entries should be + inserted into the routing table for each of the router's active area + address ranges (see Section 3.5). (An area range is considered + "active" if the range contains one or more networks reachable by + intra-area paths.) The destination of a "discard" entry is the set of + addresses described by its associated active area address range, and + the path type of each "discard" entry is set to "inter-area".[10] + + Note that the steps described below may fail to produce a best match + routing table entry (i.e., all existing routing table entries are + pruned for some reason or another), or the best match routing table + entry may be one of the above "discard" routing table entries. In + these cases, the packet's IP destination is considered unreachable. + Instead of being forwarded, the packet should be discarded and an + ICMP destination unreachable message should be returned to the + packet's source. + + (1) Select the complete set of "matching" routing table entries + from the routing table. Each routing table entry describes + a (set of) path(s) to a range of IP addresses. If the data + packet's IP destination falls into an entry's range of IP + addresses, the routing table entry is called a match. (It is + quite likely that multiple entries will match the data + packet. For example, a default route will match all + packets.) + + (2) Reduce the set of matching entries to those having the most + preferential path-type (see Section 11). OSPF has a four + level hierarchy of paths. Intra-area paths are the most + preferred, followed in order by inter-area, type 1 external + and type 2 external paths. + + (3) Select the remaining routing table entry that provides the + most specific (longest) match. Another way of saying this is + to choose the remaining entry that specifies the narrowest + range of IP addresses.[11] For example, the entry for the + address/mask pair of (128.185.1.0, 0xffffff00) is more + + + +Moy Standards Track [Page 96] + +RFC 2178 OSPF Version 2 July 1997 + + + specific than an entry for the pair (128.185.0.0, + 0xffff0000). The default route is the least specific match, + since it matches all destinations. + +11.2. Sample routing table, without areas + + Consider the Autonomous System pictured in Figure 2. No OSPF areas + have been configured. A single metric is shown per outbound + interface. The calculation of Router RT6's routing table proceeds as + described in Section 2.2. The resulting routing table is shown in + Table 12. Destination types are abbreviated: Network as "N", Router + as "R". + + There are no instances of multiple equal-cost shortest paths in this + example. Also, since there are no areas, there are no inter-area + paths. + + Routers RT5 and RT7 are AS boundary routers. Intra-area routes have + been calculated to Routers RT5 and RT7. This allows external routes + to be calculated to the destinations advertised by RT5 and RT7 (i.e., + Networks N12, N13, N14 and N15). It is assumed all AS-external-LSAs + originated by RT5 and RT7 are advertising type 1 external metrics. + This results in type 1 external paths being calculated to + destinations N12-N15. + +11.3. Sample routing table, with areas + + Consider the previous example, this time split into OSPF areas. An + OSPF area configuration is pictured in Figure 6. Router RT4's + routing table will be described for this area configuration. Router + RT4 has a connection to Area 1 and a backbone connection. This + causes Router RT4 to view the AS as the concatenation of the two + graphs shown in Figures 7 and 8. The resulting routing table is + displayed in Table 13. + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 97] + +RFC 2178 OSPF Version 2 July 1997 + + + Type Dest Area Path Type Cost Next Adv. + Hop(s) Router(s) + ____________________________________________________________ + N N1 0 intra-area 10 RT3 * + N N2 0 intra-area 10 RT3 * + N N3 0 intra-area 7 RT3 * + N N4 0 intra-area 8 RT3 * + N Ib 0 intra-area 7 * * + N Ia 0 intra-area 12 RT10 * + N N6 0 intra-area 8 RT10 * + N N7 0 intra-area 12 RT10 * + N N8 0 intra-area 10 RT10 * + N N9 0 intra-area 11 RT10 * + N N10 0 intra-area 13 RT10 * + N N11 0 intra-area 14 RT10 * + N H1 0 intra-area 21 RT10 * + R RT5 0 intra-area 6 RT5 * + R RT7 0 intra-area 8 RT10 * + ____________________________________________________________ + N N12 * type 1 ext. 10 RT10 RT7 + N N13 * type 1 ext. 14 RT5 RT5 + N N14 * type 1 ext. 14 RT5 RT5 + N N15 * type 1 ext. 17 RT10 RT7 + + + Table 12: The routing table for Router RT6 + (no configured areas). + + Again, Routers RT5 and RT7 are AS boundary routers. Routers RT3, + RT4, RT7, RT10 and RT11 are area border routers. Note that there are + two routing entries for the area border router RT3, since it has two + areas in common with RT4 (Area 1 and the backbone). + + Backbone paths have been calculated to all area border routers. + These are used when determining the inter-area routes. Note that all + of the inter-area routes are associated with the backbone; this is + always the case when the calculating router is itself an area border + router. Routing information is condensed at area boundaries. In + this example, we assume that Area 3 has been defined so that networks + N9-N11 and the host route to H1 are all condensed to a single route + when advertised into the backbone (by Router RT11). Note that the + cost of this route is the maximum of the set of costs to its + individual components. + + + + + + + + +Moy Standards Track [Page 98] + +RFC 2178 OSPF Version 2 July 1997 + + + There is a virtual link configured between Routers RT10 and RT11. + Without this configured virtual link, RT11 would be unable to + advertise a route for networks N9-N11 and Host H1 into the backbone, + and there would not be an entry for these networks in Router RT4's + routing table. + + In this example there are two equal-cost paths to Network N12. + However, they both use the same next hop (Router RT5). + + + Type Dest Area Path Type Cost Next Adv. + Hops(s) Router(s) + __________________________________________________________________ + N N1 1 intra-area 4 RT1 * + N N2 1 intra-area 4 RT2 * + N N3 1 intra-area 1 * * + N N4 1 intra-area 3 RT3 * + R RT3 1 intra-area 1 * * + __________________________________________________________________ + N Ib 0 intra-area 22 RT5 * + N Ia 0 intra-area 27 RT5 * + R RT3 0 intra-area 21 RT5 * + R RT5 0 intra-area 8 * * + R RT7 0 intra-area 14 RT5 * + R RT10 0 intra-area 22 RT5 * + R RT11 0 intra-area 25 RT5 * + __________________________________________________________________ + N N6 0 inter-area 15 RT5 RT7 + N N7 0 inter-area 19 RT5 RT7 + N N8 0 inter-area 18 RT5 RT7 + N N9-N11,H1 0 inter-area 36 RT5 RT11 + __________________________________________________________________ + N N12 * type 1 ext. 16 RT5 RT5,RT7 + N N13 * type 1 ext. 16 RT5 RT5 + N N14 * type 1 ext. 16 RT5 RT5 + N N15 * type 1 ext. 23 RT5 RT7 + + Table 13: Router RT4's routing table + in the presence of areas. + + + Router RT4's routing table would improve (i.e., some of the paths in + the routing table would become shorter) if an additional virtual link + were configured between Router RT4 and Router RT3. The new virtual + link would itself be associated with the first entry for area border + router RT3 in Table 13 (an intra-area path through Area 1). This + would yield a cost of 1 for the virtual link. The routing table + entries changes that would be caused by the addition of this virtual + + + +Moy Standards Track [Page 99] + +RFC 2178 OSPF Version 2 July 1997 + + + link are shown in Table 14. + +12. Link State Advertisements (LSAs) + + Each router in the Autonomous System originates one or more link + state advertisements (LSAs). This memo defines five distinct types + of LSAs, which are described in Section 4.3. The collection of LSAs + forms the link-state database. Each separate type of LSA has a + separate function. Router-LSAs and network-LSAs describe how an + area's routers and networks are interconnected. Summary-LSAs provide + a way of condensing an area's routing information. AS-external-LSAs + provide a way of transparently advertising externally-derived routing + information throughout the Autonomous System. + + Each LSA begins with a standard 20-byte header. This LSA header is + discussed below. + + Type Dest Area Path Type Cost Next Adv. + Hop(s) Router(s) + ________________________________________________________________ + N Ib 0 intra-area 16 RT3 * + N Ia 0 intra-area 21 RT3 * + R RT3 0 intra-area 1 * * + R RT10 0 intra-area 16 RT3 * + R RT11 0 intra-area 19 RT3 * + ________________________________________________________________ + N N9-N11,H1 0 inter-area 30 RT3 RT11 + + + Table 14: Changes resulting from an + additional virtual link. + +12.1. The LSA Header + + The LSA header contains the LS type, Link State ID and Advertising + Router fields. The combination of these three fields uniquely + identifies the LSA. + + There may be several instances of an LSA present in the Autonomous + System, all at the same time. It must then be determined which + instance is more recent. This determination is made by examining the + LS sequence, LS checksum and LS age fields. These fields are also + contained in the 20-byte LSA header. + + Several of the OSPF packet types list LSAs. When the instance is not + important, an LSA is referred to by its LS type, Link State ID and + Advertising Router (see Link State Request Packets). Otherwise, the + LS sequence number, LS age and LS checksum fields must also be + + + +Moy Standards Track [Page 100] + +RFC 2178 OSPF Version 2 July 1997 + + + referenced. + + A detailed explanation of the fields contained in the LSA header + follows. + +12.1.1. LS age + + This field is the age of the LSA in seconds. It should be processed + as an unsigned 16-bit integer. It is set to 0 when the LSA is + originated. It must be incremented by InfTransDelay on every hop of + the flooding procedure. LSAs are also aged as they are held in each + router's database. + + The age of an LSA is never incremented past MaxAge. LSAs having age + MaxAge are not used in the routing table calculation. When an LSA's + age first reaches MaxAge, it is reflooded. An LSA of age MaxAge is + finally flushed from the database when it is no longer needed to + ensure database synchronization. For more information on the aging + of LSAs, consult Section 14. + + The LS age field is examined when a router receives two instances of + an LSA, both having identical LS sequence numbers and LS checksums. + An instance of age MaxAge is then always accepted as most recent; + this allows old LSAs to be flushed quickly from the routing domain. + Otherwise, if the ages differ by more than MaxAgeDiff, the instance + having the smaller age is accepted as most recent.[12] See Section + 13.1 for more details. + +12.1.2. Options + + The Options field in the LSA header indicates which optional + capabilities are associated with the LSA. OSPF's optional + capabilities are described in Section 4.5. One optional capability is + defined by this specification, represented by the E-bit found in the + Options field. The unrecognized bits in the Options field should be + set to zero. The E-bit represents OSPF's ExternalRoutingCapability. + This bit should be set in all LSAs associated with the backbone, and + all LSAs associated with non-stub areas (see Section 3.6). It should + also be set in all AS-external-LSAs. It should be reset in all + router-LSAs, network-LSAs and summary-LSAs associated with a stub + area. For all LSAs, the setting of the E-bit is for informational + purposes only; it does not affect the routing table calculation. + + + + + + + + + +Moy Standards Track [Page 101] + +RFC 2178 OSPF Version 2 July 1997 + + +12.1.3. LS type + + The LS type field dictates the format and function of the LSA. LSAs + of different types have different names (e.g., router-LSAs or + network-LSAs). All LSA types defined by this memo, except the AS- + external-LSAs (LS type = 5), are flooded throughout a single area + only. AS-external-LSAs are flooded throughout the entire Autonomous + System, excepting stub areas (see Section 3.6). Each separate LSA + type is briefly described below in Table 15. + +12.1.4. Link State ID + + This field identifies the piece of the routing domain that is being + described by the LSA. Depending on the LSA's LS type, the Link State + ID takes on the values listed in Table 16. + + Actually, for Type 3 summary-LSAs (LS type = 3) and AS-external-LSAs + (LS type = 5), the Link State ID may additionally have one or more of + the destination network's "host" bits set. For example, when + originating an AS-external-LSA for the network 10.0.0.0 with mask of + 255.0.0.0, the Link State ID can be set to anything in the range + 10.0.0.0 through 10.255.255.255 inclusive (although 10.0.0.0 should + be used whenever possible). The freedom to set certain host bits + allows a router to originate separate LSAs for two networks having + the same address but different masks. See Appendix E for details. + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 102] + +RFC 2178 OSPF Version 2 July 1997 + + + LS Type LSA description + ________________________________________________ + 1 These are the router-LSAs. + They describe the collected + states of the router's + interfaces. For more information, + consult Section 12.4.1. + ________________________________________________ + 2 These are the network-LSAs. + They describe the set of routers + attached to the network. For + more information, consult + Section 12.4.2. + ________________________________________________ + 3 or 4 These are the summary-LSAs. + They describe inter-area routes, + and enable the condensation of + routing information at area + borders. Originated by area border + routers, the Type 3 summary-LSAs + describe routes to networks while the + Type 4 summary-LSAs describe routes to + AS boundary routers. + ________________________________________________ + 5 These are the AS-external-LSAs. + Originated by AS boundary routers, + they describe routes + to destinations external to the + Autonomous System. A default route for + the Autonomous System can also be + described by an AS-external-LSA. + + Table 15: OSPF link state advertisements (LSAs). + + LS Type Link State ID + _______________________________________________ + 1 The originating router's Router ID. + 2 The IP interface address of the + network's Designated Router. + 3 The destination network's IP address. + 4 The Router ID of the described AS + boundary router. + 5 The destination network's IP address. + + + Table 16: The LSA's Link State ID. + + + + + +Moy Standards Track [Page 103] + +RFC 2178 OSPF Version 2 July 1997 + + + When the LSA is describing a network (LS type = 2, 3 or 5), the + network's IP address is easily derived by masking the Link State ID + with the network/subnet mask contained in the body of the LSA. When + the LSA is describing a router (LS type = 1 or 4), the Link State ID + is always the described router's OSPF Router ID. + + When an AS-external-LSA (LS Type = 5) is describing a default route, + its Link State ID is set to DefaultDestination (0.0.0.0). + +12.1.5. Advertising Router + + This field specifies the OSPF Router ID of the LSA's originator. For + router-LSAs, this field is identical to the Link State ID field. + Network-LSAs are originated by the network's Designated Router. + Summary-LSAs originated by area border routers. AS-external-LSAs are + originated by AS boundary routers. + +12.1.6. LS sequence number + + + The sequence number field is a signed 32-bit integer. It is used to + detect old and duplicate LSAs. The space of sequence numbers is + linearly ordered. The larger the sequence number (when compared as + signed 32-bit integers) the more recent the LSA. To describe to + sequence number space more precisely, let N refer in the discussion + below to the constant 2**31. + + The sequence number -N (0x80000000) is reserved (and unused). This + leaves -N + 1 (0x80000001) as the smallest (and therefore oldest) + sequence number; this sequence number is referred to as the constant + InitialSequenceNumber. A router uses InitialSequenceNumber the first + time it originates any LSA. Afterwards, the LSA's sequence number is + incremented each time the router originates a new instance of the + LSA. When an attempt is made to increment the sequence number past + the maximum value of N - 1 (0x7fffffff; also referred to as + MaxSequenceNumber), the current instance of the LSA must first be + flushed from the routing domain. This is done by prematurely aging + the LSA (see Section 14.1) and reflooding it. As soon as this flood + has been acknowledged by all adjacent neighbors, a new instance can + be originated with sequence number of InitialSequenceNumber. + + The router may be forced to promote the sequence number of one of its + LSAs when a more recent instance of the LSA is unexpectedly received + during the flooding process. This should be a rare event. This may + indicate that an out-of-date LSA, originated by the router itself + before its last restart/reload, still exists in the Autonomous + System. For more information see Section 13.4. + + + + +Moy Standards Track [Page 104] + +RFC 2178 OSPF Version 2 July 1997 + + +12.1.7. LS checksum + + This field is the checksum of the complete contents of the LSA, + excepting the LS age field. The LS age field is excepted so that an + LSA's age can be incremented without updating the checksum. The + checksum used is the same that is used for ISO connectionless + datagrams; it is commonly referred to as the Fletcher checksum. It + is documented in Annex B of [Ref6]. The LSA header also contains the + length of the LSA in bytes; subtracting the size of the LS age field + (two bytes) yields the amount of data to checksum. + + The checksum is used to detect data corruption of an LSA. This + corruption can occur while an LSA is being flooded, or while it is + being held in a router's memory. The LS checksum field cannot take + on the value of zero; the occurrence of such a value should be + considered a checksum failure. In other words, calculation of the + checksum is not optional. + + The checksum of an LSA is verified in two cases: a) when it is + received in a Link State Update Packet and b) at times during the + aging of the link state database. The detection of a checksum + failure leads to separate actions in each case. See Sections 13 and + 14 for more details. + + Whenever the LS sequence number field indicates that two instances of + an LSA are the same, the LS checksum field is examined. If there is + a difference, the instance with the larger LS checksum is considered + to be most recent.[13] See Section 13.1 for more details. + +12.2. The link state database + + A router has a separate link state database for every area to which + it belongs. All routers belonging to the same area have identical + link state databases for the area. + + The databases for each individual area are always dealt with + separately. The shortest path calculation is performed separately + for each area (see Section 16). Components of the area link-state + database are flooded throughout the area only. Finally, when an + adjacency (belonging to Area A) is being brought up, only the + database for Area A is synchronized between the two routers. + + The area database is composed of router-LSAs, network-LSAs and + summary-LSAs (all listed in the area data structure). In addition, + external routes (AS-external-LSAs) are included in all non-stub area + databases (see Section 3.6). + + + + + +Moy Standards Track [Page 105] + +RFC 2178 OSPF Version 2 July 1997 + + + An implementation of OSPF must be able to access individual pieces of + an area database. This lookup function is based on an LSA's LS type, + Link State ID and Advertising Router.[14] There will be a single + instance (the most up-to-date) of each LSA in the database. The + database lookup function is invoked during the LSA flooding procedure + (Section 13) and the routing table calculation (Section 16). In + addition, using this lookup function the router can determine whether + it has itself ever originated a particular LSA, and if so, with what + LS sequence number. + + An LSA is added to a router's database when either a) it is received + during the flooding process (Section 13) or b) it is originated by + the router itself (Section 12.4). An LSA is deleted from a router's + database when either a) it has been overwritten by a newer instance + during the flooding process (Section 13) or b) the router originates + a newer instance of one of its self-originated LSAs (Section 12.4) or + c) the LSA ages out and is flushed from the routing domain (Section + 14). + + Whenever an LSA is deleted from the database it must also be removed + from all neighbors' Link state retransmission lists (see Section 10). + +12.3. Representation of TOS + + For backward compatibility with previous versions of the OSPF + specification ([Ref9]), TOS-specific information can be included in + router-LSAs, summary-LSAs and AS-external-LSAs. The encoding of TOS + in OSPF LSAs is specified in Table 17. That table relates the OSPF + encoding to the IP packet header's TOS field (defined in [Ref12]). + The OSPF encoding is expressed as a decimal integer, and the IP + packet header's TOS field is expressed in the binary TOS values used + in [Ref12]. + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 106] + +RFC 2178 OSPF Version 2 July 1997 + + + OSPF encoding RFC 1349 TOS values + ___________________________________________ + 0 0000 normal service + 2 0001 minimize monetary cost + 4 0010 maximize reliability + 6 0011 + 8 0100 maximize throughput + 10 0101 + 12 0110 + 14 0111 + 16 1000 minimize delay + 18 1001 + 20 1010 + 22 1011 + 24 1100 + 26 1101 + 28 1110 + 30 1111 + + Table 17: Representing TOS in OSPF. + +12.4. Originating LSAs + + Into any given OSPF area, a router will originate several LSAs. Each + router originates a router-LSA. If the router is also the Designated + Router for any of the area's networks, it will originate network-LSAs + for those networks. + + Area border routers originate a single summary-LSA for each known + inter-area destination. AS boundary routers originate a single AS- + external-LSA for each known AS external destination. Destinations + are advertised one at a time so that the change in any single route + can be flooded without reflooding the entire collection of routes. + During the flooding procedure, many LSAs can be carried by a single + Link State Update packet. + + As an example, consider Router RT4 in Figure 6. It is an area border + router, having a connection to Area 1 and the backbone. Router RT4 + originates 5 distinct LSAs into the backbone (one router-LSA, and one + summary-LSA for each of the networks N1-N4). Router RT4 will also + originate 8 distinct LSAs into Area 1 (one router-LSA and seven + summary-LSAs as pictured in Figure 7). If RT4 has been selected as + Designated Router for Network N3, it will also originate a network- + LSA for N3 into Area 1. + + In this same figure, Router RT5 will be originating 3 distinct AS- + external-LSAs (one for each of the networks N12-N14). These will be + flooded throughout the entire AS, assuming that none of the areas + + + +Moy Standards Track [Page 107] + +RFC 2178 OSPF Version 2 July 1997 + + + have been configured as stubs. However, if area 3 has been + configured as a stub area, the AS-external-LSAs for networks N12-N14 + will not be flooded into area 3 (see Section 3.6). Instead, Router + RT11 would originate a default summary- LSA that would be flooded + throughout area 3 (see Section 12.4.3). This instructs all of area + 3's internal routers to send their AS external traffic to RT11. + + Whenever a new instance of an LSA is originated, its LS sequence + number is incremented, its LS age is set to 0, its LS checksum is + calculated, and the LSA is added to the link state database and + flooded out the appropriate interfaces. See Section 13.2 for details + concerning the installation of the LSA into the link state database. + See Section 13.3 for details concerning the flooding of newly + originated LSAs. + + The ten events that can cause a new instance of an LSA to be + originated are: + + (1) The LS age field of one of the router's self-originated LSAs + reaches the value LSRefreshTime. In this case, a new + instance of the LSA is originated, even though the contents + of the LSA (apart from the LSA header) will be the same. + This guarantees periodic originations of all LSAs. This + periodic updating of LSAs adds robustness to the link state + algorithm. LSAs that solely describe unreachable + destinations should not be refreshed, but should instead be + flushed from the routing domain (see Section 14.1). + + When whatever is being described by an LSA changes, a new LSA is + originated. However, two instances of the same LSA may not be + originated within the time period MinLSInterval. This may require + that the generation of the next instance be delayed by up to + MinLSInterval. The following events may cause the contents of an LSA + to change. These events should cause new originations if and only if + the contents of the new LSA would be different: + + (2) An interface's state changes (see Section 9.1). This may + mean that it is necessary to produce a new instance of the + router-LSA. + + (3) An attached network's Designated Router changes. A new + router-LSA should be originated. Also, if the router itself + is now the Designated Router, a new network-LSA should be + produced. If the router itself is no longer the Designated + Router, any network-LSA that it might have originated for + the network should be flushed from the routing domain (see + Section 14.1). + + + + +Moy Standards Track [Page 108] + +RFC 2178 OSPF Version 2 July 1997 + + + (4) One of the neighboring routers changes to/from the FULL + state. This may mean that it is necessary to produce a new + instance of the router-LSA. Also, if the router is itself + the Designated Router for the attached network, a new + network-LSA should be produced. + + The next four events concern area border routers only: + + (5) An intra-area route has been added/deleted/modified in the + routing table. This may cause a new instance of a summary- + LSA (for this route) to be originated in each attached area + (possibly including the backbone). + + (6) An inter-area route has been added/deleted/modified in the + routing table. This may cause a new instance of a summary- + LSA (for this route) to be originated in each attached area + (but NEVER for the backbone). + + (7) The router becomes newly attached to an area. The router + must then originate summary-LSAs into the newly attached + area for all pertinent intra-area and inter-area routes in + the router's routing table. See Section 12.4.3 for more + details. + + (8) When the state of one of the router's configured virtual + links changes, it may be necessary to originate a new + router-LSA into the virtual link's Transit area (see the + discussion of the router-LSA's bit V in Section 12.4.1), as + well as originating a new router-LSA into the backbone. + + The last two events concern AS boundary routers (and former AS + boundary routers) only: + + (9) An external route gained through direct experience with an + external routing protocol (like BGP) changes. This will + cause an AS boundary router to originate a new instance of + an AS-external-LSA. + + (10) + A router ceases to be an AS boundary router, perhaps after + restarting. In this situation the router should flush all + AS-external-LSAs that it had previously originated. These + LSAs can be flushed via the premature aging procedure + specified in Section 14.1. + + + + + + + +Moy Standards Track [Page 109] + +RFC 2178 OSPF Version 2 July 1997 + + + The construction of each type of LSA is explained in detail below. In + general, these sections describe the contents of the LSA body (i.e., + the part coming after the 20-byte LSA header). For information + concerning the building of the LSA header, see Section 12.1. + +12.4.1. Router-LSAs + + A router originates a router-LSA for each area that it belongs to. + Such an LSA describes the collected states of the router's links to + the area. The LSA is flooded throughout the particular area, and no + further. The format of a router-LSA is shown in Appendix A (Section + A.4.2). The first 20 bytes of the LSA consist of the generic LSA + header that was discussed in Section 12.1. router-LSAs have LS type + = 1. + + A router also indicates whether it is an area border router, or an AS + boundary router, by setting the appropriate bits + + .................................... + . 192.1.2 Area 1 . + . + . + . | . + . | 3+---+1 . + . N1 |--|RT1|-----+ . + . | +---+ \ . + . | \ _______N3 . + . + \/ \ . 1+---+ + . * 192.1.1 *------|RT4| + . + /\_______/ . +---+ + . | / | . + . | 3+---+1 / | . + . N2 |--|RT2|-----+ 1| . + . | +---+ +---+8 . 6+---+ + . | |RT3|----------------|RT6| + . + +---+ . +---+ + . 192.1.3 |2 . 18.10.0.6|7 + . | . | + . +------------+ . + . 192.1.4 (N4) . + .................................... + + Figure 15: Area 1 with IP addresses shown + + (bit B and bit E, respectively) in its router-LSAs. This enables + paths to those types of routers to be saved in the routing table, for + later processing of summary-LSAs and AS-external-LSAs. Bit B should + be set whenever the router is actively attached to two or more areas, + even if the router is not currently attached to the OSPF backbone + + + +Moy Standards Track [Page 110] + +RFC 2178 OSPF Version 2 July 1997 + + + area. Bit E should never be set in a router-LSA for a stub area + (stub areas cannot contain AS boundary routers). + + In addition, the router sets bit V in its router-LSA for Area A if + and only if the router is the endpoint of one or more fully adjacent + virtual links having Area A as their Transit area. The setting of bit + V enables other routers in Area A to discover whether the area + supports transit traffic (see TransitCapability in Section 6). + + The router-LSA then describes the router's working connections (i.e., + interfaces or links) to the area. Each link is typed according to + the kind of attached network. Each link is also labelled with its + Link ID. This Link ID gives a name to the entity that is on the + other end of the link. Table 18 summarizes the values used for the + Type and Link ID fields. + + Link type Description Link ID + __________________________________________________ + 1 Point-to-point Neighbor Router ID + link + 2 Link to transit Interface address of + network Designated Router + 3 Link to stub IP network number + network + 4 Virtual link Neighbor Router ID + + Table 18: Link descriptions in the + router-LSA. + + In addition, the Link Data field is specified for each link. This + field gives 32 bits of extra information for the link. For links to + transit networks, numbered point-to-point links and virtual links, + this field specifies the IP interface address of the associated + router interface (this is needed by the routing table calculation, + see Section 16.1.1). For links to stub networks, this field + specifies the stub network's IP address mask. For unnumbered point- + to-point links, the Link Data field should be set to the unnumbered + interface's MIB-II [Ref8] ifIndex value. + + Finally, the cost of using the link for output is specified. The + output cost of a link is configurable. With the exception of links to + stub networks, the output cost must always be non-zero. + + To further describe the process of building the list of link + descriptions, suppose a router wishes to build a router-LSA for Area + A. The router examines its collection of interface data structures. + For each interface, the following steps are taken: + + + + +Moy Standards Track [Page 111] + +RFC 2178 OSPF Version 2 July 1997 + + + o If the attached network does not belong to Area A, no + links are added to the LSA, and the next interface should be + examined. + + o If the state of the interface is Down, no links are added. + + o If the state of the interface is Loopback, add a Type 3 + link (stub network) as long as this is not an interface to an + unnumbered point-to-point network. The Link ID should be set to + the IP interface address, the Link Data set to the + mask 0xffffffff (indicating a host route), and the cost set to 0. + + o Otherwise, the link descriptions added to the router-LSA + depend on the OSPF interface type. Link descriptions used for + point-to-point interfaces are specified in Section 12.4.1.1, for + virtual links in Section 12.4.1.2, for broadcast and NBMA + interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in + 12.4.1.4. + + After consideration of all the router interfaces, host links are + added to the router-LSA by examining the list of attached hosts + belonging to Area A. A host route is represented as a Type 3 link + (stub network) whose Link ID is the host's IP address, Link Data is + the mask of all ones (0xffffffff), and cost the host's configured + cost (see Section C.7). + +12.4.1.1. Describing point-to-point interfaces + + For point-to-point interfaces, one or more link descriptions are + added to the router-LSA as follows: + + o If the neighboring router is fully adjacent, add a + Type 1 link (point-to-point). The Link ID should be set to the + Router ID of the neighboring router. For numbered point-to-point + networks, the Link Data should specify the IP interface address. + For unnumbered point-to-point networks, the Link Data field + should specify the interface's MIB-II [Ref8] ifIndex value. The + cost should be set to the output cost of the point-to-point + interface. + + o In addition, as long as the state of the interface + is "Point-to-Point" (and regardless of the neighboring router + state), a Type 3 link (stub network) should be added. There are + two forms that this stub link can take: + + + + + + + +Moy Standards Track [Page 112] + +RFC 2178 OSPF Version 2 July 1997 + + + Option 1 + Assuming that the neighboring router's IP address is known, set + the Link ID of the Type 3 link to the neighbor's IP address, the + Link Data to the mask 0xffffffff (indicating a host route), and + the cost to the interface's configured output cost.[15] + + Option 2 + If a subnet has been assigned to the point-to-point link, set the + Link ID of the Type 3 link to the subnet's IP address, the Link + Data to the subnet's mask, and the cost to the interface's + configured output cost.[16] + +12.4.1.2. Describing broadcast and NBMA interfaces + + For operational broadcast and NBMA interfaces, a single link + description is added to the router-LSA as follows: + + o If the state of the interface is Waiting, add a Type + 3 link (stub network) with Link ID set to the IP network number + of the attached network, Link Data set to the attached network's + address mask, and cost equal to the interface's configured output + cost. + + o Else, there has been a Designated Router elected for + the attached network. If the router is fully adjacent to the + Designated Router, or if the router itself is Designated Router + and is fully adjacent to at least one other router, add a single + Type 2 link (transit network) with Link ID set to the IP + interface address of the attached network's Designated Router + (which may be the router itself), Link Data set to the router's + own IP interface address, and cost equal to the interface's + configured output cost. Otherwise, add a link as if the + interface state were Waiting (see above). + +12.4.1.3. Describing virtual links + + For virtual links, a link description is added to the router-LSA only + when the virtual neighbor is fully adjacent. In this case, add a Type + 4 link (virtual link) with Link ID set to the Router ID of the + virtual neighbor, Link Data set to the IP interface address + associated with the virtual link and cost set to the cost calculated + for the virtual link during the routing table calculation (see + Section 15). + + + + + + + + +Moy Standards Track [Page 113] + +RFC 2178 OSPF Version 2 July 1997 + + +12.4.1.4. Describing Point-to-MultiPoint interfaces + + For operational Point-to-MultiPoint interfaces, one or more link + descriptions are added to the router-LSA as follows: + + o A single Type 3 link (stub network) is added with + Link ID set to the router's own IP interface address, Link Data + set to the mask 0xffffffff (indicating a host route), and cost + set to 0. + + o For each fully adjacent neighbor associated with the + interface, add an additional Type 1 link (point-to-point) with + Link ID set to the Router ID of the neighboring router, Link Data + set to the IP interface address and cost equal to the interface's + configured output cost. + +12.4.1.5. Examples of router-LSAs + + Consider the router-LSAs generated by Router RT3, as pictured in + Figure 6. The area containing Router RT3 (Area 1) has been redrawn, + with actual network addresses, in Figure 15. Assume that the last + byte of all of RT3's interface addresses is 3, giving it the + interface addresses 192.1.1.3 and 192.1.4.3, and that the other + routers have similar addressing schemes. In addition, assume that + all links are functional, and that Router IDs are assigned as the + smallest IP interface address. + + RT3 originates two router-LSAs, one for Area 1 and one for the + backbone. Assume that Router RT4 has been selected as the Designated + router for network 192.1.1.0. RT3's router-LSA for Area 1 is then + shown below. It indicates that RT3 has two connections to Area 1, + the first a link to the transit network 192.1.1.0 and the second a + link to the stub network 192.1.4.0. Note that the transit network is + identified by the IP interface of its Designated Router (i.e., the + Link ID = 192.1.1.4 which is the Designated Router RT4's IP interface + to 192.1.1.0). Note also that RT3 has indicated that it is an area + border router. + + + + + + + + + + + + + + +Moy Standards Track [Page 114] + +RFC 2178 OSPF Version 2 July 1997 + + + ; RT3's router-LSA for Area 1 + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 1 ;indicates router-LSA + Link State ID = 192.1.1.3 ;RT3's Router ID + Advertising Router = 192.1.1.3 ;RT3's Router ID + bit E = 0 ;not an AS boundary router + bit B = 1 ;area border router + #links = 2 + Link ID = 192.1.1.4 ;IP address of Desig. Rtr. + Link Data = 192.1.1.3 ;RT3's IP interface to net + Type = 2 ;connects to transit network + # TOS metrics = 0 + metric = 1 + + Link ID = 192.1.4.0 ;IP Network number + Link Data = 0xffffff00 ;Network mask + Type = 3 ;connects to stub network + # TOS metrics = 0 + metric = 2 + + Next RT3's router-LSA for the backbone is shown. It indicates that + RT3 has a single attachment to the backbone. This attachment is via + an unnumbered point-to-point link to Router RT6. RT3 has again + indicated that it is an area border router. + + + ; RT3's router-LSA for the backbone + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 1 ;indicates router-LSA + Link State ID = 192.1.1.3 ;RT3's router ID + Advertising Router = 192.1.1.3 ;RT3's router ID + bit E = 0 ;not an AS boundary router + bit B = 1 ;area border router + #links = 1 + Link ID = 18.10.0.6 ;Neighbor's Router ID + Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link + Type = 1 ;connects to router + # TOS metrics = 0 + metric = 8 + + + + + + + + +Moy Standards Track [Page 115] + +RFC 2178 OSPF Version 2 July 1997 + + +12.4.2. Network-LSAs + + A network-LSA is generated for every transit broadcast or NBMA + network. (A transit network is a network having two or more attached + routers). The network-LSA describes all the routers that are + attached to the network. + + The Designated Router for the network originates the LSA. The + Designated Router originates the LSA only if it is fully adjacent to + at least one other router on the network. The network-LSA is flooded + throughout the area that contains the transit network, and no + further. The network-LSA lists those routers that are fully adjacent + to the Designated Router; each fully adjacent router is identified by + its OSPF Router ID. The Designated Router includes itself in this + list. + + The Link State ID for a network-LSA is the IP interface address of + the Designated Router. This value, masked by the network's address + mask (which is also contained in the network-LSA) yields the + network's IP address. + + A router that has formerly been the Designated Router for a network, + but is no longer, should flush the network-LSA that it had previously + originated. This LSA is no longer used in the routing table + calculation. It is flushed by prematurely incrementing the LSA's age + to MaxAge and reflooding (see Section 14.1). In addition, in those + rare cases where a router's Router ID has changed, any network-LSAs + that were originated with the router's previous Router ID must be + flushed. Since the router may have no idea what it's previous Router + ID might have been, these network-LSAs are indicated by having their + Link State ID equal to one of the router's IP interface addresses and + their Advertising Router equal to some value other than the router's + current Router ID (see Section 13.4 for more details). + +12.4.2.1. Examples of network-LSAs + + Again consider the area configuration in Figure 6. Network-LSAs are + originated for Network N3 in Area 1, Networks N6 and N8 in Area 2, + and Network N9 in Area 3. Assuming that Router RT4 has been selected + as the Designated Router for Network N3, the following network-LSA is + generated by RT4 on behalf of Network N3 (see Figure 15 for the + address assignments): + + + + + + + + + +Moy Standards Track [Page 116] + +RFC 2178 OSPF Version 2 July 1997 + + + ; Network-LSA for Network N3 + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 2 ;indicates network-LSA + Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. + Advertising Router = 192.1.1.4 ;RT4's Router ID + Network Mask = 0xffffff00 + Attached Router = 192.1.1.4 ;Router ID + Attached Router = 192.1.1.1 ;Router ID + Attached Router = 192.1.1.2 ;Router ID + Attached Router = 192.1.1.3 ;Router ID + +12.4.3. Summary-LSAs + + The destination described by a summary-LSA is either an IP network, + an AS boundary router or a range of IP addresses. Summary-LSAs are + flooded throughout a single area only. The destination described is + one that is external to the area, yet still belongs to the Autonomous + System. + + Summary-LSAs are originated by area border routers. The precise + summary routes to advertise into an area are determined by examining + the routing table structure (see Section 11) in accordance with the + algorithm described below. Note that only intra-area routes are + advertised into the backbone, while both intra-area and inter-area + routes are advertised into the other areas. + + To determine which routes to advertise into an attached Area A, each + routing table entry is processed as follows. Remember that each + routing table entry describes a set of equal-cost best paths to a + particular destination: + + o Only Destination Types of network and AS boundary router + are advertised in summary-LSAs. If the routing table entry's + Destination Type is area border router, examine the next routing + table entry. + + o AS external routes are never advertised in summary-LSAs. + If the routing table entry has Path-type of type 1 external or + type 2 external, examine the next routing table entry. + + o Else, if the area associated with this set of paths is + the Area A itself, do not generate a summary-LSA for the + route.[17] + + + + + + +Moy Standards Track [Page 117] + +RFC 2178 OSPF Version 2 July 1997 + + + o Else, if the next hops associated with this set of paths + belong to Area A itself, do not generate a summary-LSA for the + route.[18] This is the logical equivalent of a Distance Vector + protocol's split horizon logic. + + o Else, if the routing table cost equals or exceeds the + value LSInfinity, a summary-LSA cannot be generated for this + route. + + o Else, if the destination of this route is an AS boundary + router, a summary-LSA should be originated if and only if the + routing table entry describes the preferred path to the AS + boundary router (see Step 3 of Section 16.4). If so, a Type 4 + summary-LSA is originated for the destination, with Link State ID + equal to the AS boundary router's Router ID and metric equal to + the routing table entry's cost. Note: these LSAs should not be + generated if Area A has been configured as a stub area. + + o Else, the Destination type is network. If this is an + inter-area route, generate a Type 3 summary-LSA for the + destination, with Link State ID equal to the network's address (if + necessary, the Link State ID can also have one or more of the + network's host bits set; see Appendix E for details) and metric + equal to the routing table cost. + + o The one remaining case is an intra-area route to a network. This + means that the network is contained in one of the router's + directly attached areas. In general, this information must be + condensed before appearing in summary-LSAs. Remember that an area + has a configured list of address ranges, each range consisting of + an [address,mask] pair and a status indication of either Advertise + or DoNotAdvertise. At most a single Type 3 summary-LSA is + originated for each range. When the range's status indicates + Advertise, a Type 3 summary-LSA is generated with Link State ID + equal to the range's address (if necessary, the Link State ID can + also have one or more of the range's "host" bits set; see Appendix + E for details) and cost equal to the largest cost of any of the + component networks. When the range's status indicates + DoNotAdvertise, the Type 3 summary-LSA is suppressed and the + component networks remain hidden from other areas. + + By default, if a network is not contained in any explicitly + configured address range, a Type 3 summary-LSA is generated with Link + State ID equal to the network's address (if necessary, the Link State + ID can also have one or more of the network's "host" bits set; see + Appendix E for details) and metric equal to the network's routing + table cost. + + + + +Moy Standards Track [Page 118] + +RFC 2178 OSPF Version 2 July 1997 + + + If an area is capable of carrying transit traffic (i.e., its + TransitCapability is set to TRUE), routing information concerning + backbone networks should not be condensed before being summarized + into the area. Nor should the advertisement of backbone networks + into transit areas be suppressed. In other words, the backbone's + configured ranges should be ignored when originating summary-LSAs + into transit areas. + + If a router advertises a summary-LSA for a destination which then + becomes unreachable, the router must then flush the LSA from the + routing domain by setting its age to MaxAge and reflooding (see + Section 14.1). Also, if the destination is still reachable, yet can + no longer be advertised according to the above procedure (e.g., it is + now an inter-area route, when it used to be an intra-area route + associated with some non-backbone area; it would thus no longer be + advertisable to the backbone), the LSA should also be flushed from + the routing domain. + +12.4.3.1. Originating summary-LSAs into stub areas + + The algorithm in Section 12.4.3 is optional when Area A is an OSPF + stub area. Area border routers connecting to a stub area can + originate summary-LSAs into the area according to the Section + 12.4.3's algorithm, or can choose to originate only a subset of the + summary-LSAs, possibly under configuration control. The fewer LSAs + originated, the smaller the stub area's link state database, further + reducing the demands on its routers' resources. However, omitting + LSAs may also lead to sub-optimal inter-area routing, although + routing will continue to function. + + As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary- + LSAs) are never originated into stub areas. + + In a stub area, instead of importing external routes each area border + router originates a "default summary-LSA" into the area. The Link + State ID for the default summary-LSA is set to DefaultDestination, + and the metric set to the (per-area) configurable parameter + StubDefaultCost. Note that StubDefaultCost need not be configured + identically in all of the stub area's area border routers. + +12.4.3.2. Examples of summary-LSAs + + Consider again the area configuration in Figure 6. Routers RT3, RT4, + RT7, RT10 and RT11 are all area border routers, and therefore are + originating summary-LSAs. Consider in particular Router RT4. Its + routing table was calculated as the example in Section 11.3. RT4 + originates summary-LSAs into both the backbone and Area 1. Into the + backbone, Router RT4 originates separate LSAs for each of the + + + +Moy Standards Track [Page 119] + +RFC 2178 OSPF Version 2 July 1997 + + + networks N1-N4. Into Area 1, Router RT4 originates separate LSAs for + networks N6-N8 and the AS boundary routers RT5,RT7. It also + condenses host routes Ia and Ib into a single summary-LSA. Finally, + the routes to networks N9,N10,N11 and Host H1 are advertised by a + single summary-LSA. This condensation was originally performed by + the router RT11. + + These LSAs are illustrated graphically in Figures 7 and 8. Two of + the summary-LSAs originated by Router RT4 follow. The actual IP + addresses for the networks and routers in question have been assigned + in Figure 15. + + ; Summary-LSA for Network N1, + ; originated by Router RT4 into the backbone + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 3 ;Type 3 summary-LSA + Link State ID = 192.1.2.0 ;N1's IP network number + Advertising Router = 192.1.1.4 ;RT4's ID + metric = 4 + + ; Summary-LSA for AS boundary router RT7 + ; originated by Router RT4 into Area 1 + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 4 ;Type 4 summary-LSA + Link State ID = Router RT7's ID + Advertising Router = 192.1.1.4 ;RT4's ID + metric = 14 + +12.4.4. AS-external-LSAs + + AS-external-LSAs describe routes to destinations external to the + Autonomous System. Most AS-external-LSAs describe routes to specific + external destinations; in these cases the LSA's Link State ID is set + to the destination network's IP address (if necessary, the Link State + ID can also have one or more of the network's "host" bits set; see + Appendix E for details). However, a default route for the Autonomous + System can be described in an AS-external-LSA by setting the LSA's + Link State ID to DefaultDestination (0.0.0.0). AS-external-LSAs are + originated by AS boundary routers. An AS boundary router originates + a single AS-external-LSA for each external route that it has learned, + either through another routing protocol (such as BGP), or through + configuration information. + + + + + +Moy Standards Track [Page 120] + +RFC 2178 OSPF Version 2 July 1997 + + + AS-external-LSAs are the only type of LSAs that are flooded + throughout the entire Autonomous System; all other types of LSAs are + specific to a single area. However, AS-external-LSAs are not flooded + into/throughout stub areas (see Section 3.6). This enables a + reduction in link state database size for routers internal to stub + areas. + + The metric that is advertised for an external route can be one of two + types. Type 1 metrics are comparable to the link state metric. Type + 2 metrics are assumed to be larger than the cost of any intra-AS + path. + + If a router advertises an AS-external-LSA for a destination which + then becomes unreachable, the router must then flush the LSA from the + routing domain by setting its age to MaxAge and reflooding (see + Section 14.1). + +12.4.4.1. Examples of AS-external-LSAs + + Consider once again the AS pictured in Figure 6. There are two AS + boundary routers: RT5 and RT7. Router RT5 originates three AS- + external-LSAs, for networks N12-N14. Router RT7 originates two AS- + external-LSAs, for networks N12 and N15. Assume that RT7 has learned + its route to N12 via BGP, and that it wishes to advertise a Type 2 + metric to the AS. RT7 would then originate the following LSA for + N12: + + ; AS-external-LSA for Network N12, + ; originated by Router RT7 + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 5 ;AS-external-LSA + Link State ID = N12's IP network number + Advertising Router = Router RT7's ID + bit E = 1 ;Type 2 metric + metric = 2 + Forwarding address = 0.0.0.0 + + In the above example, the forwarding address field has been set to + 0.0.0.0, indicating that packets for the external destination should + be forwarded to the advertising OSPF router (RT7). This is not always + desirable. Consider the example pictured in Figure 16. There are + three OSPF routers (RTA, RTB and RTC) connected to a common network. + Only one of these routers, RTA, is exchanging BGP information with + the non-OSPF router RTX. RTA must then originate AS- external-LSAs + for those destinations it has learned from RTX. By using the AS- + external-LSA's forwarding address field, RTA can specify that packets + + + +Moy Standards Track [Page 121] + +RFC 2178 OSPF Version 2 July 1997 + + + for these destinations be forwarded directly to RTX. Without this + feature, Routers RTB and RTC would take an extra hop to get to these + destinations. + + Note that when the forwarding address field is non-zero, it should + point to a router belonging to another Autonomous System. + + A forwarding address can also be specified for the default route. For + example, in figure 16 RTA may want to specify that all externally- + destined packets should by default be forwarded to its BGP peer RTX. + The resulting AS-external-LSA is pictured below. Note that the Link + State ID is set to DefaultDestination. + + ; Default route, originated by Router RTA + ; Packets forwarded through RTX + + LS age = 0 ;always true on origination + Options = (E-bit) ; + LS type = 5 ;AS-external-LSA + Link State ID = DefaultDestination ; default route + Advertising Router = Router RTA's ID + bit E = 1 ;Type 2 metric + metric = 1 + Forwarding address = RTX's IP address + + In figure 16, suppose instead that both RTA and RTB exchange BGP + information with RTX. In this case, RTA and RTB would originate the + same set of AS-external-LSAs. These LSAs, if they specify the same + metric, would be functionally equivalent since they would specify the + same destination and forwarding address (RTX). This leads to a clear + duplication of effort. If only one of RTA or RTB originated the set + of AS-external-LSAs, the routing would remain the same, and the size + of the link state database would decrease. However, it must be + unambiguously defined as to which router originates the LSAs + (otherwise neither may, or the identity of the originator may + oscillate). The following rule is thereby established: if two + routers, both reachable from one another, originate functionally + equivalent AS-external-LSAs (i.e., same destination, cost and non- + zero forwarding address), then the LSA originated by the router + having the highest OSPF Router ID is used. The router having the + lower OSPF Router ID can then flush its LSA. Flushing an LSA is + discussed in Section 14.1. + +13. The Flooding Procedure + + Link State Update packets provide the mechanism for flooding LSAs. A + Link State Update packet may contain several distinct LSAs, and + floods each LSA one hop further from its point of origination. To + + + +Moy Standards Track [Page 122] + +RFC 2178 OSPF Version 2 July 1997 + + + make the flooding procedure reliable, each LSA must be acknowledged + separately. Acknowledgments are transmitted in Link State + Acknowledgment packets. Many separate acknowledgments can also be + grouped together into a single packet. + + The flooding procedure starts when a Link State Update packet has + been received. Many consistency checks have been made on the + received packet before being handed to the flooding procedure (see + Section 8.2). In particular, the Link State Update packet has been + associated with a particular neighbor, and a particular area. If the + neighbor is in a lesser state than Exchange, the packet should be + dropped without further processing. + + + + | + +---+.....|.BGP + |RTA|-----|.....+---+ + +---+ |-----|RTX| + | +---+ + +---+ | + |RTB|-----| + +---+ | + | + +---+ | + |RTC|-----| + +---+ | + | + + + + Figure 16: Forwarding address example + + All types of LSAs, other than AS-external-LSAs, are associated with a + specific area. However, LSAs do not contain an area field. An LSA's + area must be deduced from the Link State Update packet header. + + For each LSA contained in a Link State Update packet, the following + steps are taken: + + + (1) Validate the LSA's LS checksum. If the checksum turns out to be + invalid, discard the LSA and get the next one from the Link + State Update packet. + + (2) Examine the LSA's LS type. If the LS type is unknown, discard + the LSA and get the next one from the Link State Update Packet. + This specification defines LS types 1-5 (see Section 4.3). + + (3) Else if this is an AS-external-LSA (LS type = 5), and the area + + + +Moy Standards Track [Page 123] + +RFC 2178 OSPF Version 2 July 1997 + + + has been configured as a stub area, discard the LSA and get the + next one from the Link State Update Packet. AS-external-LSAs + are not flooded into/throughout stub areas (see Section 3.6). + + (4) Else if the LSA's LS age is equal to MaxAge, and there is + currently no instance of the LSA in the router's link state + database, then take the following actions: + + (a) Acknowledge the receipt of the LSA by sending a Link State + Acknowledgment packet back to the sending neighbor (see + Section 13.5). + + (b) Purge all outstanding requests for equal or previous + instances of the LSA from the sending neighbor's Link State + Request list (see Section 10). + + (c) If the sending neighbor is in state Exchange or in state + Loading, then install the MaxAge LSA in the link state + database. Otherwise, simply discard the LSA. In either + case, examine the next LSA (if any) listed in the Link State + Update packet. + + (5) Otherwise, find the instance of this LSA that is currently + contained in the router's link state database. If there is no + database copy, or the received LSA is more recent than the + database copy (see Section 13.1 below for the determination of + which LSA is more recent) the following steps must be performed: + + (a) If there is already a database copy, and if the database + copy was installed less than MinLSArrival seconds ago, + discard the new LSA (without acknowledging it) and examine + the next LSA (if any) listed in the Link State Update + packet. + + (b) Otherwise immediately flood the new LSA out some subset of + the router's interfaces (see Section 13.3). In some cases + (e.g., the state of the receiving interface is DR and the + LSA was received from a router other than the Backup DR) the + LSA will be flooded back out the receiving interface. This + occurrence should be noted for later use by the + acknowledgment process (Section 13.5). + + (c) Remove the current database copy from all neighbors' Link + state retransmission lists. + + (d) Install the new LSA in the link state database (replacing + the current database copy). This may cause the routing + table calculation to be scheduled. In addition, timestamp + + + +Moy Standards Track [Page 124] + +RFC 2178 OSPF Version 2 July 1997 + + + the new LSA with the current time (i.e., the time it was + received). The flooding procedure cannot overwrite the + newly installed LSA until MinLSArrival seconds have elapsed. + The LSA installation process is discussed further in Section + 13.2. + + (e) Possibly acknowledge the receipt of the LSA by sending a + Link State Acknowledgment packet back out the receiving + interface. This is explained below in Section 13.5. + + (f) If this new LSA indicates that it was originated by the + receiving router itself (i.e., is considered a self- + originated LSA), the router must take special action, either + updating the LSA or in some cases flushing it from the + routing domain. For a description of how self-originated + LSAs are detected and subsequently handled, see Section + 13.4. + + (6) Else, if there is an instance of the LSA on the sending + neighbor's Link state request list, an error has occurred in the + Database Exchange process. In this case, restart the Database + Exchange process by generating the neighbor event BadLSReq for + the sending neighbor and stop processing the Link State Update + packet. + + (7) Else, if the received LSA is the same instance as the database + copy (i.e., neither one is more recent) the following two steps + should be performed: + + (a) If the LSA is listed in the Link state retransmission list + for the receiving adjacency, the router itself is expecting + an acknowledgment for this LSA. The router should treat the + received LSA as an acknowledgment by removing the LSA from + the Link state retransmission list. This is termed an + "implied acknowledgment". Its occurrence should be noted + for later use by the acknowledgment process (Section 13.5). + + (b) Possibly acknowledge the receipt of the LSA by sending a + Link State Acknowledgment packet back out the receiving + interface. This is explained below in Section 13.5. + + (8) Else, the database copy is more recent. If the database copy + has LS age equal to MaxAge and LS sequence number equal to + MaxSequenceNumber, simply discard the received LSA without + acknowledging it. (In this case, the LSA's LS sequence number is + wrapping, and the MaxSequenceNumber LSA must be completely + flushed before any new LSA instance can be introduced). + Otherwise, send the database copy back to the sending neighbor, + + + +Moy Standards Track [Page 125] + +RFC 2178 OSPF Version 2 July 1997 + + + encapsulated within a Link State Update Packet. The Link State + Update Packet should be unicast to the neighbor. In so doing, do + not put the database copy of the LSA on the neighbor's link + state retransmission list, and do not acknowledge the received + (less recent) LSA instance. + +13.1. Determining which LSA is newer + + When a router encounters two instances of an LSA, it must determine + which is more recent. This occurred above when comparing a received + LSA to its database copy. This comparison must also be done during + the Database Exchange procedure which occurs during adjacency bring- + up. + + An LSA is identified by its LS type, Link State ID and Advertising + Router. For two instances of the same LSA, the LS sequence number, + LS age, and LS checksum fields are used to determine which instance + is more recent: + + o The LSA having the newer LS sequence number is more recent. + See Section 12.1.6 for an explanation of the LS sequence number + space. If both instances have the same LS sequence number, then: + + o If the two instances have different LS checksums, then the + instance having the larger LS checksum (when considered as a 16- + bit unsigned integer) is considered more recent. + + o Else, if only one of the instances has its LS age field set + to MaxAge, the instance of age MaxAge is considered to be more + recent. + + o Else, if the LS age fields of the two instances differ by + more than MaxAgeDiff, the instance having the smaller (younger) + LS age is considered to be more recent. + + o Else, the two instances are considered to be identical. + + + + + + + + + + + + + + + +Moy Standards Track [Page 126] + +RFC 2178 OSPF Version 2 July 1997 + + +13.2. Installing LSAs in the database + + Installing a new LSA in the database, either as the result of + flooding or a newly self-originated LSA, may cause the OSPF routing + table structure to be recalculated. The contents of the new LSA + should be compared to the old instance, if present. If there is no + difference, there is no need to recalculate the routing table. When + comparing an LSA to its previous instance, the following are all + considered to be differences in contents: + + o The LSA's Options field has changed. + + o One of the LSA instances has LS age set to MaxAge, and + the other does not. + + o The length field in the LSA header has changed. + + o The body of the LSA (i.e., anything outside the 20-byte + LSA header) has changed. Note that this excludes changes in LS + Sequence Number and LS Checksum. + + If the contents are different, the following pieces of the routing + table must be recalculated, depending on the new LSA's LS type field: + + Router-LSAs and network-LSAs + The entire routing table must be recalculated, starting with the + shortest path calculations for each area (not just the area whose + link-state database has changed). The reason that the shortest + path calculation cannot be restricted to the single changed area + has to do with the fact that AS boundary routers may belong to + multiple areas. A change in the area currently providing the best + route may force the router to use an intra-area route provided by + a different area.[19] + + Summary-LSAs + The best route to the destination described by the summary-LSA + must be recalculated (see Section 16.5). If this destination is + an AS boundary router, it may also be necessary to re-examine all + the AS-external-LSAs. + + AS-external-LSAs + The best route to the destination described by the AS-external-LSA + must be recalculated (see Section 16.6). + + Also, any old instance of the LSA must be removed from the + database when the new LSA is installed. This old instance must + also be removed from all neighbors' Link state retransmission + lists (see Section 10). + + + +Moy Standards Track [Page 127] + +RFC 2178 OSPF Version 2 July 1997 + + +13.3. Next step in the flooding procedure + + When a new (and more recent) LSA has been received, it must be + flooded out some set of the router's interfaces. This section + describes the second part of flooding procedure (the first part being + the processing that occurred in Section 13), namely, selecting the + outgoing interfaces and adding the LSA to the appropriate neighbors' + Link state retransmission lists. Also included in this part of the + flooding procedure is the maintenance of the neighbors' Link state + request lists. + + This section is equally applicable to the flooding of an LSA that the + router itself has just originated (see Section 12.4). + + For these LSAs, this section provides the entirety of the flooding + procedure (i.e., the processing of Section 13 is not performed, + since, for example, the LSA has not been received from a neighbor and + therefore does not need to be acknowledged). + + Depending upon the LSA's LS type, the LSA can be flooded out only + certain interfaces. These interfaces, defined by the following, are + called the eligible interfaces: + + AS-external-LSAs (LS Type = 5) + AS-external-LSAs are flooded throughout the entire AS, with the + exception of stub areas (see Section 3.6). The eligible + interfaces are all the router's interfaces, excluding virtual + links and those interfaces attaching to stub areas. + + All other LS types + All other types are specific to a single area (Area A). The + eligible interfaces are all those interfaces attaching to the Area + A. If Area A is the backbone, this includes all the virtual + links. + + Link state databases must remain synchronized over all adjacencies + associated with the above eligible interfaces. This is accomplished + by executing the following steps on each eligible interface. It + should be noted that this procedure may decide not to flood an LSA + out a particular interface, if there is a high probability that the + attached neighbors have already received the LSA. However, in these + cases the flooding procedure must be absolutely sure that the + neighbors eventually do receive the LSA, so the LSA is still added to + each adjacency's Link state retransmission list. For each eligible + interface: + + + + + + +Moy Standards Track [Page 128] + +RFC 2178 OSPF Version 2 July 1997 + + + (1) Each of the neighbors attached to this interface are + examined, to determine whether they must receive the new + LSA. The following steps are executed for each neighbor: + + (a) If the neighbor is in a lesser state than Exchange, it + does not participate in flooding, and the next neighbor + should be examined. + + (b) Else, if the adjacency is not yet full (neighbor state + is Exchange or Loading), examine the Link state request + list associated with this adjacency. If there is an + instance of the new LSA on the list, it indicates that + the neighboring router has an instance of the LSA + already. Compare the new LSA to the neighbor's copy: + + o If the new LSA is less recent, then examine the next + neighbor. + + o If the two copies are the same instance, then delete + the LSA from the Link state request list, and + examine the next neighbor.[20] + + o Else, the new LSA is more recent. Delete the LSA + from the Link state request list. + + (c) If the new LSA was received from this neighbor, examine + the next neighbor. + + (d) At this point we are not positive that the neighbor has + an up-to-date instance of this new LSA. Add the new LSA + to the Link state retransmission list for the adjacency. + This ensures that the flooding procedure is reliable; + the LSA will be retransmitted at intervals until an + acknowledgment is seen from the neighbor. + + (2) The router must now decide whether to flood the new LSA out + this interface. If in the previous step, the LSA was NOT + added to any of the Link state retransmission lists, there + is no need to flood the LSA out the interface and the next + interface should be examined. + + (3) If the new LSA was received on this interface, and it was + received from either the Designated Router or the Backup + Designated Router, chances are that all the neighbors have + received the LSA already. Therefore, examine the next + interface. + + + + + +Moy Standards Track [Page 129] + +RFC 2178 OSPF Version 2 July 1997 + + + (4) If the new LSA was received on this interface, and the + interface state is Backup (i.e., the router itself is the + Backup Designated Router), examine the next interface. The + Designated Router will do the flooding on this interface. + However, if the Designated Router fails the router (i.e., + the Backup Designated Router) will end up retransmitting the + updates. + + (5) If this step is reached, the LSA must be flooded out the + interface. Send a Link State Update packet (including the + new LSA as contents) out the interface. The LSA's LS age + must be incremented by InfTransDelay (which must be > 0) + when it is copied into the outgoing Link State Update packet + (until the LS age field reaches the maximum value of + MaxAge). + + On broadcast networks, the Link State Update packets are + multicast. The destination IP address specified for the + Link State Update Packet depends on the state of the + interface. If the interface state is DR or Backup, the + address AllSPFRouters should be used. Otherwise, the + address AllDRouters should be used. + + On non-broadcast networks, separate Link State Update + packets must be sent, as unicasts, to each adjacent neighbor + (i.e., those in state Exchange or greater). The destination + IP addresses for these packets are the neighbors' IP + addresses. + +13.4. Receiving self-originated LSAs + + It is a common occurrence for a router to receive self-originated + LSAs via the flooding procedure. A self-originated LSA is detected + when either 1) the LSA's Advertising Router is equal to the router's + own Router ID or 2) the LSA is a network-LSA and its Link State ID is + equal to one of the router's own IP interface addresses. + + However, if the received self-originated LSA is newer than the last + instance that the router actually originated, the router must take + special action. The reception of such an LSA indicates that there + are LSAs in the routing domain that were originated by the router + before the last time it was restarted. In most cases, the router + must then advance the LSA's LS sequence number one past the received + LS sequence number, and originate a new instance of the LSA. + + It may be the case the router no longer wishes to originate the + received LSA. Possible examples include: 1) the LSA is a summary-LSA + or AS-external-LSA and the router no longer has an (advertisable) + + + +Moy Standards Track [Page 130] + +RFC 2178 OSPF Version 2 July 1997 + + + route to the destination, 2) the LSA is a network-LSA but the router + is no longer Designated Router for the network or 3) the LSA is a + network-LSA whose Link State ID is one of the router's own IP + interface addresses but whose Advertising Router is not equal to the + router's own Router ID (this latter case should be rare, and it + indicates that the router's Router ID has changed since originating + the LSA). In all these cases, instead of updating the LSA, the LSA + should be flushed from the routing domain by incrementing the + received LSA's LS age to MaxAge and reflooding (see Section 14.1). + +13.5. Sending Link State Acknowledgment packets + + Each newly received LSA must be acknowledged. This is usually done + by sending Link State Acknowledgment packets. However, + acknowledgments can also be accomplished implicitly by sending Link + State Update packets (see step 7a of Section 13). + + Many acknowledgments may be grouped together into a single Link State + Acknowledgment packet. Such a packet is sent back out the interface + which received the LSAs. The packet can be sent in one of two ways: + delayed and sent on an interval timer, or sent directly (as a + unicast) to a particular neighbor. The particular acknowledgment + strategy used depends on the circumstances surrounding the receipt of + the LSA. + + Sending delayed acknowledgments accomplishes several things: 1) it + facilitates the packaging of multiple acknowledgments in a single + Link State Acknowledgment packet, 2) it enables a single Link State + Acknowledgment packet to indicate acknowledgments to several + neighbors at once (through multicasting) and 3) it randomizes the + Link State Acknowledgment packets sent by the various routers + attached to a common network. The fixed interval between a router's + delayed transmissions must be short (less than RxmtInterval) or + needless retransmissions will ensue. + + Direct acknowledgments are sent to a particular neighbor in response + to the receipt of duplicate LSAs. These acknowledgments are sent as + unicasts, and are sent immediately when the duplicate is received. + + The precise procedure for sending Link State Acknowledgment packets + is described in Table 19. The circumstances surrounding the receipt + of the LSA are listed in the left column. The acknowledgment action + then taken is listed in one of the two right columns. This action + depends on the state of the concerned interface; interfaces in state + Backup behave differently from interfaces in all other states. + Delayed acknowledgments must be delivered to all adjacent routers + associated with the interface. On broadcast networks, this is + accomplished by sending the delayed Link State Acknowledgment packets + + + +Moy Standards Track [Page 131] + +RFC 2178 OSPF Version 2 July 1997 + + + as multicasts. The Destination IP address used depends on the state + of the interface. If the interface state is DR or Backup, the + destination AllSPFRouters is used. In all other states, the + destination AllDRouters is used. On non-broadcast networks, delayed + Link State Acknowledgment packets must be unicast separately over + each adjacency (i.e., neighbor whose state is >= Exchange). + + Action taken in state + Circumstances Backup All other states + _______________________________________________________________ + LSA has No acknowledgment No acknowledgment + been flooded back sent. sent. + out receiving in- + terface (see Sec- + tion 13, step 5b). + _______________________________________________________________ + LSA is Delayed acknowledg- Delayed ack- + more recent than ment sent if adver- nowledgment sent. + database copy, but tisement received + was not flooded from Designated + back out receiving Router, otherwise + interface do nothing + _______________________________________________________________ + LSA is a Delayed acknowledg- No acknowledgment + duplicate, and was ment sent if adver- sent. + treated as an im- tisement received + plied acknowledg- from Designated + ment (see Section Router, otherwise + 13, step 7a). do nothing + _______________________________________________________________ + LSA is a Direct acknowledg- Direct acknowledg- + duplicate, and was ment sent. ment sent. + not treated as an + implied ack- + nowledgment. + _______________________________________________________________ + LSA's LS Direct acknowledg- Direct acknowledg- + age is equal to ment sent. ment sent. + MaxAge, and there is + no current instance + of the LSA + in the link state + database (see + Section 13, step 4). + + + Table 19: Sending link state acknowledgments. + + + + +Moy Standards Track [Page 132] + +RFC 2178 OSPF Version 2 July 1997 + + + The reasoning behind sending the above packets as multicasts is best + explained by an example. Consider the network configuration depicted + in Figure 15. Suppose RT4 has been elected as Designated Router, and + RT3 as Backup Designated Router for the network N3. When Router RT4 + floods a new LSA to Network N3, it is received by routers RT1, RT2, + and RT3. These routers will not flood the LSA back onto net N3, but + they still must ensure that their link-state databases remain + synchronized with their adjacent neighbors. So RT1, RT2, and RT4 are + waiting to see an acknowledgment from RT3. Likewise, RT4 and RT3 are + both waiting to see acknowledgments from RT1 and RT2. This is best + achieved by sending the acknowledgments as multicasts. + + The reason that the acknowledgment logic for Backup DRs is slightly + different is because they perform differently during the flooding of + LSAs (see Section 13.3, step 4). + + +13.6. Retransmitting LSAs + + LSAs flooded out an adjacency are placed on the adjacency's Link + state retransmission list. In order to ensure that flooding is + reliable, these LSAs are retransmitted until they are acknowledged. + The length of time between retransmissions is a configurable per- + interface value, RxmtInterval. If this is set too low for an + interface, needless retransmissions will ensue. If the value is set + too high, the speed of the flooding, in the face of lost packets, may + be affected. + + Several retransmitted LSAs may fit into a single Link State Update + packet. When LSAs are to be retransmitted, only the number fitting + in a single Link State Update packet should be sent. Another packet + of retransmissions can be sent whenever some of the LSAs are + acknowledged, or on the next firing of the retransmission timer. + + Link State Update Packets carrying retransmissions are always sent as + unicasts (directly to the physical address of the neighbor). They + are never sent as multicasts. Each LSA's LS age must be incremented + by InfTransDelay (which must be > 0) when it is copied into the + outgoing Link State Update packet (until the LS age field reaches the + maximum value of MaxAge). + + If an adjacent router goes down, retransmissions may occur until the + adjacency is destroyed by OSPF's Hello Protocol. When the adjacency + is destroyed, the Link state retransmission list is cleared. + + + + + + + +Moy Standards Track [Page 133] + +RFC 2178 OSPF Version 2 July 1997 + + +13.7. Receiving link state acknowledgments + + Many consistency checks have been made on a received Link State + Acknowledgment packet before it is handed to the flooding procedure. + In particular, it has been associated with a particular neighbor. If + this neighbor is in a lesser state than Exchange, the Link State + Acknowledgment packet is discarded. + + Otherwise, for each acknowledgment in the Link State Acknowledgment + packet, the following steps are performed: + + + o Does the LSA acknowledged have an instance on the Link state + retransmission list for the neighbor? If not, examine the + next acknowledgment. Otherwise: + + o If the acknowledgment is for the same instance that is + contained on the list, remove the item from the list and + examine the next acknowledgment. Otherwise: + + o Log the questionable acknowledgment, and examine the next + one. + +14. Aging The Link State Database + + Each LSA has an LS age field. The LS age is expressed in seconds. + An LSA's LS age field is incremented while it is contained in a + router's database. Also, when copied into a Link State Update Packet + for flooding out a particular interface, the LSA's LS age is + incremented by InfTransDelay. + + An LSA's LS age is never incremented past the value MaxAge. LSAs + having age MaxAge are not used in the routing table calculation. As + a router ages its link state database, an LSA's LS age may reach + MaxAge.[21] At this time, the router must attempt to flush the LSA + from the routing domain. This is done simply by reflooding the + MaxAge LSA just as if it was a newly originated LSA (see Section + 13.3). + + When creating a Database summary list for a newly forming adjacency, + any MaxAge LSAs present in the link state database are added to the + neighbor's Link state retransmission list instead of the neighbor's + Database summary list. See Section 10.3 for more details. + + A MaxAge LSA must be removed immediately from the router's link state + database as soon as both a) it is no longer contained on any neighbor + Link state retransmission lists and b) none of the router's neighbors + are in states Exchange or Loading. + + + +Moy Standards Track [Page 134] + +RFC 2178 OSPF Version 2 July 1997 + + + When, in the process of aging the link state database, an LSA's LS + age hits a multiple of CheckAge, its LS checksum should be verified. + If the LS checksum is incorrect, a program or memory error has been + detected, and at the very least the router itself should be + restarted. + +14.1. Premature aging of LSAs + + An LSA can be flushed from the routing domain by setting its LS age + to MaxAge and reflooding the LSA. This procedure follows the same + course as flushing an LSA whose LS age has naturally reached the + value MaxAge (see Section 14). In particular, the MaxAge LSA is + removed from the router's link state database as soon as a) it is no + longer contained on any neighbor Link state retransmission lists and + b) none of the router's neighbors are in states Exchange or Loading. + We call the setting of an LSA's LS age to MaxAge "premature aging". + + Premature aging is used when it is time for a self-originated LSA's + sequence number field to wrap. At this point, the current LSA + instance (having LS sequence number MaxSequenceNumber) must be + prematurely aged and flushed from the routing domain before a new + instance with sequence number equal to InitialSequenceNumber can be + originated. See Section 12.1.6 for more information. + + Premature aging can also be used when, for example, one of the + router's previously advertised external routes is no longer + reachable. In this circumstance, the router can flush its AS- + external-LSA from the routing domain via premature aging. This + procedure is preferable to the alternative, which is to originate a + new LSA for the destination specifying a metric of LSInfinity. + Premature aging is also be used when unexpectedly receiving self- + originated LSAs during the flooding procedure (see Section 13.4). + + A router may only prematurely age its own self-originated LSAs. The + router may not prematurely age LSAs that have been originated by + other routers. An LSA is considered self- originated when either 1) + the LSA's Advertising Router is equal to the router's own Router ID + or 2) the LSA is a network-LSA and its Link State ID is equal to one + of the router's own IP interface addresses. + +15. Virtual Links + + The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, + or some areas of the Autonomous System will become unreachable. To + establish/maintain connectivity of the backbone, virtual links can be + configured through non-backbone areas. Virtual links serve to + connect physically separate components of the backbone. The two + endpoints of a virtual link are area border routers. The virtual + + + +Moy Standards Track [Page 135] + +RFC 2178 OSPF Version 2 July 1997 + + + link must be configured in both routers. The configuration + information in each router consists of the other virtual endpoint + (the other area border router), and the non-backbone area the two + routers have in common (called the Transit area). Virtual links + cannot be configured through stub areas (see Section 3.6). + + The virtual link is treated as if it were an unnumbered point-to- + point network belonging to the backbone and joining the two area + border routers. An attempt is made to establish an adjacency over + the virtual link. When this adjacency is established, the virtual + link will be included in backbone router-LSAs, and OSPF packets + pertaining to the backbone area will flow over the adjacency. Such + an adjacency has been referred to in this document as a "virtual + adjacency". + + In each endpoint router, the cost and viability of the virtual link + is discovered by examining the routing table entry for the other + endpoint router. (The entry's associated area must be the configured + Transit area). This is called the virtual link's corresponding + routing table entry. The InterfaceUp event occurs for a virtual link + when its corresponding routing table entry becomes reachable. + Conversely, the InterfaceDown event occurs when its routing table + entry becomes unreachable. In other words, the virtual link's + viability is determined by the existence of an intra-area path, + through the Transit area, between the two endpoints. Note that a + virtual link whose underlying path has cost greater than hexadecimal + 0xffff (the maximum size of an interface cost in a router-LSA) should + be considered inoperational (i.e., treated the same as if the path + did not exist). + + The other details concerning virtual links are as follows: + + o AS-external-LSAs are NEVER flooded over virtual adjacencies. This + would be duplication of effort, since the same AS-external-LSAs are + already flooded throughout the virtual link's Transit area. For this + same reason, AS-external-LSAs are not summarized over virtual + adjacencies during the Database Exchange process. + + o The cost of a virtual link is NOT configured. It is defined to be + the cost of the intra-area path between the two defining area border + routers. This cost appears in the virtual link's corresponding + routing table entry. When the cost of a virtual link changes, a new + router-LSA should be originated for the backbone area. + + o Just as the virtual link's cost and viability are determined by the + routing table build process (through construction of the routing + table entry for the other endpoint), so are the IP interface address + for the virtual interface and the virtual neighbor's IP address. + + + +Moy Standards Track [Page 136] + +RFC 2178 OSPF Version 2 July 1997 + + + These are used when sending OSPF protocol packets over the virtual + link. Note that when one (or both) of the virtual link endpoints + connect to the Transit area via an unnumbered point-to-point link, it + may be impossible to calculate either the virtual interface's IP + address and/or the virtual neighbor's IP address, thereby causing the + virtual link to fail. + + o In each endpoint's router-LSA for the backbone, the virtual link is + represented as a Type 4 link whose Link ID is set to the virtual + neighbor's OSPF Router ID and whose Link Data is set to the virtual + interface's IP address. See Section 12.4.1 for more information. + + o A non-backbone area can carry transit data traffic (i.e., is + considered a "transit area") if and only if it serves as the Transit + area for one or more fully adjacent virtual links (see + TransitCapability in Sections 6 and 16.1). Such an area requires + special treatment when summarizing backbone networks into it (see + Section 12.4.3), and during the routing calculation (see Section + 16.3). + + o The time between link state retransmissions, RxmtInterval, is + configured for a virtual link. This should be well over the expected + round-trip delay between the two routers. This may be hard to + estimate for a virtual link; it is better to err on the side of + making it too large. + +16. Calculation of the routing table + + This section details the OSPF routing table calculation. Using its + attached areas' link state databases as input, a router runs the + following algorithm, building its routing table step by step. At + each step, the router must access individual pieces of the link state + databases (e.g., a router-LSA originated by a certain router). This + access is performed by the lookup function discussed in Section 12.2. + The lookup process may return an LSA whose LS age is equal to MaxAge. + Such an LSA should not be used in the routing table calculation, and + is treated just as if the lookup process had failed. + + The OSPF routing table's organization is explained in Section 11. + Two examples of the routing table build process are presented in + Sections 11.2 and 11.3. This process can be broken into the + following steps: + + (1) The present routing table is invalidated. The routing table is + built again from scratch. The old routing table is saved so + that changes in routing table entries can be identified. + + + + + +Moy Standards Track [Page 137] + +RFC 2178 OSPF Version 2 July 1997 + + + (2) The intra-area routes are calculated by building the shortest- + path tree for each attached area. In particular, all routing + table entries whose Destination Type is "area border router" are + calculated in this step. This step is described in two parts. + At first the tree is constructed by only considering those links + between routers and transit networks. Then the stub networks + are incorporated into the tree. During the area's shortest-path + tree calculation, the area's TransitCapability is also + calculated for later use in Step 4. + + (3) The inter-area routes are calculated, through examination of + summary-LSAs. If the router is attached to multiple areas + (i.e., it is an area border router), only backbone summary-LSAs + are examined. + + (4) In area border routers connecting to one or more transit areas + (i.e, non-backbone areas whose TransitCapability is found to be + TRUE), the transit areas' summary-LSAs are examined to see + whether better paths exist using the transit areas than were + found in Steps 2-3 above. + + (5) Routes to external destinations are calculated, through + examination of AS-external-LSAs. The locations of the AS + boundary routers (which originate the AS-external-LSAs) have + been determined in steps 2-4. + + Steps 2-5 are explained in further detail below. + + Changes made to routing table entries as a result of these + calculations can cause the OSPF protocol to take further actions. + For example, a change to an intra-area route will cause an area + border router to originate new summary-LSAs (see Section 12.4). See + + Section 16.7 for a complete list of the OSPF protocol actions + resulting from routing table changes. + +16.1. Calculating the shortest-path tree for an area + + This calculation yields the set of intra-area routes associated with + an area (called hereafter Area A). A router calculates the + shortest-path tree using itself as the root.[22] The formation of the + shortest path tree is done here in two stages. In the first stage, + only links between routers and transit networks are considered. + Using the Dijkstra algorithm, a tree is formed from this subset of + the link state database. In the second stage, leaves are added to + the tree by considering the links to stub networks. + + + + + +Moy Standards Track [Page 138] + +RFC 2178 OSPF Version 2 July 1997 + + + The procedure will be explained using the graph terminology that was + introduced in Section 2. The area's link state database is + represented as a directed graph. The graph's vertices are routers, + transit networks and stub networks. The first stage of the procedure + concerns only the transit vertices (routers and transit networks) and + their connecting links. Throughout the shortest path calculation, + the following data is also associated with each transit vertex: + + + Vertex (node) ID + A 32-bit number uniquely identifying the vertex. For router + vertices this is the router's OSPF Router ID. For network + vertices, this is the IP address of the network's Designated + Router. + + An LSA + Each transit vertex has an associated LSA. For router + vertices, this is a router-LSA. For transit networks, this + is a network-LSA (which is actually originated by the + network's Designated Router). In any case, the LSA's Link + State ID is always equal to the above Vertex ID. + + List of next hops + The list of next hops for the current set of shortest paths + from the root to this vertex. There can be multiple + shortest paths due to the equal-cost multipath capability. + Each next hop indicates the outgoing router interface to use + when forwarding traffic to the destination. On broadcast, + Point-to-MultiPoint and NBMA networks, the next hop also + includes the IP address of the next router (if any) in the + path towards the destination. + + Distance from root + The link state cost of the current set of shortest paths + from the root to the vertex. The link state cost of a path + is calculated as the sum of the costs of the path's + constituent links (as advertised in router-LSAs and + network-LSAs). One path is said to be "shorter" than + another if it has a smaller link state cost. + + + The first stage of the procedure (i.e., the Dijkstra algorithm) can + now be summarized as follows. At each iteration of the algorithm, + there is a list of candidate vertices. Paths from the root to these + vertices have been found, but not necessarily the shortest ones. + However, the paths to the candidate vertex that is closest to the + root are guaranteed to be shortest; this vertex is added to the + shortest-path tree, removed from the candidate list, and its adjacent + + + +Moy Standards Track [Page 139] + +RFC 2178 OSPF Version 2 July 1997 + + + vertices are examined for possible addition to/modification of the + candidate list. The algorithm then iterates again. It terminates + when the candidate list becomes empty. + + The following steps describe the algorithm in detail. Remember that + we are computing the shortest path tree for Area A. All references + to link state database lookup below are from Area A's database. + + (1) Initialize the algorithm's data structures. Clear the list + of candidate vertices. Initialize the shortest-path tree to + only the root (which is the router doing the calculation). + Set Area A's TransitCapability to FALSE. + + (2) Call the vertex just added to the tree vertex V. Examine + the LSA associated with vertex V. This is a lookup in the + Area A's link state database based on the Vertex ID. If + this is a router-LSA, and bit V of the router-LSA (see + Section A.4.2) is set, set Area A's TransitCapability to + TRUE. In any case, each link described by the LSA gives the + cost to an adjacent vertex. For each described link, (say + it joins vertex V to vertex W): + + (a) If this is a link to a stub network, examine the next + link in V's LSA. Links to stub networks will be + considered in the second stage of the shortest path + calculation. + + (b) Otherwise, W is a transit vertex (router or transit + network). Look up the vertex W's LSA (router-LSA or + network-LSA) in Area A's link state database. If the + LSA does not exist, or its LS age is equal to MaxAge, or + it does not have a link back to vertex V, examine the + next link in V's LSA.[23] + + (c) If vertex W is already on the shortest-path tree, + examine the next link in the LSA. + + (d) Calculate the link state cost D of the resulting path + from the root to vertex W. D is equal to the sum of the + link state cost of the (already calculated) shortest + path to vertex V and the advertised cost of the link + between vertices V and W. If D is: + + o Greater than the value that already appears for + vertex W on the candidate list, then examine the + next link. + + + + + +Moy Standards Track [Page 140] + +RFC 2178 OSPF Version 2 July 1997 + + + o Equal to the value that appears for vertex W on the + candidate list, calculate the set of next hops that + result from using the advertised link. Input to + this calculation is the destination (W), and its + parent (V). This calculation is shown in Section + 16.1.1. This set of hops should be added to the + next hop values that appear for W on the candidate + list. + + o Less than the value that appears for vertex W on the + candidate list, or if W does not yet appear on the + candidate list, then set the entry for W on the + candidate list to indicate a distance of D from the + root. Also calculate the list of next hops that + result from using the advertised link, setting the + next hop values for W accordingly. The next hop + calculation is described in Section 16.1.1; it takes + as input the destination (W) and its parent (V). + + (3) If at this step the candidate list is empty, the shortest- + path tree (of transit vertices) has been completely built + and this stage of the procedure terminates. Otherwise, + choose the vertex belonging to the candidate list that is + closest to the root, and add it to the shortest-path tree + (removing it from the candidate list in the process). Note + that when there is a choice of vertices closest to the root, + network vertices must be chosen before router vertices in + order to necessarily find all equal-cost paths. This is + consistent with the tie-breakers that were introduced in the + modified Dijkstra algorithm used by OSPF's Multicast routing + extensions (MOSPF). + + (4) Possibly modify the routing table. For those routing table + entries modified, the associated area will be set to Area A, + the path type will be set to intra-area, and the cost will + be set to the newly discovered shortest path's calculated + distance. + + If the newly added vertex is an area border router or AS + boundary router, a routing table entry is added whose + destination type is "router". The Options field found in + the associated router-LSA is copied into the routing table + entry's Optional capabilities field. Call the newly added + vertex Router X. If Router X is the endpoint of one of the + calculating router's virtual links, and the virtual link + uses Area A as Transit area: the virtual link is declared + up, the IP address of the virtual interface is set to the IP + address of the outgoing interface calculated above for + + + +Moy Standards Track [Page 141] + +RFC 2178 OSPF Version 2 July 1997 + + + Router X, and the virtual neighbor's IP address is set to + Router X's interface address (contained in Router X's + router-LSA) that points back to the root of the shortest- + path tree; equivalently, this is the interface that points + back to Router X's parent vertex on the shortest-path tree + (similar to the calculation in Section 16.1.1). + + If the newly added vertex is a transit network, the routing + table entry for the network is located. The entry's + Destination ID is the IP network number, which can be + obtained by masking the Vertex ID (Link State ID) with its + associated subnet mask (found in the body of the associated + network-LSA). If the routing table entry already exists + (i.e., there is already an intra-area route to the + destination installed in the routing table), multiple + vertices have mapped to the same IP network. For example, + this can occur when a new Designated Router is being + established. In this case, the current routing table entry + should be overwritten if and only if the newly found path is + just as short and the current routing table entry's Link + State Origin has a smaller Link State ID than the newly + added vertex' LSA. + + If there is no routing table entry for the network (the + usual case), a routing table entry for the IP network should + be added. The routing table entry's Link State Origin + should be set to the newly added vertex' LSA. + + (5) Iterate the algorithm by returning to Step 2. + + The stub networks are added to the tree in the procedure's second + stage. In this stage, all router vertices are again examined. Those + that have been determined to be unreachable in the above first phase + are discarded. For each reachable router vertex (call it V), the + associated router-LSA is found in the link state database. Each stub + network link appearing in the LSA is then examined, and the following + steps are executed: + + + (1) Calculate the distance D of stub network from the root. D + is equal to the distance from the root to the router vertex + (calculated in stage 1), plus the stub network link's + advertised cost. Compare this distance to the current best + cost to the stub network. This is done by looking up the + stub network's current routing table entry. If the + calculated distance D is larger, go on to examine the next + stub network link in the LSA. + + + + +Moy Standards Track [Page 142] + +RFC 2178 OSPF Version 2 July 1997 + + + (2) If this step is reached, the stub network's routing table + entry must be updated. Calculate the set of next hops that + would result from using the stub network link. This + calculation is shown in Section 16.1.1; input to this + calculation is the destination (the stub network) and the + parent vertex (the router vertex). If the distance D is the + same as the current routing table cost, simply add this set + of next hops to the routing table entry's list of next hops. + In this case, the routing table already has a Link State + Origin. If this Link State Origin is a router-LSA whose + Link State ID is smaller than V's Router ID, reset the Link + State Origin to V's router-LSA. + + Otherwise D is smaller than the routing table cost. + Overwrite the current routing table entry by setting the + routing table entry's cost to D, and by setting the entry's + list of next hops to the newly calculated set. Set the + routing table entry's Link State Origin to V's router-LSA. + Then go on to examine the next stub network link. + + For all routing table entries added/modified in the second stage, the + associated area will be set to Area A and the path type will be set to + intra-area. When the list of reachable router-LSAs is exhausted, the + second stage is completed. At this time, all intra-area routes + associated with Area A have been determined. + + The specification does not require that the above two stage method be + used to calculate the shortest path tree. However, if another + algorithm is used, an identical tree must be produced. For this + reason, it is important to note that links between transit vertices + must be bidirectional in order to be included in the above tree. It + should also be mentioned that more efficient algorithms exist for + calculating the tree; for example, the incremental SPF algorithm + described in [Ref1]. + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 143] + +RFC 2178 OSPF Version 2 July 1997 + + +16.1.1. The next hop calculation + + This section explains how to calculate the current set of next hops + to use for a destination. Each next hop consists of the outgoing + interface to use in forwarding packets to the destination together + with the IP address of the next hop router (if any). The next hop + calculation is invoked each time a shorter path to the destination is + discovered. This can happen in either stage of the shortest-path + tree calculation (see Section 16.1). In stage 1 of the shortest-path + tree calculation a shorter path is found as the destination is added + to the candidate list, or when the destination's entry on the + candidate list is modified (Step 2d of Stage 1). In stage 2 a + shorter path is discovered each time the destination's routing table + entry is modified (Step 2 of Stage 2). + + The set of next hops to use for the destination may be recalculated + several times during the shortest-path tree calculation, as shorter + and shorter paths are discovered. In the end, the destination's + routing table entry will always reflect the next hops resulting from + the absolute shortest path(s). + + Input to the next hop calculation is a) the destination and b) its + parent in the current shortest path between the root (the calculating + router) and the destination. The parent is always a transit vertex + (i.e., always a router or a transit network). + + If there is at least one intervening router in the current shortest + path between the destination and the root, the destination simply + inherits the set of next hops from the parent. Otherwise, there are + two cases. In the first case, the parent vertex is the root (the + calculating router itself). This means that the destination is + either a directly connected network or directly connected router. + The outgoing interface in this case is simply the OSPF interface + connecting to the destination network/router. If the destination is a + router which connects to the calculating router via a Point-to- + MultiPoint network, the destination's next hop IP address(es) can be + determined by examining the destination's router-LSA: each link + pointing back to the calculating router and having a Link Data field + belonging to the Point-to-MultiPoint network provides an IP address + of the next hop router. If the destination is a directly connected + network, or a router which connects to the calculating router via a + point-to-point interface, no next hop IP address is required. If the + destination is a router connected to the calculating router via a + virtual link, the setting of the next hop should be deferred until + the calculation in Section 16.3. + + + + + + +Moy Standards Track [Page 144] + +RFC 2178 OSPF Version 2 July 1997 + + + In the second case, the parent vertex is a network that directly + connects the calculating router to the destination router. The list + of next hops is then determined by examining the destination's + router-LSA. For each link in the router-LSA that points back to the + parent network, the link's Link Data field provides the IP address of + a next hop router. The outgoing interface to use can then be derived + from the next hop IP address (or it can be inherited from the parent + network). + +16.2. Calculating the inter-area routes + + The inter-area routes are calculated by examining summary-LSAs. If + the router has active attachments to multiple areas, only backbone + summary-LSAs are examined. Routers attached to a single area examine + that area's summary-LSAs. In either case, the summary-LSAs examined + below are all part of a single area's link state database (call it + Area A). + + Summary-LSAs are originated by the area border routers. Each + summary-LSA in Area A is considered in turn. Remember that the + destination described by a summary-LSA is either a network (Type 3 + summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). For + each summary-LSA: + + + (1) If the cost specified by the LSA is LSInfinity, or if the + LSA's LS age is equal to MaxAge, then examine the the next + LSA. + + (2) If the LSA was originated by the calculating router itself, + examine the next LSA. + + (3) If it is a Type 3 summary-LSA, and the collection of + destinations described by the summary-LSA equals one of the + router's configured area address ranges (see Section 3.5), + and the particular area address range is active, then the + summary-LSA should be ignored. "Active" means that there + are one or more reachable (by intra-area paths) networks + contained in the area range. + + (4) Else, call the destination described by the LSA N (for Type + 3 summary-LSAs, N's address is obtained by masking the LSA's + Link State ID with the network/subnet mask contained in the + body of the LSA), and the area border originating the LSA + BR. Look up the routing table entry for BR having Area A as + its associated area. If no such entry exists for router BR + (i.e., BR is unreachable in Area A), do nothing with this + LSA and consider the next in the list. Else, this LSA + + + +Moy Standards Track [Page 145] + +RFC 2178 OSPF Version 2 July 1997 + + + describes an inter-area path to destination N, whose cost is + the distance to BR plus the cost specified in the LSA. Call + the cost of this inter-area path IAC. + + (5) Next, look up the routing table entry for the destination N. + (If N is an AS boundary router, look up the "router" routing + table entry associated with Area A). If no entry exists for + N or if the entry's path type is "type 1 external" or "type + 2 external", then install the inter-area path to N, with + associated area Area A, cost IAC, next hop equal to the list + of next hops to router BR, and Advertising router equal to + BR. + + (6) Else, if the paths present in the table are intra-area + paths, do nothing with the LSA (intra-area paths are always + preferred). + + (7) Else, the paths present in the routing table are also + inter-area paths. Install the new path through BR if it is + cheaper, overriding the paths in the routing table. + Otherwise, if the new path is the same cost, add it to the + list of paths that appear in the routing table entry. + +16.3. Examining transit areas' summary-LSAs + + This step is only performed by area border routers attached to one or + more non-backbone areas that are capable of carrying transit traffic + (i.e., "transit areas", or those areas whose TransitCapability + parameter has been set to TRUE in Step 2 of the Dijkstra algorithm + (see Section 16.1). + + The purpose of the calculation below is to examine the transit areas + to see whether they provide any better (shorter) paths than the paths + previously calculated in Sections 16.1 and 16.2. Any paths found + that are better than or equal to previously discovered paths are + installed in the routing table. + + The calculation proceeds as follows. All the transit areas' summary- + LSAs are examined in turn. Each such summary-LSA describes a route + through a transit area Area A to a Network N (N's address is obtained + by masking the LSA's Link State ID with the network/subnet mask + contained in the body of the LSA) or in the case of a Type 4 + summary-LSA, to an AS boundary router N. Suppose also that the + summary-LSA was originated by an area border router BR. + + (1) If the cost advertised by the summary-LSA is LSInfinity, or + if the LSA's LS age is equal to MaxAge, then examine the + next LSA. + + + +Moy Standards Track [Page 146] + +RFC 2178 OSPF Version 2 July 1997 + + + (2) If the summary-LSA was originated by the calculating router + itself, examine the next LSA. + + (3) Look up the routing table entry for N. (If N is an AS + boundary router, look up the "router" routing table entry + associated with the backbone area). If it does not exist, or + if the route type is other than intra-area or inter-area, or + if the area associated with the routing table entry is not + the backbone area, then examine the next LSA. In other + words, this calculation only updates backbone intra-area + routes found in Section 16.1 and inter-area routes found in + Section 16.2. + + (4) Look up the routing table entry for the advertising router + BR associated with the Area A. If it is unreachable, examine + the next LSA. Otherwise, the cost to destination N is the + sum of the cost in BR's Area A routing table entry and the + cost advertised in the LSA. Call this cost IAC. + + (5) If this cost is less than the cost occurring in N's routing + table entry, overwrite N's list of next hops with those used + for BR, and set N's routing table cost to IAC. Else, if IAC + is the same as N's current cost, add BR's list of next hops + to N's list of next hops. In any case, the area associated + with N's routing table entry must remain the backbone area, + and the path type (either intra-area or inter-area) must + also remain the same. + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 147] + +RFC 2178 OSPF Version 2 July 1997 + + + . Area 1 (transit) . + + . . | + . +---+1 1+---+100 | + . |RT2|----------|RT4|=========| + . 1/+---+********* +---+ | + . /******* . | + . 1/*Virtual . | + 1+---+/* Link . Net|work + =======|RT1|* . | N1 + +---+\ . | + . \ . | + . \ . | + . 1\+---+1 1+---+20 | + . |RT3|----------|RT5|=========| + . +---+ +---+ | + . . | + ........................ + + + + Figure 17: Routing through transit areas + + It is important to note that the above calculation never makes + unreachable destinations reachable, but instead just potentially + finds better paths to already reachable destinations. The + calculation installs any better cost found into the routing table + entry, from which it may be readvertised in summary-LSAs to other + areas. + + As an example of the calculation, consider the Autonomous System + pictured in Figure 17. There is a single non-backbone area (Area 1) + that physically divides the backbone into two separate pieces. To + maintain connectivity of the backbone, a virtual link has been + configured between routers RT1 and RT4. On the right side of the + figure, Network N1 belongs to the backbone. The dotted lines indicate + that there is a much shorter intra-area backbone path between router + RT5 and Network N1 (cost 20) than there is between Router RT4 and + Network N1 (cost 100). Both Router RT4 and Router RT5 will inject + summary-LSAs for Network N1 into Area 1. + + After the shortest-path tree has been calculated for the backbone in + Section 16.1, Router RT1 (left end of the virtual link) will have + calculated a path through Router RT4 for all data traffic destined + for Network N1. However, since Router RT5 is so much closer to + Network N1, all routers internal to Area 1 (e.g., Routers RT2 and + RT3) will forward their Network N1 traffic towards Router RT5, + instead of RT4. And indeed, after examining Area 1's summary-LSAs by + the above calculation, Router RT1 will also forward Network N1 + traffic towards RT5. Note that in this example the virtual link + + + +Moy Standards Track [Page 148] + +RFC 2178 OSPF Version 2 July 1997 + + + enables transit data traffic to be forwarded through Area 1, but the + actual path the transit data traffic takes does not follow the + virtual link. In other words, virtual links allow transit traffic to + be forwarded through an area, but do not dictate the precise path + that the traffic will take. + +16.4. Calculating AS external routes + + AS external routes are calculated by examining AS-external-LSAs. + Each of the AS-external-LSAs is considered in turn. Most AS- + external-LSAs describe routes to specific IP destinations. An AS- + external-LSA can also describe a default route for the Autonomous + System (Destination ID = DefaultDestination, network/subnet mask = + 0x00000000). For each AS-external-LSA: + + (1) If the cost specified by the LSA is LSInfinity, or if the + LSA's LS age is equal to MaxAge, then examine the next LSA. + + (2) If the LSA was originated by the calculating router itself, + examine the next LSA. + + (3) Call the destination described by the LSA N. N's address is + obtained by masking the LSA's Link State ID with the + network/subnet mask contained in the body of the LSA. Look + up the routing table entries (potentially one per attached + area) for the AS boundary router (ASBR) that originated the + LSA. If no entries exist for router ASBR (i.e., ASBR is + unreachable), do nothing with this LSA and consider the next + in the list. + + Else, this LSA describes an AS external path to destination + N. Examine the forwarding address specified in the AS- + external-LSA. This indicates the IP address to which + packets for the destination should be forwarded. + + If the forwarding address is set to 0.0.0.0, packets should + be sent to the ASBR itself. Among the multiple routing table + entries for the ASBR, select the preferred entry as follows. + If RFC1583Compatibility is set to "disabled", prune the set + of routing table entries for the ASBR as described in + Section 16.4.1. In any case, among the remaining routing + table entries, select the routing table entry with the least + cost; when there are multiple least cost routing table + entries the entry whose associated area has the largest OSPF + Area ID (when considered as an unsigned 32-bit integer) is + chosen. + + + + + +Moy Standards Track [Page 149] + +RFC 2178 OSPF Version 2 July 1997 + + + If the forwarding address is non-zero, look up the + forwarding address in the routing table.[24] The matching + routing table entry must specify an intra-area or inter-area + path; if no such path exists, do nothing with the LSA and + consider the next in the list. + + (4) Let X be the cost specified by the preferred routing table + entry for the ASBR/forwarding address, and Y the cost + specified in the LSA. X is in terms of the link state + metric, and Y is a type 1 or 2 external metric. + + (5) Look up the routing table entry for the destination N. If + no entry exists for N, install the AS external path to N, + with next hop equal to the list of next hops to the + forwarding address, and advertising router equal to ASBR. + If the external metric type is 1, then the path-type is set + to type 1 external and the cost is equal to X+Y. If the + external metric type is 2, the path-type is set to type 2 + external, the link state component of the route's cost is X, + and the type 2 cost is Y. + + (6) Compare the AS external path described by the LSA with the + existing paths in N's routing table entry, as follows. If + the new path is preferred, it replaces the present paths in + N's routing table entry. If the new path is of equal + preference, it is added to N's routing table entry's list of + paths. + + (a) Intra-area and inter-area paths are always preferred + over AS external paths. + + (b) Type 1 external paths are always preferred over type 2 + external paths. When all paths are type 2 external + paths, the paths with the smallest advertised type 2 + metric are always preferred. + + (c) If the new AS external path is still indistinguishable + from the current paths in the N's routing table entry, + and RFC1583Compatibility is set to "disabled", select + the preferred paths based on the intra-AS paths to the + ASBR/forwarding addresses, as specified in Section + 16.4.1. + + + + + + + + + +Moy Standards Track [Page 150] + +RFC 2178 OSPF Version 2 July 1997 + + + (d) If the new AS external path is still indistinguishable + from the current paths in the N's routing table entry, + select the preferred path based on a least cost + comparison. Type 1 external paths are compared by + looking at the sum of the distance to the forwarding + address and the advertised type 1 metric (X+Y). Type 2 + external paths advertising equal type 2 metrics are + compared by looking at the distance to the forwarding + addresses. + +16.4.1. External path preferences + + When multiple intra-AS paths are available to ASBRs/forwarding + addresses, the following rules indicate which paths are preferred. + These rules apply when the same ASBR is reachable through multiple + areas, or when trying to decide which of several AS-external-LSAs + should be preferred. In the former case the paths all terminate at + the same ASBR, while in the latter the paths terminate at separate + ASBRs/forwarding addresses. In either case, each path is represented + by a separate routing table entry as defined in Section 11. + + This section only applies when RFC1583Compatibility is set to + "disabled". + + The path preference rules, stated from highest to lowest preference, + are as follows. Note that as a result of these rules, there may still + be multiple paths of the highest preference. In this case, the path + to use must be determined based on cost, as described in Section + 16.4. + + o Intra-area paths using non-backbone areas are always the + most preferred. + + o Otherwise, intra-area backbone paths are preferred. + + o Inter-area paths are the least preferred. + +16.5. Incremental updates -- summary-LSAs + + When a new summary-LSA is received, it is not necessary to + recalculate the entire routing table. Call the destination described + by the summary-LSA N (N's address is obtained by masking the LSA's + Link State ID with the network/subnet mask contained in the body of + the LSA), and let Area A be the area to which the LSA belongs. There + are then two separate cases: + + + + + + +Moy Standards Track [Page 151] + +RFC 2178 OSPF Version 2 July 1997 + + + Case 1: Area A is the backbone and/or the router is not an area + border router. + In this case, the following calculations must be performed. + First, if there is presently an inter-area route to the + destination N, N's routing table entry is invalidated, saving the + entry's values for later comparisons. Then the calculation in + Section 16.2 is run again for the single destination N. In this + calculation, all of Area A's summary-LSAs that describe a route to + N are examined. In addition, if the router is an area border + router attached to one or more transit areas, the calculation in + Section 16.3 must be run again for the single destination. If the + results of these calculations have changed the cost/path to an AS + boundary router (as would be the case for a Type 4 summary-LSA) or + to any forwarding addresses, all AS- external-LSAs will have to be + reexamined by rerunning the calculation in Section 16.4. + Otherwise, if N is now newly unreachable, the calculation in + Section 16.4 must be rerun for the single destination N, in case + an alternate external route to N exists. + + Case 2: Area A is a transit area and the router is an area border + router. + In this case, the following calculations must be performed. + First, if N's routing table entry presently contains one or more + inter-area paths that utilize the transit area Area A, these paths + should be removed. If this removes all paths from the routing + table entry, the entry should be invalidated. The entry's old + values should be saved for later comparisons. Next the calculation + in Section 16.3 must be run again for the single destination N. If + the results of this calculation have caused the cost to N to + increase, the complete routing table calculation must be rerun + starting with the Dijkstra algorithm specified in Section 16.1. + Otherwise, if the cost/path to an AS boundary router (as would be + the case for a Type 4 summary-LSA) or to any forwarding addresses + has changed, all AS-external-LSAs will have to be reexamined by + rerunning the calculation in Section 16.4. Otherwise, if N is now + newly unreachable, the calculation in Section 16.4 must be rerun + for the single destination N, in case an alternate external route + to N exists. + +16.6. Incremental updates -- AS-external-LSAs + + When a new AS-external-LSA is received, it is not necessary to + recalculate the entire routing table. Call the destination described + by the AS-external-LSA N. N's address is obtained by masking the + LSA's Link State ID with the network/subnet mask contained in the + body of the LSA. If there is already an intra- area or inter-area + route to the destination, no recalculation is necessary (internal + routes take precedence). + + + +Moy Standards Track [Page 152] + +RFC 2178 OSPF Version 2 July 1997 + + + Otherwise, the procedure in Section 16.4 will have to be performed, + but only for those AS-external-LSAs whose destination is N. Before + this procedure is performed, the present routing table entry for N + should be invalidated. + +16.7. Events generated as a result of routing table changes + + Changes to routing table entries sometimes cause the OSPF area border + routers to take additional actions. These routers need to act on the + following routing table changes: + + o The cost or path type of a routing table entry has changed. + If the destination described by this entry is a Network or AS + boundary router, and this is not simply a change of AS external + routes, new summary-LSAs may have to be generated (potentially one + for each attached area, including the backbone). See Section + 12.4.3 for more information. If a previously advertised entry has + been deleted, or is no longer advertisable to a particular area, + the LSA must be flushed from the routing domain by setting its LS + age to MaxAge and reflooding (see Section 14.1). + + o A routing table entry associated with a configured virtual + link has changed. The destination of such a routing table entry + is an area border router. The change indicates a modification to + the virtual link's cost or viability. + + If the entry indicates that the area border router is newly + reachable, the corresponding virtual link is now operational. An + InterfaceUp event should be generated for the virtual link, which + will cause a virtual adjacency to begin to form (see Section + 10.3). At this time the virtual link's IP interface address and + the virtual neighbor's Neighbor IP address are also calculated. + + If the entry indicates that the area border router is no longer + reachable, the virtual link and its associated adjacency should be + destroyed. This means an InterfaceDown event should be generated + for the associated virtual link. + + If the cost of the entry has changed, and there is a fully + established virtual adjacency, a new router-LSA for the backbone + must be originated. This in turn may cause further routing table + changes. + + + + + + + + + +Moy Standards Track [Page 153] + +RFC 2178 OSPF Version 2 July 1997 + + +16.8. Equal-cost multipath + + The OSPF protocol maintains multiple equal-cost routes to all + destinations. This can be seen in the steps used above to calculate + the routing table, and in the definition of the routing table + structure. + + Each one of the multiple routes will be of the same type (intra-area, + inter-area, type 1 external or type 2 external), cost, and will have + the same associated area. However, each route specifies a separate + next hop and Advertising router. + + There is no requirement that a router running OSPF keep track of all + possible equal-cost routes to a destination. An implementation may + choose to keep only a fixed number of routes to any given + destination. This does not affect any of the algorithms presented in + this specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 154] + +RFC 2178 OSPF Version 2 July 1997 + + +Footnotes + + [1]The graph's vertices represent either routers, transit networks, + or stub networks. Since routers may belong to multiple areas, it is + not possible to color the graph's vertices. + + [2]It is possible for all of a router's interfaces to be unnumbered + point-to-point links. In this case, an IP address must be assigned + to the router. This address will then be advertised in the router's + router-LSA as a host route. + + [3]Note that in these cases both interfaces, the non-virtual and the + virtual, would have the same IP address. + + [4]Note that no host route is generated for, and no IP packets can be + addressed to, interfaces to unnumbered point-to-point networks. This + is regardless of such an interface's state. + + [5]It is instructive to see what happens when the Designated Router + for the network crashes. Call the Designated Router for the network + RT1, and the Backup Designated Router RT2. If Router RT1 crashes (or + maybe its interface to the network dies), the other routers on the + network will detect RT1's absence within RouterDeadInterval seconds. + All routers may not detect this at precisely the same time; the + routers that detect RT1's absence before RT2 does will, for a time, + select RT2 to be both Designated Router and Backup Designated Router. + When RT2 detects that RT1 is gone it will move itself to Designated + Router. At this time, the remaining router having highest Router + Priority will be selected as Backup Designated Router. + + [6]On point-to-point networks, the lower level protocols indicate + whether the neighbor is up and running. Likewise, existence of the + neighbor on virtual links is indicated by the routing table + calculation. However, in both these cases, the Hello Protocol is + still used. This ensures that communication between the neighbors is + bidirectional, and that each of the neighbors has a functioning + routing protocol layer. + + [7]When the identity of the Designated Router is changing, it may be + quite common for a neighbor in this state to send the router a + Database Description packet; this means that there is some momentary + disagreement on the Designated Router's identity. + + [8]Note that it is possible for a router to resynchronize any of its + fully established adjacencies by setting the adjacency's state back + to ExStart. This will cause the other end of the adjacency to + process a SeqNumberMismatch event, and therefore to also go back to + ExStart state. + + + +Moy Standards Track [Page 155] + +RFC 2178 OSPF Version 2 July 1997 + + + [9]The address space of IP networks and the address space of OSPF + Router IDs may overlap. That is, a network may have an IP address + which is identical (when considered as a 32-bit number) to some + router's Router ID. + + [10]"Discard" entries are necessary to ensure that route + summarization at area boundaries will not cause packet looping. + + [11]It is assumed that, for two different address ranges matching the + destination, one range is more specific than the other. Non- + contiguous subnet masks can be configured to violate this assumption. + Such subnet mask configurations cannot be handled by the OSPF + protocol. + + [12]MaxAgeDiff is an architectural constant. It indicates the + maximum dispersion of ages, in seconds, that can occur for a single + LSA instance as it is flooded throughout the routing domain. If two + LSAs differ by more than this, they are assumed to be different + instances of the same LSA. This can occur when a router restarts and + loses track of the LSA's previous LS sequence number. See Section + 13.4 for more details. + + [13]When two LSAs have different LS checksums, they are assumed to be + separate instances. This can occur when a router restarts, and loses + track of the LSA's previous LS sequence number. In the case where + the two LSAs have the same LS sequence number, it is not possible to + determine which LSA is actually newer. However, if the wrong LSA is + accepted as newer, the originating router will simply originate + another instance. See Section 13.4 for further details. + + [14]There is one instance where a lookup must be done based on + partial information. This is during the routing table calculation, + when a network-LSA must be found based solely on its Link State ID. + The lookup in this case is still well defined, since no two network- + LSAs can have the same Link State ID. + + [15]This is the way RFC 1583 specified point-to-point representation. + It has three advantages: a) it does not require allocating a subnet + to the point-to-point link, b) it tends to bias the routing so that + packets destined for the point-to-point interface will actually be + received over the interface (which is useful for diagnostic purposes) + and c) it allows network bootstrapping of a neighbor, without + requiring that the bootstrap program contain an OSPF implementation. + + [16]This is the more traditional point-to-point representation used + by protocols such as RIP. + + + + + +Moy Standards Track [Page 156] + +RFC 2178 OSPF Version 2 July 1997 + + + [17]This clause covers the case: Inter-area routes are not summarized + to the backbone. This is because inter-area routes are always + associated with the backbone area. + + [18]This clause is only invoked when a non-backbone Area A supports + transit data traffic (i.e., has TransitCapability set to TRUE). For + example, in the area configuration of Figure 6, Area 2 can support + transit traffic due to the configured virtual link between Routers + RT10 and RT11. As a result, Router RT11 need only originate a single + summary-LSA into Area 2 (having the collapsed destination N9-N11,H1), + since all of Router RT11's other eligible routes have next hops + belonging to Area 2 itself (and as such only need be advertised by + other area border routers; in this case, Routers RT10 and RT7). + + [19]By keeping more information in the routing table, it is possible + for an implementation to recalculate the shortest path tree for only + a single area. In fact, there are incremental algorithms that allow + an implementation to recalculate only a portion of a single area's + shortest path tree [Ref1]. However, these algorithms are beyond the + scope of this specification. + + [20]This is how the Link state request list is emptied, which + eventually causes the neighbor state to transition to Full. See + Section 10.9 for more details. + + [21]It should be a relatively rare occurrence for an LSA's LS age to + reach MaxAge in this fashion. Usually, the LSA will be replaced by a + more recent instance before it ages out. + + [22]Strictly speaking, because of equal-cost multipath, the algorithm + does not create a tree. We continue to use the "tree" terminology + because that is what occurs most often in the existing literature. + + [23]Note that the presence of any link back to V is sufficient; it + need not be the matching half of the link under consideration from V + to W. This is enough to ensure that, before data traffic flows + between a pair of neighboring routers, their link state databases + will be synchronized. + + [24]When the forwarding address is non-zero, it should point to a + router belonging to another Autonomous System. See Section 12.4.4 + for more details. + + + + + + + + + +Moy Standards Track [Page 157] + +RFC 2178 OSPF Version 2 July 1997 + + +References + + [Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing + Algorithm Improvements", BBN Technical Report 3803, April + 1978. + + [Ref2] Digital Equipment Corporation, "Information processing + systems -- Data communications -- Intermediate System to + Intermediate System Intra-Domain Routing Protocol", October + 1987. + + [Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the + ARPANET", IEEE Transactions on Communications, May 1980. + + [Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing + Information", Computer Networks, December 1983. + + [Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, + USC/Information Sciences Institute, September 1981. + + [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP + 8073", RFC 905, ISO, April 1984. + + [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, Stanford University, May 1988. + + [Ref8] McCloghrie, K., and M. Rose, "Management Information Base + for network management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, Hughes LAN Systems, Performance Systems + International, March 1991. + + [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March + 1994. + + [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless + Inter-Domain Routing (CIDR): an Address Assignment and + Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, + OARnet, September 1993. + + [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [Ref12] Almquist, P., "Type of Service in the Internet Protocol + Suite", RFC 1349, July 1992. + + [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN + Protocol Handbook, April 1985. + + + + +Moy Standards Track [Page 158] + +RFC 2178 OSPF Version 2 July 1997 + + + [Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution + Protocol", RFC 1293, January 1992. + + [Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF + Over Frame Relay Networks", RFC 1586, March 1994. + + [Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol + Suite", ACM Computer Communications Review, Volume 19, + Number 2, pp. 32-38, April 1989. + + [Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, + Inc., March 1994. + + [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, + RainbowBridge Communications, Stanford University, March + 1994. + + [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in + progress. + + [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC + 1793, Cascade, April 1995. + + [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, + DECWRL, Stanford University, November 1990. + + [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- + 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco + Systems, March 1995. + + [Ref24] Hinden, R., "Internet Routing Protocol Standardization + Criteria", BBN, October 1991. + + + + + + + + + + + + + + + + +Moy Standards Track [Page 159] + +RFC 2178 OSPF Version 2 July 1997 + + +A. OSPF data formats + + This appendix describes the format of OSPF protocol packets and OSPF + LSAs. The OSPF protocol runs directly over the IP network layer. + Before any data formats are described, the details of the OSPF + encapsulation are explained. + + Next the OSPF Options field is described. This field describes + various capabilities that may or may not be supported by pieces of + the OSPF routing domain. The OSPF Options field is contained in OSPF + Hello packets, Database Description packets and in OSPF LSAs. + + OSPF packet formats are detailed in Section A.3. A description of + OSPF LSAs appears in Section A.4. + +A.1 Encapsulation of OSPF packets + + OSPF runs directly over the Internet Protocol's network layer. OSPF + packets are therefore encapsulated solely by IP and local data-link + headers. + + OSPF does not define a way to fragment its protocol packets, and + depends on IP fragmentation when transmitting packets larger than the + network MTU. If necessary, the length of OSPF packets can be up to + 65,535 bytes (including the IP header). The OSPF packet types that + are likely to be large (Database Description Packets, Link State + Request, Link State Update, and Link State Acknowledgment packets) + can usually be split into several separate protocol packets, without + loss of functionality. This is recommended; IP fragmentation should + be avoided whenever possible. Using this reasoning, an attempt should + be made to limit the sizes of OSPF packets sent over virtual links to + 576 bytes unless Path MTU Discovery is being performed (see [Ref22]). + + The other important features of OSPF's IP encapsulation are: + + o Use of IP multicast. Some OSPF messages are multicast, when + sent over broadcast networks. Two distinct IP multicast addresses + are used. Packets sent to these multicast addresses should never + be forwarded; they are meant to travel a single hop only. To + ensure that these packets will not travel multiple hops, their IP + TTL must be set to 1. + + + + + + + + + + +Moy Standards Track [Page 160] + +RFC 2178 OSPF Version 2 July 1997 + + + AllSPFRouters + This multicast address has been assigned the value 224.0.0.5. All + routers running OSPF should be prepared to receive packets sent to + this address. Hello packets are always sent to this destination. + Also, certain OSPF protocol packets are sent to this address + during the flooding procedure. + + AllDRouters + This multicast address has been assigned the value 224.0.0.6. Both + the Designated Router and Backup Designated Router must be + prepared to receive packets destined to this address. Certain + OSPF protocol packets are sent to this address during the flooding + procedure. + + o OSPF is IP protocol number 89. This number has been registered + with the Network Information Center. IP protocol number + assignments are documented in [Ref11]. + + o All OSPF routing protocol packets are sent using the normal + service TOS value of binary 0000 defined in [Ref12]. + + o Routing protocol packets are sent with IP precedence set to + Internetwork Control. OSPF protocol packets should be given + precedence over regular IP data traffic, in both sending and + receiving. Setting the IP precedence field in the IP header to + Internetwork Control [Ref5] may help implement this objective. + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 161] + +RFC 2178 OSPF Version 2 July 1997 + + +A.2 The Options field + + The OSPF Options field is present in OSPF Hello packets, Database + Description packets and all LSAs. The Options field enables OSPF + routers to support (or not support) optional capabilities, and to + communicate their capability level to other OSPF routers. Through + this mechanism routers of differing capabilities can be mixed within + an OSPF routing domain. + + When used in Hello packets, the Options field allows a router to + reject a neighbor because of a capability mismatch. Alternatively, + when capabilities are exchanged in Database Description packets a + router can choose not to forward certain LSAs to a neighbor because + of its reduced functionality. Lastly, listing capabilities in LSAs + allows routers to forward traffic around reduced functionality + routers, by excluding them from parts of the routing table + calculation. + + Five bits of the OSPF Options field have been assigned, although only + one (the E-bit) is described completely by this memo. Each bit is + described briefly below. Routers should reset (i.e. clear) + unrecognized bits in the Options field when sending Hello packets or + Database Description packets and when originating LSAs. Conversely, + routers encountering unrecognized Option bits in received Hello + Packets, Database Description packets or LSAs should ignore the + capability and process the packet/LSA normally. + + +------------------------------------+ + | * | * | DC | EA | N/P | MC | E | * | + +------------------------------------+ + + The Options field + + E-bit + This bit describes the way AS-external-LSAs are flooded, as + described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. + + MC-bit + This bit describes whether IP multicast datagrams are forwarded + according to the specifications in [Ref18]. + + N/P-bit + This bit describes the handling of Type-7 LSAs, as specified in + [Ref19]. + + EA-bit + This bit describes the router's willingness to receive and + forward External-Attributes-LSAs, as specified in [Ref20]. + + + +Moy Standards Track [Page 162] + +RFC 2178 OSPF Version 2 July 1997 + + + DC-bit + This bit describes the router's handling of demand circuits, as + specified in [Ref21]. + +A.3 OSPF Packet Formats + + There are five distinct OSPF packet types. All OSPF packet types + begin with a standard 24 byte header. This header is described + first. Each packet type is then described in a succeeding section. + In these sections each packet's division into fields is displayed, + and then the field definitions are enumerated. + + All OSPF packet types (other than the OSPF Hello packets) deal with + lists of LSAs. For example, Link State Update packets implement the + flooding of LSAs throughout the OSPF routing domain. Because of + this, OSPF protocol packets cannot be parsed unless the format of + LSAs is also understood. The format of LSAs is described in Section + A.4. + + The receive processing of OSPF packets is detailed in Section 8.2. + The sending of OSPF packets is explained in Section 8.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 163] + +RFC 2178 OSPF Version 2 July 1997 + + +A.3.1 The OSPF packet header + + Every OSPF packet starts with a standard 24 byte header. This header + contains all the information necessary to determine whether the + packet should be accepted for further processing. This determination + is described in Section 8.2 of the specification. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | Type | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | AuType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Version # + The OSPF version number. This specification documents version 2 + of the protocol. + + Type + The OSPF packet types are as follows. See Sections A.3.2 through + A.3.6 for details. + + Type Description + ________________________________ + 1 Hello + 2 Database Description + 3 Link State Request + 4 Link State Update + 5 Link State Acknowledgment + + + Packet length + The length of the OSPF protocol packet in bytes. This length + includes the standard OSPF header. + + Router ID + The Router ID of the packet's source. + + + + +Moy Standards Track [Page 164] + +RFC 2178 OSPF Version 2 July 1997 + + + Area ID + A 32 bit number identifying the area that this packet belongs + to. All OSPF packets are associated with a single area. Most + travel a single hop only. Packets travelling over a virtual + link are labelled with the backbone Area ID of 0.0.0.0. + + Checksum + The standard IP checksum of the entire contents of the packet, + starting with the OSPF packet header but excluding the 64-bit + authentication field. This checksum is calculated as the 16-bit + one's complement of the one's complement sum of all the 16-bit + words in the packet, excepting the authentication field. If the + packet's length is not an integral number of 16-bit words, the + packet is padded with a byte of zero before checksumming. The + checksum is considered to be part of the packet authentication + procedure; for some authentication types the checksum + calculation is omitted. + + AuType + Identifies the authentication procedure to be used for the + packet. Authentication is discussed in Appendix D of the + specification. Consult Appendix D for a list of the currently + defined authentication types. + + Authentication + A 64-bit field for use by the authentication scheme. See + Appendix D for details. + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 165] + +RFC 2178 OSPF Version 2 July 1997 + + +A.3.2 The Hello packet + + Hello packets are OSPF packet type 1. These packets are sent + periodically on all interfaces (including virtual links) in order to + establish and maintain neighbor relationships. In addition, Hello + Packets are multicast on those physical networks having a multicast + or broadcast capability, enabling dynamic discovery of neighboring + routers. + + All routers connected to a common network must agree on certain + parameters (Network mask, HelloInterval and RouterDeadInterval). + These parameters are included in Hello packets, so that differences + can inhibit the forming of neighbor relationships. A detailed + explanation of the receive processing for Hello packets is presented + in Section 10.5. The sending of Hello packets is covered in Section + 9.5. + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | 1 | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | AuType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HelloInterval | Options | Rtr Pri | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RouterDeadInterval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Designated Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Backup Designated Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Neighbor | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + + + +Moy Standards Track [Page 166] + +RFC 2178 OSPF Version 2 July 1997 + + + Network mask + The network mask associated with this interface. For example, + if the interface is to a class B network whose third byte is + used for subnetting, the network mask is 0xffffff00. + + Options + The optional capabilities supported by the router, as documented + in Section A.2. + + HelloInterval + The number of seconds between this router's Hello packets. + + Rtr Pri + This router's Router Priority. Used in (Backup) Designated + Router election. If set to 0, the router will be ineligible to + become (Backup) Designated Router. + + RouterDeadInterval + The number of seconds before declaring a silent router down. + + Designated Router + The identity of the Designated Router for this network, in the + view of the sending router. The Designated Router is identified + here by its IP interface address on the network. Set to 0.0.0.0 + if there is no Designated Router. + + Backup Designated Router + The identity of the Backup Designated Router for this network, + in the view of the sending router. The Backup Designated Router + is identified here by its IP interface address on the network. + Set to 0.0.0.0 if there is no Backup Designated Router. + + Neighbor + The Router IDs of each router from whom valid Hello packets have + been seen recently on the network. Recently means in the last + RouterDeadInterval seconds. + + + + + + + + + + + + + + + +Moy Standards Track [Page 167] + +RFC 2178 OSPF Version 2 July 1997 + + +A.3.3 The Database Description packet + + Database Description packets are OSPF packet type 2. These packets + are exchanged when an adjacency is being initialized. They describe + the contents of the link-state database. Multiple packets may be + used to describe the database. For this purpose a poll-response + procedure is used. One of the routers is designated to be the master, + the other the slave. The master sends Database Description packets + (polls) which are acknowledged by Database Description packets sent + by the slave (responses). The responses are linked to the polls via + the packets' DD sequence numbers. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | 2 | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | AuType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface MTU | Options |0|0|0|0|0|I|M|MS + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DD sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- -+ + | | + +- An LSA Header -+ + | | + +- -+ + | | + +- -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + The format of the Database Description packet is very similar to both + the Link State Request and Link State Acknowledgment packets. The + main part of all three is a list of items, each item describing a + piece of the link-state database. The sending of Database + + + +Moy Standards Track [Page 168] + +RFC 2178 OSPF Version 2 July 1997 + + + Description Packets is documented in Section 10.8. The reception of + Database Description packets is documented in Section 10.6. + + Interface MTU + The size in bytes of the largest IP datagram that can be sent out + the associated interface, without fragmentation. The MTUs of + common Internet link types can be found in Table 7-1 of [Ref22]. + Interface MTU should be set to 0 in Database Description packets + sent over virtual links. + + Options + The optional capabilities supported by the router, as documented + in Section A.2. + + I-bit + The Init bit. When set to 1, this packet is the first in the + sequence of Database Description Packets. + + M-bit + The More bit. When set to 1, it indicates that more Database + Description Packets are to follow. + + MS-bit + The Master/Slave bit. When set to 1, it indicates that the router + is the master during the Database Exchange process. Otherwise, + the router is the slave. + + DD sequence number + Used to sequence the collection of Database Description Packets. + The initial value (indicated by the Init bit being set) should be + unique. The DD sequence number then increments until the complete + database description has been sent. + + The rest of the packet consists of a (possibly partial) list of the + link-state database's pieces. Each LSA in the database is described + by its LSA header. The LSA header is documented in Section A.4.1. It + contains all the information required to uniquely identify both the + LSA and the LSA's current instance. + + + + + + + + + + + + + +Moy Standards Track [Page 169] + +RFC 2178 OSPF Version 2 July 1997 + + +A.3.4 The Link State Request packet + + Link State Request packets are OSPF packet type 3. After exchanging + Database Description packets with a neighboring router, a router may + find that parts of its link-state database are out-of-date. The Link + State Request packet is used to request the pieces of the neighbor's + database that are more up-to-date. Multiple Link State Request + packets may need to be used. + + A router that sends a Link State Request packet has in mind the + precise instance of the database pieces it is requesting. Each + instance is defined by its LS sequence number, LS checksum, and LS + age, although these fields are not specified in the Link State + Request Packet itself. The router may receive even more recent + instances in response. + + The sending of Link State Request packets is documented in Section + 10.9. The reception of Link State Request packets is documented in + Section 10.7. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | 3 | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | AuType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + Each LSA requested is specified by its LS type, Link State ID, and + Advertising Router. This uniquely identifies the LSA, but not its + instance. Link State Request packets are understood to be requests + for the most recent instance (whatever that might be). + + + + +Moy Standards Track [Page 170] + +RFC 2178 OSPF Version 2 July 1997 + + +A.3.5 The Link State Update packet + + Link State Update packets are OSPF packet type 4. These packets + implement the flooding of LSAs. Each Link State Update packet + carries a collection of LSAs one hop further from their origin. + Several LSAs may be included in a single packet. + + Link State Update packets are multicast on those physical networks + that support multicast/broadcast. In order to make the flooding + procedure reliable, flooded LSAs are acknowledged in Link State + Acknowledgment packets. If retransmission of certain LSAs is + necessary, the retransmitted LSAs are always carried by unicast Link + State Update packets. For more information on the reliable flooding + of LSAs, consult Section 13. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | 4 | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | AuType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | # LSAs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- +-+ + | LSAs | + +- +-+ + | ... | + + + + # LSAs + The number of LSAs included in this update. + + The body of the Link State Update packet consists of a list of LSAs. + Each LSA begins with a common 20 byte header, described in Section + A.4.1. Detailed formats of the different types of LSAs are described + in Section A.4. + + + + +Moy Standards Track [Page 171] + +RFC 2178 OSPF Version 2 July 1997 + + +A.3.6 The Link State Acknowledgment packet + + Link State Acknowledgment Packets are OSPF packet type 5. To make + the flooding of LSAs reliable, flooded LSAs are explicitly + acknowledged. This acknowledgment is accomplished through the + sending and receiving of Link State Acknowledgment packets. Multiple + LSAs can be acknowledged in a single Link State Acknowledgment + packet. + + Depending on the state of the sending interface and the sender of the + corresponding Link State Update packet, a Link State Acknowledgment + packet is sent either to the multicast address AllSPFRouters, to the + multicast address AllDRouters, or as a unicast. The sending of Link + State Acknowledgment packets is documented in Section 13.5. The + reception of Link State Acknowledgment packets is documented in + Section 13.7. + + The format of this packet is similar to that of the Data Description + packet. The body of both packets is simply a list of LSA headers. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | 5 | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | AuType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- -+ + | | + +- An LSA Header -+ + | | + +- -+ + | | + +- -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + + + +Moy Standards Track [Page 172] + +RFC 2178 OSPF Version 2 July 1997 + + + Each acknowledged LSA is described by its LSA header. The LSA header + is documented in Section A.4.1. It contains all the information + required to uniquely identify both the LSA and the LSA's current + instance. + +A.4 LSA formats + + This memo defines five distinct types of LSAs. Each LSA begins with + a standard 20 byte LSA header. This header is explained in Section + A.4.1. Succeeding sections then diagram the separate LSA types. + + Each LSA describes a piece of the OSPF routing domain. Every router + originates a router-LSA. In addition, whenever the router is elected + Designated Router, it originates a network-LSA. Other types of LSAs + may also be originated (see Section 12.4). All LSAs are then flooded + throughout the OSPF routing domain. The flooding algorithm is + reliable, ensuring that all routers have the same collection of LSAs. + (See Section 13 for more information concerning the flooding + algorithm). This collection of LSAs is called the link-state + database. + + From the link state database, each router constructs a shortest path + tree with itself as root. This yields a routing table (see Section + 11). For the details of the routing table build process, see Section + 16. + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 173] + +RFC 2178 OSPF Version 2 July 1997 + + +A.4.1 The LSA header + + All LSAs begin with a common 20 byte header. This header contains + enough information to uniquely identify the LSA (LS type, Link State + ID, and Advertising Router). Multiple instances of the LSA may exist + in the routing domain at the same time. It is then necessary to + determine which instance is more recent. This is accomplished by + examining the LS age, LS sequence number and LS checksum fields that + are also contained in the LSA header. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | LS type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + LS age + The time in seconds since the LSA was originated. + + Options + The optional capabilities supported by the described portion of + the routing domain. OSPF's optional capabilities are documented + in Section A.2. + + LS type + The type of the LSA. Each LSA type has a separate advertisement + format. The LSA types defined in this memo are as follows (see + Section 12.1.3 for further explanation): + + + LS Type Description + ___________________________________ + 1 Router-LSAs + 2 Network-LSAs + 3 Summary-LSAs (IP network) + 4 Summary-LSAs (ASBR) + 5 AS-external-LSAs + + + + + +Moy Standards Track [Page 174] + +RFC 2178 OSPF Version 2 July 1997 + + + Link State ID + This field identifies the portion of the internet environment + that is being described by the LSA. The contents of this field + depend on the LSA's LS type. For example, in network-LSAs the + Link State ID is set to the IP interface address of the + network's Designated Router (from which the network's IP address + can be derived). The Link State ID is further discussed in + Section 12.1.4. + + Advertising Router + The Router ID of the router that originated the LSA. For + example, in network-LSAs this field is equal to the Router ID of + the network's Designated Router. + + LS sequence number + Detects old or duplicate LSAs. Successive instances of an LSA + are given successive LS sequence numbers. See Section 12.1.6 + for more details. + + LS checksum + The Fletcher checksum of the complete contents of the LSA, + including the LSA header but excluding the LS age field. See + Section 12.1.7 for more details. + + length + The length in bytes of the LSA. This includes the 20 byte LSA + header. + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 175] + +RFC 2178 OSPF Version 2 July 1997 + + +A.4.2 Router-LSAs + + Router-LSAs are the Type 1 LSAs. Each router in an area originates a + router-LSA. The LSA describes the state and cost of the router's + links (i.e., interfaces) to the area. All of the router's links to + the area must be described in a single router-LSA. For details + concerning the construction of router-LSAs, see Section 12.4.1. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 |V|E|B| 0 | # links | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | # TOS | metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TOS | 0 | TOS metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + In router-LSAs, the Link State ID field is set to the router's OSPF + Router ID. Router-LSAs are flooded throughout a single area only. + + bit V + When set, the router is an endpoint of one or more fully adjacent + virtual links having the described area as Transit area (V is for + virtual link endpoint). + + + + +Moy Standards Track [Page 176] + +RFC 2178 OSPF Version 2 July 1997 + + + bit E + When set, the router is an AS boundary router (E is for external). + + bit B + When set, the router is an area border router (B is for border). + + # links + The number of router links described in this LSA. This must be + the total collection of router links (i.e., interfaces) to the + area. + + The following fields are used to describe each router link (i.e., + interface). Each router link is typed (see the below Type field). + The Type field indicates the kind of link being described. It may be + a link to a transit network, to another router or to a stub network. + The values of all the other fields describing a router link depend on + the link's Type. For example, each link has an associated 32-bit + Link Data field. For links to stub networks this field specifies the + network's IP address mask. For other link types the Link Data field + specifies the router interface's IP address. + + Type + A quick description of the router link. One of the following. + Note that host routes are classified as links to stub networks + with network mask of 0xffffffff. + + Type Description + __________________________________________________ + 1 Point-to-point connection to another router + 2 Connection to a transit network + 3 Connection to a stub network + 4 Virtual link + + Link ID + Identifies the object that this router link connects to. Value + depends on the link's Type. When connecting to an object that + also originates an LSA (i.e., another router or a transit + network) the Link ID is equal to the neighboring LSA's Link + State ID. This provides the key for looking up the neighboring + LSA in the link state database during the routing table + calculation. See Section 12.2 for more details. + + + + + + + + + + +Moy Standards Track [Page 177] + +RFC 2178 OSPF Version 2 July 1997 + + + Type Link ID + ______________________________________ + 1 Neighboring router's Router ID + 2 IP address of Designated Router + 3 IP network/subnet number + 4 Neighboring router's Router ID + + Link Data + Value again depends on the link's Type field. For connections to + stub networks, Link Data specifies the network's IP address + mask. For unnumbered point-to-point connections, it specifies + the interface's MIB-II [Ref8] ifIndex value. For the other link + types it specifies the router interface's IP address. This + latter piece of information is needed during the routing table + build process, when calculating the IP address of the next hop. + See Section 16.1.1 for more details. + + # TOS + The number of different TOS metrics given for this link, not + counting the required link metric (referred to as the TOS 0 + metric in [Ref9]). For example, if no additional TOS metrics + are given, this field is set to 0. + + metric + The cost of using this router link. + + Additional TOS-specific information may also be included, for + backward compatibility with previous versions of the OSPF + specification ([Ref9]). Within each link, and for each desired TOS, + TOS TOS-specific link information may be encoded as follows: + + TOS IP Type of Service that this metric refers to. The encoding of + TOS in OSPF LSAs is described in Section 12.3. + + TOS metric + TOS-specific metric information. + + + + + + + + + + + + + + + +Moy Standards Track [Page 178] + +RFC 2178 OSPF Version 2 July 1997 + + +A.4.3 Network-LSAs + + Network-LSAs are the Type 2 LSAs. A network-LSA is originated for + each broadcast and NBMA network in the area which supports two or + more routers. The network-LSA is originated by the network's + Designated Router. The LSA describes all routers attached to the + network, including the Designated Router itself. The LSA's Link + State ID field lists the IP interface address of the Designated + Router. + + The distance from the network to all attached routers is zero. This + is why metric fields need not be specified in the network-LSA. For + details concerning the construction of network-LSAs, see Section + 12.4.2. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attached Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + Network Mask + The IP address mask for the network. For example, a class A + network would have the mask 0xff000000. + + Attached Router + The Router IDs of each of the routers attached to the network. + Actually, only those routers that are fully adjacent to the + Designated Router are listed. The Designated Router includes + itself in this list. The number of routers included can be + deduced from the LSA header's length field. + + + + + + +Moy Standards Track [Page 179] + +RFC 2178 OSPF Version 2 July 1997 + + +A.4.4 Summary-LSAs + + Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by + area border routers. Summary-LSAs describe inter-area destinations. + For details concerning the construction of summary-LSAs, see Section + 12.4.3. + + Type 3 summary-LSAs are used when the destination is an IP network. + In this case the LSA's Link State ID field is an IP network number + (if necessary, the Link State ID can also have one or more of the + network's "host" bits set; see Appendix E for details). When the + destination is an AS boundary router, a Type 4 summary-LSA is used, + and the Link State ID field is the AS boundary router's OSPF Router + ID. (To see why it is necessary to advertise the location of each + ASBR, consult Section 16.4.) Other than the difference in the Link + State ID field, the format of Type 3 and 4 summary-LSAs is identical. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 3 or 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TOS | TOS metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + For stub areas, Type 3 summary-LSAs can also be used to describe a + (per-area) default route. Default summary routes are used in stub + areas instead of flooding a complete set of external routes. When + describing a default summary route, the summary-LSA's Link State ID + is always set to DefaultDestination (0.0.0.0) and the Network Mask is + set to 0.0.0.0. + + + + + + +Moy Standards Track [Page 180] + +RFC 2178 OSPF Version 2 July 1997 + + + Network Mask + For Type 3 summary-LSAs, this indicates the destination network's + IP address mask. For example, when advertising the location of a + class A network the value 0xff000000 would be used. This field is + not meaningful and must be zero for Type 4 summary-LSAs. + + metric + The cost of this route. Expressed in the same units as the + interface costs in the router-LSAs. + + Additional TOS-specific information may also be included, for + backward compatibility with previous versions of the OSPF + specification ([Ref9]). For each desired TOS, TOS-specific + information is encoded as follows: + + TOS IP Type of Service that this metric refers to. The encoding of + TOS in OSPF LSAs is described in Section 12.3. + + TOS metric + TOS-specific metric information. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 181] + +RFC 2178 OSPF Version 2 July 1997 + + +A.4.5 AS-external-LSAs + + AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by + AS boundary routers, and describe destinations external to the AS. + For details concerning the construction of AS-external-LSAs, see + Section 12.4.3. + + AS-external-LSAs usually describe a particular external destination. + For these LSAs the Link State ID field specifies an IP network number + (if necessary, the Link State ID can also have one or more of the + network's "host" bits set; see Appendix E for details). AS- + external-LSAs are also used to describe a default route. Default + routes are used when no specific route exists to the destination. + When describing a default route, the Link State ID is always set to + DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS age | Options | 5 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link State ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Advertising Router | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LS checksum | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E| 0 | metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Forwarding address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | External Route Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E| TOS | TOS metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Forwarding address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | External Route Tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + + + + + + +Moy Standards Track [Page 182] + +RFC 2178 OSPF Version 2 July 1997 + + + Network Mask + The IP address mask for the advertised destination. For + example, when advertising a class A network the mask 0xff000000 + would be used. + + bit E + The type of external metric. If bit E is set, the metric + specified is a Type 2 external metric. This means the metric is + considered larger than any link state path. If bit E is zero, + the specified metric is a Type 1 external metric. This means + that it is expressed in the same units as the link state metric + (i.e., the same units as interface cost). + + metric + The cost of this route. Interpretation depends on the external + type indication (bit E above). + + Forwarding address + Data traffic for the advertised destination will be forwarded to + this address. If the Forwarding address is set to 0.0.0.0, data + traffic will be forwarded instead to the LSA's originator (i.e., + the responsible AS boundary router). + + External Route Tag + A 32-bit field attached to each external route. This is not + used by the OSPF protocol itself. It may be used to communicate + information between AS boundary routers; the precise nature of + such information is outside the scope of this specification. + + Additional TOS-specific information may also be included, for + backward compatibility with previous versions of the OSPF + specification ([Ref9]). For each desired TOS, TOS-specific + information is encoded as follows: + + TOS The Type of Service that the following fields concern. The + encoding of TOS in OSPF LSAs is described in Section 12.3. + + bit E + For backward-compatibility with [Ref9]. + + TOS metric + TOS-specific metric information. + + Forwarding address + For backward-compatibility with [Ref9]. + + External Route Tag + For backward-compatibility with [Ref9]. + + + +Moy Standards Track [Page 183] + +RFC 2178 OSPF Version 2 July 1997 + + +B. Architectural Constants + + Several OSPF protocol parameters have fixed architectural values. + These parameters have been referred to in the text by names such as + LSRefreshTime. The same naming convention is used for the + configurable protocol parameters. They are defined in Appendix C. + + The name of each architectural constant follows, together with its + value and a short description of its function. + + LSRefreshTime + The maximum time between distinct originations of any particular + LSA. If the LS age field of one of the router's self-originated + LSAs reaches the value LSRefreshTime, a new instance of the LSA is + originated, even though the contents of the LSA (apart from the + LSA header) will be the same. The value of LSRefreshTime is set + to 30 minutes. + + MinLSInterval + The minimum time between distinct originations of any particular + LSA. The value of MinLSInterval is set to 5 seconds. + + MinLSArrival + For any particular LSA, the minimum time that must elapse + between reception of new LSA instances during flooding. LSA + instances received at higher frequencies are discarded. The value + of MinLSArrival is set to 1 second. + + MaxAge + The maximum age that an LSA can attain. When an LSA's LS age field + reaches MaxAge, it is reflooded in an attempt to flush the LSA + from the routing domain (See Section 14). LSAs of age MaxAge are + not used in the routing table calculation. The value of MaxAge is + set to 1 hour. + + CheckAge + When the age of an LSA in the link state database hits a multiple + of CheckAge, the LSA's checksum is verified. An incorrect + checksum at this time indicates a serious error. The value of + CheckAge is set to 5 minutes. + + MaxAgeDiff + The maximum time dispersion that can occur, as an LSA is flooded + throughout the AS. Most of this time is accounted for by the LSAs + sitting on router output queues (and therefore not aging) during + the flooding process. The value of MaxAgeDiff is set to 15 + minutes. + + + + +Moy Standards Track [Page 184] + +RFC 2178 OSPF Version 2 July 1997 + + + LSInfinity + The metric value indicating that the destination described by an + LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as + an alternative to premature aging (see Section 14.1). It is + defined to be the 24-bit binary value of all ones: 0xffffff. + + DefaultDestination + The Destination ID that indicates the default route. This route + is used when no other matching routing table entry can be found. + The default destination can only be advertised in AS-external- + LSAs and in stub areas' type 3 summary-LSAs. Its value is the IP + address 0.0.0.0. Its associated Network Mask is also always + 0.0.0.0. + + InitialSequenceNumber + The value used for LS Sequence Number when originating the first + instance of any LSA. Its value is the signed 32-bit integer + 0x80000001. + + MaxSequenceNumber + The maximum value that LS Sequence Number can attain. Its value + is the signed 32-bit integer 0x7fffffff. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 185] + +RFC 2178 OSPF Version 2 July 1997 + + +C. Configurable Constants + + The OSPF protocol has quite a few configurable parameters. These + parameters are listed below. They are grouped into general + functional categories (area parameters, interface parameters, etc.). + Sample values are given for some of the parameters. + + Some parameter settings need to be consistent among groups of + routers. For example, all routers in an area must agree on that + area's parameters, and all routers attached to a network must agree + on that network's IP network number and mask. + + Some parameters may be determined by router algorithms outside of + this specification (e.g., the address of a host connected to the + router via a SLIP line). From OSPF's point of view, these items are + still configurable. + +C.1 Global parameters + + In general, a separate copy of the OSPF protocol is run for each + area. Because of this, most configuration parameters are defined on + a per-area basis. The few global configuration parameters are listed + below. + + Router ID + This is a 32-bit number that uniquely identifies the router in + the Autonomous System. One algorithm for Router ID assignment is + to choose the largest or smallest IP address assigned to the + router. If a router's OSPF Router ID is changed, the router's + OSPF software should be restarted before the new Router ID takes + effect. Before restarting in order to change its Router ID, the + router should flush its self-originated LSAs from the routing + domain (see Section 14.1), or they will persist for up to MaxAge + minutes. + + RFC1583Compatibility + Controls the preference rules used in Section 16.4 when choosing + among multiple AS-external-LSAs advertising the same destination. + When set to "enabled", the preference rules remain those + specified by RFC 1583 ([Ref9]). When set to "disabled", the + preference rules are those stated in Section 16.4.1, which + prevent routing loops when AS- external-LSAs for the same + destination have been originated from different areas (see + Section G.7). Set to "enabled" by default. + + + + + + + +Moy Standards Track [Page 186] + +RFC 2178 OSPF Version 2 July 1997 + + + In order to minimize the chance of routing loops, all OSPF + routers in an OSPF routing domain should have + RFC1583Compatibility set identically. When there are routers + present that have not been updated with the functionality + specified in Section 16.4.1 of this memo, all routers should have + RFC1583Compatibility set to "enabled". Otherwise, all routers + should have RFC1583Compatibility set to "disabled", preventing + all routing loops. + +C.2 Area parameters + + All routers belonging to an area must agree on that area's + configuration. Disagreements between two routers will lead to an + inability for adjacencies to form between them, with a resulting + hindrance to the flow of routing protocol and data traffic. The + following items must be configured for an area: + + Area ID + This is a 32-bit number that identifies the area. The Area ID of + 0.0.0.0 is reserved for the backbone. If the area represents a + subnetted network, the IP network number of the subnetted network + may be used for the Area ID. + + List of address ranges + An OSPF area is defined as a list of address ranges. Each address + range consists of the following items: + + [IP address, mask] + Describes the collection of IP addresses contained in the + address range. Networks and hosts are assigned to an area + depending on whether their addresses fall into one of the + area's defining address ranges. Routers are viewed as + belonging to multiple areas, depending on their attached + networks' area membership. + + Status Set to either Advertise or DoNotAdvertise. Routing + information is condensed at area boundaries. External to the + area, at most a single route is advertised (via a summary- + LSA) for each address range. The route is advertised if and + only if the address range's Status is set to Advertise. + Unadvertised ranges allow the existence of certain networks + to be intentionally hidden from other areas. Status is set to + Advertise by default. + + + + + + + + +Moy Standards Track [Page 187] + +RFC 2178 OSPF Version 2 July 1997 + + + As an example, suppose an IP subnetted network is to be its + own OSPF area. The area would be configured as a single + address range, whose IP address is the address of the + subnetted network, and whose mask is the natural class A, B, + or C address mask. A single route would be advertised + external to the area, describing the entire subnetted + network. + + ExternalRoutingCapability + Whether AS-external-LSAs will be flooded into/throughout the + area. If AS-external-LSAs are excluded from the area, the + area is called a "stub". Internal to stub areas, routing to + external destinations will be based solely on a default + summary route. The backbone cannot be configured as a stub + area. Also, virtual links cannot be configured through stub + areas. For more information, see Section 3.6. + + StubDefaultCost + If the area has been configured as a stub area, and the + router itself is an area border router, then the + StubDefaultCost indicates the cost of the default summary-LSA + that the router should advertise into the area. + +C.3 Router interface parameters + + Some of the configurable router interface parameters (such as IP + interface address and subnet mask) actually imply properties of the + attached networks, and therefore must be consistent across all the + routers attached to that network. The parameters that must be + configured for a router interface are: + + IP interface address + The IP protocol address for this interface. This uniquely + identifies the router over the entire internet. An IP address is + not required on point-to-point networks. Such a point-to-point + network is called "unnumbered". + + IP interface mask + Also referred to as the subnet/network mask, this indicates the + portion of the IP interface address that identifies the attached + network. Masking the IP interface address with the IP interface + mask yields the IP network number of the attached network. On + point-to-point networks and virtual links, the IP interface mask + is not defined. On these networks, the link itself is not + assigned an IP network number, and so the addresses of each side + of the link are assigned independently, if they are assigned at + all. + + + + +Moy Standards Track [Page 188] + +RFC 2178 OSPF Version 2 July 1997 + + + Area ID + The OSPF area to which the attached network belongs. + + Interface output cost + The cost of sending a packet on the interface, expressed in the + link state metric. This is advertised as the link cost for this + interface in the router's router-LSA. The interface output cost + must always be greater than 0. + + RxmtInterval + The number of seconds between LSA retransmissions, for + adjacencies belonging to this interface. Also used when + retransmitting Database Description and Link State Request + Packets. This should be well over the expected round-trip delay + between any two routers on the attached network. The setting of + this value should be conservative or needless retransmissions + will result. Sample value for a local area network: 5 seconds. + + InfTransDelay + The estimated number of seconds it takes to transmit a Link State + Update Packet over this interface. LSAs contained in the update + packet must have their age incremented by this amount before + transmission. This value should take into account the + transmission and propagation delays of the interface. It must be + greater than 0. Sample value for a local area network: 1 second. + + Router Priority + An 8-bit unsigned integer. When two routers attached to a network + both attempt to become Designated Router, the one with the + highest Router Priority takes precedence. If there is still a + tie, the router with the highest Router ID takes precedence. A + router whose Router Priority is set to 0 is ineligible to become + Designated Router on the attached network. Router Priority is + only configured for interfaces to broadcast and NBMA networks. + + HelloInterval + The length of time, in seconds, between the Hello Packets that + the router sends on the interface. This value is advertised in + the router's Hello Packets. It must be the same for all routers + attached to a common network. The smaller the HelloInterval, the + faster topological changes will be detected; however, more OSPF + routing protocol traffic will ensue. Sample value for a X.25 PDN + network: 30 seconds. Sample value for a local area network: 10 + seconds. + + + + + + + +Moy Standards Track [Page 189] + +RFC 2178 OSPF Version 2 July 1997 + + + RouterDeadInterval + After ceasing to hear a router's Hello Packets, the number of + seconds before its neighbors declare the router down. This is + also advertised in the router's Hello Packets in their + RouterDeadInterval field. This should be some multiple of the + HelloInterval (say 4). This value again must be the same for all + routers attached to a common network. + + AuType + Identifies the authentication procedure to be used on the + attached network. This value must be the same for all routers + attached to the network. See Appendix D for a discussion of the + defined authentication types. + + Authentication key + This configured data allows the authentication procedure to + verify OSPF protocol packets received over the interface. For + example, if the AuType indicates simple password, the + Authentication key would be a clear 64-bit password. + Authentication keys associated with the other OSPF authentication + types are discussed in Appendix D. + +C.4 Virtual link parameters + + Virtual links are used to restore/increase connectivity of the + backbone. Virtual links may be configured between any pair of area + border routers having interfaces to a common (non-backbone) area. + The virtual link appears as an unnumbered point-to-point link in the + graph for the backbone. The virtual link must be configured in both + of the area border routers. + + A virtual link appears in router-LSAs (for the backbone) as if it + were a separate router interface to the backbone. As such, it has + all of the parameters associated with a router interface (see Section + C.3). Although a virtual link acts like an unnumbered point-to-point + link, it does have an associated IP interface address. This address + is used as the IP source in OSPF protocol packets it sends along the + virtual link, and is set dynamically during the routing table build + process. Interface output cost is also set dynamically on virtual + links to be the cost of the intra-area path between the two routers. + The parameter RxmtInterval must be configured, and should be well + over the expected round-trip delay between the two routers. This may + be hard to estimate for a virtual link; it is better to err on the + side of making it too large. Router Priority is not used on virtual + links. + + + + + + +Moy Standards Track [Page 190] + +RFC 2178 OSPF Version 2 July 1997 + + + A virtual link is defined by the following two configurable + parameters: the Router ID of the virtual link's other endpoint, and + the (non-backbone) area through which the virtual link runs (referred + to as the virtual link's Transit area). Virtual links cannot be + configured through stub areas. + +C.5 NBMA network parameters + + OSPF treats an NBMA network much like it treats a broadcast network. + Since there may be many routers attached to the network, a Designated + Router is selected for the network. This Designated Router then + originates a network-LSA, which lists all routers attached to the + NBMA network. + + However, due to the lack of broadcast capabilities, it may be + necessary to use configuration parameters in the Designated Router + selection. These parameters will only need to be configured in those + routers that are themselves eligible to become Designated Router + (i.e., those router's whose Router Priority for the network is non- + zero), and then only if no automatic procedure for discovering + neighbors exists: + + List of all other attached routers + The list of all other routers attached to the NBMA network. Each + router is listed by its IP interface address on the network. + Also, for each router listed, that router's eligibility to become + Designated Router must be defined. When an interface to a NBMA + network comes up, the router sends Hello Packets only to those + neighbors eligible to become Designated Router, until the + identity of the Designated Router is discovered. + + PollInterval + If a neighboring router has become inactive (Hello Packets have + not been seen for RouterDeadInterval seconds), it may still be + necessary to send Hello Packets to the dead neighbor. These + Hello Packets will be sent at the reduced rate PollInterval, + which should be much larger than HelloInterval. Sample value for + a PDN X.25 network: 2 minutes. + +C.6 Point-to-MultiPoint network parameters + + On Point-to-MultiPoint networks, it may be necessary to configure the + set of neighbors that are directly reachable over the Point-to- + MultiPoint network. Each neighbor is identified by its IP address on + the Point-to-MultiPoint network. Designated Routers are not elected + on Point-to-MultiPoint networks, so the Designated Router eligibility + of configured neighbors is undefined. + + + + +Moy Standards Track [Page 191] + +RFC 2178 OSPF Version 2 July 1997 + + + Alternatively, neighbors on Point-to-MultiPoint networks may be + dynamically discovered by lower-level protocols such as Inverse ARP + ([Ref14]). + +C.7 Host route parameters + + Host routes are advertised in router-LSAs as stub networks with mask + 0xffffffff. They indicate either router interfaces to point-to-point + networks, looped router interfaces, or IP hosts that are directly + connected to the router (e.g., via a SLIP line). For each host + directly connected to the router, the following items must be + configured: + + Host IP address + The IP address of the host. + + Cost of link to host + The cost of sending a packet to the host, in terms of the link + state metric. However, since the host probably has only a single + connection to the internet, the actual configured cost in many + cases is unimportant (i.e., will have no effect on routing). + + Area ID + The OSPF area to which the host belongs. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 192] + +RFC 2178 OSPF Version 2 July 1997 + + +D. Authentication + + All OSPF protocol exchanges are authenticated. The OSPF packet + header (see Section A.3.1) includes an authentication type field, and + 64-bits of data for use by the appropriate authentication scheme + (determined by the type field). + + The authentication type is configurable on a per-interface (or + equivalently, on a per-network/subnet) basis. Additional + authentication data is also configurable on a per-interface basis. + + Authentication types 0, 1 and 2 are defined by this specification. + All other authentication types are reserved for definition by the + IANA (iana@ISI.EDU). The current list of authentication types is + described below in Table 20. + + AuType Description + ___________________________________________ + 0 Null authentication + 1 Simple password + 2 Cryptographic authentication + All others Reserved for assignment by the + IANA (iana@ISI.EDU) + + + Table 20: OSPF authentication types. + + +D.1 Null authentication + + Use of this authentication type means that routing exchanges over the + network/subnet are not authenticated. The 64-bit authentication field + in the OSPF header can contain anything; it is not examined on packet + reception. When employing Null authentication, the entire contents of + each OSPF packet (other than the 64-bit authentication field) are + checksummed in order to detect data corruption. + +D.2 Simple password authentication + + Using this authentication type, a 64-bit field is configured on a + per-network basis. All packets sent on a particular network must + have this configured value in their OSPF header 64-bit authentication + field. This essentially serves as a "clear" 64- bit password. In + addition, the entire contents of each OSPF packet (other than the + 64-bit authentication field) are checksummed in order to detect data + corruption. + + + + + +Moy Standards Track [Page 193] + +RFC 2178 OSPF Version 2 July 1997 + + + Simple password authentication guards against routers inadvertently + joining the routing domain; each router must first be configured with + its attached networks' passwords before it can participate in + routing. However, simple password authentication is vulnerable to + passive attacks currently widespread in the Internet (see [Ref16]). + Anyone with physical access to the network can learn the password and + compromise the security of the OSPF routing domain. + +D.3 Cryptographic authentication + + Using this authentication type, a shared secret key is configured in + all routers attached to a common network/subnet. For each OSPF + protocol packet, the key is used to generate/verify a "message + digest" that is appended to the end of the OSPF packet. The message + digest is a one-way function of the OSPF protocol packet and the + secret key. Since the secret key is never sent over the network in + the clear, protection is provided against passive attacks. + + The algorithms used to generate and verify the message digest are + specified implicitly by the secret key. This specification completely + defines the use of OSPF Cryptographic authentication when the MD5 + algorithm is used. + + In addition, a non-decreasing sequence number is included in each + OSPF protocol packet to protect against replay attacks. This + provides long term protection; however, it is still possible to + replay an OSPF packet until the sequence number changes. To implement + this feature, each neighbor data structure + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | Key ID | Auth Data Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cryptographic sequence number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 18: Usage of the Authentication field + in the OSPF packet header when Cryptographic + Authentication is employed + + contains a new field called the "cryptographic sequence number". + This field is initialized to zero, and is also set to zero whenever + the neighbor's state transitions to "Down". Whenever an OSPF packet + is accepted as authentic, the cryptographic sequence number is set to + the received packet's sequence number. + + + + + +Moy Standards Track [Page 194] + +RFC 2178 OSPF Version 2 July 1997 + + + This specification does not provide a rollover procedure for the + cryptographic sequence number. When the cryptographic sequence number + that the router is sending hits the maximum value, the router should + reset the cryptographic sequence number that it is sending back to 0. + After this is done, the router's neighbors will reject the router's + OSPF packets for a period of RouterDeadInterval, and then the router + will be forced to reestablish all adjacencies over the interface. + However, it is expected that many implementations will use "seconds + since reboot" (or "seconds since 1960", etc.) as the cryptographic + sequence number. Such a choice will essentially prevent rollover, + since the cryptographic sequence number field is 32 bits in length. + + The OSPF Cryptographic authentication option does not provide + confidentiality. + + When cryptographic authentication is used, the 64-bit Authentication + field in the standard OSPF packet header is redefined as shown in + Figure 18. The new field definitions are as follows: + + Key ID + This field identifies the algorithm and secret key used to create + the message digest appended to the OSPF packet. Key Identifiers + are unique per-interface (or equivalently, per- subnet). + + Auth Data Len + The length in bytes of the message digest appended to the OSPF + packet. + + Cryptographic sequence number + An unsigned 32-bit non-decreasing sequence number. Used to guard + against replay attacks. + + The message digest appended to the OSPF packet is not actually + considered part of the OSPF protocol packet: the message digest is + not included in the OSPF header's packet length, although it is + included in the packet's IP header length field. + + Each key is identified by the combination of interface and Key ID. An + interface may have multiple keys active at any one time. This + enables smooth transition from one key to another. Each key has four + time constants associated with it. These time constants can be + expressed in terms of a time-of-day clock, or in terms of a router's + local clock (e.g., number of seconds since last reboot): + + KeyStartAccept + The time that the router will start accepting packets that + have been created with the given key. + + + + +Moy Standards Track [Page 195] + +RFC 2178 OSPF Version 2 July 1997 + + + KeyStartGenerate + The time that the router will start using the key for packet + generation. + + KeyStopGenerate + The time that the router will stop using the key for packet + generation. + + KeyStopAccept + The time that the router will stop accepting packets that + have been created with the given key. + + In order to achieve smooth key transition, KeyStartAccept should be + less than KeyStartGenerate and KeyStopGenerate should be less than + KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left + unspecified, the key's lifetime is infinite. When a new key replaces + an old, the KeyStartGenerate time for the new key must be less than + or equal to the KeyStopGenerate time of the old key. + + Key storage should persist across a system restart, warm or cold, to + avoid operational issues. In the event that the last key associated + with an interface expires, it is unacceptable to revert to an + unauthenticated condition, and not advisable to disrupt routing. + Therefore, the router should send a "last authentication key + expiration" notification to the network manager and treat the key as + having an infinite lifetime until the lifetime is extended, the key + is deleted by network management, or a new key is configured. + +D.4 Message generation + + After building the contents of an OSPF packet, the authentication + procedure indicated by the sending interface's Autype value is called + before the packet is sent. The authentication procedure modifies the + OSPF packet as follows. + +D.4.1 Generating Null authentication + + When using Null authentication, the packet is modified as follows: + + (1) The Autype field in the standard OSPF header is set to + 0. + + + + + + + + + + +Moy Standards Track [Page 196] + +RFC 2178 OSPF Version 2 July 1997 + + + (2) The checksum field in the standard OSPF header is set to + the standard IP checksum of the entire contents of the packet, + starting with the OSPF packet header but excluding the 64-bit + authentication field. This checksum is calculated as the 16-bit + one's complement of the one's complement sum of all the 16-bit + words in the packet, excepting the authentication field. If the + packet's length is not an integral number of 16-bit words, the + packet is padded with a byte of zero before checksumming. + +D.4.2 Generating Simple password authentication + + When using Simple password authentication, the packet is modified as + follows: + + (1) The Autype field in the standard OSPF header is set to 1. + + (2) The checksum field in the standard OSPF header is set to the + standard IP checksum of the entire contents of the packet, + starting with the OSPF packet header but excluding the 64-bit + authentication field. This checksum is calculated as the 16-bit + one's complement of the one's complement sum of all the 16-bit + words in the packet, excepting the authentication field. If the + packet's length is not an integral number of 16-bit words, the + packet is padded with a byte of zero before checksumming. + + (3) The 64-bit authentication field in the OSPF packet header + is set to the 64-bit password (i.e., authentication key) that has + been configured for the interface. + +D.4.3 Generating Cryptographic authentication + + When using Cryptographic authentication, there may be multiple keys + configured for the interface. In this case, among the keys that are + valid for message generation (i.e, that have KeyStartGenerate <= + current time < KeyStopGenerate) choose the one with the most recent + KeyStartGenerate time. Using this key, modify the packet as follows: + + (1) The Autype field in the standard OSPF header is set to + 2. + + (2) The checksum field in the standard OSPF header is not + calculated, but is instead set to 0. + + (3) The Key ID (see Figure 18) is set to the chosen key's + Key ID. + + + + + + +Moy Standards Track [Page 197] + +RFC 2178 OSPF Version 2 July 1997 + + + (4) The Auth Data Len field is set to the length in bytes of + the message digest that will be appended to the OSPF packet. When + using MD5 as the authentication algorithm, Auth Data Len will be + 16. + + (5) The 32-bit Cryptographic sequence number (see Figure 18) + is set to a non-decreasing value (i.e., a value at least as large + as the last value sent out the interface). The precise values to + use in the cryptographic sequence number field are + implementation-specific. For example, it may be based on a + simple counter, or be based on the system's clock. + + (6) The message digest is then calculated and appended to + the OSPF packet. The authentication algorithm to be used in + calculating the digest is indicated by the key itself. Input to + the authentication algorithm consists of the OSPF packet and the + secret key. When using MD5 as the authentication algorithm, the + message digest calculation proceeds as follows: + + (a) The 16 byte MD5 key is appended to the OSPF packet. + + (b) Trailing pad and length fields are added, as specified in + [Ref17]. + + (c) The MD5 authentication algorithm is run over the + concatenation of the OSPF packet, secret key, pad and + length fields, producing a 16 byte message digest (see + [Ref17]). + + (d) The MD5 digest is written over the OSPF key (i.e., + appended to the original OSPF packet). The digest is not + counted in the OSPF packet's length field, but is included + in the packet's IP length field. Any trailing pad or + length fields beyond the digest are not counted or + transmitted. + +D.5 Message verification + + When an OSPF packet has been received on an interface, it must be + authenticated. The authentication procedure is indicated by the + setting of Autype in the standard OSPF packet header, which matches + the setting of Autype for the receiving OSPF interface. + + If an OSPF protocol packet is accepted as authentic, processing of + the packet continues as specified in Section 8.2. Packets which fail + authentication are discarded. + + + + + +Moy Standards Track [Page 198] + +RFC 2178 OSPF Version 2 July 1997 + + +D.5.1 Verifying Null authentication + + When using Null authentication, the checksum field in the OSPF header + must be verified. It must be set to the 16-bit one's complement of + the one's complement sum of all the 16-bit words in the packet, + excepting the authentication field. (If the packet's length is not + an integral number of 16-bit words, the packet is padded with a byte + of zero before checksumming.) + +D.5.2 Verifying Simple password authentication + + When using Simple password authentication, the received OSPF packet + is authenticated as follows: + + (1) The checksum field in the OSPF header must be verified. + It must be set to the 16-bit one's complement of the + one's complement sum of all the 16-bit words in the + packet, excepting the authentication field. (If the + packet's length is not an integral number of 16-bit + words, the packet is padded with a byte of zero before + checksumming.) + + (2) The 64-bit authentication field in the OSPF packet + header must be equal to the 64-bit password (i.e., + authentication key) that has been configured for the + interface. + +D.5.3 Verifying Cryptographic authentication + + When using Cryptographic authentication, the received OSPF packet is + authenticated as follows: + + (1) Locate the receiving interface's configured key having + Key ID equal to that specified in the received OSPF + packet (see Figure 18). If the key is not found, or if + the key is not valid for reception (i.e., current time < + KeyStartAccept or current time >= KeyStopAccept), the + OSPF packet is discarded. + + (2) If the cryptographic sequence number found in the OSPF + header (see Figure 18) is less than the cryptographic + sequence number recorded in the sending neighbor's data + structure, the OSPF packet is discarded. + + (3) Verify the appended message digest in the following + steps: + + (a) The received digest is set aside. + + + +Moy Standards Track [Page 199] + +RFC 2178 OSPF Version 2 July 1997 + + + (b) A new digest is calculated, as specified in Step 6 + of Section D.4.3. + + (c) The calculated and received digests are compared. If + they do not match, the OSPF packet is discarded. If + they do match, the OSPF protocol packet is accepted + as authentic, and the "cryptographic sequence + number" in the neighbor's data structure is set to + the sequence number found in the packet's OSPF + header. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 200] + +RFC 2178 OSPF Version 2 July 1997 + + +E. An algorithm for assigning Link State IDs + + The Link State ID in AS-external-LSAs and summary-LSAs is usually set + to the described network's IP address. However, if necessary one or + more of the network's host bits may be set in the Link State ID. + This allows the router to originate separate LSAs for networks having + the same address, yet different masks. Such networks can occur in the + presence of supernetting and subnet 0s (see [Ref10]). + + This appendix gives one possible algorithm for setting the host bits + in Link State IDs. The choice of such an algorithm is a local + decision. Separate routers are free to use different algorithms, + since the only LSAs affected are the ones that the router itself + originates. The only requirement on the algorithms used is that the + network's IP address should be used as the Link State ID whenever + possible; this maximizes interoperability with OSPF implementations + predating RFC 1583. + + The algorithm below is stated for AS-external-LSAs. This is only for + clarity; the exact same algorithm can be used for summary-LSAs. + Suppose that the router wishes to originate an AS-external-LSA for a + network having address NA and mask NM1. The following steps are then + used to determine the LSA's Link State ID: + + (1) Determine whether the router is already originating an AS- + external-LSA with Link State ID equal to NA (in such an LSA the + router itself will be listed as the LSA's Advertising Router). + If not, the Link State ID is set equal to NA and the algorithm + terminates. Otherwise, + + (2) Obtain the network mask from the body of the already existing + AS-external-LSA. Call this mask NM2. There are then two cases: + + o NM1 is longer (i.e., more specific) than NM2. In this case, + set the Link State ID in the new LSA to be the network + [NA,NM1] with all the host bits set (i.e., equal to NA or'ed + together with all the bits that are not set in NM1, which is + network [NA,NM1]'s broadcast address). + + o NM2 is longer than NM1. In this case, change the existing + LSA (having Link State ID of NA) to reference the new + network [NA,NM1] by incrementing the sequence number, + changing the mask in the body to NM1 and inserting the cost + of the new network. Then originate a new LSA for the old + network [NA,NM2], with Link State ID equal to NA or'ed + together with the bits that are not set in NM2 (i.e., + network [NA,NM2]'s broadcast address). + + + + +Moy Standards Track [Page 201] + +RFC 2178 OSPF Version 2 July 1997 + + + The above algorithm assumes that all masks are contiguous; this + ensures that when two networks have the same address, one mask is + more specific than the other. The algorithm also assumes that no + network exists having an address equal to another network's broadcast + address. Given these two assumptions, the above algorithm always + produces unique Link State IDs. The above algorithm can also be + reworded as follows: When originating an AS-external-LSA, try to use + the network number as the Link State ID. If that produces a + conflict, examine the two networks in conflict. One will be a subset + of the other. For the less specific network, use the network number + as the Link State ID and for the more specific use the network's + broadcast address instead (i.e., flip all the "host" bits to 1). If + the most specific network was originated first, this will cause you + to originate two LSAs at once. + + As an example of the algorithm, consider its operation when the + following sequence of events occurs in a single router (Router A). + + (1) Router A wants to originate an AS-external-LSA for + [10.0.0.0,255.255.255.0]: + + (a) A Link State ID of 10.0.0.0 is used. + + (2) Router A then wants to originate an AS-external-LSA for + [10.0.0.0,255.255.0.0]: + + (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a + new Link State ID of 10.0.0.255. + + (b) A Link State ID of 10.0.0.0 is used for + [10.0.0.0,255.255.0.0]. + + (3) Router A then wants to originate an AS-external-LSA for + [10.0.0.0,255.0.0.0]: + + (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a + new Link State ID of 10.0.255.255. + + (b) A Link State ID of 10.0.0.0 is used for + [10.0.0.0,255.0.0.0]. + + (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID + of 10.0.0.255. + + + + + + + + +Moy Standards Track [Page 202] + +RFC 2178 OSPF Version 2 July 1997 + + +F. Multiple interfaces to the same network/subnet + + There are at least two ways to support multiple physical interfaces + to the same IP subnet. Both methods will interoperate with + implementations of RFC 1583 (and of course this memo). The two + methods are sketched briefly below. An assumption has been made that + each interface has been assigned a separate IP address (otherwise, + support for multiple interfaces is more of a link-level or ARP issue + than an OSPF issue). + + Method 1: + Run the entire OSPF functionality over both interfaces, sending and + receiving hellos, flooding, supporting separate interface and + neighbor FSMs for each interface, etc. When doing this all other + routers on the subnet will treat the two interfaces as separate + neighbors, since neighbors are identified (on broadcast and NBMA + networks) by their IP address. + + Method 1 has the following disadvantages: + + (1) You increase the total number of neighbors and adjacencies. + + (2) You lose the bidirectionality test on both interfaces, since + bidirectionality is based on Router ID. + + (3) You have to consider both interfaces together during the + Designated Router election, since if you declare both to be + DR simultaneously you can confuse the tie-breaker (which is + Router ID). + + Method 2: + Run OSPF over only one interface (call it the primary interface), + but include both the primary and secondary interfaces in your + Router-LSA. + + Method 2 has the following disadvantages: + + (1) You lose the bidirectionality test on the secondary + interface. + + (2) When the primary interface fails, you need to promote the + secondary interface to primary status. + + + + + + + + + +Moy Standards Track [Page 203] + +RFC 2178 OSPF Version 2 July 1997 + + +G. Differences from RFC 1583 + + This section documents the differences between this memo and RFC + 1583. All differences are backward-compatible. Implementations of + this memo and of RFC 1583 will interoperate. + +G.1 Enhancements to OSPF authentication + + An additional OSPF authentication type has been added: the + Cryptographic authentication type. This has been defined so that any + arbitrary "Keyed Message Digest" algorithm can be used for packet + authentication. Operation using the MD5 algorithm is completely + specified (see Appendix D). + + A number of other changes were also made to OSPF packet + authentication, affecting the following Sections: + + o The authentication type is now specified per-interface, + rather than per-area (Sections 6, 9, C.2 and C.3). + + o The OSPF packet header checksum is now considered part of + the authentication procedure, and so has been moved out of the + packet send and receive logic (Sections 8.1 and 8.2) and into the + description of authentication types (Appendix D). + + o In Appendix D, sections detailing message generation and + message verification have been added. + + o For the OSPF Cryptographic authentication type, a discussion + of key management, including the requirement for simultaneous + support of multiple keys, key lifetimes and smooth key + transition, has been added to Appendix D. + +G.2 Addition of Point-to-MultiPoint interface + + This memo adds an additional method for running OSPF over non- + broadcast networks: the Point-to-Multipoint network. To implement + this addition, the language of RFC 1583 has been altered slightly. + References to "multi-access" networks have been deleted. The term + "non-broadcast networks" is now used to describe networks which can + connect many routers, but which do not natively support + broadcast/multicast (such as a public Frame relay network). Over + non-broadcast networks, there are two options for running OSPF: + modelling them as "NBMA networks" or as "Point-to-MultiPoint + networks". NBMA networks require full mesh connectivity between + routers; when employing NBMA networks in the presence of partial mesh + connectivity, multiple NBMA networks must be configured, as described + in [Ref15]. In contrast, Point-to-Multipoint networks have been + + + +Moy Standards Track [Page 204] + +RFC 2178 OSPF Version 2 July 1997 + + + designed to work simply and naturally when faced with partial mesh + connectivity. + + The addition of Point-to-MultiPoint networks has impacted the text in + many places, which are briefly summarized below: + + o Section 2 describing the OSPF link-state database has been + split into additional subsections, with one of the subsections + (Section 2.1.1) describing the differing map representations of + the two non-broadcast network options. This subsection also + contrasts the NBMA network and Point- to-MultiPoint network + options, and describes the situations when one is preferable to + the other. + + o In contrast to NBMA networks, Point-to-MultiPoint networks + have the following properties. Adjacencies are established + between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 and + 10.4). There is no Designated Router or Backup Designated Router + for a Point-to-MultiPoint network (Sections 7.3 and 7.4). No + network-LSA is originated for Point-to-MultiPoint networks + (Sections 12.4.2 and A.4.3). Router Priority is not configured + for Point-to-MultiPoint interfaces, nor for neighbors on Point- + to-MultiPoint networks (Sections C.3 and C.6). + + o The Interface FSM for a Point-to-MultiPoint interface is + identical to that used for point-to-point interfaces. Two states + are possible: "Down" and "Point-to-Point" (Section 9.3). + + o When originating a router-LSA, and Point-to-MultiPoint + interface is reported as a collection of "point-to-point links" + to all of the interface's adjacent neighbors, together with a + single stub link advertising the interface's IP address with a + cost of 0 (Section 12.4.1.4). + + o When flooding out a non-broadcast interface (when either in + NBMA or Point-to-MultiPoint mode) the Link State Update or Link + State Acknowledgment packet must be replicated in order to be + sent to each of the interface's neighbors (see Sections 13.3 and + 13.5). + +G.3 Support for overlapping area ranges + + RFC 1583 requires that all networks falling into a given area range + actually belong to a single area. This memo relaxes that restriction. + This is useful in the following example. Suppose that [10.0.0.0, + 255.0.0.0] is carved up into subnets. Most of these subnets are + assigned to a single OSPF area (call it Area X), while a few subnets + are assigned to other areas. In order to get this configuration to + + + +Moy Standards Track [Page 205] + +RFC 2178 OSPF Version 2 July 1997 + + + work with RFC 1583, you must not summarize the subnets of Area X with + the single range [10.0.0.0, 255.0.0.0], because then the subnets of + 10.0.0.0 belonging to other areas would become unreachable. However, + with this memo you can summarize the subnets in Area X, provided that + the subnets belonging to other areas are not summarized. + + Implementation details for this change can be found in Sections 11.1 + and 16.2. + +G.4 A modification to the flooding algorithm + + The OSPF flooding algorithm has been modified as follows. When a Link + State Update Packet is received that contains an LSA instance which + is actually less recent than the the router's current database copy, + the router will now in most cases respond by flooding back its + database copy. This is in contrast to the RFC 1583 behavior, which + was to simply throw the received LSA away. + + Detailed description of the change can be found in Step 8 of Section + 13. + + This change improves MaxAge processing. There are times when MaxAge + LSAs stay in a router's database for extended intervals: 1) when they + are stuck in a retransmission queue on a slow link or 2) when a + router is not properly flushing them from its database, due to + software bugs. The prolonged existence of these MaxAge LSAs can + inhibit the flooding of new instances of the LSA. New instances + typically start with LS sequence number equal to + InitialSequenceNumber, and are treated as less recent (and hence were + discarded according to RFC 1583) by routers still holding MaxAge + instances. However, with the above change to flooding, a router + holding a MaxAge instance will flood back the MaxAge instance. When + this flood reaches the LSA's originator, it will then pick the next + highest LS sequence number and reflood, overwriting the MaxAge + instance. + +G.5 Introduction of the MinLSArrival constant + + OSPF limits the frequency that new instances of any particular LSA + can be accepted during flooding. This is extra protection, just in + case a neighboring router is violating the mandated limit on LSA + (re)originations (namely, one per LSA in any MinLSInterval). + + + + + + + + + +Moy Standards Track [Page 206] + +RFC 2178 OSPF Version 2 July 1997 + + + In RFC 1583, the frequency at which new LSA instances were accepted + was also set equal to once every MinLSInterval seconds. However, in + some circumstances this led to unwanted link state retransmissions, + even when the LSA originator was obeying the MinLSInterval limit on + originations. This was due to either 1) choice of clock granularity + in some OSPF implementations or 2) differing clock speed in + neighboring routers. + + To alleviate this problem, the frequency at which new LSA instances + are accepted during flooding has now been increased to once every + MinLSArrival seconds, whose value is set to 1. This change is + reflected in Steps 5a and 5d of Section 13, and in Appendix B. + +G.6 Optionally advertising point-to-point links as subnets + + When describing a point-to-point interface in its router-LSA, a + router may now advertise a stub link to the point-to-point network's + subnet. This is specified as an alternative to the RFC 1583 behavior, + which is to advertise a stub link to the neighbor's IP address. See + Sections 12.4.1 and 12.4.1.1 for details. + +G.7 Advertising same external route from multiple areas + + This document fixes routing loops which can occur in RFC 1583 when + the same external destination is advertised by AS boundary routers in + separate areas. There are two manifestations of this problem. The + first, discovered by Dennis Ferguson, occurs when an aggregated + forwarding address is in use. In this case, the desirability of the + forwarding address can change for the worse as a packet crosses an + area aggregation boundary on the way to the forwarding address, which + in turn can cause the preference of AS-external-LSAs to change, + resulting in a routing loop. + + The second manifestation was discovered by Richard Woundy. It is + caused by an incomplete application of OSPF's preference of intra- + area routes over inter-area routes: paths to any given + ASBR/forwarding address are selected first based on intra-area + preference, while the comparison between separate ASBRs/forwarding + addresses is driven only by cost, ignoring intra-area preference. His + example is replicated in Figure 19. Both router A3 and router B3 are + originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 + metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, + based on shorter cost to ASBR B3 (via B1->B2->B3). However, the + shorter route to B3 is not available to B1, due to B1's preference + for the (higher cost) intra-area route to B3 through Area A. This + leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a + routing loop. + + + + +Moy Standards Track [Page 207] + +RFC 2178 OSPF Version 2 July 1997 + + + The following two changes have been made to prevent these routing + loops: + + o When originating a type 3 summary-LSA for a configured area + address range, the cost of the summary-LSA is now set to the + maximum cost of the range's component networks (instead of the + previous algorithm which set the cost to the minimum component + cost). This change affects Sections 3.5 and 12.4.3, Figures 7 + and 8, and Tables 6 and 13. + + o The preference rules for choosing among multiple AS- + external-LSAs have been changed. Where previously cost was the + only determining factor, now the preference is driven first by + type of path (intra-area or inter-area, through non-backbone area + or through backbone) to the ASBR/forwarding address, using cost + only to break ties. This change affects Sections 16.4 and 16.4.1. + + After implementing this change, the example in Figure 19 is modified + as follows. Router A1 now chooses A3 as the next + + 10.0.0.0/8 + ---------- + | + +----+ + | XX | + +----+ + RIP / \ RIP + --------------------- -------------------- + ! ! + ! ! + +----+ +----+ 1 +----+......+----+.... + | A3 |------| A1 |---------------| B1 |------| B3 | . + +----+ 6 +----+ +----+ 8 +----+ . + 1| . / . + OSPF backbone | . / . + +----+ 2 / . + | B2 |------- Area A. + +----+................ + + Figure 19: Example routing loop when the + same external route is advertised from multiple + areas + + hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for + both choices is that ASBRs/forwarding addresses are now chosen based + first on intra-area preference, and then by cost. + + + + + +Moy Standards Track [Page 208] + +RFC 2178 OSPF Version 2 July 1997 + + + Unfortunately, this change is not backward compatible. While the + change prevents routing loops when all routers run the new preference + rules, it can actually create routing loops when some routers are + running the new preference rules and other routers implement RFC + 1583. For this reason, a new configuration parameter has been added: + RFC1583Compatibility. Only when RFC1583Compatibility is set to + "disabled" will the new preference rules take effect. See Appendix C + for more details. + +G.8 Retransmission of initial Database Description packets + + This memo allows retransmission of initial Database Description + packets, without resetting the state of the adjacency. In some + environments, retransmission of the initial Database Description + packet may be unavoidable. For example, the link delay incurred by a + satellite link may exceed the value configured for an interface's + RxmtInterval. In RFC 1583 such an environment prevents a full + adjacency from ever forming. + + In this memo, changes have been made in the reception of Database + Description packets so that retransmitted initial Database + Description packets are treated identically to any other + retransmitted Database Description packets. See Section 10.6 for + details. + +G.9 Detecting interface MTU mismatches + + When two neighboring routers have a different interface MTU for their + common network segment, serious problems can ensue: large packets are + prevented from being successfully transferred from one router to the + other, impairing OSPF's flooding algorithm and possibly creating + "black holes" for user data traffic. + + This memo provides a fix for the interface MTU mismatch problem by + advertising the interface MTU in Database Description packets. When a + router receives a Database description packet advertising an MTU + larger than the router can receive, the router drops the Database + Description packet. This prevents an adjacency from forming, telling + OSPF flooding and user data traffic to avoid the connection between + the two routers. For more information, see Sections 10.6, 10.8, and + A.3.3. + +G.10 Deleting the TOS routing option + + The TOS routing option has been deleted from OSPF. This action was + required by the Internet standards process ([Ref24]), due to lack of + implementation experience with OSPF's TOS routing. However, for + backward compatibility the formats of OSPF's various LSAs remain + + + +Moy Standards Track [Page 209] + +RFC 2178 OSPF Version 2 July 1997 + + + unchanged, maintaining the ability to specify TOS metrics in router- + LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-LSAs (see + Sections 12.3, A.4.2, A.4.4, and A.4.5). + + To see OSPF's original TOS routing design, consult [Ref9]. + +Security Considerations + + All OSPF protocol exchanges are authenticated. OSPF supports multiple + types of authentication; the type of authentication in use can be + configured on a per network segment basis. One of OSPF's + authentication types, namely the Cryptographic authentication option, + is believed to be secure against passive attacks and provide + significant protection against active attacks. When using the + Cryptographic authentication option, each router appends a "message + digest" to its transmitted OSPF packets. Receivers then use the + shared secret key and received digest to verify that each received + OSPF packet is authentic. + + The quality of the security provided by the Cryptographic + authentication option depends completely on the strength of the + message digest algorithm (MD5 is currently the only message digest + algorithm specified), the strength of the key being used, and the + correct implementation of the security mechanism in all communicating + OSPF implementations. It also requires that all parties maintain the + secrecy of the shared secret key. + + None of the OSPF authentication types provide confidentiality. Nor do + they protect against traffic analysis. Key management is also not + addressed by this memo. + + For more information, see Sections 8.1, 8.2, and Appendix D. + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 210] + +RFC 2178 OSPF Version 2 July 1997 + + +Author's Address + + John Moy + Cascade Communications Corp. + 5 Carlisle Road + Westford, MA 01886 + + Phone: 508-952-1367 + Fax: 508-692-9214 + Email: jmoy@casc.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy Standards Track [Page 211] + -- cgit v1.2.3