Ciscos SDN-Protokoll OpFlex: Konkurrenz für OpenFlow und VMwares OVSDB?

Ob Ciscos SDN-Protokoll OpFlex genauso offen wie OpenFlow sein wird, muss sich zeigen. Zu erwarten ist eher ein ähnlicher Aufbau wie VMwares OVSDB.

Laut Cisco kann man mithilfe seines SDN-Protokolls OpFlex Policies dynamisch über Netzwerke mehrerer Hersteller programmieren. Die Konkurrenz fragt sich allerdings, ob die Technologie jemals offen genug sein wird, um anderen Herstellern einen praxistauglichen Einsatz zu ermöglichen.

Weiterhin mutmaßt man bei der Konkurrenz, dass die OpFlex-Standardisierung lediglich eine Taktik seitens Cisco ist, um Applikations-zentrierte Infrastrukturen (ACI) als eine SDN-Technologie zu legitimieren.

OpFlex ist ein so genanntes Southbound-Protokoll, womit ein Controller Policy- und Konfigurations-Befehle an Netzwerk-Geräte weitergibt. Durch diese Form der Programmierbarkeit kann die Infrastruktur dynamisch reagieren und sich auf die Anforderungen der Applikationen anpassen.

Dieses Protokoll ist für Ciscos ACI von zentraler Bedeutung, da es von proprietären Switches mit verteilter Intelligenz und zentralisierter Policy-Kontrolle abhängt. Andere SDN-Strategien gehen einen Weg, der mehr auf Software ausgerichtet ist, wodurch die komplette Steuerungs-Schicht in einem zentralen Controller liegt. Dieser kommuniziert mit dem Netzwerk über einfache, handelsübliche Switche.

Cisco will OpFlex für eine Standardisierung bei der Internet Engineering Task Force (IETF) einreichen, somit würde das Protokoll öffentlich zugänglich und ließe sich von der gesamten Branche nutzen. Darüber hinaus arbeitet Cisco an einem Projekt mit dem OpenDaylight-Konsortium, das sich Group Policy Initiative nennt. Die OpFlex-Controller könnten damit die Policy-Kontrolle auf jede Anbieter-Plattform ausweiten, die das Protokoll unterstützt. Midokura und Plexxi beispielsweise sind in diesem Projekt involviert.

Wenn Cisco OpFlex offen ist, wo bitte ist dann der Code?

Andere Anbieter, die sich derzeit knietief in der SDN-Entwicklung befinden und gegenüber OpFlex durchaus aufgeschlossen wären, halten es für ein schlechtes Zeichen, dass Cisco bisher den Code hinter der Technologie noch nicht veröffentlicht hat.

Carl Moberg ist Vize-Präsident der Technologie-Abteilung bei Tail-f Systems. Er ist der Meinung, dass Cisco bisher lediglich einen „informellen Entwurf zur Verfügung gestellt hat“. Dieser sei weit davon entfernt, den Code als IETF-Standard durchgehen zu lassen. Für diesen Beitrag wurden mehr als ein halbes Dutzend Firmen interviewt und einige davon sind sogar in OpenDaylight involviert. Keiner hat laut eigenen Aussagen bisher den OpFlex-Code zu Gesicht bekommen.

Es gibt einen massiven Unterschied zwischen einem veröffentlichten Standard und einem, der quelloffen einer Open-Source-Community für Weiterentwicklung und Mitarbeit zur Verfügung steht. Diese Aussage traf Kelly Herrell, Vize-Präsident und Geschäftsführer der Software Networking Business Unit bei Brocade. OpenFlow zum Beispiel ist komplett offen gelegt und jedes Mitglied der Open Networking Foundation (ONF) kann bei der Entwicklung mitarbeiten.

Ob nun offen oder nicht, OpFlex ist auf ausgeklügelte Hardware und eine verteilte Steuer-Ebene angewiesen. Das spielt klar in die Hände von Ciscos Geschäfts-Modell, ist aber nicht wirklich ein Ziel von SDN.

„Die Branche hat im Hinblick auf wirklich offene Standards genaue Vorstellungen und ist misstrauisch gegenüber potenziellen Trojanischen Pferden und Goldenen Käfigen. Die Geschichte hat uns gelehrt, dass proprietäre Protokolle fast nie auf der Gewinner-Seite standen. Das gilt besonders dann, wenn diese als offen verkleidet sind, wie das im Moment bei Ciscos Vorschlag der Fall ist“, sagte Brocades Herrel. „Brocades Strategie ist das krasse Gegenteil zu dieser Herangehensweise. Wir arbeiten mit Partnern und Kunden, um auf wirklich offenen Standards basierende SDN- und NFV-Technologien voranzutreiben und einzusetzen.“

