Merit Network und das NSFNET-Tor: Wie Backbone-Zugang die Adressmacht prägte

Zusammenfassung

• Adressregistrierung und Netzzugang waren verwandt, aber getrennt. Eine gültige Internetnetznummer begründete Einzigartigkeit und einen administrativen Eintrag; sie stellte keine Leitung, regionale Mitgliedschaft, NSFNET-Berechtigung oder eine Route bereit, die andere Betreiber akzeptieren würden.
• Die NSF finanzierte und beaufsichtigte das Backbone-Programm, Merit verwaltete es, IBM lieferte wichtige Paketvermittlungstechnologie und Engineering, MCI stellte Übertragungseinrichtungen bereit, und später betrieb ANS große Teile der T3-Infrastruktur. Regionale Netze, Universitäten, Kennungsbehörden und Peer-Betreiber behielten unterschiedliche Entscheidungen.
• Das NSFNET-Routing-System wandelte institutionelle Beziehungen in operative Erreichbarkeit um, indem es Netznummern, Autonomous-System-Identitäten und autorisierte regionale Vertretung validierte. Dadurch wurden Routing-Einträge so wichtig wie Registrierungseinträge, ohne Merit zum Zuteiler von Internetadressen zu machen.
• Öffentliche Investitionen brachten erhebliche Interoperabilitätsvorteile: schnellere nationale Verbindungen, gemeinsamen Betrieb, breiteren Universitätszugang und ein Routingsystem, das Tausende von Netzen verband. Die Abhängigkeit von dieser subventionierten Erreichbarkeit verlieh regionalen und Backbone-Entscheidungen dennoch Konsequenzen, die über ihre formellen Mandate hinausgingen.
• Der Übergang von 1993–1995 zeigte die Trennung der beiden Achsen. Die Registrierung ging an InterNIC, während regionale Netze kommerziellen Transit beschafften, Routen zu mehreren Anbietern und Austauschpunkten wanderten und der alte NSFNET-Backbone-Dienst am 30. April 1995 endete.

Eine vielschichtige Illustration, kein dokumentierter Zulassungsfall

Die Kent State University bietet einen nützlichen Einblick in die Schichten, durch die eine Adresse nutzbar wurde, aber die erhaltenen Belege dokumentieren keinen einzigen durchgehenden Zulassungsvorgang.

Das im Juli 1990 veröffentlichte InternetnummernregisterRFC 1166führte131.123alsKENT-STATEin der Forschungskategorie. Dieser Eintrag belegt, dass die Nummer zu diesem Zeitpunkt der Kent State zugewiesen war. Er gibt weder Aufschluss über den ursprünglichen Antrag, das Datum der ersten Anforderung, die Begründung für die Genehmigung noch die Bedingungen, unter denen die Universität externe Konnektivität erhielt.

Ein separater Betriebsbericht von 1991,RFC 1246, beschrieb Kent States Position innerhalb des Ohio Academic Resources Network (OARnet). Er verzeichnete eine DS1-Leitung von Kent State zu OARnets Präsenzpunkt in Akron und eine 56-Kilobit-Verbindung, dargestellt als131.187.36.0. Letztere Nummer gehörte zur OARnet-Infrastruktur, nicht zu Kent States registriertem131.123-Netz. Das Dokument beschrieb auch einen umständlichen Ausweichpfad über Cleveland, wenn die bevorzugten Verbindungen nicht verfügbar waren.

Das sind zwei echte Beobachtungen: eine Register-Momentaufnahme und eine spätere Betriebs-Momentaufnahme des regionalen Netzes. Sie beweisen nicht Kent States ursprüngliche Mitgliedschaftsbedingungen, seine erste erfolgreiche externe Routenankündigung oder den genauen Pfad eines Pakets an einem bestimmten Tag. Der in RFC 1246 beschriebene OARnet-Neustart betraf die Konvergenz von Routen zu OARnet-Infrastrukturadressen. Er sollte nicht als aufgezeichneter End-to-End-Pfad zu131.123missverstanden werden.

Das begrenzte Beispiel legt dennoch den steuernden Mechanismus offen. Kent State benötigte eine Kennung, die nicht mit einem anderen Netz kollidierte. Es benötigte eine Anbindung an OARnet. OARnet benötigte funktionierende externe Verbindungen und die Erlaubnis, die dahinterliegenden Netze zu vertreten. Backbone- und Peer-Router mussten dann die entsprechenden Erreichbarkeitsinformationen akzeptieren. Ein Ausfall in einer dieser Stufen konnte ein Ziel unerreichbar machen, selbst wenn die anderen Einträge intakt blieben.

Die Unterscheidung ist wichtig, weil das Ergebnis vom Campus aus einheitlich aussehen konnte. Ein Nutzer sah nur, dass ein entfernter Host erreichbar war oder nicht. Hinter diesem Ergebnis standen Entscheidungen einer Registrierungsstelle, einer Universität, eines regionalen Netzes, von Backbone-Betreibern, Leitungsanbietern und entfernten Peers. Ihre Zuständigkeiten wirkten zusammen, waren aber nicht austauschbar.

Was die NSF in Auftrag gab – und was die öffentlichen Aufzeichnungen belegen

Das erste Instrument in der Backbone-Kette war keine Adressvergabepolitik. Es war die Ausschreibung der National Science Foundation von 1987 für Management und Betrieb eines erweiterten NSFNET-Backbones.

Merits spätere Chronik datiert die Projektausschreibung NSF 87-37 auf den 15. Juni 1987. Die Anhörung des House Subcommittee on Science von 1992,Management of NSFNET, gibt wichtige Formulierungen aus der Ausschreibung wieder. Sie beschreibt das vorgeschlagene System als dreistufige Hierarchie: einen transkontinentalen Backbone, autonom verwaltete Netze der zweiten Ebene und Campus-Netze, die darunter angeschlossen sind. Der wiedergegebene Text lud die Antragsteller auch ein, alternative Architekturen oder Methoden vorzuschlagen, die angemessener, wirtschaftlicher oder effektiver sein könnten.

Diese Formulierung belegt die beabsichtigte Trennung zwischen nationalem Backbone-Management und regionaler Verwaltung. Sie legt nicht jede Bedingung der endgültigen Vereinbarung fest. Ein vollständiger beglaubigter Satz mit der unterzeichneten Kooperationsvereinbarung NCR-8720904, allen Änderungen, jeder IBM- und MCI-Vereinbarung und dem späteren Betriebsinstrument Merit–ANS ist über das zitierte öffentliche Archiv nicht verfügbar. Behauptungen über unveröffentlichte Klauseln würden daher über die Beweislage hinausgehen.

Die engere institutionelle Kette ist gut belegt. Merit schlug im August 1987 einen 1,5-Megabit-pro-Sekunde-T1-Backbone mit IBM und MCI vor. Die NSF kündigte im November eine fünfjährige Kooperationsvereinbarung mit Merit an. Zeitgenössische Kongressaussagen und Merits institutioneller Bericht benennen Merit als die gegenüber der NSF für Management und Betrieb des Backbone-Projekts verantwortliche Organisation. IBM lieferte Paketvermittlungshardware, Software und Engineering. MCI stellte Fernübertragungseinrichtungen bereit. Der Bundesstaat Michigan leistete zusätzliche Unterstützung.

