Markt für Software-Defined Networking bleibt fragmentiert

Standard für Northbound API gesucht

| Autor / Redakteur: Dirk Srocke / Andreas Donner

Selbst Marktforscher fragen sich noch, welche Architektur sich letzlich für SDN durchsetzen wird.
Selbst Marktforscher fragen sich noch, welche Architektur sich letzlich für SDN durchsetzen wird. (Bild: Srocke)

Die Suche nach marktreifen Produkten für Software-Defined Networking führt zu erstaunlichen Ergebnissen. Statt eines branchenübergreifenden Standards propagieren die Anbieter unterschiedlichste Ansätze.

Auf dem ersten Blick erscheint die Welt des Software-Defined Networking (SDN) wohlgeordnet und leicht überschaubar: Die Open Networking Foundation (ONF) hat mit OpenFlow einen Industriestandard geschaffen, den mittlerweile über 90 ONF-Mitglieder mitentwickeln. Zu denen zählen die Größen der Netzwerkbranche; das nährt die Hoffnung, dass alle Anbieter in Kürze mit interoperablen Lösungen auf den Markt kommen. Genau nach diesen Angeboten hat sich IP-Insider erkundigt und ist auf dabei auf einige Widersprüche gestoßen.

Ein bisschen OpenFlow

So entfernt sich ONF-Mitglied Alcatel-Lucent zumindest mit der Enterprise-Sparte von OpenFlow. Konkret heißt es, dass das von OpenFlow vorgeschlagene, komplett zentralisierte Control-Modell "die notwendige Skalierbarkeit und Verlässlichkeit/Belastbarkeit vermissen" lasse. Gerade kleine und mittlere Unternehmen benötigten jedoch "typischerweise einfachere Lösungen die einen höheren Grad an Automatisierung mitbringen."

Und die liefere man mit dem Application Fluent Network. Das setzt auf das Managementsystem OmniVista und OmniSwitches. Mehrere solcher Switches lassen sich zu Pods zusammenschließen und als Mesh organisieren.

Obwohl OpenFlow dabei außen vor bleibe, halte man Elemente des Protokolls dennoch für sinnvoll und wolle diese in künftige Versionen einfließen lassen. Des Weiteren sollen Systeme von Drittherstellern künftig per OpenFlow angesteuert werden.

Auch Juniper Networks (Juniper) ist zwar ONF-Mitglied, konzentriert sich mit der eigenen SDN-Strategie aber auf alternative Protokolle, namentlich BGP und XMPP. Ein Grund hierfür seien Skalierungsüberlegungen, heißt es. So entwerfe man bei Juniper Netzwerklösungen mit maximaler Leistungsfähigkeit und breche diese erst dann auf kleinere Einheiten herunter. Das aus dem akademischen Umfeld stammende OpenFlow verfolge dagegen den entgegengesetzten Ansatz und müsse sich erst in großen Umgebungen beweisen.

Und noch einen Aspekt hat Juniper im Auge: Die Verzahnung von Anwendungen und Netzwerk. Unter dem Begriff "SDN Service Chaining" beschreibt Juniper, wie virtuelle Softwareinstanzen – beispielsweise Firewalls oder Application Delivery Controller – in den Netzwerktraffic eingebunden werden. Marktreife Produkte dieser Vision sollen 2014 erhältlich sein. Künftig will der Hersteller einzelne Netzwerksoftware auch unabhängig von Appliances lizenzieren.

Eine durchgehend klare Trennung zwischen Netzwerkhardware und Softwareinstanzen vermeidet Juniper allerdings. So könnte eine Deep Packet Inspection auch weiterhin auf dafür ausgelegter, dedizierter Netzwerkhardware laufen, während andere Anwendungen auf virtualisierte x86-Server ausgelagert werden.

Nord und Süd

Was sich hier andeutet ist auch ein Zwiespalt zwischen Northbound API und Southbound API. Die Southbound API regelt, wie Data Plane und Control Plane miteinander kommunizieren. Infoblox-CTO Stu Bailey sieht darin gleichsam "das Fundament für SDN". Dieses kann beispielsweise per OpenFlow implementiert werden, muss es aber nicht. Der nicht an der ONF beteiligte Anbieter Enterasys Networks nennt als valide Alternativen für Southbound APIs beispielsweise SNMP, NETCONF, XMPP oder RADIUS.

Die Northbound API hingegen steuert die Kommunikation des Controllers mit zusätzlichen Services, die über den eigentlichen Netzwerkverkehr hinausgehen. Und hier gibt es branchenweit noch keinen Konsens über ein passendes Protokoll. Für den auf Services spezialisierten Anbieter Enterasys ist das Grund genug, sich noch nicht bei der ONF zu beteiligen.

