Die Virtualisierung von Netzfunktionen wurde bisher vorrangig in Datenzentren genutzt, um auch bei Loadbalancer, Firewalls, Gateways und anderen sogenannten „Middleboxen“ von der Virtualisierung profitieren zu können. Mittlerweile dehnt sich dieses Konzept aber auch auf Telekommunikationsnetze aus. Dazu werden Teile der Netzfunktionen des TK-Netzes in Software abgebildet und komponentenweise zu virtuellen Netzfunktionen (VNF) zusammengesetzt (orchestriert). Über ein VNF-Management sollen diese dann in den Datenzentren auf COTS Servern bereitgestellt und betrieben werden.

Die Aufgabe eines VNF-Managements ist daher die Kontrolle und Steuerung der virtuellen Netzfunktionen von der Inbetriebnahme bis zur Abschaltung (LifeCycle). Damit diese Aufgabe auf unterschiedlichen Plattformen in gleicher Art geleistet wird, hat das „European Telecommunications Standards Institute“, ETSI, die funktionalen Anforderungen an das Management von virtuellen Netzfunktionen in „ETSI GS NFV-IFA 010“ (NFV MANO Functional requirements specification) zusammengefasst. Das Dokument stellt eine Ergänzung zu „ETSI GS NFV-MAN 001“ (NFV MANO) dar, das die NFV MANO Architektur beschreibt.

Wesentliche Bestandteile der NFV MANO Architektur sind der NFVO (Orchestrator), der NFVM (Manager) und der VIM (Infrastruktur Manager). Der NFVO unterstützt die Zusammenstellung der Funktionen und Services. Der VIM sorgt für die verlässliche Bereitstellung der Infrastruktur und der VNFM nimmt eine Art Vermittlerrolle ein. In dieser Rolle ist er über den Zustand der Infrastruktur informiert und überwacht die Einrichtung der für die Serviceerbringung notwendigen Ressourcen.

Im Rahmen eines Projektes wurde bei der Adiccon GmbH getestet, in wie fern die von ETSI beschriebenen Anforderungen an das VNF-Management bei einer aktuellen Entwicklung berücksichtigt werden. Dazu wurde der neue VNF-Manager der weit verbreiteten OpenStack-Cloud Umgebung ausgewählt, der dort innerhalb des Projektes „Tacker“ realisiert wird.  Die Tests wurden mit der DevStack Variante für  „OpenStack-Liberty“ aber auch für die Entwicklungsversionen von „Mitaka“ durchgeführt.

Tacker ermöglicht ein „Onboarding“ von VNF-Funktionen, die basierend auf OASIS-TOSCA Spezifikationen im VNF-Katalog bereitgestellt werden. Nach einem erfolgreichen „Onboarding“ ist das Einsetzen der Funktion (Deployment) in die Umgebung als initiierende Methode des VNF-Managements möglich. Die Netz-Funktion läuft nach dem Deployment innerhalb der OpenStack-Umgebung, von der die funktionsüberwachenden Dienste für die VNF Infrastruktur geleistet werden.

Die Tacker Funktionen können in OpenStack auf verschiedene Weise bedient werden. Für eine erste Orientierung ist deren Bedienung über die  OpenStack-Oberfläche „Horizon“ unter dem Menüpunkt „NFV“ angeraten. Es gibt in der getesteten Variante nur die Menüeinträge „VNF Catalog“ (Abbildung 1) und „VNF Manager“ (Abbildung 2).

Abbildung 1: OpenStack – VNF Management – VNF Catalog

Beim VNF-Management werden die Bereitstellung (Deployment) und das Abschalten (Terminate) von VNF angeboten. Das Deployment erlaubt die Übergabe von Konfigurations-Parametern und – Werten in einer Datei oder in einem Eingabefeld. Zum Terminieren kann eine oder mehrere VNF ausgewählt werden.

Abbildung 2: OpenStack – VNF Management – VNF Manager

Anhand von Einträgen in der Service-Beschreibung können die VNF mit Monitoring Funktionen, wie z.B. eine „ping“-Überwachung, verknüpft werden. Die Korrelation von Fehlern in Bezug auf die gesamte Funktionskette und ein entsprechendes Fehlermanagement ist noch ausbaufähig. Diese Aufgabe ist allerdings komplex, da hier möglicherweise die Informationen mehrerer VNF-Umgebungen zusammengebracht werden müssen.

Der Funktionsumfang soll mit weiteren OpenStack-Versionen steigen.

Zur Integration des VNF Managements in bestehende Prozessumgebungen stellt Tacker eine REST API zur Verfügung. Als Administratorschnittstelle verfügt Tacker, wie bei OpenStack üblich, über ein Python Command Line Client Interface. Beide Schnittstellen wurden um ETSI MANO Funktionalitäten erweitert und sollen die Integration mit anderen Systemen unterstützen.

Mit der Bereitstellung des Service-Kataloges wird die Tacker Funktionalität über die von ETSI beschriebenen Aufgaben eines VNF-Managers in die Orchestrierungsebene (NFVO) ausgeweitet. Das führt zu einer Verschmelzung des VNF-Managers mit anderen Modulen der Virtualisierungsumgebung. Damit wird zwar die plattforminterne Kommunikationsmenge verringert, aber auch eine nicht gewollte Abhängigkeit der Module untereinander geschaffen. Dadurch entsteht die Gefahr, dass die gewonnene Hardware-Unabhängigkeit in einer Plattform-Abhängigkeit mündet.

Es ist zu begrüßen, dass das VNF-Management durch das Tacker-Projekt eine größere Aufmerksamkeit bekommt. Der Test hat gezeigt, dass die vorliegende VNF-Manager Variante erste Ansätze der Standardisierung aufgreift. Es ist zu erwarten, dass sich der Funktionsumfang mit weiteren OpenStack-Versionen erhöht.

Die Verschmelzung von Modul-Funktionalitäten mit der Virtualisierungsumgebung stellt allerdings ein Problem dar, das auch bei anderen VNF-Managern zu beobachten ist. Zukünftig ist verstärkt darauf zu achten, dass die von ETSI vorgegebene Architektur, insbesondere die Schnittstellen, umgesetzt werden.

Erläuterungen:

COTS: Commercial of the Shelf
REST: Represential State Transfer
Onboarding: Aufnahme einer VNF Spezifikation in den VNF Katalog
MANO: Management and Orchestration
OASIS: Nonprofit Konsortium, das die Entwicklung und Verwendung offener Standards in der Informationsgesellschaft zum Ziel hat.
TOSCA: Topology and Orchestration Specification for Cloud Applications