summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1583.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1583.txt')
-rw-r--r--doc/rfc/rfc1583.txt12097
1 files changed, 12097 insertions, 0 deletions
diff --git a/doc/rfc/rfc1583.txt b/doc/rfc/rfc1583.txt
new file mode 100644
index 0000000..b8a3b15
--- /dev/null
+++ b/doc/rfc/rfc1583.txt
@@ -0,0 +1,12097 @@
+
+
+
+
+Network Working Group J. Moy
+Request for Comments: 1583 Proteon, Inc.
+Obsoletes: 1247 March 1994
+Category: Standards Track
+
+
+ OSPF Version 2
+
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is
+ unlimited.
+
+Abstract
+
+ This memo documents version 2 of the OSPF protocol. OSPF is a
+ link-state routing protocol. It is designed to be run internal to a
+ single Autonomous System. Each OSPF router maintains an identical
+ database describing the Autonomous System's topology. From this
+ database, a routing table is calculated by constructing a shortest-
+ path tree.
+
+ OSPF recalculates routes quickly in the face of topological changes,
+ utilizing a minimum of routing protocol traffic. OSPF provides
+ support for equal-cost multipath. Separate routes can be calculated
+ for each IP Type of Service. 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.
+
+ OSPF Version 2 was originally documented in RFC 1247. The
+ differences between RFC 1247 and this memo are explained in Appendix
+ E. The differences consist of bug fixes and clarifications, and are
+ backward-compatible in nature. Implementations of RFC 1247 and of
+ this memo will interoperate.
+
+ Please send comments to ospf@gated.cornell.edu.
+
+
+
+
+
+
+
+
+Moy [Page 1]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+Table of Contents
+
+ 1 Introduction ........................................... 5
+ 1.1 Protocol Overview ...................................... 5
+ 1.2 Definitions of commonly used terms ..................... 6
+ 1.3 Brief history of link-state routing technology ......... 9
+ 1.4 Organization of this document .......................... 9
+ 2 The Topological Database .............................. 10
+ 2.1 The shortest-path tree ................................ 13
+ 2.2 Use of external routing information ................... 16
+ 2.3 Equal-cost multipath .................................. 20
+ 2.4 TOS-based routing ..................................... 20
+ 3 Splitting the AS into Areas ........................... 21
+ 3.1 The backbone of the Autonomous System ................. 22
+ 3.2 Inter-area routing .................................... 22
+ 3.3 Classification of routers ............................. 23
+ 3.4 A sample area configuration ........................... 24
+ 3.5 IP subnetting support ................................. 30
+ 3.6 Supporting stub areas ................................. 31
+ 3.7 Partitions of areas ................................... 32
+ 4 Functional Summary .................................... 34
+ 4.1 Inter-area routing .................................... 35
+ 4.2 AS external routes .................................... 35
+ 4.3 Routing protocol packets .............................. 35
+ 4.4 Basic implementation requirements ..................... 38
+ 4.5 Optional OSPF capabilities ............................ 39
+ 5 Protocol data structures .............................. 41
+ 6 The Area Data Structure ............................... 42
+ 7 Bringing Up Adjacencies ............................... 45
+ 7.1 The Hello Protocol .................................... 45
+ 7.2 The Synchronization of Databases ...................... 46
+ 7.3 The Designated Router ................................. 47
+ 7.4 The Backup Designated Router .......................... 48
+ 7.5 The graph of adjacencies .............................. 49
+ 8 Protocol Packet Processing ............................ 50
+ 8.1 Sending protocol packets .............................. 51
+ 8.2 Receiving protocol packets ............................ 53
+ 9 The Interface Data Structure .......................... 55
+ 9.1 Interface states ...................................... 58
+ 9.2 Events causing interface state changes ................ 61
+ 9.3 The Interface state machine ........................... 62
+ 9.4 Electing the Designated Router ........................ 65
+ 9.5 Sending Hello packets ................................. 67
+ 9.5.1 Sending Hello packets on non-broadcast networks ....... 68
+ 10 The Neighbor Data Structure ........................... 69
+ 10.1 Neighbor states ....................................... 72
+ 10.2 Events causing neighbor state changes ................. 75
+ 10.3 The Neighbor state machine ............................ 77
+
+
+
+Moy [Page 2]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 10.4 Whether to become adjacent ............................ 83
+ 10.5 Receiving Hello Packets ............................... 83
+ 10.6 Receiving Database Description Packets ................ 86
+ 10.7 Receiving Link State Request Packets .................. 89
+ 10.8 Sending Database Description Packets .................. 89
+ 10.9 Sending Link State Request Packets .................... 90
+ 10.10 An Example ............................................ 91
+ 11 The Routing Table Structure ........................... 93
+ 11.1 Routing table lookup .................................. 96
+ 11.2 Sample routing table, without areas ................... 97
+ 11.3 Sample routing table, with areas ...................... 98
+ 12 Link State Advertisements ............................ 100
+ 12.1 The Link State Advertisement Header .................. 101
+ 12.1.1 LS age ............................................... 102
+ 12.1.2 Options .............................................. 102
+ 12.1.3 LS type .............................................. 103
+ 12.1.4 Link State ID ........................................ 103
+ 12.1.5 Advertising Router ................................... 105
+ 12.1.6 LS sequence number ................................... 105
+ 12.1.7 LS checksum .......................................... 106
+ 12.2 The link state database .............................. 107
+ 12.3 Representation of TOS ................................ 108
+ 12.4 Originating link state advertisements ................ 109
+ 12.4.1 Router links ......................................... 112
+ 12.4.2 Network links ........................................ 118
+ 12.4.3 Summary links ........................................ 120
+ 12.4.4 Originating summary links into stub areas ............ 123
+ 12.4.5 AS external links .................................... 124
+ 13 The Flooding Procedure ............................... 126
+ 13.1 Determining which link state is newer ................ 130
+ 13.2 Installing link state advertisements in the database . 130
+ 13.3 Next step in the flooding procedure .................. 131
+ 13.4 Receiving self-originated link state ................. 134
+ 13.5 Sending Link State Acknowledgment packets ............ 135
+ 13.6 Retransmitting link state advertisements ............. 136
+ 13.7 Receiving link state acknowledgments ................. 138
+ 14 Aging The Link State Database ........................ 139
+ 14.1 Premature aging of advertisements .................... 139
+ 15 Virtual Links ........................................ 140
+ 16 Calculation Of The Routing Table ..................... 142
+ 16.1 Calculating the shortest-path tree for an area ....... 143
+ 16.1.1 The next hop calculation ............................. 149
+ 16.2 Calculating the inter-area routes .................... 150
+ 16.3 Examining transit areas' summary links ............... 152
+ 16.4 Calculating AS external routes ....................... 154
+ 16.5 Incremental updates -- summary link advertisements ... 156
+ 16.6 Incremental updates -- AS external link advertisements 157
+ 16.7 Events generated as a result of routing table changes 157
+
+
+
+Moy [Page 3]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 16.8 Equal-cost multipath ................................. 158
+ 16.9 Building the non-zero-TOS portion of the routing table 158
+ Footnotes ............................................ 161
+ References ........................................... 164
+ A OSPF data formats .................................... 166
+ A.1 Encapsulation of OSPF packets ........................ 166
+ A.2 The Options field .................................... 168
+ A.3 OSPF Packet Formats .................................. 170
+ A.3.1 The OSPF packet header ............................... 171
+ A.3.2 The Hello packet ..................................... 173
+ A.3.3 The Database Description packet ...................... 175
+ A.3.4 The Link State Request packet ........................ 177
+ A.3.5 The Link State Update packet ......................... 179
+ A.3.6 The Link State Acknowledgment packet ................. 181
+ A.4 Link state advertisement formats ..................... 183
+ A.4.1 The Link State Advertisement header .................. 184
+ A.4.2 Router links advertisements .......................... 186
+ A.4.3 Network links advertisements ......................... 190
+ A.4.4 Summary link advertisements .......................... 192
+ A.4.5 AS external link advertisements ...................... 194
+ B Architectural Constants .............................. 196
+ C Configurable Constants ............................... 198
+ C.1 Global parameters .................................... 198
+ C.2 Area parameters ...................................... 198
+ C.3 Router interface parameters .......................... 200
+ C.4 Virtual link parameters .............................. 202
+ C.5 Non-broadcast, multi-access network parameters ....... 203
+ C.6 Host route parameters ................................ 203
+ D Authentication ....................................... 205
+ D.1 AuType 0 -- No authentication ........................ 205
+ D.2 AuType 1 -- Simple password .......................... 205
+ E Differences from RFC 1247 ............................ 207
+ E.1 A fix for a problem with OSPF Virtual links .......... 207
+ E.2 Supporting supernetting and subnet 0 ................. 208
+ E.3 Obsoleting LSInfinity in router links advertisements . 209
+ E.4 TOS encoding updated ................................. 209
+ E.5 Summarizing routes into transit areas ................ 210
+ E.6 Summarizing routes into stub areas ................... 210
+ E.7 Flushing anomalous network links advertisements ...... 210
+ E.8 Required Statistics appendix deleted ................. 211
+ E.9 Other changes ........................................ 211
+ F. An algorithm for assigning Link State IDs ............ 213
+ Security Considerations .............................. 216
+ Author's Address ..................................... 216
+
+
+
+
+
+
+
+Moy [Page 4]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 IP
+ subnetting, TOS-based routing 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.
+
+ The author would like to thank Fred Baker, Jeffrey Burgan, Rob
+ Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo
+ Medin, Kannan Varadhan and the rest of the OSPF working group for
+ the ideas and support they have given to this project.
+
+ 1.1. Protocol overview
+
+ OSPF routes IP packets based solely on the destination IP
+ address and IP Type of Service 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. 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.
+
+ All routers run the exact same algorithm, in parallel. From the
+ topological database, each router constructs a tree of shortest
+ paths with itself as root. This shortest-path tree gives the
+
+
+
+Moy [Page 5]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ route to each destination in the Autonomous System. Externally
+ derived routing information appears on the tree as leaves.
+
+ OSPF calculates separate routes for each Type of Service (TOS).
+ 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; a
+ single authentication scheme is configured for each area. This
+ enables some areas to use much stricter authentication than
+ others.
+
+ Externally derived routing data (e.g., routes learned from the
+ Exterior Gateway Protocol (EGP)) is passed transparently
+ 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 boundaries of the Autonomous System.
+
+
+ 1.2. Definitions of commonly used terms
+
+ This section provides definitions for terms that have a specific
+ meaning to the OSPF protocol and that are used throughout the
+ text. The reader unfamiliar with the Internet Protocol Suite is
+ referred to [RS-85-153] for an introduction to IP.
+
+
+
+
+Moy [Page 6]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Router
+ A level three Internet Protocol packet switch. Formerly
+ called a gateway in much of the IP literature.
+
+ Autonomous System
+ A group of routers exchanging routing information via a
+ common routing protocol. Abbreviated as AS.
+
+ Interior Gateway Protocol
+ The routing protocol spoken by the routers belonging to an
+ Autonomous system. Abbreviated as IGP. Each Autonomous
+ System has a single IGP. Separate Autonomous Systems may be
+ running different IGPs.
+
+ Router ID
+ A 32-bit number assigned to each router running the OSPF
+ protocol. This number uniquely identifies the router within
+ an Autonomous System.
+
+ Network
+ In this memo, an IP network/subnet/supernet. It is possible
+ for one physical network to be assigned multiple IP
+ network/subnet numbers. We consider these to be separate
+ networks. Point-to-point physical networks are an exception
+ - they are considered a single network no matter how many
+ (if any at all) IP network/subnet numbers are assigned to
+ them.
+
+ Network mask
+ A 32-bit number indicating the range of IP addresses
+ residing on a single IP network/subnet/supernet. This
+ specification displays network masks as hexadecimal numbers.
+ For example, the network mask for a class C IP network is
+ displayed as 0xffffff00. Such a mask is often displayed
+ elsewhere in the literature as 255.255.255.0.
+
+ Multi-access networks
+ Those physical networks that support the attachment of
+ multiple (more than two) routers. Each pair of routers on
+ such a network is assumed to be able to communicate directly
+ (e.g., multi-drop networks are excluded).
+
+ 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
+
+
+
+Moy [Page 7]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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. On
+ multi-access networks, neighbors are 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
+ Describes the local state of a router or network. 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 topological database.
+
+ Hello Protocol
+ The part of the OSPF protocol used to establish and maintain
+ neighbor relationships. On multi-access networks the Hello
+ Protocol can also dynamically discover neighboring routers.
+
+ Designated Router
+ Each multi-access network that has at least two attached
+ routers has a Designated Router. The Designated Router
+ generates a link state advertisement for the multi-access
+ 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 multi-access network.
+ This in turn reduces the amount of routing protocol traffic
+ and the size of the topological 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.
+
+
+
+
+
+Moy [Page 8]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 [McQuillan]. 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 [Perlman].
+ These modifications dealt with increasing the fault tolerance of
+ the routing protocol through, among other things, adding a
+ checksum to the link state advertisements (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 link state advertisement originations to be
+ increased by an order of magnitude.
+
+ A link-state algorithm has also been proposed for use as an ISO
+ IS-IS routing protocol. This protocol is described in [DEC].
+ 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 a link state
+ advertisement for the network.
+
+ The OSPF subcommittee 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 algorithm has been
+ modified 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
+
+
+
+Moy [Page 9]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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. The
+ architectural constants are explained in Appendix B. The
+ configurable constants are explained 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.
+
+
+2. The Topological Database
+
+ The Autonomous System's topological 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.
+
+ The vertices of the graph can be further typed according to
+ function. Only some of these types carry transit data traffic; that
+ is, traffic that is neither locally originated nor locally destined.
+ Vertices that can carry transit traffic are indicated on the graph
+ by having both incoming and outgoing edges.
+
+
+
+ Vertex type Vertex name Transit?
+ _____________________________________
+ 1 Router yes
+ 2 Network yes
+ 3 Stub network no
+
+
+ Table 1: OSPF vertex types.
+
+
+ OSPF supports the following types of physical networks:
+
+
+ Point-to-point networks
+ A network that joins a single pair of routers. A 56Kb serial
+ line is an example of a point-to-point network.
+
+
+
+Moy [Page 10]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 protocol makes further use of
+ multicast capabilities, if they exist. 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 also discovered
+ on these nets using OSPF's Hello Protocol. However, due to the
+ lack of broadcast capability, some configuration information is
+ necessary for the correct operation of the Hello Protocol. On
+ these 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.
+
+
+ The neighborhood of each network node in the graph depends on
+ whether the network has multi-access capabilities (either broadcast
+ or non-broadcast) and, if so, the number of routers having an
+ interface to the network. The three cases are depicted in Figure 1.
+ Rectangles indicate routers. Circles and oblongs indicate multi-
+ access 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 a network with
+ its connected routers, with the resulting graph shown on the right.
+
+ Two routers joined by a point-to-point network are represented in
+ the directed graph as being directly connected by a pair of edges,
+ one in each direction. Interfaces to physical point-to-point
+ networks need not be assigned IP addresses. Such a point-to-point
+ network is called unnumbered. The graphical representation of
+ point-to-point networks is designed so that unnumbered networks can
+ be supported naturally. When interface addresses exist, they are
+ modelled as stub routes. Note that each router would then have a
+ stub connection to the other router's interface address (see Figure
+ 1).
+
+ When multiple routers are attached to a multi-access network, the
+ directed graph shows all routers bidirectionally connected to the
+ network vertex (again, see Figure 1). If only a single router is
+ attached to a multi-access network, the network will appear in the
+
+
+
+Moy [Page 11]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+
+ **FROM**
+
+ * |RT1|RT2|
+ +---+Ia +---+ * ------------
+ |RT1|------|RT2| T RT1| | X |
+ +---+ Ib+---+ O RT2| X | |
+ * Ia| | X |
+ * Ib| X | |
+
+ Physical point-to-point 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 | |
+ +---+ +---+
+
+ Multi-access networks
+
+ **FROM**
+ +---+ *
+ |RT7| * |RT7| N3|
+ +---+ T ------------
+ | O RT7| | |
+ +----------------------+ * N3| X | |
+ N3 *
+
+ Stub multi-access networks
+
+
+
+ Figure 1: Network map components
+
+ Networks and routers are represented by vertices.
+ An edge connects Vertex A to Vertex B iff the
+ intersection of Column A and Row B is marked with
+ an X.
+
+
+
+
+
+
+Moy [Page 12]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ directed graph as a stub connection.
+
+ 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.
+
+ 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 EGP
+ connections to other Autonomous Systems. A set of EGP-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 EGP-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 topological database (or what has been referred to above as the
+ directed graph) is pieced together from link state advertisements
+ generated by the routers. The neighborhood of each transit vertex
+ is represented in a single, separate link state advertisement.
+ Figure 4 shows graphically the link state representation of the two
+ kinds of transit vertices: routers and multi-access networks.
+ 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 link state advertisement for
+ Network N6 is actually generated by one of the attached routers: the
+ router that has been elected Designated Router for the network.
+
+ 2.1. The shortest-path tree
+
+ When no OSPF areas are configured, each router in the Autonomous
+ System has an identical topological database, leading to an
+
+
+
+Moy [Page 13]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ +
+ | 3+---+ N12 N14
+ N1|--|RT1|\ 1 \ N13 /
+ | +---+ \ 8\ |8/8
+ + \ ____ \|/
+ / \ 1+---+8 8+---+6
+ * N3 *---|RT4|------|RT5|--------+
+ \____/ +---+ +---+ |
+ + / | |7 |
+ | 3+---+ / | | |
+ N2|--|RT2|/1 |1 |6 |
+ | +---+ +---+8 6+---+ |
+ + |RT3|--------------|RT6| |
+ +---+ +---+ |
+ |2 Ia|7 |
+ | | |
+ +---------+ | |
+ N4 | |
+ | |
+ | |
+ N11 | |
+ +---------+ | |
+ | | | N12
+ |3 | |6 2/
+ +---+ | +---+/
+ |RT9| | |RT7|---N15
+ +---+ | +---+ 9
+ |1 + | |1
+ _|__ | Ib|5 __|_
+ / \ 1+----+2 | 3+----+1 / \
+ * N9 *------|RT11|----|---|RT10|---* N6 *
+ \____/ +----+ | +----+ \____/
+ | | |
+ |1 + |1
+ +--+ 10+----+ N8 +---+
+ |H1|-----|RT12| |RT8|
+ +--+SLIP +----+ +---+
+ |2 |4
+ | |
+ +---------+ +--------+
+ N10 N7
+
+ Figure 2: A sample Autonomous System
+
+
+
+
+
+
+
+Moy [Page 14]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ **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 [Page 15]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ **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 links N9's network links
+ advertisement advertisement
+
+ 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.
+
+ 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 route 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 serial line (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
+ this externally derived routing information is considered in the
+ next section.
+
+
+ 2.2. 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 EGP, or be statically
+
+
+
+Moy [Page 16]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ RT6(origin)
+ RT5 o------------o-----------o Ib
+ /|\ 6 |\ 7
+ 8/8|8\ | \
+ / | \ | \
+ 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.2
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 17]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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.
+
+ 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 equivalent to the link state metric. Type 2
+ external metrics are 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 external route, the distance from
+ Router RT6 is calculated as the sum of the external route's cost
+ and the distance from Router RT6 to the advertising router. For
+ every external destination, the router advertising the shortest
+ route is discovered, and the next hop to the advertising router
+ becomes the next hop to the destination.
+
+
+
+
+Moy [Page 18]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Both Router RT5 and RT7 are advertising an external route to
+ destination Network N12. Router RT7 is preferred since it is
+ advertising N12 at a distance of 10 (8+2) to Router RT6, which
+ is better than Router RT5's 14 (6+8). Table 3 shows the entries
+ that are added to the routing table when external routes are
+ examined:
+
+
+
+ Destination Next Hop Distance
+ __________________________________
+ N12 RT10 10
+ N13 RT5 14
+ N14 RT5 14
+ N15 RT10 17
+
+
+ Table 3: The portion of Router RT6's routing table
+ listing external destinations.
+
+
+ Processing of Type 2 external metrics is simpler. The AS
+ boundary router advertising the smallest external metric is
+ chosen, regardless of the internal distance to the AS boundary
+ router. Suppose in our example both Router RT5 and Router RT7
+ were advertising Type 2 external routes. Then all traffic
+ destined for Network N12 would be forwarded to Router RT7, since
+ 2 < 8. When several equal-cost Type 2 routes exist, the
+ internal distance to the advertising routers is used to break
+ the tie.
+
+ Both Type 1 and Type 2 external metrics can be present in the AS
+ at the same time. In that event, Type 1 external metrics always
+ take precedence.
+
+ This section has assumed that packets destined for external
+ destinations are always routed through the advertising AS
+ boundary router. This is not always desirable. For example,
+ suppose in Figure 2 there is an additional router attached to
+ Network N6, called Router RTX. Suppose further that RTX does
+ not participate in OSPF routing, but does exchange EGP
+ 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
+
+
+
+Moy [Page 19]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ boundary router to specify a "forwarding address" in its
+ external advertisements. 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
+ external advertisements. In each external advertisement, Router
+ RT6 would specify the correct Autonomous System exit point to
+ use for the destination through appropriate setting of the
+ advertisement's "forwarding address" field.
+
+
+ 2.3. 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.
+
+
+ 2.4. TOS-based routing
+
+ OSPF can calculate a separate set of routes for each IP Type of
+ Service. This means that, for any destination, there can
+ potentially be multiple routing table entries, one for each IP
+ TOS. The IP TOS values are represented in OSPF exactly as they
+ appear in the IP packet header.
+
+ Up to this point, all examples shown have assumed that routes do
+ not vary on TOS. In order to differentiate routes based on TOS,
+ separate interface costs can be configured for each TOS. For
+ example, in Figure 2 there could be multiple costs (one for each
+ TOS) listed for each interface. A cost for TOS 0 must always be
+ specified.
+
+ When interface costs vary based on TOS, a separate shortest path
+
+
+
+Moy [Page 20]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ tree is calculated for each TOS (see Section 2.1). In addition,
+ external costs can vary based on TOS. For example, in Figure 2
+ Router RT7 could advertise a separate type 1 external metric for
+ each TOS. Then, when calculating the TOS X distance to Network
+ N15 the cost of the shortest TOS X path to RT7 would be added to
+ the TOS X cost advertised by RT7 for Network N15 (see Section
+ 2.2).
+
+ All OSPF implementations must be capable of calculating routes
+ based on TOS. However, OSPF routers can be configured to route
+ all packets on the TOS 0 path (see Appendix C), eliminating the
+ need to calculate non-zero TOS paths. This can be used to
+ conserve routing table space and processing resources in the
+ router. These TOS-0-only routers can be mixed with routers that
+ do route based on TOS. TOS-0-only routers will be avoided as
+ much as possible when forwarding traffic requesting a non-zero
+ TOS.
+
+ It may be the case that no path exists for some non-zero TOS,
+ even if the router is calculating non-zero TOS paths. In that
+ case, packets requesting that non-zero TOS are routed along the
+ TOS 0 path (see Section 11.1).
+
+
+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 topological
+ 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 topological database. A router
+ actually has a separate topological 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 topological databases.
+
+
+
+
+Moy [Page 21]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Routing in the Autonomous System takes place on two levels,
+ depending on whether the source and destination of a packet reside
+ in the same area (intra-area routing is used) or different areas
+ (inter-area routing is used). In intra-area routing, the packet is
+ routed solely on information obtained within the area; no routing
+ information obtained from outside the area can be used. This
+ protects intra-area routing from the injection of bad routing
+ information. We discuss inter-area routing in Section 3.2.
+
+
+ 3.1. The backbone of the Autonomous System
+
+ The backbone consists of those networks not contained in any
+ area, their attached routers, and those routers that belong to
+ multiple areas. The backbone must be contiguous.
+
+ It is possible to define areas in such a way that the backbone
+ is no longer contiguous. In this case the system administrator
+ must restore backbone connectivity by configuring 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 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.
+
+ The backbone is responsible for distributing routing information
+ between areas. The backbone itself has all of the properties of
+ an area. The topology of the backbone is invisible to each of
+ the areas, while the backbone itself knows nothing of the
+ topology of the areas.
+
+
+ 3.2. Inter-area routing
+
+ When routing a packet between two 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
+
+
+
+Moy [Page 22]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ as forcing a star configuration on the Autonomous System, with
+ the backbone as hub and each of the areas as spokes.
+
+ The topology of the backbone dictates the backbone paths used
+ between areas. The topology of the backbone can be enhanced by
+ adding virtual links. This gives the system administrator some
+ control over the routes taken by inter-area traffic.
+
+ The correct area border router to use as the packet exits the
+ source area is chosen in exactly the same way routers
+ advertising external routes are chosen. Each area border router
+ in an area summarizes for the area its cost to all networks
+ external to the area. After the SPF tree is calculated for the
+ area, routes to all other networks 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. Routers with only backbone interfaces also
+ belong to this category. 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 and an additional copy for the
+ backbone. 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. 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 connected to the backbone are considered to be
+ internal routers.
+
+
+
+Moy [Page 23]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ AS boundary routers
+ A router that exchanges routing information with routers
+ belonging to other Autonomous Systems. Such a router has AS
+ external routes that are advertised throughout the
+ Autonomous System. The path to each AS boundary router is
+ 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 topological 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, external advertisements from RT5
+ and RT7 are flooded throughout the entire AS, and in particular
+ throughout Area 1. These advertisements are included in Area
+ 1's database, and yield routes to Networks N12-N15.
+
+ Routers RT3 and RT4 must also summarize Area 1's topology for
+ distribution to the backbone. Their backbone advertisements 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.
+
+
+
+
+
+Moy [Page 24]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ ...........................
+ . + .
+ . | 3+---+ . N12 N14
+ . N1|--|RT1|\ 1 . \ N13 /
+ . | +---+ \ . 8\ |8/8
+ . + \ ____ . \|/
+ . / \ 1+---+8 8+---+6
+ . * N3 *---|RT4|------|RT5|--------+
+ . \____/ +---+ +---+ |
+ . + / \ . |7 |
+ . | 3+---+ / \ . | |
+ . N2|--|RT2|/1 1\ . |6 |
+ . | +---+ +---+8 6+---+ |
+ . + |RT3|------|RT6| |
+ . +---+ +---+ |
+ . 2/ . Ia|7 |
+ . / . | |
+ . +---------+ . | |
+ .Area 1 N4 . | |
+ ........................... | |
+ .......................... | |
+ . N11 . | |
+ . +---------+ . | |
+ . | . | | N12
+ . |3 . Ib|5 |6 2/
+ . +---+ . +----+ +---+/
+ . |RT9| . .........|RT10|.....|RT7|---N15.
+ . +---+ . . +----+ +---+ 9 .
+ . |1 . . + /3 1\ |1 .
+ . _|__ . . | / \ __|_ .
+ . / \ 1+----+2 |/ \ / \ .
+ . * N9 *------|RT11|----| * N6 * .
+ . \____/ +----+ | \____/ .
+ . | . . | | .
+ . |1 . . + |1 .
+ . +--+ 10+----+ . . N8 +---+ .
+ . |H1|-----|RT12| . . |RT8| .
+ . +--+SLIP +----+ . . +---+ .
+ . |2 . . |4 .
+ . | . . | .
+ . +---------+ . . +--------+ .
+ . N10 . . N7 .
+ . . .Area 2 .
+ .Area 3 . ................................
+ ..........................
+
+ Figure 6: A sample OSPF area configuration
+
+
+
+Moy [Page 25]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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.
+
+ The topological 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.
+
+ Again, Routers RT3, RT4, RT7, RT10 and RT11 are area border
+ routers. As Routers RT3 and RT4 did above, they have condensed
+ the routing information of their attached 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.
+
+ 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 advertisements, and adding in the
+ backbone distance to each advertising router.
+
+ Again using Routers RT3 and RT4 as an example, the procedure
+ goes as follows: They first calculate the SPF tree for the
+ backbone. This gives the distances to all other area border
+ routers. Also noted are the distances to networks (Ia and Ib)
+ and AS boundary routers (RT5 and RT7) that belong to the
+ backbone. This calculation is shown in Table 5.
+
+
+ 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.
+
+
+
+Moy [Page 26]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ **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| | |15|22| | | |
+ N6| | |16|15| | | |
+ N7| | |20|19| | | |
+ N8| | |18|18| | | |
+ N9-N11,H1| | |19|16| | | |
+ 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 [Page 27]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ **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| | | | | | |1 |
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 28]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Area border dist from dist from
+ router 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.
+
+ Note that Table 6 assumes that an area range has been configured
+ for the backbone which groups Ia and Ib into a single
+ advertisement.
+
+
+ The information imported into Area 1 by Routers RT3 and RT4
+ enables an internal router, such as RT1, to choose an area
+ border router intelligently. Router RT1 would use RT4 for
+ traffic to Network N6, RT3 for traffic to Network N10, and would
+ load share between the two for traffic to Network N8.
+
+
+
+ Destination RT3 adv. RT4 adv.
+ _________________________________
+ Ia,Ib 15 22
+ N6 16 15
+ N7 20 19
+ N8 18 18
+ N9-N11,H1 19 26
+ _________________________________
+ RT5 14 8
+ RT7 20 14
+
+
+ Table 6: Destinations advertised into Area 1
+ by Routers RT3 and RT4.
+
+
+
+
+
+Moy [Page 29]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 external advertisements, 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. Also, a
+ virtual link between RT7 and RT10 would allow a much shorter
+ path between the third area (containing N9) and the router RT7,
+ which is advertising a good route to external network N12.
+
+
+ 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 advertisement for the
+ destination 128.185.0.0 with a mask of 0xffff0000 actually is
+ describing a single route to the collection of destinations
+ 128.185.0.0 - 128.185.255.255. Similarly, host routes are
+ always advertised with a mask of 0xffffffff, indicating the
+ presence of only a single destination.
+
+ Including the mask with each advertised destination enables the
+ implementation of what is commonly referred to as variable-
+ length subnetting. This means that a single IP class A, B, or C
+ network number can be broken up into many subnets of various
+ sizes. For example, the network 128.185.0.0 could be broken up
+ into 62 variable-sized subnets: 15 subnets of size 4K, 15
+ subnets of size 256, and 32 subnets of size 8. Table 7 shows
+ some of the resulting network addresses together with their
+ masks:
+
+
+
+ Network address IP address mask Subnet size
+ _______________________________________________
+ 128.185.16.0 0xfffff000 4K
+ 128.185.1.0 0xffffff00 256
+ 128.185.0.8 0xfffffff8 8
+
+
+ Table 7: Some sample subnet sizes.
+
+
+
+
+
+Moy [Page 30]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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.
+
+ The OSPF area concept is modelled after an IP subnetted network.
+ OSPF areas have been loosely defined to be a collection of
+ networks. In actuality, an OSPF area is specified to be a list
+ of address ranges (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 minimum
+ cost to any of the networks falling in the specified range.
+
+ For example, an IP subnetted network can be configured as a
+ single OSPF area. In that case, the area would be defined as a
+ single address range: 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. 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 minimum of the set of
+ costs to the component subnets.
+
+
+ 3.6. Supporting stub areas
+
+ In some Autonomous Systems, the majority of the topological
+ database may consist of AS external advertisements. An OSPF AS
+ external advertisement is usually flooded throughout the entire
+ AS. However, OSPF allows certain areas to be configured as
+ "stub areas". AS external advertisements 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 topological database size, and therefore the memory
+ requirements, for a stub area's internal routers.
+
+
+
+
+Moy [Page 31]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link advertisements. 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 match any destination that is
+ not explicitly reachable by an intra-area or inter-area path
+ (i.e., AS external destinations).
+
+ An area can be configured as 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 link advertisement), instead of flooding the AS
+ external advertisements 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 advertisements.
+
+ 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.
+
+ In the previous section, an area was described as a list of
+ address ranges. Any particular address range must still be
+ completely contained in a single component of the area
+ partition. This has to do with the way the area contents are
+ summarized to the backbone. Also, the backbone itself must not
+ partition. If it does, parts of the Autonomous System will
+ become unreachable. Backbone partitions can be repaired by
+
+
+
+Moy [Page 32]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ configuring virtual links (see Section 15).
+
+ Another way to think about area partitions is to look at the
+ Autonomous System graph that was introduced in Section 2. Area
+ IDs can be viewed as colors for the graph's edges.[1] Each edge
+ of the graph connects to a network, or is itself a point-to-
+ point network. In either case, the edge is colored with the
+ network's Area ID.
+
+ A group of edges, all having the same color, and interconnected
+ by vertices, represents an area. If the topology of the
+ Autonomous System is intact, the graph will have several regions
+ of color, each color being a distinct Area ID.
+
+ 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 [Page 33]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 is
+ necessary in order to discover neighbors. On all multi-access
+ networks (broadcast or non-broadcast), 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. Topological databases are synchronized between
+ pairs of adjacent routers. On multi-access networks, the Designated
+ Router determines which routers should become adjacent.
+
+ Adjacencies control the distribution of routing protocol packets.
+ Routing protocol packets are sent and received only on adjacencies.
+ In particular, distribution of topological database updates proceeds
+ along 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 link state advertisements. This relationship between
+ adjacencies and link state allows the protocol to detect dead
+ routers in a timely fashion.
+
+ Link state advertisements are flooded throughout the area. The
+ flooding algorithm is reliable, ensuring that all routers in an area
+ have exactly the same topological database. This database consists
+ of the collection of link state advertisements received from 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 [Page 34]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 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 destinations not contained in
+ its attached areas. 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 to
+ destinations in other areas.
+
+
+ 4.2. AS external routes
+
+ Routers that have information regarding other Autonomous Systems
+ can flood this information throughout the AS. This external
+ routing information is distributed verbatim to every
+ participating router. There is one exception: external routing
+ information is not flooded into "stub" areas (see Section 3.6).
+
+ To utilize external routing information, the path to all routers
+ advertising external information must be known throughout the AS
+ (excepting the stub areas). For that reason, the locations of
+ these AS boundary routers are summarized by the (non-stub) area
+ border routers.
+
+
+ 4.3. Routing protocol packets
+
+ The OSPF protocol runs directly over IP, using IP protocol 89.
+ OSPF does not provide any explicit fragmentation/reassembly
+ support. When fragmentation is necessary, IP
+ fragmentation/reassembly is used. OSPF protocol packets have
+ been designed so that large protocol packets can generally be
+ split into several smaller protocol packets. This practice is
+ recommended; IP fragmentation should be avoided whenever
+
+
+
+Moy [Page 35]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 [RFC 791]).
+
+ All OSPF protocol packets share a common protocol header that is
+ described in Appendix A. The OSPF packet types are listed below
+ in Table 8. Their formats are also described in Appendix A.
+
+
+
+ Type Packet name Protocol function
+ __________________________________________________________
+ 1 Hello Discover/maintain neighbors
+ 2 Database Description Summarize database contents
+ 3 Link State Request Database download
+ 4 Link State Update Database update
+ 5 Link State Ack Flooding acknowledgment
+
+
+ Table 8: OSPF packet types.
+
+
+ OSPF's Hello protocol uses Hello packets to discover and
+ maintain neighbor relationships. The Database Description and
+ Link State Request packets are used in the forming of
+ adjacencies. OSPF's reliable update mechanism is implemented by
+ the Link State Update and Link State Acknowledgment packets.
+
+ Each Link State Update packet carries a set of new link state
+ advertisements one hop further away from their point of
+ origination. A single Link State Update packet may contain the
+ link state advertisements of several routers. Each
+ advertisement is tagged with the ID of the originating router
+ and a checksum of its link state contents. The five different
+ types of OSPF link state advertisements are listed below in
+ Table 9.
+
+ As mentioned above, OSPF routing packets (with the exception of
+ Hellos) are sent only over adjacencies. Note that 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
+
+
+
+Moy [Page 36]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+ LS Advertisement Advertisement description
+ type name
+ _________________________________________________________
+ 1 Router links Originated by all routers.
+ advertisements This advertisement describes
+ the collected states of the
+ router's interfaces to an
+ area. Flooded throughout a
+ single area only.
+ _________________________________________________________
+ 2 Network links Originated for multi-access
+ advertisements networks by the Designated
+ Router. This advertisement
+ contains the list of routers
+ connected to the network.
+ Flooded throughout a single
+ area only.
+ _________________________________________________________
+ 3,4 Summary link Originated by area border
+ advertisements routers, and flooded through-
+ out the advertisement's
+ associated area. Each summary
+ link advertisement describes
+ a route to a destination out-
+ side the area, yet still inside
+ the AS (i.e., an inter-area
+ route). Type 3 advertisements
+ describe routes to networks.
+ Type 4 advertisements describe
+ routes to AS boundary routers.
+ _________________________________________________________
+ 5 AS external link Originated by AS boundary
+ advertisements routers, and flooded through-
+ out the AS. Each AS external
+ link advertisement describes
+ a route to a destination in
+ another Autonomous System.
+ Default routes for the AS can
+ also be described by AS
+ external link advertisements.
+
+
+ Table 9: OSPF link state advertisements.
+
+
+
+
+
+
+Moy [Page 37]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 (on
+ broadcast networks). 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
+ timer interval at each firing.
+
+ IP multicast
+ Certain OSPF packets take the form of IP multicast
+ datagrams. Support for receiving and sending IP multicast
+ datagrams, along with the appropriate lower-level protocol
+ support, is required. The IP multicast datagrams used by
+ OSPF never travel more than one hop. For this reason, the
+ ability to forward IP multicast datagrams is not required.
+ For information on IP multicast, see [RFC 1112].
+
+ 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
+
+
+
+Moy [Page 38]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ scaling of IP routing in the worldwide Internet. For more
+ information on IP supernetting, see [RFC 1519].
+
+ 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
+ Remember that non-broadcast networks are multi-access
+ networks such as a X.25 PDN. On these networks, the Hello
+ Protocol can be aided by providing an indication to OSPF
+ when an attempt is made to send a packet to a dead or non-
+ existent router. For example, on an X.25 PDN a dead
+ neighboring router may be indicated by the reception of a
+ X.25 clear with an appropriate cause and diagnostic, and
+ this information would be passed to OSPF.
+
+ List manipulation primitives
+ Much of the OSPF functionality is described in terms of its
+ operation on lists of link state advertisements. For
+ example, the collection of advertisements that will be
+ retransmitted to an adjacent router until acknowledged are
+ described as a list. Any particular advertisement may be on
+ many such lists. An OSPF implementation needs to be able to
+ manipulate these lists, adding and deleting constituent
+ advertisements 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
+ link state advertisements. This enables routers supporting a
+
+
+
+Moy [Page 39]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ capability mismatch with a neighbor in this case will result in
+ only a subset of link state advertisements 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 link state
+ advertisements, routers incapable of certain functions can be
+ avoided when building the shortest path tree. An example of
+ this is the TOS routing capability (see below).
+
+ The current OSPF optional capabilities 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 advertisements 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).
+
+ TOS capability
+ All OSPF implementations must be able to calculate separate
+ routes based on IP Type of Service. However, to save
+ routing table space and processing resources, an OSPF router
+ can be configured to ignore TOS when forwarding packets. In
+ this case, the router calculates routes for TOS 0 only.
+ This capability is represented by the T-bit in the OSPF
+ options field (see Section A.2). TOS-capable routers will
+ attempt to avoid non-TOS-capable routers when calculating
+ non-zero TOS paths.
+
+
+
+
+Moy [Page 40]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+5. Protocol Data Structures
+
+ The OSPF protocol is described in this specification 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.
+ Before restarting in order to change its Router ID, the router
+ should flush its self-originated link state advertisements from
+ the routing domain (see Section 14.1), or they will persist for
+ up to MaxAge minutes.
+
+ Area structures
+ Each one of the areas to which the router is connected has its
+ own data structure. This data structure describes the working
+ of the basic algorithm. Remember that each area runs a separate
+ copy of the basic algorithm.
+
+ Backbone (area) structure
+ The basic algorithm operates on the backbone as if it were an
+ area. For this reason the backbone is represented as an area
+ structure.
+
+ 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
+
+
+
+Moy [Page 41]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ with another routing protocol (such as EGP), 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 link
+ advertisements.
+
+ List of AS external link advertisements
+ Part of the topological 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 link
+ advertisements have been self-originated.
+
+ The routing table
+ Derived from the topological database. Each destination that
+ the router can forward to is represented by a cost and a set of
+ paths. A path is described by its type and next hop. For more
+ information, see Section 11.
+
+ TOS capability
+ This item indicates whether the router will calculate separate
+ routes based on TOS. This is a configurable parameter. For
+ more information, see Sections 4.5 and 16.9.
+
+
+ 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 routing algorithm. Each area maintains its own topological
+ 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 has all the properties of an area. For that
+ reason it is also represented by an area data structure. Note that
+ some items in the structure apply differently to the backbone than
+ to non-backbone areas.
+
+
+
+Moy [Page 42]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+
+ +----+
+ |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
+
+ The area topological (or link state) database consists of the
+ collection of router links, network links and summary link
+ advertisements that have originated from the area's routers. This
+ information is flooded throughout a single area only. The list of
+ AS external link advertisements (see Section 5) is also considered
+ to be part of each area's topological database.
+
+
+ Area ID
+ A 32-bit number identifying the area. 0.0.0.0 is reserved for
+ the Area ID of the backbone. If assigning subnetted networks as
+ separate areas, the IP network number could be used as the Area
+ ID.
+
+ List of component address ranges
+ The address ranges that define the area. Each address range is
+
+
+
+Moy [Page 43]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ specified by an [address,mask] pair and a status indication of
+ either Advertise or DoNotAdvertise (see Section 12.4.3). Each
+ network is then assigned to an area depending on the address
+ range that it falls into (specified address ranges are not
+ allowed to overlap). As an example, if an IP subnetted network
+ is to be its own separate OSPF area, the area is defined to
+ consist of a single address range - an IP network number with
+ its natural (class A, B or C) mask.
+
+ 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 structure this list includes all the virtual
+ links. A virtual link is identified by the Router ID of its
+ other endpoint; its cost is the cost of the shortest intra-area
+ path through the Transit area that exists between the two
+ routers.
+
+ List of router links advertisements
+ A router links advertisement is generated by each router in the
+ area. It describes the state of the router's interfaces to the
+ area.
+
+ List of network links advertisements
+ One network links advertisement is generated for each transit
+ multi-access network in the area. A network links advertisement
+ describes the set of routers currently connected to the network.
+
+ List of summary link advertisements
+ Summary link advertisements originate from the area's area
+ border routers. They describe routes to destinations internal
+ to the Autonomous System, yet external to the area.
+
+ Shortest-path tree
+ The shortest-path tree for the area, with this router itself as
+ root. Derived from the collected router links and network links
+ advertisements by the Dijkstra algorithm (see Section 16.1).
+
+ AuType
+ The type of authentication used for this area. Authentication
+ types are defined in Appendix D. All OSPF packet exchanges are
+ authenticated. Different authentication schemes may be used in
+ different areas.
+
+ TransitCapability
+ Set to TRUE if and only if there are one or more active virtual
+ links using the area as a Transit area. Equivalently, this
+ parameter indicates whether the area can carry data traffic that
+
+
+
+Moy [Page 44]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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, and is used as an input to a subsequent
+ step of the routing table build process (see Section 16.3).
+
+ ExternalRoutingCapability
+ Whether AS external advertisements will be flooded
+ into/throughout the area. This is a configurable parameter. If
+ AS external advertisements are excluded from the area, the area
+ is called a "stub". Internal to stub areas, routing to AS
+ external destinations will be based solely on a default summary
+ route. The backbone cannot be configured as a stub area. Also,
+ virtual links cannot be configured through stub areas. For more
+ information, see Section 3.6.
+
+ StubDefaultCost
+ If the area has been configured as a stub area, and the router
+ itself is an area border router, then the StubDefaultCost
+ indicates the cost of the default summary link that the router
+ should advertise into the area. There can be a separate cost
+ configured for each IP TOS. See Section 12.4.3 for more
+ information.
+
+
+ Unless otherwise specified, the remaining sections of this document
+ refer to the operation of the protocol in 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 multi-access networks, the Hello Protocol elects a Designated
+ Router for the network. Among other things, the Designated
+
+
+
+Moy [Page 45]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Router controls what adjacencies will be formed over the network
+ (see below).
+
+ The Hello Protocol works differently on broadcast networks, as
+ compared to non-broadcast 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 non-broadcast networks some configuration information is
+ necessary for the operation of the Hello Protocol. Each router
+ that may potentially become Designated Router has a list of all
+ other routers attached to the network. A router, having
+ Designated Router potential, sends Hello Packets to all other
+ potential Designated Routers when its interface to the non-
+ broadcast 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.
+
+ After a neighbor has been discovered, bidirectional
+ communication ensured, and (if on a multi-access 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). An attempt is always made to establish
+ adjacencies over point-to-point networks and virtual links. The
+ first step in bringing up an adjacency is to synchronize the
+ neighbors' topological 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' topological 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 link state advertisements belonging to
+ the router's database. When the neighbor sees a link state
+ advertisement that is more recent than its own database copy, it
+ makes a note that this newer advertisement should be requested.
+
+ This sending and receiving of Database Description packets is
+
+
+
+Moy [Page 46]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ 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 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 link state advertisements for which the neighbor
+ has more up-to-date instances. These advertisements 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' link state
+ advertisements.
+
+ 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 multi-access network has a Designated Router. The
+ Designated Router performs two main functions for the routing
+ protocol:
+
+ o The Designated Router originates a network links
+ advertisement on behalf of the network. This advertisement
+ lists the set of routers (including the Designated Router
+ itself) currently attached to the network. The Link State
+ ID for this advertisement (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 subnet/network
+ mask.
+
+
+
+
+Moy [Page 47]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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. Multi-access 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 link state advertisements. Until the topological databases
+ again converge, some temporary loss of connectivity may result.
+ This may result in ICMP unreachable messages being sent in
+ response to data traffic. For that reason, the Designated
+ Router should change only infrequently. Router Priorities
+ should be configured so that the most dependable router on a
+ network eventually becomes Designated Router.
+
+
+ 7.4. The Backup Designated Router
+
+ In order to make the transition to a new Designated Router
+ smoother, there is a Backup Designated Router for each multi-
+ access network. The Backup Designated Router is also adjacent
+
+
+
+Moy [Page 48]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 topological 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 link state
+ advertisements (which announce the new Designated Router).
+
+ The Backup Designated Router does not generate a network links
+ advertisement for the network. (If it did, the transition to a
+ new Designated Router would be even faster. However, this is a
+ tradeoff between database size and speed of convergence when the
+ Designated Router disappears.)
+
+ The Backup Designated Router is also elected by the Hello
+ Protocol. Each Hello Packet has a field that specifies the
+ Backup Designated Router for the network.
+
+ In some steps of the flooding procedure, the Backup Designated
+ Router plays a passive role, letting the Designated Router do
+ more of the work. This cuts down on the amount of local routing
+ traffic. See Section 13.3 for more information.
+
+
+ 7.5. The graph of adjacencies
+
+ An adjacency is bound to the network that the two routers have
+ in common. If two routers have multiple networks in common,
+ they may have multiple adjacencies between them.
+
+ One can picture the collection of adjacencies on a network as
+ forming an undirected graph. The vertices consist of routers,
+ with an edge joining two routers if they are adjacent. The
+ graph of adjacencies describes the flow of routing protocol
+ packets, and in particular Link State Update Packets, through
+ the Autonomous System.
+
+ Two graphs are possible, depending on whether the common network
+ is multi-access. On physical point-to-point networks (and
+ virtual links), the two routers joined by the network will be
+ adjacent after their databases have been synchronized. On
+ multi-access networks, both the Designated Router and the Backup
+
+
+
+Moy [Page 49]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Designated Router are adjacent to all other routers attached to
+ the network, and these account for all adjacencies.
+
+ 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 topological
+ 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
+
+
+
+ +---+ +---+
+ |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 [Page 50]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 give the details on how to fill in and verify this
+ standard header. Then, for each packet type, the section is listed
+ that gives more details on that particular packet type's processing.
+
+ 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.
+
+ 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 should be calculated before handing
+ the packet to the appropriate authentication procedure.
+
+ AuType and Authentication
+ Each OSPF packet exchange is authenticated. Authentication
+ types are assigned by the protocol and documented in
+ Appendix D. A different authentication scheme can be used
+ for each OSPF area. The 64-bit authentication field is set
+ by the appropriate authentication procedure (determined by
+ AuType). This procedure should be the last called when
+
+
+
+Moy [Page 51]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ forming the packet to be sent. The setting of the
+ authentication field is determined by the packet contents
+ and the authentication key (which is configurable on a per-
+ interface basis).
+
+
+ The IP destination address for the packet is selected as
+ follows. On physical point-to-point networks, the IP
+ destination is always set to the address AllSPFRouters. On all
+ other network types (including virtual links), the majority of
+ OSPF packets are sent as unicasts, i.e., sent directly to the
+ other end of the adjacency. In this case, the IP destination is
+ just the Neighbor IP address associated with the other end of
+ the adjacency (see Section 10). The only packets not sent as
+ unicasts are on broadcast networks; on these networks Hello
+ packets are sent to the multicast destination AllSPFRouters, the
+ Designated Router and its Backup send both Link State Update
+ Packets and Link State Acknowledgment Packets to the multicast
+ address AllSPFRouters, while all other routers send both their
+ Link State Update and Link State Acknowledgment Packets to the
+ multicast address AllDRouters.
+
+ Retransmissions of Link State Update packets are ALWAYS sent as
+ unicasts.
+
+ The IP source address should be set to the IP address of the
+ sending interface. Interfaces to unnumbered point-to-point
+ networks have no associated IP address. On these interfaces,
+ the IP source should be set to any of the other IP addresses
+ belonging to the router. For this reason, there must be at
+ least one IP address assigned to the router.[2] Note that, for
+ most purposes, virtual links act precisely the same as
+ unnumbered point-to-point networks. However, each virtual link
+ does have an IP interface address (discovered during the routing
+ table build process) which is used as the IP source when sending
+ packets over the virtual link.
+
+ For more information on the format of specific OSPF packet
+ types, consult the sections listed in Table 10.
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 52]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ Type Packet name detailed section (transmit)
+ _________________________________________________________
+ 1 Hello Section 9.5
+ 2 Database description Section 10.8
+ 3 Link state request Section 10.9
+ 4 Link state update Section 13.3
+ 5 Link state ack Section 13.5
+
+
+ Table 10: Sections describing OSPF protocol packet transmission.
+
+
+
+ 8.2. Receiving protocol packets
+
+ Whenever a protocol packet is received by the router it is
+ marked with the interface it was received on. For routers that
+ have virtual links configured, it may not be immediately obvious
+ which interface 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
+
+
+
+Moy [Page 53]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ interface. If they do not, the packet should be discarded:
+
+
+ o The version number field must specify protocol version 2.
+
+ o The 16-bit one's complement checksum of the OSPF packet's
+ contents must be verified. Remember that the 64-bit
+ authentication field must be excluded from the checksum
+ calculation.
+
+ o The Area ID found in the OSPF header must be verified. If
+ both of the following cases fail, the packet should be
+ discarded. The Area ID specified in the header must either:
+
+ (1) Match the Area ID of the receiving interface. In this
+ case, the packet has been sent over a single hop.
+ Therefore, the packet's IP source address must be on the
+ same network as the receiving interface. This can be
+ determined 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.
+
+
+ Next, the packet must be authenticated. This depends on the
+ AuType specified (see Appendix D). The authentication procedure
+ may use an Authentication key, which can be configured on a
+
+
+
+Moy [Page 54]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ per-interface basis. If the authentication fails, the packet
+ should be discarded.
+
+ If the packet type is Hello, it should then be further processed
+ by the Hello Protocol (see Section 10.5). All other packet
+ types are sent/received only on adjacencies. This means that
+ the packet must have been sent by one of the router's active
+ neighbors. If the receiving interface is a multi-access network
+ (either broadcast or non-broadcast) the sender is identified by
+ the IP source address found in the packet's IP header. If the
+ receiving interface is a point-to-point link 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.
+ There is a single OSPF interface structure for each attached
+ network; each interface structure has at most one IP interface
+ address (see below). The support for multiple addresses on a single
+ network is a matter for future consideration.
+
+ 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 link state advertisements reflect the
+
+
+
+Moy [Page 55]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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; those items must be the same for all routers
+ connected to the network.
+
+
+ Type
+ The kind of network to which the interface attaches. Its value
+ is either broadcast, non-broadcast yet still multi-access,
+ point-to-point 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 link state
+ advertisements.
+
+ 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.
+
+ 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
+
+
+
+Moy [Page 56]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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. Link state
+ advertisements 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. On multi-access
+ networks, this list is formed by the Hello Protocol.
+ Adjacencies will be formed to some of these neighbors. The set
+ of adjacent neighbors can be determined by an examination of all
+ of the neighbors' states.
+
+ Designated Router
+ The Designated Router selected for the attached network. The
+ Designated Router is selected on all multi-access 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 link state advertisement 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.
+
+
+
+Moy [Page 57]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Backup Designated Router
+ The Backup Designated Router is also selected on all multi-
+ access 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 links advertisement. There may be
+ a separate cost for each IP Type of Service. The cost of an
+ interface must be greater than zero.
+
+ RxmtInterval
+ The number of seconds between link state advertisement
+ retransmissions, for adjacencies belonging to this interface.
+ Also used when retransmitting Database Description and Link
+ State Request Packets.
+
+ Authentication key
+ This configured data allows the authentication procedure to
+ generate and/or verify the Authentication field in the OSPF
+ header. 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 password.
+ This key would be inserted directly into the OSPF header when
+ originating routing protocol packets, and there could be a
+ separate password for each network.
+
+
+ 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.
+
+
+
+
+Moy [Page 58]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ +----+ 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
+
+
+ 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
+ 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
+
+
+
+Moy [Page 59]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ still be addressed to an interface in Loopback state. To
+ facilitate this, such interfaces are advertised in router
+ links advertisements 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 multi-access network on which another
+ router has been selected to be the Designated Router. In
+ this state, the router itself has not been selected Backup
+ Designated Router either. The router forms adjacencies to
+ both the Designated Router and the Backup Designated Router
+ (if they exist).
+
+ Backup
+ In this state, the router itself is the Backup Designated
+ Router on the attached network. It will be promoted to
+ Designated Router when the present Designated Router fails.
+ The router establishes adjacencies to all other routers
+ attached to the network. The Backup Designated Router
+ performs slightly different functions during the Flooding
+ Procedure, as compared to the Designated Router (see Section
+ 13.3). See Section 7.4 for more details on the functions
+ performed by the Backup Designated Router.
+
+ DR In this state, this router itself is the Designated Router
+ on the attached network. Adjacencies are established to all
+ other routers attached to the network. The router must also
+ originate a network links advertisement for the network
+ node. The advertisement 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.
+
+
+
+Moy [Page 60]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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.
+
+ 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.
+
+
+
+Moy [Page 61]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ 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 links advertisement. See Section 12.4
+ for more details.
+
+ Some of the required actions below involve generating events for
+
+
+
+Moy [Page 62]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 or virtual link, the interface state
+ transitions to Point-to-Point. Else, if the router
+ is not eligible to become Designated Router the
+ interface state transitions to DR Other.
+
+ Otherwise, the attached network is multi-access 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. If in addition the attached network is
+ non-broadcast, 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
+
+
+
+
+
+Moy [Page 63]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+
+ 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.
+
+
+
+
+
+Moy [Page 64]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ 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
+
+
+
+Moy [Page 65]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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,
+ 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 non-broadcast, 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 [Page 66]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (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 multi-access networks, Hello Packets are
+ also used to elect the Designated Router and Backup Designated
+ Router, and in that way determine what adjacencies should be
+ formed.
+
+ 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
+
+
+
+Moy [Page 67]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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. There are currently two optional
+ capabilities defined (see Sections 4.5 and A.2). The T-bit of
+ the Options field should be set if the router is capable of
+ calculating separate routes for each IP TOS. The E-bit should
+ be set if and only if the attached area is capable of processing
+ AS external advertisements (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). The rest of 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 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 non-
+ broadcast networks, the sending of Hello packets is more
+ complicated. This will be covered in the next section.
+
+
+ 9.5.1. Sending Hello packets on non-broadcast networks
+
+ Static configuration information is necessary in order for
+ the Hello Protocol to function on non-broadcast networks
+ (see Section C.5). Every attached router which is eligible
+ to become Designated Router has a configured list of all of
+ its neighbors on the network. Each listed neighbor is
+ labelled with its Designated Router eligibility.
+
+ The interface state must be at least Waiting for any Hello
+ Packets to be sent. 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
+
+
+
+Moy [Page 68]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 a non-broadcast 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
+ 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.
+
+
+
+
+Moy [Page 69]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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.
+
+ DD Sequence Number
+ A 32-bit number identifying individual Database Description
+ packets. When the neighbor state ExStart is entered, the DD
+ sequence number should be set to a value not previously seen by
+ the neighboring router. One possible scheme is to use the
+ machine's time of day counter. The DD sequence number is then
+ incremented by the master with each new Database Description
+ packet sent. The slave's DD sequence number indicates the last
+ packet received from the master. Only one packet is allowed
+ outstanding at a time.
+
+ 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 links advertisements 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).
+
+
+
+Moy [Page 70]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Neighbor Options
+ The optional OSPF capabilities supported by the neighbor.
+ Learned during the Database Exchange process (see Section 10.6).
+ The neighbor's optional OSPF capabilities are also listed in its
+ Hello packets. This enables received Hello Packets to be
+ rejected (i.e., neighbor relationships will not even start to
+ form) if there is a mismatch in certain crucial OSPF
+ capabilities (see Section 10.5). The optional OSPF capabilities
+ are documented in Section 4.5.
+
+ Neighbor's Designated Router
+ The neighbor's idea of the Designated Router. If this is the
+ neighbor itself, this is important in the local calculation of
+ the Designated Router. Defined only on multi-access 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 multi-access
+ networks.
+
+
+ The next set of variables are lists of link state advertisements.
+ These lists describe subsets of the area topological database.
+ There can be five distinct types of link state advertisements in an
+ area topological database: router links, network links, and Type 3
+ and 4 summary links (all stored in the area data structure), and AS
+ external links (stored in the global data structure).
+
+
+ Link state retransmission list
+ The list of link state advertisements 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 link state advertisements that make up the
+ area topological 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 link state advertisements that need to be received
+ from this neighbor in order to synchronize the two neighbors'
+ topological 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
+
+
+
+Moy [Page 71]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ appropriate Link State Update packets are received.
+
+
+ 10.1. Neighbor states
+
+ The state of a neighbor (really, the state of a conversation
+ being held with a neighboring router) is documented in the
+ following sections. The states are listed in order of
+ progressing functionality. For example, the inoperative state
+ is listed first, followed by a list of intermediate states
+ before the final, fully functional state is achieved. The
+ specification makes use of this ordering by sometimes making
+ references such as "those neighbors/adjacencies in state greater
+ than X". Figures 12 and 13 show the graph of neighbor state
+ changes. The arcs of the graphs are labelled with the event
+ causing the state change. The neighbor events are documented in
+ Section 10.2.
+
+ The graph in Figure 12 shows the state changes effected by the
+ Hello Protocol. The Hello Protocol is responsible for neighbor
+
+ +----+
+ |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 [Page 72]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link state
+ advertisements.
+
+ For a more detailed description of neighbor state changes,
+ together with the additional actions involved in each change,
+ see Section 10.3.
+
+ +-------+
+ |ExStart|
+ +-------+
+ |
+ NegotiationDone|
+ +->+--------+
+ |Exchange|
+ +--+--------+
+ |
+ Exchange|
+ Done |
+ +----+ | +-------+
+ |Full|<---------+----->|Loading|
+ +----+<-+ +-------+
+ | LoadingDone |
+ +------------------+
+
+ Figure 13: Neighbor state changes (Database Exchange)
+
+ In addition to the state transitions pictured,
+ Event SeqNumberMismatch forces ExStart state,
+ Event BadLSReq forces ExStart state,
+ Event 1-Way forces Init state,
+ Event KillNbr always forces Down State,
+ Event InactivityTimer always forces Down State,
+ Event LLDown always forces Down State,
+ Event AdjOK? leads to adjacency forming/breaking
+
+
+
+
+
+Moy [Page 73]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Down
+ This is the initial state of a neighbor conversation. It
+ indicates that there has been no recent information received
+ from the neighbor. On non-broadcast networks, Hello packets
+ may still be sent to "Down" neighbors, although at a reduced
+ frequency (see Section 9.5.1).
+
+ Attempt
+ This state is only valid for neighbors attached to non-
+ broadcast networks. It indicates that no recent information
+ has been received from the neighbor, but that a more
+ concerted effort should be made to contact the neighbor.
+ This is done by sending the neighbor Hello packets at
+ intervals of HelloInterval (see Section 9.5.1).
+
+ Init
+ In this state, an Hello packet has recently been seen from
+ the neighbor. However, bidirectional communication has not
+ yet been established with the neighbor (i.e., the router
+ itself did not appear in the neighbor's Hello packet). All
+ neighbors in this state (or higher) are listed in the Hello
+ packets sent from the associated interface.
+
+ 2-Way
+ In this state, communication between the two routers is
+ bidirectional. This has been assured by the operation of
+ the Hello Protocol. This is the most advanced state short
+ of beginning adjacency establishment. The (Backup)
+ Designated Router is selected from the set of neighbors in
+ state 2-Way or greater.
+
+ ExStart
+ This is the first step in creating an adjacency between the
+ two neighboring routers. The goal of this step is to decide
+ which router is the master, and to decide upon the initial
+ DD sequence number. Neighbor conversations in this state or
+ greater are called adjacencies.
+
+ Exchange
+ In this state the router is describing its entire link state
+ database by sending Database Description packets to the
+ neighbor. Each Database Description Packet has a DD
+ sequence number, and is explicitly acknowledged. Only one
+ Database Description Packet is allowed outstanding at any
+ one time. In this state, Link State Request Packets may
+ also be sent asking for the neighbor's more recent
+ advertisements. All adjacencies in Exchange state or
+ greater are used by the flooding procedure. In fact, these
+
+
+
+Moy [Page 74]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 advertisements 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 links and
+ network links advertisements.
+
+
+ 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
+ A Hello packet has been received from a 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 non-
+ broadcast networks.
+
+ 2-WayReceived
+ Bidirectional communication has been realized between the
+ two neighboring routers. This is indicated by this router
+ seeing itself in the other'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
+
+
+
+Moy [Page 75]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 10.8.
+
+ BadLSReq
+ A Link State Request has been received for a link state
+ advertisement not contained in the database. This indicates
+ an error in the Database Exchange process.
+
+ Loading Done
+ Link State Updates have been received for all out-of-date
+ portions of the database. This is indicated by the Link
+ state request list becoming empty after the Database
+ Exchange process has completed.
+
+ AdjOK?
+ A decision must be made (again) 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 this 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.
+
+
+
+
+Moy [Page 76]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ LLDown
+ This is an indication from the lower level protocols that
+ the neighbor is now unreachable. For example, on an X.25
+ network this could be indicated by an X.25 clear indication
+ with appropriate cause and diagnostic fields. This event
+ forces the neighbor into Down state.
+
+
+ 10.3. The Neighbor state machine
+
+ A detailed description of the neighbor state changes follows.
+ Each state change is invoked by an event (Section 10.2). This
+ event may produce different effects, depending on the current
+ state of the neighbor. For this reason, the state machine below
+ is organized by current neighbor state and received event. Each
+ entry in the state machine describes the resulting new neighbor
+ state and the required set of additional actions.
+
+ 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 links advertisement 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 a non-broadcast 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 [Page 77]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ sequence number for this neighbor. 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
+
+
+
+Moy [Page 78]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 links, network links and summary links
+ contained in the area structure, along with the AS
+ external links contained in the global structure.
+ AS external link advertisements are omitted from a
+ virtual neighbor's Database summary list. AS
+ external advertisements are omitted from the
+ Database summary list if the area has been
+ configured as a stub (see Section 3.6).
+ Advertisements whose age is equal to MaxAge are
+ instead added to the neighbor's Link state
+ retransmission list. A summary of the Database
+ summary list will be sent to the neighbor in
+ Database Description packets. Each Database
+ Description Packet has a DD sequence number, and is
+ explicitly acknowledged. Only one Database
+ Description Packet is allowed outstanding at any one
+ time. For more detail on the sending and receiving
+ of Database Description packets, see Sections 10.8
+ and 10.6.
+
+
+ State(s): Exchange
+
+ Event: ExchangeDone
+
+ New state: Depends upon action routine.
+
+ Action: If the neighbor Link state request list is empty,
+ the new neighbor state is Full. No other action is
+ required. This is an adjacency's final state.
+
+
+
+
+Moy [Page 79]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 advertisements (which
+ were discovered but not yet received in the Exchange
+ state). These advertisements 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.
+
+
+ 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 link state advertisements.
+
+
+
+Moy [Page 80]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link state
+ advertisements. Then the router increments the DD
+ sequence number for this neighbor, 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
+
+ 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 link
+ state advertisements. Also, the Inactivity Timer is
+ disabled.
+
+
+
+
+
+Moy [Page 81]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link
+ state advertisements. 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 link
+ state advertisements.
+
+
+ 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 link
+ state advertisements.
+
+
+ State(s): 2-Way or greater
+
+ Event: 2-WayReceived
+
+ New state: No state change.
+
+ Action: No action required.
+
+
+ State(s): Init
+
+ Event: 1-WayReceived
+
+
+
+
+
+Moy [Page 82]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 and
+ virtual links always become adjacent. On multi-access 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
+ 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 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
+
+
+
+Moy [Page 83]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ packet to be dropped. In other words, the above fields are
+ really describing the attached network's configuration. However,
+ there is one exception to the above rule: on point-to-point
+ networks and on virtual links, the Network Mask in the received
+ Hello Packet should be ignored.
+
+ The receiving interface attaches to a single OSPF area (this
+ could be the backbone). The setting of the E-bit found in the
+ Hello Packet's Options field must match this area's
+ ExternalRoutingCapability. If AS external advertisements 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 is a multi-access network (either
+ broadcast or non-broadcast) the source is identified by the IP
+ source address found in the Hello's IP header. If the receiving
+ interface is 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 multi-access
+ network (broadcast or non-broadcast), set the neighbor
+ structure's Neighbor ID equal to the Router ID found in the
+ packet's OSPF header. When receiving an Hello on a point-to-
+ point network (but not on a virtual link) set the neighbor
+ structure's Neighbor IP address to the packet's IP source
+ address.
+
+ Now the rest of the Hello Packet is examined, generating events
+ to be given to the neighbor and interface state machines. These
+ state machines are specified either to be executed or scheduled
+ (see Section 4.4). For example, by specifying below that the
+ neighbor state machine be executed in line, several neighbor
+ state transitions may be effected by a single received Hello:
+
+
+ o Each Hello Packet causes the neighbor state machine to be
+ executed with the event HelloReceived.
+
+
+
+
+Moy [Page 84]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ o Then the list of neighbors contained in the Hello Packet is
+ examined. If the router itself appears in this list, the
+ neighbor state machine should be executed with the event 2-
+ WayReceived. Otherwise, the neighbor state machine should
+ be executed with the event 1-WayReceived, and the processing
+ of the packet stops.
+
+ o Next, the Hello Packet's Router Priority field is examined.
+ If this field is different than the one previously received
+ from the neighbor, the receiving interface's state machine
+ is scheduled with the event NeighborChange. In any case,
+ the Router Priority field in the neighbor data structure
+ should be updated accordingly.
+
+ o Next the Designated Router field in the Hello Packet is
+ examined. If the neighbor is both declaring itself to be
+ Designated Router (Designated Router field = Neighbor IP
+ address) and the Backup Designated Router field in the
+ packet is equal to 0.0.0.0 and the receiving interface is in
+ state Waiting, the receiving interface's state machine is
+ scheduled with the event BackupSeen. Otherwise, if the
+ neighbor is declaring itself to be Designated Router and it
+ had not previously, or the neighbor is not declaring itself
+ Designated Router where it had previously, the receiving
+ interface's state machine is scheduled with the event
+ NeighborChange. In any case, the Neighbors' Designated
+ Router item in the neighbor structure is updated
+ accordingly.
+
+ o Finally, the Backup Designated Router field in the Hello
+ Packet is examined. If the neighbor is declaring itself to
+ be Backup Designated Router (Backup Designated Router field
+ = Neighbor IP address) and the receiving interface is in
+ state Waiting, the receiving interface's state machine is
+ scheduled with the event BackupSeen. Otherwise, if the
+ neighbor is declaring itself to be Backup Designated Router
+ and it had not previously, or the neighbor is not declaring
+ itself Backup Designated Router where it had previously, the
+ receiving interface's state machine is scheduled with the
+ event NeighborChange. In any case, the Neighbor's Backup
+ Designated Router item in the neighbor structure is updated
+ accordingly.
+
+ On non-broadcast multi-access 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 [Page 85]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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).
+ The further processing of the Database Description Packet
+ depends on the neighbor state. If the neighbor's state is Down
+ or Attempt the packet should be ignored. Otherwise, if the
+ state is:
+
+
+ Init
+ The neighbor state machine should be executed with the event
+ 2-WayReceived. This causes an immediate state change to
+ either state 2-Way or state ExStart. If the new state is
+ ExStart, the processing of the current packet should then
+ continue in this new state by falling through to case
+ ExStart below.
+
+ 2-Way
+ The packet should be ignored. Database Description Packets
+ are used only for the purpose of bringing up adjacencies.[7]
+
+ ExStart
+ If the received packet matches one of the following cases,
+ then the neighbor state machine should be executed with the
+ event NegotiationDone (causing the state to transition to
+ Exchange), the packet's Options field should be recorded in
+ the neighbor structure's Neighbor Options field and the
+ packet should be accepted as next in sequence and processed
+ further (see below). Otherwise, the packet should be
+ ignored.
+
+ o The initialize(I), more (M) and master(MS) bits are set,
+ the contents of the packet are empty, and the neighbor's
+ Router ID is larger than the router's own. In this case
+ the router is now Slave. Set the master/slave bit to
+ slave, and set the 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 router's own DD
+ sequence number (indicating acknowledgment) and the
+ neighbor's Router ID is smaller than the router's own.
+ In this case the router is Master.
+
+
+
+
+
+Moy [Page 86]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Exchange
+ 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.
+ Otherwise:
+
+ o If the initialize(I) bit is set, generate the neighbor
+ event SeqNumberMismatch and stop processing the packet.
+
+ o If the packet's Options field indicates a different set
+ of optional OSPF capabilities than were previously
+ received from the neighbor (recorded in the Neighbor
+ Options field of the neighbor structure), generate the
+ neighbor event SeqNumberMismatch and stop processing the
+ packet.
+
+ o If the router is master, and the packet's DD sequence
+ number equals the router's own DD sequence number (this
+ packet is the next in sequence) the packet should be
+ accepted and its contents processed (below).
+
+ o If the router is master, and the packet's DD sequence
+ number is one less than the router's DD sequence number,
+ the packet is a duplicate. Duplicates should be
+ discarded by the master.
+
+ o If the router is slave, and the packet's DD sequence
+ number is one more than the router's own DD sequence
+ number (this packet is the next in sequence) the packet
+ should be accepted and its contents processed (below).
+
+ o If the router is slave, and the packet's DD sequence
+ number is equal to the router's DD sequence number, the
+ packet is a duplicate. The slave must respond to
+ duplicates by repeating the last Database Description
+ packet that it had sent.
+
+ 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
+
+
+
+Moy [Page 87]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link state advertisement listed, the
+ advertisement'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 a AS external advertisement (LS
+ type = 5) and the neighbor is associated with a stub area,
+ generate the neighbor event SeqNumberMismatch and stop
+ processing the packet. Otherwise, the router looks up the
+ advertisement in its database to see whether it also has an
+ instance of the link state advertisement. If it does not, or if
+ the database copy is less recent (see Section 13.1), the link
+ state advertisement 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. 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 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.
+
+
+
+
+
+
+
+Moy [Page 88]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link state advertisements 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.
+
+ Each link state advertisement 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 link state advertisements should NOT be placed
+ on the Link state retransmission list for the neighbor. If a
+ link state advertisement 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 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. There are currently two optional capabilities defined.
+ The T-bit should be set if and only if the router is capable of
+ calculating separate routes for each IP TOS. The E-bit should
+ be set if and only if the attached network belongs to a non-stub
+ area. The rest of 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 link state advertisement in the area's
+ topological database (at the time the neighbor transitions into
+ Exchange state) is listed in the neighbor Database summary list.
+ When a new Database Description Packet is to be sent, the
+
+
+
+Moy [Page 89]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ packet's DD sequence number is incremented, and the (new) top of
+ the Database summary list is described by the packet. 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 link state advertisements that
+ need to be obtained from the neighbor. To request these
+ advertisements, a router sends the neighbor the beginning of the
+ Link state request list, packaged in a Link State Request
+ packet.
+
+ When the neighbor responds to these requests with the proper
+ Link State Update packet(s), the Link state request list is
+ truncated and a new Link State Request packet is sent. This
+ process continues until the Link state request list becomes
+ empty. Unsatisfied Link State Request packets are retransmitted
+
+
+
+Moy [Page 90]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ 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
+
+
+
+Moy [Page 91]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+
+
+
+ +---+ +---+
+ |RT1| |RT2|
+ +---+ +---+
+
+ Down Down
+ Hello(DR=0,seen=0)
+ ------------------------------>
+ Hello (DR=RT2,seen=RT1,...) Init
+ <------------------------------
+ ExStart D-D (Seq=x,I,M,Master)
+ ------------------------------>
+ D-D (Seq=y,I,M,Master) ExStart
+ <------------------------------
+ Exchange D-D (Seq=y,M,Slave)
+ ------------------------------>
+ D-D (Seq=y+1,M,Master) Exchange
+ <------------------------------
+ D-D (Seq=y+1,M,Slave)
+ ------------------------------>
+ ...
+ ...
+ ...
+ D-D (Seq=y+n, Master)
+ <------------------------------
+ D-D (Seq=y+n, Slave)
+ Loading ------------------------------>
+ LS Request Full
+ ------------------------------>
+ LS Update
+ <------------------------------
+ LS Request
+ ------------------------------>
+ LS Update
+ <------------------------------
+ Full
+
+
+ Figure 14: An adjacency bring-up example
+
+
+
+
+
+
+
+
+Moy [Page 92]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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.
+
+ 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
+ The destination can be one of three types. Only the first type,
+ Network, is actually used when forwarding IP data traffic. The
+ other destinations are used solely as intermediate steps in the
+ routing table build process.
+
+ Network
+ 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 in this category.
+
+ Area border router
+ Routers that are connected to multiple OSPF areas. Such
+ routers originate summary link advertisements. These
+ routing table entries are used when calculating the inter-
+ area routes (see Section 16.2). These routing table entries
+ may also be associated with configured virtual links.
+
+
+
+
+
+Moy [Page 93]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ AS boundary router
+ Routers that originate AS external link advertisements.
+ These routing table entries 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 all other types, 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 (either an area border router
+ or an AS boundary router) this field indicates the optional OSPF
+ capabilities supported by the destination router. The two
+ optional capabilities currently defined by this specification
+ are the ability to route based on IP TOS and the ability to
+ process AS external link advertisements. For a further
+ discussion of OSPF's optional capabilities, see Section 4.5.
+
+
+ The set of paths to use for a destination may vary based on IP Type
+ of Service and 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 two fields.
+
+
+ Type of Service
+ There can be a separate set of routes for each IP Type of
+ Service. The encoding of TOS in OSPF link state advertisements
+ is described in Section 12.3.
+
+ 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
+ "area border router", there may be separate sets of paths (and
+ therefore separate routing table entries) associated with each
+ of several areas. This will happen when two area border routers
+ share multiple areas in common. For all other destination
+ types, only the set of paths associated with the best area (the
+
+
+
+Moy [Page 94]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ one providing the shortest route) is kept.
+
+
+ The rest of the routing table entry describes the set of paths to
+ the destination. The following fields pertain to the set of paths
+ as a whole. In other words, each one of the paths contained in a
+ routing table entry is of the same path-type and cost (see below).
+
+
+ Path-type
+ There are four possible types of paths used to route traffic to
+ the destination, listed here in order of preference: intra-area,
+ inter-area, type 1 external or type 2 external. Intra-area
+ paths indicate destinations belonging to one of the router's
+ attached areas. Inter-area paths are paths to destinations in
+ other OSPF areas. These are discovered through the examination
+ of received summary link advertisements. AS external paths are
+ paths to destinations external to the AS. These are detected
+ through the examination of received AS external link
+ advertisements.
+
+ Cost
+ The link state cost of the path to the destination. For all
+ paths except type 2 external paths this describes the entire
+ path's cost. For Type 2 external paths, this field describes
+ the cost of the portion of the path internal to the AS. This
+ cost is calculated as the sum of the costs of the path's
+ constituent links.
+
+ Type 2 cost
+ Only valid for type 2 external paths. For these paths, this
+ field indicates the cost of the path's external portion. This
+ cost has been advertised by an AS boundary router, and is the
+ most significant part of the total path cost. For example, a
+ type 2 external path with type 2 cost of 5 is always preferred
+ over a path with type 2 cost of 10, regardless of the cost of
+ the two paths' internal components.
+
+ Link State Origin
+ Valid only for intra-area paths, this field indicates the link
+ state advertisement (router links or network links) that
+ directly references the destination. For example, if the
+ destination is a transit network, this is the transit network's
+ network links advertisement. If the destination is a stub
+ network, this is the router links advertisement for the attached
+ router. The advertisement is discovered during the shortest-
+ path tree calculation (see Section 16.1). Multiple
+ advertisements may reference the destination, however a tie-
+
+
+
+Moy [Page 95]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ breaking scheme always reduces the choice to a single
+ advertisement. 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 multi-access networks, the next hop also
+ includes the IP address of the next router (if any) in the path
+ towards the destination. This next router will always be one of
+ the adjacent neighbors.
+
+ Advertising router
+ Valid only for inter-area and AS external paths. This field
+ indicates the Router ID of the router advertising the summary
+ link or AS external link that led to this path.
+
+
+ 11.1. Routing table lookup
+
+ When an IP data packet is received, an OSPF router finds the
+ routing table entry that best matches the packet's destination.
+ This routing table entry then provides the outgoing interface
+ and next hop router to use in forwarding the packet. This
+ section describes the process of finding the best matching
+ routing table entry. The process consists of a number of steps,
+ wherein the collection of routing table entries is progressively
+ pruned. In the end, the single routing table entry remaining is
+ the called best match.
+
+ Note that the steps described below may fail to produce a best
+ match routing table entry (i.e., all existing routing table
+ entries are pruned for some reason or another). In this case,
+ the packet's IP destination is considered unreachable. Instead
+ of being forwarded, the packet should be dropped and an ICMP
+ destination unreachable message should be returned to the
+ packet's source.
+
+
+ (1) Select the complete set of "matching" routing table entries
+ from the routing table. Each routing table entry describes
+ a (set of) path(s) to a range of IP addresses. If the data
+
+
+
+Moy [Page 96]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ packet's IP destination falls into an entry's range of IP
+ addresses, the routing table entry is called a match. (It is
+ quite likely that multiple entries will match the data
+ packet. For example, a default route will match all
+ packets.)
+
+ (2) Suppose that the packet's IP destination falls into one of
+ the router's configured area address ranges (see Section
+ 3.5), and that the particular area address range is active.
+ This means that there are one or more reachable (by intra-
+ area paths) networks contained in the area address range.
+ The packet's IP destination is then required to belong to
+ one of these constituent networks. For this reason, only
+ matching routing table entries with path-type of intra-area
+ are considered (all others are pruned). If no such matching
+ entries exist, the destination is unreachable (see above).
+ Otherwise, skip to step 4.
+
+ (3) Reduce the set of matching entries to those having the most
+ preferential path-type (see Section 11). OSPF has a four
+ level hierarchy of paths. Intra-area paths are the most
+ preferred, followed in order by inter-area, type 1 external
+ and type 2 external paths.
+
+ (4) Select the remaining routing table entry that provides the
+ longest (most specific) match. Another way of saying this is
+ to choose the remaining entry that specifies the narrowest
+ range of IP addresses.[10] 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.
+
+ (5) At this point, there may still be multiple routing table
+ entries remaining. Each routing entry will specify the same
+ range of IP addresses, but a different IP Type of Service.
+ Select the routing table entry whose TOS value matches the
+ TOS found in the packet header. If there is no routing table
+ entry for this TOS, select the routing table entry for TOS
+ 0. In other words, packets requesting TOS X are routed along
+ the TOS 0 path if a TOS X path does not exist.
+
+
+ 11.2. Sample routing table, without areas
+
+ Consider the Autonomous System pictured in Figure 2. No OSPF
+ areas have been configured. A single metric is shown per
+ outbound interface, indicating that routes will not vary based
+
+
+
+Moy [Page 97]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ on TOS. The calculation of Router RT6's routing table proceeds
+ as described in Section 2.1. The resulting routing table is
+ shown in Table 12. Destination types are abbreviated: Network
+ as "N", area border router as "BR" and AS boundary router as
+ "ASBR".
+
+ 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 advertisements 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 table entries (in this case having
+ identical paths) for Router RT7, in its dual capacities as an
+ area border router and an AS boundary router. Note also 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
+ (BR). These are used when determining the inter-area routes.
+ Note that all of the inter-area routes are associated with the
+ backbone; this is always the case when the calculating router is
+ itself an area border router. Routing information is condensed
+ at area boundaries. In this example, we assume that Area 3 has
+ been defined so that networks N9-N11 and the host route to H1
+ are all condensed to a single route when advertised into the
+ backbone (by Router RT11). Note that the cost of this route is
+
+
+
+Moy [Page 98]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+ 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 *
+ ASBR RT5 0 intra-area 6 RT5 *
+ ASBR 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).
+
+ the minimum 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).
+
+
+
+ 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
+
+
+
+Moy [Page 99]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+ 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 *
+ BR RT3 1 intra-area 1 * *
+ __________________________________________________________________
+ N Ib 0 intra-area 22 RT5 *
+ N Ia 0 intra-area 27 RT5 *
+ BR RT3 0 intra-area 21 RT5 *
+ BR RT7 0 intra-area 14 RT5 *
+ BR RT10 0 intra-area 22 RT5 *
+ BR RT11 0 intra-area 25 RT5 *
+ ASBR RT5 0 intra-area 8 * *
+ ASBR RT7 0 intra-area 14 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 26 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.
+
+ 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
+ in Table 14.
+
+
+
+12. Link State Advertisements
+
+ Each router in the Autonomous System originates one or more link
+ state advertisements. There are five distinct types of link state
+ advertisements, which are described in Section 4.3. The collection
+ of link state advertisements forms the link state or topological
+ database. Each separate type of advertisement has a separate
+
+
+
+Moy [Page 100]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+ 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 *
+ BR RT3 0 intra-area 1 * *
+ BR RT10 0 intra-area 16 RT3 *
+ BR RT11 0 intra-area 19 RT3 *
+ ________________________________________________________________
+ N N9-N11,H1 0 inter-area 20 RT3 RT11
+
+
+ Table 14: Changes resulting from an
+ additional virtual link.
+
+ function. Router links and network links advertisements describe
+ how an area's routers and networks are interconnected. Summary link
+ advertisements provide a way of condensing an area's routing
+ information. AS external advertisements provide a way of
+ transparently advertising externally-derived routing information
+ throughout the Autonomous System.
+
+ Each link state advertisement begins with a standard 20-byte header.
+ This link state advertisement header is discussed below.
+
+
+ 12.1. The Link State Advertisement Header
+
+ The link state advertisement header contains the LS type, Link
+ State ID and Advertising Router fields. The combination of
+ these three fields uniquely identifies the link state
+ advertisement.
+
+ There may be several instances of an advertisement 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 link
+ state advertisement header.
+
+ Several of the OSPF packet types list link state advertisements.
+ When the instance is not important, an advertisement 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.
+
+
+
+
+Moy [Page 101]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ A detailed explanation of the fields contained in the link state
+ advertisement header follows.
+
+
+ 12.1.1. LS age
+
+ This field is the age of the link state advertisement in
+ seconds. It should be processed as an unsigned 16-bit
+ integer. It is set to 0 when the link state advertisement
+ is originated. It must be incremented by InfTransDelay on
+ every hop of the flooding procedure. Link state
+ advertisements are also aged as they are held in each
+ router's database.
+
+ The age of a link state advertisement is never incremented
+ past MaxAge. Advertisements having age MaxAge are not used
+ in the routing table calculation. When an advertisement's
+ age first reaches MaxAge, it is reflooded. A link state
+ advertisement 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 link
+ state advertisements, consult Section 14.
+
+ The LS age field is examined when a router receives two
+ instances of a link state advertisement, both having
+ identical LS sequence numbers and LS checksums. An instance
+ of age MaxAge is then always accepted as most recent; this
+ allows old advertisements 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.[11] See Section 13.1 for more details.
+
+
+ 12.1.2. Options
+
+ The Options field in the link state advertisement header
+ indicates which optional capabilities are associated with
+ the advertisement. OSPF's optional capabilities are
+ described in Section 4.5. There are currently two optional
+ capabilities defined; they are represented by the T-bit and
+ E-bit found in the Options field. The rest of the Options
+ field should be set to zero.
+
+ The E-bit represents OSPF's ExternalRoutingCapability. This
+ bit should be set in all advertisements associated with the
+ backbone, and all advertisements associated with non-stub
+ areas (see Section 3.6). It should also be set in all AS
+ external link advertisements. It should be reset in all
+
+
+
+Moy [Page 102]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ router links, network links and summary link advertisements
+ associated with a stub area. For all link state
+ advertisements, the setting of the E-bit is for
+ informational purposes only; it does not affect the routing
+ table calculation.
+
+ The T-bit represents OSPF's TOS routing capability. This
+ bit should be set in a router links advertisement if and
+ only if the router is capable of calculating separate routes
+ for each IP TOS (see Section 2.4). The T-bit should always
+ be set in network links advertisements. It should be set in
+ summary link and AS external link advertisements if and only
+ if the advertisement describes paths for all TOS values,
+ instead of just the TOS 0 path. Note that, with the T-bit
+ set, there may still be only a single metric in the
+ advertisement (the TOS 0 metric). This would mean that
+ paths for non-zero TOS exist, but are equivalent to the TOS
+ 0 path. A link state advertisement's T-bit is examined when
+ calculating the routing table's non-zero TOS paths (see
+ Section 16.9).
+
+
+ 12.1.3. LS type
+
+ The LS type field dictates the format and function of the
+ link state advertisement. Advertisements of different types
+ have different names (e.g., router links or network links).
+ All advertisement types, except the AS external link
+ advertisements (LS type = 5), are flooded throughout a
+ single area only. AS external link advertisements are
+ flooded throughout the entire Autonomous System, excepting
+ stub areas (see Section 3.6). Each separate advertisement
+ 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 advertisement. Depending on the
+ advertisement's LS type, the Link State ID takes on the
+ values listed in Table 16.
+
+
+ Actually, for Type 3 summary link (LS type = 3)
+ advertisements and AS external link (LS type = 5)
+ advertisements, the Link State ID may additionally have one
+ or more of the destination network's "host" bits set. For
+ example, when originating an AS external link for the
+ network 10.0.0.0 with mask of 255.0.0.0, the Link State ID
+
+
+
+Moy [Page 103]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+ LS Type Advertisement description
+ __________________________________________________
+ 1 These are the router links
+ advertisements. They describe the
+ collected states of the router's
+ interfaces. For more information,
+ consult Section 12.4.1.
+ __________________________________________________
+ 2 These are the network links
+ advertisements. 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 link
+ advertisements. They describe
+ inter-area routes, and enable the
+ condensation of routing information at
+ area borders. Originated by area border
+ routers, the Type 3 advertisements
+ describe routes to networks while the
+ Type 4 advertisements describe routes to
+ AS boundary routers.
+ __________________________________________________
+ 5 These are the AS external link
+ advertisements. 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 link
+ advertisement.
+
+
+ Table 15: OSPF link state advertisements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 104]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 advertisement's 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 advertisements for two
+ networks having the same address but different masks. See
+ Appendix F for details.
+
+ When the link state advertisement 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 link state advertisement.
+ When the link state advertisement 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 advertisement (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
+ advertisement's originator. For router links
+ advertisements, this field is identical to the Link State ID
+ field. Network link advertisements are originated by the
+ network's Designated Router. Summary link advertisements
+ are originated by area border routers. AS external link
+ advertisements 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 link state advertisements.
+
+
+
+Moy [Page 105]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ The space of sequence numbers is linearly ordered. The
+ larger the sequence number (when compared as signed 32-bit
+ integers) the more recent the advertisement. 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. A router uses this
+ sequence number the first time it originates any link state
+ advertisement. Afterwards, the advertisement's sequence
+ number is incremented each time the router originates a new
+ instance of the advertisement. When an attempt is made to
+ increment the sequence number past the maximum value of N -
+ 1 (0x7fffffff), the current instance of the advertisement
+ must first be flushed from the routing domain. This is done
+ by prematurely aging the advertisement (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 -N + 1 (0x80000001).
+
+ The router may be forced to promote the sequence number of
+ one of its advertisements when a more recent instance of the
+ advertisement is unexpectedly received during the flooding
+ process. This should be a rare event. This may indicate
+ that an out-of-date advertisement, originated by the router
+ itself before its last restart/reload, still exists in the
+ Autonomous System. For more information see Section 13.4.
+
+
+ 12.1.7. LS checksum
+
+ This field is the checksum of the complete contents of the
+ advertisement, excepting the LS age field. The LS age field
+ is excepted so that an advertisement'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 [RFC 905]. The
+ link state advertisement header also contains the length of
+ the advertisement 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
+ advertisement. This corruption can occur while an
+ advertisement 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
+
+
+
+Moy [Page 106]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ considered a checksum failure. In other words, calculation
+ of the checksum is not optional.
+
+ The checksum of a link state advertisement 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 advertisement 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.[12] 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. The link state database has been referred to
+ elsewhere in the text as the topological database. All routers
+ belonging to the same area have identical topological databases
+ for the area.
+
+ The databases for each individual area are always dealt with
+ separately. The shortest path calculation is performed
+ separately for each area (see Section 16). Components of the
+ area topological 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 links advertisements,
+ network links advertisements, and summary link advertisements
+ (all listed in the area data structure). In addition, external
+ routes (AS external advertisements) 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
+ advertisement's LS type, Link State ID and Advertising
+ Router.[13] There will be a single instance (the most up-to-
+ date) of each link state advertisement in the database. The
+ database lookup function is invoked during the link state
+ 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
+
+
+
+Moy [Page 107]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ originated a particular link state advertisement, and if so,
+ with what LS sequence number.
+
+ A link state advertisement 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).
+ A link state advertisement 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
+ advertisements (Section 12.4) or c) the advertisement ages out
+ and is flushed from the routing domain (Section 14). Whenever a
+ link state advertisement 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
+
+ All OSPF link state advertisements (with the exception of
+ network links advertisements) specify metrics. In router links
+ advertisements, the metrics indicate the costs of the described
+ interfaces. In summary link and AS external link
+ advertisements, the metric indicates the cost of the described
+ path. In all of these advertisements, a separate metric can be
+ specified for each IP TOS. The encoding of TOS in OSPF link
+ state advertisements is specified in Table 17. That table
+ relates the OSPF encoding to the IP packet header's TOS field
+ (defined in [RFC 1349]). The OSPF encoding is expressed as a
+ decimal integer, and the IP packet header's TOS field is
+ expressed in the binary TOS values used in [RFC 1349].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 108]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ 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.
+
+
+ Each OSPF link state advertisement must specify the TOS 0
+ metric. Other TOS metrics, if they appear, must appear in order
+ of increasing TOS encoding. For example, the TOS 8 (maximize
+ throughput) metric must always appear before the TOS 16
+ (minimize delay) metric when both are specified. If a metric
+ for some non-zero TOS is not specified, its cost defaults to the
+ cost for TOS 0, unless the T-bit is reset in the advertisement's
+ Options field (see Section 12.1.2 for more details).
+
+
+ 12.4. Originating link state advertisements
+
+ Into any given OSPF area, a router will originate several link
+ state advertisements. Each router originates a router links
+ advertisement. If the router is also the Designated Router for
+ any of the area's networks, it will originate network links
+ advertisements for those networks.
+
+ Area border routers originate a single summary link
+ advertisement for each known inter-area destination. AS
+ boundary routers originate a single AS external link
+ advertisement 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
+
+
+
+Moy [Page 109]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ collection of routes. During the flooding procedure, many link
+ state advertisements can be carried by a single Link State
+ Update packet.
+
+ As an example, consider Router RT4 in Figure 6. It is an area
+ border router, having a connection to Area 1 and the backbone.
+ Router RT4 originates 5 distinct link state advertisements into
+ the backbone (one router links, and one summary link for each of
+ the networks N1-N4). Router RT4 will also originate 8 distinct
+ link state advertisements into Area 1 (one router links and
+ seven summary link advertisements as pictured in Figure 7). If
+ RT4 has been selected as Designated Router for Network N3, it
+ will also originate a network links advertisement for N3 into
+ Area 1.
+
+ In this same figure, Router RT5 will be originating 3 distinct
+ AS external link advertisements (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
+ external advertisements for networks N12-N14 will not be flooded
+ into area 3 (see Section 3.6). Instead, Router RT11 would
+ originate a default summary link advertisement 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 a link state advertisement is
+ originated, its LS sequence number is incremented, its LS age is
+ set to 0, its LS checksum is calculated, and the advertisement
+ is added to the link state database and flooded out the
+ appropriate interfaces. See Section 13.2 for details concerning
+ the installation of the advertisement into the link state
+ database. See Section 13.3 for details concerning the flooding
+ of newly originated advertisements.
+
+
+ The ten events that can cause a new instance of a link state
+ advertisement to be originated are:
+
+
+ (1) The LS age field of one of the router's self-originated
+ advertisements reaches the value LSRefreshTime. In this
+ case, a new instance of the link state advertisement is
+ originated, even though the contents of the advertisement
+ (apart from the link state advertisement header) will be the
+ same. This guarantees periodic originations of all link
+ state advertisements. This periodic updating of link state
+
+
+
+Moy [Page 110]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ advertisements adds robustness to the link state algorithm.
+ Link state advertisements that solely describe unreachable
+ destinations should not be refreshed, but should instead be
+ flushed from the routing domain (see Section 14.1).
+
+
+ When whatever is being described by a link state advertisement
+ changes, a new advertisement is originated. However, two
+ instances of the same link state advertisement 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 a link state advertisement to change. These events
+ should cause new originations if and only if the contents of the
+ new advertisement 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 links advertisement.
+
+ (3) An attached network's Designated Router changes. A new
+ router links advertisement should be originated. Also, if
+ the router itself is now the Designated Router, a new
+ network links advertisement should be produced. If the
+ router itself is no longer the Designated Router, any
+ network links advertisement 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 links advertisement. Also, if the
+ router is itself the Designated Router for the attached
+ network, a new network links advertisement 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
+ links advertisement (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
+
+
+
+Moy [Page 111]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ links advertisement (for this route) to be originated in
+ each attached area (but NEVER for the backbone).
+
+ (7) The router becomes newly attached to an area. The router
+ must then originate summary link advertisements 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
+ links advertisement into the virtual link's transit area
+ (see the discussion of the router links advertisement's bit
+ V in Section 12.4.1), as well as originating a new router
+ links advertisement 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 EGP) changes. This will
+ cause an AS boundary router to originate a new instance of
+ an AS external link advertisement.
+
+ (10)
+ A router ceases to be an AS boundary router, perhaps after
+ restarting. In this situation the router should flush all AS
+ external link advertisements that it had previously
+ originated. These advertisements can be flushed via the
+ premature aging procedure specified in Section 14.1.
+
+
+ The construction of each type of link state advertisement is
+ explained in detail below. In general, these sections describe
+ the contents of the advertisement body (i.e., the part coming
+ after the 20-byte advertisement header). For information
+ concerning the building of the link state advertisement header,
+ see Section 12.1.
+
+ 12.4.1. Router links
+
+ A router originates a router links advertisement for each
+ area that it belongs to. Such an advertisement describes
+ the collected states of the router's links to the area. The
+ advertisement is flooded throughout the particular area, and
+ no further.
+
+
+
+Moy [Page 112]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ ....................................
+ . 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 links advertisement is shown in
+ Appendix A (Section A.4.2). The first 20 bytes of the
+ advertisement consist of the generic link state
+ advertisement header that was discussed in Section 12.1.
+ Router links advertisements have LS type = 1. The router
+ indicates whether it is willing to calculate separate routes
+ for each IP TOS by setting (or resetting) the T-bit of the
+ link state advertisement's Options field.
+
+ 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 links
+ advertisements. This enables paths to those types of routers
+ to be saved in the routing table, for later processing of
+ summary link advertisements and AS external link
+ advertisements. 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 links advertisement for a
+ stub area (stub areas cannot contain AS boundary routers).
+ In addition, the router sets bit V in its router links
+
+
+
+Moy [Page 113]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ advertisement for Area A if and only if it is the endpoint
+ of an active virtual link using Area A as its Transit area.
+ This enables the other routers attached to Area A to
+ discover whether the area supports any virtual links (i.e.,
+ is a transit area).
+
+ The router links advertisement 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 links advertisement.
+
+
+ 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 links to routers 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 network's IP
+ address mask. For unnumbered point-to-point networks, the
+ Link Data field should be set to the unnumbered interface's
+ MIB-II [RFC 1213] ifIndex value.
+
+ Finally, the cost of using the link for output (possibly
+ specifying a different cost for each Type of Service) is
+ specified. The output cost of a link is configurable. It
+ must always be non-zero.
+
+ To further describe the process of building the list of link
+
+
+
+Moy [Page 114]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ descriptions, suppose a router wishes to build a router
+ links advertisement 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 advertisement, and the next
+ interface should be examined.
+
+ o Else, if the state of the interface is Down, no links
+ are added.
+
+ o Else, if the state of the interface is Point-to-Point,
+ then add links according to the following:
+
+ - If the neighboring router is fully adjacent, add a
+ Type 1 link (point-to-point) if this is an interface
+ to a point-to-point network, or add a Type 4 link
+ (virtual link) if this is a virtual link. The Link
+ ID should be set to the Router ID of the neighboring
+ router. For virtual links and 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 [RFC 1213] ifIndex value.
+
+ - If this is a numbered point-to-point network (i.e,
+ not a virtual link and not an unnumbered point-to-
+ point network) and the neighboring router's IP
+ address is known, add a Type 3 link (stub network)
+ whose Link ID is the neighbor's IP address, whose
+ Link Data is the mask 0xffffffff indicating a host
+ route, and whose cost is the interface's configured
+ output cost.
+
+ o Else 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 serial line. 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 Else if the state of the interface is Waiting, add a
+ Type 3 link (stub network) whose Link ID is the IP
+ network number of the attached network and whose Link
+ Data is the attached network's address mask.
+
+
+
+
+Moy [Page 115]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ o Else, there has been a Designated Router selected 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)
+ whose Link ID is the IP interface address of the
+ attached network's Designated Router (which may be the
+ router itself) and whose Link Data is the router's own
+ IP interface address. Otherwise, add a link as if the
+ interface state were Waiting (see above).
+
+
+ Unless otherwise specified, the cost of each link generated
+ by the above procedure is equal to the output cost of the
+ associated interface. Note that in the case of serial
+ lines, multiple links may be generated by a single
+ interface.
+
+ After consideration of all the router interfaces, host links
+ are added to the advertisement by examining the list of
+ attached hosts. A host route is represented as a Type 3
+ link (stub network) whose Link ID is the host's IP address
+ and whose Link Data is the mask of all ones (0xffffffff).
+
+ As an example, consider the router links advertisements
+ 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 links advertisements, 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 links advertisement 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 capable of
+ calculating separate routes based on IP TOS, through setting
+ the T-bit in the Options field. It has also indicated that
+ it is an area border router.
+
+
+
+Moy [Page 116]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ ; RT3's router links advertisement for Area 1
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 1 ;indicates router links
+ Link State ID = 192.1.1.3 ;RT3's Router ID
+ Advertising Router = 192.1.1.3 ;RT3's Router ID
+ bit E = 0 ;not an AS boundary router
+ bit B = 1 ;area border router
+ #links = 2
+ Link ID = 192.1.1.4 ;IP address of Desig. Rtr.
+ Link Data = 192.1.1.3 ;RT3's IP interface to net
+ Type = 2 ;connects to transit network
+ # other metrics = 0
+ TOS 0 metric = 1
+
+ Link ID = 192.1.4.0 ;IP Network number
+ Link Data = 0xffffff00 ;Network mask
+ Type = 3 ;connects to stub network
+ # other metrics = 0
+ TOS 0 metric = 2
+
+ Next RT3's router links advertisement 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 TOS-capable, and that it is an area border router.
+
+ ; RT3's router links advertisement for the backbone
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 1 ;indicates router links
+ 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
+ # other metrics = 0
+ TOS 0 metric = 8
+
+ Even though Router RT3 has indicated that it is TOS-capable
+ in the above examples, only a single metric (the TOS 0
+ metric) has been specified for each interface. Different
+ metrics can be specified for each TOS. The encoding of TOS
+
+
+
+Moy [Page 117]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ in OSPF link state advertisements is described in Section
+ 12.3.
+
+ As an example, suppose the point-to-point link between
+ Routers RT3 and RT6 in Figure 15 is a satellite link. The
+ AS administrator may want to encourage the use of the line
+ for high bandwidth traffic. This would be done by setting
+ the metric artificially low for the appropriate TOS value.
+ Router RT3 would then originate the following router links
+ advertisement for the backbone (TOS 8 = maximize
+ throughput):
+
+ ; RT3's router links advertisement for the backbone
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 1 ;indicates router links
+ Link State ID = 192.1.1.3 ;RT3's Router ID
+ Advertising Router = 192.1.1.3
+ 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
+ # other metrics = 1
+ TOS 0 metric = 8
+ TOS = 8 ;maximize throughput
+ metric = 1 ;traffic preferred
+
+
+ 12.4.2. Network links
+
+ A network links advertisement is generated for every transit
+ multi-access network. (A transit network is a network
+ having two or more attached routers). The network links
+ advertisement describes all the routers that are attached to
+ the network.
+
+ The Designated Router for the network originates the
+ advertisement. The Designated Router originates the
+ advertisement only if it is fully adjacent to at least one
+ other router on the network. The network links
+ advertisement is flooded throughout the area that contains
+ the transit network, and no further. The networks links
+ advertisement 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
+
+
+
+Moy [Page 118]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ includes itself in this list.
+
+ The Link State ID for a network links advertisement 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 links advertisement) 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 links
+ advertisement that it had previously originated. This
+ advertisement is no longer used in the routing table
+ calculation. It is flushed by prematurely incrementing the
+ advertisement'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 links advertisements 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 links
+ advertisements are indicated by having their Link State ID
+ equal to one of the router's IP interface addresses and
+ their Advertising Router not equal to the router's current
+ Router ID (see Section 13.4 for more details).
+
+ As an example of a network links advertisement, again
+ consider the area configuration in Figure 6. Network links
+ advertisements 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 links
+ advertisement is generated by RT4 on behalf of Network N3
+ (see Figure 15 for the address assignments):
+
+ ; network links advertisement for Network N3
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 2 ;indicates network links
+ 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
+
+
+
+
+
+
+Moy [Page 119]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 12.4.3. Summary links
+
+ Each summary link advertisement describes a route to a
+ single destination. Summary link advertisements are flooded
+ throughout a single area only. The destination described is
+ one that is external to the area, yet still belonging to the
+ Autonomous System.
+
+ Summary link advertisements 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 link advertisements. 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 link
+ advertisements. If the routing table entry has Path-
+ type of type 1 external or type 2 external, examine the
+ next routing table entry.
+
+ o Else, if the area associated with this set of paths is
+ the Area A itself, do not generate a summary link
+ advertisement for the route.[14]
+
+ o Else, if the next hops associated with this set of paths
+ belong to Area A itself, do not generate a summary link
+ advertisement for the route.[15] 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 link advertisement cannot be
+ generated for this route.
+
+ o Else, if the destination of this route is an AS boundary
+ router, generate a Type 4 link state advertisement for
+
+
+
+Moy [Page 120]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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. These advertisements 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 advertisement 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 F 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 link advertisements. Remember that
+ an area has been defined as a 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 advertisement is made for each
+ range. When the range's status indicates Advertise, a
+ Type 3 advertisement is generated with Link State ID
+ equal to the range's address (if necessary, the Link
+ State ID can also have one or more of the range's "host"
+ bits set; see Appendix F for details) and cost equal to
+ the smallest cost of any of the component networks. When
+ the range's status indicates DoNotAdvertise, the Type 3
+ advertisement 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
+ advertisement 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 F for details) and metric equal to the
+ network's routing table cost.
+
+ If virtual links are being used to provide/increase
+ connectivity of the backbone, routing information
+ concerning the backbone networks should not be condensed
+ before being summarized into the virtual links' Transit
+ areas. Nor should the advertisement of backbone networks
+ into Transit areas be suppressed. In other words, the
+ backbone's configured ranges should be ignored when
+
+
+
+Moy [Page 121]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ originating summary links into Transit areas. The
+ existence of virtual links is determined during the
+ shortest path calculation for the Transit areas (see
+ Section 16.1).
+
+ If a router advertises a summary advertisement for a
+ destination which then becomes unreachable, the router must
+ then flush the advertisement 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
+ advertisement should also be flushed from the routing
+ domain.
+
+ For an example of summary link advertisements, 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 link advertisements.
+ Consider in particular Router RT4. Its routing table was
+ calculated as the example in Section 11.3. RT4 originates
+ summary link advertisements into both the backbone and Area
+ 1. Into the backbone, Router RT4 originates separate
+ advertisements for each of the networks N1-N4. Into Area 1,
+ Router RT4 originates separate advertisements for networks
+ N6-N8 and the AS boundary routers RT5,RT7. It also
+ condenses host routes Ia and Ib into a single summary link
+ advertisement. Finally, the routes to networks N9,N10,N11
+ and Host H1 are advertised by a single summary link
+ advertisement. This condensation was originally performed
+ by the router RT11.
+
+ These advertisements are illustrated graphically in Figures
+ 7 and 8. Two of the summary link advertisements originated
+ by Router RT4 follow. The actual IP addresses for the
+ networks and routers in question have been assigned in
+ Figure 15.
+
+ ; summary link advertisement for Network N1,
+ ; originated by Router RT4 into the backbone
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 3 ;summary link to IP net
+ Link State ID = 192.1.2.0 ;N1's IP network number
+ Advertising Router = 192.1.1.4 ;RT4's ID
+
+
+
+Moy [Page 122]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ TOS = 0
+ metric = 4
+
+ ; summary link advertisement for AS boundary router RT7
+ ; originated by Router RT4 into Area 1
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 4 ;summary link to ASBR
+ Link State ID = Router RT7's ID
+ Advertising Router = 192.1.1.4 ;RT4's ID
+ TOS = 0
+ metric = 14
+
+ Summary link advertisements pertain to a single destination
+ (IP network or AS boundary router). However, for a single
+ destination there may be separate sets of paths, and
+ therefore separate routing table entries, for each Type of
+ Service. All these entries must be considered when building
+ the summary link advertisement for the destination; a single
+ advertisement must specify the separate costs (if they
+ exist) for each TOS. The encoding of TOS in OSPF link state
+ advertisements is described in Section 12.3.
+
+ Clearing the T-bit in the Options field of a summary link
+ advertisement indicates that there is a TOS 0 path to the
+ destination, but no paths for non-zero TOS. This can happen
+ when non-TOS-capable routers exist in the routing domain
+ (see Section 2.4).
+
+ 12.4.4. Originating summary links 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 link advertisements into the area
+ according to the above Section's algorithm, or can choose to
+ originate only a subset of the advertisements, possibly
+ under configuration control. The fewer advertisements
+ originated, the smaller the stub area's link state database,
+ further reducing the demands on its routers' resources.
+ However, omitting advertisements may also lead to sub-
+ optimal inter-area routing, although routing will continue
+ to function.
+
+ As specified in Section 12.4.3, Type 4 link state
+ advertisements (ASBR summary links) are never originated
+ into stub areas.
+
+
+
+
+Moy [Page 123]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ In a stub area, instead of importing external routes each
+ area border router originates a "default summary link" into
+ the area. The Link State ID for the default summary link 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.5. AS external links
+
+ AS external link advertisements describe routes to
+ destinations external to the Autonomous System. Most AS
+ external link advertisements describe routes to specific
+ external destinations; in these cases the advertisement'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 F for
+ details). However, a default route for the Autonomous
+ System can be described in an AS external link advertisement
+ by setting the advertisement's Link State ID to
+ DefaultDestination (0.0.0.0). AS external link
+ advertisements are originated by AS boundary routers. An AS
+ boundary router originates a single AS external link
+ advertisement for each external route that it has learned,
+ either through another routing protocol (such as EGP), or
+ through configuration information.
+
+ In general, AS external link advertisements are the only
+ type of link state advertisements that are flooded
+ throughout the entire Autonomous System; all other types of
+ link state advertisements are specific to a single area.
+ However, AS external link advertisements 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. As with summary link
+ advertisements, if separate paths exist based on TOS,
+ separate TOS costs can be included in the AS external link
+ advertisement. The encoding of TOS in OSPF link state
+ advertisements is described in Section 12.3. If the T-bit
+ of the advertisement's Options field is clear, no non-zero
+ TOS paths to the destination exist.
+
+ If a router advertises an AS external link advertisement for
+
+
+
+Moy [Page 124]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ a destination which then becomes unreachable, the router
+ must then flush the advertisement from the routing domain by
+ setting its age to MaxAge and reflooding (see Section 14.1).
+
+ For an example of AS external link advertisements, consider
+ once again the AS pictured in Figure 6. There are two AS
+ boundary routers: RT5 and RT7. Router RT5 originates three
+ external link advertisements, for networks N12-N14. Router
+ RT7 originates two external link advertisements, for
+ networks N12 and N15. Assume that RT7 has learned its route
+ to N12 via EGP, and that it wishes to advertise a Type 2
+ metric to the AS. RT7 would then originate the following
+ advertisement for N12:
+
+ ; AS external link advertisement for Network N12,
+ ; originated by Router RT7
+
+ LS age = 0 ;always true on origination
+ Options = (T-bit|E-bit) ;TOS-capable
+ LS type = 5 ;indicates AS external link
+ Link State ID = N12's IP network number
+ Advertising Router = Router RT7's ID
+ bit E = 1 ;Type 2 metric
+ TOS = 0
+ metric = 2
+ Forwarding address = 0.0.0.0
+
+ In the above example, the forwarding address field has been
+ set to 0.0.0.0, indicating that packets for the external
+ destination should be forwarded to the advertising OSPF
+ router (RT7). This is not always desirable. Consider the
+ example pictured in Figure 16. There are three OSPF routers
+ (RTA, RTB and RTC) connected to a common network. Only one
+ of these routers, RTA, is exchanging EGP information with
+ the non-OSPF router RTX. RTA must then originate AS
+ external link advertisements for those destinations it has
+ learned from RTX. By using the AS external link
+ advertisement'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
+
+
+
+Moy [Page 125]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ that all externally-destined packets should by default be
+ forwarded to its EGP peer RTX. The resulting AS external
+ link advertisement 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 = (T-bit|E-bit) ;TOS-capable
+ LS type = 5 ;indicates AS external link
+ Link State ID = DefaultDestination ; default route
+ Advertising Router = Router RTA's ID
+ bit E = 1 ;Type 2 metric
+ TOS = 0
+ metric = 1
+ Forwarding address = RTX's IP address
+
+ In figure 16, suppose instead that both RTA and RTB exchange
+ EGP information with RTX. In this case, RTA and RTB would
+ originate the same set of AS external link advertisements.
+ These advertisements, 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 external advertisements, 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 advertisements
+ (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 advertisements (i.e.,
+ same destination, cost and non-zero forwarding address),
+ then the advertisement originated by the router having the
+ highest OSPF Router ID is used. The router having the lower
+ OSPF Router ID can then flush its advertisement. Flushing a
+ link state advertisement is discussed in Section 14.1.
+
+13. The Flooding Procedure
+
+ Link State Update packets provide the mechanism for flooding link
+ state advertisements. A Link State Update packet may contain
+ several distinct advertisements, and floods each advertisement one
+ hop further from its point of origination. To make the flooding
+ procedure reliable, each advertisement must be acknowledged
+ separately. Acknowledgments are transmitted in Link State
+ Acknowledgment packets. Many separate acknowledgments can also be
+
+
+
+Moy [Page 126]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ +
+ |
+ +---+.....|.EGP
+ |RTA|-----|.....+---+
+ +---+ |-----|RTX|
+ | +---+
+ +---+ |
+ |RTB|-----|
+ +---+ |
+ |
+ +---+ |
+ |RTC|-----|
+ +---+ |
+ |
+ +
+
+
+ Figure 16: Forwarding address example
+
+ 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 link state advertisements, other than AS external link
+ advertisements, are associated with a specific area. However, link
+ state advertisements do not contain an area field. A link state
+ advertisement's area must be deduced from the Link State Update
+ packet header.
+
+ For each link state advertisement contained in the packet, the
+ following steps are taken:
+
+
+ (1) Validate the advertisement's LS checksum. If the checksum turns
+ out to be invalid, discard the advertisement and get the next
+ one from the Link State Update packet.
+
+ (2) Examine the link state advertisement's LS type. If the LS type
+ is unknown, discard the advertisement and get the next one from
+ the Link State Update Packet. This specification defines LS
+ types 1-5 (see Section 4.3).
+
+
+
+Moy [Page 127]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (3) Else if this is a AS external link advertisement (LS type = 5),
+ and the area has been configured as a stub area, discard the
+ advertisement and get the next one from the Link State Update
+ Packet. AS external link advertisements are not flooded
+ into/throughout stub areas (see Section 3.6).
+
+ (4) Else if the advertisement's LS age is equal to MaxAge, and there
+ is currently no instance of the advertisement in the router's
+ link state database, then take the following actions:
+
+ (a) Acknowledge the receipt of the advertisement by sending a
+ Link State Acknowledgment packet back to the sending
+ neighbor (see Section 13.5).
+
+ (b) Purge all outstanding requests for equal or previous
+ instances of the advertisement from the sending neighbor's
+ Link State Request list (see Section 10).
+
+ (c) If the sending neighbor is in state Exchange or in state
+ Loading, then install the MaxAge advertisement in the link
+ state database. Otherwise, simply discard the
+ advertisement. In either case, examine the next
+ advertisement (if any) listed in the Link State Update
+ packet.
+
+ (5) Otherwise, find the instance of this advertisement that is
+ currently contained in the router's link state database. If
+ there is no database copy, or the received advertisement is more
+ recent than the database copy (see Section 13.1 below for the
+ determination of which advertisement is more recent) the
+ following steps must be performed:
+
+ (a) If there is already a database copy, and if the database
+ copy was installed less than MinLSInterval seconds ago,
+ discard the new advertisement (without acknowledging it) and
+ examine the next advertisement (if any) listed in the Link
+ State Update packet.
+
+ (b) Otherwise immediately flood the new advertisement 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 advertisement was received from a router other than
+ the Backup DR) the advertisement 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.
+
+
+
+Moy [Page 128]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (d) Install the new advertisement 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 advertisement with the current time (i.e.,
+ the time it was received). The flooding procedure cannot
+ overwrite the newly installed advertisement until
+ MinLSInterval seconds have elapsed. The advertisement
+ installation process is discussed further in Section 13.2.
+
+ (e) Possibly acknowledge the receipt of the advertisement by
+ sending a Link State Acknowledgment packet back out the
+ receiving interface. This is explained below in Section
+ 13.5.
+
+ (f) If this new link state advertisement indicates that it was
+ originated by the receiving router itself (i.e., is
+ considered a self-originated advertisement), the router must
+ take special action, either updating the advertisement or in
+ some cases flushing it from the routing domain. For a
+ description of how self-originated advertisements are
+ detected and subsequently handled, see Section 13.4.
+
+ (6) Else, if there is an instance of the advertisement 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 advertisement 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 advertisement is listed in the Link state
+ retransmission list for the receiving adjacency, the router
+ itself is expecting an acknowledgment for this
+ advertisement. The router should treat the received
+ advertisement as an acknowledgment, by removing the
+ advertisement 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 advertisement by
+ sending a Link State Acknowledgment packet back out the
+ receiving interface. This is explained below in Section
+ 13.5.
+
+
+
+
+Moy [Page 129]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (8) Else, the database copy is more recent. Note an unusual event
+ to network management, discard the advertisement and process the
+ next link state advertisement contained in the Link State Update
+ packet.
+
+
+ 13.1. Determining which link state is newer
+
+ When a router encounters two instances of a link state
+ advertisement, it must determine which is more recent. This
+ occurred above when comparing a received advertisement to its
+ database copy. This comparison must also be done during the
+ Database Exchange procedure which occurs during adjacency
+ bring-up.
+
+ A link state advertisement is identified by its LS type, Link
+ State ID and Advertising Router. For two instances of the same
+ advertisement, the LS sequence number, LS age, and LS checksum
+ fields are used to determine which instance is more recent:
+
+
+ o The advertisement 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.
+
+
+ 13.2. Installing link state advertisements in the database
+
+ Installing a new link state advertisement in the database,
+ either as the result of flooding or a newly self-originated
+ advertisement, may cause the OSPF routing table structure to be
+ recalculated. The contents of the new advertisement should be
+ compared to the old instance, if present. If there is no
+
+
+
+Moy [Page 130]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ difference, there is no need to recalculate the routing table.
+ (Note that even if the contents are the same, the LS checksum
+ will probably be different, since the checksum covers the LS
+ sequence number.)
+
+ If the contents are different, the following pieces of the
+ routing table must be recalculated, depending on the new
+ advertisement's LS type field:
+
+
+ Router links and network links advertisements
+ The entire routing table must be recalculated, starting with
+ the shortest path calculations for each area (not just the
+ area whose topological 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.[16]
+
+ Summary link advertisements
+ The best route to the destination described by the summary
+ link advertisement 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 link
+ advertisements.
+
+ AS external link advertisements
+ The best route to the destination described by the AS
+ external link advertisement must be recalculated (see
+ Section 16.6).
+
+
+ Also, any old instance of the advertisement must be removed from
+ the database when the new advertisement 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) advertisement 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
+ advertisement to the appropriate neighbors' Link state
+
+
+
+Moy [Page 131]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ advertisement that the router itself has just originated (see
+ Section 12.4). For these advertisements, this section provides
+ the entirety of the flooding procedure (i.e., the processing of
+ Section 13 is not performed, since, for example, the
+ advertisement has not been received from a neighbor and
+ therefore does not need to be acknowledged).
+
+ Depending upon the advertisement's LS type, the advertisement
+ can be flooded out only certain interfaces. These interfaces,
+ defined by the following, are called the eligible interfaces:
+
+
+ AS external link advertisements (LS Type = 5)
+ AS external link advertisements are flooded throughout the
+ entire AS, with the exception of stub areas (see Section
+ 3.6). The eligible interfaces are all the router's
+ interfaces, excluding virtual links and those interfaces
+ attaching to stub areas.
+
+ All other LS types
+ All other types are specific to a single area (Area A). The
+ eligible interfaces are all those interfaces attaching to
+ the Area A. If Area A is the backbone, this includes all
+ the virtual links.
+
+
+ Link state databases must remain synchronized over all
+ adjacencies associated with the above eligible interfaces. This
+ is accomplished by executing the following steps on each
+ eligible interface. It should be noted that this procedure may
+ decide not to flood a link state advertisement out a particular
+ interface, if there is a high probability that the attached
+ neighbors have already received the advertisement. However, in
+ these cases the flooding procedure must be absolutely sure that
+ the neighbors eventually do receive the advertisement, so the
+ advertisement 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
+ advertisement. The following steps are executed for each
+ neighbor:
+
+
+
+Moy [Page 132]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (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 advertisement on the list, it
+ indicates that the neighboring router has an instance of
+ the advertisement already. Compare the new
+ advertisement to the neighbor's copy:
+
+ o If the new advertisement is less recent, then
+ examine the next neighbor.
+
+ o If the two copies are the same instance, then delete
+ the advertisement from the Link state request list,
+ and examine the next neighbor.[17]
+
+ o Else, the new advertisement is more recent. Delete
+ the advertisement from the Link state request list.
+
+ (c) If the new advertisement 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 advertisement. Add
+ the new advertisement to the Link state retransmission
+ list for the adjacency. This ensures that the flooding
+ procedure is reliable; the advertisement will be
+ retransmitted at intervals until an acknowledgment is
+ seen from the neighbor.
+
+ (2) The router must now decide whether to flood the new link
+ state advertisement out this interface. If in the previous
+ step, the link state advertisement was NOT added to any of
+ the Link state retransmission lists, there is no need to
+ flood the advertisement out the interface and the next
+ interface should be examined.
+
+ (3) If the new advertisement 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 advertisement already. Therefore, examine
+ the next interface.
+
+ (4) If the new advertisement was received on this interface, and
+ the interface state is Backup (i.e., the router itself is
+
+
+
+Moy [Page 133]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ the Backup Designated Router), examine the next interface.
+ The Designated Router will do the flooding on this
+ interface. If the Designated Router fails, this router will
+ end up retransmitting the updates.
+
+ (5) If this step is reached, the advertisement must be flooded
+ out the interface. Send a Link State Update packet (with
+ the new advertisement as contents) out the interface. The
+ advertisement's LS age must be incremented by InfTransDelay
+ (which must be > 0) when copied into the outgoing Link State
+ Update packet (until the LS age field reaches its maximum
+ value of MaxAge).
+
+ On broadcast networks, the Link State Update packets are
+ multicast. The destination IP address specified for the
+ Link State Update Packet depends on the state of the
+ interface. If the interface state is DR or Backup, the
+ address AllSPFRouters should be used. Otherwise, the
+ address AllDRouters should be used.
+
+ On non-broadcast, multi-access 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 link state
+
+ It is a common occurrence for a router to receive self-
+ originated link state advertisements via the flooding procedure.
+ A self-originated advertisement is detected when either 1) the
+ advertisement's Advertising Router is equal to the router's own
+ Router ID or 2) the advertisement is a network links
+ advertisement and its Link State ID is equal to one of the
+ router's own IP interface addresses.
+
+ However, if the received self-originated advertisement is newer
+ than the last instance that the router actually originated, the
+ router must take special action. The reception of such an
+ advertisement indicates that there are link state advertisements
+ in the routing domain that were originated before the last time
+ the router was restarted. In most cases, the router must then
+ advance the advertisement's LS sequence number one past the
+ received LS sequence number, and originate a new instance of the
+ advertisement.
+
+ It may be the case the router no longer wishes to originate the
+
+
+
+Moy [Page 134]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ received advertisement. Possible examples include: 1) the
+ advertisement is a summary link or AS external link and the
+ router no longer has an (advertisable) route to the destination,
+ 2) the advertisement is a network links advertisement but the
+ router is no longer Designated Router for the network or 3) the
+ advertisement is a network links advertisement 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
+ advertisement). In all these cases, instead of updating the
+ advertisement, the advertisement should be flushed from the
+ routing domain by incrementing the received advertisement's LS
+ age to MaxAge and reflooding (see Section 14.1).
+
+
+ 13.5. Sending Link State Acknowledgment packets
+
+ Each newly received link state advertisement 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 that has received the advertisements. The packet can
+ be sent in one of two ways: delayed and sent on an interval
+ timer, or sent directly (as a unicast) to a particular neighbor.
+ The particular acknowledgment strategy used depends on the
+ circumstances surrounding the receipt of the advertisement.
+
+ Sending delayed acknowledgments accomplishes several things: it
+ facilitates the packaging of multiple acknowledgments in a
+ single Link State Acknowledgment packet; it enables a single
+ Link State Acknowledgment packet to indicate acknowledgments to
+ several neighbors at once (through multicasting); and it
+ randomizes the Link State Acknowledgment packets sent by the
+ various routers attached to a multi-access network. The fixed
+ interval between a router's delayed transmissions must be short
+ (less than RxmtInterval) or needless retransmissions will ensue.
+
+ Direct acknowledgments are sent to a particular neighbor in
+ response to the receipt of duplicate link state advertisements.
+ These acknowledgments are sent as unicasts, and are sent
+ immediately when the duplicate is received.
+
+ The precise procedure for sending Link State Acknowledgment
+
+
+
+Moy [Page 135]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ packets is described in Table 19. The circumstances surrounding
+ the receipt of the advertisement 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
+ on the state of the interface. If the state is DR or Backup,
+ the destination AllSPFRouters is used. In 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
+ advertisement to Network N3, it is received by routers RT1, RT2,
+ and RT3. These routers will not flood the advertisement back
+ onto net N3, but they still must ensure that their topological
+ 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 link state advertisements (see Section 13.3,
+ step 4).
+
+
+
+ 13.6. Retransmitting link state advertisements
+
+ Advertisements flooded out an adjacency are placed on the
+ adjacency's Link state retransmission list. In order to ensure
+ that flooding is reliable, these advertisements are
+ retransmitted until they are acknowledged. The length of time
+ between retransmissions is a configurable per-interface value,
+ RxmtInterval. If this is set too low for an interface, needless
+ retransmissions will ensue. If the value is set too high, the
+ speed of the flooding, in the face of lost packets, may be
+
+
+
+Moy [Page 136]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+
+
+
+ Action taken in state
+ Circumstances Backup All other states
+ _______________________________________________________________
+ Advertisement has No acknowledgment No acknowledgment
+ been flooded back sent. sent.
+ out receiving in-
+ terface (see Sec-
+ tion 13, step 5b).
+ _______________________________________________________________
+ Advertisement 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
+ _______________________________________________________________
+ Advertisement 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
+ _______________________________________________________________
+ Advertisement is a Direct acknowledg- Direct acknowledg-
+ duplicate, and was ment sent. ment sent.
+ not treated as an
+ implied ack-
+ nowledgment.
+ _______________________________________________________________
+ Advertisement's LS Direct acknowledg- Direct acknowledg-
+ age is equal to ment sent. ment sent.
+ MaxAge, and there is
+ no current instance
+ of the advertisement
+ in the link state
+ database (see
+ Section 13, step 4).
+
+
+ Table 19: Sending link state acknowledgements.
+
+
+
+
+
+
+
+Moy [Page 137]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ affected.
+
+ Several retransmitted advertisements may fit into a single Link
+ State Update packet. When advertisements are to be
+ retransmitted, only the number fitting in a single Link State
+ Update packet should be transmitted. Another packet of
+ retransmissions can be sent when some of the advertisements are
+ acknowledged, or on the next firing of the retransmission timer.
+
+ Link State Update Packets carrying retransmissions are always
+ sent as unicasts (directly to the physical address of the
+ neighbor). They are never sent as multicasts. Each
+ advertisement's LS age must be incremented by InfTransDelay
+ (which must be > 0) when copied into the outgoing Link State
+ Update packet (until the LS age field reaches its maximum value
+ of MaxAge).
+
+ If the 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 advertisement acknowledged have an instance on the
+ Link state retransmission list for the neighbor? If not,
+ examine the next acknowledgment. Otherwise:
+
+ o If the acknowledgment is for the same instance that is
+ contained on the list, remove the item from the list and
+ examine the next acknowledgment. Otherwise:
+
+ o Log the questionable acknowledgment, and examine the next
+ one.
+
+
+
+
+
+
+Moy [Page 138]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+14. Aging The Link State Database
+
+ Each link state advertisement has an LS age field. The LS age is
+ expressed in seconds. An advertisement'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 advertisement's LS age is incremented by
+ InfTransDelay.
+
+ An advertisement's LS age is never incremented past the value
+ MaxAge. Advertisements having age MaxAge are not used in the
+ routing table calculation. As a router ages its link state
+ database, an advertisement's LS age may reach MaxAge.[18] At this
+ time, the router must attempt to flush the advertisement from the
+ routing domain. This is done simply by reflooding the MaxAge
+ advertisement just as if it was a newly originated advertisement
+ (see Section 13.3).
+
+ When creating a Database summary list for a newly forming adjacency,
+ any MaxAge advertisements 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 advertisement 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
+ advertisement's LS age hits a multiple of CheckAge, its LS checksum
+ should be verified. If the LS checksum is incorrect, a program or
+ memory error has been detected, and at the very least the router
+ itself should be restarted.
+
+
+ 14.1. Premature aging of advertisements
+
+ A link state advertisement can be flushed from the routing
+ domain by setting its LS age to MaxAge and reflooding the
+ advertisement. This procedure follows the same course as
+ flushing an advertisement whose LS age has naturally reached the
+ value MaxAge (see Section 14). In particular, the MaxAge
+ advertisement 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
+ advertisement's LS age to MaxAge premature aging.
+
+
+
+Moy [Page 139]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Premature aging is used when it is time for a self-originated
+ advertisement's sequence number field to wrap. At this point,
+ the current advertisement instance (having LS sequence number of
+ 0x7fffffff) must be prematurely aged and flushed from the
+ routing domain before a new instance with sequence number
+ 0x80000001 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
+ external advertisement from the routing domain via premature
+ aging. This procedure is preferable to the alternative, which is
+ to originate a new advertisement for the destination specifying
+ a metric of LSInfinity. Premature aging is also be used when
+ unexpectedly receiving self-originated advertisements during the
+ flooding procedure (see Section 13.4).
+
+ A router may only prematurely age its own self-originated link
+ state advertisements. The router may not prematurely age
+ advertisements that have been originated by other routers. An
+ advertisement is considered self-originated when either 1) the
+ advertisement's Advertising Router is equal to the router's own
+ Router ID or 2) the advertisement is a network links
+ advertisement and its Link State ID is equal to one of the
+ router's own IP interface addresses.
+
+
+15. Virtual Links
+
+ The single backbone area (Area ID = 0.0.0.0) cannot be disconnected,
+ or some areas of the Autonomous System will become unreachable. To
+ establish/maintain connectivity of the backbone, virtual links can
+ be configured through non-backbone areas. Virtual links serve to
+ connect physically separate components of the backbone. The two
+ endpoints of a virtual link are area border routers. The virtual
+ 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) 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 links advertisements, and
+ OSPF packets pertaining to the backbone area will flow over the
+
+
+
+Moy [Page 140]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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). Actually, there may be a separate routing
+ table entry for each Type of Service. These are called the virtual
+ link's corresponding routing table entries. The InterfaceUp event
+ occurs for a virtual link when its corresponding TOS 0 routing table
+ entry becomes reachable. Conversely, the InterfaceDown event occurs
+ when its TOS 0 routing table entry becomes unreachable.[19] 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 links advertisement) 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 links are NEVER flooded over virtual adjacencies.
+ This would be duplication of effort, since the same AS external
+ links are already flooded throughout the virtual link's transit
+ area. For this same reason, AS external link advertisements 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 links advertisement 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.
+
+
+
+
+
+Moy [Page 141]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ o In each endpoint's router links advertisement 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. Note that it may be the case that
+ there is a TOS 0 path, but no non-zero TOS paths, between the
+ two endpoint routers. In this case, both routers must revert to
+ being non-TOS-capable, clearing the T-bit in the Options field
+ of their backbone router links advertisements.
+
+ o When virtual links are configured for the backbone, information
+ concerning backbone networks should not be condensed before
+ being summarized for the transit areas. In other words, each
+ backbone network should be advertised into the transit areas in
+ a separate summary link advertisement, regardless of the
+ backbone's configured area address ranges. See Section 12.4.3
+ for more information.
+
+ o The time between link state retransmissions, RxmtInterval, is
+ configured for a virtual link. This should be well over the
+ expected round-trip delay between the two routers. This may be
+ hard to estimate for a virtual link; it is better to err on the
+ side of making it too large.
+
+
+16. Calculation Of The Routing Table
+
+ This section details the OSPF routing table calculation. Using its
+ attached areas' link state databases as input, a router runs the
+ following algorithm, building its routing table step by step. At
+ each step, the router must access individual pieces of the link
+ state databases (e.g., a router links advertisement originated by a
+ certain router). This access is performed by the lookup function
+ discussed in Section 12.2. The lookup process may return a link
+ state advertisement whose LS age is equal to MaxAge. Such an
+ advertisement should not be used in the routing table calculation,
+ and is treated just as if the lookup process had failed.
+
+ The OSPF routing table's organization is explained in Section 11.
+ Two examples of the routing table build process are presented in
+ Sections 11.2 and 11.3. This process can be broken into the
+ following steps:
+
+
+ (1) The present routing table is invalidated. The routing table is
+ built again from scratch. The old routing table is saved so
+ that changes in routing table entries can be identified.
+
+
+
+
+Moy [Page 142]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (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 link advertisements. If the router is attached to
+ multiple areas (i.e., it is an area border router), only
+ backbone summary link advertisements are examined.
+
+ (4) In area border routers connecting to one or more transit areas
+ (i.e, non-backbone areas whose TransitCapability is found to be
+ TRUE), the transit areas' summary link advertisements 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 link advertisements. The locations
+ of the AS boundary routers (which originate the AS external link
+ advertisements) have been determined in steps 2-4.
+
+
+ Steps 2-5 are explained in further detail below. The explanations
+ describe the calculations for TOS 0 only. It may also be necessary
+ to perform each step (separately) for each of the non-zero TOS
+ values.[20] For more information concerning the building of non-zero
+ TOS routes see Section 16.9.
+
+ 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 link advertisements (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.[21] 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
+
+
+
+Moy [Page 143]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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:
+
+
+ Vertex (node) ID
+ A 32-bit number uniquely identifying the vertex. For router
+ vertices this is the router's OSPF Router ID. For network
+ vertices, this is the IP address of the network's Designated
+ Router.
+
+ A link state advertisement
+ Each transit vertex has an associated link state
+ advertisement. For router vertices, this is a router links
+ advertisement. For transit networks, this is a network
+ links advertisement (which is actually originated by the
+ network's Designated Router). In any case, the
+ advertisement'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 multi-access
+ 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 links and network
+ links advertisements). One path is said to be "shorter"
+ than another if it has a smaller link state cost.
+
+
+
+
+
+Moy [Page 144]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ 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 link state advertisement 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 links advertisement, and bit
+ V of the router links advertisement (see Section A.4.2) is
+ set, set Area A's TransitCapability to TRUE. In any case,
+ each link described by the advertisement 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 advertisement. 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 link state
+ advertisement (router links or network links) in Area
+ A's link state database. If the advertisement 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 advertisement.[22]
+
+ (c) If vertex W is already on the shortest-path tree,
+ examine the next link in the advertisement.
+
+
+
+Moy [Page 145]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (d) Calculate the link state cost D of the resulting path
+ from the root to vertex W. D is equal to the sum of the
+ link state cost of the (already calculated) shortest
+ path to vertex V and the advertised cost of the link
+ between vertices V and W. If D is:
+
+ o Greater than the value that already appears for
+ vertex W on the candidate list, then examine the
+ next link.
+
+ 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 [Page 146]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ If the newly added vertex is an area border router (call it
+ ABR), a routing table entry is added whose destination type
+ is "area border router". The Options field found in the
+ associated router links advertisement is copied into the
+ routing table entry's Optional capabilities field. If in
+ addition ABR is the endpoint of one of the calculating
+ router's configured virtual links that uses Area A as its
+ 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 ABR, and the
+ virtual neighbor's IP address is set to the ABR interface
+ address (contained in ABR's router links advertisement) that
+ points back to the root of the shortest-path tree;
+ equivalently, this is the interface that points back to
+ ABR's parent vertex on the shortest-path tree (similar to
+ the calculation in Section 16.1.1).
+
+ If the newly added vertex is an AS boundary router, the
+ routing table entry of type "AS boundary router" for the
+ destination is located. Since routers can belong to more
+ than one area, it is possible that several sets of intra-
+ area paths exist to the AS boundary router, each set using a
+ different area. However, the AS boundary router's routing
+ table entry must indicate a set of paths which utilize a
+ single area. The area leading to the routing table entry is
+ selected as follows: The area providing the shortest path is
+ always chosen; if more than one area provides paths with the
+ same minimum cost, the area with the largest OSPF Area ID
+ (when considered as an unsigned 32-bit integer) is chosen.
+ Note that whenever an AS boundary router's routing table
+ entry is added/modified, the Options found in the associated
+ router links advertisement is copied into the routing table
+ entry's Optional capabilities field.
+
+ 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 links advertisement). 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
+
+
+
+Moy [Page 147]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ added vertex' link state advertisement.
+
+ 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' link state
+ advertisement.
+
+ (5) Iterate the algorithm by returning to Step 2.
+
+
+ The stub networks are added to the tree in the procedure's
+ second stage. In this stage, all router vertices are again
+ examined. Those that have been determined to be unreachable in
+ the above first phase are discarded. For each reachable router
+ vertex (call it V), the associated router links advertisement is
+ found in the link state database. Each stub network link
+ appearing in the advertisement 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 advertisement.
+
+ (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 links
+ advertisement whose Link State ID is smaller than V's Router
+ ID, reset the Link State Origin to V's router links
+ advertisement.
+
+ 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
+
+
+
+Moy [Page 148]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ routing table entry's Link State Origin to V's router links
+ advertisement. 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 links is exhausted, the second stage is completed. At
+ this time, all intra-area routes associated with Area A have
+ been determined.
+
+ The specification does not require that the above two stage
+ method be used to calculate the shortest path tree. However, if
+ another algorithm is used, an identical tree must be produced.
+ For this reason, it is important to note that links between
+ transit vertices must be bidirectional in ordered 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 [BBN].
+
+
+ 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 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
+
+
+
+Moy [Page 149]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ always a transit vertex (i.e., always a router or a transit
+ network).
+
+ If there is at least one intervening router in the current
+ shortest path between the destination and the root, the
+ destination simply inherits the set of next hops from the
+ parent. Otherwise, there are two cases. In the first case,
+ the parent vertex is the root (the calculating router
+ itself). This means that the destination is either a
+ directly connected network or directly connected router.
+ The next hop in this case is simply the OSPF interface
+ connecting to the network/router; no next hop router is
+ required. If the connecting OSPF interface in this case is 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 links advertisement. For
+ each link in the advertisement 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 link
+ advertisements. If the router has active attachments to
+ multiple areas, only backbone summary link advertisements are
+ examined. Routers attached to a single area examine that area's
+ summary links. In either case, the summary links examined below
+ are all part of a single area's link state database (call it
+ Area A).
+
+ Summary link advertisements are originated by the area border
+ routers. Each summary link advertisement in Area A is
+ considered in turn. Remember that the destination described by
+ a summary link advertisement is either a network (Type 3 summary
+ link advertisements) or an AS boundary router (Type 4 summary
+ link advertisements). For each summary link advertisement:
+
+
+ (1) If the cost specified by the advertisement is LSInfinity, or
+ if the advertisement's LS age is equal to MaxAge, then
+ examine the the next advertisement.
+
+
+
+Moy [Page 150]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (2) If the advertisement was originated by the calculating
+ router itself, examine the next advertisement.
+
+ (3) If the collection of destinations described by the summary
+ link advertisement falls into one of the router's configured
+ area address ranges (see Section 3.5) and the particular
+ area address range is active, the summary link advertisement
+ should be ignored. Active means that there are one or more
+ reachable (by intra-area paths) networks contained in the
+ area range. In this case, all addresses in the area range
+ are assumed to be either reachable via intra-area paths, or
+ else to be unreachable by any other means.
+
+ (4) Else, call the destination described by the advertisement N
+ (for Type 3 summary links, N's address is obtained by
+ masking the advertisement's Link State ID with the
+ network/subnet mask contained in the body of the
+ advertisement), and the area border originating the
+ advertisement 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 advertisement and consider the next in the
+ list. Else, this advertisement describes an inter-area path
+ to destination N, whose cost is the distance to BR plus the
+ cost specified in the advertisement. Call the cost of this
+ inter-area path IAC.
+
+ (5) Next, look up the routing table entry for the destination N.
+ (The entry's Destination Type is either Network or AS
+ boundary router.) If no entry exists for N or if the
+ entry's path type is "type 1 external" or "type 2 external",
+ then install the inter-area path to N, with associated area
+ Area A, cost IAC, next hop equal to the list of next hops to
+ router BR, and Advertising router equal to BR.
+
+ (6) Else, if the paths present in the table are intra-area
+ paths, do nothing with the advertisement (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.
+
+
+
+
+
+
+
+Moy [Page 151]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 16.3. Examining transit areas' summary links
+
+ This step is only performed by area border routers attached to
+ one or more transit areas. Transit areas are those areas
+ supporting one or more virtual links; their TransitCapability
+ parameter has been set to TRUE in Step 2 of the Dijkstra
+ algorithm (see Section 16.1). They are the only non-backbone
+ areas that can carry data traffic that neither originates nor
+ terminates in the area itself.
+
+ The purpose of the calculation below is to examine the transit
+ areas to see whether they provide any better (shorter) paths
+ than the paths previously calculated in Sections 16.1 and 16.2.
+ Any paths found that are better than or equal to previously
+ discovered paths are installed in the routing table.
+
+ The calculation proceeds as follows. All the transit areas'
+ summary link advertisements are examined in turn. Each such
+ summary link advertisement describes a route through a transit
+ area Area A to a Network N (N's address is obtained by masking
+ the advertisement's Link State ID with the network/subnet mask
+ contained in the body of the advertisement) or in the case of a
+ Type 4 summary link advertisement, to an AS boundary router N.
+ Suppose also that the summary link advertisement was originated
+ by an area border router BR.
+
+ (1) If the cost advertised by the summary link advertisement is
+ LSInfinity, or if the advertisement's LS age is equal to
+ MaxAge, then examine the next advertisement.
+
+ (2) If the summary link advertisement was originated by the
+ calculating router itself, examine the next advertisement.
+
+ (3) Look up the routing table entry for N. 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 advertisement.
+ 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 advertisement. 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 advertisement. Call this cost
+ IAC.
+
+
+
+
+Moy [Page 152]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (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. Also,
+ unlike Section 16.3 of [RFC 1247], the above calculation
+ installs any better cost found into the routing table entry,
+ from which it may be readvertised in summary link advertisements
+ 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
+
+ ........................
+ . 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
+
+
+
+
+
+Moy [Page 153]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link
+ advertisements 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 link advertisements by the above
+ calculation, Router RT1 will also forward Network N1 traffic
+ towards RT5. Note that in this example the virtual link enables
+ Network N1 traffic to be forwarded through the transit area Area
+ 1, but the actual path the data traffic takes does not follow
+ the virtual link. In other words, virtual links allow transit
+ traffic to be forwarded through an area, but do not dictate the
+ precise path that the traffic will take.
+
+ 16.4. Calculating AS external routes
+
+ AS external routes are calculated by examining AS external link
+ advertisements. Each of the AS external link advertisements is
+ considered in turn. Most AS external link advertisements
+ describe routes to specific IP destinations. An AS external
+ link advertisement can also describe a default route for the
+ Autonomous System (Destination ID = DefaultDestination,
+ network/subnet mask = 0x00000000). For each AS external link
+ advertisement:
+
+
+ (1) If the cost specified by the advertisement is LSInfinity, or
+ if the advertisement's LS age is equal to MaxAge, then
+ examine the next advertisement.
+
+ (2) If the advertisement was originated by the calculating
+ router itself, examine the next advertisement.
+
+ (3) Call the destination described by the advertisement N. N's
+ address is obtained by masking the advertisement's Link
+ State ID with the network/subnet mask contained in the body
+ of the advertisement. Look up the routing table entry for
+ the AS boundary router (ASBR) that originated the
+ advertisement. If no entry exists for router ASBR (i.e.,
+ ASBR is unreachable), do nothing with this advertisement and
+ consider the next in the list.
+
+
+
+Moy [Page 154]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Else, this advertisement describes an AS external path to
+ destination N. Examine the forwarding address specified in
+ the AS external link advertisement. 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. Otherwise, look
+ up the forwarding address in the routing table.[23] An
+ intra-area or inter-area path must exist to the forwarding
+ address. If no such path exists, do nothing with the
+ advertisement and consider the next in the list.
+
+ Call the routing table distance to the forwarding address X
+ (when the forwarding address is set to 0.0.0.0, this is the
+ distance to the ASBR itself), and the cost specified in the
+ advertisement Y. X is in terms of the link state metric,
+ and Y is a type 1 or 2 external metric.
+
+ (4) Next, 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.
+
+ (5) Else, if the paths present in the table are not type 1 or
+ type 2 external paths, do nothing (AS external paths have
+ the lowest priority).
+
+ (6) Otherwise, compare the cost of this new AS external path to
+ the ones present in the table. Type 1 external paths are
+ always shorter than type 2 external paths. 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 are compared by looking at the
+ advertised type 2 metrics, and then if necessary, the
+ distance to the forwarding addresses.
+
+ If the new path is shorter, it replaces the present paths in
+ the routing table entry. If the new path is the same cost,
+ it is added to the routing table entry's list of paths.
+
+
+
+
+
+
+
+
+Moy [Page 155]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 16.5. Incremental updates -- summary link advertisements
+
+ When a new summary link advertisement is received, it is not
+ necessary to recalculate the entire routing table. Call the
+ destination described by the summary link advertisement N (N's
+ address is obtained by masking the advertisement's Link State ID
+ with the network/subnet mask contained in the body of the
+ advertisement), and let Area A be the area to which the
+ advertisement 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
+ link advertisements 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 link advertisement) or to any forwarding addresses,
+ all AS external link advertisements 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 link advertisement)
+ or to any forwarding addresses has changed, all AS external
+ link advertisements will have to be reexamined by rerunning
+
+
+
+Moy [Page 156]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link advertisements
+
+ When a new AS external link advertisement is received, it is not
+ necessary to recalculate the entire routing table. Call the
+ destination described by the AS external link advertisement N.
+ N's address is obtained by masking the advertisement's Link
+ State ID with the network/subnet mask contained in the body of
+ the advertisement. 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 link advertisements
+ 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 link advertisements 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 advertisement must be flushed from the routing domain by
+ setting its LS age to MaxAge and reflooding (see Section
+ 14.1).
+
+ o A routing table entry associated with a configured virtual
+ link has changed. The destination of such a routing table
+ entry is an area border router. The change indicates a
+ modification to the virtual link's cost or viability.
+
+ If the entry indicates that the area border router is newly
+ reachable (via TOS 0), the corresponding virtual link is now
+
+
+
+Moy [Page 157]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 (via TOS 0), 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 links
+ advertisement 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 specifies a separate next hop and Advertising router.
+
+ There is no requirement that a router running OSPF keep track of
+ all possible equal-cost routes to a destination. An
+ implementation may choose to keep only a fixed number of routes
+ to any given destination. This does not affect any of the
+ algorithms presented in this specification.
+
+
+ 16.9. Building the non-zero-TOS portion of the routing table
+
+ The OSPF protocol can calculate a different set of routes for
+ each IP TOS (see Section 2.4). Support for TOS-based routing is
+ optional. TOS-capable and non-TOS-capable routers can be mixed
+ in an OSPF routing domain. Routers not supporting TOS calculate
+ only the TOS 0 route to each destination. These routes are then
+ used to forward all data traffic, regardless of the TOS
+ indications in the data packet's IP header. A router that does
+ not support TOS indicates this fact to the other OSPF routers by
+ clearing the T-bit in the Options field of its router links
+
+
+
+Moy [Page 158]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ advertisement.
+
+ The above sections detailing the routing table calculations
+ handle the TOS 0 case only. In general, for routers supporting
+ TOS-based routing, each piece of the routing table calculation
+ must be rerun separately for the non-zero TOS values. When
+ calculating routes for TOS X, only TOS X metrics can be used.
+ Any link state advertisement may specify a separate cost for
+ each TOS (a cost for TOS 0 must always be specified). The
+ encoding of TOS in OSPF link state advertisements is described
+ in Section 12.3.
+
+ An advertisement can specify that it is restricted to TOS 0
+ (i.e., non-zero TOS is not handled) by clearing the T-bit in the
+ link state advertisement's Option field. Such advertisements
+ are not used when calculating routes for non-zero TOS. For this
+ reason, it is possible that a destination is unreachable for
+ some non-zero TOS. In this case, the TOS 0 path is used when
+ forwarding packets (see Section 11.1).
+
+ The following lists the modifications needed when running the
+ routing table calculation for a non-zero TOS value (called TOS
+ X). In general, routers and advertisements that do not support
+ TOS are omitted from the calculation.
+
+
+ Calculating the shortest-path tree (Section 16.1).
+ Routers that do not support TOS-based routing should be
+ omitted from the shortest-path tree calculation. These
+ routers are identified as those having the T-bit reset in
+ the Options field of their router links advertisements.
+ Such routers should never be added to the Dijktra
+ algorithm's candidate list, nor should their router links
+ advertisements be examined when adding the stub networks to
+ the tree. In particular, if the T-bit is reset in the
+ calculating router's own router links advertisement, it does
+ not run the shortest-path tree calculation for non-zero TOS
+ values.
+
+ Calculating the inter-area routes (Section 16.2).
+ Inter-area paths are the concatenation of a path to an area
+ border router with a summary link. When calculating TOS X
+ routes, both path components must also specify TOS X. In
+ other words, only TOS X paths to the area border router are
+ examined, and the area border router must be advertising a
+ TOS X route to the destination. Note that this means that
+ summary link advertisements having the T-bit reset in their
+ Options field are not considered.
+
+
+
+Moy [Page 159]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Examining transit areas' summary links (Section 16.3).
+ This calculation again considers the concatenation of a path
+ to an area border router with a summary link. As with
+ inter-area routes, only TOS X paths to the area border
+ router are examined, and the area border router must be
+ advertising a TOS X route to the destination.
+
+ Calculating AS external routes (Section 16.4).
+ This calculation considers the concatenation of a path to a
+ forwarding address with an AS external link. Only TOS X
+ paths to the forwarding address are examined, and the AS
+ boundary router must be advertising a TOS X route to the
+ destination. Note that this means that AS external link
+ advertisements having the T-bit reset in their Options field
+ are not considered.
+
+ In addition, the advertising AS boundary router must also be
+ reachable for its advertisements to be considered (see
+ Section 16.4). However, if the advertising router and the
+ forwarding address are not one in the same, the advertising
+ router need only be reachable via TOS 0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 160]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 links advertisement as a host route.
+
+ [3]Note that in these cases both interfaces, the non-virtual and the
+ virtual, would have the same IP address.
+
+ [4]Note that no host route is generated for, and no IP packets can
+ be addressed to, interfaces to unnumbered point-to-point networks.
+ This is regardless of such an interface's state.
+
+ [5]It is instructive to see what happens when the Designated Router
+ for the network crashes. Call the Designated Router for the network
+ RT1, and the Backup Designated Router RT2. If Router RT1 crashes
+ (or maybe its interface to the network dies), the other routers on
+ the network will detect RT1's absence within RouterDeadInterval
+ seconds. All routers may not detect this at precisely the same
+ time; the routers that detect RT1's absence before RT2 does will,
+ for a time, select RT2 to be both Designated Router and Backup
+ Designated Router. When RT2 detects that RT1 is gone it will move
+ itself to Designated Router. At this time, the remaining router
+ having highest Router Priority will be selected as Backup Designated
+ Router.
+
+ [6]On point-to-point networks, the lower level protocols indicate
+ whether the neighbor is up and running. Likewise, existence of the
+ neighbor on virtual links is indicated by the routing table
+ calculation. However, in both these cases, the Hello Protocol is
+ still used. This ensures that communication between the neighbors
+ is bidirectional, and that each of the neighbors has a functioning
+ routing protocol layer.
+
+ [7]When the identity of the Designated Router is changing, it may be
+ quite common for a neighbor in this state to send the router a
+ Database Description packet; this means that there is some momentary
+ disagreement on the Designated Router's identity.
+
+ [8]Note that it is possible for a router to resynchronize any of its
+ fully established adjacencies by setting the adjacency's state back
+ to ExStart. This will cause the other end of the adjacency to
+
+
+
+Moy [Page 161]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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]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.
+
+ [11]MaxAgeDiff is an architectural constant. It indicates the
+ maximum dispersion of ages, in seconds, that can occur for a single
+ link state instance as it is flooded throughout the routing domain.
+ If two advertisements differ by more than this, they are assumed to
+ be different instances of the same advertisement. This can occur
+ when a router restarts and loses track of the advertisement's
+ previous LS sequence number. See Section 13.4 for more details.
+
+ [12]When two advertisements have different LS checksums, they are
+ assumed to be separate instances. This can occur when a router
+ restarts, and loses track of the advertisement's previous LS
+ sequence number. In the case where the two advertisements have the
+ same LS sequence number, it is not possible to determine which link
+ state is actually newer. If the wrong advertisement is accepted as
+ newer, the originating router will originate another instance. See
+ Section 13.4 for further details.
+
+ [13]There is one instance where a lookup must be done based on
+ partial information. This is during the routing table calculation,
+ when a network links advertisement must be found based solely on its
+ Link State ID. The lookup in this case is still well defined, since
+ no two network links advertisements can have the same Link State ID.
+
+ [14]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.
+
+ [15]This clause is only invoked when Area A is a Transit area
+ supporting one or more virtual links. For example, in the area
+ configuration of Figure 6, Router RT11 need only originate a single
+ summary link having the (collapsed) destination N9-N11,H1 into its
+ connected Transit area Area 2, since all of its other eligible
+ routes have next hops belonging to Area 2 (and as such only need be
+ advertised by other area border routers; in this case, Routers RT10
+
+
+
+Moy [Page 162]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ and RT7).
+
+ [16]By keeping more information in the routing table, it is possible
+ for an implementation to recalculate the shortest path tree only for
+ 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 [BBN]. However, these algorithms are beyond the
+ scope of this specification.
+
+ [17]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.
+
+ [18]It should be a relatively rare occurrence for an advertisement's
+ LS age to reach MaxAge in this fashion. Usually, the advertisement
+ will be replaced by a more recent instance before it ages out.
+
+ [19]Only the TOS 0 routes are important here because all OSPF
+ protocol packets are sent with TOS = 0. See Appendix A.
+
+ [20]It may be the case that paths to certain destinations do not
+ vary based on TOS. For these destinations, the routing calculation
+ need not be repeated for each TOS value. In addition, there need
+ only be a single routing table entry for these destinations (instead
+ of a separate entry for each TOS value).
+
+ [21]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.
+
+ [22]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.
+
+ [23]When the forwarding address is non-zero, it should point to a
+ router belonging to another Autonomous System. See Section 12.4.5
+ for more details.
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 163]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+References
+
+ [BBN] McQuillan, J., I. Richer and E. Rosen, "ARPANET
+ Routing Algorithm Improvements", BBN Technical
+ Report 3803, April 1978.
+
+ [DEC] Digital Equipment Corporation, "Information
+ processing systems -- Data communications --
+ Intermediate System to Intermediate System Intra-
+ Domain Routing Protocol", October 1987.
+
+ [McQuillan] McQuillan, J. et.al., "The New Routing Algorithm for
+ the Arpanet", IEEE Transactions on Communications,
+ May 1980.
+
+ [Perlman] Perlman, R., "Fault-Tolerant Broadcast of Routing
+ Information", Computer Networks, December 1983.
+
+ [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ USC/Information Sciences Institute, September 1981.
+
+ [RFC 905] McKenzie, A., "ISO Transport Protocol specification
+ ISO DP 8073", RFC 905, ISO, April 1984.
+
+ [RFC 1112] Deering, S., "Host extensions for IP multicasting",
+ STD 5, RFC 1112, Stanford University, May 1988.
+
+ [RFC 1213] McCloghrie, K., and M. Rose, "Management Information
+ Base for network management of TCP/IP-based
+ internets: MIB-II", STD 17, RFC 1213, Hughes LAN
+ Systems, Performance Systems International, March
+ 1991.
+
+ [RFC 1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
+ July 1991.
+
+ [RFC 1519] Fuller, V., T. Li, J. Yu, and K. Varadhan,
+ "Classless Inter-Domain Routing (CIDR): an Address
+ Assignment and Aggregation Strategy", RFC1519,
+ BARRNet, cisco, MERIT, OARnet, September 1993.
+
+ [RFC 1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD
+ 2, RFC 1340, USC/Information Sciences Institute,
+ July 1992.
+
+ [RFC 1349] Almquist, P., "Type of Service in the Internet
+ Protocol Suite", RFC 1349, July 1992.
+
+
+
+
+Moy [Page 164]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ [RS-85-153] Leiner, B., et.al., "The DARPA Internet Protocol
+ Suite", DDN Protocol Handbook, April 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 165]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A. OSPF data formats
+
+ This appendix describes the format of OSPF protocol packets and OSPF
+ link state advertisements. 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 link state
+ advertisements.
+
+ OSPF packet formats are detailed in Section A.3. A description of
+ OSPF link state advertisements 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. 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 packets sent over virtual links to 576
+ bytes. However, if necessary, the length of OSPF packets can be up
+ to 65,535 bytes (including the IP header).
+
+ The other important features of OSPF's IP encapsulation are:
+
+ o Use of IP multicast. Some OSPF messages are multicast, when
+ sent over multi-access 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.
+
+ 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
+
+
+
+Moy [Page 166]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 [RFC 1340].
+
+ o Routing protocol packets are sent with IP TOS of 0. The OSPF
+ protocol supports TOS-based routing. Routes to any particular
+ destination may vary based on TOS. However, all OSPF routing
+ protocol packets are sent using the normal service TOS value of
+ binary 0000 defined in [RFC 1349].
+
+ 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 [RFC 791] may help implement this
+ objective.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 167]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.2 The Options field
+
+ The OSPF Options field is present in OSPF Hello packets, Database
+ Description packets and all link state advertisements. 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 link state advertisements
+ to a neighbor because of its reduced functionality. Lastly, listing
+ capabilities in link state advertisements allows routers to route
+ traffic around reduced functionality routers, by excluding them from
+ parts of the routing table calculation.
+
+ Two capabilities are currently defined. For each capability, the
+ effect of the capability's appearance (or lack of appearance) in
+ Hello packets, Database Description packets and link state
+ advertisements is specified below. For example, the
+ ExternalRoutingCapability (below called the E-bit) has meaning only
+ in OSPF Hello Packets. Routers should reset (i.e. clear) the
+ unassigned part of the capability field when sending Hello packets
+ or Database Description packets and when originating link state
+ advertisements.
+
+ Additional capabilities may be assigned in the future. Routers
+ encountering unrecognized capabilities in received Hello Packets,
+ Database Description packets or link state advertisements should
+ ignore the capability and process the packet/advertisement normally.
+
+ +-+-+-+-+-+-+-+-+
+ | | | | | | |E|T|
+ +-+-+-+-+-+-+-+-+
+
+ The Options field
+
+
+ T-bit
+ This describes the router's TOS capability. If the T-bit is
+ reset, then the router supports only a single TOS (TOS 0). Such
+ a router is also said to be incapable of TOS-routing, and
+ elsewhere in this document referred to as a TOS-0-only router.
+ The absence of the T-bit in a router links advertisement causes
+ the router to be skipped when building a non-zero TOS shortest-
+ path tree (see Section 16.9). In other words, routers incapable
+
+
+
+Moy [Page 168]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ of TOS routing will be avoided as much as possible when
+ forwarding data traffic requesting a non-zero TOS. The absence
+ of the T-bit in a summary link advertisement or an AS external
+ link advertisement indicates that the advertisement is
+ describing a TOS 0 route only (and not routes for non-zero TOS).
+
+ E-bit
+ This bit reflects the associated area's
+ ExternalRoutingCapability. AS external link advertisements are
+ not flooded into/through OSPF stub areas (see Section 3.6). The
+ E-bit ensures that all members of a stub area agree on that
+ area's configuration. The E-bit is meaningful only in OSPF
+ Hello packets. When the E-bit is reset in the Hello packet sent
+ out a particular interface, it means that the router will
+ neither send nor receive AS external link state advertisements
+ on that interface (in other words, the interface connects to a
+ stub area). Two routers will not become neighbors unless they
+ agree on the state of the E-bit.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 169]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 link state advertisements. For example, Link State Update
+ packets implement the flooding of advertisements throughout the OSPF
+ routing domain. Because of this, OSPF protocol packets cannot be
+ parsed unless the format of link state advertisements is also
+ understood. The format of Link state advertisements 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 [Page 170]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.3.1 The OSPF packet header
+
+ Every OSPF packet starts with a common 24 byte header. This header
+ contains all the necessary information 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. The format of each of
+ these packet types is described in a succeeding section.
+
+
+
+ Type Description
+ ________________________________
+ 1 Hello
+ 2 Database Description
+ 3 Link State Request
+ 4 Link State Update
+ 5 Link State Acknowledgment
+
+
+
+
+
+
+
+
+Moy [Page 171]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Packet length
+ The length of the protocol packet in bytes. This length
+ includes the standard OSPF header.
+
+ Router ID
+ The Router ID of the packet's source. In OSPF, the source and
+ destination of a routing protocol packet are the two ends of an
+ (potential) adjacency.
+
+ 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.
+
+ AuType
+ Identifies the authentication scheme to be used for the packet.
+ Authentication is discussed in Appendix D of the specification.
+ Consult Appendix D for a list of the currently defined
+ authentication types.
+
+ Authentication
+ A 64-bit field for use by the authentication scheme.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 172]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.3.2 The Hello packet
+
+ Hello packets are OSPF packet type 1. These packets are sent
+ periodically on all interfaces (including virtual links) in order to
+ establish and maintain neighbor relationships. In addition, Hello
+ Packets are multicast on those physical networks having a multicast
+ or broadcast capability, enabling dynamic discovery of neighboring
+ routers.
+
+ All routers connected to a common network must agree on certain
+ parameters (Network mask, HelloInterval and RouterDeadInterval).
+ These parameters are included in Hello packets, so that differences
+ can inhibit the forming of neighbor relationships. A detailed
+ explanation of the receive processing for Hello packets is presented
+ in Section 10.5. The sending of Hello packets is covered in Section
+ 9.5.
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version # | 1 | Packet length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Router ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Area ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | AuType |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Authentication |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Authentication |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Network Mask |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | HelloInterval | Options | Rtr Pri |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RouterDeadInterval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Designated Router |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Backup Designated Router |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Neighbor |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+
+
+Moy [Page 173]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 advertising 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 advertising 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 [Page 174]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 topological 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 master,
+ the other a 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 0 | Options |0|0|0|0|0|I|M|MS
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DD sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +- -+
+ | A |
+ +- Link State Advertisement -+
+ | Header |
+ +- -+
+ | |
+ +- -+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+ The format of the Database Description packet is very similar to
+ both the Link State Request and Link State Acknowledgment packets.
+ The main part of all three is a list of items, each item describing
+
+
+
+Moy [Page 175]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ a piece of the topological 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.
+
+ 0 These fields are reserved. They must be 0.
+
+ 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
+ topological database's pieces. Each link state advertisement in the
+ database is described by its link state advertisement header. The
+ link state advertisement header is documented in Section A.4.1. It
+ contains all the information required to uniquely identify both the
+ advertisement and the advertisement's current instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 176]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 topological 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. The sending of Link State
+ Request packets is the last step in bringing up an adjacency.
+
+ A router that sends a Link State Request packet has in mind the
+ precise instance of the database pieces it is requesting, defined by
+ LS sequence number, LS checksum, and LS age, although these fields
+ are not specified in the Link State Request Packet itself. The
+ router may receive even more recent instances in response.
+
+ The sending of Link State Request packets is documented in Section
+ 10.9. The reception of Link State Request packets is documented in
+ Section 10.7.
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version # | 3 | Packet length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Router ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Area ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Checksum | AuType |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Authentication |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Authentication |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LS type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link State ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Advertising Router |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+ Each advertisement requested is specified by its LS type, Link State
+ ID, and Advertising Router. This uniquely identifies the
+ advertisement, but not its instance. Link State Request packets are
+
+
+
+Moy [Page 177]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ understood to be requests for the most recent instance (whatever
+ that might be).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 178]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.3.5 The Link State Update packet
+
+ Link State Update packets are OSPF packet type 4. These packets
+ implement the flooding of link state advertisements. Each Link
+ State Update packet carries a collection of link state
+ advertisements one hop further from its origin. Several link state
+ advertisements 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 advertisements are acknowledged in Link
+ State Acknowledgment packets. If retransmission of certain
+ advertisements is necessary, the retransmitted advertisements are
+ always carried by unicast Link State Update packets. For more
+ information on the reliable flooding of link state advertisements,
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | # advertisements |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +- +-+
+ | Link state advertisements |
+ +- +-+
+ | ... |
+
+
+
+ # advertisements
+ The number of link state advertisements included in this update.
+
+
+
+
+
+
+Moy [Page 179]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ The body of the Link State Update packet consists of a list of link
+ state advertisements. Each advertisement begins with a common 20
+ byte header, the link state advertisement header. This header is
+ described in Section A.4.1. Otherwise, the format of each of the
+ five types of link state advertisements is different. Their formats
+ are described in Section A.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 180]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.3.6 The Link State Acknowledgment packet
+
+ Link State Acknowledgment Packets are OSPF packet type 5. To make
+ the flooding of link state advertisements reliable, flooded
+ advertisements are explicitly acknowledged. This acknowledgment is
+ accomplished through the sending and receiving of Link State
+ Acknowledgment packets. Multiple link state advertisements can be
+ acknowledged in a single Link State Acknowledgment packet.
+
+ Depending on the state of the sending interface and the source of
+ the advertisements being acknowledged, 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 link state
+ advertisement 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +- -+
+ | A |
+ +- Link State Advertisement -+
+ | Header |
+ +- -+
+ | |
+ +- -+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+Moy [Page 181]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Each acknowledged link state advertisement is described by its link
+ state advertisement header. The link state advertisement header is
+ documented in Section A.4.1. It contains all the information
+ required to uniquely identify both the advertisement and the
+ advertisement's current instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 182]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.4 Link state advertisement formats
+
+ There are five distinct types of link state advertisements. Each
+ link state advertisement begins with a standard 20-byte link state
+ advertisement header. This header is explained in Section A.4.1.
+ Succeeding sections then diagram the separate link state
+ advertisement types.
+
+ Each link state advertisement describes a piece of the OSPF routing
+ domain. Every router originates a router links advertisement. In
+ addition, whenever the router is elected Designated Router, it
+ originates a network links advertisement. Other types of link state
+ advertisements may also be originated (see Section 12.4). All link
+ state advertisements are then flooded throughout the OSPF routing
+ domain. The flooding algorithm is reliable, ensuring that all
+ routers have the same collection of link state advertisements. (See
+ Section 13 for more information concerning the flooding algorithm).
+ This collection of advertisements is called the link state (or
+ topological) 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 [Page 183]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.4.1 The Link State Advertisement header
+
+ All link state advertisements begin with a common 20 byte header.
+ This header contains enough information to uniquely identify the
+ advertisement (LS type, Link State ID, and Advertising Router).
+ Multiple instances of the link state advertisement 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 link state advertisement 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 link state advertisement 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 link state advertisement. Each link state type
+ has a separate advertisement format. The link state types are
+ as follows (see Section 12.1.3 for further explanation):
+
+
+
+
+
+
+
+
+
+
+Moy [Page 184]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+
+ LS Type Description
+ ___________________________________
+ 1 Router links
+ 2 Network links
+ 3 Summary link (IP network)
+ 4 Summary link (ASBR)
+ 5 AS external link
+
+
+
+
+ Link State ID
+ This field identifies the portion of the internet environment
+ that is being described by the advertisement. The contents of
+ this field depend on the advertisement's LS type. For example,
+ in network links advertisements 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 link state
+ advertisement. For example, in network links advertisements
+ this field is set to the Router ID of the network's Designated
+ Router.
+
+ LS sequence number
+ Detects old or duplicate link state advertisements. Successive
+ instances of a link state advertisement 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 link state
+ advertisement, including the link state advertisement header but
+ excepting the LS age field. See Section 12.1.7 for more details.
+
+ length
+ The length in bytes of the link state advertisement. This
+ includes the 20 byte link state advertisement header.
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 185]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.4.2 Router links advertisements
+
+ Router links advertisements are the Type 1 link state
+ advertisements. Each router in an area originates a router links
+ advertisement. The advertisement 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
+ links advertisement. For details concerning the construction of
+ router links advertisements, 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 | TOS 0 metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TOS | 0 | metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TOS | 0 | metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link Data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+ In router links advertisements, the Link State ID field is set to
+ the router's OSPF Router ID. The T-bit is set in the
+ advertisement's Option field if and only if the router is able to
+
+
+
+Moy [Page 186]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ calculate a separate set of routes for each IP TOS. Router links
+ advertisements are flooded throughout a single area only.
+
+ bit V
+ When set, the router is an endpoint of an active virtual link
+ that is using the described area as a 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 by this advertisement.
+ 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 data field. For links to stub networks this field
+ specifies the network's IP address mask. For other link types the
+ Link Data specifies the router's associated IP interface address.
+
+
+ Type
+ A quick description of the router link. One of the following.
+ Note that host routes are classified as links to stub networks
+ whose network mask is 0xffffffff.
+
+
+
+ Type Description
+ __________________________________________________
+ 1 Point-to-point connection to another router
+ 2 Connection to a transit network
+ 3 Connection to a stub network
+ 4 Virtual link
+
+
+
+
+
+
+Moy [Page 187]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 a link state advertisement (i.e., another router
+ or a transit network) the Link ID is equal to the neighboring
+ advertisement's Link State ID. This provides the key for
+ looking up said advertisement in the link state database. 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
+ Contents again depend on the link's Type field. For connections
+ to stub networks, it specifies the network's IP address mask.
+ For unnumbered point-to-point connections, it specifies the
+ interface's MIB-II [RFC 1213] ifIndex value. For the other link
+ types it specifies the router's associated IP interface address.
+ This latter piece of information is needed during the routing
+ table build process, when calculating the IP address of the next
+ hop. See Section 16.1.1 for more details.
+
+ # TOS
+ The number of different TOS metrics given for this link, not
+ counting the required metric for TOS 0. For example, if no
+ additional TOS metrics are given, this field should be set to 0.
+
+ TOS 0 metric
+ The cost of using this router link for TOS 0.
+
+
+ For each link, separate metrics may be specified for each Type of
+ Service (TOS). The metric for TOS 0 must always be included, and
+ was discussed above. Metrics for non-zero TOS are described below.
+ The encoding of TOS in OSPF link state advertisements is described
+ in Section 12.3. Note that the cost for non-zero TOS values that
+ are not specified defaults to the TOS 0 cost. Metrics must be
+ listed in order of increasing TOS encoding. For example, the metric
+ for TOS 16 must always follow the metric for TOS 8 when both are
+
+
+
+Moy [Page 188]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ specified.
+
+
+ TOS IP Type of Service that this metric refers to. The encoding of
+ TOS in OSPF link state advertisements is described in Section
+ 12.3.
+
+ metric
+ The cost of using this outbound router link, for traffic of the
+ specified TOS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 189]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.4.3 Network links advertisements
+
+ Network links advertisements are the Type 2 link state
+ advertisements. A network links advertisement is originated for
+ each transit network in the area. A transit network is a multi-
+ access network that has more than one attached router. The network
+ links advertisement is originated by the network's Designated
+ Router. The advertisement describes all routers attached to the
+ network, including the Designated Router itself. The
+ advertisement'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, for
+ all Types of Service. This is why the TOS and metric fields need
+ not be specified in the network links advertisement. For details
+ concerning the construction of network links advertisements, see
+ Section 12.4.2.
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LS age | Options | 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Link State ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Advertising Router |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LS sequence number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LS checksum | length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Network Mask |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attached Router |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+ Network Mask
+ The IP address mask for the network. For example, a class A
+ network would have the mask 0xff000000.
+
+ Attached Router
+ The Router IDs of each of the routers attached to the network.
+ Actually, only those routers that are fully adjacent to the
+ Designated Router are listed. The Designated Router includes
+
+
+
+Moy [Page 190]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ itself in this list. The number of routers included can be
+ deduced from the link state advertisement header's length field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 191]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.4.4 Summary link advertisements
+
+ Summary link advertisements are the Type 3 and 4 link state
+ advertisements. These advertisements are originated by area border
+ routers. A separate summary link advertisement is made for each
+ destination (known to the router) which belongs to the AS, yet is
+ outside the area. For details concerning the construction of
+ summary link advertisements, see Section 12.4.3.
+
+ Type 3 link state advertisements are used when the destination is an
+ IP network. In this case the advertisement'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 F for
+ details). When the destination is an AS boundary router, a Type 4
+ advertisement 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 link state advertisements 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TOS | metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+ For stub areas, Type 3 summary link advertisements 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
+ advertisement's Link State ID is always set to DefaultDestination
+ (0.0.0.0) and the Network Mask is set to 0.0.0.0.
+
+
+
+
+Moy [Page 192]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Separate costs may be advertised for each IP Type of Service. The
+ encoding of TOS in OSPF link state advertisements is described in
+ Section 12.3. Note that the cost for TOS 0 must be included, and is
+ always listed first. If the T-bit is reset in the advertisement's
+ Option field, only a route for TOS 0 is described by the
+ advertisement. Otherwise, routes for the other TOS values are also
+ described; if a cost for a certain TOS is not included, its cost
+ defaults to that specified for TOS 0.
+
+ Network Mask
+ For Type 3 link state advertisements, 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 link state advertisements.
+
+
+ For each specified Type of Service, the following fields are
+ defined. The number of TOS routes included can be calculated from
+ the link state advertisement header's length field. Values for TOS
+ 0 must be specified; they are listed first. Other values must be
+ listed in order of increasing TOS encoding. For example, the cost
+ for TOS 16 must always follow the cost for TOS 8 when both are
+ specified.
+
+
+ TOS The Type of Service that the following cost concerns. The
+ encoding of TOS in OSPF link state advertisements is described
+ in Section 12.3.
+
+ metric
+ The cost of this route. Expressed in the same units as the
+ interface costs in the router links advertisements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 193]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+A.4.5 AS external link advertisements
+
+ AS external link advertisements are the Type 5 link state
+ advertisements. These advertisements are originated by AS boundary
+ routers. A separate advertisement is made for each destination
+ (known to the router) which is external to the AS. For details
+ concerning the construction of AS external link advertisements, see
+ Section 12.4.3.
+
+ AS external link advertisements usually describe a particular
+ external destination. For these advertisements 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 F for details). AS external link advertisements 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| TOS | metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Forwarding address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | External Route Tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+
+
+
+ Separate costs may be advertised for each IP Type of Service. The
+ encoding of TOS in OSPF link state advertisements is described in
+ Section 12.3. Note that the cost for TOS 0 must be included, and is
+
+
+
+Moy [Page 194]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ always listed first. If the T-bit is reset in the advertisement's
+ Option field, only a route for TOS 0 is described by the
+ advertisement. Otherwise, routes for the other TOS values are also
+ described; if a cost for a certain TOS is not included, its cost
+ defaults to that specified for TOS 0.
+
+ Network Mask
+ The IP address mask for the advertised destination. For
+ example, when advertising a class A network the mask 0xff000000
+ would be used.
+
+
+ For each specified Type of Service, the following fields are
+ defined. The number of TOS routes included can be calculated from
+ the link state advertisement header's length field. Values for TOS
+ 0 must be specified; they are listed first. Other values must be
+ listed in order of increasing TOS encoding. For example, the cost
+ for TOS 16 must always follow the cost for TOS 8 when both are
+ specified.
+
+
+ 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 is is comparable directly (without translation) to the link
+ state metric.
+
+ 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 advertisement's
+ originator (i.e., the responsible AS boundary router).
+
+ TOS The Type of Service that the following cost concerns. The
+ encoding of TOS in OSPF link state advertisements is described
+ in Section 12.3.
+
+ metric
+ The cost of this route. Interpretation depends on the external
+ type indication (bit E above).
+
+ 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.
+
+
+
+Moy [Page 195]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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
+ link state advertisement. When the LS age field of one of the
+ router's self-originated advertisements reaches the value
+ LSRefreshTime, a new instance of the link state advertisement is
+ originated, even though the contents of the advertisement (apart
+ from the link state header) will be the same. The value of
+ LSRefreshTime is set to 30 minutes.
+
+ MinLSInterval
+ The minimum time between distinct originations of any particular
+ link state advertisement. The value of MinLSInterval is set to
+ 5 seconds.
+
+ MaxAge
+ The maximum age that a link state advertisement can attain. When
+ an advertisement's LS age field reaches MaxAge, it is reflooded
+ in an attempt to flush the advertisement from the routing domain
+ (See Section 14). Advertisements of age MaxAge are not used in
+ the routing table calculation. The value of MaxAge must be
+ greater than LSRefreshTime. The value of MaxAge is set to 1
+ hour.
+
+ CheckAge
+ When the age of a link state advertisement (that is contained in
+ the link state database) hits a multiple of CheckAge, the
+ advertisement's checksum is verified. An incorrect checksum at
+ this time indicates a serious error. The value of CheckAge is
+ set to 5 minutes.
+
+ MaxAgeDiff
+ The maximum time dispersion that can occur, as a link state
+ advertisement is flooded throughout the AS. Most of this time
+ is accounted for by the link state advertisements sitting on
+ router output queues (and therefore not aging) during the
+ flooding process. The value of MaxAgeDiff is set to 15 minutes.
+
+
+
+
+Moy [Page 196]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ LSInfinity
+ The metric value indicating that the destination described by a
+ link state advertisement is unreachable. Used in summary link
+ advertisements and AS external link advertisements 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
+ link advertisements and in stub areas' type 3 summary link
+ advertisements. Its value is the IP address 0.0.0.0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 197]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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 link state advertisements from the routing
+ domain (see Section 14.1), or they will persist for up to
+ MaxAge minutes.
+
+ TOS capability
+ This item indicates whether the router will calculate
+ separate routes based on TOS. For more information, see
+ Sections 4.5 and 16.9.
+
+ 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
+
+
+
+Moy [Page 198]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ traffic. The following items must be configured for an area:
+
+
+ Area ID
+ This is a 32-bit number that identifies the area. The Area
+ ID of 0.0.0.0 is reserved for the backbone. If the area
+ represents a subnetted network, the IP network number of the
+ subnetted network may be used for the Area ID.
+
+ List of address ranges
+ An OSPF area is defined as a list of address ranges. Each
+ address range consists of the following items:
+
+ [IP address, mask]
+ Describes the collection of IP addresses contained
+ in the address range. Networks and hosts are
+ assigned to an area depending on whether their
+ addresses fall into one of the area's defining
+ address ranges. Routers are viewed as belonging to
+ multiple areas, depending on their attached
+ networks' area membership.
+
+ Status Set to either Advertise or DoNotAdvertise. Routing
+ information is condensed at area boundaries.
+ External to the area, at most a single route is
+ advertised (via a summary link advertisement) 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.
+
+ AuType
+ Each area can be configured for a separate type of
+ authentication. See Appendix D for a discussion of the
+ defined authentication types.
+
+ ExternalRoutingCapability
+ Whether AS external advertisements will be flooded
+ into/throughout the area. If AS external advertisements are
+
+
+
+Moy [Page 199]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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
+ link that the router should advertise into the area. There
+ can be a separate cost configured for each IP TOS. See
+ Section 12.4.3 for more information.
+
+ C.3 Router interface parameters
+
+ Some of the configurable router interface parameters (such as IP
+ interface address and subnet mask) actually imply properties of
+ the attached networks, and therefore must be consistent across
+ all the routers attached to that network. The parameters that
+ must be configured for a router interface are:
+
+
+ IP interface address
+ The IP protocol address for this interface. This uniquely
+ identifies the router over the entire internet. An IP
+ address is not required on serial lines. Such a serial line
+ is called "unnumbered".
+
+ 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.
+
+ Interface output cost(s)
+ 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 links
+ advertisement. There may be a separate cost for each IP
+ Type of Service. The interface output cost(s) must always
+ be greater than 0.
+
+
+
+Moy [Page 200]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ RxmtInterval
+ The number of seconds between link state advertisement
+ 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. It will need to be larger on low speed serial lines
+ and virtual links. 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. Link state
+ advertisements contained in the update packet must have
+ their age incremented by this amount before transmission.
+ This value should take into account the transmission and
+ propagation delays of the interface. It must be greater
+ than 0. Sample value for a local area network: 1 second.
+
+ Router Priority
+ An 8-bit unsigned integer. When two routers attached to a
+ network both attempt to become Designated Router, the one
+ with the highest Router Priority takes precedence. If there
+ is still a tie, the router with the highest Router ID takes
+ precedence. A router whose Router Priority is set to 0 is
+ ineligible to become Designated Router on the attached
+ network. Router Priority is only configured for interfaces
+ to multi-access 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, but 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
+
+
+
+Moy [Page 201]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ network.
+
+ Authentication key
+ This configured data allows the authentication procedure to
+ generate and/or verify the authentication field in the OSPF
+ header. This value again must be the same for all routers
+ attached to a common network. For example, if the AuType
+ indicates simple password, the Authentication key would be a
+ 64-bit password. This key would be inserted directly into
+ the OSPF header when originating routing protocol packets.
+ There could be a separate password for each network.
+
+ 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 links advertisements (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 Non-broadcast, multi-access network parameters
+
+ OSPF treats a non-broadcast, multi-access 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
+
+
+
+Moy [Page 202]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ network. This Designated Router then originates a networks
+ links advertisement, which lists all routers attached to the
+ non-broadcast network.
+
+ However, due to the lack of broadcast capabilities, it is
+ necessary to use configuration parameters in the Designated
+ Router selection. These parameters need only 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):
+
+
+ List of all other attached routers
+ The list of all other routers attached to the non-broadcast
+ 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 non-broadcast 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 Host route parameters
+
+ Host routes are advertised in router links advertisements 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. There may be multiple costs configured,
+ one for each IP TOS. However, since the host probably has
+
+
+
+Moy [Page 203]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ only a single connection to the internet, the actual
+ configured cost(s) in many cases is unimportant (i.e., will
+ have no effect on routing).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 204]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+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-area basis.
+ Additional authentication data is configurable on a per-interface
+ basis. For example, if an area uses a simple password scheme for
+ authentication, a separate password may be configured for each
+ network contained in the area.
+
+ Authentication types 0 and 1 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 No authentication
+ 1 Simple password
+ All others Reserved for assignment by the
+ IANA (iana@ISI.EDU)
+
+
+ Table 20: OSPF authentication types.
+
+
+
+ D.1 AuType 0 -- No authentication
+
+ Use of this authentication type means that routing exchanges in
+ the area are not authenticated. The 64-bit field in the OSPF
+ header can contain anything; it is not examined on packet
+ reception.
+
+ D.2 AuType 1 -- Simple password
+
+ 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.
+
+
+
+
+
+Moy [Page 205]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ This guards against routers inadvertently joining the area.
+ They must first be configured with their attached networks'
+ passwords before they can participate in the routing domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 206]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+E. Differences from RFC 1247
+
+ This section documents the differences between this memo and RFC
+ 1247. These differences include a fix for a problem involving OSPF
+ virtual links, together with minor enhancements and clarifications
+ to the protocol. All differences are backward-compatible.
+ Implementations of this memo and of RFC 1247 will interoperate.
+
+ E.1 A fix for a problem with OSPF Virtual links
+
+ In RFC 1247, certain configurations of OSPF virtual links can
+ cause routing loops. The root of the problem is that while there
+ is an information mismatch at the boundary of any virtual link's
+ Transit area, a backbone path can still cross the boundary. RFC
+ 1247 attempted to compensate for this information mismatch by
+ adjusting any backbone path as it enters the transit area (see
+ Section 16.3 in RFC 1247). However, this proved not to be
+ enough. This memo fixes the problem by having all area border
+ routers determine, by looking at summary links, whether better
+ backbone paths can be found through the transit areas.
+
+ This fix simplifies the OSPF virtual link logic, and consists of
+ the following components:
+
+ o A new bit has been defined in the router links
+ advertisement, called bit V. Bit V is set in a router's
+ router links advertisement for Area A if and only if the
+ router is an endpoint of an active virtual link that uses
+ Area A as its Transit area (see Sections 12.4.1 and A.4.2).
+ This enables the other routers attached to Area A to
+ discover whether the area supports any virtual links (i.e.,
+ is a transit area). This discovery is done during the
+ calculation of Area A's shortest-path tree (see Section
+ 16.1).
+
+ o To aid in the description of the algorithm, a new parameter
+ has been added to the OSPF area structure:
+ TransitCapability. This parameter indicates whether the area
+ supports any active virtual links. Equivalently, it
+ indicates whether the area can carry traffic that neither
+ originates nor terminates in the area itself.
+
+ o The calculation in Section 16.3 of RFC 1247 has been
+ replaced. The new calculation, performed by area border
+ routers only, examines the summary links belonging to all
+ attached transit areas to see whether the transit areas can
+ provide better paths than those already found in Sections
+ 16.1 and 16.2.
+
+
+
+Moy [Page 207]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ o The incremental calculations in Section 16.5 have been
+ updated as a result of the new calculations in Section 16.3.
+
+ E.2 Supporting supernetting and subnet 0
+
+ In RFC 1247, an OSPF router cannot originate separate AS
+ external link advertisements (or separate summary link
+ advertisements) for two networks that have the same address but
+ different masks. This situation can arise when subnet 0 of a
+ network has been assigned (a practice that is generally
+ discouraged), or when using supernetting as described in [RFC
+ 1519] (a practice that is generally encouraged to reduce the
+ size of routing tables), or even when in transition from one
+ mask to another on a subnet. Using supernetting as an example,
+ you might want to aggregate the four class C networks
+ 192.9.4.0-192.9.7.0, advertising one route for the aggregation
+ and another for the single class C network 192.9.4.0.
+
+ The reason behind this limitation is that in RFC 1247, the Link
+ State ID of AS external link advertisements and summary link
+ advertisements is set equal to the described network's IP
+ address. In the above example, RFC 1247 would assign both
+ advertisements the Link State ID of 192.9.4.0, making them in
+ essence the same advertisement. This memo fixes the problem by
+ relaxing the setting of the Link State ID so that any of the
+ "host" bits of the network address can also be set. This allows
+ you to disambiguate advertisements for networks having the same
+ address but different masks. Given an AS external link
+ advertisement (or a summary link advertisement), the described
+ network's address can now be obtained by masking the Link State
+ ID with the network mask carried in the body of the
+ advertisement. Again using the above example, the aggregate can
+ now be advertised using a Link State ID of 192.9.4.0 and the
+ single class C network advertised simultaneously using the Link
+ State ID of 192.9.4.255.
+
+ Appendix F gives one possible algorithm for setting one or more
+ "host" bits in the Link State ID in order to disambiguate
+ advertisements. It should be noted that this is a local
+ decision. Each router in an OSPF system is free to use its own
+ algorithm, since only those advertisements originated by the
+ router itself are affected.
+
+ It is believed that this change will be more or less compatible
+ with implementations of RFC 1247. Implementations of RFC 1247
+ will probably either a) install routing table entries that won't
+ be used or b) do the correct processing as outlined in this memo
+ or c) mark the advertisement as unusable when presented with a
+
+
+
+Moy [Page 208]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Link State ID that has one or more of the host bits set.
+ However, in the interest of interoperability, implementations of
+ this memo should only set the host bits in Link State IDs when
+ absolutely necessary.
+
+ The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3,
+ 16.4, 16.5, 16.6, A.4.4 and A.4.5.
+
+ E.3 Obsoleting LSInfinity in router links advertisements
+
+ The metric of LSInfinity can no longer be used in router links
+ advertisements to indicate unusable links. This is being done
+ for several reasons:
+
+ o It removes any possible confusion in an OSPF area as to just
+ which routers/networks are reachable in the area. For
+ example, the above virtual link fix relies on detecting the
+ existence of virtual links when running the Dijkstra.
+ However, when one-directional links (i.e., cost of
+ LSInfinity in one direction, but not the other) are
+ possible, some routers may detect the existence of virtual
+ links while others may not. This may defeat the fix for the
+ virtual link problem.
+
+ o It also helps OSPF's Multicast routing extensions (MOSPF),
+ because one-way reachability can lead to places that are
+ reachable via unicast but not multicast, or vice versa.
+
+ The two prior justifications for using LSInfinity in router
+ links advertisements were 1) it was a way to not support TOS
+ before TOS was optional and 2) it went along with strong TOS
+ interpretations. These justifications are no longer valid.
+ However, LSInfinity will continue to mean "unreachable" in
+ summary link advertisements and AS external link advertisements,
+ as some implementations use this as an alternative to the
+ premature aging procedure specified in Section 14.1.
+
+ This change has one other side effect. When two routers are
+ connected via a virtual link whose underlying path is non-TOS-
+ capable, they must now revert to being non-TOS-capable routers
+ themselves, instead of the previous behavior of advertising the
+ non-zero TOS costs of the virtual link as LSInfinity. See
+ Section 15 for details.
+
+ E.4 TOS encoding updated
+
+ The encoding of TOS in OSPF link state advertisements has been
+ updated to reflect the new TOS value (minimize monetary cost)
+
+
+
+Moy [Page 209]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ defined by [RFC 1349]. The OSPF encoding is defined in Section
+ 12.3, which is identical in content to Section A.5 of [RFC
+ 1349].
+
+ E.5 Summarizing routes into transit areas
+
+ RFC 1247 mandated that routes associated with Area A are never
+ summarized back into Area A. However, this memo further reduces
+ the number of summary links originated by refusing to summarize
+ into Area A those routes having next hops belonging to Area A.
+ This is an optimization over RFC 1247 behavior when virtual
+ links are present. For example, in the area configuration of
+ Figure 6, Router RT11 need only originate a single summary link
+ having the (collapsed) destination N9-N11,H1 into its connected
+ transit area Area 2, since all of its other eligible routes have
+ next hops belonging to Area 2 (and as such only need be
+ advertised by other area border routers; in this case, Routers
+ RT10 and RT7). This is the logical equivalent of a Distance
+ Vector protocol's split horizon logic.
+
+ This change appears in Section 12.4.3.
+
+ E.6 Summarizing routes into stub areas
+
+ RFC 1247 mandated that area border routers attached to stub
+ areas must summarize all inter-area routes into the stub areas.
+ However, while area border routers connected to OSPF stub areas
+ must originate default summary links into the stub area, they
+ need not summarize other routes into the stub area. The amount
+ of summarization done into stub areas can instead be put under
+ configuration control. The network administrator can then make
+ the trade-off between optimal routing and database size.
+
+ This change appears in Sections 12.4.3 and 12.4.4.
+
+ E.7 Flushing anomalous network links advertisements
+
+ Text was added indicating that a network links advertisement
+ whose Link State ID is equal to one of the router's own IP
+ interface addresses should be considered to be self-originated,
+ regardless of the setting of the advertisement's Advertising
+ Router. If the Advertising Router of such an advertisement is
+ not equal to the router's own Router ID, the advertisement
+ should be flushed from the routing domain using the premature
+ aging procedure specified in Section 14.1. This case should be
+ rare, and it indicates that the router's Router ID has changed
+ since originating the advertisement.
+
+
+
+
+Moy [Page 210]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ Failure to flush these anomalous advertisements could lead to
+ multiple network links advertisements having the same Link State
+ ID. This in turn could cause the Dijkstra calculation in Section
+ 16.1 to fail, since it would be impossible to tell which network
+ links advertisement is valid (i.e., more recent).
+
+ This change appears in Sections 13.4 and 14.1.
+
+ E.8 Required Statistics appendix deleted
+
+ Appendix D of RFC 1247, which specified a list of required
+ statistics for an OSPF implementation, has been deleted. That
+ appendix has been superseded by the two documents: the OSPF
+ Version 2 Management Information Base and the OSPF Version 2
+ Traps.
+
+ E.9 Other changes
+
+ The following small changes were also made to RFC 1247:
+
+ o When representing unnumbered point-to-point networks in
+ router links advertisements, the corresponding Link Data
+ field should be set to the unnumbered interface's MIB-II
+ [RFC 1213] ifIndex value.
+
+ o A comment was added to Step 3 of the Dijkstra algorithm in
+ Section 16.1. When removing vertices from the candidate
+ list, and 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.
+
+ o A comment was added to Section 12.4.3 noting that a summary
+ link advertisement cannot express a reachable destination
+ whose path cost equals or exceeds LSInfinity.
+
+ o A comment was added to Section 15 noting that a virtual link
+ whose underlying path has cost greater than hexadecimal
+ 0xffff (the maximum size of an interface cost in a router
+ links advertisement) should be considered inoperational.
+
+ o An option was added to the definition of area address
+ ranges, allowing the network administrator to specify that a
+ particular range should not be advertised to other OSPF
+ areas. This enables the existence of certain networks to be
+ hidden from other areas. This change appears in Sections
+ 12.4.3 and C.2.
+
+
+
+
+
+Moy [Page 211]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ o A note was added reminding implementors that bit E (the AS
+ boundary router indication) should never be set in a router
+ links advertisement for a stub area, since stub areas cannot
+ contain AS boundary routers. This change appears in Section
+ 12.4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 212]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+F. An algorithm for assigning Link State IDs
+
+ In RFC 1247, the Link State ID in AS external link advertisements
+ and summary link advertisements is set to the described network's IP
+ address. This memo relaxes that requirement, allowing one or more of
+ the network's host bits to be set in the Link State ID. This allows
+ the router to originate separate advertisements for networks having
+ the same addresses, yet different masks. Such networks can occur in
+ the presence of supernetting and subnet 0s (see Section E.2 for more
+ information).
+
+ 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 advertisements 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
+ (the RFC 1247 behavior) whenever possible.
+
+ The algorithm below is stated for AS external link advertisements.
+ This is only for clarity; the exact same algorithm can be used for
+ summary link advertisements. Suppose that the router wishes to
+ originate an AS external link advertisement for a network having
+ address NA and mask NM1. The following steps are then used to
+ determine the advertisement's Link State ID:
+
+ (1) Determine whether the router is already originating an AS
+ external link advertisement with Link State ID equal to NA (in
+ such an advertisement the router itself will be listed as the
+ advertisement's Advertising Router). If not, set the Link State
+ ID equal to NA (the RFC 1247 behavior) and the algorithm
+ terminates. Otherwise,
+
+ (2) Obtain the network mask from the body of the already existing AS
+ external link advertisement. 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 advertisement 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
+ advertisement (having Link State ID of NA) to reference the
+ new network [NA,NM1] by incrementing the sequence number,
+ changing the mask in the body to NM1 and using the cost for
+ the new network. Then originate a new advertisement for the
+
+
+
+Moy [Page 213]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ 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 link state
+ advertisement, 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 link state
+ advertisements 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 link advertisement
+ 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 link
+ advertisement for [10.0.0.0,255.255.0.0]:
+
+ (a) The advertisement 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 link
+ advertisement for [10.0.0.0,255.0.0.0]:
+
+ (a) The advertisement 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].
+
+
+
+
+
+Moy [Page 214]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+ (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
+ of 10.0.0.255.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 215]
+
+RFC 1583 OSPF Version 2 March 1994
+
+
+Security Considerations
+
+ All OSPF protocol exchanges are authenticated. This is accomplished
+ through authentication fields contained in the OSPF packet header.
+ For more information, see Sections 8.1, 8.2, and Appendix D.
+
+Author's Address
+
+ John Moy
+ Proteon, Inc.
+ 9 Technology Drive
+ Westborough, MA 01581
+
+ Phone: 508-898-2800
+ Fax: 508-898-3176
+ Email: jmoy@proteon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moy [Page 216]
+