Merit Network und das NSFNET: Wie der Backbone-Zugriff die Macht der Adressen bestimmte

Zusammenfassung

• Die Registrierung von Adressen und der Netzwerkzugang waren miteinander verbunden, aber dennoch getrennt. Eine gültige Internet-Netzwerknummer gewährleistete Eindeutigkeit und eine administrative Spur; sie stellte jedoch keine Schaltung, regionale Mitgliedschaft, NSFNET-Berechtigung oder eine von anderen Betreibern akzeptierte Route bereit.
• Die NSF finanzierte und überwachte das Backbone-Programm, Merit verwaltete es, IBM lieferte Paketvermittlungstechnik und Ingenieurleistungen, MCI stellte die Übertragungseinrichtungen bereit, und später betrieb ANS einen Großteil der T3-Infrastruktur. Regionale Netze, Universitäten, Kennungsbehörden und Peer-Betreiber behielten unterschiedliche Entscheidungen.
• Das Routing-System des NSFNET verwandelte institutionelle Beziehungen in operative Reichweite, indem es Netzwerknummern, autonome Systemkennungen und autorisierte regionale Vertretung validierte. Dadurch wurden Routing-Einträge genauso wichtig wie Registereinträge, ohne dass Merit zum Zuteiler von Internetadressen wurde.
• Die öffentliche Investition brachte erhebliche Interoperabilitätsvorteile: schnellere nationale Verbindungen, gemeinsamer Betrieb, erweiterter Hochschulzugang und ein Routing-System, das Tausende von Netzwerken verband. Die Abhängigkeit von dieser subventionierten Reichweite gab regionalen und Backbone-Entscheidungen jedoch Konsequenzen, die über ihre formalen Mandate hinausgingen.
• Der Übergang 1993–1995 zeigte die Trennung der beiden Achsen. Die Registrierung wechselte zum InterNIC, während regionale Netze kommerziellen Transit kauften, Routen zu mehreren Anbietern und Austauschpunkten migrierten und der alte NSFNET-Backbone-Dienst am 30. April 1995 endete.

Eine geschichtete Veranschaulichung, kein dokumentierter Admissionsfall

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

Das Internet-Nummernregister vom Juli 1990, veröffentlicht unter der ReferenzRFC 1166, führte131.123alsKENT-STATEin der Kategorie Forschung auf. Dieser Eintrag belegt, dass die Nummer zu diesem Zeitpunkt auf den Namen der Kent State registriert war. Er offenbart nicht den ursprünglichen Antrag, das Datum, an dem die Nummer erstmals beantragt wurde, die Begründung, die zu ihrer Genehmigung führte, oder die Bedingungen, unter denen die Universität ihre externe Konnektivität erhielt.

Ein separater operativer Bericht von 1991,RFC 1246, beschrieb die Stellung von Kent State im Ohio Academic Resources Network, kurz OARnet. Er berichtete von einer DS1-Schaltung zwischen Kent State und dem OARnet-Präsenzpunkt in Akron sowie von einer 56-Kilobit-Verbindung, die als131.187.36.0dargestellt wurde. Letztere Nummer gehörte zur Infrastruktur von OARnet, nicht zum von Kent State registrierten Netz131.123. Das Dokument beschrieb auch einen indirekten Ausweichpfad über Cleveland, wenn die bevorzugten Verbindungen nicht verfügbar waren.

Dies sind zwei authentische Beobachtungen: eine Momentaufnahme des Registers und eine spätere operative Momentaufnahme des regionalen Netzes. Sie belegen nicht die anfänglichen Beitrittsbedingungen von Kent State, seine erste erfolgreiche externe Routenankündigung oder den genauen Weg, den ein Paket an einem bestimmten Tag nahm. Der in RFC 1246 beschriebene Neustart von OARnet betraf die Konvergenz der Routen zu den Infrastrukturadressen von OARnet. Er sollte nicht fälschlicherweise als End-to-End-Aufzeichnung einer Route zu131.123interpretiert werden.

Das begrenzte Beispiel zeigt jedoch den Governance-Mechanismus. Kent State benötigte eine Kennung, die nicht mit einem anderen Netz in Konflikt geriet. Es benötigte eine Anbindung an OARnet. OARnet benötigte funktionierende externe Verbindungen und die Autorisierung, die von ihm beherbergten Netze zu vertreten. Die Backbone- und Peer-Router mussten dann die entsprechenden Erreichbarkeitsinformationen akzeptieren. Ein Versagen in einem dieser Schritte konnte ein Ziel unerreichbar machen, selbst wenn die anderen Einträge intakt blieben.

Die Unterscheidung ist wichtig, weil das Ergebnis vom Campus aus einheitlich erscheinen konnte. Der Benutzer sah nur, ob ein entferntes System erreichbar war oder nicht. Dahinter standen Entscheidungen eines Registers, einer Universität, eines regionalen Netzes, von Backbone-Betreibern, von Schaltungsanbietern und entfernten Peers. Ihre Befugnisse interagierten, aber sie waren nicht austauschbar.

Was die NSF in Auftrag gab – und was öffentliche Archive belegen

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

Die spätere historische Darstellung von Merit datiert die Projektausschreibung NSF 87-37 auf den 15. Juni 1987. Die Anhörung des Unterausschusses für Wissenschaft des Repräsentantenhauses von 1992,Management of NSFNET, gibt wichtige Passagen der Ausschreibung wieder. Sie beschreibt das vorgeschlagene System als eine dreistufige Hierarchie: einen transkontinentalen Backbone, autonom verwaltete Netze der zweiten Ebene und darunter angeschlossene Campusnetze. Der wiedergegebene Text lud die Bieter auch ein, alternative Architekturen oder Methoden vorzuschlagen, die geeigneter, wirtschaftlicher oder effizienter sein könnten.

Diese Sprache legt die beabsichtigte Trennung zwischen nationalem Backbone-Management und regionaler Verwaltung nahe. Sie legt nicht jede Klausel der endgültigen Vereinbarung fest. Eine vollständige und authentifizierte Sammlung mit dem ausgeführten Kooperationsvertrag NCR-8720904, allen seinen Änderungen, jeder Vereinbarung mit IBM und MCI und der späteren Betriebsvereinbarung zwischen Merit und ANS ist in den zitierten öffentlichen Archiven nicht verfügbar. Jede Behauptung über unveröffentlichte Klauseln würde daher über die Beweise hinausgehen.

