Virtualisierung von Netzwerkfunktionen - Network function virtualization

Network Functions Virtualization (auch Network Function Virtualization oder NFV ) ist ein Netzwerkarchitekturkonzept , das die Technologien der IT- Virtualisierung nutzt, um ganze Klassen von Netzwerkknotenfunktionen in Bausteine zu virtualisieren , die miteinander verbunden oder verkettet werden können, um Kommunikationsdienste zu erstellen.

NFV stützt sich auf, aber unterscheidet sich von traditionellen server- Virtualisierungstechniken, wie sie in Unternehmens - IT verwendet. Eine virtualisierte Netzwerkfunktion oder VNF kann aus einer oder mehreren virtuellen Maschinen oder Containern bestehen, auf denen unterschiedliche Software und Prozesse ausgeführt werden, zusätzlich zu Standard-Servern, Switches und Speichergeräten oder sogar Cloud-Computing- Infrastruktur, anstatt benutzerdefinierte Hardware-Appliances zu verwenden für jede Netzwerkfunktion.

Zum Beispiel könnte ein virtueller Session Border Controller eingesetzt werden, um ein Netzwerk zu schützen, ohne die typischen Kosten und Komplexität des Erwerbs und der Installation von physischen Netzwerkschutzeinheiten. Andere Beispiele für NFV sind virtualisierte Load Balancer , Firewalls , Intrusion Detection-Geräte und WAN-Beschleuniger .

Hintergrund

Die Produktentwicklung in der Telekommunikationsindustrie folgte traditionell strengen Standards für Stabilität, Protokolltreue und Qualität, was sich in der Verwendung des Begriffs Carrier Grade zur Bezeichnung von Geräten widerspiegelt, die diese Zuverlässigkeit demonstrieren. Obwohl dieses Modell in der Vergangenheit gut funktionierte, führte es unweigerlich zu langen Produktzyklen, einem langsamen Entwicklungstempo und der Abhängigkeit von proprietärer oder spezifischer Hardware, zB maßgeschneiderten anwendungsspezifischen integrierten Schaltkreisen (ASICs). Der zunehmende Wettbewerb bei Kommunikationsdiensten durch schnelllebige Unternehmen, die in großem Umfang im öffentlichen Internet tätig sind (wie Google Talk , Skype , Netflix ), hat Dienstanbieter dazu veranlasst, nach Wegen zu suchen, den Status quo zu durchbrechen.

Geschichte

Im Oktober 2012 veröffentlichte eine Gruppe von Telekom - Betreiber ein weißes Papier auf einer Konferenz in Darmstadt, Deutschland , auf Software-Defined Networking (SDN) und Openflow . Der Call for Action zum Abschluss des Weißbuchs führte zur Gründung der Network Functions Virtualization (NFV) Industry Specification Group (ISG) innerhalb des European Telecommunications Standards Institute (ETSI). Die ISG setzte sich aus Vertretern der Telekommunikationsbranche aus Europa und darüber hinaus zusammen. Seit der Veröffentlichung des Whitepapers hat die Gruppe über 100 Publikationen erstellt. Im Jahr 2016 wird eine leistungsstarke Open-Source-Version von NFV veröffentlicht. openNetVM ist eine leistungsstarke NFV-Plattform basierend auf DPDK- und Docker-Containern.

Rahmen

Das NFV-Framework besteht aus drei Hauptkomponenten:

  1. Virtualisierte Netzwerkfunktionen (VNFs) sind Softwareimplementierungen von Netzwerkfunktionen, die in einer Infrastruktur zur Virtualisierung von Netzwerkfunktionen (NFVI) bereitgestellt werden können.
  2. Network Functions Virtualization Infrastructure (NFVI) ist die Gesamtheit aller Hardware- und Softwarekomponenten, die die Umgebung bilden, in der NFVs bereitgestellt werden. Die NFV-Infrastruktur kann sich über mehrere Standorte erstrecken. Das Netzwerk, das die Konnektivität zwischen diesen Standorten bereitstellt, wird als Teil der NFV-Infrastruktur betrachtet.
  3. Network Functions Virtualization Management and Orchestration Architecture Framework (NFV-MANO Architectural Framework) ist die Sammlung aller Funktionsblöcke, Datenrepositorys, die von diesen Blöcken verwendet werden, sowie Referenzpunkte und Schnittstellen, über die diese Funktionsblöcke Informationen zum Zweck der Verwaltung und Orchestrierung von NFVI austauschen und VNFs.

