© anyka, 123RF

Onos ist als Projekt zwar jünger als Open Daylight, mausert sich aber zu einer ernst zu nehmenden Konkurrenz im SDN-Bereich. Das Linux-Magazin inspiziert das Reich des Netzwerk-Betriebssystems.

Das Open Network Operating System (Onos, [1]) ist eine SDN-Plattform, die darauf abzielt, proprietäre, unflexible und teure Netzwerk-Black-Boxes zu öffnen. Diesen Markt dominieren seit Jahren ein paar hochpreisige Anbieter. Den primären Support für das Onos-Projekt liefert das Open Networking Lab (On.lab, [2]), eine gemeinnützige, im kalifornischen Menlo-Park ansässige Organisation. Sie arbeitet zurzeit an Version 1.7.0 (Codename Hummingbird), der mittlerweile achten Release von Onos.

Zum Team von Onos gehören diverse weitere Zuträger, darunter Service Provider wie AT&T, China Unicom, NTT Communications und Anbieter wie Alcatel Lucent, Ciena, Cisco und Ericsson. Zudem kooperiert das Onos-Projekt seit dem Oktober 2015 mit der Linux Foundation [3]. Zusammen mit Open Daylight [4] gehört Onos dank seiner konstanten Entwicklung, der aktuellen Dokumentation, dem Community-Support und den praktischen Anwendungsfällen zu den zwei Größen in dem noch jungen SDN-Ökosystem.

Drei Hauptziele beschreibt das Projekt auf seiner Webseite. Es will Partner gewinnen, hochqualitative SDN-Software (Netzwerk-OS-Software) produzieren und Open-Source-Prozesse schaffen, mit denen Mitarbeiter möglichst produktiv arbeiten. Das Projekt erhofft sich aus der Kooperation aller am Projekt Beteiligten einen deutlichen Mehrwert. Der äußerte sich zunächst in Form sorgfältig verfasster Wiki-Einträge und einer gepflegten Mailingliste, die sich von der lückenhaften Dokumentation des Open-Daylight-Projekts abhoben.

Wohl auch um das zu leisten, steigerte Onos innerhalb von ein paar Monaten die Zahl seiner Zuarbeiter deutlich. Vielleicht als Reaktion verfeinert das Open-Daylight-Projekt seine Dokumentation in letzter Zeit ebenfalls.

Architektur

Bei Onos handelt es sich um eine modulare, erweiterbare und verteilte Controller-Infrastruktur. Sie ist in Java verfasst und steht unter Apache-2.0-Lizenz. Seine Modularität und Erweiterbarkeit verdankt das Projekt der Implementierung als Apache-Karaf-Container [5]. Verteilt arbeitet es aufgrund einer eigens für Onos entworfenen Architektur. Ein Netzwerkbetreiber kann mehrere Onos-Instanzen als Cluster laufen lassen. Dies synchronisiert die Dienste und Anwendungen der SDN-Devices automatisch und visualisiert das Netzwerk als Ganzes in einer Überblicksansicht.

Daneben unterstützt Onos eine breite Auswahl an Southbound-Interface-Protokollen, mit denen SDN-Controller und Switches sowie Router kommunizieren. Dazu gehört Open Flow [6] in den Versionen 1.0 und 1.3, die von Anbietern hauptsächlich unterstützten Varianten. Hinzu kommen Netconf [7] und das Open Vswitch Database Management Protocol (OVSDB, [8]) für die Gerätekonfiguration.

Wie Abbildung 1 zeigt, ist Onos aus funktional verbundenen Ebenen [9] konstruiert. Die Anwendungsebene thront über allen und ist Konsument des Northbound-API. Am Fuß des Stapels sammeln sich Netzwerkelemente, die über spezifische Protokolle (Open Flow, Netconf und weitere) mit Onos reden. Das verwandelt sie in protokollunabhängige Provider, die das Southbound-API formen.

Abbildung 1: Die Architektur von Onos funktioniert Protokoll-agnostisch, die Anwendungen auf Basis der Plattform verwenden das Northbound-API.

