Zusammenfassung

  • Eine RSVP-Kurzauffrischung verweist auf zuvor vollständig angekündigten Path- oder Resv-Zustand. Sie erhält Bekanntes, ersetzt aber keine neue oder geänderte Zustandsbeschreibung.
  • Ein fehlender Eintrag kann eine Anforderung nach vollständiger Information auslösen. Ein weiterhin auffindbarer, intern beschädigter Eintrag kann dieser Prüfung entgehen; RFC 2961 benennt diese Grenze ausdrücklich.
  • Gelegentliche vollständige Auffrischungen und spätere Verfahren zur zuverlässigen Zustellung und Nachbarerkennung übernahmen verbleibende Aufgaben. Weniger Wiederholung bedeutete nicht, dass deren Reparaturfunktion verschwunden war.

Ein Bit galt nicht für immer

Ein RSVP-Nachbar hatte seine Bereitschaft zur Auffrischungsreduktion angezeigt. Später traf eine Nachricht ein, in der dieses Fähigkeitsbit nicht mehr gesetzt war. Durfte der andere Knoten weiterhin nur kurze Zustandsreferenzen schicken, weil die Zusammenarbeit zuvor funktioniert hatte?

Die im April 2001 veröffentlichte RFC 2961 behandelt Unterstützung als laufende Eigenschaft der Nachbarschaft. Das Bit ist in empfangenen Nachrichten zu beachten. Verschwindet es, darf die Verwendung der betreffenden Kurzverfahren grundsätzlich nicht einfach fortgesetzt werden, sofern keine entsprechende ausdrückliche Konfiguration greift.

Diese kleine Regel zeigt, wie eng die Optimierung begrenzt war. Nicht die Veröffentlichung eines Formats und nicht die Erinnerung an einen früheren Erfolg machten die kurze Nachricht ausreichend. Entscheidend war, was der konkrete Empfänger unter den geltenden Bedingungen damit anfangen konnte.

Eine zweite, weniger sichtbare Grenze lag innerhalb des Empfängers. Selbst wenn er das Verfahren unterstützte und jede Kennung wiederfand, hatte er damit nicht unbedingt den Inhalt jedes gefundenen Eintrags erneut geprüft.

Die alte Wiederholung transportierte auch eine Reparaturchance

Die RSVP-Grundspezifikation RFC 2205 vom September 1997 hält Path- und Resv-Zustand durch periodische Nachrichten am Leben. Bleiben Auffrischungen lange genug aus, verfällt der Zustand. Eine ausdrückliche Abbaunachricht kann die Freigabe beschleunigen; ihr Verlust soll jedoch keine ewige Reservierung hinterlassen.

Diese Form von Soft State erfüllte mehr als eine Lebenszeichenfunktion. Mit einer vollständigen Beschreibung kamen Informationen erneut an, die zuvor verloren gegangen oder nicht richtig weitergegeben worden waren. Bei einer Routenänderung mussten die passenden Zustände auf dem neuen Weg entstehen. Wiederholung verringerte die Abhängigkeit von der fehlerfreien Zustellung jedes einzelnen Änderungsschritts.

Der Preis wuchs mit der Zahl der Zustände. Immer wieder dieselben Objekte zu übertragen und auszuwerten beanspruchte Leitungen und Prozessoren. Größere Intervalle entlasteten den Normalbetrieb, konnten aber Reparatur und Bereinigung verzögern. Kleinere Intervalle erhöhten die laufende Arbeit. Die Wiederholung war teuer, aber nicht funktionslos.

RFC 2961 trennte deshalb zunächst Änderungen von unveränderten Wiederholungen. Neue oder veränderte Information erfordert eine entsprechende auslösende Nachricht. Auch ein verändertes Richtlinienobjekt zählt dazu, selbst wenn die sichtbare Ressourcenmenge gleich bleibt. Eine alte Kennung darf nicht als Abkürzung dienen, um neuen Inhalt ohne Beschreibung einzuführen.

Was eine Kennung bezeichnete

Vor der ersten Kurzauffrischung musste der vollständige Zustand zusammen mit MESSAGE_ID bekannt gemacht worden sein. Spätere Srefresh-Nachrichten konnten dann Listen solcher Referenzen enthalten. Der Empfänger suchte den zugehörigen Path- oder Resv-Zustand und frischte ihn auf.

Dabei wurde zunächst nicht einfach seltener gesendet. Im Entwurf von 2001 durfte die Kurzauffrischung für einen Zustand nicht weniger häufig erfolgen als die vollständige Auffrischung, die sie ersetzte. Eingespart wurde wiederholte Beschreibung. Die viel längeren Intervalle späterer Verfahren gehören zu einem anderen Bündel von Voraussetzungen.

