SFC. Service Function Chaining SFC. Autor: Prof. Dr.-Ing. Anatol Badach

Transkript

1 Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN SFC Service Function Chaining Mit der Virtualisierung von Rechnern und deren Verfügbarkeit in Form von Virtual Machines (VMs) auf speziellen leistungsfähigen, oft als Wirt-Server bezeichneten, Rechnerplattformen eröffnen sich vollkommen neue Möglichkeiten, unterschiedliche an Geschäftsprozesse angepasste Netzwerkdienste als sog. Clouds spontan bereitzustellen. Denn auf der Basis von VMs können zur Einrichtung verschiedener komplexer Netzwerkdienste diverse Funktionskomponenten, die nicht unbedingt hardwaremäßig realisiert werden müssen, wie z.b. Deep Packet Inspection (DPI), Customer Premises Equipment (CPE), Intrusion Prevention System (IPS), Load Balancer und Firewall, bereitgestellt werden. Diese Funktionskomponenten können somit als virtuelle, standardisierte Netzwerkfunktionsmodule im Voraus für einen Einsatz vorbereitet und dann bei Bedarf als Softwarekomponenten ad hoc verfügbar gemacht werden. Diese Idee hat bereits zur Network Functions Virtualisation (NFV) 1 geführt. Man spricht hierbei von virtualisierten Netzwerkfunktionen. Sie werden kurz als Virtualised Network Functions (VNFs) bzw. auch wie in diesem Beitrag als Service Functions (SFs) bezeichnet. Um einen durch das Zusammenwirken mehrerer SFs erbrachten Netzwerkdienst verwirklichen zu können, müssen die daran beteiligten SFs untereinander kooperieren. Hierfür müssen sie entsprechend vernetzt werden. Als Folge ist zur Gewährleistung dessen ein Konzept für das Zusammenwirken der den gewünschten Netzwerkdienst erbringenden SFs zu erarbeiten. Für jeden Netzwerkdienst muss also ein Konzept zur Vernetzung und Kooperation von an diesem Service beteiligten SFs entwickelt und in einer übersichtlichen, präzisen Form spezifiziert werden. Daher werden Ideen bzw. Lösungen benötigt, die ermöglichen, dass die durch Kooperation mehrerer SFs erbrachten Netzwerkdienste sowohl konzipiert als auch einheitlich und präzise spezifiziert werden können. 1 Es wird auch Network Functions Virtualization geschrieben. 1

2 Da die Realisierung jedes Netzwerkdienstes auf der Basis von durch virtualisierte Rechner (VMs) erbrachten SFs in der Regel zu einer Verkettung von SFs führt, spricht man in diesem Zusammenhang von Service Function Chaining (SFC). Im Allgemeinen werden darunter zahlreiche Konzepte und Lösungen zur Kooperation von hauptsächlich softwaremäßig realisierten SFs zur Erbringung diverser Netzwerkdienste verstanden. Die beiden Konzepte NFV und SFC sind keine Big Hypes, sondern gelten als neue, sich gegenseitig ergänzende Entwicklungstrends auf dem Gebiet Networking. Die Idee von NFV wurde im Oktober 2012 auf dem SDN & OpenFlow World Congress in Darmstadt zum ersten Mal offiziell vorgestellt. Damit einhergehende Entwicklungen rund um NFV werden von der ISG NFV (Industry Specification Group for NFV) am European Telecommunications Standards Institute (ETSI) koordiniert und als Standards spezifiziert 2. Die Entwicklungen zum Thema SFC koordiniert die gleichnamige, im September 2013 gegründete, Working Group bei der Internet Engineering Task Force (IETF). 3 Das Software Defined Networking (SDN) ist als dritter wichtiger Entwicklungstrend eng mit NFV und SFC verbunden denn: NFV, SFC und SDN ergänzen sich ideal. Es sei hervorgehoben, dass der Controller bei SDN der Funktion nach vollkommen sowohl dem Controller bei SFC als auch dem Orchestrator bei NFV entspricht. Dieser Aspekt wird in diesem Beitrag noch vertieft werden. Folglich bilden NFV, SFC und SDN zusammen quasi ein antreibendes Dreiergespann, das in den kommenden Jahren mit Sicherheit die Fahrtrichtung der Entwicklung auf dem Gebiet Networking bestimmen wird. Vor allem die Konvergenz von NFV, SFC und SDN wird es uns bald ermöglichen, diverse, durch Vernetzungen von standardisierten Softwareinstanzen erbrachte Netzwerkdienste nach Bedarf zu kreieren. Und dann könnte man tatsächlich von Software Defined Network Services (SDNSs) sprechen, also von software-definierten Netzwerkdiensten bzw. auch von flexiblen und programmierbaren Netzwerkdiensten