Die engere institutionelle Abfolge ist gut belegt. Merit schlug im August 1987 einen T1-Backbone mit 1,5 Megabit pro Sekunde zusammen mit IBM und MCI vor. Die NSF gab im November eine fünfjährige Kooperationsvereinbarung mit Merit bekannt. Zeitgenössische Kongressaussagen und der institutionelle Bericht von Merit identifizieren Merit als die Organisation, die gegenüber der NSF für das Management und den Betrieb des Backbone-Projekts verantwortlich ist. IBM stellte die Paketvermittlungshardware, -software und -entwicklung zur Verfügung. MCI stellte die Fernübertragungseinrichtungen. Der Bundesstaat Michigan leistete zusätzliche Unterstützung.

Diese Beiträge schufen keinen einzigen, körperschaftlichen oder föderalen Akteur namens „NSFNET“. Die NSF war der Geldgeber und Programmaufsichtsbehörde. Merit war der Inhaber der Kooperationsvereinbarung und der Backbone-Manager. IBMs Ingenieure trugen zu Systemen und Routing bei. MCI stellte die Schaltungen und Kommunikationsexpertise. Universitäten und regionale Netze blieben getrennt verwaltet. Die IANA-Funktion und das Internet-Register verwalteten die Kennungen über eine andere institutionelle Kette.

Die Unterscheidung zwischen einer Kooperationsvereinbarung und einem einfachen Kauf ist ebenfalls relevant, obwohl sie die Kernfrage des Artikels nicht entscheidet. Die NSF übte eine kontinuierliche Beteiligung an einem Infrastrukturprogramm aus, dessen Design und Betrieb auf den Beiträgen mehrerer Organisationen beruhten. Sie konnte die Vergabe überwachen, die Leistung überprüfen, Änderungen genehmigen und entscheiden, ob die Unterstützung verlängert werden sollte. Sie erwarb nicht das Eigentum an allen Adressen, deren Verkehr später über den Dienst lief.

Der neue T1-Backbone wurde im Sommer 1988 an dreizehn Standorten in Betrieb genommen. Der abschließende institutionelle Bericht von Merit datiert den Betrieb auf Juli und meldet 152 Millionen Pakete pro Monat bei 1,5 Megabit pro Sekunde. Die Kongressaussage der NSF von 1992 verwendete eine andere Basislinie und beschrieb den neuen Backbone als verkehrsführend ab August 1988 mit einem Wachstum von etwa 200 Millionen Paketen pro Monat auf 11 Milliarden zu Beginn des Jahres 1992.

Diese Zahlen sind nicht unbedingt widersprüchlich. Sie können unterschiedliche Berichtszeiträume, partielle oder vollständige monatliche Beobachtungen oder spätere Rundungen widerspiegeln. Die öffentlichen Dokumente definieren den Unterschied nicht genau genug, um sie zu einer einzigen exakten Zahl für den „ersten Monat“ zu verschmelzen. Die vertretbare Schlussfolgerung ist, dass der T1-Dienst im Juli–August 1988 in Betrieb ging, wobei Merit für Juli 152 Millionen monatliche Pakete meldete und die NSF später eine Basis von etwa 200 Millionen Paketen zu Dienstbeginn verwendete.

Dieser Vorbehalt schmälert die Errungenschaft nicht. Das 13-Knoten-System ersetzte eine gesättigte 56-Kilobit-Einrichtung durch einen Produktions-Backbone, unterstützte regionale Interkonnektivität und gab Universitäten Zugang zu entfernten Rechen- und Informationsressourcen, ohne dass jeder Campus ein nationales Netz aufbauen musste.

Das T1-System kombinierte mehrere Barrieren

Die Betriebsstruktur von 1988 bis 1990 kann in separate Entscheidungen zerlegt werden:

Die Finanzstruktur erhöhte die praktische Bedeutung der Abstimmung zwischen diesen Barrieren.RFC 1192, ein Bericht eines Kommerzialisierungsworkshops von 1990, schätzte die jährlichen Backbone-Kosten auf etwa 10 Millionen Dollar, von denen die NSF weniger als 3 Millionen zahlte. Ein großer Teil des Restbetrags wurde dem Bundesstaat Michigan und den Sachleistungen von IBM und MCI zugeschrieben. Derselbe Bericht schätzte, dass die NSF etwa 40 % der Kosten der von ihr unterstützten Mid-Level-Netze finanzierte, wobei die Spanne von null bis 75 % reichte.

Dies waren Workshop-Schätzungen, keine einheitliche Gebühr oder Preisliste. Sie zeigen jedoch, warum eine von der NSF unterstützte Route wertvoller sein konnte als eine bloße Adresse. Bundesmittel, staatliche Unterstützung, Unternehmensbeiträge, regionale Gebühren, Hochschulausgaben und technische Sachleistungen kombinierten sich zu einem nationalen Dienst, dessen Gesamtkosten nicht jedem Campus als kommerzieller Fernverkehr in Rechnung gestellt wurden.

Der Vorteil war kollektiv. Eine Universität musste keine dedizierte Schaltung zu jedem Supercomputerzentrum oder jedem anderen regionalen Netz aushandeln. Gemeinsame Protokolle und ein betriebener Backbone ermöglichten es einer einzigen Anbindung, eine wachsende Anzahl von Zielen zu erreichen. Die resultierenden Netzwerkeffekte erhöhten den Wert jeder nutzbaren Route.

Die Abhängigkeit war die Kehrseite dieses Vorteils. Sobald Forscher, Bibliotheken, Verwaltungen und Campus-IT-Abteilungen auf entfernte Konnektivität angewiesen waren, verursachte eine Verzögerung auf einer regionalen Verbindung oder ein Backbone-Policy-Eintrag echte Kosten für die Nutzer. Dennoch hing der Ort der Abhilfe von der Art des Versagens ab. Ein fehlerhafter Registereintrag war Sache der Kennungsverwalter. Eine defekte Standleitung war Sache des Campus, des regionalen Netzes oder des Carriers. Eine nicht autorisierte Ankündigung war Sache des Routing-Betriebs.