MESSAGE_ID besitzt einen Kennungswert und eine Epoche; hinzu kommt der Geltungsbereich der erzeugenden Adresse. Für ursprüngliche Path- und Resv-Nachrichten stammt diese Adresse aus RSVP_HOP, nicht zwingend aus dem äußeren IP-Absenderfeld. Eine neue Epoche hilft, nach einem Neustart alte und neue Ausführungszustände auseinanderzuhalten.

Keine dieser Angaben ist eine inhaltliche Prüfsumme des gespeicherten Datensatzes. Die Kennung ist weder globaler Eigentumstitel noch kryptographischer Beleg für sämtliche Felder. Sie löst die Frage, auf welche frühere Mitteilung sich die aktuelle Nachricht bezieht. Ob der zugeordnete Inhalt noch stimmt, ist eine andere Frage.

Fehlend und falsch waren verschiedene Fehler

Findet ein zuständiger Empfänger den bezeichneten Zustand nicht, kann er mit MESSAGE_ID_NACK die fehlende Referenz zurückmelden. Besitzt der ursprüngliche Sender den passenden Zustand noch, muss er ihn als gewöhnliche Path- oder Resv-Nachricht erneut übermitteln. Besitzt auch er ihn nicht, gibt es keine passende Beschreibung, die sich aus der Nummer allein wiederherstellen ließe.

Dieses NACK lehnt keine Bandbreitenanforderung ab. Es meldet eine fehlende Zuordnung. Ressourcenadmission bleibt ein eigener Vorgang. Auch die erfolgreiche Nachlieferung einer Beschreibung beweist nicht, dass eine Reservierung über den gesamten Pfad genehmigt wurde oder die Daten tatsächlich mit der erwarteten Qualität fließen.

Bei Multicast muss zusätzlich geklärt werden, ob ein Empfänger den Zustand überhaupt führen sollte. Quellen- und Gruppenangaben sowie Prüfungen des Rückwegs verhindern, dass unbeteiligte Knoten allein wegen einer unbekannten Kennung Reparatur verlangen. Es handelt sich nicht um eine Liste, die jeder Router der Welt vollständig besitzen müsste.

Der Mechanismus kann somit Abwesenheit sichtbar machen. Ein anderer Fall bleibt schwieriger: Die Kennung passt, der Eintrag ist vorhanden, aber ein Teil seines Inhalts ist beschädigt. Eine Nachricht, die nur auf diesen Eintrag zeigt, liefert nicht notwendigerweise die Felder mit, anhand deren sich das erkennen ließe.

Der Vorbehalt stand im Standard

Abschnitt 5.5 der RFC 2961 beschreibt genau diese Grenze. Kurzauffrischungen helfen bei üblichen Paketverlusten und Routenänderungen, haben aber nicht exakt dieselben Fehlerbehebungseigenschaften wie vollständige Auffrischungen. Interne Zustandsbeschädigung wird als mögliches Beispiel genannt.

Das ist keine Behauptung über einen bestimmten historischen Ausfall. Es ist eine Aussage über den Umfang des Verfahrens. Ein denkbarer Eintrag kann weiterhin über seine Kennung erreichbar sein, obwohl seine Beschreibung nicht mehr stimmt. Die verlängerte Lebensdauer ist dann kein Nachweis einer erneuten Inhaltsprüfung.

Die Spezifikation nennt zwei Ergänzungen, deren Reichweite auseinanderzuhalten ist. Bei der ersten wird beim Versand einer Änderungsnachricht ein Prüfwert über den internen Zustand gespeichert und später neu berechnet. Damit lässt sich eine Änderung entdecken, die eine Nachricht hätte auslösen sollen, dies aber nicht tat. Der Text sagt ausdrücklich, dass dieser Ansatz nicht vor interner Zustandsbeschädigung schützt.

Die zweite Ergänzung sendet von Zeit zu Zeit wieder vollständige Path- und Resv-Nachrichten. Ihr Intervall liegt über dem der Kurzauffrischungen, damit der Einsparungseffekt erhalten bleibt. Im selben Zeitraum muss für den betreffenden Zustand nicht zusätzlich noch ein Kurzverweis geschickt werden. Das Verhältnis der Häufigkeiten kann administrativ eingestellt werden.

Eine ausgebliebene Änderungsmitteilung zu erkennen ist etwas anderes, als eine vollständige Beschreibung neu zu liefern. Beide zu einer vermeintlichen Gesamtprüfung des Nachbarzustands zusammenzufassen, würde die sorgfältige Einschränkung des Dokuments aufheben. Die vollständige Wiederholung erhält eine Reparaturmöglichkeit, nicht eine Garantie für jeden denkbaren Fehler des Geräts.

Zustellung war noch keine Zulassung

