Zusammenfassung

  • Ohne Barriere darf OpenFlow Nachrichten aus Leistungsgründen umordnen. Eine Barrier Reply besagt für dieselbe Verbindung, dass frühere Nachrichten samt Antworten oder Fehlern vollständig verarbeitet wurden, bevor spätere beginnen.
  • Die Aussage endet im Steuerpfad. Selbst ein vollständig verarbeitetes Packet-Out muss den Switch nicht verlassen; Stau, QoS sowie gesperrte oder ungültige Ports können es laut Spezifikation lautlos verwerfen.
  • Nick McKeown steht hier für eine gemeinschaftlich entstandene Architektur, die Entscheidung und Weiterleitung trennt. Diese Trennung verlangt eigenständige Belege für Absicht, Kanal, Ordnung, Zustand, Treffer, Ausgang, Pfad und Ergebnis.

Wenn der grüne Status zu früh kommt

Der Controller sendet ein FlowMod, anschließend eine Barrier Request und erhält die erwartete Antwort. Trotzdem kann die gewünschte Regel in der falschen Tabelle liegen, eine falsche Maske enthalten oder von einer höher priorisierten Regel verdeckt werden. Eine group bucket kann einen anderen Ausgang wählen, ein meter kann verwerfen, der Port kann blockiert sein. Hinter dem Switch kann der Pfad abbrechen.

Die Barrier Reply ist in keinem dieser Fälle falsch. Falsch ist nur das Etikett „Rollout erfolgreich“.

OpenFlow 1.3.5 beschreibt eine zeitliche Schranke. Fehlt sie, darf ein Switch Nachrichten zur Leistungssteigerung umordnen. Auf einer Verbindung müssen alle Nachrichten vor der Barrier Request vollständig bearbeitet werden, einschließlich der daraus entstehenden Antworten oder Fehler. Danach wird die Barriere bearbeitet und beantwortet; erst anschließend dürfen spätere Nachrichten beginnen.

Die Beispiele betreffen echte Abhängigkeiten: zuerst eine group anlegen, dann ein flow installieren, das sie verwendet; zuerst einen Port ändern, dann ein Packet-Out darüber senden; zuerst ein flow anlegen, dann ein Paket durch die Tabelle schicken. Die Antwort beweist diese Ordnung. Sie ist weder eine netzweite Transaktion noch ein Empfangsnachweis.

Eine gemeinsam geschaffene Schnittstelle

Das OpenFlow-Papier von 2008 wurde von Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker und Jonathan Turner verfasst. Es öffnete eine begrenzte Schnittstelle zu den flow tables realer Switches: Ein Controller setzt oder entfernt Einträge, nachfolgende Pakete bleiben im schnellen Datenpfad. Im Amy-OSPF-Beispiel berechnet das Programm einen Pfad und programmiert die Geräte entlang dieses Pfades.

McKeown ist ein Mitbegründer von OpenFlow und SDN, nicht deren alleiniger Erfinder. Auch die spätere Barrier-Semantik entstand aus Beiträgen der Deployment-Community, der Hersteller, der Forschung und der Open Networking Foundation. Für diese Analyse ist seine architektonische Rolle wichtig: Die Trennung zwischen Softwareentscheidung und Ausführung wurde so sichtbar, dass auch die Grenzen ihrer Quittungen sichtbar werden.

Die 2014 veröffentlichte Deployment-Geschichte führt praktische Rückmeldungen als Grund für die Einführung des Barrier-Befehls in OpenFlow 0.9 an. Zugleich dokumentiert sie schwankende flow-setup delays, schwache Switch-CPUs, ungelöste In-band-Steuerprobleme und Fehlersuche, die Steuertraces mit RTT, CPU-Last, Installationsrate und Anwendungsmessungen verbindet. Barrier war eine Ergänzung dieser Beobachtungskette, kein Ersatz.

„Vollständig verarbeitet“ endet vor der Leitung

OpenFlow 1.3.5 zieht die entscheidende Grenze selbst: Die vollständige Verarbeitung eines Packet-Out garantiert nicht, dass das Paket den Switch verlässt. Überlastung, QoS, ein blockierter oder ungültiger Port können es nach der OpenFlow-Verarbeitung ohne Fehlermeldung verwerfen. Auch Pakete zum Controller können unter policing oder Stau verschwinden, ohne ein Packet-In zu erzeugen.

