SDN ist eine Totgeburt

2 Kommentare Drucken

Erinnern Sie sich noch an ATM LAN-Emulation? Ja? Dann wissen Sie, warum aus SDN nichts wird. Nein, macht nichts, es sei denn, Sie sind Netzwerk-Historiker mit dem Spezialgebiet gescheiterter Techniken.

Die ATM LAN-Emulation war eine Totgeburt: man versuchte einen paketvermittelnden Dienst mit Broadcast Funktion, namentlich Ethernet, auf einen zellbasierten Dienst ohne Broadcast Funktion, namentlich ATM, abzubilden. SDN begeht einen ähnlichen Fehler: man versucht dezentrale Protokolle, namentlich IP (und Ethernet), zentral zu steuern. Mit Verlaub, das wird nichts!


Schauen wir uns die Paradigmen der genannten Techniken/Protokolle mal an:

  1. Planwirtschaft: SDN
    SDN verfolgt einen zentralistischen Ansatz: irgendwo steht ein Kontroller, der dumme Netzwerkkomponenten steuert.
  2. Marktwirtschaft: IP (bedingt auch Ethernet):
    Sowohl Ethernet als auch insbesondere IP sind dezentrale Techniken. Bei IP war das ein Entwicklungsgrundsatz: kleinste Netzeinheiten sollten auch dann noch autonom arbeiten können, wenn sie die Verbindung zum Rest der Welt verlieren.
    Die Idee diese beiden Ansätze zu kombinieren, ist ähnlich erfolgsversprechend wie einen 5 Jahresplan für die freie Marktwirtschaft zu erarbeiten.

Dezentrale IP-Welt
Warum ist unsere Netzwerkwelt dezentral? Betrachtet man die Geschichte, so war das nicht immer so, es gab Zeiten der Großrechner mit den dazugehörigen zentralen Netzwerkarchitekturen, SNA sei hier mal als Beispiel angeführt.

Warum also heute dezentral? Dafür gibt es verschiedene Gründe. Der erste liegt in der grauen Vergangenheit, als die Welt noch in zwei Hälften geteilt war: der Kalte Krieg. Als IP erschaffen wurde, war eine Kernforderung für die Entwicklung des Protokolls, dass es dem Gegner nicht möglich sein sollte, durch einen einzigen gezielten Schlag die gesamte Kommunikationsinfrastruktur auszuschalten. Vielmehr sollten auch kleinste zusammenhängende Netze weiterhin funktionieren, auch wenn sie die Verbindung zum Rest der Welt verloren haben. Als IP das einzige Layer 3 Protokoll wurde, erbten alle Netze diese Eigenschaft, obwohl der kalte Krieg vorbei ist und nur wenige Unternehmen einen präventiven Erstschlag der Mitbewerber fürchten.

Der zweite Grund ist die Performance. Ursprünglich waren die Großrechner, die „Hosts“, die Instanzen, die wirklich rechnen konnten. Die User saßen vor „dummen“ Terminals, im Grunde nicht mehr als eine Tastatur mit Monitor und jeder Tastenanschlag wurde zum Host übermittelt, dort ausgewertet und das Ergebnis kam über die Leitung zurück.

Mit den PCs endete diese Ära. Natürlich war ein Host damals viel leistungsfähiger als ein PC, nur war er nicht leistungsfähiger als hunderte von PCs. Also wurde die Rechenkapazität weg vom Host hin zu den dezentralen PCs verlagert. Wer künftig ein Dokument schreiben wollte, brauchte nur noch einen zentralen Ort (Server) um es abzulegen, alles andere übernahm der PC (Client), von der Tastatureingabe über das Rendern bis hin zur graphischen Darstellung am Bildschirm.

Dasselbe galt auch für die Netzwerk-Welt: ein zentraler Controller, der alle Verbindungen „der Welt“ kontrollierte, war allein aus Ressourcen-Gründen undenkbar: so viel Speicher und CPU-Power in einem oder sehr wenigen Geräten war utopisch. Also baute man lieber „kleine“ Geräte, die nur begrenzte Bereiche / Aufgaben abdeckten.

Die dezentrale Client-Server-Architektur passte also hervorragend zur dezentralen Netzstruktur von IP.

