Arbeit an Benchmarks, Migration, NFV, NBI und Hardware ONF zaudert mit Software-Standards

Von Amtswegen ist Dan Pitt einer der größten Fürsprecher des OpenFlow-Protokolls. Im Interview verdeutlicht der ONF Executive Director allerdings, was es darüber hinaus noch für Software-Defined Networking braucht.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

Zonicgroup

Software-Defined Networking (SDN) wird erwachsen – dieses Bild vermittelte zumindest der diesjährige SDN & OpenFlow World Congress. Das Konzept ist mittlerweile bekannt, jetzt geht es um die Umsetzung in der Praxis. IP-Insider hat sich bei Dan Pitt erkundigt, was das für Anwender, Hersteller und die weitere Arbeit der Open Networking Foundation (ONF) bedeutet.

IP-Insider: Seit unserem letzten Treffen ist ein Jahr vergangen. Was ist für Sie der größte Erfolg, den die ONF in dieser Zeit erreicht hat?

Pitt: Der größte Erfolg? Es ist schwer da nur einen hervorzuheben!

Ich denke es ist eine Kombination aus wirklich erheblichem Fortschritt am OpenFlow-Substrat – darunter nicht nur verschiedene Updates für OpenFlow selbst, sondern auch Erweiterungen für Optical Transport und Wireless, deutlich mehr Erweiterungsmöglichkeiten sowie Verbesserungen bei Konfiguration, Management und Security.

Wir haben beim Software-Defined Networking auch über OpenFlow hinaus einiges geschafft. Das beinhaltet die Kooperation mit ETSI NFV (European Telecommunications Standards Institute Network Functions Virtualisation) und die Arbeit in Sachen Migration, Architektur und Northbound Interface (NBI). Wir haben uns ein Jahr lang intensiv mit dem Thema NBI beschäftigt und einen Bericht über die vielfältigen NBI-Arten zusammengestellt. Jetzt haben wir eine offizielle Arbeitsgruppe gegründet, um Informationsmodelle und Anwendungsfälle aufzubauen und die zahlreichen Kombinationen aus Longitudes [Funktionsebene, Anm. d. Red.] und Latitudes [Abstraktionsebene, Anm. d. Red.] mit den wichtigsten Bedürfnissen des Marktes abzugleichen – und für diese werden wir einen etwas prototypischen Code entwickeln.

IP-Insider: Das ist eine Menge. Möchten Sie wirklich nichts hervorheben?

Pitt: Sicher, reden wir doch noch etwas mehr über das Northbound Interface. Das ist ein heißes Thema, denn es zeigt, die Softwareindustrie ist bereit, die Vorteile einer SDN-Infrastruktur zu nutzen. Vor zweieinhalb Jahren haben wir angefangen, darüber nachzudenken. Damals haben wir uns gegen eine Standardisierung des Northbound Interface entschieden. Für die Entscheidung gab es zwei hauptsächliche Gründe: Zum einen fühlten wir, dass es noch zu früh für eine Standardisierung war; außerdem glauben wir, dass Softwarestandards nur dann von einem Komitee festgelegt werden sollten, wenn das absolut nötig ist.

Seither haben wir das Thema NBI und entsprechende Bemühungen im Auge behalten. Im vergangenen Jahr haben wir dann über 20 bestehende APIs katalogisiert. Dabei haben wir die eigentlichen Controller und Anwendungsszenarien genauso betrachtet, wie bereits existierende Datenmodelle. Schließlich haben wir beschlossen, eine formelle ONF Northbound Interfaces Working Group zu gründen, um das Thema eingehender zu betrachten, Informationsmodelle für eine Auswahl von Longitudes und Latitudes zu erstellen und Prototypen zu programmieren.

Es ist dabei nicht das Ziel der Arbeitsgruppe, einen Standard zu erstellen; wir werden aber erneut darüber entscheiden, ob ein Standard nicht vielleicht doch nötig sein wird. Wir arbeiten dabei mit Partnern zusammen und haben einige Szenarien für Zielimplementierungen. Wir schließen nicht aus, dass wir noch mehr tun – wenn die Industrie danach verlangt.

IP-Insider: Warum so zurückhaltend?

Pitt: Wir sind nicht sicher, ob das Northbound Interface überhaupt von einem Gremium standardisiert werden muss. Wenn man eine Schnittstelle in Software implementiert, kann das ein anderer leicht modifizieren. Und wenn es einmal von der Industrie angenommen wird, braucht man kein Komitee mehr, um die Schnittstelle zu standardisieren. Außerdem wird es nie nur eine einzige Schnittstelle geben; es muss auch nicht nur eine einzige sein.

Bei Protokollen ist das anders, weil wir die in Hardware und Silizium implementieren müssen. Und hier erledigt man die Dinge lieber richtig, bevor man 50 Millionen Dollar und zwei Jahre Entwicklung in einen Chipsatz steckt.

IP-Insider: Aus diesem Grund hat die ONF auch ein "Chipmakers Advisory Board" eingerichtet?

