When using a WLAN Controller with lightweight APs in a QoS-enabled network, why do the APs have to support 802.1Q priority tags, DSCP headers, or other similar tagging?
Just taking a stab at this:
To support the QoS translation (mapping) between Layer 2 (MAC) and Layer 3 (Network).
In the centralized wireless LAN architecture, wireless LAN data is tunneled between the access point and the wireless LAN controller via LWAPP. In order to maintain the original QoS classification across this tunnel, the QoS settings of the encapsulated data packet must be appropriately mapped to the Layer 2 (802.1p) and Layer 3 (IP DSCP) fields of the outer tunnel packet.
In the original question, the APs need to support 802.1q...
My current Cisco switches already have QoS enabled to handle my AVVID IP Telephony system. If the APs passed on QoS tagging, would there be an opportunity for problems? Shouldn't the controller be the one responsible for the 802.1q tagging, not the thin AP?
You've stumbled across the exact point that I was hoping that the discussion would bring out.
To prod you along a bit (toward the right answer), let me ask yet another question...
How do thin APs typically talk to controllers?
Are you looking for CAPWAP standard?
Okay, so I know my switches need encapsulation to handle my voice traffic. And don't the APs need encapsulation to talk to their controllers? Encapsulation within encapsulation once the 802.11 voice device's traffic gets all the way back to the QoS switch and eventually to the phone system server? I'm not sure why yet, but if that is the case I'm thinking that might cause problems.
The Ethernet switches can handle voice traffic without using any sort of encapsulation.
The APs have to build tunnels (LWAPP, GRE, etc) back to the controller over the Ethernet infrastructure in order to communicate with the controller.
The frames placed onto the Ethernet by the AP must be tagged with 802.1Q, DSCP, or some other kind of tag in order for the Ethernet switch to recognize the priority level of those frames. The AP places the appropriate tag in the Ethernet frame according to the data's priority on the WLAN (through use of Access Categories).
So, in a WMM environment, the application on the client would tell the MAC layer which AC to place the traffic in, then the client would transmit the MAC frame across the RF to the WMM-enabled AP, who would then tag that data for continued QoS across the Ethernet to the controller.
You're also right about the controller having to understand Ethernet frames tagged for priority both on the ingress (from the APs) and egress (to the application server to which Ethernet frames are intended).
Thank you very much for making my brain work!! :)
What kind of traffic impact is there by tunneling all of that traffic to the controller? Since controllers are sometimes very centralized on the LAN (lower TCO and all), are we talking about an excessive amount of traffic that is required to tunnel everything back to the controller rather than just letting the AP move it onto the LAN?
That was one of the major points of my blog recently. It's bad enough now, but soon it'll reach uncontrollable proportions. Right now, the biggest, baddest controller out there (in terms of raw throughput), is Aruba's 6000 unit. It can handle up to 512 APs/switch with 8 Gbps throughput (unencrypted), 7.2 Gbps (encrypted).
512 x 40 (the max throughput if you have an 802.11a/g AP) = ~20.5 Gbps. We're not yet to the point where all APs are saturated on both bands, but soon enough we would be if it weren't for 802.11n.
Once 802.11n hits, we're talking about 512 x 200 (minimum) = 102.4 Gbps. Each 802.11n radio can push well over 100 Mbps of throughput and there will be 2 radios in the average enterprise AP (one for 2.4 Ghz, one for 5 Ghz).
Show me a controller that can handle 100+ Gbps of AES-encrypted traffic, and I'll show you a Core Ethernet switch. :-)