NSFNET routing architecture
RFC 1093

Document Type RFC - Unknown (February 1989; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1093 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         H.W. Braun
Request for Comments: 1093                                         Merit
                                                           February 1989

                    The NSFNET Routing Architecture

Status of this Memo

   This document describes the routing architecture for the NSFNET
   centered around the new NSFNET Backbone, with specific emphasis on
   the interface between the backbone and its attached networks.
   Distribution of this memo is unlimited.


   This document describes the routing architecture for the NSFNET
   centered around the new NSFNET Backbone, with specific emphasis on
   the interface between the backbone and its attached networks.  It
   reflects and augments thoughts described in [1], discussions during
   the Internet Engineering Task Force meeting at the San Diego
   Supercomputing Center in March 1988, discussions on mailing lists,
   especially on a backbone/regional network working group mailing list,
   and a final discussion held at the IBM T.J. Watson Research Center in
   Yorktown, NY, on the 21st of March 1988.  The Yorktown meeting was
   attended by Hans-Werner Braun (Merit), Scott Brim (Cornell
   University), Mark Fedor (NYSERNet), Jeff Honig (Cornell University),
   and Jacob Rekhter (IBM).  Thanks also to: Milo Medin (NASA), John Moy
   (Proteon) and Greg Satz (Cisco) for discussing this document by email
   and/or phone.

   Understanding of [1] is highly recommended prior to reading this

1. Routing Overview

   The new NSFNET backbone forms the core of the overall NSFNET, which
   connects to regional networks (or regional backbones) as well as to
   peer networks (other backbones like the NASA Science Network or the
   ARPANET).  The NSFNET core uses a SPF based internal routing
   protocol, adapted from the IS-IS protocol submitted by ANSI for
   standardization to the ISO.  The ANSI IS-IS protocol is based upon
   work done at Digital Equipment Corporation.  Its adaptation to the
   Internet environment requires additional definitions, most notably to
   the addressing structure, which will be described in a later
   document.  This adaptation was largely done by Jacob Rekhter of IBM
   Research in Yorktown, NY. The RCP/PSP routing architecture was
   largely implemented by Rick Boivie and his colleagues at IBM TCS in

Braun                                                           [Page 1]
RFC 1093              NSFNET Routing Architecture          February 1989

   Milford, CT.  The adaptation of EGP to the NSS routing code and the
   new requirements was done jointly by Jeff Honig (who spent about a
   week to work on this at IBM Research) and Jacob Rekhter.  Jeff is
   integrating the changes done for the new EGP requirements into the
   "gated" distributions.

   The IGP derives routing tables from Internet address information.
   This information is flooded throughout the NSFNET core, and the
   individual NSS nodes create or update their routing information after
   running the SPF algorithm over the flooded information.  A detailed
   description of the NSFNET backbone IGP will be documented in a future

   The routing interface between the NSFNET core and regional backbones
   as well as peer networks utilizes the Exterior Gateway Protocol
   (EGP).  The EGP/IGP consistency and integrity at the interface points
   is ensured by filtering mechanisms according to individual nodal
   routing policy data bases [1].  EGP is selected as the routing
   interface of choice between the NSFNET backbone and its regional
   attachments due to its widespread implementation as well its ability
   to utilize autonomous system designators and to allow for effective
   firewalls between systems.  In the longer run the hope is to replace
   the EGP interface with a new inter Autonomous System protocol. Such a
   new protocol should also allow to move the filtering of network
   numbers or Autonomous Network number groups to the regional gateways
   in order for the regional gateways to decide as to what routing
   information they wish to receive.

   A general model is to ensure consistent routing information between
   peer networks.  This means that, e.g., the NSFNET core will have the
   same sets of Internet network numbers in its routing tables as are
   present in the ARPANET core.  However, the redistribution of this
   routing information is tightly controlled and based on Autonomous
   System numbers.  For example, ARPANET routes with the ARPANET
   Autonomous System number will not be redistributed into regional or
   other peer networks.  If an NSFNET internal path exists to such a
   network known to the ARPANET it may be redistributed into regional
   networks, subject to further policy verification. Generally it may be
   necessary to have different trust models for peer and subordinate
   networks, while giving a greater level of trust to peer networks.
Show full document text