Zusammenfassung

  • RFC 1074 beschrieb für NSFNET eine auf Level 2 und permanente Punkt-zu-Punkt-Verbindungen begrenzte ANSI-IS-IS-Implementierung. IS-IS- und ES-IS-PDUs liefen als IP-Protokoll 85; IPv4-Adressen und aus AS-Nummern abgeleitete Administrative Domains wurden in NSAP-förmige Felder gesetzt.
  • EGP-Erreichbarkeit gelangte nicht unverändert in den Kern. Ein NSS prüfte die Routing Policy Data Base, erzeugte einen Präfix für eine End System PDU, übernahm einen Policy-Kostenwert und verteilte erst dieses neue Ergebnis.

Der Backbone aus RFC 1074 verband dreizehn Standorte in den kontinentalen USA über permanente T1-Strecken mit 1,544 Mbit/s. Logische Verbindungen konnten einen Teil oder die volle Leistung nutzen. Ein Nodal Switching Subsystem aus IBM-RT/PC-Prozessoren und einem angepassten 4.3BSD-Kernel schaltete an jedem Ort die Pakete. Für das Routing war ein NSS ein Knoten.

Zwischen diesen Knoten arbeitete eine Anpassung des von ANSI an ISO gegebenen IS-IS. An den regionalen Grenzen sprach NSFNET EGP. Dazwischen lag kein formloser Austausch: Eine externe Behauptung wurde administrativ geprüft und in die interne Kontrollsprache umgebaut.

Von IS-IS blieb ein gezielter Ausschnitt

ANSI IS-IS teilte Level 1 innerhalb eines Gebiets und Level 2 zwischen Gebieten. NSFNET implementierte ausschließlich Level 2. Bei den subnetzabhängigen Funktionen beschränkte es sich auf allgemeine Topologien aus permanenten Punkt-zu-Punkt-Strecken. Der Name bezeichnete deshalb keine vollständige OSI-Einführung, sondern eine auf den Backbone zugeschnittene Auswahl.

Auch die Schicht war anders. Im ISO-Rahmen lag IS-IS direkt über der Sicherungsschicht. NSFNET transportierte IS-IS- und ES-IS-PDUs über IP mit Protokollnummer 85; ein Discriminator in der PDU unterschied die Formate. Das IANA-Register führt 85 weiterhin als NSFNET-IGP.

Die Registrierung belegt weder heutigen Einsatz noch historische Routenerfolge. Ein empfangenes Protokoll-85-Datagramm wäre erst ein Transportnachweis. Dekodierung, Link-State-Aufnahme, SPF-Ergebnis, Tabelleneintrag und Nutzdatenpfad wären weitere Beobachtungen.

Für große Kontrollnachrichten nutzte die Implementierung IP-Fragmentierung und -Reassembly, statt eine eigene IS-IS-Fragmentierung zu bauen. Man erwartete keine Überschreitung des IP-Maximums. Damit legte der Träger auch die Größen- und Fehlergrenze des geliehenen Protokolls fest.

Leere Bytes markierten den Adapter

ANSI IS-IS erwartete NSAP-Adressen. NSFNET hatte IPv4-Adressen, Netznummern und AS-Nummern. Seine neun Byte lange Domain Specific Part enthielt zwei Byte Administrative Domain, zwei leere Byte, vier Byte IP-Adresse und ein weiteres leeres Byte. Die Initial Domain Part blieb ungenutzt.

Die sechs Byte lange Router-ID bestand ebenso aus zwei leeren und vier IP-Bytes. Der Network Entity Title wurde aus der aufgebauten NSAP-Form abgeleitet. Die Lücken sind kein bedeutungsloser Verschnitt. Sie zeigen, dass Internet-Fakten an bekannte Stellen einer fremden Struktur gesetzt wurden.

Für diese Implementierung behandelte NSFNET jedes Autonomous System als eigene Administrative Domain. So ließen sich Wer und Was einer EGP-Ankündigung gemeinsam kodieren. Das war eine lokale Arbeitsgleichung, keine universelle Definition.

Vor der Route stand das Recht zur Repräsentation