Diese Beiträge schufen keinen einzelnen korporativen oder bundesstaatlichen Akteur namens „NSFNET“. Die NSF war Geldgeber und Programmaufsicht. Merit war Inhaber der Kooperationsvereinbarung und Backbone-Manager. IBM-Ingenieure trugen System- und Routingarbeit bei. MCI lieferte Leitungen und Kommunikationsexpertise. Universitäten und regionale Netze blieben getrennt verwaltet. Die IANA-Funktion und die Internet Registry behandelten Kennungen über eine andere institutionelle Kette.

Die Unterscheidung zwischen einer Kooperationsvereinbarung und gewöhnlicher Beschaffung ist ebenfalls relevant, obwohl sie die zentrale Frage des Artikels nicht entscheidet. Die NSF übte eine fortlaufende Beteiligung an einem Infrastrukturprogramm aus, dessen Entwurf und Betrieb von Beiträgen mehrerer Organisationen abhingen. Sie konnte die Vergabe beaufsichtigen, die Leistung überprüfen, Änderungen genehmigen und entscheiden, ob die Unterstützung verlängert wird. Sie erwarb kein Eigentum an allen Adressen, deren Verkehr später den Dienst durchlief.

Der neue T1-Backbone wurde im Sommer 1988 an dreizehn Standorten in Betrieb genommen. Merits abschließender institutioneller Bericht datiert den Betrieb auf Juli und meldet 152 Millionen Pakete pro Monat bei 1,5 Megabit pro Sekunde. Die NSF-Aussage vor dem Kongress 1992 verwendete eine andere Basis, beschrieb den neuen Backbone als verkehrsführend ab August 1988 und zeigte ein Wachstum von etwa 200 Millionen Paketen pro Monat auf 11 Milliarden bis Anfang 1992.

Diese Zahlen widersprechen sich nicht notwendigerweise. Sie können unterschiedliche Berichtszeitpunkte, teilweise versus vollständige Monatsbeobachtungen oder spätere Rundungen widerspiegeln. Die öffentlichen Dokumente definieren den Unterschied nicht genau genug, um sie zu einer exakten Zählung des „ersten Monats“ zusammenzuführen. Die vertretbare Schlussfolgerung ist, dass der T1-Dienst im Juli–August 1988 in Betrieb ging, wobei Merit 152 Millionen monatliche Pakete zum Juli-Zeitpunkt meldete und die NSF später eine Basis von etwa 200 Millionen Paketen für den Frühdienst verwendete.

Diese Einschränkung schmälert die Leistung nicht. Das System mit dreizehn Knoten ersetzte eine überlastete 56-Kilobit-Konfiguration durch einen Produktions-Backbone, unterstützte regionale Zusammenschaltung und gab Universitäten Zugang zu entfernten Rechen- und Informationsressourcen, ohne dass jeder Campus ein nationales Netz aufbauen musste.

Das T1-System verband mehrere Tore

Die Finanzstruktur erhöhte die praktische Bedeutung der Abstimmung zwischen diesen Toren.RFC 1192, ein Bericht eines Kommerzialisierungs-Workshops von 1990, schätzte die jährlichen Backbone-Kosten auf etwa 10 Millionen Dollar, wovon die NSF weniger als 3 Millionen zahlte. Der Großteil des Rests wurde dem Bundesstaat Michigan sowie beigetragenen IBM- und MCI-Diensten zugeschrieben. Derselbe Bericht schätzte, dass die NSF etwa 40 Prozent der Kosten der von ihr unterstützten Mid-Level-Netze trug, wobei eine Spanne von null bis 75 Prozent festgestellt wurde.

Dies waren Workshop-Schätzungen, kein einheitlicher Anspruch oder Preiskatalog. Sie zeigen dennoch, warum eine NSF-unterstützte Route wertvoller sein konnte als eine Adresse allein. Bundesmittel, staatliche Unterstützung, Unternehmensbeiträge, regionale Gebühren, Universitätsausgaben und Sachleistungen im Engineering führten zu einem nationalen Dienst, dessen volle Kosten nicht jedem angeschlossenen Campus als kommerzieller Ferntransit berechnet wurden.

Der Nutzen war kollektiv. Eine Universität musste keine Standleitung zu jedem Supercomputer-Zentrum oder jedem anderen regionalen Netz aushandeln. Gemeinsame Protokolle und ein betriebener Backbone ermöglichten es, mit einer Anbindung eine wachsende Anzahl von Zielen zu erreichen. Die daraus resultierenden Netzwerkeffekte steigerten den Wert jeder nutzbaren Route.

Abhängigkeit war die Kehrseite dieses Nutzens. Sobald Forscher, Bibliotheken, Verwaltungen und Campus-Rechenzentren auf entfernte Konnektivität angewiesen waren, verursachte eine Verzögerung an einer regionalen Verbindung oder einem Backbone-Richtlinieneintrag reale Kosten für die Nutzer. Doch der Ort der Abhilfe hing vom Fehler ab. Ein fehlerhafter Registereintrag fiel in den Bereich der Kennungsverwalter. Eine ausgefallene Standleitung in den Bereich des Campus, des regionalen Netzes oder des Netzbetreibers. Eine nicht autorisierte Ankündigung in den Bereich des Routing-Betriebs.

Die Ablehnung durch einen entfernten Peer konnte von der NSF nicht allein durch die Erklärung der Legitimität des Ziels behoben werden.

Regionaler Zugang war keine einheitliche Bundesregelung

Die dreistufige Architektur platzierte regionale Netze zwischen den Campus und dem nationalen Backbone, aber diese Netze waren keine identischen Verwaltungszweige der NSF oder von Merit.

OARnets Betriebsbericht von 1991 beschrieb ein Netz, das der Hochschulbildung in Ohio diente und Verbindungen für Unternehmen ermöglichte, die in Forschung, Produktentwicklung oder Lehre tätig waren. Es verwendete TCP/IP und DECnet, verband 29 Standorte direkt und betrieb eine Topologie, in der 13 Router als Autonomous-System-Boundary-Router fungierten.

Die wichtigste externe Routing-Beziehung laut RFC 1246 verlief über ein demilitarisiertes Netz in Columbus, das mit CICNet verbunden war. Teile von OARnet generierten eine Default-Route, wenn die entsprechende externe Sitzung verfügbar war, anstatt alle externen EGP-Informationen durch das Innere zu tragen. OARnet hatte auch Gateways zu anderen Systemen, einschließlich des NASA Science Internet.

Diese Anordnung gab OARnet operative Wahlmöglichkeiten. Seine Ingenieure bestimmten interne Routing-Kosten, Ausweichpfade, das Design der Präsenzpunkte und wie externe Erreichbarkeit zu einer Default-Route innerhalb des regionalen Systems wurde. Merits Backbone-Betreiber wählten nicht die Kosten von OARnets Pfad von Kent State nach Akron, und das DDN-NIC konfigurierte nicht OARnets OSPF-Router.

