Not sure I follow what you mean, please ask again if the answer is not what you are looking for:
RTS/CTS are control frames, they are part of the normal frames defined by 802.11 and expected in a cell.
However, 802.11 does not specify cases where you 'must' or 'should never' use them. They are optional.
Some clients start using RTS/CTS when the AP load is high (AP advertises the load in the beacons); some clients start using RTS/CTS if they experience a lot of collisions (frames sent and not acknowledged, even when the data rate is low - this is commonly caused to collisions with other clients on the other side of the cell that the local client cannot hear, and this phenomenon is called the 'hidden node problem', because the other client (or 'node') is hidden to (not detected by) the local client); some clients start using RTS/CTS when their buffer get full (to increase the chance of collision less transmission), etc.
... View more
The sender (the AP) constructs a frame which header has 3 MAC addresses. The first is the intended destination (the client) MAC< the second is the sender, (the AP, identified by its MAC address for that SSID, called the BSSID), and the third address is the original source of the frame (if the AP is relaying the frame from the wire, for example).
All stations in the cell detecting the transmission will read the frame header to understand who the destination is, then all stations except the intended receiver will ignore the frame once they read the first MAC address. The intended receiver will read the whole frame, verify that the checksum is okay, then send an ACK frame back to the AP.
You can read more on these address structures in many documents, for example here: https://mrncciew.com/2014/09/28/cwap-mac-headeraddresses/
... View more
" Is the NAV value used when access points needs to send data to clients?", > yes, inside the AP. The AP is just like the other stations in most cases, so it counts down etc just like the others, it just happens to send quite more than a single client, but its contention mechanism is the same (again, "in most cases", there are 2 cases described in 802.11, called PCF and HCCA, where the AP may use different rules, but these cases are not implemented in 'normal' networks).
"time period specified by NAV value can be used by clients not only for transmitting but also for receiving data?" > no, the clients have no idea about the other stations', or the AP's internal NAV (please read my reply to your other question, the station can use the beginning of a transmission to re-adjust its NAV, but NAVs are not sent across to various stations).
... View more
Haven't been following this old thread for a while, but in short, the NAV is an internal process to a station ready to transmit (it is not exchanged over the air between stations, imaging how impractical this scheme would be in a cell at CiscoLIve with 150 stations on an AP :)). It is used only to determine how long the station ends up having to wait before a transmission effectively occurs. So it is not used to "receive" traffic.
However, when a station sends, the header contains the duration of the transmission. So a station counting down can read another station's frame read the duration field, add that value to its counter, and doze for that duration (instead of counting down and hearing at each step what it already knows, i.e. that the other station is still transmitting, just like it said it would).
Hope this helps
... View more
When QoS was brought to WiFi, we started with other L2 technologies class models, and chose to align to 802.1, which in those days had an 8 class model, with 802.1D-1998 (UP 0 to 7). So 802.11 aligned to this model with 8 UPs, (among other reasons) to allow for an easier translation mechanism when moving packets from one medium to the other (802.1 to 802.11 for example).
Then, experimenting with the priority system, people from various companies found that 8 queues were hard to manage cleanly over 802.11 (keep in mind that we had only 802.11a and 11.b/g back then). There was not a big difference between these 8 queues, and a lot of collisions were messing up the priorities. So the 802.11 group reverted to 4 access categories. 4 classes gave enough differentiation between classes, and a reasonable compatibility with prior (non WMM) traffic type.
Now, inside your device, you can arbitrate the 2 UPs inside a given AC (this is what Cisco does), so, for example, UPs 4 and 5 both get the same statistical access over the air, but the internal queue gives a statistical preference to 5 over 4, so overall you recreate a clean hierarchy system without disrupting too much the air space.
Now, that is where we stand today, With RFC 8325, we expressed that it is silly anyway to want to translate an L2 into another L2 without first looking at the global intent of the packet (L3 marking). Now that this is instantiated, our next job is to look at 802.11 to examine if 802.1D is the best reference point to start from (in my view, we should align with 802.,1Q-2014 instead, not much change from the outside, still 8 queues, but it would change a bit the internal sauce).
If the client is WMM, and the packet comes with no DSCP, then the policy depends of your QoS profile config. If you have Platinum, and you set the "non WMM" to best effort (which we recommend), the packet gets sent into the BE (UP0) queue. You would get BK only if you configured the 'non WMM' to background.
... View more
Thanks a lot Rasika for this great explanation!
A few more nuggets, in case they might be useful...
When you client associates, its association request should contain the QoS capability field, this is how the AP knows that it is WMM. Then, downstream, the AP receives a packet from the wire, looks at the client destination, and if it is a WMM client, the AP uses the EDCA (WMM) procedure, sending frames with higher priority at statistically faster interval, etc. If the client is not WMM, then the AP switches to the DCF procedure (non WMM transmission method, with fixed DIFS). No UP value is then present in the header (and no frame is sent faster than others for that client, even if the wired incoming packet had a QoS value).
Please also note, as Rasika mentions, that the UP value in the 8.x guide text refers to the QoS profile. If the incoming packet (from the wire) is untagged (no QoS), and the target client supports WMM, what should the QoS value be for that packet over the air? The QoS profile determines the marking for non WMM packets. This marking used to be the same as the profile (e.g. Platinum, i.e. UP 6, for Platinum profile), but this was back in the days where we would create SSIDs for traffic types (e.g. "voice" SSID), so we would assume that unmarked traffic for this type of SSID would also be voice, so should be marked the same. Since then, phones got themselves a screen and a web browser! So we don't do specialized SSIDs much anymore, and this unmarked traffic QoS value is configurable.
Last bit, inside the phone, the OS describes a socket call (as a programmer, for every packet you want your app to send to the network, you build a socket call, with an instruction to send 'somewhere'). Each call will be associated to a type, and each type to a DSCP value. For example, in iOS, SO_NET_SERVICE_TYPE_RV is Real time interactive media (gaming etc.), and is mapped to DSCP CS4. Then, inside the Wi-Fi driver, each DSCP value is mapped to a UP value (in iOS, CS4 is mapped to UP5). Each vendor is free to use their own map, but we published RFC 8325 a few months back to set a common map that starts being adopted by most m major vendors.
Please note that RFC4594 describes traffic categories (as in 'their sensitivity to jitter, loss and delay'), and suggest a DSCP marking for each of the 12 categories (we call this the 12 classes model), it does not describe the UP value (that's RFC 8325's job).
... View more
Yes, "hybrid 802.11r" means FT (802.11r) enabled on a WPA2 WLAN, and key management set to both PSK and FT PSK (if you use PSK) or both 802.1X and FT 802.1X (if you use 802.1X). This way, both 802.11r and standard WPA2 schemes are supported and announced by the AP.
Hybrid mode is called "mixed mode" these days in the WLC guides (e.g. https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_01010010.html).
RE Adaptive and 802.11r on the same WLAN, you cannot do that... :-)
The reason is that the goal of Adaptive 802.11r is to support 802.11r for iOS devices in WLANs where you cannot announce 802.11r openly (because 802.11r-incompatible stations may fail to associate). But if you turned 802.11r on for such a WLAN, then suddenly you would announce 802.11r openly, and this would defeat the purpose of Adaptive. On one side, your iOS devices would associate directly using 802.11r (they don't need any special treatment as 802.11r is visible and they support it), rendering Adaptive 11r not useful, but on the other side 802.11r-incompatible stations may fail to associate.
So 802.11r (openly supported and announced) and Adaptive 802.11r (802.11r not announced but activated for iOS dynamically) are opposite modes, they answer opposite requirements and should not be both on the same WLAN...
... View more
Please allow me to provide a bit of context. You basically have 3 sorts of clients (in regards to 11r):
1. Those that support 802.11r. They can associate to a WLAN where 11r is enabled and mandatory, and benefit from 11r fast roaming. iOS devices are in this case.
2. Those that do not support 802.11r (not compliant), but are not against it (they are compatible). Recent macOS are of this type for example. They do not support 802.11r (they cannot associate with 802.11r mode, and could not associate to a WLAN where 802.11r would be the only method). However, they do not 'mind' 802.11r. If you have a WLAN where both 802.11r and WPA2 are supported, they will join using WPA2.
3. Those that are allergic to 802.11r. They do not support 802.11r, and refuse to associate to any WLAN where 802.11r is mentioned, even if other methods are also allowed on this WLAN. These clients are usually older, and poorly programmed. The developers thought "er... let's see: Open, WEP, WPA, WPA2. Anything else, stop in panic mode". So, when 802.11r is seen, they reach the line that says "OMG, unknown security method, don't know what it means and what I should do, oh, life is sooo hard, panic!" and they fail to associate (their poorly developed driver does not have the option to say 'okay, you don't get 11r, BUT look, there is this other one there that you understand, WPA2').
Okay, that's the client side. Now on the WLC side:
Before 8.0, you could configure a WLAN for 802.11r OR WPA2. So you had pretty much to create one WLAN for your 802.11r clients, and one for the others.
In code 8.0, we introduced the hybrid mode, where your WLAN can be configured for both 802.11r and WPA2. Both are announced in the beacons and probe responses. Most 'normal' clients work well, the 802.11r-compatible (cat 1) using 802.11r, and the others (cat 2) using WPA2. But then, every now and then some client show up that are of category 3, and admins may spend time troubleshooting why that client can't associate (before figuring out that chipset blah with driver version x makes that this is an allergic client... and then there is no real solution, this poorly programmed client will not associate to that WLAN).
So... many admins live very well with the hybrid mode, but quite some networks chose to not implement the hybrid mode, and use only WPA2, in fear that these 'cat 3' clients show up.
We stayed there for a while, and were a bit sad, because you have in your networks devices (like iOS) that are highly mobile, and for which the vendor did the serious job of implementing high mobility features... and they pay the price of not benefiting from fast roaming because other, lazier, vendors, did not care to program their chipset (or cheapset) properly, or even to publish a driver fix to be at least category 2.
Then, as we started working with Apple, we thought "hey, this is something we may be able to help with".
So we jointly implemented Adaptive 11r. In this mode, 802.11r is not announced (it is hidden, so the cat 3 clients do not panic). However, as we recognize iOS clients (for Fastlane for example), we use this recognition to still activate 802.11r for the supporting iOS clients when they are recognized and join the cell. This does not solve the problem for all the 802.11r clients on the planet, but at least help for the iOS clients, which are usually a consequent chunk of your mobile populations.
Please do not believe that "Adaptive 11r breaks 802.11r for non-iOS clients", this is the same as saying "building houses breaks the market for camping tents". The purpose is not the same. Adaptive was built for networks where 802.11r is NOT enabled in the first place.
a. If all your clients are 802.11r, enabled 802.11r and all is good.
b. If some of your clients are 802.11r, some others are not, enable hybrid 802.11r (both 802.11r and WPA2 announced), and you should be fine most of the time. You do not need Adaptive 11r (and Adaptive 11r is not a feature needed in your network).
c. If you are in a public space (no control over which client will show up) AND you are concerned about this handful of clients that may show up and be of category 3, you may have decided to troubleshoot them when they show up (you are in case (b)), or you may have decided to cut off 802.11r on do only WPA2, so you don't have to troubleshoot for every random cat 3 client that may show up. In this case, enable Adaptive 802.11r. At least, your supporting iOS clients will benefit from 802.11r, so you are in better shape than you were before, even if there are still some other clients that could benefit from 802.11r, but that will not, because you decided that announcing 802.11r was too worrisome.
RE CCXv4 and FT, they are not the same thing. CCX are a set of Cisco extensions that were developed to speed up the adoption of features that were useful for Wi-FI networks. Among them, one is called Cisco Central Key Management (CCKM). It was developed in 2004-2005 and later years. It performs functions equivalent to 802.11r (which was partly built on CCKM principles). Then the IEEE published 802.11r in 2008. It was integrated in a Wi-Fi Alliance just a few years back (Voice enterprise). So you will have some clients that will be CCXv4 (with CCKM of course) and that will also implement 802.11r, but all combinations are possible (CCXv4 and no 802.11r, no CCXv4/CCKM but 802.11r, or neither) as the two methods are independent.
Hope this helps
... View more
A quick word on support of Michael's comments... :-)
Johannes, please make sure to distinguish upstream from downstream, and Voice from Video...
Upstream vs downstream: you are right, Microsoft incorrectly applies the same L3 to L2 QoS mapping regardless of the transmission medium, so EF gets UP 5 or CoS 5. I write "incorrectly", although they would debate that point. But until the whole world changes the recommended mapping, including 802.11, Voice in wireless should be UP 6.
This means that if your STA does not do TSPEC (ADDTS request) for its upstream traffic, it is not allowed to send in the UP 6 queue if ACM is enabled. iOS 10 are an exception, because we know that what they send in UP 6 is indeed going to be voice traffic (and not a "home made" marking for a bittorrent app ;-)).
If the STA still sends in UP 6 (without ADDTS, and despite ACM being enabled), this is a violation of 802.11, and we respond with return traffic marked down to BE.
Okay. Now if your Windows machine sends upstream traffic with EF/UP5, it will not fall into the ACM restriction. The return traffic will be marked according to your QoS policy, so there is no issue there.
In general, specialized phones (Cisco, Vocera etc) do TSPEC. General use stations (laptops, tablets, etc) do not do TSPEC, simply because each app developer is unable to provide clean description of wifi TSPEc requirements for their voice flows...
So in my opinion, your policy should depend on your voice device population. One risk without ACM, like Michael pointed out, is that if you have too many calls in your cell, all calls suffer, not just the "additional ones", so it is healthy for voice quality to have a mechanism to limit the number of calls in the cell. If none of your clients do TSPEC, then of course ACM is not very useful. If you have a mix of iOS 10 devices, or specialized phones, and more general devices, ACM is going to protect part of your cell airtime, forcing the non-compliant devices to get into UP 5 (which is not as good, but still good).
Voice vs video:
Almost no device (I write "almost", but in fact I have never seen any) supports ACM for Video traffic. We have the option in the WLC because it is present in 802.11 and WFA, but I do not see value in turning it on.
So if you use ACM for Voice (I turn it on in all my networks where iOS or specialized phones are present, even if I have a large population of Windows machines with Skype), the other machines have a lot of space to use the Video queue...
hope this helps
... View more
Hi Elemzy, Few comments to clarify the behavior: - when you choose to contain a "rogue SSID", a message warns you that this could have legal consequences. What this means is that you do not have the right to contain a legitimate network. In the scenario you describe, both companies would be at fault, because each is trying to block a legitimate other network. Recent examples with various brands show that when the FCC is called for help for such illegal behavior, the fine can be expensive for the offender. Containment is solely for situations where the rogue is in your facility (and if you are not sure... well you should make sure before you contain :-)). Containment is not automatic, but a conscious admin choice. - There are mechanisms (RLDP, rogue on wire) to help you decide if the rogue is on your network or not. - There is no mechanism to resist a deauth (it is part of the protocol). However, there is a protocol called 802.11w (also known as PMF, for which Cisco has a more elaborate and older solution called MFP) that allows the AP and the clients to agree on a hash, and therefore ignore any external deauth message. This would effectively achieve the protection you describe. hth Jerome
... View more