draft-ietf-ospf-nssa-option-00.txt   rfc1587.txt 
Network Working Group R. Coltun
Internet Draft OSPF NSSA Option October 1992 Request for Comments: 1587 RainbowBridge Communications
Expiration Date: April 1993 Category: Standards Track V. Fuller
Stanford University
The OSPF NSSA Option March 1994
Rob Coltun
Consultant
(301) 340-9416
rcoltun@ni.umd.edu
Vince Fuller
BARRNet
Stanford University
Pine Hall 115
Stanford, CA, 94305-4122
vaf@Valinor.Stanford.EDU
Status of this Memo
This document is an Internet Draft. Internet Drafts are working The OSPF NSSA Option
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 Status of this Memo
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Inter-
net Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet This document specifies an Internet standards track protocol for the
Draft directory to learn the current status of this or any other Internet community, and requests discussion and suggestions for
Internet Draft. 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 Table Of Contents
1.0 Abstract ................................................. 2 1.0 Abstract ................................................. 1
2.0 Overview ................................................. 2 2.0 Overview ................................................. 2
2.1 Motivation ............................................... 2 2.1 Motivation ............................................... 2
2.2 Proposed Solution ........................................ 3 2.2 Proposed Solution ........................................ 3
3.0 Implementation Details ................................... 5 3.0 Implementation Details ................................... 5
3.1 The N-bit ................................................ 5 3.1 The N-bit ................................................ 5
3.2 Type-7 LSAs .............................................. 5 3.2 Type-7 Address Ranges .................................... 5
3.3 Originating Type-7 LSAs .................................. 6 3.3 Type-7 LSAs .............................................. 5
3.4 Calculating Type-7 AS External Routes .................... 7 3.4 Originating Type-7 LSAs .................................. 7
3.5 Incremental Updates ...................................... 9 3.5 Calculating Type-7 AS External Routes .................... 8
4.0 Originating Type-5 LSAs .................................. 9 3.6 Incremental Updates ...................................... 10
4.1 Translating Type-7 LSAs .................................. 9 4.0 Originating Type-5 LSAs .................................. 10
4.2 Flushing Translated Type-7 LSAs .......................... 10 4.1 Translating Type-7 LSAs .................................. 10
5.0 Acknowledgements ......................................... 10 4.2 Flushing Translated Type-7 LSAs .......................... 13
6.0 References ............................................... 10 5.0 Acknowledgements ......................................... 13
Appendix A: Type-7 LSA Packet Format ......................... 11 6.0 References ............................................... 13
Appendix B: The Options Field ................................ 11 7.0 Security Considerations .................................. 13
Appendix C: Configuration Parameters ......................... 12 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 1.0 Abstract
This document describes a new optional type of OSPF area, some- This document describes a new optional type of OSPF area, somewhat
what humorously referred to as a "not-so-stubby" area (or NSSA). humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs
NSSAs are similar to the existing OSPF stub area configuration are similar to the existing OSPF stub area configuration option but
option but have the additional capability of importing AS exter- have the additional capability of importing AS external routes in a
nal routes in a limited fashion. limited fashion.
2.0 Overview 2.0 Overview
2.1 Motivation 2.1 Motivation
Wide-area transit networks (such as the NSFNET regionals) often Wide-area transit networks (such as the NSFNET regionals) often have
have connections to moderately-complex "leaf" sites. A leaf site connections to moderately-complex "leaf" sites. A leaf site may have
may have multiple IP network numbers assigned to it. multiple IP network numbers assigned to it.
Typically, one of the leaf site's networks is directly connected Typically, one of the leaf site's networks is directly connected to a
to a router provided and administered by the transit network router provided and administered by the transit network while the
while the others are distributed throughout and administered by others are distributed throughout and administered by the site. From
the site. From the transit network's perspective, all of the the transit network's perspective, all of the network numbers
network numbers associated with the site make up a single "stub" associated with the site make up a single "stub" entity. For
entity. For example, BARRNet has one site composed of a class-B example, BARRNet has one site composed of a class-B network,
network, 130.57.0.0, and a class-C network, 192.31.114.0. From 130.57.0.0, and a class-C network, 192.31.114.0. From BARRNet's
BARRNet's perspective, this configuration looks something like perspective, this configuration looks something like this:
this:
192.31.114 192.31.114
| |
(cloud) (cloud)
-------------- 130.57.4 -------------- 130.57.4
| |
| |
------ 131.119.13 ------ ------ 131.119.13 ------
|BR18|------------|BR10| |BR18|------------|BR10|
------ ------ ------ ------
| |
V V
to BARRNet "core" OSPF system to BARRNet "core" OSPF system
where the "cloud" consists of the subnets of 130.57 and network 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. 192.31.114, all of which are learned by RIP on router BR18.
Topologically, this cloud looks very much like an OSPF stub area. Topologically, this cloud looks very much like an OSPF stub area.
The advantages of running the cloud as an OSPF stub area are: The advantages of running the cloud as an OSPF stub area are:
1. Type-5 routes (OSPF external link-state advertise- 1. Type-5 routes (OSPF external link-state advertisements
ments (LSAs)) are not advertised into the cloud (LSAs)) are not advertised beyond the router
utilizing less resources in the (perhaps limited) labeled "BR10". This is advantageous because the
cloud's routers. 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 cloud 2. The transit network is abstracted to the "leaf"
by advertising a default route into the cloud. router BR18 by advertising only a default route
across the link between BR10 and BR18.
3. The cloud becomes a single manageable entity to the 3. The cloud becomes a single, manageable "leaf" with
transit network. respect to the transit network.
4. The cloud can become part of the transit network's 4. The cloud can become, logically, a part of the transit
OSPF routing system. network's OSPF routing system.
However, the current definition of the OSPF protocol [OSPF] 5. Translated type-5 LSAs that are sent into the
imposes topological limitations which restrict simple cloud topo- backbone from the cloud (which is a separate
logies from becoming OSPF stub areas. In particular, it is ille- stub area) may be considered "leaf" nodes
gal for a stub area to import routes external to OSPF; it is not when performing the Dijkstra calculation.
possible for routers BR18 and BR10 to both be members of the stub
area and to import the routes learned from RIP or other IP rout-
ing protocols as type-5 (OSPF external LSAs) into the OSPF sys-
tem. In order to run OSPF out to BR18, BR18 must be a member of
a non-stub area or the OSPF backbone to import routes other than
its directly-connected network(s). Since it is not acceptable
for BR18 to maintain all of BARRNet's external (type-5) routes,
BARRNet is forced by OSPF's topological limitations to run OSPF
out to BR10 and to run RIP between BR18 and BR10.
2.2 Proposed Solution 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.
This document describes a new optional type of OSPF area, some- 2.2 Proposed Solution
what humorously referred to as a "not-so-stubby" area (or NSSA)
which has the capability of importing external routes in a lim-
ited fashion.
The OSPF specification defines two general classes of area confi- This document describes a new optional type of OSPF area, somewhat
guration. The first allows type-5 LSAs to be flooded throughout humorously referred to as a "not-so-stubby" area (or NSSA) which has
the area. In this configuration, type-5 LSAs may be originated the capability of importing external routes in a limited fashion.
by routers internal to the area or flooded into the area by area
border routers. These areas, referred to herein as type-5 capa-
ble areas (or just plain areas in the OSPF spec), are dis-
tinguished by the fact that they can carry transit traffic. The
backbone is always a type-5 capable area. The second type of
area configuration, called stub, allows no type-5 LSAs to be pro-
pagated into/throughout the area and instead depends on default
routing to external destinations.
NSSAs are defined in much the same manner as existing stub areas. The OSPF specification defines two general classes of area
To support NSSAs, a new option bit (the "N" bit) and a new type configuration. The first allows type-5 LSAs to be flooded throughout
of LSA (type-7) area defined. The "N" bit ensures that routers the area. In this configuration, type-5 LSAs may be originated by
belonging to an NSSA agree on its configuration. Similar to the routers internal to the area or flooded into the area by area border
stub area's use of the "E" bit, both NSSA neighbors must agree on routers. These areas, referred to herein as type-5 capable areas (or
the setting of the "N" bit or the OSPF neighbor adjacency will just plain areas in the OSPF spec), are distinguished by the fact
not form. 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.
Type-7 LSAs provide for carrying external route information NSSAs are defined in much the same manner as existing stub areas. To
within an NSSA. Type-7 AS External LSAs have virtually the same support NSSAs, a new option bit (the "N" bit) and a new type of LSA
syntax as the Type-5 AS External LSAs with the obvious exception (type-7) area defined. The "N" bit ensures that routers belonging to
of the link-state type (see section 3.2 for more details). There an NSSA agree on its configuration. Similar to the stub area's use
are two major semantic differences between type-5 and type-7 of the "E" bit, both NSSA neighbors must agree on the setting of the
LSAs. "N" bit or the OSPF neighbor adjacency will not form.
Type-7 LSAs provide for carrying external route information within an
NSSA. Type-7 AS External LSAs have virtually the same syntax as the
Type-5 AS External LSAs with the obvious exception of the link-state
type (see section 3.2 for more details). There are two major semantic
differences between type-5 and type-7 LSAs.
o Type-7 LSAs may be originated by and advertised o Type-7 LSAs may be originated by and advertised
throughout an NSSA; as with stub areas, NSSA's do not throughout an NSSA; as with stub areas, NSSA's do not
receive or originate type-5 LSAs. receive or originate type-5 LSAs.
o Type-7 LSAs are advertised only within a single NSSA; o Type-7 LSAs are advertised only within a single NSSA;
they are not flooded into the backbone area or any they are not flooded into the backbone area or any
other area by border routers, though the information other area by border routers, though the information
which they contain can be propagated into the backbone which they contain can be propagated into the backbone
area (see section 3.6). area (see section 3.6).
In order to allow limited exchange of external information across In order to allow limited exchange of external information across an
an NSSA area border, NSSA border routers will translate selected NSSA area border, NSSA border routers will translate selected type-7
type-7 LSAs received from the NSSA into type-5 LSAs. These LSAs received from the NSSA into type-5 LSAs. These type-5 LSAs will
type-5 LSAs will be flooded to all type-5 capable areas. In be flooded to all type-5 capable areas. NSSA area border routers may
addition, an NSSA area border router can originate a default be configured with address ranges so that several type-7 LSAs may be
type-7 LSA (IP address of 0.0.0.0) into the NSSA (note that the represented by a single type-5 LSA.
default route originated by an NSSA area border router is never
translated into a type-5 LSA). As with stub areas and the sum-
mary default route, default routes are necessary because NSSAs do
not receive full routing information and therefore must have a
default route to route to AS-external destinations. As with stub
areas, NSSAs may be connected to the backbone at more than one
area border router, but may not be used as a transit area.
It should be noted that unlike stub areas, all OSPF summary In addition, an NSSA area border router can originate a default
routes (type-3 LSAs) must be imported into NSSAs. This is to type-7 LSA (IP address of 0.0.0.0) into the NSSA. Default routes are
ensure that OSPF internal routes are always chosen over OSPF necessary because NSSAs do not receive full routing information and
external (type-7) routes. 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.
In our example topology the subnets of 130.57 and network It should also be noted that unlike stub areas, all OSPF summary
192.31.114, will still be learned by RIP on router BR18 but now routes (type-3 LSAs) must be imported into NSSAs. This is to ensure
both BR10 and BR18 can be in an NSSA and all of BARRNets external that OSPF internal routes are always chosen over OSPF external
routes are hidden from BR18; BR10 becomes an NSSA area border (type-7) routes.
router and BR18 becomes an AS boundary router internal to the
NSSA. BR18 will import the subnets of 130.57 and network
192.31.114 as type-7 LSAs into the NSSA. BR10 then translates
these routes into type-5 LSAs and floods them into BARRNet's
backbone.
3.0 Implementation Details In our example topology the subnets of 130.57 and network 192.31.114,
will still be learned by RIP on router BR18 but now both BR10 and
BR18 can be in an NSSA and all of BARRNets external routes are hidden
from BR18; BR10 becomes an NSSA area border router and BR18 becomes
an AS boundary router internal to the NSSA. BR18 will import the
subnets of 130.57 and network 192.31.114 as type-7 LSAs into the
NSSA. BR10 then translates these routes into type-5 LSAs and floods
them into BARRNet's backbone.
3.1 The N-bit 3.0 Implementation Details
The N-bit ensures that all members of a NSSA agree on the area's 3.1 The N-bit
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 N-bit ensures that all members of a NSSA agree on the area's
the function that handles receiving Hello packet to verify that configuration. Together, the N-bit and E-bit reflect an interface's
both the N-bit and the E-bit found in the Hello packet's option (and consequently the interface's associated area's) external LSA
field match the value of the options that have been configured in flooding capability. As explained in section 10.5 of the OSPF
the receiving interface. A mismatch in the options causes pro- specification, if type-5 LSAs are not flooded into/throughout the
cessing of the received Hello packet to stop and the packet to be area, the E-bit must be clear in the option field of the received
dropped. 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.
3.2 Type-7 LSAs: NSSA External Link-State Advertisements 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.
External routes are imported into NSSAs as type-7 LSAs by the 3.2 Type-7 Address Ranges
NSSA's AS boundary routers. That is, type-7 LSAs are originated
by the NSSA's AS boundary routers that have an interface associ-
ated with the NSSA and are exchanging routing information with
routers belonging to another AS (or importing static routes). As
with type-5 LSAs a separate LSA is originated for each destina-
tion network. The link-state database must therefore be expanded
to contain a type-7 LSA.
Type 7-LSAs are identical to type-5 LSAs except for the following NSSA area border routers may be configured with type-7 address
(see section 12.3.4 "AS external links" in the OSPF specifica- ranges. Each address range is defined as an [address,mask] pair.
tion). Many separate type-7 networks may then be represented by in a single
1. The type field in the LSA header is 7. 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.
2. Type-7 LSAs are only flooded within the NSSA. A type-7 address range includes the following configurable items.
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 o An [address,mask] pair.
specific) whereas because type-5 LSAs are flooded to
all type-5 capable areas, type-5 LSAs have global scope
in the router's LSDB.
4. At the area border router, selected type-7 LSAs are o A status indication of either Advertise or
translated into type 5-LSAs and flooded into the DoNotAdvertise.
backbone.
5. Type 7 LSAs have a propagate (P) bit which is o External route tag.
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 3.3 Type-7 LSAs: NSSA External Link-State Advertisements
LSAs must have their forwarding address set;
all type-5 LSAs that have been translated from type-7 LSAs
must contain a forwarding address.
The forwarding address contained in type-5 LSAs will
result in more efficient routing to the AS external
networks when there are multiple NSSA area
border routers. Having the forwarding address in the
type-7 LSAs will ease the translation of type-7 into
type-5 LSAs as the NSSA area border router will
not be required to compute the forwarding address.
If the network between the NSSA AS boundary router and the External routes are imported into NSSAs as type-7 LSAs by the NSSA's
adjacent AS is advertised into OSPF as an internal OSPF AS boundary routers. An NSSA AS boundary routers is a router which
route, the forwarding address should be the next hop has an interface associated with the NSSA and is exchanging routing
address as is currently done in type-5 LSAs, but unlike information with routers belonging to another AS. As with type-5
type-5 LSAs if the intervening network is not advertised LSAs a separate type-7 LSA is originated for each destination
into OSPF as an internal OSPF route, the forwarding network. To support NSSA areas, the link-state database must
address should be any one of the router's active OSPF therefore be expanded to contain a type-7 LSA.
interface addresses.
Type-5 and type-7 metrics and path types are directly comparable. 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).
3.3 Originating Type-7 LSAs 1. The type field in the LSA header is 7.
NSSA AS boundary routers may originate type-7 LSAs. All NSSA 2. Type-7 LSAs are only flooded within the NSSA.
area border routers must also be AS boundary routers since they The flooding of type-7 LSAs follow the same rules
all must have the capability of translating a type-7 LSAs into a as the flooding of type 1-4 LSAs.
type-5 LSAs (see section 3.6 routes for the translation algo-
rithm). NSSA area border routers must set the E-bit (external
bit) as well as the B-bit (border bit) in its router (type-1)
LSA.
When an NSSA internal AS boundary router originates a type-7 LSA 3. Type-7 LSAs are kept within the NSSA's LSDB (are
that it wants to be translated into a type-5 LSA by the NSSA area area specific) whereas because type-5 LSAs are
border router (and subsequently flooded into the backbone), it flooded to all type-5 capable areas, type-5 LSAs
must set the P-bit in the LS header's option field and add a global scope in the router's LSDB.
valid forwarding address in the type-7 LSA.
If a router is attached to another AS and is also an NSSA area 4. At the area border router, selected type-7 LSAs are
border router, it may originate a both a type-5 and a type-7 LSA translated into type 5-LSAs and flooded into the
for the same network. The type-5 LSA will be flooded to the backbone.
backbone (and all attached type-5 capable areas) and the type-7
will be flooded into the NSSA. If this is the case, the P-bit
must be reset in the type-7 NSSA so the type-7 LSA isn't again
translated into a type-5 LSA by another NSSA area border router.
A type-7 default route (network 0.0.0.0) may be originated into 5. Type 7 LSAs have a propagate (P) bit which is
the NSSA by an NSSA area border router or by an NSSA AS boundary used to flag the area border router to translate the
router which is internal to the NSSA. The type-7 default route type-7 LSA into a type-5 LSA. Examples of how the P-bit
originated by the NSSA area border router must have the P-bit is used for loop avoidance are in the following sections.
reset so that the default route originated by the NSSA area
border router will not find its way out of the NSSA into the rest
of the AS system via another NSSA area border router. The type-7
default originated by an NSSA AS boundary router which is inter-
nal to the NSSA may have the P-bit set. Type-7 routes which are
originated by the NSSA area border router will not get added to
other NSSA area border router's routing table.
A default route must not be injected into the NSSA as a summary 6. Those type-7 LSAs that are to be translated into type-5
(type-3) LSA as in the stub area case. The reason for this is LSAs must have their forwarding address set.
that the preferred summary default route would be chosen over all Type-5 LSAs that have been translated from type-7 LSAs
more specific type-7 route. Because summary routes are preferred for the most part must contain a forwarding address.
to external routes and to ensure that summary routes are chosen The execption to this is if the translation to a type-5
over external within the NSSA, all summary routes (unlike stub LSA is the result of an address range match, in which
areas in which this is optional) must be imported into an NSSA. case the type-5 LSA will not contain a forwarding address
(see section 4.1 for details).
The forwarding address contained in type-5 LSAs will
result in more efficient routing to the AS external
networks when there are multiple NSSA area
border routers. Having the forwarding address in the
type-7 LSAs will ease the translation of type-7 into
type-5 LSAs as the NSSA area border router will
not be required to compute the forwarding address.
3.4 Calculating Type-7 AS External Routes If the network between the NSSA AS boundary router and the
adjacent AS is advertised into OSPF as an internal OSPF
route, the forwarding address should be the next hop
address as is currently done in type-5 LSAs, but unlike
type-5 LSAs if the intervening network is not advertised
into OSPF as an internal OSPF route, the forwarding
address should be any one of the router's active OSPF
interface addresses.
This section is very similar to section 16.4 (Calculating AS Type-5 and type-7 metrics and path types are directly comparable.
external routes) in the OSPF specification. An NSSA area border
router should examine both type-5 LSAs and type-7 LSAs if either
type-5 or type-7 routes need to be updated. Type-7 LSAs should
be examined after type-5 LSAs. An NSSA internal router should
examine type-7 LSAs when type-7 routes need to be recalculated.
In relation to the steps to calculate the routing table as 3.4 Originating Type-7 LSAs
presented in the OSPF specification (chapter 16, "Calculation of
the Routing Table"), type-7 LSAs should be examined after step 5
where the routes to external destinations are calculated.
Type-7 routes are calculated by examining type-7 LSAs. Each of NSSA AS boundary routers may originate type-7 LSAs. All NSSA area
LSAs are considered in turn. Most type-7 LSAs describe routes to border routers must also be AS boundary routers since they all must
specific IP destinations. A type-7 LSA can also describe a have the capability of translating a type-7 LSAs into a type-5 LSAs
default route for the NSSA (destination = DefaultDestination). (see section 3.6 routes for the translation algorithm). NSSA area
For each type-7 LSA: border routers must set the E-bit (external bit) as well as the B-bit
(border bit) in its router (type-1) LSAs (both in the backbone and in
the NSSA area).
1. If the metric specified by the LSA is LSInfinity, the When an NSSA internal AS boundary router originates a type-7 LSA that
age of the LSA equals MaxAge or the advertising router it wants to be translated into a type-5 LSA by the NSSA area border
field is equal to this router's router ID, examine the router (and subsequently flooded into the backbone), it must set the
next advertisement. P-bit in the LS header's option field and add a valid forwarding
address in the type-7 LSA.
2. Call the destination described by the LSA N. Look up the If a router is attached to another AS and is also an NSSA area border
routing table entry for the AS boundary router (ASBR) that router, it may originate a both a type-5 and a type-7 LSA for the
originated the LSA. If no entry exists for the ASBR same network. The type-5 LSA will be flooded to the backbone (and
(i.e., ASBR is unreachable), do nothing with this LSA and all attached type-5 capable areas) and the type-7 will be flooded
consider the next in the list. into the NSSA. If this is the case, the P-bit must be reset in the
type-7 NSSA so the type-7 LSA isn't again translated into a type-5
LSA by another NSSA area border router.
If the destination is the default route (destination = A type-7 default route (network 0.0.0.0) may be originated into the
DefaultDestination) and if the originator of the LSA and NSSA by an NSSA area border router or by an NSSA AS boundary router
the calculating router are both NSSA are border routers which is internal to the NSSA. The type-7 default route originated
do nothing with this LSA and consider the next in the list. by the NSSA area border router must have the P-bit reset so that the
default route originated by the NSSA area border router will not find
its way out of the NSSA into the rest of the AS system via another
NSSA area border router. The type-7 default route originated by an
NSSA AS boundary router which is not an NSSA area border router may
have the P-bit set. Type-7 routes which are originated by the NSSA
area border router will not get added to other NSSA area border
router's routing table.
Else, this LSA describes an AS external path to destination A default route must not be injected into the NSSA as a summary
N. If the forwarding address (as specified in the forwarding (type-3) LSA as in the stub area case. The reason for this is that
address field of the LSA) is 0.0.0.0, the packets routed the preferred summary default route would be chosen over all more
to the external destination N will be routed to the specific type-7 routes. Because summary routes are preferred to
originating ASBR. If the forwarding address is not 0.0.0.0, external routes and to ensure that summary routes are chosen over
look up the forwarding address in the routing table. Packets external within the NSSA, all summary routes (unlike stub areas in
routed to the external destination N will be routed within which this is optional) must be imported into an NSSA.
the NSSA to the this forwarding address. An intra-area path
must therefore exist to the forwarding address. If no such
path exists, do nothing with the LSA and consider the next
in the list.
Call the routing table distance to the forwarding address 3.5 Calculating Type-7 AS External Routes
(or the distance to the originating ASBR if the forwarding
address is 0.0.0.0) X, and the cost specified in the type-7
LSA Y. X is in terms of the link-state metric, and Y is a
Type-1 or external metric.
3. Now, look up the routing table entry for the destination This section is very similar to section 16.4 (Calculating AS external
N. If no entries exist for N, install the AS external path routes) in the OSPF specification. An NSSA area border router should
to N, with the next hop equal to the list of next hops to examine both type-5 LSAs and type-7 LSAs if either type-5 or type-7
the forwarding address/ASBR, and the advertising router equal routes need to be updated. Type-7 LSAs should be examined after
to ASBR. If the external metric type is 1, then the type-5 LSAs. An NSSA internal router should examine type-7 LSAs when
path-type is set to Type-1 external and the cost is equal type-7 routes need to be recalculated.
to X + Y. If the external metric type is 2, the path-type
is set to Type-2 external, the link-state component of the
route's cost is X, and the Type-2 cost is Y.
4. Else, if the paths present in the table are not Type-1 or In relation to the steps to calculate the routing table as presented
Type-2 external paths, do nothing (AS external paths have in the OSPF specification (chapter 16, "Calculation of the Routing
the lowest priority). Table"), type-7 LSAs should be examined after step 5 where the routes
to external destinations are calculated.
5. Otherwise, compare the cost of this new AS external path Type-7 routes are calculated by examining type-7 LSAs. Each of LSAs
to the ones present in the table. Note that type-5 and are considered in turn. Most type-7 LSAs describe routes to specific
type-7 routes are directly comparable. Type-1 external IP destinations. A type-7 LSA can also describe a default route for
paths are always shorter than Type-2 external paths. the NSSA (destination = DefaultDestination). For each type-7 LSA:
Type-1 external paths are compared by looking at the sum
of the distance to the forwarding address/ASBR and the
advertised Type-1 paths (X+Y). Type-2 external paths are
compared by looking at the advertised Type-2 metrics,
and then if necessary, the distance to the forwarding
address/ASBR.
When a type-5 LSA and a type-7 LSA are found to have the
same type and an equal distance, the following priorities
apply (listed from highest to lowest) for breaking the tie.
a. Any type 5 LSA.
b. A type-7 LSA with the P-bit set and the forwarding
address non-zero.
c. Any other type-7 LSA.
If the new path is shorter, it replaces the present paths 1. If the metric specified by the LSA is LSInfinity, the
in the routing table entry. If the new path is the same age of the LSA equals MaxAge or the advertising router
cost, it is added to the routing table entry's list of field is equal to this router's router ID, examine the
paths. next advertisement.
3.5 Incremental Updates 2. Call the destination described by the LSA N. Look up the
routing table entry for the AS boundary router (ASBR) that
originated the LSA. If no entry exists for the ASBR
(i.e., ASBR is unreachable), do nothing with this LSA and
consider the next in the list.
Incremental updates for type-7 LSAs should be treated the same as If the destination is the default route (destination =
incremental updates for type-5 LSAs (see section 16.6 of the OSPF DefaultDestination) and if the originator of the LSA and
specification). That is, if a new instance of a type-7 LSA is the calculating router are both NSSA area border routers
received it is not necessary to recalculate the entire routing do nothing with this LSA and consider the next in the list.
table. If there is already an OSPF internal route to the destina-
tion represented by the type-7 LSA, no recalculation is neces-
sary. Otherwise, the procedure in the proceeding section will
have to be performed but only for the external routes (type-5 and
type-7) whose networks describe the same networks as the newly
received LSA.
4.0 Originating Type-5 LSAs Else, this LSA describes an AS external path to destination
N. If the forwarding address (as specified in the forwarding
address field of the LSA) is 0.0.0.0, the packets routed
to the external destination N will be routed to the
originating ASBR. If the forwarding address is not 0.0.0.0,
look up the forwarding address in the routing table. Packets
routed to the external destination N will be routed within
the NSSA to this forwarding address. An intra-area path
must therefore exist to the forwarding address. If no such
path exists, do nothing with the LSA and consider the next
in the list.
4.1 Translating Type-7 LSAs Into Type-5 LSAs Call the routing table distance to the forwarding address
(or the distance to the originating ASBR if the forwarding
address is 0.0.0.0) X, and the cost specified in the type-7
LSA Y. X is in terms of the link-state metric, and Y is a
Type-1 or Type-2 external metric.
This step is performed as part of the NSSA's Dijkstra calculation 3. Now, look up the routing table entry for the destination
after type-5 and type-7 routes have been calculated. If the cal- N. If no entries exist for N, install the AS external path
culating router is not an area border router this translation to N, with the next hop equal to the list of next hops to
algorithm should be skipped. All reachable area border routers the forwarding address/ASBR, and the advertising router equal
in the NSSA should now be examined noting the one with the to ASBR. If the external metric type is 1, then the
highest router ID. If this router has the highest router ID, it path-type is set to Type-1 external and the cost is equal
will be the one translating type-7 LSAs into type-5 LSAs for the to X + Y. If the external metric type is 2, the path-type
NSSA, otherwise the translation algorithm should not be per- is set to Type-2 external, the link-state component of the
formed. route's cost is X, and the Type-2 cost is Y.
All type-7 routes that have been added to the routing table 4. Else, if the paths present in the table are not Type-1 or
should be examined. If the type-7 LSA being examined has the P- Type-2 external paths, do nothing (AS external paths have
bit set and a non-zero forwarding address a new instance of a the lowest priority).
type-5 LSA should be originated and flooded to all attached
type-5 capable areas if one of the following is true.
1. There currently is no type-5 LSA originated from this 5. Otherwise, compare the cost of this new AS external path
router corresponding to the type-7 LSA. to the ones present in the table. Note that type-5 and
type-7 routes are directly comparable. Type-1 external
paths are always shorter than Type-2 external paths.
Type-1 external paths are compared by looking at the sum
of the distance to the forwarding address/ASBR and the
advertised Type-1 paths (X+Y). Type-2 external paths are
compared by looking at the advertised Type-2 metrics,
and then if necessary, the distance to the forwarding
address/ASBR.
2. The path type or the metric in the corresponding When a type-5 LSA and a type-7 LSA are found to have the
type-5 LSA is different from the type-7 LSA. same type and an equal distance, the following priorities
apply (listed from highest to lowest) for breaking the tie.
3. The forwarding address in the corresponding a. Any type 5 LSA.
type-5 LSA is different from the type-7 LSA. b. A type-7 LSA with the P-bit set and the forwarding
address non-zero.
c. Any other type-7 LSA.
The newly originated type-5 LSAs will describe the same network If the new path is shorter, it replaces the present paths
and have the same network mask, metrics, forwarding address, and in the routing table entry. If the new path is the same
external route tag as the type-7 LSA. The advertising router cost, it is added to the routing table entry's list of
field will be the router ID of this area border router. paths.
4.2 Flushing Translated Type-7 LSAs 3.6 Incremental Updates
If an NSSA area border router has translated a type-7 LSA to a Incremental updates for type-7 LSAs should be treated the same as
type-5 LSA that should no longer be translated, the type-5 LSA incremental updates for type-5 LSAs (see section 16.6 of the OSPF
should be flushed (set to MaxAge and flooded). The translated specification). That is, if a new instance of a type-7 LSA is
type-5 LSA should be flushed whenever the routing table entry received it is not necessary to recalculate the entire routing table.
that caused the translation changes so that either the routing If there is already an OSPF internal route to the destination
table entry is unreachable or the entry's associated LSA is not a represented by the type-7 LSA, no recalculation is necessary.
type-7 with the P-bit set and a non-zero forwarding address. 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.
5.0 Acknowledgements 4.0 Originating Type-5 LSAs
This document was produced by the OSPF Working Group, chaired by 4.1 Translating Type-7 LSAs Into Type-5 LSAs
John Moy.
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 not an area border router this translation
algorithm should be skipped. All reachable area border routers in
the NSSA should now be examined noting the one with the highest
router ID. If this router has the highest router ID, it will be the
one translating type-7 LSAs into type-5 LSAs for the NSSA, otherwise
the translation algorithm should not be performed.
All type-7 routes that have been added to the routing table should be
examined. If the type-7 LSA (associated with the route being
examined) has the P-bit set and a non-zero forwarding address, the
following steps should be taken.
The translation procedure must first check for a configured type-7
address range. Recall that an type-7 address range consists of an
[address,mask] pair and a status indication of either Advertise or
DoNotAdvertise. At most a single type-5 LSA is made for each
range. If the route being examined falls within the type-7
address range, (the [address,mask] pair of the route equal to or a
more specific instance of the [address,mask] pair of the type-7
address range), one of following three actions may take place.
1. When the range's status indicates Advertise and the
route's address and mask are equal to the address
and mask of the type-7 range a type-5 LSA should be
originated if:
o there currently is no type-5 LSA originated from
this router corresponding to the type-7 LSA,
o the path type or the metric in the corresponding
type-5 LSA is different from the type-7 LSA or
o The forwarding address in the corresponding
type-5 LSA is different from the type-7 LSA.
The newly originated type-5 LSA will describe
the same network and have the same network mask,
metrics, forwarding address, external route tag
and path type as the type-7 LSA, however, the
advertising router field will be the router ID
of this area border router.
2. When the range's status indicates Advertise and the
route's address or mask indicates a more specific
route (i.e., the route's address is subsumed by the
range or the route has a longer mask), a type-5 LSA
is generated with link-state ID equal to the range's
address (if necessary, the link-state ID can also have
one or more of the range's "host" bits set; see
Appendix F of the OSPF specification for details),
the network mask, external route tag and
path type will be set to the configured type-7 range
values. The advertising router field will be the
router ID of this area border router.
The forwarding address will not be set.
The path type should always be set to the highest
path type that is subsumed by the net range.
The metric for the type-5 LSA will be set as follows:
o if the path type is externl type 2, the type-5
metric should be set to the largest type-7 metric
subsumed by this net range + 1.
o if the path type is external type 1, the type-5
metric should be set to the largest metric.
For example, given a net range of [10.0.0.0, 255.0.0.0]
for an area that has type-7 routes of:
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 will be generated with a path type of 2
and a metric of 6.
As another example, given a net range of
[10.0.0.0, 255.0.0.0] for an area that has
type-7 routes of:
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 of 11.
These metric and path type rules will avoid routing
loops in the event that path type 1 and 2 are both
used within the area.
3. When the range's status indicates DoNotAdvertise,
the type-5 LSA is suppressed and the component networks
remain hidden from the rest of the AS.
By default (given that the P-bit is set and the LSA has a
non-zero forwarding address) if a network is not contained
in any explicitly configured address range, a type-7 to
type-5 LSA translation will occur.
A new instance of a type-5 LSA should be originated and
flooded to all attached type-5 capable areas if one of the
following is true.
1. There currently is no type-5 LSA originated from this
router corresponding to the type-7 LSA.
2. The path type or the metric in the corresponding
type-5 LSA is different from the type-7 LSA.
3. The forwarding address in the corresponding
type-5 LSA is different from the type-7 LSA.
The newly originated type-5 LSAs will describe the same
network and have the same network mask, metrics, forwarding
address, external route tag and path type as the type-7 LSA.
The advertising router field will be the router ID of this
area border router.
As with all newly originated type-5 LSAs, a type-5 LSA that
is the result of a type-7 to type-5 translation (type-7 range
or default case) is flooded to all attached type-5 capable
areas.
4.2 Flushing Translated Type-7 LSAs
If an NSSA area border router has translated a type-7 LSA to a type-5
LSA that should no longer be translated, the type-5 LSA should be
flushed (set to MaxAge and flooded). The translated type-5 LSA
should be flushed whenever the routing table entry that caused the
translation changes so that either the routing table entry is
unreachable or the entry's associated LSA is not a type-7 with the
P-bit set and a non-zero forwarding address.
5.0 Acknowledgements
This document was produced by the OSPF Working Group, chaired by John
Moy.
In addition, the comments of the following individuals are also
acknowledged:
In addition, the comments of the following individuals are also
acknowledged:
Phani Jajjarvarpu cisco Phani Jajjarvarpu cisco
Dino Farinacci cisco Dino Farinacci cisco
Jeff Honig Cornell University Jeff Honig Cornell University
John Moy Proteon, Inc. John Moy Proteon, Inc.
Doug Williams IBM Doug Williams IBM
6.0 References 6.0 References
[OSPF] Moy, J. OSPF Version 2. RFC 1247. July 1991. [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
[MOSPF] Moy, J. Multicast Extensions to OSPF.
Internet Draft. September 1992.
Appendix A: Type-7 Packet Format [2] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,
Proteon, Inc., March 1994.
0 32 7.0 Security Considerations
-----------------------------------
| | OPTS | 7 |
| ------------------
| Link-State Header |
| |
-----------------------------------
| Network Mask |
----------------------------------- ______
|E| Tos | metric | .
----------------------------------- . repeated for each TOS
| Forwarding Address | .
----------------------------------- .
| External Route Tag | ______
-----------------------------------
The definitions of the link-state ID, network mask, metrics and Security issues are not discussed in this memo.
external route tag are the same as the definitions for the type-5
LSAs (see A.4.5 in the OSPF specification) except for: 8.0 Authors' Addresses
Rob Coltun
RainbowBridge Communications
Phone: (301) 340-9416
EMail: rcoltun@rainbow-bridge.com
Vince Fuller
BARRNet
Stanford University
Pine Hall 115
Stanford, CA, 94305-4122
Phone: (415) 723-6860
EMail: vaf@Valinor.Stanford.EDU
Appendix A: Type-7 Packet Format
0 32
-----------------------------------
| | OPTS | 7 |
| ------------------
| Link-State Header |
| |
-----------------------------------
| Network Mask |
----------------------------------- ______
|E| Tos | metric | .
----------------------------------- . repeated for each TOS
| Forwarding Address | .
----------------------------------- .
| External Route Tag | ______
-----------------------------------
The definitions of the link-state ID, network mask, metrics and
external route tag are the same as the definitions for the type-5
LSAs (see A.4.5 in the OSPF specification) except for:
The Forwarding Address The Forwarding Address
If the network between the NSSA AS boundary router and the adja-
cent AS is advertised into OSPF as an internal OSPF route, the
forwarding address should be the next hop address but if the
intervening network is not advertised into OSPF as an internal
OSPF route, the forwarding address should be any one of the
router's active OSPF interface addresses.
Appendix B: The Options Field 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 but if the intervening network
is not advertised into OSPF as an internal OSPF route, the forwarding
address should be any one of the router's active OSPF interface
addresses.
The OSPF options field is present in OSPF Hello packets, Database Appendix B: The Options Field
Description packets and all link-state advertisements. See appen-
dix A.2 in the OSPF specification for a description of option The OSPF options field is present in OSPF Hello packets, Database
field. Description packets and all link-state advertisements. See appendix
A.2 in the OSPF specification for a description of option field.
------------------------------------ ------------------------------------
| * | * | * | * | N/P | MC | E | T | | * | * | * | * | N/P | MC | E | T |
------------------------------------ ------------------------------------
The Type-7 LSA options field The Type-7 LSA options field
T-bit: The T-bit describes the router's TOS capability. T-bit: The T-bit describes the router's TOS capability.
E-bit: Type-5 AS external link advertisements are not E-bit: Type-5 AS external link advertisements are not
flooded into/through OSPF stub and NSSA areas. flooded into/through OSPF stub and NSSA areas.
The E-bit ensures that all members of a stub area The E-bit ensures that all members of a stub area
agree on that area configuration. The E-bit is agree on that area configuration. The E-bit is
meaningful only in OSPF Hello packets. When the meaningful only in OSPF Hello packets. When the
E-bit is reset in the Hello packet sent out a E-bit is reset in the Hello packet sent out a
particular interface, it means that the router particular interface, it means that the router
will neither send nor receive type-5 AS external will neither send nor receive type-5 AS external
link state advertisements on that interface (in other link state advertisements on that interface (in
words, the interface connects to a stub area). Two other words, the interface connects to a stub
routers will not become neighbors unless they agree area). Two routers will not become neighbors
on the state of the E-bit. unless they agree on the state of the E-bit.
MC-bit: The MC-bit describes the multicast capability of the MC-bit: The MC-bit describes the multicast capability of
various pieces of the OSPF routing domain [MOSPF]. the various pieces of the OSPF routing domain
[2].
N-bit: The N-bit describes the the router's NSSA capability. N-bit: The N-bit describes the the router's NSSA
The N-bit is used only in Hello packets and ensures capability. The N-bit is used only in Hello
that all members of an NSSA agree on that area's packets and ensures that all members of an NSSA
configuration. When the N-bit is reset in the Hello agree on that area's configuration. When the
packet sent out a particular interface, it means N-bit is reset in the Hello packet sent out a
that the router will neither send nor receive particular interface, it means that the router
type-7 LSAs on that interface. Two routers will not will neither send nor receive type-7 LSAs on that
form an adjacency unless they agree on the state interface. Two routers will not form an adjacency
of the N-bit. If the N-bit is set in the options unless they agree on the state of the N-bit. If
field, the E-bit must be reset. the N-bit is set in the options field, the E-bit
must be reset.
P-bit: The P-bit is used only in the type-7 LSA header. P-bit: The P-bit is used only in the type-7 LSA header.
It flags the NSSA area border router to translate the It flags the NSSA area border router to translate
type-7 LSA into a type-5 LSA. the type-7 LSA into a type-5 LSA.
Appendix C: Configuration Parameters Appendix C: Configuration Parameters
Appendix C.2 in the OSPF specification lists the area parameters. Appendix C.2 in the OSPF specification lists the area parameters.
Area ID, list of address ranges and authentication type remain The area ID, list of address ranges for type-3 summary routes and
unchanged. For NSSAs the external capabilities of the area must authentication type remain unchanged. Section 3.2 of this document
be set to accept type-7 external routes. Additionally there must lists the configuration parameters for type-7 address ranges.
be a way of configuring the NSSA area border router to send a
default route into the NSSA using a specific metric (type-1 or For NSSAs the external capabilities of the area must be set to accept
type-2 and the actual cost). type-7 external routes. Additionally there must be a way of
configuring the NSSA area border router to send a default route into
the NSSA using a specific metric (type-1 or type-2 and the actual
cost).
 End of changes. 88 change blocks. 
437 lines changed or deleted 572 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/