Der Baustein sowohl für NFVI als auch für NFV-MANO ist die NFV-Plattform. In der NFVI-Rolle besteht es aus virtuellen und physischen Verarbeitungs- und Speicherressourcen sowie Virtualisierungssoftware. In seiner NFV-MANO-Rolle besteht es aus VNF- und NFVI-Managern und Virtualisierungssoftware, die auf einem Hardware-Controller betrieben wird . Die NFV-Plattform implementiert Carrier-Grade-Funktionen, die verwendet werden, um die Plattformkomponenten zu verwalten und zu überwachen, sich nach Ausfällen zu erholen und effektive Sicherheit zu bieten – alles erforderlich für das öffentliche Carrier-Netzwerk.

Praktische Aspekte

Ein Dienstanbieter, der dem NFV-Design folgt, implementiert eine oder mehrere virtualisierte Netzwerkfunktionen oder VNFs . Ein VNF selbst stellt den Kunden des Anbieters nicht automatisch ein nutzbares Produkt oder eine nutzbare Dienstleistung zur Verfügung. Um komplexere Dienste zu erstellen, wird das Konzept der Dienstverkettung verwendet, bei der mehrere VNFs nacheinander verwendet werden, um einen Dienst bereitzustellen.

Ein weiterer Aspekt bei der Implementierung von NFV ist der Orchestrierungsprozess . Um hochzuverlässige und skalierbare Dienste zu erstellen, erfordert NFV, dass das Netzwerk in der Lage ist, VNF-Instanzen zu instanziieren, sie zu überwachen, zu reparieren und (am wichtigsten für ein Service-Provider-Geschäft) die erbrachten Dienste abzurechnen. Diese als Carrier-Grade-Features bezeichneten Attribute werden einer Orchestrierungsschicht zugewiesen, um eine hohe Verfügbarkeit und Sicherheit sowie niedrige Betriebs- und Wartungskosten bereitzustellen. Wichtig ist, dass die Orchestrierungsschicht in der Lage sein muss, VNFs unabhängig von der zugrunde liegenden Technologie innerhalb der VNF zu verwalten. Beispielsweise muss eine Orchestrierungsschicht eine SBC- VNF von Anbieter X, die auf VMware vSphere ausgeführt wird, genauso gut verwalten können wie eine IMS- VNF von Anbieter Y, die auf KVM ausgeführt wird.

Verteiltes NFV

Die anfängliche Wahrnehmung von NFV war, dass virtualisierte Fähigkeiten in Rechenzentren implementiert werden sollten. Dieser Ansatz funktioniert in vielen – aber nicht in allen – Fällen. NFV setzt größtmögliche Flexibilität hinsichtlich des physischen Standorts der virtualisierten Funktionen voraus und betont diese.

Daher sollten virtualisierte Funktionen idealerweise dort platziert werden, wo sie am effektivsten und am wenigsten teuer sind. Das bedeutet, dass es einem Service Provider freistehen sollte, NFV an allen möglichen Standorten zu lokalisieren, vom Rechenzentrum über den Netzknoten bis hin zum Kundenstandort. Dieser Ansatz, der als verteiltes NFV bekannt ist, wurde von Anfang an betont, als NFV entwickelt und standardisiert wurde, und ist in den kürzlich veröffentlichten NFV-ISG-Dokumenten prominent vertreten.

Für einen Service Provider hat es in manchen Fällen klare Vorteile, diese virtualisierte Funktionalität beim Kunden vor Ort zu platzieren. Diese Vorteile reichen von der Wirtschaftlichkeit über die Leistung bis hin zur Machbarkeit der zu virtualisierenden Funktionen.