Die aufgezeichneten Kent-State-Verbindungen zeigen, was sich in der regionalen Topologie änderte. Die DS1-Leitung bot einen schnelleren bevorzugten Pfad. Die 56-Kilobit-Verbindung und der längere Pfad über Cleveland boten eine weniger attraktive Alternative während eines Neustarts. Als sich die Verbindungen erholten, berechnete OSPF die Routen neu. Das Ereignis zeigt regionale Konvergenz und Widerstandsfähigkeit; es zeigt weder eine Änderung von Kents externem Präfix noch beweist es, dass der gesamte externe Verkehr das NSFNET nutzte.

Andere regionale Netze verwendeten unterschiedliche organisatorische und technische Arrangements. Die StudieThe Strategic Future of the Mid-Level Networksbeschrieb BARRNet als Verteilung von Geräteeigentum und Betriebsverantwortung unter den teilnehmenden Einrichtungen. NYSERNet stützte sich stark auf Vereinbarungen mit Telekommunikationsunternehmen. PREPnet lagerte umfangreiche Funktionen an einen Netzbetreiber aus. NorthwestNet nutzte Boeing Computer Services, während NEARnet BBN nutzte.

BARRnets Fußabdruck von 1991 umfasste rund 80 Universitäts-, Regierungs- und kommerzielle Standorte mit Zugangsgeschwindigkeiten von 9,6 Kilobit pro Sekunde bis T1. Es war in Stanford sowohl mit T1- als auch mit T3-NSFNET-Einrichtungen verbunden und hatte auch Verbindungen zu ESnet, Verteidigungsnetzen und kalifornischen Universitätssystemen. Dies war nicht dieselbe Topologie, derselbe Markt oder dasselbe institutionelle Umfeld wie OARnet.

Folglich ließ sich „NSFNET-Zugang“ nicht auf einen einzigen nationalen Campus-Antrag reduzieren. Eine Universität benötigte typischerweise eine regionale Organisation, die willens und in der Lage war, sie anzuschließen, eine geeignete Standleitung, Ausrüstung, technisches Personal und eine Routenvereinbarung. Die regionale Organisation mochte Bundesmittel erhalten, konnte sich aber auch auf staatliche Zuwendungen, institutionelle Gebühren, Unternehmensmitglieder, Betreiberverträge oder Sachleistungen stützen.

Ein verspäteter Campus war nicht notwendigerweise durch Bundeserlass vom Internet ausgeschlossen. Es konnte stattdessen an einer erschwinglichen Last-Mile-Leitung fehlen, außerhalb der Mitgliedschaftsklasse eines regionalen Netzes liegen oder eine Geräteanforderung nicht erfüllen können. Ob eine andere Route existierte, hing von Geografie, Anbieterpräsenz, Berechtigung und Zusammenschaltung ab.

Diese Beweisgrenze ist für Kent State wichtig. Die erhaltenen Materialien liefern weder Kent States ursprüngliche OARnet-Anbindungsvereinbarung, Gebühren, das Installationsdatum noch Angebote für alternative Dienste. Sie können daher keine Behauptung stützen, dass Kent 1988 ein bestimmter Ersatzanbieter zu einem bekannten Preis zur Verfügung gestanden hätte. OARnets Verbindungen zu CICNet und NASA belegen nicht, dass Kent diese Pfade unabhängig hätte erwerben oder nutzen können, wenn seine OARnet-Anbindung verweigert worden wäre.

Die regionale Zulassung war ein echtes Tor. Sie war kein national standardisiertes Tor, und die verfügbaren Kent-Aufzeichnungen bewahren weder eine Ablehnung, einen Einspruch noch eine bezifferte Alternative.

Eine registrierte Nummer war kein Dienstanspruch

Das Kennungssystem trug Spuren früherer Zusammenschaltungspolitik. RFC 1166 unterschied Netze, die am Forschungs- und Betriebs-Internet teilnahmen, von unabhängigen IP-Netzen. Unabhängige Netze waren mit einem Sternchen markiert und benötigten eine separate Genehmigung zur Zusammenschaltung. Kent States131.123und OARnets131.187erschienen als Forschungsnetze ohne diese Markierung.

Das war im Juli 1990 eine bedeutsame Verwaltungsinformation, aber ihre Bedeutung muss eingegrenzt bleiben. Der Eintrag bewies nicht, dass eine Route zu jedem Zeitpunkt aktiv war. Er legte nicht fest, welches regionale Netz für jedes Paket verantwortlich war. Er wies keinen Betreiber an, eine Leitung bereitzustellen, oder zwang ein fremdes Netz, das Ziel zu akzeptieren.

RFC 1174, veröffentlicht im August 1990, erläutert sowohl die institutionelle Teilung als auch die wachsende Unzulänglichkeit des „Connected Status“. Es identifizierte die IANA-Funktion als vom Information Sciences Institute der USC ausgeführt. Es identifizierte SRI International als die für das Sammeln und Registrieren von Informationen über zugewiesene Netz- und Autonomous-System-Kennungen zuständige Internet Registry.

Das Dokument beschrieb eine Geschichte, in der Nummern zunächst an Organisationen vergeben wurden, die an der Internet-Forschung teilnahmen, und später an staatliche oder staatlich geförderte Netze, denen die Zusammenschaltung gestattet wurde. Als TCP/IP sich in privaten Netzen verbreitete, vergab die Registry global eindeutige Nummern, selbst wenn eine Organisation nicht beabsichtigte, sich mit dem bundesgeförderten Internet zu verbinden. „Connected Status“ wurde zum versuchten Unterscheidungsmerkmal zwischen dem Besitz einer Kennung und der staatlichen Genehmigung zur Zusammenschaltung.

Bis 1990 beschrieb dieses binäre Feld das Netz nicht mehr zutreffend. Regionale Systeme bedienten gemischte Mitgliedschaften. Kommerzielle Netze entstanden. Internationale Netze ließen sich sinnvollerweise nicht auf die Genehmigung eines Sponsors aus den Vereinigten Staaten reduzieren. Ein Netz konnte einen Teil seines Verkehrs über einen NSF-unterstützten Pfad und anderen Verkehr über einen anderen Peer oder Backbone leiten.

RFC 1174 empfahl daher, dass die Internet Registry den Connected Status aus Formularen und Datenbanken entfernt, stattdessen Zugangs- und Transitrichtlinieninformationen sammelt und jedem registrierten Netz den Eintrag in das Domain Name System unabhängig vom Connected Status erlaubt. Es erklärte, dass die Registry den Nummernraum verwalten solle, während Netzadministratoren die Verkehrsrichtlinien durchsetzen.

Das Dokument war eine IAB-Empfehlung, kein technischer Standard und kein Beweis, dass jedes Formular, jede Datenbank und jeder Router sofort geändert wurde. Seine Chronologie sollte nicht zu einer Reform über Nacht verkürzt werden. Was es klar belegt, ist, dass politische Entscheidungsträger Registrierung und Zusammenschaltung als unterschiedliche Funktionen erkannten und versuchten, die Zugangserzwingung von der Namens- und Kennungsregistrierungsschicht zu entfernen.

