Kurz erklärt: Open Network Automation Platform
Nach Schema
Automatisierung ist die größte Herausforderung für Telekommunikationsanbieter. Das Open-Source-Framework ONAP soll sie dabei unterstützen.
Die Automatisierung ist einer der zentralen Trends in der IT. Das gilt besonders für Serviceprovider, die Millionen von Netzanschlüssen einrichten, konfigurieren und überwachen müssen. Änderungen sollen als zentrale Policies definiert und umgehend ausgeführt sowie Netzfunktionen zunehmend virtualisiert werden.
Das erfordert grundlegende Änderungen an den Softwarearchitekturen. Mit der Open Network Automation Platform (ONAP) hat die Linux Foundation (LF) ein Projekt initiiert, das diese Aufgaben erfüllen soll. Sponsoren sind Telcos, Netzausrüster sowie Hard- und Softwarehersteller wie IBM und VMware.
Im Kern handelt es sich um eine Softwarebibliothek, die als Open Source unter der Apache-v2-Lizenz vorliegt. Die erste Version erschien im November 2017, die stark erweiterte Version 3 im Dezember 2018. Neu sind unter anderem die Einbeziehung von 5G-Netzen und die Implementierung von Diensten über Providergrenzen hinweg mithilfe des Managed Extensibility Framework.
Die Linux Foundation spezifiziert die unterschiedlichen Anwendungsfälle in sogenannten Blueprints. Die ersten beiden waren die Steuerung virtueller Endkundenanschlüsse (vCPE) und Voice over LTE (VoLTE). In Zukunft sollen Weiterentwicklungen zweimal pro Jahr in einer neuen Version erscheinen.
Verwandtschaft mit NFV
ONAP ist eng verwandt mit der Network Functions Virtualization des ETSI. NFV definiert unter anderem ein Framework für Management und Orchestrierung (MANO), das ONAP konkret implementiert, aber auch Open Source MANO (OSM) oder das von Telefónica geförderte OpenMANO.
Zehn Millionen Zeilen Quellcode zeugen von der Komplexität; der modulare Aufbau ermöglicht es den Providern aber, in ihren Netzen nur einzelne Funktionen zu implementieren. Das unterstützt ONAP durch eine Microservices-Architektur und Runtimes in Docker-Containern.
Die ONAP-Architektur besteht aus zwei zentralen Elementen, die den Lifecycle von Funktionen und Diensten abbilden. Das Design-Time Framework dient dem Spezifizieren von Services in all ihren Aspekten, dem Modellieren von Ressourcen und deren Beziehungen sowie dem Definieren von Regeln und Policies. Das Run-Time Environment setzt die Regeln im Netz um, steuert und überwacht die physischen und virtualisierten Netzelemente. Die Grundlage bildet das Active & Available Inventory (A&AI), das alle Informationen über Ressourcen, Funktionen und Dienste verwaltet – einschließlich ihrer Beziehungen zueinander. Es ist echtzeitfähig und dient gleichermaßen zum Monitoring wie zum Einrichten und Ändern von Diensten. Mithilfe eines Metadatenformats lassen sich neue Inventory-Typen dynamisch anlegen, was die Entwicklungszyklen verkürzen soll.
ONAP läuft vollständig in einem Kubernetes-Cluster, verwaltet vom ONAP Operations Manager. Seine Aufgabe besteht in der automatisierten Steuerung des gesamten Lifecycle einer Netzfunktion: Einrichtung, Konfiguration, Monitoring, Restart, Upgrade, Scaling und Terminierung. Die Linux Foundation spricht von Closed-Loop Automation, da Fehler, Ressourcenengpässe oder neue Kundenanforderungen nicht nur erkannt, sondern auch automatisiert behoben respektive bearbeitet werden sollen. Neu ist der Multi-Site State Coordination Service, der die Verwaltung geografisch verteilter Komponenten ermöglicht. Dabei können Instanzen an mehreren Lokationen gleichzeitig laufen, um Verfügbarkeit und Zuverlässigkeit zu erhöhen. Aus diesem Grund eignet sich ONAP für unterschiedliche Cloud-Szenarien. (un@ix.de)