DE102015108145B4 - Lokale Dienstverkettung mit virtuellen Maschinen und virtualisierten Behältern in software-definierter Vernetzung - Google Patents

Lokale Dienstverkettung mit virtuellen Maschinen und virtualisierten Behältern in software-definierter Vernetzung Download PDF

Info

Publication number
DE102015108145B4
DE102015108145B4 DE102015108145.8A DE102015108145A DE102015108145B4 DE 102015108145 B4 DE102015108145 B4 DE 102015108145B4 DE 102015108145 A DE102015108145 A DE 102015108145A DE 102015108145 B4 DE102015108145 B4 DE 102015108145B4
Authority
DE
Germany
Prior art keywords
lsc
packet
container
virtual
vnic
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.)
Active
Application number
DE102015108145.8A
Other languages
English (en)
Other versions
DE102015108145A1 (de
Inventor
Trevor Cooper
Brian J. Skerry
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 DE102015108145A1 publication Critical patent/DE102015108145A1/de
Application granted granted Critical
Publication of DE102015108145B4 publication Critical patent/DE102015108145B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306—Intercommunication techniques
    • G06F15/17331—Distributed shared memory [DSM], e.g. remote direct memory access [RDMA]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/154—Networked environment

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren, das auf einer Rechenplattform (102) implementiert wird, auf der mehrere virtuelle Maschinen, VMs (112), oder virtualisierte Behälter, Behälter (606), laufen, wobei jede VM (112) oder jeder Behälter (606) eine virtuelle Netzschnittstellensteuereinheit, vNIC, umfasst, die mit einem virtuellen Koppler (109) in einem Software-definierten Netz, SDN, kommunikativ gekoppelt ist, wobei das Verfahren Folgendes umfasst:Implementieren einer lokalen Dienstkette, LSC, durch die mehrere Pakete jeweils sequentiell durch mehrere virtuelle Netzgeräte (136) hintereinander verarbeitet werden, wobei die virtuellen Netzgeräte (136) von den mehreren VMs (112) oder Behältern (606) beherbergt werden, wobei jedes virtuelle Netzgerät (136) dazu konfiguriert ist, einen oder mehrere Dienste für jedes der mehreren durch die LSC zu verarbeitenden Pakete durchzuführen; undÜbertragen von Paketdaten, die in den mehreren Paketen enthalten sind, zwischen VMs (112) oder Behältern (606) ohne Verwendung des virtuellen Kopplers (109).

Description

  • HINTERGRUNDINFORMATIONEN
  • Der Zugang zu Computernetzen wurde zu einem allgegenwärtigen Teil der heutigen Computernutzung. Ob auf ein lokales Netz (LAN) in einer Unternehmensumgebung zugegriffen wird, um auf gemeinsam genutzte Netzressourcen zuzugreifen, oder auf das Internet über das LAN oder einen anderen Zugangspunkt zugegriffen wird, scheint es, dass Benutzer immer bei mindestens einem Dienst angemeldet sind, auf den über ein Computernetz zugegriffen wird. Überdies hat die schnelle Ausdehnung von Diensten auf Cloudbasis zu einer noch weiteren Nutzung von Computernetzen geführt und es wird vorhergesagt, dass diese Dienste immer weitverbreiteter werden.
  • Die Vernetzung wird durch verschiedene Typen von Ausrüstung, einschließlich Routern, Kopplern, Brücken, Gateways und Zugangspunkten, erleichtert. Eine große Netzinfrastruktur umfasst typischerweise die Verwendung von Netzelementen der Telekommunikationsklasse, einschließlich Kopplern und Routern, die von Firmen wie z. B. Cisco Systems, Juniper Networks, Alcatel Lucent, IBM und Hewlett-Packard hergestellt werden. Solche Telekommunikationskoppler sind sehr raffiniert, wobei sie mit sehr hohen Bandbreiten arbeiten und eine fortschrittliche Leitweglenkungsfunktionalität bereitstellen sowie verschiedene Dienstqualitätsniveaus (QoS-Niveaus) unterstützen. Private Netze, wie z. B. lokale Netze (LANs) werden von Geschäfts- und Heimanwendern am üblichsten verwendet. Es ist auch üblich, dass viele Geschäftsnetze Firewalls auf Hardware- und/oder Softwarebasis und dergleichen verwenden.
  • In den letzten Jahren hat die Virtualisierung von Computersystemen ein schnelles Wachstum gesehen, insbesondere in Servereinrichtungen und Datenzentren. Unter einer herkömmlichen Methode betreibt ein Server eine einzelne Instanz eines Betriebssystems direkt auf physikalischen Hardwareressourcen, wie z. B. der CPU, des RAM, Speichervorrichtungen (z. B. Festplatte), Netzsteuereinheiten, E/A-Ports usw. Unter einer virtualisierten Methode unter Verwendung von virtuellen Maschinen (VMs) werden die physikalischen Hardwareressourcen verwendet, um entsprechende Instanzen von virtuellen Ressourcen zu unterstützen, so dass mehrere VMs auf den physikalischen Hardwareressourcen des Servers laufen können, wobei jede virtuelle Maschine ihre eigene CPU-Zuweisung, Speicherzuweisung, Speichervorrichtungen, Netzsteuereinheiten, E/A-Ports usw. umfasst. Mehrere Instanzen derselben oder verschiedener Betriebssysteme laufen dann auf den mehreren VMs. Durch die Verwendung eines Managers für virtuelle Maschinen (VMM) oder „Hypervisors“ können überdies die virtuellen Ressourcen dynamisch zugewiesen werden, während der Server läuft, was ermöglicht, dass VM-Instanzen hinzugefügt, abgeschaltet oder zweckentfremdet werden, ohne zu erfordern, dass der Server abgeschaltet wird. Dies schafft eine größere Flexibilität für die Servernutzung und eine bessere Nutzung von Serververarbeitungsressourcen, insbesondere für Mehrkern-Prozessoren und/oder Mehrprozessorserver.
  • Unter einer anderen Virtualisierungsmethode wird eine OS-Virtualisierung auf Behälterbasis verwendet, die virtualisierte „Behälter“ ohne Verwendung eines VMM oder Hypervisors verwendet. Anstelle des Beherbergens von separaten Instanzen von Betriebssystemen auf jeweiligen VMs teilt sich die OS-Virtualisierung auf Behälterbasis einen einzelnen OS-Kern über mehrere Behälter mit separaten Instanzen von System- und Softwarebibliotheken für jeden Behälter. Wie bei den VMs werden auch virtuelle Ressourcen jedem Behälter zugewiesen.
  • Der Einsatz von Software-definierter Vernetzung (SDN) und Netzfunktionsvirtualisierung (NFV) hat auch in den letzten paar Jahren ein schnelles Wachstum gesehen. Unter SDN wird das System, das Entscheidungen darüber trifft, wo Verkehr gesendet wird (die Steuerebene), für das zugrundeliegende System, das Verkehr zum ausgewählten Ziel weiterleitet (die Dateneben), abgekoppelt. SDN-Konzepte können verwendet werden, um die Netzvirtualisierung zu erleichtern, was ermöglicht, dass Dienstanbieter verschiedene Aspekte ihrer Netzdienste über Softwareanwendungen und APIs (Anwendungsprogrammschnittstellen) managen. Unter NFV können Netzdienstanbieter durch Virtualisieren von Netzfunktionen wie Softwareanwendungen Flexibilität in der Netzkonfiguration erlangen, was signifikante Vorteile, einschließlich Optimierung der verfügbaren Bandbreite, Kosteneinsparungen und schnellere Zeit bis zum Markt für neue Dienste ermöglicht.
  • Die „Dienstverkettung“ wird häufig im Zusammenhang mit SDN verwendet, um einen Fluss von Paketen zu beschreiben, die ein Netz durchqueren, die durch eine Reihe von Netzdienstelementen verarbeitet werden, die an verschiedenen physikalischen Rechenknoten implementiert werden. Wie hier verwendet, wird der Begriff „lokale Dienstverkettung“ (LSC) verwendet, um einen Fluss von Paketen zu beschreiben, die ein Netz durchqueren, das innerhalb eines Rechenknotens liegt, die durch eine Reihe von Netzdienstelementen verarbeitet werden, die in VMs oder virtualisierten Behältern implementiert werden. Unter der herkömmlichen Methode verwendet die LSC die Verwendung eines virtuellen Kopplers (VS) oder eines äquivalenten Mechanismus, um Pakete zwischen VMs zu vermitteln. Dieser Vermittlungsmechanismus erfordert Rechenressourcen und wirkt sich negativ auf die Durchsatzkapazität des Systems aus. Dieses Problem wird verschlimmert, wenn eine große Menge an Verkehr durch LSCs verarbeitet wird, da die Verarbeitung von jedem Paket mehrere Datenübertragungen über einen oder mehrere VSs beinhalten kann.
  • Aus der Druckschrift WO 2014/004060 A1 ist ein Aggregationsgerät bekannt, das eine Mehrzahl von virtuellen Netzwerkschnittstellenkarten umfasst. Die Netzwerkschnittstellenkarten kommunizieren mit einer Mehrzahl von Prozessgeräten, die jeweils zumindest eine virtuelle Maschine umfassen. Ferner ist ein Input-Output-Komplex vorgesehen, der logischen zwischen den virtuellen Netzwerkschnittstellenkarten und einer physischen Netzwerkschnittstellenkarte angeordnet ist. Der Input-Output-Komplex umfasst zumindest eine Proxy-Netzwerkschnittstellenkarte und einen virtuellen Koppler, wobei der virtueller Koppler Daten mit dem einem Prozessgerät über einen Kommunikationspfad austauscht, der von einer virtuellen Netzwerkschnittstellenkarte hergestellt wird zwischen einer der virtuellen Maschinen und einem der Proxy-Netzwerkschnittstellenkarten.
  • Die Druckschrift US 2011/0090915 A1 offenbart zwei virtuelle Maschinen, die unter Beteiligung des Hypervisors mittels virtueller Proxy-Schnittstellenkarten Daten untereinander austauschen können.
  • Figurenliste
  • Die vorangehenden Aspekte und viele der zugehörigen Vorteile dieser Erfindung werden leichter erkannt, wenn dieselbe mit Bezug auf die folgende ausführliche Beschreibung in Verbindung mit den begleitenden Zeichnungen besser verständlich wird, wobei sich gleiche Bezugszeichen auf gleiche Teile in den ganzen verschiedenen Ansichten beziehen, wenn nicht anders angegeben:
    • 1 ist ein schematisches Diagramm, das eine Architektur mit virtuellen Maschinen für eine Rechenplattform darstellt, die dazu konfiguriert ist, Paketverarbeitungsoperationen durch die Verwendung von LSCs durchzuführen;
    • 1a ist ein schematisches Diagramm, das eine gesteigerte Version der Rechenplattform von 1 darstellt, unter der Paketdaten direkt von einer Netzschnittstelle zu einem Empfangspuffer (Rx-Puffer) in einer virtuellen Netzschnittstellensteuereinheit (vNIC) übertragen werden;
    • 1b ist ein schematisches Diagramm, das eine Architektur für eine Rechenplattform mit virtualisierten Behältern darstellt, die dazu konfiguriert ist, Paketverarbeitungsoperationen durch die Verwendung von LSCs durchzuführen;
    • 2 ist ein Ablaufplan, der Operationen und eine Logik darstellt, die durch eine Software durchgeführt werden, die auf der Rechenplattform arbeitet, um die Implementierung von LSCs zu erleichtern.
    • 3 ist ein schematisches Diagramm, das weitere Details von Rx-FIFO-Warteschlangen im gemeinsam genutzten Speicherbereich der Architektur von 1 darstellt;
    • 4 ist ein Diagramm, das einen ersten Satz von beispielhaften Daten darstellt, die in den Flusstabellen der Architektur von 1 zum Implementieren von LSC-Operationen unter Verwendung von LSC-IDs enthalten sind;
    • 4a ist ein Diagramm, das einen zweiten Satz von beispielhaften Daten darstellt, die in den Flusstabellen der Architektur von 1 zum Implementieren von LSC-Operationen unter Verwendung von Fluss-IDs enthalten sind;
    • 4b ist ein Diagramm, das einen dritten Satz von beispielhaften Daten darstellt, die in den Flusstabellen der Architektur von 1 zum Implementieren einer vordefinierten LSC für alle Pakete, die an einem vordefinierten Netzport empfangen werden, enthalten sind;
    • 5 ist ein schematisches Diagramm einer ersten beispielhaften Hauptrechnerplattform-Hardware- und Hauptrechnerplattform-Softwarearchitektur mit virtuellen Maschinen, über die Aspekte der hier offenbarten Ausführungsformen implementiert werden können; und
    • 6 ist ein schematisches Diagramm einer zweiten beispielhaften Hauptrechnerplattform-Hardware- und Hauptrechnerplattform-Softwarearchitektur mit Behältern, die eine Virtualisierung auf Behälterbasis implementieren, über die Aspekte der hier offenbarten Ausführungsformen implementiert werden können.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Ausführungsformen von Verfahren, Software und einer Vorrichtung zum Implementieren der lokalen Dienstverkettung mit virtuellen Maschinen oder virtualisierten Behältern in Software-definierter Vernetzung werden hier beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um für ein gründliches Verständnis der hier offenbarten und erläuterten Ausführungsformen zu sorgen. Ein Fachmann auf dem Gebiet erkennt jedoch, dass die Erfindung ohne eines oder mehrere der spezifischen Details oder mit anderen Verfahren, Komponenten, Materialien usw. ausgeführt werden kann. In anderen Fällen sind gut bekannte Strukturen, Materialien oder Operationen nicht im Einzelnen gezeigt oder beschrieben, um es zu vermeiden, die Aspekte der Erfindung unklar zu machen.
  • Der Deutlichkeit halber können individuelle Komponenten in den Figuren hier auch durch ihre Bezeichnungen in den Figuren bezeichnet werden anstatt durch ein spezielles Bezugszeichen. Außerdem können Bezugszeichen, die auf einen speziellen Typ von Komponente (im Gegensatz zu einer speziellen Komponente) Bezug nehmen, mit einem Bezugszeichen, gefolgt von „(Typ)“ gezeigt sein, was „typisch“ bedeutet. Selbstverständlich ist die Konfiguration dieser Komponenten typisch für ähnliche Komponenten, die existieren können, die jedoch in den Zeichnungsfiguren der Einfachheit oder Deutlichkeit halber nicht gezeigt sind, oder anderweitige ähnliche Komponenten, die nicht mit separaten Bezugszeichen bezeichnet sind. Dagegen soll „(Typ)“ nicht als die Komponente, das Element usw. bedeutend aufgefasst werden, es wird typischerweise für ihre offenbarte Funktion, Implementierung, Zweck usw. verwendet.
  • Wie hier verwendet, können die Begriffe „virtuelles Gerät“, „virtuelles Netzgerät“, „Netzgerät“ oder einfach „Gerät“ austauschbar verwendet werden. Für den Zweck hier, einschließlich der Ansprüche, kann außerdem irgendein Gerät auf Softwarebasis in Bezug auf Software-definiertes Vernetzen oder das dazu konfiguriert ist, eine Netzfunktionsvirtualisierung zu implementieren, allgemeiner als „virtuelles Gerät“ bezeichnet werden, mit dem Verständnis, dass virtuelle Netzgeräte irgendein Netzgerät oder eine virtualisierte Entität umfassen, die dazu konfiguriert ist, eine Netzfunktionsvirtualisierung und/oder Operationen in Bezug auf Softwaredefinierte Vernetzung zu implementieren. Folglich umfassen die Begriffe virtuelles Gerät in der folgenden Beschreibung alle NFV-Geräte ebenso.
  • Gemäß Aspekten der hier beschriebenen Ausführungsformen wird der Paketdurchsatz durch Erzeugen eines „Durchtrieb“-Mechanismus beschleunigt, der ermöglicht, dass Pakete zwischen virtuellen Netzgeräten und ähnlichen SDN-Komponenten ohne Verwendung von virtuellen Kopplern übertragen werden. Dies wird teilweise über die Verwendung einer „lokalen Dienstverkettung“ (LSC) erleichtert, die hier verwendet wird, um einen Fluss von Paketen zu beschreiben, die ein Netz durchqueren, das sich innerhalb eines Rechenknotens befindet, unter dem die Pakete durch eine Reihe von Netzdienstelementen (z. B. virtuellen Netzgeräten) verarbeitet werden, die in mehreren virtuellen Maschinen oder virtualisierten Maschinen implementiert werden.
  • Als Beispiel und ohne Begrenzung zeigt 1 eine Architektur 100 für einen Rechenknoten (z. B. eine Rechenplattform wie z. B. einen Server), der dazu konfiguriert ist, Paketverarbeitungsoperationen durch die Verwendung von LSC durchzuführen. Die Architektur 100 umfasst eine Rechenplattform 102, die mit einer Netzschnittstelle 104 gekoppelt ist, die auf der Rechenplattform integriert (z. B. als Netzschnittstellensteuereinheit (NIC)) oder anderweitig wirksam mit der Rechenplattform gekoppelt sein kann (z. B. als PCIe-Karte (Peripheriekomponenten-Verbindungsexpress-Karte), die in einem PCIe-Erweiterungsschlitz installiert ist). Die Rechenplattform 102 umfasst ein Hauptrechner-Betriebssystem (OS) 106, das im OS-Speicher 107 läuft, der dazu konfiguriert ist, mehrere Anwendungen zu beherbergen, die in einem Anwendungsspeicherraum 108 laufen, die über dem Hauptrechner-OS 106 dargestellt sind. Dies umfasst einen virtuellen Koppler 109 und einen Hypervisor 110, der dazu konfiguriert ist, N virtuelle Maschinen 112 zu beherbergen, wie durch die mit VM1, VM2 und VMN bezeichneten virtuellen Maschinen dargestellt. Die Softwarekomponenten umfassen ferner eine SDN-Steuereinheit 114.
  • Die Netzschnittstelle 104 umfasst M Netzports 116, die mit Port1, Port2 ... PortM bezeichnet sind, wobei M dasselbe wie N oder davon verschieden sein kann. Jeder Netzport 116 umfasst einen Empfangspuffer (Rx-Puffer) 118 und einen Sendepuffer (Tx-Puffer) 120. Wie in den Figuren hier verwendet, können die Rx- und Tx-Puffer und Rx- und Tx-Warteschlangen, die dargestellt sind, auch gemeinsam angeordnete Rx- und Tx-Ports darstellen; um das Durcheinander zu verringern, sind die Rx- und Tx-Ports nicht separat dargestellt, aber der Fachmann auf dem Gebiet erkennt, dass jeder Rx- und Tx-Port einen oder mehrere Rx- und Tx-Puffer und/oder -Warteschlangen umfasst.
  • Im Allgemeinen kann eine Netzschnittstelle relativ kleine Rx- und Tx-Puffer umfassen, die in den Rx- und Tx-Ports implementiert werden, und dann größere Rx- und Tx-Puffer, die im Eingabe/Ausgabe-Speicher (IO-Speicher) an der Netzschnittstelle implementiert werden können, der über mehrere Rx- und Tx-Ports gemeinsam genutzt wird. In dem dargestellten Beispiel ist zumindest ein Abschnitt des IO-Speichers eine speicherabgebildete IO (MMIO) 122, die durch einen NIC-Treiber 124 im OS-Speicher 107 des Hauptrechner-OS 106 konfiguriert ist. Die MMIO 122 ist dazu konfiguriert, Direktspeicherzugriffs-Datenübertragungen (DMA-Datenübertragungen) zwischen Speicherpuffern in der MMIO 122 und Puffern im Systemspeicher auf der Rechenplattform 102 zu unterstützen, wie nachstehend genauer beschrieben.
  • Der virtuelle Koppler 108 ist eine Entität auf Softwarebasis, die dazu konfiguriert ist, SDN-Vermittlungsoperationen innerhalb der Rechenplattform 102 durchzuführen. Im dargestellten Beispiel umfasst der virtuelle Koppler 108 einen virtuellen Rx- und Tx-Port für jeden physikalischen Rx- und Tx-Port an der Netzschnittstelle 104 (z. B. für jeden Port1 - PortM) und einen virtuellen Rx- und Tx-Port für jede der virtuellen Maschinen VM 1 - VM N. Die virtuellen Ports auf der Netzschnittstellenseite sind als virtuelle Rx-Ports 126 und virtuelle Tx-Ports 127 dargestellt, während die virtuellen Ports auf der VM-Seite als virtuelle Rx-Ports 128 und virtuelle Tx-Ports 129 dargestellt sind. Wie weiter gezeigt, ist ein Teil von jedem der virtuellen Rx- und Tx-Ports 126, 127, 128 und 129 als einen gemeinsam genutzten Speicherbereich 134 des Systemspeicheradressenraums überlappend dargestellt (auch als gemeinsam genutzter Speicherraum bezeichnet). Außerdem sind Paare von virtuellen Rx- und Tx-Ports 130 und 132 ferner als sich in eine jeweilige virtuelle NIC (vNIC) erstreckend dargestellt, wie durch vNICI, vNIC2 und vNICN gezeigt, wobei die vNICs jeweiligen virtuellen Maschinen VM 1, VM 2 und VM N zugeordnet sind.
  • Jede der virtuellen Maschinen VM 1, VM 2 und VM N ist mit einem virtuellen Gerät 136 und drei Anwendungen 138 mit Angaben, die die entsprechende VM identifizieren, auf der das virtuelle Gerät und die Anwendungen laufen, gezeigt. Für die VM 1 ist beispielsweise das virtuelle Gerät als „Gerät 1“ bezeichnet und die Anwendungen sind als „Anwendung 1A“, „Anwendung 1B“ und „Anwendung 1C“ bezeichnet. Im Allgemeinen kann jedes virtuelle Gerät 136 über eine oder mehrere Anwendungen 138 implementiert werden und der Einschluss von drei Anwendungen dient nur für Erläuterungszwecke. Während des Betriebs der Rechenplattform 102 ist jedes der virtuellen Geräte 136 dazu konfiguriert, einen oder mehrere Paketverarbeitungsdienste durchzuführen. Überdies werden die Paketverarbeitungsdienste in einer verketteten Weise implementiert, wie durch die entsprechende LSC für den Paketfluss definiert, der jedem Paket zugeordnet ist.
  • Das Konzept von verketteten Paketverarbeitungsdiensten unter Verwendung von lokaler Dienstverkettung ist weiter in 1 über Operationen und Datenübertragungen weiter dargestellt, die in Verbindung mit der Verarbeitung eines Pakets 140 dargestellt sind, und mit weiterem Bezug auf einen Ablaufplan 200, der in 2 gezeigt ist. Das Paket 140 ist als IP-Paket (Internetprotokollpaket) dargestellt und diese beispielhafte Verwendung eines IP-Pakets bedeutet, dass das Paket eine IP-Adressierung verwendet, die teilweise verwendet wird, um zu bestimmen, wohin das Paket 140 im Netz weitergeleitet und wo es intern durch die Rechenplattform 102 bearbeitet wird. Wie in einem Block 202 des Ablaufplans 200 gezeigt, beginnt der Prozess damit, dass das Paket 140 vom Netz am Port1 der Netzschnittstelle 104 empfangen wird. Im Allgemeinen werden Paketdaten über die Verbindungen eines Netzes als Bitströme von Daten übertragen. Für ein Ethernet-Netz werden beispielsweise Paketdaten als Strom von Ethernet-Rahmen übertragen. Am Port1 werden Operationen der entsprechenden Bitübertragungsschicht (PHY) durchgeführt, um Ethernet-Pakete zu extrahieren, die die Paketdaten einkapseln, die durch die virtuellen Geräte 136 verarbeitet werden sollen. Die extrahierten Ethernet-Pakete werden im Rx-Puffer 118 des Port1 gepuffert.
  • Als nächstes werden in einem Block 204 IP-Pakete aus den Ethernet-Paketen extrahiert. Wahlweise können Pakete der Schicht 4 oder einer höheren Ebene extrahiert werden, wie geeignet. Im Allgemeinen können die Operationen des Blocks 204 durch entweder die Netzschnittstelle 104, durch Vernetzungskomponenten auf OS-Softwarebasis, die als Netzstapel 142 dargestellt sind, oder durch eine Kombination der beiden unter Verwendung eines geteilten Verarbeitungsschemas durchgeführt werden. Einige jüngere NICs unterstützen beispielsweise Paketverarbeitungsoperationen der Schicht 3 (IP) und können auch TCP-Paketverarbeitungsoperationen (Transaktionssteuerprotokoll-Paketverarbeitungsoperationen) unterstützen. Eine andere Paketverarbeitung der Schicht 4 und höher wird gewöhnlich über Software-Komponenten im Netzstapel 142 durchgeführt, obwohl diese auch durch eine NIC oder eine ähnliche Netzschnittstelle implementiert werden kann.
  • In einem Block 206 wird eine Flussklassifizierung des Pakets durchgeführt. Dies beinhaltet gewöhnlich das Untersuchen von entsprechenden Kopffeldern in einem Paketkopf oder in Paketköpfen, um einen Paketfluss zu identifizieren, zu dem ein empfangenes Paket gehört (falls vorhanden). Wie nachstehend genauer beschrieben, können in einigen Ausführungsformen Paketflussinformationen explizit in einem Paketkopffeld definiert werden. Die Paketflussklassifizierung kann auch unter Verwendung von Daten in mehreren Feldern durchgeführt werden, wie z. B. durch die Verwendung von gut bekannten N-Tupel-Paketklassifizierungstechniken.
  • Im Allgemeinen kann die Paketkopfuntersuchung unter Verwendung von einem oder mehreren der folgenden Schemen durchgeführt werden. In einer Ausführungsform werden Pakete von Rx-Puffern im Port 116 in einen Rx-Puffer 144 im OS-Speicher 107 einer DMA-Operation unterzogen (z. B. unter Verwendung einer DMA-Schreiboperation). In einer Ausführungsform werden beispielsweise Speicherräume in den NIC-Port-Rx-Puffern für FIFO-Warteschlangen (First-in-First-out-Warteschlangen) zugewiesen, die zirkulare FIFO-Zeiger verwenden, und der FIFO-Kopfzeiger zeigt auf das Paket, das in den Rx-Puffer 144 einer DMA-Operation unterzogen wird. Weitere Details dessen, wie FIFO-Warteschlangen arbeiten, gemäß einer Ausführungsform sind in 3 gezeigt und werden nachstehend beschrieben. Als Alternative wird nur der Paketkopf in den Rx-Puffer 144 einer DMA-Operation unterzogen. Als noch weitere Option werden die Paketkopfdaten „an der Stelle“ gelesen ohne Kopieren entweder der Paketdaten oder des Kopfs in den Rx-Puffer 144. In diesem Fall werden die Paketkopfdaten für eine kleine Anzahl von Paketen in einen Puffer, der dem Netzstapel 142 oder einem Flussklassifizierer 146 zugeordnet ist, im OS 106 gelesen. Für die Flussklassifizierung, die durch die Netzschnittstelle 104 durchgeführt wird, können ebenso die Paketkopfdaten an der Stelle gelesen werden; in diesem Fall ist jedoch der Puffer im Speicher an der Netzschnittstelle 104 angeordnet, der typischerweise von der MMIO 122 separat ist (nicht dargestellt).
  • Das Ergebnis der Flussklassifizierung gibt einen Flussidentifizierer (Fluss-ID) für das Paket zurück. In einer Ausführungsform wird der Fluss-ID zu einem Paketkopffeld für Pakete hinzugefügt, die ohne expliziten Fluss-ID empfangen werden, oder alternativ wird ein Fluss-ID-Kennzeichen angehängt (z. B. vorangestellt) oder das Paket wird in einer „Umhüllung“ eingekapselt, die ein Feld für den Fluss-ID umfasst.
  • Wie in 1 gezeigt, wird in der dargestellten Ausführungsform die Paketklassifizierung durch den Flussklassifizierer 146 durchgeführt. Wahlweise kann die Flussklassifizierung in der Netzschnittstelle 104 über einen ähnlichen Flussklassifizierer 146a durchgeführt werden. In einer Ausführungsform wird ein geteiltes Klassifzierungsschema implementiert, unter dem existierende Flüsse (z. B. vorher klassifizierte Flüsse) in der Netzschnittstelle 104 durch den Flussklassifizierer 146a identifiziert werden, während Pakete, die nicht zu einem existierenden Fluss gehören, zum Flussklassifizierer 146 zur Paketklassifizierung entsprechend einem neuen Paketfluss weitergeleitet werden. Informationen für den neuen Paketfluss werden dann zum Flussklassifizierer 146a geliefert. Unter einer anderen Ausführungsform ist die Liste der klassifizierten Flüsse, die durch einen Flussklassifizierer 146a unterhalten wird, geringer als eine vollständige Liste, die durch den Flussklassifizierer 146 unterhalten wird, und arbeitet ähnlich zu einem Speichercache, wo Flüsse, die zu jüngeren Paketen gehören, im Flussklassifizierer 146a an der NIC unterhalten werden und Flüsse für weniger neue Pakete ersetzt werden.
  • Wie im Block 206 weiter dargestellt, wird der Fluss-ID als Nachschlag in einer Flusstabelle 148 verwendet, die als Teil des virtuellen Kopplers 109 dargestellt ist. In einer Ausführungsform enthält die Flusstabelle eine Spalte von Fluss-IDs und eine Spalte von vNIC-Rx-Port-IDs, so dass in Anbetracht eines eingegebenen Fluss-ID der Nachschlag einen entsprechenden vNIC-Rx-Port-ID zurückgibt. Die Flusstabelle 148 kann auch einen LSC-ID enthalten, der für ein LSC-Kennzeichen oder ein Feld in der Paketumhüllung verwendet werden kann oder ansonsten dem Paket zugeordnet sein kann. Wahlweise kann ein LSC-Kennzeichen durch ein erstes virtuelles Gerät in einer lokalen Dienstkette hinzugefügt werden.
  • Zusätzlich zur Flusstabelle 148, die im virtuellen Koppler 109 implementiert wird, kann alles oder ein Abschnitt der Flusstabelle im Hauptrechner-OS 106 oder in der Netzschnittstelle 104 (von denen keines in 1 gezeigt ist) implementiert werden. In Ausführungsformen, die alles oder einen Abschnitt einer Flusstabelle in der Netzschnittstelle 104 verwenden, werden die Flusstabelleneinträge im Allgemeinen durch die Software im Hauptrechner-OS 106 bestimmt und über eine Schnittstelle gefüllt, die durch den NIC-Treiber 124 bereitgestellt wird.
  • Sobald der vNIC-Rx-Port-ID identifiziert ist, werden die Paketdaten in eine entsprechende Rx-Pufferadresse geschrieben. In dem in 1 dargestellten Beispiel ist dieser Rx-Port mit V1 Rx bezeichnet (der Rx-Port für vNIC 1 der virtuellen Maschine VM 1). In einer Ausführungsform werden die Paketdaten von einem Rx-Puffer im OS-Speicher 107 (nicht dargestellt) unter Verwendung einer Speicherschreiboperation kopiert, unter der Daten vom OS-Speicher-Rx-Puffer in die entsprechende Rx-Pufferadresse kopiert werden. In einer anderen Ausführungsform werden die Paketdaten vom Rx-Puffer des Port1 in der MMIO 122 direkt in den vNIC-Rx-Puffer unter Verwendung von DMA-Schreiben geschrieben. Für Pakete, deren Köpfe an der Stelle untersucht werden, kann beispielsweise ein direktes DMA-Schreiben durchgeführt werden.
  • In einer Ausführungsform werden die vNIC-Rx-Puffer als FIFO-Warteschlangen mit zirkularen FIFO-Zeigern implementiert. Details einer Ausführungsform, die diese Konfiguration verwendet, sind in 3 gezeigt. Wie in Richtung der Unterseite von 3 dargestellt, umfasst jeder vNIC-Rx-Port 130 eine zugehörige vNIC-Rx-FIFO-Warteschlange 300. Jede vNIC-Rx-FIFO-Warteschlange 300 umfasst einen Adressenraum, der in mehrere FIFO-„Schlitze“ unterteilt ist; unter der dargestellten Ausführungsform sind 256 Schlitze pro FIFO-Warteschlange vorhanden, aber dies ist nur erläuternd für ein Beispiel, da die Anzahl von FIFO-Schlitzen variieren kann. Die Größe, die für jeden FIFO-Schlitz verwendet wird, kann auch variieren. In einer Ausführungsform ist die Größe jedes FIFO-Schlitzes dieselbe wie die Größe einer Cache-Leitung, die für den Anwendungsspeicherraum 108 verwendet wird. Jede vNIC-Rx-FIFO-Warteschlange 300 umfasst ferner einen zirkularen FIFO-Kopfzeiger und einen zirkularen FIFO-Endzeiger. Der zirkulare FIFO-Kopfzeiger zeigt auf den FIFO-Schlitz, der sich gegenwärtig an der logischen „Oberseite“ der FIFO-Warteschlange befindet, während der Endzeiger auf einen FIFO-Schlitz zeigt, der der aktuellen logischen „Unterseite“ der FIFO-Warteschlange entspricht. Die Operationen der FIFO-Warteschlangen unter Verwendung von Kopf- und Endzeigern sind auf dem Fachgebiet gut bekannt, so dass weitere Details dieser Operationen hier nicht bereitgestellt werden.
  • In einer Ausführungsform wird jede vNIC über einen Satz von einem oder mehreren Softwaremodulen implementiert. Unter einer objektorientierten Konstruktion kann jede Rx-FIFO-Warteschlange als Instanz einer entsprechenden Klasse (z. B. Rx_FIFO_queue) implementiert werden. Wie gut bekannt ist, schaffen Klassen Verfahren zum Implementieren von Funktionen, die Klassenobjekte (z. B. Daten) verarbeiten, und Schnittstellen zum Leiten von Daten zu und Empfangen von Daten von anderen Softwarekomponenten (z. B. anderen Klassen).
  • In einer Ausführungsform wird eine DMA-Schreibanforderung zur Instanz Rx_FIFO_queue (Klasse) für die vNICI-Ro-FIFO-Warteschlange gesendet. In Reaktion auf das Empfangen der DMA-Schreibanforderung identifiziert ein Verfahren in der Rx_FIFO_queue-Instanz die Speicheradresse des FIFO-Schlitzes, auf den gegenwärtig durch den Endzeiger gezeigt wird, und gibt die Adresse an den DMA-Schreibanforderer zurück (z. B. ein eingebettetes Softwaremodul an der Netzschnittstelle 104). Eine DMA-Funktionseinheit oder dergleichen (nicht dargestellt) schreibt dann die Paketdaten von ihrer Stelle in der MMIO 122 in die Speicheradresse für den FIFO-Schlitz. Für Instanzen, in denen die Paketdaten sich über mehrere FIFO-Schlitze erstrecken, können mehrere DMA-Schreibvorgänge der Reihe nach durchgeführt werden. Für Erläuterungszwecke sind die Paketdaten als an die Unterseite der Darstellung der vNIC-Rx-Ports geschrieben gezeigt; der Fachmann auf dem Gebiet erkennt jedoch, dass der Ort in der Rx-FIFO-Warteschlange des Schlitzes, in den die Paketdaten geschrieben werden, die logische „Unterseite“ des FIFO-Puffers ist, auf die durch den FIFO-Endzeiger gezeigt wird.
  • Als nächstes wird in einem Block 207 ein Fluss-ID-Kennzeichen oder LSC-Kennzeichen an die Paketdaten angehängt. Wie in 3 gezeigt, enthalten in einer Ausführungsform die Daten, die in einen ersten FIFO-Schlitz (von einem oder mehreren Schlitzen, in die die Paketdaten geschrieben werden) geschrieben werden, ein Kennzeichen 302, das den Paketdaten vorangestellt wird, die einen Paketkopf 304 und Paket-Nutzinformationsdaten 306 umfassen. In einer Ausführungsform wird das Kennzeichen 302 verwendet, um es im LCS-Kennzeichen zu speichern (z. B. LSC-ID-Wert). Wahlweise kann das Kennzeichen 302 verwendet werden, um einen Fluss-ID zu speichern. Wie gut bekannt ist, kann die Größe eines IP-Pakets (oder anderer Typen von Paketen) variieren, während die Länge eines Paketprotokollkopfs im Allgemeinen gleich ist (wobei beachtet wird, dass einige Protokolle Paketköpfe mit optionalen Feldern definieren, die, wenn sie verwendet werden, die Kopflänge ändern). Angesichts der Paketgröße mit variabler Länge können die Paketdaten für ein gegebenes Paket in einen oder mehrere FIFO-Schlitze geschrieben werden.
  • Wie durch die Schleife dargestellt, die durch Start- und Endschleifenblöcke 208 und 218 begrenzt ist, werden mehrere Operationen für jedes virtuelle Gerät in einer lokalen Dienstkette durchgeführt, die einem gegebenen Paketfluss zugeordnet ist (oder alternativ, wie explizit durch einen LSC-ID in einem LSC-Kennzeichen identifiziert, Paketkopf oder Umhüllung). Jede LSC umfasst mehrere Dienste, die durch virtuelle Netzgeräte durchgeführt werden, die zusammen in einer Sequenz in einer Weise ähnlich zu einem Satz von Pipelinediensten verkettet sind. Beispieldienste können NAT-Dienste (Netzadressenumsetzungsdienste), Firewalldienste, Paketverarbeitungsdienste, WAN-Optimierung, virtueller privater Netz-Gateway, Videotranscodierung, Inhaltsverteilungsnetzdienste usw. umfassen. Für Erläuterungszwecke zeigt 1 eine verkettete Sequenz vom Gerät 1 zum Gerät 2 ... zum Gerät N. Dies ist jedoch nur beispielhaft, da die LSC irgendeine Kombination von Geräten durchqueren kann. Überdies muss die LSC nicht Geräte in einer ansteigenden Reihenfolge durchqueren (z. B. könnte eine LSC Gerät 3 zu Gerät 2 zu Gerät 5 ... sein). Es ist auch möglich, dass mehrere Geräte implementiert werden, um denselben Dienst oder Satz von Diensten durchzuführen. Alternativ kann ein gegebenes Gerät dazu konfiguriert sein, verschiedene Dienste für verschiedene Paketflüsse durchzuführen.
  • Mit Rückkehr zur Verarbeitungsschleife im Ablaufplan 200 werden in einem Block 210 die Paketverarbeitungsoperationen für den Fluss und/oder die LSC für das aktuelle virtuelle Gerät in der LSC-Kette durchgeführt. In einer Ausführungsform werden die Paketverarbeitungsoperationen an einem gegebenen Paket in der vNIC-Rx-FIFO-Warteschlange durchgeführt, auf die durch den FIFO-Kopfzeiger gezeigt wird. Einige virtuelle Geräte lesen die Paketdaten und führen eine Verarbeitung unter Verwendung dieser Daten durch (z. B. Weiterleiten der Paketdaten zu einer Verbraucheranwendung), während andere virtuelle Geräte die Paketdaten modifizieren können (z. B. Modifizieren von einem oder mehreren Feldern in einem Paketkopf). In Fällen, in denen die Paketdaten modifiziert werden, können die Paketdaten entweder an der Stelle modifiziert werden oder Paketdaten können in einen Puffer an der VM kopiert werden, die für das virtuelle Gerät (in 1 nicht gezeigt) zugewiesen ist, und dann modifiziert werden.
  • Mit Fortsetzung an einem Block 212 wird bei der Vollendung der Operationen, die durch ein gegebenes virtuelles Gerät durchgeführt werden, eine Feststellung hinsichtlich dessen durchgeführt, wohin die Paketdaten weitergeleitet werden sollen, so dass auf diese entweder durch ein nächstes virtuelles Gerät in der LSC zugegriffen werden kann, oder wenn das aktuelle virtuelle Gerät das letzte virtuelle Gerät in der LSC ist, zu welchem Tx-Netzport das Paket weiterzuleiten ist. In einer Ausführungsform wird dies unter Verwendung des LSC-Kennzeichenwerts als Nachschlag in einer lokalen Flusstabelle 150 durchgeführt. Wahlweise kann die lokale Flusstabelle vielmehr Fluss-IDs als oder zusätzlich zu LSC-Kennzeichenwerten enthalten. Im Allgemeinen können lokale Flusstabellen 150 in einer ähnlichen Weise zur Flusstabelle 148 konfiguriert sein; anstatt auf den vNIC-Rx-Port (oder die Rx-FIFO-Warteschlange) für die VM, die das erste virtuelle Gerät in der LSC beherbergt, zu zeigen, zeigt jedoch die lokale Flusstabelle auf den vNIC-Rx-Port (oder die Rx-FIFO-Warteschlange) für die VM, die das nächste virtuelle Gerät in der LSC beherbergt. Es wird auch angemerkt, dass die Flusstabelle 148 Informationen enthalten kann, die Nicht-LSC-Flüsse betreffen (oder ansonsten können solche Informationen in einer separaten Tabelle unterhalten werden, die für den virtuellen Koppler 109 zugänglich ist).
  • Unter der herkömmlichen Methode werden VMs separate Speicherräume zugewiesen und Daten werden zwischen diesen separaten Speicherräumen durch die Verwendung von virtuellen Kopplern übertragen. Dies hat zuerst das Kopieren der Daten in einen vNIC-Tx-Port, das Weiterleiten der Daten zu einem Rx-Port des virtuellen Kopplers (über Speicherschreiben), das Bestimmen des vNIC-Rx-Ports über den virtuellen Koppler, in den die Daten geschrieben werden sollen, das Kopieren oder Schreiben der Daten in den Tx-Port des virtuellen Kopplers, der mit diesem vNIC-Rx-Port verbunden ist, und dann das Schreiben der Daten in den vNIC-Rx-Port zur Folge. In der Praxis findet jeder dieser Schreibvorgänge in einen Puffer wie z. B. eine FIFO-Warteschlange statt und die Vermittlungsprozesse beinhalten eine signifikante Menge an Mehraufwand. Wenn mehrere Paketflüsse gleichzeitig vermittelt werden, besteht überdies ein Potential für einen Stau an einem oder mehreren der Ports des virtuellen Kopplers.
  • Um die herkömmliche Operation des virtuellen Kopplers besser zu verstehen, soll eine Paketverarbeitungssequenz betrachtet werden, die Operationen beinhaltet, die durch eine Reihe von virtuellen Netzgeräten A, B, C und D durchgeführt werden, von denen jedes eine oder mehrere Operationen in Bezug auf die Pakete, die es empfängt, durchführt. Diese Operationen werden verkettet, so dass eine Sequenz von Operationen a, b, c und d durch jeweilige virtuelle Netzgeräte A, B, C und D durchgeführt wird und jedes der virtuellen Netzgeräte durch eine separate VMA-D beherbergt wird, die mit einem virtuellen Koppler S verbunden ist. Unter der existierenden Methode würde der Paketfluss wie folgt behandelt werden: VMA zu S zu VMB zu S zu VMC zu S zu VMD. Jede Übertragung zu und vom virtuellen Koppler S erfordert die Verwendung von separaten Empfangs- und Sendepuffern/Warteschlangen, die für separate Ports des virtuellen Kopplers implementiert werden, mit denen virtuelle Maschinen VMA, VMB, VMC und VMD jeweils verbunden sind.
  • Gemäß einem Aspekt der Ausführungsformen hier wird ein „Durchtreib“-Mechanismus implementiert, unter dem Daten direkt von einem ersten vNIC-Rx-Puffer (z. B. vNIC-Rx-FIFO-Warteschlange) oder einem Puffer an einer VM, die ein virtuelles Gerät beherbergt, das einen aktuellen Dienst in einer LSC durchführt, in den vNIC-Rx-Puffer (z. B. vNIC-Rx-FIFO-Warteschlange) der VM, die das virtuelle Gerät beherbergt, das den nächsten Dienst in der LSC durchführen soll, geschrieben werden. Dies wird teilweise durch die Verwendung des gemeinsam genutzten Speicherbereichs 134 erleichtert: da die vNIC-Rx-FIFO-Warteschlangen sich in einem gemeinsam genutzten Speicherbereich befinden, der für alle VMs zugänglich ist, kann irgendeine VM in die vNIC-Rx-FIFO-Warteschlange von irgendeiner anderen VM schreiben in einer Weise, die den virtuellen Koppler umgeht. Dies schafft eine signifikante Verringerung der Speicherübertragungen ebenso wie es entsprechende Latenzen beseitigt, die während virtuellen Vermittlungsoperationen erlitten werden.
  • Wie durch einen Entscheidungsblock 214 dargestellt, geht, wenn der nächste Puffer eine vNIC-Rx-FIFO-Warteschlange ist, die Ablaufplanlogik zu einem Block 216 weiter, in dem Paketdaten direkt in die identifizierte vNIC-Rx-FIFO-Warteschlange geschrieben werden, wobei somit der virtuelle Koppler 134 umgangen wird. Wie vorher und wie dargestellt, werden die Paketdaten in die Unterseite der vNIC-Rx-Port-Darstellung geschrieben. Auch wie vorher kann dies durch Schreiben der Daten in eine Adresse des Schlitzes in der Rx-FIFO-Warteschlange durchgeführt werden, auf die gegenwärtig durch den FIFO-Endzeiger gezeigt wird.
  • Wenn der Fluss-ID-Nachschlag im Block 212 den nächsten Puffer als Netz-Tx-Port identifiziert, geht die Ablaufplanlogik zu einem Block 220 weiter, in dem ein DMA-Schreiben der Paketdaten von dem (den) aktuellen vNIC-Rx-FIFO-Schlitz(en) (oder lokalen Puffer, wenn er dem aktuellen virtuellen Gerät zugeordnet ist) in den Netz-Tx-Puffer, der im Adressenraum von MMIO 122 angeordnet ist, stattfindet. In dem in 1 dargestellten Beispiel ist dies als direkte Übertragung von Paketdaten von der Rx-FIFO-Warteschlange von vNICN zum Tx-Puffer von PortM an der Netzschnittstelle 104 dargestellt. Alternativ können anstatt einer direkten DMA-Datenübertragung die Paketdaten durch den virtuellen Koppler 109 weitergeleitet werden. In einer Ausführungsform werden die Paketdaten direkt von der vNICN-Rx-FIFO-Warteschlange (oder einem Puffer an der VM N) zum Netz-Tx-Puffer am virtuellen Koppler kopiert (anstatt über den vNICN Tx-Port weitergeleitet zu werden).
  • Wie in der unteren rechen Ecke von 1 dargestellt, wird ein Paket 152 vom Tx-Port von PortM in das Netz übertragen. Im Allgemeinen können sich die Köpfe der Pakete 140 und 152 unterscheiden, während die Paket-Nutzinformationsdaten gleich bleiben können. Ein oder mehrere Felder im Paketkopf für ein gegebenes Paket können beispielsweise während der LSC-Verarbeitungsoperationen geändert werden, die durch die virtuellen Geräte durchgeführt werden. In einigen Fällen können die Paket-Nutzinformationsdaten sich auch infolge von Diensten, die durch eine LSC durchgeführt werden, ändern.
  • Die vorangehende Verarbeitung des Pakets 140 stellt eine Technik zum Verarbeiten von Paketen auf einer Basis pro Fluss dar. In einer Ausführungsform ist die SDN-Steuereinheit 114 dazu konfiguriert, den Fluss-ID und/oder LSC-Daten zu managen, die von der Flusstabelle 148 und lokalen Flusstabellen 150 verwendet werden. Pakete für einen gegebenen Paketfluss können unter Verwendung einer LSC mit einer verketteten Sequenz von Diensten bedient werden, die durch jeweilige virtuelle Geräte durchgeführt werden, wie vorstehend erörtert. In einer Ausführungsform wird ein Eingangspunkt (z. B. ein Eintritts-Rx-Port, Rx-Puffer oder eine Rx-FIFO-Warteschlange) für einen Fluss-ID oder LSC-ID in einer Flusstabelle verwendet, um den nächsten Eingangspunkt für die Dienstkette (z. B. den nächsten Rx-Port, Rx-Puffer oder Rx-FIFO-Warteschlange) nachzuschlagen. Folglich können die Flusstabellen im Allgemeinen zwei oder mehr Spalten umfassen, wobei eine den Fluss-ID oder LSC-ID enthält und die andere den nächsten Eingangspunkt enthält. In einer anderen Ausführungsform wird ein Fluss-ID verwendet, um ein Paket, das vom Netz empfangen wird, zu einem ersten virtuellen Gerät weiterzuleiten, das dann eine Abbildung vom Fluss-ID auf den LSC-ID durchführt und ein LSC-Kennzeichen an das Paket für die Weiterverarbeitung anhängt.
  • LSCs, die in einer flussweisen Implementierung verwendet werden, können entweder durch die SDN-Steuereinheit 114 vorkonfiguriert oder bestimmt werden, wenn ein Fluss zum ersten Mal auftritt. Gemäß dem OpenFlow-Protokoll können beispielsweise Paketflüsse und entsprechende LSCs während Laufzeitoperationen bestimmt werden. Die spezielle Sequenzkette für die LSC kann durch die Logik in der SDN-Steuereinheit, die Logik in einer anderen Komponente wie z. B. eine zentrale SDN-Steuereinheit (z. B. Koordinator) oder dergleichen oder eine Kombination von SDN-Steuereinheits-Komponenten und verwandten Komponenten bestimmt werden.
  • 4 stellt einen Satz von beispielhaften Tabellendaten für Flusstabellen 148, Tabelle 1, Tabelle 2 und Tabelle N dar. Die Flusstabelle 148 umfasst eine Fluss-ID-Spalte, die Fluss-IDs enthält, eine Eintrittsportspalte, die Eintrittsport-IDs enthält, und eine LSC-ID-Spalte, die LSC-IDs enthält. Jede von Tabelle 1, Tabelle 2 und Tabelle N umfasst eine LSC-ID-Spalte, eine Spalte des nächsten Ports und eine Dienstspalte. In einer Ausführungsform werden die Tabellendaten für jede der Tabellen 148, Tabelle 1, Tabelle 2 und Tabelle N, durch die SDN-Steuereinheit 114 gemanagt. Im Allgemeinen können die Tabellendaten während der Initialisierung der Rechenplattform und/oder während Laufzeitoperationen eingefüllt werden.
  • In einer Ausführungsform werden die Tabellendaten wie folgt implementiert. In Verbindung mit der Flussklassifizierung wird ein Fluss-ID für das Paket bestimmt. Dieser wird als Nachschlag für die Flusstabelle 148 verwendet. Aus dem Fluss-ID kann der Eintrittsport der VM, die das erste virtuelle Gerät in der Dienstkette beherbergt, bestimmt werden. Der LSC-ID kann auch bestimmt werden. Als Option kann die Flusstabelle 148 keine LSC-ID-Spalte umfassen und die Abbildung vom Fluss-ID auf den LSC-ID wird durch das erste virtuelle Gerät in jeder LSC durchgeführt.
  • Wie gezeigt, muss der Eintrittsport nicht für jeden Fluss derselbe sein. In Abhängigkeit von den Diensten, die durchgeführt werden sollen, kann eine LSC ein oder mehrere virtuelle Geräte überspringen. Die von einem gegebenen virtuellen Gerät durchgeführten Dienste können in Abhängigkeit von dem LSC-ID auch unterschiedlich sein. Die Verwendung von „A“, „B“ und „C“ in den Dienstspalten entspricht Diensten, die vom virtuellen Gerät durchgeführt werden, dem jede Flusstabelle 150 entspricht. Der Einschluss der Dienstspalte ist optional, da unter einer gewissen Implementierung ein gegebenes virtuelles Gerät dieselben Dienste für alle LSCs (oder Flüsse) durchführt, für die es einen Dienst bereitstellt. Außerdem kann sich der Austrittsport am Netzadapter/NIC auch in Abhängigkeit von der speziellen LSC unterscheiden.
  • 4a stellt ein alternatives Flusstabellenschema dar, das vielmehr Fluss-IDs für Flusstabellen 150 als LSC-IDs verwendet. Die Abbildung des Fluss-ID auf die LSC wird intern durch die SDN-Steuereinheit 114 durchgeführt, so dass Fluss-IDs anstelle von LSC-IDs verwendet werden können. Der Rest der Verarbeitungslogik bleibt gleich.
  • Zusätzlich zur flussweisen lokalen Dienstverkettung kann eine Rechenplattform vorkonfiguriert sein, um denselben Satz von Diensten durchzuführen (und folglich dieselbe LSC zu implementieren) für alle Pakete, die von einer Netzschnittstelle empfangen werden, oder alle Pakete, die an einem vorbestimmten Port der Netzschnittstelle empfangen werden. 4b zeigt beispielhafte Tabellendaten in einer Flusstabelle 148a, Flusstabelle1, Flusstabelle2 und FlusstabelleN, um eine einzelne, vorbestimmte LSC zu implementieren. Wie dargestellt, ist der Eintrittsport für alle Flüsse vNIC1-Rx. Unterdessen ist der nächste Port für jedes virtuelle Gerät der vNIC-Rx-Port für das nächste virtuelle Gerät in der LSC. Für Erläuterungszwecke sind Flusstabellendaten zum Implementieren einer vorbestimmten LSC gezeigt. In der Praxis könnten andere Techniken verwendet werden, wie z. B. Konfigurieren von Softwarevariablen und/oder Softwarebefehlen, um die vorbestimmte LSC zu implementieren. Die Software könnte beispielsweise in jede der virtuellen Maschinen heruntergeladen werden, um die LSC ohne Verwendung von Flusstabellen zu implementieren. Ebenso könnte ein Netzadapter oder eine NIC dazu konfiguriert sein, alle Pakete zum Eintritts-vNIC-Rx-Port für die LSC weiterzuleiten (z. B. über DMA-Schreiben).
  • 1a stellt die Verarbeitung eines Pakets 140 unter Verwendung einer vorbestimmten LSC dar. Wie dargestellt, wird das Paket 140 vom Rx-Port des Port1 zum Rx-Port der vNIC1 einer DMA-Operation unterzogen, wobei beliebige Operationen umgangen werden, die vorher durch das Hauptrechner-OS 106 durchgeführt worden sein können, und auch der virtuelle Koppler 109 umgangen wird. Unter einer anderen Ausführungsform können Pakete von der Netzschnittstelle zum Rx-Puffer 144 und dann zum Rx-Port der vNIC1 einer DMA-Operation unterzogen werden.
  • Gemäß einem anderen Verfahren werden LSCs unter Verwendung von Metadaten implementiert, die zum Paketkopf hinzugefügt werden. Unter dieser Technik kann eine Entität (z. B. ein Koordinator oder dergleichen) an einer externen Plattform die Elemente der ganzen Dienstkette bestimmen, dann sobald die Dienstkette die Plattform mit der LSC erreicht, verwendet die auf dieser Plattform arbeitende Software diese Metadaten, um den Paketfluss zu bestimmen. In dieser Weise könnte eine LSC mit einer größeren Dienstkette zusammenarbeiten, die über virtuelle Geräte implementiert wird, die auf mehreren Plattformen arbeiten.
  • Im Allgemeinen kann es in einem Netzfunktionsvirtualisierungssystem, in dem eine VM-Anordnung durch einen Koordinator durchgeführt wird, vorteilhaft sein, dass ein Koordinator VMs, die die virtuellen Geräte einer Dienstkette beherbergen, in eine einzelne physikalische Plattform instantiiert, so dass die innewohnenden Vorteile der Implementierung von lokalen Dienstketten gemäß den Ausführungsformen hier ausgenutzt werden können. Da beispielsweise dieselben Dienste für jedes Paket für einen gegebenen Fluss in einer Pipelineweise durchgeführt werden, kann das potentielle Problem des FIFO-Überlaufs (kein Raum in einer FIFO-Warteschlange, um mehr Paketdaten hinzuzufügen) durch die Verwendung von FIFO-Warteschlangen mit geeigneter Größe beseitigt werden. Diese Methode beseitigt auch irgendwelche Latenzen, die infolge von Verkehrsstau in einem virtuellen Koppler auftreten können; solche Latenzen führen zur Verringerung der Verarbeitungsleistung der ganzen Dienstkette, da eine Latenz für ein einzelnes Paket zu einer Verarbeitungslatenz für alle nachfolgenden Pakete führt.
  • Es wird angemerkt, dass, obwohl FIFO-Warteschlangen in den Zeichnungen dargestellt und hier beschrieben sind, es möglich ist, andere Typen von Warteschlangen zu verwenden, wie sie auf dem Fachgebiet bekannt sind. Für verkettete Operationen schaffen jedoch FIFO-Warteschlangen innewohnende Vorteile durch ihre Einfachheit und ihren mangelnden Mehraufwand. Obwohl eine einzelne FIFO-Warteschlange für jeden vNIC-Rx-Port gezeigt ist, können ferner eine oder mehrere FIFO-Warteschlangen verwendet werden. Separate FIFO-Warteschlangen können beispielsweise für jeweilige Flüsse und/oder LSCs verwendet werden.
  • Computerplattformen können auch dazu konfiguriert sein, sowohl LSC-Flüsse als auch Nicht-LSC-Flüsse zu unterstützen. Während der Flussklassifizierung kann beispielsweise ein Paket als zu einem Fluss gehörend identifiziert werden, der keiner LSC zugeordnet ist. Folglich könnte das Paket unter Verwendung von herkömmlichen Techniken zum Verarbeiten von Paketflüssen verarbeitet werden.
  • Zusätzlich zur Verwendung von Flusstabellen 150 können andere Techniken zum Ermöglichen, dass jede VM bestimmt, welche Handlungen für jedes Paket unternommen werden sollten, das sie empfängt, das einer LSC zugeordnet ist, verwendet werden. In einer Ausführungsform kennzeichnet beispielsweise ein LSC-Modul in der Eintritts-VM die Pakete mit einem geeigneten LSC-Etikett, das von jeder anschließenden VM verwendet wird, die das Paket empfängt, um zu bestimmen, welche Dienste, falls überhaupt, an dem Paket durchgeführt werden sollten, und um die nächste VM zu bestimmen, zu der das Paket weitergeleitet werden sollte.
  • 5 zeigt eine beispielhafte Hauptrechnerplattform-Konfiguration 500 mit einer Plattformhardware 502 und verschiedenen Komponenten auf Softwarebasis. Die Plattformhardware 502 umfasst eine Zentraleinheit (CPU) 504, die mit einer Speicherschnittstelle 506 und einer Eingabe/Ausgabe-Schnittstelle (E/A-Schnittstelle) 508 über eine Verbindung 510 gekoppelt ist. In einigen Ausführungsformen kann alles oder ein Teil der vorangehenden Komponenten in einem System auf einem Chip (SoC) integriert sein. Die Speicherschnittstelle 506 ist dazu konfiguriert, den Zugriff auf den Systemspeicher 512 zu erleichtern, der gewöhnlich vom SoC separat ist.
  • Die E/A-Schnittstelle 508 stellt verschiedene E/A-Schnittstellen dar, die durch die Plattformhardware 502 bereitgestellt werden. Im Allgemeinen kann die E/A-Schnittstelle 508 als diskrete Komponente (wie z. B. ein ICH (E/A-Steuereinheitsnetzknoten) oder dergleichen) implementiert werden oder sie kann auf einem SoC implementiert werden. Überdies kann die E/A-Schnittstelle 508 auch als E/A-Hierarchie implementiert werden, wie z. B. eine Peripheriekomponenten-Verbindungsexpress-E/A-Hierarchie (PCIe™-E/A-Hierarchie). Die E/A-Schnittstelle 508 erleichtert weiter die Kommunikation zwischen verschiedenen E/A-Ressourcen und Vorrichtungen und anderen Plattformkomponenten. Diese umfassen eine nichtflüchtige Speichervorrichtung wie z. B. ein Plattenlaufwerk 514, das kommunikativ mit der E/A-Schnittstelle 508 über eine Plattensteuereinheit 516 gekoppelt ist, einen Firmwarespeicher 518, eine NIC 520 und verschiedene andere E/A-Vorrichtungen, die gemeinsam als andere Hardware 522 dargestellt sind.
  • Im Allgemeinen kann die CPU 504 einen Einzelkernprozessor oder einen Mehrkernprozessor umfassen, wie z. B. durch M Kerne 505 dargestellt. Die mehreren Kerne werden verwendet, um verschiedene Software-Komponenten 424 wie z. B. Module und Anwendungen auszuführen, die in einer oder mehreren nichtflüchtigen Speichervorrichtungen gespeichert sind, wie durch das Plattenlaufwerk 514 dargestellt. Allgemeiner stellt das Plattenlaufwerk 514 verschiedene Typen von nichtflüchtigen Speichervorrichtungen dar, einschließlich sowohl Speichervorrichtungen auf magnetischer als auch optischer Basis, sowie Halbleiter-Speichervorrichtungen wie z. B. Halbleiterlaufwerke (SSDs) oder einen Flash-Speicher. Wahlweise können alle oder ein Teil der Software-Komponenten 524 auf einer oder mehreren Speichervorrichtungen (nicht dargestellt) gespeichert sein, auf die über ein Netz 526 zugegriffen wird.
  • Während Hochfahr- oder Laufzeitoperationen werden verschiedene Software-Komponenten 524 und Firmware-Komponenten 528 in den Systemspeicher 512 geladen (wie durch den FW-Raum dargestellt) und an Kernen 505 als Prozesse ausgeführt, die Ausführungsprozessstränge oder dergleichen umfassen. In Abhängigkeit von der speziellen Prozessor- oder SoC-Architektur kann ein gegebener „physikalischer“ Kern als ein oder mehrere logische Kerne implementiert werden, wobei Prozesse den verschiedenen logischen Kernen zugewiesen sind. Unter der Intel® Hyperthreading™ Architektur wird beispielsweise jeder physikalische Kern als zwei logische Kerne implementiert.
  • Unter einem typischen Systemhochfahren für die Plattformhardware 502 wird die Firmware 528 in den Systemspeicher 512 geladen und konfiguriert, gefolgt vom Hochfahren eines Hauptrechner-OS 530. Anschließend wird ein Hypervisor 532, der im Allgemeinen eine Anwendung umfassen kann, die auf dem Hauptrechner-OS 530 läuft, gestartet. Der Hypervisor 532 kann dann verwendet werden, um verschiedene virtuelle Maschinen VM1-N, zu starten, von denen jede dazu konfiguriert ist, verschiedene Abschnitte (d. h. Adressenräume) des Systemspeichers 512 zu verwenden. Jede virtuelle Maschine VM1-N kann wiederum verwendet werden, um ein jeweiliges Betriebssystem 5341-N zu beherbergen.
  • Während Laufzeitoperationen ermöglicht der Hypervisor 532 die Umkonfiguration von verschiedenen Systemressourcen wie z. B. des Systemspeichers 512, der Kerne 505 und des (der) Plattenlaufwerks (Plattenlaufwerke) 514. Im Allgemeinen schaffen die virtuellen Maschinen Abstraktionen (in Kombination mit dem Hypervisor 532) zwischen ihrem beherbergten Betriebssystem und der zugrundeliegenden Plattformhardware 502, was ermöglicht, dass die Hardwareressourcen unter den VM1-N gemeinsam genutzt werden. Vom Gesichtspunkt jedes beherbergten Betriebssystems „besitzt“ dieses Betriebssystem die ganze Plattform und ist sich nicht über die Existenz von anderen Betriebssystemen bewusst, die auf virtuellen Maschinen laufen. In der Realität hat jedes Betriebssystem nur Zugriff auf die Ressourcen und/oder Ressourcenteile, die ihm durch den Hypervisor 532 zugewiesen werden.
  • Wie in 5 weiter dargestellt, umfasst jedes Betriebssystem einen Kernraum und einen Benutzerraum, die beide als Speicherräume im Systemspeicher 512 implementiert werden. Der Kernraum ist geschützt und wird verwendet, um Betriebssystem-Kernkomponenten zu betreiben, einschließlich eines Vernetzungsstapels. Unterdessen wird der Benutzerraum eines Betriebssystems verwendet, um Benutzeranwendungen zu betreiben, wie durch die Geräte 1, 2 und N und Anwendungen 1A-C, 2A-C und NA-C dargestellt.
  • Im Allgemeinen stellen die Geräte 1, 2 und N verschiedene SDN- oder NFV-Geräte dar, die auf virtuellen Maschinen auf der Plattformhardware 502 laufen können. Der Einfachheit halber ist jede VM1-N als einen ähnlichen Satz von Softwareanwendungen beherbergend dargestellt; dies dient jedoch nur Erläuterungszwecken, da die VMs für eine gegebene Plattform ähnliche Anwendungen beherbergen können oder verschiedene Anwendungen beherbergen können. Ebenso kann jede VM1-N ein einzelnes virtuelles Netzgerät (wie gezeigt) beherbergen, kann mehrere virtuelle Netzgeräte beherbergen oder kann beliebige virtuelle Netzgeräte beherbergen.
  • Wie vorstehend erörtert, kann zusätzlich zum Virtualisieren der Computerplattform unter Verwendung von VMs eine OS-Virtualisierung auf Behälterbasis, die virtualisierte Behälter verwendet, implementiert werden. Beispiele von Ausführungsformen, die eine Virtualisierung auf Behälterbasis verwenden, sind in der in 1b gezeigten Architektur 100b und der Plattformkonfiguration 600 in 6 dargestellt.
  • Die in der Plattformkonfiguration 600 verwendete Hardwarekonfiguration ist dieselbe wie die Plattformkonfiguration 500, wie gezeigt. Die Unterschiede in den Plattformkonfigurationen treten in der Software auf. Die Software in der Plattformkonfiguration 600 umfasst ein Hauptrechner-OS 602, eine OS-Virtualisierungsschicht 604 und mehrere Behälter 606. Wahlweise können die Behälter auch virtuelle Funktionseinheiten, virtuelle Maschinen oder andere Begriffe genannt werden in Abhängigkeit vom Verkäufer, der die Virtualisierungssoftware auf Behälterbasis bereitstellt, oder vom Autor, der beschreibt, wie die OS-Virtualisierung auf Behälterbasis arbeitet.
  • Jeder Behälter umfasst einen Satz von Softwarebibliotheken und Anwendungen, die logisch in Systemkomponenten und Anwendungs- und/oder Benutzerkomponenten unterteilt sind. Die Systemkomponenten umfassen Systembibliotheken und Systemsoftwaremodule. Wie dargestellt, umfasst jeder Behälter ein Vernetzungsstapel-Systemmodul oder dergleichen. Die virtuellen Geräte laufen im Anwendungs-Benutzerraum. Im Allgemeinen können die virtuellen Geräte derart konfiguriert sein, dass sie sich hinsichtlich dessen im Unklaren sind, ob sie an einer VM oder einem Behälter arbeiten, oder ansonsten bestehen geringfügige Unterschiede zwischen virtuellen Geräten, die dazu konfiguriert sind, an VMs zu laufen, im Gegensatz zu solchen, die durch Behälter beherbergt sind.
  • Wie in der Architektur 100b von 1b gezeigt, sind die Architekturkomponenten im Wesentlichen ähnlich zu den in den Architekturen 100 und 100a gezeigten, wobei die Hauptunterschiede darin liegen, dass der Hypervisor durch die OS-Virtualisierungsschicht 604 ersetzt ist und die VMs durch Behälter 606 ersetzt sind. Wie bei den VMs umfasst jeder Behälter einen ähnlichen Satz von Softwarekomponenten, einschließlich einer vNIC, eines oder mehrere virtuelle Geräte 136 und entsprechende Anwendungen 138 sowie eine Flusstabelle 150.
  • Zusätzlich zur Verwendung von IP-Paketen und Ethernet-Paketen können Virtualisierungsüberlagerungen verwendet werden, wie z. B. VXLAN (Lokales Netz mit virtueller Erweiterung), NVGRE (Netzvirtualisierung unter Verwendung von allgemeiner Leitweglenkung), die eine innere und eine äußere IP-Adresse verwenden. Um die lokale Dienstverkettung unter Verwendung von VXLAN oder NVGRE zu implementieren, würde die Anwesenheit von Überlagerungen nur zur Verarbeitung von IP beitragen, wie in den obigen Ausführungsformen beschrieben. Weitere Techniken zum Verarbeiten von Paketen unter Verwendung von VXLAN und NVGRE sind dem Fachmann auf dem Gebiet bekannt, so dass weitere Details zum Implementieren von Ausführungsformen unter Verwendung von VXLAN oder NVGRE hier nicht beschrieben werden.
  • Weitere Aspekte des hier beschriebenen Gegenstandes sind in den folgenden nummerierten Abschnitten dargelegt:
    • 1. Verfahren, das auf einer Rechenplattform implementiert wird, auf der mehrere virtuelle Maschinen (VMs) oder virtualisierte Behälter (Behälter) laufen, wobei jede VM oder jeder Behälter eine virtuelle Netzschnittstellensteuereinheit (vNIC) umfasst, die mit einem virtuellen Koppler in einem Software-definierten Netz (SDN) kommunikativ gekoppelt ist, wobei das Verfahren Folgendes umfasst:
      • Implementieren einer lokalen Dienstkette (LSC) über mehrere virtuelle Netzgeräte, die von den mehreren VMs oder Behältern beherbergt werden, wobei jedes virtuelle Netzgerät dazu konfiguriert ist, einen oder mehrere Dienste für jedes von mehreren durch die LSC zu verarbeitenden Pakete durchzuführen; und
      • Übertragen von Paketdaten entsprechend den mehreren Paketen zwischen VMs oder Behältern ohne Verwendung des virtuellen Kopplers.
    • 2. Verfahren nach Abschnitt 1, wobei die Paketdaten von einer ersten VM oder einem ersten Behälter mit einer ersten vNIC mit einem ersten Empfangspuffer (Rx-Puffer), die/der ein aktuelles virtuelles Netzgerät in der LSC beherbergt, zu einer zweiten VM oder einem zweiten Behälter mit einer zweiten vNIC mit einem zweiten Rx-Puffer, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt, durch Schreiben von Paketdaten direkt in den zweiten Rx-Puffer übertragen werden.
    • 3. Verfahren nach Abschnitt 2, wobei die Paketdaten vom ersten Rx-Puffer in den zweiten Rx-Puffer kopiert werden.
    • 4. Verfahren nach Abschnitt 3, wobei zumindest ein Abschnitt des ersten und des zweiten Rx-Puffers als jeweilige First-in-, First-out-Warteschlangen (FIFO-Warteschlangen) konfiguriert sind und Paketdaten für ein gegebenes Paket von einem oder mehreren Schlitzen in einer ersten FIFO-Warteschlange in einen oder mehrere Schlitze in der zweiten FIFO-Warteschlange kopiert werden.
    • 5. Verfahren nach einem der vorangehenden Abschnitte, das ferner Folgendes umfasst:
      • Implementieren von mehreren LSCs, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und
      • Implementieren eines Mechanismus für jede der mehreren LSCs, um die Übertragung von Paketdaten für Pakete zu erleichtern, die dieser LSC zugeordnet sind, wobei für jede LSC die Paketdaten zwischen VMs oder Behältern übertragen werden, die die virtuellen Netzgeräte für diese LSC in einer verketteten Weise beherbergen, die nicht den virtuellen Koppler durchquert.
    • 6. Verfahren nach Abschnitt 5, wobei der Mechanismus eine jeweilige lokale Flusstabelle für jede VM oder jeden Behälter umfasst, wobei die lokale Flusstabelle für eine gegebene VM oder einen gegebenen Behälter einen vNIC-Empfangsport (vNIC-Rx-Port) und/oder einen Rx-Puffer für eine VM oder einen Behälter, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt, identifiziert.
    • 7. Verfahren nach Abschnitt 6, das ferner das Konfigurieren der lokalen Flusstabelle für jede VM oder jeden Behälter unter Verwendung einer SDN-Steuereinheit umfasst.
    • 8. Verfahren nach einem der vorangehenden Abschnitte, das ferner Folgendes umfasst:
      • Zuweisen von jeweiligen Anwendungsspeicherräumen für jede/jeden der mehreren VMs oder Behälter, wobei eine Anwendung, die in einem Anwendungsspeicherraum einer VM oder eines Behälters läuft, nicht auf den Anwendungsspeicherraum einer anderen VM oder eines anderen Behälters zugreifen kann; und
      • Zuweisen eines gemeinsam genutzten Speicherraums, der für Empfangspuffer verwendet wird, die von virtuellen Netzschnittstellensteuereinheiten (vNICs) für jede der VMs oder jeden der Behälter verwendet werden, wobei jeder VM oder jedem Behälter ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
    • 9. Verfahren nach einem der vorangehenden Abschnitte, wobei die Rechenplattform eine Netzschnittstelle umfasst, die mindestens einen Netzport umfasst, der mit der Rechenplattform kommunikativ gekoppelt ist, wobei das Verfahren ferner Folgendes umfasst:
      • Empfangen eines Paket an einem Netzport der Netzschnittstelle;
      • Bestimmen eines Flusses, zu dem das Paket gehört, und/oder einer zum Bedienen des Pakets zu verwendenden LSC; und
      • Weiterleiten des Pakets von der Netzschnittstelle zu einem Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
    • 10. Verfahren nach Abschnitt 9, wobei das Paket durch Kopieren von Paketdaten für das Paket von einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum) der Netzschnittstelle in den Empfangspuffer der vNIC unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung) weitergeleitet wird.
    • 11. Verfahren nach einem der vorangehenden Abschnitte, wobei die Rechenplattform eine Netzschnittstelle mit mindestens einem Netzport umfasst, der mit der Rechenplattform kommunikativ gekoppelt ist, wobei das Verfahren ferner Folgendes umfasst:
      • für jedes Paket, das von einem Netz an einem vordefinierten Netzport der Netzschnittstelle empfangen wird,
      • Puffern von Paketdaten für das Paket in einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum) der Netzschnittstelle; und
      • Kopieren der Paketdaten für das Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung).
    • 12. Verfahren nach einem der vorangehenden Abschnitte, wobei die Rechenplattform eine Netzschnittstelle mit mindestens einem Netzport umfasst, der mit der Rechenplattform kommunikativ gekoppelt ist, das ferner die Verwendung derselben LSC für alle Pakete, die an einem vordefinierten Netzport empfangen werden, umfasst.
    • 13. Verfahren nach einem der vorangehenden Abschnitte, das ferner Folgendes umfasst:
      • Bestimmen, dass ein virtuelles Gerät das letzte virtuelle Gerät in einer LSC ist, die für ein gegebenes Paket verwendet wird;
      • Bestimmen eines Ausgangsports an einem physikalischen Netzadapter, aus dem das Paket weitergeleitet werden soll; und
      • Weiterleiten von Paketdaten von einem Puffer an einer VM oder einem Behälter, die/der das letzte virtuelle Gerät beherbergt, zu einem Puffer, der dem Ausgangsport des physikalischen Netzadapters zugeordnet ist, in einer Weise, die den virtuellen Koppler umgeht.
    • 14. Verfahren nach Abschnitt 13, wobei die Rechenplattform eine Netzschnittstelle mit mindestens einem Netzport umfasst, der mit der Rechenplattform kommunikativ gekoppelt ist, wobei das Verfahren ferner Folgendes umfasst:
      • für jedes Paket, das von einem Netz an einem vordefinierten Netzport der Netzschnittstelle empfangen wird,
      • Puffern von Paketdaten für das Paket in einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum) der Netzschnittstelle; und
      • Kopieren der Paketdaten für das Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung).
    • 15. Nichtflüchtiges maschinenlesbares Medium, auf dem mehrere Befehle gespeichert sind, die dazu konfiguriert sind, auf einem Prozessor einer Rechenplattform ausgeführt zu werden, auf der mehrere VMs oder Behälter betrieben werden sollen, wobei die Ausführung der mehreren Befehle bewirkt, dass die Rechenplattform das Verfahren nach einem der vorangehenden Abschnitte durchführt.
    • 16. Rechenplattform mit einem Mittel zum Implementieren des Verfahrens nach einem der Abschnitte 1-14.
    • 17. Nichtflüchtiges maschinenlesbares Medium, auf dem mehrere Befehle gespeichert sind, die dazu konfiguriert sind, auf einem Prozessor einer Rechenplattform ausgeführt zu werden, auf der mehrere virtuelle Maschinen (VMs) oder virtualisierte Behälter (Behälter) betrieben werden sollen, wobei zumindest ein Teil der VMs oder Behälter eine virtuelle Netzschnittstellensteuereinheit (vNIC) umfasst, die mit einem virtuellen Koppler in einem Software-definierten Netz (SDN) kommunikativ gekoppelt ist, und ein virtuelles Netzgerät beherbergt, wobei die Ausführung der mehreren Befehle bewirkt, dass die Rechenplattform:
      • eine lokale Dienstkette (LSC) über mehrere der virtuellen Netzgeräte implementiert, wobei jedes virtuelle Netzgerät dazu konfiguriert ist, einen oder mehrere Dienste für jedes von mehreren Paketen durchzuführen, die durch die LSC verarbeitet werden sollen; und
      • Paketdaten entsprechend den mehreren Paketen zwischen VMs oder Behältern durch Schreiben von Paketdaten von einem Puffer, der für eine erste VM oder einen ersten Behälter zugänglich ist, die/der ein erstes virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen aktuellen Dienst in der LSC durchzuführen, zu einem Empfangspuffer (Rx-Puffer) einer vNIC einer zweiten VM oder eines zweiten Behälters, die/der ein zweites virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen nächsten Dienst in der LSC durchzuführen, überträgt.
    • 18. Nichtflüchtiges maschinenlesbares Medium nach Abschnitt 17, wobei der Rx-Puffer der vNIC der zweiten VM oder des zweiten Behälters einen zweiten Rx-Puffer umfasst, und wobei die Paketdaten von einem ersten Rx-Puffer einer vNIC für die erste VM oder den ersten Behälter in den zweiten Rx-Puffer kopiert werden.
    • 19. Nichtflüchtiges maschinenlesbares Medium nach Abschnitt 17 oder 18, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • zumindest einen Teil der ersten und zweiten Rx-Puffer als jeweilige erste und zweite First-in-, First-out-Warteschlangen (FIFO-Warteschlangen) konfiguriert; und
      • Paketdaten für ein gegebenes Paket von einem oder mehreren Schlitzen in einer ersten FIFO-Warteschlange in einen oder mehrere Schlitze in der zweiten FIFO-Warteschlange kopiert.
    • 20. Nichtflüchtiges maschinenlesbares Medium gemäß einem der Abschnitte 17-19, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • mehrere LSCs implementiert, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und
      • eine lokale Flusstabelle für jede VM oder jeden Behälter konfiguriert, die/der ein virtuelles Netzgerät beherbergt, wobei die lokale Flusstabelle für eine gegebene VM oder einen gegebenen Behälter einen Eintrag für jede der LSCs umfasst, die einen Dienst umfassen, der durch ein virtuelles Netzgerät durchgeführt werden soll, das von dieser VM oder diesem Behälter beherbergt wird, und der Eintrag für jede LSC einen vNIC-Empfangs-Port (vNIC-Rx-Port) und/oder Rx-Puffer für eine VM oder einen Behälter identifiziert, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt.
    • 21. Nichtflüchtiges maschinenlesbares Medium nach Abschnitt 20, wobei die mehreren Befehle ferner Befehle zum Implementieren einer SDN-Steuereinheit umfassen, die, wenn sie ausgeführt wird, die lokale Flusstabelle für jede VM oder jeden Behälter konfiguriert.
    • 22. Nichtflüchtiges maschinenlesbares Medium nach einem der Abschnitte 17-21, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform einen gemeinsam genutzten Speicherraum, der für Empfangspuffer verwendet wird, die durch vNICs für jede/jeden der VMs oder Behälter verwendet werden, zuweist, wobei jeder VM oder jedem Behälter ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
    • 23. Nichtflüchtiges maschinenlesbares Medium nach Abschnitt 22, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform jeweilige Anwendungsspeicherräume für jede der mehreren VMs oder Behälter zuweist, wobei eine Anwendung, die in einem Anwendungsspeicherraum einer VM oder eines Behälters läuft, nicht auf den Anwendungsspeicherraum einer anderen VM oder eines anderen Behälters zugreifen kann.
    • 24. Nichtflüchtiges maschinenlesbares Medium nach einem der Abschnitte 17-23, wobei die Rechenplattform eine Netzschnittstelle mit mindestens einem Netzport umfasst, der mit der Rechenplattform kommunikativ gekoppelt ist, und wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • einen Fluss, zu dem ein an der Netzschnittstelle empfangenes Paket gehört, und/oder eine LSC, die verwendet werden soll, um das Paket zu bedienen, bestimmt; und
      • das Paket von der Netzschnittstelle zu einem Empfangspuffer einer vNIC für eine VM oder einen Behälter weiterleitet, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
    • 25. Nichtflüchtiges maschinenlesbares Medium nach Abschnitt 24, wobei das Paket durch Kopieren von Paketdaten für das Paket von einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum) der Netzschnittstelle in den Empfangspuffer der vNIC unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung) weitergeleitet wird.
    • 26. Nichtflüchtiges maschinenlesbares Medium nach einem der Abschnitte 17-25, wobei die Rechenplattform eine Netzschnittstelle mit mindestens einem Netzport, der mit der Rechenplattform kommunikativ gekoppelt ist, und einen Speicher umfasst, und wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • zumindest einen Abschnitt des Speichers an der Netzschnittstelle als speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum) konfiguriert; und
      • die Netzschnittstelle konfiguriert, um
      • Paketdaten für jedes von mehreren Paketen, die von einem Netz an einem vordefinierten Netzport der Netzschnittstelle empfangen werden, in einem Empfangspuffer im MMIO-Adressenraum zu puffern; und
      • Paketdaten für jedes Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung) zu kopieren.
    • 27. Nichtflüchtiges maschinenlesbares Medium nach einem der Abschnitte 17-26, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • einen Fluss bestimmt, zu dem ein Paket gehört;
      • eine LSC bestimmt, die verwendet werden soll, um Pakete zu bedienen, die zum Fluss gehören; und
      • Angaben zum Paket hinzufügt, die die LSC identifizieren, die verwendet werden soll, um das Paket zu bedienen.
    • 28. Rechenplattform, die Folgendes umfasst:
      • einen Prozessor mit mehreren Prozessorkernen;
      • einen Systemspeicher, der mit dem Prozessor wirksam gekoppelt ist;
      • eine Netzschnittstellensteuereinheit (NIC) mit mindestens einem Netzport und einem Speicher, der mit dem Prozessor wirksam gekoppelt ist; und
      • eine Speichervorrichtung, auf der mehrere Befehle gespeichert sind, einschließlich Befehlen, die dazu konfiguriert sind, über einen oder mehrere Prozessorkerne ausgeführt zu werden, um zu bewirken, dass die Vorrichtung
      • mehrere virtuelle Maschinen (VMs) oder virtualisierte Behälter (Behälter) initiiert, wobei jede VM oder jeder Behälter eine virtuelle Netzschnittstellensteuereinheit (vNIC) umfasst, wobei zumindest ein Teil der VMs oder Behälter ein virtuelles Netzgerät beherbergt;
      • ein Software-definiertes Netz (SDN) auf der Plattform mit einem virtuellen Koppler mit virtuellen Netzports konfiguriert, die mit jeweiligen vNICs und mindestens einem Netzport an der NIC gekoppelt sind;
      • eine lokale Dienstkette (LSC) über mehrere der virtuellen Netzgeräte implementiert, wobei jedes virtuelle Netzgerät dazu konfiguriert ist, einen oder mehrere Dienste für jedes von mehreren Paketen durchzuführen, die durch die LSC verarbeitet werden sollen; und
      • Paketdaten entsprechend den mehreren Paketen zwischen VMs oder Behältern durch Schreiben von Paketdaten von einem Puffer, der für eine erste VM oder einen ersten Behälter zugänglich ist, die/der ein erstes virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen aktuellen Dienst in der LSC durchzuführen, zu einem Empfangspuffer (Rx-Puffer) einer vNIC einer zweiten VM oder eines zweiten Behälters, die/der ein zweites virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen nächsten Dienst in der LSC durchzuführen, überträgt.
    • 29. Rechenplattform nach Abschnitt 28, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • mehrere LSCs implementiert, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und
      • eine lokale Flusstabelle für jede VM oder jeden Behälter konfiguriert, die/der ein virtuelles Netzgerät beherbergt, wobei die lokale Flusstabelle für eine gegebene VM oder einen gegebenen Behälter einen Eintrag für jede der LSCs umfasst, die einen Dienst umfassen, der durch ein virtuelles Netzgerät durchgeführt werden soll, das von dieser VM oder diesem Behälter beherbergt wird, und der Eintrag für jede LSC einen vNIC-Empfangsport (vNIC-Rx-Port) und/oder Rx-Puffer für eine VM oder einen Behälter identifiziert, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt.
    • 30. Rechenplattform nach Abschnitt 28 oder 29, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform einen gemeinsam genutzten Speicherraum zuweist, der für Empfangspuffer verwendet wird, die von vNICs für jede der VMs oder Behälter verwendet werden, wobei jeder VM oder jedem Behälter ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
    • 31. Rechenplattform nach einem der Abschnitte 28-30, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • einen Fluss, zu dem ein Paket, das an der NIC empfangen wird, gehört, und/oder eine LSC, die verwendet werden soll, um das Paket zu bedienen, bestimmt; und
      • das Paket von der NIC zu einem Empfangspuffer einer vNIC für eine VM oder einen Behälter weiterleitet, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
    • 32. Rechenplattform nach einem der Abschnitte 28-31, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform:
      • mindestens einen Teil des Speichers an der NIC als speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum) konfiguriert; und
      • die NIC dazu konfiguriert,
      • Paketdaten für jedes von mehreren Paketen, die von einem Netz an einem vordefinierten Netzport der Netzschnittstelle empfangen werden, in einem Empfangspuffer im MMIO-Adressenraum zu puffern; und
      • Paketdaten für jedes Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung) zu kopieren.
    • 33. Rechenplattform, die Folgendes umfasst:
      • eine Netzschnittstellensteuereinheit (NIC) mit mindestens einem Netzport und einem Speicher, und
      • ein Mittel zum
      • Instantiieren von mehreren virtuellen Maschinen (VMs) oder virtualisierten Behältern (Behältern), wobei jede VM oder jeder Behälter eine virtuelle Netzschnittstellensteuereinheit (vNIC) umfasst, wobei zumindest ein Teil der VMs oder Behälter ein virtuelles Netzgerät beherbergt;
      • Konfigurieren eines Software-definierten Netzes (SDN) an der Plattform mit einem virtuellen Koppler mit virtuellen Netzports, die mit jeweiligen vNICs und mindestens einem Netzport an der NIC gekoppelt sind;
      • Implementieren einer lokalen Dienstkette (LSC) über mehrere der virtuellen Netzgeräte, wobei jedes virtuelle Netzgerät dazu konfiguriert ist, einen oder mehrere Dienste für jedes von mehreren Paketen durchzuführen, die durch die LSC verarbeitet werden sollen; und
      • Übertragen von Paketdaten entsprechend den mehreren Paketen zwischen VMs oder Behältern durch Schreiben von Paketdaten von einem Puffer, der für eine erste VM oder einen ersten Behälter zugänglich ist, die/der ein erstes virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen aktuellen Dienst in der LSC durchzuführen, zu einem Empfangspuffer (Rx-Puffer) einer vNIC einer zweiten VM oder eines zweiten Behälters, die/der ein zweites virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen nächsten Dienst in der LSC durchzuführen.
    • 34. Rechenplattform nach Abschnitt 33, die ferner ein Mittel umfasst zum:
      • Implementieren von mehreren LSCs, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und
      • Konfigurieren einer lokalen Flusstabelle für jede VM oder jeden Behälter, die/der ein virtuelles Netzgerät beherbergt, wobei die lokale Flusstabelle für eine gegebene VM oder einen gegebenen Behälter einen Eintrag für jede der LSCs umfasst, die einen Dienst umfassen, der von einem virtuellen Netzgerät durchgeführt werden soll, das von dieser VM oder diesem Behälter beherbergt wird, und der Eintrag für jede LSC einen vNIC-Empfangsport (vNIC-Rx-Port) und/oder Rx-Puffer für eine VM oder einen Behälter identifiziert, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt.
    • 35. Rechenplattform nach Abschnitt 33 oder 34, die ferner ein Mittel zum Zuweisen eines gemeinsam genutzten Speicherraums umfasst, der für Empfangspuffer verwendet wird, die von vNICs für jede der VMs oder der Behälter verwendet werden, wobei jeder VM oder jedem Behälter ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
    • 36. Rechenplattform nach einem der Abschnitte 33-35, die ferner ein Mittel umfasst zum:
      • Bestimmen eines Flusses, zu dem ein an der NIC empfangenes Paket gehört, und/oder einer LSC, die verwendet werden soll, um das Paket zu bedienen; und
      • Weiterleiten des Pakets von der NIC zu einem Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
    • 37. Rechenplattform nach einem der Abschnitte 33-36, die ferner ein Mittel umfasst zum:
      • Konfigurieren zumindest eines Abschnitts des Speichers an der NIC als speicherabgebildeten Eingabe/Ausgabe-Adressenraum (MMIO-Adressenraum); und
      • Konfigurieren der NIC, um
      • Paketdaten für jedes von mehreren Paketen, die von einem Netz an einem vordefinierten Netzport der Netzschnittstelle empfangen werden, in einem Empfangspuffer im MMIO-Adressenraum zu puffern; und
      • Paketdaten für jedes Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung) zu kopieren.
  • Obwohl einige Ausführungsformen mit Bezug auf spezielle Implementierungen beschrieben wurden, sind andere Implementierungen gemäß einigen Ausführungsformen möglich. Außerdem müssen die Anordnung und/oder Reihenfolge von Elementen oder anderen in den Zeichnungen dargestellten und/oder hier beschriebenen Merkmalen nicht in der dargestellten und beschriebenen speziellen Weise angeordnet sein. Viele andere Anordnungen sind gemäß einigen Ausführungsformen möglich.
  • In jedem in einer Figur gezeigten System können die Elemente in einigen Fällen jeweils ein gleiches Bezugszeichen oder ein unterschiedliches Bezugszeichen aufweisen, um darauf hinzudeuten, dass die dargestellten Elemente unterschiedlich und/oder ähnlich sein könnten. Ein Element kann jedoch flexibel genug sein, um verschiedene Implementierungen aufzuweisen und mit einigen oder allen der hier gezeigten oder beschriebenen Systeme zu arbeiten. Die in den Figuren gezeigten verschiedenen Elemente können gleich oder verschieden sein. Welches als erstes Element bezeichnet wird und welches zweites Element genannt wird, ist beliebig.
  • In der Beschreibung und in den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ zusammen mit ihren Ableitungen verwendet werden. Selbstverständlich sind diese Begriffe nicht als Synonyme füreinander gemeint. In speziellen Ausführungsformen kann vielmehr „verbunden“ verwendet werden, um anzugeben, dass zwei oder mehr Elemente in direktem physikalischem oder elektrischem Kontakt miteinander stehen. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physikalischem oder elektrischem Kontakt stehen. „Gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, aber dennoch miteinander zusammenwirken oder zusammenarbeiten.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Die Bezugnahme in der Patentbeschreibung auf „eine Ausführungsform“, „eine einzelne Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Eigenschaft, die in Verbindung mit den Ausführungsformen beschrieben ist, in mindestens einigen Ausführungsformen enthalten ist, aber nicht notwendigerweise in allen Ausführungsformen der Erfindungen. Die verschiedenen Erscheinungen „eine Ausführungsform“, „eine einzelne Ausführungsform“ oder „einige Ausführungsformen“ beziehen sich nicht notwendigerweise alle auf dieselben Ausführungsformen.
  • Nicht alle Komponenten, Merkmale, Strukturen, Eigenschaften usw., die hier beschrieben und erläutert sind, müssen in einer speziellen Ausführungsform oder speziellen Ausführungsformen enthalten sein. Wenn die Patentbeschreibung angibt, dass eine Komponente, ein Merkmal, eine Struktur oder eine Eigenschaft enthalten sein „darf“, „dürfte“, kann" oder „könnte“, muss beispielsweise diese spezielle Komponente, dieses spezielle Merkmal, diese spezielle Struktur oder diese spezielle Eigenschaft nicht enthalten sein. Wenn die Patentbeschreibung oder ein Anspruch sich auf „ein“ Element bezieht, bedeutet dies nicht, dass nur eines des Elements vorhanden ist. Wenn die Patentbeschreibung oder die Ansprüche sich auf „ein zusätzliches“ Element beziehen, schließt dies nicht aus, dass mehr als eines des zusätzlichen Elements vorhanden ist.
  • Kursive Buchstaben wie z. B. ‚M‘ und ‚N‘ in der vorangehenden ausführlichen Beschreibung werden verwendet, um eine ganze Zahl darzustellen, und die Verwendung eines speziellen Buchstaben ist nicht auf spezielle Ausführungsformen begrenzt. Überdies kann derselbe Buchstabe verwendet werden, um separate ganze Zahlen darzustellen, oder verschiedene Buchstaben können verwendet werden. Außerdem kann die Verwendung eines speziellen Buchstaben in der ausführlichen Beschreibung dem Buchstaben entsprechen oder nicht, der in einem Anspruch verwendet wird, der denselben Gegenstand in der ausführlichen Beschreibung betrifft.
  • Wie vorstehend erörtert, können verschiedene Aspekte der Ausführungsformen hier durch entsprechende Software- und/oder Firmware-Komponenten und Anwendungen erleichtert werden, wie z. B. Software, die auf einem Server oder Vorrichtungsprozessor läuft, oder Software und/oder Firmware, die durch einen eingebetteten Prozessor oder dergleichen ausgeführt wird. Folglich können die Ausführungsformen dieser Erfindung verwendet werden als oder zum Unterstützen eines Softwareprogramms, von Softwaremodulen, Firmware und/oder verteilter Software, die auf einer gewissen Form von Verarbeitungskern (wie z. B. der CPU eines Computers, einem oder mehreren Kernen eines Mehrkernprozessors) ausgeführt wird, eine virtuelle Maschine, die auf einem Prozessor oder Kern läuft oder anderweitig implementiert oder ausgeführt wird auf oder innerhalb eines computerlesbaren oder maschinenlesbaren nichtflüchtigen Speichermediums. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speichermedium umfasst irgendeinen Mechanismus zum Speichern oder Übertragen von Informationen in einer für eine Maschine (z. B. einen Computer) lesbaren Form. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speichermedium umfasst beispielsweise irgendeinen Mechanismus, der Informationen in einer Form bereitstellt (d. h. speichert und/oder überträgt), die für einen Computer oder eine Rechenmaschine (z. B. eine Rechenvorrichtung, ein elektronisches System usw.) zugänglich ist, wie z. B. aufzeichnungsfähige/nicht aufzeichnungsfähige Medien (z. B. Festwertspeicher (ROM), Direktzugriffsspeicher (RAM), Magnetplatten-Speichermedien, optische Speichermedien, Flash-Speichervorrichtungen usw.). Der Inhalt kann direkt ausführbar („Objekt“ oder „ausführbare“ Form), Quellencode oder Differenzcode („Delta“ oder „Patch“-Code) sein. Ein computerlesbares oder maschinenlesbares nichtflüchtiges Speichermedium kann auch einen Speicher oder eine Datenbank umfassen, aus der Inhalt heruntergeladen werden kann. Das computerlesbare oder maschinenlesbare nichtflüchtige Speichermedium kann auch eine Vorrichtung oder ein Produkt umfassen, auf dem Inhalt zu einem Zeitpunkt von Verkauf oder Auslieferung gespeichert ist. Folglich kann das Ausliefern einer Vorrichtung mit gespeichertem Inhalt oder Anbieten von Inhalt für das Herunterladen über ein Kommunikationsmedium als einen Herstellungsgengenstand bereitstellend verstanden werden, der ein computerlesbares oder maschinenlesbares nichtflüchtiges Speichermedium mit einem solchen hier beschriebenen Inhalt umfasst.
  • Verschiedene Komponenten, auf die vorstehend als Prozesse, Server oder Werkzeuge Bezug genommen wurde, die hier beschrieben sind, können ein Mittel zum Durchführen der beschriebenen Funktionen sein. Die Operationen und Funktionen, die durch verschiedene hier beschriebene Komponenten durchgeführt werden, können durch Software, die auf einem Verarbeitungselement läuft, über eingebettete Hardware oder dergleichen oder irgendeine Kombination von Hardware und Software implementiert werden. Solche Komponenten können als Softwaremodule, Hardwaremodule, eine Spezialhardware (z. B. anwendungsspezifische Hardware, ASICs, DSPs usw.), eingebettete Steuereinheiten, eine festverdrahtete Schaltungsanordnung, Hardwarelogik usw. implementiert werden. Der Softwareinhalt (z. B. Daten, Befehle, Konfigurationsinformationen usw.) können über einen Herstellungsgegenstand mit einem computerlesbaren oder maschinenlesbaren nichtflüchtigen Speichermedium bereitgestellt werden, das Inhalt bereitstellt, der Befehle darstellt, die ausgeführt werden können. Der Inhalt kann dazu führen, dass ein Computer verschiedene hier beschriebene Funktionen/Operationen durchführt.
  • Die obige Beschreibung von erläuterten Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, soll nicht erschöpfend sein oder die Erfindung auf die offenbarten genauen Formen begrenzen. Obwohl spezifische Ausführungsformen von und Beispiele für die Erfindung hier für Erläuterungszwecke beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Schutzbereichs der Erfindung möglich, wie der Fachmann auf dem relevanten Gebiet erkennt.
  • Diese Modifikationen können an der Erfindung angesichts der vorstehenden ausführlichen Beschreibung durchgeführt werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht als Begrenzung der Erfindung auf die in der Patentbeschreibung und den Zeichnungen offenbarten spezifischen Ausführungsformen aufgefasst werden. Vielmehr soll der Schutzbereich der Erfindung vollständig durch die folgenden Ansprüche bestimmt werden, die gemäß festgelegten Grundsätzen der Anspruchsinterpretation aufgefasst werden sollen.