Dies war keine bloß theoretische Unterscheidung. Eine Organisation konnte eine eindeutige Nummer für ein privates TCP/IP-Netz benötigen, ohne über externen Transit zu verfügen. Umgekehrt konnte ein Campus physischen Zugang zu einem regionalen Netz haben, aber dennoch legitimen, konfliktfreien Adressraum benötigen, bevor er sicher gegenüber dem weiteren Internet vertreten werden konnte.

Die Routing-Richtlinie schuf die operative Verbindung

Die Registrierung machte eine Kennung administrativ legitim. Die Routing-Richtlinie bestimmte, ob der Backbone glaubte, dass ein bestimmtes Netz über ein bestimmtes regionales System erreichbar war.

InRFC 1092beschrieb Jacob Rekhter eine Einschränkung des Exterior Gateway Protocol, das zwischen dem neuen Backbone und regionalen Netzen verwendet wurde. EGP allein konnte ein regionales Netz nicht daran hindern, ein Ziel zu beanspruchen, das hinter einem anderen lag. Es konnte auch keine zuverlässige Hierarchie von bevorzugten und Ausweichpfaden in einer vermaschten Umgebung mit zusätzlichen „Hintertür“-Verbindungen ausdrücken.

Die vorgeschlagene Abhilfe war sowohl institutionell als auch technisch. Ein Netz würde einen oder mehrere regionale Vertreter durch bilaterale Vereinbarungen auswählen. Informationen über die gewählten primären und sekundären Vertreter würden an das NSFNET Network Operations Center geliefert und in die Routing Policy Database eingetragen. Der Backbone würde eine Ankündigung eines regionalen Netzes ignorieren, das nicht autorisiert war, dieses Ziel zu vertreten.

RFC 1093beschrieb die entsprechende Architektur. Von regionalen Backbones wurde erwartet, eindeutige Autonomous-System-Nummern zu verwenden. Backbone-Knoten prüften sowohl die Netznummern als auch die Quell-Autonomous-System-Nummer. Bevorzugte Pfade wurden aus Informationen abgeleitet, die von regionalen Backbones und angeschlossenen Campus bereitgestellt wurden. Regionale Netze konnten interne Defaults generieren, während der Backbone die explizite Erreichbarkeit für angeschlossene und Peer-Netze aufrechterhielt.

Die Route hing daher von der Übereinstimmung von Einträgen verschiedener Autoritäten ab:

1. Eine Netznummer musste eindeutig und ordnungsgemäß registriert sein.
2. Ein Campus benötigte eine Anbindungsbeziehung zu einem regionalen Netz.
3. Campus und regionales Netz benötigten eine vereinbarte Vertretung und Pfadpräferenz.
4. Die Backbone-Richtliniendaten mussten das regionale Autonomous System autorisieren, dieses Ziel anzukündigen.
5. Die entsprechende Leitung und die Router-Sitzungen mussten betriebsbereit sein.
6. Andere Betreiber mussten die Route akzeptieren und weiterverbreiten, wenn Erreichbarkeit über das NSFNET hinaus erforderlich war.

Diese Bedingungen waren kumulativ, aber nicht verfassungsmäßig vereinheitlicht. Die Registrierungsstelle konnte die mit einer Nummer verbundene Identität korrigieren, aber keine ausgefallene DS1-Leitung reparieren. Ein regionaler Betreiber konnte eine Verbindung wiederherstellen, aber keine doppelte Nummer global eindeutig machen. Merits Network Operations Center konnte eine nicht autorisierte Ankündigung zurückweisen, aber keinen unabhängigen Peer zwingen, eine Route zu akzeptieren.

Hier prägte der Backbone-Zugang die Adressmacht. Die NSFNET-Richtliniendatenbank war nicht das Adressregister, doch die Aufnahme in ein weit verbreitetes Routingsystem machte eine registrierte Nummer nützlicher. Als das erreichbare Netz wuchs, erlangte die korrekte Vertretung durch den Backbone größeren praktischen Wert.

Dasselbe System schränkte einseitige Routenansprüche ein. Ein regionales Netz konnte nicht einfach die Netznummer einer anderen Organisation mit einer bevorzugten Metrik ankündigen und erwarten, dass der Backbone ihr glaubte. Richtlinieneinträge und die Validierung des Autonomous System machten eine administrative Beziehung zu einer Routing-Genehmigung.

Die daraus resultierende Autorität war enger als Adresseigentum und breiter als mechanische Paketweiterleitung. Backbone-Betreiber kontrollierten, was ihr eigener Dienst akzeptierte. Weil dieser Dienst eine außergewöhnliche Reichweite hatte, konnten ihre betrieblichen Entscheidungen viele Nutzer betreffen. Das Ausmaß der Konsequenz ergab sich aus Topologie und Akzeptanz, nicht aus einem globalen Mandat.

Was die Wachstumszahlen zählen

Das Wachstum des NSFNET ist ein materieller Beweis für den öffentlichen Nutzen, aber seine Statistiken beschreiben unterschiedliche Populationen.

Die Merit-Zahl von 152 Millionen monatlichen Paketen im Juli 1988 und die spätere NSF-Basis von etwa 200 Millionen für den Frühdienst betreffen den Verkehr. Sie zählen keine Adressen oder Institutionen. Die NSF-Aussage meldete bis März 1992 etwa 11 Milliarden Pakete pro Monat, ein Maß für die rasch zunehmende Nutzung und keine Zählung angeschlossener Organisationen.

Der Backbone selbst wuchs von 13 T1-Standorten zu einer T3-Architektur mit 16 Standorten. Ein Backbone-Standort war kein Campus, regionales Netz oder einzelner Nutzer. Es war ein Knoten oder Anschlusspunkt innerhalb des nationalen Dienstes.

Kongresserklärungen von 1992 bezogen sich auf etwa 5.000 Netze, darunter etwa 1.500 außerhalb der Vereinigten Staaten, die in das weitere System eingebunden waren. Diese Schätzungen wurden in einer politischen und institutionellen Anhörung vorgelegt und sollten nicht als exakte Momentaufnahme der Routing-Tabelle behandelt werden.

Ein datiertes NSFNET-Routing-Update vom Januar 1993 meldete 8.997 in der T3-Richtliniendatenbank konfigurierte Netze. Diese Zahl stellte konfigurierte Netzeinträge und deren bevorzugte Autonomous-System-Pfade dar. Es war keine Zählung eindeutiger Organisationen. Eine Einrichtung konnte mehrere klassenbasierte Netze halten, und ein konfigurierter Eintrag konnte primäre und Backup-Vertretungen haben.

Die Zuteilungssummen inRFC 1366maßen wieder etwas anderes. 1992 meldete das Dokument 49 zugeteilte Class-A-Nummern, 7.354 Class-B-Nummern und 44.014 Class-C-Nummern. Dies waren Zuteilungseinheiten im klassenbasierten Adresssystem, keine NSFNET-Kunden. Einige wurden von privaten oder Nicht-NSF-Netzen genutzt, und eine Class A repräsentierte weit mehr Adresskapazität als eine Class C.

