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