As per Relevance of the word designated, we have this rfc below:
Network Working Group J.
Request for Comments: 2178 Cascade Communications Corp
Obsoletes: 1583 July 1997
Category: Standards
OSPF Version 2
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo documents version 2 of the OSPF protocol. OSPF is a link
state routing protocol. It is designed to be run internal to
single Autonomous System. Each OSPF router maintains an
database describing the Autonomous System's topology. From
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
support for equal-cost multipath. An area routing capability
provided, enabling an additional level of routing protection and
reduction in routing protocol traffic. In addition, all OSPF
protocol exchanges are authenticated
The differences between this memo and RFC 1583 are explained
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
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.
This document is a specification of the Open Shortest Path
(OSPF) TCP/IP internet routing protocol. OSPF is classified as
Interior Gateway Protocol (IGP). This means that it
routing information between routers belonging to a single
System. The OSPF protocol is based on link-state or SPF technology
This is a departure from the Bellman-Ford base used by
TCP/IP internet routing protocols
The OSPF protocol was developed by the OSPF working group of
Internet Engineering Task Force. It has been designed expressly
the TCP/IP internet environment, including explicit support for
and the tagging of externally-derived routing information. OSPF
provides for the authentication of routing updates, and utilizes
multicast when sending/receiving the updates. In addition, much
has been done to produce a protocol that responds quickly to
changes, yet involves small amounts of routing protocol traffic
1.1. Protocol
OSPF routes IP packets based solely on the destination IP
found in the IP packet header. IP packets are routed "as is" --
are not encapsulated in any further protocol headers as they
the Autonomous System. OSPF is a dynamic routing protocol.
quickly detects topological changes in the AS (such as
interface failures) and calculates new loop-free routes after
period of convergence. This period of convergence is short
involves a minimum of routing traffic
In a link-state routing protocol, each router maintains a
describing the Autonomous System's topology. This database
referred to as the link-state database. Each participating router
an identical database. Each individual piece of this database is
particular router's local state (e.g., the router's usable
and reachable neighbors). The router distributes its local
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
link-state database, each router constructs a tree of shortest
with itself as root. This shortest-path tree gives the route to
destination in the Autonomous System. Externally derived
information appears on the tree as leaves
When several equal-cost routes to a destination exist, traffic
distributed equally among them. The cost of a route is described
a single dimensionless metric
OSPF allows sets of networks to be grouped together. Such a
is called an area. The topology of an area is hidden from the
of the Autonomous System. This information hiding enables
significant reduction in routing traffic. Also, routing within
area is determined only by the area's own topology, lending the
protection from bad routing data. An area is a generalization of
IP subnetted network
OSPF enables the flexible configuration of IP subnets. Each
distributed by OSPF has a destination and mask. Two
subnets of the same IP network number may have different sizes (i.e.,
different masks). This is commonly referred to as variable
subnetting. A packet is routed to the best (i.e., longest or
specific) match. Host routes are considered to be subnets
masks are "all ones" (0xffffffff).
All OSPF protocol exchanges are authenticated. This means that
trusted routers can participate in the Autonomous System's routing
A variety of authentication schemes can be used; in fact,
authentication schemes can be configured for each IP subnet
Externally derived routing data (e.g., routes learned from
Exterior Gateway Protocol such as BGP; see [Ref23]) is
throughout the Autonomous System. This externally derived data
kept separate from the OSPF protocol's link state data.
external route can also be tagged by the advertising router,
the passing of additional information between routers on the
of the Autonomous System
1.2. Definitions of commonly used
This section provides definitions for terms that have a
meaning to the OSPF protocol and that are used throughout the text
The reader unfamiliar with the Internet Protocol Suite is referred
[Ref13] for an introduction to IP
Moy Standards Track [Page 6]
RFC 2178 OSPF Version 2 July 1997
A level three Internet Protocol packet switch. Formerly called
gateway in much of the IP literature
Autonomous
A group of routers exchanging routing information via a
routing protocol. Abbreviated as AS
Interior Gateway
The routing protocol spoken by the routers belonging to
Autonomous system. Abbreviated as IGP. Each Autonomous System
a single IGP. Separate Autonomous Systems may be
different IGPs
Router
A 32-bit number assigned to each router running the OSPF protocol
This number uniquely identifies the router within an
System
In this memo, an IP network/subnet/supernet. It is possible
one physical network to be assigned multiple IP network/
numbers. We consider these to be separate networks. Point-to
point physical networks are an exception - they are considered
single network no matter how many (if any at all)
network/subnet numbers are assigned to them
Network
A 32-bit number indicating the range of IP addresses residing on
single IP network/subnet/supernet. This specification
network masks as hexadecimal numbers. For example, the
mask for a class C IP network is displayed as 0xffffff00. Such
mask is often displayed elsewhere in the literature
255.255.255.0.
Point-to-point
A network that joins a single pair of routers. A 56Kb serial
is an example of a point-to-point network
Moy Standards Track [Page 7]
RFC 2178 OSPF Version 2 July 1997
Broadcast
Networks supporting many (more than two) attached routers
together with the capability to address a single physical
to all of the attached routers (broadcast). Neighboring
are discovered dynamically on these nets using OSPF's
Protocol. The Hello Protocol itself takes advantage of
broadcast capability. The OSPF protocol makes further use
multicast capabilities, if they exist. Each pair of routers on
broadcast network is assumed to be able to communicate directly
An ethernet is an example of a broadcast network
Non-broadcast
Networks supporting many (more than two) routers, but having
broadcast capability. Neighboring routers are maintained on
nets using OSPF's Hello Protocol. However, due to the lack
broadcast capability, some configuration information may
necessary to aid in the discovery of neighbors. On non-
networks, OSPF protocol packets that are normally multicast
to be sent to each neighboring router, in turn. An X.25
Data Network (PDN) is an example of a non-broadcast network
OSPF runs in one of two modes over non-broadcast networks.
first mode, called non-broadcast multi-access or NBMA,
the operation of OSPF on a broadcast network. The second mode
called Point-to-MultiPoint, treats the non-broadcast network as
collection of point-to-point links. Non-broadcast networks
referred to as NBMA networks or Point-to-MultiPoint networks
depending on OSPF's mode of operation over the network
The connection between a router and one of its attached networks
An interface has state information associated with it, which
obtained from the underlying lower level protocols and the
protocol itself. An interface to a network has associated with
a single IP address and mask (unless the network is an
point-to-point network). An interface is sometimes also
to as a link
Neighboring
Two routers that have interfaces to a common network.
relationships are maintained by, and usually
discovered by, OSPF's Hello Protocol
A relationship formed between selected neighboring routers for
purpose of exchanging routing information. Not every pair
neighboring routers become adjacent
Moy Standards Track [Page 8]
RFC 2178 OSPF Version 2 July 1997
Link state
Unit of data describing the local state of a router or network
For a router, this includes the state of the router's
and adjacencies. Each link state advertisement is
throughout the routing domain. The collected link
advertisements of all routers and networks forms the protocol'
link state database. Throughout this memo, link
advertisement is abbreviated as LSA
Hello
The part of the OSPF protocol used to establish and
neighbor relationships. On broadcast networks the Hello
can also dynamically discover neighboring routers
The part of the OSPF protocol that distributes and
the link-state database between OSPF routers
Designated
Each broadcast and NBMA network that has at least two
routers has a Designated Router. The Designated Router
an LSA for the network and has other special responsibilities
the running of the protocol. The Designated Router is elected
the Hello Protocol
The Designated Router concept enables a reduction in the number
adjacencies required on a broadcast or NBMA network. This in
reduces the amount of routing protocol traffic and the size of
link-state database
Lower-level
The underlying network access protocols that provide services
the Internet Protocol and in turn the OSPF protocol. Examples
these are the X.25 packet and frame levels for X.25 PDNs, and
ethernet data link layer for ethernets
1.3. Brief history of link-state routing
OSPF is a link state routing protocol. Such protocols are
referred to in the literature as SPF-based or distributed-
protocols. This section gives a brief description of
developments in link-state technology that have influenced the
protocol
The first link-state routing protocol was developed for use in
ARPANET packet switching network. This protocol is described
[Ref3]. It has formed the starting point for all other link-
protocols. The homogeneous ARPANET environment, i.e., single-
Moy Standards Track [Page 9]
RFC 2178 OSPF Version 2 July 1997
packet switches connected by synchronous serial lines, simplified
design and implementation of the original protocol
Modifications to this protocol were proposed in [Ref4].
modifications dealt with increasing the fault tolerance of
routing protocol through, among other things, adding a checksum
the LSAs (thereby detecting database corruption). The paper
included means for reducing the routing traffic overhead in a link
state protocol. This was accomplished by introducing
which enabled the interval between LSA originations to be
by an order of magnitude
A link-state algorithm has also been proposed for use as an ISO IS-
routing protocol. This protocol is described in [Ref2].
protocol includes methods for data and routing traffic reduction
operating over broadcast networks. This is accomplished by
of a Designated Router for each broadcast network, which
originates an LSA for the network
The OSPF Working Group of the IETF has extended this work
developing the OSPF protocol. The Designated Router concept has
greatly enhanced to further reduce the amount of routing
required. Multicast capabilities are utilized for additional
bandwidth reduction. An area routing scheme has been
enabling information hiding/protection/reduction. Finally,
algorithms have been tailored for efficient operation in TCP/
internets
1.4. Organization of this
The first three sections of this specification give a
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
appendices
Labels such as HelloInterval encountered in the text refer
protocol constants. They may or may not be configurable
Architectural constants are summarized in Appendix B.
constants are summarized in Appendix C
The detailed specification of the protocol is presented in terms
data structures. This is done in order to make the explanation
precise. Implementations of the protocol are required to support
functionality described, but need not use the precise data
that appear in this memo
Moy Standards Track [Page 10]
RFC 2178 OSPF Version 2 July 1997
1.5.
The author would like to thank Ran Atkinson, Fred Baker,
Burgan, Rob Coltun, Dino Farinacci, Vince Fuller,
Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui
and the rest of the OSPF Working Group for the ideas and support
have given to this project
The OSPF Point-to-MultiPoint interface is based on work done by
Baker
The OSPF Cryptographic Authentication option was developed by
Baker and Ran Atkinson
2. The Link-state Database: organization and
The following subsections describe the organization of OSPF's link
state database, and the routing calculations that are performed
the database in order to produce a router's routing table
2.1. Representation of routers and
The Autonomous System's link-state database describes a
graph. The vertices of the graph consist of routers and networks.
graph edge connects two routers when they are attached via a
point-to-point network. An edge connecting a router to a
indicates that the router has an interface on the network.
can be either transit or stub networks. Transit networks are
capable of carrying data traffic that is neither locally
nor locally destined. A transit network is represented by a
vertex having both incoming and outgoing edges. A stub network'
vertex has only incoming edges
The neighborhood of each network node in the graph depends on
network's type (point-to-point, broadcast, NBMA or Point-to
MultiPoint) and the number of routers having an interface to
network. Three cases are depicted in Figure 1a. Rectangles
routers. Circles and oblongs indicate networks. Router names
prefixed with the letters RT and network names with the letter N
Router interface names are prefixed by the letter I. Lines
routers indicate point-to-point networks. The left side of
figure shows networks with their connected routers, with
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
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
Stub
+---+ +---+
|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
Figure 1a: Network map
Networks and routers are represented by vertices. An edge
Vertex A to Vertex B iff the intersection of Column A and Row B
marked with an X
The top of Figure 1a shows two routers connected by a point-to-
link. In the resulting link-state database graph, the two
vertices are directly connected by a pair of edges, one in
direction. Interfaces to point-to-point networks need not be
IP addresses. When interface addresses are assigned, they
modelled as stub links, with each router advertising a
connection to the other router's interface address. Optionally, an
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
advertising each others' IP interface addresses
The middle of Figure 1a shows a network with only one attached
(i.e., a stub network). In this case, the network appears on the
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
the network vertex. This is pictured at the bottom of Figure 1a
Each network (stub or transit) in the graph has an IP address
associated network mask. The mask indicates the number of nodes
the network. Hosts attached directly to routers (referred to as
routes) appear on the graph as stub networks. The network mask for
host route is always 0xffffffff, which indicates the presence of
single node
2.1.1. Representation of non-broadcast
As mentioned previously, OSPF can run over non-broadcast networks
one of two modes: NBMA or Point-to-MultiPoint. The choice of
determines the way that the Hello protocol and flooding work over
non-broadcast network, and the way that the network is represented
the link-state database
In NBMA mode, OSPF emulates operation over a broadcast network:
Designated Router is elected for the NBMA network, and the
Router originates an LSA for the network. The graph
for broadcast networks and NBMA networks is identical.
representation is pictured in the middle of Figure 1a
NBMA mode is the most efficient way to run OSPF over non-
networks, both in terms of link-state database size and in terms
the amount of routing protocol traffic. However, it has
significant restriction: it requires all routers attached to the
network to be able to communicate directly. This restriction may
met on some non-broadcast networks, such as an ATM subnet
SVCs. But it is often not met on other non-broadcast networks,
as PVC-only Frame Relay networks. On non-broadcast networks where
all routers can communicate directly you can break the non-
network into logical subnets, with the routers on each subnet
able to communicate directly, and then run each separate subnet as
NBMA network (see [Ref15]). This however requires quite a bit
administrative overhead, and is prone to misconfiguration. It
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-
connections over the non-broadcast network as if they were point-to
point links. No Designated Router is elected for the network, nor
there an LSA generated for the network. In fact, a vertex for
Point-to-MultiPoint network does not appear in the graph of
link-state database
Figure 1b illustrates the link-state database representation of
Point-to-MultiPoint network. On the left side of the figure,
Point-to-MultiPoint network is pictured. It is assumed that
routers can communicate directly, except for routers RT4 and RT5. I
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
Point-to-MultiPoint network are joined by bidirectional edges,
each router also has a stub connection to its own IP
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
data-link protocols such as Inverse ARP (see [Ref14]) will
autodiscovery of OSPF neighbors even though broadcast support is
available
2.1.2. An example link-state
Figure 2 shows a sample map of an Autonomous System. The
labelled H1 indicates a host, which has a SLIP connection to
RT12. Router RT12 is therefore advertising a host route.
between routers indicate physical point-to-point networks. The
point-to-point network that has been assigned interface addresses
the one joining Routers RT6 and RT10. Routers RT5 and RT7 have
connections to other Autonomous Systems. A set of BGP-learned
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
cost,the more likely the interface is to be used to forward
traffic. Costs are also associated with the externally
routing data (e.g., the BGP-learned routes).
The directed graph resulting from the map in Figure 2 is depicted
Figure 3. Arcs are labelled with the cost of the
router output interface. Arcs having no labelled cost have a cost
0. Note that arcs leading from networks to routers always have
0; they are significant nonetheless. Note also that the
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
Point-to-MultiPoint
All routers can communicate directly over N2,
routers RT4 and RT5. I3 through I6 indicate
interface
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 N
Figure 2: A sample Autonomous
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
Networks and routers are represented by vertices
An edge of cost X connects Vertex A to Vertex B
the intersection of Column A and Row B is
with an X
The link-state database is pieced together from LSAs generated by
routers. In the associated graphical representation,
neighborhood of each router or transit network is represented in
single, separate LSA. Figure 4 shows these LSAs graphically.
RT12 has an interface to two broadcast networks and a SLIP line to
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
network's attached routers: the router that has been
Designated Router for the network
2.2. The shortest-path
When no OSPF areas are configured, each router in the
System has an identical link-state database, leading to an
graphical representation. A router generates its routing table
this graph by calculating a tree of shortest paths with the
itself as root. Obviously, the shortest- path tree depends on
router doing the calculation. The shortest-path tree for Router RT
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
forwarding process. Note also that the best route to any router
also been calculated. For the processing of external data, we
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
point-to-point network (in this case, the serial line between
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-
Figure 4: Individual link state
Networks and routers are represented by vertices
An edge of cost X connects Vertex A to Vertex B
the intersection of Column A and Row B is
with an X
Moy Standards Track [Page 18]
RFC 2178 OSPF Version 2 July 1997
RT6(origin
RT5 o------------o-----------o
/|\ 6 |\ 7
8/8|8\ | \
/ | \ 6| \
o | o | \7
N12 o N14 | \
N13 2 | \
N4 o-----o RT3 \
/ \ 5
1/ RT10 o-------o
/ |\
RT4 o-----o N3 3| \1
/| | \ N6 RT
/ | N8 o o---------
/ | | | /|
RT2 o o RT1 | | 2/ |9
/ | | |RT8 / |
/3 |3 RT11 o o o
/ | | | N12 N15
N2 o o N1 1| |4
| |
N9 o o N
/|
/ |
N11 RT9 / |RT12
o--------o-------o o--------o H
3 | 10
|2
|
o N10
Figure 5: The SPF tree for Router RT
Edges that are not marked with a cost have a cost of of zero (
are network-to-router links). Routes to networks N12-N15 are
information that is considered in Section 2.3
Moy Standards Track [Page 19]
RFC 2178 OSPF Version 2 July 1997
Destination Next Hop
__________________________________
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
destinations
Routes to networks belonging to other AS'es (such as N12) appear
dashed lines on the shortest path tree in Figure 5. Use of
externally derived routing information is considered in the
section
2.3. Use of external routing
After the tree is created the external routing information
examined. This external routing information may originate
another routing protocol such as BGP, or be statically
(static routes). Default routes can also be included as part of
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
Router RT7 has two external routes, with metrics 2 and 9.
OSPF supports two types of external metrics. Type 1 external
are expressed in the same units as OSPF interface cost (i.e.,
terms of the link state metric). Type 2 external metrics are
order of magnitude larger; any Type 2 metric is considered
than the cost of any path internal to the AS. Use of Type 2
metrics assumes that routing between AS'es is the major cost
routing a packet, and eliminates the need for conversion of
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
Routers RT7 and RT5 in Figure 2 are advertising Type 1
metrics. For each advertised external route, the total cost
Router RT6 is calculated as the sum of the external route'
advertised cost and the distance from Router RT6 to the
router. When two routers are advertising the same
destination, RT6 picks the advertising router providing the
total cost. RT6 then sets the next hop to the external
equal to the next hop that would be used when routing packets to
chosen advertising router
In Figure 2, both Router RT5 and RT7 are advertising an
route to destination Network N12. Router RT7 is preferred since
is advertising N12 at a distance of 10 (8+2) to Router RT6, which
better than Router RT5's 14 (6+8). Table 3 shows the entries
are added to the routing table when external routes are examined
Destination Next Hop
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
Table 3: The portion of Router RT6's routing
listing external destinations
Processing of Type 2 external metrics is simpler. The AS
router advertising the smallest external metric is chosen,
of the internal distance to the AS boundary router. Suppose in
example both Router RT5 and Router RT7 were advertising Type 2
external routes. Then all traffic destined for Network N12 would
forwarded to Router RT7, since 2 < 8. When several equal-cost Type 2
routes exist, the internal distance to the advertising routers
used to break the tie
Both Type 1 and Type 2 external metrics can be present in the AS
the same time. In that event, Type 1 external metrics always
precedence
This section has assumed that packets destined for
destinations are always routed through the advertising AS
router. This is not always desirable. For example, suppose
Figure 2 there is an additional router attached to Network N6,
Router RTX. Suppose further that RTX does not participate in
Moy Standards Track [Page 21]
RFC 2178 OSPF Version 2 July 1997
routing, but does exchange BGP information with the AS
router RT7. Then, Router RT7 would end up advertising OSPF
routes for all destinations that should be routed to RTX. An
hop will sometimes be introduced if packets for these
need always be routed first to Router RT7 (the advertising router).
To deal with this situation, the OSPF protocol allows an AS
router to specify a "forwarding address" in its AS- external-LSAs.
the above example, Router RT7 would specify RTX's IP address as
"forwarding address" for all those destinations whose packets
be routed directly to RTX
The "forwarding address" has one other application. It
routers in the Autonomous System's interior to function as "
servers". For example, in Figure 2 the router RT6 could become
route server, gaining external routing information through
combination of static configuration and external routing protocols
RT6 would then start advertising itself as an AS boundary router,
would originate a collection of OSPF AS-external-LSAs. In each AS
external-LSA, Router RT6 would specify the correct Autonomous
exit point to use for the destination through appropriate setting
the LSA's "forwarding address" field
2.4. Equal-cost
The above discussion has been simplified by considering only a
route to any destination. In reality, if multiple equal-cost
to a destination exist, they are all discovered and used.
requires no conceptual changes to the algorithm, and its
is postponed until we consider the tree-building process in
detail
With equal cost multipath, a router potentially has several
next hops towards any given destination
3. Splitting the AS into
OSPF allows collections of contiguous networks and hosts to
grouped together. Such a group, together with the routers
interfaces to any one of the included networks, is called an area
Each area runs a separate copy of the basic link-state
algorithm. This means that each area has its own link-state
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
detailed topology external to the area. This isolation of
enables the protocol to effect a marked reduction in routing
Moy Standards Track [Page 22]
RFC 2178 OSPF Version 2 July 1997
as compared to treating the entire Autonomous System as a
link-state domain
With the introduction of areas, it is no longer true that all
in the AS have an identical link-state database. A router
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,
area link-state databases
Routing in the Autonomous System takes place on two levels,
on whether the source and destination of a packet reside in the
area (intra-area routing is used) or different areas (inter-
routing is used). In intra-area routing, the packet is routed
on information obtained within the area; no routing
obtained from outside the area can be used. This protects intra-
routing from the injection of bad routing information. We
inter-area routing in Section 3.2.
3.1. The backbone of the Autonomous
The OSPF backbone is the special OSPF Area 0 (often written as
0.0.0.0, since OSPF Area ID's are typically formatted as
addresses). The OSPF backbone always contains all area
routers. The backbone is responsible for distributing
information between non-backbone areas. The backbone must
contiguous. However, it need not be physically contiguous;
connectivity can be established/maintained through the
of virtual links
Virtual links can be configured between any two backbone routers
have an interface to a common non-backbone area. Virtual
belong to the backbone. The protocol treats two routers joined by
virtual link as if they were connected by an unnumbered point-to
point backbone network. On the graph of the backbone, two
routers are joined by arcs whose costs are the intra-area
between the two routers. The routing protocol traffic that
along the virtual link uses intra-area routing only
3.2. Inter-area
When routing a packet between two non-backbone areas the backbone
used. The path that the packet will travel can be broken up
three contiguous pieces: an intra-area path from the source to
area border router, a backbone path between the source
destination areas, and then another intra-area path to
destination. The algorithm finds the set of such paths that have
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
backbone as hub and each of the non-backbone areas as spokes
The topology of the backbone dictates the backbone paths used
areas. The topology of the backbone can be enhanced by
virtual links. This gives the system administrator some control
the routes taken by inter-area traffic
The correct area border router to use as the packet exits the
area is chosen in exactly the same way routers advertising
routes are chosen. Each area border router in an area summarizes
the area its cost to all networks external to the area. After
SPF tree is calculated for the area, routes to all inter-
destinations are calculated by examining the summaries of the
border routers
3.3. Classification of
Before the introduction of areas, the only OSPF routers having
specialized function were those advertising external
information, such as Router RT5 in Figure 2. When the AS is
into OSPF areas, the routers are further divided according
function into the following four overlapping categories
Internal
A router with all directly connected networks belonging to
same area. These routers run a single copy of the basic
algorithm
Area border
A router that attaches to multiple areas. Area border routers
multiple copies of the basic algorithm, one copy for each
area. Area border routers condense the topological information
their attached areas for distribution to the backbone.
backbone in turn distributes the information to the other areas
Backbone
A router that has an interface to the backbone area.
includes all routers that interface to more than one area (i.e.,
area border routers). However, backbone routers do not have to
area border routers. Routers with all interfaces connecting
the backbone area are supported
Moy Standards Track [Page 24]
RFC 2178 OSPF Version 2 July 1997
AS boundary
A router that exchanges routing information with routers
to other Autonomous Systems. Such a router advertises AS
routing information throughout the Autonomous System. The
to each AS boundary router are known by every router in the AS
This classification is completely independent of the
classifications: AS boundary routers may be internal or
border routers, and may or may not participate in the backbone
3.4. A sample area
Figure 6 shows a sample area configuration. The first area
of networks N1-N4, along with their attached routers RT1-RT4.
second area consists of networks N6-N8, along with their
routers RT7, RT8, RT10 and RT11. The third area consists of
N9-N11 and Host H1, along with their attached routers RT9, RT11
RT12. The third area has been configured so that networks N9-N11
Host H1 will all be grouped into a single route, when
external to the area (see Section 3.5 for more details).
In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12
internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are
border routers. Finally, as before, Routers RT5 and RT7 are
boundary routers
Figure 7 shows the resulting link-state database for the Area 1.
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
Moy Standards Track [Page 26]
RFC 2178 OSPF Version 2 July 1997
It also shows the complete view of the internet for the two
routers RT1 and RT2. It is the job of the area border routers, RT
and RT4, to advertise into Area 1 the distances to all
external to the area. These are indicated in Figure 7 by the
stub routes. Also, RT3 and RT4 must advertise into Area 1
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
1's database, and yield routes to Networks N12-N15.
Routers RT3 and RT4 must also summarize Area 1's topology
distribution to the backbone. Their backbone LSAs are shown in
4. These summaries show which networks are contained in Area 1
(i.e., Networks N1-N4), and the distance to these networks from
routers RT3 and RT4 respectively
The link-state database for the backbone is shown in Figure 8.
set of routers pictured are the backbone routers. Router RT11 is
backbone router because it belongs to two areas. In order to
the backbone connected, a virtual link has been configured
Routers R10 and R11.
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
routing information of their attached non-backbone areas
distribution via the backbone; these are the dashed stubs that
in Figure 8. Remember that the third area has been configured
condense Networks N9-N11 and Host H1 into a single route.
yields a single dashed line for networks N9-N11 and Host H1 in
8. Routers RT5 and RT7 are AS boundary routers; their
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
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
the intersection of Column A and Row B is
with an X
Moy Standards Track [Page 28]
RFC 2178 OSPF Version 2 July 1997
**FROM**
|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 b