Wie fügt sich ONAP in die NFV-Architektur ein?

Status von MANO for NFV

2018 entwickeln sich die NFV-Implementierungen über die bloße Virtualisierung hinaus hin zu einer breiter angelegten NFV-Architektur. Diese komplexen Implementierungen erfordern Interoperabilität mit mehreren Anbietern, eine hohe Skalierbarkeit und eine ausgefeilte Orchestrierung. Die Unreife der MANO-Optionen behindert aber diese komplexeren NFV-Implementierungen derzeit noch.

Service-Provider arbeiten an ihren Plänen für ihre NFV-Architekturen und erwägen viele MANO-Optionen – sowohl Open Source als auch von speziellen Anbietern. Sie müssen auch virtuelle Funktionen mit modernisierten Operations- and Business-Support-Systemen (OSS/BSS) integrieren.

ONAP-Module und -Anwendungen

ONAP verfügt über eine große Codebasis mit vielen verschiedenen Modulen, die sich für mannigfaltige Anwendungsfälle eignen. Kein Service-Provider wird wahrscheinlich die gesamte oder auch nur den Großteil der Codebasis direkt implementieren. Die Provider müssen die ONAP-Module an ihre individuellen NFV-Infrastrukturen und Back-Office-Systeme anpassen. Zu den ONAP-Modulen gehören:

• Service Design and Creation
• Master Service Orchestrator
• SDN-Controller
• NFV-Orchestrierung
• Active and Available Inventory
• Sammeln und Analysieren von Daten
• Richtlinien- und Sicherheits-Framework

Die ONAP-Anwendungen sind sehr vielfältig und umfassen Themen wie Voice over Long Term Evolution, virtual Customer Premises Equipment (vCPE), VNF Lifecycle Management, verteilte Firewalls, Multi-Tenancy, Netzwerk-Management, Analytics sowie Elemente von 5G.

ONAP: Entwicklung und Reifegrad

ONAP verfügt durch die Kombination von ECOMP und Open-O über eine riesige Codebasis mit sich überlappenden Elementen. Die ersten Releases sind darauf ausgerichtet, die Codebasis zu verkleinern und sie für den Betrieb effizient, zuverlässig, sicher und leistungsfähig zu gestalten.

Ein weiteres wichtiges Ziel der ONAP-Community ist eine klare und umfassende Dokumentation. Da sich ONAP mit vielen anderen standardbasierten MANO-Optionen überschneidet, hofft die Linux Foundation, die Interaktion zwischen den oft konkurrierenden Organisationen zu verbessern. Viele Service-Provider kombinieren die ONAP-Architektur mit OpenDaylight, OpenStack und Open Platform for NFV (OPNFV) für den Aufbau einer umfassenden Open-Source-NFV-Architektur.

Breite Unterstützung durch Service-Provider und Lieferanten

ONAP wird von vielen Service-Providern unterstützt. AT&T und China Mobile beispielsweise haben einen Großteil der ursprünglichen Codebasis für das Projekt bereitgestellt. Bell Canada implementierte modulare Komponenten von ONAP, um die Bereitstellung des Netzwerks in seinen Rechenzentren zu automatisieren. Auch Service-Provider wie Verizon, Vodafone, Orange, Colt, Reliance Communications, China Telecom, China Unicom und Comcast unterstützen ONAP.

Das Ziel von ONAP ist es, die erforderlichen Fähigkeiten bereitzustellen, um den gesamten Lebenszyklus von NFV-Implementierungen zu koordinieren und zu verwalten.

Eine Reihe von Lieferanten sind Teil des ONAP-Projekts und planen, die ONAP-Implementierung durch Software-Releases, Professional Services und Support-Services kommerziell zu unterstützen. Nachfolgend einige Beispiele:

Amdocs: Der OSS/BSS-Anbieter Amdocs engagiert sich seit vielen Jahren für ECOMP, bedingt durch seine kundenspezifische Arbeit für AT&T. Im Jahr 2017 kündigte Amdocs ein ECOMP-basiertes Produkt an, das Netzbetreiber bei der Virtualisierung helfen soll. Das Angebot umfasst ein Portfolio von Modulen und die damit verbundenen Services. Amdocs unterstützte zudem Bell Canada bei der Implementierung von ONAP.

Red Hat: Red Hat trägt mit seinem Engagement zu vielen vorgelagerten Open-Source-Projekten bei, aus denen sich ONAP zusammensetzt – zum Beispiel OpenDaylight, Kubernetes, OPNFV und Linux. Der Fokus von Red Hat liegt auf der Entwicklung der Architektur und der Integration von ONAP-Elementen mit offenen Plattformen wie OpenStack, OpenShift, Ansible und JBoss, die es Service-Providern ermöglichen, innovative neue Anwendungen und Services anzubieten.

Weitere wichtige Lieferanten für ONAP sind Nokia, Ericsson, Ciena, Intel, Microsoft, Tech Mahindra, VMware, Huawei, ZTE und IBM.

Fazit

ONAP soll der künftige Standard für NFV MANO werden, ähnlich wie OpenStack beim Cloud Computing. Doch es wird Jahre dauern, bis ONAP diese Reife erreicht. Bis dahin werden sich die meisten Service-Provider aber weiterhin auf herstellerspezifische Optionen für NFV MANO verlassen müssen.

Service-Provider sollten eine umfassende Vision für die Netzwerk-Virtualisierung entwickeln, aber aufgrund der sich entwickelnden MANO-Technologie flexibel bleiben, um ihre Infrastruktur anzupassen. ONAP unterstützt Service-Provider beim Betrieb herstellerübergreifender NFV-Implementierungen und sorgt für eine hohe Zuverlässigkeit der Services. Längerfristig wird ONAP bei den Service-Providern Teil der NFV-Architektur sowie der Pläne für die Modernisierung ihrer Back-Office-Systeme sein.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!