DE102018214007A1 - Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken - Google Patents

Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken Download PDF

Info

Publication number
DE102018214007A1
DE102018214007A1 DE102018214007.3A DE102018214007A DE102018214007A1 DE 102018214007 A1 DE102018214007 A1 DE 102018214007A1 DE 102018214007 A DE102018214007 A DE 102018214007A DE 102018214007 A1 DE102018214007 A1 DE 102018214007A1
Authority
DE
Germany
Prior art keywords
message
transitory computer
network
ibf
orchestrator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102018214007.3A
Other languages
English (en)
Inventor
Timothy Verrall
Chris Macnamara
John Browne
Michael McGrath
Sean Harte
Maryam Tahhan
Jonathan Kenny
Kevin Devey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102018214007A1 publication Critical patent/DE102018214007A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0873—Checking configuration conflicts between network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0886—Fully automatic configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Automation & Control Theory (AREA)

Abstract

Eine Rechnervorrichtung, die Folgendes umfasst: eine Hardwareplattform; und eine Interworking-Broker-Funktion (IBF), die auf der Hardwareplattform gehostet ist, wobei die IBF einen Übersetzungstreiber (TD) umfasst, der einer Altnetzwerkvorrichtung zugeordnet ist, die keine native Interoperabilität mit einem Orchestrator aufweist, und die IBF konfiguriert ist, um: vom Orchestrator einen Netzwerkfunktionsbereitstellungs- oder -konfigurationsbefehl für die Altnetzwerkvorrichtung zu empfangen; den TD zu betreiben, um den Befehl in ein von der Altnetzwerkvorrichtung aufnehmbares Format zu übersetzen; und den Befehl an die Altnetzwerkvorrichtung weiterzuleiten.