Der erste ETSI NFV ISG-zugelassene öffentliche Multi-Vendor Proof of Concept (PoC) von D-NFV wurde im Juni 2014 von Cyan, Inc. , RAD , Fortinet und Certes Networks in Chicago durchgeführt und von CenturyLink gesponsert . Es basierte auf RADs dedizierter D-NFV-Ausrüstung für Kunden, auf der Fortinets Next Generation Firewall (NGFW) und die virtuelle Verschlüsselungs-/Entschlüsselungs-Engine von Certes Networks als Virtual Network Functions (VNFs) ausgeführt wurden, wobei das Blue Planet-System von Cyan das gesamte Ökosystem orchestrierte. Die D-NFV-Lösung von RAD, eine Layer 2 / Layer 3 Network Termination Unit (NTU), die mit einem D-NFV X86 Servermodul ausgestattet ist, das als Virtualisierungs-Engine am Kundenrand fungiert, wurde Ende des Monats kommerziell verfügbar. Im Jahr 2014 hatte RAD außerdem eine D-NFV Alliance organisiert, ein Ökosystem von Anbietern und internationalen Systemintegratoren, die sich auf neue NFV-Anwendungen spezialisiert haben.

Vorteile der NFV-Modularität

Beim Entwerfen und Entwickeln der Software, die die VNFs bereitstellt, können Anbieter diese Software in Softwarekomponenten strukturieren (Implementierungsansicht einer Softwarearchitektur) und diese Komponenten in ein oder mehrere Images packen (Bereitstellungsansicht einer Softwarearchitektur). Diese herstellerdefinierten Softwarekomponenten werden als VNF-Komponenten (VNFCs) bezeichnet. VNFs werden mit einem oder mehreren VNFCs implementiert und ohne Verlust der Allgemeinheit wird davon ausgegangen, dass VNFC-Instanzen 1:1 auf VM-Images abbilden.

VNFCs sollten im Allgemeinen in der Lage sein, hoch- und/oder hochskalieren zu können . Durch die Möglichkeit, jeder der VNFC-Instanzen flexible (virtuelle) CPUs zuzuordnen, kann die Netzwerkverwaltungsschicht den VNFC hochskalieren (dh vertikal skalieren ), um die Durchsatz-/Leistungs- und Skalierbarkeitserwartungen über ein einzelnes System oder eine einzelne Plattform bereitzustellen. In ähnlicher Weise kann die Netzwerkverwaltungsschicht einen VNFC durch Aktivieren mehrerer Instanzen eines solchen VNFC über mehrere Plattformen skalieren (dh horizontal skalieren ) und daher die Leistungs- und Architekturspezifikationen erreichen, ohne die anderen VNFC-Funktionsstabilitäten zu beeinträchtigen.

Frühe Anwender solcher Architektur-Blaupausen haben die NFV-Modularitätsprinzipien bereits implementiert.

Beziehung zu SDN

SDN oder Software-Defined Networking ist ein Konzept im Zusammenhang mit NFV, aber sie beziehen sich auf verschiedene Domänen. Network Functions Virtualization (NFV) und Deep Packet Inspection (DPI) könnten die SDN-Funktionen effizient ergänzen.

Im Wesentlichen ist Software-Defined Networking (SDN) ein Ansatz zum Aufbau von Datennetzwerkgeräten und -software, die Elemente dieser Systeme trennt und abstrahiert. Dies geschieht durch die Entkopplung von Control Plane und Data Plane voneinander, sodass die Control Plane zentral liegt und die Weiterleitungskomponenten verteilt bleiben. Die Kontrollebene interagiert sowohl in Richtung Norden als auch in Richtung Süden . In Richtung Norden bietet die Steuerungsebene eine allgemeine abstrahierte Ansicht des Netzwerks für Anwendungen und Programme auf höherer Ebene, die APIs verwenden. In Richtung Süden programmiert die Steuerebene das Weiterleitungsverhalten der Datenebene unter Verwendung von APIs auf Geräteebene der im Netzwerk verteilten physischen Netzwerkausrüstung.

