Zusammenfassung

  • RFC 1434 beendete LLC Type 2 an jedem Data Link Switch. Die beiden Endgeräte hatten damit zwei unabhängige lokale Verbindungen und keinen einzigen Data Link durch das WAN.
  • SSP musste eine Station suchen, ein Paar nur lokal bedeutender Circuit IDs austauschen und den entfernten Kontakt herstellen; eine aktive TCP-Verbindung belegte diese Schritte nicht.
  • Lokale Bestätigungen schützten LAN-Zeitgeber vor wechselnder WAN-Laufzeit. Die Bündelung schuf jedoch ein gemeinsames Ausfallrisiko: Ein verlorener Transport riss sämtliche darauf liegenden Schaltkreise mit.

Ein LAN-Zeitgeber konnte das WAN falsch lesen

LLC Type 2 beruhte auf kleinen und berechenbaren Laufzeiten. Mit einem festen Zeitgeber ließ sich eine verlorene Frame erkennen. Über langsame oder ausgelastete Weitverkehrsverbindungen war diese Annahme gefährlich: Eine verspätete Frame erschien als Verlust, löste eine unnötige Wiederholung aus und konnte das Link-Verfahren so weit verwirren, dass es die Verbindung schließlich abbrach.

Data Link Switching verlängerte nicht einfach den Zeitgeber. Es verlegte die Protokollgrenze. Das linke Endgerät führte LLC Type 2 nur bis zu seinem örtlichen Switch. Rechts bestand eine zweite LLC-Verbindung zum dortigen Switch. Zwischen den Switches übernahm das Switch-to-Switch Protocol die Weitergabe über einen zuverlässigen Transport.

Dadurch blieben LLC-Timeouts und Bestätigungen im lokalen Netz. Auch SDLC-Polling konnte nahe am Endgerät stattfinden. Jeder Switch absorbierte Wiederholungen nach den Bedingungen seines angrenzenden Links. Die ungleichmäßige Verzögerung des WAN griff nicht mehr unmittelbar in ein für das LAN entworfenes Verfahren ein.

Gleichzeitig änderte sich die Aussage einer Bestätigung. RR oder UA bedeuteten für das Endgerät, dass der benachbarte Switch lokale Verantwortung übernommen hatte. Sie sagten nicht, dass die entfernte Station die Frame erhalten, ihren lokalen Link aufgebaut oder eine Anwendung ausgeführt hatte. RFC 1434 bezeichnete die beiden LLC-Verbindungen ausdrücklich als vollständig unabhängig.

TCP war der gemeinsame Boden, nicht der fertige Schaltkreis

Zwei Data Link Switches stellten zunächst eine Transportverbindung her. Die erste SSP-Implementierung nutzte TCP; ein anderer zuverlässiger Transport blieb denkbar. Erst auf dieser Verbindung richtete SSP Ende-zu-Ende-Schaltkreise zwischen den DLS ein. Viele davon konnten denselben Transport teilen.

„TCP connected“ war daher lediglich eine Beobachtung über zwei Switches. Der Zielort konnte noch unbekannt, ein geeigneter Peer noch ungewählt, das Kennungspaar unvollständig und der entfernte lokale Link unkontaktiert sein. Wer aus dem offenen Socket den Erfolg der Terminal-Sitzung ableitete, übersprang den eigentlichen Zustandsautomaten.

Für die gesuchte Beziehung gab es eine Data Link ID aus den MAC- und SAP-Adressen beider Stationen. Für eine konkrete Instanz vergab jeder Switch eine 64-Bit-Circuit-ID aus DLC Port ID und Data Link Correlator. Ein Ende-zu-Ende-Schaltkreis war erst durch das Paar der beiden lokalen Kennungen bestimmt. Beide DLS mussten die Zuordnung aufbewahren.

Vor dem Aufbau trugen Kontrollnachrichten die ausführliche Data Link ID. Danach durfte INFOFRAME einen kürzeren Header mit der entfernten Circuit ID verwenden. Die Ersparnis setzte den Kontext im Switch voraus. Eine einzelne Zahl ohne zuweisenden Switch, Richtung und Gegenstück ist für eine spätere Korrelation wertlos.

Erreichbarkeit war eine Frage mit mehreren Etappen

CANUREACH fragte nach einer erreichbaren Station. ICANREACH antwortete positiv und lieferte die Circuit ID der Zielseite. REACH_ACK gab die Kennung der Ursprungsseite zurück. CONTACT und CONTACTED behandelten danach den tatsächlichen Kontakt zur entfernten Station.

Die Verben sollten nicht verschmolzen werden. Ein lebender Transport-Peer kann die Station nicht kennen. Ein positiver Fund vervollständigt noch nicht beide Kennungen. Ein identifizierter Schaltkreis kann warten, bis der örtliche Link am anderen Ende den Kontakt abgeschlossen hat. Jeder Zustand beantwortete eine andere Frage.

Auf eine Suche konnten mehrere ICANUREACH-Antworten folgen. Der Ursprungs-DLS wählte die erste ICANREACH und sandte REACH_ACK an diesen Peer. Der operative Standort war somit ein zeitgebundenes Such- und Auswahlergebnis. Ein Protokoll, das nur den Gewinner behält, verliert alternative Beobachtungen und die Reihenfolge, die die Auswahl bestimmte.

Ein Standort-Cache verringerte die Suche. Ohne Eintrag konnte CANUREACH oder eine NetBIOS-Anfrage an alle bekannten DLS-Peers gehen. Frische Information sparte Verkehr, veraltete Information führte neue Schaltkreise an eine frühere Stelle. Suchumfang, Alter und Herkunft des Caches gehörten zur Betriebswahrheit.

Das nahe Ende durfte früher zustimmen

