Zusammenfassung

  • RFC 2383 band einen ST2+-Hop an genau einen virtuellen ATM-Kanal und trennte Benutzer-, Steuerungs- und Managementebene. Der reservierte Datenpfad war deshalb nicht dasselbe Beweisobjekt wie der Steuerungspfad, der seinen Ausfall melden konnte.
  • Da die ST2+-Wiederherstellung unklar und unvollständig war und mehrere Agenten denselben ATM-Fehler gleichzeitig bemerken konnten, schrieb die Spezifikation NoRecover vor. Eine benannte Ablehnung war interoperabler als ein Versprechen ohne gemeinsame Autorität.

Kapazität lässt sich reservieren. Der Rückweg aus einem Fehler lässt sich damit noch nicht reservieren.

Diese Grenze legte RFC 2383 offen, das im August 1998 als informatives Dokument für ST2+ über ATM UNI 3.1 erschien. Die Zuordnung war eng: Ein ST2+-Hop benutzte einen virtuellen ATM-Kanal; der Kanal wurde nicht mit anderen Hops geteilt, und ein Hop wurde nicht auf mehrere Kanäle verteilt. Eine abstrakte Ressourcenanforderung erhielt so einen konkreten Träger.

Die Wiederherstellung bekam dieselbe Bestimmtheit nicht. Jede Implementierung musste in CONNECT NoRecover auswählen. Eine abweichende Anforderung sollte der Empfänger mit REFUSE und dem Grund NoRecover zurückweisen. Das Dokument bezeichnete dies nicht als eingeschränkte automatische Wiederherstellung und behandelte eine ATM-Fehlermeldung nicht als Ersatz für fehlende ST2+-Semantik. Stream-Wiederherstellung wurde nicht unterstützt und blieb Aufgabe der Anwendung.

Diese Entscheidung zählt, weil bereits viele Bausteine vorhanden waren, die leicht vorschnell als Wiederherstellung gelten konnten. ATM konnte einen Verbindungsverlust anzeigen. ST2+-Agenten tauschten SCMP aus. Ein FlowSpec reservierte Ressourcen Hop für Hop. Ein neuer virtueller Kanal ließ sich aufbauen. Keiner dieser Tatsachen bestimmte den handelnden Agenten, verhinderte konkurrierende Versuche, band den Ersatz zwingend an den ursprünglichen Stream oder belegte ein von der Anwendung akzeptiertes Ergebnis.

Ein Hop, ein Kanal, mehrere Wahrheiten

RFC 2383 unterschied Benutzer-, Steuerungs- und Managementebene. ST2+-Daten liefen über die dem Hop zugewiesene ATM-Verbindung. Agenten tauschten SCMP auf der Steuerungsebene aus. Lokales Management wählte Adressen, baute Kanäle auf und beobachtete ihren Zustand.

Diese Ebenen mussten keinen gemeinsamen Pfad benutzen. Die Spezifikation legte den virtuellen Kanal für SCMP nicht fest: Eine Implementierung konnte einen IPv4-VC wiederverwenden oder einen eigenen Kanal für die ST2+-Steuerung einrichten. Daten und SCMP eines Streams mussten derselben ST2+-Routingrichtung folgen, während die IPv4-Route zur gleichen IP-Adresse entgegengesetzt verlaufen konnte. Die Steuerung konnte also erreichbar bleiben, obwohl der reservierte Datenkanal gebrochen war — oder unabhängig von ihm ausfallen.

„Das Netz ist erreichbar“ blieb damit eine schwache Aussage. Hatte ein IPv4-Paket eine Route? Erreichte SCMP den Agenten? Bewahrte der ATM-Switch den Rufzustand? Durchliefen Nutzdaten genau diesen VC? Jede Antwort war ein Beleg auf einer anderen Ebene und zertifizierte die übrigen nicht automatisch.

Die Ein-Hop-ein-VC-Regel machte die Evidenz konkreter und zugleich lokaler. Der Kanal trug diesen Abschnitt. Ein Ende-zu-Ende-Stream bestand aus mehreren Hops, Kanälen und Agenten. Der Verlust eines VC identifizierte einen gebrochenen Abschnitt, stellte aber nicht den gesamten Stream wieder her.

Fehlererkennung war keine Wiederherstellungskoordination

Die HELLO-Funktion von ST2+ durfte über ATM unimplementiert bleiben, weil ATM als ausreichend für die Anzeige eines Verbindungsfehlers galt. Doch Daten und SCMP konnten verschiedene VC benutzen. Ein Lebenszeichen auf einem Pfad bewies den Zustand des anderen nicht.