Neela Jacques, Geschäftsführer bei OpenDaylight, ist dagegen der Meinung, dass Ciscos OpFlex mehr ein philosophischer Unterschied zwischen den Firmen ist. „Die einen glauben daran, dass die Intelligenz komplett zentralisiert sein müsse,“ Cisco hingegen vertritt die Meinung, „dass die eingesetzte Hardware viel beitragen könne.“ Cisco enthülle erstmals seine „geheime Zutat“, anstatt diese hinter verschlossenen Türen zu lassen, fügte Jacques an.

Laut Jacques behauptet Cisco, dass man einen offenen Standard erschaffen wolle. Man verstehe schon, dass Endanwender keine Lösung von nur einem Hersteller haben möchten. Cisco verstehe auch, dass man das Vertrauen anderer gewinnen und diese auf den Zug aufspringen lassen müsse. Je mehr Unterstützung das Unternehmen bekommt, desto besser. Durch einen OpenDaylight-Controller könnten Anwender zum Beispiel selbst aus einer der beiden SDN-Strategien wählen.

Policy-Krieg: OpFlex gegen OVSDB, Cisco gegen VMware

Oft wird OpFlex mit OpenFlow verglichen, da es sich bei beiden Varianten um Southbound-Protokolle für SDN handelt. Allerdings ist OpFlex mehr mit Open vSwitch Database(OVSDB) von VMware vergleichbar. OVSDB ist das Protokoll, das Management- und Konfigurations-Policies an Open vSwitches verteilt. VMware verwendet OVSDB daher für Policy- und Management-Aufgaben in NSX-Overlay-Umgebungen.

Mithilfe von OVSDB lassen sich Konfigurationen auf Netzwerk-Geräte und Overlays ausgeben, so Nick Lippis. Er ist Gründer der Open Networking User Group (ONUG) und des Lippis Reports. OpFlex sei das erste alternative Protokoll, das dieselbe Funktionalität wie OVSDB verspreche. Allerdings könne man derzeit noch nicht abschätzen, welches davon effizienter ist, da beide noch nicht aktiv eingesetzt werden.

Cisco „mache das Richtige“, einen OpFlex-Agent mit einer Open-Source-Lizenz auszugeben, die ähnlich zu Apache 2.0 ist, meint Lippis. Ob der Markt darauf anspringe, müsse sich allerdings erst noch zeigen.

Möglicherweise wird sich die Branche in zwei Lager aufspalten. VMware verwendet VXLAN als das Tunneling-Protokoll und OVSDB bei der Open-vSwitch-Implementierung. Cisco hingegen benutzt OpFlex und eine Kombination aus OpenFlow und anderen Southbound-Protokollen. Auf der Interop sagte VMwares CTO, Martin Casado, dass seine Firma eine Annahme von OpFlex nicht ausschließe. Voraussetzung sei aber, dass das Protokoll gut genug und wirklich offen sei. Er wies auch darauf hin, dass Cisco OVSDB die gleiche Ehre wahrscheinlich nicht zuteil lassen würde.

Beide Protokolle wirken sich nicht direkt auf OpenFlow aus, OpenFlow wiederum kann unter Umständen aber in jeder Infrastruktur eine Rolle spielen, die OpFlex oder OVSDB im Einsatz hat. Ein Netzwerk könnte zum Beispiel darauf setzen, via OpenFlow die Datenfluss-Befehle zu verteilen, während OpFlex für die Policy-Kontrolle zuständig ist.

Sowohl Cisco OpFlex als auch VMwares OVSDB werden in OpenStack-Umgebungen funktionieren

Bei Ciscos Ankündigung, OpFlex für eine IETF-Standardisierung einzureichen, hat das Unternehmen von einigen Partnerschaften gesprochen, zum Beispiel mit Canonical. So soll die Orchestrierungs-Unterstützung für OpenStack unter Ubuntu  um OpFlex erweitert werden.

„Wir wollen OpFlex … um mit Open vSwitch-Komponenten zu interagieren und das Ganze soll mit unserem Orchestrierungs-Tool verbunden sein“, sagte Mark Baker, Produkt-Manager für Ubuntu Server und Cloud.

Für jeden Cloud-Betreiber ist es derzeit ein erklärtes Ziel, gleichzeitig über Netzwerk, Storage und Computing eine einheitliche Orchestrierung betreiben zu können. Die Interaktion sowohl zu OpFlex als auch zu OVSDB wird damit gerade in OpenStack-Umgebungen ausschlaggebend sein.

Martin Casado, bei VMware für die Netzwerk-Architektur verantwortlich, hat gegenüber SDNCentral verlauten lassen,  dass er in einem OpenStack-Projekt mit Namen Congress involviert ist. Damit will man „Policy as a Service“ über Netzwerk, Storage und Computing für Cloud-Services etablieren. Laut Casado beinhaltet die Initiative ein Gruppen-Policy-Framework. Das geht seiner Aussage nach sogar noch über das hinaus, was Cisco mit OpenDaylight anstrebt. Das Ziel sei dabei, keinem Hersteller die alleinige Kontrolle über das Policy-Framework zu geben.

Folgen Sie SearchNetworkingDE auch auf Facebook, Google+ und Twitter!

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close