and Section 2.6, Incremental Updates, rely heavily on text in RFC
2328's Section 16.4 and Section 16.6 respectively. Section 4.0,
Security Considerations, is an edit of similar content in Rob
Coltun's RFC2370, "The OSPF Opaque LSA option", Section 6.0.
Acee Lindem, Redback Networks, Inc, is also recognized for the first
full known implementation of this specification. Acee's
implementation resulted in substantive content change.
7.0 References
[DIGI] Murphy, S., Badger, M. and B. Wellington, "OSPF with
Digital Signatures", RFC2154, June 1997.
[MUEX] Moy, J., "Multicast Extensions to OSPF", RFC1584, March
1994.
[OSPF] Moy, J., "OSPF Version 2", RFC2328, April 1998.
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC2370, July
1998.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC1765, March 1995.
Appendix A: The Options Field
The OSPF options field is present in OSPF Hello packets, Database
Description packets and all link state advertisements. See [OSPF]
Appendix A.2 and [OPAQUE] Appendix A.1 for a description of the
options field. Six bits are assigned but only two (the E-bit and the
N/P bit) are described completely in this section.
--------------------------------------
| * | O | DC | EA | N/P | MC | E | * |
--------------------------------------
The Type-7 LSA options field
E-bit: Type-5 AS-external-LSAs are not flooded into/through OSPF
stub areas and NSSAs. The E-bit ensures that all members
of a stub area or NSSA agree on that area configuration.
The E-bit is meaningful only in OSPF Hello and Database
Description packets. When the E-bit is clear in the Hello
packet sent out a particular interface, it means that the
router will neither send nor receive Type-5 AS-external-
LSAs on that interface (in other words, the interface
connects to a stub area or NSSA). Two routers will not
become neighbors unless they agree on the state of the E-
bit.
N-bit: The N-bit describes the router's NSSA capability. The N-
bit is used only in Hello packets and ensures that all
members of an NSSA agree on that area's configuration.
When the N-bit is set in the Hello packet that is sent out
a particular interface, it means that the router will send
and receive Type-7 LSAs on that interface. Two routers
will not form an adjacency unless they agree on the state
of the N-bit. If the N-bit is set in the options field,
the E-bit must be clear.
P-bit: The P-bit is used only in the Type-7 LSA header. It flags
the NSSA border router to translate the Type-7 LSA into a
Type-5 LSA. The default setting for the P-bit is clear.
Appendix B: Router-LSAs
Router-LSAs are the Type-1 LSAs. Each router in an area originates a
router-LSA. The LSA describes the state and cost of the router's
links (i.e., interfaces) to the area. All of the router's links to
the area must be described in a single router-LSA. For details
concerning the construction of router-LSAs, see [OSPF] Section
12.4.1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 Nt|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
In router-LSAs, the Link State ID field is set to the router's OSPF
Router ID. Router-LSAs are flooded throughout a single area only.
bit V
When set, the router is an endpoint of one or more fully
adjacent virtual links having the described area as their
transit area (V is for virtual link endpoint).
bit E
When set, the router is an AS boundary router (E is for
external). ALL NSSA border routers set bit E in those
router-LSAs originated into directly attached Type-5 capable
areas. An NSSA's AS boundary routers also set bit E in their
router-LSAs originated into the NSSA. (See Section 3.1 for
details.)
bit B
When set, the router is an area border router (B is for
border).
bit W
When set, the router is a wild-card multicast receiver (W is
for wild).
bit Nt
When set, the router is an NSSA border router that is
unconditionally translating Type-7 LSAs into Type-5 LSAs (Nt
stands for NSSA translation). Note that such routers have
their NSSATranslatorRole area configuration parameter set to
Always. (See Appendix D and Section 3.1.)
The remainder of the router-LSAs specification is defined in [OSPF]
Section A.4.2.
Appendix C: Type-7 LSA Packet Format
0 32
------------------------------------
| | Options | 7 |
| -------------------
| Link-State Header |
| |
------------------------------------
| Network Mask |
------------------------------------ ______
|E| TOS | metric | .
------------------------------------ . repeated for each TOS
| Forwarding Address | .
------------------------------------ .
| External Route Tag | ______
------------------------------------
The definitions of the link-state ID, network mask, metrics and
external route tag are the same as the definitions for Type-5 LSAs
(See [OSPF] Appendix A.4.5), except for the forwarding address and
the N/P-bit. The Options field must have the N/P bit set as
described in Appendix A when the originating router desires that the
external route be propagated throughout the OSPF domain.
Forwarding address
Data traffic for the advertised destination will be forwarded to
this address. If the forwarding address is set to 0.0.0.0, data
traffic will be forwarded to the LSA's originator (i.e., the
responsible NSSA AS boundary router). Normally the next hop
address of an installed AS external route learned by an NSSA ASBR
from an adjacent AS points at one of the adjacent AS's gateway
routers. If this address belongs to a network connected to the
NSSA ASBR via one of its NSSAs' active interfaces, then it is the
forwarding address for the route's Type-7 LSA originated into this
NSSA. For an NSSA with no such network the forwarding address is
either an address from one of its active interfaces or 0.0.0.0.
If the P-bit is set, the forwarding address must be non-zero,
otherwise it may be 0.0.0.0. (See Section 2.3 for details.)
Appendix D: Configuration Parameters
[OSPF] Appendix C.2 lists the area configuration parameters. The
area ID and the list of address ranges for Type-3 summary routes
remain unchanged. Section 2.2 of this document lists the
configuration parameters for Type-7 address ranges. The following
area configuration parameters have been added:
NSSATranslatorRole
Specifies whether or not an NSSA border router will
unconditionally translate Type-7 LSAs into Type-5 LSAs. When
it is set to Always, an NSSA border router always translates
Type-7 LSAs into Type-5 LSAs regardless of the translator state
of other NSSA border routers. When it is set to Candidate, an
NSSA border router participates in the translator election
process described in Section 3.1. The default setting is
Candidate.
TranslatorStabilityInterval
Defines the length of time an elected Type-7 translator will
continue to perform its translator duties once it has
determined that its translator status has been deposed by
another NSSA border router translator as described in Section
3.1 and 3.3. The default setting is 40 seconds.
ImportSummaries
When set to enabled, OSPF's summary routes are imported into
the NSSA as Type-3 summary-LSAs. When set to disabled, summary
routes are not imported into the NSSA. The default setting is
enabled.
Implementations must provide a vehicle for setting the P-bit when
external routes are imported into the NSSA as Type-7 LSAs. Without
configuration, the default setting of the P-bit is clear. (See
Section 2.3 and Appendix B.)
For NSSAs the ExternalRoutingCapability area configuration parameter
must be set to accept Type-7 external routes. Additionally there
must be a way of configuring the metric of the default LSA that a
border router advertises into its directly attached NSSAs. If a
Type-7 default LSA is advertised, its metric type (1 or 2) should
also be configurable.
Appendix E: The P-bit Policy Paradox.
Non-default Type-7 LSAs with the P-bit clear may be installed in the
OSPF routing table of NSSA border routers. (See Section 2.5.) These
LSAs are not propagated throughout the OSPF domain as translated
Type-5 LSAs. (See Section 3.2.) Thus, traffic that is external to
an NSSA and that passes through one of the NSSA's border routers may
be hijacked into the NSSA by a route installed from a Type-7 LSA with
the P-bit clear. This may be contrary to the expected path at the
source of the traffic. It may also violate the routing policy
intended by the Type-7 LSA's clear P-bit. A Type-7 address range
that is configured with DoNotAdvertise exhibits the same paradox for
any installed Type-7 LSAs it subsumes, regardless of the P-bit
setting.
This paradox is best illustrated by the following example. Consider
an OSPF domain (AS 1842) with connections for default Internet
routing and to external AS 4156. NSSA 1 and OSPF Area 2 are
partially defined in the following diagram:
AS 4156
|
Area 2 |
|
A2 A0 Area 0 C0-----Internet
| | | Default
| | |
| | |
+-----------------B0---------------+
/\
/ \
/ \
Internet------------A1 B1------AS 4156 (P-bit clear)
Default (P-bit set)
NSSA 1
Here A0, B0, and C0 are Area 0 routers, A1 and B1 are NSSA 1 routers,
and A2 is an Area 2 router. B0 is a border router for both NSSA 1
and Area 2.
If the Type-7 external routes imported by B1 for AS 4156 are
installed on B0 so that the NSSA 1 tree below A1 can take advantage
of them, then A2's traffic to AS 4156 is hijacked through B0 by B1,
rather than its computed path through A0.
An NSSA border router's installed Type-7 default LSAs will exhibit
this paradox when it possesses a Type-7 address range [0,0]
configured with DoNotAdvertise, as these LSAs are not propagated even
though their P-bit is set. In the example above, if A1's default is
installed on B0, which has a configured Type-7 address range [0,0]
with DoNotAdvertise set, then A2's Internet traffic is hijacked
through B0 by A1 rather than the computed path through C0.
Appendix F: Differences from RFC1587
This section documents the differences between this memo and RFC
1587. All differences are backward-compatible. Implementations of
this memo and of RFC1587 will interoperate.
F.1 Enhancements to the import of OSPF's summary routes.
The import of OSPF's summary routes into an NSSA as Type-3 summary-
LSAs is now optional. In RFC1587 the import of summary routes was
mandated in order to guarantee that inter-area summary routing was
not obscured by an NSSA's Type-7 AS-external-LSAs. The current
recommended default behavior is to import summary routes. When
summary routes are not imported into an NSSA, the default LSA
originated by its border routers must be a Type-3 summary-LSA.
See Sections 1.3 and 2.7 for details.
F.2 Changes to Type-7 LSAs.
The setting of the forwarding address in Type-7 LSAs has been further
refined.
See Section 2.3 for details.
F.3 Changes to the Type-7 AS external routing calculation.
The Type-7 external route calculation has been revised. Most
notably:
o The path preference defined in [OSPF] Section 16.4.1 has been
included.
o A Type-7 default route with the P-bit clear will not be
installed on an NSSA border router. This protects the default
routing of other OSPF Areas. (See Appendix E.)
o The LSA type of two AS-external-LSAs plays no role in
determining path preference except when the LSAs are
functionally the same (i.e., same destination, cost and non-
zero forwarding address).
See Section 2.5 for details.
F.4 Changes to translating Type-7 LSAs into Type-5 LSAs
The translator election algorithm of RFC1587 has been updated to
close a bug that results when the translator with the highest router
ID loses connectivity to the AS's transit topology. The default
translator election process occurs only in the absence of an existing
translator.
The identity of the translator is optionally configurable, with more
than one allowed. This allows the network designer to choose the
most cost effective intra-AS route for NSSA originated Type-5 LSA
aggregations of Type-7 LSAs.
Self-originated non-default Type-7 LSAs are now included in the
translation process.
The translation process has been strengthened to close some of the
weak points of RFC1587.
See Sections 3.1 and 3.2 for details.
F.5 Changes to flushing translated Type-7 LSAs
An NSSA border router, which was elected by the augmented RFC1587
translator selection process defined in Section 3.1 and which has
been deposed from its translation duties by another NSSA border
router, flushes its self-originated Type-5 LSAs that resulted from
the aggregation of Type-7 LSAs. This prevents these obsolete
aggregations from short circuiting the preferred path through the new
translator(s). A deposed translator continues to maintain its self-
originated Type-5 LSAs resulting from translation until they age out
normally.
See Section 3.3 for details.
F.6 P-bit additions
The P-bit default has been defined as clear. RFC1587 had no default
setting. (See Appendix C.)
A discussion on the packet forwarding impact of installing Type-7
LSAs with the P-bit clear on NSSA border routers has been added as
Appendix E.
Author's Addresses
Pat Murphy
US Geological Survey
345 Middlefield Road
Menlo Park, California 94560
Phone: (650) 329-4044
EMail: pmurphy@noc.usgs.net
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.