Im Zentrum zwischen Northbound- und Southbound-API steckt mit dem Core-Element eine funktionale Einheit, die verschiedene Dienste anbietet. Die bestehen aus einem oder mehreren Subsystemen (Device, Host, Link und so weiter), die sich einerseits auf Basis von Informationen formieren, die von den Providern stammen. Andererseits tragen sie zu den APIs für die Anwendungen bei.

Abbildung 2 zeigt die Beziehungen der Subsystem-Komponenten zueinander [9]. Die gepunkteten Linien repräsentieren die Northbridge- und Southbridge-APIs. Anwendungen fragen Dienste aktiv ab, verwalten sie oder ergänzen Listener für Dienste-Events. Läuft Open Flow im Netzwerk und ist der Open-Flow-Provider aktiv, erzeugt ein neues Netzwerkpaket, das auf einem Netzwerkgerät eintrifft, ein »PacketIn« -Event.

Abbildung 2: Die Beziehungen der Stack-Komponenten zueinander. Die Anwendungen können Listener aktivieren, die auf Events reagieren.

Der Listener kann sich für ein Event registrieren und darauf reagieren. Eine Anwendung, die solche Events konsumiert, lässt sich unabhängig von der Protokollversion ausführen, auch wenn der Provider nicht aktiv ist. Die Manager-Komponente vermittelt zwischen Applikationen, Diensten und Providern. Stores synchronisieren Informationen zwischen mehreren Onos-Instanzen, was das erwähnte Cluster-Feature ermöglicht.

Intents programmieren

Ein charakteristisches Subsystem von Onos ist das Intent Framework. Mit ihm entwerfen Entwickler Anwendungen auf einer höheren Abstraktionsebene, indem sie dem Netzwerk schlicht mitteilen, was es erledigen soll, und nicht, wie es dies erreicht.

Will ein Netzwerkbetreiber zum Beispiel, dass Host A mit Host B redet, teilt er das Onos direkt mit: “Ich will, dass A mit B kommuniziert.” Andere SDN-Controller erfordern, dass Netzwerker mit eingehenden Paketen hantieren und einen Flow Entry für jedes Netzwerkgerät in dem Pfad anlegen.

Logisch sammelt das Intent-Framework-Subsystem, um seine Aufgabe zu erfüllen, Informationen von anderen Subsystem-Komponenten (Topologie, Host). Allerdings ist es noch nicht ausgereift genug und die Entwickler arbeiten an einer reicheren Syntax.

Praxiseinsatz

Entwickler haben bereits mehrere Projekte mit Onos als SDN-Plattform umgesetzt. Das wohl relevanteste heißt Central Offices Re-architected as Datacenters (Cord, [10]). Es wurde kürzlich aufgrund der hohen Nachfrage als eigenes Open-Source-Projekt abgesplittet. Cord baut traditionelle Netzwerkdienste und Protokolle zu Anwendungen in einer Cloudumgebung um. Ein Beispiel: Optical Line Terminations (OLT) sind Geräte, die Telekommunikationsanbieter verwenden. Sie bestehen in der Regel aus reiner Hardware. Neuerdings stellen aber virtuelle OLTs (vOLTs), die Onos entwickelt hat, die gewünschte Funktionalität bereit. Dadurch laufen sie auch als Dienste auf nicht-spezialisierter Hardware.

Die anderen Controller

Ryu [11] ist ein Python-basierter SDN-Controller, der sich aufgrund einer guten Dokumentation und eines beherrschbaren API für die Anwendungsentwicklung in Proof-of-Concept-Szenarios sehr gut eignet. Allerdings hängen die Anwendungen noch immer von einem speziellen Southbridge-Protokoll ab, welches das Netzwerk antreibt, während Onos keine solche Präferenz verlangt.

Floodlight [12] gilt als weiteres Beispiel für einen bekannten SDN-Controller. Sein größter Nachteil besteht darin, dass es Anwendungen zur Laufzeit nicht dynamisch aktiviert. Dank der Karaf-Container beherrscht Onos dieses Feature, das dazu konzipiert ist, bei Bedarf Java-Bundles zu laden oder entladen. Das Onos-Projekt verwendet einige der Bibliotheken von Floodlight, um zum Beispiel Open-Flow-Nachrichen zu verschicken. Die Importe im Onos-Code sehen so aus: »import org.projectfloodlight.*« .

