summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2328.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2328.txt')
-rw-r--r--doc/rfc/rfc2328.txt12201
1 files changed, 12201 insertions, 0 deletions
diff --git a/doc/rfc/rfc2328.txt b/doc/rfc/rfc2328.txt
new file mode 100644
index 0000000..68ea1f2
--- /dev/null
+++ b/doc/rfc/rfc2328.txt
@@ -0,0 +1,12201 @@
+
+
+
+
+Network Working Group J. Moy
+Request for Comments: 2328 Ascend Communications, Inc.
+STD: 54 April 1998
+Obsoletes: 2178
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+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 2178 are explained in
+ Appendix G. All differences are backward-compatible in nature.
+
+
+
+
+Moy Standards Track [Page 1]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Implementations of this memo and of RFCs 2178, 1583, and 1247 will
+ interoperate.
+
+ Please send comments to ospf@gated.cornell.edu.
+
+Table of Contents
+
+ 1 Introduction ........................................... 6
+ 1.1 Protocol Overview ...................................... 6
+ 1.2 Definitions of commonly used terms ..................... 8
+ 1.3 Brief history of link-state routing technology ........ 11
+ 1.4 Organization of this document ......................... 12
+ 1.5 Acknowledgments ....................................... 12
+ 2 The link-state database: organization and calculations 13
+ 2.1 Representation of routers and networks ................ 13
+ 2.1.1 Representation of non-broadcast networks .............. 15
+ 2.1.2 An example link-state database ........................ 18
+ 2.2 The shortest-path tree ................................ 21
+ 2.3 Use of external routing information ................... 23
+ 2.4 Equal-cost multipath .................................. 26
+ 3 Splitting the AS into Areas ........................... 26
+ 3.1 The backbone of the Autonomous System ................. 27
+ 3.2 Inter-area routing .................................... 27
+ 3.3 Classification of routers ............................. 28
+ 3.4 A sample area configuration ........................... 29
+ 3.5 IP subnetting support ................................. 35
+ 3.6 Supporting stub areas ................................. 37
+ 3.7 Partitions of areas ................................... 38
+ 4 Functional Summary .................................... 40
+ 4.1 Inter-area routing .................................... 41
+ 4.2 AS external routes .................................... 41
+ 4.3 Routing protocol packets .............................. 42
+ 4.4 Basic implementation requirements ..................... 43
+ 4.5 Optional OSPF capabilities ............................ 46
+ 5 Protocol data structures .............................. 47
+ 6 The Area Data Structure ............................... 49
+ 7 Bringing Up Adjacencies ............................... 52
+ 7.1 The Hello Protocol .................................... 52
+ 7.2 The Synchronization of Databases ...................... 53
+ 7.3 The Designated Router ................................. 54
+ 7.4 The Backup Designated Router .......................... 56
+ 7.5 The graph of adjacencies .............................. 56
+
+
+
+Moy Standards Track [Page 2]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 8 Protocol Packet Processing ............................ 58
+ 8.1 Sending protocol packets .............................. 58
+ 8.2 Receiving protocol packets ............................ 61
+ 9 The Interface Data Structure .......................... 63
+ 9.1 Interface states ...................................... 67
+ 9.2 Events causing interface state changes ................ 70
+ 9.3 The Interface state machine ........................... 72
+ 9.4 Electing the Designated Router ........................ 75
+ 9.5 Sending Hello packets ................................. 77
+ 9.5.1 Sending Hello packets on NBMA networks ................ 79
+ 10 The Neighbor Data Structure ........................... 80
+ 10.1 Neighbor states ....................................... 83
+ 10.2 Events causing neighbor state changes ................. 87
+ 10.3 The Neighbor state machine ............................ 89
+ 10.4 Whether to become adjacent ............................ 95
+ 10.5 Receiving Hello Packets ............................... 96
+ 10.6 Receiving Database Description Packets ................ 99
+ 10.7 Receiving Link State Request Packets ................. 102
+ 10.8 Sending Database Description Packets ................. 103
+ 10.9 Sending Link State Request Packets ................... 104
+ 10.10 An Example ........................................... 105
+ 11 The Routing Table Structure .......................... 107
+ 11.1 Routing table lookup ................................. 111
+ 11.2 Sample routing table, without areas .................. 111
+ 11.3 Sample routing table, with areas ..................... 112
+ 12 Link State Advertisements (LSAs) ..................... 115
+ 12.1 The LSA Header ....................................... 116
+ 12.1.1 LS age ............................................... 116
+ 12.1.2 Options .............................................. 117
+ 12.1.3 LS type .............................................. 117
+ 12.1.4 Link State ID ........................................ 117
+ 12.1.5 Advertising Router ................................... 119
+ 12.1.6 LS sequence number ................................... 120
+ 12.1.7 LS checksum .......................................... 121
+ 12.2 The link state database .............................. 121
+ 12.3 Representation of TOS ................................ 122
+ 12.4 Originating LSAs ..................................... 123
+ 12.4.1 Router-LSAs .......................................... 126
+ 12.4.1.1 Describing point-to-point interfaces ................. 130
+ 12.4.1.2 Describing broadcast and NBMA interfaces ............. 130
+ 12.4.1.3 Describing virtual links ............................. 131
+ 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 131
+
+
+
+Moy Standards Track [Page 3]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 12.4.1.5 Examples of router-LSAs .............................. 132
+ 12.4.2 Network-LSAs ......................................... 133
+ 12.4.2.1 Examples of network-LSAs ............................. 134
+ 12.4.3 Summary-LSAs ......................................... 135
+ 12.4.3.1 Originating summary-LSAs into stub areas ............. 137
+ 12.4.3.2 Examples of summary-LSAs ............................. 138
+ 12.4.4 AS-external-LSAs ..................................... 139
+ 12.4.4.1 Examples of AS-external-LSAs ......................... 140
+ 13 The Flooding Procedure ............................... 143
+ 13.1 Determining which LSA is newer ....................... 146
+ 13.2 Installing LSAs in the database ...................... 147
+ 13.3 Next step in the flooding procedure .................. 148
+ 13.4 Receiving self-originated LSAs ....................... 151
+ 13.5 Sending Link State Acknowledgment packets ............ 152
+ 13.6 Retransmitting LSAs .................................. 154
+ 13.7 Receiving link state acknowledgments ................. 155
+ 14 Aging The Link State Database ........................ 156
+ 14.1 Premature aging of LSAs .............................. 157
+ 15 Virtual Links ........................................ 158
+ 16 Calculation of the routing table ..................... 160
+ 16.1 Calculating the shortest-path tree for an area ....... 161
+ 16.1.1 The next hop calculation ............................. 167
+ 16.2 Calculating the inter-area routes .................... 178
+ 16.3 Examining transit areas' summary-LSAs ................ 170
+ 16.4 Calculating AS external routes ....................... 173
+ 16.4.1 External path preferences ............................ 175
+ 16.5 Incremental updates -- summary-LSAs .................. 175
+ 16.6 Incremental updates -- AS-external-LSAs .............. 177
+ 16.7 Events generated as a result of routing table changes 177
+ 16.8 Equal-cost multipath ................................. 178
+ Footnotes ............................................ 179
+ References ........................................... 183
+ A OSPF data formats .................................... 185
+ A.1 Encapsulation of OSPF packets ........................ 185
+ A.2 The Options field .................................... 187
+ A.3 OSPF Packet Formats .................................. 189
+ A.3.1 The OSPF packet header ............................... 190
+ A.3.2 The Hello packet ..................................... 193
+ A.3.3 The Database Description packet ...................... 195
+ A.3.4 The Link State Request packet ........................ 197
+ A.3.5 The Link State Update packet ......................... 199
+ A.3.6 The Link State Acknowledgment packet ................. 201
+
+
+
+Moy Standards Track [Page 4]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ A.4 LSA formats .......................................... 203
+ A.4.1 The LSA header ....................................... 204
+ A.4.2 Router-LSAs .......................................... 206
+ A.4.3 Network-LSAs ......................................... 210
+ A.4.4 Summary-LSAs ......................................... 212
+ A.4.5 AS-external-LSAs ..................................... 214
+ B Architectural Constants .............................. 217
+ C Configurable Constants ............................... 219
+ C.1 Global parameters .................................... 219
+ C.2 Area parameters ...................................... 220
+ C.3 Router interface parameters .......................... 221
+ C.4 Virtual link parameters .............................. 224
+ C.5 NBMA network parameters .............................. 224
+ C.6 Point-to-MultiPoint network parameters ............... 225
+ C.7 Host route parameters ................................ 226
+ D Authentication ....................................... 227
+ D.1 Null authentication .................................. 227
+ D.2 Simple password authentication ....................... 228
+ D.3 Cryptographic authentication ......................... 228
+ D.4 Message generation ................................... 231
+ D.4.1 Generating Null authentication ....................... 231
+ D.4.2 Generating Simple password authentication ............ 232
+ D.4.3 Generating Cryptographic authentication .............. 232
+ D.5 Message verification ................................. 234
+ D.5.1 Verifying Null authentication ........................ 234
+ D.5.2 Verifying Simple password authentication ............. 234
+ D.5.3 Verifying Cryptographic authentication ............... 235
+ E An algorithm for assigning Link State IDs ............ 236
+ F Multiple interfaces to the same network/subnet ....... 239
+ G Differences from RFC 2178 ............................ 240
+ G.1 Flooding modifications ............................... 240
+ G.2 Changes to external path preferences ................. 241
+ G.3 Incomplete resolution of virtual next hops ........... 241
+ G.4 Routing table lookup ................................. 241
+ Security Considerations .............................. 243
+ Author's Address ..................................... 243
+ Full Copyright Statement ............................. 244
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 5]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 6]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 7]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 8]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 9]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 10]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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.
+
+
+
+
+Moy Standards Track [Page 11]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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
+
+
+
+Moy Standards Track [Page 12]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 13]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+
+ **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
+
+ **FROM**
+ +---+ +---+
+ |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
+
+
+
+
+Moy Standards Track [Page 14]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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
+
+
+
+Moy Standards Track [Page 15]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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'
+
+
+
+Moy Standards Track [Page 16]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+
+
+ **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 17]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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. 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.
+
+
+
+
+
+Moy Standards Track [Page 18]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ +
+ | 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
+
+
+
+Moy Standards Track [Page 19]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Figure 2: A sample Autonomous System
+
+ **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.
+
+
+
+Moy Standards Track [Page 20]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ **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.
+
+ 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).
+
+
+ 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
+
+
+
+Moy Standards Track [Page 21]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ 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 22]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 23]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+ 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
+
+
+
+Moy Standards Track [Page 24]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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.
+
+
+
+
+Moy Standards Track [Page 25]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+ 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
+
+
+
+Moy Standards Track [Page 26]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 27]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 28]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+ 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
+
+
+
+Moy Standards Track [Page 29]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ ...........................
+ . + .
+ . | 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 .
+ . | . . | .
+ . +---------+ . . +--------+ .
+
+
+
+Moy Standards Track [Page 30]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ . N10 . . N7 .
+ . . .Area 2 .
+ .Area 3 . ................................
+ ..........................
+
+ Figure 6: A sample OSPF area configuration
+
+ 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 31]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ **FROM**
+
+ |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 32]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ **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.
+
+
+
+
+Moy Standards Track [Page 33]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 34]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+ 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.
+
+ load share between the two for traffic to Network N8.
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 35]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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]).
+
+
+
+Moy Standards Track [Page 36]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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
+
+
+
+Moy Standards Track [Page 37]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+
+
+Moy Standards Track [Page 38]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 39]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 40]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 41]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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.
+
+
+
+
+Moy Standards Track [Page 42]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 43]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 44]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Table 9: OSPF link state advertisements (LSAs).
+
+
+
+ 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].
+
+ 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
+
+
+
+
+
+Moy Standards Track [Page 45]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ Other capabilities can be negotiated during the Database
+ Exchange process. This is accomplished by specifying the
+ optional capabilities in Database Description packets. A
+
+
+
+Moy Standards Track [Page 46]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 47]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 48]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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).
+
+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.
+
+ 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).
+
+
+
+Moy Standards Track [Page 49]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+
+ +----+
+ |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
+
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 50]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 51]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 52]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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
+
+
+
+Moy Standards Track [Page 53]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 54]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 55]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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.
+
+
+
+
+
+Moy Standards Track [Page 56]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+ +---+ +---+
+ |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
+
+
+
+
+
+Moy Standards Track [Page 57]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+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:
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 58]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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
+
+
+
+Moy Standards Track [Page 59]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+ directly to the neighbor. On multi-access networks, this means
+ that retransmissions should be sent to the neighbor's IP
+ address.
+
+ 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.
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 60]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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:
+
+
+
+Moy Standards Track [Page 61]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+ (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.
+
+
+
+
+
+Moy Standards Track [Page 62]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 63]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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. 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.
+
+
+
+Moy Standards Track [Page 64]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+
+Moy Standards Track [Page 65]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 66]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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. 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
+
+
+
+Moy Standards Track [Page 67]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ +----+ 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
+
+
+ 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
+
+
+
+
+
+
+
+Moy Standards Track [Page 68]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ facilitate this, such interfaces are advertised in router-
+ LSAs as single host routes, whose destination is the IP
+ interface address.[4]
+
+ 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
+
+
+
+Moy Standards Track [Page 69]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 70]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+
+
+
+Moy Standards Track [Page 71]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 72]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+
+Moy Standards Track [Page 73]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+ 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
+
+
+
+Moy Standards Track [Page 74]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 75]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 76]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 77]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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-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.
+
+
+
+
+
+
+
+Moy Standards Track [Page 78]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 79]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 80]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 81]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 82]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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 83]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ +----+
+ |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 InactivityTimer always forces Down State,
+ Event LLDown always forces Down State
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 84]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ +-------+
+ |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
+
+ 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
+
+
+
+
+Moy Standards Track [Page 85]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ Full
+ In this state, the neighboring routers are fully adjacent.
+ These adjacencies will now appear in router-LSAs and
+ network-LSAs.
+
+
+
+
+
+Moy Standards Track [Page 86]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+
+
+Moy Standards Track [Page 87]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ portions of the database. This is indicated by the Link
+ state request list becoming empty after the Database
+ Exchange process has completed.
+
+ 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
+
+
+
+Moy Standards Track [Page 88]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+
+Moy Standards Track [Page 89]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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
+
+
+
+Moy Standards Track [Page 90]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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-
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 91]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 92]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+ This Database Description Packet should be otherwise
+ empty (see Section 10.8).
+
+
+ State(s): Exchange or greater
+
+ Event: BadLSReq
+
+
+
+
+Moy Standards Track [Page 93]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 94]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 95]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+
+
+Moy Standards Track [Page 96]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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. For these network types, the neighbor
+ structure's Router Priority field, Neighbor's Designated Router
+ field, and Neighbor's Backup Designated Router field are also
+ set equal to the corresponding fields found in the received
+ Hello Packet; changes in these fields should be noted for
+ possible use in the steps below. 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:
+
+
+
+
+
+
+Moy Standards Track [Page 97]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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, if a change in the neighbor's Router Priority field
+ was noted, the receiving interface's state machine is
+ scheduled with the event NeighborChange.
+
+ o If the neighbor is both declaring itself to be Designated
+ Router (Hello Packet's Designated Router field = Neighbor IP
+ address) and the Backup Designated Router field in the
+ 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.
+
+ o If the neighbor is declaring itself to be Backup Designated
+ Router (Hello Packet's 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.
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 98]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 99]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 100]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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
+
+
+
+Moy Standards Track [Page 101]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 102]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+
+
+Moy Standards Track [Page 103]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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:
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 104]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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. LSAs on the Link state request list that have been
+ requested, but not yet received, are packaged into Link State
+ Request packets for retransmission 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.
+
+
+ 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
+
+
+
+Moy Standards Track [Page 105]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+
+
+
+ +---+ +---+
+ |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
+
+
+
+
+
+Moy Standards Track [Page 106]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Figure 14: An adjacency bring-up example
+
+
+
+
+
+ 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.
+
+
+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.
+
+
+
+
+Moy Standards Track [Page 107]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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]
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 108]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 decreasing 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.
+
+ 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
+
+
+
+
+Moy Standards Track [Page 109]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 110]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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]
+
+ Several routing table entries may match the destination address.
+ In this case, the "best match" is the routing table entry that
+ provides the most specific (longest) match. Another way of
+ saying this is to choose the 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 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. (Note that for any single routing table entry,
+ multiple paths may be possible. In these cases, the calculations
+ in Sections 16.1, 16.2, and 16.4 always yield the paths having
+ the most preferential path-type, as described in Section 11).
+
+ If there is no matching routing table entry, or the best match
+ routing table entry is one of the above "discard" routing table
+ entries, then the packet's IP destination is considered
+ unreachable. Instead of being forwarded, the packet should then
+ be discarded and an ICMP destination unreachable message should
+ be returned to the packet's source.
+
+ 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
+
+
+
+Moy Standards Track [Page 111]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 112]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+ 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).
+
+ 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.
+
+ 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).
+
+
+
+Moy Standards Track [Page 113]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 link are shown
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 114]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 115]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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
+
+
+
+Moy Standards Track [Page 116]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ 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
+
+
+
+Moy Standards Track [Page 117]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+ 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).
+
+ 16.
+
+
+ Actually, for Type 3 summary-LSAs (LS type = 3) and AS-
+ external-LSAs (LS type = 5), the Link State ID may
+
+
+
+Moy Standards Track [Page 118]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 119]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 120]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+
+
+Moy Standards Track [Page 121]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ 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
+
+
+
+Moy Standards Track [Page 122]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ integer, and the IP packet header's TOS field is expressed in
+ the binary TOS values used in [Ref12].
+
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 123]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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).
+
+
+
+Moy Standards Track [Page 124]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ (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).
+
+
+
+
+Moy Standards Track [Page 125]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 126]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ ....................................
+ . 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
+
+ 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
+ (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 area. Bit E
+ should never be set in a router-LSA for a stub area (stub
+ areas cannot contain AS boundary routers).
+
+
+
+Moy Standards Track [Page 127]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 128]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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:
+
+
+ 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).
+
+
+
+
+
+Moy Standards Track [Page 129]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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:
+
+ 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:
+
+
+
+
+Moy Standards Track [Page 130]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 131]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ ; 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
+
+
+
+Moy Standards Track [Page 132]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+ 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.
+
+
+
+Moy Standards Track [Page 133]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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):
+
+ ; Network-LSA for Network N3
+
+
+
+Moy Standards Track [Page 134]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 135]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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]
+
+ 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
+
+
+
+Moy Standards Track [Page 136]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 137]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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.
+
+
+
+
+
+Moy Standards Track [Page 138]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 139]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+
+
+
+
+
+Moy Standards Track [Page 140]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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,
+
+
+
+Moy Standards Track [Page 141]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+ +
+ |
+ +---+.....|.BGP
+ |RTA|-----|.....+---+
+ +---+ |-----|RTX|
+ | +---+
+ +---+ |
+ |RTB|-----|
+ +---+ |
+ |
+ +---+ |
+ |RTC|-----|
+ +---+ |
+ |
+ +
+
+
+ Figure 16: Forwarding address example
+
+
+
+
+
+Moy Standards Track [Page 142]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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
+ 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.
+
+ 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
+ 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, and none of router's neighbors are in states Exchange
+
+
+
+Moy Standards Track [Page 143]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ or Loading, 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), and b) Discard
+ the LSA and 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 received via flooding and 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
+ 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.
+
+
+
+
+Moy Standards Track [Page 144]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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, as long as the database copy has not been sent in a
+ Link State Update within the last MinLSArrival seconds, send the
+ database copy back to the sending neighbor, encapsulated within
+ a Link State Update Packet. The Link State Update Packet should
+ be sent directly to the neighbor. In so doing, do not put the
+
+
+
+Moy Standards Track [Page 145]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 146]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 147]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+
+ 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
+
+
+
+Moy Standards Track [Page 148]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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:
+
+
+ (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.
+
+
+
+Moy Standards Track [Page 149]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+ (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
+
+
+
+Moy Standards Track [Page 150]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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) 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).
+
+
+
+
+Moy Standards Track [Page 151]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 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 directly to a particular
+ neighbor in response to the receipt of duplicate LSAs. Direct
+ acknowledgments are sent immediately when the duplicate is
+ received. On multi-access networks, these acknowledgments are
+ sent directly to the neighbor's IP address.
+
+ 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 as multicasts. The Destination IP address used depends
+
+
+
+Moy Standards Track [Page 152]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+
+
+ 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, and none
+ of router's neighbors
+ are in states Exchange
+
+
+
+Moy Standards Track [Page 153]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ or Loading (see
+ Section 13, step 4).
+
+
+ Table 19: Sending link state acknowledgements.
+
+
+
+
+ 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).
+
+ 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
+
+
+
+Moy Standards Track [Page 154]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 directly to the neighbor. On multi-access networks, this
+ means that retransmissions are sent directly to the neighbor's
+ IP address. 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.
+
+
+ 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:
+
+
+
+
+
+Moy Standards Track [Page 155]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 156]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 14.1. Premature aging of LSAs
+
+ An LSA can be flushed from the routing domain by setting its LS
+ age to MaxAge, while leaving its LS sequence number alone, and
+ then 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.
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 157]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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
+ 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-
+
+
+
+Moy Standards Track [Page 158]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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. 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
+
+
+
+
+Moy Standards Track [Page 159]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ (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.
+
+
+
+
+
+Moy Standards Track [Page 160]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+ 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:
+
+
+
+Moy Standards Track [Page 161]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Vertex (node) ID
+ A 32-bit number which together with the vertex type (router
+ or network) uniquely identifies the vertex. For router
+ vertices the Vertex ID is the router's OSPF Router ID. For
+ network vertices, it 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 vertices are examined for
+ possible addition to/modification of the candidate list. The
+
+
+
+Moy Standards Track [Page 162]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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:
+
+
+
+Moy Standards Track [Page 163]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ o Greater than the value that already appears for
+ vertex W on the candidate list, then examine the
+ next link.
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 164]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+ 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.
+
+
+
+
+
+
+Moy Standards Track [Page 165]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ (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
+
+
+
+Moy Standards Track [Page 166]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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].
+
+
+ 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).
+
+
+
+Moy Standards Track [Page 167]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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).
+
+
+
+Moy Standards Track [Page 168]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+ 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.
+
+
+
+Moy Standards Track [Page 169]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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 also determines the actual next hop(s) for those
+ destinations whose next hop was calculated as a virtual link in
+ Sections 16.1 and 16.2. After completion of the calculation
+ below, any paths calculated in Sections 16.1 and 16.2 that still
+ have unresolved virtual next hops should be discarded.
+
+ 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 170]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+ 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
+
+
+
+Moy Standards Track [Page 171]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ ........................
+ . 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
+
+ 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 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.
+
+
+
+Moy Standards Track [Page 172]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 173]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 174]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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 The other paths, intra-area backbone paths and inter-
+ area paths, are of equal preference.
+
+ 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
+
+
+
+Moy Standards Track [Page 175]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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:
+
+ 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
+
+
+
+Moy Standards Track [Page 176]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ 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.
+
+
+
+Moy Standards Track [Page 177]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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 may specify 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 178]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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
+
+
+
+Moy Standards Track [Page 179]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ [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.
+
+
+
+Moy Standards Track [Page 180]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ [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
+
+
+
+Moy Standards Track [Page 181]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 182]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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, September
+ 1981.
+
+ [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP
+ 8073", RFC 905, April 1984.
+
+ [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5,
+ RFC 1112, 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, March 1991.
+
+ [Ref9] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
+
+ [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless
+ Inter-Domain Routing (CIDR): an Address Assignment and
+ Aggregation Strategy", RFC1519, September 1993.
+
+ [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, October 1994.
+
+ [Ref12] Almquist, P., "Type of Service in the Internet Protocol
+ Suite", RFC 1349, July 1992.
+
+
+
+
+Moy Standards Track [Page 183]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN
+ Protocol Handbook, April 1985.
+
+ [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, March
+ 1994.
+
+ [Ref19] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587,
+ March 1994.
+
+ [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in
+ progress.
+
+ [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
+ 1793, April 1995.
+
+ [Ref22] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
+ November 1990.
+
+ [Ref23] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
+ 4)", RFC 1771, March 1995.
+
+ [Ref24] Hinden, R., "Internet Routing Protocol Standardization
+ Criteria", BBN, October 1991.
+
+ [Ref25] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
+
+ [Ref26] Rosen, E., "Vulnerabilities of Network Control Protocols: An
+ Example", Computer Communication Review, July 1981.
+
+
+
+
+Moy Standards Track [Page 184]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 185]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 186]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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].
+
+
+
+
+Moy Standards Track [Page 187]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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].
+
+ DC-bit
+ This bit describes the router's handling of demand circuits, as
+ specified in [Ref21].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 188]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 189]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 190]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ 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.
+
+ 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.
+
+
+
+Moy Standards Track [Page 191]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Authentication
+ A 64-bit field for use by the authentication scheme. See
+ Appendix D for details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 192]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 |
+
+
+
+Moy Standards Track [Page 193]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Neighbor |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+ 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 194]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 -+
+ | |
+ +- -+
+ | |
+ +- -+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+Moy Standards Track [Page 195]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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
+ 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 196]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+Moy Standards Track [Page 197]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 198]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 sent directly to the
+ neighbor. 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 |
+ +- +-+
+ | ... |
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 199]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ # 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 200]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 Acknowledgement packets is
+ documented in Section 13.5. The reception of Link State
+ Acknowledgement 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 201]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ | |
+ +- -+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 202]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 203]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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):
+
+
+
+
+
+
+Moy Standards Track [Page 204]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ LS Type Description
+ ___________________________________
+ 1 Router-LSAs
+ 2 Network-LSAs
+ 3 Summary-LSAs (IP network)
+ 4 Summary-LSAs (ASBR)
+ 5 AS-external-LSAs
+
+
+
+
+ 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 205]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+
+
+
+Moy Standards Track [Page 206]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 207]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+
+Moy Standards Track [Page 208]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ # 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 209]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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.
+
+
+
+
+
+Moy Standards Track [Page 210]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 211]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+
+
+
+Moy Standards Track [Page 212]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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 213]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Moy Standards Track [Page 214]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ | External Route Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+ 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.
+
+
+
+Moy Standards Track [Page 215]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 216]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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.
+
+
+
+
+Moy Standards Track [Page 217]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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 218]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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
+
+
+
+Moy Standards Track [Page 219]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ Section 16.4.1, which prevent routing loops when AS-
+ external-LSAs for the same destination have been originated
+ from different areas. Set to "enabled" by default.
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 220]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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:
+
+
+
+
+
+Moy Standards Track [Page 221]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 222]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+
+
+
+Moy Standards Track [Page 223]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+Moy Standards Track [Page 224]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ Alternatively, neighbors on Point-to-MultiPoint networks may be
+ dynamically discovered by lower-level protocols such as Inverse
+ ARP ([Ref14]).
+
+
+
+
+Moy Standards Track [Page 225]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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 226]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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.
+
+
+
+
+
+Moy Standards Track [Page 227]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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
+ contains a new field called the "cryptographic sequence number".
+ This field is initialized to zero, and is also set to zero
+
+
+
+Moy Standards Track [Page 228]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+
+
+ 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
+
+ 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.
+
+ 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:
+
+
+
+
+
+
+Moy Standards Track [Page 229]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+Moy Standards Track [Page 230]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ (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
+
+
+
+
+
+Moy Standards Track [Page 231]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+
+
+
+
+Moy Standards Track [Page 232]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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.
+
+ (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
+
+
+
+
+
+Moy Standards Track [Page 233]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ 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.
+
+
+
+Moy Standards Track [Page 234]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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.
+
+ (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 235]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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,
+
+
+
+Moy Standards Track [Page 236]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ 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).
+
+ 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]:
+
+
+
+
+Moy Standards Track [Page 237]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ (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 238]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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 239]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+G. Differences from RFC 2178
+
+ This section documents the differences between this memo and RFC
+ 2178. All differences are backward-compatible. Implementations of
+ this memo and of RFCs 2178, 1583, and 1247 will interoperate.
+
+ G.1 Flooding modifications
+
+ Three changes have been made to the flooding procedure in
+ Section 13.
+
+ The first change is to step 4 in Section 13. Now MaxAge LSAs are
+ acknowledged and then discarded only when both a) there is no
+ database copy of the LSA and b) none of router's neighbors are
+ in states Exchange or Loading. In all other cases, the MaxAge
+ LSA is processed like any other LSA, installing the LSA in the
+ database and flooding it out the appropriate interfaces when the
+ LSA is more recent than the database copy (Step 5 of Section
+ 13). This change also affects the contents of Table 19.
+
+ The second change is to step 5a in Section 13. The MinLSArrival
+ check is meant only for LSAs received during flooding, and
+ should not be performed on those LSAs that the router itself
+ originates.
+
+ The third change is to step 8 in Section 13. Confusion between
+ routers as to which LSA instance is more recent can cause a
+ disastrous amount of flooding in a link-state protocol (see
+ [Ref26]). OSPF guards against this problem in two ways: a) the
+ LS age field is used like a TTL field in flooding, to eventually
+ remove looping LSAs from the network (see Section 13.3), and b)
+ routers refuse to accept LSA updates more frequently than once
+ every MinLSArrival seconds (see Section 13). However, there is
+ still one case in RFC 2178 where disagreements regarding which
+ LSA is more recent can cause a lot of flooding traffic:
+ responding to old LSAs by reflooding the database copy. For
+ this reason, Step 8 of Section 13 has been amended to only
+ respond with the database copy when that copy has not been sent
+ in any Link State Update within the last MinLSArrival seconds.
+
+
+
+
+
+
+Moy Standards Track [Page 240]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ G.2 Changes to external path preferences
+
+ There is still the possibility of a routing loop in RFC 2178
+ when both a) virtual links are in use and b) the same external
+ route is being imported by multiple ASBRs, each of which is in a
+ separate area. To fix this problem, Section 16.4.1 has been
+ revised. To choose the correct ASBR/forwarding address, intra-
+ area paths through non-backbone areas are always preferred.
+ However, intra-area paths through the backbone area (Area 0) and
+ inter-area paths are now of equal preference, and must be
+ compared solely based on cost.
+
+ The reasoning behind this change is as follows. When virtual
+ links are in use, an intra-area backbone path for one router can
+ turn into an inter-area path in a router several hops closer to
+ the destination. Hence, intra-area backbone paths and inter-area
+ paths must be of equal preference. We can safely compare their
+ costs, preferring the path with the smallest cost, due to the
+ calculations in Section 16.3.
+
+ Thanks to Michael Briggs and Jeremy McCooey of the UNH
+ InterOperability Lab for pointing out this problem.
+
+ G.3 Incomplete resolution of virtual next hops
+
+ One of the functions of the calculation in Section 16.3 is to
+ determine the actual next hop(s) for those destinations whose
+ next hop was calculated as a virtual link in Sections 16.1 and
+ 16.2. After completion of the calculation in Section 16.3, any
+ paths calculated in Sections 16.1 and 16.2 that still have
+ unresolved virtual next hops should be discarded.
+
+ G.4 Routing table lookup
+
+ The routing table lookup algorithm in Section 11.1 has been
+ modified to reflect current practice. The "best match" routing
+ table entry is now always selected to be the one providing the
+ most specific (longest) match. Suppose for example a router is
+ forwarding packets to the destination 192.9.1.1. A routing table
+ entry for 192.9.1/24 will always be a better match than the
+ routing table entry for 192.9/16, regardless of the routing
+ table entries' path-types. Note however that when multiple paths
+
+
+
+Moy Standards Track [Page 241]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+ are available for a given routing table entry, the calculations
+ in Sections 16.1, 16.2, and 16.4 always yield the paths having
+ the most preferential path-type. (Intra-area paths are the most
+ preferred, followed in order by inter-area, type 1 external and
+ type 2 external paths; see Section 11).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 242]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+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.
+
+Author's Address
+
+ John Moy
+ Ascend Communications, Inc.
+ 1 Robbins Road
+ Westford, MA 01886
+
+ Phone: 978-952-1367
+ Fax: 978-392-2075
+ EMail: jmoy@casc.com
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 243]
+
+RFC 2328 OSPF Version 2 April 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy Standards Track [Page 244]
+