[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3101

Network Working Group                                          R. Coltun
Internet Draft                                              FORE Systems
Expiration Date: June 2001                                     V. Fuller
File name: draft-ietf-ospf-nssa-update-10.txt                 BBN Planet
                                                               P. Murphy
                                                    US Geological Survey
                                                           December 2000

                          The OSPF NSSA Option

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.























Coltun, Fuller, Murphy                                          [Page i]

Internet Draft              OSPF NSSA Option               December 2000


Table Of Contents

   1.0 Abstract .................................................  1
   2.0 Overview .................................................  2
   2.1 Motivation - transit networks ............................  2
   2.2 Motivation - corporate networks ..........................  3
   2.3 Proposed Solution ........................................  4
   3.0 NSSA Intra-area Implementation Details ...................  6
   3.1 The N-bit ................................................  6
   3.2 Type-7 Address Ranges ....................................  7
   3.3 Type-7 LSAs ..............................................  7
   3.4 Originating Type-7 LSAs ..................................  9
   3.5 Calculating Type-7 AS External Routes .................... 10
   3.6 Incremental Updates ...................................... 13
   3.7 Optionally Importing Summary LSAs ........................ 13
   4.0 Intra-AS implementation Details .......................... 14
   4.1 Type-7 Translator Election ............................... 14
   4.2 Translating Type-7 LSAs into Type-5 LSAs ................. 15
   4.3 Flushing Translated Type-7 LSAs .......................... 18
   5.0 Security Considerations .................................. 18
   6.0 Acknowledgments .......................................... 20
   7.0 References ............................................... 20
   8.0 Authors' Addresses ....................................... 21
   Appendix A: The Options Field ................................ 22
   Appendix B: Router-LSAs ...................................... 23
   Appendix C: Type-7 LSA Packet Format ......................... 25
   Appendix D: Configuration Parameters ......................... 26
   Appendix E: The P-bit Policy Paradox ......................... 27
   Appendix F: Differences from RFC 1587 ........................ 29


1.0  Abstract

   This memo documents an optional type of OSPF area which is somewhat
   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 external routes in a
   limited fashion.

   The OSPF NSSA Option was originally defined in RFC 1587.  The
   functional differences between this memo and RFC 1587 are explained
   in Appendix F.  All differences, while expanding capability, are
   backward-compatible in nature. Implementations of this memo and of
   RFC 1587 will interoperate.

   Please send comments to ospf@discuss.microsoft.com.





Coltun, Fuller, Murphy                                          [Page 1]

Internet Draft              OSPF NSSA Option               December 2000


2.0  Overview

2.1  Motivation - transit networks

   Wide-area transit networks 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, BBN Planet has one site composed of a
   class-B network, 130.57.0.0, and a class-C network, 192.31.114.0.
   From BBN Planet's perspective, this configuration looks something
   like this:

                       192.31.114
                           |
                         (cloud)
                     -------------- 130.57.4
                           |
                           |
                        ------ 131.119.13 ------
                        |BR18|------------|BR10|
                        ------            ------
                                             |
                                             V
                                     to BBN Planet "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.

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



Coltun, Fuller, Murphy                                          [Page 2]

Internet Draft              OSPF NSSA Option               December 2000


   However, the current definition of the OSPF protocol [OSPF] 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 routing domain.  In order
   to run OSPF out to BR18, BR18 must be a member of a non-stub area or
   the OSPF backbone before it can import routes other than its
   directly-connected network(s).  Since it is not acceptable for BR18
   to maintain all of BBN Planet's external (Type-5) routes, BBN Planet
   is forced by OSPF's topological limitations to only run OSPF out to
   BR10 and to run RIP between BR18 and BR10.

2.2  Motivation - corporate networks

   In a corporate network which supports a large corporate
   infrastructure it is not uncommon for OSPF area 0 to have a large
   non-zero area infrastructure which injects large routing tables into
   area 0.  Organizations within the corporate infrastructure may
   routinely multi-home their non-0 OSPF areas to strategically located
   backbone area 0 routers, either to provide backbone redundancy or to
   increase backbone connectivity or both.  Because of these large
   routing tables, OSPF aggregation via summarization is routinely used
   and recommended.  Stub areas are also recommended to keep the size of
   the routing tables of non-backbone routers small.  Organizations
   within the corporation are administratively autonomous and compete
   for corporate backbone resources.  They also want isolation from each
   other in order to protect their own network resources within the
   organization.

   Consider a typical backbone connection, as shown on the next page,
   where routers A1, B1 and A2, B2 are connected to area 1 and area 2
   respectively, and where routers A0 and B0 are border routers which
   connect to both area 1 and area 2.  Assume the 192.168.192/20 and
   192.168.208/22 clouds are subnetted with a protocol different from
   the corporate OSPF instance.  These other protocols could be RIP,
   IGRP, or second and third OSPF instances separate from the corporate
   OSPF backbone instance.

   Area 1 and Area 2 would like to be stub areas to minimize the size of
   their link state data base.  It is also desirable to aggregate the
   subnets of 192.168.192/20 and 192.168.208/22 each in a single
   advertisement to the backbone in such a way that the preferred path
   to 192.168.192/20 is through A0 and the preferred path to
   192.168.208/22 is through B0.





Coltun, Fuller, Murphy                                          [Page 3]

Internet Draft              OSPF NSSA Option               December 2000


                  +---A0------Area 0 cloud------B0---+
                  |   |                          |   |
                  |   |                          |   |
                  |   |T1                   56kbs|   |
             56kbs|   |                          |   |T1
                  |   |                          |   |
                  |   |       Area 1 cloud       |   |
                  |   A1-----192.168.192/20-----B1   |
                  |                                  |
                  +---A2                        B2---+
                       |                         |
                       |      Area 2 cloud       |
                       +-----192.168.208/22------+


   The current standard OSPF stub area has no mechanism to support the
   redistribution of routes for the subnets of 192.168.192/20 and
   192.168.208/22 within a stub area or the ability to aggregate a range
   of external routes in any OSPF area.  Any solution to this dilemma
   must also honor Area 1's path of choice to 192.168.192/20 through A0
   with redundancy through B0 while at the same time honoring Area 2's
   path of choice to 192.168.208/20 through B0 with redundancy through
   A0.

2.3 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 specification), 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) are 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.




Coltun, Fuller, Murphy                                          [Page 4]