Claims (25)

  1. Verfahren, das auf einer Rechenplattform (102) implementiert wird, auf der mehrere virtuelle Maschinen, VMs (112), oder virtualisierte Behälter, Behälter (606), laufen, wobei jede VM (112) oder jeder Behälter (606) eine virtuelle Netzschnittstellensteuereinheit, vNIC, umfasst, die mit einem virtuellen Koppler (109) in einem Software-definierten Netz, SDN, kommunikativ gekoppelt ist, wobei das Verfahren Folgendes umfasst: Implementieren einer lokalen Dienstkette, LSC, durch die mehrere Pakete jeweils sequentiell durch mehrere virtuelle Netzgeräte (136) hintereinander verarbeitet werden, wobei die virtuellen Netzgeräte (136) von den mehreren VMs (112) oder Behältern (606) beherbergt werden, wobei jedes virtuelle Netzgerät (136) dazu konfiguriert ist, einen oder mehrere Dienste für jedes der mehreren durch die LSC zu verarbeitenden Pakete durchzuführen; und Übertragen von Paketdaten, die in den mehreren Paketen enthalten sind, zwischen VMs (112) oder Behältern (606) ohne Verwendung des virtuellen Kopplers (109).
  2. Verfahren nach Anspruch 1, wobei die Paketdaten von einer ersten VM oder einem ersten Behälter mit einer ersten vNIC mit einem ersten Empfangspuffer. Rx-Puffer, die/der ein aktuelles virtuelles Netzgerät in der LSC beherbergt, zu einer zweiten VM oder einem zweiten Behälter mit einer zweiten vNIC mit einem zweiten Rx-Puffer, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt, durch Schreiben von Paketdaten direkt in den zweiten Rx-Puffer übertragen werden.
  3. Verfahren nach Anspruch 2, wobei die Paketdaten vom ersten Rx-Puffer in den zweiten Rx-Puffer kopiert werden.
  4. Verfahren nach Anspruch 3, wobei zumindest ein Abschnitt des ersten und des zweiten Rx-Puffers als jeweilige First-in-, First-out-Warteschlangen, FIFO-Warteschlangen, konfiguriert werden und Paketdaten für ein gegebenes Paket von einem oder mehreren Schlitzen in einer ersten FIFO-Warteschlange in einen oder mehrere Schlitze in der zweiten FIFO-Warteschlange kopiert werden.
  5. Verfahren nach einem der vorangehenden Ansprüche, das ferner Folgendes umfasst: Implementieren von mehreren LSCs, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und Implementieren eines Mechanismus für jede der mehreren LSCs, um die Übertragung von Paketdaten für Pakete zu erleichtern, die dieser LSC zugeordnet sind, wobei für jede LSC die Paketdaten zwischen VMs (112) oder Behältern (606) übertragen werden, die die virtuellen Netzgeräte (136) für diese LSC in einer verketteten Weise beherbergen, die nicht den virtuellen Koppler (109) durchquert.
  6. Verfahren nach Anspruch 5, wobei der Mechanismus eine jeweilige lokale Flusstabelle für jede VM (112) oder jeden Behälter (606) umfasst, wobei die lokale Flusstabelle für eine gegebene VM (112) oder einen gegebenen Behälter (606) einen vNIC-Empfangsport, vNIC-Rx-Port, und/oder einen Rx-Puffer für eine VM (112) oder einen Behälter (606), die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt, identifiziert.
  7. Verfahren nach Anspruch 6, das ferner das Konfigurieren der lokalen Flusstabelle für jede VM (112) oder jeden Behälter (606) unter Verwendung einer SDN-Steuereinheit umfasst.
  8. Verfahren nach einem der vorangehenden Ansprüche, das ferner Folgendes umfasst: Zuweisen von jeweiligen Anwendungsspeicherräumen für jede/jeden der mehreren VMs (112) oder Behälter (606), wobei eine Anwendung, die in einem Anwendungsspeicherraum einer VM oder eines Behälters läuft, nicht auf den Anwendungsspeicherraum einer anderen VM oder eines anderen Behälters zugreifen kann; und Zuweisen eines gemeinsam genutzten Speicherraums, der für Empfangspuffer verwendet wird, die von vNICs für jede der VMs (112) oder jeden der Behälter (606) verwendet werden, wobei jeder VM (112) oder jedem Behälter (606) ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
  9. Verfahren nach einem der vorangehenden Ansprüche, wobei die Rechenplattform (102) eine Netzschnittstelle (104) umfasst, die mindestens einen Netzport (116) umfasst, der mit der Rechenplattform (102) kommunikativ gekoppelt ist, wobei das Verfahren ferner Folgendes umfasst: Empfangen eines Paket an einem Netzport (116) der Netzschnittstelle (104); Bestimmen eines Flusses, zu dem das Paket gehört, und/oder einer zum Bedienen des Pakets zu verwendenden LSC; und Weiterleiten des Pakets von der Netzschnittstelle (104) zu einem Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
  10. Verfahren nach Anspruch 9, wobei das Paket durch Kopieren von Paketdaten für das Paket von einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum, MMIO-Adressenraum, der Netzschnittstelle (104) in den Empfangspuffer der vNIC unter Verwendung einer Direktspeicherzugriffs-Datenübertragung, DMA-Datenübertragung, weitergeleitet wird.
  11. Verfahren nach einem der vorangehenden Ansprüche, wobei die Rechenplattform (102) eine Netzschnittstelle (104) mit mindestens einem Netzport (116) umfasst, der mit der Rechenplattform (102) kommunikativ gekoppelt ist, wobei das Verfahren ferner Folgendes umfasst: für jedes Paket, das von einem Netz an einem vordefinierten Netzport (116) der Netzschnittstelle (104) empfangen wird, Puffern von Paketdaten für das Paket in einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum, MMIO-Adressenraum, der Netzschnittstelle (104); und Kopieren der Paketdaten für das Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung, DMA-Datenübertragung.
  12. Nichtflüchtiges maschinenlesbares Medium, auf dem mehrere Befehle gespeichert sind, die dazu konfiguriert sind, auf einem Prozessor einer Rechenplattform (102) ausgeführt zu werden, auf der mehrere virtuelle Maschinen, VMs (112), oder virtualisierte Behälter, Behälter (606), betrieben werden sollen, wobei zumindest ein Teil der VMs (112) oder Behälter (606) eine virtuelle Netzschnittstellensteuereinheit, vNIC, umfasst, die mit einem virtuellen Koppler (109) in einem Software-definierten Netz, SDN, kommunikativ gekoppelt ist, und ein virtuelles Netzgerät beherbergt, wobei die Ausführung der mehreren Befehle bewirkt, dass die Rechenplattform (102): eine lokale Dienstkette, LSC, implementiert, durch die mehrere Pakete jeweils sequentiell durch mehrere der virtuellen Netzgeräte hintereinander verarbeitet werden, wobei jedes virtuelle Netzgerät dazu konfiguriert ist, einen oder mehrere Dienste für jedes von mehreren Paketen durchzuführen, die durch die LSC verarbeitet werden sollen; und Paketdaten, die in den mehreren Paketen enthalten sind, zwischen VMs (112) oder Behältern (606) durch Schreiben von Paketdaten von einem Puffer, der für eine erste VM oder einen ersten Behälter zugänglich ist, die/der ein erstes virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen aktuellen Dienst in der LSC durchzuführen, zu einem Empfangspuffer, Rx-Puffer, einer vNIC einer zweiten VM oder eines zweiten Behälters, die/der ein zweites virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen nächsten Dienst in der LSC durchzuführen, überträgt.
  13. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 12, wobei der Rx-Puffer der vNIC der zweiten VM oder des zweiten Behälters einen zweiten Rx-Puffer umfasst, und wobei die Paketdaten von einem ersten Rx-Puffer einer vNIC für die erste VM oder den ersten Behälter in den zweiten Rx-Puffer kopiert werden.
  14. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 12 oder 13, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): zumindest einen Teil der ersten und zweiten Rx-Puffer als jeweilige erste und zweite First-in-, First-out-Warteschlangen, FIFO-Warteschlangen, konfiguriert, und Paketdaten für ein gegebenes Paket von einem oder mehreren Schlitzen in einer ersten FIFO-Warteschlange in einen oder mehrere Schlitze in der zweiten FIFO-Warteschlange kopiert.
  15. Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 12-14, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): mehrere LSCs implementiert, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und eine lokale Flusstabelle für jede VM (112) oder jeden Behälter (606) konfiguriert, die/der ein virtuelles Netzgerät (136) beherbergt, wobei die lokale Flusstabelle für eine gegebene VM oder einen gegebenen Behälter einen Eintrag für jede der LSCs umfasst, die einen Dienst umfassen, der durch ein virtuelles Netzgerät durchgeführt werden soll, das von dieser VM oder diesem Behälter beherbergt wird, und der Eintrag für jede LSC einen vNIC-Empfangs-Port, vNIC-Rx-Port, und/oder einen Rx-Puffer für eine VM oder einen Behälter identifiziert, die/der ein nächstes virtuelles Netzgerät in der LSC beherbergt.
  16. Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 12-15, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102) einen gemeinsam genutzten Speicherraum, der für Empfangspuffer verwendet wird, die durch vNICs für jede/jeden der VMs (112) oder Behälter (606) verwendet werden, zuweist, wobei jeder VM (112) oder jedem Behälter (606) ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
  17. Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 12-16, wobei die Rechenplattform (102) eine Netzschnittstelle (104) mit mindestens einem Netzport (116) umfasst, der mit der Rechenplattform (102) kommunikativ gekoppelt ist, und wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): einen Fluss, zu dem ein an der Netzschnittstelle (104) empfangenes Paket gehört, und/oder eine LSC, die verwendet werden soll, um das Paket zu bedienen, bestimmt; und das Paket von der Netzschnittstelle (104) zu einem Empfangspuffer einer vNIC für eine VM oder einen Behälter weiterleitet, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
  18. Nichtflüchtiges maschinenlesbares Medium nach Anspruch 17, wobei das Paket durch Kopieren von Paketdaten für das Paket von einem Empfangspuffer in einem speicherabgebildeten Eingabe/Ausgabe-Adressenraum, MMIO-Adressenraum, der Netzschnittstelle (104) in den Empfangspuffer der vNIC unter Verwendung einer Direktspeicherzugriffs-Datenübertragung (DMA-Datenübertragung) weitergeleitet wird.
  19. Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 12-18, wobei die Rechenplattform (102) eine Netzschnittstelle (104) mit mindestens einem Netzport (116), der mit der Rechenplattform (102) kommunikativ gekoppelt ist, und einen Speicher umfasst, und wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): zumindest einen Abschnitt des Speichers an der Netzschnittstelle (104) als speicherabgebildeten Eingabe/Ausgabe-Adressenraum, MMIO-Adressenraum, konfiguriert, und die Netzschnittstelle (104) konfiguriert, um Paketdaten für jedes von mehreren Paketen, die von einem Netz an einem vordefinierten Netzport (116) der Netzschnittstelle (104) empfangen werden, in einem Empfangspuffer im MMIO-Adressenraum zu puffern; und Paketdaten für jedes Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM oder einen Behälter, die/der verwendet wird, um ein erstes virtuelles Netzgerät (136) zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung, DMA-Datenübertragung, zu kopieren.
  20. Nichtflüchtiges maschinenlesbares Medium nach einem der Ansprüche 12-19, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): einen Fluss bestimmt, zu dem ein Paket gehört; eine LSC bestimmt, die verwendet werden soll, um Pakete zu bedienen, die zum Fluss gehören; und Angaben zum Paket hinzufügt, die die LSC identifizieren, die verwendet werden soll, um das Paket zu bedienen.
  21. Rechenplattform (102), die Folgendes umfasst: einen Prozessor mit mehreren Prozessorkernen; einen Systemspeicher, der mit dem Prozessor wirksam gekoppelt ist; eine Netzschnittstellensteuereinheit, NIC (104), mit mindestens einem Netzport (116) und einem Speicher, der mit dem Prozessor wirksam gekoppelt ist; und eine Speichervorrichtung, auf der mehrere Befehle gespeichert sind, einschließlich Befehlen, die dazu konfiguriert sind, über einen oder mehrere der Prozessorkerne ausgeführt zu werden, um zu bewirken, dass die Vorrichtung mehrere virtuelle Maschinen, VMs (112), oder virtualisierte Behälter, Behälter (606), instantiiert, wobei jede VM (112) oder jeder Behälter (606) eine virtuelle Netzschnittstellensteuereinheit, vNIC, umfasst, wobei zumindest ein Teil der VMs (112) oder Behälter (606) ein virtuelles Netzgerät (136) beherbergt; ein Software-definiertes Netz, SDN, auf der Plattform mit einem virtuellen Koppler (109) mit virtuellen Netzports konfiguriert, die mit jeweiligen vNICs und mindestens einem Netzport an der NIC gekoppelt sind; eine lokale Dienstkette, LSC, implementiert, durch die mehrere Pakete jeweils sequentiell durch mehrere der virtuellen Netzgeräte (136) hintereinander verarbeitet werden, wobei jedes virtuelle Netzgerät (136) dazu konfiguriert ist, einen oder mehrere Dienste für jedes von mehreren Paketen durchzuführen, die von der LSC verarbeitet werden sollen; und Paketdaten, die in den mehreren Paketen enthalten sind, zwischen VMs (112) oder Behältern (606) durch Schreiben von Paketdaten von einem Puffer, der für eine erste VM oder einen ersten Behälter zugänglich ist, die/der ein erstes virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen aktuellen Dienst in der LSC durchzuführen, zu einem Empfangspuffer, Rx-Puffer, einer vNIC einer zweiten VM oder eines zweiten Behälters, die/der ein zweites virtuelles Netzgerät beherbergt, das dazu konfiguriert ist, einen nächsten Dienst in der LSC durchzuführen, überträgt.
  22. Rechenplattform (102) nach Anspruch 21, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): mehrere LSCs implementiert, wobei jede LSC eine eindeutige Sequenz von Diensten umfasst, die an Paketen durchgeführt werden sollen, die unter Verwendung dieser LSC verarbeitet werden; und eine lokale Flusstabelle für jede VM (112) oder jeden Behälter (606) konfiguriert, die/der ein virtuelles Netzgerät (136) beherbergt, wobei die lokale Flusstabelle für eine gegebene VM oder einen gegebenen Behälter einen Eintrag für jede der LSCs umfasst, die einen Dienst umfassen, der durch ein virtuelles Netzgerät (136) durchgeführt werden soll, das von dieser VM oder diesem Behälter beherbergt wird, und der Eintrag für jede LSC einen vNIC-Empfangsport, vNIC-Rx-Port, und/oder Rx-Puffer für eine VM oder einen Behälter identifiziert, die/der ein nächstes virtuelles Netzgerät (136) in der LSC beherbergt.
  23. Rechenplattform (102) nach Anspruch 21 oder 22, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102) einen gemeinsam genutzten Speicherraum zuweist, der für Empfangspuffer verwendet wird, die von vNICs für jede der VMs (112) oder jeden der Behälter (606) verwendet werden, wobei jeder VM (112) oder jedem Behälter (606) ermöglicht wird, aus dem gemeinsam genutzten Speicherraum zu lesen und in diesen zu schreiben.
  24. Rechenplattform (102) nach einem der Ansprüche 21-23, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): einen Fluss, zu dem ein Paket, das an der NIC empfangen wird, gehört, und/oder eine LSC, die verwendet werden soll, um das Paket zu bedienen, bestimmt; und das Paket von der NIC zu einem Empfangspuffer einer vNIC für eine VM (112) oder einen Behälter (606) weiterleitet, die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist.
  25. Rechenplattform (102) nach einem der Ansprüche 21-24, wobei die Ausführung der mehreren Befehle ferner bewirkt, dass die Rechenplattform (102): mindestens einen Teil des Speichers an der NIC als speicherabgebildeten Eingabe/Ausgabe-Adressenraum, MMIO-Adressenraum, konfiguriert; und die NIC dazu konfiguriert, Paketdaten für jedes von mehreren Paketen, die von einem Netz an einem vordefinierten Netzport (116) der Netzschnittstelle (104) empfangen werden, in einem Empfangspuffer im MMIO-Adressenraum zu puffern; und Paketdaten für jedes Paket vom Empfangspuffer in einen Empfangspuffer einer vNIC für eine VM (112) oder einen Behälter (606), die/der verwendet wird, um ein erstes virtuelles Netzgerät zu beherbergen, das für die LSC definiert ist, unter Verwendung einer Direktspeicherzugriffs-Datenübertragung, DMA-Datenübertragung, zu kopieren.
