Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1247

OSPF Version 2

Pages: 189
Obsoletes:  1131
Obsoleted by:  1583
Updated by:  1349
Part 1 of 7 – Pages 1 to 23
None   None   Next

ToP   noToC   RFC1247 - Page 1
Network Working Group                                             J. Moy
Request for Comments: 1247                                 Proteon, Inc.
Obsoletes: RFC 1131                                            July 1991

                             OSPF Version 2

Status of this Memo

This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the ``IAB Official Protocol
Standards'' for the standardization state 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 based 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

OSPF recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic.  OSPF provides support
for equal-cost multipath.  Separate routes can be calculated for each IP
type of service.  An area routing capability is provided, enabling an
additional level of routing protection and a reduction in routing
protocol traffic.  In addition, all OSPF routing protocol exchanges are

Version 1 of the OSPF protocol was documented in RFC 1131.  The
differences between the two versions are explained in Appendix F.

Please send comments to

1. Introduction

This document is a specification of the Open Shortest Path First (OSPF)
internet routing protocol.  OSPF is classified as an Internal Gateway
Protocol (IGP).  This means that it distributes routing information
between routers belonging to a single Autonomous System.  The OSPF
protocol is based on SPF or link-state technology.  This is a departure
ToP   noToC   RFC1247 - Page 2
from the Bellman-Ford base used by traditional internet routing

The OSPF protocol was developed by the OSPF working group of the
Internet Engineering Task Force.  It has been designed expressly for the
internet environment, including explicit support for IP subnetting,
TOS-based routing and the tagging of externally-derived routing
information.  OSPF also provides for the authentication of routing
updates, and utilizes IP multicast when sending/receiving the updates.
In addition, much work has been done to produce a protocol that responds
quickly to topology changes, yet involves small amounts of routing
protocol traffic.

The author would like to thank Rob Coltun, Milo Medin, Mike Petry and
the rest of the OSPF working group for the ideas and support they have
given to this project.

1.1 Protocol overview

OSPF routes IP packets based solely on the destination IP address and IP
Type of Service found in the IP packet header.  IP packets are routed
"as is" -- they are not encapsulated in any further protocol headers as
they transit the Autonomous System.  OSPF is a dynamic routing protocol.
It quickly detects topological changes in the AS (such as router
interface failures) and calculates new loop-free routes after a period
of convergence.  This period of convergence is short and involves a
minimum of routing traffic.

In an SPF-based routing protocol, each router maintains a database
describing the Autonomous System's topology.  Each participating router
has an identical database.  Each individual piece of this database is a
particular router's local state (e.g., the router's usable interfaces
and reachable neighbors).  The router distributes its local state
throughout the Autonomous System by flooding.

All routers run the exact same algorithm, in parallel.  From the
topological database, each router constructs a tree of shortest paths
with itself as root.  This shortest-path tree gives the route to each
destination in the Autonomous System.  Externally derived routing
information appears on the tree as leaves.

OSPF calculates separate routes for each Type of Service (TOS).  When
several equal-cost routes to a destination exist, traffic is distributed
equally among them.  The cost of a route is described by a single
dimensionless metric.

OSPF allows sets of networks to be grouped together.  Such a grouping is
ToP   noToC   RFC1247 - Page 3
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

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 subnets.  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"

All OSPF protocol exchanges are authenticated.  This means that only
trusted routers can participate in the Autonomous System's routing.  A
variety of authentication schemes can be used; a single authentication
scheme is configured for each area.  This enables some areas to use much
stricter authentication than others.

Externally derived routing data (e.g., routes learned from the Exterior
Gateway Protocol (EGP)) is passed transparently throughout the
Autonomous System.  This externally derived data is kept separate from
the OSPF protocol's link state data.  Each external route can also be
tagged by the advertising router, enabling the passing of additional
information between routers on the boundaries of the Autonomous System.

1.2 Definitions of commonly used terms

Here is a collection of definitions for terms that have a specific
meaning to the protocol and that are used throughout the text.  The
reader unfamiliar with the Internet Protocol Suite is referred to [RS-
85-153] for an introduction to IP.

    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.

Internal Gateway Protocol
    The routing protocol spoken by the routers belonging to an
    Autonomous system.  Abbreviated as IGP.  Each Autonomous System has