Die Ablehnung durch einen entfernten Peer konnte nicht von der NSF behoben werden, indem sie das Ziel einfach für legitim erklärte.

Der regionale Zugang war keine einheitliche Bundesregel

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

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

Seine wichtigste externe Routing-Beziehung in RFC 1246 verlief über ein entmilitarisiertes Netz in Columbus, das an CICNet angeschlossen war. Teile von OARnet erzeugten eine Standardroute, wenn die entsprechende externe Sitzung verfügbar war, anstatt alle externen EGP-Informationen intern zu transportieren. OARnet hatte auch Gateways zu anderen Systemen, einschließlich des NASA Science Internet.

Diese Anordnung gab OARnet operative Wahlmöglichkeiten. Seine Ingenieure bestimmten die internen Routing-Kosten, Ausweichpfade, das Design der Präsenzpunkte und wie die externe Erreichbarkeit innerhalb des regionalen Systems zu einer Standardroute wurde. Die Backbone-Betreiber von Merit wählten nicht die Wegkosten von OARnet zwischen Kent State und Akron, und das DDN-NIC konfigurierte nicht die OSPF-Router von OARnet.

Die gemeldeten Verbindungen von Kent State zeigen, was die regionale Topologie veränderte. Die DS1-Schaltung bot einen schnelleren bevorzugten Pfad. Die 56-Kilobit-Verbindung und der längere Weg über Cleveland stellten eine weniger attraktive Alternative während eines Neustarts dar. Als die Verbindungen wiederhergestellt wurden, berechnete OSPF die Routen neu. Das Ereignis zeigt regionale Konvergenz und Resilienz; es zeigt nicht, dass sich das externe Präfix von Kent änderte, und es belegt nicht, 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 eine Verteilung der Geräteeigentums- und Betriebsverantwortung auf die teilnehmenden Einrichtungen. NYSERNet stützte sich stark auf Vereinbarungen mit Telekommunikationsunternehmen. PREPnet lagerte viele Funktionen an einen Carrier aus. NorthwestNet nutzte Boeing Computer Services, während NEARnet BBN nutzte.

Die Reichweite von BARRNet umfasste 1991 etwa 80 Standorte von Universitäten, Regierungen und Unternehmen mit Zugangsgeschwindigkeiten von 9,6 Kilobit pro Sekunde bis T1. Es war in Stanford sowohl an die NSFNET-T1- als auch an die T3-Einrichtungen angeschlossen und verfügte auch über Verbindungen zu ESnet, den Verteidigungsnetzen und den kalifornischen Universitätssystemen. Dies war nicht dieselbe Topologie, derselbe Markt oder dasselbe institutionelle Umfeld wie OARnet.

Folglich ließ sich der „NSFNET-Zugang“ nicht auf einen einzigen nationalen Campus-Antrag reduzieren. Eine Universität benötigte in der Regel eine regionale Organisation, die bereit und in der Lage war, sie anzuschließen, eine geeignete Standleitung, Ausrüstung, technisches Personal und eine Routing-Vereinbarung. Die regionale Organisation konnte Bundesunterstützung erhalten, aber auch auf staatliche Mittel, institutionelle Gebühren, Unternehmensmitgliedschaften, Carrier-Verträge oder Sachleistungen angewiesen sein.

Ein verzögerter Campus war nicht unbedingt durch einen Bundesbeschluss vom Internet ausgeschlossen. Ihm fehlte möglicherweise eine erschwingliche Letzte-Meile-Schaltung, er entsprach nicht der Mitgliedskategorie eines regionalen Netzes oder konnte eine Ausrüstungsanforderung nicht erfüllen. Die Existenz einer alternativen Route hing von Geografie, Anbieterpräsenz, Berechtigung und Interkonnektivität ab.

Diese Beweisgrenze ist für Kent State wichtig. Die erhaltenen Dokumente liefern weder den ursprünglichen Anschlussvertrag von Kent mit OARnet, noch die Gebühren, das Installationsdatum oder Angebote für alternative Dienste. Sie erlauben daher nicht die Behauptung, dass ein bestimmter Ersatzanbieter für Kent im Jahr 1988 zu einem bekannten Preis verfügbar war. Die Verbindungen von OARnet zu CICNet und zur NASA belegen nicht, dass Kent diese Pfade unabhängig hätte kaufen oder nutzen können, wenn sein Anschluss an OARnet verweigert worden wäre.

Der regionale Zugang war eine echte Hürde. Es war keine national standardisierte Hürde, und die verfügbaren Aufzeichnungen über Kent enthalten keine Ablehnung, Berufung oder bezifferte Alternative.

Eine registrierte Nummer war kein Recht auf Dienst

Das Kennungssystem trug die Spuren der früheren Interkonnektionspolitik. RFC 1166 unterschied zwischen Forschungs- und Betriebs-Internet-Entität-Netzen und unabhängigen IP-Netzen. Unabhängige Netze waren mit einem Sternchen markiert und erforderten eine separate Genehmigung zur Interkonnektion. Das131.123von Kent State und das131.187von OARnet erschienen als Forschungsnetze ohne diese Markierung.

Dies waren administrative Informationen im Juli 1990, aber ihre Bedeutung muss begrenzt bleiben. Der Eintrag belegte nicht, dass eine Route zu jedem Zeitpunkt aktiv war. Er gab nicht an, welches regionale Netz für jedes Paket verantwortlich war. Er ordnete nicht an, dass ein Carrier eine Schaltung bereitstellte, und zwang kein entferntes Netz, das Ziel zu akzeptieren.

RFC 1174, veröffentlicht im August 1990, erläutert sowohl die institutionelle Teilung als auch die zunehmende Unzulänglichkeit des „Verbundenen Status“. Sie identifizierte die IANA-Funktion als vom Information Sciences Institute der USC wahrgenommen. Sie identifizierte SRI International als das Internet-Register, das für die Sammlung und Registrierung von Informationen über vergebene Netz- und AS-Nummern zuständig war.