DE102015108145.8A 2014-06-23 2015-05-22 Lokale Dienstverkettung mit virtuellen Maschinen und virtualisierten Behältern in software-definierter Vernetzung Active DE102015108145B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/311,818 2014-06-23
US14/311,818 US10261814B2 (en) 2014-06-23 2014-06-23 Local service chaining with virtual machines and virtualized containers in software defined networking

Publications (2)

Publication Number Publication Date
DE102015108145A1 DE102015108145A1 (de) 2015-12-24
DE102015108145B4 true DE102015108145B4 (de) 2023-04-27

Family

ID=54768037

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015108145.8A Active DE102015108145B4 (de) 2014-06-23 2015-05-22 Lokale Dienstverkettung mit virtuellen Maschinen und virtualisierten Behältern in software-definierter Vernetzung

Country Status (5)

Country Link
US (1) US10261814B2 (de)
JP (2) JP6016984B2 (de)
KR (1) KR101747518B1 (de)
CN (1) CN105282135B (de)
DE (1) DE102015108145B4 (de)

Families Citing this family (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9225638B2 (en) 2013-05-09 2015-12-29 Vmware, Inc. Method and system for service switching using service tags
US9832168B2 (en) * 2014-07-01 2017-11-28 Cable Television Laboratories, Inc. Service discovery within multi-link networks
US9647894B2 (en) 2014-07-30 2017-05-09 International Business Machines Corporation Mapping relationships among virtual elements across a system
US9558041B2 (en) * 2014-09-05 2017-01-31 Telefonaktiebolaget L M Ericsson (Publ) Transparent non-uniform memory access (NUMA) awareness
US9459903B2 (en) * 2014-09-24 2016-10-04 Intel Corporation Techniques for routing service chain flow packets between virtual machines
US11296930B2 (en) 2014-09-30 2022-04-05 Nicira, Inc. Tunnel-enabled elastic service model
US9755898B2 (en) 2014-09-30 2017-09-05 Nicira, Inc. Elastically managing a service node group
US9817602B2 (en) * 2014-11-13 2017-11-14 Violin Systems Llc Non-volatile buffering for deduplication
US11340943B2 (en) 2014-12-04 2022-05-24 Nokia Solutions And Networks Gmbh & Co. Kg Steering of virtualized resources
US9445279B2 (en) * 2014-12-05 2016-09-13 Huawei Technologies Co., Ltd. Systems and methods for placing virtual serving gateways for mobility management
US10320921B2 (en) * 2014-12-17 2019-06-11 Vmware, Inc. Specializing virtual network device processing to bypass forwarding elements for high packet rate applications
US9979704B2 (en) * 2014-12-17 2018-05-22 Cisco Technology, Inc. End-to-end security for virtual private service chains
US9699060B2 (en) * 2014-12-17 2017-07-04 Vmware, Inc. Specializing virtual network device processing to avoid interrupt processing for high packet rate applications
US9462427B2 (en) * 2015-01-14 2016-10-04 Kodiak Networks, Inc. System and method for elastic scaling using a container-based platform
US10599458B2 (en) * 2015-01-23 2020-03-24 Unisys Corporation Fabric computing system having an embedded software defined network
US9584415B2 (en) * 2015-01-30 2017-02-28 Huawei Technologies Co., Ltd. Devices, systems and methods for service chains
US10812632B2 (en) * 2015-02-09 2020-10-20 Avago Technologies International Sales Pte. Limited Network interface controller with integrated network flow processing
US9571395B2 (en) * 2015-02-09 2017-02-14 Cavium, Inc. Reconfigurable interconnect element with local lookup tables shared by multiple packet processing engines
US9729442B1 (en) * 2015-03-01 2017-08-08 Netronome Systems, Inc. Method of detecting large flows within a switch fabric of an SDN switch
US10009270B1 (en) * 2015-03-01 2018-06-26 Netronome Systems, Inc. Modular and partitioned SDN switch
US9998374B1 (en) * 2015-03-01 2018-06-12 Netronome Systems, Inc. Method of handling SDN protocol messages in a modular and partitioned SDN switch
US10594743B2 (en) 2015-04-03 2020-03-17 Nicira, Inc. Method, apparatus, and system for implementing a content switch
US9860189B2 (en) * 2015-04-30 2018-01-02 Dell Products Lp Systems and methods to enable network communications for management controllers
US9971624B2 (en) 2015-05-17 2018-05-15 Nicira, Inc. Logical processing for containers
US9942131B2 (en) * 2015-07-29 2018-04-10 International Business Machines Corporation Multipathing using flow tunneling through bound overlay virtual machines
US20170031704A1 (en) * 2015-07-31 2017-02-02 Hewlett-Packard Development Company, L.P. Network port profile for virtual machines using network controller
US9667725B1 (en) * 2015-08-06 2017-05-30 EMC IP Holding Company LLC Provisioning isolated storage resource portions for respective containers in multi-tenant environments
US9781209B2 (en) * 2015-08-20 2017-10-03 Intel Corporation Techniques for routing packets between virtual machines
US10871981B2 (en) * 2015-11-01 2020-12-22 Nicira, Inc. Performing logical network functionality within data compute nodes
US10027604B2 (en) * 2015-11-24 2018-07-17 Red Hat Israel, Ltd. Implicit dynamic receive queue steering for unidirectional flows in virtualized systems
US10063469B2 (en) 2015-12-16 2018-08-28 Nicira, Inc. Forwarding element implementation for containers
WO2017122847A1 (ko) * 2016-01-12 2017-07-20 쿨클라우드(주) Sdn 기반의 네트워크 시스템의 멀티 테넌트 지원 방법 및 그 시스템
US10230633B2 (en) * 2016-01-21 2019-03-12 Red Hat, Inc. Shared memory communication in software defined networking
US10892942B2 (en) 2016-01-22 2021-01-12 Equinix, Inc. Container-based cloud exchange disaster recovery
KR101797115B1 (ko) 2016-01-25 2017-11-15 쿨클라우드(주) 컨테이너 네트워크의 컨테이너 네트워킹 방법
KR101797112B1 (ko) 2016-01-25 2017-11-15 쿨클라우드(주) 컨테이너 네트워크 관리 시스템
WO2017131285A1 (ko) * 2016-01-25 2017-08-03 쿨클라우드(주) 컨테이너 네트워크 관리 시스템 및 컨테이너 네트워킹 방법
US10083055B2 (en) * 2016-02-12 2018-09-25 At&T Intellectual Property I, L.P. Management of IoT devices in a virtualized network
US10182019B2 (en) * 2016-02-25 2019-01-15 Telefonaktiebolaget Lm Ericsson (Publ) Interconnected hardware infrastructure resource control
JP2017167763A (ja) * 2016-03-15 2017-09-21 富士通株式会社 情報処理装置、試験実行方法および試験実行プログラム
US20170272400A1 (en) * 2016-03-17 2017-09-21 Microsoft Technology Licensing, Llc Network virtualization of containers in computing systems
EP3436938A1 (de) * 2016-03-31 2019-02-06 Intel Corporation Hochdichter behälter für virtuelle maschine mit copy-on-dma-write
US10178054B2 (en) * 2016-04-01 2019-01-08 Intel Corporation Method and apparatus for accelerating VM-to-VM network traffic using CPU cache
WO2017205223A1 (en) * 2016-05-23 2017-11-30 William Turner Hyperconverged system including a user interface, a services layer and a core layer equipped with an operating system kernel
US20170366605A1 (en) * 2016-06-16 2017-12-21 Alcatel-Lucent Usa Inc. Providing data plane services for applications
CN105975330B (zh) 2016-06-27 2019-06-18 华为技术有限公司 一种网络边缘计算的虚拟网络功能部署方法、装置和系统
WO2018003020A1 (ja) * 2016-06-28 2018-01-04 日本電気株式会社 制御装置、コンテナの起動方法及びプログラム
US10237176B2 (en) * 2016-06-30 2019-03-19 Juniper Networks, Inc. Auto discovery and auto scaling of services in software-defined network environment
US11824863B2 (en) * 2016-11-03 2023-11-21 Nicira, Inc. Performing services on a host
US10148561B2 (en) 2016-12-06 2018-12-04 At&T Intellectual Property I, L.P. Enhanced quality of service in software-defined networking-based connectionless mobility architecture
US10021033B2 (en) * 2016-12-07 2018-07-10 Nicira, Inc. Context driven policy based packet capture
KR102001617B1 (ko) * 2016-12-21 2019-08-08 주식회사 나임네트웍스 컨테이너 관리 컴포넌트를 가지는 머신 관리 디바이스 및 사물 인터넷 관리 디바이스
JP6888295B2 (ja) * 2016-12-26 2021-06-16 富士通株式会社 プログラム、情報処理装置、および情報処理方法
KR101716715B1 (ko) 2016-12-27 2017-03-15 주식회사 티맥스클라우드 가상 머신 환경의 네트워크 입출력 장치 가상화 방법 및 장치
US20180181421A1 (en) * 2016-12-27 2018-06-28 Intel Corporation Transferring packets between virtual machines via a direct memory access device
US10169023B2 (en) * 2017-02-06 2019-01-01 International Business Machines Corporation Virtual container deployment
CN107071932B (zh) * 2017-03-09 2020-10-23 南京耀泽电子科技有限公司 用于数据处理的无线网关虚拟化多通道构建及控制方法
US10594829B2 (en) 2017-05-24 2020-03-17 At&T Intellectual Property I, L.P. Cloud workload proxy as link-local service configured to access a service proxy gateway via a link-local IP address to communicate with an external target service via a private network
US20180357086A1 (en) * 2017-06-13 2018-12-13 Intel Corporation Container virtual switching
US20190028409A1 (en) * 2017-07-19 2019-01-24 Alibaba Group Holding Limited Virtual switch device and method
RU181857U1 (ru) * 2017-09-13 2018-07-26 Общество с ограниченной ответственностью "Интегратор" Программно-аппаратное устройство на базе операционной системы облачной гиперконвергенции
US11018981B2 (en) * 2017-10-13 2021-05-25 Cisco Technology, Inc. System and method for replication container performance and policy validation using real time network traffic
US10805181B2 (en) 2017-10-29 2020-10-13 Nicira, Inc. Service operation chaining
US11169845B2 (en) * 2017-12-21 2021-11-09 Ciena Corporation Flow and application based processor scheduling for network functions virtualization applications using flow identification based on logical calculations on frame based fields
US10805192B2 (en) 2018-03-27 2020-10-13 Nicira, Inc. Detecting failure of layer 2 service using broadcast messages
CN110554977A (zh) * 2018-05-30 2019-12-10 阿里巴巴集团控股有限公司 数据缓存方法、数据处理方法、计算机设备、存储介质
US11283676B2 (en) 2018-06-11 2022-03-22 Nicira, Inc. Providing shared memory for access by multiple network service containers executing on single service machine
US10897392B2 (en) 2018-06-11 2021-01-19 Nicira, Inc. Configuring a compute node to perform services on a host
CN110704155B (zh) * 2018-07-09 2023-03-17 阿里巴巴集团控股有限公司 容器网络构建方法及装置、物理主机、数据传输方法
US10581730B2 (en) * 2018-07-12 2020-03-03 Vmware, Inc. Packet processing using service chains
CN110769075B (zh) * 2018-07-25 2022-07-05 中国电信股份有限公司 容器的通信方法、系统、控制器和计算机可读存储介质
US10645201B2 (en) 2018-07-31 2020-05-05 Vmware, Inc. Packet handling during service virtualized computing instance migration
CN110851371B (zh) 2018-08-20 2023-09-26 华为技术有限公司 报文处理方法及相关设备
US11595250B2 (en) 2018-09-02 2023-02-28 Vmware, Inc. Service insertion at logical network gateway
US10887251B2 (en) 2018-09-13 2021-01-05 International Business Machines Corporation Fault-tolerant architecture for packet capture
US11494212B2 (en) * 2018-09-27 2022-11-08 Intel Corporation Technologies for adaptive platform resource assignment
US11159366B1 (en) * 2018-09-28 2021-10-26 Juniper Networks, Inc. Service chaining for virtual execution elements
US11316822B1 (en) 2018-09-28 2022-04-26 Juniper Networks, Inc. Allocating external IP addresses from isolated pools
CN111124254B (zh) * 2018-10-30 2023-09-29 伊姆西Ip控股有限责任公司 调度存储空间回收请求的方法、电子设备和程序产品
US11016793B2 (en) * 2018-11-26 2021-05-25 Red Hat, Inc. Filtering based containerized virtual machine networking
US11354148B2 (en) 2019-02-22 2022-06-07 Vmware, Inc. Using service data plane for service control plane messaging
US11283732B2 (en) * 2019-03-29 2022-03-22 Juniper Networks, Inc. Network functions virtualization (NFV) backplane on forwarding microchip
KR102101602B1 (ko) * 2019-04-04 2020-04-17 한국전자통신연구원 트래픽 관리 장치 및 방법
KR102099118B1 (ko) * 2019-04-29 2020-04-09 래블업(주) 사용자가 요청한 다수개의 라이브러리를 탑재한 세션 컨테이너 제공방법
WO2020236296A1 (en) 2019-05-23 2020-11-26 Cray Inc. System and method for facilitating efficient packet injection into an output buffer in a network interface controller (nic)
KR102025435B1 (ko) * 2019-06-05 2019-09-25 주식회사 오픈케어랩 컨테이너를 이용하여 iot 서비스를 제공하는 방법, 장치 및 그를 이용한 시스템
JP7226123B2 (ja) 2019-06-19 2023-02-21 富士通株式会社 情報処理システム、情報処理装置、及び情報処理プログラム
US11277382B2 (en) * 2019-07-22 2022-03-15 Vmware, Inc. Filter-based packet handling at virtual network adapters
LU101360B1 (en) * 2019-08-26 2021-03-11 Microsoft Technology Licensing Llc Pinned physical memory supporting direct memory access for virtual memory backed containers
CN110597633A (zh) * 2019-09-12 2019-12-20 北京交通大学 一种智慧协同网络族群弹性伸缩的方法和系统
CN110580157A (zh) * 2019-09-12 2019-12-17 广东鑫光智能系统有限公司 基于软件定义的数据采集接口
US11140218B2 (en) 2019-10-30 2021-10-05 Vmware, Inc. Distributed service chain across multiple clouds
US11283717B2 (en) 2019-10-30 2022-03-22 Vmware, Inc. Distributed fault tolerant service chain
US11659061B2 (en) 2020-01-20 2023-05-23 Vmware, Inc. Method of adjusting service function chains to improve network performance
US11528219B2 (en) 2020-04-06 2022-12-13 Vmware, Inc. Using applied-to field to identify connection-tracking records for different interfaces
JP2022022059A (ja) 2020-07-22 2022-02-03 富士通株式会社 情報処理装置、情報処理プログラム、及び情報処理方法
CN112398688B (zh) * 2020-11-13 2022-06-03 广东省华南技术转移中心有限公司 容器网络配置方法、容器网络系统以及存储介质
EP4185959A1 (de) * 2020-12-15 2023-05-31 VMware, Inc. Bereitstellung von zustandsbehafteten diensten in einer skalierbaren weise für auf host-computern ausgeführte maschinen
US11734043B2 (en) 2020-12-15 2023-08-22 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
US11611625B2 (en) 2020-12-15 2023-03-21 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
CN113472848A (zh) * 2021-05-31 2021-10-01 济南浪潮数据技术有限公司 一种虚拟机和容器的网络融合方法、装置及相关设备
JP2023003987A (ja) * 2021-06-25 2023-01-17 富士通株式会社 情報処理装置、情報処理プログラム、及び情報処理方法
KR102633569B1 (ko) * 2021-10-25 2024-02-02 에스케이텔레콤 주식회사 네트워크데이터체이닝장치 및 네트워크데이터체이닝장치의 동작 방법
KR102633575B1 (ko) * 2021-10-25 2024-02-02 에스케이텔레콤 주식회사 네트워크데이터체이닝장치 및 네트워크데이터체이닝장치의 동작 방법
US20240022477A1 (en) * 2022-07-13 2024-01-18 Vmware, Inc. PLACEMENT OF VIRTUAL COMPUTING INSTANCES (VCIs) BASED ON PHYSICAL NETWORK INTERFACE CONTROLLER (NIC) QUEUE INFORMATION
CN115378822B (zh) * 2022-08-19 2023-06-06 武汉烽火技术服务有限公司 一种dds分布式应用仿真的方法和系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110090915A1 (en) 2009-10-16 2011-04-21 Sun Microsystems, Inc. Method and system for intra-host communication
WO2014004060A1 (en) 2012-06-25 2014-01-03 Advanced Micro Devices, Inc. Systems and methods for input/output virtualization

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4439100B2 (ja) 2000-09-22 2010-03-24 株式会社東芝 ネットワーク間中継装置
US7685281B1 (en) * 2004-02-13 2010-03-23 Habanero Holdings, Inc. Programmatic instantiation, provisioning and management of fabric-backplane enterprise servers
JP4622835B2 (ja) 2005-12-07 2011-02-02 株式会社日立製作所 仮想計算機システム及びそのネットワーク通信方法
US7634608B2 (en) * 2006-06-30 2009-12-15 Sun Microsystems, Inc. Bridging network components
WO2008082483A1 (en) 2006-12-21 2008-07-10 Simtone Corporation Service chaining methods and apparatus
US8219778B2 (en) 2008-02-27 2012-07-10 Microchip Technology Incorporated Virtual memory interface
JP5125659B2 (ja) 2008-03-24 2013-01-23 富士通株式会社 情報処理装置、情報処理方法及びコンピュータプログラム
JP2009230479A (ja) 2008-03-24 2009-10-08 Toshiba Microelectronics Corp マイクロプロセッサ
US8031731B2 (en) * 2008-06-09 2011-10-04 Oracle America, Inc. System for sharing a network port of a network interface including a link for connection to another shared network interface
JP5352132B2 (ja) 2008-06-19 2013-11-27 株式会社日立製作所 計算機システム及びそのｉ／ｏ構成変更方法
JP5532793B2 (ja) 2009-09-28 2014-06-25 富士通株式会社 プログラム及び通信制御方法
JP5720577B2 (ja) 2009-12-04 2015-05-20 日本電気株式会社 サーバ及びフロー制御プログラム
US20110153909A1 (en) 2009-12-22 2011-06-23 Yao Zu Dong Efficient Nested Virtualization
US8739177B2 (en) 2010-06-21 2014-05-27 Intel Corporation Method for network interface sharing among multiple virtual machines
US9923826B2 (en) * 2011-10-14 2018-03-20 Citrix Systems, Inc. Systems and methods for dynamic adaptation of network accelerators
US8521905B2 (en) 2011-12-22 2013-08-27 Telefonaktiebolaget L M Ericsson (Publ) System for flexible and extensible flow processing in software-defined networks
US20130279378A1 (en) * 2012-04-19 2013-10-24 Delphax Technologies Canada, Ltd. Cascaded Streaming of Data Through Virtual Chain of Nodes in Hub Topology
US9106508B2 (en) * 2012-04-30 2015-08-11 International Business Machines Corporation Providing services to virtual overlay network traffic
US9769061B2 (en) 2012-05-23 2017-09-19 Brocade Communications Systems, Inc. Integrated heterogeneous software-defined network
US9661522B2 (en) 2012-07-09 2017-05-23 Cisco Technology, Inc. System and method associated with a service flow router
US9571507B2 (en) 2012-10-21 2017-02-14 Mcafee, Inc. Providing a virtual security appliance architecture to a virtual cloud infrastructure
JP2014096675A (ja) * 2012-11-08 2014-05-22 Hitachi Ltd 通信装置、及び、設定方法
US9356871B2 (en) * 2013-03-15 2016-05-31 Cisco Technology, Inc. Programmable management engine for networks
US9967181B2 (en) * 2014-01-13 2018-05-08 Futurewei Technologies, Inc. Packet labeling in a virtual network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110090915A1 (en) 2009-10-16 2011-04-21 Sun Microsystems, Inc. Method and system for intra-host communication
WO2014004060A1 (en) 2012-06-25 2014-01-03 Advanced Micro Devices, Inc. Systems and methods for input/output virtualization

Also Published As

Publication number Publication date
JP6016984B2 (ja) 2016-10-26
JP2016009486A (ja) 2016-01-18
DE102015108145A1 (de) 2015-12-24
KR20150146391A (ko) 2015-12-31
JP2017022767A (ja) 2017-01-26
KR101747518B1 (ko) 2017-06-14
CN105282135A (zh) 2016-01-27
CN105282135B (zh) 2019-07-26
US10261814B2 (en) 2019-04-16
US20150370586A1 (en) 2015-12-24

Similar Documents

Publication Publication Date Title
DE102015108145B4 (de) Lokale Dienstverkettung mit virtuellen Maschinen und virtualisierten Behältern in software-definierter Vernetzung
DE112014000415B4 (de) Quantisierte Überlastbenachrichtigung in einem virtuellen Netzwerksystem
DE112008002550B4 (de) Verfahren und System für virtuelle Schnittstellenkommunikation
DE112016000258B4 (de) Gruppieren von nichtflüchtigem speicher auf grundlage von hosts mithilfe von zugeordnetem netzwerkspeicher
DE112012002998B4 (de) Virtuelle Netzwerküberlagerungen
DE102013209372B4 (de) Ein für die Aggregation virtueller Ethernet-Ports (VEPA) geeignetes mandantenfähiges Overlay-Netzwerk
DE112013000731B4 (de) Skalierbare virtuelle Geräte-Cloud
DE112012001198B4 (de) Verfahren zum Bereitstellen ortsunabhängigen Anschlussspiegelns auf verteilten virtuellen Switches
DE112020001833T5 (de) Netzwerkschnittstelle für Datentransport in heterogenen Rechenumgebungen
DE102020201834A1 (de) Technologien für netzvorrichtungslastausgleichseinrichtungen für beschleunigte funktionen-als-dienst
DE102019105069A1 (de) Technologien zur netzpaketverarbeitung zwischen cloud- und telekommunikationsnetzen
DE102020109669A1 (de) Dienstgüte-verkehrsmanagement in hochgeschwindigkeitspaketverarbeitungssystemen
DE202016107377U1 (de) Systeme zur Auslagerung von Netzwerkfunktionen über Paket-Trunking
DE112012002404B4 (de) Konfiguration und Management virtueller Netzwerke
DE112007001529T5 (de) Flexibles und erweiterbares Receive Side Scaling
DE112016005933T5 (de) Technologien zum Durchsetzen einer Netzwerkzugriffssteuerung fiir virtuelle Maschinen
DE102020129690A1 (de) Semiflexibler paketzusammenführungs-steuerweg
DE112013001904T5 (de) Paketvermittlung auf der Ebene 2 ohne Nachschlagetabelle für Ethernet-Switches
DE102022205478A1 (de) Busübergreifende speicherabbildung
DE102019127285A1 (de) Verfahren und Vorrichtung zur sicheren Datenzentrumsüberbrückung in einem Multi-Tenant-System
DE102021207394A1 (de) Zusammenführen von paketen auf der grundlage von hinweisen, die vom netzwerkadapter erzeugt werden
DE112022002284T5 (de) Auslagerung der vermittlungsschicht 7 an eine infrastrukturverarbeitungseinheit für ein vermaschtes dienstnetz
DE102022126611A1 (de) Service-mesh-auslagerung an netzwerkvorrichtungen
DE112017003494T5 (de) Mehrfach-core-software-forwarding
DE112021004377T5 (de) Systeme zum aufbau von datenstrukturen mit hoch skalierbaren algorithmen für eine verteiltelpm-implementierung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012700000

Ipc: H04L0012931000

R016 Response to examination communication
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012931000

Ipc: H04L0049100000

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final