Network Working Group J. Moy
Request for Comments: 1583 Proteon, Inc.
Obsoletes: 1247 March 1994
Category: Standards Track
OSPF Version 2
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is
unlimited.
Abstract
This memo documents version 2 of the OSPF protocol. OSPF is a
link-state routing protocol. It is designed to be run internal to a
single Autonomous System. Each OSPF router maintains an identical
database describing the Autonomous System"s topology. From this
database, a routing table is calculated by constrUCting a shortest-
path tree.
OSPF recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic. OSPF provides
support for equal-cost multipath. Separate routes can be calculated
for each IP Type of Service. An area routing capability is
provided, enabling an additional level of routing protection and a
reduction in routing protocol traffic. In addition, all OSPF
routing protocol exchanges are authenticated.
OSPF Version 2 was originally documented in RFC1247. The
differences between RFC1247 and this memo are eXPlained in Appendix
E. The differences consist of bug fixes and clarifications, and are
backward-compatible in nature. Implementations of RFC1247 and of
this memo will interoperate.
Please send comments to ospf@gated.cornell.edu.
Table of Contents
1 Introduction ........................................... 5
1.1 Protocol Overview ...................................... 5
1.2 Definitions of commonly used terms ..................... 6
1.3 Brief history of link-state routing technology ......... 9
1.4 Organization of this document .......................... 9
2 The Topological Database .............................. 10
2.1 The shortest-path tree ................................ 13
2.2 Use of external routing information ................... 16
2.3 Equal-cost multipath .................................. 20
2.4 TOS-based routing ..................................... 20
3 Splitting the AS into Areas ........................... 21
3.1 The backbone of the Autonomous System ................. 22
3.2 Inter-area routing .................................... 22
3.3 Classification of routers ............................. 23
3.4 A sample area configuration ........................... 24
3.5 IP subnetting support ................................. 30
3.6 Supporting stub areas ................................. 31
3.7 Partitions of areas ................................... 32
4 Functional Summary .................................... 34
4.1 Inter-area routing .................................... 35
4.2 AS external routes .................................... 35
4.3 Routing protocol packets .............................. 35
4.4 Basic implementation requirements ..................... 38
4.5 Optional OSPF capabilities ............................ 39
5 Protocol data structures .............................. 41
6 The Area Data Structure ............................... 42
7 Bringing Up Adjacencies ............................... 45
7.1 The Hello Protocol .................................... 45
7.2 The Synchronization of Databases ...................... 46
7.3 The Designated Router ................................. 47
7.4 The Backup Designated Router .......................... 48
7.5 The graph of adjacencies .............................. 49
8 Protocol Packet Processing ............................ 50
8.1 Sending protocol packets .............................. 51
8.2 Receiving protocol packets ............................ 53
9 The Interface Data Structure .......................... 55
9.1 Interface states ...................................... 58
9.2 Events causing interface state changes ................ 61
9.3 The Interface state machine ........................... 62
9.4 Electing the Designated Router ........................ 65
9.5 Sending Hello packets ................................. 67
9.5.1 Sending Hello packets on non-broadcast networks ....... 68
10 The Neighbor Data Structure ........................... 69
10.1 Neighbor states ....................................... 72
10.2 Events causing neighbor state changes ................. 75
10.3 The Neighbor state machine ............................ 77
10.4 Whether to become adjacent ............................ 83
10.5 Receiving Hello Packets ............................... 83
10.6 Receiving Database Description Packets ................ 86
10.7 Receiving Link State Request Packets .................. 89
10.8 Sending Database Description Packets .................. 89
10.9 Sending Link State Request Packets .................... 90
10.10 An Example ............................................ 91
11 The Routing Table Structure ........................... 93
11.1 Routing table lookup .................................. 96
11.2 Sample routing table, without areas ................... 97
11.3 Sample routing table, with areas ...................... 98
12 Link State Advertisements ............................ 100
12.1 The Link State Advertisement Header .................. 101
12.1.1 LS age ............................................... 102
12.1.2 Options .............................................. 102
12.1.3 LS type .............................................. 103
12.1.4 Link State ID ........................................ 103
12.1.5 Advertising Router ................................... 105
12.1.6 LS sequence number ................................... 105
12.1.7 LS checksum .......................................... 106
12.2 The link state database .............................. 107
12.3 Representation of TOS ................................ 108
12.4 Originating link state advertisements ................ 109
12.4.1 Router links ......................................... 112
12.4.2 Network links ........................................ 118
12.4.3 Summary links ........................................ 120
12.4.4 Originating summary links into stub areas ............ 123
12.4.5 AS external links .................................... 124
13 The Flooding Procedure ............................... 126
13.1 Determining which link state is newer ................ 130
13.2 Installing link state advertisements in the database . 130
13.3 Next step in the flooding procedure .................. 131
13.4 Receiving self-originated link state ................. 134
13.5 Sending Link State Acknowledgment packets ............ 135
13.6 Retransmitting link state advertisements ............. 136
13.7 Receiving link state acknowledgments ................. 138
14 Aging The Link State Database ........................ 139
14.1 Premature aging of advertisements .................... 139
15 Virtual Links ........................................ 140
16 Calculation Of The Routing Table ..................... 142
16.1 Calculating the shortest-path tree for an area ....... 143
16.1.1 The next hop calculation ............................. 149
16.2 Calculating the inter-area routes .................... 150
16.3 Examining transit areas" summary links ............... 152
16.4 Calculating AS external routes ....................... 154
16.5 Incremental updates -- summary link advertisements ... 156
16.6 Incremental updates -- AS external link advertisements 157
16.7 Events generated as a result of routing table changes 157
16.8 Equal-cost multipath ................................. 158
16.9 Building the non-zero-TOS portion of the routing table 158
Footnotes ............................................ 161
References ........................................... 164
A OSPF data formats .................................... 166
A.1 Encapsulation of OSPF packets ........................ 166
A.2 The Options field .................................... 168
A.3 OSPF Packet Formats .................................. 170
A.3.1 The OSPF packet header ............................... 171
A.3.2 The Hello packet ..................................... 173
A.3.3 The Database Description packet ...................... 175
A.3.4 The Link State Request packet ........................ 177
A.3.5 The Link State Update packet ......................... 179
A.3.6 The Link State Acknowledgment packet ................. 181
A.4 Link state advertisement formats ..................... 183
A.4.1 The Link State Advertisement header .................. 184
A.4.2 Router links advertisements .......................... 186
A.4.3 Network links advertisements ......................... 190
A.4.4 Summary link advertisements .......................... 192
A.4.5 AS external link advertisements ...................... 194
B Architectural Constants .............................. 196
C Configurable Constants ............................... 198
C.1 Global parameters .................................... 198
C.2 Area parameters ...................................... 198
C.3 Router interface parameters .......................... 200
C.4 Virtual link parameters .............................. 202
C.5 Non-broadcast, multi-Access network parameters ....... 203
C.6 Host route parameters ................................ 203
D Authentication ....................................... 205
D.1 AuType 0 -- No authentication ........................ 205
D.2 AuType 1 -- Simple passWord .......................... 205
E Differences from RFC1247 ............................ 207
E.1 A fix for a problem with OSPF Virtual links .......... 207
E.2 Supporting supernetting and subnet 0 ................. 208
E.3 Obsoleting LSInfinity in router links advertisements . 209
E.4 TOS encoding updated ................................. 209
E.5 Summarizing routes into transit areas ................ 210
E.6 Summarizing routes into stub areas ................... 210
E.7 Flushing anomalous network links advertisements ...... 210
E.8 Required Statistics appendix deleted ................. 211
E.9 Other changes ........................................ 211
F. An algorithm for assigning Link State IDs ............ 213
Security Considerations .............................. 216
Author"s Address ..................................... 216
1. Introduction
This document is a specification of the Open Shortest Path First
(OSPF) TCP/IP internet routing protocol. OSPF is classified as an
Interior Gateway Protocol (IGP). This means that it distributes
routing information between routers belonging to a single Autonomous
System. The OSPF protocol is based on link-state or SPF technology.
This is a departure from the Bellman-Ford base used by traditional
TCP/IP internet routing protocols.
The OSPF protocol was developed by the OSPF working group of the
Internet Engineering Task Force. It has been designed expressly for
the TCP/IP internet environment, including explicit support for IP
subnetting, TOS-based routing and the tagging of externally-derived
routing information. OSPF also provides for the authentication of
routing updates, and utilizes IP multicast when sending/receiving
the updates. In addition, much work has been done to produce a
protocol that responds quickly to topology changes, yet involves
small amounts of routing protocol traffic.
The author would like to thank Fred Baker, Jeffrey Burgan, Rob
Coltun, Dino Farinacci, Vince Fuller, Phanindra JujJavarapu, Milo
Medin, Kannan Varadhan and the rest of the OSPF working group for
the ideas and support they have given to this project.
1.1. Protocol overview
OSPF routes IP packets based solely on the destination IP
address and IP Type of Service found in the IP packet header.
IP packets are routed "as is" -- they are not encapsulated in
any further protocol headers as they transit the Autonomous
System. OSPF is a dynamic routing protocol. It quickly detects
topological changes in the AS (such as router interface
failures) and calculates new loop-free routes after a period of
convergence. This period of convergence is short and involves a
minimum of routing traffic.
In a link-state routing protocol, each router maintains a
database describing the Autonomous System"s topology. Each
participating router has an identical database. Each individual
piece of this database is a particular router"s local state
(e.g., the router"s usable interfaces and reachable neighbors).
The router distributes its local state throughout the Autonomous
System by flooding.
All routers run the exact same algorithm, in parallel. From the
topological database, each router constructs a tree of shortest
paths with itself as root. This shortest-path tree gives the
route to each destination in the Autonomous System. Externally
derived routing information appears on the tree as leaves.
OSPF calculates separate routes for each Type of Service (TOS).
When several equal-cost routes to a destination exist, traffic
is distributed equally among them. The cost of a route is
described by a single dimensionless metric.
OSPF allows sets of networks to be grouped together. Such a
grouping is called an area. The topology of an area is hidden
from the rest of the Autonomous System. This information hiding
enables a significant reduction in routing traffic. Also,
routing within the area is determined only by the area"s own
topology, lending the area protection from bad routing data. An
area is a generalization of an IP subnetted network.
OSPF enables the flexible configuration of IP subnets. Each
route distributed by OSPF has a destination and mask. Two
different subnets of the same IP network number may have
different sizes (i.e., different masks). This is commonly
referred to as variable length subnetting. A packet is routed
to the best (i.e., longest or most specific) match. Host routes
are considered to be subnets whose masks are "all ones"
(0xffffffff).
All OSPF protocol exchanges are authenticated. This means that
only trusted routers can participate in the Autonomous System"s
routing. A variety of authentication schemes can be used; a
single authentication scheme is configured for each area. This
enables some areas to use much stricter authentication than
others.
Externally derived routing data (e.g., routes learned from the
Exterior Gateway Protocol (EGP)) is passed transparently
throughout the Autonomous System. This externally derived data
is kept separate from the OSPF protocol"s link state data. Each
external route can also be tagged by the advertising router,
enabling the passing of additional information between routers
on the boundaries of the Autonomous System.
1.2. Definitions of commonly used terms
This section provides definitions for terms that have a specific
meaning to the OSPF protocol and that are used throughout the
text. The reader unfamiliar with the Internet Protocol Suite is
referred to [RS-85-153] for an introduction to IP.
Router
A level three Internet Protocol packet switch. Formerly
called a gateway in much of the IP literature.
Autonomous System
A group of routers exchanging routing information via a
common routing protocol. Abbreviated as AS.
Interior Gateway Protocol
The routing protocol spoken by the routers belonging to an
Autonomous system. Abbreviated as IGP. Each Autonomous
System has a single IGP. Separate Autonomous Systems may be
running different IGPs.
Router ID
A 32-bit number assigned to each router running the OSPF
protocol. This number uniquely identifies the router within
an Autonomous System.
Network
In this memo, an IP network/subnet/supernet. It is possible
for one physical network to be assigned multiple IP
network/subnet numbers. We consider these to be separate
networks. Point-to-point physical networks are an exception
- they are considered a single network no matter how many
(if any at all) IP network/subnet numbers are assigned to
them.
Network mask
A 32-bit number indicating the range of IP addresses
residing on a single IP network/subnet/supernet. This
specification displays network masks as hexadecimal numbers.
For example, the network mask for a class C IP network is
displayed as 0xffffff00. Such a mask is often displayed
elsewhere in the literature as 255.255.255.0.
Multi-access networks
Those physical networks that support the attachment of
multiple (more than two) routers. Each pair of routers on
such a network is assumed to be able to communicate directly
(e.g., multi-drop networks are excluded).
Interface
The connection between a router and one of its attached
networks. An interface has state information associated
with it, which is oBTained from the underlying lower level
protocols and the routing protocol itself. An interface to
a network has associated with it a single IP address and
mask (unless the network is an unnumbered point-to-point
network). An interface is sometimes also referred to as a
link.
Neighboring routers
Two routers that have interfaces to a common network. On
multi-access networks, neighbors are dynamically discovered
by OSPF"s Hello Protocol.
Adjacency
A relationship formed between selected neighboring routers
for the purpose of exchanging routing information. Not
every pair of neighboring routers become adjacent.
Link state advertisement
Describes the local state of a router or network. This
includes the state of the router"s interfaces and
adjacencies. Each link state advertisement is flooded
throughout the routing domain. The collected link state
advertisements of all routers and networks forms the
protocol"s topological database.
Hello Protocol
The part of the OSPF protocol used to establish and maintain
neighbor relationships. On multi-access networks the Hello
Protocol can also dynamically discover neighboring routers.
Designated Router
Each multi-access network that has at least two attached
routers has a Designated Router. The Designated Router
generates a link state advertisement for the multi-access
network and has other special responsibilities in the
running of the protocol. The Designated Router is elected
by the Hello Protocol.
The Designated Router concept enables a reduction in the
number of adjacencies required on a multi-access network.
This in turn reduces the amount of routing protocol traffic
and the size of the topological database.
Lower-level protocols
The underlying network access protocols that provide
services to the Internet Protocol and in turn the OSPF
protocol. Examples of these are the X.25 packet and frame
levels for X.25 PDNs, and the ethernet data link layer for
ethernets.
1.3. Brief history of link-state routing technology
OSPF is a link state routing protocol. Such protocols are also
referred to in the literature as SPF-based or distributed-
database protocols. This section gives a brief description of
the developments in link-state technology that have influenced
the OSPF protocol.
The first link-state routing protocol was developed for use in
the ARPANET packet switching network. This protocol is
described in [McQuillan]. It has formed the starting point for
all other link-state protocols. The homogeneous Arpanet
environment, i.e., single-vendor packet switches connected by
synchronous serial lines, simplified the design and
implementation of the original protocol.
Modifications to this protocol were proposed in [Perlman].
These modifications dealt with increasing the fault tolerance of
the routing protocol through, among other things, adding a
checksum to the link state advertisements (thereby detecting
database corruption). The paper also included means for
reducing the routing traffic overhead in a link-state protocol.
This was accomplished by introducing mechanisms which enabled
the interval between link state advertisement originations to be
increased by an order of magnitude.
A link-state algorithm has also been proposed for use as an ISO
IS-IS routing protocol. This protocol is described in [DEC].
The protocol includes methods for data and routing traffic
reduction when operating over broadcast networks. This is
accomplished by election of a Designated Router for each
broadcast network, which then originates a link state
advertisement for the network.
The OSPF subcommittee of the IETF has extended this work in
developing the OSPF protocol. The Designated Router concept has
been greatly enhanced to further reduce the amount of routing
traffic required. Multicast capabilities are utilized for
additional routing bandwidth reduction. An area routing scheme
has been developed enabling information
hiding/protection/reduction. Finally, the algorithm has been
modified for efficient operation in TCP/IP internets.
1.4. Organization of this document
The first three sections of this specification give a general
overview of the protocol"s capabilities and functions. Sections
4-16 explain the protocol"s mechanisms in detail. Packet
formats, protocol constants and configuration items are
specified in the appendices.
Labels such as HelloInterval encountered in the text refer to
protocol constants. They may or may not be configurable. The
architectural constants are explained in Appendix B. The
configurable constants are explained in Appendix C.
The detailed specification of the protocol is presented in terms
of data structures. This is done in order to make the
explanation more precise. Implementations of the protocol are
required to support the functionality described, but need not
use the precise data structures that appear in this memo.
2. The Topological Database
The Autonomous System"s topological database describes a directed
graph. The vertices of the graph consist of routers and networks.
A graph edge connects two routers when they are attached via a
physical point-to-point network. An edge connecting a router to a
network indicates that the router has an interface on the network.
The vertices of the graph can be further typed according to
function. Only some of these types carry transit data traffic; that
is, traffic that is neither locally originated nor locally destined.
Vertices that can carry transit traffic are indicated on the graph
by having both incoming and outgoing edges.
Vertex type Vertex name Transit?
_____________________________________
1 Router yes
2 Network yes
3 Stub network no
Table 1: OSPF vertex types.
OSPF supports the following types of physical networks:
Point-to-point networks
A network that joins a single pair of routers. A 56Kb serial
line is an example of a point-to-point network.
Broadcast networks
Networks supporting many (more than two) attached routers,
together with the capability to address a single physical
message to all of the attached routers (broadcast). Neighboring
routers are discovered dynamically on these nets using OSPF"s
Hello Protocol. The Hello Protocol itself takes advantage of
the broadcast capability. The protocol makes further use of
multicast capabilities, if they exist. An ethernet is an
example of a broadcast network.
Non-broadcast networks
Networks supporting many (more than two) routers, but having no
broadcast capability. Neighboring routers are also discovered
on these nets using OSPF"s Hello Protocol. However, due to the
lack of broadcast capability, some configuration information is
necessary for the correct operation of the Hello Protocol. On
these networks, OSPF protocol packets that are normally
multicast need to be sent to each neighboring router, in turn.
An X.25 Public Data Network (PDN) is an example of a non-
broadcast network.
The neighborhood of each network node in the graph depends on
whether the network has multi-access capabilities (either broadcast
or non-broadcast) and, if so, the number of routers having an
interface to the network. The three cases are depicted in Figure 1.
Rectangles indicate routers. Circles and oblongs indicate multi-
access networks. Router names are prefixed with the letters RT and
network names with the letter N. Router interface names are
prefixed by the letter I. Lines between routers indicate point-to-
point networks. The left side of the figure shows a network with
its connected routers, with the resulting graph shown on the right.
Two routers joined by a point-to-point network are represented in
the directed graph as being directly connected by a pair of edges,
one in each direction. Interfaces to physical point-to-point
networks need not be assigned IP addresses. Such a point-to-point
network is called unnumbered. The graphical representation of
point-to-point networks is designed so that unnumbered networks can
be supported naturally. When interface addresses exist, they are
modelled as stub routes. Note that each router would then have a
stub connection to the other router"s interface address (see Figure
1).
When multiple routers are attached to a multi-access network, the
directed graph shows all routers bidirectionally connected to the
network vertex (again, see Figure 1). If only a single router is
attached to a multi-access network, the network will appear in the
**FROM**
* RT1RT2
+---+Ia +---+ * ------------
RT1------RT2 T RT1 X
+---+ Ib+---+ O RT2 X
* Ia X
* Ib X
Physical point-to-point networks
**FROM**
+---+ +---+
RT3 RT4 RT3RT4RT5RT6N2
+---+ +---+ * ------------------------
N2 * RT3 X
+----------------------+ T RT4 X
O RT5 X
+---+ +---+ * RT6 X
RT5 RT6 * N2 X X X X
+---+ +---+
Multi-access networks
**FROM**
+---+ *
RT7 * RT7 N3
+---+ T ------------
O RT7
+----------------------+ * N3 X
N3 *
Stub multi-access networks
Figure 1: Network map components
Networks and routers are represented by vertices.
An edge connects Vertex A to Vertex B iff the
intersection of Column A and Row B is marked with
an X.
directed graph as a stub connection.
Each network (stub or transit) in the graph has an IP address and
associated network mask. The mask indicates the number of nodes on
the network. Hosts attached directly to routers (referred to as
host routes) appear on the graph as stub networks. The network mask
for a host route is always 0xffffffff, which indicates the presence
of a single node.
Figure 2 shows a sample map of an Autonomous System. The rectangle
labelled H1 indicates a host, which has a SLIP connection to Router
RT12. Router RT12 is therefore advertising a host route. Lines
between routers indicate physical point-to-point networks. The only
point-to-point network that has been assigned interface addresses is
the one joining Routers RT6 and RT10. Routers RT5 and RT7 have EGP
connections to other Autonomous Systems. A set of EGP-learned
routes have been displayed for both of these routers.
A cost is associated with the output side of each router interface.
This cost is configurable by the system administrator. The lower
the cost, the more likely the interface is to be used to forward
data traffic. Costs are also associated with the externally derived
routing data (e.g., the EGP-learned routes).
The directed graph resulting from the map in Figure 2 is depicted in
Figure 3. Arcs are labelled with the cost of the corresponding
router output interface. Arcs having no labelled cost have a cost
of 0. Note that arcs leading from networks to routers always have
cost 0; they are significant nonetheless. Note also that the
externally derived routing data appears on the graph as stubs.
The topological database (or what has been referred to above as the
directed graph) is pieced together from link state advertisements
generated by the routers. The neighborhood of each transit vertex
is represented in a single, separate link state advertisement.
Figure 4 shows graphically the link state representation of the two
kinds of transit vertices: routers and multi-access networks.
Router RT12 has an interface to two broadcast networks and a SLIP
line to a host. Network N6 is a broadcast network with three
attached routers. The cost of all links from Network N6 to its
attached routers is 0. Note that the link state advertisement for
Network N6 is actually generated by one of the attached routers: the
router that has been elected Designated Router for the network.
2.1. The shortest-path tree
When no OSPF areas are configured, each router in the Autonomous
System has an identical topological database, leading to an
+
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 Ia7