Die spätere Verkehrsvisualisierung, bewahrt vonCAIDA, meldet 18,5 Billionen eingehende Bytes im Dezember 1994. Für diese Visualisierung wurden 24.435 inländische Client-Netze nach Stadt und Backbone-Knoten in 12.177 virtuelle Verkehrsverbindungen aggregiert. Auch hier waren ein Client-Netz, eine virtuelle Linie in einer Visualisierung und eine Einrichtung nicht gleichwertig.

Sorgfältig verwendet, zeigen die Zahlen mehrere Formen der Expansion: mehr Verkehr, mehr konfigurierte Routen, mehr Adresszuteilungen, mehr Client-Netze und eine größere geografische Reichweite. Sie beweisen nicht, dass allein die Backbone-Finanzierung jede Veränderung verursachte. Sinkende Gerätekosten, die Verbreitung von TCP/IP-Software, regionale Investitionen, kommerzielle Dienste, Campus-Nachfrage, internationale Netze und neue Anwendungen trugen alle dazu bei.

Die kausale Behauptung kann daher bescheiden, aber wichtig bleiben. Die Investition der NSF und der von Merit geleitete Dienst stellten eine gemeinsame Hochkapazitäts-Routenumgebung bereit, die es einem Großteil dieses Wachstums ermöglichte, gegenseitig erreichbar zu werden. Sie produzierte nicht jede zugeteilte Adresse, und die zeitliche Korrelation zwischen Adresswachstum und Backbone-Wachstum belegt nicht, dass Merit die Zuteilung kontrollierte.

T3 änderte Kapazität und Betrieb, nicht die Kennungsautorität

Bis 1990 stand das T1-System erneut unter Druck. Das T3-Upgrade erhöhte die nominelle Backbone-Übertragung von 1,5 auf 45 Megabit pro Sekunde und erweiterte die Architektur auf 16 Standorte. Es änderte auch die Betriebsorganisation.

Merit, IBM und MCI gründeten im September 1990 Advanced Network & Services, Inc. (ANS). Der Kongressbericht von 1992 beschreibt Merit als weiterhin im Rahmen seiner Kooperationsvereinbarung verantwortlich, während es wesentliches Management und Betrieb des aufgerüsteten Backbones an die neue gemeinnützige Organisation untervergabe. Merits abschließende institutionelle Geschichte stellt ANS ähnlich als das Betriebsfahrzeug für einen Großteil der T3-Arbeit dar.

Die verfügbaren öffentlichen Materialien belegen die organisatorischen Umrisse, legen aber nicht jede operative Klausel der Merit–ANS-Vereinbarung vom 17. September 1990 offen. Es ist daher sicherer, die beobachtbare Aufteilung zu beschreiben, als nicht dokumentierte Rechte zuzuschreiben. Die NSF blieb Programmfinanzierer und -aufseher. Merit blieb in der Kette der Kooperationsvereinbarung verantwortlich. ANS übernahm umfangreiches T3-Engineering und -Betrieb. IBM und MCI lieferten weiterhin wichtige Technologie, Einrichtungen, Personal und Unterstützung.

Der Übergang zu T3 erfolgte nicht schlagartig. Die Installation der Knoten, die erste Verkehrsführung, die Migration der regionalen Anbindungen und die Außerbetriebnahme des T1-Netzes waren unterschiedliche Ereignisse. Merits Bericht datiert die Fertigstellung des 16-Standorte-T3-Systems auf 1991. T1- und T3-Einrichtungen existierten dann nebeneinander, während Anbindungen und Routen umzogen.

Eine im NANOG-Protokoll vom November 1992 archivierte Merit-Betriebsmitteilung sah die Abschaltung des T1-Backbones für Mittwoch, den 2. Dezember 1992 vor. Diese datierte Mitteilung liefert die fehlende Unterscheidung zwischen dem früheren Beginn des T3-Produktionsdienstes und der späteren Stilllegung des verbleibenden T1-Dienstes. Der T3-Backbone wurde nicht allein dadurch vollständig exklusiv, dass die ersten T3-Verbindungen Pakete transportierten.

Das Routensystem expandierte ebenfalls. Das Update vom Januar 1993, das 8.997 konfigurierte T3-Netze meldete, veranschaulicht die Menge an Richtliniendaten, die der Backbone-Betrieb verwalten musste. Jeder Eintrag repräsentierte ein Netz und erwartete Autonomous-System-Pfade, keine Adressvergabe. Die Datenbank operationalisierte Beziehungen, die bereits anderswo etabliert waren.

Diese Phase intensivierte daher das praktische Tor, ohne seine rechtliche Identität zu ändern. Ein fehlender oder falscher T3-Richtlinieneintrag konnte die Erreichbarkeit in einem viel größeren Dienst beeinträchtigen. Er machte ANS oder Merit nicht zur IANA, und er übertrug das Eigentum an registrierten Nummern nicht auf die NSF.

Die Kommerzialisierung führte ungleichmäßig Alternativen ein

Kommerzielle TCP/IP-Dienste entstanden, bevor der T3-Übergang abgeschlossen war. AlterNet und Performance Systems International vermarkteten Konnektivität. Regionale Netze bedienten einige industrielle Forschungseinrichtungen und suchten Einnahmen jenseits der Bundesförderung. Der Commercial Internet Exchange bot Zusammenschaltung außerhalb der Verkehrsbedingungen des NSF-unterstützten Backbones.

ANS gründete 1991 eine gewinnorientierte Tochtergesellschaft, ANS CO+RE, um kommerzielle Dienste anzubieten. Die Regelung wurde kontrovers, weil ANS auch die für den bundesgeförderten Dienst genutzte Infrastruktur betrieb. Teilnehmer der House-Anhörung von 1992 bestritten die Kostenzuordnung, Konsultation, Zusammenschaltung und Wettbewerbsvorteile.

Die Aussagen stützen nicht die Umwandlung jeder Behauptung in eine Feststellung. Kritiker argumentierten, dass die Struktur einen Pfad begünstige und die Grenzen der öffentlichen Unterstützung verschwimmen lasse. Merit und die NSF argumentierten, dass die Regelung private Investitionen fördere und gleichzeitig den Forschungs- und Bildungsdienst schütze. Die Anhörung belegt das Vorhandensein eines ernsthaften institutionellen Streits, nicht eine bewiesene Verschwörung oder Eigentumsforderung.

Für den Adresswert war die Kommerzialisierung wichtig, weil sie eine alternative Paarung zunehmend möglich machte: Eine gültige registrierte Nummer konnte über einen kommerziellen Anbieter statt über das NSFNET geroutet werden. Ein Kunde konnte einen Dienst erwerben, eine Leitung einrichten und den Anbieter bitten, sein Netz zu vertreten.

Diese Möglichkeit blieb bedingt. Ein Anbieter benötigte geografische Präsenz oder einen erreichbaren Präsenzpunkt. Der Kunde benötigte eine Last-Mile-Leitung, Ausrüstung, Personal, einen Dienstvertrag und Routing-Akzeptanz. Die Existenz eines kommerziellen Backbones in den Vereinigten Staaten bewies nicht, dass jede Universität lokal oder erschwinglich einen vergleichbaren Dienst kaufen konnte.