Das Dokument beschrieb eine Geschichte, in der Nummern zunächst an Organisationen vergeben wurden, die Entität am Internet der Forschung waren, dann an staatliche oder staatlich unterstützte Netze, die zur Interkonnektion berechtigt waren. Als sich TCP/IP auf private Netze ausbreitete, vergab das Register global eindeutige Nummern, auch wenn eine Organisation nicht beabsichtigte, sich mit dem staatlich geförderten Internet zu verbinden. Der „Verbundene Status“ wurde zu einem Versuch, zwischen dem Besitz einer Kennung und der staatlichen Genehmigung zur Interkonnektion zu unterscheiden.

Bis 1990 beschrieb dieses binäre Feld das Netz nicht mehr genau. Regionale Systeme beherbergten vielfältige Mitglieder. Kommerzielle Netze entstanden. Internationale Netze ließen sich nicht sinnvoll auf die Zustimmung eines US-Sponsors reduzieren. Ein Netz konnte einen Teil seines Verkehrs über einen von der NSF unterstützten Pfad und einen anderen Teil über einen Peer oder einen anderen Backbone leiten.

RFC 1174 empfahl daher, dass das Internet-Register den Verbundenen Status aus Formularen und Datenbanken entfernt, stattdessen Informationen über Zugang und Transitrichtlinien sammelt und jedem registrierten Netz den Eintritt in das Domain Name System ohne Rücksicht auf den Verbundenen Status erlaubt. Sie erklärte, dass das Register den Nummernraum verwalten solle, während die Netzadministratoren die Verkehrspolitik anwenden.

Dieses Dokument war eine IAB-Empfehlung, kein technischer Standard und kein Beleg dafür, dass jedes Formular, jede Datenbank und jeder Router sofort geändert wurde. Seine Chronologie sollte nicht zu einer Reform über Nacht komprimiert werden. Was es klar belegt, ist, dass die Entscheidungsträger Registrierung und Interkonnektion als unterschiedliche Funktionen erkannten und versuchten, die Durchsetzung des Zugangs aus der Namens- und Kennungsvergabeschicht zu entfernen.

Es handelte sich nicht um eine rein theoretische Unterscheidung. Eine Organisation konnte eine eindeutige Nummer für ein privates TCP/IP-Netz benötigen, ohne externen Transit zu haben. Umgekehrt konnte ein Campus physischen Zugang zu einem regionalen Netz haben, aber einen legitimen und nicht konfligierenden Adressraum benötigen, bevor er sicher im weiteren Internet vertreten werden konnte.

Die Routing-Policy schuf die operative Verbindung

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

InRFC 1092beschrieb Jacob Rekhter eine Einschränkung des zwischen dem neuen Backbone und den regionalen Netzen verwendeten Exterior Gateway Protocol. EGP allein konnte nicht verhindern, dass ein regionales Netz ein Ziel beanspruchte, das einem anderen gehörte. Es konnte auch keine zuverlässige Hierarchie von bevorzugten und Ausweichpfaden in einer vermaschten Umgebung mit zusätzlichen „Backdoor“-Verbindungen ausdrücken.

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

RFC 1093beschrieb die entsprechende Architektur. Regionale Backbones sollten eindeutige autonome Systemnummern verwenden. Die Backbone-Knoten überprüften sowohl die Netznummern als auch die Quell-AS-Nummer. Bevorzugte Pfade wurden aus Informationen abgeleitet, die von den regionalen Backbones und den angeschlossenen Campus bereitgestellt wurden. Regionale Netze konnten interne Standardrouten erzeugen, während der Backbone explizite Erreichbarkeit für angeschlossene und Peer-Netze aufrechterhielt.

Die Route hing daher von der Übereinstimmung zwischen Einträgen aus verschiedenen Autoritäten ab:

1. Eine Netznummer musste eindeutig und korrekt registriert sein.
2. Ein Campus musste eine Anbindungsbeziehung zu einem regionalen Netz haben.
3. Der Campus und das regionale Netz mussten sich auf eine Vertretung und Pfadpräferenz einigen.
4. Die Policy-Daten des Backbones mussten dem regionalen AS erlauben, dieses Ziel anzukündigen.
5. Die entsprechende Schaltung und die Router-Sitzungen mussten betriebsbereit sein.
6. Andere Betreiber mussten die Route akzeptieren und verbreiten, wenn Erreichbarkeit über das NSFNET hinaus erforderlich war.

Diese Bedingungen waren kumulativ, aber nicht verfassungsrechtlich vereinheitlicht. Das Register konnte die mit einer Nummer verbundene Identität korrigieren, aber keine defekte DS1-Schaltung reparieren. Ein regionaler Betreiber konnte eine Verbindung wiederherstellen, aber keine doppelte Nummer global eindeutig machen. Das Betriebszentrum von Merit konnte eine nicht autorisierte Ankündigung zurückweisen, aber keinen unabhängigen Peer zwingen, eine Route zu akzeptieren.

Hier prägte der Backbone-Zugriff die Macht der Adressen. Die Policy-Datenbank des NSFNET war nicht das Adressregister, aber die Aufnahme in ein weit verbreitetes Routing-System machte eine registrierte Nummer nützlicher. Mit der Ausweitung des erreichbaren Netzes gewann die korrekte Vertretung über den Backbone an praktischem 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 dies glaubt. Die Policy-Einträge und die AS-Validierung verwandelten eine administrative Beziehung in eine Routing-Erlaubnis.

Die resultierende Autorität war enger als das Eigentum an einer Adresse und weiter als die bloße mechanische Paketvermittlung. Die Backbone-Betreiber kontrollierten, was ihr eigener Dienst akzeptierte. Da dieser Dienst eine außergewöhnliche Reichweite hatte, konnten ihre operativen Entscheidungen viele Nutzer betreffen. Das Ausmaß der Konsequenz ergab sich aus der Topologie und der Akzeptanz, nicht aus einem globalen Mandat.

Was die Wachstumszahlen messen

Die Expansion des NSFNET ist ein greifbarer Beleg für den öffentlichen Nutzen, aber seine Statistiken beschreiben unterschiedliche Populationen.