+---------+
N4


N11
+---------+
N12
3 6 2/
+---+ +---+/
RT9 RT7---N15
+---+ +---+ 9
1 + 1
___ Ib5 ___
/ 1+----+2 3+----+1 /
* N9 *------RT11-------RT10---* N6 *
____/ +----+ +----+ ____/

1 + 1
+--+ 10+----+ N8 +---+
H1-----RT12 RT8
+--+SLIP +----+ +---+
2 4

+---------+ +--------+
N10 N7
Figure 2: A sample Autonomous System
**FROM**
RTRTRTRTRTRTRTRTRTRTRTRT
1 2 3 4 5 6 7 8 9 101112N3N6N8N9
----- ---------------------------------------------
RT1 0
RT2 0
RT3 6 0
RT4 80
RT5 8 6 6
RT6 8 7 5
RT7 6 0
* RT8 0
* RT9 0
T RT10 70 0
O RT11 0 0
* RT12 0
* N13
N2 3
N31 1 1 1
N4 2
N6 1 1 1
N7 4
N8 3 2
N91 1 1
N10 2
N113
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.
**FROM** **FROM**
RT12N9N10H1 RT9RT11RT12N9
* -------------------- * ----------------------
* RT12 * RT9 0
T N91 T RT11 0
O N102 O RT12 0
* H110 * N9
* *
RT12"s router links N9"s network links
advertisement advertisement
Figure 4: Individual link state components
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
identical graphical representation. A router generates its
routing table from this graph by calculating a tree of shortest
paths with the router itself as root. Obviously, the shortest-
path tree depends on the router doing the calculation. The
shortest-path tree for Router RT6 in our example is depicted in
Figure 5.
The tree gives the entire route to any destination network or
host. However, only the next hop to the destination is used in
the forwarding process. Note also that the best route to any
router has also been calculated. For the processing of external
data, we note the next hop and distance to any router
advertising external routes. The resulting routing table for
Router RT6 is pictured in Table 2. Note that there is a
separate route for each end of a numbered serial line (in this
case, the serial line between Routers RT6 and RT10).
Routes to networks belonging to other AS"es (such as N12) appear
as dashed lines on the shortest path tree in Figure 5. Use of
this externally derived routing information is considered in the
next section.
2.2. Use of external routing information
After the tree is created the external routing information is
examined. This external routing information may originate from
another routing protocol such as EGP, or be statically
RT6(origin)
RT5 o------------o-----------o Ib
/ 6 7
8/88
/
o o 7
N12 o N14
N13 2
N4 o-----o RT3
/ 5
1/ RT10 o-------o Ia
/
RT4 o-----o N3 3 1
/ N6 RT7
/ N8 o o---------o
/ /
RT2 o o RT1 2/ 9
/ RT8 /
/3 3 RT11 o o o o
/ N12 N15
N2 o o N1 1 4

