Zusammenfassung

  • RFC 2171 beschrieb ein durch Switches erzeugtes Mehrfachzugriffsnetz über Punkt-zu-Punkt-SONET/SDH. Ein Knoten erbte die Kennung seines Ports; in einem Cluster bestand die Adresse aus Switch- und Portanteil.
  • Das Zielfeld lenkte die Weiterleitung eines HDLC-Rahmens. Es authentisierte weder Rechner noch Eigentümer oder Organisation; ein ungültiges Ziel konnte ohne Rückmeldung verworfen werden.
  • Das Memorandum vom Juni 1997 war Informational, kein Ergebnis einer IETF-Arbeitsgruppe und kein Standards-Track-Dokument. Seine möglichen Topologien waren keine Belege für breite Nutzung oder Interoperabilität.

Der Anschluss gab den Wert vor

RFC 2171 formulierte die maßgebliche Beziehung ausdrücklich: Jeder Port eines Switches besaß innerhalb dieses Switches eine eindeutige Kennung, und der angeschlossene Knoten musste die Adresse des Ports übernehmen. Knotenadresse und Portkennung waren dort gleich.

Diese Regel machte die Vermittlung einfach. SONET/SDH lieferte optische Punkt-zu-Punkt-Verbindungen. MAPOS verpackte Netzwerkdatagramme in HDLC-Rahmen und verband mehrere Leitungen über einen Frame-Switch. Der Sender setzte ein Ziel, der Switch wählte den Ausgang. Aus getrennten Leitungen entstand so funktional ein LAN mit Mehrfachzugriff, Broadcast und Multicast.

RFC 2171 zeigte Direktverbindung, Stern mit einem Switch und einen Verbund mehrerer Switches. Im Verbund bezeichneten die höherwertigen Bits den Switch, die übrigen den lokalen Knoten oder Port. RFC 2173 nannte die Sache beim Namen: Die HDLC-Adresse entsprach der Nummer des Ports, an dem der Knoten angeschlossen war.

„Knotenadresse“ war damit kein unveränderlicher Maschinenname. Der Wert kodierte einen Ort in einer begrenzten Topologie. Ein Umstecken konnte die Weiterleitungswahrheit ändern, ohne dass Rechner, Betreiber oder Eigentümer wechselten.

Eindeutig nur im passenden Raum

Das Adressfeld war acht Bit lang. Das niederwertigste Bit markierte das Feldende; bei Unicast war das höchstwertige Bit null, sodass sechs Bits für das Ziel blieben. 0xFF bedeutete Broadcast, 0x01 den Kontrollprozessor des Switches. Ein getrenntes Quelladressfeld gab es nicht.

Bei einem Switch wählte der Wert einen Port. In einem Cluster wählte ein Teil zunächst den Switch, der andere den Port. RFC 2174 beschrieb die Verarbeitung: Entsprach der Switch-Anteil dem lokalen Switch, ging der Rahmen an den kodierten Port; andernfalls bestimmte eine Routingtabelle den nächsten Switch.

Die Eindeutigkeit blieb daher auf das konfigurierte System beschränkt. Der Punkt-zu-Punkt-Sonderfall in RFC 2173 zeigt dies besonders deutlich: Beide Enden durften 0x03 erhalten. Das war laut Dokument unproblematisch, weil in dieser Anordnung jede Adresse funktionierte. Eine Zahl, die in anderem Kontext gefahrlos doppelt vorkommen kann, ist kein inhärenter Identitätsnachweis.

Auch automatische Zuweisung fügte keine Authentisierung hinzu. Nach Empfang des SONET-Signals forderte der Knoten beim lokalen Kontrollprozessor eine Adresse an, wiederholte nach fünf Sekunden und prüfte den Wert alle 30 Sekunden. Nach 90 Sekunden ohne Anfrage oder bei Signalverlust konnte der Switch den Knoten als ausgefallen ansehen. Diese Signale pflegten lokalen Anschlusszustand; sie bewiesen weder Eigentum noch organisatorische Zugehörigkeit.

Weiterleitung ist noch keine Zustellung

RFC 2171 beschrieb verbindungslose Übertragung. Der Knoten trug das Ziel ein; ein oder mehrere Switches leiteten anhand dieses Werts weiter. War die Zieladresse ungültig, wurde der Rahmen still verworfen.

Das Feld belegt also die verlangte Auswahl des Senders. Ein Treffer in der Tabelle belegt, dass der Switch einen nächsten Hop oder lokalen Port fand. Keines von beidem beweist allein den Empfang beim Host, die Annahme durch eine höhere Schicht oder den Erfolg einer Anwendung. Stilles Verwerfen erzeugt gerade keinen positiven Beleg.

Oberhalb von MAPOS blieb IPv4 ein eigener Namensraum. RFC 2176 verlangte einen ARP-Cache, der IPv4-Adressen mit acht Bit langen HDLC-Adressen verband. Die notwendige Zuordnung zeigt, dass beide Werte verschieden waren. Sie lieferte Weiterleitungsinformation und machte aus dem Portwert keine beständige Hostidentität.

Der Rahmen orientierte sich an Mechanismen aus RFC 1662. Diese Herkunft belegt das Format, nicht die Verbreitung. RFC 2171 erklärte sich selbst zum Informational-Memo außerhalb einer IETF-Arbeitsgruppe und des Standards Track. Sicherheitsfragen blieben undiskutiert; der Anhang nannte Unterschiede zwischen SONET, SDH und Implementierungen, die Interoperabilität stören konnten.

Die historische Aussage ist deshalb begrenzt, aber belastbar: Eine kurze Adresse konnte für die Handlung eines Switches genügen. Sie lokalisierte einen Anschluss in genau dieser Struktur; eine dauerhafte Identität durfte daraus nicht ohne weitere Belege entstehen.

Quellen und Grenzen

  • RFC 2171, Kernprotokoll, Topologien und Adressregel.
  • RFC 2173, automatische portbezogene Zuweisung.
  • RFC 2174, Clusteradressierung und Weiterleitung.
  • RFC 2176, Abbildung zwischen IPv4 und HDLC.
  • RFC 1662, zitierte HDLC-ähnliche Rahmengrundlage.

Diese Quellen belegen keine breite Einführung, gemessene Interoperabilität, authentisierte Identität, Eigentum, Ende-zu-Ende-Zustellung oder heutige Nutzung.