S ► SDN

SDN Software Defined Networking Autor: Prof. Dr.-Ing. Anatol Badach

Auszug aus dem Werk:

Herausgeber: Heinz Schulte WEKA-Verlag ISBN 978-3-82769142-2

Die Virtualisierung von Rechnern und der zunehmende Bedarf an flexiblen, spontanen und an Geschäftsprozesse angepassten ITDiensten verlangen neue Ideen zur flexiblen und raschen Bereitstellung von Netzwerkdiensten. Das Software Defined Networking (SDN) stellt eine solche Idee dar. Sie ermöglicht die Bereitstellung universeller und programmierbarer Netzwerkknoten zur Weiterleitung von Daten. Diese Netzwerkknoten können fast alle denkbaren Netzwerkfunktionen erbringen, wie z.B. verschiedene SwitchingArten und Routing und dies sogar parallel für die beiden Internetprotokolle IPv4 und IPv6. Dadurch können beim SDN verschiedene programmierbare Netzwerkdienste (Programmable Network Services) realisiert werden. Folglich kann man beim SDN sogar von Netzwerkprogrammierbarkeit (Network Programmability) sprechen, von der Netzwerkentwickler bereits seit langem geträumt haben. Es sei hervorgehoben, dass man SDN auch als Abkürzung für „Software Driven Networking“ verwendet. Darunter werden de facto die gleichen Ideen wie bei „Software Defined Networking“ verfolgt; aus diesem Grund sind diese beiden Begriffe als Synonyme anzusehen und SDN steht folglich für „Software Defined/Driven Networking“. Das SDN stellt eine revolutionäre Idee dar, der eine neue Netzwerkarchitektur zugrunde liegt. Diese Idee besteht darin, dass die Steuerung von den für den Datentransport verantwortlichen Funktionsmodulen in Netzwerkkomponenten (in Switches, Routern usw.) von diesen entkoppelt ist, also an einer anderen Stelle im Netzwerk platziert und mithilfe eines bzw. mehrerer spezieller Controller sowie eines speziellen Protokolls zwischen Controllern und Netzwerkkomponenten realisiert wird. Beispielsweise besitzen die SDNfähigen Switches und Router fast keine „eigene“ Steuerung mehr, sondern werden von einer ausgelagerten Stelle einprogrammiert – quasi fern angesteuert. Beim SDN können innerhalb einer physischen Netzwerkstruktur mehrere, den Geschäftsprozessen angepasste, virtuelle Netzwerke bei Bedarf spontan für eine bestimmte, sogar nur kurze Zeitspanne eingerichtet werden. Es kann also ad hoc ein Software-definiertes

1

S ► SDN

Netzwerk (Software Defined Network) aufgebaut werden. So ermöglicht das SDN es beispielsweise einem Service Provider, in seinem Datacenter für Kunden mehrere virtuelle Datacenter (Virtual Data Center, VDC) so einzurichten, dass man von Multi-Tenancy – also von Mandantenfähigkeit – sprechen kann. Der Betreiber eines Datacenters, in dem eine „öffentliche Rechnerwolke“ – eine sog. Public Cloud – eingerichtet wurde, kann SDN dazu verwenden, diese seinen Kunden als Multi-Tenant Network mit zahlreichen Privat Clouds anzubieten und ihnen so verschiedene Arten von Cloud Computing Services, wie z.B. Infrastructure as a Service (IaaS) oder Platform as a Service (PaaS), entgeltlich zur Verfügung zu stellen. Mit SDN hat somit eine neue Ära von Networking begonnen und der Weg zu Software-definierten Netzwerken ist beschritten worden. Die zum SDN führenden Entwicklungen und die zahlreichen SDN betreffenden Aktivitäten werden von zwei Organisationen koordiniert. Somit gibt es zwei konkurrierende, sehr ähnliche, dem SDN zugrunde liegende Konzepte, welche auch als SDN-Frameworks betrachtet werden können. Es handelt sich hierbei um: •

OpenFlow1, herausgegeben von der im Jahr 2011 von Deutscher Telekom, Facebook, Google, Microsoft, Verizon und Yahoo! gegründeten Open Networking Foundation (ONF)2, der alle auf dem Gebiet Networking tätigen namhaften Firmen angehören.