N9 o o N7
/
/
N11 RT9 / RT12
o--------o-------o o--------o H1
3 10
2

o N10
Figure 5: The SPF tree for Router RT6
Edges that are not marked with a cost have a cost of
of zero (these are network-to-router links). Routes
to networks N12-N15 are external information that is
considered in Section 2.2
Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT10 8
N7 RT10 12
N8 RT10 10
N9 RT10 11
N10 RT10 13
N11 RT10 14
H1 RT10 21
__________________________________
RT5 RT5 6
RT7 RT10 8
Table 2: The portion of Router RT6"s routing table listing local
destinations.
configured (static routes). Default routes can also be included
as part of the Autonomous System"s external routing information.
External routing information is flooded unaltered throughout the
AS. In our example, all the routers in the Autonomous System
know that Router RT7 has two external routes, with metrics 2 and
9.
OSPF supports two types of external metrics. Type 1 external
metrics are equivalent to the link state metric. Type 2
external metrics are greater than the cost of any path internal
to the AS. Use of Type 2 external metrics assumes that routing
between AS"es is the major cost of routing a packet, and
eliminates the need for conversion of external costs to internal
link state metrics.
As an example of Type 1 external metric processing, suppose that
the Routers RT7 and RT5 in Figure 2 are advertising Type 1
external metrics. For each external route, the distance from
Router RT6 is calculated as the sum of the external route"s cost
and the distance from Router RT6 to the advertising router. For
every external destination, the router advertising the shortest
route is discovered, and the next hop to the advertising router
becomes the next hop to the destination.
Both Router RT5 and RT7 are advertising an external route to
destination Network N12. Router RT7 is preferred since it is
advertising N12 at a distance of 10 (8+2) to Router RT6, which
is better than Router RT5"s 14 (6+8). Table 3 shows the entries
that are added to the routing table when external routes are
examined:
Destination Next Hop Distance
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
Table 3: The portion of Router RT6"s routing table
listing external destinations.
Processing of Type 2 external metrics is simpler. The AS
boundary router advertising the smallest external metric is
chosen, regardless of the internal distance to the AS boundary
router. Suppose in our example both Router RT5 and Router RT7
were advertising Type 2 external routes. Then all traffic
destined for Network N12 would be forwarded to Router RT7, since
2 < 8. When several equal-cost Type 2 routes exist, the
internal distance to the advertising routers is used to break
the tie.
Both Type 1 and Type 2 external metrics can be present in the AS
at the same time. In that event, Type 1 external metrics always
take precedence.
This section has assumed that packets destined for external
destinations are always routed through the advertising AS
boundary router. This is not always desirable. For example,
suppose in Figure 2 there is an additional router attached to
Network N6, called Router RTX. Suppose further that RTX does
not participate in OSPF routing, but does exchange EGP
information with the AS boundary router RT7. Then, Router RT7
would end up advertising OSPF external routes for all
destinations that should be routed to RTX. An extra hop will
sometimes be introduced if packets for these destinations need
always be routed first to Router RT7 (the advertising router).
To deal with this situation, the OSPF protocol allows an AS
boundary router to specify a "forwarding address" in its
external advertisements. In the above example, Router RT7 would
specify RTX"s IP address as the "forwarding address" for all
those destinations whose packets should be routed directly to
RTX.
The "forwarding address" has one other application. It enables
routers in the Autonomous System"s interior to function as
"route servers". For example, in Figure 2 the router RT6 could
become a route server, gaining external routing information
through a combination of static configuration and external
routing protocols. RT6 would then start advertising itself as
an AS boundary router, and would originate a collection of OSPF
external advertisements. In each external advertisement, Router
RT6 would specify the correct Autonomous System exit point to
use for the destination through appropriate setting of the
advertisement"s "forwarding address" field.
2.3. Equal-cost multipath
The above discussion has been simplified by considering only a
single route to any destination. In reality, if multiple
equal-cost routes to a destination exist, they are all
discovered and used. This requires no conceptual changes to the
algorithm, and its discussion is postponed until we consider the
tree-building process in more detail.
With equal cost multipath, a router potentially has several
available next hops towards any given destination.
2.4. TOS-based routing
OSPF can calculate a separate set of routes for each IP Type of
Service. This means that, for any destination, there can
potentially be multiple routing table entries, one for each IP
TOS. The IP TOS values are represented in OSPF exactly as they
appear in the IP packet header.
Up to this point, all examples shown have assumed that routes do
not vary on TOS. In order to differentiate routes based on TOS,
separate interface costs can be configured for each TOS. For
example, in Figure 2 there could be multiple costs (one for each
TOS) listed for each interface. A cost for TOS 0 must always be
specified.
When interface costs vary based on TOS, a separate shortest path
tree is calculated for each TOS (see Section 2.1). In addition,
external costs can vary based on TOS. For example, in Figure 2
Router RT7 could advertise a separate type 1 external metric for
each TOS. Then, when calculating the TOS X distance to Network
N15 the cost of the shortest TOS X path to RT7 would be added to
the TOS X cost advertised by RT7 for Network N15 (see Section
2.2).
All OSPF implementations must be capable of calculating routes
based on TOS. However, OSPF routers can be configured to route
all packets on the TOS 0 path (see Appendix C), eliminating the
need to calculate non-zero TOS paths. This can be used to
conserve routing table space and processing resources in the
router. These TOS-0-only routers can be mixed with routers that
do route based on TOS. TOS-0-only routers will be avoided as
much as possible when forwarding traffic requesting a non-zero
TOS.
It may be the case that no path exists for some non-zero TOS,
even if the router is calculating non-zero TOS paths. In that
case, packets requesting that non-zero TOS are routed along the
TOS 0 path (see Section 11.1).
3. Splitting the AS into Areas
OSPF allows collections of contiguous networks and hosts to be
grouped together. Such a group, together with the routers having
interfaces to any one of the included networks, is called an area.
Each area runs a separate copy of the basic link-state routing
algorithm. This means that each area has its own topological
database and corresponding graph, as explained in the previous
section.
The topology of an area is invisible from the outside of the area.
Conversely, routers internal to a given area know nothing of the
detailed topology external to the area. This isolation of knowledge
enables the protocol to effect a marked reduction in routing traffic
as compared to treating the entire Autonomous System as a single
link-state domain.
With the introduction of areas, it is no longer true that all
routers in the AS have an identical topological database. A router
actually has a separate topological database for each area it is
connected to. (Routers connected to multiple areas are called area
border routers). Two routers belonging to the same area have, for
that area, identical area topological databases.
Routing in the Autonomous System takes place on two levels,
depending on whether the source and destination of a packet reside
in the same area (intra-area routing is used) or different areas
(inter-area routing is used). In intra-area routing, the packet is
routed solely on information obtained within the area; no routing
information obtained from outside the area can be used. This
protects intra-area routing from the injection of bad routing
information. We discuss inter-area routing in Section 3.2.
3.1. The backbone of the Autonomous System
The backbone consists of those networks not contained in any
area, their attached routers, and those routers that belong to
multiple areas. The backbone must be contiguous.
It is possible to define areas in such a way that the backbone
is no longer contiguous. In this case the system administrator
must restore backbone connectivity by configuring virtual links.
Virtual links can be configured between any two backbone routers
that have an interface to a common non-backbone area. Virtual
links belong to the backbone. The protocol treats two routers
joined by a virtual link as if they were connected by an
unnumbered point-to-point network. On the graph of the
backbone, two such routers are joined by arcs whose costs are
the intra-area distances between the two routers. The routing
protocol traffic that flows along the virtual link uses intra-
area routing only.
The backbone is responsible for distributing routing information
between areas. The backbone itself has all of the properties of
an area. The topology of the backbone is invisible to each of
the areas, while the backbone itself knows nothing of the
topology of the areas.
3.2. Inter-area routing
When routing a packet between two areas the backbone is used.
The path that the packet will travel can be broken up into three
contiguous pieces: an intra-area path from the source to an area
border router, a backbone path between the source and
destination areas, and then another intra-area path to the
destination. The algorithm finds the set of such paths that
have the smallest cost.
Looking at this another way, inter-area routing can be pictured
as forcing a star configuration on the Autonomous System, with
the backbone as hub and each of the areas as spokes.
The topology of the backbone dictates the backbone paths used
between areas. The topology of the backbone can be enhanced by
adding virtual links. This gives the system administrator some
control over the routes taken by inter-area traffic.
The correct area border router to use as the packet exits the
source area is chosen in exactly the same way routers
advertising external routes are chosen. Each area border router
in an area summarizes for the area its cost to all networks
external to the area. After the SPF tree is calculated for the
area, routes to all other networks are calculated by examining
the summaries of the area border routers.
3.3. Classification of routers
Before the introduction of areas, the only OSPF routers having a
specialized function were those advertising external routing
information, such as Router RT5 in Figure 2. When the AS is
split into OSPF areas, the routers are further divided according
to function into the following four overlapping categories:
Internal routers
A router with all directly connected networks belonging to
the same area. Routers with only backbone interfaces also
belong to this category. These routers run a single copy of
the basic routing algorithm.
Area border routers
A router that attaches to multiple areas. Area border
routers run multiple copies of the basic algorithm, one copy
for each attached area and an additional copy for the
backbone. Area border routers condense the topological
information of their attached areas for distribution to the
backbone. The backbone in turn distributes the information
to the other areas.
Backbone routers
A router that has an interface to the backbone. This
includes all routers that interface to more than one area
(i.e., area border routers). However, backbone routers do
not have to be area border routers. Routers with all
interfaces connected to the backbone are considered to be
internal routers.
AS boundary routers
A router that exchanges routing information with routers
belonging to other Autonomous Systems. Such a router has AS
external routes that are advertised throughout the
Autonomous System. The path to each AS boundary router is
known by every router in the AS. This classification is
completely independent of the previous classifications: AS
boundary routers may be internal or area border routers, and
may or may not participate in the backbone.
3.4. A sample area configuration
Figure 6 shows a sample area configuration. The first area
consists of networks N1-N4, along with their attached routers
RT1-RT4. The second area consists of networks N6-N8, along with
their attached routers RT7, RT8, RT10 and RT11. The third area
consists of networks N9-N11 and Host H1, along with their
attached routers RT9, RT11 and RT12. The third area has been
configured so that networks N9-N11 and Host H1 will all be
grouped into a single route, when advertised external to the
area (see Section 3.5 for more details).
In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are
internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area
border routers. Finally, as before, Routers RT5 and RT7 are AS
boundary routers.
Figure 7 shows the resulting topological database for the Area
1. The figure completely describes that area"s intra-area
routing. It also shows the complete view of the internet for
the two internal routers RT1 and RT2. It is the job of the area
border routers, RT3 and RT4, to advertise into Area 1 the
distances to all destinations external to the area. These are
indicated in Figure 7 by the dashed stub routes. Also, RT3 and
RT4 must advertise into Area 1 the location of the AS boundary
routers RT5 and RT7. Finally, external advertisements from RT5
and RT7 are flooded throughout the entire AS, and in particular
throughout Area 1. These advertisements are included in Area
1"s database, and yield routes to Networks N12-N15.
Routers RT3 and RT4 must also summarize Area 1"s topology for
distribution to the backbone. Their backbone advertisements are
shown in Table 4. These summaries show which networks are
contained in Area 1 (i.e., Networks N1-N4), and the distance to
these networks from the routers RT3 and RT4 respectively.
...........................
. + .
. 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/ . Ia7
. / .
. +---------+ .
.Area 1 N4 .
...........................
..........................
. N11 .
. +---------+ .
. . N12
. 3 . Ib5 6 2/
. +---+ . +----+ +---+/
. RT9 . .........RT10.....RT7---N15.
. +---+ . . +----+ +---+ 9 .
. 1 . . + /3 1 1 .
. ___ . . / ___ .
. / 1+----+2 / / .
. * N9 *------RT11---- * N6 * .
. ____/ +----+ ____/ .
. . . .
. 1 . . + 1 .
. +--+ 10+----+ . . N8 +---+ .
. H1-----RT12 . . RT8 .
. +--+SLIP +----+ . . +---+ .
. 2 . . 4 .
. . . .
. +---------+ . . +--------+ .
. N10 . . N7 .
. . .Area 2 .
.Area 3 . ................................
..........................
Figure 6: A sample OSPF area configuration
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3
Table 4: Networks advertised to the backbone
by Routers RT3 and RT4.
The topological database for the backbone is shown in Figure 8.
The set of routers pictured are the backbone routers. Router
RT11 is a backbone router because it belongs to two areas. In
order to make the backbone connected, a virtual link has been
configured between Routers R10 and R11.
Again, Routers RT3, RT4, RT7, RT10 and RT11 are area border
routers. As Routers RT3 and RT4 did above, they have condensed
the routing information of their attached areas for distribution
via the backbone; these are the dashed stubs that appear in
Figure 8. Remember that the third area has been configured to
condense Networks N9-N11 and Host H1 into a single route. This
yields a single dashed line for networks N9-N11 and Host H1 in
Figure 8. Routers RT5 and RT7 are AS boundary routers; their
externally derived information also appears on the graph in
Figure 8 as stubs.
The backbone enables the exchange of summary information between
area border routers. Every area border router hears the area
summaries from all other area border routers. It then forms a
picture of the distance to all networks outside of its area by
examining the collected advertisements, and adding in the
backbone distance to each advertising router.
Again using Routers RT3 and RT4 as an example, the procedure
goes as follows: They first calculate the SPF tree for the
backbone. This gives the distances to all other area border
routers. Also noted are the distances to networks (Ia and Ib)
and AS boundary routers (RT5 and RT7) that belong to the
backbone. This calculation is shown in Table 5.
Next, by looking at the area summaries from these area border
routers, RT3 and RT4 can determine the distance to all networks
outside their area. These distances are then advertised
internally to the area by RT3 and RT4. The advertisements that
Router RT3 and RT4 will make into Area 1 are shown in Table 6.
**FROM**
RTRTRTRTRTRT
1 2 3 4 5 7 N3
----- -------------------
RT1 0
RT2 0
RT3 0
* RT4 0
* RT5 148
T RT7 2014
O N13
* N2 3
* N31 1 1 1
N4 2
Ia,Ib 1522
N6 1615
N7 2019
N8 1818
N9-N11,H1 1916
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.
**FROM**
RTRTRTRTRTRTRT
3 4 5 6 7 1011
------------------------
RT3 6
RT4 8
RT5 8 6 6
RT68 7 5
RT7 6
* RT10 7 2
* RT11 3
T N14 4
O N24 4
* N31 1
* N42 3
Ia 5
Ib 7
N6 1 1 3
N7 5 5 7
N8 4 3 2
N9-N11,H1 1
N12 8 2
N13 8
N14 8
N15 9
Figure 8: The backbone"s database.
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
Area border dist from dist from
router RT3 RT4
______________________________________
to RT3 * 21
to RT4 22 *
to RT7 20 14
to RT10 15 22
to RT11 18 25
______________________________________
to Ia 20 27
to Ib 15 22
______________________________________
to RT5 14 8
to RT7 20 14
Table 5: Backbone distances calculated
by Routers RT3 and RT4.
Note that Table 6 assumes that an area range has been configured
for the backbone which groups Ia and Ib into a single
advertisement.
The information imported into Area 1 by Routers RT3 and RT4
enables an internal router, such as RT1, to choose an area
border router intelligently. Router RT1 would use RT4 for
traffic to Network N6, RT3 for traffic to Network N10, and would
load share between the two for traffic to Network N8.
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 15 22
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 19 26
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
Router RT1 can also determine in this manner the shortest path
to the AS boundary routers RT5 and RT7. Then, by looking at RT5
and RT7"s external advertisements, Router RT1 can decide between
RT5 or RT7 when sending to a destination in another Autonomous
System (one of the networks N12-N15).
Note that a failure of the line between Routers RT6 and RT10
will cause the backbone to become disconnected. Configuring a
virtual link between Routers RT7 and RT10 will give the backbone
more connectivity and more resistance to such failures. Also, a
virtual link between RT7 and RT10 would allow a much shorter
path between the third area (containing N9) and the router RT7,
which is advertising a good route to external network N12.
3.5. IP subnetting support
OSPF attaches an IP address mask to each advertised route. The
mask indicates the range of addresses being described by the
particular route. For example, a summary advertisement for the
destination 128.185.0.0 with a mask of 0xffff0000 actually is
describing a single route to the collection of destinations
128.185.0.0 - 128.185.255.255. Similarly, host routes are
always advertised with a mask of 0xffffffff, indicating the
presence of only a single destination.
Including the mask with each advertised destination enables the
implementation of what is commonly referred to as variable-
length subnetting. This means that a single IP class A, B, or C
network number can be broken up into many subnets of various
sizes. For example, the network 128.185.0.0 could be broken up
into 62 variable-sized subnets: 15 subnets of size 4K, 15
subnets of size 256, and 32 subnets of size 8. Table 7 shows
some of the resulting network addresses together with their
masks:
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8
Table 7: Some sample subnet sizes.
There are many possible ways of dividing up a class A, B, and C
network into variable sized subnets. The precise procedure for
doing so is beyond the scope of this specification. This
specification however establishes the following guideline: When
an IP packet is forwarded, it is always forwarded to the network
that is the best match for the packet"s destination. Here best
match is synonymous with the longest or most specific match.
For example, the default route with destination of 0.0.0.0 and
mask 0x00000000 is always a match for every IP destination. Yet
it is always less specific than any other match. Subnet masks
must be assigned so that the best match for any IP destination
is unambiguous.
The OSPF area concept is modelled after an IP subnetted network.
OSPF areas have been loosely defined to be a collection of
networks. In actuality, an OSPF area is specified to be a list
of address ranges (see Section C.2 for more details). Each
address range is defined as an [address,mask] pair. Many
separate networks may then be contained in a single address
range, just as a subnetted network is composed of many separate
subnets. Area border routers then summarize the area contents
(for distribution to the backbone) by advertising a single route
for each address range. The cost of the route is the minimum
cost to any of the networks falling in the specified range.
For example, an IP subnetted network can be configured as a
single OSPF area. In that case, the area would be defined as a
single address range: a class A, B, or C network number along
with its natural IP mask. Inside the area, any number of
variable sized subnets could be defined. External to the area,
a single route for the entire subnetted network would be
distributed, hiding even the fact that the network is subnetted
at all. The cost of this route is the minimum of the set of
costs to the component subnets.
3.6. Supporting stub areas
In some Autonomous Systems, the majority of the topological
database may consist of AS external advertisements. An OSPF AS
external advertisement is usually flooded throughout the entire
AS. However, OSPF allows certain areas to be configured as
"stub areas". AS external advertisements are not flooded
into/throughout stub areas; routing to AS external destinations
in these areas is based on a (per-area) default only. This
reduces the topological database size, and therefore the memory
requirements, for a stub area"s internal routers.
In order to take advantage of the OSPF stub area support,
default routing must be used in the stub area. This is
accomplished as follows. One or more of the stub area"s area
border routers must advertise a default route into the stub area
via summary link advertisements. These summary defaults are
flooded throughout the stub area, but no further. (For this
reason these defaults pertain only to the particular stub area).
These summary default routes will match any destination that is
not explicitly reachable by an intra-area or inter-area path
(i.e., AS external destinations).
An area can be configured as stub when there is a single exit
point from the area, or when the choice of exit point need not
be made on a per-external-destination basis. For example, Area
3 in Figure 6 could be configured as a stub area, because all
external traffic must travel though its single area border
router RT11. If Area 3 were configured as a stub, Router RT11
would advertise a default route for distribution inside Area 3
(in a summary link advertisement), instead of flooding the AS
external advertisements for Networks N12-N15 into/throughout the
area.
The OSPF protocol ensures that all routers belonging to an area
agree on whether the area has been configured as a stub. This
guarantees that no confusion will arise in the flooding of AS
external advertisements.
There are a couple of restrictions on the use of stub areas.
Virtual links cannot be configured through stub areas. In
addition, AS boundary routers cannot be placed internal to stub
areas.
3.7. Partitions of areas
OSPF does not actively attempt to repair area partitions. When
an area becomes partitioned, each component simply becomes a
separate area. The backbone then performs routing between the
new areas. Some destinations reachable via intra-area routing
before the partition will now require inter-area routing.
In the previous section, an area was described as a list of
address ranges. Any particular address range must still be
completely contained in a single component of the area
partition. This has to do with the way the area contents are
summarized to the backbone. Also, the backbone itself must not
partition. If it does, parts of the Autonomous System will
become unreachable. Backbone partitions can be repaired by
configuring virtual links (see Section 15).
Another way to think about area partitions is to look at the
Autonomous System graph that was introduced in Section 2. Area
IDs can be viewed as colors for the graph"s edges.[1] Each edge
of the graph connects to a