RFC 8325
Mapping Diffserv to IEEE 802.11
6. Overview of IEEE 802.11 QoS
QoS is enabled on wireless networks by means of the Hybrid Coordination Function (HCF). To give better context to the enhancements in HCF that enable QoS, it may be helpful to begin with a review of the original Distributed Coordination Function (DCF).
6.1. Distributed Coordination Function (DCF)
As has been noted, the Wi-Fi medium is a shared medium, with each station -- including the wireless AP -- contending for the medium on equal terms. As such, it shares the same challenge as any other shared medium in requiring a mechanism to prevent (or avoid) collisions, which can occur when two (or more) stations attempt simultaneous transmission. The IEEE Ethernet Working Group solved this challenge by implementing a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) mechanism that could detect collisions over the shared physical cable (as collisions could be detected as reflected energy pulses over the physical wire). Once a collision was detected, then a predefined set of rules was invoked that required stations to back off and wait random periods of time before reattempting transmission. While CSMA/ CD improved the usage of Ethernet as a shared medium, it should be noted the ultimate solution to solving Ethernet collisions was the advance of switching technologies, which treated each Ethernet cable as a dedicated collision domain. However, unlike Ethernet (which uses physical cables), collisions cannot be directly detected over the wireless medium, as RF energy is radiated over the air and colliding bursts are not necessarily reflected back to the transmitting stations. Therefore, a different mechanism is required for this medium. As such, the IEEE modified the CSMA/CD mechanism to adapt it to wireless networks to provide Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA). The original CSMA/CA mechanism used in IEEE 802.11 was the Distributed Coordination Function. DCF is a timer- based system that leverages three key sets of timers, the slot time, interframe spaces and CWs.6.1.1. Slot Time
The slot time is the basic unit of time measure for both DCF and HCF, on which all other timers are based. The slot-time duration varies with the different generations of data rates and performances described by [IEEE.802.11-2016]. For example, [IEEE.802.11-2016] specifies the slot time to be 20 microseconds ([IEEE.802.11-2016], Table 15-5) for legacy implementations (such as IEEE 802.11b, supporting 1, 2, 5.5, and 11 Mbps data rates), while newer implementations (including IEEE 802.11g, 802.11a, 802.11n, and 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per spatial stream) define a shorter slot time of 9 microseconds ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
6.1.2. Interframe Space (IFS)
The time interval between frames that are transmitted over the air is called the Interframe Space (IFS). Several IFSs are defined in [IEEE.802.11-2016], with the most relevant to DCF being the Short Interframe Space (SIFS), the DCF Interframe Space (DIFS), and the Extended Interframe Space (EIFS). The SIFS is the amount of time in microseconds required for a wireless interface to process a received RF signal and its associated frame (as specified in [IEEE.802.11-2016]) and to generate a response frame. Like slot times, the SIFS can vary according to the performance implementation of [IEEE.802.11-2016]. The SIFS for IEEE 802.11a, 802.11n, and 802.11ac (in 5 GHz) is 16 microseconds ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). Additionally, a station must sense the status of the wireless medium before transmitting. If it finds that the medium is continuously idle for the duration of a DIFS, then it is permitted to attempt transmission of a frame (after waiting an additional random backoff period, as will be discussed in the next section). If the channel is found busy during the DIFS interval, the station must defer its transmission until the medium is found to be idle for the duration of a DIFS interval. The DIFS is calculated as: DIFS = SIFS + (2 * Slot time) However, if all stations waited only a fixed amount of time before attempting transmission, then collisions would be frequent. To offset this, each station must wait, not only a fixed amount of time (the DIFS), but also a random amount of time (the random backoff) prior to transmission. The range of the generated random backoff timer is bounded by the CW.6.1.3. Contention Window (CW)
Contention windows bound the range of the generated random backoff timer that each station must wait (in addition to the DIFS) before attempting transmission. The initial range is set between 0 and the CW minimum value (CWmin), inclusive. The CWmin for DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). However, it is possible that two (or more) stations happen to pick the exact same random value within this range. If this happens, then a collision may occur. At this point, the stations effectively begin the process again, waiting a DIFS and generate a new random backoff value. However, a key difference is that for this subsequent
attempt, the CW approximately doubles in size (thus, exponentially increasing the range of the random value). This process repeats as often as necessary if collisions continue to occur, until the maximum CW size (CWmax) is reached. The CWmax for DCF is specified as 1023 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). At this point, transmission attempts may still continue (until some other predefined limit is reached), but the CW sizes are fixed at the CWmax value. Incidentally it may be observed that a significant amount of jitter can be introduced by this contention process for wireless transmission access. For example, the incremental transmission delay of 1023 slot times (CWmax) using 9-microsecond slot times may be as high as 9 ms of jitter per attempt. And, as previously noted, multiple attempts can be made at CWmax.6.2. Hybrid Coordination Function (HCF)
Therefore, as can be seen from the preceding description of DCF, there is no preferential treatment of one station over another when contending for the shared wireless media; nor is there any preferential treatment of one type of traffic over another during the same contention process. To support the latter requirement, the IEEE enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, which was integrated into the main IEEE 802.11 standard in 2007.6.2.1. User Priority (UP)
One of the key changes to the frame format in [IEEE.802.11-2016] is the inclusion of a QoS Control field, with 3 bits dedicated for QoS markings. These bits are referred to the User Priority (UP) bits and these support eight distinct marking values: 0-7, inclusive. While such markings allow for frame differentiation, these alone do not directly affect over-the-air treatment. Rather, it is the non-configurable and standard-specified mapping of UP markings to the Access Categories (ACs) from [IEEE.802.11-2016] that generate differentiated treatment over wireless media.
6.2.2. Access Category (AC)
Pairs of UP values are mapped to four defined access categories that correspondingly specify different treatments of frames over the air. These access categories (in order of relative priority from the top down) and their corresponding UP mappings are shown in Figure 2 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1). +-----------------------------------------+ | User | Access | Designative | | Priority | Category | (informative) | |===========+============+================| | 7 | AC_VO | Voice | +-----------+------------+----------------+ | 6 | AC_VO | Voice | +-----------+------------+----------------+ | 5 | AC_VI | Video | +-----------+------------+----------------+ | 4 | AC_VI | Video | +-----------+------------+----------------+ | 3 | AC_BE | Best Effort | +-----------+------------+----------------+ | 0 | AC_BE | Best Effort | +-----------+------------+----------------+ | 2 | AC_BK | Background | +-----------+------------+----------------+ | 1 | AC_BK | Background | +-----------------------------------------+ Figure 2: Mappings between IEEE 802.11 Access Categories and User Priority The manner in which these four access categories achieve differentiated service over-the-air is primarily by tuning the fixed and random timers that stations have to wait before sending their respective types of traffic, as will be discussed next.
6.2.3. Arbitration Interframe Space (AIFS)
As previously mentioned, each station must wait a fixed amount of time to ensure the medium is idle before attempting transmission. With DCF, the DIFS is constant for all types of traffic. However, with [IEEE.802.11-2016], the fixed amount of time that a station has to wait will depend on the access category and is referred to as an Arbitration Interframe Space (AIFS). AIFSs are defined in slot times and the AIFSs per access category are shown in Figure 3 (adapted from [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). +-------------------------------------------+ | Access | Designative | AIFS | | Category | (informative) |(slot times)| |============+=================+============| | AC_VO | Voice | 2 | +------------+-----------------+------------+ | AC_VI | Video | 2 | +------------+-----------------+------------+ | AC_BE | Best Effort | 3 | +------------+-----------------+------------+ | AC_BK | Background | 7 | +------------+-----------------+------------+ Figure 3: Arbitration Interframe Spaces by Access Category6.2.4. Access Category CWs
Not only is the fixed amount of time that a station has to wait skewed according to its [IEEE.802.11-2016] access category, but so are the relative sizes of the CWs that bound the random backoff timers, as shown in Figure 4 (adapted from [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). +-------------------------------------------------------+ | Access | Designative | CWmin | CWmax | | Category | (informative) |(slot times)|(slot times)| |===========+=================+============|============| | AC_VO | Voice | 3 | 7 | +-----------+-----------------+------------+------------+ | AC_VI | Video | 7 | 15 | +-----------+-----------------+------------+------------+ | AC_BE | Best Effort | 15 | 1023 | +-----------+-----------------+------------+------------+ | AC_BK | Background | 15 | 1023 | +-----------+-----------------+------------+------------+ Figure 4: CW Sizes by Access Category
When the fixed and randomly generated timers are added together on a per-access-category basis, then traffic assigned to the Voice Access Category (i.e., traffic marked to UP 6 or 7) will receive a statistically superior service relative to traffic assigned to the Video Access Category (i.e., traffic marked UP 5 and 4), which, in turn, will receive a statistically superior service relative to traffic assigned to the Best Effort Access Category traffic (i.e., traffic marked UP 3 and 0), which finally will receive a statistically superior service relative to traffic assigned to the Background Access Category traffic (i.e., traffic marked to UP 2 and 1).6.3. IEEE 802.11u QoS Map Set
IEEE 802.11u [IEEE.802-11u-2011] is an addendum that has now been included within the main standard ([IEEE.802.11-2016]), and which includes, among other enhancements, a mechanism by which wireless APs can communicate DSCP to/from UP mappings that have been configured on the wired IP network. Specifically, a QoS Map Set information element (described in [IEEE.802.11-2016], Section 9.4.2.95, and commonly referred to as the "QoS Map element") is transmitted from an AP to a wireless endpoint device in an association / re-association Response frame (or within a special QoS Map Configure frame). The purpose of the QoS Map element is to provide the mapping of higher-layer QoS constructs (i.e., DSCP) to User Priorities. One intended effect of receiving such a map is for the wireless endpoint device (that supports this function and is administratively configured to enable it) to perform corresponding DSCP-to-UP mapping within the device (i.e., between applications and the operating system / wireless network interface hardware drivers) to align with what the APs are mapping in the downstream direction, so as to achieve consistent end-to-end QoS in both directions. The QoS Map element includes two key components: 1) each of the eight UP values (0-7) is associated with a range of DSCP values, and 2) (up to 21) exceptions from these range-based DSCP to/from UP mapping associations may be optionally and explicitly specified.
In line with the recommendations put forward in this document, the
following recommendations apply when the QoS Map element is enabled:
1) each of the eight UP values (0-7) are RECOMMENDED to be mapped to
DSCP 0 (as a baseline, so as to meet the recommendation made in
Section 8.2, and
2) (up to 21) exceptions from this baseline mapping are RECOMMENDED
to be made in line with Section 4.3, to correspond to the
Diffserv Codepoints that are in use over the IP network.
It is important to note that the QoS Map element is intended to be
transmitted from a wireless AP to a non-AP station. As such, the
model where this element is used is that of a network where the AP is
the edge of the Diffserv domain. Networks where the AP extends the
Diffserv domain by connecting other APs and infrastructure devices
through the IEEE 802.11 medium are not included in the cases covered
by the presence of the QoS Map element, and therefore are not
included in the present recommendation.
7. IANA Considerations
This document has no IANA actions.
8. Security Considerations
The recommendations in this document concern widely deployed wired
and wireless network functionality, and, for that reason, do not
present additional security concerns that do not already exist in
these networks. In fact, several of the recommendations made in this
document serve to protect wired and wireless networks from potential
abuse, as is discussed further in this section.
8.1. Security Recommendations for General QoS
It may be possible for a wired or wireless device (which could be
either a host or a network device) to mark packets (or map packet
markings) in a manner that interferes with or degrades existing QoS
policies. Such marking or mapping may be done intentionally or
unintentionally by developers and/or users and/or administrators of
such devices.
To illustrate: A gaming application designed to run on a smartphone
or tablet may request that all its packets be marked DSCP EF and/or
UP 6. However, if the traffic from such an application is forwarded
without change over a business network, then this could interfere
with QoS policies intended to provide priority services for business
voice applications.
To mitigate such scenarios, it is RECOMMENDED to implement general
QoS security measures, including:
o Setting a traffic conditioning policy reflective of business
objectives and policy, such that traffic from authorized users
and/or applications and/or endpoints will be accepted by the
network; otherwise, packet markings will be "bleached" (i.e.,
re-marked to DSCP DF and/or UP 0). Additionally, Section 5.3 made
it clear that it is generally NOT RECOMMENDED to pass through DSCP
markings from unauthorized and/or unauthenticated devices, as
these are typically considered untrusted sources. This is
especially relevant for Internet of Things (IoT) deployments,
where tens of billions of devices are being connected to IP
networks with little or no security capabilities, leaving them
vulnerable to be utilized as agents for DDoS attacks. These
attacks can be amplified with preferential QoS treatments, should
the packet markings of such devices be trusted.
o Policing EF marked packet flows, as detailed in [RFC2474],
Section 7, and [RFC3246], Section 3.
In addition to these general QoS security recommendations, WLAN-
specific QoS security recommendations can serve to further mitigate
attacks and potential network abuse.
8.2. Security Recommendations for WLAN QoS
The wireless LAN presents a unique DoS attack vector, as endpoint
devices contend for the shared media on a completely egalitarian
basis with the network (as represented by the AP). This means that
any wireless client could potentially monopolize the air by sending
packets marked to preferred UP values (i.e., UP values 4-7) in the
upstream direction. Similarly, airtime could be monopolized if
excessive amounts of downstream traffic were marked/mapped to these
same preferred UP values. As such, the ability to mark/map to these
preferred UP values (of UP 4-7) should be controlled.
If such marking/mapping were not controlled, then, for example, a
malicious user could cause WLAN DoS by flooding traffic marked CS7
DSCP downstream. This codepoint would map by default (as described
in Section 2.3) to UP 7 and would be assigned to the Voice Access
Category (AC_VO). Such a flood could cause Denial-of-Service to not
only wireless voice applications, but also to all other traffic
classes. Similarly, an uninformed application developer may request
all traffic from his/her application be marked CS7 or CS6, thinking
this would achieve the best overall servicing of their application
traffic, while not realizing that such a marking (if honored by the
client operating system) could cause not only WLAN DoS, but also IP
network instability, as the traffic marked CS7 or CS6 finds its way into queues intended for servicing (relatively low-bandwidth) network control protocols, potentially starving legitimate network control protocols in the process. Therefore, to mitigate such an attack, it is RECOMMENDED that all packets marked to Diffserv Codepoints not authorized or explicitly provisioned for use over the wireless network by the network administrator be mapped to UP 0; this recommendation applies both at the AP (in the downstream direction) and within the operating system of the wireless endpoint device (in the upstream direction). Such a policy of mapping unused codepoints to UP 0 would also prevent an attack where non-standard codepoints were used to cause WLAN DoS. Consider the case where codepoints are mapped to UP values using a range function (e.g., DSCP values 48-55 all map to UP 6), then an attacker could flood packets marked, for example, to DSCP 49, in either the upstream or downstream direction over the WLAN, causing DoS to all other traffic classes in the process. In the majority of WLAN deployments, the AP represents not only the edge of the Diffserv domain, but also the edge of the network infrastructure itself; that is, only wireless client endpoint devices are downstream from the AP. In such a deployment model, CS6 and CS7 also fall into the category of codepoints that are not in use over the wireless LAN (since only wireless client endpoint devices are downstream from the AP in this model and these devices do not (legitimately) participate in network control protocol exchanges). As such, it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in these Wi-Fi-at-the-edge deployment models. Otherwise, it would be easy for a malicious application developer, or even an inadvertently poorly programmed IoT device, to cause WLAN DoS and even wired IP network instability by flooding traffic marked CS6 DSCP, which would, by default (as described in Section 2.3), be mapped to UP 6, causing all other traffic classes on the WLAN to be starved, as well as hijacking queues on the wired IP network that are intended for the servicing of routing protocols. To this point, it was also recommended in Section 5.1 that packets requesting a marking of CS6 or CS7 DSCP SHOULD be re-marked to DSCP 0 and mapped to UP 0 by the wireless client operating system. Finally, it should be noted that the recommendations put forward in this document are not intended to address all attack vectors leveraging QoS marking abuse. Mechanisms that may further help mitigate security risks of both wired and wireless networks deploying QoS include strong device- and/or user-authentication, access- control, rate-limiting, control-plane policing, encryption, and other techniques; however, the implementation recommendations for such
mechanisms are beyond the scope of this document to address in detail. Suffice it to say that the security of the devices and networks implementing QoS, including QoS mapping between wired and wireless networks, merits consideration in actual deployments.9. References
9.1. Normative References
[IEEE.802.11-2016] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December 2016, <https://standards.ieee.org/findstds/ standard/802.11-2016.html>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/info/rfc2597>. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <https://www.rfc-editor.org/info/rfc3662>. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>. [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <https://www.rfc-editor.org/info/rfc5865>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.9.2. Informative References
[GSMA-IPX_Guidelines] GSM Association, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) Version 11.0", Official Document IR.34, November 2014, <https://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>. [IEEE.802-11u-2011] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 9: Interworking with External Networks", IEEE 802.11, DO 10.1109/IEEESTD.2011.5721908, February 2011, <http://standards.ieee.org/getieee802/ download/802.11u-2011.pdf>. [LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Work in Progress, draft-ietf-tsvwg-le-phb-02, June 2017. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <https://www.rfc-editor.org/info/rfc5127>. [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, "Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, DOI 10.17487/RFC7561, June 2015, <https://www.rfc-editor.org/info/rfc7561>. [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, <https://www.rfc-editor.org/info/rfc8100>.
Acknowledgements
The authors wish to thank David Black, Gorry Fairhurst, Ruediger Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, David Benham, and the TSVWG. The authors also acknowledge a great many inputs, notably from David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, Ramachandra Murthy, and many others.Authors' Addresses
Tim Szigeti Cisco Systems Vancouver, British Columbia V6K 3L4 Canada Email: szigeti@cisco.com Jerome Henry Cisco Systems Research Triangle Park, North Carolina 27709 United States of America Email: jerhenry@cisco.com Fred Baker Santa Barbara, California 93117 United States of America Email: FredBaker.IETF@gmail.com