Die Frage, die wir uns heute stellen müssen, ist die: haben sich diese Voraussetzungen geändert? Zumindest für Unternehmen?

Zentrale SDN-Architektur
SDN ist aus dem Wunsch heraus geboren worden, eine Schnittstelle zu haben, mittels derer man das Netzwerk steuern kann. Diese Schnittstelle braucht man, um Anwendungen die Voraussetzungen zu geben, die sie für ihre Funktion benötigen, bspw. ein definiertes Delay, eine garantierte Bandbreite oder ein „merkwürdiges“ Routing, weil IP Adressen an „falschen“ Stellen auftauchen (Stichwort: vMotion).

Prinzipiell können diese Anforderungen bereits heute erfüllt werden, durch „policy based routing“, Host-Netze oder SPB im Layer-2 Umfeld. Allerdings muss man dafür viel Aufwand betreiben. Beispiel „policy based routing“: eine Kommunikation kann anhand von Regeln klassifiziert werden, bspw. dem TCP Port. Wird diese Kommunikation erkannt, so wird die Routing-Tabelle übersteuert und das Paket auf einen anderen Weg gebracht. Damit das Ganze wirklich funktioniert, müssen entsprechende Regeln auf allen Layer-3-Komponten entlang dieses Weges vorliegen. Die Nachteile liegen auf der Hand: das macht viel Arbeit, bietet jede Menge Möglichkeiten für Konfigurationsfehler und last but not least: wenn der Weg mal nicht funktioniert, gibt es kein Backup.

SDN soll das nun lösen, indem eine zentrale Komponente den Gesamtüberblick besitzt und den Kommunikationsfluss steuert. Man muss also nur noch an einer Stelle etwas eintragen, der Rest passiert automatisch. Zumindest theoretisch können Leitungsausfälle so auch erkannt und kompensiert werden.

Klingt doch prima!

Das Paradigmen-Problem
Es gibt bei SDN, wie bei der ATM LAN-Emulation, eine ganze Reihe von ungelösten Problemen. Das Grundproblem ist jedoch, wie eingangs geschrieben, dass hier unterschiedliche Philosophien aufeinander prallen. IP wurde nicht dafür geschaffen, sich zentral verwalten zu lassen. Es ist in jeder Faser seine Seins dezentral und alle Erweiterungen von IP setzen auf diesem Prinzip auf. IP denkt nämlich gar nicht in Kommunikationsströmen, sondern IP denkt in Netzen und die Paketvermittlung basiert nur auf dem Zielnetz, die Quelle ist egal, der TCP Port oder gar die URL sowieso.

Darum kann man zwar genau sagen, wo die Zieladresse in einem Paket steht (vgl. Bild 1), wo aber der Port oder gar irgendeine Anwendungsanweisung steht, ist nicht vorhersagbar: der IPv4 Header lässt Optionen zu und bei IPv6 gibt es die Extension Headers (vgl. Bild 2). Ohne eine „genaue“ Untersuchung des Inhaltes kann ich also keine Entscheidung bzgl. der Anwendung treffen. Das aber wiederum bedingt, dass ich die Header auswerten muss. Einfach ist das nicht, da alle Möglichkeiten mit programmiert werden müssen und ggf. in die Entscheidung einfließen.

Nun stellen Sie sich mal vor, dass ein einzelner Kontroller irgendwo in ihrem Netz sich wegen einer einzigen Anwendung mit allen Kommunikationsströmen auseinandersetzen muss, nur um dieser einen Applikation einen besonderes breitbandigen Weg zu garantieren. Das passt vorne und hinten nicht.

Will man ein Netz, bei dem man aufgrund bestimmter Bit-Folgen, die irgendwo im Paket stehen, Routing-Entscheidungen treffen kann, dann braucht man ein Protokoll, bei dem man genau vorhersagen kann, wo diese Bit-Folge steht. IP ist das nicht. TCP, RTP und ähnliche höhere Protokolle machen das nur noch schlimmer.

Fazit
Da IP gesetzt ist, wird SDN nicht kommen.

zugeordnete Kategorien: LAN
zugeordnete Tags: ,

Sie fanden diesen Beitrag interessant? Sie können



