RFC 1222 (rfc1222) - Page 1 of 6


Advancing the NSFNET routing architecture



Alternative Format: Original Text Document



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