3 Der Vorteil des Einsatzes von auf NFV und SFC beruhenden Lösungen besteht hauptsächlich darin, dass teure Hardwarekomponenten, die in herkömmlichen Netzwerken zur Realisierung verschiedener Services benötigt werden, weitgehend durch die auf der Basis von VMs erbrachten Netzwerkservices ersetzt werden können; diese werden standardisiert, folglich weltweit einheitlich aufgebaut. Dadurch lassen sich diverse Netzwerkdienste schnell einrichten, ihre Wartung und Pflege vereinfacht sich und im Endeffekt reduzieren sich nicht nur die Investitionskosten (Capital Expenditure, CAPEX) und Betriebskosten (Operational Expenditure, OPEX), sondern es kommt auch zur Verbesserung der Flexibilität und Agilität von Netzwerken. Das primäre Ziel dieses Beitrags ist es, das Konzept von SFC und dessen Einsatz in fundierter Form zu präsentieren. Die SFC betreffenden Konzepte sind im Moment (März 2015) allerdings noch als zahlreiche Drafts bei der IETF in der Entwurfsphase. Die hier dargestellten Konzepte und Beispiele können daher als denkbare realisierbare Visionen für Systemlösungen angesehen werden. Die Idee von SFC Unter SFC werden im Allgemeinen Prinzipien verstanden, nach denen die Vernetzung von in der Regel durch virtuelle Rechner erbrachten SFs in Form von seriellen (linearen) SF-Ketten (Service Function Chains) realisiert werden kann, um verschiedene Services insbesondere diverse Network und Security Services zu erbringen. Die grundlegende Idee von SFC illustriert Bild anhand eines stark vereinfachten Beispiels. Wie hier ersichtlich ist, kann ein verteiltes System für schrittweise durchführbare Untersuchungen (Analysen) mehrerer gleichzeitig verlaufender Ströme von IP 4 -Paketen auf der Basis kettenartiger (serieller) Vernetzungen von Service Functions (SFs), in Form von SF Paths (SFPs) also, eingerichtet werden. Die in diesem System schrittweise realisierten Untersuchungen der IP-Pakete werden mit dem Ziel durchgeführt, verschiedene Network und Security Services zu erbringen. Die Funktionalität solch eines verteilten Systems wird 4 Internet Protocol 3

4 durch die drei Funktionskomponenten Classifier (Klassifizierer), SF Paths (SF-Pfade) und SFC Controller erbracht. Bild : Die grundlegende Idee von SFC anhand eines vereinfachten Beispiels IP: SF: SFP: Internet Protocol Service Function (z.b. Firewall, Load Balancer, ) Service Function Path (SF Path) Die soeben angeführten drei Funktionskomponenten der auf dem SFC-Konzept basierenden verteilten Systeme lassen sich wie folgt kurz charakterisieren: Classifier Diese Funktionskomponente klassifiziert nach vorgegebenen Kriterien (Policies) alle ankommenden IP-Pakete so, dass Ströme von diesen, als quasi deren Klassen, gebildet werden. Diese Ströme werden dann auf die vom Classifier ausgehenden SF Paths (SFPs) verteilt. Infolgedessen können im weiteren Verlauf die einzelnen Ströme von IP-Paketen über einzelne SFPs nach vorher festgelegten Vorgaben analysiert und dann dem Untersuchungsergebnis entsprechend behandelt und bearbeitet bzw. modifiziert werden. SF Paths (SFPs) Die vom Klassifizierer kommenden Ströme von IP-Paketen können auf verschiedenen SFPs durch mehrere SFs, de facto in aufeinanderfolgenden Schritten, weiter analysiert, überprüft und anschließend weitergeleitet werden. Die SFPs werden 4