•

ForCES, kurz für Forwarding and Control Element Separation, herausgegeben von der Internet Engineering Task Force (IETF)3.

Die hier dargestellten Ideen, die Konzepte für SDN und deren Anwendungsmöglichkeiten basieren ausschließlich auf dem Framework OpenFlow. Dieses Framework umfasst mehrere ONF-Dokumente4; zu nennen sind insbesondere die Dokumente „OpenFlow Switch

1

Es sei erwähnt, dass OpenFlow unter Führung der Stanford University und der University of California entwickelt wurde.

2 3

https://www.opennetworking.org http://datatracker.ietf.org/wg/forces

4

Auf der Website von Open Networking Foundation (ONF) können alle ONF-Dokumente kostenlos heruntergeladen werden.

2

S ► SDN

Specification“ und „OpenFlow Configuration and Management Protocol“. Grundlegendes Konzept von SDN Beim SDN wird vorausgesetzt, dass jede Netzwerkkomponente zur Übermittlung von Daten wie Switch oder Router die folgenden zwei funktionellen Teile enthält: •

Hardware zur Übermittlung (Weiterleitung) von Daten – als (Data) Forwarding Hardware bezeichnet – und

•

Software, die sich aus mehreren Applikationen und einem Betriebssystem zusammensetzt.

Das grundlegende Konzept von SDN basiert darauf, die Software in Netzwerkkomponenten zur Übermittlung von Daten möglichst von deren Hardware zu trennen und sie dann zu einer bzw. zu mehreren zentralen, als SDN-Controller bezeichneten Steuerungskomponente/n auszulagern. Demzufolge werden die Netzwerkkomponenten zur Übermittlung von Daten vereinfacht und zentral gesteuert. Diese Idee liefert neue Möglichkeiten, diverse Netzwerkdienste zu entwickeln, diese de facto zu programmieren und sie in Netzwerken mit vereinfachten Hardwareeinheiten zu verwirklichen. Beispiel für SDN in Datacentern Das SDN ist vor allem in großen Datacentern von besonderer Bedeutung. Aus diesem Grund wird hier die Idee des SDN am Beispiel des Einsatzes in Datacentern erläutert. Hierfür soll die in Bild 005451 gezeigte, sehr stark vereinfachte Struktur der Vernetzung von Switches in Datacentern – insbesondere die Vernetzung von Access Switches zur Anbindung von Servern an Aggregation Switches – betrachtet werden.

Bild 005451: Struktur der Vernetzung von Switches in Datacentern 3

S ► SDN

AS: S:

Access Switch Server

Um die bereits geschilderte logische Betrachtung von Netzwerkkomponenten beim SDN näher zum Ausdruck zu bringen, zeigt Bild 005452 die logische Struktur von Access und Aggregation Switches in der in Bild 005451 dargestellten Vernetzung.

Bild 005452: Vernetzung von Switches in Datacentern und deren vereinfachte logische Struktur App: DFH: OS:

Application: Software zur Realisierung einer Switch-Funktion Data Forwarding Hardware: bildet eine (Data) Forwarding Plane Operation System: Betriebssystem; bildet eine Control Plane

Im Allgemeinen wird beim SDN angenommen, dass die Hardware in den zur Übermittlung von Daten dienenden Netzwerkkomponenten (z.B. in Switches) eine (Data) Forwarding Plane bildet. Es sei aber angemerkt, dass jede Forwarding Plane die Daten in Form von in Ethernet Frames eingekapselten Paketen übermittelt (weiterleitet). Ähnlich wie bei der Hardware kann auch die Software jeder der Übermittlung von Daten dienenden Netzwerkkomponente in Form von zwei funktionellen Planes dargestellt werden: das Betriebssystem als Control Plane und alle Applikationen als Application Plane. Die grundlegende Idee des SDN5 besteht darin, die kontroll- und anwendungsspezifische Software von der Hardware in Netzwerk-

5 Es sei nochmals hervorgehoben, dass dieser Beitrag nur das SDN auf Basis des Framework OpenFlow präsentiert. Beim SDN nach dem Framework

4

S ► SDN