RFC 1092 beschreibt EGPs Grenze. Sein Modell nahm einen geplanten Baum an; NSFNET besaß jedoch Backdoor-Verbindungen zwischen Regionen. Mehrere Regionals konnten dasselbe Netz als erreichbar melden. EGP bestimmte weder allgemeingültig den primären Vertreter, noch hinderte es eine Region daran, ein fremdes Netz mit Distanz null zu beanspruchen.

Netze und regionale Betreiber vereinbarten deshalb Haupt- und Ersatzvertretungen. Das Network Operations Center legte sie in der Routing Policy Data Base ab. Der anschließende NSS konnte Quelladresse, AS, Netznummer und Priorität prüfen. Abweichungen führten zu Ablehnung oder Alarm.

Eine erlaubte EGP-NR wurde nicht als EGP durch den Kern geflutet. Netznummer und Administrative Domain des Peers wurden in einen NSAP-förmigen Adresspräfix kodiert und in eine End System PDU eingesetzt. Der Kostenwert kam aus der Policy-Datenbank. IS-IS verteilte damit eine neue Aussage aus Beobachtung, Erlaubnis und Präferenz.

Ein EGP-Datensatz beweist die Aussage des Nachbarn. Eine Policy-Zeile beweist administrative Absicht. Eine ES-PDU belegt die Erzeugung des umgebauten Zustands. Aufnahme, SPF, Installation und tatsächlicher Pfad kommen später. Keine dieser Stufen darf für die ganze Kette sprechen.

Informationspolitik war keine Kontrolle jedes Pakets

RFC 1104 nennt vier Prüfungen: Peer über Quelladresse, Administrative Domain beziehungsweise AS, angekündigte Internet-Netze und Metrik über die Datenbank. Die NSFNET-Implementierung lief demnach seit Juli 1988.

Sie steuerte die Verteilung von Routinginformation auf Netz- oder Domänenebene. Weil daraus Tabellen entstanden, musste der NSS nicht für jedes Datenpaket die Policy abfragen. Das hielt den Weiterleitungspfad leicht, bedeutete aber auch: keine Autorisierung einzelner Nutzer und kein universeller Paketfilter.

Eine erlaubte Route konnte trotzdem kaputt sein. Veraltete Daten, unterschiedliche Versionen oder ein legitimer Peer mit defektem Pfad trennten administrative Gültigkeit von realer Lieferung.

Integrated IS-IS war eine spätere, andere Konstruktion

RFC 1195 standardisierte 1990 Integrated IS-IS für IP-, OSI- und gemischte Domains. Es fügte IP-spezifische Information hinzu und leitete IP- und OSI-Pakete unverändert über die jeweiligen Links. Umfang und Drahtmodell waren breiter als bei RFC 1074.

Beide Arbeiten lösten Link-State aus der Bindung an eine einzige Netzwerkschicht. RFC 1074 trug aber Kontroll-PDUs über IP und setzte Internet-Werte in eine NSAP-Form; RFC 1195 definierte explizite integrierte IP-Funktionen. Eine Gleichsetzung würde gerade die frühe Übersetzungsleistung aus der Geschichte entfernen.

Der Rückblick in RFC 1222 nennt das Architekturziel: Die T1-Phase entkoppelte Backbone-IGP und Client-IGPs stark und nutzte Exterior Routing an der Grenze. Jede administrative Einheit behielt ihre interne Wahl. Einheitlichkeit war nicht nötig; eine kontrollierte Naht war es.

Quellen und Grenzen

RFC 904 liefert EGPs Grundgrammatik, enthält aber nicht NSFNETs spätere Vertretungspolitik. RFC 1093 ordnet die IGP/EGP-Grenze in die Gesamtarchitektur ein. RFC 1074, 1092 und 1104 sind Implementierungsberichte Beteiligter. Sie belegen Entwurf und Absicht, nicht Verfügbarkeit oder lückenlose Konformität. RFC 1222 blickt später zurück; RFC 1195 spezifiziert ein Folgesystem. IANA registriert eine Nummer, nicht Verkehr.

Die belastbare Aussage bleibt schmal: IP trug die PDU, die NSAP-Form die Internet-Adresse, EGP eine externe Behauptung, Policy deren Zulässigkeit und Kosten, IS-IS den daraus gebauten Zustand. Kein einzelner Beleg war die Route.