5 hauptsächlich mit dem Ziel eingerichtet, verschiedene Ströme von IP-Paketen bezüglich bestimmter Merkmale schrittweise so zu analysieren bzw. im Hinblick auf ihre Sicherheit zu überprüfen, dass die auf den von einzelnen SFPs zu erwartenden Services erbracht werden können. Es sei dabei hervorgehoben, dass SFPs normalerweise kettenartige, mehrere SFs enthaltende Vernetzungen darstellen; im Sonderfall kann ein SFP aber auch nur eine SF enthalten. SFC Controller Der Classifier und alle SFs müssen zuerst konfiguriert und später eventuell auch noch gesteuert werden. Diese Aufgaben werden vom sog. SFC Controller übernommen. Dieser kann auch als verteiltes System implementiert werden. Ist dies der Fall, so bildet der Controller de facto eine Control Plane. Dementsprechend könnte man dann die restlichen Systemkomponenten also den Classifier und die SFPs als Function Plane betrachten. Solch ein verteiltes System zur Erbringung diverser Network und Security Services, wie es gerade beschrieben wurde, kann in Sonderfällen nur aus einer einzigen Kette von SFs, also nur aus einem SFP, bestehen. Ist dies der Fall, erübrigt sich die Funktion eines Classifier, der normalerweise aus den ankommenden IP-Paketen mehrere Ströme von IP-Paketen bildet und diese auf mehrere SFPs verteilt. Auch vorstellbar sind Sonderfälle, in denen die SFs auf einem ganzen Path auf Dauer fest konfiguriert werden und dann ist auch der Controller überflüssig. Ein System zur Untersuchung eines Stroms von IP-Paketen kann also nur aus einem SFP bestehen folglich nur eine SF-Kette bilden. Das weiter in Bild gezeigte Beispiel eines Security Gateway stellt solch einen Fall dar. Es sei hervorgehoben, dass SFs in der Regel durch als VMs bezeichnete virtuelle Rechner erbracht werden. SFs können aber auch diverse herkömmliche Hardware-Funktionskomponenten repräsentieren. Alle diese, die Bereitstellung von SFs betreffenden Aspekte wurden in Bild außer Acht gelassen. Weil das Konzept von SFC hauptsächlich auf den Vernetzungen von durch virtuelle Rechner erbrachten SFs basiert, stellen die Virtualisierung von Rechnern und die Bildung von Virtual Overlay 5

6 Networks für die Vernetzung von SFs die zwei wichtigsten Säulen von SFC dar. Auf diese wird im Weiteren kurz eingegangen. Funktionelle Komponenten und Architektur von SFC Nachdem in Bild die grundlegende Idee von SFC nur anhand der Service Plane dargestellt wurde, zeigt Bild die ganze Architektur von SFC in einer stark vereinfachten Form. Bild : Vereinfachte Architektur von SFC in Anlehnung an draft-ietf-sfc-architecture-04 SF: SFF: SFP: Service Function Service Function Forwarder (zur Anbindung von SFs an die Transport Plane) Service Function Path (SF Path) Die Architektur von SFC enthält vier funktionelle, als Planes bezeichnete Schichten und diese sind: Service Function Plane Diese besteht aus SFC-fähigen, als SFC-aware bezeichneten und in der Regel durch virtuelle Rechner (Virtuelle Machines, VMs) erbrachten SFs. Die klassischen Funktionskomponenten, SFCunaware SFs also, können mithilfe von sog. SFC-Proxies in das SFC-System integriert werden. Wie aus Bild hervorgeht, müssen einige Daten und Steuerungsangaben zwischen 6