Die ONF selbst hat ich des Themas allerdings schon angenommen. Eine 2012 gegründete Diskussionsgruppe sei mittlerweile in der "Architecture and Framework Working Group" aufgegangen, die Anforderungen an die Northbound API ergründen soll. Am Ende des Prozesses sollen dann Empfehlungen stehen, die dazu beitragen, die Einführung von SDN-Anwendungen weiter zu beschleunigen, hofft ONF Executive Director Dan Pitt.

Analysten ratlos

Kein Wunder also, dass Analysten derzeit noch von einem frühen Stadium der SDN-Evolution sprechen. Marktforscher von Ovum haben kürzlich entsprechende Lösungen 37 unterschiedlicher Hersteller begutachtet. Welche der von diesen genutzten Architekturen sich auf lange Frist durchsetzen wird, wagten die Experten allerdings nicht zu prognostizieren.

Anwender sollten die angebotenen SDN-Lösungen auf dem Markt sehr genau begutachten. Gern werben die Hersteller zwar mit industrieüblichen Standards und offenen Schnittstellen. Konkret werden diese dann aber auf das eigene Ökosystem zugeschnitten. Beispielsweise nutzt Alcatel-Lucent mit RESTful API eine offene Schnittstelle, über die verschiedene Lösungen am Markt auf die Produkte zugreifen könnten. Die ONF beschreibt hingegen das deutlich umfassendere Szenario eines OpenFlow-Ökosystems in dem sich Netzwerksysteme und Controller aller Hersteller beliebig miteinander kombinieren lassen.

Alles aus einer Hand

Doch auch mit OpenFlow gibt es anscheinend noch keine Garantie, dass Lösungen verschiedener Anbieter tatsächlich reibungslos miteinander funktionieren. Während die ONF die Interoperabilität des OpenFlow-Protokolls gern bei PlugFest-Events demonstriert, nähren einzelne Hersteller Zweifel.

So stellt sich IBM zwar hinter die Vorteile offener Standards, wirbt letzten Endes aber auch mit getestetem, zertifiziertem und stabilem Equipment aus einer Hand. Ähnlich argumentiert Dell und will SDN-Lösungen "end-to-end" anbieten – Kunden erhalten damit also "erprobte Lösungen und Referenzarchitekturen". Konkret hatte der Hersteller bereits im Frühjahr 2012 hierfür erste Lösungsansätze gezeigt, zu denen auch ein Controller des Anbieters Big Switch gehörte. Aktuell kündigt der Hersteller Produkte für eine schrittweise SDN-Implementierung an. Eine im Herbst 2012 vorgestellte Beta-Lösung könne auf den bestehenden Plattformen Z9000 oder S4810 beispielsweise einzelne Ports für SDN nutzen.

Weitere sanfte Übergänge

Einen sanften Ansatz ermöglicht auch Netzwerkexperte Brocade, der sich sich nach Übernahme des Anbieters Vyatta auf dem Weg zu einem kompletten SDN-fähigen Portfolio sieht. OpenFlow-Controller seien mit dem Brocade-MLXe-Geräten interoperabel. An der Hardware könne OpenFlow portweise aktiviert werden. Zudem kooperiert der Anbieter in Sachen SDN auch mit NEC.

Der auf die Software-Steuerungsebene fokusierte Anbieter Infoblox will seine bereits für klassische Netzwerke angebotene Expertise auf SDN übertragen und somit für eine bessere Kontrolle von Netzwerken sorgen. Dazu CTO Stu Bailey: "Heute und in Zukunft unterstützen wir unsere Kunden auf dem Weg zu wirtschaftlich vorteilhafteren SDN, unabhängig von dem Standard, der sich am Ende durchsetzt."

Die Auflistung von SDN-Lösungen lässt sich nahezu beliebig fortsetzen. Das Angebot reicht dabei von Netzwerkanwendungen für Unternehmen unterschiedlichster Prägung bis hin zu Testlösungen.

So hat Hewlett-Packard bereits ein komplettes Produktportfolio angekündigt. Intune Networks bietet auf Basis der iVX8000-Plattform einen RZ-übergreifenden SDN-Switch für Carrier und Enterprise-Kunden an. ADVA Optical hat derweil schon die Betreitstellung von Wellenlängen per SDN demonstriert. Testtools für SDN-Implementierungen liefern Ixia mit IxNetwork und IxANVL sowie Luxoft mit Twister für OpenFlow and SDN.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 37975810 / Produkte & Lösungen)