datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

The OSPF NSSA Option
RFC 1587

Document type: RFC - Proposed Standard (March 1994)
Obsoleted by RFC 3101
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 1587 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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

                          The OSPF NSSA Option

Status of this Memo

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

Table Of Contents

   1.0 Abstract .................................................  1
   2.0 Overview .................................................  2
   2.1 Motivation ...............................................  2
   2.2 Proposed Solution ........................................  3
   3.0 Implementation Details ...................................  5
   3.1 The N-bit ................................................  5
   3.2 Type-7 Address Ranges ....................................  5
   3.3 Type-7 LSAs ..............................................  5
   3.4 Originating Type-7 LSAs ..................................  7
   3.5 Calculating Type-7 AS External Routes ....................  8
   3.6 Incremental Updates ...................................... 10
   4.0 Originating Type-5 LSAs .................................. 10
   4.1 Translating Type-7 LSAs .................................. 10
   4.2 Flushing Translated Type-7 LSAs .......................... 13
   5.0 Acknowledgements ......................................... 13
   6.0 References ............................................... 13
   7.0 Security Considerations .................................. 13
   8.0 Authors' Addresses ....................................... 14
   Appendix A: Type-7 LSA Packet Format ......................... 15
   Appendix B: The Options Field ................................ 16
   Appendix C: Configuration Parameters ......................... 17

1.0  Abstract

   This document describes a new optional type of OSPF area, somewhat
   humorously referred to as a "not-so-stubby" area (or NSSA).  NSSAs
   are similar to the existing OSPF stub area configuration option but
   have the additional capability of importing AS external routes in a
   limited fashion.

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

2.0  Overview

2.1  Motivation

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

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

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

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

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

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

             3. The cloud becomes a single, manageable "leaf" with

[include full document text]