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: 2019-Feb-11
Document File: 6 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

H.W. Braun: AUTHOR [+1]

Related Documents

10.17487/RFC1222: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% 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.

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

Processing...
Loading...