komponenten zur Übermittlung von Daten möglichst so zu entkoppeln, dass diese von der Hardware entfernt in einem zentralen Controller bzw. in mehreren Controllern untergebracht werden kann. Bild 005453 illustriert diese Idee.

Bild 005453: Bedeutung des SDN bei der Vernetzung von Switches in Datacentern AG: API: App: AS: DFH: L2: OF:

Aggregation Switch Application Programming Interface Application Access Switch Data Forwarding Hardware Layer 2 OpenFlow

Wie hier ersichtlich ist, führt das SDN dazu, dass die zur Übermittlung von Daten dienenden Netzwerkkomponenten hauptsächlich die Hardware als Forwarding Plane benötigen: sie müssen also weder eine Control Plane noch eine Application Plane besitzen. Diese beiden Software Planes werden in einem zentralen Controller untergebracht und von dort aus werden alle – sowohl um die Control Plane als auch um die Application Plane „reduzierten“ – Switches mithilfe eines speziellen, als OpenFlow (OF) bezeichneten Protokolls angesteuert.

ForSEC würde das ForSEC-Protokoll dem OpenFlow-Protokoll entsprechen (siehe hierzu RFC 5810).

5

S ► SDN

An dieser Stelle sei darauf verwiesen, dass die SDN-konformen Netzwerkkomponenten zur Übermittlung von Daten nur eine Data Forwarding Hardware (DFH) – also de facto nur die Forwarding Plane – besitzen und, damit sie von einem Controller mithilfe von OpenFlow angesteuert werden können, OpenFlow-fähig sein müssen. Ein OpenFlow-fähiger Switch wird auch OpenFlow Switch – kurz OF-Switch oder OFS – genannt. Anmerkung: Unter Flow, genauer: Data Flow, Datenfluss, versteht man eine Folge von Ethernet Frames mit den gleichen Angaben in einigen Feldern im Protokoll-Overhead; zu diesem gehören die folgenden Header: Ethernet-, IPv4-/IPv66- und TCP7-/UDP8-Header. Den Datenfluss einer TCPVerbindung markieren beispielsweise die Angaben: IP Source Address, TCP Source Port, IP Destimation Address, TCP Destination Port. Die Bezeichnung „Open“ in OpenFlow verweist darauf, dass der Datenfluss beliebig sein kann. Betrachtet man die in Bild 005453 gezeigte Vernetzungsstruktur, so erkennt man, dass die Vernetzung von SDN-konformen Access und Aggregation Switches zu einer besonderen Data Forwarding Infrastructure (DFI) führt; diese könnte man als Distributed-Layer2-Fabric bzw. quasi als Ethernet Fabric mit programmierbaren OFSwitches betrachten. Bild 005454 bringt dies zum Ausdruck und zeigt dabei, dass die in Bild 005451 dargestellte Struktur der Vernetzung von Switches in Datacentern auch beim SDN weiter erhalten bleibt, wobei jetzt alle Switches OF-Switches sind. Innerhalb der DFI werden die in Ethernet Frames (also in Layer-2Frames) eingekapselten IP-Pakete übermittelt und die DFI kann von einem Controller mithilfe des OF-Protokolles so angesteuert werden, dass sie gewünschte Netzwerkdienste zur Verfügung stellt. Um welche Netzwerkdienste es sich handelt, bestimmen die Applikationen im Controller (vgl. Bild 005453). Diese greifen über eine standardisierte Softwareschnittstelle (Application Programming Interface, API) auf die Control Plane zu und sind mithilfe des OFProtokolls in der Lage, die OF-Switches in der DFI bei Bedarf so

6 7 8

Internet Protocol Version 4 oder 6 Transmission Control Protocol User Datagram Protocol

6

S ► SDN

einzuprogrammieren (zu konfigurieren), dass erwünschte Netzwerkdienste von der DFI erbracht werden können.

Bild 005454: OF-Switches bilden eine Data Forwarding Infrastructure (DFI) AG: AS: OFS: S:

Aggregation Switch Access Switch OpenFlow Switch (OF-Switch) Server

