Advancing the NSFNET routing architecture
RFC 1222

Document Type RFC - Informational (May 1991; 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 1222 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         H-W. Braun
Request for Comments: 1222                San Diego Supercomputer Center
                                                              Y. Rekhter
                                         IBM T.J. Watson Research Center
                                                                May 1991

               Advancing the NSFNET Routing Architecture

Status of this Memo

   This RFC suggests improvements in the NSFNET routing architecture to
   accommodate a more flexible interface to the Backbone clients.  This
   memo provides information for the Internet community.  It does not
   specify an Internet standard.  Distribution of this memo is
   unlimited.

Introduction

   This memo describes the history of NSFNET Backbone routing and
   outlines two suggested phases for further evolution of the Backbone's
   routing interface.  The intent is to provide a more flexible
   interface for NSFNET Backbone service subscribers, by providing an
   attachment option that is simpler and lower-cost than the current
   one.

Acknowledgements

   The authors would like to thank Scott Brim (Cornell University),
   Bilal Chinoy (Merit), Elise Gerich (Merit), Paul Love (SDSC), Steve
   Wolff (NSF), Bob Braden (ISI), and Joyce K. Reynolds (ISI) for their
   review and constructive comments.

1. NSFNET Phase 1 Routing Architecture

   In the first phase of the NSFNET Backbone, a 56Kbps infrastructure
   utilized routers based on Fuzzball software [2].  The Phase 1
   Backbone used the Hello Protocol for interior routing.  At the
   periphery of the Backbone, the client networks were typically
   connected by using a gatedaemon ("gated") interface to translate
   between the Backbone's Hello Protocol and the interior gateway
   protocol (IGP) of the mid-level network.

   Mid-level networks primarily used the Routing Information Protocol
   (RIP) [3] for their IGP.  The gatedaemon system acted as an interface
   between the Hello and RIP environments.  The overall appearance was
   that the Backbone, mid-level networks, and the campus networks formed
   a single routing system in which information was freely exchanged.

Braun & Rekhter                                                 [Page 1]
RFC 1222       Advancing the NSFNET Routing Architecture        May 1991

   Network metrics were translated among the three network levels
   (backbone, mid-level networks, and campuses).

   With the development of the gatedaemon, sites were able to introduce
   filtering based on IP network numbers.  This process was controlled
   by the staff at each individual site.

   Once specific network routes were learned, the infrastructure
   forwarded metric changes throughout the interconnected network. The
   end-result was that a metric fluctuation on one end of the
   interconnected network could permeate all the way to the other end,
   crossing multiple network administrations.  The frequency of metric
   fluctuations within the Backbone itself was further increased when
   event-driven updates (e.g., metric changes) were introduced.  Later,
   damping of the event driven updates lessened their frequency, but the
   overall routing environment still appeared to be quite unstable.

   Given that only limited tools and protocols were available to
   engineer the flow of dynamic routing information, it was fairly easy
   for routing loops to form.  This was amplified as the topology became
   more fully connected without insulation of routing components from
   each other.

   All six nodes of the Phase 1 Backbone were located at client sites,
   specifically NSF funded supercomputer centers.

2. NSFNET Phase 2 Routing Architecture

   The routing architecture for the second phase of the NSFNET Backbone,
   implemented on T1 (1.5Mbps) lines, focused on the lessons learned in
   the first NSFNET phase.  This resulted in a strong decoupling of the
   IGP environments of the backbone network and its attached clients
   [5].  Specifically, each of the administrative entities was able to
   use its own IGP in any way appropriate for the specific network.  The
   interface between the backbone network and its attached client was
   built by means of exterior routing, initially via the Exterior
   Gateway Protocol (EGP) [1,4].

   EGP improved provided routing isolation in two ways.  First, EGP
   signals only up/down transitions for individual network numbers, not
   the fluctuations of metrics (with the exception of metric acceptance
   of local relevance to a single Nodal Switching System (NSS) only for
   inbound routing information, in the case of multiple EGP peers at a
   NSS).  Second, it allowed engineering of the dynamic distribution of
   routing information.  That is, primary, secondary, etc., paths can be
   determined, as long as dynamic externally learned routing information
   is available.  This allows creation of a spanning tree routing

Braun & Rekhter                                                 [Page 2]
Show full document text