Pitt: Ja, wir haben damit im Juni angefangen. Um besser zu verstehen, was Chips tun können und was das OpenFlow-Substrat tun muss. Mit der Einführung von „Multiple Tables“ in OF 1.1 gab es immer wieder einige Beschwerden, weil die Chips damit nicht klarkommen.

Nun, ein wenig können die Chips schon tun. In einer wechselseitigen Diskussion wollen wir jetzt herausfinden, wie OpenFlow-Protokoll und Hardware besser miteinander zusammenarbeiten.

Dabei überlegen wir, wie das OpenFlow-Protokoll besser mit bestehender Hardware harmoniert und betrachten insbesondere aktuell verfügbares Silizium, etwa die Fähigkeiten von Netzwerkprozessoren für DPI [Deep Packet Inspection, Anm. d. Red.] und NFV in der Forwarding Plane.

IP-Insider: Mit NFV (Network Functions Virtualization) erwähnen Sie eines der aktuellen Trendthemen. Wie hängen SDN und NFV zusammen?

Pitt: In erster Linie ermöglicht SDN viele nützliche Ausprägungen von NFV. Ohne SDN taugt NFV lediglich dazu, von einem auf dedizierten Appliances basierenden Programmiermodell zu einer Infrastruktur mit nicht spezialisierten Servern auf virtuellen Maschinen zu wechseln. Wenn man diese VMs aber bewegen – also erstellen, löschen und ändern – will, dann muss man auch Pfade zu den VMs erstellen. Der ideale Ansatz hierfür heißt OpenFlow. Erfordert eine zu virtualisierende Funktion die Einbeziehung der Forwarding Plane – etwa für eine bestimmte Aktion des Netzwerks – dann braucht es etwas wie OpenFlow, um diese Änderungen zu vollziehen: Beim Load Balancing müssen Anfragen beispielsweise über den geringst ausgelasteten Link zum Server mit der geringsten Auslastung geschickt werden. Das kann über eine reguläre Pfadkalkulation umgesetzt und den relevanten Switches per OpenFlow mitgeteilt werden. Ohne diese SDN-Mechanismen wird man zwar Rechenleistung sparen, aber kein flexibles Netzwerk gewinnen und auch nicht die wichtigsten Netzwerkfunktionen selbst virtualisieren können.

IP-Insider: Ab wann werden diese Mechanismen und SDN allgemein auch für kleinere Anwenderunternehmen interessant werden?

Pitt: Ich glaube, dass KMU schlussendlich über Cloud Provider von SDN profitieren werden. Über eine vertrauenswürdige Cloud werden Unternehmen die Dinge tun können, die sie schon immer tun wollten. Sie werden dafür keine große IT-Abteilung mehr vorhalten müssen; alles was interessiert ist die Verbindung zwischen Anwendern und Applikationen.

Der Cloud Provider kümmert sich um den Rest. Und um eine verlässliche, mehrmandantenfähige Infrastruktur aufzubauen wird unter der Haube ein SDN laufen.

IP-Insider:Wie geht es weiter: Worin sehen Sie die größte Herausforderung für die ONF im kommenden Jahr?

Pitt: Das Tempo mitzuhalten, dass uns die Industrie vorgibt!

Wir haben so viele Dinge die wir erledigen wollen und wir wollen sie so schnell wie möglich erledigen. Dabei wollen wir auch sicher sein, dass sie den Markt voranbringen. Eine bedeutende Rolle wird dabei sicher das Thema der Migration spielen, weil immer mehr Unternehmen wissen wollen, wie sie von all dem profitieren können, was SDN zu bieten hat während sie die bisherigen Investionen in bestehende Netzwerke optimal ausschöpfen. Wir werden sehr viel Zeit damit verbringen, über das OpenFlow Substrate hinauszublicken und SDN nicht nur in NFV zu integrieren, sondern auch in OpenStack und Telekommunikationsmanagementsysteme.

IP-Insider: Da werden Interoperabilitätstests sicher ein wichtiger Aspekt sein…

Pitt: Beim Thema Interoberabilitätstests haben wir bereits einen guten Start hingelegt aber auch noch einen weiten Weg vor uns. Wir testen, wie Switches und Controller miteinander sprechen. In OpenFlow gibt es jede Menge Optionen und Extensions, die das Protokoll sehr flexibel machen. Das bedeutet: Es gibt sehr unterschiedliche Implementierungen, die nicht immer miteinander funktionieren.

Wir versuchen darum zu verstehen, welche der verschiedenen Optionen und Extensions der Markt wirklich braucht. Konformität hilft, garantiert noch keine Interoperabilität. Wir glauben, dass wir Stufen der Konformität definieren können, die zu einer größeren Interoperabilität führen – also keine zufällig gewählten Protokolleigenschaften, sondern eher einige sinnvoll miteinander kombinierte Basisfunktionen oder -optionen. Wir haben zudem mit Konformitätstests begonnen und werden unsere Arbeit weiter ausbauen; zugleich planen wir Performance-Benchmarks. All diese Bemühungen sollen die Zuversicht des Marktes in verfügbare Produkte und Lösungen anregen.

IP-Insider: Herr Pitt, vielen Dank für das Gespräch!

(ID:42439873)