Suchen

Software-Defined Networking im Carrier-Einsatz SDN-Power für Service Provider: Offenheit auf allen Ebenen

| Autor / Redakteur: Eugen Gebhard / Dipl.-Ing. (FH) Andreas Donner

Das Thema Software Defined Networking (SDN) erfährt aktuell in der Netzwerkbranche viel Aufmerksamkeit. Allerdings ist häufig nicht ganz klar, was SDN in den verschiedenen Kontexten bedeutet, denn SDN ist kein Universalkonzept. Dennoch eignet sich der Ansatz für weit mehr als nur das Rechenzentrum.

Firma zum Thema

SDN wird zunehmend auch für Service-Provider interessant.
SDN wird zunehmend auch für Service-Provider interessant.
(Bild: Ciena)

Die erheblichen Unterschiede zwischen Anwendungszenarien, wie dem Einsatz in Rechenzentren, universitären Einrichtungen oder WANs von Unternehmen und Service Providern, treten bei SDN besonders deutlich hervor. Hat bislang der Einsatz im Rechenzentrum die Diskussion dominiert, wird SDN für Service-Provider-WANs aktuell immer mehr zum Thema.

Die Offenheit der Lösungen ist dabei der entscheidende Faktor. Mit SDN werden Innovationen möglich, da das Netzverhalten stärker von Software bestimmt wird und diese relativ leicht und schnell verändert werden kann. Allerdings ist der Einsatz von Software, die genauso geschlossen ist (proprietäre Software) wie die aktuellen hardwarebasierten Systeme wenig sinnvoll. Dies gerät leicht in Vergessenheit, da sich Diskussionen zur Rolle der Software auf die Control Plane und andere technologische Details konzentrieren. Insbesondere für Service Provider, die sehr große WANs mit vielen Kunden in verschiedenen Service-Frameworks betreiben, sind Offenheit und Flexibilität für SDN zwingend erforderlich.

Bildergalerie

SDN-Ebenen und -Schnittstellen aus der Perspektive des Service Providers

In einem grundlegenden Whitepaper hat die Open Networking Foundation (ONF) eine beispielhafte SDN-Architektur skizziert, die aus drei horizontalen Ebenen aufgebaut ist (siehe Abbildung 1). Die Anwendungs- und Steuerungsebene sind Softwareebenen, darunter folgt die Infrastrukturebene. Dazwischen liegen offene, programmierbare APIs (Application Programming Interfaces).

Bei der Definition von Anwendungs- und Steuerungsebene gibt es jedoch unterschiedliche Ansätze, die sich nach dem Bedarf des Netzbetreibers richten.

Handelt es sich beispielsweise um ein firmeneigenes Rechenzentrum ist nur eine einzige Netzdomäne betroffen. Das Netz stellt eine begrenzte Zahl von Anwendungen bereit und wird von der hauseigenen Firmen-IT betreut. Ziel ist es, die Kosten so gering wie möglich zu halten, da es nicht aktiv zum Firmenumsatz beiträgt. In diesem Fall ist die Steuerungsebene möglichst einfach zu halten. Sie soll gerade so viel Funktionalität bieten, dass die Entwickler das Netz – im benötigten Rahmen – relativ frei programmieren können. Ähnlich sieht es auch auf der Anwendungsebene aus: Sie besteht aus Softwaremodulen und/oder Softwarefunktionen zur Verbindung mit dem physikalischen Netz.

Netzbetreiber stehen hingegen vor gänzlich anderen, wesentlich komplexeren Anforderungen, die sie für den Einsatz von SDN prädestinieren. So arbeiten sie mit Mehrebenen-Übertragungs- und Paketnetzen sowie mehreren Netzdomänen, die große geographische Gebiete abdecken. Diese Komplexität verursacht erheblichen administrativen Aufwand, stellt dabei aber auch eine wichtige, manchmal sogar die einzige Umsatzquelle dar.

Ferner unterstützen die Netze sowohl mehrere Service-Frameworks, die ständig weiterentwickelt werden, als auch eine Vielzahl von Kunden für jeden einzelnen Service. In diesem Szenario unterscheidet sich die Sicht auf Anwendungs- und Steuerungsebene in der SDN-Architektur deutlich vom vorhergehenden Beispiel.

„Anwendungen“ im Kontext des Service Providers sind kundenorientierte, umsatzgenerierende Service-Anwendungen, welche Netzdienste nutzen, die typischerweise nur teilweise hierdurch definiert werden. SDN ermöglicht die Übertragung solcher Anwendungen von einer Netzplattform auf eine andere und garantiert somit auch bei Weiterentwicklungen der Netzplattformen stabile Dienste. Zudem ist die WAN-Infrastruktur der Service Provider geprägt durch eine komplexere Equipment-Ebene als andernorts, da sie in der Regel mehrere, sich verändernde Netzdomänen über Netzebenen hinweg umfasst. Dieser Tatsache muss in der Steuerungsebene Rechnung getragen werden und resultiert in einer umfangreichen Netzsteuerung mit einer Vielzahl an Funktionen.

Offenheit „Richtung Süden“ ermöglicht Differenzierung gegenüber Mitbewerbern

Eine solche Steuerungsebene, basierend auf SDN, hat ebenso wie die Anwendungsebene das Potenzial zur Differenzierung gegenüber dem Wettbewerb. Beispielsweise sollte es für einzelne Service Provider möglich sein, innovative Netzoptimierung zu betreiben, um konsistent auch sehr hohe Anforderungen von Service-Anwendungen mit möglichst wenigen Infrastruktur-Ressourcen zu erfüllen und damit Kosten zu senken.