Die erhaltenen Kent-State-Materialien liefern kein zeitgenössisches Angebot von AlterNet, PSI oder einem anderen kommerziellen Anbieter, das Kents Standort, Berechtigung, Installation und Gesamtkosten abdeckt. Sie zeigen nicht, dass BITNET, das NASA Science Internet oder ein benachbartes regionales Netz als allgemeiner IP-Transit-Ersatz verfügbar war. Es wäre daher spekulativ zu behaupten, dass ein bestimmter alternativer Dienst 1988 für Kent machbar war, oder ihm einen Vergleichspreis zuzuordnen.

Was die breiteren Aufzeichnungen zeigen, ist eine Veränderung des Marktes im Laufe der Zeit. Anfang der 1990er Jahre hatten Organisationen mehr mögliche Upstreams und mehr Orte zum Austausch von Verkehr. BARRNets mehrere Verbindungen zeigen, dass regionale Systeme NSFNET neben Behörden- und lokalen Pfaden nutzen konnten. RFC 1092 hatte bereits primäre, sekundäre und „Hintertür“-Vertretungen in Betracht gezogen. Das kommerzielle Wachstum erweiterte diese technischen Möglichkeiten zu Dienstwahlmöglichkeiten, wenn auch ungleichmäßig.

Die praktische Autorität des NSFNET schwächte sich folglich ab, bevor der Dienst formell endete. Es blieb äußerst wichtig, aber ein registriertes Netz war weniger von einem subventionierten nationalen Pfad abhängig, sobald kommerzielle Anbieter und Austauschbeziehungen vergleichbare Ziele liefern konnten.

Die Registrierung folgte einem eigenen Zeitplan

Die Kennungsverwaltung durchlief ihren eigenen institutionellen Wandel, während der T3-Backbone in Betrieb war.

Die Ausschreibung der NSF vom März 1992,NSF 92-24, unterteilte Netzwerkinformationsdienste in Registrierungs-, Verzeichnis- und Datenbank- sowie Informationsfunktionen. Mit Wirkung vom 1. Januar 1993 richtete dieKooperationsvereinbarung NCR-9218742 der NSF mit Network Solutionsnicht-militärische Registrierungsdienste im Rahmen des späteren InterNIC-Rahmens ein.

Die Leistungsbeschreibung umfasste die Registrierung von Internet-Domains, die Zuteilung von Netznummern und die Zuteilung von Autonomous-System-Nummern in Abstimmung mit der IANA und den einschlägigen Richtliniendokumenten. Sie übertrug Network Solutions nicht die Verantwortung für den Betrieb von NSFNET-Routern oder die Auswahl kommerzieller Transit-Anbieter.

RFC 1400dokumentierte den betrieblichen Übergang vom DDN-NIC zum InterNIC. Es legte den 1. April 1993 als Stichtag fest, an dem nicht-DDN-Registrierungsanfragen zum neuen Dienst übergehen sollten. Die militärische Registrierung blieb auf ihrem separaten Pfad.

Diese Abfolge ist wichtig, weil sie vor der Abschaltung des alten Backbones stattfand. Bis 1993 konnte eine Universität eine Nummern- oder Autonomous-System-Anfrage an InterNIC richten, während ihr regionales Netz weiterhin den von ANS betriebenen T3-Dienst nutzte. Die Routing-Richtliniendatenbank und die Registrierungsdatenbank waren administrativ getrennt, selbst wenn sie Kennungen und Kontaktinformationen teilten.

Eine genaue Registrierung beeinflusste dennoch das Routing. Betreiber mussten wissen, welche Organisation ein Netz hielt und wen sie kontaktieren sollten, wenn eine Ankündigung umstritten war. Aber der Registereintrag aktivierte keine Backbone-Schnittstelle. Ebenso übertrug eine gültige Route im NSFNET nicht die zugrunde liegende Registrierungsfunktion auf den Backbone-Betreiber.

Der Übergang von 1993–1995 verteilte die Zugangsautorität neu

Die Ausschreibung der NSF vom Mai 1993,NSF 93-52, schlug vier verschiedene Projektbereiche vor: Network Access Points, einen Routing Arbiter, regionale Netzunterstützung und einen sehr schnellen Backbone Network Service für fortgeschrittene Forschung (vBNS).

Die Struktur vermied bewusst, den alten NSFNET-Dienst durch einen einzigen Commodity-Backbone zu ersetzen. Kommerzielle Netzwerkdienstanbieter würden den allgemeinen Verkehr transportieren und sich an Network Access Points zusammenschalten. Regionale Netze würden Upstream-Dienste von diesen Anbietern beschaffen, mit übergangsweiser NSF-Unterstützung. Die Routing-Koordination würde durch ein Routing Arbiter-Projekt fortgeführt. Das vBNS würde fortgeschrittenen Forschungsanforderungen dienen und nicht als einziger universeller Nachfolger fungieren.

DieGAO-Entscheidung bezüglich Sprints Anfechtung der vBNS-Vergabebestätigt, dass NSF 93-52 mehrere Kooperationsvereinbarungen vorsah und dass MCI im Februar 1994 für das vBNS-Projekt ausgewählt wurde. Die Entscheidung unterstreicht auch die Notwendigkeit, diesen Forschungsdienst vom kommerziellen Transit zu unterscheiden, der den alten Backbone ersetzte.

Die Zugangskette änderte sich entsprechend:

Ein Merit-Übergangsbericht vom 30. September 1994 zeigt, warum die Registrierung allein die Migration nicht abschließen konnte. Er verfolgte fünf betriebliche Abhängigkeiten: funktionierende Network Access Points, NSFNET-Anbindung an diese Punkte, neue Anbieteranbindungen, Routing Arbiter-Dienste und die Verbindung jedes regionalen Netzes zu seinem gewählten Anbieter. Ein Ausfall in einem dieser Bereiche konnte eine Einrichtung mit gültigen Kennungen, aber unvollständiger Erreichbarkeit zurücklassen.

Der endgültige Übergang war gestaffelt und nicht zeremoniell. Merits Mitteilung vom 14. April 1995 meldete, dass nur sieben Organisationen ihre alte NSFNET-Beziehung vollständig gekappt hatten. Viele nutzten neue Anbieter, während sie NSFNET als Backup behielten.

Verbleibende Sitzungen waren für eine Testabschaltung am 21. April vorgesehen, um unerreichbare Netze aufzudecken. Eine vorübergehende Wiederherstellung blieb möglich, während Probleme behoben wurden. Die Mitteilung forderte dann die dauerhafte Beendigung der verbleibenden Sitzungen am 28. April, gefolgt von der Einstellung des Backbone-Dienstes am 30. April.

Eine NSF-Mitteilung vom 15. Mai bestätigte, dass der NSFNET-Backbone-Dienst am 30. April 1995 um Mitternacht stillgelegt wurde.

Die Abschaltung verdeutlicht die Trennung zwischen Adressregistrierung und Backbone-Dienst, beweist aber nicht, dass jedes einzelne Präfix ohne Unterbrechung migrierte. Die Kontinuität für Kent States131.123nachzuweisen, würde beispielsweise zusätzlich zum Registereintrag übereinstimmende Vorher-Nachher-Routingbeobachtungen erfordern. Die verfügbaren Übergangsmitteilungen zeigen ein System, das darauf ausgelegt war, die Erreichbarkeit während des Dienstwechsels zu erhalten; sie liefern keine präfixspezifische Kent-Spur.