ToP   noToC   RFC1247 - Page 4
    a single IGP.  Different Autonomous Systems may be running different

Router ID
    A 32-bit number assigned to each router running the OSPF protocol.
    This number uniquely identifies the router within an Autonomous

    In this paper, an IP network or subnet.  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.  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

Multi-access networks
    Those physical networks that support the attachment of multiple
    (more than two) routers.  Each pair of routers on such a network is
    assumed to be able to communicate directly (e.g., multi-drop
    networks are excluded).

    The connection between a router and one of its attached networks.
    An interface has state information associated with it, which is
    obtained from the underlying lower level protocols and the routing
    protocol itself.  An interface to a network has associated with it a
    single IP address and mask (unless the network is an unnumbered
    point-to-point network).  An interface is sometimes also referred to
    as a link.

Neighboring routers
    Two routers that have interfaces to a common network.  On multi-
    access networks, neighbors are dynamically discovered by OSPF's
    Hello Protocol.

    A relationship formed between selected neighboring routers for the
    purpose of exchanging routing information.  Not every pair of
    neighboring routers become adjacent.
ToP   noToC   RFC1247 - Page 5
Link state advertisement
    Describes to the local state of a router or network.  This includes
    the state of the router's interfaces and adjacencies.  Each link
    state advertisement is flooded throughout the routing domain.  The
    collected link state advertisements of all routers and networks
    forms the protocol's topological database.

Hello protocol
    The part of the OSPF protocol used to establish and maintain
    neighbor relationships.  On multi-access networks the Hello protocol
    can also dynamically discover neighboring routers.

Designated Router
    Each multi-access network that has at least two attached routers has
    a Designated Router.  The Designated Router generates a link state
    advertisement for the multi-access network and has other special
    responsibilities in the running of the protocol.  The Designated
    Router is elected by the Hello Protocol.

    The Designated Router concept enables a reduction in the number of
    adjacencies required on a multi-access network.  This in turn
    reduces the amount of routing protocol traffic and the size of the
    topological database.

Lower-level protocols
    The underlying network access protocols that provide services to the
    Internet Protocol and in turn the OSPF protocol.  Examples of these
    are the X.25 packet and frame levels for PDNs, and the ethernet data
    link layer for ethernets.

1.3 Brief history of SPF-based routing technology

OSPF is an SPF-based routing protocol.  Such protocols are also referred
to in the literature as link-state or distributed-database protocols.
This section gives a brief description of the developments in SPF-based
technology that have influenced the OSPF protocol.

The first SPF-based routing protocol was developed for use in the
ARPANET packet switching network.  This protocol is described in
[McQuillan].  It has formed the starting point for all other SPF-based
protocols.  The homogeneous Arpanet environment, i.e., single-vendor
packet switches connected by synchronous serial lines, simplified the
design and implementation of the original protocol.

Modifications to this protocol were proposed in [Perlman].  These
modifications dealt with increasing the fault tolerance of the routing
protocol through, among other things, adding a checksum to the link
ToP   noToC   RFC1247 - Page 6
state advertisements (thereby detecting database corruption).  The paper
also included means for reducing the routing traffic overhead in an
SPF-based protocol.  This was accomplished by introducing mechanisms
which enabled the interval between link state advertisements to be
increased by an order of magnitude.

An SPF-based algorithm has also been proposed for use as an ISO IS-IS
routing protocol.  This protocol is described in [DEC].  The protocol
includes methods for data and routing traffic reduction when operating
over broadcast networks.  This is accomplished by election of a
Designated Router for each broadcast network, which then originates a
link state advertisement for the network.

The OSPF subcommittee of the IETF has extended this work in developing
the OSPF protocol.  The Designated Router concept has been greatly
enhanced to further reduce the amount of routing traffic required.
Multicast capabilities are utilized for additional routing bandwidth
reduction.  An area routing scheme has been developed enabling
information hiding/protection/reduction.  Finally, the algorithm has
been modified for efficient operation in the internet environment.

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,
configuration items and required management statistics are specified in
the appendices.

Labels such as HelloInterval encountered in the text refer to protocol
constants.  They may or may not be configurable.  The architectural
constants are explained in Appendix B.  The configurable constants are
explained in Appendix C.

