Die ideale SDN-Architektur für Service-Provider

SDN bietet mehr Flexibilität. Für Service-Provider ist eine offene SDN-Architektur die richtige Lösung, meint Experte Eugen Gebhard.

Image goes hereEugen Gebhard

Derzeit erfährt das Thema Software Defined Networking (SDN) große Aufmerksamkeit in der Netzwerkbranche. Stand bisher der Einsatz im Data Center im Vordergrund, entdecken inzwischen immer mehr Service-Provider die Vorteile von SDN für ihre WANs (Wide Area Networks). Doch wie müsste eine SDN-Architektur idealerweise in der Welt der Service-Provider aussehen?

Mit SDN können produktive Innovationen verwirklicht werden, da das Netzverhalten stärker von Software bestimmt wird. Software ist außerdem leichter zugänglich und kann schneller und einfacher verändert werden, wenn etwa ein neuer Service bereitgestellt werden muss. Um diese Vorteile zu nutzen, ist jedoch die Offenheit der Lösungen ein entscheidender Faktor. Vor allem für Service-Provider mit ihren großen WANs mit vielen Kunden in unterschiedlichen Service-Frameworks sind transparente Durchgängigkeit und Flexibilität zwischen den einzelnen Ebenen einer Lösung unverzichtbar. Daher ist es wenig sinnvoll, proprietäre Software einzusetzen, die ebenso geschlossen ist, wie die aktuellen hardwarebasierten Systeme.

Wie sollte eine SDN-Architektur aussehen?

Eine SDN-Architektur hat die Open Networking Foundation (ONF) kürzlich in einem grundlegenden Whitepaper „Software-Defined Networking: The New Norm for Networks“ aufgezeigt (Abbildung 1). Sie besteht aus drei horizontalen Ebenen, der Anwendungs- und Steuerungsebene, die als Softwareebenen konzipiert sind, gefolgt von der Equipment-Ebene als Basis. An den Schnittstellen zwischen den Ebenen sind programmierbare, offene APIs (Application Programming Interfaces) platziert.

Abbildung 1: SDN-Architekturdiagramm: drei Ebenen mit zwei offenen Schnittstellen (Quelle: Ciena)

Service-Provider sind mit ihren komplexen Anforderungen für den Einsatz von SDN prädestiniert. Sie setzen Multi-Layer-Übertragungs- und Paketnetze ein und arbeiten mit mehreren Netzdomänen, die große geographische Gebiete überspannen. Unterstützt werden jeweils mehrere Service-Frameworks, die ständig weiterentwickelt werden, sowie zahlreiche Kunden pro Service. Diese aufwendige Struktur erfordert hohen administrativen Aufwand, stellt häufig aber auch eine wichtige, wenn nicht manchmal sogar die einzige Umsatzquelle dar.

Die Anwendungsebene hat für den Service-Provider mithin eine hohe Bedeutung, da „Anwendungen“ aus seiner Perspektive kundenorientierte, umsatzgenerierende Service-Anwendungen sind, die Netzdienste nutzen, typischerweise jedoch nur teilweise durch sie definiert werden. Diese Anwendungen können in einer SDN-Lösung von einer Netzplattform auf eine andere übertragen werden, wobei auch bei Weiterentwicklungen der Plattform stabile Dienste gewährleistet sind. Die zugrundeliegende Equipment-Ebene im WAN des Service-Providers ist in der Regel sehr komplex, da sie mehrere, sich verändernde Netzdomänen über mehrere Ebenen hinweg abdecken muss. Entsprechend muss auch die Steuerungsebene relativ komplex sein und die Netzsteuerung mit zahlreichen Funktionen vollständig übernehmen.

Differenzierung gegenüber Mitbewerbern über offene „Southbound“-Verbindung

Ebenso wie die Anwendungsebene bietet eine solche Steuerungsebene dem Anbieter die Möglichkeit zur Differenzierung gegenüber Mitbewerbern. Zum Beispiel könnten Service-Provider Funktionen für die Netzoptimierung nutzen, um durch die konsistente Erfüllung auch sehr hoher Anforderungen von Service-Anwendungen mit möglichst wenigen Equipment-Ressourcen die eigenen Kosten zu senken.

Voraussetzung dafür ist der Zugriff auf die Steuerungsebene durch den Service-Provider. Neben bestimmten Charakteristika hängt dies ebenfalls von der Offenheit zwischen der Steuerungs- und Equipment-Ebene ab, da es erforderlich ist, diese unabhängig voneinander verändern zu können. Als ungeeignet haben sich daher softwaregetriebene Netzkonzepte erwiesen, die die Steuerungsebene fest mit physischen Netzen verbinden. Letzten Endes profitiert davon nur der Anbieter und nicht der Provider. Die OpenFlow-Technologie ist insofern ein guter Ansatzpunkt, erfüllt jedoch letzten Endes nicht die Anforderungen, da Transportnetze nicht eingeschlossen sind (Abbildung 2).

Abbildung 2: Beispiel eines Service-Moduls für Performance-on-Demand: V-WAN Network von Ciena in einem Multi-Ebenen-Cloud-Backbone-Netz (Quelle: Ciena)