Somit ist NFV nicht von SDN oder SDN-Konzepten abhängig. Es ist durchaus möglich, eine virtualisierte Netzwerkfunktion (VNF) als eigenständige Einheit unter Verwendung vorhandener Netzwerk- und Orchestrierungsparadigmen zu implementieren. Die Nutzung von SDN-Konzepten zur Implementierung und Verwaltung einer NFV-Infrastruktur bietet jedoch inhärente Vorteile, insbesondere im Hinblick auf die Verwaltung und Orchestrierung von VNFs. Aus diesem Grund werden herstellerübergreifende Plattformen definiert, die SDN und NFV in abgestimmten Ökosystemen integrieren.

Eine NFV-Infrastruktur benötigt ein zentrales Orchestrierungs- und Managementsystem, das mit einem VNF verbundene Betreiberanfragen entgegennimmt und sie in die geeignete Verarbeitungs-, Speicher- und Netzwerkkonfiguration übersetzt, die für die Inbetriebnahme des VNF erforderlich sind. Im Betrieb muss der VNF ggf. auf Kapazität und Auslastung überwacht und gegebenenfalls angepasst werden.

All diese Funktionen können mithilfe von SDN-Konzepten erreicht werden, und NFV könnte als einer der primären SDN-Anwendungsfälle in Service-Provider-Umgebungen angesehen werden. Es ist auch offensichtlich, dass viele SDN-Anwendungsfälle Konzepte beinhalten könnten, die in die NFV-Initiative eingeführt wurden. Beispiele hierfür sind, dass der zentralisierte Controller eine verteilte Weiterleitungsfunktion steuert, die tatsächlich auch auf vorhandenen Verarbeitungs- oder Routing-Geräten virtualisiert werden könnte.

Auswirkungen auf die Branche

NFV hat sich schon in den Kinderschuhen als beliebter Standard erwiesen. Seine unmittelbaren Anwendungen sind zahlreich, wie zum Beispiel Virtualisierung von mobilen Basisstationen , Platform as a Service (PaaS), Content Delivery Networks (CDN), Festnetzzugang und Heimumgebungen. Der potenzielle Nutzen von NFV wird voraussichtlich erheblich sein. Die Virtualisierung von Netzwerkfunktionen, die auf standardisierter Allzweckhardware bereitgestellt werden, soll die Kapital- und Betriebsausgaben sowie die Service- und Produkteinführungszeiten reduzieren. Viele große Hersteller von Netzwerkgeräten haben die Unterstützung für NFV angekündigt. Dies fiel mit NFV-Ankündigungen von großen Softwareanbietern zusammen, die die NFV-Plattformen bereitstellen, die von Ausrüstungslieferanten zum Bau ihrer NFV-Produkte verwendet werden.

Um jedoch die erwarteten Vorteile der Virtualisierung zu realisieren, verbessern Anbieter von Netzwerkgeräten die IT-Virtualisierungstechnologie, um Attribute der Carrier-Klasse zu integrieren, die für eine hohe Verfügbarkeit , Skalierbarkeit, Leistung und effektive Netzwerkverwaltungsfunktionen erforderlich sind. Um die Gesamtbetriebskosten (TCO) zu minimieren, müssen Carrier-Grade-Features so effizient wie möglich implementiert werden. Dies erfordert, dass NFV-Lösungen redundante Ressourcen effizient nutzen, um eine Verfügbarkeit von fünf Neun (99,999%) und Rechenressourcen zu erreichen, ohne die Vorhersagbarkeit der Leistung zu beeinträchtigen.

