RFC 1587 (rfc1587) - Page 3 of 17

The OSPF NSSA Option

RFC 1587                    OSPF NSSA Option                  March 1994


             4. The cloud can become, logically, a part of the transit
                network's OSPF routing system.

             5. Translated type-5 LSAs that are sent into the
                backbone from the cloud (which is a separate
                stub area) may be considered "leaf" nodes
                when performing the Dijkstra calculation.

   However, the current definition of the OSPF protocol [1] imposes
   topological limitations which restrict simple cloud topologies from
   becoming OSPF stub areas.  In particular, it is illegal for a stub
   area to import routes external to OSPF; it is not possible for
   routers BR18 and BR10 to both be members of the stub area and to
   import the routes learned from RIP or other IP routing protocols as
   type-5 (OSPF external LSAs) into the OSPF system.  In order to run
   OSPF out to BR18, BR18 must be a member of a non-stub area or the
   OSPF backbone to import routes other than its directly-connected
   network(s).  Since it is not acceptable for BR18 to maintain all of
   BARRNet's external (type-5) routes, BARRNet is forced by OSPF's
   topological limitations to run OSPF out to BR10 and to run RIP
   between BR18 and BR10.

2.2 Proposed Solution

   This document describes a new optional type of OSPF area, somewhat
   humorously referred to as a "not-so-stubby" area (or NSSA) which has
   the capability of importing external routes in a limited fashion.

   The OSPF specification defines two general classes of area
   configuration.  The first allows type-5 LSAs to be flooded throughout
   the area.  In this configuration, type-5 LSAs may be originated by
   routers internal to the area or flooded into the area by area border
   routers.  These areas, referred to herein as type-5 capable areas (or
   just plain areas in the OSPF spec), are distinguished by the fact
   that they can carry transit traffic.  The backbone is always a type-5
   capable area.  The second type of area configuration, called stub,
   allows no type-5 LSAs to be propagated into/throughout the area and
   instead depends on default routing to external destinations.

   NSSAs are defined in much the same manner as existing stub areas.  To
   support NSSAs, a new option bit (the "N" bit) and a new type of LSA
   (type-7) area defined.  The "N" bit ensures that routers belonging to
   an NSSA agree on its configuration.  Similar to the stub area's use
   of the "E" bit, both NSSA neighbors must agree on the setting of the
   "N" bit or the OSPF neighbor adjacency will not form.

   Type-7 LSAs provide for carrying external route information within an
   NSSA.  Type-7 AS External LSAs have virtually the same syntax as the



Coltun & Fuller