WLAN-Infrastrukturen ohne zentralen Controller

Eine Frage der Architektur

19. Juli 2012, 6:00 Uhr | Georg Weltmaier/pf, Senior Sales Engineer bei Aerohive.

Wireless LAN entwickelt sich mehr und mehr zur primären Zugangstechnik zu Unternehmensnetzen. Dies erhöht die Anforderungen an Zuverlässigkeit, Skalierbarkeit und Sicherheit. Die Bereitstellung geschäftskritischer Anwendungen, die Einbindung von unternehmensfremden Nutzern sowie Entwicklungen wie BYOD ("Bring Your Own Device") erfordern neue Herangehensweisen an den Aufbau des WLANs. Bei der Beurteilung einer WLAN-Technik sollte der Planer das Hauptaugenmerk auf die Betrachtung der Control-, der Forwarding- und der Management-Ebene richten. Die Notwendigkeit, Traffic auf der Kontrollebene zu beherrschen, bildet die Basis, auf der viele WLAN-Hersteller während der letzten Dekade ihre grundlegende Architektur aufbauten. Generell beinhaltet der Traffic auf der Kontrollebene alles, was notwendig ist, um die Funktionsfähigkeit in einem koordinierten Multi-Access-Point-(AP-)Netzwerk zu gewährleisten. Diese Daten lassen sich auch als "Signalisierung" des Netzwerks ansehen. Pakete der Kontrollebene dienen der Steuerung des WLAN Equipments.

Zentralisierte WLAN Controller

Bereits 2001 führten einige Hersteller das Konzept der zentralisierten WLAN Controller ein, um den Datenverkehr auf der Kontrollebene zu bewerkstelligen. Aufgrund der damals verfügbaren Prozessorleistung handelte es sich dabei mehr um eine wirtschaftliche Entscheidung. APs mit der für verteilte Strukturen erforderlichen Rechenleistung wären einfach zu teuer gewesen.

Zehn Jahre der Entwicklung haben zu leistungsfähigeren und exponentiell billigeren Prozessoren geführt, sodass es heute möglich ist, Control Plane Processing in einem verteilten Modell zu realisieren. In diesem wird die Kontrollinformation einschließlich Link- und User-Status von AP zu AP weitergeleitet, ohne dass dazu ein zentraler Controller erforderlich wäre.

Beim Datenverkehr der Forwarding-Ebene wiederum handelt es sich um die Nutzdaten, die über das WLAN zu transportieren sind. Die Datenebene ist zwar generell verteilt, in einer zentralisierten Architektur trifft aber dennoch der zentralen Controller viele Policy-Entscheidungen. Deshalb muss die Datenebene oft durch die Controller laufen, um die Policies einschließlich QoS, Deep Packet Inspection, Flow-Klassifizierung etc. durchzusetzen.

Der Datenverkehr der Management-Ebene letztlich überträgt den Betriebs- und Administrations-Traffic, der für das Netzwerk-Management erforderlich ist. In einer verteilten Umgebung, in der viele Geräte zu betreiben sind, muss das Management zentralisiert sein, um einfache und konsistente Policy-Durchsetzung zu ermöglichen. Der Traffic auf der Management-Ebene hat keinen funktionalen Einfluss auf den Echtzeitbetrieb des Netzwerks.

Limitierungen zentraler Controller

Diese drei Ebenen des WLAN-Traffics haben im Lauf der Zeit verschiedene Architekturen hervorgebracht, nämlich den zentralen Controller mit zentraler Forwarding-Ebene, den zentralen Controller mit verteilter Forwarding-Ebene sowie verteilte Kontrolle mit verteiltem Forwarding. Das Konzept des zentralen Controllers resultierte letztlich aus dem Mangel an ausreichender und bezahlbarer Prozessorleistung, um sowohl Kontroll- als auch Datenfunktionen auf dem AP zu realisieren. Zentralisierte Controller wurden entwickelt, weil sie ein Weg waren, eine Balance zwischen Kosten und Prozessorleistung zu finden. Die inhärenten Limitierungen eines zentralen Controller-Modells - wie Kosten, Latenz und Single Point of Failure - sind jedoch in Anbetracht heutiger Anforderungen wie BYOD, Highspeed-WLAN-Anbindung und kostengünstiger Endgeräte zunehmend offensichtlich.

