home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ospf-nssa-update-02.txt < prev    next >
Text File  |  1997-06-03  |  59KB  |  1,472 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. Network Working Group                                          R. Coltun
  7. Internet Draft                                              FORE Systems  
  8. Expiration Date: July 1997                                     V. Fuller
  9. File name: draft-ietf-ospf-nssa-02.txt                        BBN Planet
  10.                                                                P. Murphy
  11.                                                     US Geological Survey
  12.                                                               April 1997
  13.  
  14.  
  15.                           The OSPF NSSA Option
  16.  
  17. Status of this Memo
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups.  Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six
  25.    months and may be updated, replaced, or obsoleted by other documents
  26.    at any time.  It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as "work in progress".
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  31.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.    ftp.isi.edu (US West Coast).
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Coltun, Fuller & Murphy                                         [Page i]
  58.  
  59. Internet Draft              OSPF NSSA Option                  April 1997
  60.  
  61.  
  62. Table Of Contents
  63.  
  64.    1.0 Abstract .................................................  1
  65.    2.0 Overview .................................................  2
  66.    2.1 Motivation - transit networks ............................  2
  67.    2.2 Motivation - corporate networks ..........................  3
  68.    2.3 Proposed Solution ........................................  4
  69.    3.0 Implementation Details ...................................  6
  70.    3.1 The N-bit ................................................  6
  71.    3.2 Type-7 Address Ranges ....................................  7
  72.    3.3 Type-7 LSAs ..............................................  7
  73.    3.4 Originating Type-7 LSAs ..................................  8
  74.    3.5 Calculating Type-7 AS External Routes ....................  9
  75.    3.6 Incremental Updates ...................................... 12
  76.    4.0 Originating Type-5 LSAs .................................. 13
  77.    4.1 Translating Type-7 LSAs .................................. 13
  78.    4.2 Flushing Translated Type-7 LSAs .......................... 16
  79.    5.0 Acknowledgments .......................................... 17
  80.    6.0 References ............................................... 17
  81.    7.0 Security Considerations .................................. 17
  82.    8.0 Authors' Addresses ....................................... 18
  83.    Appendix A: Type-7 LSA Packet Format ......................... 19
  84.    Appendix B: The Options Field ................................ 20
  85.    Appendix C: Router-LSAs ...................................... 21
  86.    Appendix D: Configuration Parameters ......................... 23
  87.    Appendix E: Differences from RFC 1587 ........................ 24
  88.  
  89. 1.0  Abstract 
  90.  
  91.    This memo documents of an optional type of OSPF area which is
  92.    somewhat humorously referred to as a "not-so-stubby" area (or NSSA). 
  93.    NSSAs are similar to the existing OSPF stub area configuration option
  94.    but have the additional capability of importing AS external routes in 
  95.    a limited fashion.
  96.  
  97.    The OSPF NSSA Option was originally defined in RFC 1587.  The functional
  98.    differences between this memo and RFC 1587 are explained in Appendix D.
  99.    All differences, while expanding capability, are backward-compatible in
  100.    nature.  Implementations of this memo and of RFC 1587 will interoperate.
  101.  
  102.    Please send comments to ospf@gated.cornell.edu.
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. Coltun, Fuller & Murphy                                         [Page 1]
  116.  
  117. Internet Draft              OSPF NSSA Option                  April 1997
  118.  
  119.  
  120. 2.0  Overview
  121.  
  122. 2.1  Motivation - transit networks
  123.  
  124.  
  125.    Wide-area transit networks (such as the NSFNET regionals) often have
  126.    connections to moderately-complex "leaf" sites.  A leaf site may have
  127.    multiple IP network numbers assigned to it.
  128.  
  129.    Typically, one of the leaf site's networks is directly connected to a
  130.    router provided and administered by the transit network while the
  131.    others are distributed throughout and administered by the site.  From
  132.    the transit network's perspective, all of the network numbers
  133.    associated with the site make up a single "stub" entity.  For example,
  134.    BBN Planet has one site composed of a class-B network, 130.57.0.0,
  135.    and a class-C network, 192.31.114.0.  From BBN Planet's perspective,
  136.    this configuration looks something like this:
  137.  
  138.                     192.31.114
  139.                         |
  140.                       (cloud)
  141.                   -------------- 130.57.4
  142.                         |
  143.                         |
  144.                      ------ 131.119.13 ------
  145.                      |BR18|------------|BR10|
  146.                      ------            ------
  147.                                           |
  148.                                           V
  149.                                   to BBN Planet "core" OSPF system
  150.  
  151.  
  152.    where the "cloud" consists of the subnets of 130.57 and network
  153.    192.31.114, all of which are learned by RIP on router BR18.
  154.    Topologically, this cloud looks very much like an OSPF stub area.  The
  155.    advantages of running the cloud as an OSPF stub area are:
  156.  
  157.              1. Type-5 routes (OSPF external link-state advertisements
  158.                 (LSAs)) are not advertised beyond the router labeled
  159.                 "BR10".  This is advantageous because the link between
  160.                 BR10 and BR18 may be a low-speed link or the router BR18
  161.                 may have limited resources.
  162.  
  163.              2. The transit network is abstracted to the "leaf" router
  164.                 BR18 by advertising only a default route across the link
  165.                 between BR10 and BR18.
  166.  
  167.              3. The cloud becomes a single, manageable "leaf" with
  168.                 respect to the transit network.
  169.  
  170.  
  171.  
  172. Coltun, Fuller & Murphy                                         [Page 2]
  173.  
  174. Internet Draft              OSPF NSSA Option                  April 1997
  175.  
  176.  
  177.              4. The cloud can become, logically, a part of the transit
  178.                 network's OSPF routing system.
  179.  
  180.              5. Translated type-5 LSAs that are sent into the backbone
  181.                 from the cloud (which is a separate stub area) may be
  182.                 considered "leaf" nodes when performing the Dijkstra
  183.                 calculation.
  184.  
  185.    However, the current definition of the OSPF protocol [1] imposes
  186.    topological limitations which restrict simple cloud topologies from
  187.    becoming OSPF stub areas.  In particular, it is illegal for a stub
  188.    area to import routes external to OSPF; it is not possible for
  189.    routers BR18 and BR10 to both be members of the stub area and to
  190.    import the routes learned from RIP or other IP routing protocols as
  191.    type-5 (OSPF external LSAs) into the OSPF system.  In order to run
  192.    OSPF out to BR18, BR18 must be a member of a non-stub area or the
  193.    OSPF backbone before it can import routes other than its
  194.    directly-connected network(s).  Since it is not acceptable for BR18 to
  195.    maintain all of BBN Planet's external (type-5) routes, BBN Planet
  196.    is forced by OSPF's topological limitations to only run OSPF out to
  197.    BR10 and to run RIP between BR18 and BR10.
  198.  
  199.  
  200. 2.2  Motivation - corporate networks
  201.  
  202.    In a corporate network which supports a large corporate infrastructure it
  203.    is not uncommon for OSPF area 0 to have a large area infrastructure
  204.    injecting large routing tables into area 0.  Organizations within the
  205.    corporate infrastructure may routinely multi-home their non-0 OSPF areas
  206.    to strategically located backbone area 0 routers, either to provide
  207.    backbone redundancy or increase backbone connectivity or both.  Because
  208.    of these large routing tables, OSPF aggregation via summarization is
  209.    routinely used and recommended.  Stub areas are also recommended to keep
  210.    the size of the non-zero routing tables small.  Organizations within the
  211.    corporation are administratively autonomous and compete for corporate
  212.    backbone resources.  They also want isolation from each other in order
  213.    protect their own network resources within the organization.
  214.  
  215.    Consider a typical backbone connection, as shown on the next page, where
  216.    routers An, Bn are connected to their respective area n's and routers A0
  217.    and B0 are border routers to both area 1 and area 2.  Serial lines are
  218.    displayed, but several ethernets, not displayed, may also connect from
  219.    the connected areas at each router depicted internal to Areas 1 and 2. 
  220.    Assume the 192.243.192/20 and 192.243.208/22 clouds are subnetted with a
  221.    protocol foreign to the corporate OSPF process.  These processes could be
  222.    RIP, IGRP, or second and third OSPF processes separate from the corporate
  223.    OSPF backbone process.
  224.  
  225.  
  226.  
  227.  
  228.  
  229. Coltun, Fuller & Murphy                                         [Page 3]
  230.  
  231. Internet Draft              OSPF NSSA Option                  April 1997
  232.  
  233.  
  234.            /---A0-----Area 0(cloud)------B0---\
  235.            |   |                          |   |
  236.       56kbs|   |T1             19.2 dialup|   |T1
  237.            |   |                          |   |
  238.            |   A1-----Area 1(cloud)------B1   |
  239.            |   |   T1                 T1  |   |
  240.            | T1|                          |T1 |
  241.            |   \---192.243.192/20 cloud---/   |
  242.            |                                  |
  243.            \---A2-----Area 2(cloud)------B2---/
  244.                |   T1                 T1  |
  245.                |                          |   
  246.                \---192.243.208/22 cloud---/  
  247.  
  248.    As a matter of policy, the corporate network administrators want
  249.    192.243.192/20 and 192.243.208/22 aggregated to the backbone.  This
  250.    policy conflicts with both Area 1 and Area 2's desire to see the
  251.    aggregate's subnetted infrastructures learned from Area 1's internal
  252.    routers A1 and B1 and Area 2's internal routers A2 and B2 from which it
  253.    can make efficient routing decisions.  The current standard OSPF stub
  254.    area has no mechanism to support the redistribution of routes for
  255.    192.243.192/20 and 192.243.208/22 subnets within their respective areas. 
  256.    If one assumes that both the Area 1 and Area 2 clouds are extremely large
  257.    with internally very large routing tables originating from a complex OSPF
  258.    link state topology and subnetting scheme, neither Area 1 or Area 2 wants
  259.    to be at the mercy of either the other area's summary links
  260.    advertisements or external links advertisements.  Thus standard OSPF
  261.    areas are not an option either.
  262.  
  263.    Any solution to this dilemma must honor Area 1's path of choice through
  264.    A0 with redundancy through B0 while at the same time honoring Area 2's
  265.    path of choice through B0 with redundancy through A0.  Furthermore, such
  266.    a solution must support the aggregation of the externally learned
  267.    subnetted routing subdomain.
  268.  
  269.    2.3 Proposed Solution
  270.  
  271.    This document describes a new optional type of OSPF area, somewhat
  272.    humorously referred to as a "not-so-stubby" area (or NSSA), which has the
  273.    capability of importing external routes in a limited fashion.
  274.  
  275.    The OSPF specification defines two general classes of area configuration. 
  276.    The first allows type-5 LSAs to be flooded throughout the area.  In this
  277.    configuration, type-5 LSAs may be originated by routers internal to the
  278.    area or flooded into the area by area border routers.  These areas,
  279.    referred to herein as type-5 capable areas (or just plain areas in the
  280.    OSPF specification), are distinguished by the fact that they can carry
  281.    transit traffic.  The backbone is always a type-5 capable area.  The
  282.    second type of area configuration, called stub, allows no type-5 LSAs to
  283.  
  284.  
  285.  
  286. Coltun, Fuller & Murphy                                         [Page 4]
  287.  
  288. Internet Draft              OSPF NSSA Option                  April 1997
  289.  
  290.  
  291.    be propagated into/throughout the area and instead depends on default
  292.    routing to external destinations.
  293.  
  294.    NSSAs are defined in much the same manner as existing stub areas.  To
  295.    support NSSAs, a new option bit (the "N" bit) and a new type of LSA
  296.    (type-7) are defined.  The "N" bit ensures that routers belonging to a
  297.    NSSA agree on its configuration.  Similar to the stub area's use of the
  298.    "E" bit, both NSSA neighbors must agree on the setting of the "N" bit or
  299.    the OSPF neighbor adjacency will not form.
  300.  
  301.    Type-7 LSAs provide for carrying external route information within a
  302.    NSSA.  Type-7 AS External LSAs have virtually the same syntax as the
  303.    Type-5 AS External LSAs with the obvious exception of the link-state type
  304.    (see section 3.2 for more details).  There are two major semantic
  305.    differences between type-5 and type-7 LSAs.
  306.  
  307.           o  Type-7 LSAs may be originated by and advertised throughout
  308.              a NSSA; as with stub areas, type-5 LSAs are not flooded
  309.              into NSSAs and do not originate there, except on NSSA border 
  310.              routers.
  311.  
  312.           o  Type-7 LSAs are advertised only within a single NSSA; they
  313.              are not flooded into the backbone area or any other area by
  314.              border routers, though the information which they contain
  315.              can be propagated into the backbone area (see section 3.6).
  316.  
  317.    In order to allow limited exchange of external information across a NSSA
  318.    border, NSSA border routers will translate selected type-7 LSAs received
  319.    from the NSSA into type-5 LSAs.  These type-5 LSAs will be flooded to all
  320.    type-5 capable areas.  NSSA border routers may be configured with address
  321.    ranges so that several type-7 LSAs may be represented by a single type-5
  322.    LSA. The NSSA border routers which perform translation are configurable
  323.    thus creating efficient forwarding to type-5 LSA originating from
  324.    aggregated type-7s.
  325.  
  326.    In addition, a NSSA border router may originate a default type-7 LSA (IP
  327.    address of 0.0.0.0) into the NSSA, and must if no NSSA internal type-7
  328.    default route exists.  Default routes are necessary because NSSAs do not
  329.    receive full routing information and must have a default route to route
  330.    to AS-external destinations.  Like stub areas, NSSAs may be connected to
  331.    the backbone at more than one area border router, but may not be used as
  332.    a transit area.  Note that the default route originated by a NSSA border
  333.    router is never translated into a type-5 LSA, however, a default route
  334.    originated by a NSSA internal AS boundary router (one that is not also an
  335.    area border router) may be translated into a type-5 LSA.
  336.  
  337.    Like stub areas, the importing of OSPF summary routes (type-3 LSAs) into
  338.    NSSAs is a configuration option.  However particular care should be taken
  339.    to ensure that OSPF internal routes are always chosen over OSPF external
  340.    (type-7) routes.  This may happen when other IGPs, like RIP and ISIS,
  341.  
  342.  
  343. Coltun, Fuller & Murphy                                         [Page 5]
  344.  
  345. Internet Draft              OSPF NSSA Option                  April 1997
  346.  
  347.  
  348.    leak routing information between an OSPF NSSA and another OSPF area.  In
  349.    these cases, all OSPF summary routes should be imported into the effected
  350.    NSSAs.  The recommended default behavior is to import OSPF summary routes
  351.    into NSSAs.  Note that if a type-7 default originates from an internal
  352.    NSSA router, all summary routes must automatically be imported into the
  353.    NSSA.  This insures that OSPF internal routes are preferred over an
  354.    internal type-7 LSA default path which may cause inter-AS traffic to exit
  355.    the AS.
  356.  
  357.    In our transit example topologies the subnets of 130.57 and network
  358.    192.31.114 will still be learned by RIP on router BR18 but now both
  359.    BR10 and BR18 can be in a NSSA and all of BBN Planet's external routes
  360.    are hidden from BR18; BR10 becomes a NSSA border router and BR18 becomes
  361.    an AS boundary router internal to the NSSA.  BR18 will import the subnets
  362.    of 130.57 and network 192.31.114 as type-7 LSAs into the NSSA.  BR10 then
  363.    translates these routes into type-5 LSAs and floods them into BBN
  364.    Planet's backbone.
  365.  
  366.    In our corporate example, the subnets of 192.243.192/20 and
  367.    192.243.208/22 are learned via their respective routing process,
  368.    redistributed throughout NSSAreas 1 and 2, and then aggregated during the
  369.    translation process into a single Type-5 LSA which is flooded into Area
  370.    0.  Area 1 may configure A0 to perform translation with B0 standing by as
  371.    a backup translator, while Area 2 configures B0 as its translator with A0
  372.    its backup.
  373.  
  374. 3.0  Implementation Details
  375.  
  376. 3.1  The N-bit
  377.  
  378.    The N-bit ensures that all members of a NSSA agree on the area's
  379.    configuration.  Together, the N-bit and E-bit reflect an interface's
  380.    (and consequently the interface's associated area) external LSA
  381.    flooding capability.  As explained in section 10.5 of the OSPF
  382.    specification, if type-5 LSAs are not flooded into/throughout the
  383.    area, the E-bit must be clear in the option field of the received
  384.    Hello packets.  Interfaces associated with a NSSA will not send or
  385.    receive type-5 LSAs on that interface but may send and receive type-7
  386.    LSAs.  Therefore, if the N-bit is set in the options field, the E-bit
  387.    must be cleared.
  388.  
  389.    To support the NSSA option an additional check must be made in the
  390.    function that handles the receiving of the Hello packet to verify that
  391.    both the N-bit and the E-bit found in the Hello packet's option field
  392.    match the value of the options that have been configured in the receiving
  393.    interface.  A mismatch in the options causes processing of the received
  394.    Hello packet to stop and the packet to be dropped.
  395.  
  396.  
  397.  
  398.  
  399.  
  400. Coltun, Fuller & Murphy                                         [Page 6]
  401.  
  402. Internet Draft              OSPF NSSA Option                  April 1997
  403.  
  404.  
  405. 3.2  Type-7 Address Ranges
  406.  
  407.    NSSA border routers may be configured with type-7 address ranges. 
  408.  
  409.    Each address range is defined as an [address,mask] pair.  Many
  410.    separate type-7 networks may then be represented by a single address
  411.    range, just as a subnetted network is composed of many separate
  412.    subnets.  NSSA border routers may then summarize type-7 routes by
  413.    advertising a single type-5 route for each type-7 address range.  The
  414.    type-5 route, resulting from a type-7 address range match will be
  415.    distributed to all type-5 capable areas.  Section 4.1 gives the
  416.    details of generating type-5 routes from type-7 address ranges.
  417.  
  418.    A type-7 address range includes the following configurable items.
  419.  
  420.                o An [address,mask] pair.
  421.  
  422.                o A status indication of either Advertise or
  423.                  DoNotAdvertise.
  424.  
  425.                o An external route tag.
  426.  
  427. 3.3  Type-7 LSAs: NSSA External Link-State Advertisements
  428.  
  429.    External routes are imported into NSSAs as type-7 LSAs by NSSA AS
  430.    boundary routers.  A NSSA AS boundary routers (ASBR) is a router
  431.    which has an interface associated with the NSSA and is exchanging
  432.    routing information with routers belonging to another AS.  Like ASBRs,
  433.    a NSSA router indicates it is a NSSA ASBR by setting the E-bit in its
  434.    router links advertisement.  As with type-5 LSAs a separate type-7 LSA
  435.    is originated for each destination network.  To support NSSAs, the
  436.    link-state database must therefore be expanded to contain a type-7
  437.    LSA.
  438.  
  439.    Type 7-LSAs are identical to type-5 LSAs except for the following
  440.    (see section 12.4.4 "AS external links" in the OSPF specification).
  441.  
  442.       1. The type field in the LSA header is 7.
  443.  
  444.       2. Type-7 LSAs are only flooded within the originating NSSA.  The
  445.          flooding of type-7 LSAs follows the same rules as the flooding
  446.          of type 1-2 LSAs.
  447.  
  448.       3. Type-7 LSAs, which are kept within the NSSA's LSDB, are area
  449.          specific.  Type-5 LSAs, which are flooded to all type-5 capable
  450.          areas, have global scope and are kept in the router's LSDB.
  451.  
  452.       4. At the NSSA border router, selected type-7 LSAs are translated
  453.          into type 5-LSAs and flooded into the backbone.
  454.  
  455.  
  456.  
  457. Coltun, Fuller & Murphy                                         [Page 7]
  458.  
  459. Internet Draft              OSPF NSSA Option                  April 1997
  460.  
  461.  
  462.       5. Type 7 LSAs have a propagate (P) bit which is used to flag the
  463.          NSSA border router to translate the type-7 LSA into a type-5
  464.          LSA.  Examples of how the P-bit is used for loop avoidance are
  465.          in the following sections.
  466.  
  467.       6. Those type-7 LSAs that are to be translated into type-5 LSAs
  468.          must have their forwarding address set.  Type-5 LSAs that have
  469.          been translated from type-7 LSAs for the most part must contain
  470.          a forwarding address.  The exception to this is if the
  471.          translation to a type-5 LSA is the result of an address range
  472.          match, in which case the type-5 LSA will not contain a
  473.          forwarding address (see section 4.1 for details).  The
  474.          forwarding address contained in type-5 LSAs will result in more
  475.          efficient routing to the AS external networks when there are
  476.          multiple NSSA border routers.  Having the forwarding address in
  477.          the type-7 LSAs will ease the translation of type-7 into type-5
  478.          LSAs as the NSSA border router will not be required to compute
  479.          the forwarding address.
  480.  
  481.          If the network between the NSSA AS boundary router and the
  482.          adjacent AS is advertised into OSPF as an internal OSPF route,
  483.          the forwarding address should be the next hop address as is
  484.          currently done in type-5 LSAs, but unlike type-5 LSAs if the
  485.          intervening network is not advertised into OSPF as an internal
  486.          OSPF route, the forwarding address should be any one of the
  487.          router's active OSPF interface addresses.
  488.  
  489.    Type-5 and type-7 metrics and path types are directly comparable.
  490.  
  491. 3.4 Originating Type-7 LSAs
  492.  
  493. NSSA AS boundary routers may originate type-7 LSAs.  All NSSA  border
  494. routers must also be AS boundary routers since they all must have the
  495. capability of translating type-7 LSAs into type-5 LSAs (see section
  496. 4.1 for the translation algorithm).  NSSA  border routers must
  497. set the E-bit (external bit) as well as the B-bit (border bit) in
  498. their router (type-1) LSAs (both in the backbone and in the NSSA).
  499.  
  500.    When a NSSA internal AS boundary router originates a type-7 LSA that
  501.    it wants to be translated into a type-5 LSA by NSSA border routers
  502.    (and subsequently flooded into the backbone), it must set the P-bit
  503.    in the LSA header's option field and add a valid forwarding address in
  504.    the type-7 LSA.
  505.  
  506.    If a router is attached to another AS and is also a NSSA border
  507.    router, it may originate both a type-5 and a type-7 LSA for the same
  508.    network.  The type-5 LSA will be flooded to the backbone (and all
  509.    attached type-5 capable areas).  The type-7 LSA will be flooded into
  510.    the NSSA.  If this is the case, the P-bit must be reset in the type-7
  511.  
  512.  
  513. Coltun, Fuller & Murphy                                         [Page 8]
  514.  
  515. Internet Draft              OSPF NSSA Option                  April 1997
  516.  
  517.  
  518.    NSSA so the type-7 LSA isn't again translated into a type-5 LSA by
  519.    another NSSA border router.  If the border router only originates a
  520.    type-7 LSA, it may set the P-bit, thus allowing the network to be
  521.    aggregated/propagated during the type-7 translation.
  522.  
  523.    A type-7 default route (network 0.0.0.0) may be originated into the NSSA
  524.    by a NSSA border router or by a NSSA ASBR which is internal to the NSSA. 
  525.    The type-7 default route originated by the NSSA border router must have
  526.    the P-bit reset so that the default route originated by the NSSA border
  527.    router will not find its way out of the NSSA into the rest of the AS
  528.    system via another NSSA border router. 
  529.  
  530.    The type-7 default route originated by a NSSA ASBR which is not a NSSA
  531.    border router may have the P-bit set.  Type-7 routes which are originated
  532.    by a NSSA border router will not get added to the routing tables of other
  533.    NSSA border routers.  If no NSSA internal router originates a type-7
  534.    default route in the NSSA, then, like stub areas, a type-7 LSA with
  535.    default destination must be originated by all the NSSA's border routers
  536.    in order to support inter-area AS routing and inter-AS routing. 
  537.  
  538.    Note that a NSSA area border router which originates a type-7
  539.    default route would have to originate a type-5 default route before
  540.    other NSSA area border routers would see that default route.  An
  541.    internal type-7 default route whose P-bit is not set may only be
  542.    installed on a NSSA border router when it is the only non-backbone
  543.    OSPF area connected to it.  This restriction protects the default
  544.    routing of other areas attached to the NSSA border router as well any
  545.    ISP agreements of the NSSArea.
  546.  
  547.    In order for backbone summary internal routes to be preferred over 
  548.    external Type 7 routes, all implementations must support the optional
  549.    import of summary LSAs from the backbone into a NSSA, with the
  550.    exception of a (type-3) summary LSA for the default route.  The
  551.    import of summary LSAs is automatically activated when an type-7
  552.    default route is detected as originating from an internal NSSA ASBR,
  553.    regardless of the no-summary setting.  This protects the NSSA from
  554.    routing intra-AS traffic out the AS via a type-7 default route.
  555.  
  556.    Unlike the stub area case, a default route must not be injected into 
  557.    the NSSA as a summary (type-3) LSA.  The reason for this is that the
  558.    summary default route would be chosen over all more preferred type-7
  559.    default routes.
  560.  
  561. 3.5 Calculating Type-7 AS External Routes
  562.  
  563.    This calculation must be run when type-7 LSAs are processed during the AS
  564.    external route calculation.  This calculation will also process type-5
  565.    LSAs and may replace section 16.4 when processing type-5 LSAs.  If
  566.    section 16.4 is still used to process type-5 LSAs, NSSA ASBR routing
  567.    table entries are not to be used for the ASBR address calculation of
  568.    type-5 LSAs.
  569.  
  570. Coltun, Fuller & Murphy                                         [Page 9]
  571.  
  572. Internet Draft              OSPF NSSA Option                  April 1997
  573.  
  574.  
  575.    A NSSA border router should examine both type-5 LSAs and type-7 LSAs
  576.    if either type-5 or type-7 routes need to be updated or recalculated.
  577.    This is done as part of the AS external route calculation.  A NSSA
  578.    internal router should examine type-7 LSAs when type-7 routes need to
  579.    be recalculated.  When OSPF Section 16.4.1 path preference is applied
  580.    in step (6.c), NSSA and non-NSSA intra-AS paths have equal
  581.    preference.
  582.  
  583.    What follows is only a modest modification of the OSPF Version 2
  584.    Specification Section 16.4.  Original text is suffixed with <Moy>.  NSSA
  585.    specific text is suffixed with <NSSA>.
  586.  
  587.    AS external routes are calculated by examining AS-external-LSAs, be they
  588.    type-5 or type-7.  Each of the AS-external-LSAs is considered in turn.
  589.    Most AS-external-LSAs describe routes to specific IP destinations.  An
  590.    AS-external-LSA can also describe a default route for the Autonomous
  591.    System (Destination ID = DefaultDestination, network/subnet mask =
  592.    0x00000000).  For each AS-external-LSA <Moy with "or type-7">:
  593.  
  594.     (1) If the metric specified by the LSA is LSInfinity, or if the age
  595.         of the LSA equals MaxAge, then examine the next LSA.  <Moy>
  596.  
  597.     (2) If the LSA was originated by the calculating router itself,
  598.         examine the next LSA.  <Moy>
  599.  
  600.     (3) Call the destination described by the LSA N.  N's address is
  601.         obtained by masking the LSA's Link State ID with the
  602.         network/subnet mask contained in the body of the LSA.  Look up
  603.         the routing table entries (potentially one per attached area)
  604.         for the AS boundary router (ASBR) that originated the LSA.  If
  605.         no entries exist for router ASBR (i.e., ASBR is unreachable), do
  606.         nothing with this LSA and consider the next in the list.  <Moy>
  607.  
  608.         Else if the destination is a type-7 default route (destination =
  609.         DefaultDestination) and one of the following is true, then do
  610.         nothing with this LSA and consider the next in the list:
  611.  
  612.            o  The originator of the type-7 LSA and the calculating
  613.               router are both NSSA border routers.
  614.  
  615.            o  The calculating router is a border router, the LSA has its
  616.               P-bit clear, and at least two non-backbone OSPF areas
  617.               connect to the calculating router.  <NSSA>
  618.  
  619.         Else, this LSA describes an AS external path to destination N.    
  620.         Examine    the forwarding address specified in the    AS-external-LSA. 
  621.  
  622.         This indicates the IP address to which packets for the
  623.         destination should be forwarded.  <Moy>
  624.  
  625.  
  626.  
  627. Coltun, Fuller & Murphy                                        [Page 10]
  628.  
  629. Internet Draft              OSPF NSSA Option                  April 1997
  630.  
  631.    
  632.         If the forwarding address is set to 0.0.0.0, packets should be
  633.         sent to the ASBR itself.  <Moy>
  634.  
  635.         If the current LSA is type-5, among the multiple non-NSSA ASBR
  636.         routing table entries for the ASBR (both NSSA and non-NSSA ASBR
  637.         entries might exists on an NSSA border router), select the
  638.         preferred entry as follows <NSSA>:
  639.  
  640.            If RFC1583Compatibility is set to "disabled", prune the set
  641.            of routing table entries for the ASBR as described in OSPF
  642.            Section 16.4.1.  In any case, among the remaining routing
  643.            table entries, select the routing table entry with the least
  644.            cost; when there are multiple least cost routing table
  645.            entries the entry whose associated area has the largest OSPF
  646.            Area ID (when considered as an unsigned 32-bit integer) is
  647.            chosen.  <Moy>
  648.  
  649.         If the forwarding address is non-zero, look up the forwarding
  650.         address in the routing table.  The matching routing table entry
  651.         must specify an intra-area or inter-area path; if no such path
  652.         exists, do nothing with the LSA and consider the next in the
  653.         list.  <Moy>
  654.  
  655.     (4) Let X be the cost specified by the preferred routing table entry
  656.         for the ASBR/forwarding address, and Y the cost specified in the
  657.         LSA.  X is in terms of the link state metric, and Y is a type 1
  658.         or 2 external metric.  <Moy>
  659.  
  660.     (5) Now, look up the routing table entry for the destination N.  If
  661.         no entry exists for N, install the AS external path to N, with
  662.         the next hop equal to the list of next hops to the
  663.         ASBR/forwarding address, and advertising router equal to ASBR. 
  664.         If the external metric type is 1, then the path-type is set to
  665.         Type-1 external and the cost is equal to X + Y.  If the external
  666.         metric type is 2, the path-type is set to Type-2 external, the
  667.         link-state component of the route's cost is X, and the Type-2
  668.         cost is Y.  <Moy>
  669.  
  670.     (6) Otherwise compare the AS external path described by the LSA with
  671.         the existing paths in N's routing table entry, as follows.  If
  672.         the new path is preferred, it replaces the present paths in N's    
  673.         routing    table entry.  If the new path is of equal preference, it
  674.         is added to N's routing table entry's list of paths.  <Moy> 
  675.  
  676.         Preference is defined as follows:
  677.  
  678.         (a) Intra-area and inter-area paths are always preferred over AS    
  679.             external paths.  <Moy>
  680.  
  681.         (b) Type 1 external paths are always preferred over type 2
  682.  
  683.  
  684. Coltun, Fuller & Murphy                                        [Page 11]
  685.  
  686. Internet Draft              OSPF NSSA Option                  April 1997
  687.  
  688.  
  689.             external paths.  When all paths are type 2 external paths,
  690.             the paths with the smallest advertised type 2 metric are
  691.             always preferred.  <Moy>
  692.  
  693.         (c) If the new AS external path is still indistinguishable from
  694.             the current paths in N's routing table entry, and
  695.             RFC1583Compatibility is set    to "disabled", select the
  696.             preferred paths based on the intra-AS paths to the
  697.             ASBR/forwarding addresses, as specified in Section
  698.             16.4.1.  <Moy>
  699.  
  700.         (d) If the new AS external path is still indistinguishable from
  701.             the current paths in N's routing table entry, select the
  702.             preferred path based on a least cost comparison.  Type 1
  703.             external paths are compared by looking at the sum of the
  704.             distance to the forwarding address and the advertised type 1
  705.             metric (X+Y).  Type 2 external paths advertising equal type
  706.             2 metrics are compared by looking at the distance to the
  707.             forwarding addresses.  <Moy>
  708.  
  709.         (e) If the new paths are still indistinguishable the following
  710.             priorities apply (listed from highest to lowest) for
  711.             breaking the tie.
  712.  
  713.                a. Any type-5 LSA. 
  714.  
  715.                b. A type-7 LSA with the P-bit set and the forwarding
  716.                   address non-zero. 
  717.  
  718.                c. Any other type-7 LSA.  <NSSA>
  719.  
  720. 3.6 Incremental Updates
  721.  
  722.    Incremental updates for type-7 LSAs should be treated the same as
  723.    incremental updates for type-5 LSAs (see section 16.6 of the OSPF
  724.    specification).  That is, if a new instance of a type-7 LSA is
  725.    received it is not necessary to recalculate the entire routing table.
  726.    If there is already an OSPF internal route to the destination
  727.    represented by the type-7 LSA, no recalculation is necessary.
  728.    Otherwise, the procedure in the proceeding section will have to be
  729.    performed but only for the external routes (type-5 and type-7) whose
  730.    networks describe the same networks as the newly received LSA.
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740. Coltun, Fuller & Murphy                                        [Page 12]
  741.  
  742. Internet Draft              OSPF NSSA Option                  April 1997
  743.  
  744.  
  745. 4.0 Originating Type-5 LSAs
  746.  
  747. 4.1 Translating Type-7 LSAs Into Type-5 LSAs
  748.  
  749.    This step is performed as part of the NSSA's Dijkstra calculation after
  750.    type-5 and type-7 routes have been calculated.  If the calculating router
  751.    is not a NSSA border router this translation algorithm should be skipped.
  752.    It is not recommended that multiple NSSA border routers perform the
  753.    translation unless the efficient routing of packets through area 0 to a
  754.    NSSA partitioned by aggregation requires it.  It is normally sufficient
  755.    to have only one NSSA border router perform the translation.  Excessive
  756.    numbers of type-7 translators unnecessarily increase the size of the OSPF
  757.    link state data base.
  758.  
  759.    A new bit called bit Nt is added to the router links advertisement.  All
  760.    NSSA area border routers which are performing the translation set bit Nt in
  761.    their router links advertisement into the NSSA. 
  762.  
  763.    A new parameter called the NSSATranslateState is added to the OSPF area
  764.    data structure.  If a NSSA border router has 
  765.  
  766.         NSSATranslateState = enabled
  767.  
  768.    then this router always translates Type-7 LSAs into Type-5 LSAs for the
  769.    NSSA. 
  770.  
  771.    If a NSSA border router has
  772.  
  773.         NSSATranslateState = disabled
  774.  
  775.    and no NSSA border router for the NSSA has bit Nt set in its router links
  776.    advertisement and this router has the highest router ID among the NSSA
  777.    border router set, then this router performs the translation of type-7
  778.    LSAs into type-5 LSAs for the NSSA and NSSATranslateState should be set
  779.    to elected.
  780.  
  781.    Otherwise the translation algorithm should not be performed and
  782.    NSSATranslateState should remain set to disabled.
  783.  
  784.    Note that during the translation of type-7 LSAs into aggregated type-5
  785.    LSAs, the highest router ID is not necessarily the best choice for an
  786.    advertising router as all packets which are forwarded by a type-5 LSA
  787.    routing table entry originating from an aggregated type-7 LSA translation
  788.    are sent to the translator (As described below, the forwarding address is
  789.    not set in type-5 LSAs which originate from aggregated type-7 LSAs).  The
  790.    NSSATranslateState allows the network designer to configure the most cost
  791.    effective route to the NSSA's type-5 LSAs which originate from the
  792.    aggregation of type-7 LSAs.  Is cases of aggregate partitioning of the
  793.    NSSA, multiple translators may be required to effect efficient routing.
  794.  
  795.  
  796. Coltun, Fuller & Murphy                                        [Page 13]
  797.  
  798. Internet Draft              OSPF NSSA Option                  April 1997
  799.  
  800.  
  801.  
  802.    Indeed, all NSSA border routers could be set to perform translation, if
  803.    required.
  804.  
  805.    All installed type-7 LSA's should be examined including those type-7s
  806.    originated by the router itself (a set which may differ between NSSA
  807.    border routers of the same NSSArea).  This allows NSSA border routers to
  808.    propagate and/or aggregate locally originated type-7s during the
  809.    translation.  Locally originated type-7s are skipped during the external
  810.    route calculation.  Their installation status is external to OSPF.
  811.  
  812.    If the type-7 LSA (associated with the route being examined) has the
  813.    P-bit set and a non-zero forwarding address, the following steps
  814.    should be taken.
  815.  
  816.       The translation procedure must first check for a configured type-7
  817.       address range.  Recall that a type-7 address range consists of an
  818.       [address,mask] pair and a status indication of either Advertise or
  819.       DoNotAdvertise.  At most a single type-5 LSA is made for each
  820.       range.  If the route being examined falls within the type-7
  821.       address range, (i.e., the [address,mask] pair of the route is
  822.       equal to or a more specific instance of the [address,mask] pair of
  823.       the type-7 address range), one of following three actions may take
  824.       place.
  825.  
  826.          1. When the range's status indicates Advertise and the route's
  827.             address and mask are equal to the address and mask of the
  828.             type-7 range, a type-5 LSA should be originated if
  829.  
  830.             o there currently is no type-5 LSA originated from this
  831.               router corresponding to the type-7 LSA, or there is and
  832.  
  833.             o the path type or the metric in the corresponding type-5
  834.               LSA is different from the type-7 LSA or
  835.  
  836.             o the forwarding address in the corresponding type-5 LSA is
  837.               different from the type-7 LSA.
  838.  
  839.             The newly originated type-5 LSA will describe the same
  840.             network and have the same network mask, metrics, forwarding
  841.             address, external route tag and path type as the type-7 LSA,
  842.             however, the advertising router field will be the router ID
  843.             of this area border router.
  844.  
  845.          2. When the range's status indicates Advertise and the route's
  846.             address or mask indicates a more specific route (i.e., the
  847.             route's address is subsumed by the range or the route has a
  848.             longer mask), a type-5 LSA is generated with link-state ID
  849.  
  850.  
  851.  
  852. Coltun, Fuller & Murphy                                        [Page 14]
  853.  
  854. Internet Draft              OSPF NSSA Option                  April 1997
  855.  
  856.  
  857.  
  858.             equal to the range's address (if necessary, the link-state
  859.             ID can also have one or more of the range's "host" bits set;
  860.             see Appendix F of the OSPF specification for details), the
  861.             network mask, external route tag and path type will be set
  862.             to the configured type-7 range values.  The advertising
  863.             router field will be the router ID of this area border
  864.             router.  The forwarding address will not be set.  The path
  865.             type should always be set to the highest path type that is
  866.             subsumed by the net range.  The metric for the type-5 LSA
  867.             will be set as follows:
  868.  
  869.             o if the path type is external type 2, the type-5 metric
  870.               should be set to the largest type-7 metric subsumed by
  871.               this net range + 1.
  872.  
  873.             o if the path type is external type 1, the type-5 metric
  874.               should be set to the largest metric.
  875.  
  876.             For example, given a net range of [10.0.0.0, 255.0.0.0] for
  877.             an area that has type-7 routes of:
  878.  
  879.                     10.1.0.0 path type 1, metric 10
  880.                     10.2.0.0 path type 1, metric 11
  881.                     10.3.0.0 path type 2, metric 5
  882.  
  883.             a type-5 LSA will be generated with a path type of 2 and a
  884.             metric of 6.
  885.  
  886.             As another example, given a net range of [10.0.0.0,
  887.             255.0.0.0] for an area that has type-7 routes of:
  888.  
  889.                     10.1.0.0 path type 1, metric 10
  890.                     10.2.0.0 path type 1, metric 11
  891.                     10.3.0.0 path type 1, metric 5
  892.  
  893.             a type-5 LSA will be generated with a path type of 1 and a
  894.             metric of 11.
  895.  
  896.             These metric and path type rules will avoid routing loops in
  897.             the event that path type 1 and 2 are both used within the
  898.             area.
  899.  
  900.          3. When the range's status indicates DoNotAdvertise, the type-5
  901.             LSA is suppressed and the component networks remain hidden
  902.             from the rest of the AS.
  903.  
  904.       By default (given that the P-bit is set and the LSA has a non-zero
  905.       forwarding address) if a network is not contained in any
  906.  
  907.  
  908. Coltun, Fuller & Murphy                                        [Page 15]
  909.  
  910. Internet Draft              OSPF NSSA Option                  April 1997
  911.  
  912.       explicitly configured address range, a type-7 to type-5 LSA
  913.       translation will occur.
  914.  
  915.       A new instance of a type-5 LSA should be originated and flooded to
  916.       all attached type-5 capable areas if
  917.  
  918.             o  there currently is no type-5 LSA originated from this
  919.                router corresponding to the type-7 LSA, or there is and
  920.  
  921.             o  the path type or the metric in the corresponding type-5
  922.                LSA is different from the type-7 LSA or
  923.  
  924.             o  the forwarding address in the corresponding type-5 LSA is
  925.                different from the type-7 LSA.
  926.       The newly originated type-5 LSAs will describe the same network
  927.       and have the same network mask, metrics, forwarding address,
  928.       external route tag and path type as the type-7 LSA.  The
  929.       advertising router field will be the router ID of this area border
  930.       router.
  931.  
  932.       As with all newly originated type-5 LSAs, a type-5 LSA that is the
  933.       result of a type-7 to type-5 translation (type-7 range or default
  934.       case) is flooded to all attached type-5 capable areas.
  935.  
  936. 4.2 Flushing Translated Type-7 LSAs
  937.  
  938.    If a NSSA border router has translated a type-7 LSA to a type-5 LSA that
  939.    should no longer be translated, the type-5 LSA should be flushed (set to
  940.    MaxAge and flooded).  The translated type-5 LSA should be flushed
  941.    whenever the routing table entry that caused the translation changes so
  942.    that either the routing table entry is unreachable or the entry's
  943.    associated LSA is not a type-7 with the P-bit set and a non-zero
  944.    forwarding address.
  945.  
  946.    If a NSSA border router is translating type-7 LSA's into type-5 LSA's and
  947.    
  948.         NSSATranslateState = elected
  949.  
  950.    and a new router links advertisement arrives in the NSSA with bit Nt set,
  951.    then it should flush any of its type-5 LSAs originating from translated
  952.    type-7 LSAs and readvertise its router links advertisement into the NSSA
  953.    with bit Nt clear.
  954.  
  955.    This flushing keeps the number of type-7 translators at the minimum
  956.    number configured, either explicitly or by default.  Since the default
  957.    translator election process only occurs in the absence of a translator,
  958.    should a router with a higher router ID join the NSSA border router set
  959.    it will not necessarily assume translator duties.  Indeed, a previously
  960.    default elected translator should continue to perform translation duties
  961.    until supplanted by an NSSA border router whose Nt bit is set to true.
  962.    Such an event might happen due to by setting the NSSATranslateState to
  963.  
  964.  
  965. Coltun, Fuller & Murphy                                        [Page 16]
  966.  
  967. Internet Draft              OSPF NSSA Option                  April 1997
  968.  
  969.  
  970.    enabled or a topological rejoining of a partitioned NSSA.  This behavior
  971.    reduces the flushing of translated type-7 LSA's in the AS.
  972.  
  973.    Any change in the membership of the NSSA border router set or the setting
  974.    of their Nt bits resulting from updated router links advertisements
  975.    should force a NSSA border router whose NSSATranslateState is not set to
  976.    recheck and possibly elect or disable its type-7 translation status.
  977.  
  978. 5.0 Acknowledgments
  979.  
  980.    This document was produced by the OSPF Working Group, chaired by John
  981.    Moy.
  982.  
  983.    In addition, the comments of the following individuals are also
  984.    acknowledged:
  985.  
  986.                   Phani Jajjarvarpu  cisco
  987.                   Dino Farinacci     cisco
  988.                   Jeff Honig         Cornell University
  989.                   John Moy           Proteon, Inc.
  990.                   Doug Williams      IBM
  991.  
  992. 6.0 References
  993.  
  994.    [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
  995.  
  996.    [2] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,
  997.        Proteon, Inc., March 1994.
  998.  
  999. 7.0 Security Considerations
  1000.  
  1001.    Security issues are not discussed in this memo.
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021. Coltun, Fuller & Murphy                                        [Page 17]
  1022.  
  1023. Internet Draft              OSPF NSSA Option                  April 1997
  1024.  
  1025.  
  1026. 8.0 Authors' Addresses
  1027.  
  1028.    This update uses much of the original text from RFC 1587 authored by
  1029.  
  1030.    Rob Coltun
  1031.    Fore Systems
  1032.    6905 Rockledge Drive
  1033.    Suite 800
  1034.    Bethesada, Maryland 20817
  1035.  
  1036.    Phone: (301) 571-2521
  1037.    EMail: rcoltun@fore.com
  1038.  
  1039.  
  1040.    Vince Fuller
  1041.    BBN Planet
  1042.    3801 East Bayshore Road
  1043.    Palo Alto, California 94303
  1044.  
  1045.    Phone: (415) 528-7227
  1046.    EMail: vaf@wr.BBNPlanet.com
  1047.  
  1048.  
  1049.    New Sections, edits and revisions are authored by
  1050.  
  1051.    Pat Murphy
  1052.    US Geological Survey
  1053.    345 Middlefield Road
  1054.    Menlo Park, California 94560
  1055.    
  1056.    Phone: (415) 329-4044
  1057.    EMail: pmurphy@usgs.gov
  1058.  
  1059.    in support of the new features suggested by Pat Murphy.
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078. Coltun, Fuller & Murphy                                        [Page 18]
  1079.  
  1080. Internet Draft              OSPF NSSA Option                  April 1997
  1081.  
  1082.  
  1083. Appendix A: Type-7 Packet Format
  1084.  
  1085.           0                                32
  1086.           -----------------------------------
  1087.           |                | OPTS   |   7   |
  1088.           |                ------------------
  1089.           |        Link-State Header        |
  1090.           |                                 |
  1091.           -----------------------------------
  1092.           | Network Mask                    |
  1093.           -----------------------------------  ______
  1094.           |E| Tos  |        metric          |  .
  1095.           -----------------------------------  .  repeated for each TOS
  1096.           | Forwarding Address              |  .
  1097.           -----------------------------------  .
  1098.           | External Route Tag              |  ______
  1099.           -----------------------------------
  1100.  
  1101.    The definitions of the link-state ID, network mask, metrics and
  1102.    external route tag are the same as the definitions for the type-5
  1103.    LSAs (see A.4.5 in the OSPF specification) except for:
  1104.  
  1105.                The Forwarding Address
  1106.  
  1107.    If the network between the NSSA AS boundary router and the adjacent
  1108.    AS is advertised into OSPF as an internal OSPF route, the forwarding
  1109.    address should be the next hop address but if the intervening network
  1110.    is not advertised into OSPF as an internal OSPF route, the forwarding
  1111.    address should be any one of the router's active OSPF interface
  1112.    addresses.
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134. Coltun, Fuller & Murphy                                        [Page 19]
  1135.  
  1136. Internet Draft              OSPF NSSA Option                  April 1997
  1137.  
  1138.  
  1139. Appendix B: The Options Field
  1140.  
  1141.    The OSPF options field is present in OSPF Hello packets, Database
  1142.    Description packets and all link-state advertisements.  See appendix
  1143.    A.2 in the OSPF specification for a description of option field.  Six
  1144.    bits are assigned but only two (the E-bit and the N/P bit) are
  1145.    described completely in this section.
  1146.  
  1147.                    --------------------------------------
  1148.                    | * | * | DC | EA | N/P | MC | E | T |
  1149.                    --------------------------------------
  1150.  
  1151.                        The Type-7 LSA options field
  1152.  
  1153.  
  1154.              E-bit:  Type-5 AS external link advertisements are not
  1155.                      flooded into/through OSPF stub areas and NSSAs.
  1156.                      The E-bit ensures that all members of a stub area
  1157.                      agree on that area configuration.  The E-bit is
  1158.                      meaningful only in OSPF Hello packets.  When the
  1159.                      E-bit is reset in the Hello packet sent out a
  1160.                      particular interface, it means that the router
  1161.                      will neither send nor receive type-5 AS external
  1162.                      link state advertisements on that interface (in
  1163.                      other words, the interface connects to a stub
  1164.                      area or NSSArea).  Two routers will not become 
  1165.                      neighbors unless they agree on the state of the 
  1166.                      E-bit.
  1167.  
  1168.              N-bit:  The N-bit describes the router's NSSArea
  1169.                      capability.  The N-bit is used only in Hello
  1170.                      packets and ensures that all members of a NSSArea
  1171.                      agree on that area's configuration.  When the
  1172.                      N-bit is set in the Hello packet and sent out a
  1173.                      particular interface, it means that the router
  1174.                      will send and receive type-7 LSAs on that
  1175.                      interface.  Two routers will not form an adjacency
  1176.                      unless they agree on the state of the N-bit.  If
  1177.                      the N-bit is set in the options field, the E-bit
  1178.                      must be reset.
  1179.  
  1180.              P-bit:  The P-bit is used only in the type-7 LSA header.
  1181.                      It flags the NSSA border router to translate
  1182.                      the type-7 LSA into a type-5 LSA.
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190. Coltun, Fuller & Murphy                                        [Page 20]
  1191.  
  1192. Internet Draft              OSPF NSSA Option                  April 1997
  1193.  
  1194. Appendix C: Router-LSAs
  1195.  
  1196.    Router-LSAs are the Type 1 LSAs.  Each router in an area originates a
  1197.    router-LSA. The LSA describes the state and cost of the router's links
  1198.    (i.e., interfaces) to the area. All of the router's links to the area
  1199.    must be described in a single router-LSA. For details concerning the
  1200.    construction    of router-LSAs,    see the OSPF Specification, Section 12.4.1.
  1201.  
  1202.  
  1203.     0            1            2            3
  1204.     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
  1205.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1206.        |        LS age           |     Options   |       1       |
  1207.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1208.        |            Link State ID                   |
  1209.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1210.        |             Advertising Router                   |
  1211.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1212.        |             LS    sequence number                   |
  1213.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1214.        |     LS checksum           |         length           |
  1215.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1216.        |  0  Nt|W|V|E|B|    0      |        # links           |
  1217.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1218.        |              Link ID                   |
  1219.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1220.        |             Link Data                   |
  1221.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1222.        |     Type      |     # TOS     |    TOS 0 metric           |
  1223.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1224.        |      TOS      |    0      |        metric           |
  1225.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1226.        |                  ...                   |
  1227.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1228.        |      TOS      |    0      |        metric           |
  1229.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1230.        |              Link ID                   |
  1231.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1232.        |             Link Data                   |
  1233.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1234.        |                  ...                   |
  1235.  
  1236.  
  1237.     In router-LSAs, the    Link State ID field is set to the router's OSPF
  1238.     Router ID.    The T-bit is set in the    LSA's Option field if and only
  1239.     if the router is able to calculate a separate set of routes    for each
  1240.     IP TOS.  Router-LSAs are flooded throughout    a single area only.
  1241.  
  1242.  
  1243.  
  1244.  
  1245. Coltun, Fuller & Murphy                                        [Page 21]
  1246.  
  1247. Internet Draft             OSPF Version 2          September 1996
  1248.  
  1249.  
  1250.     bit    V
  1251.     When set, the router is    an endpoint of one or more fully
  1252.     adjacent virtual links having the described area as Transit area
  1253.     (V is for virtual link endpoint).
  1254.  
  1255.     bit    E
  1256.     When set, the router is    an AS boundary router (E is for
  1257.     external).
  1258.  
  1259.     bit    B
  1260.     When set, the router is    an area    border router (B is for    border).
  1261.  
  1262.     bit    W
  1263.     When set, the router is a wild-card multicast receiver (W is for
  1264.         for wild).
  1265.  
  1266.     bit    Nt
  1267.     When set, the router is    a NSSA border router which translates type-7
  1268.         LSAs into type-5 LSAs (Nt is for NSSA translation).
  1269.  
  1270.    The remainder of the router links specification is as defined in the OSPF
  1271.    Specification, Section A.4.2
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298. Coltun, Fuller & Murphy                                        [Page 22]
  1299.  
  1300. Internet Draft              OSPF NSSA Option                  April 1997
  1301.  
  1302.  
  1303. Appendix D:  Configuration Parameters
  1304.  
  1305.    Appendix C.2 in the OSPF specification lists the area parameters.  The
  1306.    area ID, list of address ranges for type-3 summary routes and
  1307.    authentication type remain unchanged.  Section 3.2 of this document lists
  1308.    the configuration parameters for type-7 address ranges.  The following
  1309.    parameter is added to the NSSArea data structure:
  1310.  
  1311.    NSSATranslateState 
  1312.        This parameter indicates whether or not an NSSA Border router is
  1313.        performing NSSA translation of type-7 LSAs into type-5 LSAs and
  1314.        flooding the translated type-5 LSAs into the AS.  If the parameter is
  1315.        set to "enabled", translation is always performed.  If the parameter
  1316.        is set to "elected", it means translation is being performed because
  1317.        the router was chosen during the default election process. If the
  1318.        parameter is set to "disabled" the NSSA border router is not
  1319.        currently performing type-7 translation.  "disabled" is the default
  1320.        setting.  (See Section 4.1.)
  1321.  
  1322.    For NSSAs the external capabilities of the area must be set to accept
  1323.    type-7 external routes.  Additionally there must be a way of
  1324.    configuring the NSSA border router to send a default route into the
  1325.    NSSArea using a specific metric (type 1 or type 2 and the actual cost).
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357. Coltun, Fuller & Murphy                                        [Page 23]
  1358.  
  1359. Internet Draft              OSPF NSSA Option                  April 1997
  1360.  
  1361.  
  1362. Appendix E: Differences from RFC 1587
  1363.  
  1364.    This section documents the differences between this    memo and RFC
  1365.    1587.  All differences are backward-compatible.  Implementations of
  1366.    this memo and of RFC 1587 will interoperate.
  1367.  
  1368.    E.1 Enhancements to OSPF summary LSAs.                      .
  1369.  
  1370.        The flooding of backbone summary LSAs (type-3 LSAs) into the NSSA
  1371.        is now optional.  In RFC 1587 the flooding of backbone summary
  1372.        LSAs was mandated in order to guarantee inter-area routes are
  1373.        preferred over external routes.  The current recommended default
  1374.        behavior is to flood summary LSAs.
  1375.  
  1376.        See sections 2.2 and 3.4 for details.
  1377.  
  1378.    E.2 Changes to the type-7 AS external routing calculation.
  1379.  
  1380.        The type-7 external route calculation has been revised.  Most
  1381.        notably:
  1382.  
  1383.          o The path preference defined in OSPF Section 16.4.1 has been
  1384.            included.
  1385.  
  1386.          o A type-7 default route with the P-bit clear will not be installed
  1387.            on a NSSA border router which connects multiple non-backbone
  1388.            areas.  This protects the default routing of other OSPF Areas as
  1389.            well as any ISP agreements of the originating NSSArea.
  1390.  
  1391.          o The type-7 AS external route calculation may now compute
  1392.            type-5 external paths.
  1393.  
  1394.        See Section 3.5 for details.
  1395.  
  1396.    E.3 Changes to translating type-7 LSAs into type-5 LSAs
  1397.  
  1398.        NSSA border routers which perform the translation are now optionally
  1399.        configurable, with more than one allowed.  This allows the network
  1400.        designer to choose the most cost effective intra-AS route for NSSA
  1401.        type-7 aggregates propagated into the AS.  Furthermore, since
  1402.        different NSSA border routers may install different sets of type-7
  1403.        LSA routes, the cost effectiveness of non-aggregated type-7
  1404.        propagation may also be maximized.
  1405.  
  1406.        All installed type-7 LSA's including those originated by the NSSA
  1407.        border router are processed for translation.  This allows the
  1408.        NSSA border router to propagate and/or aggregate locally
  1409.        originated type-7s utilizing the type-5 translation process. 
  1410.        NSSA RFC 1587 required locally originated type-7 LSAs be paired
  1411.  
  1412.  
  1413. Coltun, Fuller & Murphy                                        [Page 24]
  1414.  
  1415. Internet Draft              OSPF NSSA Option                  April 1997
  1416.  
  1417.  
  1418.        with locally originated type-5 LSAs for the external path to be
  1419.        seen by the AS (Note that locally originated type-7s are skipped
  1420.        during the external route calculation).
  1421.  
  1422.        The default translator election process occurs only in the absence of
  1423.        a translator amongst the NSSA border router set.
  1424.  
  1425.        See Section 4.1 for details.
  1426.  
  1427.    E.4 Changes to flushing translated type-7 LSAs
  1428.  
  1429.        A NSSA border router which was elected by the default selection
  1430.        process of RFC 1587, terminates its translation duties and flushes
  1431.        its translated type-7 LSAs from the AS when another translator
  1432.        presents itself in the NSSA.  This keeps the number of translators at
  1433.        a minimum.
  1434.  
  1435.        See Section 4.2 for details.
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458.  
  1459.  
  1460.  
  1461.  
  1462.  
  1463.  
  1464.  
  1465.  
  1466.  
  1467.  
  1468.  
  1469.  
  1470. Coltun, Fuller & Murphy                                        [Page 25]
  1471.  
  1472.