rfc1587.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

Network Working Group                                          R. Coltun
Request for Comments: 1587                  RainbowBridge Communications
Category: Standards Track                                      V. Fuller
                                                     Stanford University
                                                              March 1994


                          The OSPF NSSA Option

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Table Of Contents

   1.0 Abstract .................................................  1
   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 Address Ranges ....................................  5
   3.3 Type-7 LSAs ..............................................  5
   3.4 Originating Type-7 LSAs ..................................  7
   3.5 Calculating Type-7 AS External Routes ....................  8
   3.6 Incremental Updates ...................................... 10
   4.0 Originating Type-5 LSAs .................................. 10
   4.1 Translating Type-7 LSAs .................................. 10
   4.2 Flushing Translated Type-7 LSAs .......................... 13
   5.0 Acknowledgements ......................................... 13
   6.0 References ............................................... 13
   7.0 Security Considerations .................................. 13
   8.0 Authors' Addresses ....................................... 14
   Appendix A: Type-7 LSA Packet Format ......................... 15
   Appendix B: The Options Field ................................ 16
   Appendix C: Configuration Parameters ......................... 17

1.0  Abstract

   This document describes a new optional type of OSPF area, 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.



Coltun & Fuller                                                 [Page 1]

RFC 1587                    OSPF NSSA Option                  March 1994


2.0  Overview

2.1  Motivation

   Wide-area transit networks (such as the NSFNET regionals) often have
   connections to moderately-complex "leaf" sites.  A leaf site may have
   multiple IP network numbers assigned to it.

   Typically, one of the leaf site's networks is directly connected to a
   router provided and administered by the transit network while the
   others are distributed throughout and administered by the site.  From
   the transit network's perspective, all of the network numbers
   associated with the site make up a single "stub" entity.  For
   example, BARRNet has one site composed of a class-B network,
   130.57.0.0, and a class-C network, 192.31.114.0.  From BARRNet's
   perspective, this configuration looks something like this:

                    192.31.114
                        |
                      (cloud)
                  -------------- 130.57.4
                        |
                        |
                     ------ 131.119.13 ------
                     |BR18|------------|BR10|
                     ------            ------
                                          |
                                          V
                                  to BARRNet "core" OSPF system


   where the "cloud" consists of the subnets of 130.57 and network
   192.31.114, all of which are learned by RIP on router BR18.
   Topologically, this cloud looks very much like an OSPF stub area.
   The advantages of running the cloud as an OSPF stub area are:

             1. Type-5 routes (OSPF external link-state advertisements
                (LSAs)) are not advertised beyond the router
                labeled "BR10". This is advantageous because the
                link between BR10 and BR18 may be a low-speed link
                or the router BR18 may have limited resources.

             2. The transit network is abstracted to the "leaf"
                router BR18 by advertising only a default route
                across the link between BR10 and BR18.

             3. The cloud becomes a single, manageable "leaf" with
                respect to the transit network.



Coltun & Fuller                                                 [Page 2]

RFC 1587                    OSPF NSSA Option                  March 1994


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

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

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

2.2 Proposed Solution

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

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

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

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



Coltun & Fuller                                                 [Page 3]

RFC 1587                    OSPF NSSA Option                  March 1994


   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.  NSSA area border routers may
   be configured with address ranges so that several type-7 LSAs may be
   represented by a single type-5 LSA.

   In addition, an NSSA area border router can originate a default
   type-7 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 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
   the default route originated by an NSSA area border router is never
   translated into a type-5 LSA, however, a 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.

   It should also 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 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.






Coltun & Fuller                                                 [Page 4]

RFC 1587                    OSPF NSSA Option                  March 1994


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 processing of the
   received Hello packet to stop and the packet to be dropped.

3.2  Type-7 Address Ranges

   NSSA area 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 then be represented by in a single
   address range (as advertised by a type-5 LSA), just as a subnetted
   network is composed of many separate subnets.  Area border routers
   may then summarize type-7 routes by advertising a single type-5 route
   for each type-7 address range.  The type-5 route, resulting from a
   type-7 address range match will be distributed to all type-5 capable
   areas.  Section 4.1 gives the details of generating type-5 routes
   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 External route tag.

3.3  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.  An NSSA AS boundary routers is a router which



Coltun & Fuller                                                 [Page 5]

RFC 1587                    OSPF NSSA Option                  March 1994


   has an interface associated with the NSSA and is exchanging routing
   information with routers belonging to another AS.  As with type-5
   LSAs a separate type-7 LSA is originated for each destination
   network.  To support NSSA areas, 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
   specification).

      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
         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
         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.
         Type-5 LSAs that have been translated from type-7 LSAs