Die NFV-Plattform ist die Grundlage für effiziente NFV-Lösungen auf Carrier-Niveau. Es ist eine Softwareplattform, die auf Standard-Multi-Core-Hardware läuft und mit Open-Source-Software erstellt wurde, die Funktionen der Carrier-Klasse enthält. Die Software der NFV-Plattform ist für die dynamische Neuzuweisung von VNFs aufgrund von Ausfällen und Änderungen der Verkehrslast verantwortlich und spielt daher eine wichtige Rolle beim Erreichen einer hohen Verfügbarkeit. Es gibt zahlreiche Initiativen zur Spezifizierung, Ausrichtung und Förderung von NFV-Carrier-Grade-Funktionen wie ETSI NFV Proof of Concept, ATIS Open Platform for NFV Project, Carrier Network Virtualization Awards und verschiedene Anbieter-Ökosysteme.

Der vSwitch, eine Schlüsselkomponente von NFV-Plattformen, ist für die Bereitstellung von Konnektivität sowohl von VM zu VM (zwischen VMs) als auch zwischen VMs und dem externen Netzwerk verantwortlich. Seine Leistung bestimmt sowohl die Bandbreite der VNFs als auch die Kosteneffizienz von NFV-Lösungen. Die Leistung des Standard Open vSwitch (OVS) weist Mängel auf, die behoben werden müssen, um die Anforderungen von NFVI-Lösungen zu erfüllen. Sowohl für die OVS- als auch für die Accelerated Open vSwitch (AVS)-Versionen berichten NFV-Lieferanten über signifikante Leistungsverbesserungen.

Virtualisierung verändert auch die Art und Weise, wie Verfügbarkeit in NFV-Lösungen spezifiziert, gemessen und erreicht wird. Da VNFs traditionelle funktionsbezogene Geräte ersetzen, gibt es eine Verschiebung von der gerätebasierten Verfügbarkeit zu einem servicebasierten, durchgängigen, mehrschichtigen Ansatz. Die Virtualisierung von Netzwerkfunktionen unterbricht die explizite Kopplung mit bestimmten Geräten, daher wird die Verfügbarkeit durch die Verfügbarkeit von VNF-Diensten definiert. Da die NFV-Technologie eine Vielzahl von Netzwerkfunktionstypen mit jeweils eigenen Erwartungen an die Serviceverfügbarkeit virtualisieren kann, sollten NFV-Plattformen eine breite Palette von Fehlertoleranzoptionen unterstützen. Diese Flexibilität ermöglicht es CSPs, ihre NFV-Lösungen zu optimieren, um alle VNF-Verfügbarkeitsanforderungen zu erfüllen.

Management und Orchestrierung (MANO)

ETSI hat bereits darauf hingewiesen, dass ein wichtiger Teil der Steuerung der NFV-Umgebung durch Automatisierung und Orchestrierung erfolgt. Es gibt einen separaten Stream MANO innerhalb von NFV, der umreißt, wie die Flexibilität kontrolliert werden sollte.

ETSI bietet einen vollständigen Satz von Standards, die ein offenes Ökosystem ermöglichen, in dem Virtualized Network Functions (VNFs) mit unabhängig entwickelten Management- und Orchestrierungssystemen interoperabel sein können und in dem die Komponenten eines Management- und Orchestrierungssystems selbst interoperabel sind. Dies umfasst eine Reihe von Restful-API- Spezifikationen sowie die Spezifikationen eines Paketformats für die Bereitstellung von VNFs an Dienstanbieter und der Bereitstellungsvorlagen, die mit den Software-Images gepackt werden müssen, um die Verwaltung des Lebenszyklus von VNFs zu ermöglichen. Bereitstellungsvorlagen können auf TOSCA oder YANG basieren .

Eine OpenAPI-Darstellung (auch bekannt als Swagger) der API-Spezifikationen ist auf dem ETSI-Forge- Server verfügbar , zusammen mit TOSCA- und YANG-Definitionsdateien, die beim Erstellen von Bereitstellungsvorlagen verwendet werden.

Der vollständige Satz veröffentlichter Spezifikationen ist in der folgenden Tabelle zusammengefasst.

