DE102015013946A1

DE102015013946A1 - Netzwerkbasiertes Service Function Chaining

Info

Publication number: DE102015013946A1
Application number: DE102015013946.0A
Authority: DE
Inventors: Nicholas Ilyadis; Ariel Hendel; Hamid Assarpour
Original assignee: Broadcom Corp
Current assignee: Avago Technologies International Sales Pte Ltd
Priority date: 2014-11-11
Filing date: 2015-10-29
Publication date: 2016-05-12
Also published as: US9923815B2; HK1218477A1; US20160134531A1; CN105591978A; CN105591978B

Abstract

Dienstbewusste Netzwerkvorrichtungen koordinieren Funktionsketten virtueller Funktionen. Die Netzwerkvorrichtungen haben Kenntnis darüber, welche virtuellen Funktionen existieren, und wie sie auf effizienteste Art und Weise miteinander zu verbinden sind, und definieren und verarbeiten Dienstdiagramme, die gespeichert, überwacht und weitergesendet werden können. Die Netzwerkvorrichtungen selbst implementieren und verwalten die Dienstdiagramme im Gegensatz zu den virtuellen Servern, die die virtuellen Funktionen hosten.

Description

Technisches Gebiet
Die vorliegende Offenbarung bezieht sich auf Netzwerkfunktionsvirtualisierung.
Hintergrund
Die Verarbeitungsleistung, die Speicherkapazität, der verfügbare Speicherplatz und andere für Verarbeitungssysteme verfügbare Ressourcen sind exponentiell gestiegen. Rechnerressourcen haben sich bis zu einem Punkt entwickelt, bei dem ein einziger physikalischer Server viele virtuelle Maschinen und virtualisierte Funktionen hosten kann. Jede virtuelle Maschine stellt typischerweise virtualisierte Prozessoren, Datenspeicher, Speicher, Netzwerkverbindungsfähigkeit und andere Ressourcen bereit. Gleichzeitig sind Hochgeschwindigkeits-Datennetze entstanden und zur Reife gelangt, und bilden nun einen Teil des Rückgrats von dem, was zu einer unverzichtbaren weltweiten Datenverbindungsfähigkeit geworden ist, einschließlich der Verbindungsfähigkeit zu virtuellen Maschinenhosts. Verbesserungen der Virtualisierung treiben die weitere Entwicklung und Nutzung der Virtualisierungsfunktionalität an.
Kurzer Überblick über die Erfindung
Gemäß einem Aspekt weist ein Netzwerk-Switch auf:
eine Netzwerkfluss-Schnittstelle zu dem Netzwerk-Switch, wobei die Netzwerkfluss-Schnittstelle dazu konfiguriert ist, einen Netzwerkfluss zu empfangen, der ein Paket aufweist;
einen Speicher, der dazu konfiguriert ist, eine Netzwerkdienstketten-Definition zu speichern, wobei die Netzwerkdienstketten-Definition ein Dienstfunktions-Spezifikationssymbol einer Dienstfunktion aufweist, die auf einer Server-Ressource getrennt von dem Netzwerk-Switch vorgehalten wird; und
Dienstketten-Verarbeitungsschaltung, die mit der Netzwerkfluss-Schnittstelle und dem Speicher in Verbindung steht, wobei die Dienstketten-Verarbeitungsschaltung konfiguriert ist zum:
Bestimmen, dass die Netzwerkdienstketten-Definition für den Netzwerkfluss zutrifft;
Bestimmen, dass das Paket als nächstes von der Dienstfunktion verarbeitet werden sollte;
Aktualisieren eines Dienstfunktionsindexes, um den Verlauf des Pakets durch die Netzwerkdienstketten-Definition zu verfolgen;
Kennzeichnen des Pakets mit einer Netzwerkadresse für die Dienstfunktion; und
Weiterleiten des Pakets aus dem Netzwerk-Switch zu der Dienstfunktion auf der Server-Ressource.
Vorteilhaft ist die Dienstketten-Verarbeitungsschaltung des Weiteren konfiguriert zum:
Erhalten einer Flussklassifizierung für das Paket; und
Abbilden der Flussklassifizierung auf die Netzwerkdienstketten-Definition, um zu bestimmen, dass die Netzwerkdienstketten-Definition für den Netzwerkfluss zutrifft.
Vorteilhaft:
weist die Flussklassifizierung eine Anwendungskennung, eine Teilnehmerkennung oder beides auf.
Vorteilhaft:
spezifiziert die Netzwerkdienstketten-Definition eine sequenzielle Reihenfolge zur Ausführung der Dienstfunktion in der Netzwerkdienstketten-Definition; und
ist die Dienstketten-Verarbeitungsschaltung des Weiteren konfiguriert zum:
Lesen eines Paket-Headers des Pakets, um einen aktuellen Indexwert zu bestimmen; und
Anpassen des aktuellen Indexwerts an die Netzwerkdienstketten-Definition, um zu bestimmen, dass das Paket als nächstes von der Dienstfunktion verarbeitet werden sollte.
Vorteilhaft:
ist die Dienstketten-Verarbeitungsschaltung des Weiteren dazu konfiguriert, einen Dienstfunktionsindex zu aktualisieren, um die Weiterleitung des Pakets an die Dienstfunktion zur Verarbeitung zu bedingen.
Vorteilhaft:
ist die Dienstketten-Verarbeitungsschaltung des Weiteren dazu konfiguriert, von der Server-Ressource das Paket nach der Verarbeitung durch die Servicefunktion zu empfangen; und
ein Folgeziel in der Netzwerkdienstketten-Definition basierend auf dem Dienstfunktionsindex zu bestimmen.
Vorteilhaft:
ist die Dienstketten-Verarbeitungsschaltung des Weiteren konfiguriert zum:
nochmaligen Aktualisieren des Dienstfunktionsindexes für das Paket, um den Verlauf des Pakets durch die Netzwerkdienstketten-Definition zu verfolgen; und
Weiterleiten des Pakets aus dem Netzwerk-Switch an das Folgeziel.
Vorteilhaft:
ist das Folgeziel eine andere Dienstfunktion, die auf einer anderen Server-Ressource vorgehalten wird.
Vorteilhaft:
ist die andere Server-Ressource mit einem separaten Netzwerk-Switch verbunden.
Gemäß einem Aspekt umfasst ein Verfahren:
in einem Netzwerk-Switch, der Hostserver miteinander verbindet, auf denen eine erste Dienstfunktion und eine zweite Dienstfunktion vorgehalten werden:
Definieren, in einem Speicher, einer Netzwerkdienstketten-Definition, die eine Abfolge von Dienstfunktionen spezifiziert, mit:
der ersten Dienstfunktion; und
der zweiten Dienstfunktion;
wobei die Netzwerkdienstketten-Definition aufweist:
einen ersten Dienstfunktionsindex für die erste Dienstfunktion; und
einen zweiten Dienstfunktionsindex für die zweite Dienstfunktion;
wobei der erste und der zweite Dienstfunktionsindex die erste Dienstfunktion vor der zweiten Dienstfunktion anordnen;
Empfangen eines Pakets, das Teil eines Netzwerkflusses ist;
Empfangen von Klassifizierungsinformationen für das Paket;
basierend auf den Klassifizierungsinformationen Bestimmen, dass die Netzwerkdienstkette für den Netzwerkfluss zutrifft;
Bestimmen, dass die erste Dienstfunktion als nächstes das Paket verarbeiten sollte; und
Weiterleiten des Pakets an die erste Dienstfunktion.
Vorteilhaft umfasst das Verfahren des Weiteren:
Bestimmen einer Dienstkettenkennung und eines Dienstfunktionsindexes für das Paket, nachdem es empfangen wurde und bestimmt wurde, dass die Netzwerkdienstkette für den Netzwerkfluss zutrifft.
Vorteilhaft:
identifiziert die Dienstkettenkennung die Netzwerkdienstketten-Definition; und
identifiziert der Dienstfunktionsindex die erste Dienstfunktion.
Vorteilhaft umfasst das Verfahren des Weiteren:
Hinzufügen eines Dienstfunktionsketten-Headers zu dem Paket, wobei der Dienstfunktionsketten-Header den Dienstfunktionsindex und die Dienstkettenkennung aufweist.
Vorteilhaft umfasst das Verfahren des Weiteren:
Einstellen des Dienstfunktionsindexes, um auf die zweite Dienstfunktion zu zeigen, bevor das Paket an die erste Dienstfunktion weitergeleitet wird.
Vorteilhaft umfasst das Verfahren des Weiteren:
Abbilden der Dienstkettenkennung und des Dienstfunktionsindexes auf eine Netzwerkadresse für die erste Dienstfunktion.
Vorteilhaft umfasst das Verfahren des Weiteren:
wobei die Netzwerkadresse eine virtuelle Switch-Adresse, eine Dienstfunktions-Netzwerkadresse aufweist.
Vorteilhaft umfasst das Verfahren des Weiteren:
vor dem Weiterleiten, Hinzufügen eines Rechenzentrums-Routingheaders zu dem Paket, wobei der Rechenzentrums-Routingheader aufweist:
eine virtuelle Switch-Adresse eines virtuellen Switches, der als Hostserver für die erste Dienstfunktion dient; und
eine Dienstfunktions-Netzwerkadresse für die erste Dienstfunktion auf dem Hostserver.
Gemäß einem Aspekt weist ein Netzwerk-Switch auf:
eine Paketschnittstelle, die dazu konfiguriert ist, Pakete in den Netzwerk-Switch zu empfangen und Pakete aus dem Netzwerk-Switch zu kommunizieren;
einen Speicher, der konfiguriert ist zum Speichern von:
Netzwerkdienstketten-Definitionen, die aufweisen:
eine erste Netzwerkdienstketten-Definition, die eine erste Abfolge von Dienstfunktionen spezifiziert, die eine erste Paketverarbeitungskette darstellen; und
eine erste Dienstkettenkennung für die erste Netzwerkdienstketten-Definition; und
eine Dienstketten-Abbildungstabelle, die aufweist:
eine Klassifizierungsabbildung von der Paketklassifizierung auf die Netzwerkdienstketten-Definitionen in dem Speicher;
einen Dienstketten-Prozessor, der mit der Paketschnittstelle in Verbindung ist, wobei der Dienstketten-Prozessor konfiguriert ist zum:
Erhalten von Klassifizierungsinformationen für die Pakete;
Bestimmen, aus den Klassifizierungsinformationen und der Dienstketten-Abbildungstabelle, dass die erste Netzwerkdienstkette die Pakete verarbeiten sollte;
Bestimmen einer nächsten Dienstfunktion, die auf den Paketen ausgeführt werden soll, aus der ersten Abfolge von Dienstfunktionen;
Verfolgen des Verlaufs der Pakete durch die erste Netzwerkdienstkette durch Aktualisieren eines Dienstfunktions-Headers der Pakete;
Hinzufügen eines Routing-Headers zu den Paketen, wobei der Routing-Header aufweist:
eine virtuelle Switch-Adresse eines virtuellen Switches, der mit einem Hostserver für die nächste Dienstfunktion in Verbindung ist; und
eine Dienstfunktions-Netzwerkadresse für die nächste Dienstfunktion auf dem Hostserver; und
Weiterleiten der Pakete aus dem Netzwerk-Switch an die nächste Dienstfunktion auf dem Hostserver.
Vorteilhaft:
weist der Dienstfunktions-Header auf:
die erste Dienstkettenkennung; und
einen Dienstfunktionsindex in der ersten Netzwerkdienstkette.
Vorteilhaft:
ist der Netzwerk-Switch dazu konfiguriert:
die Pakete nach dem Verarbeiten durch die nächste Dienstfunktion an dem Netzwerk-Switch zurück zu empfangen; und wobei:
der Dienstketten-Prozessor dazu konfiguriert ist:
den Verlauf zu verfolgen durch Ändern des Dienstfunktionsindexes in der ersten Netzwerkdienstkette, um auf eine folgende Dienstfunktion zu zeigen, die der nächsten Dienstfunktion für die Pakete folgt; und
die nach der Verarbeitung durch die nächste Dienstfunktion empfangenen Pakete an die folgende Dienstfunktion in der ersten Netzwerkdienstkette weiterzuleiten.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein Beispiel eines Netzwerks, das virtuelle Maschinenhosts aufweist, die durch Netzwerkvorrichtungen verbunden sind.
2 zeigt einen virtuellen Maschinenhost, der dazu konfiguriert ist, virtuelle Maschinen und virtuelle Funktionen auszuführen.
3 zeigt ein beispielhaftes Netzwerk für Service Function Chaining (Dienstfunktionsverkettung).
4 zeigt ein Beispiel eines Top-of-Rack Switches.
5 zeigt eine Overlay Tunnel Topologie für netzwerkbasiertes Service Function Chaining.
6 zeigt die Weiterleitung in einer Dienstfunktionskette in einem Rack.
7 zeigt die Weiterleitung in einer Dienstfunktionskette, die sich durch Top-of-Rack Switches über Racks hinweg erstreckt.
8 zeigt eine beispielhafte Service Function Chain.
9 zeigt ein weiteres Beispiel der Weiterleitung in einer Dienstfunktionskette, die sich durch Top-of-Rack Switches über Racks hinweg erstreckt.
10 zeigt ein weiteres Beispiel der Weiterleitung in einer Dienstfunktionskette, die sich durch Top-of-Rack Switches über Racks hinweg erstreckt.
11 zeigt ein weiteres Beispiel der Weiterleitung in einer Dienstfunktionskette in einem Rack.
12 zeigt ein Beispiel von Logik, die durch einen Netzwerkknoten implementiert werden kann, um netzwerkbasiertes Service Function Chaining durchzuführen.
DETAILLIERTE BESCHREIBUNG
Einführung