Die 152 Millionen monatlichen Pakete von Merit im Juli 1988 und die Basis von etwa 200 Millionen Paketen der NSF zu Dienstbeginn beziehen sich auf den Verkehr. Sie zählen keine Adressen oder Institutionen. Die Kongressaussage der NSF meldete etwa 11 Milliarden Pakete pro Monat im März 1992, ein Maß für das stark wachsende Nutzungsvolumen, nicht eine Zählung der angeschlossenen Organisationen.

Der Backbone selbst wuchs von 13 T1-Standorten auf eine T3-Architektur mit 16 Standorten. Ein Backbone-Standort war weder ein Campus noch ein regionales Netz noch ein einzelner Nutzer. Es war ein Knoten oder Anschlusspunkt innerhalb des nationalen Dienstes.

Die Kongressaussagen von 1992 bezogen sich auf etwa 5.000 Netze, davon etwa 1.500 außerhalb der USA, die mit dem Gesamtsystem verbunden waren. Diese Schätzungen wurden in einer politischen und institutionellen Anhörung präsentiert und sollten nicht als exakte Momentaufnahme der Routing-Tabelle behandelt werden.

Ein NSFNET-Routing-Update vom Januar 1993 meldete 8.997 Netze, die in der T3-Policy-Datenbank konfiguriert waren. Diese Zählung repräsentierte konfigurierte Netzeinträge und ihre bevorzugten AS-Pfade. Es war keine Zählung einzelner Organisationen. Eine Institution konnte mehrere Klassen-Netze besitzen, und ein konfigurierter Eintrag konnte primäre und sekundäre Vertretungen haben.

Die Zuteilungssummen inRFC 1366maßen noch etwas anderes. 1992 berichtete das Dokument über 49 zugeteilte Klasse-A-Nummern, 7.354 Klasse-B und 44.014 Klasse-C. Dies waren Zuteilungseinheiten im klassenbasierten Adressierungssystem, nicht NSFNET-Kunden. Einige wurden von privaten oder nicht-NSF-Netzen verwendet, und eine Klasse-A repräsentierte eine weitaus größere Adresskapazität als eine Klasse-C.

Die spätere Verkehrsvisualisierung, die vonCAIDAaufbewahrt wird, meldet 18,5 Billionen eingehende Byte im Dezember 1994. Für diese Visualisierung wurden 24.435 nationale Kundennetze zu 12.177 virtuellen Verkehrsverbindungen nach Stadt und Backbone-Knoten aggregiert. Auch hier waren ein Kundennetz, eine virtuelle Leitung in einer Visualisierung und eine Institution nicht gleichbedeutend.

Mit Bedacht verwendet, zeigen diese Zahlen mehrere Formen der Expansion: mehr Verkehr, mehr konfigurierte Routen, mehr Adresszuteilungen, mehr Kundennetze und eine größere geografische Reichweite. Sie belegen nicht, dass die Backbone-Finanzierung allein jede Veränderung verursacht hat. Fallende 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 bedeutsam bleiben. Die Investition der NSF und der von Merit geführte Dienst boten eine gemeinsam genutzte Hochgeschwindigkeits-Routing-Umgebung, 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 Vergabe kontrollierte.

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

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

Merit, IBM und MCI gründeten im September 1990 Advanced Network & Services, Inc., kurz ANS. Der Bericht der Kongressanhörung von 1992 beschreibt Merit als weiterhin verantwortlich gemäß seiner Kooperationsvereinbarung, während es einen wesentlichen Teil des Managements und Betriebs des verbesserten Backbones an die neue gemeinnützige Organisation untervergabe. Der abschließende institutionelle Bericht von Merit stellt ANS ebenfalls als das Betriebsfahrzeug für einen Großteil der Arbeiten am T3 dar.

Die verfügbaren öffentlichen Dokumente legen die organisatorischen Konturen fest, offenbaren jedoch nicht jede Betriebsklausel der Merit-ANS-Vereinbarung vom 17. September 1990. Daher ist es sicherer, die beobachtbare Arbeitsteilung zu beschreiben, anstatt nicht dokumentierte Rechte zuzuschreiben. Die NSF blieb Geldgeber und Programmaufsicht. Merit blieb in der Kooperationsvereinbarungskette verantwortlich. ANS übernahm bedeutende Ingenieur- und Betriebsaufgaben für den T3. IBM und MCI stellten weiterhin wichtige Technologie, Einrichtungen, Personal und Unterstützung zur Verfügung.

Der Übergang zu T3 erfolgte nicht sofort. Die Installation der Knoten, der anfängliche Verkehrstransport, die Migration regionaler Anschlüsse und die Außerbetriebnahme des T1-Netzes waren separate Ereignisse. Der Bericht von Merit datiert die Fertigstellung des 16-Knoten-T3-Systems auf 1991. Die T1- und T3-Einrichtungen koexistierten dann, während Anschlüsse und Routen migrierten.

Eine Betriebsmitteilung von Merit, archiviert in den NANOG-Aufzeichnungen vom November 1992, kündigte die Abschaltung des T1-Backbones für Mittwoch, den 2. Dezember 1992 an. Diese datierte Mitteilung liefert die fehlende Unterscheidung zwischen der früheren Verfügbarkeit des T3-Produktionsdienstes und der späteren Abschaltung des verbleibenden T1-Dienstes. Der T3-Backbone wurde nicht sofort vollständig exklusiv, nur weil die ersten T3-Strecken Pakete transportierten.

Das Routensystem erweiterte sich ebenfalls. Das Update vom Januar 1993, das 8.997 konfigurierte T3-Netze meldete, veranschaulicht die Menge an Policy-Daten, die der Backbone-Betrieb verwalten musste. Jeder Eintrag repräsentierte ein Netz und die erwarteten AS-Pfade, nicht die Vergabe einer Adresse. Die Datenbank operationalisierte Beziehungen, die bereits anderswo etabliert waren.

