Zusammenfassung

  • Der Transportanbieter sah in RFC 1307 nur up oder down; DSLCP hielt intern Down, Coming Up, Up, Going Down, Bring Down und Bring Up auseinander.
  • Ein Release im Zustand Up löste Teardown aus und wechselte nach Going Down, meldete dem Anbieter aber sofort down, noch bevor der Controller geantwortet hatte.
  • DSLCP beantwortete Teardown lokal immer erfolgreich und setzte selbst bei unbekannter Controller-Transaktion fort, als wäre der Antrag gelungen. Das bewies keinen physischen Abbau, keine freie Kapazität, kein Abrechnungsende und kein Datenergebnis.

Eine binäre Anzeige ist eine bewusste Kürzung

Zwei Zustände wirken vollständig, solange die Übergänge augenblicklich und zuverlässig erscheinen. Ist eine Leitung oben, kann sie benutzt werden; ist sie unten, ist sie weg. RFC 1307 entwarf jedoch ein System, in dem Befehle über ein unzuverlässiges Netz liefen und ein eigener Controller die Hardware behandelte. Zwischen Wunsch und Wirkung lagen damit Zeiten, in denen „oben“ und „unten“ zu grob waren.

Das Dokument erschien im März 1992 als Experimental RFC für weitere Forschung, nicht als Internetstandard. Es beschrieb das Dynamically Switched Link Control Protocol aus einem Projekt von Cray Research. Ein Host sollte ihm bekannte nachgelagerte Netzverbindungen steuern können, ohne dass der Transportanbieter die unterschiedlichen Schalttechniken verstehen musste. Der Text belegt diesen Entwurf, keinen aktuellen Einsatz.

Der Ausgangspunkt war wirtschaftlich. Leitungsvermittelte Verbindungen blieben normalerweise getrennt, weil dauerndes Verbundensein teuer war. Der Transportanbieter konnte Anfang und Ende einer Transportsitzung erkennen und zu diesen Grenzen Aktivierung oder Freigabe verlangen. Ein separater Link Controller übernahm Hardware- und Verwaltungsdetails. Wer Bedarf erkannte, war also nicht dieselbe Instanz wie jene, die den physischen Aufbau ausführte.

Der Steuerweg musste vor der Nutzverbindung funktionieren

Noch bevor DSLCP eine Datenverbindung vorbereiten konnte, brauchte der Host einen bestehenden Netzwerkpfad zum Link Controller. Steuerbotschaften durften als IP- oder UDP-Datagramme reisen. Zuverlässigen Transport verlangte das Protokoll nicht.

Damit waren Steuer- und Datenpfad von Anfang an getrennte Evidenz. Eine DSLCP-Nachricht konnte versendet werden, ohne dass die nachgelagerte Leitung bereits stand. Ein verlorenes Steuerdatagramm erklärte eine ausbleibende Antwort, sagte aber allein nichts über Nutzdaten. Der Weg, der den Schalter anweist, ist nicht der Weg, den der Schalter schaffen soll.

Das Nachrichtenformat enthielt einen 16-Bit-Identifier, zwei 32-Bit-Endpunktadressen, Funktion, Ereignisstatus und einen beliebigen, für den Controller bedeutsamen Nachrichtenteil. Die Transaktion sollte durch Identifier und beide Endpunkte gemeinsam erkannt werden. Der Identifier allein war weder Leitung noch Sitzung, Person oder global eindeutiges Autoritätszeichen.

Auch der Ereignisstatus war relational. Er beschrieb den gesteuerten Link bezogen auf die zuletzt angeforderte Funktion. „Setup succeeded“ oder „teardown failed“ verliert daher ohne ausstehende Funktion, Endpunkte, Zustand und Zeitpunkt einen Teil seiner Bedeutung. Ein Statuswort ist kein freistehendes physisches Urteil.

Die sechs Zustände bewahrten die noch offene Vergangenheit

