Zusammenfassung

  • Bei RSVP sendet der Absender Path in Datenrichtung, während der Empfänger Resv hopweise zurückschickt. Jeder Knoten entscheidet Ressourcen und Berechtigung getrennt und muss Verkehrssteuerung tatsächlich installieren.
  • Ohne passende Auffrischung läuft der Zustand ab. Auch ResvConf garantiert keinen Ende-zu-Ende-Dienst; belastbar wird „reserviert“ erst mit Pfad, Epoche, lokalen Entscheidungen, Konfigurationslesung und gemessenem Ergebnis.

Ein Versprechen mit eingebautem Ablaufdatum

Wenn eine Anwendung endet und keine Auffrischung mehr folgt, lässt ein Router seinen Bereinigungszeitgeber ablaufen und löscht den Reservierungszustand. Kein zentraler Widerruf muss den gesamten Pfad atomar erreichen.

RFC 2205 nennt dieses Modell Soft State. Path- und Resv-Nachrichten erzeugen Zustand und frischen ihn regelmäßig auf. Trifft bis zum Bereinigungszeitpunkt nichts Passendes ein, verschwindet er. Einzelne Signalisierungsverluste können toleriert werden; eine alte Absicht erhält dennoch keinen dauerhaften Anspruch auf heutige Ressourcen.

„Reserviert“ braucht deshalb Subjekt, Umfang und Zeit: welcher Empfänger, welcher Datenstrom, welcher Pfad, welche Entscheidungen, welche letzte Auffrischung und welche Frist. Ohne diese Angaben überlebt das Wort leichter als der Zustand.

Der Pfad läuft vorwärts, die Forderung zurück

RSVP ist simplex und empfängerorientiert. Der Absender schickt Path entlang der Datenroute. Unterstützende Knoten speichern Pfadzustand und den vorherigen Hop. Der Empfänger erzeugt anschließend Resv, das hopweise in Gegenrichtung zu den passenden Absendern wandert.

Eine beobachtete Path-Nachricht belegt Pfadwissen an einem Ort, aber keine abgeschlossene Rückwärtsreservierung. Eine Resv-Nachricht belegt eine Anfrage an diesem Ort, aber keine Annahme weiter oben. Die Nachrichten sind getrennte Zeugen.

Bei Multicast können Anfragen mehrerer Empfänger zusammengeführt werden. Der weitergeleitete flowspec kann lokal angepasst oder aus mehreren Zweigen gebildet sein. Wer nur das Vorhandensein von Resv protokolliert, verliert Herkunft und Veränderung der Forderung.

Zwei Entscheidungen vor der Ausführung

Die Zulassungssteuerung prüft, ob genügend Ressourcen verfügbar sind. Die Richtliniensteuerung prüft, ob der Nutzer reservieren darf. RFC 2205 verlangt beide positiven Entscheidungen.

Erst danach setzt der Knoten Paketklassifizierer und Scheduler oder eine entsprechende Link-Layer-Funktion. RSVP transportiert QoS- und Richtlinienparameter, behandelt ihre Inhalte aber als opak. Lokale Systeme interpretieren und vollziehen sie.

Kapazität ist keine Erlaubnis. Erlaubnis ist keine Installation. Eine Installation an einer Schnittstelle ist keine Pfadtransaktion. Kontrollzustand ist kein gemessener Dienst. Jede Grenze braucht ihren eigenen Beleg.

RFC 2208 warnte bei großflächiger Einführung vor Verarbeitung und Speicherbedarf, Aggregation, Sicherheit und Richtliniensteuerung. Das ist keine heutige Verbreitungsstatistik. Es dokumentiert, warum Signalisierung auf ein größeres betriebliches Gefüge angewiesen blieb.

Die Bestätigung, die keine Garantie übernimmt

Ein Empfänger kann in Resv um Bestätigung bitten. Trifft die Anfrage an einem Zusammenführungspunkt auf eine gleich große oder größere bestehende Reservierung, kann der Knoten ResvConf zurücksenden, ohne die Anfrage weiterzuleiten.

RFC 2205 schränkt die Bedeutung ausdrücklich ein: ResvConf bietet keine Garantie. Im Beispiel des Standards werden zwei Empfängeranfragen zusammengeführt. Die zweite kann eine Bestätigung erhalten, obwohl die erste noch keinen passenden Absender erreicht hat und scheitern kann. Auf ResvConf kann ResvErr folgen.

Sicher ist nur: Ein bestimmter Knoten hat die Bestätigungsanfrage anhand seines damaligen Zustands verarbeitet. Nicht bewiesen sind Zulassung jedes Hops, Installation jedes Schedulers, unveränderter Pfad oder die erlebte Dienstqualität.

ResvConf ist ein nützlicher Signalisierungsbeleg. Als Ende-zu-Ende-Zertifikat wäre es eine Fehlinterpretation.

Der alte Weg wird nicht umgeschrieben, sondern vergessen