Die 1 und 2 stellen einen Kontext für die weitere Erörterung des netzwerkbasierten Service Function Chaining bereit, das beginnend mit 3 unten näher beschrieben ist. Einige der unten verwendeten SFC-Abkürzungen sind in Tabelle 1 zusammengefasst:

Tabelle 1
Abkürzung	Bedeutung
SFC	service function chaining [Dienstfunktionsverkettung]
SC	service function chain [Dienstfunktionskette]
SCID	service chain identifier [Dienstkettenkennung]
SF	service function [Dienstfunktion]
SFI	service function index [Dienstfunktionsindex]
SCC	service chain classifier [Dienstkettenklassifizierer]
SFF	service function forwarder [Dienstfunktionsversender]
VS	virtual switch [virtueller Switch]
VM	virtual machine [virtuelle Maschine]
STEP	service tunnel endpoint [Diensttunnelendpunkt]
XTEP	data center endpoint [Rechenzentrumsendpunkt]
ToR	top of rack [Oberseite des Racks]

1 zeigt ein beispielhaftes Netzwerk 100. In dem Netzwerk 100 routen Netzwerkvorrichtungen Pakete (z. B. das Paket 102) von Quellen (z. B. der Quelle 104) an Ziele (z. B. das Ziel 106) über eine beliebige Anzahl und eine beliebige Art von Netzwerken (z. B. das Ethernet/TCP/IP Netzwerk 108). Die Netzwerkvorrichtungen können viele verschiedene Formen annehmen und können in beliebiger Anzahl vorliegen. Das Netzwerk 108 kann zum Beispiel mehrere Router und Switches überspannen. Beispiele für Netzwerkvorrichtungen umfassen Switches, Brücken, Router und Hubs. Andere Arten von Netzwerkvorrichtungen können jedoch ebenso in dem Netzwerk 100 vorhanden sein.
Das Netzwerk 100 ist nicht auf eine bestimmte Implementierung oder einen bestimmten geografischen Bereich begrenzt. Um nur einige Beispiele zu nennen, kann das Netzwerk 100 ein privates firmenweites Intranet, ein Fernverteilungsnetz für Kabel- oder Satellitenfernsehen, Internet-Zugang und Audio- und Video-Streaming, oder ein globales Netzwerk (z. B. das Internet) kleinerer miteinander verbundener Netzwerke repräsentieren. In dieser Hinsicht kann das Rechenzentrum 110 eine hoch konzentrierte Serverinstallation 150 mit dazugehörigem Netzwerk-Switch und Router-Verbindungsfähigkeit 152 darstellen. Das Rechenzentrum 110 kann E-Commerce mit extrem großem Volumen, Suchmaschinen, Cloudspeicher und Clouddienste, Streaming Video- oder Audiodienste oder beliebige andere Arten von Funktionalität unterstützen.
Bei dem Beispiel von 1 weist das Netzwerk 100 Betreiber und Anbieter von Kabel- oder Satellitenfernsehdiensten, Telefondiensten und Internetdiensten auf. In dieser Hinsicht zeigt 1 zum Beispiel, dass das Netzwerk 100 eine beliebige Anzahl von Cable Modem Termination Systems (CMTSs) 112 aufweisen kann. Die CMTSs 112 können für eine beliebige Anzahl von Gateways, z. B. die Gateways 114, 116, 118, Dienste anbieten. Die Gateways können Kabelmodems, kombinierte Kabelmodems und drahtlose Router oder andere Arten von Eintrittspunktsystemen in beliebige einer breiten Vielfalt von Orten 121 darstellen, zum Beispiel Häuser, Büros, Schulen und Regierungsgebäude. Das Netzwerk 100 kann andere Arten von Endsystemen und Gateways aufweisen. Das Netzwerk 100 kann zum Beispiel Digital Subscriber Line (DSL) Endsysteme und DSL-Modems aufweisen, die als Eintrittspunkte in Häuser, Büros oder andere Orte dienen.
An jedem gegebenen Ort kann sich das Gateway mit einer beliebigen Anzahl und einer beliebigen Art von Knoten verbinden. Bei dem Beispiel von 1 weisen die Knoten Digitalempfänger (Set Top Boxes; STBs), zum Beispiel die STBs 120, 122, 124, auf. Andere Beispiele von Knoten weisen netzwerkverbundene intelligente TVs 126, Audio-/Video-Receiver 128, digitale Videorecorder (DVRs) 130, Streaming Media Player 132, Spielesysteme 134, Computersysteme 136 und Player für physikalische Medien (z. B. BluRay) auf. Die Knoten können jede Art von Teilnehmer-Endgeräten (Customer Premises Equipment; CPE) repräsentieren.
2 zeigt einen virtuellen Maschinenhost 200 (”Host”), der dazu konfiguriert ist, virtuelle Switches, virtuelle Maschinen und virtuelle Funktionen auszuführen. Alle der Vorrichtungen in dem Netzwerk 100 können Hosts sein, einschließlich der Knoten, Gateways, CMTSs, Switches, Server, Quellen und Ziele. Die Hosts stellen eine Umgebung bereit, in der jede ausgewählte Funktionalität laufen kann, durch das Netzwerk 100 erreichbar sein kann und die Gesamtheit oder einen Teil einer Kette von Funktionalitäten bilden kann, um jede definierte Verarbeitungs- oder Inhaltslieferungsaufgabe zu erfüllen. Die Funktionalität kann in dem Sinne virtuell sein, dass beispielsweise die virtuellen Funktionen als Software, die auf den Hosts läuft, Funktionen implementieren, die in der Vergangenheit mit dedizierter Hardware ausgeführt wurden.
In 2 weist der Host 200 eine oder mehrere Kommunikationsschnittstellen 202, Systemschaltung 204, Eingangs-/Ausgangsschnittstellen 206 und eine Anzeige 208 auf, auf der der Host 200 eine Benutzerschnittstelle 209 erzeugt. Die Kommunikationsschnittstellen 202 können Sender und Empfänger („Transceiver”) 238 und beliebige Antennen 240 aufweisen, die von den Transceivern 238 verwendet werden. Die Transceiver 238 können Bitübertragungsschichtschnittstellen für jedes eines weiten Bereichs von Kommunikationsprotokollen 242 bereitstellen, zum Beispiel jede Art von Ethernet, Data Over Cable Service Interface Specification (DOCSIS), Digital Subscriber Line (DSL), Multimedia over Coax Alliance (MOCA), oder ein anderes Protokoll. Wenn die Kommunikationsschnittstellen 202 mobile Verbindungsfähigkeit unterstützen, kann der Host auch eine SIM-Karten-Schnittstelle 210 und eine SIM-Karte 212 aufweisen. Der Host 200 weist auch Speichervorrichtungen wie zum Beispiel Festplattenlaufwerke (hard disk drives; HDDs) 214 und Festkörperlaufwerke (solid state disk drives; SDDs) 216, 218 auf.
Die Benutzerschnittstelle 209 und die Eingangs-/Ausgangsschnittstellen 206 können eine graphische Benutzerschnittstelle (graphical user interface; GUI), eine berührungsempfindliche Anzeige, Sprach- oder Gesichtserkennungseingänge, Schaltflächen, Switches, Lautsprecher und andere Benutzerschnittstellenelemente aufweisen. Zusätzliche Beispiele der Eingangs-/Ausgangs-Schnittstellen 206 weisen Mikrofone, Video- und Standbild-Kameras, Kopfhörer- und Mikrofon-Eingangs-/Ausgangs-Buchsen, Universal Serial Bus (USB) Stecker, Speicherkartenschlitze und andere Arten von Eingängen auf. Die Eingangs-/Ausgangs-Schnittstellen 206 können des Weiteren magnetische oder optische Medienschnittstellen (z. B. ein CDROM- oder DVD-Laufwerk), serielle und parallele Busschnittstellen und Tastatur- und Mausschnittstellen aufweisen.
Die Systemschaltung 204 kann jede beliebige Kombination aus Hardware, Software, Firmware oder anderer Logik aufweisen. Die Systemschaltung 204 kann zum Beispiel mit einem oder mehreren Systemen auf einem Chip (systems an a chip; SoC), anwendungsspezifischen integrierten Schaltungen (application specific integrated circuit; ASIC), diskreten analogen und digitalen Schaltungen und anderen Schaltungen implementiert werden. Die Systemschaltung 204 ist Teil der Implementierung jeder gewünschten Funktionalität in dem Host 200. In dieser Hinsicht kann die Systemschaltung 204 Schaltung aufweisen, die, um nur einige Beispiele zu nennen, das Laufen virtueller Maschinen, Switches und Funktionen, das Routen von Paketen zwischen den virtuellen Maschinen und dem Netzwerk, und das Schalten von Paketen zwischen den virtuellen Maschinen erleichtert.
Um nur ein Beispiel zu nennen, kann die Systemschaltung 204 einen oder mehrere Prozessoren 220 und Speicher 222 aufweisen. Der Speicher 222 und die Speichervorrichtungen 214, 216 speichern zum Beispiel Steuerbefehle 224 und ein Betriebssystem 226. Der Prozessor 220 führt die Steuerbefehle 243 und das Betriebssystem 226 aus, um jede gewünschte Funktionalität für den Host 200 durchzuführen. Die Steuerparameter 228 liefern und spezifizieren Konfigurations- und Betriebsoptionen für die Steuerbefehle 224, das Betriebssystem 226 und andere Funktionalität des Hosts 200.
Bei einigen Implementierungen weisen die Steuerbefehle 224 einen Hypervisor 230 auf. Der Hypervisor 230 stellt eine Überwachungssoftwareumgebung bereit, die eine oder mehrere virtuelle Maschinen (VMs), virtuelle Switches (VSs) 232, virtuelle Firewalls, virtuelle Betriebssysteme, virtuelle Netzwerkschnittstellenkarten (network interface cards; NICs) oder beliebige andere gewünschte Virtualisierungskomponenten ausführt. Bei anderen Implementierungen ist der Host 200 ein Virtualisierungshost direkt auf der Hardware. Das heißt, der Host 200 braucht kein separates Betriebssystem 226 ausführen, auf dem der Hypervisor 230 läuft. Stattdessen kann der Hypervisor 230 direkt mit den physikalischen Hardware-Ressourcen in dem Host 220 kommunizieren und diese steuern, ohne Überwachung oder Eingreifen durch ein separates Betriebssystem.
Der Host 200 kann eine beliebige Anzahl von VMs 234 ausführen. Jede VM kann eine beliebige Anzahl oder Art von virtuellen Funktionen (VFs) 236 ausführen. Die VFs können Softwareimplementierungen jeder gewünschten Funktionalität sein, die zum Beispiel von hoch spezialisierten Netzwerkfunktionen bis zu Verarbeitungsfunktionen für den allgemeinen Zweck reicht.
Um nur einige Beispiele von Dienstfunktionen zu nennen, können die VFs 236 Netzwerk-Firewalls, Nachrichten-Spamfilter und Netzwerkadress-Translatoren implementieren. Als anderes Beispiel von Verarbeitungsfunktionen können die VFs 236 Audio- und Video-Codierer und -Transcodierer, digitales Rechtemanagement(digital rights management; DRM)-Verarbeitung, Datenbank-Nachschlagen, E-Commerce Transaktionsverarbeitung (z. B. Rechnungstellung und Zahlung), Webhosting, Content Management, kontextgesteuerte Werbung und Sicherheitsverarbeitung wie zum Beispiel High-bandwidth Digital Content Protection (HDCP) und Digital Transmission Content Protection(DTCP-IP)-Verarbeitung implementieren. Zusätzliche Beispiele für VFs 236 umfassen Audio-, Video- und Bildkomprimierung und -dekomprimierung, wie zum Beispiel H.264-, MPG- und MP4-Komprimierung und -Dekomprimierung, Audio- und Video-Vor- und -Nachbearbeitung, Serverfunktionalität wie zum Beispiel Video-auf-Abruf-Server, DVR-Server, Over The Top (OTT) Server, Speicherung, Erzeugung und Anwendung sicherer Schlüssel, und Anzeigen von 2D- und 3D-Grafiken.
Netzwerkbasiertes Service Chaining
Netzwerkbasiertes Service Function Chaining (SFC) bedingt ein dienstbewusstes Netzwerk. In dem Netzwerk selbst haben Netzwerkvorrichtungen wie zum Beispiel Top of Rack (ToR) Switches Kenntnis darüber, welche Dienstfunktionen (service functions; SFs) existieren, z. B. die VFs 236, welche Hosts die Dienstfunktionen ausführen, über die Verbindungsfähigkeitspfade zwischen Hosts und den Netzwerkvorrichtungen, und wie die Dienstfunktionen auf effiziente Weise zu verbinden sind, um eine Ende-zu-Ende-Dienstkette (service chain; SC) der Verarbeitung zu bilden. Dienstfunktionen können virtuelle Funktionen (virtual functions; VFs) sein, die auf einer VM laufen, können nicht virtualisierte Funktionen beliebiger Art sein, die auf einem physikalischen Server außerhalb einer Virtualisierungsumgebung laufen, oder können anderweitig in Vorrichtungen vorgehalten werden, die mit dem Netzwerk verbunden sind.
Die Netzwerkvorrichtungen (z. B. die ToR-Switches) überwachen, erzeugen und speichern Definitionen von SCs, die eine Sequenz von Dienstfunktionen für eine beliebige gewünschte Paketverarbeitung definieren. Die Netzwerkvorrichtungen bestimmen den nächsten Hop für Pakete entlang einer beliebigen gegebenen SC und verfolgen den Verlauf durch die SC. Ein Ergebnis ist, dass die Hosts 200, die VFs 236 und die virtuellen Switches 234 keine Informationen über den Weiterleitungszustand der Dienstverkettung speichern müssen. Stattdessen verarbeiten die Hosts 200 die Pakete lokal gemäß den gehosteten SFs, die zu einer beliebigen gegebenen SC zugehörig sind, und senden diese Pakete nach der Verarbeitung an die Netzwerkvorrichtungen zurück. Die Netzwerkvorrichtungen treffen eine Entscheidung über die nächste SF und den Ort der nächsten SF. Dann leiten die Netzwerkvorrichtungen die Pakete an das geeignete Ziel zur fortgesetzten Verarbeitung durch die SC weiter.
Die SFC-Fähigkeiten des Netzwerks ermöglichen es einem Netzwerk, logische Verbindungen unter und zwischen einer oder mehreren Dienstfunktionen in einer bestimmten Reihenfolge zu erzeugen, um eine Sequenz von Dienstfunktionen bereitzustellen, die von der zugrunde liegenden physikalischen Netzwerktopologie unabhängig ist. Die Architektur kann als Teil von SFC mehrere funktionelle Komponenten implementieren, einschließlich eines SFC-Klassifizierers (SFC Classifier; SCC) und eines Dienstfunktions-Absenders (Service Function Forwarder; SFF). Der SCC kann die Teilnehmer- oder Kunden-Paketflüsse oder -Teilflüsse auf eine bestimmte SC abbilden, zum Beispiel im Ansprechen auf eine festgelegte Richtlinie für den Kunden, den Verkehrstyp, den Grad der Dienstgüte, Zeit und Datum, Quelle oder andere Abbildungskriterien.
Der SFF leitet Pakete von einer SF an die nächste im Kontext der für den Paketfluss bestimmten SC weiter. Es wird angemerkt, dass anstatt des Implementierens der SCC- und der SFF-Funktionen in einem Serverknoten (oder einer anderen Endpunktvorrichtung) die unten beschriebene Architektur diese Funktionen in den Netzwerkvorrichtungen selbst implementieren kann. Bei anderen Implementierungen werden die Informationen der SFC-Klassifizierung durch Knoten bestimmt, die sich von den Netzwerkvorrichtungen, die SFC durchführen, unterscheiden, und diese Knoten liefern die Klassifizierungsinformationen an die Netzwerkvorrichtungen, die SFC durchführen.
Anders ausgedrückt kann die Architektur SFC mit der Hardwareverarbeitungsfähigkeit eines Netzwerk-Switches implementieren. Als ein bestimmtes Beispiel kann die Architektur SFC in einem ToR-Switch implementieren. In einigen Fällen ist der Netzwerk-Switch Teil eines Rechenzentrums und kann sich die SFC-Verantwortung mit anderen Netzwerk-Switches in dem Rechenzentrum oder anderswo teilen. Das heißt, das SFC kann unter mehreren Netzwerkvorrichtungen verteilt werden, von denen jede für einen Teil der SC verantwortlich ist.
3 zeigt ein beispielhaftes Netzwerk 300 für SFC. Das SFC ist netzwerkbasiert und verwendet SFC-fähige ToR-Switches 302, 304 und 306. Die ToR-Switches können skalierbare SFC-Prozessoren aufweisen, die die weiter unten beschriebene SFC-Verarbeitung durchführen. Bei einer Implementierung speichern nur die ToR-Switches SF-Erreichbarkeitstabellen und andere Zustandsinformationen zum Implementieren von SFC. Das heißt, die Server 308, 310 und 312 brauchen keine Erreichbarkeitstabellen oder andere Zustandsinformationen zur Unterstützung von SFC speichern.
Ein technischer Vorteil ist demgemäß, dass es weniger Berührungspunkte für das Vorhalten und die SC-Definition und -Verwaltung gibt. Die Architektur stellt ein besseres Modell für die Durchsetzung von Dienstgütevereinbarung (Service Level Agreement; SLA) bereit, mit einem verbesserten Betriebs- und Verwaltungs(Operations and Management; CAM)-Modell für Ende-zu-Ende-Sichtbarkeit. Außerdem stellt die Architektur höhere Leistung bereit, was effektivere und effizientere Nutzung von Vorrichtungsknoten erlaubt. Die Architektur ist auch für die Verwendung jeder Größe, von klein bis zu sehr groß, geeignet.
4 zeigt zwei beispielhafte Implementierungen einer Netzwerkvorrichtung, einen Top-of-Rack Switch 400. Jede der Komponenten des in 4 gezeigten Switches 400 kann logisch, physikalisch oder als Kombination von logischen und physikalischen Elementen implementiert werden. Der Switch 400A zeigt eine Mehrgerät-Implementierung, während der Switch 400B eine Eingerät-Implementierung zeigt. Der Switch 400 weist einen Service Chain Prozessor (SCP) 402 und einen Underlay Switch 404 auf. Der Underlay Switch 404 kann viele verschiedene Funktionen implementieren. Um zwei Beispiele zu nennen, kann der Underlay Switch 404 einen Rechenzentrumstunnelendpunkt (XTEP) 406 implementieren und kann einen virtuellen Switch (VS) 408 aufweisen. Als spezifisches Beispiel können Trident Series Ethernet Switch ASICs den Underlay Switch 404 implementieren. Als anderes Beispiel kann eine Caladan 3 Netzwerkverarbeitungseinheit (network processing unit; NPU) den SCP 402 implementieren. Wenn der SCP 402 und der Underlay-Switch 404 in einer einzigen Vorrichtung integriert sind, können Qumran und Jericho Switch ASICs den kombinierten Funktionalitätssatz implementieren. Diese NPUs und ASICs sowie andere Implementierungsoptionen unterscheiden sich durch Skalierungs- und Leistungsfähigkeit und sind von Broadcom in Irvine, CA, erhältlich.
Wie oben angemerkt, können die in 4 gezeigten Funktionsblöcke als separate Geräte implementiert werden oder können in verschiedenen Kombinationen in einem oder mehreren Geräten vorliegen. Bei einigen Implementierungen sind zum Beispiel der SCP 402 und der Underlay Switch 404 in einem einzigen Gerät integriert, während sie bei anderen Implementierungen in separaten Geräten implementiert sind. Wenn sie integriert sind, können die Funktionsblöcke, um nur ein Beispiel zu nennen, verteilt werden, um eine flexible Paketverarbeitungspipeline zu bilden. Eine integrierte Implementierung kann zum Beispiel in Qumran oder Jericho Schaltgeräten vorgenommen werden. Anders ausgedrückt kann der SCP 402 einer Switch-Architektur in Form einer separaten NPU hinzugefügt werden (wie zum Beispiel durch die Implementierung 400A in 4 gezeigt ist), oder der SCP 402, der Underlay Switch 404 und beliebige andere Funktionsblöcke können in einem einzigen Gerät integriert werden, zum Beispiel als Teil einer Verarbeitungspipeline (wie zum Beispiel durch die Implementierung 400B in 4 gezeigt ist).
Bei diesem Beispiel implementiert der SCP 402 in dem Switch 400 einen SCC 410. Der SCC 410 kann ankommende Paketflüsse auf beliebiger Grundlage auf eine bestimmte SC abbilden, z. B. durch eine beliebige Kombination aus Kunde, Quellenanwendung, Zielanwendung, QoS, Zeit/Datum oder einen anderen Parameter. Bei einigen Implementierungen führt der SCC 410 die Klassifizierung durch Abbilden von {Application ID, Subscriber ID/Class} (Anwendungskennung, Teilnehmerkennung/Klasse) von empfangenen Paketen auf {Service Chain ID, Service Function Index} (Dienstkettenkennung, Dienstfunktionsindex) durch. Das Abbilden kann durch Durchsuchen der Dienstketten-Abbildungstabelle (service chain mapping table; SCMT) 448 erfolgen, die eine Klassifizierungsabbildung von Paketklassifizierung auf die Netzwerkdienstketten-Definitionen in dem Speicher 440 speichert.
Der SCC 410 kann auch jedem Paket in dem Paketfluss gemäß der Abbildung einen Klassifizierungs-Header hinzufügen, der zum Beispiel {Service Chain ID, Service Function Index} (Dienstkettenkennung, Dienstfunktionsindex) enthält. Die Dienstkettenkennung (service chain ID; SCID) identifiziert eine bestimmte SC-Definition in dem Speicher 440, und der Dienstfunktionsindex (service function index; SFI) zeigt auf die nächste SF, die für die empfangenen Pakete auszuführen ist. Die Anfangspakete, die in einem Paketfluss empfangen werden, können mit einem SFI gekennzeichnet werden, der auf die erste SF zeigt, die in der SC auszuführen ist, auf die der SCC 410 den Paketfluss abgebildet hat. Der Speicher 440 kann eine beliebige Anzahl von SC-Definitionen speichern. In 4 sind drei der Definitionen bezeichnet als SC-Definition 1 442, SC-Definition 444 und SC-Definition 'n' 446, jeweils mit eindeutigen SCIDs.
Bei dem Beispiel von 4 implementiert der SCP 402 auch den SFF 412. Der SFF 412 kann Pakete von einer SF zur nächsten in einer gegebenen SC weiterleiten, wie unten genauer beschrieben wird. Bei einer Implementierung bildet der SFF 412 {Service Chain ID, Service Function index} (Dienstkettenkennung, Dienstfunktionsindex), die im Paketklassifizierungs-Header vorliegen, auf {VS network address, SF network address} (VS Netzwerkadresse, SF Netzwerkadresse) ab. Der SFF dekrementiert auch den SFI und aktualisiert den SFC-Header auf den Paketen, der den SFI speichert, um den Verlauf der Pakete durch die SFs in der abgebildeten SC zu verfolgen und zu speichern.
Der SCP 402 kann des Weiteren einen Diensttunnel-Endpunkt (service tunnel end point; STEP) 414 implementieren. Der STEP 414 kann Dienst-Overlay-Netze für SF-Verbindungsfähigkeit unterstützen. Der STEP 414 kann auch Dienst-Overlay-Tunnelheader auf den Paketen, die einer SC unterliegen, hinzufügen, löschen und aktualisieren. Die Dienst-Overlay-Tunnelheader verbinden zum Beispiel einen ersten SCP mit einem anderen SCP oder mit einem VS.
Der SCP 402 kann auch einen Rechenzentrumstunnelendpunkt (data center tunnel end point; XTEP) 416 implementieren. Der XTEP 416 unterstützt ein Rechenzentrums-Overlay-Netz für VS-Verbindungsfähigkeit. Insbesondere kann der XTEP 416 Dienst-Overlay-Tunnelheader auf den Paketen, die einer SC unterliegen, hinzufügen, löschen und aktualisieren. Der Dienst-Overlay-Tunnelheader kann einen SCP mit einer SF in einem Host verbinden, der zum Beispiel direkt mit dem TOR Switch verbunden ist, der aktuell die Pakete verarbeitet.
Es wird angemerkt, dass der Underlay Switch 404 unter Verwendung der äußeren Header der Pakete Schicht 2- und Schicht 3-Weiterleitung implementieren kann. Die Pakete können von einer beliebigen Kombination aus SCP 402 und Paketschnittstellen 418 und 420 stammen. Die Schnittstelle 418 kann eine Uplink Schnittstelle sein, zum Beispiel zu anderen ToR Switches in demselben Rechenzentrum oder anderswo. Die Schnittstelle 420 kann eine Serverknotenschnittstelle sein, zum Beispiel zu Servern in demselben Rack wie der Switch 400. Jede Kombination aus physikalischen und logischen Schnittstellen 422 verbindet den SCP 402 und den Underlay Switch 404.
Einige der technischen Vorteile der Architektur 100 umfassen, dass die Serverknoten den Aufwand des Speicherns eines SFC-Weiterleitungszustands nicht auf sich nehmen müssen. Außerdem können die ToR Switches, die die Netzwerk-Architektur bilden (was ToR Switches in verschiedenen Server Racks einschließen kann), unter Verwendung von Rechenzentrums-Overlay-Tunneln wie zum Beispiel Virtual Extensible Local Area Network (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), Generic Network Virtualization Encapsulation (Geneve), Shortest Path Breaching (SPB) entweder vollständig oder teilweise miteinander verbunden sein. Der Tunnelendpunkt kann in jedem ToR ein SCP sein. Des Weiteren ist bei einigen Implementierungen das Vorsehen eines Tunnels statisch. Das heißt, das Vorsehen eines Tunnels kann einmal konfiguriert werden und dann selektiv modifiziert werden, zum Beispiel wenn sich die physikalische Topologie ändert.
Weitere technische Vorteile umfassen, dass jedes ToR in einem Rack mit jedem Serverknoten in diesem Rack logisch verbunden werden kann, indem zumindest ein Rechenzentrums-Overlay-Tunnel verwendet wird, zum Beispiel VXLAN-, NVGRE-, Geneve-, SPB-Tunnel. Der Tunnelendpunkt in dem ToR ist ein SCP, und der Endpunkt in dem Server kann ein virtueller Switch (VS) sein. Wenn es mehrere VSs pro Server gibt, dann kann jeder VS mit einem separaten Rechenzentrums-Overlay-Tunnel mit dem SCP in dem ToR verbunden sein. Wiederum kann das Vorsehen eines Tunnels statisch sein, indem das Vorsehen eines Tunnels einmal konfiguriert werden und dann selektiv modifiziert werden kann, zum Beispiel, wenn sich die physikalische Topologie ändert.
Zusätzliche technische Vorteile umfassen, dass jedes ToR in einem Rack mit jeder VM, die ein Behälter für eine SF in diesem Rack ist, unter Verwendung eines Dienst-Overlay-Tunnels logisch verbunden werden kann. Der Diensttunnel-Endpunkt in dem ToR ist der SCP, und in dem Serverknoten ist es die VM. Die Diensttunnel-Endpunkt-Verarbeitung kann für jede VM in dem Serverknoten in dem virtuellen Switch, in dem VM-Gastbetriebssystem (operating system; OS) oder in der Netzwerkfunktion selbst implementiert werden.
5 zeigt eine beispielhafte Overlay-Tunnel-Topologie 500 für netzwerkbasiertes SFC. Jeder ToR SCP 502, 504 und 506 kann einen Erreichbarkeits- oder Weiterleitungszustand für SFs speichern, die direkt damit verbunden sind, z. B. in dem lokalen Rack 508, 510, 512. Wenn sich die nächste SF in der Dienstkette in einem anderen Rack befindet, leitet der Quellen-ToR-SCP das Paket an den Ziel-ToR-SCP für dieses andere Rack weiter, zum Beispiel durch Senden der Pakete an diesen Ziel-ToR-SCP in dem anderen Rack. Der Ziel-ToR-SCP leitet dann das Paket an die Ziel-SF weiter, zum Beispiel durch Senden der Pakete an einen VS, der mit VMs in Verbindung steht, welche in einem Host laufen, der mit diesem Ziel-ToR verbunden ist. Der Underlay Core Switch (UCS) 514 repräsentiert in jedem ToR Switch die Underlay Switches und kann die ToR SCPs 502, 504 und 506 durch jede Art von physikalischer oder logischer Netzwerktopologie verbinden.
6 zeigt die Weiterleitung 600 in einer beispielhaften SC 650 in einem Rack von Servern 652, 654 und 656, die durch einen Netzwerk Switch 658 verbunden sind und bedient werden. 6 zeigt den Beginn 602 der Dienstkette 650 und den Dienst-Overlay-Tunnelanfangspunkt. 6 zeigt auch das Ende 604 der Dienstkette 650 und den Dienst-Overlay-Tunnelendpunkt. Die Dienstkette 650 beginnt und endet in demselben Server Rack, wobei die VFs auf den Servern 652, 653 und 656 vorgehalten werden, die mit dem Netzwerk Switch 658 verbunden sind. [051] Es wird angemerkt, dass bei diesem Beispiel weder die SFs noch die VSs irgendwelche SFC Weiterleitungszustandsinformationen speichern. Die VSs senden Pakete, die zu der SC zugehörig sind, wie durch beliebige Identifizierungsinformationen bestimmt, ob in dem Paket oder gemäß VLAN-, Tunnel- oder anderen Netzwerkkennungen, die zu dem Paket zugehörig sind, an den lokalen Netzwerk Switch 658 zurück. Bei einer Implementierung senden die VSs die Pakete durch Swappen der Quelle (source; SRC) und des Ziels (destination; DST) sowohl im Rechenzentrum als auch in den Dienst-Overlay-Tunnelheadern auf den Paketen zurück. Der Swap wird durchgeführt, um die Pakete zur weiteren Verarbeitung an das ToR zurückzusenden, weil in dem VS kein Zustand gespeichert ist. In dieser Hinsicht können die VSs vorab mit Flusstabellen versehen werden, die die Adressen (z. B. die ToR Switch-Adressen) spezifizieren, für welche der VS das Swappen durchführen wird.
6 zeigt auch ein beispielhaftes Paket 660. Das Paket weist Nutzdaten 662 und SFC Header auf. Die SFC Header können zum Beispiel einen Rechenzentrums-Overlay-Tunnelheader 664 aufweisen, der die Pakete an einen bestimmten VS leitet, der mit der VM in Verbindung steht, welche die nächste SF hostet. Die SFC Header können auch einen Dienst-Overlay-Tunnelheader 666 aufweisen, der die Netzwerkadresse der SF spezifiziert, die mit dem VS verbunden ist. Der SFF 412 kann die SFC Header erzeugen, hinzufügen, aktualisieren und entfernen, während Pakete zunächst an dem ToR Switch ankommen, Pakete der Reihe nach an bestimmte SFs gesendet werden und nach der Verarbeitung von der SF zurück erhalten werden, und während Pakete ihre Verarbeitung durch die SC beenden.
7 zeigt ein Beispiel von netzwerkbasierten SFC 700, mit einer SC, die sich durch mehrere Netzwerkvorrichtungen 702, 704 und 706 und über die Racks 708, 710 und 712 hinweg erstreckt. 7 zeigt den Dienstkettenbeginn 714 in der Netzwerkvorrichtung 702. Der Dienstkettenbeginn 714 kann der Dienst-Overlay-Tunnelanfangspunkt sein, zum Beispiel, wo die Netzwerkvorrichtung 702 die Rechenzentrums- und Dienst-Overlay-Tunnel-Header in die Pakete einfügt. 7 zeigt auch das Dienstkettenende 716. Das Dienstkettenende 716 kann der Dienst-Overlay-Tunnelendpunkt sein, zum Beispiel, wo die Netzwerkvorrichtung 706 die Rechenzentrums- und Dienst-Overlay-Tunnel-Header aus den Paketen entfernt.
Wenn Pakete, die einer SC unterliegen, zwischen zwei Netzwerkvorrichtungen weitergeleitet werden, zum Beispiel von der Netzwerkvorrichtung 702 an die Netzwerkvorrichtung 704, dann muss die sendende Netzwerkvorrichtung 702 die Dienst-Overlay-Tunnelkennung in dem Paket nicht ändern. Stattdessen kann die empfangende Netzwerkvorrichtung den Dienst-Overlay-Tunnelheader aktualisieren, bevor sie das Paket an ihre lokale SF sendet.
Es wird angemerkt, dass auch bei diesem Beispiel die SFs und VSs keine SFC Weiterleitungszustandsinformationen speichern. Die VSs senden Pakete, die zu der SC zugehörig sind, wie durch beliebige Identifizierungsinformationen bestimmt, ob in dem Paket oder gemäß VLAN-, Tunnel- oder anderen Netzwerkkennungen, die zu dem Paket zugehörig sind, an ihre lokale Netzwerkvorrichtung zurück. Die VSs können Pakete zum Beispiel durch Swappen von SRC und DST sowohl in den Rechenzentrums- als auch in den Dienst-Overlay-Tunnelheadern zurücksenden.
7 zeigt ToR-Switch-an-ToR-Switch-Verkehr zum Handhaben von SCs, die über ToR Switches hinweg verteilt sind. Die SCP Funktion aktualisiert in jedem ToR Switch die Rechenzentrums- und Dienst-Overlay-Tunnelheader, um die Pakete entlang der SC zu dem nächsten Hop zu leiten. Die SCP Funktion muss in jedem ToR Switch nur den Teil der SC verarbeiten, der die VSs, VMs und SF enthält, die direkt mit diesem ToR Switch verbunden sind. Die SCP Funktion kann in jedem ToR Switch ein Nachschlagen hinsichtlich des Dienstketten-Headers durchführen (der zum Beispiel den Dienstfunktionsindex und die Dienstkettenkennung aufweisen kann), um zu ermitteln, ob dieser ToR Switch für irgendeinen Teil der SC verantwortlich ist. Das heißt, jeder ToR Switch kann ein Dienstfunktions-Weiterleitungsnachschlagen durchführen, zum Beispiel hinsichtlich {SCID, SFI}, und im Ansprechen darauf sowohl die Rechenzentrums- als auch die Dienst-Overlay-Tunnelheader aktualisieren. Der Dienst-Overlay-Tunnelheader auf Paketen, die zwischen ToR Switches wandern, können einfach Platzhalterdaten sein, und werden durch den nächsten ToR Switch, der den nächsten Teil der SC behandelt, durch Netzwerkadressdaten für die SF ausgetauscht.
8 zeigt eine beispielhafte Dienstfunktionskette (service function chain; SC) 800. Eine SC kann als vordefinierte Sequenz von SFs implementiert werden. Die Sequenz von SFs kann einen vorbestimmten Datenebenendienst für Paketflüsse durch die Netzwerkvorrichtung(en) liefern, die die SC implementiert/implementieren. Wie oben erwähnt, können einzelne Netzwerkvorrichtungen SCs definieren, speichern und verwalten. Jede SC kann eine SCID als eindeutige ID innerhalb des Netzwerks haben, die die SC als bestimmte Kette von SFs kennzeichnet. Die Netzwerkvorrichtungen können einen Dienstfunktionsindex (service function index; SFI) als Index für eine SF in der spezifizierten SC speichern.
Ein SCC bildet Paketflüsse auf eine SCID ab, indem er die Pakete mit Headerinformationen kennzeichnet, zum Beispiel durch Abbilden von {Application ID, Subscriber ID/Class} (Anwendungskennung, Teilnehmerkennung/Klasse) von empfangenen Paketen auf {Service Chain ID, Service Function Index} (Dienstkettenkennung, Dienstfunktionsindex). Der SCC kann überall in dem Netzwerk implementiert werden. Beim Eintritt führt der SCC eine Identifizierung und Klassifizierung von Verkehr während des Abbildens auf eine bestimmte SC (oder auf keine SC) durch. Der SCC kann die Analyse auf Makroebene durchführen, zum Beispiel basierend auf jeglichem Verkehr von einem anderen Netzwerk gemäß der IP-Adresse des Netzwerks, basierend auf einem Segment des Netzwerks (z. B. Port oder Teilnetzwerk), basierend auf Nutzer oder Eigentümer des Verkehrs, oder basierend auf der Anwendung, die die Pakete erzeugt (um nur einige Beispiele zu nennen, einer Voice-over-IP Anwendung, einer Dateiübertragungsanwendung, einer Virtual Private Network(VPN)-Anwendung, einer Anwendung, die verschlüsselten Inhalt erzeugt, oder einer Video- oder Audio-Streaming-Anwendung). Beim Durchführen des Abbildens kann der SCC Deep Packet Inspection (DPI) durchführen, um eine spezifische SC zu ermitteln, durch welche die Pakete verarbeitet werden sollten.
Der SFF leitet Pakete von einer SF zu einer nächsten innerhalb einer SC weiter. Der SFF kann Pakete durch Abbilden von {SCID, SF1} auf eine physikalische Netzwerkadresse, z. B. {VS network address, SF network address} (VS Netzwerkadresse, SF Netzwerkadresse) weiterleiten. Die SF an der physikalischen Netzwerkadresse führt die nächste Dienstfunktion durch, die in der SC spezifiziert ist. Bei Beendigung der SC entfernt eine Dienstkettenbeendigungs(service chain termination; SCT)-Funktion die Dienstkettenkennungen/-header von den Paketen, und die Pakete kehren zu Nicht-SC-Routing durch die Netzwerk Switches zurück.
Bei dem Beispiel von 8 hat der SCC bestimmt, dass ein ankommender Paketfluss 802 der SC 800 unterliegen sollte. Der Paketfluss 802 verläuft durch die SC, die vier SFs der Reihe nach definiert: SF1, eine Deep Packet Inspection; SF2, eine Firewall, SF3, eine Netzwerkadressen-Übersetzung; und SF4, einen Wide Area Network Optimierer. Vor jeder SF bestimmt der SFF die nächste SF für das Paket, indem er den SF1 speichert (z. B. durch Inkrementieren oder Dekrementieren des SF1), um zu verfolgen, welche SF in der SC die Pakete als nächstes verarbeiten sollte.
9 zeigt ein weiteres Beispiel des Weiterleitens 900 durch eine SC 902, die sich durch ToR Switches über Racks 904, 906 und 908 hinweg erstreckt. Die SC 902 weist vier SFs der Reihe nach auf: SF1, SF2, SF3, dann SF4. Vor dem Eintreten in die SC identifiziert ein Teilnehmer-Klassifizierer (subscriber classifier; SUBC) (Funktionsknoten A) Paketflüsse, die zu einem Teilnehmer zugehörig sind, und bildet die Flüsse auf eine bestimmte Flusskennung ab. Der SCC (Funktionsknoten B) bildet die Flusskennung (und optional zusätzliche Eigenschaften wie zum Beispiel die Paketquelle) auf eine SC ab und kennzeichnet die Pakete mit einem SFC-Klassifizierungsheader, der die SCID enthält.
Anders ausgedrückt kann, wenn Pakete ankommen, ein Gateway Knoten (z. B. ein Gateway Router GWR) die Pakete überprüfen und klassifizieren. Bei einigen Implementierungen gibt es zwei Arten von Klassifizierung: Anwendungsklassifizierung und Flussursprungsklassifizierung. Für die Anwendungsklassifizierung prüft der Netzwerkknoten, der die Klassifizierung durchführt, die Pakete und ermittelt ihren Inhalt, z. B. Video, HTTP-Daten oder Dateiübertragungsdaten, und erzeugt eine entsprechende Anwendungskennung. Für Flussursprungsklassifizierung kann der Netzwerkknoten, der die Klassifizierung durchführt, eine Quelle der Pakete identifizieren. Als Beispiel kann die Quellen-IP-Adresse die Quelle identifizieren. Die Kombination aus Anwendung und Quellendaten kann als Nachschlagen verwendet werden, um eine Richtlinie zu finden, die in dem Netzwerkknoten, der Klassifizierung durchführt, vorgehalten ist. Die Richtlinie kann Anwendungs- und Quellen-IDs (oder andere Verkehrseigenschaften) auf eine SCID abbilden. Der Netzwerkknoten kann Dienstheader-Verkapselung implementieren, die die SCID und den SFI zum Beispiel in einem Klassifizierungsheader bereitstellt, der dem Paket hinzugefügt wird. Der SFF in dem ToR Switch antwortet auf den Klassifizierungsheader, um die Pakete durch die SC an SFs zu routen, indem er SCID und SFI auf physikalische Netzwerkadressen abbildet.
Bei dem Beispiel von 9 werden die ersten beiden SFs in Hosts in dem Server Rack 908 vorgehalten. Demgemäß führt der ToR Switch 910 die SFF-Funktion dreimal aus, wie in 9 gezeigt ist, um die Pakete durch zwei SFs zu routen, und dann auf das nächste Rack 906, wo die nächste SF in der SC vorgehalten wird. In dem ToR Switch 912 führt der ToR Switch 912 zweimal SFF-Funktionen aus, einmal, um die Pakete an SF 3 zu richten, und einmal, um die Pakete an den ToR Switch 914 zu richten, wo die letzte SF, SF4, in dem Server Rack 904 gehostet wird. Der ToR Switch 914 führt SFF-Funktionalität aus, um die Pakete an SF4 zu richten, und um die Pakete wieder an das Netzwerk zurück zu richten, wo die SCT die für SFC verwendeten Paketheader entfernt, und sendet die Pakete zum allgemeinen Routen an das Netzwerk zurück. Es wird angemerkt, dass in 9 die Gateway Router (GWR) einen Teil der SC-Verarbeitung durchführen, einschließlich SUBC, SCC und einen Fall von SFF, und SCT.
10 erweitert das Beispiel von 9 und zeigt ein weiteres Beispiel des Weiterleitens 1000 durch eine SC 1002, die sich durch TOR Switches 1010, 1012 und 1014 über Racks 1004, 1006 und 1008 hinweg erstreckt. Es wird angemerkt, dass in 10 Vorrichtungen (zum Beispiel physikalische Endpunkte (PEs)) in dem Teilnehmerzugangsnetzwerk die SUBC-Funktion durchführen. Bei diesem Beispiel können die PEs die resultierenden Teilnehmerkennungen in MPLS-Labeln an die folgende SCC-Funktion in dem GWR kommunizieren. Der SCC bildet die Teilnehmerkennung auf eine SC ab, und die Pakete werden durch die SC wie oben unter Bezug auf 9 angegeben verarbeitet.
11 zeigt ein weiteres Beispiel des Weiterleitens 1100 in einer Dienstfunktionskette 1102 in einem Rack 1104. Bei diesem Beispiel führt der ToR Switch 1106 die Funktionen von SUBC, SCC, SFF und SCT durch. Während der TOR Switch 1106 Pakete an die nächste SF in der SC weiterleitet, verfolgt er den SFI um zu bestimmen, wohin als nächstes Pakete weiterzuleiten sind, die von den Hosts, die die SFs ausführen, an den TOR Switch 1106 zurückkehren. Während der Index durch die SC, zum Ende der SC, zieht, erkennt der ToR Switch 1106, dass die Pakete die SC durchlaufen haben, und führt die SCT-Funktion aus, um die Dienst- und Rechenzentrums-Overlay-Tunnelheader zu entfernen, die für die Pakete verwendet wurden, um netzwerkbasiertes SFC zu unterstützen.
Bei den oben beschriebenen netzwerkbasierten SFC-Architekturen wird der Weiterleitungszustand für SFC, und insbesondere die Funktion, die die logische Adresse einer SF auf eine physikalische Netzwerkadresse abbildet, in der Netzwerkvorrichtung, zum Beispiel dem TOR Switch, selbst gespeichert. Der Weiterleitungszustand und die Abbildungsfunktion müssen nicht in den VSs bereitgestellt oder gespeichert werden. Ein vorteilhaftes Ergebnis ist, dass der Dienstketten-Controller nur die Abbildungstabelle in der Netzwerkvorrichtung verwalten muss, und nicht in allen der Endpunkte. Bei normalen Szenarien, bei denen es viele Server je ToR Switch (zum Beispiel 48 zu 1) in einem Rack gibt, liegt eine signifikante Verringerung an Verwaltungsaufwand vor.
Der VS wirkt beim netzwerkbasierten SFC so mit, dass er Pakete empfängt und sie an die SF weiterleitet, die in einer VM vorgehalten wird. Der VS sendet die Pakete nach der Verarbeitung durch die SF an die ursprüngliche Netzwerkvorrichtung, zum Beispiel den ursprünglichen ToR Switch, zurück. Der VS braucht keine Informationen über die SF des nächsten Hops in der SC zu speichern, sondern sendet stattdessen die Paketen nach der Verarbeitung zur Bestimmung des nächsten Hops an die Netzwerkvorrichtung zurück.
Als anderes Beispiel für den Anwendungsfall wird angenommen, dass eine SC drei SFs in Folge aufweist. DPI, gefolgt von einer Firewall, gefolgt von einem virtuellen Router. Der ToR Switch hat der SC als Teil des Vorhaltens der SC eine SCID zugeteilt. Eine bestimmte Dienstfunktion wird unter Verwendung von Tupel-Logikadressierung adressiert, was bei einer Implementierung die SCID und der SFI ist. Das heißt, jede SF hat einen Index innerhalb der SC. Beim vorliegenden Beispiel kann der Index mit dem Indexwert 3 für die DPI SF starten, dann Indexwert 2 für die Firewall SF, dann Indexwert 1 für die Router SF.
Der SCP 402, und insbesondere der SFF 412, der durch den SCP 402 implementiert wird, bildet die logischen Adressen, zum Beispiel {SCID 50, SFI 3}, auf eine physikalische Netzwerkadresse ab. Bei einer Implementierung weist die physikalische Netzwerkadresse zwei Komponenten auf: einen Overlay Endpunkt, welcher die Adresse des VS ist, der die SF anhängt, und die Adresse der SF innerhalb des VS. Nachdem die Pakete angekommen sind, führt der SFF 412 das Nachschlagen durch, um die SCID und den SFI auf die nächste SF abzubilden. Der SFF 412 erzeugt und addiert (oder aktualisiert) den Rechenzentrums-Overlay-Tunnelheader für die Pakete, wodurch die Pakete an den bestimmten VS geleitet werden, der mit der VM in Verbindung steht, die die nächste SF hostet. Der SFF 412 erzeugt und addiert (oder aktualisiert) auch den Dienst-Overlay-Tunnelheader auf den Paketen, der die Adresse der SF, die mit dem VS verbunden ist, spezifiziert. Das heißt, als Ergebnis des Nachschlagens durch den SFF 412 kann der SFF 412 den Dienst-Tunnelheader und den Rechenzentrums-Overlay-Tunnel erzeugen, addieren, modifizieren oder löschen.
Das SFC verfolgt den Verlauf der Pakete durch ihre abgebildeten SCs, zum Beispiel durch Dekrementieren des SFI für die Pakete. Zum Beispiel kann nach Rückkehr von der DIP SF das SFC den SFI von 3 auf 2 dekrementieren und den Header eines Pakets, der die SCID und den SFI trägt, aktualisieren. Das nächste Nachschlagen erfolgt bei diesem Beispiel hinsichtlich {SCID 50, SFI 2), um die Netzwerkadresse der folgenden SF (der Firewall SF) zu finden, die die nächste SF zum Verarbeiten der Pakete in der SC ist. Das SFC fährt auf diese Weise fort, bis die SFI null wird. Zu diesem Zeitpunkt erkennt das SFC, dass das Paket das Ende der SC erreicht hat, entfernt die SFC Header, und leitet das Paket auf die Art und Weise weiter, wie es normalerweise ohne SFC Verarbeitung stattfinden würde.
Die oben beschriebene SFC Verarbeitung kann auf viele verschiedene Arten durch viele verschiedene Arten von Schaltung, von hoch spezialisierten Paketprozessoren bis zu zentralen Recheneinheiten für den allgemeinen Gebrauch, implementiert werden. Bei einer Implementierung wird die SFC Verarbeitung durch die Datenebene des Netzwerk Switches implementiert. Die Datenebene kann spezialisierte Netzwerk-Prozessoren aufweisen, die mit einer Multigigabit Switch Fabric verbunden sind.
Unter nochmaligem Bezug auf 5 wird die netzwerkbasierte SFC-Verarbeitung durch eine Overlay Topologie unterstützt. Die Overlay Topologie implementiert Pakettunnelverbindungen, die die SCPs in jeder Netzwerkvorrichtung (zum Beispiel ToR Switch) und jeden VS in einem Server Rack miteinander verbinden. Die SCPs 412 können die Tunnelendpunkte sein. Die Overlay Topologie implementiert eine Speichen-Verbindungsarchitektur. In der Topologie wird jede Netzwerkvorrichtung mit Overlay Tunneln, zum Beispiel Tunneln von jedem ToR Switch zu jedem anderen ToR Switch, über einen definierten Ort, zum Beispiel ein bestimmtes Rechenzentrum, hinweg verbunden.
Demgemäß hat jede Netzwerkvorrichtung eine Rechenzentrums-Tunnelverbindung zu jedem unmittelbar verbundenen Host (und VS) für eine SF. Ein Diensttunnel ist in dem Rechenzentrumstunnel definiert, um die SCPs mit den einzelnen SFs und den VMs zu verbinden, die die SFs hosten. Die Rechenzentrumstunnel unterstützen Kommunikation zwischen ToR Switches, von denen jeder Paketrouting für jeden Teil einer SC handhaben kann, die eine beliebige Anzahl von ToR Switches und Server Racks kreuzen kann, zum Beispiel entlang des Rückgrats eines Rechenzentrums, das mehrere Server Racks in einem Rechenzentrum verbindet.
Der Rechenzentrums-Overlay-Tunnel und der Dienst-Overlay-Tunnel bilden eine Zweischicht-Weiterleitungsarchitektur, die eine beliebige Netzwerkvorrichtung, zum Beispiel einen beliebigen Netzwerk Switch, mit einer beliebigen SF verbindet, gleich ob physikalisch oder virtuell. Bei einer Implementierung adressiert die äußere Schicht einen bestimmten VS, und die innere Schicht adressiert eine bestimmte SF, die von einem Knoten gehostet wird, der mit dem VS in Verbindung steht. Das Adressieren ist nicht auf IP- oder MAC-Adressen begrenzt, sondern es kann jede Art von Adressieren verwendet werden. Die Overlay Topologie stellt logische und physikalische Verbindungen von jedem ToR Switch in einem Server Rack zu jedem VS, jeder VM und jeder SF bereit.
12 zeigt Logik 1200, die ein Netzwerkknoten implementieren kann, um netzwerkbasiertes SFC auszuführen. Die Logik 1200 empfängt Pakete, die Teil eines Netzwerkflusses sind (1202). Jeder logische oder physikalische Netzwerkknoten (zum Beispiel der SCC 410 in dem SCP 402) kann die Pakete zum Beispiel gemäß Anwendung/Inhalt und Quelle/Teilnehmer klassifizieren (1204). Die Logik 1200 umfasst das Definieren von SCs im Speicher (1206). Die SCs können Sequenzen von SFs spezifizieren, zum Beispiel durch Verwenden von Indexwerten, die verschiedene Dienstfunktionen in einer bestimmten Reihenfolge anordnen. Den Klassifizierungsinformationen kann eine Funktion zugeteilt werden, zum Beispiel der SFF 412, der ermittelt, welche SC gegebenenfalls für die Klassifizierung zutrifft (1208). Die Funktion kann die Pakete mit der zutreffenden {SCID, SFI} in einem Paketheader kennzeichnen (1210).
Der SFF 412 überprüft die SF's, um festzustellen, ob mehr SFs zum Verarbeiten der Pakete in der SC vorhanden sind (1212). Wenn dies nicht der Fall ist, dann entfernt der SFF 412 die Rechenzentrums- und Dienst-Overlay-Tunnelheader von den Paketen (1214). Die Pakete werden dann normal von der Netzwerkvorrichtung verarbeitet. Wenn es zusätzliche SFs zum Verarbeiten des Pakets gibt, dann aktualisiert der SFF 412 den SFI (1216) und bestimmt Netzwerkadressen (zum Beispiel basierend auf {SCID, SFI}), um die nächste SF zu erreichen. Der SFF 412 erzeugt oder modifiziert nach Bedarf die Rechenzentrums- und Dienst-Overlay-Tunnelheader auf den Paketen, um die Pakete an die nächste SF zu leiten (1218).
Der SFF 412 kann dann die Pakete an die nächste SF leiten (1220). Der SFF 412 kann zum Beispiel die Pakete durch den Underlay Switch, durch die Overlay Topologie an einen VS und eine VM senden, die mit der nächsten SF in Verbindung stehen.
Der VS sendet die Pakete, die von der SF verarbeitet wurden, an den SFF 412 zurück, zum Beispiel durch Swappen von SRC- und DST-Informationen in den Rechenzentrums- und Dienst-Overlay-Tunnelheadern. Der SFF 412 empfängt die von der SF und dem VS zurückgesendeten verarbeiteten Pakete (1222) und überprüft, ob etwaige folgende SFs die Pakete verarbeiten sollten (1212).
Die oben beschriebenen Verfahren, Vorrichtungen, Verarbeitungen und Logik können auf viele verschiedene Arten und in vielen verschiedenen Kombinationen von Hardware und Software implementiert werden. Zum Beispiel können alle oder ein Teil der Implementierungen Schaltung sein, die einen Befehlsprozessor aufweist, zum Beispiel eine zentrale Rechnereinheit (Central Processing Unit; CPU), einen Mikrocontroller oder einen Mikroprozessor, eine Application Specific Integrated Circuit (ASIC), ein Programmable Logic Device (PLD), oder ein Field Programmable Gate Array (FPGA); oder Schaltung, die diskrete Logik oder andere Schaltungskomponenten aufweist, einschließlich analoger Schaltungskomponenten, digitaler Schaltungskomponenten oder beides; oder jede Kombination daraus. Die Schaltung kann diskrete miteinander verbundene Hardwarekomponenten aufweisen und/oder kann auf einem einzigen integrierten Schaltungschip kombiniert sein, auf viele integrierte Schaltungschips verteilt sein, oder in einem Multiple Chip Module (MCM) mehrerer integrierter Schaltungschips in einem gemeinsamen Gehäuse implementiert werden, um Beispiele zu nennen.
Die Schaltung kann des Weiteren Befehle zur Ausführung durch die Schaltung aufweisen oder darauf zugreifen. Die Befehle können in einem konkreten Speichermedium gespeichert sein, das sich von einem transitorischen Signal unterscheidet, zum Beispiel einem Flash Speicher, einem Random Access Memory (RAM), einem Read Only Memory (ROM), einem Erasable Programmable Read Only Memory (EPROM); oder auf einer Magnetplatte oder optischen Platte, zum Beispiel einem Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), oder einer anderen Magnetplatte oder optischen Platte; oder in oder auf einem anderen maschinenlesbaren Medium. Ein Erzeugnis, wie zum Beispiel ein Computerprogrammerzeugnis, kann ein Speichermedium und Befehle aufweisen, die in oder auf dem Medium gespeichert sind, und die Befehle können, wenn sie von der Schaltung in einer Vorrichtung ausgeführt werden, veranlassen, dass die Vorrichtung jedes der oben beschriebenen oder in den Zeichnungen dargestellten Verfahren implementiert.
Die Implementierungen können als Schaltung unter mehreren Systemkomponenten verteilt werden, zum Beispiel unter mehreren Prozessoren und Speichern, optional einschließlich mehrerer verteilter Verarbeitungssysteme. Parameter, Datenbanken und andere Datenstrukturen können separat gespeichert und verwaltet werden, können in einem einzigen Speicher oder einer einzigen Datenbank enthalten sein, können auf viele verschiedene Arten logisch und physikalisch organisiert sein, und können auf viele verschiedene Arten implementiert werden, einschließlich als Datenstrukturen wie zum Beispiel verlinkte Listen, Hash-Tabellen, Arrays, Aufzeichnungen, Objekte oder implizite Speichermechanismen. Programme können Teile (zum Beispiel Teilroutinen) eines einzelnen Programms, separater Programme, verteilt über mehrere Speicher und Prozessoren sein, oder auf viele verschiedene Arten implementiert werden, zum Beispiel in einer Bibliothek, zum Beispiel einer gemeinsamen Bibliothek (zum Beispiel einer Dynamic Link Library (DLL)). Die DLL kann zum Beispiel Befehle speichern, die jede der oben beschriebenen oder in den Zeichnungen dargestellten Verarbeitungen durchführen, wenn sie von der Schaltung ausgeführt werden.
Verschiedene Implementierungen sind in besonderer Weise beschrieben worden. Viele andere Implementierungen sind jedoch ebenso möglich.

