Software-defined Networking im Überblick
Gut verknüpft
Veröffentlicht in Ausgabe 11/2022 - SCHWERPUNKT
Der Siegeszug der Virtualisierung rollt unaufhörlich. Server machten den Anfang, dann folgten andere Komponenten, in den 2010er Jahren auch Netzwerke. Das Prinzip ist immer gleich: Physische Hardware und Software werden getrennt, bisher in Hardware gegossene Funktionen durch Software realisiert. Mehr Flexibilität und eine Aufweichung von festen Herstellerbindungen sind auch beim Software-defined Networking (SDN) der Lohn.
Und Flexibilität brauchen Provider und Unternehmen, um Technologien wie Remote, Mobile, Cloud und IoT, Edge-Computing, Virtuelle Realität, Container, Microservices und Service-Meshes optimal gestalten und nutzen zu können. Verbindungen sollen nicht mehr in Monaten, sondern in Minuten bereitgestellt oder in ihrer Qualität verändert werden. Zusätzliche Funktionen, etwa erhöhte Sicherheit, wollen Anwender bei Bedarf und lediglich für bestimmte Datenströme, Zeitabschnitte oder Strecken benutzen, nicht mehr pauschal buchen und bezahlen.
Schichtenmodell auch bei SDN
Das alles erfordert den Abschied vom hardwarebasierten Denken. Netzwerkvirtualisierung bedeutet dabei neben der Trennung von Soft- und Hardware vor allem die Trennung von Daten- und Kontrollpfad. Im Netz werden mehrere übergeordnete Ebenen implementiert, von denen aus sich die darunterliegenden Switches und Router (Ebene 2 und 3 nach dem Netzwerkmodell) sowie die Verbindungen zwischen ihnen und deren Qualitäten steuern lassen. Ziel dabei ist, möglichst allen Daten und Streams, die durchs Netz wandern, optimale Bedingungen zu bieten und unerwünschte Eindringlinge wirksam von den transportierten Datenpaketen fernzuhalten.
Der Siegeszug der Virtualisierung rollt unaufhörlich. Server machten den Anfang, dann folgten andere Komponenten, in den 2010er Jahren auch Netzwerke. Das Prinzip ist immer gleich: Physische Hardware und Software werden getrennt, bisher in Hardware gegossene Funktionen durch Software realisiert. Mehr Flexibilität und eine Aufweichung von festen Herstellerbindungen sind auch beim Software-defined Networking (SDN) der Lohn.
Und Flexibilität brauchen Provider und Unternehmen, um Technologien wie Remote, Mobile, Cloud und IoT, Edge-Computing, Virtuelle Realität, Container, Microservices und Service-Meshes optimal gestalten und nutzen zu können. Verbindungen sollen nicht mehr in Monaten, sondern in Minuten bereitgestellt oder in ihrer Qualität verändert werden. Zusätzliche Funktionen, etwa erhöhte Sicherheit, wollen Anwender bei Bedarf und lediglich für bestimmte Datenströme, Zeitabschnitte oder Strecken benutzen, nicht mehr pauschal buchen und bezahlen.
Schichtenmodell auch bei SDN
Das alles erfordert den Abschied vom hardwarebasierten Denken. Netzwerkvirtualisierung bedeutet dabei neben der Trennung von Soft- und Hardware vor allem die Trennung von Daten- und Kontrollpfad. Im Netz werden mehrere übergeordnete Ebenen implementiert, von denen aus sich die darunterliegenden Switches und Router (Ebene 2 und 3 nach dem Netzwerkmodell) sowie die Verbindungen zwischen ihnen und deren Qualitäten steuern lassen. Ziel dabei ist, möglichst allen Daten und Streams, die durchs Netz wandern, optimale Bedingungen zu bieten und unerwünschte Eindringlinge wirksam von den transportierten Datenpaketen fernzuhalten.
Über einer Kontrollschicht liegen in SDN-Infrastrukturen die Anwendungen im Rahmen der Network Function Virtualization (NFV). Der Basisstandard der offenen SDN-Vernetzung, OpenFlow, erlaubte nur die Definition einer Datenpipeline, also des Weges, über den ein bestimmtes Datenpaket oder ein Datenstream fließen soll. Mit NFV hingegen lassen sich zusätzliche spezifische Netzwerkfunktionen herstellerneutral und dezentral verteilt im Netz als Applikationen bereitstellen.
Solche Applikationen können auf Bare Metal, in Containern und auf virtuellen Maschinen laufen. Das betrifft beispielsweise das Erteilen von Zugriffsrechten, Firewalling, Verschlüsselung und vieles andere mehr. Desweiteren gehören zu SDN zwei Schnittstellen: Zwischen der Kontroll- und Anwendungsschicht liegt die Northbound API, zwischen der Kontroll- und Infrastrukturschicht die Southbound API.
Am Anfang war OpenFlow
Motor der Bestrebungen, virtualisierte und offene Netzwerkstrukturen, also Software-defined Networking, zu entwickeln, waren und sind die großen Provider und Cloud-Hyperscaler, die sich 2011 zur Open Networking Foundation (ONF) zusammenschlossen. Denn ihre Geschäfte litten am meisten unter der fehlenden Flexibilität früherer Netzwerkkonstrukte mit ihren Hardwarezoos, hohen Wartungs- und Personalkosten.
Die ONF hat mittlerweile über 200 Mitglieder, längst nicht mehr ausschließlich Provider. Die Stiftung liefert bis heute Impulse zur Weiterentwicklung des SDN, indem sie Projekte für neue technische Umsetzungen ins Leben ruft und verwirklicht. Auch kooperiert sie unter anderem mit der Open Compute Foundation (OCF).
Die ersten Ideen zur OpenFlow-Schnittstelle, des ersten SDN-Standards, stammten von der Stanford-Universität, wo schon 2008 eine erste Vorversion vorgelegt wurde. Version 1.0 erschien im Dezember 2009. Die Schnittstelle erlaubt den Durchgriff eines SDN-Controllers auf Router und Switches, was bis dahin unmöglich war.
Die Steuerung des offenen SDN erfolgt in Infrastrukturen, die OpenFlow nutzen, über in Hard- oder Software realisierte OpenFlow-konforme SDN-Controller. OpenFlow wurde in der Folge von großen Cloudprovidern implementiert. Außerdem entwickelte die ONF einen Standard für einen offenen virtuellen Switch. Wichtige Anwendungsgebiete des offenen SDN sind etwa Infrastructure-as-a-Service, wo SDN-Technologie das schnelle Skalieren erleichtert. Außerdem lassen sich Lasten effizient den vorhandenen Ressourcen zuordnen – beispielsweise momentan nicht benötigte Ressourcen abschalten. Nicht zuletzt erleichtert die SDN-Technologie die Definition und Einhaltung von Service Level Agreements.
Stratum als neues Switching-Betriebssystem
Die Phase, in der sich die ONF auf OpenFlow konzentrierte, ist heute allerdings vorbei. Die Organisation hat schon im März 2018 mit dem neuen Projekt Stratum den Abschied von OpenFlow als SDN-Leittechnologie verkündet. Während OpenFlow lediglich als Schnittstelle zur Forwarding-Schicht und zum Betriebssystem der Router diente, sollen mit Stratum Pipeline-Definition, -Konfiguration und -Betrieb zusammenfließen.
Stratum definiert ein siliziumunabhängiges, schlankes Switching-Betriebssystem für SDNs. Die erste Version kam 2019 auf den Markt. Es gibt eine offene, minimale, aber einsatzfertige Distribution für White-Box-Switches. Stratum macht diverse neuartige SDN-Schnittstellen zugänglich. Beispiele sind P4 Runtime und OpenConfig. Insgesamt lassen sich damit leichter beliebige Systeme in Providernetze integrieren.
Derzeit befindet sich Stratum in Version 20.06. Switches, die dafür zertifiziert sind, gibt es derzeit von APS Networks und Edgecore. Chips, die Stratum unterstützen, sind Broadcom Tomahawk und Trident II sowie Intel Tofino/Barefoot Networks. Nicht zertifizierte unterstützende Switches sind bei Dell, Delta, Inventec, QCT und Stordis erhältlich.
Der zertifizierte Edgecore AS7712-32X beispielsweise passt ins Rack und bietet Switching in Leitungsgeschwindigkeit. Das Gerät unterstützt bis zu 32 Verbindungen mit 40 oder 100 GbE, 64 mit 50 GbE oder 128 mit 10 respektive 25 GbE. Es eignet sich als Top-of-the-Rack-Switch oder als Spine-Switch für die Verbindung unterschiedlicher Spines.
VOLTHA, AETHER und SD-Fabric
Die meisten aktuellen Projekte der ONF zielen auf Provider und ihre technologischen Bedürfnisse. Dabei geht es auch viel darum, die technologischen Möglichkeiten des Mobilstandards 5G zu nutzen.
SEBA etwa ist eine Plattform für diverse virtualisierte Zugangstechnologien am Edge zum Core-Netz der Provider und kommt mit relativ wenig Ressourcen aus. Sie erlaubt sowohl die Versorgung von Haushalten mit Breitbandverbindungen als auch die drahtlose Rückverbindung zum Carrier-Core. Die Technologie leitet den Verkehr ohne Umwege direkt zum Core, ohne dass virtuelle Netzwerkfunktionen am Server verarbeitet werden müssen. Sie arbeitet mit Containern und Kubernetes.
VOLTHA baut eine Hardwareabstraktion von Breitband-Zugangsequipment, sprich Software, die diesen Zweck erfüllt. Der Ansatz ist herstellerneutral, disaggregiert und ermöglicht es, jeden breitbandigen Dienst als Service zur Verfügung zu stellen. Bislang gibt es ein Steuerungs- und Managementsystem für PON-Hardware (Passive optische Netze). Demnächst sollen Technologieprofile für andere Zugangstechnologien auf den Markt kommen. In Richtung zur Anwendung erscheint VOLTHA einem programmierbaren Ethernet-Switch als SDN-Controller. Mit der PON-Hardware kommuniziert VOLTHA über herstellerspezifische Protokolle und entsprechende Adapter. Zertifizierte Produkte gibt es von Adtran, Edgecore, Radisys, Sercomm und Zyxel.
Bei AETHER handelt es sich um eine Open-Source-Plattform, mit der sich private 5G/LTE-Edge-to-Cloud-Services realisieren lassen. Die Plattform stellt am Edge verteilter Enterprise-Netze mobile Verbindungen und Edge-Cloud-Services als verwaltete Clouddienste zur Verfügung. Die Plattform ist auf Multicloud-Deployment ausgerichtet und ermöglicht drahtlose Verbindungen in lizenzierten und unlizenzierten Frequenzbändern. AETHER liegt derzeit in Version 1.6 vor. Zertifizierte Produkte gibt es von Wiwynn und Sercomm.
SD-CORE ist ein integrierter Teil von AETHER. Das Projekt realisiert einen disaggregierten mobilen Core für 4/5G-Infrastrukturen für Public Clouds und daran angeschlossene verteilte Edge-Clouds. Die Technologie passt sowohl für Carrier- als auch für 5G-Firmennetze.
Nach außen präsentiert SD-CORE herkömmliche 3GPP-Schnittstellen. Zusammen mit AETHER lässt sich SD-CORE sehr schnell bereitstellen. Es gibt ferner die Möglichkeit, die Technologie als selbständigen 4/5G-Core oder als Steuerungs- und Datenebene von kundenspezifischen Anforderungen zu nutzen.
Open-RAN (O-RAN) ist ein Ansatz für offenen Remotezugang, der über einen echtzeitfähigen RIC (RAN Intelligent Controller) umgesetzt wird. Der Controller unterstützt xApps, die höhere Netzwerkfunktionen realisieren, etwa den Handover, wie sie früher von Mobilfunk-Basisstationen übernommen wurden.
Im SD-RAN-Projekt werden ein Open-Source-RIC mit annähernden Echtzeitfähigkeiten und einige xApps entwickelt. Ziel des Ansatzes ist es, die Ausbreitung der O-RAN-Technologie durch die Verfügbarkeit interoperabler Komponenten zu beschleunigen.
SD-Fabric ist eines der Projekte, die besonders für Unternehmen interessant sind. Es baut auf der Nutzung programmierbarer Schaltkreise auf. SD-Fabric bietet sich als entwicklungsfreundliche und voll programmierbare Full-Stack-5G-Netzwerk-Fabric an, die zukünftige Edge-Applikationen beispielsweise für Industrie 4.0 unterstützt und über die Cloud verwaltbar ist. Die Fabric hat die Entwicklung kundenspezifischer Edge-Clouds zum Ziel.
Dafür werden die programmierbaren Netzressourcen über SaaS-APIs bereitgestellt. Entwickler können so Applikationen fürs Edge entwickeln, die die CPU nur minimal belasten. Kundenspezifische Prozesse für die Paketverarbeitung lassen sich tief in die Netzwerkelemente einbetten und Anwendungsfunktionen durch P4-Funktionen (dazu später mehr) beschleunigen, die in Netzwerk-Switches, programmierbaren Server-NICs und Softswitches laufen. Das steigert die Leistung, senkt die Kosten und den Ressourcenbedarf. Auch SD-Fabric gehört zu AETHER und verbindet die gesamte Hardware einer AETHER-Site.
Weitere freie ONF-Projekte
ONOS (Open Network Operating System) ist von der ONF als SDN-Controller der nächsten Generation von SDN/NFV-Implementierungen vorgesehen. An den Ansprüchen von Carriern ausgerichtet, unterstützt ONOS Konfiguration und Echtzeitkontrolle des gesamten Netzes. In der Netzwerk-Fabric müssen daher keine Protokolle zur Steuerung von Switching und Routing mehr laufen und Endanwender müssen die Datenschicht nicht mehr verändern, wenn sie neue Applikationen schreiben. Zu ONOS gehört die Plattform nebst einer Reihe von Applikationen, die gemeinsam als erweiterbarer, modularer und verteilter SDN-Controller agieren. Neue Software, Hardware und Services lassen sich einfach verwalten, konfigurieren und bereitstellen. Die Architektur ist resilient und skaliert unbegrenzt.
Zusammengefasst gesagt bündelt ONOS das jeweils beste von Cloud, SDN und NFV. Mit ONOS lassen sich disaggregierte Carrier-Transportnetze, Edge-Anwendungen wie CORD und mandantenfähige Rechenzentrumsnetzwerke realisieren. Eine praktische Umsetzung des Prinzips ist Trellis, eine vollständig auf dem Spine-and-Leaf-Prinzip basierende Datacenter-Netzwerkstruktur mit Multi-Tenant-Overlay, die ausschließlich auf White-Box-Bare-Metal-Hardware aufbaut.
P4 (Programming Protocol-Independent Packet Processors) ist eine domänenspezifische Open-Source-Programmiersprache für Netz-Devices. Sie beschreibt, wie Geräte auf der Datenebene, etwa Switches, Router, NICs und Filter, Pakete verarbeiten. Dabei sind die Programme und Compiler Target-spezifisch. Die Zielhardware kann aus FPGAs, programmierbaren ASICs oder x86-Rechnern bestehen. P4-Programme klassifizieren Pakete anhand ihrer Header und behandeln sie entsprechend.
P4-Compiler erzeugen Metadaten, mit denen die Steuerungs- und Datenschicht über die P4Runtime kommunizieren können. Außerdem erstellen sie eine ausführbare Datei für die Ziel-Datenschicht. In ihr finden sich die Header-Formate und ihnen zugeordnete Aktionen des Target-Systems. PINS (P4 Integrated Network Stack) bezeichnet den gemeinsamen Versuch der IT-Industrie, traditionelle Router SDN-fähig und der P4-Programmierung zugänglich zu machen, die eingebettete Steuerungsprotokolle wie BGP benötigen.
Mininet ist eine Entwicklungs- und Testumgebung für SDN-Netze und -Applikationen. Dieser Ansatz eignet sich für die Arbeit am Laptop. Auf Mininet läuft echter Code, einschließlich Standard-Unix/Linux-Netzwerkanwendungen, der BSD-Linux-Kernel und der Linux-Netzwerkstack. Es gibt eine erweiterbare Python-API für den Netzaufbau und Experimente. Wichtigste Anwendungen sind das schnelle Generieren von SDN-Prototypen, Topologietests ohne vorherigen physischen Netzaufbau und die gemeinsame Arbeit mehrerer Entwickler an derselben Topologie.
Im Projekt ODTN (Open and Disaggregated Transport Network) entstehen Datacenter-Interconnects, die mit disaggregiertem optischem Equipment, nach offenen und verbreiteten Standards und mit Open-Source-Software realisiert werden. Damit lassen sich optische Whitebox-Systeme unterschiedlicher Hersteller in einer Plattform kombinieren. Das erleichtert es Herstellern, sich auf wenige Komponenten zu spezialisieren, was die Kosten senkt.
Das OIMT (Open Information Modeling and Tooling)-Projekt entwickelt offene Informationsmodelle und dazu passende Softwaretools. Es eignet sich zum Entwickeln von Software-definierten Standardplattformen, Frameworks sowie Schnittstellen, die Nutzer benötigen, um SDNs zu steuern, zu managen und zu orchestrieren.
OMEC entwickelt einen mit umfangreichen Funktionen ausgerüsteten, hochleistungsfähigen und skalierbaren Open-Source-EPC (Evolved Packet Core). EPCs verbinden mobile Subscriber mit der Carrier-Infrastruktur und dem Internet. Sie bieten Authentisierung, Roaming, Abrechnung und Sicherheitsfunktionen in Form von untereinander verbundenen Services. OMEC soll dabei helfen, mit der Unzahl neuer Devices fertig zu werden, die durch 5G, IoT und Edge Computing ins Netz gehen.
OTCC (Open Transport Configuration and Control) hat übergreifend einsetzbare Konfigurations- und Steuerungsschnittstellen für SDN-Transportnetzwerke zum Ziel. Dabei werden diese Schnittstellen mit Open-Source-Software und softwaredefinierten Standards geschrieben. Steuern lassen sich die Transporttechnologien der Netzwerkschichten 0 bis 2+, wozu auch optische und Mikrowellen-Technologien gehören.
XOS definiert die höchste Servicesteuerungsebene, die als oberste Schicht auf diversen Backend-Serviceimplementierungen liegt. Dazu gehören VNFs auf virtuellen Maschinen und Microservices in Containern sowie SDN-basierte Steuerungsprogramme, die Funktionen in White-Box-Switches einbetten.
Proprietäre SDN-Technologien fürs Rechenzentrum
Allerdings nutzt längst nicht der gesamte Markt offene Standards. Grade in Firmen-Rechenzentren und -netzen arbeiten häufig proprietäre SDN-Umsetzungen. Zudem gibt es auch hybride Implementierungen, die in Teilen des Netzes SDN, in anderen konventionelle Vernetzungsmechanismen unterstützen.
VMwares NSX ist ein Beispiel für eine proprietäre virtuelle Vernetzung speziell fürs Rechenzentrum. Anbinden lassen sich Netzwerke, Clouds und Anwendungs-Frameworks. Netzwerk- und Sicherheitsfunktionen laufen auf virtuellen Maschinen, Containern oder Bare Metal Servern. Zu den Eigenschaften gehören neben Switching und Routing auch Firewalling, Lastverteilung, VPN, Gateway-Funktionen zur Definition und Verbindung unterschiedlicher virtueller Netze, kontextsensible Mikrosegmentierung, Container-Sicherheit, Multicloud-Betrieb. Weiterhin gehören dazu eine Schnittstelle zum Aufbau des Software Defined Datacenter (SDDC), eine Kommandozeile, automatische Fehlerbehebung im Betrieb und anderes mehr.
Ciscos SDN-Konzept fürs Rechenzentrum heißt ACI (Application-Centric Infrastructure). Derzeit ist die ACI-Version 6 aktuell. ACI gehört zur Nexus-Dashboard Platform for Cloud Networking, die Cloud- und Multicloud-Umgebungen regelgetrieben steuert. Der Cisco Application Policy Infrastructure Controller (APIC) steuert und betreibt als zentrale, clusterbare Appliance eine skalierbare, mandantenfähige ACI-Fabric. Zu seinen Funktionen gehören die Erstellung, Verwaltung und Anwendung von Netzwerkregeln, deklarative, auf einem Datenmodell basierende Provisionierung, Applikations- und Topologiemonitoring einschließlich Fehlerbehebung.
Integrationen gibt es mit Third-Party-Services auf den Schichten 4 bis 7, mit VMware vCenter und vRealize, mit Hyper-V, System Center Virtual Machine Manager und Azure Rack, mit Open vSwitch, OpenStack und Kubernetes. Der Ansatz liefert ein Verzeichnis der ACI-Komponenten und ihrer Konfiguration und erlaubt die Implementierung eines verteilten Frameworks über einen Appliance-Cluster hinweg. Außerdem managt ACI die Images von Spine-and-Leaf-Netzwerken. Die Funktionsfähigkeit von Netzwerkkunden, Applikationen, Switches und anderen Komponenten wird wie Fehler, Ereignisse und Leistung überwacht. Version 6 hat unter anderem die Skalierbarkeit und zeitgebundene Funktionen verbessert.
Zweite wichtige Komponente von ACI-Infrastrukturen sind Switche der Nexus-9000-Serie, mit denen sich Spine-and-Leaf-Infrastrukturen aufbauen lassen. Die Geräte skalieren von 1-GBit/s- bis inzwischen 800-GBit/s-Ethernet. Sie sind entweder für Kompatibilität mit NX-Switchen früherer Generationen oder für ACI-Umgebungen konfigurierbar. Unterschiedliche ACI-Netzwerke (Pods) lassen sich in einem ACI Multi Pod, einem ebenfalls APIC-gesteuerten überlagerten Netz, zusammenfassen.
Microsoft nennt seine Variante des SDN VNET und erlaubt die Konfiguration von SDNs in Azure-Umgebungen mit Azure Stack HCI oder unter Windows Server 2022 und 2019. Laut Microsoft sind Elemente eines virtuellen Microsoft-Netzwerks wie der virtuelle Hyper-V-Switch, die Hyper-V-Netzwerkvirtualisierung, die Loadbalancing-Funktion, der Netzwerkcontroller und das RAS-Gateway von vorn herein als SDN-Elemente konzipiert.
SDNs lassen sich über den Azure-Netzwerkcontroller, -Lastverteilung oder -Gateway bereitstellen. Anwender können dabei wählen, welche der Komponenten sie verwenden.
Der Netzwerkcontroller ist der zentrale, programmierbare Automatisierungspunkt für die gesamte Verwaltung und Konfiguration des VNET. Er übernimmt zum Beispiel die Mikrosegmentierung von VLANs und die QOS-Konfiguration. Implementieren lässt er sich entweder mit SDN-Express-PowerShell-Skripten oder über das Windows Admin Center. Der Software-Loadbalancer nutzt das Border Gateway Protocol (BGP) zur Vermittlung von virtuellen IP-Adressen ans physische Netz. Das Gateway vernetzt sicher SDNs und externe Kundennetze über das Internet und verwendet ebenfalls BGP.
Aristas SDN-Variante Converged Cloud Fabric (CCF) soll ein cloudähnliches Arbeitsgefühl in der gesamten Netzwerkinfrastruktur eines Unternehmens ermöglichen. Das Konzept sieht drei Ebenen vor: Auf der untersten Infrastrukturebene befinden sich die Anwendungen und Daten auf VMs, in Containern oder auf Bare-Metal-Maschinen. Darüber liegt die Switching-Infrastruktur mit offenen Switches.
Für seine Switches hat Arista mit Switch Light ein eigenes Betriebssystem für das SDN maßgeschneidert. Darüber liegt Aristas SDN-Controller, hier als CCF-Controller bezeichnet. Er hat offene Schnittstellen zu diversen Private-Cloud-Plattformen wie VMware, Nutanix, VxRail, Kubernetes, OpenStack und Microsoft. Der CCF-Controller dient als zentraler und hierarchisch implementierter Kontrollpunkt und wird in Form eines Paares hochverfügbarer Hardware-Appliances bereitgestellt.
Fazit
Mit der Ausbreitung von 5G und IoT werden sich SDN-Technologien noch stärker im Markt etablieren. Die neuen Projekte der ONF erlauben einen Blick in die 5G-Netzwerkzukunft, die sehr wahrscheinlich weitgehend softwarebasiert und unabhängig von proprietärer Hardware sein wird. Auch in der Industrie verbreitet sich SDN-Technologie, allerdings haben hier oft proprietäre Varianten gute Chancen, weil die Anbieter bereits vertraut sind.
(ln)