Zusammenfassung

  • BARRNet führte 1991 insgesamt 1.816 externe Routen in OSPF. Der frühe Betrieb zeigte einen zusätzlichen Hop für einen Teil des NSFNET-Verkehrs und Speicherdruck auf kleineren Routern.
  • Der Bericht verknüpft diese Grenzen mit Weiterleitungsadressen und Stub Areas in OSPFv2. Er beschreibt einen konkreten Betriebsfall, nicht den alleinigen Grund für die gesamte Protokollentwicklung.

Im April 1990 nahm BARRNet OSPF Version 1 in einem Forschungsnetz in Nordkalifornien in Betrieb. Im November lief dort bereits Version 2. Als John Moy das Netz im Juli darauf beschrieb, vermerkte er mehr als einen frühen Anwender: Ein Teil der Routen führte über einen unnötigen zusätzlichen Router, und manchen Geräten fehlte der Speicher für sämtliche externen Routen. Der Bericht nennt diese beiden Grenzen als Anlass für zwei Funktionen, die OSPFv2 ergänzte. Der Fall ist ungewöhnlich greifbar: Betreiber konnten auf realen Verkehr und reale Geräte zeigen, an denen sich der fehlende Protokollmechanismus bemerkbar machte. RFC 1246, §§6.0, 6.2.1–6.2.2

BARRNet verband mehr als einen Hochschulcampus. Laut dem Bericht von 1991 bediente das Netz ungefähr 80 Mitgliedsstandorte zwischen Sacramento und Monterey; die Anschlüsse reichten von 9,6 kbit/s bis zu einem vollständigen T1. Mitglieder waren Hochschulen, Behörden und Unternehmen. In Stanford verband BARRNet sich über T1 und T3 mit NSFNET. Weitere Übergänge bestanden zu ESnet in Lawrence Livermore, zum DDN über den Federal Internet Exchange bei NASA Ames und zu den kalifornischen Hochschulnetzen. Das Regionalnetz musste also lokale Erreichbarkeit bereitstellen und zugleich Routen mit mehreren größeren Netzen austauschen. RFC 1246, §6.2

Der Kern bestand aus 14 Proteon-Routern. Sechs davon bildeten einen redundant verbundenen Ring; vollständige T1-Strecken verbanden die Kernstandorte. Die Mitgliedsstandorte hingen hinter dem Kern, meist sternförmig mit Stanford als Mittelpunkt. Diese Anordnung ist relevant, weil externe Gateways und die Router, die den Verkehr behandelten, an verschiedenen Stellen desselben Regionalnetzes lagen. RFC 1246 zählt damals 1.816 externe Routen im OSPF-System. Die meisten kamen von NSFNET; weitere stammten von NSN, von BARRNet-Routern mit anderen Routingprotokollen und von ESnet. BARRNet importierte RIP- und EGP-Routen in OSPF, verwendete externe Metriken des Typs 1 und Route-Tags, um die erneute Bekanntgabe über EGP zu steuern. Ein Protokoll löste das andere nicht sauber ab. OSPF musste mit den bereits bestehenden Routing-Austauschen zusammenarbeiten. RFC 1246, §§6.2.1–6.2.2

Ein Netzwerkverzeichnis von 1990 beschreibt BARRNet ebenfalls als Regionalnetz aus gemieteten Leitungen, Richtfunkstrecken und unterschiedlichen Standortanschlüssen. Eine spätere Internet2-Rückschau berichtet, dass Eigentum und Wartung der Router ungewöhnlich dezentral bei den Mitgliedsuniversitäten lagen. Diese Quellen trennen das gemeinsame Routing-System von der Verantwortung für einzelne Geräte; sie belegen nicht, dass diese Organisationsform den zusätzlichen Hop oder den Speichermangel verursachte. RFC 1245 dokumentiert OSPF-Interoperabilitätstests, RFC 1131 die ursprüngliche Version-1-Spezifikation: Standardtext, Implementierungen und Betriebserfahrung entwickelten sich parallel. The User’s Directory of Computer Networks (1990); Internet2-Rückschau; RFC 1245; RFC 1131

Das erste Problem lag an der Grenze. Nur BR5 und BR6 tauschten EGP-Informationen mit dem System aus, das RFC 1246 „NSS“ nennt. Ohne eine eigene Weiterleitungsadresse in einer externen OSPF-Link-State-Anzeige schickten BR10, BR16 und BR28 für NSFNET-Ziele bestimmte Pakete zunächst zum Router, der die Route bekannt gab – auch wenn der tatsächliche externe nächste Hop direkt erreichbar war. So kam ein Router zusätzlich in den Weg. Mit dem Weiterleitungsadressfeld in OSPFv2 konnte die Anzeige den Router benennen, an den Pakete für das Ziel tatsächlich gehen sollten. Interne Router konnten den direkten Weg nehmen. Die Spezifikation erklärt das mit einem allgemeinen Beispiel; Moys Feldbericht ordnet dasselbe Verhalten den benannten BARRNet-Routern zu. Da die Quelle „NSS“ nicht ausschreibt, bleibt die Abkürzung hier unverändert. RFC 1246, §6.2.2; RFC 1247, §§2.2, 12.4.4

Das zweite Problem war der Speicher. Einige Router konnten nicht alle externen Routen halten. BARRNet nutzte vier Stub Areas, jeweils ein einzelnes LAN ohne OSPF-Router im Inneren. In Stub Areas wurden externe Anzeigen nicht geflutet; dadurch sank die Menge der Informationen, die ihre Router speichern mussten. Der Bericht beschreibt das als Versuch, OSPF auf Geräten mit knappem Speicher zu betreiben – nicht als Zusage, dass jedes kleine Gerät dafür geeignet war. Speicherkapazitäten oder Vorher-nachher-Messungen nennt er nicht. Das Design tauschte eine vollständige Sicht auf externe Routen gegen einen geringeren Routing-Zustand in der Area. RFC 1246, §§6.2.1–6.2.2; RFC 1247, §3.6

Moy ordnet BARRNet neben mehreren frühen Installationen ein. Im selben Bericht stehen auch NASA Science Internet und OARnet; OSPF wurde im Frühjahr 1990 erstmals im Internet eingesetzt. Beim ersten Einsatz fand man keine Protokollfehler, wohl aber wünschenswerte Ergänzungen. BARRNets Bedeutung ist enger und besser belegt als ein Anspruch auf den ersten Einsatz: Der Bericht benennt den Umweg und den Speichermangel, die zwei Funktionen der Version 2 motivierten. RFC 1247 hält außerdem fest, dass Version 1 und Version 2 nicht miteinander interoperierten. Ein Versionswechsel war damit auch eine betriebliche Grenze. Der Bericht nennt BARRNets Einführungsmonate, enthält aber weder ein Router-für-Router-Migrationsprotokoll noch den Beleg für einen gleichzeitigen Wechsel. RFC 1246, §§6.0, 6.2.2; RFC 1247, Anhang F

Diese Beleggrenze hält die Geschichte im richtigen Maßstab. Eine Spezifikation konnte gewünschtes Routerverhalten festlegen; das laufende Netz zeigte, wo das Modell einen zusätzlichen Transit verursachte oder mehr Zustand verlangte, als ein Gerät speichern konnte. Die Quellen sagen nicht, dass BARRNets Topologie oder OSPF allein die Probleme des Internets lösten. Sie dokumentieren zwei konkrete Anforderungen aus dem Betrieb: Die Anzeige sollte den tatsächlich benötigten nächsten Hop benennen, und eine ressourcenarme Area sollte weniger externe Routen speichern können.

Quellen