Vergleicht man die Bilder 005451 und 005454, so erkennt man sofort den Vorteil des SDN, und zwar: Beim SDN können die Netzwerkadministratoren ihre DFIs von einer zentralen Stelle aus flexibel gestalten und hierbei verschiedene Netzwerkdienste – z.B. dem aktuellen Bedarf angepasste virtuelle Netzwerke – auch für nur kurze Zeitspanne einrichten. SDN-Architektur ohne Virtualisierung von Netzwerkressourcen Im Allgemeinen kann das SDN als Framework zur Programmierung von Netzwerkdiensten angesehen werden; Bild 005455a zeigt dessen logische Architektur. Diese geht u.a. auch aus den Bildern 005453 und 005454 hervor. Bild 005455b soll zum Ausdruck bringen, dass die logische Architektur von SDN sehr der logischen Architektur eines Servers ähnelt. Hierbei entsprechen: Ethernet-Adapterkarten (Network Interface Controller, NIC) der Forwarding Plane, das Operation System (Betriebssystem) der Control Plane und die Applikationen im Server der Application Plane.

7

S ► SDN

Bild 005455: SDN ohne Virtualisierung von Netzwerkressourcen: a) SDN-Architektur, b) Architektur eines Servers ohne Virtualisierung dessen Ressourcen API: App: NIC: OF:

Application Programming Interface Application Network Interface Controller (Card) OpenFlow

Die drei funktionellen, als Planes bezeichneten Schichten der logischen SDN-Architektur sind: •

Forwarding Plane Diese verteilte Plane repräsentiert eine Vernetzung von OFSwitches, d.h. von Switches, die hauptsächlich nur eine Hardware zur Übermittlung (Weiterleitung) von Daten – also eine (Data) Forwarding Plane – enthalten und das OF-Protokoll unterstützen. Dadurch können die Switches von der ausgelagerten, in einem Controller realisierten Control Plane angesteuert werden. Die Infrastructure Plane könnte man als Ethernet Fabric betrachten. Unter OF-Switches unterscheidet man zwischen physikalischen und virtuellen, in Wirt-Servern realisierten Switches. Ein physikalischer Wirt-Server mit einer Vielzahl von virtuellen Servern (von Virtual Machines) kann sogar mehrere virtuelle OF-Switches als Access Switches zur Anbindung von virtuellen Servern zur Verfügung stellen.

•

Control Plane Zu dieser Plane gehören Controller. Sie setzen von Applikationen generierte Anweisungen (Richtlinien, Policies) in entsprechende, an OF-Switches übermittelte Nachrichten des OFProtokolls um. Dadurch können OF-Switches innerhalb der entfernten Forwarding Plane angesteuert werden. Diese Ansteuerung führt dazu, dass die sog. Flow Tables in OF-Switches ent8

S ► SDN

sprechend den seitens der Applikation generierten Anweisungen einprogrammiert (konfiguriert) werden (vgl. Bild 005456). In einigen Flow Tables können beispielsweise neue Einträge – sog. Flow Table Entries (vgl. Bild 005457) – hinzugefügt bzw. alte geändert oder gelöscht werden. Auf diese Art und Weise kann innerhalb einer aus OF-Switches bestehenden Netzwerkinfrastruktur ein Netzwerkdienst (z.B. Virtual Local Area Network, VLAN) eingerichtet werden. •

Application Plane Innerhalb dieser Plane werden verschiedene, als SDNApplikationen bezeichnete Tools zur Programmierung der Netzwerkdienste angesiedelt. Genau genommen dienen die Applikationen der Erstellung von entsprechenden Anweisungen, die daraufhin als Entries in Flow Tables abgespeichert werden (Bild 005457), um die OF-Switches anzusteuern. Die API als offene Softwareschnittstelle soll eine einheitliche Programmierung der Netzwerkdienste ermöglichen.

Auf die SDN-Architektur mit Virtualisierung von Netzwerkressourcen soll im Weiteren noch eingegangen werden (vgl. Bild 005466). OF-Switch – logische Struktur und Funktionsweise Die physikalische Infrastruktur von SDNs wird durch die Vernetzung von OF-Switches gebildet und in der logischen SDNArchitektur Forwarding Plane genannt. Beim SDN kann daher ein OF-Switch als physikalischer, programmierbarer Netzknoten angesehen werden. Um die Funktionsweise eines OF-Switch anschaulich erläutern zu können, illustriert Bild 005456 dessen logische Struktur – vgl. hierzu die ONF-Specification [OF-Switch]. Allgemein betrachtet, besitzt jeder OF-Switch die folgenden drei Funktionskomponenten: •