Description

  • Fachgebiet der Beschreibung
  • Diese Offenbarung betrifft im Allgemeinen das Gebiet der Netzwerkdienste und insbesondere, jedoch nicht ausschließlich, ein System und Verfahren für das Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken.
  • Hintergrund
  • In manchen modernen Rechenzentren kann die Funktion eines Geräts oder einer Vorrichtung nicht unbedingt an eine spezifische, feste Hardwarekonfiguration gebunden sein. Stattdessen können Verarbeitungs-, Arbeitsspeicher-, Speicher- und Beschleunigungsfunktionen in manchen Fällen aus unterschiedlichen Orten zusammengesetzt sein, um einen virtuellen „Verbundknoten“ zu bilden. Ein modernes Netzwerk kann ein Rechenzentrum umfassen, das eine große Anzahl generischer Hardware-Server-Vorrichtungen hostet, die beispielsweise in einem Server-Rack enthalten sind und von einem Hypervisor gesteuert werden. Jede Hardwarevorrichtung kann auf einer oder mehreren Instanzen eines virtuellen Geräts, wie einem Workload-Server oder einem virtuellen Desktop, laufen.
  • Figurenliste
  • Die vorliegende Offenbarung wird aus der folgenden detaillierten Beschreibung am besten verstanden, wenn sie mit den beiliegenden Figuren gelesen wird. Es wird betont, dass zahlreiche Elemente, in Übereinstimmung mit den Standardpraktiken in der Branche, nicht zwingenderweise maßstabsgetreu gezeichnet sind und lediglich für illustrative Zwecke genutzt werden. Wenn ein Maßstab angeführt wird, sei es explizit oder implizit, stellt er lediglich ein illustratives Beispiel dar. In anderen Ausführungsformen können die Dimensionen der zahlreichen Elemente, zum Zwecke der Klarheit, willkürlich erhöht oder verringert werden.
    • 1 ist ein Blockdiagramm ausgewählter Komponenten eines Rechenzentrums mit Netzwerkverbindung gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung.
    • 2 ist ein Blockdiagramm eines heterogenen Netzwerks gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung.
    • 3 ist ein Blockdiagramm eines Software-definierten Netzwerks gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung.
    • 4 ist ein Blockdiagramm, in dem eine Netzwerkfunktionsvirtualisierungs- (NFV-) Architektur, gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung, dargestellt wird.
    • 5 ist ein Blockdiagramm eines Rechenzentrums, gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung, das sowohl virtualisierte Rechnerressourcen als auch Altvorrichtungen umfasst.
    • 6 ist ein Blockdiagramm, gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung, in dem die Kommunikation zwischen einem Orchestrator und Altvorrichtungen dargestellt wird.
    • 7 ist ein Blockdiagramm in dem eine Dienstkette, die sowohl virtualisierte Funktionen als auch eine Altvorrichtung umfasst, gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung, dargestellt wird.
    • 8 ist ein Flussdiagramm eines Verfahrens zur Entdeckung von Altvorrichtungen in einem orchestrierten Netzwerk gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung. Ausführungsformen der Offenbarung
  • Die folgende Offenbarung stellt viele verschiedene Ausführungsformen oder Beispiele bereit, um unterschiedliche Elemente der vorliegenden Offenbarung zu implementieren. Spezifische Beispiele für Komponenten und Anordnungen werden im Folgenden beschrieben, um die vorliegende Offenbarung zu vereinfachen. Diese stellen selbstverständlich reine Beispiele dar und sind nicht einschränkend gedacht. Ferner können Bezugszahlen und/oder -buchstaben in den unterschiedlichen Beispielen in der vorliegenden Offenbarung wiederholt werden. Diese Wiederholung dient der Einfachheit und Klarheit und gibt an sich keinen Zusammenhang zwischen den zahlreichen besprochenen Ausführungsformen und/oder Konfigurationen vor. Unterschiedliche Ausführungsformen können unterschiedliche Vorteile aufweisen, wobei kein spezieller Vorteil zwingenderweise von einer beliebigen Ausführungsform erfordert wird.
  • Die Migration und das Nachrüsten von Rechenzentren wie jenen, die von Internet-Service-Providern (ISPs) oder anderen Service-Providern wie Cloud-Service-Providern (CSPs), Software-as-a-Service, Infrastructure-as-a-Service, Unternehmensnetzwerken oder anderen Netzwerktypen betrieben werden, ist in der Regel ein inkrementeller oder gradueller Prozess. Bestehende Netzwerkfunktionen können solange beibehalten werden, solange sie die Anforderungen des Unternehmens erfüllen. Da viele Unternehmen große Kapitalaufwendungen in ihre Rechnerressourcen investiert haben, ist es finanziell nicht praktikabel, ein Rechenzentrum oder ein anderes Unternehmensnetzwerk auf einmal zu überholen und/oder vollständig zu ersetzen.
  • Das führt zu einer Situation, in der Netzwerke in einer heterogenen Form bestehen können. Beispielsweise kann ein Unternehmen Kapitalaufwände in Althardware-Switches und Hardwarevorrichtungen wie Firewalls, Router, E-Mail-Scanner, Spam-Filtervorrichtungen oder andere physische Vorrichtungen investiert haben. Wie durchgehend in dieser Beschreibung genutzt, kann sich eine „Vorrichtung“ auf eine beliebige diskrete oder virtuelle Netzwerkvorrichtung beziehen, die für die Bereitstellung von einem oder mehreren Netzwerkdiensten konfiguriert sein kann.
  • In einem Altnetzwerk können diese Vorrichtungen in einer physischen Dienstkette verbunden worden sein, wobei eine Zwischenverbindung, zum Beispiel in Form eines physischen Schalters, bereitgestellt wurde. Jede Vorrichtung kann eine Konfigurationsschnittstelle umfassen, wie beispielsweise eine Kommandozeilenschnittstelle, auf die über einen sicheren Shell-Terminal zugegriffen werden kann, oder eine webbasierte graphische Benutzerschnittstelle (GUI), die Befehle in ein Format wie der Extensible Markup Language (XML) oder JavaScript Object Notation (JSON) formatiert.
  • Wenn sich die Bedürfnisse des Unternehmens weiterentwickeln, können bestimmte Elemente der bestehenden Altinfrastruktur migriert oder ersetzt werden. Ein aktueller Trend stellt die Verwendung von Software-definiertem Netzwerken (SDN) mit Netzwerkfunktionsvirtualisierung (NFV) und das Bereitstellen von virtualisierten Vorrichtungen dar, die aus der Ferne über eine einzelne vereinigte Schnittstelle von einem Management- und-Orchestrierungs-(MANO-) Stapel verwaltet werden können. Anstelle, dass der Netzwerkadministrator manuell eine große Anzahl physischer Altvorrichtungen über ein Kommandozeilen-Argument (CLA) verwaltet, kann ein Administrator somit eine MANO-Schnittstelle nutzen, um eine große Anzahl von Unternehmensressourcen mit weitaus weniger Einzelaufwand graphisch zu allozieren und zu verwalten.
  • Wie jedoch bereits angemerkt, kann es sich bei der Migration eines Unternehmens um einen graduellen Prozess handeln. Das kann zu einer Situation führen, in der das Unternehmen, wie ein ISP, Server-Racks oder -Einschübe aufweisen kann, die dynamisch allozierte Computerressourcen für NFV bereitstellen, während andere Netzwerkfunktionen weiterhin von Altvorrichtungen, wie Hardwarevorrichtungen, bereitgestellt werden.
  • In so einer heterogenen Umgebung ist es von Vorteil einen Mechanismus für den Systemadministrator bereitzustellen, um sowohl die modernen virtualisierten Funktionen als auch die Alt- oder Hardwarebasierten Netzwerkfunktionen über eine einzige Schnittstelle zu verwalten. Das Unternehmen kann somit seine Kapitalaufwendungen für Altprodukte maximieren, während praktischerweise ein Verfahren für den Netzwerkadministrator bereitgestellt wird, um diese Altvorrichtungen zu verwalten und zu behandeln, als ob es sich dabei in vielerlei Hinsicht um aktuelle virtuelle Netzwerkfunktionen (VNFs) handeln würde.
  • Die vorliegende Beschreibung beschreibt ein System und Verfahren für das Einbinden von Altnetzwerkvorrichtungen, die keine native Interoperabilität mit einem Orchestrator aufweisen, in NFV- und/oder SDN-Infrastrukturen, ohne die Altsysteme zu modifizieren, einschließlich Altverwaltungs- und -telemetriesysteme. Dadurch wird ermöglicht, dass die NFV und/oder SDN über Kenntnis über die Konfiguration der Altvorrichtungen und der Alttelemetrie verfügen, wodurch NFV die Altsysteme unterstützen und verwalten kann, als ob es sich dabei um NFV-Vorrichtungen handeln würde. In manchen Ausführungsformen können Altnetzwerkfunktionen verwaltet werden, als ob sie in jeder Hinsicht NFVs wären, außer bei der Fähigkeit, Instanzen der Vorrichtung dynamisch zu erzeugen oder zu beenden, da diese Instanzen in Hardware vorliegen.
  • Dadurch können Unternehmen mit großen Investitionen in Altvorrichtungen nahtlos NFV und SDN einführen, während die Einbindung mit diesen Altsystemen beibehalten wird. Vorteilhafterweise kann das mit geringeren Verwaltungsdaten als bei anderen Systemen, die auf Überbrückungstechniken bauen, erzielt werden.
  • Beispielsweise kann MANO einen virtuellen Infrastrukturmanager (VIM), wie OpenStack o.ä., umfassen. Eine Interworking-Broker-Funktion (IBF) kann bereitgestellt werden, um Altnetzwerkfunktionen nahtlos in die MANO-Konfigurationstools einzubinden. Bei dem IBF kann es sich um einen Prozess handeln, der nativ auf Bare-Metal, im VIM oder als virtuelle Maschine oder Container an sich, gemäß den Anforderungen der unterschiedlichen Ausführungsformen, laufen kann.
  • In einem Beispiel scannt die IBF das Netzwerk im Hinblick auf Altvorrichtungen oder Vorrichtungen mithilfe von IP-Ermittlungs-Standardverfahren, um zu ermitteln, welche Altvorrichtungen im Netzwerk vorhanden sind. Die IBF kann diese Altvorrichtungen dann über ein bekanntes Protokoll abfragen, bei dem es sich vorteilhafterweise um ein bestehendes und standardisiertes Protokoll, wie ein Simple Network Management Protocol (SNMP) handeln kann. SNMP stellt eine Fähigkeit bereit, eine baumähnliche Struktur „abzugehen“, um verfügbare Server und Netzwerkfunktionen zu ermitteln. Mithilfe der SNMP-Abfrage kann die IBF den Typ der Verwaltungsinformationsdatenbank (MIB) für jede bestehende Altnetzwerkfunktion ermitteln.
  • Die IBF kann die Altvorrichtung dann einer IBF-Instanz zuordnen und eine spezifische Interworking-Broker-Funktion bauen, die MANO-Befehle in für die Altvorrichtung geeignete Befehle übersetzt. Ist die Altvorrichtung einmal einer IBF-Instanz mit einem geeigneten Übersetzungstreiber (TD) für diese Altvorrichtung zugeordnet, kann die IBF der MANO die Verfügbarkeit der Altnetzwerkvorrichtung übermitteln und verfügbare Funktionen, unter Verwendung von beispielsweise einem erweiterten Network Service Descriptor (NSD), anzeigen.
  • Die IBF kann ferner konfiguriert sein, um eine Altnetzwerkvorrichtung im Hinblick auf Leistungsfähigkeitsinformation oder ein Messaging-Format abzufragen und den TD basierend auf der Leistungsfähigkeitsinformation oder dem Messaging-Format zu bauen. Der TD, der für die Altvorrichtung oder die Klasse der Altvorrichtung spezifisch ist, kann der MANO ermöglichen, die Altvorrichtungen so zu betreiben, verwalten und orchestrieren, als ob sie VNFs wären.
  • Ein System und Verfahren für das Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken wird im Folgenden mit speziellerem Bezug auf die beiliegenden FIGUREN beschrieben. Es gilt anzumerken, dass bestimmte Bezugszahlen in den FIGUREN wiederholt werden können, um anzuzeigen, dass eine bestimmte Vorrichtung oder ein Block zur Gänze oder im Wesentlichen in allen FIGUREN einheitlich ist. Damit soll jedoch kein bestimmter Zusammenhang zwischen den verschiedenen offenbarten Ausführungsformen impliziert werden. In bestimmten Beispielen kann eine Gattung eines bestimmten Elements durch eine bestimmte Bezugszahl bezeichnet werden („Steuerelement 10“), während einzelne Ausformungen oder Beispiele der Gattung können durch eine durch einen Bindestrich beigefügte Zahl bezeichnet werden („erstes spezifisches Steuerelement 10-1“ und „zweites spezifisches Steuerelement 10-2“).
  • 1 ist ein Blockdiagramm ausgewählter Komponenten eines Rechenzentrums mit Verbindung zu Netzwerk 100 eines Internet-Service-Providers (ISP) 102, gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Bei ISP 102 kann es sich, als nichteinschränkendes Beispiel, um ein Unternehmensnetzwerk, einen Cloud-Service-Provider oder ein beliebiges anderes Netzwerk, das Dienste bereitstellt, wie z.B. Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS), handeln.
  • ISP 102 kann eine Anzahl von Workload-Clustern 118 bereitstellen, bei denen es sich um Cluster aus einzelnen Servern, Bladeservern, Rack-Servern oder einer anderen beliebigen geeigneten Servertopologie handeln kann. In diesem illustrativen Beispiel werden zwei Workload-Cluster, 118-1 und 118-2 gezeigt, wobei jeder Rack-Server 146 in einem Gehäuse 148 bereitstellt ist.
  • In dieser Darstellung werden Workload-Cluster 118 als modulare Workload-Cluster gezeigt, die dem Rack-Einheits- („U“-) Standard entsprechen, in der ein 19 Zoll breites Standard-Rack gebaut sein kann, um 42 Einheiten (42U) aufzunehmen, wobei jede Einheit 1,75 Zoll hoch und etwa 36 Zoll tief ist. In diesem Fall können Rechnerressourcen, wie Prozessoren, Arbeitsspeicher, Speicher, Beschleuniger und Switches in mehrere Rack-Einheiten von eins bis 42 passen.
  • Jeder Server 146 kann ein eigenständiges Betriebssystem hosten und eine Serverfunktion bereitstellen oder die Server können virtualisiert werden, wobei sie unter Kontrolle eines Virtuellen-Maschinen-Managers (VMM), Hypervisors und/oder Orchestrators stehen können und eine oder mehrere virtuelle Maschinen, virtuelle Server oder virtuelle Vorrichtungen hosten können. Diese Server-Racks können in einem einzigen Rechenzentrum zusammengestellt sein oder sich in Rechenzentren an unterschiedlichen geographischen Orten befinden. Je nach Vertragsvereinbarungen können manche Server 146 spezifisch bestimmten Unternehmensklienten oder -mandanten dediziert sein, während andere geteilt werden.
  • Die unterschiedlichen Vorrichtungen in einem Rechenzentrum können miteinander über eine Switching Fabric 170 verbunden sein, die eine oder mehrere Hochgeschwindigkeits-Router- und/oder -Switching-Vorrichtungen umfasst. Switching Fabric 170 kann sowohl „Nord-Süd“-Datenverkehr (z.B. Datenverkehr von und zu einem Wide Area Network (WAN), wie dem Internet) und „Ost-West“-Datenverkehr (z.B. Datenverkehr über das Rechenzentrum) bereitstellen. Früher machte der Nord-Süd-Datenverkehr den Großteil des Netzwerkdatenverkehrs aus, jedoch nahm mit den komplexer werdenden und weiter verteilten Webdiensten die Menge des Ost-West-Datenverkehrs zu. In vielen Rechenzentren ist nun Ost-West-Datenverkehr für den Großteil des Datenverkehrs verantwortlich.
  • Da außerdem die Leistungsfähigkeit jedes Servers 146 zunimmt, kann auch die Datenverkehrsmenge weiter zunehmen. Beispielsweise kann jeder Server 146 mehrere Prozessorsteckplätze bereitstellen, wobei jeder Schlitz einen Prozessor mit vier bis acht Kernen zusammen mit ausreichend Speicher für die Kerne aufnehmen kann. Somit kann ein Server eine Reihe von VMs hosten, die jede ihr eigenes Datenaufkommen generiert.
  • Um mit der großen Menge an Datenaufkommen in einem Rechenzentrum umgehen zu können, kann eine hochleistungsfähige Switching Fabric 170 bereitgestellt werden. Switching Fabric 170 wird in diesem Beispiel als „flaches“ Netzwerk dargestellt, in dem jeder Server 146 eine direkte Verbindung zu einem Top-of-Rack- (ToR-) Switch 120 aufweisen kann (z.B. eine „Stern“-Konfiguration) und jeder ToR-Switch 120 mit einem Kernswitch 130 verbunden sein kann. Diese zweistufige flache Netzwerkarchitektur wird lediglich als illustratives Beispiel gezeigt. In anderen Beispielen können andere Architekturen genutzt werden, wie z.B. ein dreistufiger Stern oder Leaf-Spine (auch „Fat Tree“-Topologien genannt), die auf der „Clos“-Architektur basieren, Hub-and-Spoke-Topologien, Mesh-Topologien, Ringtopologien oder 3D-Mesh-Topologien, um nichteinschränkende Beispiele zu nennen.
  • Die Fabric selbst kann durch sämtliche geeignete Zwischenverbindungen bereitgestellt werden. Beispielsweise kann jeder Server 146 eine Host-Fabric-Schnittstelle (HFI) von Intel®, eine Netzwerkschnittstellenkarte (NIC) oder eine andere Host-Schnittstelle umfassen. Die Host-Schnittstelle selbst kann mit einem oder mehreren Prozessoren über eine Zwischenverbindung oder einen Bus, wie PCI, PCIe o.ä. und in manchen Fällen kann dieser Zwischenverbindungsbus als Teil von Fabric 170 betrachtet werden.
  • Die Zwischenverbindungstechnologie kann von einer einzigen Zwischenverbindung oder einer Hybridzwischenverbindung bereitgestellt werden, beispielsweise wenn PCIe eine On-Cip-Kommunikation bereitstellt, 1-Gb- oder 10-Gb-Kupfer-Ethernet relativ kurze Verbindungen zu einem ToR-Switch 120 bereitstellt und Glasfaserverkabelung im Verhältnis längere Verbindungen zu Kernswitch 130 bereitstellt. Zwischenverbindungstechnologien umfassen, als nichteinschränkende Beispiele, Intel® Omni-Path™, TrueScale™, Ultra Path Interconnect (UPI) (früher QPI oder KTI genannt), FibreChannel, Ethernet, FibreChannel over Ethernet (FCoE), InfiniBand, PCI, PCIe oder Glasfasern, um nur ein paar zu nennen. Manche davon sind für bestimmte Anwendungen oder Funktionen passender als andere und die Auswahl einer geeigneten Fabric für die unmittelbare Anwendung ist Aufgabe der Fachleute auf dem Gebiet der Erfindung.
  • Es gilt jedoch anzumerken, dass während hierin Fabrics der Extraklasse, wie Omni-Path™, als Veranschaulichung bereitgestellt werden, es sich bei Fabric 170 ganz allgemein um eine beliebige geeignete Zwischenverbindung oder einen Bus für die spezielle Anwendung handeln kann. Diese können in manchen Fällen Altzwischenverbindungen, wie Local Area Networks (LANs), Token-Ring-Netzwerke, Synchronous Optical Networks (SONET), Asynchronous-Transfer-Mode- (ATM-) Netzwerke, drahtlose Netzwerke, wie WiFi und Bluetooth, „Plain Old Telephone System“- (POTS-) Zwischenverbindungen o.ä. umfassen. Es wird außerdem ausdrücklich angenommen, dass in der Zukunft neue Netzwerktechnologien entstehen werden, um manche der hier angeführten zu ergänzen oder zu ersetzen und sämtliche dieser zukünftigen Netzwerktopologien und -technologien eine Fabric 170 oder Teil davon sein können.
  • In bestimmten Ausführungsformen kann Fabric 170 Kommunikationsdienste auf unterschiedlichen „Schichten“, wie ursprünglich im Sieben-Schichten-Netzwerkmodell OSI dargelegt, bereitstellen. In der heutigen Praxis wird dem OSI-Modell nicht streng gefolgt. Im Allgemeinen werden Schicht 1 und 2 oft „Ethernet“-Schicht genannt (obwohl Ethernet in großen Rechenzentren oft von neueren Technologien verdrängt wurde). Schicht 3 und 4 werden oft als Übertragungssteuerungsprotokoll/Internetprotokoll- (TCP/IP-) Schicht bezeichnet (die weiter in TCP- und IP-Schichten unterteilt werden können). Schichten 5-7 können als „Anwendungsschicht“ bezeichnet werden. Diese Schichtdefinitionen werden als nützliche Rahmenstruktur offenbart, sind jedoch nicht als Einschränkung gedacht.
  • 2 ist ein Blockdiagramm eines heterogenen Netzwerks 200 gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung. Bei dem heterogenen Netzwerk 200 kann es sich, in unterschiedlichen Ausführungsformen, um das gleiche wie Netzwerk 100 aus 1 oder um ein anderes Rechenzentrum handeln. Zusätzliche Ansichten werden in 2 bereitgestellt, um verschiedene Aspekte des heterogenen Netzwerks 200 zu veranschaulichen.
  • In diesem Beispiel wird eine Fabric 270 bereitgestellt, um verschiedene Aspekte des heterogenen Netzwerks 200 zu verbinden, einschließlich MANO 260 und eines oder mehrerer Altvorrichtungen 290. Bei den Altvorrichtungen 290 kann es sich beispielsweise um physische Vorrichtungen oder Einzweck-Hardwarevorrichtungen, Altnetzwerkfunktionen, Alt-virtuelle-Maschinen oder andere Netzwerkfunktionen handeln, die keine native Leistungsfähigkeit aufweisen, mit MANO 260 zusammenzuarbeiten.
  • Bei Fabric 270 kann es sich um die gleiche wie Fabric 170 aus 1 oder eine andere Fabric handeln. Wie oben kann Fabric 270 von einer beliebigen Zwischenverbindungstechnologie bereitgestellt werden. In diesem Beispiel wird Intel® Omni-Path™ als veranschaulichendes und nichteinschränkendes Beispiel genutzt.
  • Wie dargestellt, umfasst das heterogene Netzwerk 200 eine Reihe von Logikelementen, die eine Vielzahl von Knoten bilden. Es gilt zu verstehen, dass jeder Knoten von einem physischen Server, einer Gruppe von Servern oder anderer Hardware bereitgestellt werden kann. Jeder Server kann auf einer oder mehreren virtuellen Maschinen laufen, je nachdem, wie es für die Anwendung passend ist.
  • Knoten 0 208 ist ein Prozessorknoten, der Prozessorsockel 0 und Prozessorsockel 1 umfasst. Bei den Prozessoren kann es sich beispielsweise um Intel® Xeon™-Prozessoren mit einer Vielzahl von Kernen, wie 4 oder 8 Kernen, handeln. Knoten 0 208 kann konfiguriert sein, um Netzwerk- oder Workloadfunktionen, wie z.B. durch das Hosten einer Vielzahl von virtuellen Maschinen oder virtuellen Vorrichtungen, bereitzustellen.
  • Eine integrierte Kommunikation zwischen Prozessorsockel 0 und Prozessorsockel 1 kann durch einen integrierten Uplink 278 bereitgestellt werden. Dadurch kann eine kurze Hochgeschwindigkeitszwischenverbindung zwischen den zwei Prozessorsockeln bereitgestellt werden, sodass virtuelle Maschinen, die auf Knoten 0 208 laufen, miteinander in sehr hohen Geschwindigkeiten kommunizieren können. Um diese Kommunikation zu vereinfachen, kann ein virtueller Switch (vSwitch) auf Knoten 0 208 bereitgestellt werden, der als Teil von Fabric 270 betrachtet werden kann.
  • Knoten 0 208 ist mit Fabric 270 über eine HFI 272 verbunden. HFI 272 kann sich mit einer Intel® Omni-Path™-Fabric verbinden. In manchen Beispielen kann die Kommunikation mit Fabric 270 getunnelt werden, wie durch das Bereitstellen von UPI, die über Omni-Path™ tunnelt.
  • Da das heterogene Netzwerk 200 viele Funktionen auf verteilte Weise bereitstellen kann, die in früheren Generationen integriert bereitgestellt wurden, kann eine hochleistungsfähige HFI 272 bereitgestellt werden. HFI 272 kann in Geschwindigkeiten von mehreren Gigabits pro Sekunde arbeiten und in manchen Fällen eng mit Knoten 0 208 verbunden sein. Beispielsweise ist die Logik für HFI 272 in manchen Ausführungsformen direkt mit den Prozessoren auf einem System-on-a-Chip-System integriert. Dadurch wird eine Hochgeschwindigkeitskommunikation zwischen HFI 272 und den Prozessorsockeln, ohne die Notwendigkeit von dazwischenliegenden Busvorrichtungen, bereitgestellt, die zusätzlich Latenz in die Fabric einführen können. Damit soll jedoch nicht impliziert werden, dass Ausführungsformen, in denen HFI 272 über einen traditionellen Bus bereitgestellt wird, ausgeschlossen sind. Stattdessen wird ausdrücklich angenommen, dass HFI 272 in manchen Beispielen auf einem Bus, wie einem PCIe-Bus, bereitgestellt wird, bei dem es sich um eine serialisierte Version von PCI handelt, die höhere Geschwindigkeiten als eine traditionelle PCI bereitstellt. Im gesamten Netzwerk 200 können verschiedenen Knoten unterschiedliche Arten von HFIs 272, wie integrierte HFIs und anschließbare HFIs, bereitstellen. Es gilt außerdem anzumerken, dass bestimmte Blöcke in einem System-on-a-Chip als Blöcke intellektuellen Eigentums (IP) bereitgestellt werden können, die in eine integrierte Schaltung als modulare Einheit „fallen gelassen“ werden können. Somit kann HFI 272 in manchen Fällen von so einem IP-Block stammen.
  • Es ist anzumerken, dass wenn das Netzwerk als Vorrichtung betrachtet wird, Knoten 0 208 lediglich einen eingeschränkten oder keinen integrierten Arbeitsspeicher oder Speicher bereitstellen kann. Stattdessen kann Knoten 0 208 hauptsächlich auf verteilte Dienste, wie einen Arbeitsspeicherserver und einen Netzwerkspeicherserver angewiesen sein. Integriert, kann Knoten 0 208 nur ausreichend Arbeitsspeicher und Speicher bereitstellen, um die Vorrichtung zu laden und deren Kommunikation mit Fabric 270 zu beginnen. Diese Art der verteilten Architektur ist aufgrund der sehr hohen Geschwindigkeiten der Rechenzentren möglich und kann von Vorteil sein, da dadurch für jeden Knoten nicht übermäßig Ressourcen bereitgestellt werden müssen. Stattdessen kann ein großer Pool von spezialisiertem oder Hochgeschwindigkeitsarbeitsspeicher dynamisch auf eine Reihe von Knoten aufgeteilt werden, sodass jeder Knoten auf einen großen Pool von Ressourcen zugreifen kann, diese Ressourcen jedoch nicht ungenutzt bleiben, wenn sie von diesem speziellen Knoten nicht benötigt werden.
  • In diesem Beispiel stellen ein Knoten-1-Arbeitsspeicherserver 204 und ein Knoten-2-Speicherserver 210 die operativen Arbeitsspeicher- und Speicherleistungsfähigkeiten von Knoten 0 208 bereit. Beispielsweise kann der Arbeitsspeicherserver-Knoten 1 204 einen direkten Fernspeicherzugriff (RDMA) bereitstellen, bei dem Knoten 0 208 auf Arbeitsspeicherressourcen auf Knoten 1 204 über Fabric 270 auf die Weise eines direkten Fernspeicherzugriffs zugreifen kann, als ob er auf seinen eigenen integrierten Speicher zugreifen würde.
  • Bei dem Arbeitsspeicher, der von Arbeitsspeicherserver 204 bereitgestellt wird, kann es sich um einen traditionellen Arbeitsspeicher, wie einen dynamischen Direktzugriffsspeicher (DRAM) Double Data Rate Typ 3 (DDR3), der flüchtig ist, oder um einen exotischeren Arbeitsspeichertyp handeln, wie einen permanenten Schnellspeicher (PFM) wie Intel® 3D Crosspoint™ (3DXP), der mit DRAM-ähnlichen Geschwindigkeiten arbeitet aber nichtflüchtig ist.
  • Ähnlich dazu kann anstelle einer integrierten Festplatte für Knoten 0 208 ein Speicherserverknoten 2 210 bereitgestellt werden. Speicherserver 210 kann eine vernetzte Ansammlung von Festplatten (NBOD), PFM, redundante Anordnung unabhängiger Festplatten (RAID), redundante Anordnung unabhängiger Knoten (RAIN), netzgebundenen Speicher (NAS), optischen Speicher, Bandlaufwerke oder andere nichtflüchtige Speicherlösungen umfassen.
  • Somit kann Knoten 0 208, zur Durchführung seiner designierten Funktion, auf den Arbeitsspeicher von Arbeitsspeicherserver 204 zugreifen und die Ergebnisse in einem Speicher, der von Speicherserver 210 bereitgestellt wird, speichern. Jede dieser Vorrichtungen ist mit Fabric 270 über eine HFI 272 verbunden, die eine schnelle Kommunikation bereitstellt, wodurch diese Technologien ermöglicht werden.
  • Für eine weitere Darstellung ist außerdem Knoten 3 206 abgebildet. Knoten 3 206 umfasst auch eine HFI 272 zusammen mit zwei Prozessorsockeln, die intern durch einen Uplink verbunden sind. Anders als Knoten 0 208 umfasst Knoten 3 206 jedoch seinen eigenen integrierten Arbeitsspeicher 222 und Speicher 250. Daher kann Knoten 3 206 konfiguriert sein, um seine Funktionen in erster Linie integriert durchzuführen und ist mitunter nicht von Arbeitsspeicherserver 204 und Speicherserver 210 abhängig. Unter geeigneten Umständen kann Knoten 3 206 jedoch seinen eigenen integrierten Arbeitsspeicher 222 und Speicher 250 mit verteilten Ressourcen, ähnlich wie Knoten 0 208, ergänzen.
  • Der Grundbaustein der unterschiedlichen hierin offenbarten Komponenten kann als „Logikelemente“ bezeichnet werden. Logikelemente können Hardware (einschließlich z.B. eines Softwareprogrammierbaren Prozessors, einer ASIC oder eines FPGA), externe Hardware (digital, analog oder Mischsignale), Software, wechselwirkende Software, Dienste, Treiber, Schnittstellen, Komponenten, Module, Algorithmen, Sensoren, Komponenten, Firmware, Mikrocode, programmierbare Logik oder Objekte umfassen, die miteinander koordiniert werden können, um eine Logikoperation zu erzielen. Darüber hinaus werden manche Logikelemente von einem materiellen, nichttransitorischen computerlesbaren Medium bereitgestellt, auf dem ausführbare Befehle gespeichert sind, um den Prozessor anzuweisen, eine bestimmte Aufgabe durchzuführen. So ein nichttransitorisches Medium kann beispielsweise eine Festplatte, Solid-State-Speicher oder - Festplatte, Nur-Lese-Speicher (ROM), permanenten Schnellspeicher (PFM) (z.B. Intel® 3D Crosspoint™), redundante Anordnung unabhängiger Festplatten (RAID), redundante Anordnung unabhängiger Knoten (RAIN), netzgebundenen Speicher (NAS), optischen Speicher, Bandlaufwerke, Backup-System, Cloud-Speicher oder eine beliebige Kombination des Vorangegangenen als nichteinschränkende Beispiele umfassen. So ein Medium kann außerdem Befehle umfassen, die in einen FPGA programmiert sind oder in Hardware auf einer ASIC oder einem Prozessor kodiert sind.
  • 3 ist ein Blockdiagramm eines Software-definierten Netzwerks 300, gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung. Bei Software-definierten Netzwerken (SDN) wird eine Datenebene von einer Steuerebene getrennt, um bestimmte Vorteile umzusetzen. Bei SDN handelt es sich dabei nur um eine Form der Virtualisierung, die hier gezeigt wird, um eine Option für eine Netzwerkkonfiguration zu zeigen.
  • SDN 300 wird von einer SDN-Steuerung 310 gesteuert. SDN-Steuerung 310 ist kommunikativ mit einer Vielzahl von Netzwerkvorrichtungen 330 verbunden. Insbesondere ND1 330-1, ND2 330-2 und ND5 330-5 sind direkt kommunikativ mit der SDN-Steuerung 310 verbunden. Die Netzwerkvorrichtungen ND3 330-3 und ND4 330-4 sind nicht direkt mit der SDN-Steuerung 310, sondern stattdessen über dazwischenliegende Vorrichtungen, wie ND2 330-2 und ND5 330-5, verbunden.
  • Manche Netzwerkvorrichtungen 330 sind auch direkt kommunikativ mit Hostvorrichtungen 340 verbunden. Insbesondere Netzwerkvorrichtung ND1 verbindet sich direkt mit Host A 340-1, der die IP-Adresse 10.0.0.10 und MAC-Adresse FA:16:3:01:61:8 aufweist. Netzwerkvorrichtung ND2 330-2 verbindet sich direkt mit Host B 340-2, der die IP-Adresse 10.0.0.20 und MAC-Adresse FA:16:3:01:63:B3 aufweist. Netzwerkvorrichtung ND5 330-5 ist direkt mit Host D 440-3 verbunden, der die IP-Adresse 10.0.0.30 und MAC-Adresse FA:16:3:01:54:83 aufweist.
  • Netzwerkvorrichtungen 330 können konfiguriert sein, um eine Vielzahl von Netzwerkfunktionen durchzuführen, wie als nichteinschränkende Beispiele, Lastverteilung, Firewall, Deep Packet Inspection (DPI), DNS, Antivirus oder sämtliche andere geeigneten Netzwerkfunktionen. Die spezielle Anordnung der Zwischenverbindungen zwischen den Netzwerkvorrichtungen 330 und von den Netzwerkvorrichtungen 330 zu den Hostvorrichtungen 340 kann durch die spezielle Netzwerkkonfiguration und Anforderungen bestimmt werden. Daher soll die spezifische Konfiguration von 3 lediglich als illustratives Beispiel gesehen werden.
  • Jede Netzwerkvorrichtung 330 kann eine Vielzahl von Eingangs- und/oder Ausgangsschnittstellen, wie physisches Ethernet oder Fabric-Ports, aufweisen. In einem Beispiel kann jede Schnittstelle eine Bezeichnung oder einen neuen Namen aufweisen, wie z.B. P1, P2, P3, P4, P5 usw.
  • Daher können bestimmte Aspekte des Netzwerkaufbaus bestimmt werden, indem festgestellt wird, welche Vorrichtungen auf welcher Schnittstelle verbunden sind. So weist beispielsweise Netzwerkvorrichtung ND1 330-1 eine Eingangsschnittstelle für das Empfangen von Befehlen und das Kommunizieren mit der SDN-Steuerung 310 auf. ND1 330-1 weist außerdem eine Schnittstelle P1 auf, die kommunikativ mit Host A 340-1 verbunden ist. ND1 330-1 weist die Schnittstelle P2 auf, die kommunikativ mit ND2 330-2 verbunden ist. Im Falle von ND2 330-2 ist diese außerdem mit ND1 330-1 auf ihrer eigenen Schnittstelle P2 und mit Host B 340-2 über Schnittstelle P1 verbunden. ND2 330-2 ist kommunikativ mit den dazwischenliegenden Vorrichtungen ND3 330-3 und ND4 330-4 über die Schnittstellen P3 bzw. P4 verbunden. Zusätzliche Schnittstellendefinitionen sind in der gesamten Figur sichtbar.
  • Eine Flusstabelle kann für den Datenverkehr definiert werden, der von einer Schnittstelle zur nächsten fließt. Diese Flusstabelle wird genutzt, sodass eine Netzwerkvorrichtung, wie ND2 330-2 nach Empfang eines Pakets bestimmen kann, wohin dieses weiter geschickt werden soll.
  • Beispielsweise können die folgenden Flusstabellen für ND1 330-1 - ND4 330-4 definiert werden. Tabelle 1. ND1-Fließregel
    Eingangsschnittstelle Quellen-MAC Ziel-Mac Quellen-IP Ziel-IP Aktion
    P1 Beliebige fa: 16:3e: 01:54:a3 Beliebige 10.0.0. 30 P2
    Tabelle 2. ND2-Fließregel
    Eingangsschnittstelle Quellen-MAC Ziel-Mac Quellen-IP Ziel-IP Aktion
    P2 Beliebige fa: 16:3e: 01:54:a3 Beliebige 10.0.0 .30 P4
    Tabelle 3. ND3-Fließregel
    Eingangsschnittstelle Quellen-MAC Ziel-Mac Quellen-IP Ziel-IP Aktion
    P1 Beliebige fa:16:3e: 01:54:a3 Beliebige 10.0. 0.30 P3
    Tabelle 4. ND4-Fließregel
    Eingangsschnittstelle Quellen-MAC Ziel-Mac Quellen-IP Ziel-IP Aktion
    P3 Beliebige fa:16:3e: 01:54:a3 Beliebige 10.0. 0.30 P1
  • 4 ist ein Blockdiagramm, in dem eine Netzwerkfunktionsvirtualisierungs- (NFV-) Architektur, gemäß einem oder mehrerer Beispiele der vorliegenden Beschreibung, dargestellt wird. NFV ist eine zweite nichteinschränkende Form von Netzwerkvisualisierung, die oft als eine Ergänzung oder Verbesserung zu SDN, aber manchmal als separate Einheit behandelt wird. NFV war ursprünglich als Verfahren zur Bereitstellung von reduzierten Kapitalaufwendungen (Capex) und Betriebsaufwendungen (Opex) für Telekommunikationsdienste gedacht. Ein wichtiges Merkmal von NFV ist das Ersetzen von firmeneigenen spezialisierten Hardwarevorrichtungen durch virtuelle Vorrichtungen, die auf kommerzieller Standard- (COTS-) Hardware in einer virtualisierten Umgebung laufen. Zusätzlich zu den Capex- und Opex-Einsparungen stellt NFV ein agileres und stärker anpassbares Netzwerk bereit. Wenn sich Netzwerklasten ändern, können virtuelle Netzwerkfunktionen (VNFs) bereitgestellt (aufgestockt) oder entfernt (reduziert) werden, um den Netzwerkanforderungen nachzukommen. So können zu Zeiten mit hoher Last beispielsweise mehr Lastverteilungs-VNFs aufgestockt werden, um den Datenverkehr auf mehrere Workload-Server (bei denen es sich selbst um virtuelle Maschinen handeln kann) zu verteilen. Zu Zeiten, in denen mehr verdächtiger Datenverkehr beobachtet wird, können zusätzliche Firewalls oder Deep-Packet-Inspection- (DPI-) Vorrichtungen von Nöten sein.
  • Da NFV ursprünglich als Funktion für die Telekommunikation gedacht war, konzentrieren sich viele NFV-Instanzen auf Telekommunikation. Dennoch ist NFV nicht auf Telekommunikationsdienste beschränkt. Im weiteren Sinn umfasst NFV eine oder mehrere VNFs, die in einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI) laufen. Oft handelt es sich bei den VNFs um Inline-Dienstfunktionen, die von den Workload-Servern oder anderen Knoten getrennt sind. Diese VNFs können zu einer Dienstkette verkettet werden, die von einem virtuellen Subnetzwerk definiert sein kann und eine serielle Reihung von Netzwerkdiensten umfassen kann, die die Arbeit im Hintergrund, wie Sicherheit, Logging, Fakturierung o.ä. bereitstellen.
  • Diese Darstellungen in 3 und 4 können als funktioneller, im Vergleich zu höheren, logischen Netzwerkanordnungen, betrachtet werden. Wie SDN handelt es sich bei NFV um eine Untergruppe der Netzwerkvirtualisierung. Daher kann das Netzwerk, wie es in 4 dargestellt ist, anstatt oder zusätzlich zu dem Netzwerk aus 3 definiert werden. Anders ausgedrückt, können sich manche Abschnitte des Netzwerks auf SDN stützen, während sich andere Abschnitte (oder die gleichen Abschnitte) auf NFV stützen können.
  • Im Beispiel von 4 verwaltet ein NFV-Orchestrator 402 eine Reihe der VNFs, die auf einer NFVI 404 laufen. NFV erfordert nichttriviale Ressourcenverwaltung, wie das Allozieren eines sehr großen Pools an Rechnerressourcen unter einer geeigneten Anzahl von Instanzen jeder VNF, das Verwalten von Verbindungen zwischen VNFs, das Bestimmen, wie viele Instanzen jeder VNF zu allozieren sind und das Verwalten von Arbeitsspeicher, Speicher und Netzwerkverbindungen. Dafür ist mitunter eine komplexe Softwareverwaltung und daher auch der NFV-Orchestrator 402 nötig.
  • Es ist anzumerken, dass der NFV-Orchestrator 402 selbst üblicherweise virtualisiert (anstelle einer spezialisierten Hardwarevorrichtung) ist. NFV-Orchestrator 402 kann in einem bestehenden SDN-System integriert sein, in dem ein Betriebsunterstützungssystem (OSS) das SDN verwaltet. Dieses kann mit Cloud-Ressourcen-Verwaltungssystem (z.B. OpenStack) interagieren, um eine NFV-Orchestrierung bereitzustellen. Eine NFVI 404 kann die Hardware, Software und andere Infrastruktur bereitstellen, um das Laufen von VNFs zu ermöglichen. Das kann einen Rack oder einige Racks von Blade- oder Steckplatz-Servern (einschließlich z.B. Prozessoren, Arbeitsspeicher und Speicher), ein oder mehrere Rechenzentren, andere Hardwareressourcen, die über einen oder mehrere geographische Orte verteilt sind, Hardware-Switches oder Netzwerkschnittstellen umfassen. Eine NFVI 404 kann außerdem die Softwarearchitektur umfassen, durch die das Laufen des Hypervisors und dessen Verwalten durch einen NFV-Orchestrator 402 ermöglicht werden. Auf NFVI 404 laufen eine Reihe von virtuellen Maschinen, die in diesem Beispiel jeweils eine VNF sind, die eine virtuelle Dienstvorrichtung bereitstellen. Diese umfassen, als nichteinschränkende und veranschaulichende Beispiele, VNF 1 410, die eine Firewall ist, VNF 2 412, die ein Angrifferkennungssystem ist, VNF 3 414, die ein Lastverteiler ist, VNF 4 416, die ein Router ist, VNF 5 418, die ein Session Border Controller ist, VNF 6 420, die ein Deep-Packet-Inspection- (DPI-) Dienst ist, VNF 7 422, die ein Netzwerkadressübersetzungs- (NAT-) Modul ist, VNF 8 424, die eine Anrufsicherheitsverbindung bereitstellt und VNF 9 426, die einen zweiten aufgestockten Lastverteiler darstellt, um den erhöhten Bedarf zu decken.
  • Firewall 410 ist eine Sicherheitsvorrichtung, die den Datenverkehr (sowohl eingehend als auch ausgehend), basierend auf dem Abgleich des Datenverkehrs mit einer Liste von „Firewall-Regeln“ überwacht und verwaltet. Bei Firewall 410 kann es sich um eine Barriere zwischen einem relativ vertrauenswürdigen (z.B. internen) Netzwerk und einem relativ vertrauensunwürdigen Netzwerk (z.B. dem Internet) handeln. Hat der Datenverkehr einmal die Prüfung durch die Firewall 410 bestanden, kann er an andere Teile des Netzwerks weitergeleitet werden.
  • Angriffserkennung 412 überwacht das Netzwerk im Hinblick auf schädliche Aktivität oder Regelverstöße. Vorfälle können einem Sicherheitsadministrator gemeldet werden oder von einem Sicherheitsinformations- und Ereignisverwaltungs- (SIEM-) System gesammelt und analysiert werden. In manchen Fällen kann die Angriffserkennung 412 außerdem Antiviren- oder Antimalware-Scanner umfassen.
  • Lastverteiler 414 und 426 können Datenverkehr an eine Gruppe von im Wesentlichen identischen Workload-Servern auslagern, um die Arbeit fair zu verteilen. In einem Beispiel stellt ein Lastverteiler eine Reihe von Datenverkehr-„Eimern“ bereit und ordnet jedem Workload-Server einen Eimer zu. Eingehender Datenverkehr wird einem Eimer basierend auf einem Faktor, wie einem Hash der Quellen-IP-Adresse, zugeordnet. Ausgehend von der Annahme, dass die Hashes im Grunde gleichmäßig verteilt sind, erhält jeder Workload-Server eine angemessene Menge an Datenverkehr.
  • Router 416 leitet Pakete zwischen Netzwerken oder Subnetzwerken weiter. Beispielsweise kann Router 416 eine oder mehrere Eingangsschnittstellen und eine Vielzahl von Ausgangsschnittstellen umfassen, wobei jede Ausgangsschnittstelle einer Ressource, einem Subnetzwerk, einem virtuellen privaten Netzwerk oder einem anderen Bereich zugeordnet ist. Wenn Daten in eine Eingangsschnittstelle eintreten, bestimmt Router 416, zu welchem Ziel sie sollen, und leitet das Paket an die passende Ausgangsschnittstelle.
  • Session Border Controller 418 steuert die IP-Telefonie-(VoIP-) Signalgebung sowie die Medienströme, um Anrufe zu veranlassen, zu führen und zu beenden. In diesem Zusammenhang bezieht sich „Session“ auf ein Kommunikationsereignis (z.B. einen „Anruf“). „Border“ bezieht sich auf eine Grenze zwischen zwei unterschiedlichen Teilen eines Netzwerks (ähnlich einer Firewall).
  • DPIvorrichtung 420 stellt eine Deep Packet Inspection bereit, bei der nicht nur der Header untersucht wird, sondern auch der Inhalt eines Pakets, um nach potentiell unerwünschtem Inhalt (PUC), wie Nichteinhaltung des Protokolls, Malware, Viren, Spam oder Angriffe zu suchen.
  • NAT-Modul 422 stellt Netzwerkadressübersetzungsdienste bereit, um einen IP-Adressraum in einen anderen umzumappen (z.B. dem Mappen von Adressen in einem privaten Subnetzwerk auf das größere Internet).
  • Anrufsicherheitsverbindung 424 erzeugt eine Sicherheitsverbindung für einen Anruf oder ein anderes Ereignis (siehe Session Border Controller 418 oben). Das Aufrechterhalten dieser Sicherheitsverbindung kann wichtig sein, da der Anruf kurzfristig beendet werden kann, wenn die Sicherheitsverbindung unterbrochen wird.
  • Die Darstellung von 4 zeigt, dass eine Reihe von VNFs innerhalb von NFVI 404 bereitgestellt wurde und besteht. Diese Figur stellt nicht notwendigerweise eine Beziehung zwischen den VNFs und dem größeren Netzwerk dar.
  • 5 ist ein Blockdiagramm eines heterogenen Rechenzentrums 500 nach einem oder mehreren Beispielen der vorliegenden Beschreibung. In diesem Beispiel umfasst das heterogene Rechenzentrumnetzwerk 500 einen Altstapel 560, ein virtuelles Altnetzwerk 564 und ein orchestriertes virtuelles Netzwerk 568.
  • In diesem Beispiel umfasst Altstapel 560 eine Bare-Metal-Anwendung 504, die auf einer dedizierten Hardwarevorrichtung, wie einer Firewall, einem Switch, Router oder einer anderen gängigen physikalischen Vorrichtung laufen kann. Bare-Metal-Anwendung 504 kann eine dedizierte Hardwareplattform umfassen, die lediglich für Bare-Metal-Anwendung 504 betrieben wird. Die Hardwareplattform kann Rechnerressourcen 516-1, Netzwerkressourcen 520-1 und Speicherressourcen 524-1 als nichteinschränkende Beispiele umfassen. Diese Ressourcen können eine Basisplattformressourcenüberwachung 512-1 bereitstellen, die mit einer Überwachungs- und Analysefunktion 554-1 interagieren kann, die Überwachung und Analyse für Bare-Metal-Anwendung 504 bereitstellt. Außerdem kann ein Bare-Metal-Verwaltungssystem 550 bereitgestellt sein, das beispielsweise eine Kommandozeilenschnittstelle (CLI), auf die über eine Anwendung, wie Telnet oder Secure Shell (SSH) zugegriffen werden kann, oder ein webbasiertes graphisches Verwaltungssystem umfassen kann, das Konfigurationsregeln oder Befehle in ein standardkonformes Format wie XML- oder Simple-Network-Management-Protocol- (SNMP-) Befehle übersetzt und genutzt werden kann, um die Funktionen von Bare-Metal-Anwendung 504 zu konfigurieren. Bare-Metal-Verwaltungssystem 550 stellt eine Plattformbereitstellung bereit, während die Überwachungs- und Analysefunktion 554-1 die Plattformtelemetrie empfängt. Es kann ein Set von gemeinsamen offenen Anwendungsprogrammierschnittstellen (APIs) 508-1 bereitgestellt werden, um so eine Verwaltung zu erleichtern. So können die gemeinsamen offenen APIs beispielsweise SNMP umfassen, bei dem es sich um ein standardkonformes Verfahren zur Verwaltung von Netzwerkvorrichtungen handelt.
  • Wenn keine Interworking-Broker-Funktion, wie in dieser Beschreibung beschrieben, vorhanden ist, muss ein Netzwerkadministrator mitunter einen Altstapel 560 separat über Bare-Metal-Verwaltungssystem 550 verwalten. Wenn die Größe des Netzwerks wächst und mehr Vorrichtungen hinzugefügt werden, kann das eine weitere Belastung der Netzwerkverwaltung darstellen, der durch den Einsatz einer Interworking-Broker-Funktion vorgebeugt werden kann.
  • Ähnlich dazu umfasst der virtuelle Altstapel 564 eine Vielzahl virtueller Netzwerkfunktionen 532-1, die von einem Hypervisor oder einem Container 528-1 auf einer Hardwareplattform laufen, einschließlich z.B. Rechnerressourcen 516-2, Netzwerkressourcen 520-2 und Speicherressourcen 524-2.
  • Ähnlich zu Altstapel 560 umfasst die Plattformbereitstellung ein Verwaltungssystem 556, das für die Plattformbereitstellung von VNFs 532-1 genutzt werden kann. Wie zuvor können diese über ein Set gemeinsamer offener APIs 580-2 verwaltet werden, bei denen es sich um die gleichen oder ähnliche wie die gemeinsamen offenen APIs 508-1 von Altstapel 560 handeln. Es kann sich auch um andere gemeinsame offene APIs handeln. Virtueller Altstapel 564 umfasst die Basisplattformressourcenüberwachung 512-2, die Plattformtelemetrie für Überwachungs- und Analysefunktion 554-2 bereitstellt.
  • In diesem Beispiel umfasst virtueller Altstapel 564, ähnlich wie Altstapel 560, ein Verwaltungssystem 556, das mitunter nicht nativ kompatibel mit MANO 544 ist. Daher muss der virtuelle Altstapel 564, wenn keine Interworking-Broker-Funktion vorhanden ist, unter Umständen separat vom Altstapel 560 und orchestrierten virtuellen Netzwerk 568 verwaltet werden. Auch das kann eine zusätzliche Last für den Netzwerkadministrator bedeuten.
  • Das heterogene Rechenzentrum 500 umfasst außerdem ein virtuelles Netzwerk 568, das eine MANO-Funktion 544 umfasst, die mit einem virtuellen Infrastrukturmanager (VIM) 548, wie OpenStack o.ä., zusammenarbeitet.
  • Der VIM 548 startet mehrere Instanzen der VNFs 532-2, um Funktionen im heterogenen Netzwerk 500 bereitzustellen. Diese können in einem Hypervisor und/oder Container 528-2 enthalten sein. So wie beim virtuellen Altstapel 564, umfasst der orchestrierte virtuelle Stapel 568 eine Hardwareplattform, die Rechnerressourcen 516-3, Netzwerkressourcen 520-3 und Speicherressourcen 524-3 umfasst. Die Basisplattformressourcenüberwachung 512-3 kann eine Plattformtelemetrie für SDN 540 bereitstellen. Wie schon zuvor können auch gemeinsame offene APIs 508-3 vom VIM 548 genutzt werden, um eine Plattformbereitstellung bereitzustellen.
  • Wie bereits besprochen, ist es von Vorteil, eine Interworking-Broker-Funktion bereitzustellen, sodass MANO 544 sowohl virtuellen Altstapel 564 als auch Altstapel 560 konfigurieren und verwalten kann.
  • 6 ist ein Blockdiagramm einer Interworking-Broker-Funktion gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
  • Es ist anzumerken, dass es sich bei der Interworking-Broker-Funktion 620 in diesem Beispiel um eine beliebige geeignete Hardware- oder Softwareimplementierung handeln kann, wie sie in der vorliegenden Beschreibung vorgesehen ist. Die Interworking-Broker-Funktion 620 kann geeignete Hardware, Software, Firmware, Befehle, die auf einem materiellen, nichttransitorischen computerlesbaren Medium gespeichert sind, eine anwendungsspezifische integrierte Schaltung oder ein feldprogrammierbares Gate-Array, eine native Anwendung, die direkt auf einer Domänensteuerung oder auf der gleichen Hardwareplattform wie MANO 544 aus 5 läuft, eine oder mehrere virtuelle Maschinen oder eine beliebige andere Kombination von Hardware oder Software umfassen, die für eine Implementierung passend ist.
  • In diesem Beispiel wird eine einzige Interworking-Broker-Funktion 620 dargestellt, die zwei Übersetzungstreiber, nämlich Übersetzungstreiber 1 612-1 und Übersetzungstreiber 2 612-2, bereitstellt. Es ist anzumerken, dass das ein nichteinschränkendes Beispiel darstellt und je nach den Anforderungen einer bestimmten Umsetzung auf vielerlei Weise variieren kann. So können Übersetzungstreiber 1 612-1 und Übersetzungstreiber 2 612-2 jeweils für eine andere spezifische Altvorrichtung oder Einrichtung, wie Altvorrichtung 1 616-1 und Altvorrichtung 2 616-2 sein. In diesem Beispiel werden nur zwei Altvorrichtungen 616 gezeigt, wobei jede von einer einzelnen Instanz eines Übersetzungstreibers 612 bedient wird. Andere Konfigurationen sind jedoch ebenfalls möglich. Beispielsweise könnten viele Instanzen von Altvorrichtung 2 616-2 vorhanden sein, wobei alle Instanzen der Altvorrichtung von einem einzelnen Übersetzungstreiber 2 612-2 bedient werden können. In anderen Ausführungsformen kann eine Vielzahl von Übersetzungstreibern 2 612-2 bereitgestellt werden, um die Vielzahl der Instanzen von Altvorrichtung 2 616-2 zu bedienen. Im Allgemeinen kann eine Interworking-Broker-Funktion 620 einen oder mehrere Übersetzungstreiber 612 eines oder mehrere unterschiedlicher Typen hosten und Übersetzungstreiber 612 eines bestimmten Typs können auf einer oder mehreren Vorrichtungen oder virtuellen Maschinen eingesetzt werden, die eine oder mehrere Instanzen einer Interworking-Broker-Funktion hosten.
  • In diesem Beispiel kann die Interworking-Broker-Funktion 620 initial die Altvorrichtungen 616 aufspüren, indem sie eine Standard-SNMP-Netzwerkabfrage durchführt. SNMP stellt eine Fähigkeit bereit, eine baumähnliche Struktur abzugehen und die unterschiedlichen Funktionen, die auf dem Netzwerk bereitgestellt werden können, zu entdecken. Hat Interworking-Broker-Funktion 620 einmal alle Instanzen von Altvorrichtungen 616 aufgespürt, kann er geeignete Übersetzungstreiber 612 für jede Altvorrichtung bauen. Das kann beispielsweise auf Regelengine 630 basieren, die eine Regeldatenbank für das Bereitstellen von Übersetzungen für unterschiedliche Arten von Altvorrichtungen umfassen. Das kann Mappings von MANO-Befehlen an Altvorrichtungen und Mappings von Plattformtelemetrie zurück zu einem Format, das von MANO 604 aufgenommen werden kann, umfassen. Wenn IBF 620 MANO 604 über die verfügbaren Altvorrichtungen 616 benachrichtigt hat, kann MANO 604 dann mit der Verwaltung dieser Vorrichtungen fortfahren, als ob sie nativ orchestrierte virtuelle Maschinen oder Container wären. MANO 604 kann mit IBF 620 über eine geeignete API, wie einer REST-API 608, kommunizieren.
  • Übersetzungstreiber 612 von IBF 620 kann unterschiedliche Übersetzungen bereitstellen, einschließlich als nichteinschränkendes Beispiel Mapping von VIM-Anfragen zu Alt-SNMP, Netzwerkkonfigurationsprotokoll (NETCONF), CLIs, XML, oder anderen Formaten, um mit VIMs, wie OpenStack, zusammenzuarbeiten. In bestimmten Ausführungsformen kann ein NFV-zu-Alt-Mapping VIM-Befehle automatisch zu Anfragen für SNMP oder CLI mappen. Beispielsweise kann IBF 620 eine Enhanced-Platform- Awareness- (EPA-) Leistungsfähigkeitanfragenachricht von einer MANO-Anfrage zu einer, als nichteinschränkendes Beispiel, SNMP-Anfrage, CLI-Anfrage und/oder anderen Altschnittstellen mappen. In der anderen Richtung kann Übersetzungstreiber 612 SNMP-Traps zu dem Message-Queuing-Telemetry-Transport- (MQTT-) Bus für einen Ceilometer oder Watcher mappen. Er kann außerdem Syslog-Telemetrie, Netflows oder sflow-Telemetrie zu einem Ceilometer oder Subnetzwerkzugangsprotokoll (SNAP) als nichteinschränkendes Beispiel mappen.
  • Außerdem können MANO 604 oder ein VIM, wie VIM 548 aus 5 erweitert werden. Beispielsweise kann der Network Service Descriptor (NSD) erweitert werden, um große Altvorrichtungen zu repräsentieren. In manchen Beispielen kann der Zuordnungsprozess, der eine Altvorrichtung der IBF und einem bestimmten Übersetzungstreiber zuordnet, selbst eine VNF sein. Auf jeden Fall kann zumindest die IP-Adresse einer Altvorrichtung mit einer geeigneten IBF-Instanz 620 und/oder Übersetzungstreiber 612 verbunden sein.
  • In manchen Ausführungsformen kann ein mobil eingebettetes Computer- (MEC-) Modul in zwei unabhängigen Netzwerken (zum Beispiel ein Altnetzwerk und ein verwaltetes Netzwerk) genutzt werden, wodurch MANO Altnetzwerkvorrichtungen wie im Hinblick auf IP-Adressen oder Wide-Area-Network- (WAN-) Verbindungen zu scannen, um dann die Wiederverwendung dieses Raums zu vermeiden.
  • In unterschiedlichen Ausführungsformen kann IBF 620 operativ als Zusammenarbeitsfunktion oder in manchen Ausführungsformen als eine Telemetriebrücke vom Altstapel zum verwalteten Stapel fungieren. Zusätzlich dazu kann die IBF konfiguriert sein, um einen Netzwerkfunktionsbereitstellungs- oder - konfigurationsbefehl für eine Altnetzwerkvorrichtung von einem Orchestrator zu erhalten.
  • Die IBF kann ferner konfiguriert sein, um eine Nachricht von der Altnetzwerkvorrichtung zu erhalten und die Nachricht im TD in ein Format zu übersetzen, die von dem Orchestrator aufgenommen werden kann. Bei der Nachricht kann es sich, als nichteinschränkendes Beispiel, um ein IP-Paket, eine ATM- oder Frame-Relay-Nachricht, eine Simple-Object-Access-Protocol- (SOAP-) Nachricht, eine NETCONF-Nachricht, eine XML- oder JSON-Nachricht oder einen CLI-Befehl handeln. Weitere nichteinschränkende Beispiele einer Nachricht umfassen Benachrichtigungs-, Ereignis- oder Telemetrienachrichten. Bei einer Benachrichtigung oder einem Ereignis kann es sich, als nichteinschränkendes Beispiel, um eine SNMP-Trap, eine SNMP-Formatnachricht oder ein Internet Protocol Flow Information Export (IPFIX) handeln.
  • 7 ist ein Blockdiagramm einer Dienstkette, in der dargestellt wird, wie eine Altvorrichtung 720 nahtlos in einer Dienstkette, die verwaltete virtuelle Vorrichtungen umfassen kann, integriert werden kann.
  • In diesem Beispiel kann es sich bei Altvorrichtung 720 beispielsweise um eine Hardwarevorrichtung handeln, während es sich bei VNF 1 704 und VNF 2 708 um verwaltete virtuelle Vorrichtungen handelt. Ein Switch 716, bei dem es sich beispielsweise um einen Althardwareswitch handeln kann, kann außerdem im Netzwerk wirken. Eine SDN-Steuerung 712 stellt dem Netzwerk SDN-Dienste bereit.
  • Da die Altvorrichtung 720 physische Eingangs- und Ausgangs-Ports umfasst, integriert sie sich unter Umständen nicht virtuell und nahtlos in einer virtuellen Dienstkette, die das Weiterleiten von Tabellen auf einen virtuellen Switch bereitstellt. Stattdessen kann Switch 716 passende Weiterleitungsregeln bereitstellen, damit es Altvorrichtung 720 möglich ist, Teil einer passenden Dienstkette zu sein. In diesem Beispiel kann die Dienstkette von VNF 1 704 zu Altvorrichtung 720 zu VNF 2 708 und schließlich zu einer Zielvorrichtung übergehen.
  • Um diese Dienstkette bereitzustellen, tritt der Datenverkehr bei 1 auf eine virtuelle Eingangsschnittstelle von VNF 1 704. VNF 1 704 führte ihre Funktion auf dem Paket durch und leitet das Paket dann über eine virtuelle Ausgangsschnittstelle an Switch 716 weiter. Bei 2 erhält Switch 716 das Paket an einer Eingangsschnittstelle, die mit VNF 1 704 verbunden ist, und leitet dann das Paket an die Altvorrichtung 720 weiter. Switch 716 kann mit geeigneten Weiterleitungsregeln konfiguriert sein, um sicherzustellen, dass Datenverkehr an der Eingangsschnittstelle von VNF 1 704 an Altvorrichtung 720 weitergeleitet wird.
  • Bei 3 leitet Switch 716 das Paket, gemäß den Weiterleitungsregeln, an Altvorrichtung 720 weiter.
  • Bei 4 führt Altvorrichtung 720 ihre Funktion auf dem Paket durch und sendet das Paket zu Switch 716 zurück.
  • Switch 716 empfängt das Paket an einer Eingangsschnittstelle, die mit Altvorrichtung 720 verbunden ist und leitet das Paket, gemäß den Weiterleitungsregeln, schließlich zu VNF 2 708 weiter. VNF 2 708 stellt die letzte Funktion der Dienstkette dar und bei 5 führt VNF 2 708 ihre Funktion auf dem Paket durch. Schließlich liefert VNF 2 708 das Paket an die Zielvorrichtung.
  • 8 ist ein Flussdiagramm eines Verfahrens 800 zur Durchführung von Erkennung in einem heterogenen Netzwerk, gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
  • Verfahren 800 kann in unterschiedlichen Ausführungsformen von einer beliebigen geeigneten Vorrichtung, einschließlich einer IBF als nichteinschränkendes Beispiel, durchgeführt werden. Eine IBF wird in der Beschreibung von 8 als ein Beispiel für eine Funktion, die das Verfahren durchführen kann, genutzt. Nichtsdestotrotz kann eine beliebige geeignete Vorrichtungsengine oder Funktion genutzt werden, um Verfahren 800 durchzuführen.
  • In Block 804 scannt IBF das Netzwerk im Hinblick auf Altvorrichtungen. Das kann den Einsatz von Standard-IP-Erkennungsverfahren umfassen, um zu bestimmen, welche Vorrichtungen im Netzwerk vorhanden sind. In manchen Beispielen kann das außerdem SNMP-Abfragen umfassen.
  • Wurden alle verfügbaren Altvorrichtungen im Netzwerk gescannt und erkannt, kann die IBF in Block 808 eine SNMP oder ähnliche Abfrage auf allen erkannten Vorrichtungen bereitstellen, zum Beispiel um den SNMP-MIB-Typ zu erkennen. Der MIB-Typ kann die IBF über verfügbare Formate informieren, um Kommunikation mit den Altvorrichtungen bereitzustellen.
  • In Block 812 baut die IBF für jede Altvorrichtung einen Übersetzungstreiber. Das kann das Extrahieren oder Aufspüren einer MIB und Verwenden der MIB, um die geeigneten Übersetzungen zwischen dem Altformat und dem verwalteten VNF-Format aufzubauen, umfassen. Die IBF ordnet der Altvorrichtung dann den Übersetzungstreiber zu.
  • Sind die geeigneten Übersetzungstreiber aufgebaut und der Altvorrichtung zugeordnet, meldet die IBF die Altvorrichtungen der MANO als Altvorrichtungen. Das kann das Melden von Leistung und Fähigkeiten der Altvorrichtungen umfassen, wie über einen erweiterten Netzwerkdienstdeskriptor (NSD).
  • Das Vorangegangene skizziert Merkmale einer oder mehrerer Ausführungsformen des hierin offenbarten Gegenstands. Diese Ausführungsformen werden bereitgestellt, um einem Fachmann auf dem Gebiet der Erfindung (PHOSITA) ein besseres Verständnis der unterschiedlichen Aspekte der vorliegenden Offenbarung zu bieten. Bestimmte wohlbekannte Begriffe sowie zugrundeliegende Technologien und/oder Standards können angeführt werden, ohne genau beschrieben zu werden. Es wird angenommen, dass der PHOSITA in ausreichendem Maße über das Hintergrundwissen oder Information in diesen Technologien und Standards verfügt oder Zugang dazu hat, um die Lehren der vorliegenden Beschreibung zu praktizieren.
  • Für den PHOSITA versteht es sich, dass sie die vorliegende Offenbarung einfach als Basis für die Gestaltung oder Modifikation anderer Prozesse, Strukturen oder Variationen zur Verfolgung der gleichen Ziele und/oder Erreichung der gleichen Vorteile der hierin vorgestellten Ausführungsformen nutzen kann. Der PHOSITA wird außerdem anerkennen, dass solche äquivalenten Konstruktionen nicht vom Geist und Schutzumfang der vorliegenden Offenbarung abweichen und dass sie zahlreiche Veränderungen, Ersetzungen und Abänderungen hierin vornehmen können, ohne sich vom Geist und Schutzumfang der vorliegenden Offenbarung zu entfernen.
  • In der vorangegangenen Beschreibung sind bestimmte Aspekte mancher oder aller Ausführungsformen genauer beschrieben, als es zwingend für das Praktizieren der beiliegenden Patentansprüche nötig wäre. Diese Details werden lediglich als nichteinschränkende Beispiele bereitgestellt, um Kontext und eine Veranschaulichung der offenbarten Ausführungsformen zu liefern. Solche Details sollen nicht als Erfordernis ausgelegt werden und sollten nicht in die Patentansprüche als Einschränkungen „hineininterpretiert“ werden. Der Satz kann sich auf „eine Ausführungsform“ oder „Ausführungsformen“ beziehen. Diese Sätze und beliebige andere Verweise auf Ausführungsformen sollen im weiteren Sinn verstanden werden, um sich auf eine beliebige Kombination aus einer oder mehreren Ausführungsformen zu beziehen. Darüber hinaus können die zahlreichen Funktionen, die in einer bestimmten „Ausführungsform“ offenbart sind, genauso gut über mehrere Ausführungsformen verteilt sein. Wenn beispielsweise Funktionen 1 und 2 in „einer Ausführungsform“ offenbart sind, kann Ausführungsform A Funktion 1 aber nicht Funktion 2 aufweisen, während Ausführungsform B Funktion 2 aber nicht Funktion 1 aufweisen kann.
  • Diese Beschreibung kann Veranschaulichungen in Form eines Blockdiagramms bereitstellen, in dem bestimmte Funktionen in getrennten Blöcken offenbart sind. Diese sollten im weiteren Sinne verstanden werden, um die Zusammenarbeit verschiedener Funktionen zu offenbaren, sollen jedoch nicht implizieren, dass diese Funktionen notwendigerweise in separater Hardware oder Software ausgeführt werden müssen. Wenn außerdem ein einzelner Block mehr als eine Funktion in dem selben Block offenbart, müssen diese Funktionen nicht notwendigerweise in der selben Hardware und/oder Software ausgeführt sein. Beispielsweise kann ein Computer-„Speicher“ in manchen Fällen zwischen mehreren Cache-Ebenen oder lokalem Speicher, Hauptspeicher, batteriegepuffertem flüchtigen Speicher und unterschiedlichen Formen von Permanentspeichern, wie einer Festplatte, einem Speicherserver, einem optischen Datenträger, einem Bandlaufwerk oder Ähnlichem verteilt oder gemappt sein. In bestimmten Ausführungsformen können manche der Komponenten weggelassen oder zusammengelegt werden. Im Allgemeinen können die in den FIGUREN abgebildeten Anordnungen logischer repräsentiert sein, wohingegen eine physikalische Architektur verschiedene Permutationen, Kombinationen und/oder Hybride dieser Elemente umfassen kann. Es können zahllose mögliche Gestaltungskonfigurationen genutzt werden, um die hierin skizzierten operativen Ziele zu erreichen. Dementsprechend weist die damit verbundene Infrastruktur eine Vielzahl von Ersatzanordnungen, Gestaltungsentscheidungen, Vorrichtungsmöglichkeiten, Hardwarekonfigurationen, Softwareimplementierungen und Ausstattungsoptionen auf.
  • Hierin kann auf ein computerlesbares Medium verwiesen werden, bei dem es sich um ein materielles und nichttransitorisches computerlesbares Medium handeln kann. Wie in dieser Beschreibung und den Patentansprüchen verwendet, soll ein „computerlesbares Medium“ ein oder mehrere gleiche oder unterschiedliche computerlesbare Medien umfassend verstanden werden. Ein computerlesbares Medium kann als nichteinschränkendes Beispiel, einen optischen Datenträger (z.B. CD/DVD/Blu-Ray), eine Festplatte, eine Solid-State-Festplatte, einen Flash-Speicher oder ein anderes nichtflüchtiges Medium umfassen. Ein computerlesbares Medium kann außerdem ein Medium wie einen Nur-Lese-Speicher (ROM), FPGA oder ASIC, die konfiguriert sind, um die gewünschten Befehle auszuführen, gespeicherte Befehle für das Programmieren eines FPGA oder ASIC, um die gewünschten Befehle auszuführen, einen Intellektuelles-Eigentum- (IP-) Block, der in Hardware in anderen Schaltungen integriert sein kann, oder Befehle, die direkt in Hardware oder Mikrocode auf einem Prozessor, wie einem Mikroprozessor, digitalen Signalprozessor (DSP), Mikrosteuerung oder in einer anderen geeigneten Komponente, Vorrichtung, Element oder Objekt, je nach Eignung und spezifischen Anforderungen, kodiert sind. Ein nichttransitorisches Speichermedium hierin soll ausdrücklich beliebige nichttransitorische spezialisierte oder programmierbare Hardware umfassen, die konfiguriert ist, um die offenbarten Operationen bereitzustellen oder einen Prozessor dazu veranlassen, diese offenbarten Operationen durchzuführen.
  • Zahlreiche Elemente können „kommunikativ“, „elektrisch“, „mechanisch“ oder anderweitig miteinander in der gesamten Beschreibung und den Patentansprüchen „verbunden“ sein. Bei so einer Verbindung kann es sich um eine direkte, eine Punkt-zu-Punkt-Verbindung oder eine Verbindung, die dazwischengeschaltete Vorrichtungen umfasst, handeln. Beispielsweise können zwei Vorrichtungen kommunikativ miteinander über eine Steuerung verbunden sein, die die Kommunikation erleichtert. Vorrichtungen können elektrisch miteinander über dazwischengeschaltete Vorrichtungen, wie Signalbooster, Spannungsteiler oder Puffer, verbunden sein. Mechanisch verbundene Vorrichtungen können direkt oder indirekt mechanisch verbunden sein.
  • Ein beliebiges hierin offenbarte „Modul“ oder eine „Engine“ kann sich auf eine Software, einen Softwarestapel, eine Kombination aus Hardware, Firmware und/oder Software, eine Schaltung, die konfiguriert ist, um die Funktion der Engine oder des Moduls auszuführen oder ein beliebiges computerlesbares Medium, wie oben offenbart, beziehen oder diese umfassen. Solche Module oder Engines können unter geeigneten Umständen auf oder in Zusammenhang mit einer Hardwareplattform bereitgestellt sein, die Hardwarerechnerressourcen, wie einen Prozessor, Arbeitsspeicher, Speicher, Zwischenverbindungen, Netzwerke und Netzwerkschnittstellen, Beschleuniger und andere geeignete Hardware umfassen kann. So eine Hardwareplattform kann als einzelne monolithische Vorrichtung (z.B. in einem PC-Formfaktor) bereitgestellt sein oder wobei manche oder Teile der Funktion verteilt sind (z.B. ein „Verbundknoten“ in einem High-End-Rechenzentrum, indem Rechner-, Arbeitsspeicher-, Speicher- und andere Ressourcen dynamisch alloziert sein können und zueinander nicht lokal sein müssen).
  • Hierin können Flussdiagramme, Signalflussdiaramme oder andere Abbildungen offenbart sein, die in einer bestimmten Reihenfolge durchgeführte Operationen zeigen. Sofern nicht anderweitig angeführt oder sofern nicht in einem speziellen Kontext benötigt, soll die Reihenfolge lediglich als nichteinschränkendes Beispiel betrachtet werden. Außerdem können in Fällen, in denen eine Operation der nächsten folgt, auch andere eingreifende Operationen auftreten, die damit zusammenhängen oder nicht zusammenhängen. Manche Operationen können außerdem gleichzeitig oder parallel durchgeführt werden. In Fällen, in denen eine Operation „basierend auf“ oder „gemäß“ einem anderen Element oder einer Operation angeführt wird, ist damit implizit gemeint, dass die Operation zumindest teilweise auf dem anderen Element oder der Operation basiert oder dieser zumindest teilweise entspricht. Das soll nicht als implizite Feststellung ausgelegt werden, dass die Operation gänzlich oder ausschließlich auf dem Element oder der Operation basiert oder gänzlich oder ausschließlich dem Element oder der Operation entspricht.
  • Das Gesamte oder Teile eines hierin offenbarten Hardwarelements können einfach in einem System-on-a-Chip (SoC) bereitgestellt werden, das ein Gehäuse mit einer zentralen Verarbeitungseinheit (CPU) umfasst. Ein SoC stellt eine integrierte Schaltung dar (IC), die Komponenten eines Computers oder eines anderen elektronischen Systems in einen einzelnen Chip integriert. Daher können beispielsweise Client-Vorrichtungen oder Server-Vorrichtungen zur Gänze oder teilweise in einem SoC bereitgestellt werden. Das SoC kann digitale, analoge, Mischsignal- und Radiofrequenzfunktionen enthalten, von denen alle auf einem einzelnen Chipsubstrat bereitgestellt sein können. Andere Ausführungsformen können ein Multichip-Modul (MCM) mit einer Vielzahl von Chips umfassen, die sich in einem einzelnen elektronischen Gehäuse befinden und konfiguriert sind, um eng miteinander im elektronischen Gehäuse zu interagieren.
  • Im Allgemeinen kann eine beliebiger passend konfigurierter Schaltkreis oder Prozessor eine beliebige Art von Befehlen, die mit den Daten verbunden sind, ausführen, um die hierin beschriebenen Operationen zu erzielen. Ein beliebiger hierin offenbarter Prozessor kann ein Element oder einen Gegenstand (z.B. Daten) von einem Zustand in einen anderen Zustand oder Gegenstand zu transformieren. Darüber hinaus kann die in einem Prozessor erfasste, gesendete, empfangene oder gespeicherte Information in einer beliebigen Datenbank, einem Register, einer Tabelle, einem Cache, einer Warteschlange, Kontrollliste oder Speicherstruktur basierend auf den speziellen Anforderungen und Implementierungen bereitgestellt werden, von denen alle in einem angemessen Zeitrahmen referenziert werden können. Beliebige der hierin offenbarten Arbeitsspeicher- oder Speicherelemente sollen so ausgelegt werden, dass sie von den weitläufigen Begriffen „Arbeitsspeicher“ und „Speicher“, je nach Eignung, umfasst sind.
  • Computerprogrammlogik, die die ganze oder Teile der hierin beschriebenen Funktionalität implementiert, wird in unterschiedlichen Formen ausgeführt, einschließlich aber in keiner Weise ausschließlich einer Quellcodeform, einer computerausführbaren Form, Maschinenbefehlen oder Mikrocode, programmierbarer Hardware und zahlreicher Zwischenformen (zum Beispiel Formen, die von einem Assembler, Compiler, Linker oder Locator generiert werden).
  • In einem Beispiel umfasst Quellcode eine Reihe von Computerprogrammbefehlen, die in unterschiedlichen Programmiersprachen implementiert sind, wie einem Objektcode, einer Assemblersprache oder einer höheren Programmiersprache, wie OpenCL, FORTRAN, C, C++, JAVA oder HTML zur Verwendung in verschiedenen Betriebssystemen oder Betriebsumgebungen oder in Hardwarebeschreibungssprachen, wie Spice, Verilog und VHDL. Der Quellcode kann unterschiedliche Datenstrukturen und Kommunikationsnachrichten definieren und nutzen. Der Quellcode kann in einer computerausführbaren Form vorliegen (z.B. über einen Interpreter) oder der Quellcode kann in eine computerausführbare Form umgewandelt werden (z.B. durch einen Übersetzer, Assembler oder Compiler) oder in eine Zwischenform, wie Bytecode, umgewandelt werden. Wenn es angemessen erscheint, kann Beliebiges des Vorangegangenen genutzt werden, um geeignete diskrete oder integrierte Schaltungen zu bauen oder zu beschreiben, egal ob dies sequentiell, kombinatorisch, in Form von Zustandsmaschinen oder anderweitig erfolgt.
  • In einer beispielhaften Ausführungsform kann eine beliebige Anzahl von elektrischen Schaltungen der FIGURN auf einer Platine einer verbundenen elektronischen Vorrichtung implementiert werden. Bei der Platine kann es sich um eine üblicher Leiterplatte handeln, auf der unterschiedliche Komponenten des internen elektronischen Systems der elektronischen Vorrichtung angebracht werden können und die ferner Anschlüsse für andere Peripherievorrichtungen bereitstellt. Ein beliebiger geeigneter Prozessor und Arbeitsspeicher können passenderweise mit der Platine basierend auf den speziellen Konfigurationsanforderungen, Verarbeitungsvorgaben und Rechnergestaltungen verbunden sein. Es ist anzumerken, dass bei den zahlreichen hierin bereitgestellten Beispielen die Interaktion in Bezug auf zwei, drei, vier oder mehr elektrischen Komponenten beschrieben werden kann. Das wurde jedoch lediglich zum Zwecke der Klarheit und des Beispiels vorgenommen. Es gilt zu verstehen, dass das System auf beliebige geeignete Weise zusammengefügt oder umkonfiguriert werden kann. Entlang ähnlicher Gestaltungsalternativen können beliebige der veranschaulichten Komponenten, Module und Elemente der FIGURN in verschiedenen möglichen Konfigurationen kombiniert werden, von denen alle im weiten Schutzumfang dieser Beschreibung liegen.
  • Zahlreiche andere Veränderungen, Ersetzungen, Variationen, Abänderungen und Modifikationen können von Fachleuten auf dem Gebiet der Erfindung ermittelt werden und es ist beabsichtigt, dass die vorliegenden Offenbarung all diese Veränderungen, Ersetzungen, Variationen, Abänderungen und Modifikationen als in den Schutzumfang der beiliegenden Patentansprüche fallend umfasst. Um das United States Patent and Trademark Office (USPTO) und zusätzlich dazu sämtliche Leser und Leserinnen eines beliebigen Patents, das aufgrund dieser Anmeldung ausgegeben wird, bei der Interpretation der beigefügten Patentansprüche zu unterstützen, möchte der Anmelder anmerken, dass der Anmelder: (a) nicht beabsichtigt, dass jegliche beiliegende Patentansprüche Absatz sechs (6) von 35 U.S.C. Abschnitt 112 (pre-AIA) oder Absatz (f) des gleichen Abschnitts (post-AIA) geltend machen, wie sie zum Zeitpunkt des Einreichens hiervon bestehen, es sei denn die Wörter „Mittel zu“ oder „Schritte für“ werden in den bestimmten Ansprüchen spezifisch genutzt; und (b) nicht beabsichtigt, durch eine beliebige Aussage in der Beschreibung, die Offenbarung auf eine Weise einzuschränken, die nicht anderweitig ausdrücklich in den beiliegenden Patentansprüchen widergegeben wird.
  • Beispielhafte Ausführungen
  • Die folgenden Beispiele werden als Veranschaulichung bereitgestellt.
  • Beispiel 1 umfasst eine Rechnervorrichtung, die Folgendes umfasst: eine Hardwareplattform; und eine Interworking-Broker-Funktion (IBF), die auf der Hardwareplattform gehostet ist, wobei die IBF einen Übersetzungstreiber (TD) umfasst, der einer Altnetzwerkvorrichtung zugeordnet ist, das keine native Interoperabilität mit einem Orchestrator aufweist und die IBF konfiguriert ist, um: einen Netzwerkfunktionsbereitstellungs- oder -konfigurationsbefehl vom Orchestrator für die Altnetzwerkvorrichtung zu empfangen; den TD zu betreiben, um den Befehl in ein Format zu übersetzen, das von der Altnetzwerkvorrichtung aufgenommen werden kann; und den Befehl an die Altnetzwerkvorrichtung weiterzuleiten.
  • Beispiel 2 umfasst die Rechnervorrichtung aus Beispiel 1, wobei es sich bei dem Orchestrator um einen Management- und Orchestrierungs-(MANO-) konformen Orchestrator handelt.
  • Beispiel 3 umfasst die Rechnervorrichtung aus Beispiel 1, wobei die IBF ferner konfiguriert ist, um eine Nachricht von der Altnetzwerkvorrichtung zu empfangen und die Nachricht um TD in ein vom Orchestrator aufnehmbares Format zu übersetzen.
  • Beispiel 4 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um ein IP-Paket handelt.
  • Beispiel 5 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um eine asynchrone Transfermodus-(ATM-) oder Frame-Relay-Nachricht handelt.
  • Beispiel 6 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um eine Benachrichtigungs-, Ereignis- oder Telemetrienachricht handelt.
  • Beispiel 7 umfasst die Rechnervorrichtung aus Beispiel 6, wobei die Benachrichtigungs- oder Ereignisnachricht eine Simple-Network-Management-Protocol- (SNMP-) Trap umfasst.
  • Beispiel 8 umfasst die Rechnervorrichtung aus Beispiel 6, wobei die Benachrichtigungs- oder Ereignisnachricht ein IPFIX umfasst.
  • Beispiel 9 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um eine Nachricht im SNMP-Format handelt.
  • Beispiel 10 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um eine Simple-Object-Access-Protocol-(SOAP-), XML- oder JSON-Nachricht handelt.
  • Beispiel 11 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um eine NETCONF-Nachricht handelt.
  • Beispiel 12 umfasst die Rechnervorrichtung aus Beispiel 3, wobei es sich bei der Nachricht um einen Kommandozeilenschnittstellen-(CLI-) Befehl handelt.
  • Beispiel 13 umfasst die Rechnervorrichtung aus einem der Beispielen 1 - 12, wobei die IBF ferner konfiguriert ist, um: das Netzwerk im Hinblick auf die Altnetzwerkvorrichtung zu scannen; die Altnetzwerkvorrichtung auf Leistungsfähigkeitsinformation oder ein Messaging-Format abzufragen; und den TD basierend auf der Leistungsfähigkeitsinformation oder dem Messaging-Format aufzubauen.
  • Beispiel 14 umfasst die Rechnervorrichtung aus Beispiel 12, wobei die Leistungsfähigkeit oder das Messaging-Format MIB-Information umfasst.
  • Beispiel 15 umfasst die Rechnervorrichtung aus Beispiel 12, wobei die IBF ferner konfiguriert ist, um die Altnetzwerkvorrichtung dem TD zuzuordnen.
  • Beispiel 16 umfasst die Rechnervorrichtung aus Beispiel 12, wobei die IBF ferner konfiguriert ist, um den Orchestrator über die Altnetzwerkvorrichtung zu benachrichtigen.
  • Beispiel 17 umfasst ein oder mehrere materielle, nichttransitorische computerlesbare Medien, auf denen die Befehle für das Bereitstellen eines Interworking-Broker-Funktion (IBF) gespeichert sind, die einen Übersetzungstreiber (TD) umfasst, wobei die IBF konfiguriert ist, um: den TD einer Altnetzwerkvorrichtung zuzuordnen, die keine native Interoperabilität mit einem Orchestrator aufweist; einen Netzwerkfunktionsbereitstellungs- oder -konfigurationsbefehl für die Altnetzwerkvorrichtung vom Orchestrator zu empfangen; den TD zu betreiben, um den Befehl in ein von der Altnetzwerkvorrichtung aufnehmbares Format zu übersetzen; und den Befehl an die Altnetzwerkvorrichtung weiterzuleiten.
  • Beispiel 18 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 17, wobei es sich bei dem Orchestrator um einen Management- und Orchestrierungs-(MANO-) konformen Orchestrator handelt.
  • Beispiel 19 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 17, wobei die IBF ferner konfiguriert ist, um eine Nachricht von der Altnetzwerkvorrichtung zu empfangen und die Nachricht im TD in ein vom Orchestrator aufnehmbares Format zu übersetzen.
  • Beispiel 20 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um ein IP-Paket handelt.
  • Beispiel 21 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um eine asynchrone Transfermodus- (ATM-) oder Frame-Relay-Nachricht handelt.
  • Beispiel 22 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um eine Benachrichtigungs-, Ereignis- oder Telemetrienachricht handelt.
  • Beispiel 23 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 22, wobei die Benachrichtigungs- oder Ereignisnachricht eine Simple-Network-Management-Protocol- (SNMP-) Trap umfasst.
  • Beispiel 24 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei die Benachrichtigungs- oder Ereignisnachricht ein IPFIX umfasst.
  • Beispiel 25 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um eine Nachricht im SNMP-Format handelt.
  • Beispiel 26 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um eine Simple-Object-Access-Protocol- (SOAP-), XML- oder JSON-Nachricht handelt.
  • Beispiel 27 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um eine NETCONF-Nachricht handelt.
  • Beispiel 28 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 19, wobei es sich bei der Nachricht um einen Kommandozeilenschnittstellen- (CLI-) Befehl handelt.
  • Beispiel 29 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus einem der Beispiele 17 - 28, wobei die IBF ferner konfiguriert ist, um: das Netzwerk im Hinblick auf die Altnetzwerkvorrichtung zu scannen; die Altnetzwerkvorrichtung auf Leistungsfähigkeitsinformation oder ein Messaging-Format abzufragen; und den TD basierend auf der Leistungsfähigkeitsinformation oder dem Messaging-Format aufzubauen.
  • Beispiel 30 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 29, wobei die Leistungsfähigkeit oder das Messaging-Format MIB-Information umfasst.
  • Beispiel 31 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 29, wobei die IBF ferner konfiguriert ist, um die Altnetzwerkvorrichtung dem TD zuzuordnen.
  • Beispiel 32 umfasst das eine oder die mehreren materiellen, nichttransitorischen computerlesbaren Medien aus Beispiel 29, wobei die IBF ferner konfiguriert ist, um den Orchestrator über die Altnetzwerkvorrichtung zu benachrichtigen.
  • Beispiel 33 umfasst ein computerimplementiertes Verfahren zur Bereitstellung einer Interworking-Borker-Funktion (IBF) umfassend einen Übersetzungstreiber (TD), die Folgendes umfasst: das Zuordnen des TD zu einer Altnetzwerkvorrichtung, die keine native Interoperabilität mit einem Orchestrator aufweist; das Empfangen eines Netzwerkbereitstellungs- oder -konfigurationsbefehls vom Orchestrator für die Altnetzwerkvorrichtung; des Betreiben des TD, um den Befehl in ein von der Altnetzwerkvorrichtung aufnehmbares Format zu übersetzen; und das Weiterleiten des Befehls an die Altnetzwerkvorrichtung.
  • Beispiel 34 umfasst das Verfahren aus Beispiel 33, wobei es sich bei dem Orchestrator um einen Management- und Orchestrierungs-(MANO-) konformen Orchestrator handelt.
  • Beispiel 35 umfasst das Verfahren aus Beispiel 33, das ferner das Empfangen einer Nachricht von der Altnetzwerkvorrichtung um das Übersetzen der Nachricht im TD in ein vom Orchestrator aufnehmbares Format umfasst.
  • Beispiel 36 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um ein IP-Paket handelt.
  • Beispiel 37 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um eine asynchrone Transfermodus- (ATM-) oder Frame-Relay-Nachricht handelt.
  • Beispiel 38 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um eine Benachrichtigungs-, Ereignis- oder Telemetrienachricht handelt.
  • Beispiel 39 umfasst das Verfahren aus Beispiel 38, wobei die Benachrichtigungs- oder Ereignisnachricht eine Simple-Network-Management-Protocol- (SNMP-) Trap umfasst.
  • Beispiel 40 umfasst das Verfahren aus Beispiel 38, wobei die Benachrichtigungs- oder Ereignisnachricht ein IPFIX umfasst.
  • Beispiel 41 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um eine Nachricht im SNMP-Format handelt.
  • Beispiel 42 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um eine SOAP-, XML- oder JSON-Nachricht handelt.
  • Beispiel 43 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um eine NETCONF-Nachricht handelt.
  • Beispiel 44 umfasst das Verfahren aus Beispiel 35, wobei es sich bei der Nachricht um einen Kommandozeilenschnittstellen- (CLI-) Befehl handelt.
  • Beispiel 45 umfasst das Verfahren aus Beispiel 33, das ferner Folgendes umfasst: das Scannen des Netzwerks im Hinblick auf die Altnetzwerkvorrichtung; das Abfragen der Altnetzwerkvorrichtung für Leistungsfähigkeitsinformation oder ein Messaging-Format; und das Aufbauen des TD auf Basis der Leistungsfähigkeitsinformation oder dem Messaging-Format.
  • Beispiel 46 umfasst das Verfahren aus Beispiel 45, wobei die Leistungsfähigkeit oder das Messaging-Format MIB-Information umfasst.
  • Beispiel 47 umfasst das Verfahren aus Beispiel 45, wobei die IBF ferner konfiguriert ist, um den Orchestrator über die Altnetzwerkvorrichtung zu benachrichtigen.
  • Beispiel 48 umfasst eine Vorrichtung, die die Mittel zur Durchführung des Verfahrens aus einem der Beispiele 33 - 47 umfasst.
  • Beispiel 49 umfasst die Vorrichtung aus Beispiel 48, wobei die Mittel zur Durchführung des Verfahrens einen Prozessor und einen Arbeitsspeicher umfassen.
  • Beispiel 50 umfasst die Vorrichtung aus Beispiel 49, wobei der Arbeitsspeicher maschinenlesbare Befehle enthält, die bei ihrer Ausführung die Vorrichtung dazu veranlassen, das Verfahren aus einem der Beispiele 33 - 47 durchzuführen.
  • Beispiel 51 umfasst die Vorrichtung aus einem der Beispiele 48 - 50, wobei es sich bei der Vorrichtung um ein Computersystem handelt.
  • Beispiel 52 umfasst zumindest ein computerlesbares Medium, das Befehle umfasst, die bei ihrer Ausführung ein Verfahren implementieren oder eine Vorrichtung umsetzen, wie in einem der Beispiele 33 - 51 abgebildet.