Open Daylight [4] ist schließlich das SDN-Projekt, das Onos am meisten ähnelt. Tatsächlich sind beide in Java geschrieben, nutzen Karaf als Container und teilen auch einige weitere Features: Protokollunabhängigkeit, Skalierbarkeit, eine Kommandozeile, ein grafisches Benutzerinterface, ein REST-API und noch einige weitere Fähigkeiten. Einer der Hauptunterschiede besteht allerdings in der Architektur.

Open Daylight basiert auf einem generalisierten, Model-getriebenen Service Abstraction Layer (MD-SAL, [13]), wobei die Entwickler ihre Modelle in der Datenmodellierungssprache Yang [14] planen und später in spezifische APIs umsetzen. Onos bringt hingegen eine vorgefertigte Subsystem-Architektur mit, die hinreichend generalisiert für alle möglichen Arten von Anwendungen ist, sich aber bei Bedarf auch erweitern lässt. Daher finden es einige Entwickler leichter, neue Anwendungen für Onos zu entwickeln als für ODL. Denn anders als bei Onos, das die APIs bereits integriert, müssen sie diese für ODL erst entwickeln.

Ein weiterer Unterschied besteht in der Koordination der Projekte: ODL speist sich aus mehreren Projekten mit unterschiedlichen Projektleitern und Abhängigkeiten. Integratoren führen diese im Vorfeld einer Release zusammen. Onos ist hingegen ein Großprojekt, das eine Gruppe von Mitarbeitern leitet, die sich um die Integration kümmert.

Nicht zuletzt meinen einige SDN-Experten, Open Daylight sei geeigneter für die Cloud und universelle Systeme (auch weil es ältere Protokolle abdeckt), während sich Onos eher für die Service Provider und reine SDN-Deployments als nützlich erweise.

Erste Schritte mit Onos

Um einen ersten Eindruck von Onos zu erhalten, kann der Entwickler die Software aus den Quellen installieren. Um die Java-Bundles zu übersetzen, benötigt er Java 8, Apache Karaf und Apache Maven [15]. Eine Downloadseite [16] bietet Onos als Paket oder Archiv (Tar.gz, Zip, Deb oder RPM) oder als Tutorial-VM an. Zudem steckt es im Docker-Hub. Nicht zuletzt wartet Onos auf der DELUG-DVD. Um das SDN-Netzwerk zu emulieren, ist Mininet [17] der einfachste Ansatz, es befindet sich auf der Heft-DVD zur Linux-Magazin-Ausgabe 08/16.

Um eine installierte Onos-Instanz zu starten, genügt die Eingabe von »ok clean« . Der Befehl »ok« steht für Onos Karaf und startet einen kompilierten Karaf-Container, in dem Onos läuft. Die Option »clean« ist typisch für Karaf und sorgt dafür, dass der Nutzer eine neue Sitzung startet, ohne erst vorherige Bundels und Aktionen zu laden.

Mit Hilfe von Mininet kann er ein Tree-Netzwerk mit Open-Flow-1.3-Switches aufsetzen:

sudo mn --controller remote,ip=IP-Adresse von Onos --topo tree,3,2 --switch ovsk, protocols=OpenFlow13 --mac

Die »IP-Adresse von Onos« muss der User mit der Instanz abgleichen, auf der Onos läuft. Dank des Parameters »–mac« lassen sich MAC-Adressen auf dem Host einfach auf kleine, einzigartige und einfach zu lesende IDs setzen, die sich an die letzten Bytes der IP-Adresse anlehnen.

Abbildung 3: Der Befehl »apps -s -a« zeigt eine gekürzte (»-s«) Liste der aktiven (»-a«) Onos-Anwendungen.