Bei der Wiederherstellung wurde diese Trennung gefährlich. RFC 1819 hatte Wiederherstellungsverhalten für ST2+ beschrieben, RFC 2383 bewertete es für diese Umgebung jedoch als unklar und unvollständig. ATM konnte alle betroffenen Parteien benachrichtigen. Mehrere ST2+-Agenten konnten denselben Fehler deshalb nahezu gleichzeitig entdecken.

Handelten alle unabhängig, entstand ein Rennen. Ein Agent konnte alten Zustand freigeben, während ein anderer ihn neu aufbaute; zwei Ersatzsegmente konnten entstehen; ein nachgelagerter Zustand konnte sich mit dem falschen Versuch verbinden. Ein Auslöser reichte nicht. Nötig waren eine Autoritätsregel, eine gemeinsame Wiederherstellungsidentität, eine Reihenfolge und getrennte Belege für Erkennung, Freigabe, neue Zulassung, Hop-Rekonstruktion und Annahme durch die Anwendung.

RFC 2383 lieferte diesen interoperablen Vertrag nicht. NoRecover benannte die fehlende Steuerungsfläche. Ein Switch konnte wahrheitsgemäß den Verlust des VC melden, ein Agent den Empfang der Meldung bestätigen und ein neuer Kanal seine Zulassung belegen. Der Anwendung konnte trotzdem ein Loch, eine Wiederholung oder der erwartete Stream fehlen.

Die Anwendung erbte die letzte Verpflichtung

Die Aussage, die Anwendung müsse Wiederherstellung bereitstellen, verlieh ihr keine magische Fähigkeit. Sie übergab die ungelöste Frage an die Ebene, die wusste, was Kontinuität bedeutete. Eine Anwendung konnte bei einer Sequenznummer fortsetzen. Eine andere musste einen neuen Stream beginnen und Teilergebnisse verwerfen. Bei nicht wiederholbaren Wirkungen konnte eine menschliche Entscheidung nötig sein.

Das Netz konnte einen Ersatzpfad anbieten, wusste aber nicht, ob alter und neuer Pfad zusammen eine gültige Operation bildeten. Der erfolgreiche Aufbau eines Ersatz-VC rechtfertigte daher noch nicht „wiederhergestellt“. Die Beweiskette musste Fehlermeldung, Identitäten beider Kanäle, Freigabe der alten Reservierung, Rekonstruktion des ST2+-Hop-Zustands, Ende-zu-Ende-Streamidentität und Empfangsbestätigung der Anwendung verbinden.

Heng Lus Sicht auf Realitätsebenen macht den Irrtum deutlich. Physischer Leitungszustand, ATM-Ruf, ST2+-Agent, SCMP-Austausch, Anwendungssitzung und sichtbares Ergebnis sind verwandt, aber nicht gleich. Wer sie in eine grüne Anzeige presst, gewinnt Übersicht, indem er genau jene Unterschiede entfernt, die über die Wahrheit der Aussage entscheiden. Die Instanz, die „wiederhergestellt“ benennt, trägt nicht unbedingt die Folgen von Verlust oder Doppelung.

Die Aufbaurichtung war auch eine politische Entscheidung

Schon vor einem Fehler benötigte der Kanal einen Initiator. Bei geschalteten virtuellen Kanälen durfte laut RFC 2383 die betriebliche oder abrechnungsbezogene Politik bestimmen, welche Seite die ATM-Verbindung initiierte. Diese Richtung war unabhängig von der Sender-Empfänger-Orientierung beim Aufbau des ST2+-Streams.

Der zahlende Teilnehmer konnte den Ruf beginnen; der Stream-Ersteller konnte eine Aktion des nächsten Hops erwarten; der zuerst benachrichtigte Agent durfte möglicherweise keinen kostenpflichtigen Ersatzkanal eröffnen. Ein Wiederherstellungsentwurf, der diese Befugnisse und Anreize ignoriert, kann technisch plausibel und betrieblich unmöglich sein.

Auch die Abbildung des FlowSpec auf ATM-Parameter hatte eine harte Kante. Verkehrseigenschaften und Dienstqualität wurden anhand der Modelle in RFC 2211 und RFC 2212 sowie der Signalisierung aus RFC 1755 übersetzt. UNI 3.1 unterstützte keine Änderung der QoS einer bestehenden Verbindung. Benötigte eine unterstützte FlowSpec-Änderung andere Ressourcen, musste die Implementierung alte ATM-Verbindungen freigeben und neue aufbauen.

Das war keine Änderung an Ort und Stelle, sondern ein Obhutswechsel zwischen zwei Zuteilungen. Wann der alte Kanal endete, wann der neue zugelassen wurde und welcher Zustand bei einem Fehlschlag blieb, hing von Implementierung und Politik ab. RFC 2383 beschrieb Abbildung und Neuaufbau, veröffentlichte aber weder Messungen eines verlustfreien Übergangs noch einen Beleg für Anwendungskontinuität.