The detailed specification of the protocol is presented in terms of data
structures.  This is done in order to make the explanation more precise.
Implementations of the protocol are required to support the
functionality described, but need not use the precise data structures
that appear in this paper.

2. The Topological Database

The database of the Autonomous System's topology 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
ToP   noToC   RFC1247 - Page 7
indicates that the router has an interface on the network.

The vertices of the graph can be further typed according to function.
Only some of these types carry transit data traffic; that is, traffic
that is neither locally originated nor locally destined.  Vertices that
can carry transit traffic are indicated on the graph by having both
incoming and outgoing edges.

                   Vertex type   Vertex name    Transit?
                   1             Router         yes
                   2             Network        yes
                   3             Stub network   no

                        Table 1: OSPF vertex types.

OSPF supports the following types of physical networks:

Point-to-point networks
    A network that joins a single pair of routers.  A 56Kb serial line
    is an example of a point-to-point network.

Broadcast networks
    Networks supporting many (more than two) attached routers, together
    with the capability to address a single physical message to all of
    the attached routers (broadcast).  Neighboring routers are
    discovered dynamically on these nets using OSPF's Hello Protocol.
    The Hello Protocol itself takes advantage of the broadcast
    capability.  The protocol makes further use of multicast
    capabilities, if they exist.  An ethernet is an example of a
    broadcast network.

Non-broadcast networks
    Networks supporting many (more than two) routers, but having no
    broadcast capability.  Neighboring routers are also discovered on
    these nets using OSPF's Hello Protocol.  However, due to the lack of
    broadcast capability, some configuration information is necessary
    for the correct operation of the Hello Protocol.  On these networks,
    OSPF protocol packets that are normally multicast need to be sent to
    each neighboring router, in turn.  An X.25 Public Data Network (PDN)
    is an example of a non-broadcast network.
ToP   noToC   RFC1247 - Page 8
The neighborhood of each network node in the graph depends on whether
the network has multi-access capabilities (either broadcast or non-
broadcast) and, if so, the number of routers having an interface to the
network.  The three cases are depicted in Figure 1.  Rectangles indicate
routers.  Circles and oblongs indicate multi-access networks.  Router
names are prefixed with the letters RT and network names with N.  Router
interface names are prefixed by I.  Lines between routers indicate
point-to-point networks.  The left side of the figure shows a network
with its connected routers, with the resulting graph shown on the right.

Two routers joined by a point-to-point network are represented in the
directed graph as being directly connected by a pair of edges, one in
each direction.  Interfaces to physical point-to-point networks need not
be assigned IP addresses.  Such a point-to-point network is called
unnumbered.  The graphical representation of point-to-point networks is
designed so that unnumbered networks can be supported naturally.  When
interface addresses exist, they are modelled as stub routes.  Note that
each router would then have a stub connection to the other router's
interface address (see Figure 1).

When multiple routers are attached to a multi-access network, the
directed graph shows all routers bidirectionally connected to the
network vertex (again, see Figure 1).  If only a single router is
attached to a multi-access network, the network will appear in the
directed graph as a stub connection.

Each network (stub or transit) in the graph has an IP address and
associated network mask.  The mask indicates the number of nodes on the
network.  Hosts attached directly to routers (referred to as host
routes) appear on the graph as stub networks.  The network mask for a
host route is always 0xffffffff, which indicates the presence of a
single node.

Figure 2 shows a sample map of an Autonomous System.  The rectangle
labelled H1 indicates a host, which has a SLIP connection to router
RT12.  Router RT12 is therefore advertising a host route.  Lines between


                 (Figure not included in text version.)

                    Figure 1: Network map components
ToP   noToC   RFC1247 - Page 9
routers indicate physical point-to-point networks.  The only point-to-
point network that has been assigned interface addresses is the one
joining routers RT6 and RT10.  Routers RT5 and RT7 have EGP connections
to other Autonomous Systems.  A set of EGP-learned routes have been
displayed for both of these routers.

A cost is associated with the output side of each router interface.
This cost is configurable by the system administrator.  The lower the
cost, the more likely the interface is to be used to forward data
traffic.  Costs are also associated with the externally derived routing
data (e.g., the EGP-learned routes).