Diese Phase verstärkte daher die praktische Barriere, ohne ihre rechtliche Identität zu ändern. Ein fehlender oder falscher T3-Policy-Eintrag konnte die Erreichbarkeit eines viel größeren Dienstes beeinträchtigen. Das machte ANS oder Merit nicht zur IANA und übertrug das Eigentum an registrierten Nummern nicht auf die NSF.

Die Kommerzialisierung brachte ungleichmäßig Alternativen hervor

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 über die Bundesunterstützung hinaus. Die Commercial Internet Exchange bot eine Interkonnektion außerhalb der Verkehrsbedingungen des von der NSF unterstützten Backbones.

ANS gründete 1991 eine gewinnorientierte Tochtergesellschaft, ANS CO+RE, um kommerzielle Dienste anzubieten. Diese Regelung wurde umstritten, da ANS auch die Infrastruktur betrieb, die für den staatlich geförderten Dienst genutzt wurde. Die Teilnehmer der Anhörung im Repräsentantenhaus von 1992 bestritten die Kostenverteilung, Konsultation, Interkonnektion und Wettbewerbsvorteile.

Die Aussagen erlauben es nicht, jede Behauptung in eine Schlussfolgerung umzuwandeln. Kritiker argumentierten, dass die Struktur einen Weg begünstigte und die Grenzen der öffentlichen Unterstützung verschleierte. Merit und die NSF argumentierten, dass die Regelung private Investitionen förderte, während der Forschungs- und Bildungsdienst geschützt wurde. Die Anhörung belegt das Vorhandensein eines ernsthaften institutionellen Streits, keine erwiesene Verschwörung oder Eigentumsansprüche.

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

Diese Möglichkeit blieb bedingt. Ein Anbieter musste eine geografische Präsenz oder einen erreichbaren Präsenzpunkt haben. Der Kunde musste über eine Letzte-Meile-Schaltung, Ausrüstung, Personal, einen Dienstvertrag und die Routing-Akzeptanz verfügen. Die Existenz eines kommerziellen Backbones in den USA belegte nicht, dass jede Universität lokal einen vergleichbaren Dienst zu einem erschwinglichen Preis kaufen konnte.

Die erhaltenen Aufzeichnungen über Kent State enthalten kein zeitgenössisches Angebot von AlterNet, PSI oder einem anderen kommerziellen Anbieter, der den Standort von Kent, die Berechtigung, die Installation und die 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 für Kent im Jahr 1988 machbar war, oder ihm einen Vergleichspreis zuzuschreiben.

Was die breiteren Archive zeigen, ist eine Marktveränderung im Laufe der Zeit. In den frühen 1990er Jahren hatten Organisationen mehr mögliche Upstream-Anbieter und mehr Orte zum Austausch von Verkehr. Die mehrfachen Verbindungen von BARRNet zeigen, dass regionale Systeme das NSFNET parallel zu Behörden- und lokalen Pfaden nutzen konnten. RFC 1092 sah bereits primäre, sekundäre und „Backdoor“-Vertretungen vor. Das kommerzielle Wachstum verwandelte diese technischen Möglichkeiten in Dienstwahlmöglichkeiten, wenn auch ungleichmäßig.

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

Die Registrierung lief nach einem eigenen Zeitplan weiter

Die Kennungsverwaltung durchlief während des Betriebs des T3-Backbones ihren eigenen institutionellen Wandel.

Die NSF-Ausschreibung vom März 1992,NSF 92-24, teilte die Netzwerkinformationsdienste in Registrierungs-, Verzeichnis- und Datenbank- sowie Informationsfunktionen auf. Ab dem 1. Januar 1993 etablierte dieKooperationsvereinbarung NCR-9218742 der NSF mit Network Solutionsnicht-militärische Registrierungsdienste im Rahmen der später als InterNIC bekannten Einrichtung.

Der Leistungsumfang umfasste die Registrierung von Internet-Domains, die Zuteilung von Netznummern und die Zuteilung von AS-Nummern in Koordination mit der IANA und den einschlägigen Policy-Dokumenten. Er übertrug Network Solutions nicht die Verantwortung für den Betrieb von NSFNET-Routern oder die Auswahl kommerzieller Transitanbieter.

RFC 1400dokumentierte den operativen Übergang vom DDN-NIC zum InterNIC. Sie legte den 1. April 1993 als Datum fest, ab dem Nicht-DDN-Registrierungsanträge an den neuen Dienst zu richten waren. Die militärische Registrierung blieb auf ihrem eigenen Weg.

Diese Abfolge ist wichtig, weil sie vor der Abschaltung des alten Backbones stattfand. 1993 konnte eine Universität einen Antrag auf eine Nummer oder ein AS beim InterNIC stellen, während ihr regionales Netz weiterhin den von ANS betriebenen T3-Dienst nutzte. Die Routing-Policy-Datenbank und die Registrierungsdatenbank waren administrativ getrennt, auch wenn sie Kennungen und Kontaktinformationen teilten.

Eine korrekte Registrierung beeinflusste weiterhin das Routing. Die Betreiber mussten wissen, welche Organisation ein Netz besaß und wen sie bei Streitigkeiten über eine Ankündigung kontaktieren sollten. Aber die Registrierung aktivierte keine Backbone-Schnittstelle. Ebenso übertrug eine gültige Route im NSFNET die zugrunde liegende Registrierungsfunktion nicht auf den Backbone-Betreiber.

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

Die NSF-Ausschreibung vom Mai 1993,NSF 93-52, schlug vier separate Projektbereiche vor: Network Access Points, einen Routing Arbiter, Unterstützung für regionale Netze und einen Very High Speed Backbone Network Service für die Spitzenforschung.

Die Struktur vermied bewusst die Ersetzung des alten NSFNET-Dienstes durch einen einzigen kommerziellen Backbone. Kommerzielle Netzserviceanbieter würden den allgemeinen Verkehr transportieren und sich an den Network Access Points zusammenschließen. Regionale Netze würden Upstream-Dienst von diesen Anbietern kaufen, mit Übergangsunterstützung durch die NSF. Die Routing-Koordination würde über ein Routing-Arbiter-Projekt fortgesetzt. Der vBNS würde den Bedarf der Spitzenforschung decken, anstatt als universeller Einzelnachfolger zu dienen.

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