Abstrahierte Kommunikation ermöglicht „Northbound“-Offenheit

Die offene Schnittstelle zwischen Anwendungs- und Steuerungsebene setzt auf der anderen Seite voraus, dass die Anwendungsebene von sich aus erkennt, was sie wann und für wen vom Netz benötigt und dies entsprechend anfordert. Dabei muss sie allerdings nicht festlegen, auf welche Weise diese Anforderungen erledigt werden sollen.

Die Aktualisierung der Netzressourcen und damit verbundener Funktionen, wie die Sicherung der Ressourceneffizienz, übernimmt die Steuerungsebene. Im Gegenzug hat sie jedoch nichts damit zu tun, wann und von wem die Netzdienste benötigt werden.

Voraussetzung hierfür ist, dass die Kommunikation zwischen Anwendungs- und Steuerungsebene abstrakt und reduziert abläuft. Es wird lediglich festgelegt, dass definierte Netzknoten – physisch oder virtuell – und/oder Datenflüsse zu bestimmten Zeiten möglichst für nicht mehr als einen festgelegten Preis anhand von Verbindungsattributen verbunden werden, die über Parameter – wie Bandbreite, Verzögerungszeit, Qualität und Verfügbarkeit – definiert werden.

Neuorganisation der Netzsteuerung erforderlich

Service-Provider müssen vor diesem Hintergrund ihre Netzsteuerung effektiver organisieren. Bislang kommen hier meist vertikal integrierte und weitgehend isolierte Service-Frameworks und -Systeme zum Einsatz, die über entsprechende Steuerungssysteme mit physischen Netzen verbunden sind, die zudem häufig anbieterspezifisch sind. Die Portabilität von Komponentensoftware ist dabei aufgrund der spezifischen Eigenheiten der Ebenen und Technologien meist sehr eingeschränkt und zwischen Kundeninteraktionen, umsatzgenerierenden Service-Komponenten und Netzsteuerung existiert keine deutliche Abgrenzung. Das gesamte Netz ist in diesem Fall im Grunde keine echte Plattform, da die Kommunikation zwischen Anwendungs- und Steuerungsebene fehlt und damit eine wichtige Anforderung an SDN-Steuerungssysteme für Service-Provider nicht erfüllt ist.

Wichtig wäre daher, dass entsprechende Service-Module sowohl mit Paket- als auch mit optischen Transportnetzen (OTN) (Netzebenen 1 und 0) und der jeweiligen Control-Plane-Lösung (der Lösung auf der Steuerungsebene) zusammenarbeiten. Diese Kopplung ist die Voraussetzung für die Virtualisierung der gesamten Infrastruktur im WAN sowie die dynamische, direkte Software-zu-Software-Verbindung mit Systemen der Anwendungsebene. Wird dieses Konzept in das aktuelle Netz und die Back-Office-Software des Service-Providers integriert, kann dieser mit einer zu Beginn minimalen Veränderung der vorhandenen Netzumgebung die Voraussetzungen für den Umstieg zu einer umfassenden und wertschöpfenden SDN-Architektur verwirklichen.

Weiterhin ist wichtig, dass Managementfunktionen der Steuerungsebene genutzt werden, um aktuelle und zukünftig verfügbare beziehungsweise mögliche Netzverbindungsressourcen sowie deren aktuelle und voraussichtliche Ressourcenzuweisungen im Blick zu haben. Diese Ressourcen können intelligent und dynamisch anfragender Anwendungssoftware zugewiesen werden, während die Integrität der Zuweisungen an andere Anwendungssysteme und Serviceprozesse sichergestellt ist. Die Service-Anfrage wird über eine der offenen APIs übertragen und basiert auf einer virtualisierten Sicht auf das Netz des Service-Providers.

Stärkere Kontrolle wichtig

Offenheit zwischen Anwendungs- und Steuerungsebene reicht jedoch noch nicht ganz. Vielmehr ist insbesondere in einer Service-Provider-Umgebung genauere Kontrolle erforderlich, um die „richtige“ Offenheit zu erreichen. Das heißt, Durchgängigkeit zwischen Steuerungs- und Equipment-Ebene ist ebenso wichtig wie Offenheit nach oben zur Anwendungsebene. Eine Voraussetzung hierfür ist, dass die Infrastruktur auf Paketebene programmierbar ist. Allerdings ist für Service-Provider zusätzlich wichtig, dass auch die Transportnetze offen programmiert werden können. In der Regel arbeiten die Provider mit Multi-Layer-Netzen und deren effizienterer Betrieb wird auch weiterhin eine der großen Herausforderungen bei WAN-SDN bleiben. Das Thema „Transport SDN“ ist daher nicht von ungefähr einer der Hauptpunkte auf der Agenda der neu gegründeten Transport-Arbeitsgruppe des ONF.

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.

Über den Autor: Eugen Gebhard ist Managing Director Central Europe bei Ciena und damit für das Geschäft in der DACH-Region zuständig. Seit mehr als zehn Jahren ist er in der Branche unterwegs und war unter anderem für Nortel tätig.

Artikel wurde zuletzt im Juli 2013 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Netzwerk-Design

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close