Skip to main content

The OSPF NSSA Option
draft-ietf-ospf-nssa-option-00

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 1587.
Authors Rob Coltun , Vince Fuller
Last updated 2013-03-02 (Latest revision 1992-12-09)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 1587 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ospf-nssa-option-00
-------------------------------------------------------------------------------

   Internet Draft            OSPF NSSA Option                  October 1992
   Expiration Date: April 1993

                           The OSPF NSSA Option

                                Rob Coltun
                                Consultant
                              (301) 340-9416
                            rcoltun@ni.umd.edu

                               Vince Fuller
                                  BARRNet
                            Stanford University
                               Pine Hall 115
                         Stanford, CA, 94305-4122
                         vaf@Valinor.Stanford.EDU

     Status of this Memo

          This document is an Internet Draft. Internet Drafts  are  working
          documents  of  the  Internet  Engineering  Task Force (IETF), its
          Areas, and its Working Groups. Note that other  groups  may  also
          distribute working documents as Internet Drafts).

          Internet Drafts are draft documents valid for a  maximum  of  six
          months. Internet Drafts may be updated, replaced, or obsoleted by
          other documents at any time. It is not appropriate to use  Inter-
          net  Drafts as reference material or to cite them other than as a
          "working draft" or "work in progress."

          Please check the I-D abstract listing contained in each  Internet
          Draft  directory to learn the current status of this or any other
          Internet Draft.

   Coltun & Fuller                                                 [Page 1]

   Internet Draft            OSPF NSSA Option                  October 1992

     Table Of Contents

          1.0 Abstract ................................................. 2
          2.0 Overview ................................................. 2
          2.1 Motivation ............................................... 2
          2.2 Proposed Solution ........................................ 3
          3.0 Implementation Details ................................... 5
          3.1 The N-bit ................................................ 5
          3.2 Type-7 LSAs .............................................. 5
          3.3 Originating Type-7 LSAs .................................. 6
          3.4 Calculating Type-7 AS External Routes .................... 7
          3.5 Incremental Updates ...................................... 9
          4.0 Originating Type-5 LSAs .................................. 9
          4.1 Translating Type-7 LSAs .................................. 9
          4.2 Flushing Translated Type-7 LSAs .......................... 10
          5.0 Acknowledgements ......................................... 10
          6.0 References ............................................... 10
          Appendix A: Type-7 LSA Packet Format ......................... 11
          Appendix B: The Options Field ................................ 11
          Appendix C: Configuration Parameters ......................... 12

     1.0  Abstract

          This document describes a new optional type of OSPF  area,  some-
          what  humorously referred to as a "not-so-stubby" area (or NSSA).
          NSSAs are similar to the existing OSPF  stub  area  configuration
          option  but have the additional capability of importing AS exter-
          nal routes in a limited fashion.

     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:

   Coltun & Fuller                                                 [Page 2]

   Internet Draft            OSPF NSSA Option                  October 1992

                    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 advertise-
                ments (LSAs)) are not advertised into the cloud
                utilizing less resources in the (perhaps limited)
                cloud's routers.

             2. The transit network is abstracted to the cloud
                by advertising a default route into the cloud.

             3. The cloud becomes a single manageable entity to the
                transit network.

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

          However, the current  definition  of  the  OSPF  protocol  [OSPF]
          imposes topological limitations which restrict simple cloud topo-
          logies from becoming OSPF stub areas.  In particular, it is ille-
          gal  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 rout-
          ing protocols as type-5 (OSPF external LSAs) into the  OSPF  sys-
          tem.   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,  some-
          what  humorously  referred to as a "not-so-stubby" area (or NSSA)
          which has the capability of importing external routes in  a  lim-
          ited fashion.

   Coltun & Fuller                                                 [Page 3]

   Internet Draft            OSPF NSSA Option                  October 1992

          The OSPF specification defines two general classes of area confi-
          guration.   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  capa-
          ble  areas  (or  just  plain  areas  in  the OSPF spec), are dis-
          tinguished 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 pro-
          pagated  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 Type-5 AS External LSAs with the obvious  exception
          of  the link-state type (see section 3.2 for more details). There
          are two major semantic  differences  between  type-5  and  type-7
          LSAs.

          o  Type-7 LSAs may be originated by and advertised
             throughout an NSSA; as with stub areas, NSSA's do not
             receive or originate type-5 LSAs.

          o  Type-7 LSAs are advertised only within a single NSSA;
             they are not flooded into the backbone area or any
             other area by border routers, though the information
             which they contain can be propagated into the backbone
             area (see section 3.6).

          In order to allow limited exchange of external information across
          an  NSSA area border, NSSA border routers will translate selected
          type-7 LSAs received from  the  NSSA  into  type-5  LSAs.   These
          type-5  LSAs  will  be  flooded  to all type-5 capable areas.  In
          addition, an NSSA area border  router  can  originate  a  default
          type-7  LSA  (IP address of 0.0.0.0) into the NSSA (note that the
          default route originated by an NSSA area border router  is  never
          translated  into  a type-5 LSA).  As with stub areas and the sum-
          mary default route, default routes are necessary because NSSAs do
          not  receive  full  routing information and therefore must have a
          default route to route to AS-external destinations.  As with stub
          areas,  NSSAs  may  be connected to the backbone at more than one
          area border router, but may not be used as a transit area.

          It should be noted that  unlike  stub  areas,  all  OSPF  summary
          routes  (type-3  LSAs)  must  be  imported into NSSAs. This is to
          ensure that OSPF internal routes  are  always  chosen  over  OSPF

   Coltun & Fuller                                                 [Page 4]

   Internet Draft            OSPF NSSA Option                  October 1992

          external (type-7) routes.

          In our  example  topology  the  subnets  of  130.57  and  network
          192.31.114,  will  still be learned by RIP on router BR18 but now
          both BR10 and BR18 can be in an NSSA and all of BARRNets external
          routes  are  hidden  from  BR18; BR10 becomes an NSSA area border
          router and BR18 becomes an AS boundary  router  internal  to  the
          NSSA.   BR18  will  import  the  subnets  of  130.57  and network
          192.31.114 as type-7 LSAs into the  NSSA.  BR10  then  translates
          these  routes  into  type-5  LSAs  and floods them into BARRNet's
          backbone.

     3.0  Implementation Details

     3.1  The N-bit

          The N-bit ensures that all members of a NSSA agree on the  area's
          configuration.    Together,   the  N-bit  and  E-bit  reflect  an
          interface's (and consequently the interface's associated  area's)
          external  LSA  flooding capability.  As explained in section 10.5
          of the  OSPF  specification,  if  type-5  LSAs  are  not  flooded
          into/throughout  the  area, the E-bit must be clear in the option
          field of the received Hello packets. Interfaces  associated  with
          an  NSSA  will  not send or receive type-5 LSAs on that interface
          but may send and receive type-7 LSAs.  Therefore, if the N-bit is
          set in the options field, the E-bit must be cleared.

          To support the NSSA option an additional check must  be  made  in
          the  function  that handles receiving Hello packet to verify that
          both the N-bit and the E-bit found in the Hello  packet's  option
          field match the value of the options that have been configured in
          the receiving interface.  A mismatch in the options  causes  pro-
          cessing of the received Hello packet to stop and the packet to be
          dropped.

     3.2  Type-7 LSAs: NSSA External Link-State Advertisements

          External routes are imported into NSSAs as  type-7  LSAs  by  the
          NSSA's  AS boundary routers.  That is, type-7 LSAs are originated
          by the NSSA's AS boundary routers that have an interface  associ-
          ated  with  the  NSSA and are exchanging routing information with
          routers belonging to another AS (or importing static routes).  As
          with  type-5  LSAs a separate LSA is originated for each destina-
          tion network.  The link-state database must therefore be expanded
          to contain a type-7 LSA.

          Type 7-LSAs are identical to type-5 LSAs except for the following
          (see  section  12.3.4  "AS external links" in the OSPF specifica-
          tion).
                  1. The type field in the LSA header is 7.

                  2. Type-7 LSAs are only flooded within the NSSA.
                     The flooding of type-7 LSAs follow the same rules

   Coltun & Fuller                                                 [Page 5]

   Internet Draft            OSPF NSSA Option                  October 1992

                     as the flooding of type 1-4 LSAs.

                  3. Type-7 LSAs are kept within the NSSA's LSDB (are area
                     specific) whereas because type-5 LSAs are flooded to
                     all type-5 capable areas, type-5 LSAs have global scope
                     in the router's LSDB.

                  4. At the area border router, selected type-7 LSAs are
                     translated into type 5-LSAs and flooded into the
                     backbone.

                  5. Type 7 LSAs have a  propagate (P) bit which is
                     used to flag the area border router to translate the
                     type-7 LSA into a type-5 LSA. Examples of how the P-bit
                     is used for loop avoidance are in the following sections.

                  6. Those type-7 LSAs that are to be translated into type-5
                     LSAs must have their forwarding address set;
                     all type-5 LSAs that have been translated from type-7 LSAs
                     must contain a forwarding address.
                     The forwarding address contained in type-5 LSAs will
                     result in more efficient routing to the AS external
                     networks when there are multiple NSSA area
                     border routers. Having the forwarding address in the
                     type-7 LSAs will ease the translation of type-7 into
                     type-5 LSAs as the NSSA area border router will
                     not be required to compute the forwarding address.

                     If the network between the NSSA AS boundary router and the
                     adjacent AS is advertised into OSPF as an internal OSPF
                     route, the forwarding address should be the next hop
                     address as is currently done in type-5 LSAs, but unlike
                     type-5 LSAs if the intervening network is not advertised
                     into OSPF as an internal OSPF route, the forwarding
                     address should be any one of the router's active OSPF
                     interface addresses.

          Type-5 and type-7 metrics and path types are directly comparable.

     3.3  Originating Type-7 LSAs

          NSSA AS boundary routers may originate  type-7  LSAs.   All  NSSA
          area  border  routers must also be AS boundary routers since they
          all must have the capability of translating a type-7 LSAs into  a
          type-5  LSAs  (see  section  3.6 routes for the translation algo-
          rithm).  NSSA area border routers must set  the  E-bit  (external
          bit)  as  well  as  the B-bit (border bit) in its router (type-1)
          LSA.

          When an NSSA internal AS boundary router originates a type-7  LSA
          that it wants to be translated into a type-5 LSA by the NSSA area
          border router (and subsequently flooded into  the  backbone),  it
          must  set  the  P-bit  in  the LS header's option field and add a
          valid forwarding address in the type-7 LSA.

   Coltun & Fuller                                                 [Page 6]

   Internet Draft            OSPF NSSA Option                  October 1992

          If a router is attached to another AS and is also  an  NSSA  area
          border  router, it may originate a both a type-5 and a type-7 LSA
          for the same network.  The type-5 LSA  will  be  flooded  to  the
          backbone  (and  all attached type-5 capable areas) and the type-7
          will be flooded into the NSSA.  If this is the  case,  the  P-bit
          must  be  reset  in the type-7 NSSA so the type-7 LSA isn't again
          translated into a type-5 LSA by another NSSA area border router.

          A type-7 default route (network 0.0.0.0) may be  originated  into
          the  NSSA by an NSSA area border router or by an NSSA AS boundary
          router which is internal to the NSSA.  The type-7  default  route
          originated  by  the  NSSA  area border router must have the P-bit
          reset so that the default  route  originated  by  the  NSSA  area
          border router will not find its way out of the NSSA into the rest
          of the AS system via another NSSA area border router.  The type-7
          default  originated by an NSSA AS boundary router which is inter-
          nal to the NSSA may have the P-bit set.  Type-7 routes which  are
          originated  by  the NSSA area border router will not get added to
          other NSSA area border router's routing table.

          A default route must not be injected into the NSSA as  a  summary
          (type-3)  LSA  as  in the stub area case.  The reason for this is
          that the preferred summary default route would be chosen over all
          more specific type-7 route.  Because summary routes are preferred
          to external routes and to ensure that summary routes  are  chosen
          over  external  within  the NSSA, all summary routes (unlike stub
          areas in which this is optional) must be imported into an NSSA.

     3.4 Calculating Type-7 AS External Routes

          This section is very similar  to  section  16.4  (Calculating  AS
          external  routes) in the OSPF specification.  An NSSA area border
          router should examine both type-5 LSAs and type-7 LSAs if  either
          type-5  or  type-7 routes need to be updated.  Type-7 LSAs should
          be examined after type-5 LSAs.  An NSSA  internal  router  should
          examine type-7 LSAs when type-7 routes need to be recalculated.

          In relation to the  steps  to  calculate  the  routing  table  as
          presented  in the OSPF specification (chapter 16, "Calculation of
          the Routing Table"), type-7 LSAs should be examined after step  5
          where the routes to external destinations are calculated.

          Type-7 routes are calculated by examining type-7  LSAs.  Each  of
          LSAs  are considered in turn. Most type-7 LSAs describe routes to
          specific IP destinations.  A  type-7  LSA  can  also  describe  a
          default  route  for  the NSSA (destination = DefaultDestination).
          For each type-7 LSA:

               1. If the metric specified by the LSA is LSInfinity, the
                  age of the LSA equals MaxAge or the advertising router
                  field is equal to this router's router ID, examine the
                  next advertisement.

               2. Call the destination described by the LSA N. Look up the

   Coltun & Fuller                                                 [Page 7]

   Internet Draft            OSPF NSSA Option                  October 1992

                  routing table entry for the AS boundary router (ASBR) that
                  originated the LSA. If no entry exists for the ASBR
                  (i.e., ASBR is unreachable), do nothing with this LSA and
                  consider the next in the list.

                  If the destination is the default route (destination =
                  DefaultDestination) and if the originator of the LSA and
                  the calculating router are both NSSA are border routers
                  do nothing with this LSA and consider the next in the list.

                  Else, this LSA describes an AS external path to destination
                  N. If the forwarding address (as specified in the forwarding
                  address field of the LSA) is 0.0.0.0, the packets routed
                  to the external destination N will be routed to the
                  originating ASBR. If the forwarding address is not 0.0.0.0,
                  look up the forwarding address in the routing table. Packets
                  routed to the external destination N will be routed within
                  the NSSA to the this forwarding address. An intra-area path
                  must therefore exist to the forwarding address. If no such
                  path exists, do nothing with the LSA and consider the next
                  in the list.

                  Call the routing table distance to the forwarding address
                  (or the distance to the originating ASBR if the forwarding
                  address is 0.0.0.0) X, and the cost specified in the type-7
                  LSA Y. X is in terms of the link-state metric, and Y is a
                  Type-1 or external metric.

               3. Now, look up the routing table entry for the destination
                  N. If no entries exist for N, install the AS external path
                  to N, with the next hop equal to the list of next hops to
                  the forwarding address/ASBR, and the advertising router equal
                  to ASBR. If the external metric type is 1, then the
                  path-type is set to Type-1 external and the cost is equal
                  to X + Y. If the external metric type is 2, the path-type
                  is set to Type-2 external, the link-state component of the
                  route's cost is X, and the Type-2 cost is Y.

               4. Else, if the paths present in the table are not Type-1 or
                  Type-2 external paths, do nothing (AS external paths have
                  the lowest priority).

               5. Otherwise, compare the cost of this new AS external path
                  to the ones present in the table. Note that type-5 and
                  type-7 routes are directly comparable. Type-1 external
                  paths are always shorter than Type-2 external paths.
                  Type-1 external paths are compared by looking at the sum
                  of the distance to the forwarding address/ASBR and the
                  advertised Type-1 paths (X+Y). Type-2 external paths are
                  compared by looking at the advertised Type-2 metrics,
                  and then if necessary, the distance to the forwarding
                  address/ASBR.
                  When a type-5 LSA and a type-7 LSA are found to have the
                  same type and an equal distance, the following priorities

   Coltun & Fuller                                                 [Page 8]

   Internet Draft            OSPF NSSA Option                  October 1992

                  apply (listed from highest to lowest) for breaking the tie.
                        a. Any type 5 LSA.
                        b. A type-7 LSA with the P-bit set and the forwarding
                           address non-zero.
                        c. Any other type-7 LSA.

                  If the new path is shorter, it replaces the present paths
                  in the routing table entry. If the new path is the same
                  cost, it is added to the routing table entry's list of
                  paths.

     3.5 Incremental Updates

          Incremental updates for type-7 LSAs should be treated the same as
          incremental updates for type-5 LSAs (see section 16.6 of the OSPF
          specification).  That is, if a new instance of a  type-7  LSA  is
          received  it  is  not necessary to recalculate the entire routing
          table. If there is already an OSPF internal route to the destina-
          tion  represented  by  the type-7 LSA, no recalculation is neces-
          sary. Otherwise, the procedure in  the  proceeding  section  will
          have to be performed but only for the external routes (type-5 and
          type-7) whose networks describe the same networks  as  the  newly
          received LSA.

     4.0 Originating Type-5 LSAs

     4.1 Translating Type-7 LSAs Into Type-5 LSAs

          This step is performed as part of the NSSA's Dijkstra calculation
          after type-5 and type-7 routes have been calculated.  If the cal-
          culating router is not an area  border  router  this  translation
          algorithm  should  be skipped.  All reachable area border routers
          in the NSSA should now  be  examined  noting  the  one  with  the
          highest  router ID.  If this router has the highest router ID, it
          will be the one translating type-7 LSAs into type-5 LSAs for  the
          NSSA,  otherwise  the  translation  algorithm  should not be per-
          formed.

          All type-7 routes that have  been  added  to  the  routing  table
          should  be examined.  If the type-7 LSA being examined has the P-
          bit set and a non-zero forwarding address a  new  instance  of  a
          type-5  LSA  should  be  originated  and  flooded to all attached
          type-5 capable areas if one of the following is true.

               1. There currently is no type-5 LSA originated from this
                  router corresponding to the type-7 LSA.

               2. The path type or the metric in the corresponding
                  type-5 LSA is different from the type-7 LSA.

               3. The forwarding address in the corresponding
                  type-5 LSA is different from the type-7 LSA.

   Coltun & Fuller                                                 [Page 9]

   Internet Draft            OSPF NSSA Option                  October 1992

          The newly originated type-5 LSAs will describe the  same  network
          and  have the same network mask, metrics, forwarding address, and
          external route tag as the  type-7  LSA.  The  advertising  router
          field will be the router ID of this area border router.

     4.2 Flushing Translated Type-7 LSAs

          If an NSSA area border router has translated a type-7  LSA  to  a
          type-5  LSA  that  should no longer be translated, the type-5 LSA
          should be flushed (set to MaxAge and  flooded).   The  translated
          type-5  LSA  should  be  flushed whenever the routing table entry
          that caused the translation changes so that  either  the  routing
          table entry is unreachable or the entry's associated LSA is not a
          type-7 with the P-bit set and a non-zero forwarding address.

     5.0 Acknowledgements

          This document was produced by the OSPF Working Group, chaired  by
          John Moy.

          In addition, the comments of the following individuals  are  also
          acknowledged:
                  Phani Jajjarvarpu  cisco
                  Dino Farinacci     cisco
                  Jeff Honig         Cornell University
                  John Moy           Proteon, Inc.
                  Doug Williams      IBM

     6.0 References

             [OSPF]    Moy, J. OSPF Version 2. RFC 1247. July 1991.
             [MOSPF]   Moy, J. Multicast Extensions to OSPF.
                       Internet Draft. September 1992.

   Coltun & Fuller                                                [Page 10]

   Internet Draft            OSPF NSSA Option                  October 1992

     Appendix A: Type-7 Packet Format

                   0                                32
                   -----------------------------------
                   |                | OPTS   |   7   |
                   |                ------------------
                   |        Link-State Header        |
                   |                                 |
                   -----------------------------------
                   | Network Mask                    |
                   -----------------------------------  ______
                   |E| Tos  |        metric          |  .
                   -----------------------------------  .  repeated for each TOS
                   | Forwarding Address              |  .
                   -----------------------------------  .
                   | External Route Tag              |  ______
                   -----------------------------------

          The definitions of the link-state ID, network mask,  metrics  and
          external route tag are the same as the definitions for the type-5
          LSAs (see A.4.5 in the OSPF specification) except for:

               The Forwarding Address
          If the network between the NSSA AS boundary router and the  adja-
          cent  AS  is  advertised into OSPF as an internal OSPF route, the
          forwarding address should be the next  hop  address  but  if  the
          intervening  network  is  not advertised into OSPF as an internal
          OSPF route, the forwarding address  should  be  any  one  of  the
          router's active OSPF interface addresses.

     Appendix B: The Options Field

          The OSPF options field is present in OSPF Hello packets, Database
          Description packets and all link-state advertisements. See appen-
          dix A.2 in the OSPF specification for  a  description  of  option
          field.

                   ------------------------------------
                   | * | * | * | * | N/P | MC | E | T |
                   ------------------------------------

                       The Type-7 LSA options field

             T-bit:  The T-bit describes the router's TOS capability.

             E-bit:  Type-5 AS external link advertisements are not
                     flooded into/through OSPF stub and NSSA areas.
                     The E-bit ensures that all members of a stub area
                     agree on that area configuration. The E-bit is
                     meaningful only in OSPF Hello packets. When the
                     E-bit is reset in the Hello packet sent out a

   Coltun & Fuller                                                [Page 11]

   Internet Draft            OSPF NSSA Option                  October 1992

                     particular interface, it means that the router
                     will neither send nor receive type-5 AS external
                     link state advertisements on that interface (in other
                     words, the interface connects to a stub area). Two
                     routers will not become neighbors unless they agree
                     on the state of the E-bit.

             MC-bit: The MC-bit describes the multicast capability of the
                     various pieces of the OSPF routing domain [MOSPF].

             N-bit:  The N-bit describes the the router's NSSA capability.
                     The N-bit is used only in Hello packets and ensures
                     that all members of an NSSA agree on that area's
                     configuration. When the N-bit is reset in the Hello
                     packet sent out a particular interface, it means
                     that the router will neither send nor receive
                     type-7 LSAs on that interface. Two routers will not
                     form an adjacency unless they agree on the state
                     of the N-bit. If the N-bit is set in the options
                     field, the E-bit must be reset.

             P-bit:  The P-bit is used only in the type-7 LSA header.
                     It flags the NSSA area border router to translate the
                     type-7 LSA into a type-5 LSA.

     Appendix C:  Configuration Parameters

          Appendix C.2 in the OSPF specification lists the area parameters.
          Area  ID,  list  of address ranges and authentication type remain
          unchanged.  For NSSAs the external capabilities of the area  must
          be set to accept type-7 external routes.  Additionally there must
          be a way of configuring the NSSA area border  router  to  send  a
          default  route  into  the NSSA using a specific metric (type-1 or
          type-2 and the actual cost).

   Coltun & Fuller                                                [Page 12]