Northbound API Requirements for SDN

Transkript

1 Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Seminar Innovative Internet-Technologien und Mobilkommunikation 2014: Northbound API Requirements for SDN Christian Fuchs

2 Überblick Software Defined Networking (SDN) Was ist das? Und was ist das Northbound bzw. das Southbound API/Interface? Southbound Interface Open Flow Northbound Interface: Vorteile einer Standardisierung Mögliche Anforderungen Hindernisse einer Standardisierung Anforderungen an einen Standard Unterschiede im Standardisierungsprozess von North- und Southbound Interface 2

3 Software Defined Networking (SDN) Was ist das? Trennung der Control Plane von der Forwarding Plane Control Plane logisch zentralisiert in Controller Control Plane: Entscheidungsfindung (Was geschieht mit welchem Paket?) Forwarding/Data Plane: konkrete Behandlung der Pakete (z.b. Weiterleitung) anhand der Regeln der Control Plane Software Defined Networking: Controller in Software realisiert Netz wird komplett durch Software gesteuert ( definiert ) 3

4 Software Defined Networking (SDN) konkret vor SDN bzw. ohne SDN: mit SDN: 4

5 Software Defined Networking (SDN) konkret vor SDN bzw. ohne SDN: mit SDN: Konfiguration 5

6 Software Defined Networking - Verwendungsgebiete Großer Bedarf an einfach zu konfigurierender, aber dennoch sehr mächtiger Virtualisierung: Mobile Endgeräte Infrastrukture as a Service (Iaas) Cloud Services / Cloud Computing Komplexe Firewall und Access Control Konzepte Videostreaming, Voice over IP / Video over IP, Echtzeittraffic, usw. komplexe QoS Mechanismen benötigt Weniger Inkonsistenz mehr Sicherheit Gute Skalierbarkeit Einsatz von SDN in Rechen- & Datenzentren, Firmen- & Campusnetzwerken, Netzen von ISPs (WAN), u.v.m. 6

7 Software Defined Networking - Anwendungsbeispiele Google betreibt ein SDN basiertes WAN (G-Scale): Grafik aus [3] Google Andromeda: Microsoft Hyper-V Grafik aus [4] 7

8 Software Defined Networking - Übersicht 8

9 Northbound und Southbound API/Interface Norden oben Süden unten Northbound Interface/Northbound API/ NBI: Schnittstelle zur in Abstraktionshierarchie nächst höheren Instanz Southbound Interface/Southbound API: Schnittstelle zur in Abstraktionshierarchie nächst niedrigeren Instanz 9

10 North- und Southbound Interface im SDN Umfeld Northbound API: Schnittstelle zwischen Controller und SDN Applikationen abstrakte Sicht auf Netzwerk Funktionalitäten zur Manipulation der Netzwerkverhaltens Southbound Interface: Schnittstelle zwischen Controller und zu kontrollierten Netzwerkkomponenten (z.b. Switches) Definition von: Kommunikations-Protokoll Controller Switches Menge an zu unterstützenden Aktionen (z.b. forwarding, flooding,...) Menge an zu unterstützenden Informationen (z.b. QoS Metainformationen) 10

11 Southbound Interface Open Flow Entwickelt 2008 an der Universität von Stanford Stark unterstützt von der Open Networking Foundation : 2011 gegründete Non-Profit Organisation Sehr starke Mitglieder Ziel: Förderung von SDN und Etablieren von offenen Standards Viel OpenFlow fähige Hardware nach kurzer Zeit Robustes, erweiterbares, auf viele Anwendungsgebiete anwendbares Design Marktakzeptanz häufig benutzter Standard 11

12 Northbound API - aktuelle Situation 30+ verschiedene Controller Frameworks Alle von verschiedenen Instanzen mit individuellen Zielen zur Realisierung eines spezifischen Zwecks geschaffen Verschiedenen Abstraktionslevel In verschiedene Sprachen eingebettet Unterschiedliche Konfigurationsschnittstellen über 30 verschiedene Northbound APIs im Umlauf Verlagerung der Portabilitätsprobleme von den Switches hin zu den Controllern 12

13 Standarisierung des NBI aktueller Stand ONF: 2012 Diskussionsgruppe 2013 formale Northbound Interface Working Group Keine Ergebnisse veröffentlicht Keine andere Institution bemüht sich konkret um einen Standard OpenDaylight Projekt: Von einigen als potentieller NBI Standard gesehen Sehr jung Hauptsächlich Code produzierend kein Interesse an Standardisierung 13

