Advancing the NSFNET routing architecture (RFC1222)
Original Publication Date: 1991-May-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
H.W. Braun: AUTHOR [+2]
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.
Network Working Group H-W. Braun
Request for Comments: 1222 San Diego Supercomputer Center
IBM T.J. Watson Research Center
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
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
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 . 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)  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.
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, bu...