OSPF Protocol Analysis
RFC 1245

Document Type RFC - Informational (July 1991; No errata)
Last updated 2013-03-02
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf ps htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1245 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                     J. Moy, Editor
Request for Comments: 1245                                 Proteon, Inc.
                                                               July 1991

                         OSPF protocol analysis

Status of this Memo

This memo provides information for the Internet community. It does not
specify any Internet standard. Distribution of this memo is unlimited.
Please send comments to ospf@trantor.umd.edu.


This is the first of two reports on the OSPF protocol. These reports are
required by the IAB/ IESG in order for an Internet routing protocol to
advance to Draft Standard Status. OSPF is a TCP/IP routing protocol,
designed to be used internal to an Autonomous System (in other words,
OSPF is an Interior Gateway Protocol).

Version 1 of the OSPF protocol was published in RFC 1131. Since then
OSPF version 2 has been developed. Version 2 has been documented in RFC
1247.  The changes between version 1 and version 2 of the OSPF protocol
are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is
the subject of this report.

This report attempts to summarize the key features of OSPF V2. It also
attempts to analyze how the protocol will perform and scale in the

1.0  Introduction

This document addresses, for OSPF V2, the requirements set forth by the
IAB/IESG for an Internet routing protocol to advance to Draft Standard
state. This requirements are briefly summarized below. The remaining
sections of this report document how OSPF V2 satisfies these

o  What are the key features and algorithms of the protocol?

o  How much link bandwidth, router memory and router CPU cycles does the
   protocol consume under normal conditions?

o  For these metrics, how does the usage scale as the routing
   environment grows? This should include topologies at least an order

[Moy]                                                           [Page 1]
RFC 1245                 OSPF protocol analysis                July 1991

   of magnitude larger than the current environment.

o  What are the limits of the protocol for these metrics? (I.e., when
   will the routing protocol break?)

o  For what environments is the protocol well suited, and for what is it
   not suitable?

1.1  Acknowledgments

The OSPF protocol has been developed by the OSPF Working Group of the
Internet Engineering Task Force.

2.0  Key features of the OSPF protocol

This section summarizes the key features of the OSPF protocol. OSPF is
an Internal gateway protocol; it is designed to be used internal to a
single Autonomous System. OSPF uses link-state or SPF-based technology
(as compared to the distance-vector or Bellman-Ford technology found in
routing protocols such as RIP). Individual link state advertisements
(LSAs) describe pieces of the OSPF routing domain (Autonomous System).
These LSAs are flooded throughout the routing domain, forming the link
state database. Each router has an identical link state database;
synchronization of link state databases is maintained via a reliable
flooding algorithm. From this link state database, each router builds a
routing table by calculating a shortest-path tree, with the root of the
tree being the calculating router itself. This calculation is commonly
referred to as the Dijkstra procedure.

Link state advertisements are small. Each advertisement describes a
small pieces of the OSPF routing domain, namely either: the neighborhood
of a single router, the neighborhood of a single transit network, a
single inter-area route (see below) or a single external route.

The other key features of the OSPF protocol are:

o  Adjacency bringup. Certain pairs of OSPF routers become "adjacent".
   As an adjacency is formed, the two routers synchronize their link
   state databases by exchanging database summaries in the form of OSPF
   Database Exchange packets. Adjacent routers then maintain syn-
   chronization of their link state databases through the reliable
   flooding algorithm. Routers connected by serial lines always become
   adjacent. On multi-access networks (e.g., ethernets or X.25 PDNs),
   all routers attached to the network become adjacent to both the
   Designated Router and the Backup Designated router.

o  Designated router. A Designated Router is elected on all multi-access
   networks (e.g., ethernets or X.25 PDNs). The network's Designated

[Moy]                                                           [Page 2]
RFC 1245                 OSPF protocol analysis                July 1991

   Router originates the network LSA describing the network's local
   environment. It also plays a special role in the flooding algorithm,
   since all routers on the network are synchronizing their link state
   databases by sending and receiving LSAs to/from the Designated Router
   during the flooding process.

o  Backup Designated Router. A Backup Designated Router is elected on
   multi-access networks to speed/ease the transition of Designated
Show full document text