The OSPF Not-So-Stubby Area (NSSA) Option
RFC 3101
| Document | Type |
RFC - Proposed Standard
(January 2003; Errata)
Obsoletes RFC 1587
|
|
|---|---|---|---|
| Last updated | 2016-08-09 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3101 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Bill Fenner | ||
| Send notices to | <rohit@utstar.com>, <john.moy@sycamorenet.com> | ||
Network Working Group P. Murphy
Request for Comments: 3101 US Geological Survey
Obsoletes: 1587 January 2003
Category: Standards Track
The OSPF Not-So-Stubby Area (NSSA) Option
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo documents an optional type of Open Shortest Path First
(OSPF) area that is somewhat humorously referred to as a "not-so-
stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub
area configuration option but have the additional capability of
importing AS external routes in a limited fashion.
The OSPF NSSA Option was originally defined in RFC 1587. The
functional differences between this memo and RFC 1587 are explained
in Appendix F. All differences, while expanding capability, are
backward-compatible in nature. Implementations of this memo and of
RFC 1587 will interoperate.
Murphy Standards Track [Page 1]
RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Table Of Contents
1.0 Overview ................................................. 2
1.1 Motivation - Transit Networks ......................... 2
1.2 Motivation - Corporate Networks ....................... 4
1.3 Proposed Solution ..................................... 5
2.0 NSSA Intra-Area Implementation Details ................... 7
2.1 The N-bit ............................................. 7
2.2 Type-7 Address Ranges ................................. 7
2.3 Type-7 LSAs ........................................... 8
2.4 Originating Type-7 LSAs ............................... 9
2.5 Calculating Type-7 AS External Routes ................. 10
2.6 Incremental Updates ................................... 14
2.7 Optionally Importing Summary Routes ................... 14
3.0 Intra-AS Implementation Details .......................... 15
3.1 Type-7 Translator Election ............................ 15
3.2 Translating Type-7 LSAs into Type-5 LSAs .............. 16
3.3 Flushing Translated Type-7 LSAs ....................... 19
4.0 Security Considerations .................................. 20
5.0 Acknowledgements ......................................... 21
6.0 Contributors ............................................. 22
7.0 References ............................................... 22
Appendix A: The Options Field ................................ 23
Appendix B: Router-LSAs ...................................... 24
Appendix C: Type-7 LSA Packet Format ......................... 26
Appendix D: Configuration Parameters ......................... 27
Appendix E: The P-bit Policy Paradox ......................... 28
Appendix F: Differences from RFC 1587 ........................ 30
Author's Addresses ........................................... 32
Full Copyright Statement ..................................... 33
1.0 Overview
1.1 Motivation - Transit Networks
Wide-area transit networks often have connections to moderately
complex "leaf" sites. A leaf site may have multiple IP network
numbers assigned to it. Typically, one of the leaf site's networks
is directly connected to a router provided and administered by the
transit network while the others are distributed throughout and
administered by the site. From the transit network's perspective,
all of the network numbers associated with the site make up a single
"stub" entity. For example, BBN Planet has one site composed of a
class-B network, 130.57.0.0, and a class-C network, 192.31.114.0.
From BBN Planet's perspective, this configuration looks something
like the diagram on the next page, 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.
Murphy Standards Track [Page 2]
RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
192.31.114
|
(cloud)
-------------- 130.57.4
|
Show full document text