Claims (25)

  1. Rechnervorrichtung, umfassend: eine Hardwareplattform; und eine Interworking-Broker-Funktion (IBF), die auf der Hardwareplattform gehostet ist, wobei die IBF einen Übersetzungstreiber (TD) umfasst, der einer Altnetzwerkvorrichtung zugeordnet ist, die keine native Interoperabilität mit einem Orchestrator aufweist, und die IBF konfiguriert ist, um: vom Orchestrator einen Netzwerkfunktionsbereitstellungs- oderkonfigurationsbefehl für die Altnetzwerkvorrichtung zu empfangen; den TD zu betreiben, um den Befehl in ein von der Altnetzwerkvorrichtung aufnehmbares Format zu übersetzen; und den Befehl an die Altnetzwerkvorrichtung weiterzuleiten.
  2. Rechnervorrichtung nach Anspruch 1, wobei es sich bei dem Orchestrator um einen Management- und Orchestrierungs- (MANO-) konformen Orchestrator handelt.
  3. Rechnervorrichtung nach Anspruch 1, wobei die IBF ferner konfiguriert ist, um eine Nachricht von der Altnetzwerkvorrichtung zu empfangen und die Nachricht im TD in ein vom Orchestrator aufnehmbares Format zu übersetzen.
  4. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um ein IP-Paket handelt.
  5. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um eine asynchrone Transfermodus- (ATM-) oder Frame-Relay-Nachricht handelt.
  6. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um eine Benachrichtigungs-, Ereignis- oder Telemetrienachricht handelt.
  7. Rechnervorrichtung nach Anspruch 6, wobei die Benachrichtigungs- oder Ereignisnachricht eine Simple-Network-Management-Protocol- (SNMP-) Trap umfasst.
  8. Rechnervorrichtung nach Anspruch 6, wobei die Benachrichtigungs- oder Ereignisnachricht ein IPFIX umfasst.
  9. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um eine Nachricht im SNMP-Format handelt.
  10. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um eine Simple-Object-Access-Protocol- (SOAP-), XML- oder JSON-Nachricht handelt.
  11. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um eine NETCONF-Nachricht handelt.
  12. Rechnervorrichtung nach Anspruch 3, wobei es sich bei der Nachricht um einen Kommandolinienschnittstellen- (CLI-) Befehl handelt.
  13. Rechnervorrichtung nach einem der Ansprüche 1-12, wobei die IBF ferner konfiguriert ist, um: das Netzwerk im Hinblick auf die Altnetzwerkvorrichtung zu scannen; die Altnetzwerkvorrichtung auf Leistungsfähigkeitsinformation oder ein Messaging-Format abzufragen; und den TD basierend auf der Leistungsfähigkeitsinformation oder dem Messaging-Format aufzubauen.
  14. Rechnervorrichtung nach Anspruch 12, wobei die Leistungsfähigkeit oder das Messaging-Format MIB-Information umfasst.
  15. Rechnervorrichtung nach Anspruch 12, wobei die IBF ferner konfiguriert ist, um die Altnetzwerkvorrichtung dem TD zuzuordnen.
  16. Rechnervorrichtung nach Anspruch 12, wobei die IBF ferner konfiguriert ist, um den Orchestrator über die Altnetzwerkvorrichtung zu benachrichtigen.
  17. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien, auf denen Befehle für die Bereitstellung einer Interworking-Broker-Funktion (IBF) gespeichert sind, die einen Übersetzungstreiber (TD) umfasst und konfiguriert ist, um: den TD einer Altnetzwerkvorrichtung zuzuordnen, die keine native Interoperabilität mit einem Orchestrator aufweist; einen Netzwerkfunktionsbereitstellungs- oder - konfigurationsbefehl für die Altnetzwerkvorrichtung vom Orchestrator zu empfangen; den TD zu betreiben, um den Befehl in ein von der Altnetzwerkvorrichtung aufnehmbares Format zu übersetzen; und den Befehl an die Altnetzwerkvorrichtung weiterzuleiten.
  18. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 17, wobei es sich bei dem Orchestrator um einen Management- und Orchestrierungs- (MANO-) konformen Orchestrator handelt.
  19. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 17, wobei die IBF ferner konfiguriert ist, um eine Nachricht von der Altnetzwerkvorrichtung zu empfangen und die Nachricht im TD in ein vom Orchestrator aufnehmbares Format zu übersetzen.
  20. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 19, wobei es sich bei der Nachricht um ein IP-Paket handelt.
  21. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 19, wobei es sich bei der Nachricht um eine asynchrone Transfermodus-(ATM-) oder Frame-Relay-Nachricht handelt.
  22. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 19, wobei es sich bei der Nachricht um eine Benachrichtigungs-, Ereignis- oder Telemetrienachricht handelt.
  23. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 22, wobei die Benachrichtigungs- oder Ereignisnachricht eine Simple-Network-Management-Protocol- (SNMP-) Trap umfasst.
  24. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 19, wobei die Benachrichtigungs- oder Ereignisnachricht ein IPFIX umfasst.
  25. Materielles nichttransitorisches computerlesbares Medium bzw. materielle nichttransitorische computerlesbare Medien nach Anspruch 19, wobei es sich bei der Nachricht um eine Nachricht im SNMP-Format handelt.
