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