14 Vorteile einer Standardisierung der Northbound API Erreichen von mehr Endnutzern Anwenderfreundlichkeit durch einfachere Portabilität Etablieren von den Markt belebender Konkurrenz schnellere Verbreitung von Software Defined Networking Entscheidender Faktor: Das wichtigste im SDN Umfeld sind die Applikationen!!! 14

15 Mögliche Anforderungen an eine Northbound API verteilter Controller ABER: möglichst wenig Overhead mit bestmöglichster Performance, möglichst geringe Komplexität und Kosten Für Entwickler angemessene Komplexität, angemessener Abstraktionsgrad und angemessener Funktionsumfang ABER: Wer ist der Entwickler? sehr unterschiedliche Anforderungen Angemessene Abstraktion von der Topologie ABER: Was ist angemessen? sehr unterschiedliche Anforderungen Konkretes Lizenzmodell Anforderungen an den Controller (z.b. Skalierbarkeit) 15

16 Mögliche Anforderungen an eine Northbound API Die Anforderungen hängen stark vom Verwendungszweck bzw. dem Einsatzgebiet ab 16

17 Hindernisse einer Standardisierung Verschiedene Akteure mit unterschiedlichsten Interessen, Vorstellungen und Visionen über die (optimale) Zukunft von SDN Nicht alle wollen Erfolg von auf offenen Standards basierendem SDN Dynamischer, sich schnell verändernder Markt langwierigen Standardisierungsprozessen Mangelnde Marktakzeptanz 17

18 Hindernisse einer Standardisierung vielfältige Anforderungen sind nicht durch eine einzige API zu erfüllen Teilung eines Standards in mehrere APIs bzw. Einführung von komplexeren Erweiterungsmöglichkeiten birgt Risiken Wie granular sollte der Standard also sein? Akteure, die NBI Standard generell ablehnen 18

19 Anforderungen an einen NBI Standard An Use Cases orientieren Auf Veränderungen der Use Cases achten Vorsicht mit Erweiterbarkeit die Inkompatibilität verursacht Versionen kompatibel halten Redundanz vermeiden Standard sollte nicht zu spezifisch sein Unabhängig von konkreten Sprachen bleiben Marktakzeptanz erlangen Anforderungen hängen stark vom Verwendungszweck ab 19

20 Unterschiede im Standardisierungsprozess Hardware Entwicklungszyklen sind viel länger als die der Software Hardware Entwicklung daher sehr kostspielig Southbound API: große, traditionelle Anbieter haben großen Vorteil Northbound API: viel mehr Akteure viel diversifizierter kleine Anbieter können sich viel einfacher etablieren Markt regelt vieles selbst Standardisierung an statischerem Southbound Interface einfacher Standardisierung an dynamischerem Northbound Interface schwierig 20

21 Fazit SDN aktuell sehr wichtig in der Netzwerkwelt Aktuell kein NBI Standard Standard könnte aber Vorteile bringen Standardisierungsprozess schwieriger als am Southbound Interface Standardisierung eventuell durch ONF oder über Marktakzeptanz 21

22 Quellen 1 [1] SDN Architecture Overview. Version 1.0. Open Network Foundation [2] Software-Defined Networking: The New Norm for Networks. Open Network Foundation, [3] Präsentation für Open Network Summit 2012, Urs Hoelzle, aufgerufen am [4] Enter the Andromeda zone - Google Cloud Platform s latest networking stack. enter-andromeda-zone-google-cloud-platforms-latest-networkingstack.html, aufgerufen am

23 Quellen 2 [5] Composing Software Defined Networks. Christopher Monsanto, Joshua Reich, Nate Foster, Jennifer Rexford, and David Walker. In USENIX Symposium on Networked Systems Design and Implementation (NSDI), Lombard, IL, April 2013 [6] Modular SDN Programming with Pyretic. Joshua Reich, Christopher Monsanto, Nate Foster, Jennifer Rexford, and David Walker. ;login Magazine, 38(5): , Oktober 2013 [7] Software-Defined Networking. Keith Kirkpatrick. Communications of the ACM 56(9):16-19, September 2013 [8] The SDN Gold Rush To The Northbound API. Isabelle Guis, 16 November aufgerufen am