Ein flow entry ist ein Pipeline-Objekt aus match fields, priority, counters, instructions, timeouts und cookie. Die Verarbeitung beginnt bei table 0 und kann mehrere Tabellen durchlaufen. Je Tabelle gewinnt der höchstpriorisierte Treffer; Anweisungen verändern Metadaten und action set, rufen groups oder meters auf und steuern den Ausgang.

Ein Read-back des erwarteten Cookies nach der Barriere ist stärker als die Reply allein, beweist aber keinen Treffer. Ein kontrollierter Zähleranstieg belegt den lokalen Match, nicht die nächste Leitung. Ein Egress-Zähler belegt noch keine Ankunft bei der Anwendung.

Ebenso eng ist der Verbindungsumfang. OpenFlow synchronisiert verschiedene Verbindungen nicht. Wurde abhängige Arbeit über eine auxiliary connection gesendet und die Barriere über die main connection, deckt deren Reply die andere Verbindung nicht ab. Nach einem Reconnect müssen Controller-Rolle, Verbindungsgeneration und tatsächlich erhaltener Switch-Zustand neu festgestellt werden.

Die Konformitätstests trennen zwei Wahrheiten

Der ONF-Test OpenFlow 1.3.4 Basic Single Table legt bis zu 10.000 flows an, löscht sie und sendet auf einer Steuerverbindung eine Barrier Request. Die Reply darf erst nach allen angeforderten Flow-Removed-Nachrichten eintreffen. Ein benachbarter Packet-Out-Test nutzt dagegen eine Datenverbindung und prüft den tatsächlichen Empfang des Pakets.

Es sind zwei Tests, weil Nachrichtenordnung und Datenempfang zwei Behauptungen sind. Eine Betriebsoberfläche sollte die beiden Zustände nebeneinander zeigen, nicht semantisch verschmelzen.

Bundles in OpenFlow 1.5.1 stärken die Atomarität von Konfigurationsänderungen. Mehrere Modifikationen lassen sich vorbereiten und gemeinsam anwenden; scheitert eine beim Commit, soll keine angewandt werden. Unterstützung und Umfang hängen vom Gerät ab. Ein erfolgreicher Bundle-Commit ist ein besserer Zustandsbeleg, aber weiterhin kein Nachweis für den Gewinner eines produktiven Matches oder die Antwort eines entfernten Dienstes.

VeriFlow prüft netzweite Invarianten bei Regeländerungen, weil Vertrauen in komplexen Controller-Code allein nicht genügt. Es kann Schleifen, black holes oder Richtlinienverletzungen im Modell erkennen. Das Modell misst jedoch weder das physische Medium noch den Anwendungserfolg. Modellprüfung und Ergebnisbeobachtung sind verschiedene, sich ergänzende Schichten.

Acht Belege statt eines überladenen Status

Ein belastbarer Ablauf hält fest:

  1. Absicht: versionierte Policy und gewünschter Regelsatz.
  2. Transport: richtige Datapath ID, Rolle und Verbindung.
  3. Ordnung: Barrier Reply auf dieser Verbindung, frühere Fehler abgeglichen.
  4. Zustand: Read-back von Tabelle, Priorität, Maske, Cookie, group, meter und Port.
  5. Treffer: ein repräsentatives Testpaket verändert die erwarteten Zähler.
  6. Ausgang: Port- oder Queue-Werte zeigen Egress ohne lokale Drop-Ursache.
  7. Pfad: Beobachtung downstream oder aktive Probe bestätigt den Weg.
  8. Ergebnis: Endpunkt oder Anwendung protokolliert die erwartete Transaktion.

Gemeinsame Schlüssel verbinden die Kette: Change-Version, Switch-Identität, Verbindungsgeneration, OpenFlow-Transaktion, Cookie, Probe-Header und Zeitfenster. Ohne sie lassen sich ein alter Read-back und eine neue Probe irrtümlich zu einem nie eingetretenen Erfolg kombinieren.

Quellen