LWAPP-verkeersstudie
Inhoud
Inleiding
Het IETF-RFC-ontwerp, dat wordt voorgelegd aan de werkgroep Control and Provisioning of Wireless Access Point (CAPWAP), beschrijft het Lichtgewicht Access Point Protocol (LWAPP) als een protocol dat is ontwikkeld met het doel om communicatierichtlijnen te definiëren tussen draadloze afsluitpunten (access points) en toegangscontrollers (draadloze LAN-controllers). Alle LWAPP-communicatie kan in een van deze twee soorten berichten worden ingedeeld:
-
LWAPP-controlekanaal
-
LWAPP-ingesloten gegevens
LWAPP kan functioneren in Layer 2 of Layer 3 transportmodus. Layer 2 LWAPP-communicatie wordt ingekapseld in Ethernet-frames en kan worden geïdentificeerd met een EtherType-waarde van 0x88BB. Vanwege zijn betrouwbaarheid op Ethernet is Layer 2 LWAPP-modus niet routeerbaar en vereist Layer 2 zichtbaarheid tussen de WLC’s en AP’s. Layer 2 wordt als gedeponeerd beschouwd en de protocolstatistieken die in deze verkeersstudie worden geschetst zijn gebaseerd op Layer 3 LWAPP transportmodus. Layer 3 LWAPP transportmodus specificeert de uitwisseling van LWAPP-berichten op het IP-netwerk in de vorm van UDP-ingekapselde pakketten. De LWAPP-tunnel wordt onderhouden met het IP-adres van de WLC-interface (ap-Manager) en het IP-adres van de AP. Deze verkeersstudie toont de werkelijke hoeveelheid overhead die LWAPP-berichten op een netwerk en een basislijn van de LWAPP-operatie in een standaard installatie bieden.
Opmerking: De LWAPP-specificatie wordt uitvoerig besproken in het LWAPP-IETF-ontwerp.
Instellen
Dit document bevat alleen statistieken over de werking van het LWAPP en elke functionaliteit die niet in de protocolspecificatie is gedefinieerd, zoals roaming tussen controllers, valt buiten het toepassingsgebied van dit document. Bovendien bestrijkt de verkeersstudie alleen Layer 3-modi van de LWAPP-operatie.
Afbeelding 1: LWAPP-instelling voor verkeersstudie 
| Interface/apparaat | IP-adres |
|---|---|
| WLC-interface voor beheer | 192.168.10.102 |
| WLC - ap Manager-interface | 192.168.10.103 |
| Lichtgewicht AP | 192.168.10.22 |
Ten behoeve van deze verkeersstudie werd de instelling met slechts één access point gemaakt om de basislijnen voor de eerste uitwisseling en configuratie vast te stellen. Er zijn later meer AP's toegevoegd om de effecten te bepalen van het opschalen van het aantal AP's op de hoeveelheid verkeer die op de draad wordt gegenereerd.
LWAPP-controlekanaal
AP gebruikt vluchtige havens wanneer het met de WLC praat. De poortnummers die door de WLC in ruil daarvoor worden gebruikt, zijn UDP-poort 1222 en UDP-poort 12223 voor LWAPP-gegevens respectievelijk LWAPP-controleverkeer. Een LWAPP-BESTURINGSSYSTEEM kan van een LWAPP-gegevensframe worden onderscheiden door het "C"-bit in het veld van de headervlag van de LWAPP. Als dit item op 1 staat, is het een bedieningskader.
Eerste/eenmalige uitwisseling
LWAPP-ontdekking (aanvraag en respons)
Afbeelding 2: LWAPP-pakketstroom voor detectieaanvraag en -respons 
De LWAPP-detectieverzoeken, die door het access point worden verstuurd, worden gebruikt om te bepalen welke WLC’s in het netwerk aanwezig zijn.
Een pakket zoekaanvragen is 97 bytes, die de 4 bytes FCS omvatten. Een pakket met zoekantwoorden is 106 bytes, die de 4 bytes FCS omvatten.
LWAPP-aansluiting (aanvraag en reactie)
Afbeelding 3: LWAPP-pakketstroom voor aanvragen en reageren 
Een LWAPP-pakket dat zich bij een aanvraag aansluit, wordt door het access point gebruikt om de WLC op de hoogte te stellen dat het klanten via de controller wil bedienen. De fase van de gezamenlijke aanvraag wordt ook gebruikt om de door het vervoer gesteunde MTU te ontdekken. Het eerste samengevoegd verzoek dat door het access point wordt verstuurd, wordt altijd toegevoegd met een testelement van 1596 bytes. Op basis van de wijze waarop het transport tussen de AP en de controller is ingesteld, kunnen deze samengevoegde aanvraagframes ook worden gefragmenteerd. Als een gezamenlijk antwoord voor het eerste verzoek wordt ontvangen, stuurt AP beelden door zonder enige fragmentatie. De reactie om mee te doen initieert ook de hartslag timer (een waarde van 30 seconden) die, wanneer deze verloopt, de WLC-AP sessie verwijdert. De timer wordt opnieuw gegenereerd na ontvangst van het Echo-verzoek of de bevestiging.
Als de eerste aanvraag om toetreding geen antwoord oplevert, stuurt AP een ander verzoek om toetreding met het testelement, dat de totale lading op 1500 bytes brengt. Als de tweede bij het verzoek wordt gevoegd geen antwoord geeft, blijft AP tussen de grote en kleine pakketten bladeren en uiteindelijk opnieuw beginnen vanaf de ontdekkingsfase.
De grootte van pakketten voor de verbinding van het verzoek en de antwoordberichten variëren gebaseerd op de beschrijving maar de pakketuitwisseling die voor de doeleinden van deze verkeer-studie tussen AP en WLC (ap-Manager interface) wordt gevangen is 3.000 bytes.
LWAPP-configuratie
Afbeelding 4: LWAPP-configuratie: staat en AP-provisioningpakketstroom 
De LWAPP-configuratieverzoeken en antwoorden worden tussen de access points en de controllers uitgewisseld om de door een AP aangeboden diensten te creëren, te wijzigen (bijwerken) of te verwijderen.
In het algemeen wordt een bericht van de het Aangepaste Aanvraag door AP verzonden om zijn huidige configuratie aan zijn WLC te verzenden.
Het configuratieverzoek kan in twee scenario's worden verzonden:
-
In de beginfase waarin het AP zich bij een controller voegt en waarvoor voorzieningen nodig zijn met alle 802.11-instellingen die op de controller zijn ingesteld.
-
In het geval van on-demand administratieve wijzigingen, zoals een wijziging in een WLAN-parameter
Het LWAPP-configuratieschema wordt door de WLC naar de AP verzonden om de ontvangst van het LWAPP-configuratieverzoek van de AP te bevestigen. Dit biedt de WLC de mogelijkheid om de gewenste configuratie van AP te omzeilen. Een dergelijk kader bevat geen speciale berichtelementen.
De eerste uitwisseling tussen AP en WLC (ap-Manager interface) is ongeveer 6.000 bytes en een eenmalige configuratieverandering gemiddelden van 360 bytes en heeft betrekking op 2 pakketten die elk van AP en de app-Manager interface van de WLC zijn.
Radio Resource Management (RRM)
Afbeelding 5: Initiële RRM pakketstroom 
Er vindt een RRM-gerelateerde informatie-uitwisseling plaats nadat de AP is bevoorraad. Een typische uitwisseling tussen AP en WLC (ap-Manager interface) is ongeveer 1400 bytes. In het geval van een RRM-gerelateerde configuratieverandering is er een vierpakketuitwisseling tussen AP en de ap-Manager interface van de WLC. Deze exchange gemiddelden zijn 375 bytes.
Een 20 minuten durende steekproefopname die de ontdekking, de toetreding, de configuratie, en de aan de gang zijnde processen omvat, resulteerde in deze verkeersstatistieken op een segment van 100 Mbps:
Tabel 1: Eerste LWAPP-verkeersstatistieken voor één access point| statistisch | Waarde |
|---|---|
| Totaal Bytes | 84,869 |
| Gemiddelde benutting (percentage) | 0.001 |
| Gemiddelde benutting (kilobits/s) | 0.425 |
| Max. benutting (percentage) | 0.004 |
| Max. benutting (kilobits/s) | 5.384 |
Afbeelding 6 is een illustratieve weergave van het gehele proces.
Afbeelding 6: Protocolvergelijking tijdens de AP-ontdekking, -aansluiting en -provisioningfase 
Doorlopende uitwisselingen
hartslag
De LWAPP-architectuur zorgt voor een uitvaltimer die wordt bereikt door een reeks Echo-aanvragen en Echo-reacties. AP stuurt periodiek Echo Verzoeken om de staat van de verbinding tussen AP en WLC te bepalen. Als antwoord stuurt de WLC de Echo-respons om de ontvangst van het Echo-verzoek te bevestigen. AP, dan stelt de hartslag timer terug aan het EchoInterval. Het ontwerp van de LWAPP-protocolspecificatie bevat een gedetailleerde beschrijving van deze timers. De systeemhartslag, in combinatie met een terugvalmechanisme, is 4 pakketten per 30 seconden en bestaat uit deze pakketten:
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)
Deze uitwisseling genereert 33 bytes van het verkeer elke 30 seconden.
RRM-metingen
Er zijn twee lopende RRM-uitwisselingen. Het eerste, met elk 60-seconden interval, is de lading en signaalmeting en bestaat uit 4 pakketten. Deze uitwisseling voegt altijd tot 396 bytes toe:
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)
De tweede reeks pakketten is de ruis meting die een statistische informatieaanvraag en een reeks antwoorden omvat. Het gebeurt elke 180 seconden. Deze korte uitwisseling van pakketten bedraagt gemiddeld ongeveer 2.660 bytes en duurt gewoonlijk 0.01 seconden. Het bestaat uit deze pakketten:
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
Afmetingen van de rotatie
Schuurmetingen worden uitgevoerd als onderdeel van het scanmechanisme en worden elke 180 seconden opgenomen in de RRM-uitwisseling. Raadpleeg Radio Resource Management onder Unified Wireless Networks voor meer informatie.
De 20 minuten durende monsteropname resulteerde in de volgende waarden voor doorlopende pakketuitwisselingen op een 100 Mbps segment:
Tabel 2: Doorlopende LWAPP-verkeersstatistieken voor één access point| statistisch | Waarde |
|---|---|
| Totaal Bytes | 45,805 |
| Gemiddelde benutting (percentage) | < 0,001 |
| Gemiddelde benutting (kilobits/s) | 0.35 |
| Max. benutting (percentage) | < 0,001 |
| Max. benutting (kilobits/s) | 0.002 |
De statistieken en uitwisselingen in Tabel 2 worden in deze afbeeldingen weergegeven:
Afbeelding 7: Een 20 minuten durende steekproef van protocolvergelijking terwijl het AP in normaal bedrijf is 
LWAPP-gegevens
Frame Relay-opvulling
De LWAPP-kop van het gegevensframe voegt 6 bytes toe aan de bestaande 802.11 pakketten. Deze header wordt toegevoegd voordat het ingesloten 802.11 frame wordt toegevoegd met daarin de volgende elementen:
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]
fragmentatie
Aangezien LWAPP-frames kunnen worden gefragmenteerd, is een veld Fragment-ID opgenomen. De totale pakketgrootte kan worden bepaald als u het oorspronkelijke frame en het IP-fragment toevoegt. Het is belangrijk om op te merken dat het IP-fragment niet in een LWAPP-headers is ingesloten.
Conclusie
Zoals duidelijk door de bevindingen in deze verkeersstudie, introduceert de exploitatie van LWAPP geen zware bandbreedtevereisten op de infrastructuur en in de meeste typische implementaties is er geen behoefte om extra capaciteit aan de infrastructuur toe te voegen om Cisco Unified Wireless Architecture te kunnen ondersteunen. Als samenvatting van de verkeersstudie kunnen deze snelle feiten over de werking van LWAPP in gedachten worden gehouden:
-
Hoewel latentie een belangrijke overweging is, wordt in deze verkeersstudie alleen aandacht besteed aan de doorvoersnelheid. Als algemeen richtsnoer mag de verbinding AP-WLC niet meer dan 100 ms latentie om heen en weer te reizen bedragen.
-
Er zijn twee aparte kanalen voor de werking van LWAPP:
-
LWAPP-gegevens
-
LWAPP-beheerverkeer
-
-
De LWAPP-operatie is in twee grote categorieën ingedeeld:
-
eenmalige uitwisseling
-
doorlopende uitwisselingen
-
-
Een steekproef van 20 minuten die de eerste beurzen omvat, resulteert in een gemiddelde bezettingsgraad van 0,001%.
-
Een 20 minuten durende steekproef van de lopende beurzen resulteert in een maximale bezettingsgraad van 0,35 kilobits/seconde.
-
Het LWAPP Data Channel voegt een header van 6 bytes toe aan elk 802.11 datapakket. Er is geen extra overhead voor IP-fragmenten.
-
Een uurlange steekproef presenteert deze opsplitsing van protocollen en hun respectieve percentages:
Feedback