Die Trennung von Steuer-und Datenweiterleitungsschicht, (eine der zentralen Säulen SDN mit Zentralisierung der Steuerungsschicht) bedeutet, dass es einen Bedarf für Kommunikationsprotokolle gibt. In diesem Abschnitt stellen wir einige von ihnen vor, beginnend mit dem beliebtesten - Openflow.
OpenFlow ist ein offener Standard der ursprünglich an Universitäten entwickelt und derzeit von Open Network Foundation (ONF) [9] entwickelt wird - eine Non-Profit-Konsortium mit der Mission, OpenFlow basierte SDN zu vermarkten und zu unterstützen. ONF ist sehr spektakulär und erfolgreich. OpenFlow ist das beliebteste Protokoll für die Kommunikation zwischen Steuerungsschicht und Datenweiterleitungsschicht – es ist ein de facto Standard. Doch die ONF-Kampagne führte oft zu der falschen Annahme, dass Openflow gleich bedeutend mit SDN ist.
Trotz bestehender Software-basierter Switching-Lösungen, die eine Erforschung neuer Methoden und Netzwerkprotokolle ermöglichen, bieten die meisten Lösungen keine ausreichende Rechenleistung und/oder Portanzahl für Großversuche an.
Die einfachsten Beispiele sind viele offene Software-basierte Implementierungen von Routing- oder Vermittlungsprotokollen die auf Universalrechnern mit mehreren Netzwerkschnittstellen laufen. Diese Techniken können in der ersten Gruppe kategorisiert werden. Dazu gehören die fehlende Leistung der Techniken, im Vergleich zu dedizierten Netzwerkausrüstungen. Am anderen Ende des Spektrums sind Hardware-basierte Netzwerkforschungs-Lösungen wie NetFPGA, die eine spezialisierte FPGA-Karte für die Line-Rate-Verarbeitung des Datenfluss benutzt.
NetFPGA wird vor allem in der Wissenschaft und beim Rapid-Prototyping verwendet, da es ein Limit von 4 Ports pro Karte gibt.
Wie in [10] erwähnt, sind dies limitierende Faktoren für die akademischen Forscher. OpenFlow ist ein Kompromiss zwischen allgemeinen, leistungsschwachen Lösungen der freien Forschung auf der einen Seite und geschlossenem, nur zum Teil modifizierbarem High-Performance-Netzwerk-Equipment kommerzieller Anbieter auf der anderen Seite.
Das OpenFlow-Protokoll definiert die Kommunikationsschnittstelle zwischen Steuerungsschicht und Datenweiterleitungsebene und muss daher von beiden Seiten implementiert werden. OpenFlow bietet eine extrem genaue Kontrolle auf Per-Flow-Basis und ermöglicht es, auf die Netzwerktopologie-, Anwendungs- oder Benutzeränderungen in Echtzeit zu reagieren.
ONF Whitepaper [9] stellt fest, dass die klassischen Netzwerk-Routing-Lösungen die Kontrolle auf dieser Schicht der Granularität derzeit nicht unterstützen.
Wird ein Paket von OpenFlow-Schaltern empfangen, so wird es in der OpenFlow Pipeline von einem oder mehreren Stromtabellen zusammensetzt uns bearbeitet. Stromtabellen beinhalten Einträge mit Regeln und Aktionen, die für Pakete gelten. Wenn eine Übereinstimmung für das Paket in keiner der Fluss-Tabellen gefunden wird und wird dass unbekannten Pakete an einen Controller geschickt. Der Controller verarbeitet das Paket und entweder verwirft er das Paket oder baut einen neuen Verkehrsfluss, indem er einen neuen Eintrag in der Fluss-Tabelle erstellt. Der Handhabungsmechanismus eines empfangenen Pakets eines OpenFlow-Schalter ist in Abbildung 5 dargestellt.
Das Protokoll Forwarding and Control Element Separation (ForCES) [12] definiert eine Rahmenarchitektur und die zugehörigen Protokolle, um den Informationsaustausch zwischen der Steuerungsschicht und der Weiterleitungsschicht in einem ForCes Netzwerkelement zu standardisieren.
ForCES beschreibt vor allem eine offene API und Protokolle, welches eine klare Trennung der Steuer- und Weiterleitungsschicht erlaubt.
Die große Stärke des ForCES liegt in dem Weiterleitungs-Elementmodel, das die Beschreibung der neuen Weiterleitungsschicht und deren Funktionalität ermöglicht, ohne das Protokoll zwischen Steuerungschicht und Weiterleitungschicht zu wechseln.
Ziel der ForCES-Entwicklung war es, das Netzwerkgerät in separate Steuer- und Weiterleitungschichten aufzuteilen und von Hardware-Komponenten unabhängig zu werden. Daraus entstand ForCES – eine neue Architektur für Netzwerkgeräte, während OpenFlow auf eine neue Netzwerkarchitektur zielt.
NETCONF ist ein Netzwerk-Management-Protokoll, das Mechanismen bietet, die Remote-Installation zu manipulieren und die Konfiguration von Netzwerkgeräten zu löschen.
Das NETCONF-Protokoll selbst ist in vier Schichten mit einer Reihe von Basis-Protokoll- Operationen und verwendet RPC (Remote Procedure Call) Methoden.
Eines der Ziele von NETCONF ist es, eine programmierbare Schnittstelle zum Gerät anzubieten, die die Funktionalität der nativen Schnittstelle des Gerätes abbildet.
Obwohl NETCONF ursprünglich als Nachfolger von SNMP und einige der CLI-Protokolle für die Konfiguration der Netzwerkelemente entwickelt wurde, können NETCONF-Funktionen auch verwendet werden, um eine Form des Hybrid-SDN zu erstellen. Darüber hinaus ist NETCONF-Unterstützung eine Voraussetzung für Netzwerkgeräte, um mit dem OF-CONFIG Teil der OpenFlow-Spezifikation kompatibel zu sein.
Pfadberechnungselement (PCE) ist eine Einheit, die im Auftrag der Knoten, die Pfade berechnet. Das erlaubt die Verwendung optimaler Pfade für die Datenweiterleitung mittels MPLS, GMPLS P2P und P2MP durch Label Switched Pfade (LSPs).
PCE kündigt dann diesen Pfad den Netzwerkknoten mit über ein PCE-Kommunikationsprotokoll an. Dadurch erweitert es MPLS und GMPLS Endgerätfunktionen und verkleinert damit den Unterschied zwischen SDN und Standard-MPLS/GMPLS.
Obwohl PCE nicht in erster Linie als SDN-Schlüsseltechnologie entwickelt wurde, ist es logisch ein zentralisiertes Management-Modell für bestehende Technologien, das ein paar zusätzliche Verbesserungen bereitstellt.
Die Schnittstelle zum Routing System (I2RS) ist eine der anspruchsvolleren Ansätze zur SDN, die von der IETF entwickelt wurde und sich noch in einem frühen Stadium der Entwicklung befindet. Die I2RS ist eine bidirektionalere programmatische Schnittstelle für die Kommunikation zwischen Routingsystem und Anwendungen. Sie ermöglicht Netzwerküberwachung, Reservierung von Ressourcen und die Modifikation von Routing-Konfigurationen. I2RS konzentriert sich auf die Kommunikation zu und von Routing-Systemen. I2RS ist nicht dazu bestimmt direkte Schnittstellen zur Weiterleitungsschicht anzubieten. Die ausgewählten Strecken in die Weiterleitungsschicht zu verteilen ist Aufgabe von bestehenden Mechanismen.
Auch wenn Cisco Teil der Open Networking Foundation ist und sich aktiv an der Entwicklung von OpenFlow beteiligten, ist es nicht das einzige SDN Projekt von Cisco. Einer ihrer proprietären Alternativen ist Open Network Environment (Cisco ONE), die programmatische Schnittstellen bereitstellt, um Cisco-Geräte direkt zu steuern. Schlüsselkomponente der Cisco ONE ist das ONE Platform Kit (onePK) - Entwickler-Kit mit mehreren Plattform-APIs, das eine einfache Entwicklung von Netzwerk-Anwendungen mit direktem Zugang zu Netzwerkkomponenten über die Netzwerkabstraktionsschicht ermöglicht.
Im April 2013 startete Alcatel-Lucent das Spin-out-Unternehmen „Nuage Networks“, mit der Aufgabe eine SDN-Lösung zu erstellen, die zwar auf seiner früheren Anwendung aufbaut, aber auch die Freiheit zur Nutzung alternativer, neuer Technologien bietet. Das Ergebnis dieser Entwicklung ist die „Virtualisiesed Service Plattform“, eine Software-Lösung, die sich auf das Problem der Netzwerkvirtualisierung in Rechenzentren und auf Cloud-Service-Provider (CSPs) konzentriert. Weil Nuage VSP in Software implementiert ist und VXLAN als Kapselung für Hyperviser verwendet, es ist unabhängig von einem bestimmten Typ (oder einer Marke) von TOR-Schaltern.