9

Kommunikationsinstanz vom/zum Controller Über diese Instanz – in der „OF-Switch Specification“ OpenFlow Channel genannt – erfolgt die Kommunikation zwischen dem OF-Switch und einem Controller nach dem OFProtokoll; sie wird nach Transport Layer Security (TLS) gesichert, einem in RFC 5246 spezifizierten Sicherheitsprotokoll. Über diese Kommunikationsinstanz kann der OF-Switch dem aktuellen Bedarf entsprechend einprogrammiert und auch über-

S ► SDN

wacht werden. Die Anweisungen (Befehle) übermittelt der Controller an den OF-Switch in den Nachrichten des OF-Protokolls.

Bild 005456: Logische Struktur des OF-Switch (OpenFlow Switch) AS: FT/GT/MT: In-/Eg-Port: MD:

•

9

Action Set (Liste von Aktionen zum Ausführen) Flow/Group/Meter Table Ingress/Egress Port (Eingangs-/Ausgangsport) Metadata

Action-Set-Bestimmungsinstanz Die AS-Bestimmungsinstanz enthält eine Reihe von Flow Tables, in denen vom Controller empfangene Anweisungen in Form von sog. Flow Table Entries (Bild 005457) abgespeichert werden. Eine Flow Table wird verwendet, um zu bestimmen, welche Aktion (Operation) in einem empfangenen Ethernet Frame vor dessen Weiterleitung ausgeführt wird und wie er weitergeleitet werden muss – z.B. über welchen Ausgangs-Port. Zur Bestimmung der Aktion wird der Abgleich (Matching) von Angaben im Protokoll-Overhead – d.h. von Angaben in den folgenden Headern im Ethernet Frame (Ethernet-, IPv4-, IPv6-, TCP/UDP-Header) – mit den sog. Match Fields aller Entries der Flow Table durchgeführt (vgl. Bilder 005458 und 005460). Besteht beim Abgleich in einer Entry eine Übereinstimmung, bestimmt das Feld Instructions der Entry die auszuführende Aktion. Besteht aber keine Übereinstimmung, bestimmt die sog. Table-miss Flow Entry9 die Aktion. In einer solchen Situation kann beispielsweise der betreffende Ethernet Frame verworfen –

Auf ihre Bedeutung wird im Weiteren noch detaillierter eingegangen.

10

S ► SDN

darüber wird der Controller informiert – oder an den Controller übergeben werden, um dort zu prüfen, ob eventuell eine Route für einen neuen Datenfluss eingerichtet werden soll (vgl. Bild 005461). Damit man auch „multifunktionelle“ Netzwerkdienste (z.B. „Firewall mit Layer-4-Switching“ oder „Layer-3-Switching mit NAPT10“) realisieren kann, muss eine Reihe von Aktionen, die einen Action Set (AS) bilden, ausgeführt werden. Um einen Action Set bei Netzwerkdiensten dieser Art zu bestimmen, wird eine Kette von Flow Tables – die sog. Pipeline – verwendet. Es sei angemerkt, dass auch zwischen den Flow Tables bestimmte Daten – Metadata genannt – übergeben werden müssen. Auf die Bestimmung des Action Set soll im Weiteren noch detaillierter eingegangen werden (vgl. Bild 005460). •

Action-Set-Ausführungsinstanz In der AS-Ausführungsinstanz wird der Action Set ausgeführt. Dabei werden einige Felder im Protokoll-Overhead des Ethernet Frame vor dessen Übergabe an einen Ausgangsport modifiziert.

Jeder OF-Switch besitzt zwei besondere Tabellen, eine Group Table (GT), damit er u.a. Multicast, Link Aggregation und Multipathing unterstützen kann (vgl. Bilder 005463 und 005464), und eine Meter Table (MT), die er bei der QoS11-Unterstützung benötigt (vgl. Bild 005465). OF-Switch mit einer Flow Table – Beispiele für seine Funktionen Nehmen wird an, dass ein OF-Switch (vgl. Bild 005456) in der ASBestimmungsinstanz nur eine Flow Table hat und diese von einem Remote Controller einprogrammiert werden kann; er ist also ein Software Defined Switch. Einen solchen Switch könnte man z.B. so einprogrammieren (vgl. Bild 005458), dass er auf einer der folgenden Layer seine Funktionen bereitstellt: •