DE102018214007.3A 2017-09-27 2018-08-20 Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken Pending DE102018214007A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/716,890 US11469953B2 (en) 2017-09-27 2017-09-27 Interworking of legacy appliances in virtualized networks
US15/716,890 2017-09-27

Publications (1)

Publication Number Publication Date
DE102018214007A1 true DE102018214007A1 (de) 2019-03-28

Family

ID=65638351

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018214007.3A Pending DE102018214007A1 (de) 2017-09-27 2018-08-20 Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken

Country Status (2)

Country Link
US (3) US11469953B2 (de)
DE (1) DE102018214007A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107295049B (zh) * 2016-04-01 2020-07-24 中兴通讯股份有限公司 实现网络功能通信的架构、方法及装置
US10880210B2 (en) * 2018-12-26 2020-12-29 Juniper Networks, Inc. Cloud network having multiple protocols using virtualization overlays across physical and virtualized workloads
CN109842530A (zh) * 2019-04-15 2019-06-04 网易（杭州）网络有限公司 Vnf配置方法、装置、电子设备和计算机可读介质
JP7205620B2 (ja) * 2019-05-13 2023-01-17 日本電信電話株式会社 サービス提供方法及び装置
CN110958139B (zh) * 2019-11-20 2022-11-15 中移（杭州）信息技术有限公司 网络控制方法、编排器、控制器及计算机可读存储介质
CN111427749B (zh) * 2020-04-01 2023-07-11 山东汇贸电子口岸有限公司 一种openstack环境下针对ironic服务的监控工具及方法
GB202201065D0 (en) * 2022-01-27 2022-03-16 Microsoft Technology Licensing Llc Session border controller with dynamic reporting