The directed graph resulting from the map in Figure 2 is depicted in
Figure 3.  Arcs are labelled with the cost of the corresponding router
output interface.  Arcs having no labelled cost have a cost of 0.  Note
that arcs leading from networks to routers always have cost 0; they are
significant nonetheless.  Note also that the externally derived routing
data appears on the graph as stubs.

The topological database (or what has been referred to above as the
directed graph) is pieced together from link state advertisements
generated by the routers.  The neighborhood of each transit vertex is
represented in a single, separate link state advertisement.  Figure 4
shows graphically the link state representation of the two kinds of
transit vertices: routers and multi-access networks.  Router RT12 has an


                 (Figure not included in text version.)

                  Figure 2: A sample Autonomous System


                (Figures not included in text version.)

                 Figure 3: The resulting directed graph
               Figure 4: Individual link state components
ToP   noToC   RFC1247 - Page 10
interface to two broadcast networks and a SLIP line to a host.  Network
N6 is a broadcast network with three attached routers.  The cost of all
links from network N6 to its attached routers is 0.  Note that the link
state advertisement for network N6 is actually generated by one of the
attached routers: the router that has been elected Designated Router for
the network.

2.1 The shortest-path tree

When no OSPF areas are configured, each router in the Autonomous System
has an identical topological database, leading to an identical graphical
representation.  A router generates its routing table from this graph by
calculating a tree of shortest paths with the router itself as root.
Obviously, the shortest-path tree depends on the router doing the
calculation.  The shortest-path tree for router RT6 in our example is
depicted in Figure 5.

The tree gives the entire route to any destination network or host.
However, only the next hop to the destination is used in the forwarding
process.  Note also that the best route to any router has also been
calculated.  For the processing of external data, we note the next hop
and distance to any router advertising external routes.  The resulting
routing table for router RT6 is pictured in Table 2.  Note that there is
a separate route for each end of a numbered serial line (in this case,
the serial line between routers RT6 and RT10).

Routes to networks belonging to other AS'es (such as N12) appear as
dashed lines on the shortest path tree in Figure 5.  Use of this
externally derived routing information is considered in the next


                 (Figure not included in text version.)

                 Figure 5: The SPF tree for router RT6
ToP   noToC   RFC1247 - Page 11
                   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

2.2 Use of external routing information

After the tree is created the external routing information is examined.
This external routing information may originate from another routing
protocol such as EGP, or be statically configured (static routes).
Default routes can also be included as part of the Autonomous System's
external routing information.

External routing information is flooded unaltered throughout the AS.  In
our example, all the routers in the Autonomous System know that router
RT7 has two external routes, with metrics 2 and 9.

OSPF supports two types of external metrics.  Type 1 external metrics
are equivalent to the link state metric.  Type 2 external metrics are
greater than the cost of any path internal to the AS.  Use of Type 2
external metrics assumes that routing between AS'es is the major cost of
routing a packet, and eliminates the need for conversion of external
costs to internal link state metrics.

Here is an example of Type 1 external metric processing.  Suppose that
the routers RT7 and RT5 in Figure 2 are advertising Type 1 external
metrics.  For each external route, the distance from Router RT6 is
calculated as the sum of the external route's cost and the distance from
ToP   noToC   RFC1247 - Page 12
Router RT6 to the advertising router.  For every external destination,
the router advertising the shortest route is discovered, and the next
hop to the advertising router becomes the next hop to the destination.

Both Router RT5 and RT7 are advertising an external route to destination
network N12.  Router RT7 is preferred since it is advertising N12 at a
distance of 10 (8+2) to Router RT6, which is better than router RT5's 14
(6+8).  Table 3 shows the entries that are added to the routing table
when external routes are examined:

                     Destination   Next  Hop   Distance
                     N12           RT10        10
                     N13           RT5         14
                     N14           RT5         14
                     N15           RT10        17

    Table 3: The portion of router RT6's routing table listing external

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

This section has assumed that packets destined for external destinations
are always routed through the advertising AS boundary router.  This is
not always desirable.  For example, suppose in Figure 2 there is an
additional router attached to network N6, called Router RTX.  Suppose
further that RTX does not participate in OSPF routing, but does exchange
EGP information with the AS boundary router RT7.  Then, router RT7 would
end up advertising OSPF external routes for all destinations that should
be routed to RTX.  An extra hop will sometimes be introduced if packets
for these destinations need always be routed first to router RT7 (the
advertising router).