Diese Grenze trennt den Gegenstand von RFC 2380. Dort gehörten die Änderung einer Reservierung, die reduced reservation und der Bindungspunkt zwischen alter und neuer Zuteilung zur eigenen These. RFC 2383 besitzt eine andere Frage: Mehrere Agenten sehen den ATM-Fehler, doch dem Protokoll fehlt eine vollständige Wiederherstellungsautorität.

Eine ausdrückliche Ablehnung schafft ebenfalls Interoperabilität

NoRecover lässt sich leicht als unvollendete Funktion lesen. Es war zugleich eine positive Entscheidung. Führte eine Implementierung eine private Wiederherstellungsfolge aus, während die andere denselben Zustand anders deutete, konnten Duplikate, verwaiste Reservierungen oder zwei Bedeutungen desselben Streams entstehen.

Das obligatorische Kennzeichen machte die Grenze beim Aufbau sichtbar. Die Anfrage erhielt REFUSE mit benanntem Grund, statt die Abweichung bis zum nächsten Ausfall zu verbergen. Eine Schnittstelle, die präzise scheitert, ist sicherer als eine, deren Enden den Erfolg unterschiedlich definieren.

Aus Heng Lus Perspektive einer minimalen Ausgangsspezifikation war das disziplinierte Unvollständigkeit. Eine Mindestspezifikation sollte unbewiesenes Gelände nicht mit garantieähnlichen Formulierungen füllen. Sie definiert den gemeinsamen Kern, lokalisiert die nicht geteilte Entscheidung und lässt laufendem Code Raum, einen stärkeren Vertrag zu beweisen. Dedizierte Kanäle, Adressierung, Aufbau und Ressourcenabbildung gehörten zum Kern; Stream-Wiederherstellung nicht.

NoRecover später zu entfernen würde mehr als neuen Text erfordern. Mehrere Agenten müssten dieselbe ATM-Meldung erhalten, eine einzige Autorität auswählen, Duplikate unterdrücken, die alte Reservierung abrechnen, den Ersatz aufbauen, ihn dem richtigen Stream zuordnen und der Anwendung ein eindeutiges Ergebnis liefern. Prüfungen müssten Steuerungsnachrichten verlieren, Richtungen umkehren und Daten- und Kontroll-VC getrennt ausfallen lassen.

RFC 2383 behauptete solche Ergebnisse nicht. Sein informativer Status begrenzt auch die historische Aussage: Es war eine Protokollspezifikation, keine Erhebung über Installationen. Die IETF-Datatracker-Historie zeigt den Dokumentweg, nicht breite Nutzung.

Sicherheit schützte eine Kante der Kette

Auch der Sicherheitsabschnitt blieb begrenzt. Die minimalen ATM-Erweiterungen und Fehlerkorrekturen sollten ST2+ oder UNI 3.1 nicht schwächen. Eine vom Netz gelieferte und verifizierte Rufnummer konnte zur Authentifizierung beitragen.

Beitragen bedeutete nicht abschließen. Die Identität des Rufenden konnte den Initiator erkennen helfen, belegte aber weder die Berechtigung des FlowSpec noch die Zugehörigkeit des neuen VC zum ausgefallenen Stream oder die Annahme der rekonstruierten Sitzung durch die Anwendung. Identität, Ressource, Zustand und Ergebnis brauchten ergänzende Belege.

Aus dem Dokument folgt ebenso wenig, dass ein bestimmter Betreiber das Protokoll einsetzte, eine Latenz einhielt, einen realen Ausfall wiederherstellte oder eine Abrechnungspolitik eine konkrete Seite auswählte. Dafür wären Betriebsaufzeichnungen erforderlich.

Die historische Grenze ist langlebiger: Ressourcenreservierung, Fehlererkennung, Erreichbarkeit der Steuerung, Rekonstruktion und Anwendungserfolg sind fünf verschiedene Aussagen. Die ersten drei können ohne die vierte vorliegen; Infrastruktur kann neu aufgebaut sein, ohne die fünfte zu erfüllen. 1998 hielt RFC 2383 diese Unterscheidung mit einem unverstellten Kennzeichen fest: NoRecover.

Es bedeutete nicht, dass nach einem Fehler nichts geschehen konnte. Es bedeutete, dass das Netz keine abgeschlossene Wiederherstellung versprechen sollte, bevor Autorität, Reihenfolge und Schlussbeleg geteilt waren. Der Kanal konnte Ressourcen reservieren. Die Agenten konnten seinen Bruch erfahren. Die Bedeutung eines Neuanfangs gehörte weiterhin der Anwendung.

Quellen