Internet Draft              OSPF NSSA Option               December 2000


   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.3 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, Type-5 LSAs are not flooded into NSSAs
        and do not originate there.

      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 may be
        propagated into the backbone area (see section 4.2).

   In order to allow limited exchange of external information across an
   NSSA 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.  NSSA border routers may be
   configured with address ranges so that several Type-7 LSAs may be
   aggregated into a single Type-5 LSA.  The NSSA border routers which
   perform translation are configurable. In the absence of a configured
   translator one is elected.

   In addition, an NSSA border router should originate a default LSA (IP
   address of 0.0.0.0) into the NSSA.  Default routes are necessary
   because NSSAs do not receive full routing information and must have a
   default route in order to route to AS-external destinations.  Like
   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.  Note that
   a Type-7 default route originated by an NSSA border router is never
   translated into a Type-5 LSA, however, a Type-7 default route
   originated by an NSSA internal AS boundary router (one that is not
   also an area border router) may be translated into a Type-5 LSA.

   Like stub areas, the importing of OSPF summary routes (Type-3 LSAs)
   into NSSAs is a configuration option.  However particular care should
   be taken to ensure that OSPF internal routes are not obscured by OSPF
   external (Type-7) routes.  This may happen when other IGPs, like RIP
   and ISIS, leak routing information between an OSPF NSSA and another
   OSPF area.  In these cases, all OSPF summary routes should be
   imported into the effected NSSAs.  The recommended default behavior
   is to import OSPF summary routes into NSSAs.  Since AS-external-LSAs
   (Type-5) are not imported into NSSAs, NSSA border routers should not
   originate Type-4 summary-LSAs into their NSSAs.

   When summary routes are not imported, the default LSA originated by a
   NSSA border router into the NSSA should be a Type-3 summary LSA.  The



Coltun, Fuller, Murphy                                          [Page 5]

Internet Draft              OSPF NSSA Option               December 2000


   Type-3 summary default route insures intra-AS connectivity to the
   rest of the OSPF domain, as it takes precedence over any Type-7
   external default route which might originate on an NSSA internal
   router.  This Type-3 summary default route prevents the OSPF domain's
   internal traffic, which is normally forwarded by OSPF summary routes,
   from exiting the AS via any NSSA Type-7 external default route
   originated by an NSSA internal router.  Type-7 external defaults
   generated on NSSA internal routers and the no-summary option are
   mutually exclusive.  When summary routes are imported into the NSSA,
   the default LSA originated by a NSSA border router into the NSSA
   should be a Type-7 LSA.

   One final note, NSSA border routers never generate Type-4 summary
   LSAs for their NSSA ASBRs as their Type-7 external advertisements are
   never flooded beyond the NSSA's borders.

   In our transit topology examples 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 BBN Planet's external
   routes are hidden from BR18; BR10 becomes an NSSA 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 BBN Planet's backbone.

   In our corporate example, the subnets of 192.168.192/20 and
   192.168.208/22 are learned via their respective routing protocols,
   redistributed throughout NSSAs 1 and 2, and then aggregated during
   the translation process into a single Type-5 LSA which is flooded
   into Area 0.  Area 1 may configure A0 to perform translation, while
   Area 2 configures B0 as its translator.

3.0  NSSA Intra-area Implementation Details

3.1  The N-bit

   The N-bit ensures that all members of an 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) 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 clear.

   To support the NSSA option an additional check must be made in the



Coltun, Fuller, Murphy                                          [Page 6]

Internet Draft              OSPF NSSA Option               December 2000


   function that handles the receiving of the 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 for
   the receiving interface.  A mismatch in the options causes processing
   of the received Hello packet to stop and the packet to be dropped.

3.2  Type-7 Address Ranges

   NSSA border routers may be configured with Type-7 address ranges.
   Each address range is defined as an [address,mask] pair.  Many
   separate Type-7 networks may fall into a single address range, just
   as a subnetted network is composed of many separate subnets.  NSSA
   border routers may aggregate Type-7 routes by advertising a single
   Type-5 LSA for each Type-7 address range.  The Type-5 LSA resulting
   from a Type-7 address range match will be distributed to all Type-5
   capable areas.  Section 4.2 gives the details of generating Type-5
   LSAs from Type-7 address ranges.

   A Type-7 address range includes the following configurable items.

      o An [address,mask] pair.

      o A status indication of either Advertise or DoNotAdvertise.

      o An external route tag.

3.3  Type-7 LSAs

   External routes are imported into NSSAs as Type-7 LSAs by NSSA AS
   boundary routers.  An NSSA AS boundary router (ASBR) is a router
   which has an interface associated with the NSSA and is exchanging
   routing information with routers belonging to another AS.  Like OSPF
   ASBRs, an NSSA router indicates it is an NSSA ASBR by setting the E-
   bit in its router-LSA.  As with Type-5 LSAs a separate Type-7 LSA is
   originated for each destination network.  To support NSSAs, the
   link-state database must therefore be expanded to contain Type-7
   LSAs.

   Type-7 LSAs are identical to Type-5 LSAs except for the following
   (see section 12.4.4 "AS external links" in the OSPF specification).

      1. The type field in the LSA header is 7.

      2. Type-7 LSAs are only flooded within the originating NSSA.  The
         flooding of Type-7 LSAs follows the same rules as the flooding
         of Type-1 and Type-2 LSAs.

      3. Type-7 LSAs are only listed within the OSPF area data



Coltun, Fuller, Murphy                                          [Page 7]

Internet Draft              OSPF NSSA Option               December 2000


         structures of their respective NSSAs, making them area
         specific.  Type-5 LSAs, which are flooded to all Type-5 capable
         areas, have global scope and are listed in the OSPF protocol
         data structure.

      4. At the NSSA border router, selected Type-7 LSAs are translated
         into type 5-LSAs and flooded into the OSPF domain's transit
         topology.

      5. Type-7 LSAs have a propagate (P) bit which, when set, tells an
         NSSA 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
         described in section 4.2.

      6. Those Type-7 LSAs that are to be translated into Type-5 LSAs
         must have their forwarding address set.

   Type-5 LSAs which are translations of Type-7 LSAs normally contain a
   forwarding address.  The exception to this is when the Type-5 LSA is
   an aggregation of Type-7 LSAs, in which case the Type-5 LSA may not
   contain a forwarding address (see section 4.2 for details).  The
   forwarding address contained in Type-5 LSAs results in more efficient
   routing to Type-7 AS external networks when there are multiple NSSA
   border routers.  Moreover the forwarding address in a Type-7 LSA
   eases its translation into a Type-5 LSA, as the NSSA 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 with
   Type-5 LSAs.  If the intervening network is not advertised into OSPF
   as an internal OSPF route and the Type-7 LSA's P-bit is set, a
   forwarding address should be selected from one of the router's active
   OSPF interface addresses which belong to the NSSA.  If no such
   addresses exist, then no Type-7 LSAs with the P-bit set should
   originate from this router.

   When a router is forced to pick a forwarding address for a Type-7
   LSA, precedence should be given first to the router's loopback
   addresses (provided internal addressing is supported).  If a loopback
   address is not used and the selected forwarding address's interface
   transitions to a Down state (see OSPF Section 9.3), one must select a
   new forwarding address for any Type-7 LSAs which reference the
   previously selected forwarding address and then re-originate these
   Type-7 LSAs.  If internal addresses are not available, preference
   should be given to the router's active OSPF stub network addresses to
   avoid the possible extra hop of a transit network's address.