To deal with this situation, the OSPF protocol allows an AS boundary
ToP   noToC   RFC1247 - Page 13
router to specify a "forwarding address" in its external advertisements.
In the above example, Router RT7 would specify RTX's IP address as the
"forwarding address" for all those destinations whose packets should be
routed directly to RTX.

The "forwarding address" has one other application.  It enables routers
in the Autonomous System's interior to function as "route servers".  For
example, in Figure 2 the router RT6 could become a route server, gaining
external routing information through a combination of static
configuration and external routing protocols.  RT6 would then start
advertising itself as an AS boundary router, and would originate a
collection of OSPF external advertisements.  In each external
advertisement, router RT6 would specify the correct Autonomous System
exit point to use for the destination through appropriate setting of the
advertisement's "forwarding address" field.

2.3 Equal-cost multipath

The above discussion has been simplified by considering only a single
route to any destination.  In reality, if multiple equal-cost routes to
a destination exist, they are all discovered and used.  This requires no
conceptual changes to the algorithm, and its discussion is postponed
until we consider the tree-building process in more detail.

With equal cost multipath, a router potentially has several available
next hops towards any given destination.

2.4 TOS-based routing

OSPF can calculate a separate set of routes for each IP Type of Service.
The IP TOS values are represented in OSPF exactly as they appear in the
IP packet header.  This means that, for any destination, there can
potentially be multiple routing table entries, one for each IP TOS.

Up to this point, all examples shown have assumed that routes do not
vary on TOS.  In order to differentiate routes based on TOS, separate
interface costs can be configured for each TOS.  For example, in Figure
2 there could be multiple costs (one for each TOS) listed for each
interface.  A cost for TOS 0 must always be specified.

When interface costs vary based on TOS, a separate shortest path tree is
calculated for each TOS (see Section 2.1).  In addition, external costs
can vary based on TOS.  For example, in Figure 2 router RT7 could
advertise a separate type 1 external metric for each TOS.  Then, when
calculating the TOS X distance to network N15 the cost of the shortest
TOS X path to RT7 would be added to the TOS X cost advertised by RT7
ToP   noToC   RFC1247 - Page 14
(see Section 2.2).

All OSPF implementations must be capable of calculating routes based on
TOS.  However, OSPF routers can be configured to route all packets on
the TOS 0 path (see Appendix C), eliminating the need to calculate non-
zero TOS paths.  This can be used to conserve routing table space and
processing resources in the router.  These TOS-0-only routers can be
mixed with routers that do route based on TOS.  TOS-0-only routers will
be avoided as much as possible when forwarding traffic requesting a
non-zero TOS.

It may be the case that no path exists for some non-zero TOS, even if
the router is calculating non-zero TOS paths.  In that case, packets
requesting that non-zero TOS are routed along the TOS 0 path (see
Section 11.1).

3. Splitting the AS into Areas

OSPF allows collections of contiguous networks and hosts to be grouped
together.  Such a group, together with the routers having interfaces to
any one of the included networks, is called an area.  Each area runs a
separate copy of the basic SPF routing algorithm.  This means that each
area has its own topological database and corresponding graph, as
explained in the previous section.

The topology of an area is invisible from the outside of the area.
Conversely, routers internal to a given area know nothing of the
detailed topology external to the area.  This isolation of knowledge
enables the protocol to effect a marked reduction in routing traffic as
compared to treating the entire Autonomous System as a single SPF

With the introduction of areas, it is no longer true that all routers in
the AS have an identical topological database.  A router actually has a
separate topological database for each area it is connected to.
(Routers connected to multiple areas are called area border routers).
Two routers belonging to the same area have, for that area, identical
area topological databases.

Routing in the Autonomous System takes place on two levels, depending on
whether the source and destination of a packet reside in the same area
(intra-area routing is used) or different areas (inter-area routing is
used).  In intra-area routing, the packet is routed solely on
information obtained within the area; no routing information obtained
from outside the area can be used.  This protects intra-area routing
from the injection of bad routing information.  We discuss inter-area
routing in Section 3.2.
ToP   noToC   RFC1247 - Page 15
3.1 The backbone of the Autonomous System

