Zusammenfassung

  • RFC 3654 schrieb weder vor, dass ein Forwarding Element nach dem Verlust seiner Zuordnung zum Control Element immer weiterleitet, noch dass es stets anhält. Die Architektur sollte den Verlust erkennen, die Zuordnung wiederherstellen, den Zustand abgleichen und das Verhalten des FE im Voraus festlegen können.
  • RFC 7121 beschrieb später zwei Wiederanlaufmodi: Einer führt zurück in die Vorassoziierungsphase; der andere kann Ersatz-CEs versuchen und bis zum Ablauf einer Frist weiterleiten. Eine neue Zuordnung beweist für sich genommen nicht, dass der vollständige FE-Zustand wiederhergestellt ist.

Ein Netzgerät, zwei logische Aufgaben

RFC 3654 beschrieb im November 2003 ein IP-Netzelement als Zusammenspiel von Steuerungs- und Weiterleitungsfunktionen, das nach außen als integriertes Gerät auftreten kann. Das Control Element (CE) führt etwa Routing- und Signalisierungsprotokolle aus; das Forwarding Element (FE) verarbeitet Pakete. Die Trennung ist logisch und verlangt keine zwei getrennten Gehäuse. Als Gründe nennt die RFC Skalierbarkeit und die Möglichkeit, beide Ebenen unabhängig weiterzuentwickeln. Sie behauptet nicht, dass diese Architektur damals bereits flächendeckend eingesetzt wurde. RFC 3654

Die schwierige Phase beginnt, wenn das FE noch Tabellen und programmierte Funktionen besitzt, seine Zuordnung zum zuständigen CE aber verloren hat. „Die Steuerung ist ausgefallen“ sagt noch nicht, was mit Paketen geschieht. Das FE kann seinen vorhandenen Zustand weiterverwenden, anhalten oder ein Ersatz-CE erreichen wollen. RFC 3654 hält diese Möglichkeiten auseinander.

Die Vorgabe verlangte eine Entscheidung, keine Einheitsantwort

Architekturvorgabe 7 bündelt vier Aufgaben: Zuordnungsverlust erkennen, die Zuordnung wiederherstellen, den Zustand effizient abgleichen und das Verhalten des FE vorab festlegen. Weiterleiten oder den Betrieb anhalten sind Beispiele im Text; vorgeschrieben wird keine der beiden Antworten für alle Geräte. Protokollvorgabe 8 wiederholt dieselbe Unterscheidung. RFC 3654

Weiterleitung kann den Verkehr erhalten, bindet das FE aber an den Zustand, den es bereits kennt. Anhalten begrenzt diese Phase und macht den Dienst zugleich von der Steuerungsverbindung abhängig. Das sind Folgen, die ein Entwurf abwägen muss, keine von der RFC gemeldeten Störungen. Die Architektur soll das Verhalten vor dem Fehler festlegen, statt es dem unbeabsichtigten Schweigen einer Implementierung zu überlassen.

Spätere Hochverfügbarkeitsregeln setzten eine Frist

RFC 5810 definierte 2010 als Standards-Track-Spezifikation das ForCES-Protokoll und seine Transport Mapping Layer, um die Protokollanforderungen von RFC 3654 zu erfüllen. RFC 5812 beschrieb ein FE-Modell für Fähigkeiten, aktuellen Zustand, gewünschte Konfiguration und logische Funktionsblöcke. Was ein FE kann, was es gerade tut und was ein CE von ihm verlangt, sind unterschiedliche Informationen. RFC 5810 RFC 5812

RFC 7121 ergänzte 2014 ein Hochverfügbarkeitsverfahren innerhalb eines ForCES-Netzelements. Das FE Protocol Object benennt das führende CE und konfigurierte Ersatz-CEs; Heartbeat-Intervalle und -Richtlinien helfen bei der Erkennung von Verbindungsproblemen. Im Standardmodus 0 kehrt das FE nach einem Zuordnungsverlust in die Vorassoziierungsphase zurück; bei einer späteren Zuordnung muss sein Zustand neu aufgebaut werden. Modus 1 nutzt Restart Recovery: Das FE versucht die Ersatz-CEs der Reihe nach, während das CE Failover Timeout Interval läuft. Im Zustand „nicht zugeordnet“ darf es abhängig von der konfigurierten Richtlinie weiterleiten. Läuft die Frist ohne Zuordnung ab, wechselt es in die Vorassoziierung und fährt seinen Weiterleitungspfad herunter. Nach der Wiederzuordnung kann das CE verlorenen Zustand abgleichen; die Methode bleibt jedoch außerhalb der ForCES-Architektur und umfasst typischerweise neue Konfigurationsnachrichten und Abfragen. RFC 7121

Ein Heartbeat ist außerdem kein Urteil über die Richtigkeit einer Route. RFC 3654 lässt zu, dass Heartbeats zur Erkennung einer verlorenen Zuordnung Schnelligkeit höher gewichten als strikte Zuverlässigkeit. Kritische Konfigurationen und Weiterleitungstabellen müssen dagegen robust transportiert werden. Ein fehlendes Signal kann eine Änderung des Zuordnungszustands auslösen, beweist aber weder einen physischen Defekt noch falsche Routen oder den Ausfall des ganzen Geräts. RFC 3654

RFC 3532 behandelte eine andere ForCES-Frage: dynamische Ressourcen-Neuverteilung und ein möglicher Rückstand im Modell des Steuerungselements. Hier geht es stattdessen um die vorab gewählte FE-Reaktion und den Hochverfügbarkeitsablauf nach Verlust der Zuordnung. RFC 3654 hat den Status Informational; spätere Standards dokumentieren die Ausarbeitung des Entwurfs, nicht seine Einführung bei einem bestimmten Betreiber. RFC 3532 RFC 3746 RFC 1812 RFC-Editor-Eintrag zu RFC 3654 Datatracker-Eintrag zu RFC 3654

Quellen