Path und Resv sind idempotent. Ändert sich die Route, baut die nächste Path-Nachricht Zustand auf dem neuen Weg auf; folgende Resv-Nachrichten richten dort die Reservierung ein. Ungenutzter Zustand am alten Segment läuft aus.

PathTear und ResvTear können schneller löschen, werden aber nicht zuverlässig zugestellt. Ihr Verlust ist beherrschbar, weil ausbleibende Auffrischung die Bereinigung übernimmt. Das System benötigt keine perfekte globale Löschtransaktion.

Nach einem Zulassungsfehler kann unterhalb der Fehlerstelle Teilzustand bestehen bleiben. Das ermöglicht Teildienst oder rasche Erholung nach einer vorübergehenden Routenänderung. Ein Router kann wahrheitsgemäß Reservierungszustand melden, obwohl kein vollständiger Ende-zu-Ende-Pfad reserviert ist.

Der Beleg muss deshalb Fehlerpunkt, Restumfang und Ablaufzeit nennen. Ein einzelnes Ja/Nein-Feld verdeckt diese Struktur.

Weniger Auffrischungsdaten bedeuten keinen Dauerzustand

Vollständige Path- und Resv-Auffrischungen erzeugen Aufwand. RFC 2961 ergänzt MESSAGE_ID, hopweise Bestätigungen für bestimmte Nachrichten, Bündelung und Summary Refresh. Bekannter Zustand kann anhand von Kennungen erneuert werden.

Die Darstellung wird kleiner, nicht die Verpflichtung. Summary Refresh muss die Synchronisation des Soft State bewahren. Fehlt der bezeichnete Zustand, kann der Empfänger einen Refresh-NACK senden. Ein ACK belegt Nachrichteneingang beim Nachbarn, nicht Dienstqualität über den Gesamtpfad.

Anfrageepoche, Zeitgeber jedes Knotens, MESSAGE_ID-Epoche, Konfigurationsstand und Messfenster bleiben getrennte Uhren. Eine effiziente Nachricht darf sie nicht in ein einziges Aktivierungsdatum pressen.

Diagnose ist eine Momentaufnahme des Kontrollzustands

RFC 2745 definiert DREQ und DREP, um Path- oder Reservierungszustand entlang RSVP-Knoten einzusammeln. Die Antworten können zeigen, wo Zustand fehlt oder voneinander abweicht.

Sie können jedoch fragmentieren, wegen eines Fehlers früh enden, einen anderen Rückweg nehmen, an Filtern scheitern oder auslaufen. Auch eine vollständige Antwort beschreibt gespeicherten Kontrollzustand zum Beobachtungszeitpunkt. Sie beweist nicht automatisch Scheduler-Konfiguration oder tatsächlich erlebte Verzögerung und Verluste.

Der Diagnosebeleg erweitert die Zeugenkette. Er darf nicht für das Datenebenen-Ergebnis sprechen.

Zhangs Rolle bleibt groß, ohne Alleinzuständigkeit

Der IETF Datatracker führt Lixia Zhang als Mitautorin von RFC 2205. Ihre UCLA-Biografie ordnet Konzeption und Entwicklung von RSVP ihrer Zeit bei Xerox PARC zu. Der RFC nennt Robert Braden als Herausgeber sowie Zhang, Steven Berson, Shai Herzog und Sugih Jamin als Autoren und würdigt eine breitere Zusammenarbeit.

Die Internet Hall of Fame verbindet Zhangs Arbeit mit RSVP und späterer RSVP-TE-Praxis. Diese institutionelle Würdigung ist keine Betreiberzählung. RSVP-TE ist zudem nicht mit dem ursprünglichen Integrated-Services-Protokoll gleichzusetzen.

Belegt sind Mitgestaltung, Mitautorschaft und Standardisierungsarbeit. Nicht belegt sind alleinige Erfindung, heutiger Betrieb, Eigentum am IETF-Konsens oder Garantie eines realen Dienstes. Persönliches Ansehen darf betriebliche Nachweise nicht ersetzen.

Sieben Belege statt einer grünen Plakette

Der Pfadbeleg enthält Absender, Sitzung, Route, vorherigen Hop und Zeit. Der Anforderungsbeleg enthält Empfänger, genaue Resv-Daten, Filter und flowspec, Bestätigungswunsch und Epoche. Der Autoritätsbeleg enthält Zulassung und Richtlinie an jedem relevanten Knoten.

Es folgen Installation mit Ziel, Transaktion und Konfigurationslesung; Gültigkeit mit letzter Auffrischung, Intervall, Bereinigungsfrist, Summary-Refresh-Kennung und NACK; der begrenzte ResvConf- oder DREP-Beleg mit Knoten und Zeitpunkt; schließlich der Ergebnisbeleg mit tatsächlichem Datenpfad und Messfenster.

Keiner erbt die Bedeutung eines anderen. Verbunden tragen sie eine genaue, widerrufbare Aussage. Das ist weniger bequem als ein ewiges Grün, aber wesentlich belastbarer.

Quellen