The backbone consists of those networks not contained in any area, their
attached routers, and those routers that belong to multiple areas.  The
backbone must be contiguous.

It is possible to define areas in such a way that the backbone is no
longer contiguous.  In this case the system administrator must restore
backbone connectivity by configuring virtual links.

Virtual links can be configured between any two backbone routers that
have an interface to a common non-backbone area.  Virtual links belong
to the backbone.  The protocol treats two routers joined by a virtual
link as if they were connected by an unnumbered point-to-point network.
On the graph of the backbone, two such routers are joined by arcs whose
costs are the intra-area distances between the two routers.  The routing
protocol traffic that flows along the virtual link uses intra-area
routing only.

The backbone is responsible for distributing routing information between
areas.  The backbone itself has all of the properties of an area.  The
topology of the backbone is invisible to each of the areas, while the
backbone itself knows nothing of the topology of the areas.

3.2 Inter-area routing

When routing a packet between two areas the backbone is used.  The path
that the packet will travel can be broken up into three contiguous
pieces: an intra-area path from the source to an area border router, a
backbone path between the source and destination areas, and then another
intra-area path to the destination.  The algorithm finds the set of such
paths that have the smallest cost.

Looking at this another way, inter-area routing can be pictured as
forcing a star configuration on the Autonomous System, with the backbone
as hub and and each of the areas as spokes.

The topology of the backbone dictates the backbone paths used between
areas.  The topology of the backbone can be enhanced by adding virtual
links.  This gives the system administrator some control over the routes
taken by inter-area traffic.

The correct area border router to use as the packet exits the source
area is chosen in exactly the same way routers advertising external
routes are chosen.  Each area border router in an area summarizes for
the area its cost to all networks external to the area.  After the SPF
tree is calculated for the area, routes to all other networks are
ToP   noToC   RFC1247 - Page 16
calculated by examining the summaries of the area border routers.

3.3 Classification of routers

Before the introduction of areas, the only OSPF routers having a
specialized function were those advertising external routing
information, such as router RT5 in Figure 2.  When the AS is split into
OSPF areas, the routers are further divided according to function into
the following four overlapping categories:

Internal routers
    A router with all directly connected networks belonging to the same
    area.  Routers with only backbone interfaces also belong to this
    category.  These routers run a single copy of the basic routing

Area border routers
    A router that attaches to multiple areas.  Area border routers run
    multiple copies of the basic algorithm, one copy for each attached
    area and an additional copy for the backbone.  Area border routers
    condense the topological information of their attached areas for
    distribution to the backbone.  The backbone in turn distributes the
    information to the other areas.

Backbone routers
    A router that has an interface to the backbone.  This includes all
    routers that interface to more than one area (i.e., area border
    routers).  However, backbone routers do not have to be area border
    routers.  Routers with all interfaces connected to the backbone are
    considered to be internal routers.

AS boundary routers
    A router that exchanges routing information with routers belonging
    to other Autonomous Systems.  Such a router has AS external routes
    that are advertised throughout the Autonomous System.  The path to
    each AS boundary router is known by every router in the AS.  This
    classification is completely independent of the previous
    classifications: AS boundary routers may be internal or area border
    routers, and may or may not participate in the backbone.

3.4 A sample area configuration

Figure 6 shows a sample area configuration.  The first area consists of
networks N1-N4, along with their attached routers RT1-RT4.  The second
area consists of networks N6-N8, along with their attached routers RT7,
ToP   noToC   RFC1247 - Page 17
RT8, RT10, RT11.  The third area consists of networks N9-N11 and host
H1, along with their attached routers RT9, RT11, RT12.  The third area
has been configured so that networks N9-N11 and host H1 will all be
grouped into a single route, when advertised external to the area (see
Section 3.5 for more details).

In Figure 6, routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal
routers.  Routers RT3, RT4, RT7, RT10 and RT11 are area border routers.
Finally as before, routers RT5 and RT7 are AS boundary routers.