Beim Verbindungsaufbau konnte eine lokale Station SABME senden und vom Ursprungs-DLS bereits UA erhalten, bevor die entfernte Station kontaktiert war. Damit die Station nicht voreilig Daten übergab, hielt der Switch sie zunächst mit RNR an. Erst nach CONTACTED von der Gegenseite gab RR den Fluss frei.

UA behauptete keinen fernen Erfolg. Es markierte die Übernahme des örtlichen Links durch den Switch. RNR hielt die restliche Unsicherheit sichtbar. Problematisch wird die Konstruktion erst, wenn Überwachung oder Geschäftslogik die lokale Annahme mit dem Ergebnis am anderen Ende gleichsetzt.

SSP-Schaltkreis, entfernter Kontakt, lokale Sendeerlaubnis und Anwendungsantwort bilden vier Belegstufen. Selbst eine geordnete TCP-Zustellung zum Gegenswitch sagt nicht, ob dessen LLC noch wiederholt, bereits abbricht oder ob das Zielprogramm überhaupt handelt.

RFC 1795 führte später eine weitere Trennung durch adaptive Flusssteuerung aus. Nach dem Capability Exchange erhielt jede Richtung jedes Schaltkreises eigene Freigaben. Zu Beginn durfte ein Sender keine Dateneinheit übertragen, bevor FCIND Einheiten gewährte. Das ist eine Änderung von 1995, keine Funktion von RFC 1434, zeigt aber, weshalb zuverlässiger Transport nicht die Einspeisung jedes logischen Schaltkreises regelte.

Ein Ausfall in der Mitte wurde zu vielen lokalen Trennungen

Lokale Terminierung sparte LLC-Bestätigungen über das WAN. Multiplexing sparte eigene Transportverbindungen für jedes Stationspaar. Dafür teilten logisch getrennte Schaltkreise ein gemeinsames Schicksal.

Fiel nach RFC 1434 die TCP-Verbindung zwischen zwei DLS aus, mussten alle darauf gebündelten Verbindungen beendet werden. Beide Switches sandten DISC an sämtliche betroffenen lokalen Systeme. Kabel, Port und lokaler LLC-Zustand eines Endgeräts konnten intakt sein; die Sitzung endete wegen der gemeinsamen Abhängigkeit im Mittelteil.

Zehn zeitgleiche Terminal-Abbrüche konnten also eine einzige TCP-Ursache haben. Zehn isolierte Störungen zu zählen, übertreibt die Ursachen. Nur die Transportstörung zu speichern, unterschlägt die Wirkung. Der Vorfall braucht eine gemeinsame Ursache, die Liste aller Circuit IDs, deren lokale Links und die betroffenen Anwendungen.

Nicht jede Trennung kam von TCP. HALT_DL und DL_HALTED koordinierten das Anhalten eines Links; ein lokaler DLC-Fehler konnte nur einen Schaltkreis in den Abbau führen. Derselbe sichtbare Endzustand hatte verschiedene Besitzer. Entscheidend war die erste Zustandsänderung, nicht das letzte Alarmwort.

Die Nachfolger machten Zwischenzustände messbar

RFC 1795 erklärte umfangreiche Änderungen und ersetzte RFC 1434. Die DLSw-Gruppe des APPN Implementers Workshop wollte eine von mehreren Herstellern implementierbare SSP-Version und frühere Dokumentationsprobleme beheben. Zwischen Transportaufbau und gewöhnlicher Schaltkreissteuerung kam ein Capability Exchange hinzu.

RFC 2024 bildete diese Grenzen als Managementobjekte ab. Ein Transport konnte verbinden, den anfänglichen Fähigkeitenaustausch durchführen, verbunden sein, ruhen, trennen oder getrennt sein. Zähler erfassten Suche und Schaltkreisaufbau; Tabellen konnten Trennungsgründe bewahren. Ein einzelnes Socket-Signal reichte operativ nicht mehr aus.

RFC 2166 dokumentierte Skalierungsdruck: viele Peer-Definitionen, vervielfachte Such- und NetBIOS-Nachrichten auf Punkt-zu-Punkt-Verbindungen, dauerhafte Transporte und zahlreiche lokal terminierte LLC2-Sitzungen. DLSw v2.0 ergänzte HALT-Gründe, multicastgestützte Suche, Verbindungen bei Bedarf und möglichst eine bidirektionale TCP-Verbindung.

Diese Neuerungen gehören nicht in die Beschreibung des Jahres 1993. Ihre Notwendigkeit zeigt vielmehr, dass verlegter Zustand nicht verschwindet. Er muss am neuen Ort ausgehandelt, beobachtet und skaliert werden.

Der Belegweg reicht bis zur Anwendung

Eine belastbare Aufzeichnung verbindet Transport-Peer und -Zustand, gesuchte Data Link ID, sämtliche ICANREACH-Antworten, Auswahl, beide Circuit IDs, CONTACT/CONTACTED, beide örtlichen DLC-Zustände, Sendeerlaubnis, Zähler und erste Trennungsursache. Anwendungsbelege schließen sich separat an.

Sowohl RFC 1434 als auch RFC 1795 sagen, dass Sicherheitsfragen nicht behandelt werden. Daraus folgt keine Peer-Authentisierung, Stationsberechtigung, Vertraulichkeit oder Integrität gegen Angreifer. Zuverlässige TCP-Zustellung innerhalb des Modells ist kein Sicherheitsurteil.

Die Texte belegen ebenso wenig Verbreitung, aktuelle Nutzung oder einen konkreten Ausfall. Historisch wichtig ist ihre saubere Trennung: Ein Dienst kann zusammenhängend wirken, obwohl Transport, Schaltkreis, Kontakt, lokale Links und Anwendung jeweils eigene Tatsachen bleiben.

Quellen