Family Cites Families (108)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5909686A (en) 1997-06-30 1999-06-01 Sun Microsystems, Inc. Hardware-assisted central processing unit access to a forwarding database
US6526442B1 (en) * 1998-07-07 2003-02-25 Compaq Information Technologies Group, L.P. Programmable operational system for managing devices participating in a network
US6357003B1 (en) 1998-10-21 2002-03-12 Silicon Graphics, Inc. Advanced firmware boot sequence x86 computer system that maintains legacy hardware and software compatibility
US20050108518A1 (en) 2003-06-10 2005-05-19 Pandya Ashish A. Runtime adaptable security processor
US7685254B2 (en) 2003-06-10 2010-03-23 Pandya Ashish A Runtime adaptable search processor
US8838743B2 (en) 2004-02-13 2014-09-16 Intel Corporation Apparatus and method for a dynamically extensible virtual switch
JP4164467B2 (ja) 2004-03-26 2008-10-15 キヤノン株式会社 画像処理装置、画像処理制御方法、及びプログラム
US9058292B2 (en) 2004-12-29 2015-06-16 Intel Corporation System and method for one step address translation of graphics addresses in virtualization
US8885539B2 (en) 2005-01-26 2014-11-11 Hewlett-Packard Development Company, L.P. Configurable quality-of-service support per virtual access point (VAP) in a wireless LAN (WLAN) access device
US7688832B2 (en) 2005-01-28 2010-03-30 Cisco Technology, Inc. MPLS cookie label
US20070011444A1 (en) 2005-06-09 2007-01-11 Grobman Steven L Method, apparatus and system for bundling virtualized and non-virtualized components in a single binary
US20070050767A1 (en) 2005-08-31 2007-03-01 Grobman Steven L Method, apparatus and system for a virtual diskless client architecture
US8296759B1 (en) 2006-03-31 2012-10-23 Vmware, Inc. Offloading operations to a replicate virtual machine
US7814495B1 (en) 2006-03-31 2010-10-12 V Mware, Inc. On-line replacement and changing of virtualization software
US8619771B2 (en) 2009-09-30 2013-12-31 Vmware, Inc. Private allocated networks over shared communications infrastructure
US7822849B2 (en) * 2006-11-16 2010-10-26 Path Solutions, Inc. Apparatus and method for measuring and using response to SNMP requests to provide real-time network parameter estimates in a network management zone
WO2008121873A1 (en) 2007-03-29 2008-10-09 Vmware, Inc. Synchronization and customization of a clone computer
US8769185B2 (en) 2007-10-23 2014-07-01 Keicy Chung Computer storage device having separate read-only space and read-write space, removable media component, system management interface, and network interface
US7945436B2 (en) 2007-11-06 2011-05-17 Vmware, Inc. Pass-through and emulation in a virtual machine environment
US8140834B2 (en) 2008-02-26 2012-03-20 International Business Machines Corporation System, method and computer program product for providing a programmable quiesce filtering register
US8095773B2 (en) 2008-02-26 2012-01-10 International Business Machines Corporation Dynamic address translation with translation exception qualifier
US7983257B2 (en) 2008-07-18 2011-07-19 Emulex Design & Manufacturing Corporation Hardware switch for hypervisors and blade servers
US8776090B2 (en) 2009-02-17 2014-07-08 Broadcom Corporation Method and system for network abstraction and virtualization for a single operating system (OS)
EP2401683A4 (de) 2009-02-27 2015-07-29 Broadcom Corp Verfahren und system für die vernetzung virtueller maschinen
US8918631B1 (en) 2009-03-31 2014-12-23 Juniper Networks, Inc. Methods and apparatus for dynamic automated configuration within a control plane of a switch fabric
US8027354B1 (en) 2009-04-29 2011-09-27 Cisco Technology, Inc. Network consolidation for virtualized servers
US9031081B2 (en) 2009-08-06 2015-05-12 Broadcom Corporation Method and system for switching in a virtualized platform
CN104065555B (zh) 2009-09-24 2018-09-18 日本电气株式会社 虚拟服务器间通信识别系统和虚拟服务器间通信识别方法
US8271450B2 (en) 2009-10-01 2012-09-18 Vmware, Inc. Monitoring a data structure in a virtual machine and determining if memory pages containing the data structure are swapped into or out of guest physical memory
US8254261B2 (en) 2009-10-16 2012-08-28 Oracle America, Inc. Method and system for intra-host communication
CN102648455B (zh) 2009-12-04 2015-11-25 日本电气株式会社 服务器和流控制程序
US8701138B2 (en) * 2010-04-23 2014-04-15 Time Warner Cable Enterprises Llc Zone control methods and apparatus
US8589610B2 (en) 2011-05-31 2013-11-19 Oracle International Corporation Method and system for receiving commands using a scoreboard on an infiniband host channel adaptor
US8804752B2 (en) 2011-05-31 2014-08-12 Oracle International Corporation Method and system for temporary data unit storage on infiniband host channel adaptor
US8761187B2 (en) 2011-06-14 2014-06-24 Futurewei Technologies, Inc. System and method for an in-server virtual switch
US8719843B2 (en) 2011-07-27 2014-05-06 Intel Corporation Virtualizable and forward-compatible hardware-software interface
US8797914B2 (en) 2011-09-12 2014-08-05 Microsoft Corporation Unified policy management for extensible virtual switches
US9300531B2 (en) * 2011-12-12 2016-03-29 Openet Telecom Ltd. Systems, devices, and methods of orchestration and application of business rules for real-time control of subscribers in a telecommunications operator's network
US10091138B2 (en) 2012-02-21 2018-10-02 F5 Networks, Inc. In service upgrades for a hypervisor or hardware manager hosting virtual traffic managers
US9311122B2 (en) 2012-03-26 2016-04-12 Oracle International Corporation System and method for providing a scalable signaling mechanism for virtual machine migration in a middleware machine environment
CN103391232B (zh) 2012-05-11 2016-06-29 和沛科技股份有限公司 云端系统中的虚拟机器连线方法
US9092269B2 (en) 2012-06-21 2015-07-28 Microsoft Technology Licensing, Llc Offloading virtual machine flows to physical queues
US9154451B2 (en) 2012-08-21 2015-10-06 Advanced Micro Devices, Inc. Systems and methods for sharing devices in a virtualization environment
US9424199B2 (en) 2012-08-29 2016-08-23 Advanced Micro Devices, Inc. Virtual input/output memory management unit within a guest virtual machine
US9436636B2 (en) * 2012-12-10 2016-09-06 Avago Technologies General Ip (Singapore) Pte. Ltd. Structure for non-blocking serial attached SCSI infrastructure utilizing virtual pathways
US10341263B2 (en) 2012-12-10 2019-07-02 University Of Central Florida Research Foundation, Inc. System and method for routing network frames between virtual machines
US9336158B2 (en) 2013-02-26 2016-05-10 Oracle International Corporation Method and system for simplified address translation support for static infiniband host channel adaptor structures
US9176767B2 (en) 2013-04-11 2015-11-03 Cisco Technology, Inc. Network interface card device pass-through with multiple nested hypervisors
US9973375B2 (en) 2013-04-22 2018-05-15 Cisco Technology, Inc. App store portal providing point-and-click deployment of third-party virtualized network functions
US9674315B2 (en) 2013-05-07 2017-06-06 Futurewei Technologies, Inc. Methods for dynamically binding header field identifiers in a network control protocol
US9678769B1 (en) 2013-06-12 2017-06-13 Amazon Technologies, Inc. Offline volume modifications
US9680772B2 (en) 2013-09-09 2017-06-13 Vmware, Inc. System and method for managing configuration of virtual switches in a virtual machine network
WO2015061731A1 (en) 2013-10-27 2015-04-30 Advanced Micro Devices, Inc. Input/output memory map unit and northbridge
US9634948B2 (en) 2013-11-07 2017-04-25 International Business Machines Corporation Management of addresses in virtual machines
US9921867B2 (en) 2013-12-30 2018-03-20 Huawei Technologies Co., Ltd. Negotiation between virtual machine and host to determine executor of packet flow control policy with reduced address space
US9729578B2 (en) 2014-01-10 2017-08-08 Arista Networks, Inc. Method and system for implementing a network policy using a VXLAN network identifier
JP6345604B2 (ja) 2014-01-27 2018-06-20 アラクサラネットワークス株式会社 通信装置、拡張機能の移動方法、及び通信システム
EP3108617A4 (de) 2014-02-21 2017-10-25 Nokia Solutions and Networks Oy Paketflussoptimierung in einem netzwerk
US10110710B2 (en) * 2014-04-03 2018-10-23 Centurylink Intellectual Property Llc System and method for implementing extension of customer LAN at provider network service point
US20170063628A1 (en) * 2014-04-30 2017-03-02 Nokia Solutions And Networks Oy Function binding and selection in a network
US20150317169A1 (en) 2014-05-04 2015-11-05 Midfin Systems Inc. Constructing and operating high-performance unified compute infrastructure across geo-distributed datacenters
US10019275B2 (en) 2014-06-23 2018-07-10 Vmware, Inc. Hypervisor context switching using a trampoline scheme in processors having more than two hierarchical privilege levels
US9983832B1 (en) 2014-06-27 2018-05-29 EMC IP Holding Company LLC Storage processor with device cache providing physical memory for guest VM
KR20160033517A (ko) 2014-09-18 2016-03-28 한국전자통신연구원 인터럽트 컨트롤러를 위한 하이브리드 가상화 방법
US9584377B2 (en) * 2014-11-21 2017-02-28 Oracle International Corporation Transparent orchestration and management of composite network functions
US9798567B2 (en) 2014-11-25 2017-10-24 The Research Foundation For The State University Of New York Multi-hypervisor virtual machines
US9560018B2 (en) 2014-12-08 2017-01-31 Cisco Technology, Inc. Autonomic locator/identifier separation protocol for secure hybrid cloud extension
US9940259B2 (en) 2015-01-16 2018-04-10 International Business Machines Corporation Virtual disk alignment access
US9806950B2 (en) 2015-02-26 2017-10-31 Cisco Technology, Inc. System and method for automatically detecting and configuring server uplink network interface
US9594598B1 (en) 2015-06-12 2017-03-14 Amazon Technologies, Inc. Live migration for virtual computing resources utilizing network-based storage
US9722948B2 (en) 2015-06-26 2017-08-01 Nicira, Inc. Providing quality of service for containers in a virtualized computing environment
US10476845B2 (en) 2015-06-26 2019-11-12 Nicira, Inc. Traffic handling for containers in a virtualized computing environment
US10642753B1 (en) 2015-06-30 2020-05-05 Fireeye, Inc. System and method for protecting a software component running in virtual machine using a virtualization layer
US10223162B2 (en) 2015-07-27 2019-03-05 Advanced Micro Devices, Inc. Mechanism for resource utilization metering in a computer system
US9979639B2 (en) 2015-07-28 2018-05-22 Futurewei Technologies, Inc. Single network interface for multiple interface virtual network functions
US9870248B2 (en) 2015-08-13 2018-01-16 Red Hat Israel, Ltd. Page table based dirty page tracking
US10728096B2 (en) * 2015-10-02 2020-07-28 Arista Networks, Inc. Dynamic service device integration
US10348517B2 (en) * 2015-10-09 2019-07-09 Openet Telecom Ltd. System and method for enabling service lifecycle based policy, licensing, and charging in a network function virtualization ecosystem
US11288084B2 (en) 2015-10-22 2022-03-29 Ribbon Communications Operating Company, Inc. Isolated physical networks for network function virtualization
CN105262668A (zh) 2015-10-31 2016-01-20 四川理工学院 一种应用于云计算网络的防火墙配置
GB2545170B (en) 2015-12-02 2020-01-08 Imagination Tech Ltd GPU virtualisation
US10447728B1 (en) 2015-12-10 2019-10-15 Fireeye, Inc. Technique for protecting guest processes using a layered virtualization architecture
US9912774B2 (en) 2015-12-22 2018-03-06 Intel Corporation Accelerated network packet processing
US10048977B2 (en) 2015-12-22 2018-08-14 Intel Corporation Methods and apparatus for multi-stage VM virtual network function and virtual service function chain acceleration for NFV and needs-based hardware acceleration
US10445271B2 (en) 2016-01-04 2019-10-15 Intel Corporation Multi-core communication acceleration using hardware queue device
EP3223494A1 (de) * 2016-03-21 2017-09-27 Thomson Licensing Verfahren und vorrichtung zur verbindung zwischen netzwerken
US9967136B2 (en) 2016-03-28 2018-05-08 Dell Products L.P. System and method for policy-based smart placement for network function virtualization
CN108139982B (zh) 2016-05-31 2022-04-08 安华高科技股份有限公司 多信道输入/输出虚拟化
EP3264711B1 (de) 2016-06-28 2018-09-19 Virtual Open Systems Virtueller schalter für gemischte kritische mehrkammernetzwerkkommunikation
US10382392B2 (en) 2016-08-01 2019-08-13 Big Switch Networks, Inc. Systems and methods for network address translation
CN109074330B (zh) 2016-08-03 2020-12-08 华为技术有限公司 网络接口卡、计算设备以及数据包处理方法
US9949133B2 (en) 2016-08-05 2018-04-17 Nxgen Partners Ip, Llc Ultra-broadband virtualized telecom and internet
EP3507704A4 (de) 2016-08-30 2020-02-26 Ruckus Wireless, Inc. Datenebene einer virtuellen maschine mit dhcp-serverfunktionalität
US10402576B2 (en) 2016-08-30 2019-09-03 Red Hat Israel, Ltd. Safe physical function passthrough using virtual machine functions
US20180109471A1 (en) 2016-10-13 2018-04-19 Alcatel-Lucent Usa Inc. Generalized packet processing offload in a datacenter
US10721273B2 (en) 2016-10-26 2020-07-21 Mcafee Llc Automated security policy
US10757647B2 (en) * 2016-10-31 2020-08-25 Cisco Technology, Inc. Optimized channel selection for virtual access point (VAP) enabled networks
CN108243118B (zh) 2016-12-27 2020-06-26 华为技术有限公司 转发报文的方法和物理主机
US20180191607A1 (en) 2016-12-29 2018-07-05 Juniper Networks, Inc. Network service application and customer-aware virtualized network function placement
US11405335B2 (en) 2017-01-13 2022-08-02 Nicira, Inc. Managing network traffic in virtual switches based on logical port identifiers
WO2018152688A1 (en) 2017-02-22 2018-08-30 Intel Corporation Virtualization of process address space identifiers for scalable virtualization of input/output devices
US10367733B2 (en) 2017-03-30 2019-07-30 Nicira, Inc. Identifier-based virtual networking
US11157422B2 (en) 2017-03-31 2021-10-26 Intel Corporation Shared memory for intelligent network interface cards
US10999219B1 (en) 2017-06-19 2021-05-04 Juniper Networks, Inc. Automated packet switch type and host selection for efficient virtualized network function service chaining
US10534719B2 (en) 2017-07-14 2020-01-14 Arm Limited Memory system for a data processing network
CN116260776A (zh) 2017-10-24 2023-06-13 英特尔公司 硬件辅助的虚拟交换机
US10909066B2 (en) 2018-04-03 2021-02-02 Microsoft Technology Licensing, Llc Virtual RDMA switching for containerized applications
US11757773B2 (en) 2020-12-30 2023-09-12 Oracle International Corporation Layer-2 networking storm control in a virtualized cloud environment