Figure 7 shows the resulting topological database for the Area 1.  The
figure completely describes that area's intra-area routing.  It also
shows the complete view of the internet for the two internal routers RT1
and RT2.  It is the job of the area border routers, RT3 and RT4, to
advertise into Area 1 the distances to all destinations external to the
area.  These are indicated in Figure 7 by the dashed stub routes.  Also,
RT3 and RT4 must advertise into Area 1 the location of the AS boundary
routers RT5 and RT7.  Finally, external advertisements from RT5 and RT7
are flooded throughout the entire AS, and in particular throughout Area
1.  These advertisements are included in Area 1's database, and yield
routes to networks N12-N15.

Routers RT3 and RT4 must also summarize Area 1's topology for
distribution to the backbone.  Their backbone advertisements are shown
in Table 4.  These summaries show which networks are contained in Area 1
(i.e., networks N1-N4), and the distance to these networks from the
routers RT3 and RT4 respectively.

The topological database for the backbone is shown in Figure 8.  The set
of routers pictured are the backbone routers.  Router RT11 is a backbone
router because it belongs to two areas.  In order to make the backbone
connected, a virtual link has been configured between routers R10 and


                 (Figure not included in text version.)

               Figure 6: A sample OSPF area configuration
ToP   noToC   RFC1247 - Page 18
                     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.


                 (Figure not included in text version.)

                      Figure 7: Area 1's Database
                    Figure 8: The backbone database

Again, routers RT3, RT4, RT7, RT10 and RT11 are area border routers.  As
routers RT3 and RT4 did above, they have condensed the routing
information of their attached areas for distribution via the backbone;
these are the dashed stubs that appear in Figure 8.  Remember that the
third area has been configured to condense networks N9-N11 and Host H1
into a single route.  This yields a single dashed line for networks N9-
N11 and Host H1 in Figure 8.  Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on the graph
in Figure 8 as stubs.

The backbone enables the exchange of summary information between area
border routers.  Every area border router hears the area summaries from
all other area border routers.  It then forms a picture of the distance
to all networks outside of its area by examining the collected
advertisements, and adding in the backbone distance to each advertising

Again using routers RT3 and RT4 as an example, the procedure goes as
follows: They first calculate the SPF tree for the backbone.  This gives
the distances to all other area border routers.  Also noted are the
distances to networks (Ia and Ib) and AS boundary routers (RT5 and RT7)
that belong to the backbone.  This calculation is shown in Table 5.

Next, by looking at the area summaries from these area border routers,
RT3 and RT4 can determine the distance to all networks outside their
ToP   noToC   RFC1247 - Page 19
                 Area  border   dist  from   dist  from
                 router         RT3          RT4
                 to  RT3        *            21
                 to  RT4        22           *
                 to  RT7        20           14
                 to  RT10       15           22
                 to  RT11       18           25
                 to  Ia         20           27
                 to  Ib         15           22
                 to  RT5        14           8
                 to  RT7        20           14

     Table 5: Backbone distances calculated by routers RT3 and RT4.

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 I5 and I6 into a
single advertisement.

The information imported into Area 1 by routers RT3 and RT4 enables an
internal router, such as RT1, to choose an area border router
intelligently.  Router RT1 would use RT4 for traffic to network N6, RT3
for traffic to network N10, and would load share between the two for

                   Destination   RT3 adv.   RT4 adv.
                   Ia,Ib         15         22
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     19         26
                   RT5           14         8
                   RT7           20         14

  Table 6: Destinations advertised into Area 1 by routers RT3 and RT4.
ToP   noToC   RFC1247 - Page 20
traffic to network N8.

Router RT1 can also determine in this manner the shortest path to the AS
boundary routers RT5 and RT7.  Then, by looking at RT5 and RT7's
external advertisements, router RT1 can decide between RT5 or RT7 when
sending to a destination in another Autonomous System (one of the
networks N12-N15).

Note that a failure of the line between routers RT6 and RT10 will cause
the backbone to become disconnected.  Configuring another virtual link
between routers RT7 and RT10 will give the backbone more connectivity
and more resistance to such failures.  Also, a virtual link between RT7
and RT10 would allow a much shorter path between the third area
(containing N9) and the router RT7, which is advertising a good route to
external network N12.

3.5 IP subnetting support

OSPF attaches an IP address mask to each advertised route.  The mask
indicates the range of addresses being described by the particular
route.  For example, a summary advertisement for the destination with a mask of 0xffff0000 actually is describing a single
route to the collection of destinations -
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 subnet
masks.  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 could be broken up into 64 variable-sized subnets:
16 subnets of size 4K, 16 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
          0xfffff000        4K
           0xffffff00        256
           0xfffffff8        8

                     Table 7: Some sample subnet sizes.
