Forum

Hi

I recently had a conversation with a guy who is a CCIE in Voice. The topic was simple.

How does the AP or the authenticator, will trust that the packets coming from a voice device with 802.11e Qos in it, is actually coming for a trusted voice device, and get his or her packets prioritized?

He argued that with the standardization of 802.11e on Sept 22, 2005, the control technology for implementation of Qos in the packets were assigned to the clients (associated with APs) and not centrally managed. In that case any client could change his or her packets easily with the respective Qos classes and gets the priority.

I could not convince him that the WPA/TKIP, WPA11 security mechanism would solve the problem of tracking down the packets that come from a legimate client.

But still his argument was, Cisco Call Manager Express (CCME) or Call Manager (CM) would certainly identify which are of its IP phone and would prioritize its packets. Because, all their IP phones were physically connected. It means that a CCME or CM physically verifies that the packets were coming from its legimate IP phones. But in the case of WLAN, how can the AP really identify by device? Assuming, that if 2 stations were authenticated with WPA/TKIP, what stops from one station to put Qos parameters in its packet before leaving its WLAN card, and acting like a Voice device and get its packet prioritized? Seeing that Qos is there in the packets, AP would prioritize its packet first, assuming that it a VoIP device. This is not a real Qos, implemented in a efficient way, especially for WLAN.

I am breaking my head to get an answer.

Thank you.
SMITH JOSEPH ARULANANDAM

I have had this exact same questions. Anyone have an answer?

From 802.11e-2005

user priority (UP): A value associated with an MSDU that indicates how the MSDU is to be handled.
The UP is assigned to an MSDU in the layers above the MAC.

6.1.1.1 Determination of UP
The QoS facility supports 8 priority values, referred to as user priorities (UPs). The values a UP may take are the integer values from 0 to 7 and are identical to the IEEE 802.1D priority tags. An MSDU with a particular UP is said to belong to a traffic category (TC) with that UP. The UP is provided with each MSDU at the medium access control service access point (MAC_SAP), either directly, in the UP parameter, or indirectly, in a traffic specification (TSPEC) designated by the UP parameter.

6.1.1.1.1 Determination of UP of received frames at the QAP sent by other STAs in the BSS
The received unicast frames at the QAP may be:

a) Non-QoS subtypes, in which case the QAP shall assign to them a priority of Contention if they are
received during the CP, or ContentionFree, if they are received during the CFP.
b) QoS subtypes, in which case the QAP shall infer the UP value from the TID in the QoS control field
directly for TID values between 0 and 7. For TID values between 8 and 15, the QAP shall extract the
UP value in the user priority subfield of the TS Info field in the associated TSPEC or from the User
priority field in the associated TCLAS element, as applicable.

QAPs deliver the user priority with the received MSDUs to the DS.

-------------------

This says basically that the layers above the MAC layer are responsible for giving the user priority (UP) to each MSDU (data frame) and the QAP (an AP that understands handling of QoS based frames) must prioritize the traffic according to the UP value.

Your understanding of how 802.11e works, if I understood your email, is correct. There is no centralized QoS handling mechanism. The responsibility of properly prioritizing QoS MSDUs is left up to the QSTA.

Devinator

Hi Smith of Toronto:

IEEE 802.5 Token Ring has priority bits. It is the responsibility of the station and/or application to set the bits appropriately. I have heard it said that during the glory days of Token Ring every application defaulted to giving its packets the highest priority, and no one cared to adjust any application downward.

Now comes the 802.11e amendment with a detailed priority mechanism. Again it is the responsibility of the station and/or applications to set the priority bits appropriately.

While a cavalier 802.11 station may take unfair advantage for transmitting its own frames, the priority set in those frames need not be honored by the access point and forwarded into the infrastructure.

I predict 802.11 access points will use their own policy to reset priority in frames received from client stations not under their strict control, and honor the priority in frames received from the infrastructure. I predict that if cavalier priority setting client stations become a nuisance, access points will be designed to recognize and exclude them from their WLANs. WLAN telephony must not be hindered.

I hope this helps. Thanks. /criss

Smith,

I believe in our wired network the switches disreguard the QOS set by the end device and set it based upon the VLAN. The VLANs are tied to the physical port. IP phones have their own ports thus they're in a VLAN separate from other devices.

Should we go to soft phones then we will have to choose whether to honor the prioritization set by the end devices.

I can see where multi-use devices that abuse prioritization will necessitate edge devices performing deep packet inspection and setting priorities.

regards,

moe

Hi

Thanks for your replies. It was helpful to clarify the details. But again, it defaults to the same situation. But one point though, was the idea by Criss that QAP will have a way to figure out the voice traffic by way of a policiy settings.

Products such as SpectraLink's wireless phones and other voice device manufacturers had already taken the steps to make APs enable to identify special voice traffic through specific indications in the protocols coming from a specific voice device. One example, again from SpectraLink is SVP, which stands for SpectraLink Voice Priority, which can be generated only from a SpectraLink wireless phones.

Since such a protocol identification mechanism were already enabled in the APs, it won't be a big deal to those APs to figure out that these traffics are only generated by these specific devices and prioritize their packets. Even some may argue that it is a proprietory solution, but it is still a nice packet characterization mechanism to identify and trust that packets were from a legitimate wireless phone. And that's why I guess the IEEE have left it to the client vendors to endrose their packets Qos in the way they want it.

Let's see if some changes happening in 802.11n standard. I guess until for now, we have to rely on proprietory solutions for Qos in WLANs.

Regards
SMITH JOSEPH ARULANANDAM