RFC 2961 enthält außerdem Bestätigungen und schnelle Wiederholungen einzelner Nachrichten. Eine syntaktisch ungültige Nachricht darf nicht bestätigt werden. Eine gültige Empfangsbestätigung ist dennoch keine Zusage über die Ressourcenentscheidung entlang des ganzen Pfads.

Ähnlich begrenzt ist Bundle. Es verpackt mehrere vollständige RSVP-Nachrichten in ein Datagramm, verschmilzt aber ihre Anforderungen nicht zu einer einzigen zugelassenen Reservierung. Verpackung, Zustellung und fachlicher Inhalt bleiben getrennte Arbeitsschritte.

Auch Authentifizierung beseitigt diese Trennung nicht. RFC 2747 behandelt Integrität und authentifizierte Nachbarn unter den jeweiligen Schlüsselannahmen. MESSAGE_ID ist nicht diese Integritätsprüfung, und Integrität ist keine Verschlüsselung zur Geheimhaltung. Ein authentischer Kurzverweis enthält weiterhin nicht die ausgelassenen Zustandsfelder. Diese historische Einordnung ist keine Empfehlung für heutige Kryptographieeinstellungen.

Wiederhergestellte Erinnerung durfte keinen Datenpfad erfinden

Im Oktober 2007 nutzte RFC 5063 solche Werkzeuge für die Wiederherstellung nach einem Neustart in GMPLS RSVP. Ein nachgelagerter Nachbar kann dem neu gestarteten vorgelagerten Controller Referenzen auf früher empfangene Path-Nachrichten zurückgeben. Die Richtung unterscheidet sich von der normalen Zusammenfassung zuvor selbst gesendeten Zustands.

Erkannte Referenzen können vollständige RecoveryPath-Beschreibungen ersparen; fehlende Information muss ausführlicher nachgeliefert werden. Besondere Fähigkeiten und Kennzeichnungen unterscheiden diesen Austausch von einer gewöhnlichen Auffrischung.

Die Erinnerung des Nachbarn genügt jedoch nicht, um fehlenden Weiterleitungszustand neu zu erzeugen. Die Wiederherstellung muss Signalisierung mit erhaltenem Weiterleitungszustand verbinden. Für eine neue Einrichtung sind die passenden separaten Verfahren nötig, etwa eine vorgelagerte Path-Nachricht oder ein Managementauftrag am Eingang unter den geltenden Regeln.

Die Sicherheitsbetrachtung setzt Vertrauen zwischen Nachbarn voraus, macht daraus aber keinen Beweis einer korrekten Zuordnung zwischen dem Zustand vor und nach dem Neustart. Die Identität des Absenders und die Richtigkeit seiner Rekonstruktion sind zwei Aussagen. Eine wiedergefundene Steuerinformation belegt noch keinen funktionierenden Datenverkehr.

Längere Ruhe brauchte andere Beobachtung

Die Skalierungsanalyse in RFC 5439 von 2009 betrachtet auch Speicher und Verarbeitung je Zustand. Eine große Liste erfordert weiterhin viele Zuordnungen. Weniger Pakete beseitigen nicht die Arbeit an den einzelnen Reservierungen; aus der damaligen Analyse folgt keine universelle Kapazitätszahl heutiger Router.

Die spätere RFC 8370 vom Mai 2018 verbindet deutlich längere Auffrischungsintervalle mit zuverlässiger Zustellung, kürzerer Behandlung noch unbestätigter Path- und Resv-Nachrichten und expliziter Erkennung ausgefallener Signalisierungsnachbarschaften. Fällt eine solche Nachbarschaft aus, gilt der durch sie gelernte Zustand als abgelaufen.

Damit wird eine Aufgabe der alten Wiederholung einem anderen Beobachter zugewiesen. Nur den Intervallwert zu vergrößern würde diese Arbeit nicht übernehmen. Die stärkeren Bestätigungspflichten gelten für Implementierungen der neuen Techniken; sie lassen sich nicht allen älteren RSVP-Knoten nachträglich unterstellen. Nicht unterstützende Nachbarn bleiben beim traditionellen Verhalten.

Das RSVP-Register der IANA dokumentiert Nachrichtenwerte, Objektklassen und Fähigkeitsbits. Es schafft gemeinsame Bedeutungen, aber keinen Nachweis ihrer Aktivierung auf einer bestimmten Verbindung. Die Bedingung vom Anfang bleibt deshalb wesentlich: Unterstützung muss im laufenden Austausch erkennbar sein.

Die Dokumente erzählen von Entwürfen und Voraussetzungen, nicht von einer lückenlosen weltweiten Einführung. Ihr gemeinsamer Gewinn liegt in der präziseren Aufteilung von Arbeit. Zustand erhalten, fehlende Beschreibung nachliefern, vorhandenen Inhalt prüfen und ausgefallene Nachbarn erkennen sind verwandte, aber nicht austauschbare Tätigkeiten.