WLAN Controller arbeitet in der Cloud

Einige Hersteller von Systemen mit zentralen Controllern haben Modelle entwickelt, die Funktionen kostengünstiger bereitzustellen. Eine Methode für ein verschleiertes Controller-Modell besteht darin, diesen in die Cloud zu stellen. Dabei ist es nicht notwendig, den Controller in einem Rechenzentrum zu installieren oder eine physische Hardware zu verwalten. Controller-Pakete, die für Funktionen wie Roaming oder Session-States zwischen APs und Subnetzen verantwortlich sind, lassen sich mittels Internet-Verbindung über die Cloud senden. Diese Lösung minimiert zwar den Aufbau einer Controller-basierenden Architektur, löst aber nicht das Problem der Ausfallsicherheit und Skalierbarkeit. Jede Störung bei der Datenübertragung zum Controller kann die gesamte Leistung des WLANs beeinflussen.

In dem genannten Modell läuft der lokale Traffic (zum Beispiel die Datenübertragung von und zu einer lokalen Ressource) zwar direkt zwischen den APs und nicht über den Controller. Aber dies ändert nichts an der grundsätzlichen Architektur, die weiterhin auf einem zentralen Controller zur Bearbeitung der Funktionen der Kontrollebene beruht. Einige davon, die in einem verteilten Forwarding-Modell nach wie vor der zentrale Controller zur Verfügung stellt, können etwa Policy Enforcement, Authentifizierung, Deep Packet Inspection oder Quality of Service sein.

Verteiltes Kontroll- und Übertragungsmodell

Eine weitergehende Architektur nutzt die Vorteile der raschen Zunahme von Prozessorleistung, um sowohl die Datenebene als auch die Funktionen der Kontrollebene auf die Access Points zu laden und damit den zentralen Controller komplett zu eliminieren. Die resultierende Architektur ähnelt mehr dem Internet - ohne dedizierten Point of Failure und mit einer vollständig verteilten Kontrollebene, die die Kommunikation mit Protokollen koordiniert.

Wenn ein Problem auftritt, können die APs dieses dynamisch umgehen und so den Status und den Betrieb des Netzwerks aufrechterhalten. Dies macht eine solche Architektur extrem robust und flexibel. Gleichzeitig bleibt sie kostengünstig, weil außer den Access Points kein zusätzliches Equipment erforderlich ist. Ein WLAN mit verteilter Kontrolle und Intelligenz arbeitet eher wie ein Grid-Computer. Es kann ein extrem hohes Volumen an Kontroll- und Policy-Entscheidungen verarbeiten, ohne alle Daten an ein separates Geräte weiterleiten zu müssen. Da diese Entscheidungen schon beim Zugang in das Netzwerk am Access Point erfolgen, erhöht sich die gesamte Netzwerk-Performance und echte Quality of Service ist möglich.

Das Management hingegen muss zentralisiert sein, um einfache und konsistente Darstellungen des Netzwerkbetriebs für eine effizientere Problemlösung und minimale Service-Unterbrechungen zu ermöglichen. Da ein zentrales Management allerdings - anders als ein Controller - keine essentiellen Funktionen für den Betrieb des WLANs zur Verfügung stellt, ist dafür nicht zwingend eine dedizierte Hardware erforderlich. Das Management-Device kann durchaus in der Cloud stehen und dennoch alle Management-relevanten Funktionen zur Verfügung stellen.

Fazit

Einige Hersteller haben die Vorzüge der kostengünstigen Prozessorleistung genutzt, um auch die Kontrollinformationen direkt zwischen APs zu übertragen. Dieser Ansatz ermöglicht die Unterstützung von Clients mit hoher Leistung, verteilt die Datenverarbeitung für höhere Kapazitäten, bietet Zukunftssicherheit für das Netzwerk und stellt das vollständige Funktionsspektrum ohne Single Point of Failure bereit.

So genannte Hive-(Schwarm-)basierende WLAN-Architekturen arbeiten nach dem Prinzip der verteilten Intelligenz und kommen daher ohne zentralen WLAN Controller aus. Bild: Aerohive
LANline.

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Avery Zweckform

Weitere Artikel zu K&P Computer

Matchmaker+