LWAPP-Datenverkehrsstudie
Inhalt
Einführung
Der IETF-RFC-Entwurf, der der Arbeitsgruppe Control And Provisioning of Wireless Access Points (CAPWAP) vorgelegt wurde, beschreibt das Light Weight Access Point Protocol (LWAPP) als Protokoll, das entwickelt wurde, um Kommunikationsrichtlinien zwischen Wireless Termination Points (Access Points) und Access Controllern (Wireless LAN Controller) zu definieren. Alle LWAPP-Kommunikation kann in einen der beiden folgenden Meldungstypen klassifiziert werden:
-
LWAPP-Kontrollkanal
-
LWAPP-gekapselte Daten
LWAPP kann entweder im Layer-2- oder Layer-3-Transportmodus betrieben werden. Layer-2-LWAPP-Kommunikation ist in Ethernet-Frames gekapselt und kann mit einem EtherType-Wert von 0x88BB identifiziert werden. Aufgrund der Zuverlässigkeit auf Ethernet ist der Layer-2-LWAPP-Betriebsmodus nicht routingfähig und erfordert Layer-2-Transparenz zwischen den WLCs und APs. Layer 2 wird als veraltet angesehen, und die in dieser Datenverkehrsstudie skizzierten Protokollstatistiken basieren auf dem Layer-3-LWAPP-Transportmodus. Der Layer-3-LWAPP-Transportmodus gibt den Austausch von LWAPP-Nachrichten im IP-Netzwerk in Form von UDP-gekapselten Paketen an. Der LWAPP-Tunnel wird mit der IP-Adresse der WLC-Schnittstelle (ap-manager) und der IP-Adresse des AP verwaltet. Diese Datenverkehrsstudie zeigt die tatsächliche Menge an Overhead auf, die LWAPP-Nachrichten in einem Netzwerk verursachen, sowie eine Baseline für den LWAPP-Betrieb bei einer Standardinstallation.
Hinweis: Die LWAPP-Spezifikation wird ausführlich unter LWAPP-IETF Draft behandelt.
Einrichtung
Dieses Dokument enthält Statistiken, die sich nur auf den Betrieb von LWAPP beziehen, und alle Funktionen, die nicht in der Protokollspezifikation definiert sind, wie z. B. Roaming zwischen Controllern, fallen nicht in den Anwendungsbereich dieses Dokuments. Darüber hinaus umfasst die Datenverkehrsstudie nur den Layer-3-Modus des LWAPP-Betriebs.
Abbildung 1: Einrichtung der LWAPP-Datenverkehrsstudie 
| Schnittstelle/Gerät | IP-Adresse |
|---|---|
| WLC = Management Interface | 192.168.10.102 |
| WLC = ap-manager Interface | 192.168.10.103 |
| AP mit geringem Gewicht | 192.168.10.22 |
Für diese Datenverkehrsstudie wurde die Einrichtung mit nur einem Access Point erstellt, um die Baselines für erste Austausch- und Konfigurationsänderungen festzulegen. Später wurden weitere Access Points hinzugefügt, um die Auswirkungen der Skalierung der Anzahl von Access Points auf die Menge des über die Leitung generierten Datenverkehrs zu ermitteln.
LWAPP-Kontrollkanal
Der WAP verwendet ephemere Ports, wenn er mit dem WLC kommuniziert. Die vom WLC verwendeten Portnummern sind dagegen der UDP-Port 1222 und der UDP-Port 12223 für LWAPP-Daten- bzw. der LWAPP-Kontrollverkehr. Ein LWAPP-Steuerelementrahmen unterscheidet sich von einem LWAPP-Datenrahmen durch das "C"-Bit im Header-Flag-Feld des LWAPP. Bei der Einstellung auf 1 handelt es sich um einen Kontrollrahmen.
Erstmaliger/einmaliger Austausch
LWAPP Discovery (Anforderung und Antwort)
Abbildung 2: LWAPP Discovery Request and Response Packet Flow 
Die vom Access Point gesendeten LWAPP-Erkennungsanfragen dienen dazu, festzustellen, welche WLCs im Netzwerk vorhanden sind.
Ein Discovery Request-Paket beträgt 97 Byte, das den 4-Byte-FCS enthält. Ein Discovery-Response-Paket beträgt 106 Byte, das den 4-Byte-FCS enthält.
Teilnahme an LWAPP (Anfrage und Antwort)
Abbildung 3: LWAPP-Join Request and Response-Paketfluss 
Ein LWAPP-Join-Request-Paket wird vom Access Point verwendet, um dem WLC mitzuteilen, dass er Clients über den Controller bedienen möchte. Die Join-Anforderungsphase wird auch verwendet, um die vom Transport unterstützte MTU zu ermitteln. Die erste Join-Anfrage, die vom Access Point gesendet wird, wird immer mit einem Testelement von 1596 Byte gepaart. Je nachdem, wie der Transport zwischen dem Access Point und dem Controller eingerichtet wird, können diese Verbindungsanforderungen auch fragmentiert werden. Wenn für die erste Anforderung eine Join-Antwort empfangen wird, leitet der Access Point Frames ohne Fragmentierung weiter. Die Join-Antwort initiiert außerdem den Heartbeat-Timer (ein 30-Sekunden-Wert), der nach Ablauf die WLC-AP-Sitzung löscht. Der Timer wird nach Erhalt der Echo Request oder Acknowledgement aktualisiert.
Wenn die erste Join-Anforderung keine Antwort liefert, sendet der Access Point eine weitere Join-Anfrage mit dem Testelement, wodurch die Gesamt-Payload auf 1.500 Byte steigt. Wenn die zweite Verbindungsanforderung auch keine Antwort liefert, setzt der Access Point den Zyklus zwischen den großen und den kleinen Paketen fort und endet schließlich mit dem Neustart von der Erkennungsphase.
Die Paketgrößen für die Join-Anforderung und die Antwortnachrichten variieren je nach Beschreibung, aber der für diese Datenverkehrsstudie zwischen dem AP und dem WLC (ap-manager-Schnittstelle) erfasste Paketaustausch beträgt 3.000 Byte.
LWAPP-Konfiguration
Abbildung 4: LWAPP Configure State und AP Provisioning Packet Flow 
Die LWAPP-Konfigurationsanforderungen und -antworten werden zwischen den Access Points und den Controllern ausgetauscht, um die von einem Access Point angebotenen Services zu erstellen, zu ändern (aktualisieren) oder zu löschen.
Im Allgemeinen sendet ein WAP eine Konfigurationsanfrage, um seine aktuelle Konfiguration an seinen WLC zu senden.
Die Konfigurationsanforderung kann in zwei Szenarien gesendet werden:
-
In der Anfangsphase, in der der Access Point einem Controller beitritt und mit allen 802.11-Einstellungen bereitgestellt werden muss, die auf dem Controller konfiguriert sind.
-
Bei On-Demand-Verwaltungsänderungen, z. B. Änderung eines WLAN-Parameters
Der Typ der LWAPP-Konfigurationsantwort wird vom WLC an den AP gesendet, um den Erhalt der LWAPP-Konfigurationsanforderung vom AP zu bestätigen. Dies bietet dem WLC die Möglichkeit, die angeforderte Konfiguration des Access Points zu überschreiben. Ein solcher Frame enthält keine speziellen Nachrichtenelemente.
Der erste Austausch zwischen dem Access Point und dem WLC (ap-manager interface) beträgt ca. 6.000 Byte, und eine einmalige Konfigurationsänderung beträgt durchschnittlich 360 Byte und umfasst jeweils 2 Pakete vom Access Point und der AP-Manager-Schnittstelle des WLC.
Radio Resource Management (RRM)
Abbildung 5: Initialer RRM-Paketfluss 
Ein RRM-bezogener Informationsaustausch findet statt, sobald der Access Point bereitgestellt wurde. Ein typischer Austausch zwischen dem Access Point und dem WLC (ap-manager interface) beträgt ca. 1.400 Byte. Im Falle einer Konfigurationsänderung im Zusammenhang mit dem RRM erfolgt ein 4-Paket-Austausch zwischen dem AP und der AP-Manager-Schnittstelle des WLC. Dieser Austausch beträgt im Durchschnitt 375 Byte.
Eine 20-minütige Beispielerfassung, die Erkennung, Verknüpfung, Konfiguration und laufende Prozesse umfasst, führte zu diesen Datenverkehrsstatistiken für ein 100-Mbit/s-Segment:
Tabelle 1: Ausgangsstatistiken des LWAPP-Datenverkehrs für einen einzelnen Access Point| Statistik | Wert |
|---|---|
| Byte gesamt | 84,869 |
| Durchschnittliche Auslastung (Prozent) | 0.001 |
| Durchschnittliche Auslastung (Kilobit/s) | 0.425 |
| Max. Auslastung (Prozent) | 0.004 |
| Max. Auslastung (Kilobit/s) | 5.384 |
Abbildung 6 ist eine bildliche Darstellung des gesamten Prozesses.
Abbildung 6: Protokollvergleich während der Phase der AP-Erkennung, -Verbindung und -Bereitstellung 
Laufende Exchange
Herzschlag
Die LWAPP-Architektur bietet einen Heartbeat-Timer, der durch eine Reihe von Echo-Anfragen und Echo-Antworten erreicht wird. Ein Access Point sendet regelmäßig Echoanfragen, um den Zustand der Verbindung zwischen dem Access Point und dem WLC zu ermitteln. Daraufhin sendet der WLC die Echo-Antwort, um den Empfang der Echo-Anforderung zu bestätigen. Der Access Point setzt dann den Heartbeat-Timer auf das EchoInterval zurück. Der LWAPP-Protokollspezifikationsentwurf enthält eine detaillierte Beschreibung dieser Timer. Der System-Heartbeat umfasst zusammen mit dem Fallback-Mechanismus 4 Pakete alle 30 Sekunden und besteht aus folgenden Paketen:
LWAPP ECHO_REQUEST from AP (78 bytes) LWAPP Echo-Response to AP (64 bytes) LWAPP PRIMARY_DISCOVERY_REQ from AP (93 bytes) LWAPP Primary Discovery-Response to AP (97 bytes)
Dieser Austausch generiert 33 Byte Datenverkehr alle 30 Sekunden.
RRM-Messungen
Es gibt zwei laufende RRM-Austausche. Die erste besteht in jedem Intervall von 60 Sekunden aus der Last und dem Signal und besteht aus 4 Paketen. Dieser Austausch hat immer eine Größe von 396 Byte:
LWAPP RRM_DATA_REQ from AP (107 bytes) LWAPP Airewave-Director-Data Response to AP (64 bytes) LWAPP RRM_DATA_REQ from AP (161 bytes) LWAPP Airewave-Director-Data Response to AP (64 bytes)
Die zweite Paketsequenz ist die Rauschmessung, die eine Statistikanforderung und eine Antwortsequenz beinhaltet. Dies erfolgt alle 180 Sekunden. Dieser kurze Datenaustausch dauert im Durchschnitt ca. 2.660 Byte und dauert in der Regel 0,01 Sekunden. Es besteht aus den folgenden Paketen:
LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP STATISTICS_INFO from AP LWAPP Statistics-Info Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP 00:14:1b:59:41:80 LWAPP Airewave-Director-Data Response to AP LWAPP RRM_DATA_REQ from AP LWAPP Airewave-Director-Data Response to AP LWAPP STATISTICS_INFO from AP LWAPP Statistics-Info Response to AP
Nicht autorisierte Messwerte
Nicht autorisierte Messwerte werden als Teil des Scan-Mechanismus durchgeführt und alle 180 Sekunden in den RRM-Austausch integriert. Weitere Informationen finden Sie unter Unified Wireless Networks unter Radio Resource Management.
Die 20-minütige Beispielerfassung führte zu den folgenden Werten für den laufenden Paketaustausch auf einem 100-Mbit/s-Segment:
Tabelle 2: Laufende LWAPP-Datenverkehrsstatistiken für einen einzelnen Access Point| Statistik | Wert |
|---|---|
| Byte gesamt | 45,805 |
| Durchschnittliche Auslastung (Prozent) | < 0,001 |
| Durchschnittliche Auslastung (Kilobit/s) | 0.35 |
| Max. Auslastung (Prozent) | < 0,001 |
| Max. Auslastung (Kilobit/s) | 0.002 |
Die Statistiken und der Austausch in Tabelle 2 sind in folgenden Bildern dargestellt:
Abbildung 7: Eine 20-minütige Protokollvergleichsprobe während des normalen Betriebs des Access Points 
LWAPP-Daten
Rahmen
Der LWAPP-Daten-Frame-Header fügt den vorhandenen 802.11-Paketen 6 Byte hinzu. Dieser Header wird vor dem gekapselten 802.11-Frame hinzugefügt und umfasst Folgendes:
Light Weight Access Point Protocol [0-40]
Flags: %00000000 [42-48]
00.. .... Version: 0
..00 0... Radio ID: 0
.... .0.. C Bit - Data message [0-29]
.... ..0. F Bit - Fragmented packet [0-34]
.... ...0 L Bit - Last fragment [0-30]
Fragment ID: 0x00 [43-55]
Length: 74 [44-52]
Rec Sig Strngth Indic:183 dBm [46-77]
Signal to Noise Ratio:25 dB [47-76]
Fragmentierung
Da LWAPP-Frames fragmentiert werden können, ist ein Fragment-ID-Feld enthalten. Die Gesamtpaketgröße kann bestimmt werden, wenn Sie den ursprünglichen Frame und das IP-Fragment hinzufügen. Beachten Sie, dass das IP-Fragment nicht in LWAPP-Headern eingekapselt ist.
Fazit
Die Ergebnisse dieser Datenverkehrsstudie zeigen, dass der Betrieb von LWAPP keine hohen Bandbreitenanforderungen an die Infrastruktur mit sich bringt. In den meisten typischen Bereitstellungen ist keine zusätzliche Kapazität erforderlich, um die Cisco Unified Wireless Architecture zu unterstützen. Eine Zusammenfassung der Datenverkehrsstudie: Diese schnellen Fakten über den Betrieb von LWAPP sind zu beachten:
-
Obwohl Latenz ein wichtiger Aspekt ist, werden in dieser Datenverkehrsstudie nur Durchsatzüberlegungen dargestellt. Als allgemeine Richtlinie darf die Round-Trip-Latenz von AP zu WLC 100 ms nicht überschreiten.
-
Für den Betrieb von LWAPP gibt es zwei separate Kanäle:
-
LWAPP-Daten
-
LWAPP-Kontrolldatenverkehr
-
-
Der LWAPP-Betrieb ist in zwei große Kategorien unterteilt:
-
einmalige Börsen
-
laufende Börsen
-
-
Eine 20-minütige Stichprobe, die den ersten Austausch umfasst, ergibt eine durchschnittliche Nutzungsstatistik von 0,001 Prozent.
-
Eine 20-minütige Stichprobe laufender Börsen ergibt eine maximale Nutzungsstatistik von 0,35 Kilobit/Sekunde.
-
Der LWAPP-Datenkanal fügt jedem 802.11-Datenpaket einen Header von 6 Byte hinzu. Für IP-Fragmente gibt es keinen zusätzlichen Overhead.
-
In einem einstündigen Beispiel werden diese Aufspaltung von Protokollen und ihre jeweiligen prozentualen Anteile dargestellt:
Feedback