10 11

Layer-2-Switch: L2-Switch, Ethernet Switch Die Flow Table stellt eine L2-Forwarding-Table (L2-Switching-

Network Address Port Translation, RFC 3022 Quality of Service

11

S ► SDN

Tabelle) dar und die AS-Ausführungsinstanz realisiert die Weiterleitung von Ethernet Frames gemäß der sog. Weiterleitungstabelle (Forwarding Table). •

Layer-3-Switch: L3-Switch/Router Ein L3-Switch kann de facto als Router zur Kommunikation zwischen lokalen, als IP-Subnetze eingerichteten VLANs angesehen werden. Realisiert ein OF-Switch das L3-Switching, dann stellt die Flow Table eine L3-Forwarding-Table (in der Tat eine Art Routingtabelle) dar und die AS-Ausführungsinstanz realisiert die Weiterleitung von IP-Paketen gemäß der L3Forwarding-Table.

•

Layer-4-Firewall In diesem Fall enthält die Flow Table z.B. die Anweisung: Die IP-Pakete mit dem Zielport 80 im TCP-Header dürfen nicht weitergeleitet – müssen also verworfen (dropped) – werden.

Enthält ein OF-Switch mehrere Flow Tables als Pipeline, so kann er bei der Weiterleitung von Datenflüssen eine aufeinanderfolgende Reihe von Funktionen – quasi eine Funktionskette – realisieren. Bild 005459 veranschaulicht dies. Flow Table Entry – Struktur, Inhalt und Bedeutung Jede Flow Table enthält eine Reihe von strukturierten, als Flow Table Entries bezeichneten Zeilen, wobei eine Flow Table Entry (FT-Entry) sich nur auf einen Datenfluss (Data Flow) bezieht und beschreibt, wie alle zu diesem Datenfluss gehörenden Ethernet Frames mit IP-Paketen während deren Weiterleitung im OF-Switch „bearbeitet“ werden müssen. Bild 005457 zeigt die Struktur einer FT-Entry. Weil jede FT-Entry, d.h. jede Zeile in der Flow Table, sich nur auf einen einzigen Datenfluss bezieht, wird bei der Weiterleitung jedes Ethernet Frame aus einem Datenfluss (aus einem Flow) zuerst „herausgefiltert“, welche FT-Entry diesem Datenfluss entspricht, und dann wird aus dieser FT-Entry abgelesen, wie der Ethernet Frame im OF-Switch „bearbeitet“ werden muss.12

12

Es sei noch angemerkt, dass beim Routing ein ähnlicher Vorgang vorliegt. Jede Zeile in der Routingtabelle bezieht sich nur auf eine Route (also auf

12

S ► SDN

Bild 005457: Struktur und Inhalt einer Flow Table Entry [OFSwitch] DST: ETH: HM: IN: IPVx: OF: ONF: OXM: PHY: SRC: TCP: TLV: UDP:

Destination-Ethernet-Adresse oder Destination-IP-Adresse Ethernet HasMask Ingress Port (Eingangsport) Internet Protocol Version x OpenFlow Open Networking Foundation OpenFlow Extensible Match Physical Source-Ethernet-Adresse oder Source-IP-Adresse Transmission Control Protocol Type-Length-Value User Datagram Protocol

einen Datenfluss). Somit muss im Router bei der Weiterleitung jedes IPPakets zuerst ermittelt werden, welche Zeile in der Routingtabelle der betreffenden Route entspricht und dann wird in dieser Zeile abgelesen, wie das IPPaket „bearbeitet“ und weitergeleitet werden muss.

13

S ► SDN