Was mit Sicherheit gesagt werden kann, ist, dass die Beendigung des alten Backbones das Kennungssystem nicht abschaffte. InterNIC- und IANA-Funktionen bestanden fort. Regionale Netze kauften Ersatztransit. Anbieter tauschten Routen an neuen Zusammenschaltungspunkten aus. Der operative Wert der Adressen blieb nur bestehen, weil diese neuen Akteure die Routen transportierten und akzeptierten.

Die beiden Achsen testen, ohne Alternativen zu erfinden

Die Unterscheidung lässt sich anhand mehrerer eingegrenzter Szenarien testen.

Eine gültige Kennung ohne nutzbaren externen Transit

Angenommen, eine Universität besäße eine global eindeutige registrierte Netznummer, aber es fehlte eine funktionierende regionale Anbindung oder ein akzeptabler Upstream.

Sie könnte die Nummer intern nutzen, ohne mit einem anderen registrierten Netz zu kollidieren. Sie könnte lokale TCP/IP-Dienste betreiben und Verkehr über jeden bilateralen Pfad austauschen, der sich zur Beförderung bereit erklärte. Die Registrierung bliebe bedeutsam.

Was ihr fehlen würde, wäre die allgemeine externe Erreichbarkeit. Die Universität bräuchte eine regionale Verbindung, einen kommerziellen Anbieter, einen berechtigten Behördenpfad oder einen dedizierten Peer. Jede Option erforderte eine eigene Vereinbarung und physische Einrichtungen. Die Registrierung würde keinen von ihnen zwingen, Dienstleistungen zu erbringen.

Für Kent State lässt sich aus den historischen Aufzeichnungen nicht ableiten, welcher Ersatz, falls überhaupt, 1988 all diese Bedingungen erfüllte. OARnets spätere mehrfache Gateways belegen die Topologie, nicht einen unabhängigen Dienstanspruch für Kent. Die Existenz von BITNET allein würde keinen allgemeinen IP-Transit bieten. Kommerzielle Anbieter wurden nach 1990 plausibler, aber es wurde kein vollständiger Kent-spezifischer Preis- oder Verfügbarkeitsnachweis gefunden.

Die berechtigte Schlussfolgerung ist daher begrenzt: Eine registrierte Adresse konnte ohne NSFNET überleben, aber ihr externer Nutzen hing davon ab, einen anderen Netzbetreiber und eine akzeptierte Route zu erhalten. Ob dies für Kent an einem bestimmten Datum machbar oder erschwinglich war, bleibt unbekannt.

Physischer Zugang ohne gültige öffentliche Kennung

Kehren Sie die Bedingungen um. Ein regionales Netz könnte eine verfügbare Leitung haben und bereit sein, einen Campus anzuschließen, aber der Campus könnte keine gültige Netznummer für die allgemeine Internetnutzung besitzen.

Die Leitung könnte Verkehr unter einem lokalen Adressierungsplan oder einer anderen technisch koordinierten Regelung befördern. Allgemeine technische Möglichkeiten umfassten die Verwendung von gültigem, vom Anbieter kontrolliertem Adressraum oder die Verzögerung der öffentlichen Ankündigung, bis die Registrierung geklärt war. Die erhaltenen OARnet-Materialien belegen nicht, welche Abhilfe es Kent angeboten hätte, daher sollte keine als OARnet-Richtlinie dargestellt werden.

Was der Campus nicht gefahrlos tun konnte, war, die öffentliche Nummer einer anderen Organisation zu wählen und zu erwarten, dass das globale Routing funktionierte. Doppelte Nummerierung konnte Pakete fehlleiten oder dazu führen, dass Filter die Ankündigung ablehnten. Die Richtlinienmechanismen des NSFNET waren speziell darauf ausgelegt, Netz- und Autonomous-System-Informationen mit der erwarteten Vertretung abzugleichen.

Die Abhilfe würde auf der Kennungsseite beginnen: eine legitime Zuteilung erhalten oder korrigieren und sicherstellen, dass die verantwortlichen Kontakte und die Vertretung korrekt waren. Das Öffnen eines Backbone-Ports konnte eine doppelte Kennung nicht eindeutig machen.

Eine legitime Route, die ein Peer nicht befördern wollte

Ein Ziel konnte ordnungsgemäß registriert, an ein regionales Netz angeschlossen und vom NSFNET akzeptiert sein, während es über einen anderen Anbieter unerreichbar blieb.

Jeder Peer oder Backbone kontrollierte seine eigene Routing-Richtlinie. Die Größe des NSFNET machte seine Informationen einflussreich, aber es konnte nicht jede Behörde, jeden kommerziellen oder internationalen Betreiber anweisen, ein Netz weiterzuverbreiten. Eine geroutete Adresse war daher ein Beleg für die Akzeptanz entlang eines bestimmten Pfades, kein Beweis für universelle Zustimmung.

Die angemessene Abhilfe war Routendiagnose und zwischenbetriebliche Koordination. Die Registrierungsstelle konnte helfen, Kontakte zu identifizieren, aber keine Beförderung erzwingen. Merit konnte seine eigene Richtliniendatenbank korrigieren, aber nicht jedes entfernte Netz konfigurieren.

Berechtigte Konnektivität mit Verkehr, der einen anderen Pfad erforderte

Ein Campus konnte auch über eine gültige Kennung und eine funktionierende Route verfügen, während ein Teil des Verkehrs für den bundesgeförderten Backbone nicht zugelassen war. Dies war ein Problem der Verkehrsrichtlinie, keine Löschung der Adresse oder Verweigerung der physischen Mitgliedschaft.

Die Einrichtung müsste den betreffenden Verkehr möglicherweise über einen anderen Anbieter leiten oder nachweisen, dass er dem zulässigen Forschungs- und Bildungszweck diente. Der wichtige Punkt hier ist institutionell: Die Einhaltung der akzeptablen Nutzung war eine weitere Bedingung auf dem Pfad, nicht die Autorität, die die Nummer schuf.

Diese Szenarien vermeiden falsche Symmetrie. Ihre Konsequenzen waren nicht identisch, und die verfügbaren Abhilfen unterschieden sich. Ein Registrierungsfehler bedrohte die Eindeutigkeit und stabile Vertretung. Ein regionaler Fehler bedrohte die lokale Anbindung. Ein Backbone-Fehler bedrohte die interregionale Beförderung. Eine Peer-Ablehnung bedrohte die Erreichbarkeit über den unmittelbaren Anbieter hinaus. Ein Konflikt in der Verkehrsrichtlinie betraf, welche Nutzungen einen bestimmten unterstützten Pfad durchlaufen konnten.

Für einen Campus-Nutzer konnten alle dasselbe Symptom hervorrufen: ein entferntes Ziel antwortete nicht. Die Governance-Analyse muss die Schicht rekonstruieren, auf der der Fehler auftrat.

Wo die Autorität und die Konsequenz lagen