7 benachbarten SFs auf einem SFP übermittelt werden die benachbarten, auf demselben SFP liegenden SFs müssen also untereinander kommunizieren können. Konkret soll jede SF in der Lage sein, Angaben zu jeder von ihr durchgeführten Analyse eines IP-Paketes in Form von Metadaten (Metadata) der ihr auf dem SFP folgenden SF zu übergeben. Um dies zu ermöglichen, wurde in die Architektur von SFC eine SF Forwarding Plane eingeführt. SF Forwarding Plane Diese Plane bilden die Service Function Forwarders (SFFs). Sie stellen Funktionskomponenten dar, die benötigt werden, um Metadaten und Steuerungsangaben von einer SF zur auf einem SFP nächstfolgenden SF übermitteln zu können, sodass man eine Kette von SFs zwecks der Erbringung eines Service ausführen kann. Hierfür wurde der Network Service Header (NSH) vorgesehen. In ihm werden die Metadaten und Steuerungsangaben eingetragen und zwischen jeweils benachbarten SFFs übermittelt. So können die Metadaten von einer SF an die nächstfolgende SF übergeben werden (Bild ). Transport Plane Diese Plane stellt eine bestehende virtuelle und/oder physische Netzwerkinfrastruktur dar, über die SFFs miteinander vernetzt werden können. Control Plane Sie repräsentiert einen bzw. mehrere Controller, deren Aufgabe darin besteht, die beiden Planes (Service Function Plane und SF Forwarding Plane) nicht nur zu überwachen und zu steuern, sondern auch neue SFC-basierte Services zu kreieren und einzurichten. Für den Aufbau der Control Plane beim SFC lassen sich Bestandteile des oben erwähnten SDN-Konzeptes übernehmen (Bild ). Anmerkung: An dieser Stelle sei angemerkt, dass ein SFF sowohl auf einer VM mit SFs als auch außerhalb von VMs, de facto auf einer Virtualisierungsplattform (z.b. auf einem Wirt-Server) mit mehreren VMs, realisiert werden kann. Wird der SFF auf einer VM mit SFs implementiert, können mehrere, aber nur von der VM erbrachte SFs über den SFF innerhalb der Transport Plane an das IP-Netzwerk angebunden werden. Wird aber ein SFF außerhalb von VMs auf einer Virtualisierungsplattform implementiert, dann können mehrere, sogar von verschiedenen VMs der betreffenden 7

8 Virtualisierungsplattform erbrachte SFs mithilfe von SFFs an das IP- Netzwerk angebunden werden (Bild ). Grundlegende Aufgabe von SF Forwarding Wie bereits erwähnt wurde, enthält die SF Forwarding Plane Funktionskomponenten, die benötigt werden, um sowohl SFs, de facto virtuelle Komponenten, an das Netzwerk anzubinden, als auch Metadaten und Steuerungsangaben von einer SF zu der auf einem SFP nächstfolgenden SF übermitteln zu können. Bild zeigt, um welche Steuerungsangaben es sich handelt und veranschaulicht dabei auch ihre Bedeutung. Es sei angemerkt, dass diese Steuerungsangaben innerhalb der Transport Plane im zwischen SFFs transportierten Network Service Header (NSH) übermittelt werden. Bild : Aufgabe der SF Forwarding Plane virtuelle Vernetzung von SFs MD: NSH: SF: SFF: SFP-ID: SI: Metadata Network Service Header Service Function Service Function Forwarder Service Function Path Identification Service Index Damit man eine Kette von durch virtuelle Rechner erbrachten und beliebig verteilten SFs ausführen kann, müssen im NSH zwischen SFFs folgende Angaben übermittelt werden: Service Function Path Identification (SFP-ID) Jeder SFP muss eindeutig identifiziert werden; hierfür dient SFP-ID. Diese Angabe muss den zwischen SFs zu übermitteln- 8

