802.11 Network Structures: Difference between revisions
(38 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== |
=="Traditionelles" 802.11== |
||
IEEE 802.11 fasst Protokolle und Techniken für die Implementation drahtloser Netzwerke zusammen. Es gilt damit als Synonym für Drahtlosnetzwerke, welche im Alltag auch durch die Phrasen "wireless ethernet", "WLAN" oder "Wi-Fi" (geprägt durch die "Wi-Fi Alliance", oder auch wireless fidelity) bezeichnet werden. |
|||
* 802.11 = |
|||
** „wireless ethernet“ |
|||
===IEEE 802.11 als Teil von IEEE 802=== |
|||
** Wi-fi (from Wi-Fi Alliance, wireless fidelity) |
|||
Das Institute of Electronics and Electrical Engineers (IEEE) befasst sich mit der Entwicklung und Standardisierung technischer Spezifikationen zumeist elektonischer Art. Das IEEE gliedert sich dabei in verschiedene Projektgruppen, welche durch eine Zahl ausgezeichnet werden. Im Fall 802.11 gibt 802 dabei die Projektgruppe für die Entwicklung von Local Area Networks (LAN) an. Diese unterteilt sich wiederum in verschiedene Arbeitsgruppen, wobei die Arbeitsgruppe 11 der genannten Projektgruppe ihren Fokus auf die Entwicklung von Standards für drahtlose Netzwerke legt. |
|||
Die ersten Ergebnisse der Arbeitsgruppe lagen '97 mit der Spezifikation unter dem Namen 802.11-1997 vor. Es folgten 802.11-1999 mit nur wenigen Änderungen und 802.11-2003, welches die aktuellste Revision darstellt. |
|||
Innerhalb der Arbeitsgruppe gibt es dann weitere Fraktionen (sogenannte task groups), die sich mit einzelnen Aspekten der Technik der Drahtlosnetzwerke befassen. |
|||
die 802.11 Task Groups: |
|||
===IEEE 802.11 as part of IEEE 802=== |
|||
* IEEE 802.11x = |
|||
** IEEE = Institute of Electronics and Electrical Engineers |
|||
** 802 = project group (Entwicklung von LAN-Standards) |
|||
** 11 = working group (Entwicklung eines wireless-LAN Standards) |
|||
** x = task groups |
|||
* erstmalige Spezifikation 1997, Änderungen 802.11-1999, 802.11-2003 |
|||
* the 802.11 Task Groups: |
|||
{| border="1" |
{| border="1" |
||
| 802.11 || First standard (1997). Specified the MAC and the original slower frequency-hopping and direct-sequence modulation techniques. |
| 802.11 || First standard (1997). Specified the MAC and the original slower frequency-hopping and direct-sequence modulation techniques. |
||
Line 53: | Line 53: | ||
|} |
|} |
||
* Beziehung von 802.11 zum ISO/OSI-Modell: |
|||
===Beziehung von 802.11 zum ISO/OSI-Modell=== |
|||
Die in IEEE 802 (Local Area Networks) spezifizierten Protokolle beziehen sich nur auf die zwei unteren Schichten des OSI-Modells: Physical und Data Link Layer. IEEE 802 beschreibt den (in diesem Zusammenhang eher theoretischen) Medienzugriff (MAC) und die physische Komponente des Datenversand und -empfang (PHY). |
|||
[[Image:802.11-iso.png]] |
[[Image:802.11-iso.png]] |
||
** IEEE 802 Spezifikationen beziehen sich nur auf 2 untersten OSI-Layer -> Physical + Data Link Layer |
|||
** = MAC + PHY (physical) Komponente |
|||
** physical Layers: |
|||
*** FHSS – frequency-hopping spread-spectrum |
|||
*** DSSS – direct-sequence spread-spectrum |
|||
*** mit 802.11b -> HR/DSSS – high-rate DSSS |
|||
*** mit 802.11a -> OFDM – orthogonal frequency division multiplexing |
|||
*** 802.11g abwärts-kompatibel zu b, nutzt ausserdem auch OFDM |
|||
physikalische Schichten: |
|||
* FHSS – frequency-hopping spread-spectrum |
|||
* DSSS – direct-sequence spread-spectrum |
|||
* mit 802.11b -> HR/DSSS – high-rate DSSS |
|||
* mit 802.11a -> OFDM – orthogonal frequency division multiplexing |
|||
* 802.11g abwärts-kompatibel zu 802.11b, nutzt ausserdem auch OFDM |
|||
===Struktur eines Wireless Network=== |
|||
===Structure of a wireless network=== |
|||
Ein Drahtlosnetzwerk besteht nach IEEE 802.11 aus den wesentlichen Komponenten Stationen, Basisstationen, dem drahtlosen Übertragungsmedium und dem Verteilungssystem. Die Stationen bezeichnen dabei Computer im WLAN bzw. anders geartete Clients. Basisstationen, oder auch Access Points, agieren als Brücken für die Kommunikation zw. Stationen untereinander respektive Stationen und externen Hosts. Ursprünglich findet sich die Funktionalität eines AP in einem Gerät, im Zuge neuerer Entwicklungen kann diese aber auch auf "thin" APs und AP-Controller aufteilen. |
|||
Das Verteilungssystem, oder Distribution System, hat die Aufgabe die Kommunikation vom AP zur Aussenwelt bzw. von APs untereinander zu ermöglichen. |
|||
[[Image:station-ap.png]] |
[[Image:station-ap.png]] |
||
* Stationen |
|||
** Computer im WLAN |
|||
* Access Points |
|||
** Bridges: Station <-> Station bzw Station <-> Externe Hosts |
|||
** ursprünglich ein Gerät, neuerdings auch „thin“ APs und AP-Controller |
|||
* Drahtloses Medium |
|||
* DS – Verteilungssystem |
|||
==== |
====Typen von Netzwerken==== |
||
Es gibt mehrere Arten, die Unterschiede aufweisen und teilweise voneinander abhängen. |
Es gibt mehrere Arten von Drahtlosnetzwerken, die Unterschiede aufweisen und teilweise voneinander abhängen. |
||
Grundlage eines |
Grundlage eines Drahtlosnetzwerk ist das Basic Service Set - BSS: |
||
* Gruppe von Stationen, die miteinander kommunizieren |
* Gruppe von Stationen, die miteinander kommunizieren |
||
* Kommunikation innerhalb der BSA (Basic Service Area), durch Ausbreitungseigenschaften der Funkstrahlen definierter Raum. |
* Kommunikation innerhalb der BSA (Basic Service Area), durch Ausbreitungseigenschaften der Funkstrahlen definierter Raum. |
||
=====Unabhängiges Netzwerk, Independent BSS (IBSS, Ad-Hoc Netzwerke)===== |
|||
Hier wird auf den Einsatz eines APs verzichtet, stattdessen kommunizieren die Stationen direkt untereinander. Solche Netzwerke werden typischerweise für wenige Stationen und einen geringen Zeitraum eingerichtet. |
|||
=====Independent BSS (IBSS, Ad-Hoc networks)===== |
|||
[[Image:ibss.png]] |
[[Image:ibss.png]] |
||
* direkte Kommunikation der Stationen |
|||
* typischerweise für wenige Stationen bzw. geringen Zeitraum etabliert |
|||
=====Infrastructure BSS |
=====Infrastruktur Netzwerk, Infrastructure BSS===== |
||
Dieser Typ erfordert den Einsatz von APs, jegwede drahtlose Kommunikation involviert die Basisstation. Eine Station gilt als verbunden, wenn diese mit dem AP assoziiert ist. Damit ist die BSA als der Bereich definiert, der vom Sende- und Empfangsbereich des AP aufgespannt wird. |
|||
Somit benötigt jede Station-zu-Station-Kommunikation zwar 2 Hops, allerdings reduziert die zentrale Nachrichtenübermittlung die typischen Probleme eines Ad-Hoc-Netzwerks: Die Kommunikation aller Stationen untereinander hängt nicht mehr von sämtlichen Positionsvektoren aller Paare von Stationen ab, sondern beruht auf der Verbindung einer Station zum AP - entweder man ist mit dem AP "verbunden" oder nicht. Dies ermöglicht auch den Einsatz erweiterter Techniken, wie den Einsatz eines Stromsparmodus der Stationen, in denen der AP Datenpakete für die Stationen gezielt puffern muss. |
|||
[[Image:ap-bss.png]] |
[[Image:ap-bss.png]] |
||
* erfordert Benutzung eines AP, jegwede Kommunikation erfolgt über diesen AP |
|||
* BSA ist damit als Bereich definiert, in dem mit dem AP kommuniziert werden kann |
|||
* damit 2 Hops für Kommunikation von Station zu Station |
|||
** Unabhängigkeit von vielen Positionsvektoren (zu den anderen Stationen), nur noch abhängig von Pos. zum AP |
|||
** Möglichkeit eines Power-save Modus der Stationen (kurzzeitig PowerOff an den Stationen, AP puffert Frames) |
|||
* Association am AP |
|||
* novum: multi-BSS oder „virtual APs“ |
|||
** ein AP bedient mehrere BSS, ESS (mit jeweiliger SSID) |
|||
** Abbilden auf VLANs |
|||
Ein Novum stellt die Benutzung eines AP für die Verwaltung mehrerer BSS (multi-BSS) oder "virtual APs" dar. Dabei simuliert eine phys. Basisstation eine Menge von Basisstationen mit unterschiedlicher Konfiguration. Eine Möglichkeit der Netzwerk-Strukturierung besteht hier in der Kombination mit VLANs. |
|||
=====ESS===== |
|||
Extended Service Sets dienen der Erweiterung von BSS's, wobei mehrere BSS's in einem ESS zusammengefasst werden können. Dies ist die höchst-levelige logische Abstraktion eines Netzwerks in der 802.11-Spezifikation. Jeder Access Point, der ein BSS in einem ESS bedient kommuniziert mit den anderen BSS's (wobei diese jeweils durch andere AP's bedient werden) über ein Backbone-Netzwerk, das Teil des Verteilungssystem (Distribution System) ist. Ein ESS wird über eine eindeutige ID identifiziert, der SSID (Service Set Identifier = Netzwerkname). |
|||
=====ESS ===== |
|||
[[Image:ess.png]] |
[[Image:ess.png]] |
||
* Erweiterung von BSS's, diese werden zu einem ESS zusammengefasst |
|||
* jeder AP, der ein BSS in einem ESS bedient, kommuniziert mit den anderen BSS's über ein Backbone-Netzwerk |
|||
* Identifikation eines ESS über die SSID (Service Set Identifier = network name) |
|||
* sind höchst-levelige Abstaktion in 802.11 Netzwerken |
|||
====Distribution system ==== |
====Distribution system ==== |
||
Das Verteilungssystem stellt auf logischer Ebene die Verbindung zwischen Ethernet und Drahtlosnetzwerk her, agiert also als Bridge zum Backbone-Netzwerk. Im Falle eines ESS mit mehreren APs ist das Verteilungssystem, kurz DS, ausserdem für die Verbindung der APs verantwortlich; es aggregiert damit mehrere BSS's zu einem ESS. Die Kommunikation der APs untereinander wird über ein Inter Access Point Protocol (IAPP) geregelt. Dabei müssen neben dem Datenaustausch hauptsächlich die Assoziationen der Stationen mit ihren jeweiligen APs und Transitionen von Assoziationen kommuniziert werden. Das IAPP wird im IEEE 802.11F spezifiziert, wobei die technischen Vorgaben kaum umgesetzt wurden. Zumeist finden sich proprietäre Lösungen im Einsatz. |
|||
Die Kommunikation mehrerer APs kann sowohl über ein Backbone-Ethernet, als auch über ein drahtloses DS stattfinden. Im letzten Fall spricht man von einem WDS (wireless DS). Bei der Nutzung des drahtlosen Mediums ergeben sich jedoch neue Problemstellungen, da Inter-AP-Kommunikation denselben mediengebundenen Hürden unterliegt wie die Kommunikation von Stationen mit ihren APs. Zudem teilen sich diese Kommunikationsdomänen einen Kanal, was in Hinsicht auf Bandbreite, Leistungsfähigkeit und Stabilität des Netzes eine intensivere Planung der Netzstruktur erfordert. |
|||
[[Image:d-s.png]] |
[[Image:d-s.png]] |
||
* wenn mehrere APs verbunden sind um ein Netz zu formen kümmert sich dieses um deren Kommunikation |
|||
* basiert meist auf Ethernet |
|||
* verbindet APs zu einem ESS (DS = logische Komponente in 802.11) |
|||
** einhaltet das Backbone-Netzwerk, benötigt jedoch mehr |
|||
** Bridge zwischen Wireless Network und Backbone Network |
|||
* Inter-Access Point Kommunikation |
|||
** jeder AP muss über die Assoziationen aller APs Bescheid wissen |
|||
** IAPP – inter-AP-protocol, meist über Backbone-Netzwerk |
|||
** IAPP im IEEE 802.11F, wurde jedoch kaum umgesetzt (mittlerweile zurückgezogen) -> zu finden sind oftmals proprietäre Protokolle. |
|||
* WDS – wireless distribution system |
|||
** das drahtlose medium selbst als DS |
|||
** „wireless bridge“ |
|||
===Zugriffskontrolle in 802.11=== |
|||
===Using the MAC=== |
|||
====CSMA/CA==== |
====CSMA/CA==== |
||
Der Zugriff auf das drahtlose Medium wird in 802.11-Netzwerken nach dem Paradigma CSMA/CA geregelt. CSMA/CA steht für Carrier Sense Multiple Access with Collision Avoidance und sieht im Gegensatz zu CSMA/CD (Collision Detection, Verwendung bei 802.3 LAN) nicht nur das Erkennen von Kollisionen, sondern auch das geziehlte Verhindern von Kollisionen durch gewisse Timingparameter vor. Dass für drahtlose Netzwerke ein neuartiges Zugriffsprotokoll gewählt wurde hängt von der Charakteristik des benutzten Mediums ab: In WLANs benutzen alle Stationen in einem BSS denselben Kanel, was Kollisionen besonders teuer macht. In drahtgebundenen LANs schließt die Verwendung von Switches praktische jede Kollisison aus, bzw. ein auftretender Konflikt betrifft nur die sendende Station selbst. |
|||
* CSMA/CA – carrier sense multiple access with collision avoidance |
|||
Ein weiteres Problem stellt die Ausbreitung der Datenpakete dar: 2 Kommunikationsendpunkte im Raum haben jeweils ihren eigenen Funkbereich, was zu folgendem Problem führt: |
|||
* Ethernet nutzt CSMA/CD – collision detection |
|||
* Unterschied rührt vom benutzten Medium her |
|||
====Das "Hidden Node"-Problem und RTS/CTS==== |
|||
''Das Problem:'' |
|||
Man stelle sich 3 Kommunikationspartner (1, 2 und 3) vor. 1 kann direkt mit 2 kommunizieren, 2 ebenso direkt mit 3; allerdings sind 1 und 3 soweit von einander entfernt, dass keine direkte Kommunikation zwischen beiden möglich ist. Sendet 1 Daten an 2, so erfährt 1 nicht, dass 3 im selben Augenblick mit 2 kommunizieren könnte. Passiert dies und 1 und 3 senden gleichzeitig Daten an 2, so kollidiert der Medienzugriff von 1 und 3 aus Sicht von 2. |
|||
====The hidden node problem and RTS/CTS==== |
|||
Problem: |
|||
[[Image:hidden.png]] |
[[Image:hidden.png]] |
||
* 1 will an 2 funken, bemerkt, dass in seinem Funkbereich alles frei ist und funkt |
|||
* jedoch kann 3 ständig funken und damit den Empfang von 2 beeinträchtigen, ohne dass 1 das merken kann |
|||
''Die Lösung: RTS/CTS'' |
|||
Solution: |
|||
RTS = request to send, CTS = clear to send. |
|||
Das sind Kontrollpakete, die vor der eigentlichen Kommunikation zw. 2 Stationen gesendet werden. Der sendende Host schickt dabei ein RTS-Paket an die empfangende Station und informiert alle Stationen in seinem Funkbereich von der anstehenden Kommunikation. Der Empfänger antwortet mit CTS und informiert ebenso alle Stationen in seinem Funkbereich. Danach ist das Medium für die Kommunikation vorbereitet. |
|||
[[Image:rtscts.png]] |
[[Image:rtscts.png]] |
||
* RTS (request to send) und CTS (clear to send) |
|||
** Sender sendet RTS an seinen gesamten Funkbereich und fordert andere Stationen zur Stille auf |
|||
** Empfänger sendet daraufhin CTS an seinen gesamten Funkbereich, selber Effekt |
|||
** damit sind beide Funkbereiche bereit für Übertragung |
|||
** nach RTS/CTS muss jeder Frame geACK'ed werden |
|||
** RTS/CTS ist optional, wird meist in Hochverkehrsbereichen benutzt |
|||
*** oft auch dort unnötig, da die Dichte an APs sehr hoch, damit hört jede Station in einem BSS jede andere |
|||
** Aktivierung über WNIC-Treiber (RTS threshold, grenzwertige Framelänge, ab der Bereiche gecleared werden) |
|||
Die RTS/CTS-Sequenz propagiert verschiedene Parameter, wie die geschätzte Dauer des anstehenden Datenaustauschs. Auf diese Weise können sehr effektiv längere Übertragungen initial abgesichert werden. Die Verwendung dieser Sequenz ist allerdings optional, da sie zusätzlichen Funkaufwand erfordert und damit nur in eher stark ausgelasteten Umgebungen von Vorteil ist. Doch selbst in Hochverkehrsbereichen ist RTS/CTS nicht immer sinnvoll: Ist die AP-Dichte hoch genug, so liegen meist die Funkbereiche aller Teilnehmer eines BSS weit genug zusammen um das Hidden-Node-Problem zu umgehen. Hier erhöht RTS/CTS nur zusätzlich das Datenaufkommen. |
|||
Die Steuerung dieses Mechanismus kann meist über den Treiber eines WLAN-Gerätes vorgenommen werden. |
|||
==== |
====Coordination Functions und Timing==== |
||
=====MAC-Zugriffsmodi: Coordination Functions===== |
=====MAC-Zugriffsmodi: Coordination Functions===== |
||
Zugriff wird kontrolliert durch Coordination Functions: |
|||
[[Image:dcfpcf.png]] |
[[Image:dcfpcf.png]] |
||
* DCF – distributed coordination function |
|||
** Standard CSMA/CA |
|||
** vor Sendung eines Frames lauschen, ob Medium frei |
|||
** wenn Frame übertragen wurde, warten alle Stationen im BSS ein zufälliges Intervall (Minimum ist festgelegt), bis sie senden |
|||
*** verhindert (fast sicher) gleichzeitiges Senden, was einzige Möglichkeit der Kollision birgt |
|||
DCF – distributed coordination function |
|||
* Standard CSMA/CA |
|||
** konkurrenzfreie Koordination, gewährleistet QoS |
|||
* vor Sendung eines Frames lauschen, ob Medium frei |
|||
** selten implementiert |
|||
* wenn Frame übertragen wurde, warten alle Stationen im BSS ein zufälliges Intervall (Minimum ist festgelegt), bis sie senden |
|||
** sog. Point Coordinator verwaltet den tokenbasierten Ansatz |
|||
** verhindert (fast sicher) gleichzeitiges Senden, was einzige Möglichkeit der Kollision birgt |
|||
*** gibt Sendetoken an jede Station einzeln |
|||
*** nicht jede Station muss PCF unterstützen |
|||
**** nach einer CFP (contention-free period) kommt eine contention-period in der wie bei DCF gearbeitet wird |
|||
**** in der CFP können nicht-PCF-Stationen nicht senden, da Dauer der Tokenübergabe geringer als minimale Wartezeit bei DCF |
|||
* HCF – hybrid coordination function |
|||
PCF – point coordination function |
|||
** hybrider Ansatz der beiden oben genannten |
|||
* konkurrenzfreie Koordination, gewährleistet QoS |
|||
** noch nicht voll standardisiert, wird jedoch Teil von 802.11e |
|||
* selten implementiert |
|||
* sog. Point Coordinator verwaltet den tokenbasierten Ansatz |
|||
** gibt Sendetoken an jede Station einzeln |
|||
** nicht jede Station muss PCF unterstützen |
|||
*** nach einer CFP (contention-free period) kommt eine contention-period in der wie bei DCF gearbeitet wird |
|||
*** in der CFP können nicht-PCF-Stationen nicht senden, da Dauer der Tokenübergabe geringer als minimale Wartezeit bei DCF |
|||
HCF – hybrid coordination function |
|||
* hybrider Ansatz der beiden oben genannten |
|||
* noch nicht voll standardisiert, wird jedoch Teil von 802.11e |
|||
Line 184: | Line 168: | ||
=====Interframe Spacing===== |
=====Wartezeiten: Interframe Spacing===== |
||
[[Image:ifs.png]] |
[[Image:ifs.png]] |
||
* SIFS < PIFS < DIFS |
* SIFS < PIFS < DIFS |
||
Line 195: | Line 179: | ||
** für Fehler in der Übertragung |
** für Fehler in der Übertragung |
||
=== |
===MAC-Layer und Dienste in 802.11=== |
||
==== |
====Übersicht ==== |
||
* 802.11 definiert Dienste, die Netzwerke anbieten müssen: |
* 802.11 definiert Dienste, die Netzwerke anbieten müssen: |
||
** Distribution: |
** Distribution: |
||
Line 218: | Line 202: | ||
*** einfach Datenverkehr zw. Stationen und APs |
*** einfach Datenverkehr zw. Stationen und APs |
||
** Spektrenverwaltung (Transmit Power Control, Dynamic Frequency Selection nach 802.11h) (nur in Europa) |
** Spektrenverwaltung (Transmit Power Control, Dynamic Frequency Selection nach 802.11h) (nur in Europa) |
||
* davon Stations-seitig (von Stationen und APs angeboten): |
* davon Stations-seitig (von Stationen und APs angeboten): |
||
Line 224: | Line 209: | ||
** Vertraulichkeit |
** Vertraulichkeit |
||
** Spektrenverwaltung (TPC, DFS) |
** Spektrenverwaltung (TPC, DFS) |
||
* Distributionssystem-seitig (verbinden APs zu einem DS): |
* Distributionssystem-seitig (verbinden APs zu einem DS): |
||
Line 231: | Line 217: | ||
====Frame |
====Frame-Formate==== |
||
===== |
=====Arten von Frames===== |
||
* Data- und Control Frames für Auslieferung von Daten und Kontrolle des Datenflusses |
* Data- und Control Frames für Auslieferung von Daten und Kontrolle des Datenflusses |
||
Line 247: | Line 233: | ||
===== |
=====Fragmentation ===== |
||
* nötig, weil: |
* nötig, weil: |
||
** große Frames sonst nicht „aufs Medium passen“ |
** große Frames sonst nicht „aufs Medium passen“ |
||
Line 261: | Line 247: | ||
===== |
=====allgemeines Frame-Format ===== |
||
[[Image:frame.png]] |
[[Image:frame.png]] |
||
* enthält einige typische Felder |
* enthält einige typische Felder '''nicht''' |
||
** Präambel ist Teil des physischen Layer |
** Präambel ist Teil des physischen Layer |
||
** Type/Length werden im Datenteil gekapselt |
** Type/Length werden im Datenteil gekapselt |
||
Line 269: | Line 255: | ||
[[Image:framectrl.png]] |
|||
* Frame Control Field: |
* Frame Control Field: |
||
[[Image:framectrl.png]] |
|||
** Protocol: |
** Protocol: |
||
*** bisher nur 00 definiert, weitere für evtl. spätere 802.11 Revisionen |
*** bisher nur 00 definiert, weitere für evtl. spätere 802.11 Revisionen |
||
** Type & Subtype: |
** Type & Subtype: |
||
{| border="1" |
{| border="1" |
||
| Subtype value || Subtype name |
| Subtype value || Subtype name |
||
Line 356: | Line 345: | ||
|- |
|- |
||
|} |
|} |
||
** ToDS, FromDS: |
** ToDS, FromDS: |
||
Line 369: | Line 359: | ||
*** FromDS, ToDS = 1 |
*** FromDS, ToDS = 1 |
||
**** Daten-Frames in einer „Wireless Bridge“ |
**** Daten-Frames in einer „Wireless Bridge“ |
||
** More Fragments |
** More Fragments |
||
*** wie in IP |
*** wie in IP |
||
*** 1 = es kommen weitere Fragmente |
*** 1 = es kommen weitere Fragmente |
||
*** wird nur von einigen Managementframes und großen Daten-Frames verwendet, meist ist Daten-Frame-Größe = Ethernet-Frame-Größe |
*** wird nur von einigen Managementframes und großen Daten-Frames verwendet, meist ist Daten-Frame-Größe = Ethernet-Frame-Größe |
||
** Retry |
** Retry |
||
*** 1 = dieser Frame ist eine Sendewiederholung |
*** 1 = dieser Frame ist eine Sendewiederholung |
||
** Power Management |
** Power Management |
||
*** 1 = Station geht nach atomarem Frame-Austausch in Powersave-Modus |
*** 1 = Station geht nach atomarem Frame-Austausch in Powersave-Modus |
||
*** niemals gesetzt bei Frames vom AP |
*** niemals gesetzt bei Frames vom AP |
||
** More Data |
** More Data |
||
*** 1 = es liegen weitere gepufferte Frames im AP vor |
*** 1 = es liegen weitere gepufferte Frames im AP vor |
||
*** wird nur bei Frames verwendet, die an Powersave-Stationen geschickt werden |
*** wird nur bei Frames verwendet, die an Powersave-Stationen geschickt werden |
||
** Protected Frame |
** Protected Frame |
||
*** 1 = Frame wird durch Link-Layer-Sicherheitsprotokolle geschützt |
*** 1 = Frame wird durch Link-Layer-Sicherheitsprotokolle geschützt |
||
** Order |
** Order |
||
*** 1 = strikte Ordnung ist aktiv |
*** 1 = strikte Ordnung ist aktiv |
||
*** Frames und Fragmente können sonst auch ungeordnet übertragen werden |
*** Frames und Fragmente können sonst auch ungeordnet übertragen werden |
||
* Duration/ID Field: |
* Duration/ID Field: |
||
Line 397: | Line 395: | ||
** PS-Poll Frames |
** PS-Poll Frames |
||
*** wird von schlafenden Stationen gesendet, die gerade aufwachen |
*** wird von schlafenden Stationen gesendet, die gerade aufwachen |
||
*** AID gibt Assoziations-ID an -> gibt an, zu welchem BSS die Station gehört (falls im Schlaf BSS-Transition) |
*** AID gibt Assoziations-ID an -> gibt an, zu welchem BSS die Station gehört (falls im Schlaf BSS-Transition) (diese wird bei Assoziation vom AP bezogen) |
||
(diese wird bei Assoziation vom AP bezogen) |
|||
*** nur Werte von 1 – 2007, alle anderen sind reserviert |
*** nur Werte von 1 – 2007, alle anderen sind reserviert |
||
* 4 Adressfelder |
* 4 Adressfelder |
||
** enthalten 48Bit MAC Adressen |
** enthalten 48Bit MAC Adressen |
||
** je nach Netzwerktyp und Datenrichtung verwendet (nach ToDS, FromDS): |
** je nach Netzwerktyp und Datenrichtung verwendet (nach ToDS, FromDS): |
||
{| border="1" |
{| border="1" |
||
|- |
|- |
||
Line 417: | Line 417: | ||
|- |
|- |
||
|} |
|} |
||
** verschiedene Zwecke: |
** verschiedene Zwecke: |
||
Line 434: | Line 435: | ||
**** in Infrastruktur-Netzen: BSSID = MAC des APs |
**** in Infrastruktur-Netzen: BSSID = MAC des APs |
||
**** in ad-hoc-Netzen: zufällig generiert mit Universal/Local-Bit gesetzt (vermeidet Konflikt mit phys. MAC-Adressen) |
**** in ad-hoc-Netzen: zufällig generiert mit Universal/Local-Bit gesetzt (vermeidet Konflikt mit phys. MAC-Adressen) |
||
Line 446: | Line 448: | ||
** fragment number |
** fragment number |
||
*** gibt Nummer des Fragments an |
*** gibt Nummer des Fragments an |
||
* Frame body |
* Frame body |
||
Line 453: | Line 457: | ||
** inkl. 802.2 LLC header bleiben dann 2296 Bytes Payload |
** inkl. 802.2 LLC header bleiben dann 2296 Bytes Payload |
||
** es gibt weiterhin kein Typfeld, dass das gekapselte Protokoll angibt -> weiterer Header am Anfang des Payload benötigt |
** es gibt weiterhin kein Typfeld, dass das gekapselte Protokoll angibt -> weiterer Header am Anfang des Payload benötigt |
||
* Frame Check Sequence – FCS |
* Frame Check Sequence – FCS |
||
Line 459: | Line 465: | ||
** eigentlich gleich dem 802.3-Feld, jedoch andere MAC-Header |
** eigentlich gleich dem 802.3-Feld, jedoch andere MAC-Header |
||
*** zwingt APs zur Neuberechnung |
*** zwingt APs zur Neuberechnung |
||
Line 464: | Line 472: | ||
Management-Frames übernehmen Funktionen, die bei wired-Netzen physikalisch umgesetzt sind. |
Management-Frames übernehmen Funktionen, die bei wired-Netzen physikalisch umgesetzt sind. |
||
===== |
=====Scannen eines Netzwerks: Probes und Beacons ===== |
||
* Parameter fürs Scannen: |
* Parameter fürs Scannen: |
||
** BSS Type (independent, infrastructure) |
** BSS Type (independent, infrastructure) |
||
Line 473: | Line 481: | ||
** probe delay |
** probe delay |
||
** minChannelTime, maxChannelTime |
** minChannelTime, maxChannelTime |
||
======Passive Scanning ====== |
======Passive Scanning ====== |
||
Line 480: | Line 490: | ||
** verhindern passives Scannen, da die SSID nicht mehr in den Beacons übermittelt wird |
** verhindern passives Scannen, da die SSID nicht mehr in den Beacons übermittelt wird |
||
** wird jedoch in Probe Responses gesendet -> Active Scanning |
** wird jedoch in Probe Responses gesendet -> Active Scanning |
||
======Active Scanning ====== |
======Active Scanning ====== |
||
* für jeden Channel einzeln durchzuführen: |
* für jeden Channel einzeln durchzuführen: |
||
*# Channel abhören, bis Paket eintrifft oder probe delay timer abläuft |
|||
*# trifft Paket ein, so ist Channel in Benutzung und kann geprobed werden |
|||
*# Probe Request senden |
|||
*# minChannelTime abwarten |
|||
*## wenn nix passiert, dann ist Channel nicht in Benutzung |
|||
*## wenn Frames verkehren, dann warte bis maxChannelTime und werte jede Probe Response aus |
|||
[[Image:probes.png]] |
[[Image:probes.png]] |
||
Line 497: | Line 508: | ||
* enthalten Parameter zur Konfiguration für möglichen Netzwerkzugang für Clients |
* enthalten Parameter zur Konfiguration für möglichen Netzwerkzugang für Clients |
||
[[Image:beacon.png]] |
[[Image:beacon.png]] |
||
* Felder: |
* Felder: |
||
Line 521: | Line 533: | ||
**** 802.1X or PMK caching |
**** 802.1X or PMK caching |
||
**** Pre-shared key |
**** Pre-shared key |
||
Line 527: | Line 540: | ||
* geben Auskunft über die Möglichkeiten des Clients |
* geben Auskunft über die Möglichkeiten des Clients |
||
* versehen mit SSID eines Netzes oder broadcast SSID für alle Netze |
* versehen mit SSID eines Netzes oder broadcast SSID für alle Netze |
||
======Probe Response Frame ====== |
======Probe Response Frame ====== |
||
Line 533: | Line 547: | ||
=====Joining a network===== |
|||
=====Joining a Network: Authentifizierung und Assoziation===== |
|||
Folgende Schritte: |
Folgende Schritte: |
||
* Authentication bzw. Pre-Authentication |
* Authentication bzw. Pre-Authentication |
||
* Association |
* Association |
||
====== 802.11 Authentication ====== |
|||
====== 802.11 Authentifizierung ====== |
|||
* Open-System Authentication: |
* Open-System Authentication: |
||
** garantiert in keiner Weise Sicherheit, diese muss auf Basis dieser Auth aufgebaut werden |
** garantiert in keiner Weise Sicherheit, diese muss auf Basis dieser Auth aufgebaut werden |
||
Line 544: | Line 562: | ||
** Antwort via selbem Frametyp |
** Antwort via selbem Frametyp |
||
[[Image:opensys.png]] |
[[Image:opensys.png]] |
||
* Shared-Key Authentication: |
* Shared-Key Authentication: |
||
Line 555: | Line 575: | ||
*** ermöglicht zwar nicht die Generation des WEP-Keys aus dem Keystream, dennoch kann sich Attacker authentifizieren |
*** ermöglicht zwar nicht die Generation des WEP-Keys aus dem Keystream, dennoch kann sich Attacker authentifizieren |
||
*** kann keine Datenpakete behandeln, da denen anderer Keystream zugrunde liegt |
*** kann keine Datenpakete behandeln, da denen anderer Keystream zugrunde liegt |
||
====== Preauthentication ====== |
====== Preauthentication ====== |
||
Line 561: | Line 583: | ||
* 802.11 regelt nicht, wann authentifiziert und wann assoziiert werden muss -> auth kann lang vor assoc passieren |
* 802.11 regelt nicht, wann authentifiziert und wann assoziiert werden muss -> auth kann lang vor assoc passieren |
||
====== Association Procedure ====== |
|||
====== Association-Prozedur ====== |
|||
* wenn auth abgeschlossen kann assoc stattfinden: |
* wenn auth abgeschlossen kann assoc stattfinden: |
||
Line 572: | Line 597: | ||
====== Reassociation procedure ====== |
|||
====== Reassociation-Prozedur ====== |
|||
[[Image:reassoc.png]] |
[[Image:reassoc.png]] |
||
* Reassociation Request Frame: |
* Reassociation Request Frame: |
||
Line 578: | Line 605: | ||
====== Mobility support: Transitions ====== |
|||
====== Mobility Support: Transitions ====== |
|||
Transitionsarten in 802.11: |
Transitionsarten in 802.11: |
||
* Keine Transition (ist eben keine Transition, aber in 802.11 vereinbart) |
* Keine Transition (ist eben keine Transition, aber in 802.11 vereinbart) |
||
* BSS Transition: |
* BSS Transition: |
||
Line 607: | Line 638: | ||
*** benötigt OSI-Layer-2-Verbindung der APs (Verbindung darf nicht gerouted sein) |
*** benötigt OSI-Layer-2-Verbindung der APs (Verbindung darf nicht gerouted sein) |
||
*** bei Roaming Datenverlust wahrscheinlich, muß von höheren Schichten abgefangen werden |
*** bei Roaming Datenverlust wahrscheinlich, muß von höheren Schichten abgefangen werden |
||
Line 613: | Line 646: | ||
* wird nicht unterstützt, d.h. es ist zwar möglich das ESS zu wechseln, jedoch werden dabei vorhandene Verbindungen unterbrochen |
* wird nicht unterstützt, d.h. es ist zwar möglich das ESS zu wechseln, jedoch werden dabei vorhandene Verbindungen unterbrochen |
||
* Abmeldung im ESS1, Anmeldung im ESS2 (Verfahren zb Mobile-IP) |
* Abmeldung im ESS1, Anmeldung im ESS2 (Verfahren zb Mobile-IP) |
||
====Vertraulichkeit und Zugangskontrolle==== |
====Vertraulichkeit und Zugangskontrolle==== |
||
Line 618: | Line 656: | ||
=====WEP===== |
=====WEP===== |
||
Bei diesem Verfahren müssen die Schlüssel manuell an alle Teilnehmer verteilt werden (PSK - pre shared keys), eine dynamische (und damit leichter zu administrierende) Schlüsselverteilung ist im ursprünglichen Entwurf nicht vorgesehen, wurde jedoch teilweise trotzdem implementiert (Dynamic WEP). |
|||
* gilt mittlerweile als „geknackt“ |
|||
WEP gilt mittlerweile als „geknackt“. Allerdings ist bei diesem Verfahren der Rechenaufwand im Vergleich zu den moderneren geringer, deshalb ist WEP für schwachbrüstige Geräte wohl immer noch eine Alternative. |
|||
Line 644: | Line 683: | ||
*** CCMP mit TKIP |
*** CCMP mit TKIP |
||
==== |
====Grundlegende Flusssteuerung ==== |
||
=====Control |
=====Control-Frames ===== |
||
[[Image:ctrlframe.png]] |
[[Image:ctrlframe.png]] |
||
* ToDS und FromDS beide 0, können nur von Stationen kommen und richten sich „and Medium“, nicht ans DS |
* ToDS und FromDS beide 0, können nur von Stationen kommen und richten sich „and Medium“, nicht ans DS |
||
* niemals fragmentiert |
* niemals fragmentiert |
||
* keine Retransmission |
* keine Retransmission |
||
Line 661: | Line 701: | ||
* CTS: |
* CTS: |
||
[[Image:cts.png]] |
[[Image:cts.png]] |
||
Line 667: | Line 710: | ||
* QoS-Erweiterungen können Notwendigkeit der Bestätigung (jedes!) Frames lockern |
* QoS-Erweiterungen können Notwendigkeit der Bestätigung (jedes!) Frames lockern |
||
[[Image:ack.png]] |
[[Image:ack.png]] |
||
====Transfer von Daten ==== |
====Transfer von Daten ==== |
||
Line 680: | Line 726: | ||
* IEEE-Jargon: directed data |
* IEEE-Jargon: directed data |
||
* müssen ge'ACK'ed werden |
* müssen ge'ACK'ed werden |
||
* Fall 1: basic ACK, final fragment (oder keine Fragmentation): |
* Fall 1: basic ACK, final fragment (oder keine Fragmentation): |
||
[[Image: |
[[Image:uninofrag.png]] |
||
* Fall 2: Fragmentation: |
* Fall 2: Fragmentation: |
||
[[Image:unifrag.png]] |
[[Image:unifrag.png]] |
||
* Fall 3: RTS/CTS: |
* Fall 3: RTS/CTS: |
||
[[Image:unirtscts.png] |
[[Image:unirtscts.png]] |
||
* Fall 4: RTS/CTS mit Fragmentation: |
* Fall 4: RTS/CTS mit Fragmentation: |
||
Line 696: | Line 746: | ||
=====Distribution ===== |
|||
=====Integration bzw. Einkapselung von Ethernet Frames ===== |
|||
=====Distribution: Integration bzw. Einkapselung von Ethernet Frames===== |
|||
======Prinzip====== |
======Prinzip====== |
||
* 802.11 als 802 link layer, kann alle network-layer Protokolle kapseln |
* 802.11 als 802 link layer, kann alle network-layer Protokolle kapseln |
||
Line 714: | Line 765: | ||
[[Image:ethencap.png]] |
[[Image:ethencap.png]] |
||
Line 720: | Line 772: | ||
[[Image:bridging.png]] |
[[Image:bridging.png]] |
||
* wireless -> wired |
|||
# Frame wird empfangen, Integritätscheck (physical layer check und FCS) |
*# Frame wird empfangen, Integritätscheck (physical layer check und FCS) |
||
# Check ob weiterverarbeitet werden soll |
*# Check ob weiterverarbeitet werden soll |
||
** Frames an AP haben dessen MAC (BSSID) im 1.Adressfeld, andere MAC's sollten verworfen werden |
*#* Frames an AP haben dessen MAC (BSSID) im 1.Adressfeld, andere MAC's sollten verworfen werden |
||
** Duplikate werden verworfen |
*#* Duplikate werden verworfen |
||
# Entschlüsseln von LinkLayer-Verschlüsselung |
*# Entschlüsseln von LinkLayer-Verschlüsselung |
||
# Defragmentation |
*# Defragmentation |
||
** fragmentierte Frames müssen insgesamt auf Integrität gecheckt werden |
*#* fragmentierte Frames müssen insgesamt auf Integrität gecheckt werden |
||
# MAC Header muss übersetzt werden |
*# MAC Header muss übersetzt werden |
||
## 802.11-Zieladresse(3. Adressfeld) -> Ethernet-Zieladresse |
*## 802.11-Zieladresse(3. Adressfeld) -> Ethernet-Zieladresse |
||
## 802.11-Senderadr.(2. Adressfeld) -> Ethernet-Senderadresse |
*## 802.11-Senderadr.(2. Adressfeld) -> Ethernet-Senderadresse |
||
## Ethernet-Type-Code wird aus SNAP-Header in Ethernet-Frame kopiert; wenn Ethernet selbst SNAP benutzt, so kann kompletter SNAP-Header kopiert werden |
*## Ethernet-Type-Code wird aus SNAP-Header in Ethernet-Frame kopiert; wenn Ethernet selbst SNAP benutzt, so kann kompletter SNAP-Header kopiert werden |
||
## evtl. QoS-Flags für Verkehr aus Funknetzen im Ethernet-Frame setzen |
*## evtl. QoS-Flags für Verkehr aus Funknetzen im Ethernet-Frame setzen |
||
# FCS wird für Ethernet neu berechnet |
*# FCS wird für Ethernet neu berechnet |
||
# Frame wird via Ethernet übertragen |
*# Frame wird via Ethernet übertragen |
||
* wired -> wireless |
|||
# Frame wird empfangen, Ethernet-FCS-Check |
*# Frame wird empfangen, Ethernet-FCS-Check |
||
# Check ob Frame an Station assoziiert am AP gerichtet ist |
*# Check ob Frame an Station assoziiert am AP gerichtet ist |
||
# SNAP Header wird dem Ethernet-Frame vorangestellt |
*# SNAP Header wird dem Ethernet-Frame vorangestellt |
||
** höherleveliges Paket wird mit SNAP Header umschlossen |
*#* höherleveliges Paket wird mit SNAP Header umschlossen |
||
** Type-Code wird aus Ethernet-Type-Code-Feld kopiert |
*#* Type-Code wird aus Ethernet-Type-Code-Feld kopiert |
||
** wenn Ethernet auch SNAP-Kapselung fährt, so kann komplettes SNAP-Paket benutzt werden |
*#* wenn Ethernet auch SNAP-Kapselung fährt, so kann komplettes SNAP-Paket benutzt werden |
||
# Frame wird für Übertragung bereitgestellt -> Transmit-Queue |
*# Frame wird für Übertragung bereitgestellt -> Transmit-Queue |
||
# Frame erhält Sequence Number |
*# Frame erhält Sequence Number |
||
** Integritätscode wird generiert |
*#* Integritätscode wird generiert |
||
** evtl. Fragmentierung, Zuweisung von Fragmentnummern |
*#* evtl. Fragmentierung, Zuweisung von Fragmentnummern |
||
# Frame wird evtl. verschlüsselt |
*# Frame wird evtl. verschlüsselt |
||
# 802.11 MAC Header wird gebaut |
*# 802.11 MAC Header wird gebaut |
||
## Ethernet-Zieladresse -> 802.11-Zieladresse (1. Adressfeld) |
*## Ethernet-Zieladresse -> 802.11-Zieladresse (1. Adressfeld) |
||
## BSSID -> 2. Adressfeld (als Sender des Frames im WLAN) |
*## BSSID -> 2. Adressfeld (als Sender des Frames im WLAN) |
||
## Ethernet-Quelladresse -> 802.11-Quelladresse (3. Adressfeld) |
*## Ethernet-Quelladresse -> 802.11-Quelladresse (3. Adressfeld) |
||
## Dauer der Übertragung -> Durationfeld |
*## Dauer der Übertragung -> Durationfeld |
||
## Flags im Frame Control-Feld werden gesetzt |
*## Flags im Frame Control-Feld werden gesetzt |
||
# FCS wird für 802.11 neu berechnet |
*# FCS wird für 802.11 neu berechnet |
||
# Frame wird via 802.11 übertragen |
*# Frame wird via 802.11 übertragen |
||
====Misc. stuff ==== |
|||
=====Spectrum management ===== |
|||
=====multirate-support ===== |
|||
====weitere Dienste==== |
|||
=====Spectrum-Management===== |
|||
* nur in Europa definiert IEEE 802.11h als obligatorische Erweiterung zu 802.11a (54Mbit-Wlan im 5GHz-Band): |
|||
* TPC – Transmit Power Control |
|||
** stationsseitige Kontrolle der Sendeleistung |
|||
** gegenseitige Interferenz von „Funkern“ verringern/verhindern |
|||
** ergo Transmit Power so einstellen, dass es „gerade reicht“ |
|||
* DFS – Dynamic Frequency Selection |
|||
** dyn. Umschalten auf andere Frequenzen, sodass Interferenz mit Radarfrequenzen vermieden wird |
|||
** auch gedacht, um Frequenzband gleichmäßig auszulasten |
|||
=====Multirate-Support ===== |
|||
* Übertragungsraten ändern sich ständig als Reaktion auf Veränderung der Funkleistung |
|||
* 802.11 gibt nur generelle Regeln, wie verhalten werden soll, tatsächliche Datenraten-Auswahl liegt bei den Stationen/APs |
|||
* Management der Datenraten: |
|||
** jede Station hält Liste von „operational rates“ |
|||
*** Liste von Raten, die Station und BSS benutzen können |
|||
*** kein Transfer mit höheren Raten |
|||
** jedes BSS hält Liste von „basic rates“ - basic rate set |
|||
*** Liste von Raten, die jede Station im BSS benutzen kann |
|||
*** für Broad-, Multicast |
|||
*** für Control Frames, die Datenaustausch starten, wie RTS/CTS |
|||
** Unicast Frames können in jeder Rate übertragen werden, die vom Empfänger unterstützt wird |
|||
** Antwort Frames, wie CTS und ACK mit Rate aus basic rate set, aber niemals höher, als der initiale Frame der Sequence |
|||
*** müssen ausserdem dieselbe Modulation wie der erste Frame haben (DSSS, CCK, OFDM) |
|||
== „Ad-hoc Multi-hop Mesh“-Netzwerke == |
== „Ad-hoc Multi-hop Mesh“-Netzwerke == |
||
=== Besonderheiten === |
=== Besonderheiten === |
||
* Netzwerktopologie ist ein vermaschtes (Mesh) Netz von gleichberechtigen mobilen Knoten: |
|||
[[Image:adhoc-multihop.gif]] |
|||
* jedes Endgerät mit einem oder mehreren anderen Endgeräten verbunden |
|||
* jeder (in der Praxis: einige Mesh-APs MAP) Knoten agiert als Router für andere, um Daten von nahen Knoten zu anderen zu übertragen, die zu weit weg sind, sie zu erreichen (ad-hoc) |
|||
--> der Umweg über feste AP's und die dahinterliegenden DS entfällt also |
|||
* Vorteile: |
|||
** viele Wege führen zum Ziel, Ausfall eines Weges verkraftbar |
|||
** günstigere Lastverteilung: je mehr Teilnehmer, desto mehr mögliche Wege, mehr Bandbreite , |
|||
vorausgesetzt, die durchschnittlichen Wege bleiben kurz |
|||
--> typische Netzstruktur in der Praxis ist Maschennetz mit „eingesprenkelten“ Gateways, die Zugang zum Internet oder anderem Verteilungsnetz bereitstellen |
|||
* Probleme: |
|||
** komplexes Routing nötig, da sich wg. Bewegung der Teilnehmer Netzstruktur ständig ändert |
|||
*** momentan konkurrieren mehr als 70 Layer3-Routing-Protokolle |
|||
** Zellen überlappen sich (damit Stationen Kontakt zueinander), weil jedoch Interferenzreichweite höher als Empfangsreichweite, stören sich Stationen, die schon nichts mehr voneinander wissen: |
|||
[[Image:interf.png]] |
|||
: Stationen können sich zwar nicht mehr hören, wohl aber noch stören... |
|||
=== 802.11s === |
=== 802.11s === |
||
* ist der Entwicklung befindliche IEEE-Standard für ESS-Mesh-Netzwerke |
|||
* hat die Vorschläge der “Wi-Mesh Alliance“ und „SEEMesh“ als Grundlage |
|||
* hierarchischer Ansatz: |
|||
[[Image:mesh.jpg]] |
|||
** nur spezielle Stationen bilden das Mesh-WLAN und werden zu Mesh-APs (MAP), verbunden durch ein nun WDS |
|||
** dort anmelden können sich Mesh Points (MP), die Daten zwar weiterleiten, aber Stationen keine Möglichkeit zur Assoziierung bieten. |
|||
** MAPs können auch Mesh-Portal Dienste bereitstellen |
|||
*** Gateways in andre Netze wie z.b. Internet |
|||
* Datenintegrität und Vertraulichkeit: |
|||
** Komponenten von 802.11i wiederverwendet und Schlüssel von zentraler Instanz, z.B.Radius-Server, verwaltet |
|||
* Verwendung von mehreren Transceivern pro AP möglich |
|||
* Vorgabe von 802.11s 32 Mesh-(Access)-Points (aber keine absolute Grenze). |
|||
** Paket braucht bei WLANs solcher Größe max. etwa 4 bis 5 Hops bis zum Ziel |
|||
** Wege sollen kurz gehalten werden, um den Vorteil der höheren Bandbreite nicht zunichte zu machen |
|||
* herkömmliche Mesh-Verfahren benutzen Routing auf Layer3 (IP)-Ebene, das sich über die Schichtgrenze hinweg zusätzliche Informationen zur Link-Güte aus der MAC-Schicht holen muss.(z.b. Geschwindigkeit, Paketfehlerrate, Auslastungsgrad der Verbindung). --> Bei 802.11s Routing ausschließlich in MAC-Ebene, wo diese Parameter bekannt sind |
|||
* auf Standard-WLAN aufgepfropfter IP-Routing-Algorithmus stößt schnell an Performance-Grenzen (weil 802.11-MAC nicht für Multi-Hop-Verbindungen entworfen, denn typisches WLAN bildet Sternstruktur und kein Mesh! ) |
|||
* (802.11s macht Vorschlag für Routingprotokoll, schreibt Verwendung aber nicht zwingend vor) |
|||
* Unterschiede SEEMesh vs. Wi-Mesh: |
|||
** SEEMesh verwendet 2 Funkmodule, um Zellen- und Mesh-Verkehr zu trennen. Betrieb mit einem Modul zwar möglich, soll aber Ausnahme bleiben |
|||
** Wi-Mesh: ein Funkmodul. |
|||
*** Trennt beim Access Point auf einem einzelnen Funkkanal den Meshverkehr zeitlich vom Zellenverkehr , |
|||
*** außerdem Änderungen am MAC-Layer |
|||
*** Phasen entstehen, in denen die Stationen Pause haben und Mesh-APs den Funkkanal exklusiv nutzen. Dank der MAC-Eingriffe können diese dann einen höheren Durchsatz als Standard-WLAN erreichen. |
|||
== Quellen: == |
== Quellen: == |
||
* 802.11® Wireless Networks: The Definitive Guide, Second Edition by Matthew S. Gast, - O'Reilly Media, Inc., 2005 |
|||
* 802.11 Wireless LAN Fundamentals by Jonathan Leary, Pejman Roshan, - Cisco Press., 2003; |
|||
* und verschiedenste Einträge auf |
|||
** de.wikipedia.org |
|||
** en.wikipedia.org |
|||
** www.heise.de |
Latest revision as of 19:06, 19 October 2006
"Traditionelles" 802.11
IEEE 802.11 fasst Protokolle und Techniken für die Implementation drahtloser Netzwerke zusammen. Es gilt damit als Synonym für Drahtlosnetzwerke, welche im Alltag auch durch die Phrasen "wireless ethernet", "WLAN" oder "Wi-Fi" (geprägt durch die "Wi-Fi Alliance", oder auch wireless fidelity) bezeichnet werden.
IEEE 802.11 als Teil von IEEE 802
Das Institute of Electronics and Electrical Engineers (IEEE) befasst sich mit der Entwicklung und Standardisierung technischer Spezifikationen zumeist elektonischer Art. Das IEEE gliedert sich dabei in verschiedene Projektgruppen, welche durch eine Zahl ausgezeichnet werden. Im Fall 802.11 gibt 802 dabei die Projektgruppe für die Entwicklung von Local Area Networks (LAN) an. Diese unterteilt sich wiederum in verschiedene Arbeitsgruppen, wobei die Arbeitsgruppe 11 der genannten Projektgruppe ihren Fokus auf die Entwicklung von Standards für drahtlose Netzwerke legt.
Die ersten Ergebnisse der Arbeitsgruppe lagen '97 mit der Spezifikation unter dem Namen 802.11-1997 vor. Es folgten 802.11-1999 mit nur wenigen Änderungen und 802.11-2003, welches die aktuellste Revision darstellt.
Innerhalb der Arbeitsgruppe gibt es dann weitere Fraktionen (sogenannte task groups), die sich mit einzelnen Aspekten der Technik der Drahtlosnetzwerke befassen.
die 802.11 Task Groups:
802.11 | First standard (1997). Specified the MAC and the original slower frequency-hopping and direct-sequence modulation techniques. |
802.11a | Second physical layer standard (1999), but products not released until late 2000. |
802.11b | Third physical layer standard (1999), but second wave of products. The most common 802.11 equipment as the first book was written. |
TGc | Task group that produced a correction to the example encoding in 802.11a. Since the only product was a correction, there is no 802.11c. |
802.11d | Extends frequency-hopping PHY for use across multiple regulatory domains. |
TGe (future 802.11e) | Task group producing quality-of-service (QoS) extensions for the MAC. An interim snapshot called Wi-Fi Multi-Media (WMM) is likely to be implemented before the standard is complete. |
802.11F | Inter-access point protocol to improve roaming between directly attached access points. |
802.11g | Most recently standardized (2003) PHY for networks in the ISM band. |
802.11h | Standard to make 802.11a compatible with European radio emissions regulations. Other regulators have adopted its mechanisms for different purposes. |
802.11i | Improvements to security at the link layer. |
802.11j | Enhancements to 802.11a to conform to Japanese radio emission regulations. |
TGk (future 802.11k) | Task group to enhance communication between clients and network to better manage scarce radio use. |
TGm | Task group to incorporate changes made by 802.11a, 802.11b, and 802.11d, as well as changes made by TGc into the main 802.11 specification. (Think "m" for maintenance.) |
TGn (future 802.11n) | Task group founded to create a high-throughput standard. The design goal is throughput in excess of 100 Mbps, and the resulting standard will be called 802.11n. |
TGp (future 802.11p) | Task group adopting 802.11 for use in automobiles. The initial use is likely to be a standard protocol used to collect tolls. |
TGr (future 802.11r) | Enhancements to roaming performance. |
TGs (future 802.11s) | Task group enhancing 802.11 for use as mesh networking technology. |
TGT (future 802.11T) | Task group designing test and measurement specification for 802.11. Its results will be standalone, hence the uppercase letter. |
TGu (future 802.11u) | Task group modifying 802.11 to assist in interworking with other network technologies. |
Beziehung von 802.11 zum ISO/OSI-Modell
Die in IEEE 802 (Local Area Networks) spezifizierten Protokolle beziehen sich nur auf die zwei unteren Schichten des OSI-Modells: Physical und Data Link Layer. IEEE 802 beschreibt den (in diesem Zusammenhang eher theoretischen) Medienzugriff (MAC) und die physische Komponente des Datenversand und -empfang (PHY).
physikalische Schichten:
- FHSS – frequency-hopping spread-spectrum
- DSSS – direct-sequence spread-spectrum
- mit 802.11b -> HR/DSSS – high-rate DSSS
- mit 802.11a -> OFDM – orthogonal frequency division multiplexing
- 802.11g abwärts-kompatibel zu 802.11b, nutzt ausserdem auch OFDM
Struktur eines Wireless Network
Ein Drahtlosnetzwerk besteht nach IEEE 802.11 aus den wesentlichen Komponenten Stationen, Basisstationen, dem drahtlosen Übertragungsmedium und dem Verteilungssystem. Die Stationen bezeichnen dabei Computer im WLAN bzw. anders geartete Clients. Basisstationen, oder auch Access Points, agieren als Brücken für die Kommunikation zw. Stationen untereinander respektive Stationen und externen Hosts. Ursprünglich findet sich die Funktionalität eines AP in einem Gerät, im Zuge neuerer Entwicklungen kann diese aber auch auf "thin" APs und AP-Controller aufteilen.
Das Verteilungssystem, oder Distribution System, hat die Aufgabe die Kommunikation vom AP zur Aussenwelt bzw. von APs untereinander zu ermöglichen.
Typen von Netzwerken
Es gibt mehrere Arten von Drahtlosnetzwerken, die Unterschiede aufweisen und teilweise voneinander abhängen.
Grundlage eines Drahtlosnetzwerk ist das Basic Service Set - BSS:
- Gruppe von Stationen, die miteinander kommunizieren
- Kommunikation innerhalb der BSA (Basic Service Area), durch Ausbreitungseigenschaften der Funkstrahlen definierter Raum.
Unabhängiges Netzwerk, Independent BSS (IBSS, Ad-Hoc Netzwerke)
Hier wird auf den Einsatz eines APs verzichtet, stattdessen kommunizieren die Stationen direkt untereinander. Solche Netzwerke werden typischerweise für wenige Stationen und einen geringen Zeitraum eingerichtet.
Infrastruktur Netzwerk, Infrastructure BSS
Dieser Typ erfordert den Einsatz von APs, jegwede drahtlose Kommunikation involviert die Basisstation. Eine Station gilt als verbunden, wenn diese mit dem AP assoziiert ist. Damit ist die BSA als der Bereich definiert, der vom Sende- und Empfangsbereich des AP aufgespannt wird.
Somit benötigt jede Station-zu-Station-Kommunikation zwar 2 Hops, allerdings reduziert die zentrale Nachrichtenübermittlung die typischen Probleme eines Ad-Hoc-Netzwerks: Die Kommunikation aller Stationen untereinander hängt nicht mehr von sämtlichen Positionsvektoren aller Paare von Stationen ab, sondern beruht auf der Verbindung einer Station zum AP - entweder man ist mit dem AP "verbunden" oder nicht. Dies ermöglicht auch den Einsatz erweiterter Techniken, wie den Einsatz eines Stromsparmodus der Stationen, in denen der AP Datenpakete für die Stationen gezielt puffern muss.
Ein Novum stellt die Benutzung eines AP für die Verwaltung mehrerer BSS (multi-BSS) oder "virtual APs" dar. Dabei simuliert eine phys. Basisstation eine Menge von Basisstationen mit unterschiedlicher Konfiguration. Eine Möglichkeit der Netzwerk-Strukturierung besteht hier in der Kombination mit VLANs.
ESS
Extended Service Sets dienen der Erweiterung von BSS's, wobei mehrere BSS's in einem ESS zusammengefasst werden können. Dies ist die höchst-levelige logische Abstraktion eines Netzwerks in der 802.11-Spezifikation. Jeder Access Point, der ein BSS in einem ESS bedient kommuniziert mit den anderen BSS's (wobei diese jeweils durch andere AP's bedient werden) über ein Backbone-Netzwerk, das Teil des Verteilungssystem (Distribution System) ist. Ein ESS wird über eine eindeutige ID identifiziert, der SSID (Service Set Identifier = Netzwerkname).
Distribution system
Das Verteilungssystem stellt auf logischer Ebene die Verbindung zwischen Ethernet und Drahtlosnetzwerk her, agiert also als Bridge zum Backbone-Netzwerk. Im Falle eines ESS mit mehreren APs ist das Verteilungssystem, kurz DS, ausserdem für die Verbindung der APs verantwortlich; es aggregiert damit mehrere BSS's zu einem ESS. Die Kommunikation der APs untereinander wird über ein Inter Access Point Protocol (IAPP) geregelt. Dabei müssen neben dem Datenaustausch hauptsächlich die Assoziationen der Stationen mit ihren jeweiligen APs und Transitionen von Assoziationen kommuniziert werden. Das IAPP wird im IEEE 802.11F spezifiziert, wobei die technischen Vorgaben kaum umgesetzt wurden. Zumeist finden sich proprietäre Lösungen im Einsatz.
Die Kommunikation mehrerer APs kann sowohl über ein Backbone-Ethernet, als auch über ein drahtloses DS stattfinden. Im letzten Fall spricht man von einem WDS (wireless DS). Bei der Nutzung des drahtlosen Mediums ergeben sich jedoch neue Problemstellungen, da Inter-AP-Kommunikation denselben mediengebundenen Hürden unterliegt wie die Kommunikation von Stationen mit ihren APs. Zudem teilen sich diese Kommunikationsdomänen einen Kanal, was in Hinsicht auf Bandbreite, Leistungsfähigkeit und Stabilität des Netzes eine intensivere Planung der Netzstruktur erfordert.
Zugriffskontrolle in 802.11
CSMA/CA
Der Zugriff auf das drahtlose Medium wird in 802.11-Netzwerken nach dem Paradigma CSMA/CA geregelt. CSMA/CA steht für Carrier Sense Multiple Access with Collision Avoidance und sieht im Gegensatz zu CSMA/CD (Collision Detection, Verwendung bei 802.3 LAN) nicht nur das Erkennen von Kollisionen, sondern auch das geziehlte Verhindern von Kollisionen durch gewisse Timingparameter vor. Dass für drahtlose Netzwerke ein neuartiges Zugriffsprotokoll gewählt wurde hängt von der Charakteristik des benutzten Mediums ab: In WLANs benutzen alle Stationen in einem BSS denselben Kanel, was Kollisionen besonders teuer macht. In drahtgebundenen LANs schließt die Verwendung von Switches praktische jede Kollisison aus, bzw. ein auftretender Konflikt betrifft nur die sendende Station selbst. Ein weiteres Problem stellt die Ausbreitung der Datenpakete dar: 2 Kommunikationsendpunkte im Raum haben jeweils ihren eigenen Funkbereich, was zu folgendem Problem führt:
Das "Hidden Node"-Problem und RTS/CTS
Das Problem:
Man stelle sich 3 Kommunikationspartner (1, 2 und 3) vor. 1 kann direkt mit 2 kommunizieren, 2 ebenso direkt mit 3; allerdings sind 1 und 3 soweit von einander entfernt, dass keine direkte Kommunikation zwischen beiden möglich ist. Sendet 1 Daten an 2, so erfährt 1 nicht, dass 3 im selben Augenblick mit 2 kommunizieren könnte. Passiert dies und 1 und 3 senden gleichzeitig Daten an 2, so kollidiert der Medienzugriff von 1 und 3 aus Sicht von 2.
Die Lösung: RTS/CTS
RTS = request to send, CTS = clear to send.
Das sind Kontrollpakete, die vor der eigentlichen Kommunikation zw. 2 Stationen gesendet werden. Der sendende Host schickt dabei ein RTS-Paket an die empfangende Station und informiert alle Stationen in seinem Funkbereich von der anstehenden Kommunikation. Der Empfänger antwortet mit CTS und informiert ebenso alle Stationen in seinem Funkbereich. Danach ist das Medium für die Kommunikation vorbereitet.
Die RTS/CTS-Sequenz propagiert verschiedene Parameter, wie die geschätzte Dauer des anstehenden Datenaustauschs. Auf diese Weise können sehr effektiv längere Übertragungen initial abgesichert werden. Die Verwendung dieser Sequenz ist allerdings optional, da sie zusätzlichen Funkaufwand erfordert und damit nur in eher stark ausgelasteten Umgebungen von Vorteil ist. Doch selbst in Hochverkehrsbereichen ist RTS/CTS nicht immer sinnvoll: Ist die AP-Dichte hoch genug, so liegen meist die Funkbereiche aller Teilnehmer eines BSS weit genug zusammen um das Hidden-Node-Problem zu umgehen. Hier erhöht RTS/CTS nur zusätzlich das Datenaufkommen. Die Steuerung dieses Mechanismus kann meist über den Treiber eines WLAN-Gerätes vorgenommen werden.
Coordination Functions und Timing
MAC-Zugriffsmodi: Coordination Functions
Zugriff wird kontrolliert durch Coordination Functions:
DCF – distributed coordination function
- Standard CSMA/CA
- vor Sendung eines Frames lauschen, ob Medium frei
- wenn Frame übertragen wurde, warten alle Stationen im BSS ein zufälliges Intervall (Minimum ist festgelegt), bis sie senden
- verhindert (fast sicher) gleichzeitiges Senden, was einzige Möglichkeit der Kollision birgt
PCF – point coordination function
- konkurrenzfreie Koordination, gewährleistet QoS
- selten implementiert
- sog. Point Coordinator verwaltet den tokenbasierten Ansatz
- gibt Sendetoken an jede Station einzeln
- nicht jede Station muss PCF unterstützen
- nach einer CFP (contention-free period) kommt eine contention-period in der wie bei DCF gearbeitet wird
- in der CFP können nicht-PCF-Stationen nicht senden, da Dauer der Tokenübergabe geringer als minimale Wartezeit bei DCF
HCF – hybrid coordination function
- hybrider Ansatz der beiden oben genannten
- noch nicht voll standardisiert, wird jedoch Teil von 802.11e
Timing beim Zugriff auf das MAC: NAV
- virtuelles Carrier Sensing
- jeder Frame enthält Angaben, wie lang seine Übertragung und die folgender Pakete (inkl. ACKs) dauert
- Stationen lesen den Wert und warten entsprechend
Wartezeiten: Interframe Spacing
- SIFS < PIFS < DIFS
- short interframe space (SIFS)
- kürzestes Intervall nach Framesendung, für high-priority Verkehr
- PCF interframe space (PIFS)
- DCF interframe space (DIFS)
- extended interframe space (EIFS)
- nicht festgelegte Dauer
- für Fehler in der Übertragung
MAC-Layer und Dienste in 802.11
Übersicht
- 802.11 definiert Dienste, die Netzwerke anbieten müssen:
- Distribution:
- Kommunikation von Stationen mit anderen Stationen oder externen Hosts
- Integration
- von 802.11-Netzwerken in Andere und umgekehrt
- Assoziation
- „Registration“ am AP, notwendig für Datenverkehr
- entspr. „Kabel einstecken“ in LANs
- angestoßen von Stationen
- Reassoziation
- bei Transition einer Station zw. BSS's im selben ESS
- Disassoziation
- Authentifzierung
- authentifizieren eines Benutzers im WLAN
- soll „physikalische Sicherheit“ eines verkabelten Netzes ersetzen
- Deauthentifizierung
- Vertraulichkeit (confidentiality)
- Verschlüsselung der Daten
- MSDU delivery == MAC Service Data Unit delivery
- einfach Datenverkehr zw. Stationen und APs
- Spektrenverwaltung (Transmit Power Control, Dynamic Frequency Selection nach 802.11h) (nur in Europa)
- Distribution:
- davon Stations-seitig (von Stationen und APs angeboten):
- Frame-Zustellung
- (De)Authentifizierung
- Vertraulichkeit
- Spektrenverwaltung (TPC, DFS)
- Distributionssystem-seitig (verbinden APs zu einem DS):
- Integration (von wired und wireless Netzen)
- Distribution
- Managen von Assoziationen (Assoz., Reassoz., Disassoz.)
Frame-Formate
Arten von Frames
- Data- und Control Frames für Auslieferung von Daten und Kontrolle des Datenflusses
- Data Frames
- Transport von Daten
- Control Frames
- AreaClearing functions
- channel acquisition
- carrier sensing
- ACKs
- Management Frames
- supervisory functions
- join, leave network; move assocs
Fragmentation
- nötig, weil:
- große Frames sonst nicht „aufs Medium passen“
- Durchsatz in belasteten Umfeldern erhöht werden kann
- fragmentiert werden Pakete größer als fragmentation threshold
- dieser festgelegt durch Admin bzw. verringert von jeder Station
- Fragmente eines Frames haben:
- selbe Frame Sequence Number
- inkrementelle Fragment Number
- RTS/CTS und Fragmentation
- Thresholds für RTS/CTS und Fragmentation meist gleich
- bei Fragment Bursts wird RTS/CTS angewendet
allgemeines Frame-Format
- enthält einige typische Felder nicht
- Präambel ist Teil des physischen Layer
- Type/Length werden im Datenteil gekapselt
- 4 Adressfelder, die nicht immer genutzt werden
- Frame Control Field:
- Protocol:
- bisher nur 00 definiert, weitere für evtl. spätere 802.11 Revisionen
- Type & Subtype:
- Protocol:
Subtype value | Subtype name |
Management frames (type=00) | |
0000 | Association request |
0001 | Association response |
0010 | Reassociation request |
0011 | Reassociation response |
0100 | Probe request |
0101 | Probe response |
1000 | Beacon |
1001 | Announcement traffic indication message (ATIM) |
1010 | Disassociation |
1011 | Authentication |
1100 | Deauthentication |
1101 | Action (for spectrum management with 802.11h, also for QoS) |
Control frames (type=01) | |
1000 | Block Acknowledgment Request (QoS) |
1001 | Block Acknowledgment (QoS) |
1010 | Power Save (PS)-Poll |
1011 | RTS |
1100 | CTS |
1101 | Acknowledgment (ACK) |
1110 | Contention-Free (CF)-End |
1111 | CF-End+CF-Ack |
Data frames (type=10) | |
0000 | Data |
0001 | Data+CF-Ack |
0010 | Data+CF-Poll |
0011 | Data+CF-Ack+CF-Poll |
0100 | Null data (no data transmitted) |
0101 | CF-Ack (no data transmitted) |
0111 | CF-Ack+CF-Poll (no data transmitted) |
1000 | QoS Datac |
1001 | QoS Data + CF-Ackc |
1010 | QoS Data + CF-Pollc |
1011 | QoS Data + CF-Ack + CF-Pollc |
1100 | QoS Null (no data transmitted)c |
1101 | QoS CF-Ack (no data transmitted)c |
1110 | QoS CF-Poll (no data transmitted)c |
1111 | QoS CF-Ack+CF-Poll (no data transmitted)c |
- ToDS, FromDS:
- geben an, ob ein Frame fürs DS bestimmt ist
- in Infrastruktur-Netzen ist immer eins von beiden gesetzt
- FromDS, ToDS = 0
- Management und Control-Frames
- Daten-Frames in einem IBSS
- FromDS = 1, ToDS = 0
- Daten-Frames, die für WLAN Station bestimmt sind
- FromDS = 0, ToDS = 1
- Daten-Frames, die von WLAN Station kommen
- FromDS, ToDS = 1
- Daten-Frames in einer „Wireless Bridge“
- ToDS, FromDS:
- More Fragments
- wie in IP
- 1 = es kommen weitere Fragmente
- wird nur von einigen Managementframes und großen Daten-Frames verwendet, meist ist Daten-Frame-Größe = Ethernet-Frame-Größe
- More Fragments
- Retry
- 1 = dieser Frame ist eine Sendewiederholung
- Retry
- Power Management
- 1 = Station geht nach atomarem Frame-Austausch in Powersave-Modus
- niemals gesetzt bei Frames vom AP
- Power Management
- More Data
- 1 = es liegen weitere gepufferte Frames im AP vor
- wird nur bei Frames verwendet, die an Powersave-Stationen geschickt werden
- More Data
- Protected Frame
- 1 = Frame wird durch Link-Layer-Sicherheitsprotokolle geschützt
- Protected Frame
- Order
- 1 = strikte Ordnung ist aktiv
- Frames und Fragmente können sonst auch ungeordnet übertragen werden
- Order
- Duration/ID Field:
- Duration
- setzt NAV in allen Stationen im BSS (siehe NAV)
- Wert in Mikrosekunden (10-6)
- CFP – contention-free period
- bei Verwendung von PCF
- Wert = 32768, wenn als NAV interpretiert (für Stationen, die eine Beacon-Sendung verpasst haben, in der CFP eingeleitet wird ... diese werden dann sehr lang)
- PS-Poll Frames
- wird von schlafenden Stationen gesendet, die gerade aufwachen
- AID gibt Assoziations-ID an -> gibt an, zu welchem BSS die Station gehört (falls im Schlaf BSS-Transition) (diese wird bei Assoziation vom AP bezogen)
- nur Werte von 1 – 2007, alle anderen sind reserviert
- Duration
- 4 Adressfelder
- enthalten 48Bit MAC Adressen
- je nach Netzwerktyp und Datenrichtung verwendet (nach ToDS, FromDS):
Function | ToDS | FromDS | Address 1 (receiver) | Address 2 (transmitter) | Address 3 | Address 4 |
IBSS | 0 | 0 | DA | SA | BSSID | Not used |
To AP (infra.) | 1 | 0 | BSSID | SA | DA | Not used |
From AP (infra.) | 0 | 1 | DA | BSSID | SA | Not used |
WDS (bridge) | 1 | 1 | RA | TA | DA | SA |
- verschiedene Zwecke:
- Zieladresse:
- wie Ethernet, gibt finalen Empfänger an
- für Station -> AP: MAC-Adresse des Hosts im Backbone (zb Router)
- Empfängeradresse:
- für AP -> Station: = Zieladresse
- für Station -> AP: MAC-Adresse des AP
- Quelladresse:
- gibt Quellstation an
- Transmitter-Adresse
- MAC-Adresse des WNICs, der Frame überträgt
- wird nur bei Wireless Bridges benutzt
- BSSID
- wird genutzt um verschiedene WLANs im selben Bereich zu unterscheiden
- in Infrastruktur-Netzen: BSSID = MAC des APs
- in ad-hoc-Netzen: zufällig generiert mit Universal/Local-Bit gesetzt (vermeidet Konflikt mit phys. MAC-Adressen)
- Zieladresse:
- verschiedene Zwecke:
- Sequence Control Field:
- benutzt für Defragmentation und zum Verwerfen doppelter Frames
- nicht benutzt in Control-Frames
- sequence number
- 0 – 4095
- beginnt bei 0 und wird pro highlevel-Paket um 1 inkrementiert
- bleibt gleich bei erneuter Sendung und Fragmenten eines Pakets
- fragment number
- gibt Nummer des Fragments an
- Frame body
- kapselt higher-level Daten
- eigentlich maximal 2304 Bytes
- tatsächlich muss mehr transportiert werden können um Sicherheitsprotokolle und QoS zu erlauben
- inkl. 802.2 LLC header bleiben dann 2296 Bytes Payload
- es gibt weiterhin kein Typfeld, dass das gekapselte Protokoll angibt -> weiterer Header am Anfang des Payload benötigt
- Frame Check Sequence – FCS
- CRC (cyclic redundancy check) zur Überprüfung des Inhalts
- enthält alle Felder des MAC-Headers und der Payload
- eigentlich gleich dem 802.3-Feld, jedoch andere MAC-Header
- zwingt APs zur Neuberechnung
Management
Management-Frames übernehmen Funktionen, die bei wired-Netzen physikalisch umgesetzt sind.
Scannen eines Netzwerks: Probes und Beacons
- Parameter fürs Scannen:
- BSS Type (independent, infrastructure)
- BSSID (individual, broadcast for all)
- SSID oder ESSID (specific network name, broadcast for all)
- scan type (active, passive)
- channel list (or hop pattern for freq. hopping networks)
- probe delay
- minChannelTime, maxChannelTime
Passive Scanning
- jeden Channel eine bestimmte Zeit belauschen
- auf Beacons warten, diese enthalten alle relevanten Werte
- hidden SSID's:
- verhindern passives Scannen, da die SSID nicht mehr in den Beacons übermittelt wird
- wird jedoch in Probe Responses gesendet -> Active Scanning
Active Scanning
- für jeden Channel einzeln durchzuführen:
- Channel abhören, bis Paket eintrifft oder probe delay timer abläuft
- trifft Paket ein, so ist Channel in Benutzung und kann geprobed werden
- Probe Request senden
- minChannelTime abwarten
- wenn nix passiert, dann ist Channel nicht in Benutzung
- wenn Frames verkehren, dann warte bis maxChannelTime und werte jede Probe Response aus
Beacon Frame
- zeigt Existenz eines Netzwerks an
- werden regelmäßig (in Infrastr. von APs) gesendet
- enthalten Parameter zur Konfiguration für möglichen Netzwerkzugang für Clients
- Felder:
- Capability Info:
- ESS/IBSS – exclusive: infrastruktur oder ad-hoc
- privacy – WEP oder nicht?
- SSID – Netzwerkname = String, max 32 chars
- FH – für FrequencyHopping Networks
- DS – Channel Nummer für direct sequence networks
- CF – für contention free
- TIM – traffic indication map, benutzt bei power-save-mode
- Channel Switch – für Umschalten des Kanals
- Quiet – Stilllegung des Channels für Maßnahmen bei Radar
- TPC – Transmit Power Control, fordert Funkverbindungsmanagementinfos an
- ERP – für 802.11g, Extended Rate PHY
- Extended Rates erweitert Supported Rates Feld -> Auskunft über mögliche Datenraten
- RSN – robust security network
- Angabe von Cipher-Algorithmen, z. B .:
- WEP-40
- TKIP
- CCMP
- WEP-104
- authentication types:
- 802.1X or PMK caching
- Pre-shared key
- Angabe von Cipher-Algorithmen, z. B .:
- Capability Info:
Probe Request Frame
- geben Auskunft über die Möglichkeiten des Clients
- versehen mit SSID eines Netzes oder broadcast SSID für alle Netze
Probe Response Frame
- gleicher Aufbau wie Beacon-Frame
Joining a Network: Authentifizierung und Assoziation
Folgende Schritte:
- Authentication bzw. Pre-Authentication
- Association
802.11 Authentifizierung
- Open-System Authentication:
- garantiert in keiner Weise Sicherheit, diese muss auf Basis dieser Auth aufgebaut werden
- Anfrage vom Client an AP via Management Frame Typ: Authentication
- Antwort via selbem Frametyp
- Shared-Key Authentication:
- benutzt WEP
- Challenge wird Cleartext an Client gesendet, dieser verschlüsselt diesen mit WEP-Key und sendet ihn zurück an AP
- diese Methode ist allerdings recht verwundbar:
- Challenge Cleartext und Challenge Encrypted können belauscht werden
- aus beiden kann der benutzte Keystream generiert werden:
- diese Methode ist allerdings recht verwundbar:
- ermöglicht zwar nicht die Generation des WEP-Keys aus dem Keystream, dennoch kann sich Attacker authentifizieren
- kann keine Datenpakete behandeln, da denen anderer Keystream zugrunde liegt
Preauthentication
- wird benutzt um Assoziation zu beschleunigen
- Auth vor Assoc ... vor allem bei Reassoc wird hiermit deutliches Lag verhindert
- 802.11 regelt nicht, wann authentifiziert und wann assoziiert werden muss -> auth kann lang vor assoc passieren
Association-Prozedur
- wenn auth abgeschlossen kann assoc stattfinden:
- Association Request Frame:
- AP prüft CapInfo, SSID und Supported Rates; diese müssen stimmen, damit Station assoziiert werden kann.
- Association Response Frame:
Reassociation-Prozedur
- Reassociation Request Frame:
Mobility Support: Transitions
Transitionsarten in 802.11:
- Keine Transition (ist eben keine Transition, aber in 802.11 vereinbart)
- BSS Transition:
- Stationen prüfen ständig Signalstärke und Verbindungsqualität zu allen APs
- findet sich ein „besserer“ AP im ESS, so kann Transition stattfinden (je nach signalstärke, verlorenen paketen etc)
- um neuen AP ausfindig zu machen, existieren zwei verfahren, beide können aktiv oder passiv ausgeführt werden:
- aktiv:
- Client sendet probe-frames auf allen Kanälen
- aktiv:
- passiv:
- Client verweilt länger pro kanal, um beacon-frames der AP's zu empfangen --> langsamer & stromsparender
- passiv:
- AP-Erkennung vor Transition:
- Client sucht sich vor transition ziel-AP aus
- Nachteil: client kann während der AP-Suche keine Nutzdaten empfangen oder senden
- AP-Erkennung vor Transition:
- AP-Erkennung während Transition:
- Client sucht neuen AP nach Deassoziation vom alten
- Nachteil: transition dauert länger (wg. AP-Suche)
- AP-Erkennung während Transition:
- innerhalb eines ESS wird MAC-Layer-Mobility unterstützt
- benötigt Kooperation der APs (ist jedoch in 802.11 nicht konkret festgehalten) --> propietäre protokolle
- benötigt OSI-Layer-2-Verbindung der APs (Verbindung darf nicht gerouted sein)
- bei Roaming Datenverlust wahrscheinlich, muß von höheren Schichten abgefangen werden
- innerhalb eines ESS wird MAC-Layer-Mobility unterstützt
- ESS Transition:
- wird nicht unterstützt, d.h. es ist zwar möglich das ESS zu wechseln, jedoch werden dabei vorhandene Verbindungen unterbrochen
- Abmeldung im ESS1, Anmeldung im ESS2 (Verfahren zb Mobile-IP)
Vertraulichkeit und Zugangskontrolle
Da das Medium im Gegensatz zu Kabelnetzen offen für alle ist, wird eine Möglichkeit benötigt, die Vertraulichkeit und Echtheit von Datenverkehr sicherzustellen...
WEP
Bei diesem Verfahren müssen die Schlüssel manuell an alle Teilnehmer verteilt werden (PSK - pre shared keys), eine dynamische (und damit leichter zu administrierende) Schlüsselverteilung ist im ursprünglichen Entwurf nicht vorgesehen, wurde jedoch teilweise trotzdem implementiert (Dynamic WEP).
WEP gilt mittlerweile als „geknackt“. Allerdings ist bei diesem Verfahren der Rechenaufwand im Vergleich zu den moderneren geringer, deshalb ist WEP für schwachbrüstige Geräte wohl immer noch eine Alternative.
802.11i
- neuer Verschlüsselungs-Ansatz
- Temporal Key Integrity Protocol TKIP
- Schlüssel ändert sich je übertragene 10kB
- CCMP (Counter Mode with CBC-MAC) auf Basis von AES ersetzt inherent unsicheres WEP
- Authentication über 802.11X oder PSK (Pre-Shared-Keys)
- PSK: vorher manuell verteilter Schlüssel (Rückwärtskompatibilität, kleine Netze)
- 802.11X:
- Authentifizierung über Authenticator, der mittels RADIUS-Server (Remote Authentication Dial-In User Service) die durch Supplicant übermittelten Authentifizierungsinformationen prüft und gegebenenfalls Zugriff auf durch Authenticator angebotenen Dienste zulässt
- RADIUS emöglicht zentrale Benutzer-Administration
- basiert auf EAP (Extensible Authentication Protocol), das verschiedene Authentifizierungs-Methoden anbietet
- WPA:
- noch WEP, allerdings mit TKIP
- WPA2: vollständige Implementation von 802.11i
- CCMP mit TKIP
- WPA:
Grundlegende Flusssteuerung
Control-Frames
- ToDS und FromDS beide 0, können nur von Stationen kommen und richten sich „and Medium“, nicht ans DS
- niemals fragmentiert
- keine Retransmission
RTS/CTS
Diese dienen dem Clearing eines Channels -> Ankündigung "ich will jetzt funken".
- RTS:
- CTS:
ACK
- bestätigen jeden gerichteten datenframe (plain, rts/cts-initiiert, fragmentierte frames), management frames und ps-poll frames
- QoS-Erweiterungen können Notwendigkeit der Bestätigung (jedes!) Frames lockern
Transfer von Daten
Prinzipien
Broadcast Data, Multicast Data und Management Frames
- Management: Beacon, Probe Request, IBSS ATIM
- Datenaustausch ohne ACK's, keine Fragmentation: NAV = 0
Unicast Data (Management und Daten)
- IEEE-Jargon: directed data
- müssen ge'ACK'ed werden
- Fall 1: basic ACK, final fragment (oder keine Fragmentation):
- Fall 2: Fragmentation:
- Fall 3: RTS/CTS:
- Fall 4: RTS/CTS mit Fragmentation:
Distribution: Integration bzw. Einkapselung von Ethernet Frames
Prinzip
- 802.11 als 802 link layer, kann alle network-layer Protokolle kapseln
- benötigt 802.2 LLC Kapselung
- 2 Methoden des Verpackens:
- 802.1H (auch „tunnel encapsulation“)
- RFC 1042 (auch „IETF encapsulation“)
- beide Abkömmlinge des 802.2 Sub-Network Access Protocol (SNAP)
- welche Methode wird gewählt?
- ursprünglich APs mit Auswahlmöglichkeit
- heute eher Übernahme von Microsofts Variante (die sogar im Zertifizierungsprogramm der WiFi Alliance als Test vorkommt)
- AppleTalk und IPX via 802.1H
- andere via RFC 1042
Ablauf des Bridging zwischen 802.11 und Ethernet
- wireless -> wired
- Frame wird empfangen, Integritätscheck (physical layer check und FCS)
- Check ob weiterverarbeitet werden soll
- Frames an AP haben dessen MAC (BSSID) im 1.Adressfeld, andere MAC's sollten verworfen werden
- Duplikate werden verworfen
- Entschlüsseln von LinkLayer-Verschlüsselung
- Defragmentation
- fragmentierte Frames müssen insgesamt auf Integrität gecheckt werden
- MAC Header muss übersetzt werden
- 802.11-Zieladresse(3. Adressfeld) -> Ethernet-Zieladresse
- 802.11-Senderadr.(2. Adressfeld) -> Ethernet-Senderadresse
- Ethernet-Type-Code wird aus SNAP-Header in Ethernet-Frame kopiert; wenn Ethernet selbst SNAP benutzt, so kann kompletter SNAP-Header kopiert werden
- evtl. QoS-Flags für Verkehr aus Funknetzen im Ethernet-Frame setzen
- FCS wird für Ethernet neu berechnet
- Frame wird via Ethernet übertragen
- wired -> wireless
- Frame wird empfangen, Ethernet-FCS-Check
- Check ob Frame an Station assoziiert am AP gerichtet ist
- SNAP Header wird dem Ethernet-Frame vorangestellt
- höherleveliges Paket wird mit SNAP Header umschlossen
- Type-Code wird aus Ethernet-Type-Code-Feld kopiert
- wenn Ethernet auch SNAP-Kapselung fährt, so kann komplettes SNAP-Paket benutzt werden
- Frame wird für Übertragung bereitgestellt -> Transmit-Queue
- Frame erhält Sequence Number
- Integritätscode wird generiert
- evtl. Fragmentierung, Zuweisung von Fragmentnummern
- Frame wird evtl. verschlüsselt
- 802.11 MAC Header wird gebaut
- Ethernet-Zieladresse -> 802.11-Zieladresse (1. Adressfeld)
- BSSID -> 2. Adressfeld (als Sender des Frames im WLAN)
- Ethernet-Quelladresse -> 802.11-Quelladresse (3. Adressfeld)
- Dauer der Übertragung -> Durationfeld
- Flags im Frame Control-Feld werden gesetzt
- FCS wird für 802.11 neu berechnet
- Frame wird via 802.11 übertragen
weitere Dienste
Spectrum-Management
- nur in Europa definiert IEEE 802.11h als obligatorische Erweiterung zu 802.11a (54Mbit-Wlan im 5GHz-Band):
- TPC – Transmit Power Control
- stationsseitige Kontrolle der Sendeleistung
- gegenseitige Interferenz von „Funkern“ verringern/verhindern
- ergo Transmit Power so einstellen, dass es „gerade reicht“
- DFS – Dynamic Frequency Selection
- dyn. Umschalten auf andere Frequenzen, sodass Interferenz mit Radarfrequenzen vermieden wird
- auch gedacht, um Frequenzband gleichmäßig auszulasten
Multirate-Support
- Übertragungsraten ändern sich ständig als Reaktion auf Veränderung der Funkleistung
- 802.11 gibt nur generelle Regeln, wie verhalten werden soll, tatsächliche Datenraten-Auswahl liegt bei den Stationen/APs
- Management der Datenraten:
- jede Station hält Liste von „operational rates“
- Liste von Raten, die Station und BSS benutzen können
- kein Transfer mit höheren Raten
- jedes BSS hält Liste von „basic rates“ - basic rate set
- Liste von Raten, die jede Station im BSS benutzen kann
- für Broad-, Multicast
- für Control Frames, die Datenaustausch starten, wie RTS/CTS
- Unicast Frames können in jeder Rate übertragen werden, die vom Empfänger unterstützt wird
- Antwort Frames, wie CTS und ACK mit Rate aus basic rate set, aber niemals höher, als der initiale Frame der Sequence
- müssen ausserdem dieselbe Modulation wie der erste Frame haben (DSSS, CCK, OFDM)
- jede Station hält Liste von „operational rates“
„Ad-hoc Multi-hop Mesh“-Netzwerke
Besonderheiten
- Netzwerktopologie ist ein vermaschtes (Mesh) Netz von gleichberechtigen mobilen Knoten:
- jedes Endgerät mit einem oder mehreren anderen Endgeräten verbunden
- jeder (in der Praxis: einige Mesh-APs MAP) Knoten agiert als Router für andere, um Daten von nahen Knoten zu anderen zu übertragen, die zu weit weg sind, sie zu erreichen (ad-hoc)
--> der Umweg über feste AP's und die dahinterliegenden DS entfällt also
- Vorteile:
- viele Wege führen zum Ziel, Ausfall eines Weges verkraftbar
- günstigere Lastverteilung: je mehr Teilnehmer, desto mehr mögliche Wege, mehr Bandbreite ,
vorausgesetzt, die durchschnittlichen Wege bleiben kurz --> typische Netzstruktur in der Praxis ist Maschennetz mit „eingesprenkelten“ Gateways, die Zugang zum Internet oder anderem Verteilungsnetz bereitstellen
- Probleme:
- komplexes Routing nötig, da sich wg. Bewegung der Teilnehmer Netzstruktur ständig ändert
- momentan konkurrieren mehr als 70 Layer3-Routing-Protokolle
- Zellen überlappen sich (damit Stationen Kontakt zueinander), weil jedoch Interferenzreichweite höher als Empfangsreichweite, stören sich Stationen, die schon nichts mehr voneinander wissen:
- komplexes Routing nötig, da sich wg. Bewegung der Teilnehmer Netzstruktur ständig ändert
- Stationen können sich zwar nicht mehr hören, wohl aber noch stören...
802.11s
- ist der Entwicklung befindliche IEEE-Standard für ESS-Mesh-Netzwerke
- hat die Vorschläge der “Wi-Mesh Alliance“ und „SEEMesh“ als Grundlage
- hierarchischer Ansatz:
- nur spezielle Stationen bilden das Mesh-WLAN und werden zu Mesh-APs (MAP), verbunden durch ein nun WDS
- dort anmelden können sich Mesh Points (MP), die Daten zwar weiterleiten, aber Stationen keine Möglichkeit zur Assoziierung bieten.
- MAPs können auch Mesh-Portal Dienste bereitstellen
- Gateways in andre Netze wie z.b. Internet
- Datenintegrität und Vertraulichkeit:
- Komponenten von 802.11i wiederverwendet und Schlüssel von zentraler Instanz, z.B.Radius-Server, verwaltet
- Verwendung von mehreren Transceivern pro AP möglich
- Vorgabe von 802.11s 32 Mesh-(Access)-Points (aber keine absolute Grenze).
- Paket braucht bei WLANs solcher Größe max. etwa 4 bis 5 Hops bis zum Ziel
- Wege sollen kurz gehalten werden, um den Vorteil der höheren Bandbreite nicht zunichte zu machen
- herkömmliche Mesh-Verfahren benutzen Routing auf Layer3 (IP)-Ebene, das sich über die Schichtgrenze hinweg zusätzliche Informationen zur Link-Güte aus der MAC-Schicht holen muss.(z.b. Geschwindigkeit, Paketfehlerrate, Auslastungsgrad der Verbindung). --> Bei 802.11s Routing ausschließlich in MAC-Ebene, wo diese Parameter bekannt sind
- auf Standard-WLAN aufgepfropfter IP-Routing-Algorithmus stößt schnell an Performance-Grenzen (weil 802.11-MAC nicht für Multi-Hop-Verbindungen entworfen, denn typisches WLAN bildet Sternstruktur und kein Mesh! )
- (802.11s macht Vorschlag für Routingprotokoll, schreibt Verwendung aber nicht zwingend vor)
- Unterschiede SEEMesh vs. Wi-Mesh:
- SEEMesh verwendet 2 Funkmodule, um Zellen- und Mesh-Verkehr zu trennen. Betrieb mit einem Modul zwar möglich, soll aber Ausnahme bleiben
- Wi-Mesh: ein Funkmodul.
- Trennt beim Access Point auf einem einzelnen Funkkanal den Meshverkehr zeitlich vom Zellenverkehr ,
- außerdem Änderungen am MAC-Layer
- Phasen entstehen, in denen die Stationen Pause haben und Mesh-APs den Funkkanal exklusiv nutzen. Dank der MAC-Eingriffe können diese dann einen höheren Durchsatz als Standard-WLAN erreichen.
Quellen:
- 802.11® Wireless Networks: The Definitive Guide, Second Edition by Matthew S. Gast, - O'Reilly Media, Inc., 2005
- 802.11 Wireless LAN Fundamentals by Jonathan Leary, Pejman Roshan, - Cisco Press., 2003;
- und verschiedenste Einträge auf
- de.wikipedia.org
- en.wikipedia.org
- www.heise.de