V/K/R/W – 1. del.

Hvad er nu det? Er det en ny regeringssammensætning (når der nu snart kommer valg)?

Nej, det har alt sammen noget at gøre med trådløse netværk. Denne blogpost indeholder information om nogle af de standarder, som vi måske ikke snakker om, men som vi burde snakke om.

IEEE, der udvikler standarderne for fx trådløse netværk, arbejder i grupper. Vi kender ofte disse arbejdsgrupper ud fra det bogstav, der står efter standarden. Fx 802.11a fra 1999 som er ”Higher-Speed PHY Extension in the 5GHz Band” arbejdsgruppen. Det er her, vi fik op til 54Mbit-standarden udarbejdet.

For at holde os i det spor, så kender vi nok alle de andre hastigheds-grupper: 802.11b, 802.11g, 802.11n og senest 802.11ac – og om et års tid taler vi nok alle sammen mere om 802.11ax.
For hvert mellemliggende bogstav har der også været en arbejdsgruppe, men dem bemærker vi ikke så meget, fordi det ofte er hastighedsforøgelserne, der løber med overskrifterne.

Fx er 802.11i-arbejdsgruppen ansvarlig for den sikkerhed, vi i dag kalder WPA2 (efter den har været igennem WiFi Alliance).
Engang imellem bliver alle de tidligere arbejdsgrupper og standarder så rullet sammen i en ”rigtig” 802.11-standard.

Det kan fx være 802.11-2016, som er den sidste nye. Selve standarden kan nemlig kun indeholde tal inde i IEEE.
Jeg vil gerne slå et slag for nogle af de mere ukendte arbejdsgrupper, og samtidig skubbe på, at det ikke kun er 802.11b/g/a/n/ac/ax, man skal kigge efter på databladet, når man køber klienter eller infrastruktur.

Del 1 – 802.11v og 802.11k

Lad os starte med den ældste arbejdsgruppe:

802.11k

802.11k – Radio Resource Measurement eller andre gange også kaldet: Radio Resource Management.
Her er det lige vigtigt ikke at blande 802.11k – Radio Ressource Management sammen med Ciscos Radio Resource Management (RRM) algoritme, der kører inde i WLC. Disse to begreber har ikke som sådan noget med hinanden at gøre.

802.11k standarden gør det muligt for infrastrukturen (WLC/AP) at fortælle klienten om, hvordan radio-miljøet ser ud.

En klient har normalt ikke meget intelligens omkring, hvordan det nuværende radiomiljø ser ud.

Klienten er normalt tilknyttet et AP, og hvis der skal roames til et nyt, så scanner klienten alle kanaler for at finde et nyt bedre AP. Det vil sige, at det er først på dette tidspunkt, klienten vil forsøge at finde ud af noget om radiomiljøet. Denne scanning kan tage tid. Der skal typisk lyttes på en kanal i mere end 100ms for at fange en beacon, og der er i alt ca. 45 kanaler, der skal scannes. Dette vil så tage, i bedste tilfælde, 45 x 100ms – 4,5 sekunder at roame til at nyt AP (alene scannings-delen, derefter kommer alt associering og godkendelse). Det er alt for lang tid fx i et voice-miljø, hvor vi ikke skal have udfald på tale.

Måden 802.11k afhjælper dette, er ved at fortælle klienten, hvilke kanaler i nærheden af det AP, den er tilknyttet nu, der er på (kaldet roaming-kandidater). Hvis der fx er to AP i nærheden af det nuværende AP, så skal klienten kun scanne fire kanaler for at kunne roame.

Dette sparer tid for klienten, og faktisk også lidt strøm, da klienten ikke skal scanne alt og alle kanaler, og heller ikke behøver at lave probe requests hele tiden. 802.11k bliver slået til under Advanced-fanebladet på dit SSID / WLAN. Husk kun at enable ” Neighbor List” og ikke ”Neighbor List Dual Channel”, der oplyser AP om både 2, 4 og 5Ghz kandidaterne i området, men klienterne skal typisk kun kende kanalerne for det bånd, de allerede er på. Det er det pæneste, så derfor sætter man ikke kryds i den option.

802.11k indeholder også en såkaldt ”Assisted Roaming” funktion. Denne option er fjernet fra GUI, fordi det ikke er den bedste funktion i verden. Den findes stadig i CLI, hvis man VIL lege med det, men lad nu være :-). Ved Assisted Roaming vil det trådløse system have en ide om, hvilket AP der er bedst for klienten. Hvis klienten ikke associerer til det bedste AP i kandidat-listen, afvises den.

Men klienterne (som ved Client Load Balancing featuren, der ligner denne funktion) ved ikke, hvad de skal gøre, når de modtager denne afvisning. Så de vil prøve igen og måske igen, og måske igen, og måske… You get the picture.

802.11k fungerer fint. Alle moderne klienter burde have support for det. Selv Windows 10 har support for det. Og denne liste viser supporten på diverse af Intels NICs: https://www.intel.com/content/www/us/en/support/articles/000021562/network-and-i-o/wireless-networking.html
Der skulle ikke være nogen risiko ved at slå 802.11k til på ens SSID. Gamle klienter, der ikke forstår 802.11k, vil ikke blive påvirket.

 

