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