In der FT-Entry ist das Feld Instructions von entscheidender Bedeutung. Es beschreibt, welche Aktion während der Weiterleitung des betreffenden Ethernet Frame ausgeführt werden muss – und demzufolge auch, welche Funktion vom OF-Switch erbracht wird (vgl. Bild 005458). Jede FT-Entry beginnt mit einer Auflistung von als Match Fields (Abgleichfeldern) bezeichneten Feldern aus dem ProtokollOverhead13, die auf eine Übereinstimmung (Matching) mit den gleichnamigen, d.h. ihnen entsprechenden, Feldern in jedem weiterzuleitenden Ethernet Frame überprüft werden müssen. Um eine Übereinstimmung zu finden und somit die dem Datenfluss entsprechende FT-Entry herauszufiltern, wird der Abgleich (Matching) zwischen dem Protokoll-Overhead im zu weiterleitenden Ethernet Frame und den Match Fields allen Entries der Flow Table durchgeführt. Bei voller Übereinstimmung in einer FT-Entry wird diese – auch Flow Entry genannt – interpretiert, um die Art und Weise der „Bearbeitung“ (Processing) des betreffenden Ethernet Frame bei dessen Weiterleitung zu bestimmen. Um die Struktur einer FT-Entry zu erläutern, sollen zuerst nur Match Fields und Instructions etwas näher betrachtet werden. Ein Feld Match (vgl. Bild 005457) wird im sog. OXM-Format (OpenFlow Extensible Match) spezifiziert und hat die Struktur TLV (Type-Length-Value). Hierbei nutzt man die als oxm_type bezeichnete Kombination (oxm_class, oxm_field) zum Verweisen auf den Inhalt oxm_value des Abgleichfelds – also auf dessen Wert. Beispielsweise wird mit OXM_OF_IPV4_DST auf die IPv4-

Zieladresse verwiesen. Die Länge des Abgleichfelds (von 5 bis 259 Byte) wird in das Feld oxm_length eingetragen. Eine besondere Funktion erfüllt das Bit HM (HasMask). Dieses fungiert als Indikator und verweist im Falle HM = 0 in einer FT-Entry darauf, dass dem Feld oxm_value kein Feld oxm_hasmask mit einer Bitmaske (Bitmask) vorangestellt wurde – darauf also, dass es keine Bitmaske gibt. In einem solchen Fall wird nach einer exakten Übereinstimmung zwischen einem Feld im Protokoll-Overhead des

13 Als Protokoll-Overhead versteht man folgende, den zu transportierenden Daten vorangestellte Header: Ethernet-, IPv4-/IPv6- und TCP-/UDP-Header.

14

S ► SDN

weiterzuleitenden Ethernet Frame und dem Feld oxm_value gesucht. Sind die beiden Felder vollkommen identisch, dann tritt die exakte Übereinstimmung auf und man spricht von Exact Matching. Eine FT-Entry mit HM = 0 – also ohne Bitmaske – wird Exact Flow Entry genannt. Es gibt aber auch Felder im Protokoll-Overhead, in denen beim Abgleich nur nach einer partiellen Übereinstimmung gesucht wird. In einem solchen Fall muss angegeben werden, welche Bits beim Abgleich relevant sind. Dies wird mit einer Bitmaske im Feld 14 oxm_hasmask vorgenommen. Die beiden Felder oxm_hasmask und oxm_value haben somit die gleiche Länge. Mit den auf 1 gesetzten Bits in der Bitmaske wird angegeben, welche Bits beim Abgleich relevant sind. Das Feld oxm_value, dem eine Bitmaske vorangestellt wurde – d.h. in dem nicht alle Bits beim Abgleich relevant sind – bezeichnet man als Wildcard-Feld bzw. auch kurz Wildcard. Eine FT-Entry mit HM = 1 – also mit einer Bitmaske – nennt man Wildcard Flow Entry. Die restlichen Felder Priority, Counters, Instructions, Timeouts und Cookie in FT-Entries haben folgende Bedeutung: •

Priority (Priorität einer Wildcard Flow Entry) Dieses Feld nutzt man bei Wildcard-Feldern. Falls es mehrere FT-Entries mit Wildcard-Feldern gibt, können mehrere partielle Übereinstimmungen auftreten – stehen also mehrere FT-Entries zur Auswahl. In diesem Fall wird die FT-Entry mit der höchsten Priorität ausgewählt und der betreffende Ethernet Frame gemäß der in deren Feld Instructions festgelegten Aktion „bearbeitet“ und weitergeleitet.

•

