Zusammenfassung

  • RFC 3473 ließ ein RSVP-TE-Notify einen registrierten, nicht benachbarten Knoten direkt erreichen und bestätigte den Empfang mit dem ACK-Mechanismus aus RFC 2961.
  • Notify ersetzte PathErr und ResvErr ausdrücklich nicht; das ACK belegte die Alarmzustellung, nicht Zustandskonvergenz, Schutzumschaltung oder Dienstwiederkehr.

Ein Alarm kann schneller sein als die Reparatur, von der er berichtet. RFC 3473 machte diesen Abstand zu einer Protokolleigenschaft.

Das im Januar 2003 veröffentlichte Dokument übertrug GMPLS-Funktionen aus RFC 3471 auf RSVP-TE. Generalisierte Labels, bidirektionale LSPs, Mengen, Schutz, getrennte Steuerkanäle und Wiederanlauf erhielten Objekte. RFC 3472 tat Ähnliches für CR-LDP. Notify löste ein engeres Problem: Der Fehler lag unterwegs, der handlungsfähige Ingress oder andere Entscheider aber mehrere Hops entfernt.

Eine Notify Request in Path verlangte Upstream-, in Resv Downstream-Benachrichtigung. Das Objekt trug die IPv4- oder IPv6-Adresse des Notify Node. Empfänger sollten sie im zugehörigen Zustand speichern und Transitknoten die Anforderung weitergeben.

Die Adresse war keine unveränderliche End-to-End-Identität. Lokale Politik durfte sie ausgehend ändern. Von mehreren Request-Objekten zählte nur das erste. Vor allem garantierte eine gespeicherte Anforderung keine spätere Notify-Erzeugung.

Bei einem passenden Fehler konnte der Detektor einen nicht benachbarten Knoten adressieren. Andere Knoten leiteten unverändert weiter, oder der Sender kapselte die Nachricht in einen neuen IP-Header zum Ziel. Notify nutzte kein Router Alert. Sein Belegpfad war damit vom Fehlerort und der gewöhnlichen PathErr-/ResvErr-Kette getrennt.

ERROR_SPEC nannte Fehler und Detektor oder defekten Link; Sitzungsdeskriptoren begrenzten die LSPs. Ein Ereignis konnte beide Richtungen benachrichtigen, doch ohne passende vorherige Request durfte kein Notify entstehen.

RFC 2961 lieferte Message ID und ACK. Der Zielknoten sollte den Notify-Empfang bestätigen. Diese Folge beantwortete eine begrenzte Frage: Kam diese identifizierte RSVP-Nachricht an diesem Ziel an?

Sie bestätigte nicht die physische Richtigkeit des Fehlers, Zustandslöschung an jedem Hop, Ersatzkapazität, optische Umschaltung, Paketfluss oder Anwendungserfolg. RFC 3473 sagte klar, dass Notify vorhandene Fehlermeldungen nicht ersetzt. Es ergänzte PathErr oder ResvErr, statt deren Arbeit zu bescheinigen.

Path_State_Removed trennte Nachricht und Handlung weiter. Ein PathErr konnte festhalten, dass ein weiterleitender Knoten den Path-Zustand tatsächlich gelöscht hatte. Notify-ACK und lokaler Löschbeleg waren verschiedene Quittungen; keine beschrieb den ganzen Pfad.

Meldungen mit gleichem Ziel und ERROR_SPEC konnten zusammengefasst werden. Ereignis, Timer oder andere Verfahren waren implementierungsabhängig; ein Timer hatte standardmäßig eine Millisekunde. Bündelung reduzierte Last, doch Umschlagzeit war nicht Ereigniszeit, und zusammengefasste Sitzungen erhielten keinen atomaren Wiederherstellungserfolg.

Administrative Abläufe verlangten Folgebelege. Nach Notify mit Down musste der Sender innerhalb einer konfigurierbaren Frist, standardmäßig dreißig Sekunden, Path mit Down sehen. Sonst löste er Abbau und weitere Fehler aus. Der erste Alarm war nicht der Abschluss.

Auch nur der Steuerkanal konnte ausfallen. Während einer Restart-Wartezeit blieben RSVP- und Weiterleitungszustand erhalten. „Control Channel Degraded“ belegte keinen Datenausfall; „Active“ keine vollständige Resynchronisierung oder Dienstwiederkehr.

Direkte Zustellung änderte die Sicherheit. RSVP schützte gewöhnlich Hop für Hop. RFC 3473 verwies für nicht benachbarte Notify auf IPsec oder erlaubte die Abschaltung. Selbst authentifiziert und bestätigt bewies die Meldung nur begrenzte Fakten über Absender, Inhalt und Empfang, nicht über die physische Wirkung.

RFC 4090 sowie RFC 4872 und RFC 4873 ergänzten schnelle, Ende-zu-Ende- und Segmentwiederherstellung. Sie fügten Handlungen hinzu, ohne Meldung, Entscheidung, Umschaltung und beobachtetes Ergebnis gleichzusetzen.

Nach Heng Lus Running-Code-Prinzip bleibt Notify symbolisch, bis das Zielsystem die erwartete Zustandsänderung sichtbar macht. Minimale Spezifikation lässt Aggregation und Politik lokal. Realitätsebenen verhindern, dass das ACK die Autorität eines tatsächlich wiederhergestellten Dienstes übernimmt.

Ein vollständiger Beleg speichert Request-Path/Resv, wirksames Ziel, Detektor, ERROR_SPEC, Sitzungen, Message ID, Sendezeit, Empfang und ACK. PathErr/ResvErr, Zustandslöschung, Schutz oder Abbau, Hardware, Signal, Verkehr und Anwendung bleiben getrennt. „Wiederhergestellt“ gehört ans Ende dieser Kette.

Quellen