ToP   noToC   RFC1247 - Page 21
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.  The specification however
establishes the following guideline: When an IP packet is forwarded, it
is always forwarded to the network that is the best match for the
packet's destination.  Here best match is synonymous with the longest or
most specific match.  For example, the default route with destination of 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

The OSPF area concept is modelled after an IP subnetted network.  OSPF
areas have been loosely defined to be a collection of networks.  In
actuality, an OSPF area is specified to be a list of address ranges (see
Section C.2 for more details).  Each address range is defined as an
[address,mask] pair.  Many separate networks may then be contained in a
single address range, just as a subnetted network is composed of many
separate subnets.  Area border routers then summarize the area contents
(for distribution to the backbone) by advertising a single route for
each address range.  The cost of the route is the minimum cost to any of
the networks falling in the specified range.

For example, an IP subnetted network can be configured as a single OSPF
area.  In that case, the area would be defined as a single address
range: a class A, B, or C network number along with its natural IP mask.
Inside the area, any number of variable sized subnets could be defined.
External to the area, a single route for the entire subnetted network
would be distributed, hiding even the fact that the network is subnetted
at all.  The cost of this route is the minimum of the set of costs to
the component subnets.

3.6 Supporting stub areas

In some Autonomous Systems, the majority of the topological database may
consist of external advertisements.  An OSPF external advertisement is
usually flooded throughout the entire AS.  However, OSPF allows certain
areas to be configured as "stub areas".  External advertisements are not
flooded into/throughout stub areas; routing to AS external destinations
in these areas is based on a (per-area) default only.  This reduces the
topological database size, and therefore the memory requirements, for a
stub area's internal routers.

In order to take advantage of the OSPF stub area support, default
routing must be used in the stub area.  This is accomplished as follows.
One or more of the stub area's area border routers must advertise a
default route into the stub area via summary advertisements.  These
ToP   noToC   RFC1247 - Page 22
summary defaults are flooded throughout the stub area, but no further.
(For this reason these defaults pertain only to the particular stub
area).  These summary default routes will match any destination that is
not explicitly reachable by an intra-area or inter-area path (i.e., AS
external destinations).

An area can be configured as stub when there is a single exit point from
the area, or when the choice of exit point need not be made on a per-
external-destination basis.  For example, area 3 in Figure 6 could be
configured as a stub area, because all external traffic must travel
though its single area border router RT11.  If area 3 were configured as
a stub, router RT11 would advertise a default route for distribution
inside area 3 (in a summary advertisement), instead of flooding the
external advertisements for networks N12-N15 into/throughout the area.

The OSPF protocol ensures that all routers belonging to an area agree on
whether the area has been configured as a stub.  This guarantees that no
confusion will arise in the flooding of external advertisements.

There are a couple of restrictions on the use of stub areas.  Virtual
links cannot be configured through stub areas.  In addition, AS boundary
routers cannot be placed internal to stub areas.

3.7 Partitions of areas

OSPF does not actively attempt to repair area partitions.  When an area
becomes partitioned, each component simply becomes a separate area.  The
backbone then performs routing between the new areas.  Some destinations
reachable via intra-area routing before the partition will now require
inter-area routing.

In the previous section, an area was described as a list of address
ranges.  Any particular address range must still be completely contained
in a single component of the area partition.  This has to do with the
way the area contents are summarized to the backbone.  Also, the
backbone itself must not partition.  If it does, parts of the Autonomous
System will become unreachable.  Backbone partitions can be repaired by
configuring virtual links (see Section 15).

Another way to think about area partitions is to look at the Autonomous
System graph that was introduced in Section 2.  Area IDs can be viewed
as colors for the graph's edges.[1] Each edge of the graph connects to a
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
ToP   noToC   RFC1247 - Page 23
is intact, the graph will have several regions of color, each color
being a distinct Area ID.

When the AS topology changes, one of the areas may become partitioned.
The graph of the AS will then have multiple regions of the same color
(Area ID).  The routing in the Autonomous System will continue to
function as long as these regions of same color are connected by the
single backbone region.

(next page on part 2)

Next Section