Um zu prüfen, welche Anwendungen laufen, lässt der Admin sie sich im GUI visualisieren oder mit Hilfe des »apps« -Befehls über die Kommandozeile auflisten (Abbildung 3). Der Befehl »devices« zeigt die Geräte, die Onos erkennt, indem er die aktiven Switches anhand ihrer IDs durchnummeriert. Auch sie lassen sich alternativ über das GUI anzeigen, wie Abbildung 4 verdeutlicht.

Das CLI kennt einige weitere Onos-Befehle, die ein »help | grep onos« auflistet. Auch Karaf-Befehle stehen bereit, etwa »log:display« , um Logdaten anzuzeigen. Ist beispielsweise die Reactive Forwarding Application aktiv (»org.onosproject.fwd« ) – und das ist bei einer Standardinstallation üblicherweise der Fall –, lässt ein »pingall« in Mininet alle Hosts im GUI auftauchen, wie es Abbildung 4 schön illustriert.

Abbildung 4: Die Hauptansicht des Onos-GUI zeigt die Topologie und die generelle Konfiguration der Plattform im Browser an.

Um Anwendungen zu (de)aktivieren, hilft im Fall der Reactive Forwarding App der Befehl »app activate org.onosproject.fwd« . Das GUI erreicht der User, indem er in einen Browser

http://IP-Adresse von Onos:8181/onos/ui/login.html

eintippt und »karaf« als Username und Passwort wählt.

Auch Intents installieren Benutzer über die Kommandozeile. Das Kommando »add-host-intent« sucht einen Pfad zwischen zwei Hosts. Konkret verbindet der Befehl

add-host-intent 00:00:00:00:00:01/-1  00:00:00:00:00:03/-1

die beiden Instanzen mit den MAC-Adressen »00:00:00:00:00:01« und »00:00:00:00:00:03« miteinander. Onos sucht dabei automatisch die kürzeste Verbindung zwischen ihnen.

Das setzt allerdings voraus, dass das Host-Subsystem von Onos beide Hosts zuvor erkannt und registriert hat. Ist dies nicht der Fall, speichert Onos die Intent so lange, bis die Hosts auftauchen. Einmal installiert, lassen sich Intents wie in Abbildung 5 visualisieren.

Abbildung 5: Die gestrichelte Linie symbolisiert einen zwischen den Hosts »10.0.0.1« (»00:00:00:00:00:01«) und »10.0.0.3« (»00:00:00:00:00:03«) installierten Intent. Onos erzeugt die Verbindung eigenständig.

Um eine Onos-Instanz zu schließen, tippt der User ein einfaches »logout« oder »system:shutdown« ins CLI.

Reich mit Potenzial

Onos ist eines der jüngsten SDN-Projekte, die Plattform könnte aber eine vielversprechende Zukunft vor sich haben. Als einer der beiden wesentlichen freien SDN-Controller konkurriert Onos vor allem mit Open Daylight. Onos bringt dabei einige Vorteile mit. Dank durchdachter APIs bauen Entwickler recht einfach Anwendungen. Es setzt einen klaren Fokus auf professionelle Einsatzszenarien im Carrier-Markt, verfügt über einen signifikanten Community-Support und ist gut dokumentiert.

Allerdings startete das Projekt ein Jahr später als Open Daylight und benötigt noch einige Entwicklungsanstrengungen, um zu einer voll ausgewachsenen Plattform zu reifen. Welches der konkurrierenden Frameworks das Feld im Laufe der Zeit bestimmt, wird erst die Zukunft zeigen. Möglicherweise kreuzen sich ja irgendwann die Pfade beider Projekte und sie verschmelzen zu einem großen SDN-Reich.

Der Autor

Elisa Rojas arbeitet als Forschungsleiterin für Telcaria Ideas S.L. Ihr Fokus liegt auf SDN- und NFV-Techologien. Seit 2010 arbeitet sie mit SDN-Protokollen und -Frameworks und veröffentlichte 2013 eine Doktorarbeit zum Thema. Sie trägt zudem zu europäischen SDN-Projekten bei und arbeitet als Dozentin im Bereich NFV und SDN an der Carlos III University of Madrid (UC3M).