Browse Prior Art Database

Advancing the NSFNET routing architecture (RFC1222)

IP.com Disclosure Number: IPCOM000002036D
Original Publication Date: 1991-May-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 6 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

H.W. Braun: AUTHOR [+2]

Abstract

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 21% of the total text.

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.

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...