9 den Daten vorangestellt werden (vgl. Bilder und ). Service Index (SI) Innerhalb eines SFP muss jede SF eindeutig gekennzeichnet, quasi nummeriert werden. Hierfür dient die Angabe SI. Sie muss nur innerhalb eines SFP, für jeden SFP-ID also, eindeutig sein. Bild illustriert ihre Bedeutung. Enthält beispielsweise ein SFP insgesamt n SFs, werden die Werte von SI den einzelnen SFs auf demselben SFP wie folgt zugeordnet: SI = n der 1-ten, SI = n-1 der 2-ten,... und SI = 0 der letzten SF. Anmerkung: Eine solche abnehmende Nummerierung von SFs mit SI auf dem SFP soll dazu dienen, dass die SF mit der Nummer 0 immer als die letzte SF auf dem SFP angesehen werden kann. Metadaten Von einer SF zur auf dem SFP nächstliegenden SF müssen oft bestimmte, von der Art und Weise der SF-Ausführung abhängige Daten quasi als Ergebnis der SF-Ausführung übergeben werden. Diese Metadaten werden im NSH zwischen SFFs transportiert. Virtualisierung von Rechnern, die erste Säule von SFC Bevor auf weitere technische Details von SFC eingegangen wird, soll auf die Virtualisierung von Rechnern eingegangen werden, die die erste fundamentale Säule von SFC bildet. Hierfür zeigt Bild anhand eines einfachen Beispiels den Weg von einer kleinen Vernetzung physischer Rechner mithilfe nur eines physischen Layer-2-Switch (L2-Switch) bis hin zur Bereitstellung von auf der Basis virtueller Rechner in einem Wirt-Server eingerichteten SFs. Anmerkung: Eine wichtige Funktion bei der Virtualisierung von Rechnern in einem Wirt-Server übernimmt der sog. Hypervisor. Er repräsentiert eine Softwareinstanz, die es den auf einem Wirt-Server implementierten VMs erlaubt, dessen Hardware und Speicher gemeinsam zu nutzen. Aus der Sicht von Networking realisiert der Hypervisor im Wesentlichen die Funktionen eines L2-Switch. Aus diesem Grund kann der Hypervisor allerdings lediglich aus Sicht von Networking auch als virtueller L2-Switch (kurz vswitch), wie in Bild b gezeigt, angesehen werden. 9

10 Bild : Auf einen L2-Switch beschränkte Vernetzung: a) physischer Rechner, b) in einem Wirt-Server mittels VMs erbrachter SFs L2: Layer 2 SF: Service Function VLAN: Virtual Local Area Network (Virtual LAN) VM: Virtual Machine Im Allgemeinen kann ein L2-Switch in einem Wirt-Server mit mehreren VMs realisiert werden: als virtueller L2-Switch (vswitch) in Form einer Softwarekomponente (Bild b) oder aber auch als embedded vswitch auf einem physischen Network Interface Controller (NIC), z.b. auf einer 10GE-Adapterkarte. 5 Dazu sei angemerkt, dass ein L2-Switch seiner Funktion nach als ein Ethernet Switch angesehen werden kann. Ebenso wie die physischen Rechner am physischen L2-Switch können auch die in einem Wirt-Server eingerichteten virtuellen Rechner (VMs) so gruppiert werden, dass sie eine isolierte Gruppe bilden. Solch eine Gruppe wird als Virtual Local Area Network (VLAN) bezeichnet. Ein VLAN auf der Basis eines physischen bzw. virtuellen L2-Switch entsteht in der Regel durch die Gruppierung von dessen Ports. Die zu einem VLAN gehörenden Rechner werden normalerweise als IP-Subnetz eingerichtet und bilden dann eine 5 Für fundierte Informationen über die Betriebsarten virtueller L2-Switches in Wirt-Servern sei auf Edge Virtual Bridging (EVB) in [3] verwiesen. 10