Coltun, Fuller, Murphy                                          [Page 8]

Internet Draft              OSPF NSSA Option               December 2000


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

3.4 Originating Type-7 LSAs

   NSSA AS boundary routers may only originate Type-7 LSAs.  All NSSA
   border routers must have the capability of translating Type-7 LSAs
   into Type-5 LSAs as described in Section 4.2.  NSSA border routers
   must set bit E (external bit) in their router (Type-1) LSAs
   originated for directly attached non-stub areas.

   An NSSA internal AS boundary router must set the P-bit in the LSA
   header's option field of any Type-7 LSA whose path it wants
   advertised into the OSPF domain's full transit topology.  The LSAs of
   these networks must have a valid non-zero forwarding address.  If the
   P-bit is clear the LSA is not translated into a Type-5 LSA by NSSA
   border routers.

   When an NSSA border router originates both a Type-5 and a Type-7 LSA
   for the same network,  the P-bit must be clear in the Type-7 NSSA so
   that the Type-7 LSA isn't again translated into a Type-5 LSA by
   another NSSA border router. If the border router only originates a
   Type-7 LSA, it may set the P-bit, thus allowing the network to be
   aggregated/propagated during Type-7 translation.  If an NSSA
   originates a Type-5 LSA with a forwarding address which is part of
   the NSSA, it should also originate a Type-7 LSA into the NSSA. If two
   NSSA routers, both reachable from one another over the NSSA,
   originate functionally equivalent AS-external-LSAs (i.e., same
   destination, cost and non-zero forwarding address), then the router
   having the least preferred LSA should flush its LSA (See [OSPF]
   Section 12.4.4.1). Preference between two Type-7 LSAs is determined
   by the following tie breaker rules:

      1) An LSA with the p-bit set is preferred over one with the p-bit
         clear.

      2) If the p-bit settings are the same, the LSA with the higher
         router ID is preferred.

   A Type-7 default route (network 0.0.0.0) may be originated into the
   NSSA by any NSSA router.  The Type-7 default route originated by the
   NSSA border router must have the P-bit clear.  The Type-7 default
   route originated by an NSSA ASBR which is not an NSSA border router
   may have the P-bit set.  A Type-7 default route may be installed by
   NSSA border routers if and only if its P-bit is set (see Appendix E).

   An LSA for the default destination must be originated by all the
   NSSA's border routers in order to support intra-AS routing and
   inter-AS routing.  This default destination is advertised in either a



Coltun, Fuller, Murphy                                          [Page 9]

Internet Draft              OSPF NSSA Option               December 2000


   Type-3 or Type-7 LSA, as described in the Section 3.7.

3.5 Calculating Type-7 AS External Routes

   This calculation must be run when Type-7 LSAs are processed during
   the AS external route calculation.  This calculation may process
   Type-5 LSAs, but it is written that way only for comparison sake.

   Non-default Type-7 LSAs with the P-bit clear may be installed in the
   OSPF routing table of NSSA border routers.  Since these LSAs are not
   propagated throughout the OSPF domain, traffic which originates
   external to an NSSA and which passes through one of the NSSA's border
   routers may be unexpectedly diverted into the NSSA (See Appendix E).

   An NSSA border router should examine both Type-5 LSAs and Type-7 LSAs
   if either Type-5 or Type-7 routes need to be updated or recalculated.
   This is done as part of the AS external route calculation.  An NSSA
   internal router should examine Type-7 LSAs when Type-7 routes need to
   be recalculated.

   What follows is only a modest modification of the OSPF Version 2
   Specification Section 16.4.  Original text is suffixed with [OSPF].
   NSSA specific text is suffixed with [NSSA].

   AS external routes are calculated by examining AS-external-LSAs, be
   they Type-5 or Type-7.  Each of the AS-external-LSAs is considered in
   turn.  Most AS-external-LSAs describe routes to specific IP
   destinations.  An AS-external-LSA can also describe a default route
   for the Autonomous System (Destination ID = DefaultDestination,
   network/subnet mask = 0x00000000). For each AS-external-LSA [~OSPF]:

      (1) If the metric specified by the LSA is LSInfinity, or if the
          age of the LSA equals MaxAge, then examine the next LSA.
          [OSPF]

      (2) If the LSA was originated by the calculating router itself,
          examine the next LSA.  [OSPF]

      (3) Call the destination described by the LSA N.  N's address is
          obtained by masking the LSA's Link State ID with the
          network/subnet mask contained in the body of the LSA.  Look up
          the routing table entries which match the LSA's type for the
          AS boundary router (ASBR) that originated the LSA.  For a
          Type-5 LSA, routing table entries may only be selected from
          each attached non-NSSA/non-stub area.  Since the flooding
          scope of a Type-7 LSA is restricted to the originating NSSA,
          the routing table entry of its ASBR must be found in the
          originating NSSA.  If no entries exist for the ASBR (i.e.  the



Coltun, Fuller, Murphy                                         [Page 10]

Internet Draft              OSPF NSSA Option               December 2000


          ASBR is unreachable over the transit topology for a Type-5
          LSA, or, for a Type-7 LSA, it is unreachable over its
          originating NSSA), do nothing with this LSA and consider the
          next in the list.  [NSSA]

          Else if the destination is a Type-7 default route (destination
          ID = DefaultDestination) and one of the following is true,
          then do nothing with this LSA and consider the next in the
          list:

             o  The calculating router is a border router and the LSA
                has its P-bit clear.  Appendix E describes technique for
                border router Type-7 default installation without
                propagation.  [NSSA]

             o  The calculating router is suppressing the import of
                summary (Type-3) LSAs.

          Else, this LSA describes an AS external path to destination N.
          Examine the forwarding address specified in the AS-external-
          LSA.  This indicates the IP address to which packets for the
          destination should be forwarded.  [OSPF]

          If the forwarding address is set to 0.0.0.0 then packets
          should be sent to the ASBR itself.  If the LSA is Type-5, from
          among the multiple non-NSSA routing table entries for the ASBR
          (both NSSA and non-NSSA ASBR entries might exists on an NSSA
          border router), select the preferred entry as follows [~OSPF]:

                If RFC1583Compatibility is set to "disabled", prune the
                set of routing table entries for the ASBR as described
                in OSPF Section 16.4.1.  In any case, among the
                remaining routing table entries, select the routing
                table entry with the least cost; when there are multiple
                least cost routing table entries the entry whose
                associated area has the largest OSPF Area ID (when
                considered as an unsigned 32-bit integer) is chosen.
                [OSPF]

          Since a Type-7 LSA only has area-wide flooding scope, when its
          forwarding address is set to 0.0.0.0, its ASBR's routing table
          entry must be chosen from the originating NSSA. Here no
          pruning is necessary since this entry always contains non-
          backbone intra-area paths.  [NSSA]

          If the forwarding address is non-zero look up the forwarding
          address in the routing table. For Type-5 LSAs the matching
          routing table entry must specify an intra-area or inter-area