Spezifikation Titel
ETSI GS NFV-SOL 001 NFV-Deskriptoren basierend auf der TOSCA-Spezifikation
ETSI GS NFV-SOL 002 RESTful-Protokollspezifikation für den Ve-Vnfm-Referenzpunkt
ETSI GS NFV-SOL 003 RESTful-Protokollspezifikation für den Or-Vnfm-Referenzpunkt
ETSI GS NFV-SOL 004 VNF-Paket- und PNFD-Archivspezifikation
ETSI GS NFV-SOL 005 RESTful-Protokollspezifikation für den Os-Ma-nfvo-Referenzpunkt
ETSI GS NFV-SOL 006 NFV-Deskriptoren basierend auf der YANG-Spezifikation
ETSI GS NFV-SOL 007 Spezifikation der Netzwerk-Service-Deskriptor-Dateistruktur
ETSI GS NFV-SOL 009 RESTful-Protokollspezifikation für die Verwaltung von NFV-MANO
ETSI GS NFV-SOL 010 Spezifikation des VNF-Snapshot-Pakets
ETSI GS NFV-SOL 011 RESTful-Protokollspezifikation für den Or-Or-Referenzpunkt
ETSI GS NFV-SOL 012 RESTful-Protokollspezifikation für die Policy Management-Schnittstelle
ETSI GS NFV-SOL 013 Spezifikation gemeinsamer Aspekte für RESTful NFV MANO APIs
ETSI GS NFV-SOL 014 YAML-Datenmodellspezifikation für deskriptorbasiertes virtualisiertes Ressourcenmanagement
ETSI GS NFV-SOL 015 Spezifikation von Mustern und Konventionen für RESTful NFV-MANO APIs
ETSI GS NFV-SOL 016 NFV-MANO-Verfahrensspezifikation

Eine Übersicht über die verschiedenen Versionen der OpenAPI-Repräsentationen von NFV-MANO-APIs finden Sie im ETSI NFV- Wiki .

Die OpenAPI-Dateien sowie die TOSCA YAML-Definitionsdateien und YANG-Module, die auf NFV-Deskriptoren anwendbar sind, sind auf ETSI Forge verfügbar .

Leistungsstudie

Eine aktuelle Leistungsstudie zu NFV konzentrierte sich auf den Durchsatz, die Latenz und den Jitter von virtualisierten Netzwerkfunktionen (VNFs) sowie die NFV-Skalierbarkeit in Bezug auf die Anzahl der VNFs, die ein einzelner physischer Server unterstützen kann. Open-Source-NFV-Plattformen sind verfügbar, ein Vertreter ist openNetVM. openNetVM ist eine leistungsstarke NFV-Plattform basierend auf DPDK- und Docker-Containern. openNetVM bietet einen flexiblen Rahmen für die Bereitstellung von Netzwerkfunktionen und deren Verbindung zum Aufbau von Serviceketten. openNetVM ist eine Open-Source-Version der NetVM-Plattform, die in den Papieren NSDI 2014 und HotMiddlebox 2016 beschrieben ist und unter der BSD-Lizenz veröffentlicht wird. Den Quellcode finden Sie unter github:openNetVM

Cloud-native Netzwerkfunktionen

Im Jahr 2018 begannen viele Infrastrukturanbieter, viele ihrer VNFs auf eine containerbasierte Architektur zu migrieren. Diese Cloud-nativen Netzwerkfunktionen nutzen viele der gleichen Innovationen, die häufig in der Internetinfrastruktur eingesetzt werden. Dazu gehören die automatische Skalierung, die Unterstützung eines Continuous Delivery-/DevOps-Bereitstellungsmodells und Effizienzsteigerungen durch die gemeinsame Nutzung gemeinsamer Dienste über Plattformen hinweg. Durch Service Discovery und Orchestrierung wird ein auf CNFs basierendes System widerstandsfähiger gegenüber Knotenausfällen. Die Nutzung von Containern und damit der Verzicht auf den Overhead der herkömmlichen Virtualisierung durch den Wegfall des Gastbetriebssystems kann die Ressourceneffizienz erheblich steigern.

Siehe auch

Verweise

Externe Links