11 MAC Broadcast Domain (auch L2 Broadcast Domain), 6 d.h. eine Domain, wie man sie in herkömmlichen Ethernet-basierten Netzwerken vorfindet. Die zu einem VLAN gehörenden SFs können auch so vernetzt werden, dass sie einen vollständigen SF Path (SFP) bilden oder, wie in Bild , einen Teil eines langen SFP darstellen, der sich über mehrere virtuelle L2-Switches (vswitches) innerhalb verschiedener als Virtualisierungsplattformen dienender Wirt-Server erstreckt. SF Forwarding innerhalb einer Virtualisierungsplattform Nachdem bereits das Grundkonzept von SFC sowie die Bildung eines aus virtuellen Rechnern bestehenden und auf einen physischen Wirt-Server beschränkten VLAN dargestellt wurden, soll Bild veranschaulichen, wie ein IPv4-Paket zwischen den zu einem VLAN (hier zum VLAN A) gehörenden und SFs erbringenden VMs übermittelt werden kann. Hier soll insbesondere angemerkt werden, dass alle die SF Forwarding Plane bildenden Funktionsmodule (SFFs) an die Ports des vswitch, welcher der Transport Plane zuzuordnen ist, angebunden werden, dass der im SFF erzeugte NSH innerhalb der SF Forwarding Plane dem zu übermittelnden IPv4-Paket vorangestellt wird und dass ein SFF mehrere und sogar verschiedenen SFPs angehörende SFs an die Transport Plane anbinden sowie diese SFs auch gemäß den im NSH übermittelten Angaben SFCmäßig unterstützen kann. Das obige Beispiel illustriert die Übermittlung eines IPv4-Pakets von der VM mit SF n,1 an die VM mit SF n+1,1 innerhalb des VLAN A, in dem der SFP mit SFP-ID = 1 realisiert wird. Hierbei verweist der im SFF n dem zu übermittelnden IPv4-Paket vorangestellte NSH 6 Eine MAC Broadcast Domain repräsentiert eine isolierte Gruppe von Rechnern, in der jeder Rechner die Möglichkeit hat, an alle anderen zur Gruppe gehörenden Rechner einen MAC-Frame (d.h. einen Ethernet Frame) mit der Broadcast-MAC-Adresse zu schicken. 11

12 mit Next Protocol = 0x1 darauf, dass nach ihm ein IPv4- Paket kommt, mit SFP-ID = 1 darauf, dass dieses IPv4-Paket innerhalb des SFP mit ID = 1 transportiert wird und mit Service Index = i-1 darauf, dass dieses IPv4-Paket an die SF n+1,1 mit SI = i-1 übergeben werden muss. Bild : Aufgabe der SF Forwarding Plane beim Transport von Daten zwischen SFs in einem Wirt-Server MAC: SF: SFF: SFP-ID: SI: VLAN: VM: Media Access Control Service Function Service Function Forwarder Service Function Path Identification Service Index Virtual LAN Virtual Machine Anmerkung: Es sei an dieser Stelle darauf verwiesen, dass sowohl virtuelle als auch physische Rechner über eine MAC- und eine IP-Adresse verfügen 12