Nach außen kannte der Transportanbieter lediglich Up und Down. DSLCP unterschied Down, Coming Up, Up, Going Down, Bring Down und Bring Up. Diese vier zusätzlichen Namen trugen die zeitliche Arbeit, welche die Oberfläche absichtlich verschwieg.

Coming Up bedeutete: Setup ist angefordert, die Antwort steht aus. Going Down bedeutete entsprechend einen offenen Teardown. Bring Down entstand, wenn während des Aufbaus bereits ein Release eintraf. Bring Up entstand, wenn während des Abbaus erneut Connect verlangt wurde. Die Zustandsmaschine musste nicht nur wissen, was gewünscht ist, sondern auch, welcher ältere Befehl noch beim Controller wirken könnte.

Kommt Release während Coming Up, lässt sich das versendete Setup nicht zurückholen. DSLCP geht nach Bring Down. Meldet der Controller anschließend Setup-Erfolg, wird sofort Teardown gesendet und Going Down betreten. Der Erfolg kann also gültig sein und dennoch der aktuellen Absicht widersprechen.

Das Spiegelbild gilt für Connect während Going Down. DSLCP wechselt nach Bring Up, wartet den Abbau ab und sendet danach erneut Setup. Zu einem Zeitpunkt können Benutzerwunsch, ausstehender Controller-Befehl und nächste lokale Aktion in entgegengesetzte Richtungen zeigen. Die sechs Zustände verhindern, dass dieser Widerspruch als einfacher Schalterwechsel verloren geht.

RFC 1307 forderte den Transportanbieter deshalb auf, den konkreten Linkstatus nicht selbst zu verfolgen. DSLCP besaß die versteckte Zustandsführung und konnte Umleitung oder andere Verarbeitung vornehmen. Diese Abstraktionsgrenze verringerte Kopplung. Sie machte DSLCP aber weder zum Sensor der physischen Leitung noch zur Autorität über Abrechnung oder Datenerfolg.

Aufbau wurde berichtet, Abbau wurde zugesagt

Bei Setup informierte DSLCP den Transportanbieter darüber, ob der einzelne Antrag gelungen oder gescheitert war. Bei Teardown war die Regel anders: Der Anbieter durfte Erfolg annehmen, weil DSLCP auf einen Abbauwunsch immer Erfolg zurückgab.

Im stabilen Zustand Up zeigt sich die zeitliche Lücke am klarsten. Ein Teardown-Antrag veranlasst DSLCP, die Abbaunachricht zu senden und nach Going Down zu wechseln. Gleichzeitig erhält der Transportanbieter die Meldung, der Link sei down. Die Controller-Antwort war zu diesem Zeitpunkt noch nicht erforderlich.

Das Wort bezeichnete damit die lokale Serviceentscheidung: DSLCP behandelte die Verbindung gegenüber diesem Aufrufer nicht länger als verfügbar. Es bezeichnete nicht notwendig den vollendeten Hardwarezustand. Diese Semantik ist für eine einfache Schnittstelle brauchbar. Sie wird falsch, sobald ein nachgelagertes System daraus freie physische Kapazität, beendete Gebühren oder gestoppten Datenverkehr ableitet.

Wiederholung machte alte Antworten wieder sichtbar

Ohne zuverlässigen Steuertransport benötigte das Protokoll Timeouts und Retransmits. Die lokale Umgebung der Autoren verwendete fünf Sekunden und drei Wiederholungen, sagte aber ausdrücklich, dass andere Umgebungen andere Werte brauchen würden. Entscheidend ist nicht die Zahl, sondern ihre Folge: redundante Anfragen, unerwartete Antworten und umgekehrte Reihenfolgen waren erwartbare Bedingungen.