Coltun, Fuller, Murphy                                         [Page 11]

Internet Draft              OSPF NSSA Option               December 2000


          path. For Type-7 LSAs the matching routing table entry must
          specify an intra-area path through the originating NSSA. If no
          such path exists then do nothing with this LSA and consider
          the next in the list.  [OSPF]

      (4) Let X be the cost specified by the preferred routing table
          entry for the ASBR/forwarding address, and Y the cost
          specified in the LSA.  X is in terms of the link state metric,
          and Y is a type 1 or 2 external metric.  [OSPF]

      (5) Now, look up the routing table entry for the destination N.
          If no entry exists for N, install the AS external path to N,
          with the next hop equal to the list of next hops to the
          ASBR/forwarding address, and advertising router equal to the
          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.  [OSPF]

      (6) Otherwise compare the AS external path described by the LSA
          with the existing paths in N's routing table entry.  If the
          new path is preferred, it replaces the present paths in N's
          routing table entry.  If the new path is of equal preference,
          it is added to N's routing table entry's list of paths. [OSPF]

          Preference is defined as follows:

          (a) Intra-area and inter-area paths are always preferred over
              AS external paths.  [OSPF]

          (b) Type 1 external paths are always preferred over type 2
              external paths. When all paths are type 2 external paths,
              the paths with the smallest advertised type 2 metric are
              always preferred.  [OSPF]

          (c) If the new AS external path is still indistinguishable
              from the current paths in N's routing table entry, and
              RFC1583Compatibility is set to "disabled", select the
              preferred paths based on the intra-AS paths to the
              ASBR/forwarding addresses, as specified in Section 16.4.1.
              Here intra-NSSA paths are equivalent to the intra-area
              paths of non-backbone regular OSPF areas.  [NSSA]

          (d) If the new AS external path is still indistinguishable
              from the current paths in N's routing table entry, select
              the preferred path based on a least cost comparison.  Type
              1 external paths are compared by looking at the sum of the



Coltun, Fuller, Murphy                                         [Page 12]

Internet Draft              OSPF NSSA Option               December 2000


              distance to the forwarding address and the advertised type
              1 metric (X+Y).  Type 2 external paths advertising equal
              type 2 metrics are compared by looking at the distance to
              the forwarding addresses.  [OSPF]

          (e) If the current LSA is functionally the same as an
              installed LSA (i.e., same destination, cost and non-zero
              forwarding address) then apply the following priorities in
              deciding which LSA is preferred:

              a. A Type-7 LSA with the P-bit set.

              b. A Type-5 LSA.

              c. The LSA with the higher router ID.  [NSSA]

3.6 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 destination
   represented by the Type-7 LSA, no recalculation is necessary.

   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.

3.7 Optionally Importing Summary LSAs

   In order for backbone summary internal routes to be preferred over
   external Type-7 routes, all implementations must support the optional
   import of summary LSAs from the backbone into an NSSA.  The default
   behavior is to import Type-3 summary LSAs.  A new area configuration
   parameter, ImportSummaries, has been added.  When set to enabled,
   Type-3 summary routes are imported.  When set to disabled, summary
   routes are not imported.  The default setting is enabled.

   When summary routes are not imported, the default LSA originated by a
   NSSA border router into the NSSA should be a Type-3 summary LSA.
   This protects the NSSA from routing intra-AS traffic out the AS via a
   Type-7 external default route originating from an internal NSSA
   router.  Unlike the stub area case, when summary routes are imported
   into the NSSA, a Type-3 summary default route must not be injected
   into the NSSA, otherwise the Type-3 summary default route would be
   chosen over potentially more preferred Type-7 default routes.




Coltun, Fuller, Murphy                                         [Page 13]

Internet Draft              OSPF NSSA Option               December 2000


4.0 Intra-AS implementation Details