13 müssen. Dies ist im Weiteren zum allgemeinen Verständnis der Prinzipien der Kommunikation zwischen virtuellen Rechnern, also zwischen VMs, von großer Bedeutung. Da im hier betrachteten Beispiel das von einer VM zu einer anderen VM mit SFs übermittelte IPv4-Paket nur intern in einem Wirt-Server vom vswitch geleitet wird, enthalten die beiden MAC- und IPv4- Header als Quell- und Zieladressen entsprechend die MAC- und IPv4-Adressen dieser beiden VMs. Virtual Overlay Networks, die zweite Säule von SFC Wie schon in Bild dargestellt wurde, bildet ein aus virtuellen, SFs erbringenden Rechnern bestehendes VLAN ein virtuelles Overlay-Netzwerk (Virtual Overlay Network, VON) oberhalb einer Transport Plane, welche aus virtuellen Switches in Virtualisierungsplattformen (Wirt-Servern) und einer physischen IP- Netzwerkinfrastruktur besteht. Ein VON, das als zweite SFC-Säule die Voraussetzung für die Vernetzung von SFs schafft, kann sich über mehrere vswitches erstrecken und diese müssen häufig über ein IP-Netzwerk miteinander verbunden werden. Daher sind spezielle, auf dem sog. Tunneling-Prinzip basierende Systemlösungen notwendig, um die auf verschiedenen Wirt-Servern installierten, zu einem VON gehörenden SFs in Form von SF-Ketten (SFCs) zu vernetzen. Wie eine solche Vernetzung von SFs realisiert werden kann, wird nun gezeigt. Die bisher betrachteten, in Bild a dargestellten VLANs waren auf einen physischen L2-Switch beschränkt. VLANs mit physischen Rechnern können sich aber, wie Bild a zeigt, gleichwohl über mehrere physische L2-Switches erstrecken, d.h. sie können auch L2-Switch-übergreifend angelegt sein. Es sei an dieser Stelle angemerkt, dass es sich in Bild a um eine Lösung auf der Basis von nur zwei physischen L2-Switches eingerichteten VLANs handelt. Oberhalb einer Gruppe physischer L2-Switches können dann quasi parallel mehrere VLANs eingerichtet werden, wobei jedes dieser VLANs eine eindeutige Identifikation besitzen muss. Bild b soll zum Ausdruck bringen, dass ein virtuelles, mit einem VLAN vergleichbares Netzwerk auch von einer Gruppe von virtuellen Rechnern (VMs) dargestellt werden kann. Ein derartiges, 13

14 oberhalb mehrerer beliebig verteilter vswitches eingerichtetes und von einer Gruppe von VMs gebildetes virtuelles Netzwerk wird hier, wie bereits erwähnt, VON genannt. Um ein solches VON aufbauen zu können (Bild b), müssen vswitches oft paarweise mit virtuellen Uplinks in Form von speziellen virtuellen Tunneln verbunden werden. Die Adressierung der Endpunkte eines solchen Tunnels ist allerdings vom Tunneling-Konzept abhängig, d.h. davon, wie der Tunnel konkret realisiert wurde. Auf wichtige Tunneling- Konzepte, die den Aufbau von VONs ermöglichen, wird im Folgenden kurz eingegangen. Bild : L2-Switch-übergreifende Vernetzung a) von physischen Rechnern, b) von in mehreren Wirt-Servern mittels VMs erbrachten SFs GENEVE: IP: NVGRE: TP: UDP: VON: Generic Network Virtualization Encapsulation Internet Protocol Network Virtualization using Generic Routing Encapsulation Tunneling Protocol User Datagram Protocol Virtual Overlay Network 14

15 VXLAN: VXLAN GPE: Virtual Extensible Local Area Network Generic Protocol Extension for VXLAN Ein VON mit einer Gruppe von VMs kann auch als IP-Subnetz eingerichtet werden. Ist dies der Fall, dann bildet das VON eine MAC Broadcast Domain und folglich können die zum VON gehörenden VMs mit SFs direkt untereinander kommunizieren. Das passiert eventuell über einen Tunnel, ohne einen Router nutzen zu müssen. Demzufolge können dann auch die von VMs erbrachten SFs auf die gleiche Art und Weise untereinander direkt kommunizieren. VONs mit VMs bilden somit eine wesentliche Säule für die Realisierung von SFC. SF Forwarding zwischen Virtualisierungsplattformen Die Aufgabe von SF Forwarding beim Transport von Daten zwischen SFs in einem Wirt-Server, der als Virtualisierungsplattform dient, wurde bereits in Bild dargestellt. Auf eine ähnliche Art und Weise soll nun die Aufgabe von SF Forwarding im Falle, dass beide benachbarten SFs sich auf verschiedenen Virtualisierungsplattformen befinden, präsentiert werden; Bild zeigt eine solche Situation. Hier wird gezeigt, wie ein MAC-Frame zwischen den zu einem als VXLAN eingerichteten VON (hier mit VNI = 100) gehörenden, auf verschiedenen Virtualisierungsplattformen X und Y realisierten virtuellen Rechnern (VMs) mit SFs übermittelt wird. Dabei soll insbesondere zum Ausdruck gebracht werden, dass die Funktionsmodule SFFs ebenso wie in Bild an die Ports von zur Transport Plane gehörenden vswitches angebunden werden, dass eine zusätzliche Encapsulation-/Decapsulation-Instanz am Uplinkport vom vswitch nötig ist, damit man, wie in Bild b gezeigt, den Uplink zwischen vswitches in Form eines virtuellen Tunnels einrichten kann, dass die zwischen den auf verschiedenen Virtualisierungsplattformen eingerichteten VMs zu übermittelnden MAC- Frames als Inner MAC-Frames in die nur zwischen Virtualisierungsplattformen übermittelten Outer MAC-Frames eingekapselt werden; es wird hier also die sog. MAC-in-MAC- Encapsulation realisiert, 15