Also Published As

Publication number Publication date
US11469953B2 (en) 2022-10-11
US20230013499A1 (en) 2023-01-19
US11818008B2 (en) 2023-11-14
US20190097889A1 (en) 2019-03-28
US20240015067A1 (en) 2024-01-11

Similar Documents

Publication Publication Date Title
DE102018214007A1 (de) Zusammenwirken von Altvorrichtungen in virtualisierten Netzwerken
DE112013000731B4 (de) Skalierbare virtuelle Geräte-Cloud
US10375121B2 (en) Micro-segmentation in virtualized computing environments
DE102018004111B4 (de) Rechensystem, computerlesbares medium und bedarfsskalierungsengine zum kommunikativen koppeln an einen prozessor
DE102015119893B4 (de) Multiplexen von vielen Client-Datenströmen über eine einzige Verbindung
DE112013006420B4 (de) Erweiterte Verbindungszusammenfassung (LAG) zur Nutzung in mehreren Switsches
DE112014000415B4 (de) Quantisierte Überlastbenachrichtigung in einem virtuellen Netzwerksystem
DE102013208431B4 (de) Großer verteilter Switch auf Fabric-Basis unter Verwendung virtueller Switches und virtueller Steuereinheiten
DE102015102871B4 (de) Technologien für verteilten Leitweglenkungstabellennachschlag
DE112011103082B4 (de) Mehrere virtuelle Maschinen mit gemeinsamer Nutzung einer einzigen IP-Adresse
DE112011103123B4 (de) Performance und leistungsoptimierte Computersystemarchitekturen und -verfahren, die eine leistungsoptimierte Tree-Fabric-Verdrahtung wirksam einsetzen
DE102013209372B4 (de) Ein für die Aggregation virtueller Ethernet-Ports (VEPA) geeignetes mandantenfähiges Overlay-Netzwerk
KR101714279B1 (ko) 폴리시 기반 데이터센터 네트워크 자동화를 제공하는 시스템 및 방법
DE112013002270B4 (de) Bereitstellen von Diensten für virtuellen Overlay-Netzwerkverkehr
DE69836271T2 (de) Mehrstufiges firewall-system
DE202015009244U1 (de) Routing von Datenverkehr innerhalb von und zwischen autonomen Systemen
DE102015113997A1 (de) Mechanismus für Verwaltungssteuerungen zum Lernen der Steuerebenenhierarchie in einer Datenzentrumsumgebung
DE102015119890A1 (de) Paralleles Verarbeiten von Service-Funktionen in Service-Funktionsketten
DE112013004828T5 (de) Bereitstellen von Diensten für virtuellen Overlay-Netzwerkverkehr
DE112019005826T5 (de) Lastverteilter Zugang zu verteilten Endpunkten unter Verwendung globaler Netzwerkadressen
DE112013001904B4 (de) Paketvermittlung auf der Ebene 2 ohne Nachschlagetabelle für Ethernet-Switches
DE202016107377U1 (de) Systeme zur Auslagerung von Netzwerkfunktionen über Paket-Trunking
DE112008003966T5 (de) Selektives Um-Abbilden einer Netzwerktopologie
DE202015009251U1 (de) Netzwerkpaketkapselung und Routing
DE102014117460A1 (de) Programmierbares verteiltes Networking

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012240000

Ipc: H04L0041000000

R130 Divisional application to

Ref document number: 102018010512

Country of ref document: DE