Network Working Group J. Moy
Request for Comments: 2328 Ascend Communications, Inc.
STD: 54 April 1998
Obsoletes: 2178
Category: Standards Track
OSPF Version 2
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is
unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This memo documents version 2 of the OSPF protocol. OSPF is a
link-state routing protocol. It is designed to be run internal to a
single Autonomous System. Each OSPF router maintains an identical
database describing the Autonomous System's topology. From this
database, a routing table is calculated by constructing a shortest-
path tree.
OSPF recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic. OSPF provides
support for equal-cost multipath. An area routing capability is
provided, enabling an additional level of routing protection and a
reduction in routing protocol traffic. In addition, all OSPF
routing protocol exchanges are authenticated.
The differences between this memo and RFC 2178 are explained in
Appendix G. All differences are backward-compatible in nature.
Moy Standards Track [Page 1]
RFC 2328 OSPF Version 2 April 1998
Implementations of this memo and of RFCs 2178, 1583, and 1247 will
interoperate.
Please send comments to ospf@gated.cornell.edu.
Table of Contents
1 Introduction ........................................... 6
1.1 Protocol Overview ...................................... 6
1.2 Definitions of commonly used terms ..................... 8
1.3 Brief history of link-state routing technology ........ 11
1.4 Organization of this document ......................... 12
1.5 Acknowledgments ....................................... 12
2 The link-state database: organization and calculations 13
2.1 Representation of routers and networks ................ 13
2.1.1 Representation of non-broadcast networks .............. 15
2.1.2 An example link-state database ........................ 18
2.2 The shortest-path tree ................................ 21
2.3 Use of external routing information ................... 23
2.4 Equal-cost multipath .................................. 26
3 Splitting the AS into Areas ........................... 26
3.1 The backbone of the Autonomous System ................. 27
3.2 Inter-area routing .................................... 27
3.3 Classification of routers ............................. 28
3.4 A sample area configuration ........................... 29
3.5 IP subnetting support ................................. 35
3.6 Supporting stub areas ................................. 37
3.7 Partitions of areas ................................... 38
4 Functional Summary .................................... 40
4.1 Inter-area routing .................................... 41
4.2 AS external routes .................................... 41
4.3 Routing protocol packets .............................. 42
4.4 Basic implementation requirements ..................... 43
4.5 Optional OSPF capabilities ............................ 46
5 Protocol data structures .............................. 47
6 The Area Data Structure ............................... 49
7 Bringing Up Adjacencies ............................... 52
7.1 The Hello Protocol .................................... 52
7.2 The Synchronization of Databases ...................... 53
7.3 The Designated Router ................................. 54
7.4 The Backup Designated Router .......................... 56
7.5 The graph of adjacencies .............................. 56
Moy Standards Track [Page 2]
RFC 2328 OSPF Version 2 April 1998
8 Protocol Packet Processing ............................ 58
8.1 Sending protocol packets .............................. 58
8.2 Receiving protocol packets ............................ 61
9 The Interface Data Structure .......................... 63
9.1 Interface states ...................................... 67
9.2 Events causing interface state changes ................ 70
9.3 The Interface state machine ........................... 72
9.4 Electing the Designated Router ........................ 75
9.5 Sending Hello packets ................................. 77
9.5.1 Sending Hello packets on NBMA networks ................ 79
10 The Neighbor Data Structure ........................... 80
10.1 Neighbor states ....................................... 83
10.2 Events causing neighbor state changes ................. 87
10.3 The Neighbor state machine ............................ 89
10.4 Whether to become adjacent ............................ 95
10.5 Receiving Hello Packets ............................... 96
10.6 Receiving Database Description Packets ................ 99
10.7 Receiving Link State Request Packets ................. 102
10.8 Sending Database Description Packets ................. 103
10.9 Sending Link State Request Packets ................... 104
10.10 An Example ........................................... 105
11 The Routing Table Structure .......................... 107
11.1 Routing table lookup ................................. 111
11.2 Sample routing table, without areas .................. 111
11.3 Sample routing table, with areas ..................... 112
12 Link State Advertisements (LSAs) ..................... 115
12.1 The LSA Header ....................................... 116
12.1.1 LS age ............................................... 116
12.1.2 Options .............................................. 117
12.1.3 LS type .............................................. 117
12.1.4 Link State ID ........................................ 117
12.1.5 Advertising Router ................................... 119
12.1.6 LS sequence number ................................... 120
12.1.7 LS checksum .......................................... 121
12.2 The link state database .............................. 121
12.3 Representation of TOS ................................ 122
12.4 Originating LSAs ..................................... 123
12.4.1 Router-LSAs .......................................... 126
12.4.1.1 Describing point-to-point interfaces ................. 130
12.4.1.2 Describing broadcast and NBMA interfaces ............. 130
12.4.1.3 Describing virtual links ............................. 131
12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 131
Moy Standards Track [Page 3]
RFC 2328 OSPF Version 2 April 1998
12.4.1.5 Examples of router-LSAs .............................. 132
12.4.2 Network-LSAs ......................................... 133
12.4.2.1 Examples of network-LSAs ............................. 134
12.4.3 Summary-LSAs ......................................... 135
12.4.3.1 Originating summary-LSAs into stub areas ............. 137
12.4.3.2 Examples of summary-LSAs ............................. 138
12.4.4 AS-external-LSAs ..................................... 139
12.4.4.1 Examples of AS-external-LSAs ......................... 140
13 The Flooding Procedure ............................... 143
13.1 Determining which LSA is newer ....................... 146
13.2 Installing LSAs in the database ...................... 147
13.3 Next step in the flooding procedure .................. 148
13.4 Receiving self-originated LSAs ....................... 151
13.5 Sending Link State Acknowledgment packets ............ 152
13.6 Retransmitting LSAs .................................. 154
13.7 Receiving link state acknowledgments ................. 155
14 Aging The Link State Database ........................ 156
14.1 Premature aging of LSAs .............................. 157
15 Virtual Links ........................................ 158
16 Calculation of the routing table ..................... 160
16.1 Calculating the shortest-path tree for an area ....... 161
16.1.1 The next hop calculation ............................. 167
16.2 Calculating the inter-area routes .................... 178
16.3 Examining transit areas' summary-LSAs ................ 170
16.4 Calculating AS external routes ....................... 173
16.4.1 External path preferences ............................ 175
16.5 Incremental updates -- summary-LSAs .................. 175
16.6 Incremental updates -- AS-external-LSAs .............. 177
16.7 Events generated as a result of routing table changes 177
16.8 Equal-cost multipath ................................. 178
Footnotes ............................................ 179
References ........................................... 183
A OSPF data formats .................................... 185
A.1 Encapsulation of OSPF packets ........................ 185
A.2 The Options field .................................... 187
A.3 OSPF Packet Formats .................................. 189
A.3.1 The OSPF packet header ............................... 190
A.3.2 The Hello packet ..................................... 193
A.3.3 The Database Description packet ...................... 195
A.3.4 The Link State Request packet ........................ 197
A.3.5 The Link State Update packet ......................... 199
A.3.6 The Link State Acknowledgment packet ................. 201
Moy Standards Track [Page 4]
RFC 2328 OSPF Version 2 April 1998
A.4 LSA formats .......................................... 203
A.4.1 The LSA header ....................................... 204
A.4.2 Router-LSAs .......................................... 206
A.4.3 Network-LSAs ......................................... 210
A.4.4 Summary-LSAs ......................................... 212
A.4.5 AS-external-LSAs ..................................... 214
B Architectural Constants .............................. 217
C Configurable Constants ............................... 219
C.1 Global parameters .................................... 219
C.2 Area parameters ...................................... 220
C.3 Router interface parameters .......................... 221
C.4 Virtual link parameters .............................. 224
C.5 NBMA network parameters .............................. 224
C.6 Point-to-MultiPoint network parameters ............... 225
C.7 Host route parameters ................................ 226
D Authentication ....................................... 227
D.1 Null authentication .................................. 227
D.2 Simple password authentication ....................... 228
D.3 Cryptographic authentication ......................... 228
D.4 Message generation ................................... 231
D.4.1 Generating Null authentication ....................... 231
D.4.2 Generating Simple password authentication ............ 232
D.4.3 Generating Cryptographic authentication .............. 232
D.5 Message verification ................................. 234
D.5.1 Verifying Null authentication ........................ 234
D.5.2 Verifying Simple password authentication ............. 234
D.5.3 Verifying Cryptographic authentication ............... 235
E An algorithm for assigning Link State IDs ............ 236
F Multiple interfaces to the same network/subnet ....... 239
G Differences from RFC 2178 ............................ 240
G.1 Flooding modifications ............................... 240
G.2 Changes to external path preferences ................. 241
G.3 Incomplete resolution of virtual next hops ........... 241
G.4 Routing table lookup ................................. 241
Security Considerations .............................. 243
Author's Address ..................................... 243
Full Copyright Statement ............................. 244
Moy Standards Track [Page 5]
RFC 2328 OSPF Version 2 April 1998
1. Introduction
This document is a specification of the Open Shortest Path First
(OSPF) TCP/IP internet routing protocol. OSPF is classified as an
Interior Gateway Protocol (IGP). This means that it distributes
routing information between routers belonging to a single Autonomous
System. The OSPF protocol is based on link-state or SPF technology.
This is a departure from the Bellman-Ford base used by traditional
TCP/IP internet routing protocols.
The OSPF protocol was developed by the OSPF working group of the
Internet Engineering Task Force. It has been designed expressly for
the TCP/IP internet environment, including explicit support for CIDR
and the tagging of externally-derived routing information. OSPF
also provides for the authentication of routing updates, and
utilizes IP multicast when sending/receiving the updates. In
addition, much work has been done to produce a protocol that
responds quickly to topology changes, yet involves small amounts of
routing protocol traffic.
1.1. Protocol overview
OSPF routes IP packets based solely on the destination IP
address found in the IP packet header. IP packets are routed
"as is" -- they are not encapsulated in any further protocol
headers as they transit the Autonomous System. OSPF is a
dynamic routing protocol. It quickly detects topological
changes in the AS (such as router interface failures) and
calculates new loop-free routes after a period of convergence.
This period of convergence is short and involves a minimum of
routing traffic.
In a link-state routing protocol, each router maintains a
database describing the Autonomous System's topology. This
database is referred to as the link-state database. Each
participating router has an identical database. Each individual
piece of this database is a particular router's local state
(e.g., the router's usable interfaces and reachable neighbors).
The router distributes its local state throughout the Autonomous
System by flooding.
Moy Standards Track [Page 6]
RFC 2328 OSPF Version 2 April 1998
All routers run the exact same algorithm, in parallel. From the
link-state database, each router constructs a tree of shortest
paths with itself as root. This shortest-path tree gives the
route to each destination in the Autonomous System. Externally
derived routing information appears on the tree as leaves.
When several equal-cost routes to a destination exist, traffic
is distributed equally among them. The cost of a route is
described by a single dimensionless metric.
OSPF allows sets of networks to be grouped together. Such a
grouping is called an area. The topology of an area is hidden
from the rest of the Autonomous System. This information hiding
enables a significant reduction in routing traffic. Also,
routing within the area is determined only by the area's own
topology, lending the area protection from bad routing data. An
area is a generalization of an IP subnetted network.
OSPF enables the flexible configuration of IP subnets. Each
route distributed by OSPF has a destination and mask. Two
different subnets of the same IP network number may have
different sizes (i.e., different masks). This is commonly
referred to as variable length subnetting. A packet is routed
to the best (i.e., longest or most specific) match. Host routes
are considered to be subnets whose masks are "all ones"
(0xffffffff).
All OSPF protocol exchanges are authenticated. This means that
only trusted routers can participate in the Autonomous System's
routing. A variety of authentication schemes can be used; in
fact, separate authentication schemes can be configured for each
IP subnet.
Externally derived routing data (e.g., routes learned from an
Exterior Gateway Protocol such as BGP; see [Ref23]) is
advertised throughout the Autonomous System. This externally
derived data is kept separate from the OSPF protocol's link
state data. Each external route can also be tagged by the
advertising router, enabling the passing of additional
information between routers on the boundary of the Autonomous
System.
Moy Standards Track [Page 7]
RFC 2328 OSPF Version 2 April 1998
1.2. Definitions of commonly used terms
This section provides definitions for terms that have a specific
meaning to the OSPF protocol and that are used throughout the
text. The reader unfamiliar with the Internet Protocol Suite is
referred to [Ref13] for an introduction to IP.
Router
A level three Internet Protocol packet switch. Formerly
called a gateway in much of the IP literature.
Autonomous System
A group of routers exchanging routing information via a
common routing protocol. Abbreviated as AS.
Interior Gateway Protocol
The routing protocol spoken by the routers belonging to an
Autonomous system. Abbreviated as IGP. Each Autonomous
System has a single IGP. Separate Autonomous Systems may be
running different IGPs.
Router ID
A 32-bit number assigned to each router running the OSPF
protocol. This number uniquely identifies the router within
an Autonomous System.
Network
In this memo, an IP network/subnet/supernet. It is possible
for one physical network to be assigned multiple IP
network/subnet numbers. We consider these to be separate
networks. Point-to-point physical networks are an exception
- they are considered a single network no matter how many
(if any at all) IP network/subnet numbers are assigned to
them.
Network mask
A 32-bit number indicating the range of IP addresses
residing on a single IP network/subnet/supernet. This
specification displays network masks as hexadecimal numbers.
Moy Standards Track [Page 8]
RFC 2328 OSPF Version 2 April 1998
For example, the network mask for a class C IP network is
displayed as 0xffffff00. Such a mask is often displayed
elsewhere in the literature as 255.255.255.0.
Point-to-point networks
A network that joins a single pair of routers. A 56Kb
serial line is an example of a point-to-point network.
Broadcast networks
Networks supporting many (more than two) attached routers,
together with the capability to address a single physical
message to all of the attached routers (broadcast).
Neighboring routers are discovered dynamically on these nets
using OSPF's Hello Protocol. The Hello Protocol itself
takes advantage of the broadcast capability. The OSPF
protocol makes further use of multicast capabilities, if
they exist. Each pair of routers on a broadcast network is
assumed to be able to communicate directly. An ethernet is
an example of a broadcast network.
Non-broadcast networks
Networks supporting many (more than two) routers, but having
no broadcast capability. Neighboring routers are maintained
on these nets using OSPF's Hello Protocol. However, due to
the lack of broadcast capability, some configuration
information may be necessary to aid in the discovery of
neighbors. On non-broadcast networks, OSPF protocol packets
that are normally multicast need to be sent to each
neighboring router, in turn. An X.25 Public Data Network
(PDN) is an example of a non-broadcast network.
OSPF runs in one of two modes over non-broadcast networks.
The first mode, called non-broadcast multi-access or NBMA,
simulates the operation of OSPF on a broadcast network. The
second mode, called Point-to-MultiPoint, treats the non-
broadcast network as a collection of point-to-point links.
Non-broadcast networks are referred to as NBMA networks or
Point-to-MultiPoint networks, depending on OSPF's mode of
operation over the network.
Moy Standards Track [Page 9]
RFC 2328 OSPF Version 2 April 1998
Interface
The connection between a router and one of its attached
networks. An interface has state information associated
with it, which is obtained from the underlying lower level
protocols and the routing protocol itself. An interface to
a network has associated with it a single IP address and
mask (unless the network is an unnumbered point-to-point
network). An interface is sometimes also referred to as a
link.
Neighboring routers
Two routers that have interfaces to a common network.
Neighbor relationships are maintained by, and usually
dynamically discovered by, OSPF's Hello Protocol.
Adjacency
A relationship formed between selected neighboring routers
for the purpose of exchanging routing information. Not
every pair of neighboring routers become adjacent.
Link state advertisement
Unit of data describing the local state of a router or
network. For a router, this includes the state of the
router's interfaces and adjacencies. Each link state
advertisement is flooded throughout the routing domain. The
collected link state advertisements of all routers and
networks forms the protocol's link state database.
Throughout this memo, link state advertisement is
abbreviated as LSA.
Hello Protocol
The part of the OSPF protocol used to establish and maintain
neighbor relationships. On broadcast networks the Hello
Protocol can also dynamically discover neighboring routers.
Flooding
The part of the OSPF protocol that distributes and
synchronizes the link-state database between OSPF routers.
Designated Router
Each broadcast and NBMA network that has at least two
attached routers has a Designated Router. The Designated
Moy Standards Track [Page 10]
RFC 2328 OSPF Version 2 April 1998
Router generates an LSA for the network and has other
special responsibilities in the running of the protocol.
The Designated Router is elected by the Hello Protocol.
The Designated Router concept enables a reduction in the
number of adjacencies required on a broadcast or NBMA
network. This in turn reduces the amount of routing
protocol traffic and the size of the link-state database.
Lower-level protocols
The underlying network access protocols that provide
services to the Internet Protocol and in turn the OSPF
protocol. Examples of these are the X.25 packet and frame
levels for X.25 PDNs, and the ethernet data link layer for
ethernets.
1.3. Brief history of link-state routing technology
OSPF is a link state routing protocol. Such protocols are also
referred to in the literature as SPF-based or distributed-
database protocols. This section gives a brief description of
the developments in link-state technology that have influenced
the OSPF protocol.
The first link-state routing protocol was developed for use in
the ARPANET packet switching network. This protocol is
described in [Ref3]. It has formed the starting point for all
other link-state protocols. The homogeneous ARPANET
environment, i.e., single-vendor packet switches connected by
synchronous serial lines, simplified the design and
implementation of the original protocol.
Modifications to this protocol were proposed in [Ref4]. These
modifications dealt with increasing the fault tolerance of the
routing protocol through, among other things, adding a checksum
to the LSAs (thereby detecting database corruption). The paper
also included means for reducing the routing traffic overhead in
a link-state protocol. This was accomplished by introducing
mechanisms which enabled the interval between LSA originations
to be increased by an order of magnitude.
Moy Standards Track [Page 11]
RFC 2328 OSPF Version 2 April 1998
A link-state algorithm has also been proposed for use as an ISO
IS-IS routing protocol. This protocol is described in [Ref2].
The protocol includes methods for data and routing traffic
reduction when operating over broadcast networks. This is
accomplished by election of a Designated Router for each
broadcast network, which then originates an LSA for the network.
The OSPF Working Group of the IETF has extended this work in
developing the OSPF protocol. The Designated Router concept has
been greatly enhanced to further reduce the amount of routing
traffic required. Multicast capabilities are utilized for
additional routing bandwidth reduction. An area routing scheme
has been developed enabling information
hiding/protection/reduction. Finally, the algorithms have been
tailored for efficient operation in TCP/IP internets.
1.4. Organization of this document
The first three sections of this specification give a general
overview of the protocol's capabilities and functions. Sections
4-16 explain the protocol's mechanisms in detail. Packet
formats, protocol constants and configuration items are
specified in the appendices.
Labels such as HelloInterval encountered in the text refer to
protocol constants. They may or may not be configurable.
Architectural constants are summarized in Appendix B.
Configurable constants are summarized in Appendix C.
The detailed specification of the protocol is presented in terms
of data structures. This is done in order to make the
explanation more precise. Implementations of the protocol are
required to support the functionality described, but need not
use the precise data structures that appear in this memo.
1.5. Acknowledgments
The author would like to thank Ran Atkinson, Fred Baker, Jeffrey
Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra
Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui
Moy Standards Track [Page 12]
RFC 2328 OSPF Version 2 April 1998
Zhang and the rest of the OSPF Working Group for the ideas and
support they have given to this project.
The OSPF Point-to-MultiPoint interface is based on work done by
Fred Baker.
The OSPF Cryptographic Authentication option was developed by
Fred Baker and Ran Atkinson.
2. The Link-state Database: organization and calculations
The following subsections describe the organization of OSPF's link-
state database, and the routing calculations that are performed on
the database in order to produce a router's routing table.
2.1. Representation of routers and networks
The Autonomous System's link-state database describes a directed
graph. The vertices of the graph consist of routers and
networks. A graph edge connects two routers when they are
attached via a physical point-to-point network. An edge
connecting a router to a network indicates that the router has
an interface on the network. Networks can be either transit or
stub networks. Transit networks are those capable of carrying
data traffic that is neither locally originated nor locally
destined. A transit network is represented by a graph vertex
having both incoming and outgoing edges. A stub network's vertex
has only incoming edges.
The neighborhood of each network node in the graph depends on
the network's type (point-to-point, broadcast, NBMA or Point-
to-MultiPoint) and the number of routers having an interface to
the network. Three cases are depicted in Figure 1a. Rectangles
indicate routers. Circles and oblongs indicate networks.
Router names are prefixed with the letters RT and network names
with the letter N. Router interface names are prefixed by the
letter I. Lines between routers indicate point-to-point
networks. The left side of the figure shows networks with their
connected routers, with the resulting graphs shown on the right.
Moy Standards Track [Page 13]
RFC 2328 OSPF Version 2 April 1998
**FROM**
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
Physical point-to-point networks
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
Stub networks
**FROM**
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|N2 |
+---+ +---+ * ------------------------
| N2 | * RT3| | | | | X |
+----------------------+ T RT4| | | | | X |
| | O RT5| | | | | X |
+---+ +---+ * RT6| | | | | X |
|RT5| |RT6| * N2| X | X | X | X | |
+---+ +---+
Broadcast or NBMA networks
Figure 1a: Network map components
Moy Standards Track [Page 14]
RFC 2328 OSPF Version 2 April 1998
Networks and routers are represented by vertices.
An edge connects Vertex A to Vertex B iff the
intersection of Column A and Row B is marked with
an X.
The top of Figure 1a shows two routers connected by a point-to-
point link. In the resulting link-state database graph, the two
router vertices are directly connected by a pair of edges, one
in each direction. Interfaces to point-to-point networks need
not be assigned IP addresses. When interface addresses are
assigned, they are modelled as stub links, with each router
advertising a stub connection to the other router's interface
address. Optionally, an IP subnet can be assigned to the point-
to-point network. In this case, both routers advertise a stub
link to the IP subnet, instead of advertising each others' IP
interface addresses.
The middle of Figure 1a shows a network with only one attached
router (i.e., a stub network). In this case, the network appears
on the end of a stub connection in the link-state database's
graph.
When multiple routers are attached to a broadcast network, the
link-state database graph shows all routers bidirectionally
connected to the network vertex. This is pictured at the bottom
of Figure 1a.
Each network (stub or transit) in the graph has an IP address
and associated network mask. The mask indicates the number of
nodes on the network. Hosts attached directly to routers
(referred to as host routes) appear on the graph as stub
networks. The network mask for a host route is always
0xffffffff, which indicates the presence of a single node.
2.1.1. Representation of non-broadcast networks
As mentioned previously, OSPF can run over non-broadcast
networks in one of two modes: NBMA or Point-to-MultiPoint.
The choice of mode determines the way that the Hello
Moy Standards Track [Page 15]
RFC 2328 OSPF Version 2 April 1998
protocol and flooding work over the non-broadcast network,
and the way that the network is represented in the link-
state database.
In NBMA mode, OSPF emulates operation over a broadcast
network: a Designated Router is elected for the NBMA
network, and the Designated Router originates an LSA for the
network. The graph representation for broadcast networks and
NBMA networks is identical. This representation is pictured
in the middle of Figure 1a.
NBMA mode is the most efficient way to run OSPF over non-
broadcast networks, both in terms of link-state database
size and in terms of the amount of routing protocol traffic.
However, it has one significant restriction: it requires all
routers attached to the NBMA network to be able to
communicate directly. This restriction may be met on some
non-broadcast networks, such as an ATM subnet utilizing
SVCs. But it is often not met on other non-broadcast
networks, such as PVC-only Frame Relay networks. On non-
broadcast networks where not all routers can communicate
directly you can break the non-broadcast network into
logical subnets, with the routers on each subnet being able
to communicate directly, and then run each separate subnet
as an NBMA network (see [Ref15]). This however requires
quite a bit of administrative overhead, and is prone to
misconfiguration. It is probably better to run such a non-
broadcast network in Point-to-Multipoint mode.
In Point-to-MultiPoint mode, OSPF treats all router-to-
router connections over the non-broadcast network as if they
were point-to-point links. No Designated Router is elected
for the network, nor is there an LSA generated for the
network. In fact, a vertex for the Point-to-MultiPoint
network does not appear in the graph of the link-state
database.
Figure 1b illustrates the link-state database representation
of a Point-to-MultiPoint network. On the left side of the
figure, a Point-to-MultiPoint network is pictured. It is
assumed that all routers can communicate directly, except
for routers RT4 and RT5. I3 though I6 indicate the routers'
Moy Standards Track [Page 16]
RFC 2328 OSPF Version 2 April 1998
IP interface addresses on the Point-to-MultiPoint network.
In the graphical representation of the link-state database,
routers that can communicate directly over the Point-to-
MultiPoint network are joined by bidirectional edges, and
each router also has a stub connection to its own IP
interface address (which is in contrast to the
representation of real point-to-point links; see Figure 1a).
On some non-broadcast networks, use of Point-to-MultiPoint
mode and data-link protocols such as Inverse ARP (see
[Ref14]) will allow autodiscovery of OSPF neighbors even
though broadcast support is not available.
**FROM**
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|
+---+ +---+ * --------------------
I3| N2 |I4 * RT3| | X | X | X |
+----------------------+ T RT4| X | | | X |
I5| |I6 O RT5| X | | | X |
+---+ +---+ * RT6| X | X | X | |
|RT5| |RT6| * I3| X | | | |
+---+ +---+ I4| | X | | |
I5| | | X | |
I6| | | | X |
Figure 1b: Network map components
Point-to-MultiPoint networks
All routers can communicate directly over N2, except
routers RT4 and RT5. I3 through I6 indicate IP
interface addresses
Moy Standards Track [Page 17]
RFC 2328 OSPF Version 2 April 1998
2.1.2. An example link-state database
Figure 2 shows a sample map of an Autonomous System. The
rectangle labelled H1 indicates a host, which has a SLIP
connection to Router RT12. Router RT12 is therefore
advertising a host route. Lines between routers indicate
physical point-to-point networks. The only point-to-point
network that has been assigned interface addresses is the
one joining Routers RT6 and RT10. Routers RT5 and RT7 have
BGP connections to other Autonomous Systems. A set of BGP-
learned routes have been displayed for both of these
routers.
A cost is associated with the output side of each router
interface. This cost is configurable by the system
administrator. The lower the cost, the more likely the
interface is to be used to forward data traffic. Costs are
also associated with the externally derived routing data
(e.g., the BGP-learned routes).
The directed graph resulting from the map in Figure 2 is
depicted in Figure 3. Arcs are labelled with the cost of
the corresponding router output interface. Arcs having no
labelled cost have a cost of 0. Note that arcs leading from
networks to routers always have cost 0; they are significant
nonetheless. Note also that the externally derived routing
data appears on the graph as stubs.
The link-state database is pieced together from LSAs
generated by the routers. In the associated graphical
representation, the neighborhood of each router or transit
network is represented in a single, separate LSA. Figure 4
shows these LSAs graphically. Router RT12 has an interface
to two broadcast networks and a SLIP line to a host.
Network N6 is a broadcast network with three attached
routers. The cost of all links from Network N6 to its
attached routers is 0. Note that the LSA for Network N6 is
actually generated by one of the network's attached routers:
the router that has been elected Designated Router for the
network.
Moy Standards Track [Page 18]
RFC 2328 OSPF Version 2 April 1998
+
| 3+---+ N12 N14
N1|--|RT1|\ 1 \ N13 /
| +---+ \ 8\ |8/8
+ \ ____ \|/
/ \ 1+---+8 8+---+6
* N3 *---|RT4|------|RT5|--------+
\____/ +---+ +---+ |
+ / | |7 |
| 3+---+ / | | |
N2|--|RT2|/1 |1 |6 |
| +---+ +---+8 6+---+ |
+ |RT3|--------------|RT6| |
+---+ +---+ |
|2 Ia|7 |
| | |
+---------+ | |
N4 | |
| |
| |
N11 | |
+---------+ | |
| | | N12
|3 | |6 2/
+---+ | +---+/
|RT9| | |RT7|---N15
+---+ | +---+ 9
|1 + | |1
_|__ | Ib|5 __|_
/ \ 1+----+2 | 3+----+1 / \
* N9 *------|RT11|----|---|RT10|---* N6 *
\____/ +----+ | +----+ \____/
| | |
|1 + |1
+--+ 10+----+ N8 +---+
|H1|-----|RT12| |RT8|
+--+SLIP +----+ +---+
|2 |4
| |
+---------+ +--------+
N10 N7
Moy Standards Track [Page 19]
RFC 2328 OSPF Version 2 April 1998
Figure 2: A sample Autonomous System
**FROM**
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
----- ---------------------------------------------
RT1| | | | | | | | | | | | |0 | | | |
RT2| | | | | | | | | | | | |0 | | | |
RT3| | | | | |6 | | | | | | |0 | | | |
RT4| | | | |8 | | | | | | | |0 | | | |
RT5| | | |8 | |6 |6 | | | | | | | | | |
RT6| | |8 | |7 | | | | |5 | | | | | | |
RT7| | | | |6 | | | | | | | | |0 | | |
* RT8| | | | | | | | | | | | | |0 | | |
* RT9| | | | | | | | | | | | | | | |0 |
T RT10| | | | | |7 | | | | | | | |0 |0 | |
O RT11| | | | | | | | | | | | | | |0 |0 |
* RT12| | | | | | | | | | | | | | | |0 |
* N1|3 | | | | | | | | | | | | | | | |
N2| |3 | | | | | | | | | | | | | | |
N3|1 |1 |1 |1 | | | | | | | | | | | | |
N4| | |2 | | | | | | | | | | | | | |
N6| | | | | | |1 |1 | |1 | | | | | | |
N7| | | | | | | |4 | | | | | | | | |
N8| | | | | | | | | |3 |2 | | | | | |
N9| | | | | | | | |1 | |1 |1 | | | | |
N10| | | | | | | | | | | |2 | | | | |
N11| | | | | | | | |3 | | | | | | | |
N12| | | | |8 | |2 | | | | | | | | | |
N13| | | | |8 | | | | | | | | | | | |
N14| | | | |8 | | | | | | | | | | | |
N15| | | | | | |9 | | | | | | | | | |
H1| | | | | | | | | | | |10| | | | |
Figure 3: The resulting directed graph
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
Moy Standards Track [Page 20]
RFC 2328 OSPF Version 2 April 1998
**FROM** **FROM**
|RT12|N9|N10|H1| |RT9|RT11|RT12|N9|
* -------------------- * ----------------------
* RT12| | | | | * RT9| | | |0 |
T N9|1 | | | | T RT11| | | |0 |
O N10|2 | | | | O RT12| | | |0 |
* H1|10 | | | | * N9| | | | |
* *
RT12's router-LSA N9's network-LSA
Figure 4: Individual link state components
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
2.2. The shortest-path tree
When no OSPF areas are configured, each router in the Autonomous
System has an identical link-state database, leading to an
identical graphical representation. A router generates its
routing table from this graph by calculating a tree of shortest
paths with the router itself as root. Obviously, the shortest-
path tree depends on the router doing the calculation. The
shortest-path tree for Router RT6 in our example is depicted in
Figure 5.
The tree gives the entire path to any destination network or
host. However, only the next hop to the destination is used in
the forwarding process. Note also that the best route to any
router has also been calculated. For the processing of external
data, we note the next hop and distance to any router
advertising external routes. The resulting routing table for
Router RT6 is pictured in Table 2. Note that there is a
separate route for each end of a numbered point-to-point network
(in this case, the serial line between Routers RT6 and RT10).
Routes to networks belonging to other AS'es (such as N12) appear
as dashed lines on the shortest path tree in Figure 5. Use of
Moy Standards Track [Page 21]
RFC 2328 OSPF Version 2 April 1998
RT6(origin)
RT5 o------------o-----------o Ib
/|\ 6 |\ 7
8/8|8\ | \
/ | \ 6| \
o | o | \7
N12 o N14 | \
N13 2 | \
N4 o-----o RT3 \
/ \ 5
1/ RT10 o-------o Ia
/ |\
RT4 o-----o N3 3| \1
/| | \ N6 RT7
/ | N8 o o---------o
/ | | | /|
RT2 o o RT1 | | 2/ |9
/ | | |RT8 / |
/3 |3 RT11 o o o o
/ | | | N12 N15
N2 o o N1 1| |4
| |
N9 o o N7
/|
/ |
N11 RT9 / |RT12
o--------o-------o o--------o H1
3 | 10
|2
|
o N10
Figure 5: The SPF tree for Router RT6
Edges that are not marked with a cost have a cost of
of zero (these are network-to-router links). Routes
to networks N12-N15 are external information that is
considered in Section 2.3
Moy Standards Track [Page 22]
RFC 2328 OSPF Version 2 April 1998
Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT10 8
N7 RT10 12
N8 RT10 10
N9 RT10 11
N10 RT10 13
N11 RT10 14
H1 RT10 21
__________________________________
RT5 RT5 6
RT7 RT10 8
Table 2: The portion of Router RT6's routing table listing local
destinations.
this externally derived routing information is considered in the
next section.
2.3. Use of external routing information
After the tree is created the external routing information is
examined. This external routing information may originate from
another routing protocol such as BGP, or be statically
configured (static routes). Default routes can also be included
as part of the Autonomous System's external routing information.
External routing information is flooded unaltered throughout the
AS. In our example, all the routers in the Autonomous System
know that Router RT7 has two external routes, with metrics 2 and
9.
OSPF supports two types of external metrics. Type 1 external
metrics are expressed in the same units as OSPF interface cost
Moy Standards Track [Page 23]
RFC 2328 OSPF Version 2 April 1998
(i.e., in terms of the link state metric). Type 2 external
metrics are an order of magnitude larger; any Type 2 metric is
considered greater than the cost of any path internal to the AS.
Use of Type 2 external metrics assumes that routing between
AS'es is the major cost of routing a packet, and eliminates the
need for conversion of external costs to internal link state
metrics.
As an example of Type 1 external metric processing, suppose that
the Routers RT7 and RT5 in Figure 2 are advertising Type 1
external metrics. For each advertised external route, the total
cost from Router RT6 is calculated as the sum of the external
route's advertised cost and the distance from Router RT6 to the
advertising router. When two routers are advertising the same
external destination, RT6 picks the advertising router providing
the minimum total cost. RT6 then sets the next hop to the
external destination equal to the next hop that would be used
when routing packets to the chosen advertising router.
In Figure 2, both Router RT5 and RT7 are advertising an external
route to destination Network N12. Router RT7 is preferred since
it is advertising N12 at a distance of 10 (8+2) to Router RT6,
which is better than Router RT5's 14 (6+8). Table 3 shows the
entries that are added to the routing table when external routes
are examined:
Destination Next Hop Distance
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
Table 3: The portion of Router RT6's routing table
listing external destinations.
Processing of Type 2 external metrics is simpler. The AS
boundary router advertising the smallest external metric is
Moy Standards Track [Page 24]
RFC 2328 OSPF Version 2 April 1998
chosen, regardless of the internal distance to the AS boundary
router. Suppose in our example both Router RT5 and Router RT7
were advertising Type 2 external routes. Then all traffic
destined for Network N12 would be forwarded to Router RT7, since
2 < 8. When several equal-cost Type 2 routes exist, the
internal distance to the advertising routers is used to break
the tie.
Both Type 1 and Type 2 external metrics can be present in the AS
at the same time. In that event, Type 1 external metrics always
take precedence.
This section has assumed that packets destined for external
destinations are always routed through the advertising AS
boundary router. This is not always desirable. For example,
suppose in Figure 2 there is an additional router attached to
Network N6, called Router RTX. Suppose further that RTX does
not participate in OSPF routing, but does exchange BGP
information with the AS boundary router RT7. Then, Router RT7
would end up advertising OSPF external routes for all
destinations that should be routed to RTX. An extra hop will
sometimes be introduced if packets for these destinations need
always be routed first to Router RT7 (the advertising router).
To deal with this situation, the OSPF protocol allows an AS
boundary router to specify a "forwarding address" in its AS-
external-LSAs. In the above example, Router RT7 would specify
RTX's IP address as the "forwarding address" for all those
destinations whose packets should be routed directly to RTX.
The "forwarding address" has one other application. It enables
routers in the Autonomous System's interior to function as
"route servers". For example, in Figure 2 the router RT6 could
become a route server, gaining external routing information
through a combination of static configuration and external
routing protocols. RT6 would then start advertising itself as
an AS boundary router, and would originate a collection of OSPF
AS-external-LSAs. In each AS-external-LSA, Router RT6 would
specify the correct Autonomous System exit point to use for the
destination through appropriate setting of the LSA's "forwarding
address" field.
Moy Standards Track [Page 25]
RFC 2328 OSPF Version 2 April 1998
2.4. Equal-cost multipath
The above discussion has been simplified by considering only a
single route to any destination. In reality, if multiple
equal-cost routes to a destination exist, they are all
discovered and used. This requires no conceptual changes to the
algorithm, and its discussion is postponed until we consider the
tree-building process in more detail.
With equal cost multipath, a router potentially has several
available next hops towards any given destination.
3. Splitting the AS into Areas
OSPF allows collections of contiguous networks and hosts to be
grouped together. Such a group, together with the routers having
interfaces to any one of the included networks, is called an area.
Each area runs a separate copy of the basic link-state routing
algorithm. This means that each area has its own link-state
database and corresponding graph, as explained in the previous
section.
The topology of an area is invisible from the outside of the area.
Conversely, routers internal to a given area know nothing of the
detailed topology external to the area. This isolation of knowledge
enables the protocol to effect a marked reduction in routing traffic
as compared to treating the entire Autonomous System as a single
link-state domain.
With the introduction of areas, it is no longer true that all
routers in the AS have an identical link-state database. A router
actually has a separate link-state database for each area it is
connected to. (Routers connected to multiple areas are called area
border routers). Two routers belonging to the same area have, for
that area, identical area link-state databases.
Routing in the Autonomous System takes place on two levels,
depending on whether the source and destination of a packet reside
in the same area (intra-area routing is used) or different areas
(inter-area routing is used). In intra-area routing, the packet is
routed solely on information obtained within the area; no routing
Moy Standards Track [Page 26]
RFC 2328 OSPF Version 2 April 1998
information obtained from outside the area can be used. This
protects intra-area routing from the injection of bad routing
information. We discuss inter-area routing in Section 3.2.
3.1. The backbone of the Autonomous System
The OSPF backbone is the special OSPF Area 0 (often written as
Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP
addresses). The OSPF backbone always contains all area border
routers. The backbone is responsible for distributing routing
information between non-backbone areas. The backbone must be
contiguous. However, it need not be physically contiguous;
backbone connectivity can be established/maintained through the
configuration of virtual links.
Virtual links can be configured between any two backbone routers
that have an interface to a common non-backbone area. Virtual
links belong to the backbone. The protocol treats two routers
joined by a virtual link as if they were connected by an
unnumbered point-to-point backbone network. On the graph of the
backbone, two such routers are joined by arcs whose costs are
the intra-area distances between the two routers. The routing
protocol traffic that flows along the virtual link uses intra-
area routing only.
3.2. Inter-area routing
When routing a packet between two non-backbone areas the
backbone is used. The path that the packet will travel can be
broken up into three contiguous pieces: an intra-area path from
the source to an area border router, a backbone path between the
source and destination areas, and then another intra-area path
to the destination. The algorithm finds the set of such paths
that have the smallest cost.
Looking at this another way, inter-area routing can be pictured
as forcing a star configuration on the Autonomous System, with
the backbone as hub and each of the non-backbone areas as
spokes.
Moy Standards Track [Page 27]
RFC 2328 OSPF Version 2 April 1998
The topology of the backbone dictates the backbone paths used
between areas. The topology of the backbone can be enhanced by
adding virtual links. This gives the system administrator some
control over the routes taken by inter-area traffic.
The correct area border router to use as the packet exits the
source area is chosen in exactly the same way routers
advertising external routes are chosen. Each area border router
in an area summarizes for the area its cost to all networks
external to the area. After the SPF tree is calculated for the
area, routes to all inter-area destinations are calculated by
examining the summaries of the area border routers.
3.3. Classification of routers
Before the introduction of areas, the only OSPF routers having a
specialized function were those advertising external routing
information, such as Router RT5 in Figure 2. When the AS is
split into OSPF areas, the routers are further divided according
to function into the following four overlapping categories:
Internal routers
A router with all directly connected networks belonging to
the same area. These routers run a single copy of the basic
routing algorithm.
Area border routers
A router that attaches to multiple areas. Area border
routers run multiple copies of the basic algorithm, one copy
for each attached area. Area border routers condense the
topological information of their attached areas for
distribution to the backbone. The backbone in turn
distributes the information to the other areas.
Backbone routers
A router that has an interface to the backbone area. This
includes all routers that interface to more than one area
(i.e., area border routers). However, backbone routers do
not have to be area border routers. Routers with all
interfaces connecting to the backbone area are supported.
Moy Standards Track [Page 28]
RFC 2328 OSPF Version 2 April 1998
AS boundary routers
A router that exchanges routing information with routers
belonging to other Autonomous Systems. Such a router
advertises AS external routing information throughout the
Autonomous System. The paths to each AS boundary router are
known by every router in the AS. This classification is
completely independent of the previous classifications: AS
boundary routers may be internal or area border routers, and
may or may not participate in the backbone.
3.4. A sample area configuration
Figure 6 shows a sample area configuration. The first area
consists of networks N1-N4, along with their attached routers
RT1-RT4. The second area consists of networks N6-N8, along with
their attached routers RT7, RT8, RT10 and RT11. The third area
consists of networks N9-N11 and Host H1, along with their
attached routers RT9, RT11 and RT12. The third area has been
configured so that networks N9-N11 and Host H1 will all be
grouped into a single route, when advertised external to the
area (see Section 3.5 for more details).
In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are
internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area
border routers. Finally, as before, Routers RT5 and RT7 are AS
boundary routers.
Figure 7 shows the resulting link-state database for the Area 1.
The figure completely describes that area's intra-area routing.
It also shows the complete view of the internet for the two
internal routers RT1 and RT2. It is the job of the area border
routers, RT3 and RT4, to advertise into Area 1 the distances to
all destinations external to the area. These are indicated in
Figure 7 by the dashed stub routes. Also, RT3 and RT4 must
advertise into Area 1 the location of the AS boundary routers
RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are
flooded throughout the entire AS, and in particular throughout
Area 1. These LSAs are included in Area 1's database, and yield
routes to Networks N12-N15.
Routers RT3 and RT4 must also summarize Area 1's topology for
Moy Standards Track [Page 29]
RFC 2328 OSPF Version 2 April 1998
...........................
. + .
. | 3+---+ . N12 N14
. N1|--|RT1|\ 1 . \ N13 /
. | +---+ \ . 8\ |8/8
. + \ ____ . \|/
. / \ 1+---+8 8+---+6
. * N3 *---|RT4|------|RT5|--------+
. \____/ +---+ +---+ |
. + / \ . |7 |
. | 3+---+ / \ . | |
. N2|--|RT2|/1 1\ . |6 |
. | +---+ +---+8 6+---+ |
. + |RT3|------|RT6| |
. +---+ +---+ |
. 2/ . Ia|7 |
. / . | |
. +---------+ . | |
.Area 1 N4 . | |
........................... | |
.......................... | |
. N11 . | |
. +---------+ . | |
. | . | | N12
. |3 . Ib|5 |6 2/
. +---+ . +----+ +---+/
. |RT9| . .........|RT10|.....|RT7|---N15.
. +---+ . . +----+ +---+ 9 .
. |1 . . + /3 1\ |1 .
. _|__ . . | / \ __|_ .
. / \ 1+----+2 |/ \ / \ .
. * N9 *------|RT11|----| * N6 * .
. \____/ +----+ | \____/ .
. | . . | | .
. |1 . . + |1 .
. +--+ 10+----+ . . N8 +---+ .
. |H1|-----|RT12| . . |RT8| .
. +--+SLIP +----+ . . +---+ .
. |2 . . |4 .
. | . . | .
. +---------+ . . +--------+ .
Moy Standards Track [Page 30]
RFC 2328 OSPF Version 2 April 1998
. N10 . . N7 .
. . .Area 2 .
.Area 3 . ................................
..........................
Figure 6: A sample OSPF area configuration
distribution to the backbone. Their backbone LSAs are shown in
Table 4. These summaries show which networks are contained in
Area 1 (i.e., Networks N1-N4), and the distance to these
networks from the routers RT3 and RT4 respectively.
The link-state database for the backbone is shown in Figure 8.
The set of routers pictured are the backbone routers. Router
RT11 is a backbone router because it belongs to two areas. In
order to make the backbone connected, a virtual link has been
configured between Routers R10 and R11.
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the dashed stubs that
appear in Figure 8. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single dashed line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3
Table 4: Networks advertised to the backbone
by Routers RT3 and RT4.
Moy Standards Track [Page 31]
RFC 2328 OSPF Version 2 April 1998
**FROM**
|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |7 |N3|
----- -------------------
RT1| | | | | | |0 |
RT2| | | | | | |0 |
RT3| | | | | | |0 |
* RT4| | | | | | |0 |
* RT5| | |14|8 | | | |
T RT7| | |20|14| | | |
O N1|3 | | | | | | |
* N2| |3 | | | | | |
* N3|1 |1 |1 |1 | | | |
N4| | |2 | | | | |
Ia,Ib| | |20|27| | | |
N6| | |16|15| | | |
N7| | |20|19| | | |
N8| | |18|18| | | |
N9-N11,H1| | |29|36| | | |
N12| | | | |8 |2 | |
N13| | | | |8 | | |
N14| | | | |8 | | |
N15| | | | | |9 | |
Figure 7: Area 1's Database.
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
Moy Standards Track [Page 32]
RFC 2328 OSPF Version 2 April 1998
**FROM**
|RT|RT|RT|RT|RT|RT|RT
|3 |4 |5 |6 |7 |10|11|
------------------------
RT3| | | |6 | | | |
RT4| | |8 | | | | |
RT5| |8 | |6 |6 | | |
RT6|8 | |7 | | |5 | |
RT7| | |6 | | | | |
* RT10| | | |7 | | |2 |
* RT11| | | | | |3 | |
T N1|4 |4 | | | | | |
O N2|4 |4 | | | | | |
* N3|1 |1 | | | | | |
* N4|2 |3 | | | | | |
Ia| | | | | |5 | |
Ib| | | |7 | | | |
N6| | | | |1 |1 |3 |
N7| | | | |5 |5 |7 |
N8| | | | |4 |3 |2 |
N9-N11,H1| | | | | | |11|
N12| | |8 | |2 | | |
N13| | |8 | | | | |
N14| | |8 | | | | |
N15| | | | |9 | | |
Figure 8: The backbone's database.
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
The backbone enables the exchange of summary information between
area border routers. Every area border router hears the area
summaries from all other area border routers. It then forms a
picture of the distance to all networks outside of its area by
examining the collected LSAs, and adding in the backbone
distance to each advertising router.
Moy Standards Track [Page 33]
RFC 2328 OSPF Version 2 April 1998
Again using Routers RT3 and RT4 as an example, the procedure
goes as follows: They first calculate the SPF tree for the
backbone. This gives the distances to all other area border
routers. Also noted are the distances to networks (Ia and Ib)
and AS boundary routers (RT5 and RT7) that belong to the
backbone. This calculation is shown in Table 5.
Next, by looking at the area summaries from these area border
routers, RT3 and RT4 can determine the distance to all networks
outside their area. These distances are then advertised
internally to the area by RT3 and RT4. The advertisements that
Router RT3 and RT4 will make into Area 1 are shown in Table 6.
Note that Table 6 assumes that an area range has been configured
for the backbone which groups Ia and Ib into a single LSA.
The information imported into Area 1 by Routers RT3 and RT4
enables an internal router, such as RT1, to choose an area
border router intelligently. Router RT1 would use RT4 for
traffic to Network N6, RT3 for traffic to Network N10, and would
dist from dist from
RT3 RT4
__________________________________
to RT3 * 21
to RT4 22 *
to RT7 20 14
to RT10 15 22
to RT11 18 25
__________________________________
to Ia 20 27
to Ib 15 22
__________________________________
to RT5 14 8
to RT7 20 14
Table 5: Backbone distances calculated
by Routers RT3 and RT4.
Moy Standards Track [Page 34]
RFC 2328 OSPF Version 2 April 1998
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
load share between the two for traffic to Network N8.
Router RT1 can also determine in this manner the shortest path
to the AS boundary routers RT5 and RT7. Then, by looking at RT5
and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or
RT7 when sending to a destination in another Autonomous System
(one of the networks N12-N15).
Note that a failure of the line between Routers RT6 and RT10
will cause the backbone to become disconnected. Configuring a
virtual link between Routers RT7 and RT10 will give the backbone
more connectivity and more resistance to such failures.
3.5. IP subnetting support
OSPF attaches an IP address mask to each advertised route. The
mask indicates the range of addresses being described by the
particular route. For example, a summary-LSA for the
destination 128.185.0.0 with a mask of 0xffff0000 actually is
describing a single route to the collection of destinations
128.185.0.0 - 128.185.255.255. Similarly, host routes are
always advertised with a mask of 0xffffffff, indicating the
presence of only a single destination.
Moy Standards Track [Page 35]
RFC 2328 OSPF Version 2 April 1998
Including the mask with each advertised destination enables the
implementation of what is commonly referred to as variable-
length subnetting. This means that a single IP class A, B, or C
network number can be broken up into many subnets of various
sizes. For example, the network 128.185.0.0 could be broken up
into 62 variable-sized subnets: 15 subnets of size 4K, 15
subnets of size 256, and 32 subnets of size 8. Table 7 shows
some of the resulting network addresses together with their
masks.
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8
Table 7: Some sample subnet sizes.
There are many possible ways of dividing up a class A, B, and C
network into variable sized subnets. The precise procedure for
doing so is beyond the scope of this specification. This
specification however establishes the following guideline: When
an IP packet is forwarded, it is always forwarded to the network
that is the best match for the packet's destination. Here best
match is synonymous with the longest or most specific match.
For example, the default route with destination of 0.0.0.0 and
mask 0x00000000 is always a match for every IP destination. Yet
it is always less specific than any other match. Subnet masks
must be assigned so that the best match for any IP destination
is unambiguous.
Attaching an address mask to each route also enables the support
of IP supernetting. For example, a single physical network
segment could be assigned the [address,mask] pair
[192.9.4.0,0xfffffc00]. The segment would then be single IP
network, containing addresses from the four consecutive class C
network numbers 192.9.4.0 through 192.9.7.0. Such addressing is
now becoming commonplace with the advent of CIDR (see [Ref10]).
Moy Standards Track [Page 36]
RFC 2328 OSPF Version 2 April 1998
In order to get better aggregation at area boundaries, area
address ranges can be employed (see Section C.2 for more
details). Each address range is defined as an [address,mask]
pair. Many separate networks may then be contained in a single
address range, just as a subnetted network is composed of many
separate subnets. Area border routers then summarize the area
contents (for distribution to the backbone) by advertising a
single route for each address range. The cost of the route is
the maximum cost to any of the networks falling in the specified
range.
For example, an IP subnetted network might be configured as a
single OSPF area. In that case, a single address range could be
configured: a class A, B, or C network number along with its
natural IP mask. Inside the area, any number of variable sized
subnets could be defined. However, external to the area a
single route for the entire subnetted network would be
distributed, hiding even the fact that the network is subnetted
at all. The cost of this route is the maximum of the set of
costs to the component subnets.
3.6. Supporting stub areas
In some Autonomous Systems, the majority of the link-state
database may consist of AS-external-LSAs. An OSPF AS-external-
LSA is usually flooded throughout the entire AS. However, OSPF
allows certain areas to be configured as "stub areas". AS-
external-LSAs are not flooded into/throughout stub areas;
routing to AS external destinations in these areas is based on a
(per-area) default only. This reduces the link-state database
size, and therefore the memory requirements, for a stub area's
internal routers.
In order to take advantage of the OSPF stub area support,
default routing must be used in the stub area. This is
accomplished as follows. One or more of the stub area's area
border routers must advertise a default route into the stub area
via summary-LSAs. These summary defaults are flooded throughout
the stub area, but no further. (For this reason these defaults
pertain only to the particular stub area). These summary
default routes will be used for any destination that is not
Moy Standards Track [Page 37]
RFC 2328 OSPF Version 2 April 1998
explicitly reachable by an intra-area or inter-area path (i.e.,
AS external destinations).
An area can be configured as a stub when there is a single exit
point from the area, or when the choice of exit point need not
be made on a per-external-destination basis. For example, Area
3 in Figure 6 could be configured as a stub area, because all
external traffic must travel though its single area border
router RT11. If Area 3 were configured as a stub, Router RT11
would advertise a default route for distribution inside Area 3
(in a summary-LSA), instead of flooding the AS-external-LSAs for
Networks N12-N15 into/throughout the area.
The OSPF protocol ensures that all routers belonging to an area
agree on whether the area has been configured as a stub. This
guarantees that no confusion will arise in the flooding of AS-
external-LSAs.
There are a couple of restrictions on the use of stub areas.
Virtual links cannot be configured through stub areas. In
addition, AS boundary routers cannot be placed internal to stub
areas.
3.7. Partitions of areas
OSPF does not actively attempt to repair area partitions. When
an area becomes partitioned, each component simply becomes a
separate area. The backbone then performs routing between the
new areas. Some destinations reachable via intra-area routing
before the partition will now require inter-area routing.
However, in order to maintain full routing after the partition,
an address range must not be split across multiple components of
the area partition. Also, the backbone itself must not
partition. If it does, parts of the Autonomous System will
become unreachable. Backbone partitions can be repaired by
configuring virtual links (see Section 15).
Another way to think about area partitions is to look at the
Autonomous System graph that was introduced in Section 2. Area
IDs can be viewed as colors for the graph's edges.[1] Each edge
Moy Standards Track [Page 38]
RFC 2328 OSPF Version 2 April 1998
of the graph connects to a network, or is itself a point-to-
point network. In either case, the edge is colored with the
network's Area ID.
A group of edges, all having the same color, and interconnected
by vertices, represents an area. If the topology of the
Autonomous System is intact, the graph will have several regions
of color, each color being a distinct Area ID.
When the AS topology changes, one of the areas may become
partitioned. The graph of the AS will then have multiple
regions of the same color (Area ID). The routing in the
Autonomous System will continue to function as long as these
regions of same color are connected by the single backbone
region.
Moy Standards Track [Page 39]
RFC 2328 OSPF Version 2 April 1998
4. Functional Summary
A separate copy of OSPF's basic routing algorithm runs in each area.
Routers having interfaces to multiple areas run multiple copies of
the algorithm. A brief summary of the routing algorithm follows.
When a router starts, it first initializes the routing protocol data
structures. The router then waits for indications from the lower-
level protocols that its interfaces are functional.
A router then uses the OSPF's Hello Protocol to acquire neighbors.
The router sends Hello packets to its neighbors, and in turn
receives their Hello packets. On broadcast and point-to-point
networks, the router dynamically detects its neighboring routers by
sending its Hello packets to the multicast address AllSPFRouters.
On non-broadcast networks, some configuration information may be
necessary in order to discover neighbors. On broadcast and NBMA
networks the Hello Protocol also elects a Designated router for the
network.
The router will attempt to form adjacencies with some of its newly
acquired neighbors. Link-state databases are synchronized between
pairs of adjacent routers. On broadcast and NBMA networks, the
Designated Router determines which routers should become adjacent.
Adjacencies control the distribution of routing information.
Routing updates are sent and received only on adjacencies.
A router periodically advertises its state, which is also called
link state. Link state is also advertised when a router's state
changes. A router's adjacencies are reflected in the contents of
its LSAs. This relationship between adjacencies and link state
allows the protocol to detect dead routers in a timely fashion.
LSAs are flooded throughout the area. The flooding algorithm is
reliable, ensuring that all routers in an area have exactly the same
link-state database. This database consists of the collection of
LSAs originated by each router belonging to the area. From this
database each router calculates a shortest-path tree, with itself as
root. This shortest-path tree in turn yields a routing table for
the protocol.
Moy Standards Track [Page 40]
RFC 2328 OSPF Version 2 April 1998
4.1. Inter-area routing
The previous section described the operation of the protocol
within a single area. For intra-area routing, no other routing
information is pertinent. In order to be able to route to
destinations outside of the area, the area border routers inject
additional routing information into the area. This additional
information is a distillation of the rest of the Autonomous
System's topology.
This distillation is accomplished as follows: Each area border
router is by definition connected to the backbone. Each area
border router summarizes the topology of its attached non-
backbone areas for transmission on the backbone, and hence to
all other area border routers. An area border router then has
complete topological information concerning the backbone, and
the area summaries from each of the other area border routers.
From this information, the router calculates paths to all
inter-area destinations. The router then advertises these paths
into its attached areas. This enables the area's internal
routers to pick the best exit router when forwarding traffic
inter-area destinations.
4.2. AS external routes
Routers that have information regarding other Autonomous Systems
can flood this information throughout the AS. This external
routing information is distributed verbatim to every
participating router. There is one exception: external routing
information is not flooded into "stub" areas (see Section 3.6).
To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of
these AS boundary routers are summarized by the (non-stub) area
border routers.
Moy Standards Track [Page 41]
RFC 2328 OSPF Version 2 April 1998
4.3. Routing protocol packets
The OSPF protocol runs directly over IP, using IP protocol 89.
OSPF does not provide any explicit fragmentation/reassembly
support. When fragmentation is necessary, IP
fragmentation/reassembly is used. OSPF protocol packets have
been designed so that large protocol packets can generally be
split into several smaller protocol packets. This practice is
recommended; IP fragmentation should be avoided whenever
possible.
Routing protocol packets should always be sent with the IP TOS
field set to 0. If at all possible, routing protocol packets
should be given preference over regular IP data traffic, both
when being sent and received. As an aid to accomplishing this,
OSPF protocol packets should have their IP precedence field set
to the value Internetwork Control (see [Ref5]).
All OSPF protocol packets share a common protocol header that is
described in Appendix A. The OSPF packet types are listed below
in Table 8. Their formats are also described in Appendix A.
Type Packet name Protocol function
__________________________________________________________
1 Hello Discover/maintain neighbors
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
Table 8: OSPF packet types.
OSPF's Hello protocol uses Hello packets to discover and
maintain neighbor relationships. The Database Description and
Link State Request packets are used in the forming of
adjacencies. OSPF's reliable update mechanism is implemented by
the Link State Update and Link State Acknowledgment packets.
Moy Standards Track [Page 42]
RFC 2328 OSPF Version 2 April 1998
Each Link State Update packet carries a set of new link state
advertisements (LSAs) one hop further away from their point of
origination. A single Link State Update packet may contain the
LSAs of several routers. Each LSA is tagged with the ID of the
originating router and a checksum of its link state contents.
Each LSA also has a type field; the different types of OSPF LSAs
are listed below in Table 9.
OSPF routing packets (with the exception of Hellos) are sent
only over adjacencies. This means that all OSPF protocol
packets travel a single IP hop, except those that are sent over
virtual adjacencies. The IP source address of an OSPF protocol
packet is one end of a router adjacency, and the IP destination
address is either the other end of the adjacency or an IP
multicast address.
4.4. Basic implementation requirements
An implementation of OSPF requires the following pieces of
system support:
Timers
Two different kind of timers are required. The first kind,
called "single shot timers", fire once and cause a protocol
event to be processed. The second kind, called "interval
timers", fire at continuous intervals. These are used for
the sending of packets at regular intervals. A good example
of this is the regular broadcast of Hello packets. The
granularity of both kinds of timers is one second.
Interval timers should be implemented to avoid drift. In
some router implementations, packet processing can affect
timer execution. When multiple routers are attached to a
single network, all doing broadcasts, this can lead to the
synchronization of routing packets (which should be
avoided). If timers cannot be implemented to avoid drift,
small random amounts should be added to/subtracted from the
interval timer at each firing.
Moy Standards Track [Page 43]
RFC 2328 OSPF Version 2 April 1998
LS LSA LSA description
type name
________________________________________________________
1 Router-LSAs Originated by all routers.
This LSA describes
the collected states of the
router's interfaces to an
area. Flooded throughout a
single area only.
________________________________________________________
2 Network-LSAs Originated for broadcast
and NBMA networks by
the Designated Router. This
LSA contains the
list of routers connected
to the network. Flooded
throughout a single area only.
________________________________________________________
3,4 Summary-LSAs Originated by area border
routers, and flooded through-
out the LSA's associated
area. Each summary-LSA
describes a route to a
destination outside the area,
yet still inside the AS
(i.e., an inter-area route).
Type 3 summary-LSAs describe
routes to networks. Type 4
summary-LSAs describe
routes to AS boundary routers.
________________________________________________________
5 AS-external-LSAs Originated by AS boundary
routers, and flooded through-
out the AS. Each
AS-external-LSA describes
a route to a destination in
another Autonomous System.
Default routes for the AS can
also be described by
AS-external-LSAs.
Moy Standards Track [Page 44]
RFC 2328 OSPF Version 2 April 1998
Table 9: OSPF link state advertisements (LSAs).
IP multicast
Certain OSPF packets take the form of IP multicast
datagrams. Support for receiving and sending IP multicast
datagrams, along with the appropriate lower-level protocol
support, is required. The IP multicast datagrams used by
OSPF never travel more than one hop. For this reason, the
ability to forward IP multicast datagrams is not required.
For information on IP multicast, see [Ref7].
Variable-length subnet support
The router's IP protocol support must include the ability to
divide a single IP class A, B, or C network number into many
subnets of various sizes. This is commonly called
variable-length subnetting; see Section 3.5 for details.
IP supernetting support
The router's IP protocol support must include the ability to
aggregate contiguous collections of IP class A, B, and C
networks into larger quantities called supernets.
Supernetting has been proposed as one way to improve the
scaling of IP routing in the worldwide Internet. For more
information on IP supernetting, see [Ref10].
Lower-level protocol support
The lower level protocols referred to here are the network
access protocols, such as the Ethernet data link layer.
Indications must be passed from these protocols to OSPF as
the network interface goes up and down. For example, on an
ethernet it would be valuable to know when the ethernet
transceiver cable becomes unplugged.
Non-broadcast lower-level protocol support
On non-broadcast networks, the OSPF Hello Protocol can be
aided by providing an indication when an attempt is made to
send a packet to a dead or non-existent router. For
example, on an X.25 PDN a dead neighboring router may be
Moy Standards Track [Page 45]
RFC 2328 OSPF Version 2 April 1998
indicated by the reception of a X.25 clear with an
appropriate cause and diagnostic, and this information would
be passed to OSPF.
List manipulation primitives
Much of the OSPF functionality is described in terms of its
operation on lists of LSAs. For example, the collection of
LSAs that will be retransmitted to an adjacent router until
acknowledged are described as a list. Any particular LSA
may be on many such lists. An OSPF implementation needs to
be able to manipulate these lists, adding and deleting
constituent LSAs as necessary.
Tasking support
Certain procedures described in this specification invoke
other procedures. At times, these other procedures should
be executed in-line, that is, before the current procedure
is finished. This is indicated in the text by instructions
to execute a procedure. At other times, the other
procedures are to be executed only when the current
procedure has finished. This is indicated by instructions
to schedule a task.
4.5. Optional OSPF capabilities
The OSPF protocol defines several optional capabilities. A
router indicates the optional capabilities that it supports in
its OSPF Hello packets, Database Description packets and in its
LSAs. This enables routers supporting a mix of optional
capabilities to coexist in a single Autonomous System.
Some capabilities must be supported by all routers attached to a
specific area. In this case, a router will not accept a
neighbor's Hello Packet unless there is a match in reported
capabilities (i.e., a capability mismatch prevents a neighbor
relationship from forming). An example of this is the
ExternalRoutingCapability (see below).
Other capabilities can be negotiated during the Database
Exchange process. This is accomplished by specifying the
optional capabilities in Database Description packets. A
Moy Standards Track [Page 46]
RFC 2328 OSPF Version 2 April 1998
capability mismatch with a neighbor in this case will result in
only a subset of the link state database being exchanged between
the two neighbors.
The routing table build process can also be affected by the
presence/absence of optional capabilities. For example, since
the optional capabilities are reported in LSAs, routers
incapable of certain functions can be avoided when building the
shortest path tree.
The OSPF optional capabilities defined in this memo are listed
below. See Section A.2 for more information.
ExternalRoutingCapability
Entire OSPF areas can be configured as "stubs" (see Section
3.6). AS-external-LSAs will not be flooded into stub areas.
This capability is represented by the E-bit in the OSPF
Options field (see Section A.2). In order to ensure
consistent configuration of stub areas, all routers
interfacing to such an area must have the E-bit clear in
their Hello packets (see Sections 9.5 and 10.5).
5. Protocol Data Structures
The OSPF protocol is described herein in terms of its operation on
various protocol data structures. The following list comprises the
top-level OSPF data structures. Any initialization that needs to be
done is noted. OSPF areas, interfaces and neighbors also have
associated data structures that are described later in this
specification.
Router ID
A 32-bit number that uniquely identifies this router in the AS.
One possible implementation strategy would be to use the
smallest IP interface address belonging to the router. If a
router's OSPF Router ID is changed, the router's OSPF software
should be restarted before the new Router ID takes effect. In
this case the router should flush its self-originated LSAs from
the routing domain (see Section 14.1) before restarting, or they
will persist for up to MaxAge minutes.
Moy Standards Track [Page 47]
RFC 2328 OSPF Version 2 April 1998
Area structures
Each one of the areas to which the router is connected has its
own data structure. This data structure describes the working
of the basic OSPF algorithm. Remember that each area runs a
separate copy of the basic OSPF algorithm.
Backbone (area) structure
The OSPF backbone area is responsible for the dissemination of
inter-area routing information.
Virtual links configured
The virtual links configured with this router as one endpoint.
In order to have configured virtual links, the router itself
must be an area border router. Virtual links are identified by
the Router ID of the other endpoint -- which is another area
border router. These two endpoint routers must be attached to a
common area, called the virtual link's Transit area. Virtual
links are part of the backbone, and behave as if they were
unnumbered point-to-point networks between the two routers. A
virtual link uses the intra-area routing of its Transit area to
forward packets. Virtual links are brought up and down through
the building of the shortest-path trees for the Transit area.
List of external routes
These are routes to destinations external to the Autonomous
System, that have been gained either through direct experience
with another routing protocol (such as BGP), or through
configuration information, or through a combination of the two
(e.g., dynamic external information to be advertised by OSPF
with configured metric). Any router having these external routes
is called an AS boundary router. These routes are advertised by
the router into the OSPF routing domain via AS-external-LSAs.
List of AS-external-LSAs
Part of the link-state database. These have originated from the
AS boundary routers. They comprise routes to destinations
external to the Autonomous System. Note that, if the router is
itself an AS boundary router, some of these AS-external-LSAs
have been self-originated.
Moy Standards Track [Page 48]
RFC 2328 OSPF Version 2 April 1998
The routing table
Derived from the link-state database. Each entry in the routing
table is indexed by a destination, and contains the
destination's cost and a set of paths to use in forwarding
packets to the destination. A path is described by its type and
next hop. For more information, see Section 11.
Figure 9 shows the collection of data structures present in a
typical router. The router pictured is RT10, from the map in Figure
6. Note that Router RT10 has a virtual link configured to Router
RT11, with Area 2 as the link's Transit area. This is indicated by
the dashed line in Figure 9. When the virtual link becomes active,
through the building of the shortest path tree for Area 2, it
becomes an interface to the backbone (see the two backbone
interfaces depicted in Figure 9).
6. The Area Data Structure
The area data structure contains all the information used to run the
basic OSPF routing algorithm. Each area maintains its own link-state
database. A network belongs to a single area, and a router interface
connects to a single area. Each router adjacency also belongs to a
single area.
The OSPF backbone is the special OSPF area responsible for
disseminating inter-area routing information.
The area link-state database consists of the collection of router-
LSAs, network-LSAs and summary-LSAs that have originated from the
area's routers. This information is flooded throughout a single
area only. The list of AS-external-LSAs (see Section 5) is also
considered to be part of each area's link-state database.
Area ID
A 32-bit number identifying the area. The Area ID of 0.0.0.0 is
reserved for the backbone.
List of area address ranges
In order to aggregate routing information at area boundaries,
area address ranges can be employed. Each address range is
specified by an [address,mask] pair and a status indication of
either Advertise or DoNotAdvertise (see Section 12.4.3).
Moy Standards Track [Page 49]
RFC 2328 OSPF Version 2 April 1998
+----+
|RT10|------+
+----+ \+-------------+
/ \ |Routing Table|
/ \ +-------------+
/ \
+------+ / \ +--------+
|Area 2|---+ +---|Backbone|
+------+***********+ +--------+
/ \ * / \
/ \ * / \
+---------+ +---------+ +------------+ +------------+
|Interface| |Interface| |Virtual Link| |Interface Ib|
| to N6 | | to N8 | | to RT11 | +------------+
+---------+ +---------+ +------------+ |
/ \ | | |
/ \ | | |
+--------+ +--------+ | +-------------+ +------------+
|Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6|
| RT8 | | RT7 | | +-------------+ +------------+
+--------+ +--------+ |
|
+-------------+
|Neighbor RT11|
+-------------+
Figure 9: Router RT10's Data structures
Associated router interfaces
This router's interfaces connecting to the area. A router
interface belongs to one and only one area (or the backbone).
For the backbone area this list includes all the virtual links.
A virtual link is identified by the Router ID of its other
endpoint; its cost is the cost of the shortest intra-area path
through the Transit area that exists between the two routers.
Moy Standards Track [Page 50]
RFC 2328 OSPF Version 2 April 1998
List of router-LSAs
A router-LSA is generated by each router in the area. It
describes the state of the router's interfaces to the area.
List of network-LSAs
One network-LSA is generated for each transit broadcast and NBMA
network in the area. A network-LSA describes the set of routers
currently connected to the network.
List of summary-LSAs
Summary-LSAs originate from the area's area border routers.
They describe routes to destinations internal to the Autonomous
System, yet external to the area (i.e., inter-area
destinations).
Shortest-path tree
The shortest-path tree for the area, with this router itself as
root. Derived from the collected router-LSAs and network-LSAs
by the Dijkstra algorithm (see Section 16.1).
TransitCapability
This parameter indicates whether the area can carry data traffic
that neither originates nor terminates in the area itself. This
parameter is calculated when the area's shortest-path tree is
built (see Section 16.1, where TransitCapability is set to TRUE
if and only if there are one or more fully adjacent virtual
links using the area as Transit area), and is used as an input
to a subsequent step of the routing table build process (see
Section 16.3). When an area's TransitCapability is set to TRUE,
the area is said to be a "transit area".
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the
area. This is a configurable parameter. If AS-external-LSAs
are excluded from the area, the area is called a "stub". Within
stub areas, routing to AS external destinations will be based
solely on a default summary route. The backbone cannot be
configured as a stub area. Also, virtual links cannot be
configured through stub areas. For more information, see
Section 3.6.
Moy Standards Track [Page 51]
RFC 2328 OSPF Version 2 April 1998
StubDefaultCost
If the area has been configured as a stub area, and the router
itself is an area border router, then the StubDefaultCost
indicates the cost of the default summary-LSA that the router
should advertise into the area. See Section 12.4.3 for more
information.
Unless otherwise specified, the remaining sections of this document
refer to the operation of the OSPF protocol within a single area.
7. Bringing Up Adjacencies
OSPF creates adjacencies between neighboring routers for the purpose
of exchanging routing information. Not every two neighboring
routers will become adjacent. This section covers the generalities
involved in creating adjacencies. For further details consult
Section 10.
7.1. The Hello Protocol
The Hello Protocol is responsible for establishing and
maintaining neighbor relationships. It also ensures that
communication between neighbors is bidirectional. Hello packets
are sent periodically out all router interfaces. Bidirectional
communication is indicated when the router sees itself listed in
the neighbor's Hello Packet. On broadcast and NBMA networks,
the Hello Protocol elects a Designated Router for the network.
The Hello Protocol works differently on broadcast networks, NBMA
networks and Point-to-MultiPoint networks. On broadcast
networks, each router advertises itself by periodically
multicasting Hello Packets. This allows neighbors to be
discovered dynamically. These Hello Packets contain the
router's view of the Designated Router's identity, and the list
of routers whose Hello Packets have been seen recently.
On NBMA networks some configuration information may be necessary
for the operation of the Hello Protocol. Each router that may
potentially become Designated Router has a list of all other
Moy Standards Track [Page 52]
RFC 2328 OSPF Version 2 April 1998
routers attached to the network. A router, having Designated
Router potential, sends Hello Packets to all other potential
Designated Routers when its interface to the NBMA network first
becomes operational. This is an attempt to find the Designated
Router for the network. If the router itself is elected
Designated Router, it begins sending Hello Packets to all other
routers attached to the network.
On Point-to-MultiPoint networks, a router sends Hello Packets to
all neighbors with which it can communicate directly. These
neighbors may be discovered dynamically through a protocol such
as Inverse ARP (see [Ref14]), or they may be configured.
After a neighbor has been discovered, bidirectional
communication ensured, and (if on a broadcast or NBMA network) a
Designated Router elected, a decision is made regarding whether
or not an adjacency should be formed with the neighbor (see
Section 10.4). If an adjacency is to be formed, the first step
is to synchronize the neighbors' link-state databases. This is
covered in the next section.
7.2. The Synchronization of Databases
In a link-state routing algorithm, it is very important for all
routers' link-state databases to stay synchronized. OSPF
simplifies this by requiring only adjacent routers to remain
synchronized. The synchronization process begins as soon as the
routers attempt to bring up the adjacency. Each router
describes its database by sending a sequence of Database
Description packets to its neighbor. Each Database Description
Packet describes a set of LSAs belonging to the router's
database. When the neighbor sees an LSA that is more recent
than its own database copy, it makes a note that this newer LSA
should be requested.
This sending and receiving of Database Description packets is
called the "Database Exchange Process". During this process,
the two routers form a master/slave relationship. Each Database
Description Packet has a sequence number. Database Description
Packets sent by the master (polls) are acknowledged by the slave
through echoing of the sequence number. Both polls and their
Moy Standards Track [Page 53]
RFC 2328 OSPF Version 2 April 1998
responses contain summaries of link state data. The master is
the only one allowed to retransmit Database Description Packets.
It does so only at fixed intervals, the length of which is the
configured per-interface constant RxmtInterval.
Each Database Description contains an indication that there are
more packets to follow --- the M-bit. The Database Exchange
Process is over when a router has received and sent Database
Description Packets with the M-bit off.
During and after the Database Exchange Process, each router has
a list of those LSAs for which the neighbor has more up-to-date
instances. These LSAs are requested in Link State Request
Packets. Link State Request packets that are not satisfied are
retransmitted at fixed intervals of time RxmtInterval. When the
Database Description Process has completed and all Link State
Requests have been satisfied, the databases are deemed
synchronized and the routers are marked fully adjacent. At this
time the adjacency is fully functional and is advertised in the
two routers' router-LSAs.
The adjacency is used by the flooding procedure as soon as the
Database Exchange Process begins. This simplifies database
synchronization, and guarantees that it finishes in a
predictable period of time.
7.3. The Designated Router
Every broadcast and NBMA network has a Designated Router. The
Designated Router performs two main functions for the routing
protocol:
o The Designated Router originates a network-LSA on behalf of
the network. This LSA lists the set of routers (including
the Designated Router itself) currently attached to the
network. The Link State ID for this LSA (see Section
12.1.4) is the IP interface address of the Designated
Router. The IP network number can then be obtained by using
the network's subnet/network mask.
Moy Standards Track [Page 54]
RFC 2328 OSPF Version 2 April 1998
o The Designated Router becomes adjacent to all other routers
on the network. Since the link state databases are
synchronized across adjacencies (through adjacency bring-up
and then the flooding procedure), the Designated Router
plays a central part in the synchronization process.
The Designated Router is elected by the Hello Protocol. A
router's Hello Packet contains its Router Priority, which is
configurable on a per-interface basis. In general, when a
router's interface to a network first becomes functional, it
checks to see whether there is currently a Designated Router for
the network. If there is, it accepts that Designated Router,
regardless of its Router Priority. (This makes it harder to
predict the identity of the Designated Router, but ensures that
the Designated Router changes less often. See below.)
Otherwise, the router itself becomes Designated Router if it has
the highest Router Priority on the network. A more detailed
(and more accurate) description of Designated Router election is
presented in Section 9.4.
The Designated Router is the endpoint of many adjacencies. In
order to optimize the flooding procedure on broadcast networks,
the Designated Router multicasts its Link State Update Packets
to the address AllSPFRouters, rather than sending separate
packets over each adjacency.
Section 2 of this document discusses the directed graph
representation of an area. Router nodes are labelled with their
Router ID. Transit network nodes are actually labelled with the
IP address of their Designated Router. It follows that when the
Designated Router changes, it appears as if the network node on
the graph is replaced by an entirely new node. This will cause
the network and all its attached routers to originate new LSAs.
Until the link-state databases again converge, some temporary
loss of connectivity may result. This may result in ICMP
unreachable messages being sent in response to data traffic.
For that reason, the Designated Router should change only
infrequently. Router Priorities should be configured so that
the most dependable router on a network eventually becomes
Designated Router.
Moy Standards Track [Page 55]
RFC 2328 OSPF Version 2 April 1998
7.4. The Backup Designated Router
In order to make the transition to a new Designated Router
smoother, there is a Backup Designated Router for each broadcast
and NBMA network. The Backup Designated Router is also adjacent
to all routers on the network, and becomes Designated Router
when the previous Designated Router fails. If there were no
Backup Designated Router, when a new Designated Router became
necessary, new adjacencies would have to be formed between the
new Designated Router and all other routers attached to the
network. Part of the adjacency forming process is the
synchronizing of link-state databases, which can potentially
take quite a long time. During this time, the network would not
be available for transit data traffic. The Backup Designated
obviates the need to form these adjacencies, since they already
exist. This means the period of disruption in transit traffic
lasts only as long as it takes to flood the new LSAs (which
announce the new Designated Router).
The Backup Designated Router does not generate a network-LSA for
the network. (If it did, the transition to a new Designated
Router would be even faster. However, this is a tradeoff
between database size and speed of convergence when the
Designated Router disappears.)
The Backup Designated Router is also elected by the Hello
Protocol. Each Hello Packet has a field that specifies the
Backup Designated Router for the network.
In some steps of the flooding procedure, the Backup Designated
Router plays a passive role, letting the Designated Router do
more of the work. This cuts down on the amount of local routing
traffic. See Section 13.3 for more information.
7.5. The graph of adjacencies
An adjacency is bound to the network that the two routers have
in common. If two routers have multiple networks in common,
they may have multiple adjacencies between them.
Moy Standards Track [Page 56]
RFC 2328 OSPF Version 2 April 1998
One can picture the collection of adjacencies on a network as
forming an undirected graph. The vertices consist of routers,
with an edge joining two routers if they are adjacent. The
graph of adjacencies describes the flow of routing protocol
packets, and in particular Link State Update Packets, through
the Autonomous System.
Two graphs are possible, depending on whether a Designated
Router is elected for the network. On physical point-to-point
networks, Point-to-MultiPoint networks and virtual links,
neighboring routers become adjacent whenever they can
communicate directly. In contrast, on broadcast and NBMA
networks only the Designated Router and the Backup Designated
Router become adjacent to all other routers attached to the
network.
+---+ +---+
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2
RT7
o---------+
+---+ +---+ +---+ /|\ |
|RT7| |RT3| |RT4| / | \ |
+---+ +---+ +---+ / | \ |
| | | / | \ |
+-----------------------+ RT5o RT6o oRT4 |
| | N2 * * * |
+---+ +---+ * * * |
|RT5| |RT6| * * * |
+---+ +---+ *** |
o---------+
RT3
Figure 10: The graph of adjacencies
Moy Standards Track [Page 57]
RFC 2328 OSPF Version 2 April 1998
These graphs are shown in Figure 10. It is assumed that Router
RT7 has become the Designated Router, and Router RT3 the Backup
Designated Router, for the Network N2. The Backup Designated
Router performs a lesser function during the flooding procedure
than the Designated Router (see Section 13.3). This is the
reason for the dashed lines connecting the Backup Designated
Router RT3.
8. Protocol Packet Processing
This section discusses the general processing of OSPF routing
protocol packets. It is very important that the router link-state
databases remain synchronized. For this reason, routing protocol
packets should get preferential treatment over ordinary data
packets, both in sending and receiving.
Routing protocol packets are sent along adjacencies only (with the
exception of Hello packets, which are used to discover the
adjacencies). This means that all routing protocol packets travel a
single IP hop, except those sent over virtual links.
All routing protocol packets begin with a standard header. The
sections below provide details on how to fill in and verify this
standard header. Then, for each packet type, the section giving
more details on that particular packet type's processing is listed.
8.1. Sending protocol packets
When a router sends a routing protocol packet, it fills in the
fields of the standard OSPF packet header as follows. For more
details on the header format consult Section A.3.1:
Version #
Set to 2, the version number of the protocol as documented
in this specification.
Packet type
The type of OSPF packet, such as Link state Update or Hello
Packet.
Moy Standards Track [Page 58]
RFC 2328 OSPF Version 2 April 1998
Packet length
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.
Router ID
The identity of the router itself (who is originating the
packet).
Area ID
The OSPF area that the packet is being sent into.
Checksum
The standard IP 16-bit one's complement checksum of the
entire OSPF packet, excluding the 64-bit authentication
field. This checksum is calculated as part of the
appropriate authentication procedure; for some OSPF
authentication types, the checksum calculation is omitted.
See Section D.4 for details.
AuType and Authentication
Each OSPF packet exchange is authenticated. Authentication
types are assigned by the protocol and are documented in
Appendix D. A different authentication procedure can be
used for each IP network/subnet. Autype indicates the type
of authentication procedure in use. The 64-bit
authentication field is then for use by the chosen
authentication procedure. This procedure should be the last
called when forming the packet to be sent. See Section D.4
for details.
The IP destination address for the packet is selected as
follows. On physical point-to-point networks, the IP
destination is always set to the address AllSPFRouters. On all
other network types (including virtual links), the majority of
OSPF packets are sent as unicasts, i.e., sent directly to the
other end of the adjacency. In this case, the IP destination is
just the Neighbor IP address associated with the other end of
the adjacency (see Section 10). The only packets not sent as
unicasts are on broadcast networks; on these networks Hello
packets are sent to the multicast destination AllSPFRouters, the
Designated Router and its Backup send both Link State Update
Moy Standards Track [Page 59]
RFC 2328 OSPF Version 2 April 1998
Packets and Link State Acknowledgment Packets to the multicast
address AllSPFRouters, while all other routers send both their
Link State Update and Link State Acknowledgment Packets to the
multicast address AllDRouters.
Retransmissions of Link State Update packets are ALWAYS sent
directly to the neighbor. On multi-access networks, this means
that retransmissions should be sent to the neighbor's IP
address.
The IP source address should be set to the IP address of the
sending interface. Interfaces to unnumbered point-to-point
networks have no associated IP address. On these interfaces,
the IP source should be set to any of the other IP addresses
belonging to the router. For this reason, there must be at
least one IP address assigned to the router.[2] Note that, for
most purposes, virtual links act precisely the same as
unnumbered point-to-point networks. However, each virtual link
does have an IP interface address (discovered during the routing
table build process) which is used as the IP source when sending
packets over the virtual link.
For more information on the format of specific OSPF packet
types, consult the sections listed in Table 10.
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5
Table 10: Sections describing OSPF protocol packet transmission.
Moy Standards Track [Page 60]
RFC 2328 OSPF Version 2 April 1998
8.2. Receiving protocol packets
Whenever a protocol packet is received by the router it is
marked with the interface it was received on. For routers that
have virtual links configured, it may not be immediately obvious
which interface to associate the packet with. For example,
consider the Router RT11 depicted in Figure 6. If RT11 receives
an OSPF protocol packet on its interface to Network N8, it may
want to associate the packet with the interface to Area 2, or
with the virtual link to Router RT10 (which is part of the
backbone). In the following, we assume that the packet is
initially associated with the non-virtual link.[3]
In order for the packet to be accepted at the IP level, it must
pass a number of tests, even before the packet is passed to OSPF
for processing:
o The IP checksum must be correct.
o The packet's IP destination address must be the IP address
of the receiving interface, or one of the IP multicast
addresses AllSPFRouters or AllDRouters.
o The IP protocol specified must be OSPF (89).
o Locally originated packets should not be passed on to OSPF.
That is, the source IP address should be examined to make
sure this is not a multicast packet that the router itself
generated.
Next, the OSPF packet header is verified. The fields specified
in the header must match those configured for the receiving
interface. If they do not, the packet should be discarded:
o The version number field must specify protocol version 2.
o The Area ID found in the OSPF header must be verified. If
both of the following cases fail, the packet should be
discarded. The Area ID specified in the header must either:
Moy Standards Track [Page 61]
RFC 2328 OSPF Version 2 April 1998
(1) Match the Area ID of the receiving interface. In this
case, the packet has been sent over a single hop.
Therefore, the packet's IP source address is required to
be on the same network as the receiving interface. This
can be verified by comparing the packet's IP source
address to the interface's IP address, after masking
both addresses with the interface mask. This comparison
should not be performed on point-to-point networks. On
point-to-point networks, the interface addresses of each
end of the link are assigned independently, if they are
assigned at all.
(2) Indicate the backbone. In this case, the packet has
been sent over a virtual link. The receiving router
must be an area border router, and the Router ID
specified in the packet (the source router) must be the
other end of a configured virtual link. The receiving
interface must also attach to the virtual link's
configured Transit area. If all of these checks
succeed, the packet is accepted and is from now on
associated with the virtual link (and the backbone
area).
o Packets whose IP destination is AllDRouters should only be
accepted if the state of the receiving interface is DR or
Backup (see Section 9.1).
o The AuType specified in the packet must match the AuType
specified for the associated area.
o The packet must be authenticated. The authentication
procedure is indicated by the setting of AuType (see
Appendix D). The authentication procedure may use one or
more Authentication keys, which can be configured on a per-
interface basis. The authentication procedure may also
verify the checksum field in the OSPF packet header (which,
when used, is set to the standard IP 16-bit one's complement
checksum of the OSPF packet's contents after excluding the
64-bit authentication field). If the authentication
procedure fails, the packet should be discarded.
Moy Standards Track [Page 62]
RFC 2328 OSPF Version 2 April 1998
If the packet type is Hello, it should then be further processed
by the Hello Protocol (see Section 10.5). All other packet
types are sent/received only on adjacencies. This means that
the packet must have been sent by one of the router's active
neighbors. If the receiving interface connects to a broadcast
network, Point-to-MultiPoint network or NBMA network the sender
is identified by the IP source address found in the packet's IP
header. If the receiving interface connects to a point-to-point
network or a virtual link, the sender is identified by the
Router ID (source router) found in the packet's OSPF header.
The data structure associated with the receiving interface
contains the list of active neighbors. Packets not matching any
active neighbor are discarded.
At this point all received protocol packets are associated with
an active neighbor. For the further input processing of
specific packet types, consult the sections listed in Table 11.
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7
Table 11: Sections describing OSPF protocol packet reception.
9. The Interface Data Structure
An OSPF interface is the connection between a router and a network.
We assume a single OSPF interface to each attached network/subnet,
although supporting multiple interfaces on a single network is
considered in Appendix F. Each interface structure has at most one
IP interface address.
Moy Standards Track [Page 63]
RFC 2328 OSPF Version 2 April 1998
An OSPF interface can be considered to belong to the area that
contains the attached network. All routing protocol packets
originated by the router over this interface are labelled with the
interface's Area ID. One or more router adjacencies may develop
over an interface. A router's LSAs reflect the state of its
interfaces and their associated adjacencies.
The following data items are associated with an interface. Note
that a number of these items are actually configuration for the
attached network; such items must be the same for all routers
connected to the network.
Type
The OSPF interface type is either point-to-point, broadcast,
NBMA, Point-to-MultiPoint or virtual link.
State
The functional level of an interface. State determines whether
or not full adjacencies are allowed to form over the interface.
State is also reflected in the router's LSAs.
IP interface address
The IP address associated with the interface. This appears as
the IP source address in all routing protocol packets originated
over this interface. Interfaces to unnumbered point-to-point
networks do not have an associated IP address.
IP interface mask
Also referred to as the subnet mask, this indicates the portion
of the IP interface address that identifies the attached
network. Masking the IP interface address with the IP interface
mask yields the IP network number of the attached network. On
point-to-point networks and virtual links, the IP interface mask
is not defined. On these networks, the link itself is not
assigned an IP network number, and so the addresses of each side
of the link are assigned independently, if they are assigned at
all.
Area ID
The Area ID of the area to which the attached network belongs.
All routing protocol packets originating from the interface are
labelled with this Area ID.
Moy Standards Track [Page 64]
RFC 2328 OSPF Version 2 April 1998
HelloInterval
The length of time, in seconds, between the Hello packets that
the router sends on the interface. Advertised in Hello packets
sent out this interface.
RouterDeadInterval
The number of seconds before the router's neighbors will declare
it down, when they stop hearing the router's Hello Packets.
Advertised in Hello packets sent out this interface.
InfTransDelay
The estimated number of seconds it takes to transmit a Link
State Update Packet over this interface. LSAs contained in the
Link State Update packet will have their age incremented by this
amount before transmission. This value should take into account
transmission and propagation delays; it must be greater than
zero.
Router Priority
An 8-bit unsigned integer. When two routers attached to a
network both attempt to become Designated Router, the one with
the highest Router Priority takes precedence. A router whose
Router Priority is set to 0 is ineligible to become Designated
Router on the attached network. Advertised in Hello packets
sent out this interface.
Hello Timer
An interval timer that causes the interface to send a Hello
packet. This timer fires every HelloInterval seconds. Note
that on non-broadcast networks a separate Hello packet is sent
to each qualified neighbor.
Wait Timer
A single shot timer that causes the interface to exit the
Waiting state, and as a consequence select a Designated Router
on the network. The length of the timer is RouterDeadInterval
seconds.
List of neighboring routers
The other routers attached to this network. This list is formed
by the Hello Protocol. Adjacencies will be formed to some of
Moy Standards Track [Page 65]
RFC 2328 OSPF Version 2 April 1998
these neighbors. The set of adjacent neighbors can be
determined by an examination of all of the neighbors' states.
Designated Router
The Designated Router selected for the attached network. The
Designated Router is selected on all broadcast and NBMA networks
by the Hello Protocol. Two pieces of identification are kept
for the Designated Router: its Router ID and its IP interface
address on the network. The Designated Router advertises link
state for the network; this network-LSA is labelled with the
Designated Router's IP address. The Designated Router is
initialized to 0.0.0.0, which indicates the lack of a Designated
Router.
Backup Designated Router
The Backup Designated Router is also selected on all broadcast
and NBMA networks by the Hello Protocol. All routers on the
attached network become adjacent to both the Designated Router
and the Backup Designated Router. The Backup Designated Router
becomes Designated Router when the current Designated Router
fails. The Backup Designated Router is initialized to 0.0.0.0,
indicating the lack of a Backup Designated Router.
Interface output cost(s)
The cost of sending a data packet on the interface, expressed in
the link state metric. This is advertised as the link cost for
this interface in the router-LSA. The cost of an interface must
be greater than zero.
RxmtInterval
The number of seconds between LSA retransmissions, for
adjacencies belonging to this interface. Also used when
retransmitting Database Description and Link State Request
Packets.
AuType
The type of authentication used on the attached network/subnet.
Authentication types are defined in Appendix D. All OSPF packet
exchanges are authenticated. Different authentication schemes
may be used on different networks/subnets.
Moy Standards Track [Page 66]
RFC 2328 OSPF Version 2 April 1998
Authentication key
This configured data allows the authentication procedure to
generate and/or verify OSPF protocol packets. The
Authentication key can be configured on a per-interface basis.
For example, if the AuType indicates simple password, the
Authentication key would be a 64-bit clear password which is
inserted into the OSPF packet header. If instead Autype
indicates Cryptographic authentication, then the Authentication
key is a shared secret which enables the generation/verification
of message digests which are appended to the OSPF protocol
packets. When Cryptographic authentication is used, multiple
simultaneous keys are supported in order to achieve smooth key
transition (see Section D.3).
9.1. Interface states
The various states that router interfaces may attain is
documented in this section. The states are listed in order of
progressing functionality.