Die Zugangskette änderte sich entsprechend:

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

Der endgültige Übergang erfolgte schrittweise und nicht zeremoniell. Die Mitteilung von Merit vom 14. April 1995 meldete, dass nur sieben Organisationen ihre alte Beziehung zum NSFNET vollständig abgebrochen hatten. Viele nutzten neue Anbieter, während sie das NSFNET als Backup behielten.

Die verbleibenden Sitzungen sollten am 21. April einem Teststopp unterzogen werden, um unerreichbare Netze aufzudecken. Eine vorübergehende Wiederherstellung war möglich, während Probleme behoben wurden. Die Mitteilung sah dann die endgültige Abschaltung der verbleibenden Sitzungen am 28. April vor, gefolgt von der Abschaltung des Backbone-Dienstes am 30. April.

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

Die Abschaltung veranschaulicht stark die Trennung zwischen Adressregistrierung und Backbone-Dienst, belegt jedoch nicht, dass jedes einzelne Präfix unterbrechungsfrei migrierte. Die Kontinuität für das131.123von Kent State nachzuweisen, würde beispielsweise Routing-Beobachtungen vor und nach dem Wechsel zusätzlich zum Registereintrag erfordern. Die verfügbaren Übergangsmitteilungen zeigen ein System, das darauf ausgelegt war, die Erreichbarkeit während des Dienstwechsels zu erhalten; sie liefern keine präfix-spezifische Spur für Kent.

Was man mit Sicherheit sagen kann, ist, dass die Abschaltung des alten Backbones das Kennungssystem nicht abschaffte. Die Funktionen von InterNIC und IANA wurden fortgesetzt. Regionale Netze kauften Ersatztransit. Anbieter tauschten Routen an den neuen Interkonnektionspunkten aus. Der operative Wert der Adressen blieb nur bestehen, weil diese neuen Akteure die Routen transportierten und akzeptierten.

Testen der beiden Achsen ohne Erfindung von Alternativen

Die Unterscheidung kann anhand mehrerer begrenzter Szenarien getestet werden.

Eine gültige Kennung ohne nutzbaren externen Transit

Angenommen, eine Universität besitzt eine global eindeutig registrierte Netznummer, hat aber keine funktionierende regionale Anbindung oder keinen akzeptablen Upstream-Anbieter.

Sie könnte die Nummer intern verwenden, ohne mit einem anderen registrierten Netz in Konflikt zu geraten. Sie könnte lokale TCP/IP-Dienste betreiben und Verkehr über jeden bilateralen Pfad austauschen, der bereit ist, ihn zu transportieren. Die Registrierung bliebe bedeutsam.

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

Für Kent State belegen die historischen Aufzeichnungen nicht, welcher Ersatz, falls vorhanden, alle diese Bedingungen im Jahr 1988 erfüllte. Die späteren mehrfachen Gateways von OARnet belegen die Topologie, nicht ein Recht auf unabhängigen Dienst für Kent. Die Existenz von BITNET würde an sich keinen allgemeinen IP-Transit bereitstellen. Kommerzielle Anbieter wurden nach 1990 plausibler, aber es wurde kein vollständiger Preis oder Verfügbarkeitsnachweis speziell für Kent gefunden.

Die gerechtfertigte Schlussfolgerung ist daher begrenzt: Eine registrierte Adresse konnte ohne das NSFNET überleben, aber ihr externer Nutzen hing davon ab, einen anderen Carrier und eine akzeptierte Route zu erhalten. Die Machbarkeit oder Erschwinglichkeit für Kent zu einem bestimmten Zeitpunkt bleibt unbekannt.

Physischer Zugang ohne gültige öffentliche Kennung

Kehren wir die Bedingungen um. Ein regionales Netz könnte eine verfügbare Schaltung haben und bereit sein, einen Campus anzuschließen, aber dem Campus könnte eine gültige Netznummer für die allgemeine Internetnutzung fehlen.

Die Schaltung könnte Verkehr gemäß einem lokalen Adressplan oder einer anderen technisch koordinierten Regelung transportieren. Generische technische Möglichkeiten umfassen die Verwendung eines gültigen, vom Anbieter kontrollierten Adressraums oder das Zurückstellen der öffentlichen Ankündigung, bis die Registrierung geklärt ist. Die erhaltenen Aufzeichnungen über OARnet belegen nicht, welche Lösung es Kent angeboten hätte, daher sollte keine als OARnet-Politik dargestellt werden.

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

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

Eine legitime Route, die ein Peer sich weigert zu transportieren

Ein Ziel könnte korrekt registriert, an ein regionales Netz angebunden und vom NSFNET akzeptiert sein, aber dennoch über einen anderen Anbieter unerreichbar sein.

Jeder Peer oder Backbone kontrollierte seine eigene Routing-Politik. Der Maßstab des NSFNET machte seine Informationen einflussreich, aber er konnte nicht jedem Regierungs-, kommerziellen oder internationalen Betreiber befehlen, ein Netz zu verbreiten. Eine geroutete Adresse war daher der Beleg für die Akzeptanz entlang eines bestimmten Pfades, nicht der Beleg für universelle Zustimmung.

Die geeignete Abhilfe war die Routendiagnose und die Koordination zwischen den Betreibern. Das Register konnte bei der Identifizierung von Kontakten helfen, konnte aber den Transport nicht erzwingen. Merit konnte seine eigene Policy-Datenbank korrigieren, aber nicht jedes entfernte Netz konfigurieren.

Berechtigte Konnektivität mit Verkehr, der einen anderen Pfad benötigt

Ein Campus konnte auch eine gültige Kennung und eine funktionierende Route besitzen, während ein Teil des Verkehrs für den staatlich geförderten Backbone nicht berechtigt war. Dies war ein Problem der Verkehrspolitik, keine Annullierung der Adresse oder Verweigerung der physischen Mitgliedschaft.

Die Institution müsste den betreffenden Verkehr möglicherweise über einen anderen Anbieter leiten oder nachweisen, dass er dem autorisierten Forschungs- und Bildungszweck diente. Der wichtige Punkt hier ist institutionell: Die Einhaltung der akzeptablen Nutzung war eine zusätzliche Bedingung auf dem Pfad, nicht die Behörde, die die Nummer schuf.