2 Kommentare zu "SDN ist eine Totgeburt":

  1. Dr. Franz-Joachim Kauffels schreibt:

    Also, so kann man das nicht stehenlassen. Der Autor sollte vorsichtig im Umgang mit Fakten aus einer Vergangenheit sein, an der er selbst noch gar nicht teilgenommen hat. Ich schon. Die ATM-LAN-Emulation ist damals an folgenden Dingen gescheitert:

    1. es war eine reine IBM-Entwicklung. Genau wie Cisco heute hatte IBM die Möglichkeiten, eine reine Eigenentwicklung als Standard erscheinen zu lassen, jeder wusste aber, dass das nicht stimmt.

    2. die ATM-LAN-Emulation war (genauso wie das dicke Token Ring Kabel) dazu gedacht, sie in Europa zu verkaufen, besonders standen deutsche Behörden im Visier. Hier hatte man sich überlegt, dass angesichts des Namens IBM (die Alternative war SIEMENS) niemand wirklich auf die Kosten und Funktionen schaut. Da hatten sie sich verrechnet, weil eine neue Generation von Beratern aufkam, die keinen Respekt mehr vor großen Namen hatten. Es war aber auch sehr lustig, diesen damals unglaublich aufgeblasenen VBs die Farbe aus dem Gesicht fallen zu lassen :-))

    3. es gab innerhalb von IBM drei grundsätzliche Fraktionen: Host, mittlere Systeme und PCs incl. Token Ring, die alle beim Kunden gegeneinander kämpften. Die LAN-Emulation kam von den Host-Leuten. Die Argumente, die ich damals mit durchschlagendem Erfolg gegen die ATM-LAN-Emulation verbreiten konnte, hatte ich direkt von den Token Ring Leuten und vom Labor in La Gaude. Sie hätten selbst niemals so offen sägen können.

    4. es gab tatsächlich Installationen. Die haben aber nicht funktioniert und zwar nicht deshalb, weil es wirklich unüberwindliche technische Probleme gab, sondern weil das damalige RZ-Personal überhaupt nicht in der Lage war, damit umzugehen. Verbunden mit einem ca. 10-15-fachen Preis gegenüber einer sagen wir mal 3Com-Lösung war das das Ende.

    IBM hatte gedacht, sie könnten die Deutschen nochmal so verarschen wie mit dem dicken Token Ring Kabel, was ja tatsächlich weltweit nur hier installiert wurde, der Rest der Welt hatte sich ja schon damals von seinen angeblichen Vorzügen nicht beeindrucken lassen.

    Bei SDN sieht das grundsätzlich anders aus, deshalb sind diese Dinge überhaupt nicht miteinander zu vergleichen.

    1. SDN ist eine internationale Entwicklung mit sehr vielen unterschiedlichen Teilnehmern.

    2. SDN ist natürlich nicht nur für den Verkauf in einem einzelnen „Entwicklungsland“ gedacht.

    3. Die treibende Kraft hinter SDN ist nicht ein einzelner Hersteller, sondern eine Anzahl sehr leistungsfähiger Betreiber, nämlich Netz-Provider und Cloud-Service-Provider.

    Und damit sind wir auch bei einem Missverständnis. SDN ist überhaupt nicht dazu gedacht, in normalen RZs kleiner und mittelständischer Unternehmen irgend etwas zu steuern und dabei den Unternehmen vielleicht zu ermöglichen, die so oft zitierte „billige Standard-Hardware“ einzusetzen (das ist ohnehin Unsinn), sondern es ist, wenn man es unbedingt philosophisch einklassifizieren möchte, eine neue Form für das seit über 25 Jahren bewährte OAM&P, was es basierend auf SONET bei jedem Provider gibt. Das normale OAM&P ist momentan nicht in der Lage, von den Vorzügen der Virtualisierung zu profitieren. OAM&P ist zentralistisch und daher ist es auch kein Wunder, dass SDN ebenfalls einen zentralistischen Ansatz wählt.

    Große Provider setzen bereits heute mit großem Erfolg SDN ein. Man kann auf der Referentenliste des aktuellen ONS 2014-Programms genau sehen, für wen das eigentlich gedacht ist. Die Behauptung, SDN sei eine Totgeburt, gehört angesichts milliardenschwerer erfolgreicher Installationen mitten ins Zentrum von Absurdistan.

    Diese falsche Sicht kommt dann zustande, wenn man eine völlig falsche Perspektive einnimmt. Ich bin aber ebenfalls der Ansicht, dass in Unternehmensnetzen, wie sie vom Durchschnitt der ComConsult-Kundschaft betrieben werden, nicht so schnell SDN in der Form kommen wird, wie wir das vielleicht vor 1-2 Jahren diskutiert haben. Schon gar nicht auf der Grundlage wackeliger Standards wie OpenFlow in seiner aktuellen Version. Aber in dem Maße, wie Unternehmen Funktionen von Providern aufnehmen, sei es zur Integration in hybride Clouds oder zur Versorgung größerer Bereich mobiler Teilnehmer, werden auch SDN-Instrumente Einzug halten.

  2. Dipl.-Ing. Olaf Hagemann schreibt:

    Die Frage, ob SDN sich durchsetzen wird oder nicht, wird letzendlich daran entschieden, ob SDN in der Lage ist, die Anforderungen der Netzbetreiber in einer Art und Weise zu lösen, wie sie die klassichen Technologien nicht oder nur unzureichend zur Verfügung stellen. Stand heute gibt es Anforderungen aus drei Bereichen:

    1) Service Provider nutzen SDN zur besseren Auslastung ihrer Backbones via Traffic Engineering. Hier sei nur Google als Vorreiter genannt. Und das sogar auf Openflow
    2) Cloud Provider nutzen SDN in Form von OpenStack zur automatischen Provisionierung virtueller Aplliances und Services.
    3) Im Enterprise schafft der SDN-Ansatz eine einfache und effiziente Möglichkeit, den wachsenden Anforderungen in puncto Access Control bei steigender Mobilität und wachsender Diversifizierung der Endgeräte zu begegnen

    Dabei sei es übrigens vollkommen dahingestellt, in welcher Form SDN in den einzelnen Bereichen implementiert wird. Letzlich geht es um die einheitliche zentrale Steuerung des Netzes und um die Einführung von Abstraktionsebenen mit offenen, standartisierten Schnittstellen. Darin liegt der grosse Vorteil von SDN.
    Der Bezug zur ATM LAN Emulation ist diesbezüglich übrigens gar nicht mal so ganz weit hergeholt. Nur wird letztlich anders herum ein Schuh daraus. Warum hat sich denn ein ATM im LAN nie wirklich durchsetzen können? Nicht weil es eine schlechte Technologie an sich war. Sondern weil es keine Applikationen gab, die spezifisch für ATM entwickelt worden sind. Statt dessen hat man via LAN Emulation versucht, den verbindungslosen Charakter eines Ethernet und eines IP auf einem verbindungsorientierten Netz abzubilden. Das muss ja scheitern.
    Und an dieser Stellen gibt es bezüglich der weiteren Entwicklung von SDN eine ähnliche Herausforderung. SDN wird sich nur dann umfassend durchsetzen, wenn es nicht nur ein leistungsfähiges Northbound API gibt, sondern wenn sich die Entwickler der Applikationen auch dieses Interfaces bedienen und ihre Applikationen entsprechend modellieren. Dann ist der echte Mehrwert evident.
    Bezüglich der Zentralität und Dezentralität kann man nun wirklich geteilter Meinung sein. Brechen wir es doch mal auf den Status Quo herunter. Dann hat jeder Switch/Router eine eigene Control Plane. Nun kann ich ja mal zwei oder drei Control Planes zusammenfassen und schon habe ich einen lokalen Controller. Und dann nehme ich mehrere lokale Controller und manage die von einem regionalen Controller. Und die ganzen regionalen Controller lasse ich dann von einem globalen Controller verwalten. Mit jedem Hierarchieschritt wird ein Teil der jeweiligen Instanz an die nächsthöhere abgegeben und ein anderer Teil verbleibt. Was ist das dann? Zentral oder Dezentral? Planwirtschaft oder Marktwirtschaft? Auf jeden Fall widerspricht ein solcher Ansatz nicht dem Gedanken von SDN. Wenn man also SDN als eine Idee der Verwaltung von Netzen begreift und nicht sklavisch an den einzelnen Implementierungen und Protokollen fest macht, so glaube ich dass es alles andere als eine Totgeburt ist, sondern die Technologie, mit der in Zukunft ein wesentlicher Teil der Netze betrieben werden wird.

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.