RFC 1587 (rfc1587) - Page 2 of 17
The OSPF NSSA Option
Alternative Format: Original Text Document
RFC 1587 OSPF NSSA Option March 1994
2.0 Overview
2.1 Motivation
Wide-area transit networks (such as the NSFNET regionals) often have
connections to moderately-complex "leaf" sites. A leaf site may have
multiple IP network numbers assigned to it.
Typically, one of the leaf site's networks is directly connected to a
router provided and administered by the transit network while the
others are distributed throughout and administered by the site. From
the transit network's perspective, all of the network numbers
associated with the site make up a single "stub" entity. For
example, BARRNet has one site composed of a class-B network,
130.57.0.0, and a class-C network, 192.31.114.0. From BARRNet's
perspective, this configuration looks something like this:
192.31.114
|
(cloud)
-------------- 130.57.4
|
|
------ 131.119.13 ------
|BR18|------------|BR10|
------ ------
|
V
to BARRNet "core" OSPF system
where the "cloud" consists of the subnets of 130.57 and network
192.31.114, all of which are learned by RIP on router BR18.
Topologically, this cloud looks very much like an OSPF stub area.
The advantages of running the cloud as an OSPF stub area are:
1. Type-5 routes (OSPF external link-state advertisements
(LSAs)) are not advertised beyond the router
labeled "BR10". This is advantageous because the
link between BR10 and BR18 may be a low-speed link
or the router BR18 may have limited resources.
2. The transit network is abstracted to the "leaf"
router BR18 by advertising only a default route
across the link between BR10 and BR18.
3. The cloud becomes a single, manageable "leaf" with
respect to the transit network.
Coltun & Fuller
