In this post we will look at RFC 8325 recommendations for QoS mapping between 802.11 UP (User Priority) and DSCP (Differentiated Services Code Point). Since 802.11 is defined by IEEE and their primary focus on PHY & MAC layer, there are no considerations how QoS fields in WiFi header map into upper layer QoS field (eg DSCP in IP header). Due to lack of guidance, most vendors implemented QoS mapping on their own way and that leads into inconsistencies when we deploy QoS in WiFi environment. RFC 8325 provide general recommendation of mapping between 802.11UP and DSCP marking.

In a IP packet, QoS marking will be within TOS byte in a field called DSCP. There are well-known PHB (Per Hop Behaviors) defined by IETF for different type of traffic classes. QoS applied per hop basis by router/switch across the traffic path. If you have Layer 2 links (Trunk ports), then QoS value incorporated within 802.1Q tag in a field called PCP-Priority Code Point. Below diagram shows those different QoS field in wired frames.

When it comes to WiFi, you will have limited QoS capabilities. Primarily you classify traffic into 4 different Access Categories (Voice, Video, Best Effort & Background). When a QoS capable STA/AP transmit a data frame they will include QoS control field in WiFi header that include TID (Traffic Identifier) field. 3 bits of that field known as User Priority (or UP) value and determine the priority a WiFi frame get over the air. Since WiFi got 4 different traffic classes, two UP values map into each Access Category. Note that UP value 0 map to Best Effort (BE) in order to treat packet with no QoS marking with Best Effort Priority.

When it comes to mapping DSCP to UP values (downstream direction) or UP to DSCP (upstream direction), there could be many inconsistencies arise. Those are listed in RFC 8325 to highlight challenges facing when we implement WiFi QoS. Most of the vendors by default map 3 most significant bits (MSB) of DSCP value into UP. As an example, DSCP 46 map to UP value 5, which translate into AC_VI (Video) instead of that traffic goes in to AC_VO with UP value of 6.

By considering all of those challenges and RFC for Diffserv (2474, 2597, 3246, 4594, 5865) following recommendations made in RFC 8325 for downstream traffic (ie AP to Client).

Please not that even though it suggest CS5 for signaling (based on RFC4594), most vendors predominantly use CS3 for signaling traffic. Therefore, you will see Broadcast Video map into CS5 and Signaling traffic class map into CS3 in most of scenarios.

In the Upstream direction, it is not recommended to trust UP value and rewrite DSCP (this was the most common practices most of vendors done in the past). Since IEEE 802.11UP value is just QoS field for traffic flow within wireless cell and most of the client devices not properly mark UP value, it is not recommend to use that value for setting QoS on IP header.

In RFC 8325, it is recommended for you to implement upstream DSCP marking policy where you can apply common marking policy for both wired & wireless traffic when they come into network (in Access switch for wired, Access point for WiFi). In absence of such a marking policy, at least you should use upstream DSCP passthrough (in other words, you will trust original packet DSCP value instead of UP). Here is the summary of those upstream UP to DSCP mapping options described in that RFC.

So if you are deploying WiFi QoS today, you should pay attention how your WiFi vendor implement QoS and see if they realign with the RFC 8325 guidelines. When it comes to Cisco, they have modified their QoS recommendations to support mappings described in RFC 8325. We will look at how QoS is being implemented in AireOS and IOS-XE (9800) controllers in upcoming posts to match RFC 8325 guidelines.

In my “Rockstar QoS for WLAN Professional” digital course I will go through it bit more detail. If you are interested to learn QoS with Cisco 9800, I will be doing a Webinar 30 Sep 2021 at 3PM CST time. Pls register using this link.