Claims

Netzwerk-Switch mit: einer Netzwerkfluss-Schnittstelle zu dem Netzwerk-Switch, wobei die Netzwerkfluss-Schnittstelle dazu konfiguriert ist, einen Netzwerkfluss zu empfangen, der ein Paket aufweist; einem Speicher, der dazu konfiguriert ist, eine Netzwerkdienstketten-Definition zu speichern, wobei die Netzwerkdienstketten-Definition ein Dienstfunktions-Spezifikationssymbol einer Dienstfunktion aufweist, die auf einer Server-Ressource getrennt von dem Netzwerk-Switch vorgehalten wird; und Dienstketten-Verarbeitungsschaltung, die mit der Netzwerkfluss-Schnittstelle und dem Speicher in Verbindung steht, wobei die Dienstketten-Verarbeitungsschaltung konfiguriert ist zum: Bestimmen, dass die Netzwerkdienstketten-Definition für den Netzwerkfluss zutrifft; Bestimmen, dass das Paket als nächstes von der Dienstfunktion verarbeitet werden sollte; Aktualisieren eines Dienstfunktionsindexes, um den Verlauf des Pakets durch die Netzwerkdienstketten-Definition zu verfolgen; Kennzeichnen des Pakets mit einer Netzwerkadresse für die Dienstfunktion; und Weiterleiten des Pakets aus dem Netzwerk-Switch zu der Dienstfunktion auf der Server-Ressource.
Netzwerk-Switch nach Anspruch 1, wobei die Dienstketten-Verarbeitungsschaltung des Weiteren konfiguriert ist zum: Erhalten einer Flussklassifizierung für das Paket; und Abbilden der Flussklassifizierung auf die Netzwerkdienstketten-Definition, um zu bestimmen, dass die Netzwerkdienstketten-Definition für den Netzwerkfluss zutrifft.
Netzwerk-Switch nach Anspruch 2, wobei: die Flussklassifizierung eine Anwendungskennung, eine Teilnehmerkennung oder beides aufweist.
Netzwerk-Switch nach Anspruch 1, wobei: die Netzwerkdienstketten-Definition eine sequenzielle Reihenfolge zur Ausführung der Dienstfunktion in der Netzwerkdienstketten-Definition spezifiziert; und die Dienstketten-Verarbeitungsschaltung des Weiteren konfiguriert ist zum: Lesen eines Paket-Headers des Pakets, um einen aktuellen Indexwert zu bestimmen; und Anpassen des aktuellen Indexwerts an die Netzwerkdienstketten-Definition, um zu bestimmen, dass das Paket als nächstes von der Dienstfunktion verarbeitet werden sollte.
Netzwerk-Switch nach Anspruch 4, wobei: die Dienstketten-Verarbeitungsschaltung des Weiteren dazu konfiguriert ist, einen Dienstfunktionsindex zu aktualisieren, um die Weiterleitung des Pakets an die Dienstfunktion zur Verarbeitung zu bedingen.
Netzwerk-Switch nach Anspruch 5, wobei: die Dienstketten-Verarbeitungsschaltung des Weiteren dazu konfiguriert ist, von der Server-Ressource das Paket nach der Verarbeitung durch die Servicefunktion zu empfangen; und ein Folgeziel in der Netzwerkdienstketten-Definition basierend auf dem Dienstfunktionsindex zu bestimmen.
Netzwerk-Switch nach Anspruch 6, wobei: die Dienstketten-Verarbeitungsschaltung des Weiteren konfiguriert ist zum: nochmaligen Aktualisieren des Dienstfunktionsindexes für das Paket, um den Verlauf des Pakets durch die Netzwerkdienstketten-Definition zu verfolgen; und Weiterleiten des Pakets aus dem Netzwerk-Switch an das Folgeziel.
Netzwerk-Switch nach Anspruch 7, wobei: das Folgeziel eine andere Dienstfunktion ist, die auf einer anderen Server-Ressource vorgehalten wird.
Verfahren, das umfasst: in einem Netzwerk-Switch, der Hostserver miteinander verbindet, auf denen eine erste Dienstfunktion und eine zweite Dienstfunktion vorgehalten werden: Definieren, in einem Speicher, einer Netzwerkdienstketten-Definition, die eine Abfolge von Dienstfunktionen spezifiziert, mit: der ersten Dienstfunktion; und der zweiten Dienstfunktion; wobei die Netzwerkdienstketten-Definition aufweist: einen ersten Dienstfunktionsindex für die erste Dienstfunktion; und einen zweiten Dienstfunktionsindex für die zweite Dienstfunktion; wobei der erste und der zweite Dienstfunktionsindex die erste Dienstfunktion vor der zweiten Dienstfunktion anordnen; Empfangen eines Pakets, das Teil eines Netzwerkflusses ist; Empfangen von Klassifizierungsinformationen für das Paket; basierend auf den Klassifizierungsinformationen Bestimmen, dass die Netzwerkdienstkette für den Netzwerkfluss zutrifft; Bestimmen, dass die erste Dienstfunktion als nächstes das Paket verarbeiten sollte; und Weiterleiten des Pakets an die erste Dienstfunktion.
Netzwerk-Switch, der aufweist: eine Paketschnittstelle, die dazu konfiguriert ist, Pakete in den Netzwerk-Switch zu empfangen und Pakete aus dem Netzwerk-Switch zu kommunizieren; einen Speicher, der konfiguriert ist zum Speichern von: Netzwerkdienstketten-Definitionen, die aufweisen: eine erste Netzwerkdienstketten-Definition, die eine erste Abfolge von Dienstfunktionen spezifiziert, die eine erste Paketverarbeitungskette darstellen; und eine erste Dienstkettenkennung für die erste Netzwerkdienstketten-Definition; und eine Dienstketten-Abbildungstabelle, die aufweist: eine Klassifizierungsabbildung von der Paketklassifizierung auf die Netzwerkdienstketten-Definitionen in dem Speicher; einen Dienstketten-Prozessor, der mit der Paketschnittstelle in Verbindung ist, wobei der Dienstketten-Prozessor konfiguriert ist zum: Erhalten von Klassifizierungsinformationen für die Pakete; Bestimmen, aus den Klassifizierungsinformationen und der Dienstketten-Abbildungstabelle, dass die erste Netzwerkdienstkette die Pakete verarbeiten sollte; Bestimmen einer nächsten Dienstfunktion, die auf den Paketen ausgeführt werden soll, aus der ersten Abfolge von Dienstfunktionen; Verfolgen des Verlaufs der Pakete durch die erste Netzwerkdienstkette durch Aktualisieren eines Dienstfunktions-Headers der Pakete; Hinzufügen eines Routing-Headers zu den Paketen, wobei der Routing-Header aufweist: eine virtuelle Switch-Adresse eines virtuellen Switches, der mit einem Hostserver für die nächste Dienstfunktion in Verbindung ist; und eine Dienstfunktions-Netzwerkadresse für die nächste Dienstfunktion auf dem Hostserver; und Weiterleiten der Pakete aus dem Netzwerk-Switch an die nächste Dienstfunktion auf dem Hostserver.