4.1 Type-7 Translator Election

   It is not recommended that multiple NSSA border routers perform the
   translation unless the efficient routing of packets through area 0 to
   an NSSA partitioned by aggregation requires it.  It is normally
   sufficient to have only one NSSA border router perform the
   translation.  Excessive numbers of Type-7 translators unnecessarily
   increase the size of the OSPF link state data base.

   A new area configuration parameter, NSSATranslatorRole, is defined in
   Appendix D.  It specifies whether or not an NSSA router will
   unconditionally translate Type-7 LSAs to Type-5 LSAs when acting as
   an NSSA border router.  When set to Always, Type-7 LSAs are always
   translated regardless of the translator state of other NSSA border
   routers.  When set to Candidate and acting as an NSSA border router,
   an NSSA router will participate in the translator election process
   described below.

   A new bit called Nt is added to the router-LSA.  NSSA border routers,
   which are configured to unconditionally translate Type-7 LSAs into
   Type-5 LSAs, set bit Nt in their NSSA router-LSA.  All other routers
   clear bit Nt in their NSSA router-LSAs.

   A new area parameter called the NSSATranslatorState is maintained in
   the OSPF area data structure.  By default all NSSA routers initialize
   NSSATranslatorState to disabled.  When an NSSA router attains border
   router status and has its NSSATranslatorRole set to Always, it sets
   NSSATranslatorState to enabled and begins the unconditional
   translation of Type-7 LSAs into Type-5 LSAs for the NSSA.  When an
   NSSA border router loses its border router status,
   NSSATranslatorState is always reset to disabled and the Nt bit is
   cleared in a new router LSA.

   If an NSSA border router has its NSSATranslatorState set to disabled
   and, from the subset of NSSA border routers which are reachable over
   the NSSA and reachable as ASBRs over the AS's transit topology, no
   such router exists either with bit Nt set in its router-LSA or with
   higher router ID, then this router begins to perform the translation
   of Type-7 LSAs into Type-5 LSAs for the NSSA and it sets
   NSSATranslatorState to elected.  The Nt bit of an elected translator
   is always clear.  These conditions may result in more than one
   elected translator for the NSSA, should one of the NSSA border
   routers lose connectivity to area 0.

   All NSSA border routers must set the E-bit in their router-LSA to
   directly attached non-stub areas even when they are not translating.



Coltun, Fuller, Murphy                                         [Page 14]

Internet Draft              OSPF NSSA Option               December 2000


   This allows other NSSA border routers to see their ASBR status across
   the AS's transit topology.  Failure to do so may cause the election
   algorithm to elect unnecessary translators.  Every NSSA border router
   is a potential translator.

   An elected translator will continue to perform translation duties
   until supplanted by a reachable NSSA border router whose Nt bit is
   set to true or whose router ID is greater.  Such an event might be
   triggered by the manual setting of the NSSATranslatorState to enabled
   in one of the NSSA border routers or a topological rejoining of a
   partitioned NSSA.  Any change in the membership of the reachable NSSA
   border router set, both over the NSSA and as ASBRs over the AS's
   transit topology, or a change in a router-LSA's Nt bit setting should
   force an NSSA border router to recheck its Type-7 translation status.
   If an elected translator determines its services are no longer
   required, it should continue to perform its translation duties for
   the additional time interval defined by a new area configuration
   parameter, TranslatorStabilityInterval.  This minimizes excessive
   flushing of translated Type-7 LSAs and provides for a more stable
   translator transition. The default value for the
   TranslatorStabilityInterval parameter has been defined as 40 seconds
   (see Appendix D).

   Configuring the identity of the translator can be used to bias the
   routing to aggregated destinations.

4.2 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
   calculating router is currently not an NSSA border router translator,
   then this translation algorithm should be skipped.  Only installed
   Type-7 LSAs and those non-default Type-7 LSAs originated by the
   router itself should be examined.  Locally sourced Type-7 LSAs should
   be processed first.

   Note that it is possible for a Type-5 LSA generated by translation to
   supplant a Type-5 LSA originating from a local OSPF external source.
   Future reoriginations of the locally source Type-5 LSA should be
   suppressed until the Type-5 LSA generated by translation is flushed.

   A Type-7 LSA and a Type-7 range best match one another if there does
   not exist a more specific Type-7 range which contains the Type-7 LSA.
   For each translation eligible Type-7 LSA perform the following:

      (1) If the Type-7 LSA has the P-bit clear, or its forwarding
          address is set to 0.0.0.0, or the most specific Type-7 range
          which subsumes the network has DoNotAdvertise status, then do



Coltun, Fuller, Murphy                                         [Page 15]

Internet Draft              OSPF NSSA Option               December 2000


          nothing with this Type-7 LSA and consider the next one in the
          list.  Otherwise term the LSA as translatable and proceed with
          step (2).

      (2) If the Type-7 LSA is not contained in any explicitly
          configured Type-7 address range and the calculating router has
          the highest router ID amongst NSSA translators which have
          originated a functionally equivalent Type-5 LSA (i.e. same
          destination, cost and non-zero forwarding address) and which
          are reachable over area 0 and the NSSA, then a Type-5 LSA
          should be generated if there currently is no Type-5 LSA
          originating from this router corresponding to the Type-7 LSA's
          network or there is an existing Type-5 LSA and either it
          corresponds to a local OSPF external source whose path type
          and metric is less preferred (see Section 3.5 step (6), parts
          (b) and (d)) or it doesn't and the Type-5 LSA's path type or
          cost(s) have changed (See Section 3.5 step (5)) or the
          forwarding address no longer maps to a translatable Type-7
          LSA.

          The newly originated Type-5 LSA will describe the same network
          and have the same network mask, path type, metric, 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.  The link-state ID is equal to the LSA's
          network address (in the case of multiple originations of
          Type-5 LSAs with the same network address but different mask,
          the link-state ID can also have one or more of the range's
          "host" bits set).

      (3) Else the Type-7 LSA must be aggregated by the most specific
          Type-7 range which subsumes it.  If this Type-7 range has the
          same [address,mask] pair as the Type-7 LSA's network and the
          LSA is the only Type-7 LSA which best matches this range, then
          flag the Type-7 LSA as not contained in any explicitly
          configured Type-7 address range and continue processing the
          LSA as described in step (2).  Otherwise compute the path type
          and metric for this Type-7 range as described below.

          The path type and metric of the Type-7 range is determined
          from the path types and metrics of those translatable Type-7
          LSAs which best match the range plus any locally sourced
          Type-5 LSAs whose network has the same [address,mask] pair.
          If any of these LSAs have a path type of 2 the range's path
          type is 2, otherwise it is 1.  If the range's path type is 1
          its metric is the highest cost amongst its LSAs; if the
          range's path type is 2 its metric is the highest Type-2 cost +
          1 amongst its LSAs (See Section 3.5 step (5)).  1 is added to



Coltun, Fuller, Murphy                                         [Page 16]