Trifft Setup-Erfolg ein, während DSLCP bereits Down ist, deutet RFC 1307 auf doppelte Anfragen oder Paketumsortierung. Die Reaktion ist ein kompensierender Teardown. Der Erfolg muss also nicht falsch sein; er kann zu einer inzwischen verlassenen Absicht gehören. In Bring Down löst derselbe Erfolg ebenfalls Teardown aus und führt nach Going Down.

Ein Protokoll, das nur den letzten sichtbaren Zustand speichert, würde hier die Ursache der Kompensation verlieren. „Down“ nach verspätetem Erfolg kann bedeuten, dass Setup tatsächlich stattfand und anschließend rückgängig gemacht werden sollte. Es ist nicht gleichbedeutend mit „es gab nie einen Aufbau“.

Noch deutlicher ist Teardown-Erfolg im Zustand Up. Der RFC nennt dies einen Fehlerfall. Als konservative Behandlung empfiehlt er, die Verbindung herunterzubringen und neu zu synchronisieren; zugleich erwähnt er, dass Ignorieren vielleicht ebenfalls zufriedenstellend sein könnte. Das Dokument behauptet keine eindeutige physische Rekonstruktion aus der widersprüchlichen Nachricht.

„Unbekannte Transaktion“ führte trotzdem zur lokalen Ruhe

Im Zustand Up konnte Teardown scheitern, weil der Controller für Identifier und Endpunkte keinen Transaktionsdatensatz fand. Statt den Fehler dem Benutzer als gescheitertes Release aufzubürden, sollte DSLCP fortfahren, als wäre der Antrag erfolgreich gewesen.

„Als ob“ ist der entscheidende Ausdruck. Er legt den nächsten lokalen Zustand fest, nicht die Geschichte des Controllers. Vielleicht war dessen Datensatz verloren, nie angelegt oder schon entfernt. Die Antwort allein sagt nicht, ob und wann eine reale Leitung aufgebaut oder abgebaut wurde. Controller-Unkenntnis ist keine nachträgliche Bestätigung physischer Abwesenheit.

Daneben stand ein eigener asynchroner Network-down-Status. Der Controller konnte melden, dass das Netz unabhängig von einem Host-Release ausgefallen war. In Coming Up, Bring Up oder Up wechselte DSLCP daraufhin nach Down und benachrichtigte den Anbieter. Derselbe sichtbare Endzustand konnte somit aus Benutzerabsicht, lokaler Abstraktion oder externer Störungsmeldung entstehen. Die Herkunft blieb für die Deutung unverzichtbar.

Weder Sicherheitsnachweis noch Abrechnungsbeleg

Die Security Considerations erklären ausdrücklich, dass Sicherheitsfragen nicht behandelt werden. Aus Identifiern, Endpunktadressen, Controller-Texten und Antworten lassen sich daher keine Zusicherungen über Authentifizierung, Autorisierung, Integrität oder Vertraulichkeit gewinnen. Ebenso wenig beschreibt ein Kontrollstatus die Zustellung von Transportdaten oder das Ergebnis einer Anwendung.

Diese Geschichte überschneidet sich nicht mit dem veröffentlichten RFC-1306-Artikel. Dort gehören Routensuche, externer Aktivierungsantrag, die No-data-Regel für eine unvollständige Leitung, Routen-Aliases und ein eigener Timer vor dem ersten Byte zum Gegenstand. Hier geht es um RFC 1307: die sechs verborgenen Zustände, umgekehrte Absicht, stets erfolgreichen lokalen Teardown, unbekannte Transaktionen und verspätete Antworten.

Quelle und Beweisgrenzen

Einzige Quelle ist RFC 1307, veröffentlicht im März 1992 als Experimental RFC für weitere Forschung. Er belegt Nachrichtenfelder, Zustandsmaschine, Wiederholungsverhalten und die beschriebenen Schnittstellenregeln. Er belegt keinen realen Controller, Stromkreis oder Austausch und keine Sicherheit, Kapazitätsfreigabe, Abrechnungswirkung, Datenübertragung oder Anwendungsausgabe.