16 dass ein Network Service Header (NSH) innerhalb der SF Forwarding Plane vom SFF jedem zu übermittelnden Inner MAC-Frame vorangestellt wird; darauf, dass dem NSH ein MAC-Frame folgt, wird im NSH mit Next Protocol = 0x3 verwiesen, dass dem NSH ein Header nach dem Tunneling Protocol (TP) hier TP = VXLAN GPE vorangestellt wird. Darauf wird im TP- Header mit Next Protocol = 0x4 verwiesen. Bild : Aufgabe der SF Forwarding Plane beim Transport von Daten zwischen den in verschiedenen Virtualisierungsplattformen erbrachten SFs Enc/Dec: ID: MAC: Encapsulation/Decapsulation Identifier/Identification Media Access Control 16

17 SFF: SFP-ID: SI: TH: TP: VNI: VON: Service Function Forwarder Service Function Path Identification Service Index Tunneling Header (z.b. nach dem Konzept VXLAN GPE) Tunneling Protocol VXLAN Network Identifier Virtual Overlay Network Anmerkung: Die Outer MAC-Frames werden nur zwischen Virtualisierungsplattformen mit vswitches übermittelt. Demzufolge enthalten ihre MAC- Header die MAC-Adressen von Virtualisierungsplattformen und ihre IP- Adressen werden dann in den in Outer-Headern übermittelten IP-Headern angegeben. Die Inner MAC-Frames, das heißt die, die in den Outer MAC- Frames übermittelt werden, werden an die in Wirt-Servern eingerichteten vswitches übergeben. De facto werden die Inner MAC-Frames zwischen vswitches in Outer MAC-Frames eingebettet übermittelt. Somit sind die MAC-Adressen virtueller Rechner (VMs) in MAC-Headern und deren IP- Adressen in IP-Headern innerhalb von Inner MAC-Frames enthalten. Das in Bild gezeigte Beispiel illustriert die Übermittlung eines MAC-Frame von der VM mit SF n,1 an die VM mit SF n+1,1 innerhalb des VXLAN mit VNI = 100, in dem der SFP mit SFP-ID = 1 realisiert wird. Hierbei verweist der im SFF n dem zu übermittelnden IPv4-Paket vorangestellte NSH mit Next Protocol = 0x3 darauf, dass ihm ein MAC-Frame folgt, mit SFP-ID = 1 darauf, dass dieser MAC-Frame innerhalb des SFP mit ID = 1 transportiert wird und mit Service Index = i-1 darauf, dass dieser MAC-Frame an die VM mit SF n+1,1, d.h. mit SI = i-1, übergeben werden muss. Für die Fortsetzung siehe: Dreibändiges Loseblattwerk (Print und CD-Version) mit Update-Dienst: "Protokolle und Dienste der Informationstechnologie" Aktualisierungszyklus: 2 Monate, WEKA Media, Kissing ISBN-13: , Bestell-Nr. OL9142J 17