SDN und die Data Plane – ist Flow gleich Flow?

Nun aber möchte ich den Fokus auf einen Bereich legen, der oft vernachlässigt wird: Die Data Plane. Während es eine Frage der Architektur ist, ob und wie die Control- und Data Plane auseinandergehalten werden oder wie ein hybrider Ansatz aussieht, ist es wichtig, die Idee eines Flows – ein Schlüsselkonzept von SDN – sowie die Funktionsweise der Data Plane in einer SDN Architektur zu verstehen. Allgemein gesagt bezeichnet ein “Flow” die Kommunikation zwischen Endpunkten durch das Netzwerk. Die Definition eines Flows muss sowohl in der Data als auch in der Control Plane existieren, um diesen entsprechen zu managen.

Die meisten Hersteller sind nicht in der Lage, skalierbare flow-basierte Systeme zu entwickeln – weder im Bezug auf die Switch und Systemarchitektur, noch im Bezug auf die benötigte ASIC Entwicklung für die Data Plane. Zudem hat der “Commodity”-ASIC Markt dies bisher auch ignoriert, da eine höhere Skalierbarkeit (neben vielen anderen Dingen) auch mehr Speicher benötigt, was wiederum sehr teuer ist. Und höhere Kosten sind kein Ziel eines Netzwerkdesigns. Es hat also heutzutage keiner der großen ASIC Hersteller etwas im Angebot, was die Skalierbarkeit in Sachen Flows angeht. Und fast alle SDN Startups konzentrieren sich auf Software- bzw. Controllerlösungen, da die Einstiegskosten sehr viel geringer als im Hardware-Geschäft sind.

Aber warum ist dies überhaupt wichtig? Wenn man ein flow-basiertes System nutzt, kann das erste Datenpaket genutzt werden, um komplexe, kontextbasierte Entscheidungen in der Software zu treffen. Anschließend werden dann alle Pakete dieses Flows in der Hardware, Data Plane, geswitcht. Das ist also die Basis für all die neuen, fortgeschrittenen und agilen Services, die mit SDN in Verbindung gebracht werden.

Ein SDN Design mit zentralem Controller und Commodity ASICs wird nur mit Abstrichen in der Lage sein, die Herausforderungen in Sachen Skalierbarkeit zu bewältigen – sowohl auf der Control Plane als auch auf der Data Plane. Es gibt dazu 2 Strategien:

1. Um in Echtzeit zu arbeiten muss die Definition eines Flows sehr “grob” sein. Dadurch müssen weniger neue Entscheidungen in der Control Plane getroffen werden und demzufolge müssen weniger Flows in der Data Plane programmiert werden. “Grob” heisst hier, dass anstatt etwas genauer auf Layer 3 und 4 (Applikation) die Flows zu definieren, reduziert man dies auf die MAC oder IP-Adresse (Subnetze) – Visibilität und Kontrolle werden weniger granular. Das mag für die Konnektivität von Vorteil sein, aber für Visibilität und Kontrolle auf der Applikationsebene nicht, da man wichtige Funktionen wie unter anderem  Netflow oder ACL auf dieser Ebene verliert
2. Die Flows werden vorab in der Data Plane durch den Controller konfiguriert (ala PVC’s Permanent Virtual Circuits), so dass der Controller nicht mit neuen Flow-Anfragen überhäuft wird. Das bedeutet aber, dass man vorab wissen muss, wer mit wem spricht. Wie auch im vorherigen Punkt angemerkt, mag dies für die Konnektivität gut sein, aber für nichts weiter. Neue Optionen erlauben die Aggregierung von Flows, was wiederum zu den Abstrichen in Punkt 1 führt.

Über wie viele Flows sprechen wir also? Aus meiner Erfahrung kann man von 30 neuen Layer 4 Flows pro Minute pro Client wie beispielsweise einem Desktop-PC oder einem Tablet ausgehen. Ein Server in einem Enterprise Data Center ist typischerweise 100x bis 1000x so groß bezogen auf Flows pro Minute. Server, die Internetdienste hosten, sind nochmal um ein vielfaches größer.

Wenn wir uns nun mal ein Standard Enterprise Campus Netzwerk mit 10.000 Mitarbeiten und drei Endgeräten pro User ansehen, bedeutet dies 900.000 neue Flows pro Minute – alles Layer 4. Dies ist wohlgemerkt im Normalzustand – also ohne einen Schutz vor externen Angriffe, ohne Netzwerkausfallsicherung … Diese zusätzliches Flows müssten dann innerhalb der Geräte programmiert werden oder es müssten Techniken zur Zusammenlegung dieser angewendet werden.

Der Commodity ASIC Markt bietet momentan Hochgeschwindigkeits-ASICs mit einem Durchsatz von bis zu 1Tbit/s, welche aber aufgrund der TCAM Technologie nur maximal 4.000 gleichzeitige Flows bearbeiten können. Ebenso sind die heutigen Controller nicht für Flow-Entscheidungen in Echtzeit ausgelegt. Das Ergebnis ist eine riesige Lücke. Andererseits bieten einige Netzwerkhersteller Systeme, die durch den Einsatz von spezieller flow-basierter ASIC-Designs bis hin zu Millionen von Flows skalieren.

Wer also Lösungen vergleicht, sollte den Fokus darauf legen, was der Hersteller auf beiden Seiten – der Control und der Data Plane – zu bieten hat. Ebenso sollte man nach den Zukunftsplänen fragen, so dass man eine gute Entscheidung treffen kann!