Diese Szenarien vermeiden eine falsche Symmetrie. Ihre Konsequenzen waren nicht identisch, und die verfügbaren Abhilfemaßnahmen unterschieden sich. Ein Registrierungsfehler bedrohte die Eindeutigkeit und stabile Vertretung. Ein regionaler Fehler bedrohte die lokale Anbindung. Ein Backbone-Fehler bedrohte den überregionalen Transport. Die Ablehnung durch einen Peer bedrohte die Reichweite über den unmittelbaren Anbieter hinaus. Ein Verkehrspolitikkonflikt betraf die Nutzungen, die einen bestimmten geförderten Pfad nutzen durften.

Für den Campus-Benutzer konnten alle das gleiche Symptom erzeugen: Ein entferntes Ziel antwortete nicht. Die Governance-Analyse muss die Schicht rekonstruieren, auf der das Versagen auftrat.

Wo Autorität und Konsequenzen lagen

Die NSF regierte direkt das Programm, das sie finanzierte. Sie wählte und überwachte die Kooperationsvereinbarungsstruktur, 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. Seine Verantwortlichkeiten umfassten Netzbetrieb, Informationsdienste, regionale Anbindung und die Policy-Daten, die erforderlich waren, um die Konsistenz eines expandierenden Routing-Systems aufrechtzuerhalten.

IBM und MCI steuerten separate technische und kommunikative Beiträge bei. Sie waren weder Hochschulzulassungsbehörden noch Internet-Nummernregister. Während der T3-Phase übernahm ANS umfangreiche Ingenieur- und Betriebsaufgaben, während Merit in der NSF-Vereinbarungskette blieb.

Regionale Netze kontrollierten die campusorientierte Schicht. Sie entschieden, wen sie bedienen konnten, wie Schaltungen und Ausrüstung organisiert wurden, welche Gebühren und lokalen Bedingungen galten und wie das interne Routing funktionierte. Ihre Strukturen waren heterogen, und die Konsequenzen von Geografie oder begrenzter Carrier-Wahl variierten stark.

Die IANA-Funktion, die Internet-Registerarbeit des DDN-NIC und später die Registrierungsdienste des InterNIC kontrollierten die Kennungen und Einträge über eine separate Sequenz. Diese Einträge waren wichtig, weil doppelte oder falsch zugewiesene Nummern kein zuverlässiges globales Routing unterstützen konnten. Die Kennungsbehörden betrieben nicht die DS1-Schaltung von Kent State und wählten nicht seinen Upstream-Pfad.

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

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

Dieser Effekt erhöhte auch die Konsequenzen von Entscheidungen über regionalen Zugang und Routing-Politik. Ein Eintrag im Nummernregister war notwendig, aber nicht ausreichend. Eine regionale Schaltung ohne legitime Kennung war ebenfalls nicht ausreichend. Keine der beiden Achsen allein erzeugte allgemeine Erreichbarkeit.

Die öffentliche Investition sollte nicht als nebensächlich für dieses Ergebnis betrachtet werden. NSFNET schuf nationale Interoperabilität mit einer Geschwindigkeit und einem Umfang, die einzelne Universitäten wahrscheinlich nicht separat hätten reproduzieren können. Es verteilte Fixkosten, entwickelte Betriebsabläufe, unterstützte regionales Wachstum und gab Forschern Zugang zu entfernten Ressourcen. Sein Erfolg erklärt teilweise seine Macht: Die Abhängigkeit folgte dem Nutzen.

Die Abhängigkeit sollte auch nicht mit einem formellen Monopol auf Adressen verwechselt werden. Kommerzielle Dienste, Behördennetze, direkte Peers und regionale „Backdoors“ existierten oder entstanden zu verschiedenen Zeiten. Ihre Verfügbarkeit war ungleichmäßig, und ihre Existenz garantierte keine realisierbare Alternative für jede Institution. Aber sie zeigen, dass der Wert von Routen migrieren konnte, ohne dass die Kennung neu erstellt werden musste.

Der Übergang von 1995 machte diese Trennbarkeit systemweit sichtbar. Der alte Backbone endete. Die Registrierung wurde fortgesetzt. Regionale Netze wechselten die Anbieter. Routen migrierten zu kommerziellen Netzen und Austauschpunkten. Die Routing-Koordination bestand in neuen Organisationen fort.

Dies war kein Beleg dafür, dass jede Migration reibungslos verlief. Es war der Beleg dafür, dass Internet-Identität und Internet-Transport einen institutionellen Austausch überleben konnten, weil sie nie dieselbe Funktion gewesen waren.

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

Dennoch waren ihre Entscheidungen eng genug aufeinander abgestimmt, dass Benutzer sie als eine einzige Barriere empfinden konnten. Die gouvernementale Bedeutung des NSFNET liegt in dieser Abstimmung. Der Backbone-Zugriff prägte die Macht der Adressen nicht, indem er die Autorität über Kennungen absorbierte, sondern indem er bestimmte, ob eine legitime Kennung an einer der wertvollsten Routing-Umgebungen ihrer Zeit teilnehmen konnte.

Quellen

• Unterausschuss für Wissenschaft des Repräsentantenhauses der Vereinigten Staaten,Management of NSFNET, 12. März 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,Programm zur Abschaltung des T1-Backbones NSFNET, Archiv November 1992
• Merit, NSFNET-Routing-Policy-Update mit 8.997 konfigurierten T3-Netzen, Archiv Januar 1993
• NSF 92-24,Network Information Services Manager(s) for NSFNET and the NREN
• NSF und Network Solutions, Kooperationsvereinbarung NCR-9218742, 1. Januar 1993
• NSF 93-52,Network Access Point Manager, Routing Arbiter, Regional Network Providers, and Very High Speed Backbone Network Services Provider, 6. Mai 1993
• U.S. GAO,Sprint Communications Company, L.P., B-256586 und B-256586.2, 9. Mai 1994
• CAIDA Internet Atlas Gallery, NSFNET-Verkehrs- und Aggregationsdaten Dezember 1994
• 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. Mai 1995