Internet Draft              OSPF NSSA Option               December 2000


          the Type-2 cost to ensure that the translated Type-5 does not
          appear closer on the NSSA border than a translatable Type-7
          LSA whose network has the same [address,mask] pair and Type-2
          cost.

          A Type-5 LSA is generated from the Type-7 range when there
          currently is no Type-5 LSA originated by this router whose
          network has the same [address,mask] pair as the range or there
          is but either its path type or metric has changed or its
          forwarding address is non-zero.

          The newly generated Type-5 LSA will have link-state ID equal
          to the Type-7 range's address (in the case of multiple
          originations of Type-5 LSAs with the same network address but
          different mask, the link-state ID can also have one or more of
          the range's "host" bits set).  The advertising router field
          will be the router ID of this area border router.  The network
          mask and the external route tag are set to the Type-7 range's
          configured values.  The forwarding address is set to 0.0.0.0.
          The path type and metric are set to the Type-7 range's path
          type and metric as defined above.

          The pending processing of other translation eligible Type-7
          LSAs which best match this Type-7 range is suppressed.  Thus
          at most a single Type-5 LSA is originated for each Type-7
          range.

   For example, given a Type-7 range of [10.0.0.0, 255.0.0.0] which
   subsumes the following Type-7 routes:

                 10.1.0.0 path type 1, metric 10
                 10.2.0.0 path type 1, metric 11
                 10.3.0.0 path type 2, metric 5

   a Type-5 LSA would be generated with a path type of 2 and a metric 6.

   Given a Type-7 range of [10.0.0.0, 255.0.0.0] which subsumes the
   following Type-7 routes:

                 10.1.0.0 path type 1, metric 10
                 10.2.0.0 path type 1, metric 11
                 10.3.0.0 path type 1, metric 5

   a Type-5 LSA will be generated with a path type of 1 and a metric 11.

   These Type-7 range metric and path type rules will avoid routing
   loops in the event that path types 1 and 2 are both used within the
   area.



Coltun, Fuller, Murphy                                         [Page 17]

Internet Draft              OSPF NSSA Option               December 2000


   As with all newly originated Type-5 LSAs, a Type-5 LSA that is the
   result of a Type-7 LSA translation or aggregation is flooded to all
   attached Type-5 capable areas.

   Like Type-3 ranges, a Type-7 range performs the dual function of
   setting propagation policy via its Advertise/DoNotAdvertise parameter
   and aggregation via its network address and mask pair.  Unlike Type-3
   summary links, Type-5 translation may result in more efficient
   routing when the forwarding address is set, as is done during step
   (2) of the translation procedure.

   Another important feature of this translation process is that it
   allows a Type-7 range to apply different properties (aggregation,
   forwarding address, and Advertise/DoNotAdvertise status) for the
   Type-7 routes it subsumes, versus those Type-7 routes subsumed by
   other more specific Type-7 ranges contained by the Type-7 range.

4.3 Flushing Translated Type-7 LSAs

   If an NSSA border router has either translated or aggregated an
   installed Type-7 LSA into a Type-5 LSA which should no longer be
   translated or aggregated, then the Type-5 LSA should either be
   flushed or reoriginated as an aggregation of other Type-7 LSAs.

   If an NSSA border router is translating Type-7 LSA's into Type-5
   LSA's with

                NSSATranslatorState = elected

   and the NSSA border router has determined that its translator
   election status has been deposed by another NSSA border router, then,
   as soon as the TranslatorStabilityInterval has expired without the
   router reelecting itself as a translator, Type-5 LSAs generated by
   translating Type-7 address ranges are flushed.  Conversely Type-5
   LSAs generated by translating Type-7 LSAs are not immediately
   flushed, but are allowed to remain in the OSPF routing domain as if
   the originator is still an elected translator.  This minimizes the
   impact of an NSSA which changes its translator frequently.

5.0 Security Considerations

   There are two types of issues that need be addressed when looking at
   protecting routing protocols from misconfigurations and malicious
   attacks. The first is authentication and certification of routing
   protocol information.  The second is denial of service attacks
   resulting from repetitive origination of the same router
   advertisement or origination of a large number of distinct
   advertisements resulting in database overflow. Note that both of



Coltun, Fuller, Murphy                                         [Page 18]

Internet Draft              OSPF NSSA Option               December 2000


   these concerns exist independently of a router's support for the NSSA
   option.

   The OSPF protocol addresses authentication concerns by authenticating
   OSPF protocol exchanges.  OSPF supports multiple types of
   authentication; the type of authentication in use can be configured
   on a per network segment basis.  One of OSPF's authentication types,
   namely the Cryptographic authentication option, is believed to be
   secure against passive attacks and provides significant protection
   against active attacks.  When using the Cryptographic authentication
   option, each router appends a "message digest" to its transmitted
   OSPF packets.  Receivers then use the shared secret key and the
   received digest to verify that each received OSPF packet is
   authentic.

   The quality of the security provided by the Cryptographic
   authentication option depends completely on the strength of the
   message digest algorithm (MD5 is currently the only message digest
   algorithm specified), the strength of the key being used, and the
   correct implementation of the security mechanism in all communicating
   OSPF implementations.  It also requires that all parties maintain the
   secrecy of the shared secret key.  None of the standard OSPF
   authentication types provide confidentiality.  Nor do they protect
   against traffic analysis.  For more information on the standard OSPF
   security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].

   [DIGI] describes the extensions to OSPF required to add digital
   signature authentication to Link State data and to provide a
   certification mechanism for router data.  [DIGI] also describes the
   added LSA processing and key management as well as a method for
   migration from or co-existence with standard OSPF V2.

   Repetitive origination of advertisements are addressed by OSPF by
   mandating a limit on the frequency that new instances of any
   particular LSA can be originated and accepted during the flooding
   procedure.  The frequency at which new LSA instances may be
   originated is set to once every MinLSInterval seconds, whose value is
   5 seconds (see Section 12.4 of [OSPF]).  The frequency at which new
   LSA instances are accepted during flooding is once every MinLSArrival
   seconds, whose value is set to 1 (see Section 13, Appendix B and G.1
   of [OSPF]).

   Proper operation of the OSPF protocol requires that all OSPF routers
   maintain an identical copy of the OSPF link state database.  However,
   when the size of the link state database becomes very large, some
   routers may be unable to keep the entire database due to resource
   shortages; this is termed "database overflow".  When database
   overflow is anticipated, the routers with limited resources can be



Coltun, Fuller, Murphy                                         [Page 19]

Internet Draft              OSPF NSSA Option               December 2000


   accommodated by configuring OSPF stub areas and NSSAs.  [OVERFLOW]
   details a way of gracefully handling unanticipated database
   overflows.

6.0 Acknowledgments

   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
                  Acee Lindem        IBM
                  John Moy           Sycamore Networks, Inc.
                  Antoni Przygienda  Redback Networks, Inc
                  Doug Williams      IBM
                  Alex Zinin         cisco