Hierzu benötigt der Service Provider Zugriff auf die Steuerungsebene. Voraussetzung sind bestimmte Charakteristika, aber auch Offenheit zwischen Steuerungs- und Infrastrukturebene, die anderenfalls nicht unabhängig voneinander verändert werden können. Softwaregetriebene Netzkonzepte, die die Steuerungsebene fest mit physischen Netzen verbinden, machen das unmöglich und dienen letztlich nur den Interessen der Anbieter und nicht der Provider. Daher ist die OpenFlow-Technologie zwar ein guter Start, reicht jedoch nicht aus, da Transportnetze nicht abgedeckt werden (siehe Abbildung 2).

Offenheit „Richtung Norden“ setzt abstrahierte Kommunikation voraus

Andererseits setzt die Schnittstelle zwischen Anwendungs- und Steuerungsebene voraus, dass die Anwendungsebene „weiß“, was sie vom Netz benötigt – was, wann und für wen – und entsprechend anfordert, jedoch nicht spezifiziert, wie diese Anforderungen erfüllt werden sollen.

Die Steuerungsebene hingegen übernimmt vollständige Verantwortung für die Aktualisierung der Netzressourcen und damit verbundene Funktionen, wie die Sicherung der Ressourceneffizienz. Allerdings hat sie nichts damit zu tun, wann und von wem die Netzdienste benötigt werden.

Die Kommunikation zwischen Anwendungs- und Steuerungsebene muss entsprechend abstrakt und kompakt erfolgen: „Verbinde diese Netzknoten – physisch oder virtuell – und/oder Datenflüsse zu diesen Zeiten möglichst für nicht mehr als einen festgelegten Preis anhand von über Parameter definierte Verbindungsattribute wie Bandbreite, Verzögerungszeit, Qualität und Verfügbarkeit.“

Offenheit: Top-down

Für die Netzsteuerung von Service Providern bedeutet dies eine ganz neue Herangehensweise. Häufig sind hier vertikal integrierte und weitgehend isolierte Service-Frameworks und -Systeme im Einsatz, die über Netzsteuerungssysteme mit – häufig anbieterspezifischen – physischen Netzen verbunden sind. Ebenen und Technologien haben spezifische Eigenheiten, die die Portabilität von Komponentensoftware beschränken. Die Grenzen zwischen Kundeninteraktion, umsatzgenerierenden Servicekomponenten und Netzsteuerung sind fließend.

In diesem Fall ist das gesamte Netz keine echte Plattform. Es fehlt die Kommunikation zwischen Anwendungs- und Steuerungsebene, die aber eine entscheidende Anforderung an SDN-Steuerungssysteme für Service Provider ist. Entsprechende Service-Module sollten daher sowohl mit Paket- als auch mit optischen Transportnetzen (OTN) (Netzebenen 1 und 0) sowie der jeweiligen Control-Plane-Lösung zusammenarbeiten. Denn erst diese Kopplung ermöglicht die Infrastruktur-Virtualisierung im WAN sowie die dynamische, direkte Software-zu-Software-Verbindung mit Systemen der Anwendungsebene. Eine Integration dieses Konzeptes in das aktuelle Netz und die Back-Office-Software des Service Providers ermöglicht es mit einer anfänglich minimalen Veränderung der vorhandenen Netzumgebung, die Voraussetzungen für den Umstieg zu einer umfassenden und wertschöpfenden SDN-Architektur zu schaffen.

Zudem sollte dieser Ansatz Funktionen der Steuerungsebene (Control Plane) nutzen, um aktuelle und zukünftig verfügbare Netzverbindungsressourcen zu behalten und deren aktuelle und voraussichtliche Ressourcenzuweisungen im Blick zu haben. Diese Ressourcen können einer Anwendungssoftware intelligent und dynamisch zugewiesen werden, während die Integrität über alle Anwendungssysteme und Serviceprozesse kontinuierlich sichergestellt wird. Die Serviceanfrage wird über die oben beschriebene API übertragen und nutzt eine virtualisierte Sicht auf das Netz des Service Providers.

Offenheit: Bottom-up

Die Offenheit von der Anwendungs- zur Steuerungsebene ist jedoch noch nicht alles. Insbesondere in einer Service-Provider-Umgebung benötigt „richtige“ Offenheit eine genauere Kontrolle. Die richtige Offenheit zwischen Steuerungs- und Infrastrukturebene ist genauso wichtig wie die Offenheit zur Anwendungsebene. Daher muss die Infrastruktur auf Paketebene programmierbar sein. Für Service Provider ist jedoch zusätzlich die offene Programmierbarkeit von Transportnetzen wichtig. Multi-Layer-Netze sind in der Welt der Service Provider an der Tagesordnung und ihr effizienterer Betrieb wird für sie eine der großen Herausforderungen bei WAN-SDN bleiben. Aus den oben genannten Gründen steht „Transport SDN“ ganz oben auf der Liste der aktuellen Themen innerhalb der neu formierten Transport-Arbeitsgruppe des ONF.

Eugen Gebhard
Eugen Gebhard
(Bild: Ciena)

Über den Autor

Eugen Gebhard ist Managing Director Central Europe bei Ciena

Veranstaltungshinweis

Diskutieren Sie das Thema SDN mit Ciena auf dem SDN & OpenFlow World Congress vom 15. bis 17. Oktober 2013 in Bad Homburg bei Frankfurt. Mehr Informationen unter http://www.layer123.com/sdn.

(ID:39948640)