24 Quellen 3 [9] ONF Northbound Interface Group chair: No need for standards yet. Shamus McGillicuddy. 6 Dezember Northbound-Interface-Group-chair-No-need-for-standards-yet, aufgerufen am [10] Where Do We Stand with SDN's Northbound Interface?. Jim Metzler. aufgerufen am [11] OpenFlow: enabling innovation in campus networks. Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, Jonathan Turner. ACM SIGCOMM Computer Communication Review, 38(2), 69-74, März

25 Ich bedanke mich für Eure Aufmerksamkeit! 25

26 Noch Fragen? 26

27 Backup Folien 27

28 Southbound Interface Open Flow Interna Definition von Anforderungen an die Switches: Pipeline mehrerer Flow Tabelles Felder eines Tabelleneintrags: Matchings (siehe Tabelle unten) Metainformationen (z.b. Timeouts, Anzahl an empfangenen Bytes, Anzahl an empfangener Paketen,...) Aktion (z.b. normales Forwarding, DROP,...) Flow = Menge von Paketen mit gleichen Charakteristika Definition des Protokolls: Struktur und Abfolge der Pakete Sicherung des Kontrollkanals (SSL) Tabelle entnommen aus [11] 28

29 Northbound API Pyretic Entwickelt u.a. an den Universitäten Cornell und Stanford, vorgestellt 2013 Teil der Frenetic Famile In Python eingebettet Basiert auf Controller POX Bietet einfach zu verstehende, schön abstrakte NBI minimiert Risiko von Inkonsistenz und ungewolltem Verhalten im Netzwerk 29

30 Abstraktes Paket Modell Pakete sind Wörterbücher, die bestimmte Felder, wie Header Informationen, Paketdaten, Standort (virtuelles oder physisches Gerät und Port), aber auch virtuelle, selbst definierte Headerfelder auf ihre tatsächlichen Werte mapped Eigentlich Mapping auf Stack von Werten verschiedene Level der Abstraktion beliebige Virtualisierung Packet Processing als Funktion: Einer Funktion wird ein Paket übergeben und diese gibt eine (möglicherweise auch leere) Menge an Paketen zurück 30

31 Modularisierung und Kompositionsoperator Sämtliche Funktionalität in separaten Modulen realisierbar Verknüpfung der Module durch Kompositionsoperatoren: Parallele Komposition (+ Operator): Module werden unabhängig voneinander parallel ausgeführt Verhindert ungewollte Interferenzen zwischen den Funktionen Sequentielle Komposition (>> Operator): Pakete die von erstem Modul zurückgegeben werden dienen dem zweiten Modul als Eingabe Modell minimiert Redundanz in Applikationen und steigert Wiederverwendbarkeit und Portabilität des Codes 31

32 High Level Policy Funktionen Primitive Actions: A ::= drop passthrough fwd(port) flood push(h=v) pop(h) move(h1=h2) Predicates: P ::= all_packets no_packets match(h=v) ingress egress P & P (P P) ~P Query Policies: Q ::= packets(limit,[h]) counts(every,[h]) Policies: C ::= A Q P[C] (C C) C >> C if_(p,c,c) 32

33 Grenzen von Pyretic Virtuelle Header Felder werden weder von OpenFlow, noch von alternativen Protokollen unterstützt Pyretic Laufzeit muss diese Informationen selbst verwalten starker Performanceverlust Aktuell einzige Implementierung basiert auf POX: Nur OpenFlow Unterstützung Schlechte Performance Pyretic ist noch sehr jung: nur wenig Applikationen keine Performance Evaluation keine Evaluation über Stabilität, Usability, usw. Pyretic stark von Python abhängig: Portierung in andere Sprache wäre unter Umständen schwierig 33

34 Beispielcode - Loadbalancer def subs(c,r,p): c_to_p = match(srcip=c,dstip=p) r_to_c = match(srcip=r,dstip=c) return c_to_p[modify(dstip=r)] r_to_c[modify(srcip=p)] (~r_to_c & ~c_to_p)[passthrough] def rewrite(d,p): return (>>)([subs(c,r,p) for c,r in d]) def static_lb(p,r,h): return rewrite(balance(r,h),p) def lb(self,p,r,h): def rebalance(stats): H = H.update(stats) self.p = static_lb(p,r,h) q = counts(60,[ srcip ]) q.when(rebalance) self.p = static_lb(p,r,h) match(dstip=p)[q]) Code entnommen aus [5] 34