Die NSF regierte direkt das von ihr finanzierte Programm. Sie wählte und beaufsichtigte die Struktur der Kooperationsvereinbarung, unterstützte regionale Konnektivität, überprüfte die Leistung, genehmigte Änderungen und entwarf später den Übergang zu Network Access Points, kommerziellen Dienstanbietern, einem Routing Arbiter und dem vBNS.

Merit verwaltete und koordinierte den Backbone im Rahmen seiner Vereinbarung mit der NSF. Zu seinen Aufgaben gehörten Netzbetrieb, Informationsdienste, regionale Verbindungsstelle und die Richtliniendaten, die nötig waren, um ein wachsendes geroutetes System kohärent zu halten.

IBM und MCI leisteten unterschiedliche technische und kommunikative Beiträge. Sie waren weder Universitätsmitgliedschaftsbehörden noch Internetnummern-Registrierungsstellen. Während der T3-Phase übernahm ANS umfangreiche Engineering- und Betriebsarbeiten, während Merit in der NSF-Vereinbarungskette blieb.

Regionale Netze kontrollierten die campus-seitige Schicht. Sie entschieden, wem sie dienen konnten, wie Leitungen und Geräte arrangiert wurden, welche Gebühren und lokalen Bedingungen galten und wie das interne Routing funktionierte. Ihre Strukturen waren heterogen, und die Folgen von Geografie oder eingeschränkter Betreiberwahl variierten erheblich.

Die IANA-Funktion, die Internet-Registry-Arbeit des DDN-NIC und später die InterNIC-Registrierungsdienste kontrollierten Kennungen und Einträge durch eine separate Abfolge. Diese Einträge waren wichtig, weil doppelte oder falsch zugeordnete Nummern kein verlässliches globales Routing unterstützen konnten. Die Kennungsbehörden betrieben nicht Kent States DS1-Leitung und wählten nicht seinen Upstream-Pfad aus.

Campus-, regionale, Backbone- und Peer-Betreiber setzten diese Beziehungen in Erreichbarkeit um. Sie konfigurierten Router, tauschten Routing-Informationen aus, validierten erwartete Vertreter, stellten ausgefallene Sitzungen wieder her und entschieden, welche Routen weiterverbreitet wurden. Ihre Arbeit bestimmte, ob eine registrierte Nummer zu einem bestimmten Zeitpunkt nutzbar war.

Die Behauptung, dass das NSFNET die Adressmacht verstärkte, gilt daher nur in einem verteilten Sinne. Die NSF-finanzierte Konnektivität machte das Internet nützlicher. Je mehr Ziele der Backbone und seine Peers verbanden, desto wertvoller wurde es, eine Kennung zu besitzen, die in dieser Umgebung korrekt vertreten wurde.

Dieser Effekt erhöhte auch die Konsequenzen von regionalen Zulassungs- und Routing-Richtlinienentscheidungen. Ein Eintrag im Nummernregister war notwendig, aber nicht hinreichend. Eine regionale Leitung ohne legitime Kennung war ebenfalls nicht hinreichend. Keine Achse allein erzeugte allgemeine Erreichbarkeit.

Öffentliche Investitionen sollten nicht als nebensächlich für dieses Ergebnis behandelt werden. Das NSFNET schuf nationale Interoperabilität mit einer Geschwindigkeit und in einem Umfang, die einzelne Universitäten separat wahrscheinlich nicht reproduzieren konnten. Es teilte Fixkosten, entwickelte den Betrieb, unterstützte regionales Wachstum und gab Forschern Zugang zu entfernten Ressourcen. Sein Erfolg ist Teil der Erklärung für seine Macht: Abhängigkeit folgte dem Nutzen.

Ebenso sollte Abhängigkeit nicht mit einem formellen Monopol über Adressen verwechselt werden. Kommerzielle Dienste, Behördennetze, direkte Peers und regionale Hintertüren existierten oder entstanden zu unterschiedlichen Zeiten. Ihre Verfügbarkeit war ungleichmäßig, und ihre Existenz garantierte keine machbare Alternative für jede Einrichtung. Aber sie zeigen, dass der Routenwert migrieren konnte, ohne dass die Kennung neu geschaffen werden musste.

Der Übergang von 1995 machte diese Trennbarkeit auf Systemebene sichtbar. Der alte Backbone endete. Die Registrierung bestand fort. Regionale Netze wechselten die Anbieter. Routen wanderten über kommerzielle Netze und Austauschpunkte. Die Routing-Koordination blieb in neuen Organisationen bestehen.

Dies war kein Beweis, dass jede Migration nahtlos verlief. Es war ein Beleg, dass Internetidentität und Internettransport einen institutionellen Austausch überleben konnten, weil sie nie dieselbe Funktion gewesen waren.

Die NSF besaß nicht die über das NSFNET beförderten Adressen. Merit entschied nicht über alle globalen Internetzulassungen. ANS wurde nicht zur IANA, indem es den T3-Dienst betrieb. Das DDN-NIC und InterNIC stellten keine Campus-Leitungen bereit. Regionale Netze kontrollierten nicht jeden Peer jenseits ihrer Grenzen.

Dennoch waren ihre Entscheidungen so eng aufeinander abgestimmt, dass Nutzer sie als ein einziges Tor erleben konnten. Die governance-bezogene Bedeutung des NSFNET liegt in dieser Abstimmung. Der Backbone-Zugang prägte die Adressmacht nicht, indem er die Kennungsautorität absorbierte, sondern indem er bestimmte, ob eine legitime Kennung an einer der wertvollsten Routing-Umgebungen ihrer Zeit teilnehmen konnte.

Quellen

• U.S. House Subcommittee on Science,Management of NSFNET, 12 March 1992
• Merit Network,NSFNET: A Partnership for High-Speed Networking, Final Report 1987–1995
• The Strategic Future of the Mid-Level Networks
• RFC 1092,EGP and Policy Based Routing in the New NSFNET Backbone
• RFC 1093,The NSFNET Routing Architecture
• RFC 1166,Internet Numbers
• RFC 1174,IAB Recommended Policy on Distributing Internet Identifier Assignment and Connected Status
• RFC 1192,Commercialization of the Internet Summary Report
• RFC 1246,Experience with the OSPF Protocol
• RFC 1366,Guidelines for Management of IP Address Space
• RFC 1400,Transition and Modernization of the Internet Registration Service
• Merit,T1 NSFNET Backbone Shutdown Schedule, November 1992 archive
• Merit, NSFNET policy-routing update reporting 8,997 configured T3 networks, January 1993 archive
• NSF 92-24,Network Information Services Manager(s) for NSFNET and the NREN
• NSF and Network Solutions, Cooperative Agreement NCR-9218742, 1 January 1993
• NSF 93-52,Network Access Point Manager, Routing Arbiter, Regional Network Providers, and Very High Speed Backbone Network Services Provider, 6 May 1993
• U.S. GAO,Sprint Communications Company, L.P., B-256586 and B-256586.2, 9 May 1994
• CAIDA Internet Atlas Gallery, NSFNET December 1994 traffic and aggregation data
• Merit,Update on Transition from the NSFNET Backbone Service, 30 September 1994
• Merit,Final Transition Steps, 14 April 1995
• National Science Foundation,NSFNET Backbone Decommissioned, 15 May 1995