7.0 References

   [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital
      Signatures", RFC 2154, Trusted Information Systems, June 1997.

   [MUEX] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
      Inc., March 1994.

   [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade Communications
      Corp., April 1998.

   [OPAQUE] Coltun, Rob, "The OSPF Opaque LSA Option", RFC 2370, FORE
      Systems, July 1998.

   [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, Cascade,
      March 1995.














Coltun, Fuller, Murphy                                         [Page 20]

Internet Draft              OSPF NSSA Option               December 2000


8.0 Authors' Addresses

      This update uses much of the original text from RFC 1587 authored by

      Rob Coltun
      Redback Networks, Inc.
      1195 Borregas Avenue
      Sunnyvale, CA 94089

      Phone: (408) 548-3947
      EMail: rcoltun@redback.com


      Vince Fuller
      GTE Internetworking
      3801 East Bayshore Road
      Palo Alto, California 94303

      Phone: (415) 528-7227
      EMail: vaf@BBNPlanet.com


      New sections, edits and revisions have been added by

      Pat Murphy
      US Geological Survey
      345 Middlefield Road
      Menlo Park, California 94560

      Phone: (415) 329-4044
      EMail: pmurphy@noc.doi.net




















Coltun, Fuller, Murphy                                         [Page 21]

Internet Draft              OSPF NSSA Option               December 2000


Appendix A: The Options Field

      The OSPF options field is present in OSPF Hello packets, Database
      Description packets and all link state advertisements.  See appendix A.2 in
      [OSPF] and [OPAQUE] for a description of the options field.  Six bits
      are assigned but only two (the E-bit and the N/P bit) are described
      completely in this section.

                   --------------------------------------
                   | * | O | DC | EA | N/P | MC | E | * |
                   --------------------------------------

                       The Type-7 LSA options field

      E-bit:  Type-5 AS external LSAs are not flooded into/through OSPF
              stub areas and NSSAs.  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 and Database
              Description packets.  When the E-bit is clear in the Hello
              packet sent out a particular interface, it means that the
              router will neither send nor receive Type-5 AS external
              LSAs on that interface (in other words, the interface
              connects to a stub area or NSSA).  Two routers will not
              become neighbors unless they agree on the state of the E-
              bit.

      N-bit:  The N-bit describes 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 set in the Hello packet and sent out a
              particular interface, it means that the router will send
              and 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 clear.

      P-bit:  The P-bit is used only in the Type-7 LSA header.  It flags
              the NSSA border router to translate the Type-7 LSA into a
              Type-5 LSA.  The default setting for the P-bit is clear.












Coltun, Fuller, Murphy                                         [Page 22]

Internet Draft              OSPF NSSA Option               December 2000


Appendix B: Router-LSAs

   Router-LSAs are the Type-1 LSAs.  Each router in an area originates a
   router-LSA.  The LSA describes the state and cost of the router's
   links (i.e., interfaces) to the area.  All of the router's links to
   the area must be described in a single router-LSA.  For details
   concerning the construction of router-LSAs, see the OSPF
   Specification, Section 12.4.1.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |       1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  0  Nt|W|V|E|B|        0      |            # links            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     # TOS     |        TOS 0 metric           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

   In router-LSAs, the Link State ID field is set to the router's OSPF
   Router ID.  The T-bit is set in the LSA's Option field if and only if
   the router is able to calculate a separate set of routes for each IP
   TOS.  Router-LSAs are flooded throughout a single area only.





Coltun, Fuller, Murphy                                         [Page 23]

Internet Draft              OSPF NSSA Option               December 2000


      bit V
          When set, the router is an endpoint of one or more fully
          adjacent virtual links having the described area as Transit
          area (V is for virtual link endpoint).

      bit E
          When set, the router is an AS boundary router (E is for
          external).  ALL NSSA border routers must set bit E in the
          router-LSAs to directly attached standard areas and NSSAs.
          (See Section 4.1 for details).

      bit B
          When set, the router is an area border router (B is for
          border).

      bit W
          When set, the router is a wild-card multicast receiver (W is
          for wild).

      bit Nt
          When set, the router is an NSSA border router which is
          unconditionally translating Type-7 LSAs into Type-5 LSAs (Nt
          is for NSSA translation).  Note that such routers have their
          NSSATranslatorRole area configuration parameter set to Always
          (See Appendix D and Section 4.1).

   The remainder of the router links specification is as defined in the
   OSPF Specification, Section A.4.2.























Coltun, Fuller, Murphy                                         [Page 24]

Internet Draft              OSPF NSSA Option               December 2000


Appendix C: Type-7 LSA Packet Format

          0                                 32
          ------------------------------------
          |                | Options |   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 Type-5 LSAs
   (see Appendix A.4.5 in the [OSPF]), except for the forwarding address
   and the N/P-bit.  The Options field must have the N/P bit set as
   described in Appendix A when the originating router desires that the
   external route be propagated throughout the OSPF domain.

   Forwarding address
      Data traffic for the advertised destination will be forwarded to
      this address.  If the forwarding address is set to 0.0.0.0, data
      traffic will be forwarded to the LSA's originator (i.e., the
      responsible NSSA AS boundary router).  If the P-bit is set the
      forwarding address must be non-zero.  If the network between the
      NSSA AS boundary router and the adjacent AS is advertised into the
      NSSA as an internal OSPF route, the forwarding address should be
      the next hop address.  If the intervening network is not
      advertised into the NSSA as an internal OSPF route, the forwarding
      address should be any one of the router's active OSPF interface
      addresses (see Section 3.3 for details).














Coltun, Fuller, Murphy                                         [Page 25]

Internet Draft              OSPF NSSA Option               December 2000


Appendix D:  Configuration Parameters

      Appendix C.2 in the OSPF specification lists the area
      configuration parameters.  The area ID and the list of address
      ranges for Type-3 summary routes remain unchanged.  Section 3.2 of
      this document lists the configuration parameters for Type-7
      address ranges.  The following area configuration parameters have
      been added:

      NSSATranslatorRole

         Specifies whether or not the router will unconditionally
         translate Type-7 LSAs to Type-5 LSAs when acting as an NSSA
         border router.  When set to Always, Type-7 LSAs are always
         translated regardless of the translator state of other NSSA
         border routers.  When set to Candidate and acting as an NSSA
         border router, it participates in the translator election
         process described in Section 4.1.  The default setting is
         Candidate.

      TranslatorStabilityInterval

         Defines the length of time an elected Type-7 translator will
         continue to perform its translator duties once it has
         determined that translator status has been deposed by another
         NSSA border router translator as described in Section 4.1 and
         4.3.  The default setting is 40 seconds.

      ImportSummaries

         When set to enabled, Type-3 summary LSAs are imported into the
         NSSA.  When set to disabled, Type-3 summary LSAs are not
         imported into the NSSA.  The default setting is enabled.

   Implementations must provide a vehicle for setting the P-bit of
   external routes imported into the NSSA as Type-7 LSAs.  Without
   configuration, the default setting of the P-bit is clear (see Section
   3.3 and Appendix B).

   For NSSAs the ExternalRoutingCapability area configuration parameter
   must be set to accept Type-7 external routes.  Additionally there
   must be a way of configuring an NSSA border router to advertise a
   default route into the NSSA with configurable metric type (1 or 2)
   and cost.







Coltun, Fuller, Murphy                                         [Page 26]

Internet Draft              OSPF NSSA Option               December 2000


Appendix E: The P-bit Policy Paradox.

   Non-default Type-7 LSAs with the P-bit clear may be installed in the
   OSPF routing table of NSSA border routers (see Section 3.5).  These
   LSAs are not propagated throughout the OSPF domain as translated
   Type-5 LSAs (see Section 4.2).  Thus traffic which is external to an
   NSSA and which passes through one of the NSSA's border routers may be
   hijacked into the NSSA by a route installed from a Type-7 LSA with
   the P-bit clear.  This may be contrary to the expected path at the
   source of the traffic.  It may also violate the routing policy
   intended by the Type-7 LSA's clear P-bit.  A Type-7 range configured
   with DoNotAdvertise exhibits the same paradox for any installed
   Type-7 LSAs it subsumes.

   This paradox is best illustrated by the following example.  Consider
   an OSPF domain (AS 1842) with connections for default Internet
   routing and to external AS 4156.  NSSA 1 and OSPF Area 2 are
   partially defined in the following diagram:

                           AS 4156
                             |
         Area 2              |
                             |
           A2                A0   Area 0      C0-----Internet
           |                 |                |      Default
           |                 |                |
           |                 |                |
           +-----------------B0---------------+
                             /\
                            /  \
                           /    \
      Internet------------A1    B1------AS 4156 (p-bit clear)
      Default (p-bit set)
                           NSSA 1

   Here A0, B0, and C0 are Area 0 routers, A1 and B1 are NSSA 1 routers,
   and A2 is an Area 2 router.  B0 is a border router for both NSSA 1
   and Area 2.

   If NSSA 1 routes for AS 4156 are installed on B0 so that the NSSA 1
   tree below A1 can take advantage of it, then A2's traffic to AS 4156
   is hijacked through B0 by B1, rather than its computed path through
   A0.

   The P-bit paradox can also appear with default routes.  By setting
   the P-bit on a Type-7 default LSA, and configuring DoNotAdvertise for
   [0,0] in an NSSA's border routers, the default route can be installed
   but not propagated.  In the example above, if A1's default is



Coltun, Fuller, Murphy                                         [Page 27]

Internet Draft              OSPF NSSA Option               December 2000


   installed on B0 and the range [0,0] has DoNotAdvertise set, then A2's
   default bound traffic is hijacked through B0 by A1 rather than the
   computed path through C0.
















































Coltun, Fuller, Murphy                                         [Page 28]

Internet Draft              OSPF NSSA Option               December 2000


Appendix F: Differences from RFC 1587

   This section documents the differences between this memo and RFC
   1587.  All differences are backward-compatible.  Implementations of
   this memo and of RFC 1587 will interoperate.

   F.1 Enhancements to OSPF summary LSAs.                      .

       The flooding of backbone summary LSAs (Type-3 LSAs) into the NSSA
       is now optional.  In RFC 1587 the flooding of backbone summary
       LSAs was mandated in order to guarantee inter-area routes are
       preferred over external routes. The current recommended default
       behavior is to import summary LSAs.  When summary routes are not
       imported, the default LSA originated by a NSSA border router into
       the NSSA should be a Type-3 summary LSA.

       See Sections 2.2 and 3.4 for details.

   F.2 Changes to Type-7 LSAs.

       The setting of the forwarding address in Type-7 LSAs has been
       further refined.

       See Section 3.3 for details.

   F.3 Changes to the Type-7 AS external routing calculation.

       The Type-7 external route calculation has been revised.  Most
       notably:

          o The path preference defined in OSPF Section 16.4.1 has been
            included.

          o A Type-7 default route with the P-bit clear will not be
            installed on an NSSA border router.  This protects the
            default routing of other OSPF Areas.  (See Appendix E.)

       See Section 3.5 for details.

   F.4 Changes to translating Type-7 LSAs into Type-5 LSAs

       The translator election algorithm of RFC 1587 has been updated to
       close a bug which results when the translator with the highest
       router ID loses connectivity to the AS's transit topology.  The
       default translator election process occurs only in the absence of
       an existing translator.

       The identity of the translator is optionally configurable, with



Coltun, Fuller, Murphy                                         [Page 29]

Internet Draft              OSPF NSSA Option               December 2000


       more than one allowed.  This allows the network designer to
       choose the most cost effective intra-AS route for NSSA originated
       Type-5 LSA aggregations of Type-7 LSAs.

       Self-originated non-default Type-7 LSAs are now included in the
       translation process.

       The translation process has been strengthened to close some of
       the weak points of RFC 1587.

       See Sections 4.1 and 4.2 for details.

   F.5 Changes to flushing translated Type-7 LSAs

       An NSSA border router, which was elected by the augmented RFC
       1587 translator selection process defined in Section 4.1 and has
       been deposed from translation duties by another NSSA border
       router, flushes its self-originated Type-5 LSAs that resulted
       from the aggregation of Type-7 LSAs.  This prevents these
       obsolete aggregations from short circuiting the preferred path
       through the new translator(s).  A deposed translator continues to
       maintain its self-originated Type-5 LSAs resulting from
       translation until they age out normally.

       See Section 4.3 for details.

   F.6 P-bit additions

       The P-bit default has been defined as clear.  RFC 1587 had no
       default setting. ( See Appendix C)

       A discussion on the packet forwarding impact of installing Type-7
       LSAs with the P-bit clear on NSSA border routers has been added
       as Appendix E.

















Coltun, Fuller, Murphy                                         [Page 30]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/