Software Defined Networking (SDN) wird vorwiegend mit OpenFlow beziehungsweise der Open Network Foundation assoziiert. Doch mit OpenDaylight hat sich nun ein zweites Gremium gebildet, das SDN-Technologie entwickelt. Entstehen sollen unter anderem eine quelloffene Software für den SDN-Controller und eine Lösung, die ihn für mehrere Parteien gleichzeitig nutzbar macht.
Bis vor kurzem gab es für SDN eigentlich nur ein relevantes Gremium: die Open Network Foundation (ONF), die an dem offenen virtualisierten Vernetzungsprotokoll OpenFlow, derzeit in Version 1.3 freigegeben, und an Erweiterungen dafür arbeitet.
Das ist seit April 2013 anders. Am 8. des Monats lief die Gründungsmeldung von OpenDaylight um die Welt. Vorangegangen waren, glaubt man Insidergerüchten, allerlei Querelen. Denn ursprünglich startete Netz-Weltmarktführer Cisco die Initiative und holte sich IBM ins Boot. Gemeinsam beschloss man, dass OpenFlow, wo beide Unternehmen nicht allzu viel Initiative entwickelt hatten und andere vorn lagen, für die Realisierung softwaregesteuerter Kommunikationsnetze längst nicht ausreiche.
Lücken bei OpenFlow
Ganz falsch ist das sicher nicht. Schließlich fehlen OpenFlow bislang Umsetzungsrichtlinien für das Kernstück solcher Infrastrukturen, den SDN-Controller, sowie definierte Schnittstellen zu Netzwerk- und anderen Applikationen nebst grundlegenden Eigenschaften professioneller Netzwerke, etwa Mandantenfähigkeit oder Loadbalancing. Zwar sollen auch bei OpenFlow bald solche Ergänzungen für wichtige Netzwerkdienste entwickelt werden, sie sind aber noch nicht da.
Cisco nutzte also diese Chance, um sich selbst gegen die Unwägbarkeiten der SDN-Welt besser zu positionieren. Denn in einem idealen virtualisierten, softwaregesteuerten Netz braucht man die komplexen, über Jahrzehnte gewachsenen Protokollstapel auf jedem Router nicht mehr. Das Know-how, das in die Entwicklung und das Management immer neuer Routerprotokoll geflossen ist ? Ciscos Kronjuwelen ? droht dadurch seinen Wert zu verlieren und die bisherige Dominanz bei den Netzelementen ist ebenfalls gefährdet, wenn jedes x-beliebige Gerät dieselbe oder sehr ähnliche Leistungen bringt.
Cisco hatte deswegen schon 2012 sein SDN-Konzept CiscoONE verkündet und bringt nun den Code des dazu gehörigen Controllers XNC mit OpenDaylight ein ? gewissermaßen als Basis der neuen Netzwerkwelt. Doch als Cisco für OpenDaylight weitere Unterstützung neben IBM suchte, soll das Unternehmen zunächst auf Granit gebissen haben: Die Beitrittsgebühren für OpenDaylight seien zunächst unzumutbar hoch gewesen sein, heißt es. Wichtiger dürfte aber gewesen sein, dass kein Konkurrent Interesse haben kann, Ciscos endlich einmal leicht bedrohte Dominanz auf dem Netzwerkmarkt von neuem zu zementieren.
Cisco muss sich zu Offenheit bekennen
Damit aus der Idee ?OpenDaylight? etwas werden konnte, verabschiedeten sich Cisco und IBM also vorläufig von der Illusion der SDN-Weltherrschaft und machten die Tore auf: Die Gebühren wurden gesenkt, das OpenDaylight-Gremium hat nun konsequent offene Entwicklungsrichtlinien. Allerdings bildet noch immer Code aus Ciscos SDN-Controller eine Kernkomponente des Projekts. Doch auch andere Firmen wollen etwas beisteuern. Cisco gibt außerdem nicht seine gesamte Software in die Open-Source-Community. Für den Hausgebrauch behält der Hersteller beispielsweise Code für sich, mit dem sich ein SDN-Netzwerk in logisch getrennte Bereiche teilen lässt.
Die Maßnahme zeigte Erfolg. Schon die Gründungsmeldung des Gremiums zeichneten 13 Netzwerkhersteller und nannten die Themen, zu denen sie beizutragen gedenken. Arista beispielsweise will Software für große Cloud-Umgebungen zusteuern. BigSwitch, ein Newcomer, der sich von Anfang an auf SDN-Switches spezialisiert hat, Teile seiner Open SDN Suite, Brocade Technologien, mit denen sich elastische On-Demand-Dienste einrichten lassen.
Von Cisco stammt unter anderem die Abstraktionsschicht des Controllers, die den Controller von den Services und Applikationen (SAL, Service Abstraction Layer) trennt, über unterschiedliche Programmierschnittstellen den Zugriff auf die Netzelemente unterer Ebenen eröffnet, den Applikationen aber eine einheitliche Sicht auf diese Programmierschnittstellen bietet. Diese Netzelemente dürfen, daran muss Cisco als dem Hersteller des größten Teils der installierten Gerätebasis sehr gelegen sein, mehr Protokolle verstehen als OpenFlow.
(Schaut einfach mal hier) Webseite aufrufen