-
HINTERGRUND
-
Die Netzwerkfunktionsvirtualisierung (NFV) ist eine Technik zum Abliefern von Kommunikationsdiensten. Insbesondere ist die NFV die Anwendung von Virtualisierungs- und Automatisierungstechniken zum Bereitstellen von Netzwerkdiensten in Netzwerken von Kommunikationsdienstanbietern. Auf diese Weise können Kommunikationsdienstanbieter ihre Kommunikationsnetzwerke aus einer dedizierten Hardware-Infrastruktur in Universalinfrastrukturen umwandeln, welche Netzwerkdienste unter Verwendung von virtualisierten Netzwerkfunktionen (VNFs) bereitstellen. Mit der Netzwerkfunktionsvirtualisierung kann ein Großteil der Hardware eines Kommunikationsnetzwerks durch Software ersetzt werden, welche dieselbe Funktionalität ausübt. Im Vergleich zu Kommunikationsnetzwerken, die einzig mit Hardware-Switches, Routern und dergleichen angewendet werden, können Kommunikationsnetzwerke, welche VNFs einbeziehen, für eine größere Flexibilität und für niedrigere Kosten sorgen und können in der Lage sein, neue Netzwerkdienste in kürzerer Zeit einzubeziehen. Weitere Hintergrundinformationen zum Gebiet der Erfindung sind beispielsweise den Druckschriften
WO 2018/034 663 A1 und
US 2016/0 057 234 A1 zu entnehmen.
-
Figurenliste
-
Die vorliegende Offenbarung ist aus der folgenden detaillierten Beschreibung in Verbindung mit den begleitenden Figuren zu verstehen. Gemäß der branchenüblichen Praxis sind verschiedene Merkmale nicht maßstabsgetreu dargestellt. Tatsächlich können die Abmessungen der verschiedenen Merkmale zugunsten einer klaren Darstellung beliebig vergrößert oder verkleinert sein.
-
Einige Beispiele der vorliegenden Anmeldung werden unter Bezugnahme auf die folgenden Figuren beschrieben:
- 1 ist ein beispielhaftes System zum Erzeugen virtualisierter Netzwerkfunktionen.
- 2 ist ein Datenflussdiagramm eines beispielhaften Systems zum Erzeugen virtualisierter Netzwerkfunktionen.
- 3 ist ein beispielhaftes Verfahren zum Erzeugen virtualisierter Netzwerkfunktionen.
- 4 ist ein beispielhaftes Verfahren zum Erzeugen virtualisierter Netzwerkfunktionen.
- 5 ist ein beispielhaftes System mit einem greifbaren, nicht-flüchtigen computerlesbaren Medium, welches einen Code zum Erzeugen einer virtualisierten Netzwerkfunktion speichert.
-
DETAILLIERTE BESCHREIBUNG
-
Das Europäische Institut für Telekommunikationsnormen (European Telecommunications Standards Institute, ETSI) hat ein Modell für eine NFV-Architektur definiert. Die NFV-Architektur umfasst einen Manager für eine virtualisierte Infrastruktur (VIM), einen Manager für virtualisierte Netzwerkfunktionen (VNFM) und einen Netzwerkfunktions-Virtualisierungsorchestrator (NFVO). Der VIM kann dafür verantwortlich sein, die Rechen-, Speicher- und Netzwerk-Ressourcen zu verwalten, die verwendet werden, um die virtualisierten Netzwerkfunktionen zu erzeugen. Der VFNM kann für die Verwaltung einzelner VNFs verantwortlich sein. Der NFVO kann dafür verantwortlich sein, VNFs und physische Netzwerkfunktionen (PNFs) zu kombinieren, um die Netzwerkdienste zu erzeugen, die von der NVFI bereitgestellt werden. Physische Netzwerkfunktionen können Netzwerkfunktionen sein, welche unter Verwendung von Hardware-Vorrichtungen realisiert werden.
-
Ein VIM, z.B. OpenStack, kann einen NFVO verwenden, der als ein HEAT-Orchestrator bezeichnet wird. In einer beispielhaften Realisierung können HEAT-Orchestrierungsschablonen (HOT-Dateien) verwendet werden, um virtualisierte Netzwerkfunktionen zu definieren. Die HOT-Dateien können in den HEAT-Orchestrator eingegeben werden, um virtualisierte Netzwerkfunktionen zu erzeugen. Allerdings weisen die HOT-Dateien Beschränkungen auf, welche zum Erzeugen virtualisierter Netzwerkfunktionen führen können, welche die Strategien verletzen, die angewendet werden, um deren Standardisierung zu regeln, oder andere VNFs anderweitig negativ beeinflussen. Dementsprechend können Beispiele für die Übersetzung von HOT-Dateien sorgen, um Strategieverletzungen zu verhindern, um die bösartige Verwendung von HOT-Dateien und/oder andere mögliche negative Einflüsse zu verhindern. Beispielsweise können HOT-Dateien die Erzeugung und Verwaltung verschiedener Ressourcen ermöglichen, die in einer VIM-Installation verfügbar sind. Wenn also der HEAT-Orchestrator eine HOT-Datei annimmt, hat der HEAT-Orchestrator möglicherweise keine Kontrolle über die erzeugten Ressourcen. Ein Missbrauch dieser Fähigkeit (entweder bösartig oder versehentlich) kann andere VNFs und virtuelle Maschinen, die auf der VIM-Plattform ablaufen, negativ beeinflussen.
-
1 ist ein beispielhaftes System 100 zum Erzeugen virtualisierter Netzwerkfunktionen. Das System 100 kann einen Dienstanbieter 102, einen VIM 104 und Netzwerkdienste 106 umfassen, die über ein Netzwerk 120 verbunden sind. Der Dienstanbieter 102 kann ein Kommunikationsdienstanbieter sein, welcher seinen Kunden Netzwerkdienste 106 bereitstellt. Die Netzwerkdienste 106 können Kommunikationsdienste sein, wie z.B. E-Mail, Voice-over-Internet-Protocol, Drucken, gemeinsame Nutzung von Daten, Verzeichnisdienste, Video-on-Demand, Videotelefonie und dergleichen. In Beispielen können die Netzwerkdienste 106 aus virtualisierten Netzwerkfunktionen (VNFs) 108 zusammengesetzt sein. Diese VNFs können in einem Beispiel durch HEAT-Orchestrierungsschablonen 110 definiert werden, die dem Dienstanbieter 102 z.B. durch einen Kunden bereitgestellt werden. Die HEAT-Orchestrierungsschablonen 110 können spezielle Ressourcen zum Erzeugen der virtualisierten Netzwerkfunktionen 108 definieren, z.B. virtuelle Maschinen, virtuelle Netzwerke und Ähnliches.
-
Der VIM 104 ist ein Manager für eine virtualisierte Infrastruktur (VIM), welcher eine Wechselwirkung mit der physischen Infrastruktur vermitteln kann, welche eine Netzwerkfunktionsvirtualisierung unterstützt, wobei Komponenten wie eine Cloud-Computing-Netz-Steuerung 112, einen Vernetzungs-Manager 114 und einen HEAT-Orchestrator 116 verwendet werden. Die Cloud-Computing-Netz-Steuerung 112, z.B. Nova, kann Gruppen von Rechenressourcen verwalten. Der Vernetzungs-Manager 114, z.B. Neutron, kann Netzwerke und Internet-Protokoll(IP)-Adressen verwalten. Der HEAT-Orchestrator 116 kann Rufe an die Cloud-Computing-Netz-Steuerung 112, den Vernetzungs-Manager 114 und andere VIM-Dienste koordinieren. Ein NFVO kann die NFV-Infrastrukturkomponenten verwalten, z.B. die virtualisierten Netzwerkfunktionen 108. Ein VNFM kann dabei helfen, die Funktionen der virtuellen Vernetzung zu standardisieren und die Interoperabilität von Software-definierten Vernetzungselementen zu erhöhen. Der HEAT-Orchestrator 116 kann diese Funktionen auf Grundlage der Definitionen ausüben, die in den HEAT-Orchestrierungsschablonen 110 bereitgestellt werden.
-
Die HEAT-Orchestrierungsschablonen 110 können jedoch lediglich NFVI-Komponenten definieren, wie z.B. virtuelle Maschinen und virtuelle Netzwerke. Hingegen können die virtualisierten Netzwerkfunktionen 108 und die Netzwerkdienste 106 einem komplexeren Modell folgen, welches von einem Manager für virtualisierte Netzwerkfunktionen (VNFM) und dem NFVO verwaltet wird. Das Modell, das von dem VNFM und dem HEAT-Orchestrator 116 verwaltet wird, kann der NFVI Beziehungen und Strategien auferlegen, die in den HEAT-Orchestrierungsschablonen 110 nicht definiert sind. Entsprechend kann ein Übersetzer 118 die Informationen aus den HEAT-Orchestrierungsschablonen 110 mit dem Modell des VNFM und des HEAT-Orchestrators 116 vereinigen, um eine übersetzte Version der HEAT-Orchestrierungsschablone 110 zu erzeugen. Die übersetzte HEAT-Orchestrierungsschablone 110 kann in den HEAT-Orchestrator 116 eingegeben werden, um die virtualisierten Netzwerkfunktionen 108 oder die Netzwerkdienste 106 zu erzeugen.
-
Beispielsweise kann ein Kunde dem Dienstanbieter 102 für einen Netzwerkdienst 106 eine HEAT-Orchestrierungsschablone 110 bereitstellen. In einem Beispiel kann der Netzwerkdienst 106 ein Video-on-Demand-Dienst sein. Die HEAT-Orchestrierungsschablone 110 für den Video-on-Demand-Dienst kann mehrere virtualisierte Netzwerkfunktionen 108 definieren. In einem Beispiel können die virtualisierten Netzwerkfunktionen 108 für einen Video-on-Demand-Dienst ein virtuelles Netzwerk mit siebzig virtuellen Maschinen umfassen, wobei jede virtuelle Maschine zwei Zentralprozessoreinheiten (CPUs), Plattenlaufwerke einer Größe von einem Terabyte, Direktzugriffsspeicher (RAM) von acht Gigabyte und vier verbundene Netzwerkanschlüsse umfassen kann. Das Modell für den VNFM und den HEAT-Orchestrator 116 kann jedoch ein rechtmäßiges Abfangen des Datenverkehrs für spezielle virtuelle Maschinen in den virtuellen Netzwerken des Dienstanbieters umfassen. Ein rechtmäßiges Abfangen des Datenverkehrs kann sich darauf beziehen, dass ein Telekommunikationsnetz für einen speziellen Kunden per Gerichtsbeschluss abgehört wird und die Netzwerkkommunikationen für diesen Kunden einer Vollzugsbehörde bereitgestellt werden. Somit kann der Übersetzer 118 in Beispielen eine neue HEAT-Orchestrierungsschablone 110 erzeugen, wobei die virtuellen Maschinen, die in der ursprünglichen HEAT-Orchestrierungsschablone 110 spezifiziert sind, so modifiziert sind, dass sie einen zusätzlichen virtuellen Anschluss für die Verbindung zum rechtmäßigen Abfangen des Datenverkehrs umfassen. Entsprechend kann die übersetzte HEAT-Orchestrierungsschablone 110 in den HEAT-Orchestrator 116 eingegeben werden, um den Video-on-Demand-Dienst zu erzeugen, der von dem Kunden angefordert wird.
-
2 ist ein Datenflussdiagramm eines beispielhaften Systems 200 zum Erzeugen virtualisierter Netzwerkfunktionen. In Beispielen können HOT-Dateien 202 und Zusatzinformationen 204 in ein Aufnahmeverfahren 206 eingegeben werden. Die HOT-Dateien 202 können HEAT-Orchestrierungsschablonen sein, wie z.B. die HEAT-Orchestrierungsschablonen 110, welche virtualisierte Netzwerkfunktionen und Netzwerkdienste definieren, wie z.B. die virtualisierten Netzwerkfunktionen 108 und die Netzwerkdienste 106. Die Zusatzinformationen 204 können Skripte repräsentieren, welche auf virtuellen Maschinen ablaufen können, die in den HOT-Dateien 202 definiert sind. In dem Aufnahmeverfahren 206 können die HOT-Dateien 202 in einzelne Elemente zerlegt werden, wie z.B. virtuelle Maschinen, virtuelle Netzwerke, Anschlüsse und dergleichen, um ein internes Modell 208 zu errichten. Das interne Modell 208 kann die Elemente umfassen, die erzeugt worden wären, wenn die HOT-Dateien 202 und die Zusatzinformationen mit einem Orchestrator eingesetzt worden wären, wie z.B. mit dem HEAT-Orchestrator 116. In einem alternativen Beispiel können in dem Aufnahmeverfahren 206 Eingaben in anderen Formaten als dem HOT-Format der HOT-Dateien 202 akzeptiert werden und es können vorhandene Werkzeuge verwendet werden, um die Eingabe vor einer weiteren Verarbeitung in das HOT-Format umzuwandeln.
-
Das interne Modell 208 kann in ein Übersetzungsverfahren 210 eingegeben werden. Während des Übersetzungsverfahrens 210 kann ein Übersetzer, wie z.B. der Übersetzer 118, die einzelnen Elemente und Beziehungen in dem internen Modell 208 in ein internes Modell des (nicht dargestellten) HEAT-Orchestrators 116 abbilden. Das interne Modell des HEAT-Orchestrators 116 kann vorgeschriebene Parameter für die möglichen VNFs 108 umfassen, die in den HOT-Dateien 202 definiert sein können. Die abgebildeten Elemente und Beziehungen können in einem Satz Orchestratormodellierter Ressourcen 214 aufgezeichnet werden. Die Orchestrator-modellierten Ressourcen 214 können die vorgeschriebenen Elemente aus dem internen Modell des HEAT-Orchestrators 116 auf die einzelnen Elemente der HOT-Dateien 202 anwenden, Wenn keine direkte Abbildung zwischen einem einzelnen Element des internen Modells 208 und dem internen Modell des HEAT-Orchestrators 116 möglich ist, wird das einzelne Element in einen HOT-Schnipsel 212 übersetzt, welcher ein Element ist, das die Einzelheiten des nicht abgebildeten Elements beschreibt und Zeiger auf die Elemente in den anderen HOT-Schnipseln 212 und Orchestrator-modellierten Ressourcen 214 umfasst. In einem alternativen Beispiel können in dem Übersetzungsverfahren 210 zusätzliche Eingaben akzeptiert werden, welche die Übersetzung beeinflussen. Eine beispielhafte zusätzliche Eingabe kann eine Abbildungsdatei sein, welche die Trennung der Ressourcen innerhalb einer komplexen HOT-Datei 202 in separate VNFs 108 leitet.
-
Die HOT-Schnipsel 212 und die Orchestrator-modellierten Ressourcen 214 können in ein Validierungs- und Umwandlungsverfahren 216 eingegeben werden. Während des Validierungs- und Umwandlungsverfahrens 216 kann der HEAT-Orchestrator 116 die Orchestrator-modellierten Ressourcen 214 akzeptieren oder zurückweisen. Alternativ kann der HEAT-Orchestrator 116 automatisch Änderungen anwenden, so dass die Strategien 220 eingehalten werden. Die Strategien 220 können Bedingungen zum Implementieren spezieller Arten von VNFs 108 spezifizieren. Beispielsweise kann eine Strategie 220 spezifizieren, dass für jede virtuelle Maschine, welche Endverbraucher-Datenverkehr verarbeitet, ein zusätzlicher Anschluss hinzugefügt werden kann, der mit dem Netzwerk verbunden ist und für ein rechtmäßiges Abfangen vorgesehen ist.
-
Die HOT-Schnipsel 212 können auch auf Grundlage von Whitelists und Blacklists 218 oder definierten Umwandlungen zurückgewiesen oder akzeptiert werden. Die Whitelists können virtualisierte Netzwerkfunktionen 108 spezifizieren, welche von dem Dienstanbieter 102 zugelassen werden. Im Gegensatz dazu können die Blacklists virtualisierte Netzwerkfunktionen 108 spezifizieren, welche von dem Dienstanbieter 102 verboten werden. Ferner können die HOT-Schnipsel 212, wo eine Automatisierung nicht möglich ist, ein manuelles Zulassungsverfahren 222 durchlaufen, wobei die vollständige HOT-Datei 202 unter Quarantäne gestellt werden kann, bis das manuelle Zulassungsverfahren 222 abgeschlossen ist.
-
Die HOT-Schnipsel 212 und die Orchestrator-modellierten Ressourcen 214, die aus dem Validierungs- und Umwandlungsverfahren 216 ausgegeben werden, können in ein Einarbeitungsverfahren 226 eingegeben werden. Das Einarbeitungsverfahren 226 kann die Erzeugung der VNFs 108 und der Netzwerkdienste 106 umfassen, wie in den HOT-Schnipseln 212 und den Orchestrator-modellierten Ressourcen 214 definiert. Während des Einarbeitungsverfahrens 226 werden die HOT-Schnipsel 212 und die Orchestrator-modellierten Ressourcen 214 mit zusätzlichen Informationen 224 aktualisiert. Die zusätzlichen Informationen 224 sind Informationen, welche die NFVI-Ressourcen ergänzen, die in den HOT-Schnipseln 212 und den Orchestrator-modellierten Ressourcen 214 definiert sind, und ferner die VNFs 108 und die Netzwerkdienste 106 definieren. Die zusätzlichen Informationen können Element-Manager-Skripte, Weiterleitungsgraphen und andere vom Dienstanbieter 102 spezifizierte Ressourcen umfassen, welche von dem Kunden möglicherweise noch nicht in Erwägung gezogen worden sind. Die vollständigen virtualisierten Netzwerkfunktionen 108 und Netzwerkdienste 106, die auf diese Weise modelliert werden, können die HOT-Schnipsel 212 für jene Merkmale zurückhalten, die nicht in dem internen Modell des HEAT-Orchestrators 116 enthalten und akzeptiert sind (entweder automatisch oder durch das manuelle Zulassungsverfahren 222). Das Einarbeitungsverfahren 226 erzeugt VNFs und HOT-Schnipsel 228, welche in das Einsetzungsverfahren 230 eingegeben werden.
-
Während des Einsetzungsverfahrens 230 können die VNFs und die HOT-Schnipsel 228 auf etwaige mögliche Warnungen oder Bestätigungen überprüft werden. Wenn die die VNFs und die HOT-Schnipsel 228 HOT-Schnipsel enthalten, die auf der Blacklist stehen, kann eine Warnung für den Dienstanbieter 102 bereitgestellt werden oder eine Bestätigung von diesem angefordert werden, bevor die VNFs 108 eingesetzt werden. Wenn die VNFs und die HOT-Schnipsel 228 gar keine HOT-Schnipsel umfassen, wird das Einsetzungsverfahren 230 fortgesetzt, wie durch den HEAT-Orchestrator 116 vorgeschrieben. Wenn es HOT-Schnipsel gibt, kann der HEAT-Orchestrator aus den Artefakten in dem internen Modell des HEAT-Orchestrators 116 eine neue HOT-Datei 232 aufbauen und vereinigt diese Artefakte mit den HOT-Schnipseln 212. Der HEAT-Orchestrator 116 des VIM 234 kann dann die VNFs 108 und die Netzwerkdienste 106 entsprechend einsetzen.
-
Alternativ kann der reguläre Mechanismus des HEAT-Orchestrators 116 angewendet werden, auch wenn die VNFs und die Schnipsel 228 HOT-Schnipsel 212 umfassen. Der HEAT-Orchestrator 116 kann dann einen Feststellungs- und Abgleichschritt ausführen, um die Werte der erzeugten VNFs 108 und des Netzwerkdienstes 106 zu erhalten. Außerdem kann über den HEAT-Orchestrator 116 eine HEAT-Orchestrierungsschablone 110 bereitgestellt werden, welche nur die HOT-Schnipsel 212 enthält.
-
In einem anderen Beispiel können im Validierungs- und Umwandlungsverfahren 216 HOT-Schnipsel 212 als unter Quarantäne stehend markiert werden. Somit können die unter Quarantäne stehenden HOT-Schnipsel in dem Einsetzungsverfahren 230 einem anderen Manager für eine virtualisierte Infrastruktur bereitgestellt werden, so dass die VNF 108, die durch den unter Quarantäne stehenden HOT-Schnipsel 212 definiert wird, zur Verifikation überwacht werden kann. Die Verifikation kann beispielsweise das Sicherstellen umfassen, dass der unter Quarantäne stehende HOT-Schnipsel keine Strategien 220 verletzt.
-
Vorteilhafterweise ermöglicht das Vereinigen der Informationen aus den HEAT-Orchestrierungsschablonen 110 mit dem internen Modell des NFVO die Instanziierung anderer VIMs, welche nicht den HEAT-Orchestrator 116 verwenden. Ferner können Elemente, die wiederholt in mehreren HEAT-Orchestrierungsschablonen 110 beschrieben werden, wie z.B. Varianten, in gemeinsam genutzte Ressourcen umgewandelt werden, basierend auf spezifizierten Strategien 220 und zusätzlichen Informationen 224. Durch eine Variante kann die Rechen-, Speicher- und Speicherungskapazität eines virtuellen Servers definiert werden. Zusätzlich wird durch dieses Vereinigen dem Dienstanbieter ermöglicht, spezielle HEAT-Merkmale auf die Blacklist zu setzen, beispielsweise aufgrund von Sicherheitsregulierungen. Außerdem macht es das Vereinigen auf diese Weise möglich, Strategien durchzusetzen und zu realisieren. Beispielsweise kann der Dienstanbieter 102 eine Strategie realisieren, durch welche jede virtuelle Maschine mit mindestens einer Verbindung zu einem Sicherungsnetzwerk versehen wird. In einem anderen Beispiel kann eine Strategie für Beschränkungen für Masken zulässiger Netzwerkadressen durchgesetzt werden, um Probleme bei der IPV4-Adressraumeinsparung abzumildern.
-
3 ist ein beispielhaftes Verfahren 300 zum Erzeugen virtualisierter Netzwerkfunktionen. Das Verfahren 300 kann durch einen NFVO, z.B. den HEAT-Orchestrator 116, und einen Übersetzer, z.B. den Übersetzer 118, durchgeführt werden. Im Block 302 kann der Übersetzer 118 ein internes Modell virtualisierter Netzwerkfunktionen 108 aufbauen, welches auf den HEAT-Orchestrierungsschablonen 110 basiert.
-
Im Block 304 kann der Übersetzer 118 die Elemente und die Beziehungen des internen Modells, das durch den Übersetzer 118 aufgebaut wird, auf ein internes Modell des HEAT-Orchestrators 116 abbilden. Die Elemente und die Beziehungen des internen Modells, das durch den Übersetzer 118 aufgebaut wird, die nicht auf das interne Modell des HEAT-Orchestrators 116 abgebildet werden können, können in HOT-Schnipsel übersetzt werden, z.B. in die HOT-Schnipsel 212. Die HOT-Schnipsel 212 können Einzelheiten der Elemente und Zeiger auf verwandte Elemente beschreiben.
-
Im Block 306 kann der HEAT-Orchestrator 116 die Abbildung validieren und umwandeln. Mit anderen Worten, der HEAT-Orchestrator 116 kann Änderungen an den Elementen und Beziehungen, die auf das interne Modell des HEAT-Orchestrators 116 abgebildet werden, akzeptieren, zurückweisen oder automatisch anwenden. Auf diese Weise können Strategien durchgesetzt werden. Beispielsweise könnte eine Strategie in Bezug auf eine Lizenzierung besagen „die Organisation X kann nicht mehr als Y gleichzeitig ablaufende virtuelle Maschinen einsetzen, die das Bild Z verwenden“. In Beispielen kann eine solche Strategie nur durchgesetzt werden, indem die einzusetzende Datei und alle zuvor eingesetzten Dateien betrachtet werden. Außerdem kann der HEAT-Orchestrator 116 die HOT-Schnipsel 212 auf Grundlage von Whitelists und Blacklists, z.B. den Whitelists und Blacklists 218, akzeptieren oder zurückweisen. Alternativ können die HOT-Schnipsel 212 unter Quarantäne gestellt werden, bevor ein manuelles Zulassungsverfahren realisiert wird.
-
Im Block 308 kann der HEAT-Orchestrator 116 die abgebildeten Elemente und Beziehungen mit zusätzlichen Informationen ergänzen, z.B. mit Element-Manager-Skripten, Weiterleitungsgraphen und Ähnlichem. Im Block 310 kann der HEAT-Orchestrator 116 Warnungen für alle HOT-Schnipsel 212 erzeugen, die auf der Blacklist stehen. Im Block 312 kann der HEAT-Orchestrator 116 für alle HOT-Schnipsel 212, die auf der Whitelist stehen, eine neue HOT-Datei 232 erzeugen, welche die auf der Whitelist stehenden HOT-Schnipsel mit den Elementen vereinigt, die auf die internen Modelle abgebildet sind.
-
Im Block 314 kann der HEAT-Orchestrator 116 die neuen virtualisierten Netzwerkfunktionen 108 und Netzwerkdienste 106 erzeugen, die in den neu erzeugten HEAT-Orchestrierungsschablonen 110 beschrieben sind.
-
Es versteht sich, dass der Verfahrensablaufplan der 3 nicht anzeigen soll, dass das Verfahren 300 in jedem Fall alle in 3 dargestellten Blöcke umfassen muss. Ferner kann in das Verfahren 300 in Abhängigkeit von den Einzelheiten der speziellen Realisierung eine beliebige Anzahl an zusätzlichen Blöcken einbezogen werden. Außerdem versteht es sich, dass der Verfahrensablaufplan der 3 nicht anzeigen soll, dass das Verfahren 300 in jedem Fall in der Reihenfolge ablaufen muss, die durch die Blöcke angezeigt wird, die in 3 dargestellt sind. Beispielsweise kann der Block 304 derart neu angeordnet werden, dass er vor dem Block 302 liegt.
-
4 ist ein beispielhaftes Verfahren 400 zum Erzeugen virtualisierter Netzwerkfunktionen. Das Verfahren 400 kann durch einen NFVO, z.B. den HEAT-Orchestrator 116, und einen Übersetzer, z.B. den Übersetzer 118, durchgeführt werden. Im Block 402 kann der HEAT-Orchestrator 116 basierend auf einem Netzwerkfunktions-Virtualisierungsmodell abbildbare Elemente und nicht-abbildbare Elemente einer Schablone einer virtualisierten Netzwerkfunktion identifizieren. Die Schablone der virtualisierten Netzwerkfunktion kann beispielsweise HEAT-Orchestrierungsschablonen 110 umfassen.
-
Im Block 404 kann der HEAT-Orchestrator 116 die abbildbaren Elemente auf das Netzwerkfunktions-Virtualisierungsmodell abbilden. Im Block 406 kann der Übersetzer 118 die abbildbaren Elemente basierend auf der Abbildung übersetzen, um ein oder mehrere übersetzte Elemente zu erzeugen. Wie bereits angegeben, kann der Übersetzer 118 die einzelnen Elemente und Beziehungen in dem internen Modell 208 auf ein internes Modell des HEAT-Orchestrators 116 abbilden. Die abgebildeten Elemente und Beziehungen können in den Orchestrator-modellierten Ressourcen 214 aufgezeichnet werden, welche vorgeschriebene Elemente aus dem internen Modell 208 auf die einzelnen Elemente der HOT-Dateien 202 anwenden können. Außerdem erzeugt der Übersetzer 118 die HOT-Schnipsel 212, wenn es keine direkte Abbildung zwischen einem Element des internen Modells 208 und dem internen Modell des HEAT-Orchestrators 116 gibt.
-
Im Block 408 kann der Übersetzer 118 die nicht-abbildbaren Elemente basierend auf einer Blacklist-Whitelist filtern, um ein oder mehrere gefilterte Elemente zu erzeugen. Beispielsweise kann der Übersetzer 118 einen Filter wie die Whitelist-Blacklist 218 verwenden.
-
Im Block 410 kann der HEAT-Orchestrator 116 eine Definition einer übersetzten virtualisierten Netzwerkfunktion erzeugen, welche die übersetzten Elemente und die gefilterten Elemente umfasst. Die Definition der übersetzten virtualisierten Netzwerkfunktion kann beispielsweise die neue HOT-Datei 232 umfassen. Im Block 412 kann der HEAT-Orchestrator 116 basierend auf der Definition der übersetzten virtualisierten Netzwerkfunktion die virtualisierte Netzwerkfunktion erzeugen.
-
Es versteht sich, dass der Verfahrensablaufplan der 4 nicht anzeigen soll, dass das Verfahren 400 in jedem Fall alle in 4 dargestellten Blöcke umfassen muss. Ferner kann in das Verfahren 400 in Abhängigkeit von den Einzelheiten der speziellen Realisierung eine beliebige Anzahl an zusätzlichen Blöcken einbezogen werden. Außerdem versteht es sich, dass der Verfahrensablaufplan der 4 nicht anzeigen soll, dass das Verfahren 400 in jedem Fall in der Reihenfolge ablaufen muss, die durch die Blöcke angezeigt wird, die in 4 dargestellt sind. Beispielsweise kann der Block 404 derart neu angeordnet werden, dass er vor dem Block 402 liegt.
-
5 ist ein beispielhaftes System 500, welches ein greifbares, nicht-flüchtiges computerlesbares Medium 506 aufweist, das Code zum Erzeugen einer virtualisierten Netzwerkfunktion speichert. Das greifbare, nicht-flüchtige computerlesbare Medium ist allgemein durch die Bezugszahl 506 gekennzeichnet. Das greifbare, nicht-flüchtige computerlesbare Medium 506 kann einem beliebigen typischen Computerspeicher entsprechen, welcher computerimplementierte Befehle speichert, z.B. Programmiercode oder Ähnliches. Beispielsweise kann das greifbare, nicht-flüchtige computerlesbare Medium 506 RAM, ROM, EEPROM, CD-ROM oder einen anderen optischen Plattenspeicher, einen Magnetplattenspeicher oder andere Magnetspeichervorrichtungen oder ein beliebiges anderes Medium umfassen, welches verwendet werden kann, um gewünschten Programmcode in der Form von Befehlen oder Datenstrukturen zu tragen oder zu speichern, und auf welches durch einen Computer zugegriffen werden kann. Platte und Disc, wie hierin verwendet, umfasst eine Compact Disc (CD), eine Laser-Disc, eine optische Disc, eine Digital Versatile Disc (DVD), eine Diskette und eine Blu-ray® Disc, wobei Platten Daten gewöhnlich magnetisch reproduzieren, während Discs Daten optisch mit Lasern reproduzieren.
-
Auf das greifbare, nicht-flüchtige computerlesbare Medium 506 kann durch einen Prozessor 502 über einen Computer-Bus 504 zugegriffen werden. In einer Zone 508 des greifbaren, nicht-flüchtigen computerlesbaren Mediums werden computerausführbare Befehle gespeichert, welche basierend auf einem Netzwerkfunktions-Virtualisierungsmodell abbildbare Elemente und nicht-abbildbare Elemente einer Schablone einer virtualisierten Netzwerkfunktion identifizieren. In einer Zone 510 des greifbaren, nicht-flüchtigen computerlesbaren Mediums werden computerausführbare Befehle gespeichert, welche die abbildbaren Elemente auf das Netzwerkfunktions-Virtualisierungsmodell abbilden. In einer Zone 512 des greifbaren, nicht-flüchtigen computerlesbaren Mediums werden computerausführbare Befehle gespeichert, welche die abbildbaren Elemente basierend auf der Abbildung übersetzen, um ein oder mehrere übersetzte Elemente zu erzeugen. In einer Zone 514 des greifbaren, nicht-flüchtigen computerlesbaren Mediums werden computerausführbare Befehle gespeichert, welche die nicht-abbildbaren Elemente basierend auf einer Blacklist-Whitelist filtern, um ein oder mehrere gefilterte Elemente zu erzeugen. In einer Zone 516 des greifbaren, nicht-flüchtigen computerlesbaren Mediums werden computerausführbare Befehle gespeichert, welche eine Definition einer übersetzten virtualisierten Netzwerkfunktion erzeugen, welche die übersetzten Elemente und die gefilterten Elemente umfasst. In einer Zone 518 des greifbaren, nicht-flüchtigen computerlesbaren Mediums werden computerausführbare Befehle gespeichert, welche basierend auf der Definition der übersetzten virtualisierten Netzwerkfunktion die virtualisierte Netzwerkfunktion erzeugen.
-
Obwohl als zusammenhängende Blöcke dargestellt, können die Software-Komponenten in einer beliebigen Reihenfolge oder Konfiguration gespeichert werden. Wenn beispielsweise das greifbare, nicht-flüchtige computerlesbare Medium 506 ein Festplattenlaufwerk ist, können die Software-Komponenten in nichtzusammenhängenden oder sogar überlappenden Sektoren gespeichert werden.
-
In der vorstehenden Beschreibung wird zu Erläuterungszwecken eine spezielle Nomenklatur verwendet, um für ein gründliches Verständnis der Offenbarung zu sorgen. Dem Fachmann ist jedoch ersichtlich, dass die speziellen Einzelheiten nicht erforderlich sind, um die hierin beschriebenen Systeme und Verfahren auszuführen. Die vorstehenden Beschreibungen spezieller Beispiele werden zu Zwecken der Veranschaulichung und der Beschreibung gegeben. Sie sollen nicht erschöpfend sein oder die vorliegende Offenbarung auf die genauen beschriebenen Formen beschränken. Natürlich sind hinsichtlich der obigen Lehren viele Modifikationen und Variationen möglich. Die Beispiele werden so dargestellt und beschrieben, dass die Prinzipien der vorliegenden Offenbarung und deren praktische Anwendungen bestmöglich erläutert werden, um dadurch anderen Fachleuten zu ermöglichen, die vorliegende Offenbarung und verschiedene Beispiele mit verschiedenen Modifikationen, wie sie für die spezielle vorgesehene Verwendung geeignet sind, bestmöglich zu verwenden. Der Umfang der vorliegenden Offenbarung soll durch die nachstehenden Patentansprüche und deren Äquivalente definiert werden.