P.S. For de lidt nørdede:
802.11k kan ses i RM Capabilities i dit pakkesniff (der er også andre ting herinde), samt i Action Frames. Bemærk, der er mange andre ting, der benytter Action Frames i dag, så man skal lige ned i Framen for at sikre sig, at det er 802.11k, det handler om.

802.11v

Den næste i listen er 802.11v.
802.11v standarden hjælper klienten med at spare strøm, samt fortæller klienten hvor der er et bedre AP tilgængeligt.

I normale trådløse netværk prøver mange klienter at spare strøm ved at lukke ned for radioen i små tidsperioder. De vågner så op og lytter måske til DTIM i beacons, eller sender nogle pakker til AP for at lade infrastrukturen vide at: ”Jeg er her stadig”.  Nogle gange vågner klienten også og lytter til beacons, selv uden DTIM, for at synkronisere deres ”trådløse tid” med AP.

Da vi ikke tidligere har haft nogen standard, dvs. hver enkel klientchip-producent har selv bestemt, hvad klienten skulle gøre, så har det været ineffektivt.

802.11v standarden hjælper klienten her.

Directed Multicast Service gør, at klienten beder AP om at unicaste Multicast trafik.
Så kan klienten slukke for radioen, også i Multicast-strømme, og så vågne op og få Multicast-pakkerne som Unicast. Unicast pakker sendes og modtages ved fuld hastighed i trådløse netværk, og ikke kun ved den fælles lave Multicast hastighed. Ved fuld hastighed er klientens radio derfor tændt i en kortere tidsperiode, og derfor sparer den strøm.

Max BSS Idle service. Med denne funktion fortæller infrastrukturen klienten, hvor længe den kan sove, før vi glemmer den. På den måde ved klienten, hvor længe den maksimalt kan have sin radio slukket uden at blive smidt af.
Derved kan der spares strøm, da klienten ikke skal ”gætte” sig frem, eller benytte dens egen algoritme.

BSS Transition er funktionen, hvor vi kan foreslå klienten, at den skal finde et nyt AP at være på. Funktionaliteten her har man egentlig talt om i mange år, og der har været nogle forskellige implementeringer.

Et eksempel her også på Advanced fanebladet: Client Load Balancing. Denne funktion sender også en pakke til klienten og beder den finde et andet sted at være, hvis der er for meget load på det enkle AP i forhold til et andet. Men det var op til producenten af klientchipen at beslutte, om de ville implementere forståelse af, hvad AP sagde.

Et andet eksempel er ”Optimized Roaming” i Ciscos WLC.

Hvis man benytter Optimized Roaming (der direkte sender en dis-association til klienten, hvis visse krav ikke er overholdt, fx RSSI-niveau) sammen med 802.11v, og klienten forstår 802.11v, vil man i stedet for at sende en dis-association, sende klienten en: 802.11v BSS Transition Management Request.
Derved behandler vi egentlig klienten pænere, da vi kan snakke sammen, i stedet for bare at smide den af.
Men her har vi så Optimized Roaming Disassociation Timer. Denne Timer er tiden, vi giver klienten til at finde et nyt AP at associere til, hvis den ikke overholder vores Optimized Roaming-værdier.

Det er dette tidsinterval, vi giver klienten til at finde et andet sted, ellers sender vi en dis-association.

To vigtige:

Med 802.11v ved vi, at klienten forstår, hvad vi siger, men … det er stadig op til klienten at beslutte sig til, om den vil høre efter.

Cisco har også her (som med 802.11k) gemt nogle af de ting, der kunne give dig alvorlige problemer over i CLI – som fx at klienterne måske ”hopper mellem” APs. Så vær påpasselig med at bruge dem / ændre dem her.

 

I Wireless LAN Controlleren vil du kunne se følgende under Advanced-tappen på dit WLAN: 11v BSS Transition Support.

Begge ovenstående funktioner skulle man som sådan ikke opleve problemer med at enable i sit trådløse netværk. Klienter, der ikke forstår disse standarder, vil bare ignorere dem, og WLC vil fx ikke sende 802.11v til en klient, der ikke forstår det.

802.11v/k/r/w er understøttet i Ciscos infrastruktur, og det er godt, men vi mangler ofte klient-understøttelse, så vær opmærksomme når I skal indkøbe nye klienter, – nogle af disse er ikke optionelle i dag.

Her er Apples liste over supporterede klienter: https://support.apple.com/da-dk/HT202628
Microsofts dokumentation omkring Windows10 support: https://docs.microsoft.com/en-us/windows-hardware/drivers/network/fast-roaming-with-802-11k–802-11v–and-802-11r
Hvis man vil se en tidslinje for de forskellige 802.11 arbejdsgrupper, kan man kigge her på IEEEs hjemmeside: http://www.ieee802.org/11/Reports/802.11_Timelines.htm

Næste gang 802.11r og 802.11w