Northbound APIs und ihre Rolle in Software-definierten Netzwerken

Northbound APIs dienen in einem Software-definierten Netzwerk zur Entwicklung und Bereitstellung von Diensten und Anwendungen.

Das Northbound Application Programming Interface (API) eines Controllers für Software-definierte Netzwerke (SDN) ermöglicht Anwendungen und Orchestrationssystemen die Programmierung des Netzwerks sowie die Anforderung von Services daraus.

Ein SDN verfügt über eine „Stapel-Architektur“, bei der die Ebene der Netzwerk-Steuerung von der Weiterleitung getrennt ist. Die Steuerung erfolgt über einen zentralen Controller, der anhand von übergeordneten Richtlinien das Verhalten bei der Weiterleitung steuert. Während eine Southbound-Schnittstelle wie OpenFlow dem Controller gestattet, das Verhalten der Switches im unteren SDN-Stack zu definieren, stellt die Northbound API eine Schnittstelle zur Abstraktion des Netzwerks für die Anwendungen und Verwaltungssysteme des oberen SDN-Stacks dar.

„Diese Informationen lassen sich alle einsehen und mithilfe von OpenFlow direkt verwalten“, erläutert Mike Cohen, Director of Strategic Alliances bei Big Switch Networks. „Mit den durch die Northbound API gebotenen und darin kombinierten Funktionen ist die Erstellung von Konstrukten auf höheren Ebenen und deren sinnvolle Verarbeitung oberhalb des Controllers möglich.“

Northbound APIs bilden also die Basis für grundlegende Netzwerk-Funktionen wie Pfadberechnung, Schleifen-Unterdrückung, Routing, Sicherheit und andere Aufgaben. Zudem bieten sie für Orchestrationssysteme wie OpenStack Quantum oder VMware vCloud Director die Möglichkeit, Netzwerk-Services in einer Cloud zu verwalten.

Wichtigste Vorteile der Northbound API

„Eine offene Northbound API ist die Grundlage für das Ökosystem der Netzwerk-Anwendungen, was der eigentliche Vorteil eines SDN ist“, sagt Rob Sherwood, Principal Architect bei Big Switch Networks und Vorsitzender der von der Open Networking Foundation ins Leben gerufenen (ONF) Architecture Working Group.

„Ohne eine Northbound API müssen alle Netzwerk-Anwendungen direkt vom Geräte-Hersteller bezogen werden, was Innovationen innerhalb des Netzwerks verkompliziert. Am besten betrachtet man das Ganze als App-Store für Netzwerk-Anwendungen – ohne eine Northbound API wäre es unmöglich“, so Sherwood.

Über die Northbound API können Netzbetreiber ihre Netzwerk-Steuerung zudem schnell verändern oder anpassen. „Ein durchschnittlicher Programmierer kann das mithilfe beliebter Programmiersprachen wie Java, Python oder Ruby über eine API erledigen“, sagt Cohen. „Sie benötigen dafür niemanden, der sich mit den Feinheiten und Fallstricken der Geräte für die verschiedenen Daten-Ebenen auskennt, denn die werden ja durch den Controller über die Northbound API abstrahiert und normalisiert.“

Wer nutzt Northbound APIs?

Erstaunlich viele Leute – angefangen bei Herstellern und Service-Anbietern bis hin zu gemeinnützigen Organisationen und Bildungseinrichtungen – setzen Northbound APIs für die unterschiedlichsten Zwecke ein. „Große Netzbetreiber und Service-Anbieter passen die von ihnen genutzten Anwendungen für den internen Gebrauch an. Zudem sind auch akademische und wissenschaftliche Einrichtungen in dieser Hinsicht sehr aktiv“, erläutert Cohen.

Im Grunde genommen sind Northbound API für all jene interessant, die selbst Netzwerk-Anwendungen entwickeln möchten. Laut Sherwood gleicht die Situation einem Rennen: Die Frage sei stets, wer die nächste Killer-Anwendung präsentiert und damit den großen Durchbruch bei Smartphone-Nutzern schafft.

Northbound API: Noch nicht ausentwickelt

Momentan wird eine ganze Reihe von Northbound APIs entwickelt. Aktuell sind mehr als 20 verschiedene SDN-Controller erhältlich, und alle verfügen über unterschiedliche Northbound APIs. Dies weckte das Interesse der ONF, einem Konsortium zur Förderung und Kommerzialisierung von SDN, sodass sie sich nun mit den Ursachen für diese Vielfältigkeit beschäftigt.

Ein möglicher Grund dafür liegt in den variierenden Anforderungen für eine Northbound API. Diese hängen wiederum von den Anforderungen der übergeordneten Anwendungen und Orchestrationssysteme ab. Und offenbar gibt es bei den APIs momentan keinerlei Zusammenarbeit zwischen den verschiedenen Anbietern.

„Wir haben sogar schon eine direkte Integration von OpenFlow in Anwendungen gesehen“, berichtet Dan Pitt, Executive Director der ONF. „Andere erstellen Controller mit Northbound APIs und machen damit gute Erfahrungen. Für die Benutzer-Erfahrung sowie für das gesamte Ökosystem sind solche Erfahrungen Gold wert.“

Da es sich bei SDN um eine noch relativ neue Technologie handelt, herrscht allgemein noch leichte Unsicherheit darüber, was mit Northbound APIs alles möglich ist. Alle Beteiligten arbeiten noch daran herauszufinden, welche Form sich am besten eignet und welche Funktionen sich damit realisieren lassen.

„Ein Ziel von APIs ist die Bereitstellung einer Plattform, die unterschiedliche Varianten von Funktionen für Netzwerk-Geräte ermöglicht – und wir konzentrieren uns auf die Realisierung solcher Funktionen“, erläutert Cohen. „Mit unserer Northbound API versuchen wir, genau das zu leisten.“

Bisher fehlende Standardisierung

Angesichts der vielen von unterschiedlichen Anbietern präsentierten kommerziellen SDN-Produkte bemüht sich die ONF um die Erarbeitung möglicher Standards. Während gegenwärtig die Innovationen von Anbietern, Forschern und Nutzern im Vordergrund stehen, soll später auf Basis solcher Standards eine offene Plattform entstehen.

„Die Netzwerk-Branche erlebt gegenwärtig einen tiefgreifenden Wandel: Protokolle und Standards treten in den Hintergrund, während Software und APIs das Ruder übernehmen. Hier ist jede Menge Fingerspitzengefühl gefragt, um nicht etwa später Innovationen zu behindern, wie sie im Moment für Northbound APIs entwickelt werden“, meint Pitt.

Andere aber sehen die Zeit für Diskussionen über Standards längst noch nicht gekommen. Zum Beispiel Martin Casado, OpenFlow-Pionier und Mitgründer von Nicira, der die aktuelle Lage bei Northbound APIs als „Wildwest“ bezeichnet: „Diese ganzen APIs sind vollkommen neu, interessant und innovativ. Allerdings habe ich meine Zweifel, ob sie überhaupt irgendeines der Probleme lösen. Erst wenn am Markt Produkte auftauchen, die Lösungen für reale Probleme bieten, können wir eine Diskussion über Standards beginnen.“

Artikel wurde zuletzt im Dezember 2012 aktualisiert

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close