Counters (Zähler) Jede FT-Entry kann bestimmte Zähler enthalten, um pro Flow Entry z.B. die Anzahl der empfangenen Ethernet Frames oder die Anzahl der empfangenen Bytes zu ermitteln. Diese Werte können danach zur Verbesserung der Performance verwendet werden.

14

Die hier erwähnte Bitmaske hat die gleiche Bedeutung wie z.B. die gut bekannte Subnetzmaske, mit der man markiert, welche Bits in einer IPAdresse als Subnetz-Identifikation zu betrachten sind [1].

15

S ► SDN

•

Instructions (Aktionen) Hier wird die Aktion spezifiziert, die bei einer Übereinstimung ausgeführt werden soll.

•

Timeouts Eine FT-Entry kann nur eine bestimmte Zeitspanne nach ihrer Eintragung bzw. Modifikation gelten, danach muss sie gelöscht werden. Jede FT-Entry hat die folgenden zwei Vorgaben für die Zeitspanne (in Sek.): - idle_timeout – dient zur Entfernung einer nutzlosen FTEntry: Falls innerhalb dieser Zeitspanne keine Übereinstimmung in einer FT-Entry festgestellt wurde, sie also nutzlos war, wird sie gelöscht (entfernt). - hard_timeout – bestimmt die Lebensdauer einer FT-Entry: Ist diese Zeitspanne seit der Entry-Eintragung in der Flow Table abgelaufen, wird die Eintragung gelöscht.

•

Cookie (vom Controller vorgegebene zufällige Zeichenkette) Dieses Feld verwendet man zur Erhöhung der Sicherheit bei der Kommunikation zwischen Controller und OF-Switch. Ein Cookie wird vom Controller für eine kurze Zeitspanne vorgegeben und muss – ohne jegliche Änderung! – in jeder vom OF-Switch an den Controller übermittelten Nachricht enthalten sein.

Bedeutung von Table-miss Flow Entry Jede Flow Table muss eine besondere Flow Entry beinhalten, die sog. Table-miss Flow Entry. Diese wird lediglich dann abgelesen, wenn für einen weiterzuleitenden Ethernet Frame in der Flow Table keine ihm entsprechende Entry gefunden wurde, d.h. weder eine Exact Flow Entry noch eine Wilcard Flow Entry vorhanden ist. Die Table-miss Flow Entry spezifiziert, wie ein Ethernet Frame aus einem Datenfluss in einem solchen Fall „behandelt“ werden muss. Hierbei kommen beispielsweise folgende Möglichkeiten infrage: •

der Ethernet Frame wird einfach verworfen;

•

der Ethernet Frame wird verworfen und seine Kopie wird an den Controller gesendet. Daraufhin kann der Controller eventuell einen neuen Datenfluss im Netzwerk einrichten.

•

der Ethernet Frame wird an eine der nächsten Flow Tables übergeben.

16

S ► SDN

OF-Switch-Funktionen – auf Basis nur einer Flow Table Nachdem bereits die Struktur einer FT-Entry vorgestellt wurde (vgl. Bild 005457), sollen jetzt einige, in Bild 005458 gezeigte Funktionen betrachtet werden, welche man in einem OF-Switch mit nur einer einzigen Flow Table einprogrammieren kann.

Bild 005458: Funktionen eines OF-Switch mit einer Flow Table ID: NAPT: NAT: SA: SP: VLAN:

Identifier Network Address Port Translation Network Address Translation Source Address Source Port Virtual Local Area Network (hier de facto ein IP-Subnetz)

In Bild 005458 wurden alle Match-Felder aufgelistet, welche in FTEntries von OF-Switches enthalten sein müssen und welche bei den aufgelisteten Funktionen relevant sind. Daraus ist ersichtlich, dass eine Flow Table zur Bereitstellung verschiedener Netzwerkdienste durch die Konfiguration einzelner Abgleichfelder sehr flexibel einprogrammiert werden kann.

17

S ► SDN

Für die Fortsetzung siehe: Fachkompendium Protokolle und Dienste der Informationstechnologie, WEKA-Verlag, ISBN: 978-3-8276-9142-2

http://shop.weka.de/webapp/wcs/stores/servlet/Product2s_Protokolle -und-Dienste-der-Informationstechnologieonline_10203_10053_10635_-3_10061_10010_10010

18