| Transport Working Group | T. Szigeti |
| Internet-Draft | F. Baker |
| Intended status: Standards Track | Cisco Systems |
| Expires: January 7, 2016 | July 6, 2015 |
Guidelines for DiffServ to IEEE 802.11e Mapping
draft-szigeti-tsvwg-ieee-802-11e-00
As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This is due to the fact that two independent standards bodies provide QoS guidance on wired and wireless networks: specifically, the IETF offers design recommendations for wired IP networks, while a separate and autonomous standards-body, the IEEE, administers the standards for wireless 802.11e networks. The purpose of this document is to propose a set Differentiated Services Code Point (DSCP) to IEEE 802.11e User Priority (UP) mappings to reconcile the design recommendations offered by these two standards bodies, and, as such, to optimize wired-and-wireless interconnect QoS.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Wireless has become the medium of choice for endpoints connecting to business and private networks. However, the wireless medium defined by 802.11 [IEEE.802-11.2012] presents several design challenges for ensuring end-to-end quality of service. Some of these challenges relate to the nature of 802.11 RF medium itself, being a half-duplex and shared media, while other challenges relate to the fact that the 802.11 standard is not administered by the standards body that administers the rest of the IP network. While the IEEE has developed tools to enable QoS over wireless networks, little guidance exists on how to optimally interconnect wired IP and wireless 802.11e networks, which is the aim of this draft.
Several RFCs outline DiffServ QoS recommendations over IP networks, including:
This draft draws heavily on [RFC4594], [RFC5127], and [I-D.ietf-tsvwg-diffserv-intercon].
In turn, the relevant standard for wireless QoS is IEEE 802.11e, which has been progressively updated,
This document is primarily applicable to the use of Differentiated Services that interconnect with IEEE 802.11e wireless LANs (referred to as Wi-Fi, for simplicity, throughout this document). These guidelines are applicable whether the wireless access points (APs) are deployed in an autonomous manner, managed by (centralized or distributed) WLAN controllers or some hybrid deployment option. This is because in all these cases, the wireless access point is the bridge between wired and wireless media.
This document does not apply in full to access-point to access-point wireless networks, Wi-Fi backhaul or wireless mesh solutions, but rather applies to wired networks that have wireless access points at their access edges.
This document begins with a very brief overview of IEEE 802.11e in Section 2, focusing on how QoS is achieved over the shared, half- duplex wireless medium. This discussion is followed by Section 3 which compares DiffServ QoS with Wi-Fi QoS and highlights discrepancies requiring reconciliation. Section 4 presents downstream (wired-to-wireless) DSCP-to-UP mapping recommendations for each of the RFC 4594 traffic classes. And finally, Section 5 considers upstream (wireless-to-wired) QoS options and their respective merits.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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).
As has been noted, the Wi-Fi medium is a shared medium, with each station-including the wireless access point-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 pre-defined set of rules was invoked that required stations to back off and wait random periods of time before re-attempting 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 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 contention windows.
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 the 802.11 standard. For example, the IEEE 802.11-2012 standard specifies the slot time to be 20 us (IEEE 802.11-2012 Table 16-2) for legacy implementations (such as 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while newer implementations (including 802.11g, 80.11a, 802.11n and 802.11ac, supporting data rates from 500 Mbps to over 1 Gbps) define a shorter slot time of 9 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17).
The time interval between frames that are transmitted over the air is called the Interframe Space (IFS). Several IFS are defined in 802.11, with the two most relevant to DCF being the Short Interframe Space (SIFS) and the DCF Interframe Space (DIFS).
The SIFS is the amount of time in microseconds required for a wireless interface to process a received RF signal and its associated 802.11 frame and to generate a response frame. Like slot times, the SIFS can vary according to the performance implementation of the 802.11 standard. The SIFS for 802.11a, 802.11n and 802.11ac (in 5 Ghz) is 16 us (IEEE 802.11-2012, Section 18.4.4, Table 18-17).
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 idle for the duration of a DIFS interval. The DIFS is calculated as:
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 Contention Window.
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 Contention Window minimum value (CWmin), inclusive. The CWmin for DCF is specified as 15 slot times (in 5 GHz - IEEE 802.11- 2012, Section 18.4.4, Table 18-17).
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 will 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 Contention Window approximatively 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 Contention Window size (CWmax) is reached. The CWmax for DCF is specified as 1023 slot times (IEEE 802.11-2012, Section 18.4.4, Table 18-17).
At this point, transmission attempts may still continue (until some other pre-defined limit is reached), but the Contention Window 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 access. For example, the incremental transmission delay of 1023 slot times (CWmax) using 9 us slot times may be as high as 9 ms of jitter per attempt. And as previously noted, multiple attempts can be made at CWmax. This is of value in decoupling transmission attempts [RFC3439].
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 802.11e. 802.11e was integrated in the main standard in 2007 and is now part of 802.11.
One of the key changes to the 802.11e frame format 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 802.11e Access Categories (AC) that generate differentiated treatment over wireless media.
Pairs of UP values are mapped to four defined access categories that 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 1 Figure 1. (adapted from IEEE 802.11e-2012, Section 9.2.4.2, Table 9-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 1: IEEE 802.11e Access Categories and User Priority Mappings
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 these various types of traffic, as will be discussed next.
As previously mentioned, each station must wait a fixed amount of time to ensure the air is clear before attempting transmission. With DCF, the DIFS is constant for all types of traffic. However, with 802.11e 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). AIFS are defined in slot times and the AIFS per access category are shown in Figure 2 (adapted from IEEE 802.11e-2012, Section 8.4.2.31, Table 8-105). Figure 2.
+------------------------------------------+ | 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 2: Arbitration Interframe Spaces by Access Category
Not only is the fixed amount of time that a station has to wait skewed according to 802.11e access category, but so are the relative sizes of the Contention Windows that bound the random backoff timers, as shown in Figure 3 (adapted from IEEE 802.11e- 2012, Section 8.4.2.31, Table 8-105).Figure 3.
+-------------------------------------------------------+ | 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 3: Contention Window Sizes by Access Category
When the per access category fixed and randomly generated timers are added together, then voice access category traffic (i.e. traffic marked to UP 6 or 7) will receive (statistically) superior service relative to video access category traffic (i.e. UP 5 and 4), which in turn will receive (statistically) superior service relative to best effort access category traffic (i.e. UP 3 and 0), which finally will receive (statistically) superior service relative to background access category traffic (i.e. UP 2 and 1).
However the following comparisons between IEEE 802.11e and DiffServ should be noted:
As such, these are high-level considerations that need to be kept in mind when mapping from DiffServ to 802.11e (and vice-versa); however, some additional marking-specific incompatibilities must also be reconciled, as will be discussed next.
While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 802.11e), the networking industry norm has been to map these using the default method of transcribing the 3 Most Significant Bits (MSB) of the DSCP to generate the L2 markings.
(Note: There are example mappings in IEEE 802.11 [Annex V Tables V-1 and V2 from 3GPP 23.836 to IEEE 802.1D], but these mappings are provided as examples (vs. as recommendations). Furthermore, some of these mappings do not align with the intent and recommendations expressed in RFC 4594, as will be discussed in the following section).
However, when this default DSCP-to-UP mapping method is applied to packets marked per RFC 4594 recommendations and destined to 802.11e WLAN clients, it will yield a number of sub-optimal QoS mappings, specifically:
It should also be noted that while IEEE 802.11e defines an intended use for each access category through the AC naming convention (for example, UP 6 and UP 7 belong to AC_VO, the Voice Access Category), 802.11 does not:
In the opposite direction of flow (the upstream direction, that is, from wireless-to-wired), most APs use a default method of deriving DSCP values from UP values by multiplying these by 8 (i.e. shifting the 3 UP bits to the left and adding three additional zeros to generate a DSCP value). This default-derived DSCP value is then used for QoS treatment between the wireless access point and the nearest classification and marking policy enforcement point (which may be the centralized wireless LAN controller, relatively deep within the network).
It goes without saying that when 6 bits of marking granularity are derived from 3, then information is lost in translation. Distinctions cannot be made for 12 classes of traffic (as recommended in RFC 4594), but for only 8 (with one of these classes being reserved for future use (i.e. UP 7 which maps to DSCP CS7).
Such default upstream mapping can also yield several inconsistencies with RFC 4594, including:
Thus, the next sections of this draft seek to address these limitations and concerns and reconcile the intents of RFC 4594 and IEEE 802.11e. First the downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned and then upstream (wireless-to-wired) models will be addressed.
The following section proposes downstream (wired-to-wireless) mappings between RFC 4594 Configuration Guidelines for DiffServ Service Classes and IEEE 802.11. As such, this section draws heavily from RFC 4594, including traffic class definitions and recommendations.
This section assumes wireless access points and/or WLAN controllers that support customizable, non-default DSCP-to-UP mapping schemes.
Network control traffic is defined as packet flows that are essential for stable operation of the administered network. Network control traffic is different from user application control (signaling) that may be generated by some applications or services. Network Control Traffic may be split into two service classes:
The Network Control service class is used for transmitting packets between network devices (routers) that require control (routing) information to be exchanged between nodes within the administrative domain as well as across a peering point between different administrative domains. The RECOMMENDED DSCP marking for Network Control is CS6.
Before discussing a mapping recommendation for Network Control traffic marked to CS6 DSCP, it is interested to note a relevant recommendation pertaining to traffic marked CS7 DSCP (which is reserved for future use): in RFC 4594-Section 3.1 it is RECOMMENDED that CS7 DSCP marked packets be dropped or remarked at the edge of the DiffServ domain.
In most commonly deployed models (consistent with the Applicability Statement defined in section 1.3), the wireless access point represents the edge of the DiffServ domain (being at the same time the edge of the network infrastructure), as such and in line with the above recommendation, this would be an appropriate place to remark or drop traffic marked CS7 DSCP (or for that matter, any other DSCP not in use).
However, this recommendation could similarly apply to Network Control traffic at the edge of the DiffServ domain. Considering that downstream from the wireless access point typically only client devices are connected to the network and not network infrastructure devices (as detailed in the Applicability Statement in Section 1.3). In such cases, no network control traffic would be expected to be sent or received from such devices. As such, in the majority of cases where the wired-to-wireless boundary also represents the edge of the DiffServ domain (being at the same time the edge of the network infrastructure), then traffic marked CS6 DSCP is also RECOMMENDED to be dropped or remarked at this edge.
Note: It bears repeating that this recommendation applies to wired-to-wireless edges that are also the edges of the DiffServ domain (representing the edge of the network infrastructure itself). In deployment models where this is not the case, such as Wi-Fi backhaul, wireless AP-to-AP deployments, or other wireless mesh infrastructures, then propagating network control traffic downstream is not only RECOMMENDED, but required.
These QoS actions can prevent abuse of wireless network resources. For instance, consider the attack vector of a malicious user targeting wireless clients by flooding traffic marked to CS7 or CS6 DSCP (which would map by default to UP 7 and UP 6, respectively; both of which would be assigned to AC_VO) with the intent of flooding the voice access category causing a Denial-of-Service to wireless voice applications.
The OAM (Operations, Administration, and Management) service class is RECOMMENDED for OAM&P (Operations, Administration, and Management and Provisioning). The RECOMMENDED DSCP marking for OAM is CS2.
By default, packets marked DSCP CS2 will be mapped to UP 2 and serviced with the background access category. Such servicing is a contradiction to the intent expressed in RFC 4594-Section 3.3. As such, it is RECOMMENDED that a non-default mapping be applied to OAM traffic, such that CS2 DSCP is mapped to UP 0.
User traffic is defined as packet flows between different users or subscribers. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services. Network administrators can categorize their applications according to the type of behavior that they require and MAY choose to support all or a subset of the defined service classes.
The Telephony service class is RECOMMENDED for applications that require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service. The fundamental service offered to traffic in the Telephony service class is minimum jitter, delay, and packet loss service up to a specified upper bound. The RECOMMENDED DSCP marking for Telephony is EF.
As EF traffic will map by default to UP 5 (and thus the video access category), a non-default DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP 6 (and therefore to the voice access category).
The Signaling service class is RECOMMENDED for delay-sensitive client-server (traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between IP phone and soft-switch, soft-client and soft-switch, and media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. The RECOMMENDED DSCP marking for Signaling is CS5.
While signaling is RECOMMENDED to receive a superior level of service relative to the default class (i.e. AC_BE), it does not require the highest level of service (i.e. AC_VO). This leaves only the video access category, which it will map to by default. However, to better distinguish inelastic video flows from elastic video and signaling flows (as will be discussed next), it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 4.
Both the Real-Time Interactive and Broadcast Video traffic classes are considered to be inelastic, in that the traffic in these classes does not have the ability (or the business requirement precludes the use of the ability) to change encoding, resolution, frame or transmission rates to dynamically adapt to network conditions such as congestion and/or packet loss. The Real-Time Interactive and Broadcast Video traffic classes are intended for bi-directional and unidirectional inelastic video flows (respectively).
Specifically, the Real-Time Interactive traffic class is RECOMMENDED for applications that require low loss and jitter and very low delay for variable rate inelastic traffic sources. The RECOMMENDED DSCP marking for Real-Time Interactive is CS4.
Similarly, the Broadcast Video service class is RECOMMENDED for applications that require near-real-time packet forwarding with very low packet loss of constant rate and variable rate inelastic traffic sources. The RECOMMENDED DSCP marking for Broadcast Video is CS3.
While considering Table 1 it may seem superfluous to make a distinction between inelastic video classes (by mapping these to UP 5) and elastic video classes (by mapping these to UP 4), as both are destined to be serviced with the same video access category. However, a subtlety in implementation merits consideration and provides the rationale behind this recommendation.
IEEE 802.11-2012 illustrates a reference implementation model in Figure 9-19 which depicts four transmit queues, one per access category. In practical implementation, however, it is common for network vendors to actually implement dedicated transmit queues on a per-UP basis, which are then dequeued into the associated access category in a preferred (or even strict priority manner). For example, (and specific to this example): it is common for network vendors to dequeue UP 5 ahead of UP 4 to the hardware performing the EDCA function (EDCAF) for the video access category. As such, inelastic video flows can benefit from this distinction in servicing.
A corollary benefit may also be realized in the upstream direction, for if inelastic video flows are marked to a separate UP from elastic video (or signaling) flows, then these can easily be distinguished from each other and serviced accordingly in the upstream direction.
For these reasons it is RECOMMENDED to map inelastic video traffic marked CS4 and CS3 DSCP to UP 5.
In contrast to Real-Time Interactive and Broadcast Video, the Multimedia Conferencing and Multimedia Streaming traffic classes are intended for bi-directional and unidirectional elastic video flows (respectively).
Specifically, the Multimedia Conferencing service class is RECOMMENDED for applications that require real-time service for rate-adaptive traffic. The RECOMMENDED DSCP markings for Multimedia Conferencing are AF41, AF42 and AF43.
Similarly, the Multimedia Streaming The Multimedia Streaming service class is RECOMMENDED for applications that require near-real-time packet forwarding of variable rate elastic traffic sources. The RECOMMENDED DSCP markings for Multimedia Streaming are AF31, AF32 and AF33.
In line with the recommendation made in the previous section, and to preclude the default mapping of Multimedia Streaming to UP 3 (and hence to AC_BE), it is RECOMMENDED to map inelastic video/multimedia traffic classes marked AF4x and AF3x DSCP to UP 4.
The Low-Latency Data service class is RECOMMENDED for elastic and time-sensitive data applications, often of a transactional nature, where a user is waiting for a response via the network in order to continue with a task at hand. As such, these flows may be considered foreground traffic, with delays or drops to such traffic directly impacting user-productivity. The RECOMMENDED DSCP markings for Low-Latency Data are AF21, AF22 and AF23.
In line with the recommendations made in Section 4.2.3, mapping Low-Latency Data to UP 3 may allow such to receive a superior level of service via transmit queues servicing the EDCAF hardware for the best effort access category, as well as providing for a distinction between such traffic vs. best effort in the upstream direction. Therefore it is RECOMMENDED to map Low-Latency Data traffic marked AF2x DSCP to UP 3.
The High-Throughput Data service class is RECOMMENDED for elastic applications that require timely packet forwarding of variable rate traffic sources and, more specifically, is configured to provide efficient, yet constrained (when necessary) throughput for TCP longer-lived flows. These flows are typically non-user-interactive and, as such, can be considered background traffic. It can also be assumed that this class will consume any available bandwidth and that packets traversing congested links may experience higher queuing delays or packet loss, as well as that this traffic is elastic and responds dynamically to packet loss. The RECOMMENDED DSCP markings for High-Throughput Data are AF11, AF12 and AF13.
In line with the recommendations made in Section 4.2.3, mapping High-Throughput Data to UP 2 may allow such to receive a superior level of service via transmit queues servicing the EDCAF hardware for the background access category, as well as providing for a distinction between such traffic vs. Low-Priority Data in the upstream direction. Therefore it is RECOMMENDED to map High-Throughput Data traffic marked AF1x DSCP to UP 2.
The Standard service class is RECOMMENDED for traffic that has not been classified into one of the other supported forwarding service classes in the DiffServ network domain. This service class provides the Internet's "best-effort" forwarding behavior. The RECOMMENDED DSCP marking for the Standard Service Class is DF.
The Standard Service Class loosely corresponds to the 802.11e best effort access category and therefore it is RECOMMENDED to map Standard Service Class traffic marked DF DSCP to UP 0.
The Low-Priority Data service class serves applications that the user is willing to accept service without guarantees. This service class is specified in [RFC3662].
The Low-Priority Data service class loosely corresponds to the 802.11e background access category and therefore it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1.
Figure 4 summarizes the RFC 4594 DSCP marking recommendations mapped to IEEE 802.11e UP and access categories applied in the downstream direction (from wired-to-wireless networks)
+------------------------------------------------------------------+ | IETF DiffServ | DSCP | PHB | IEEE 802.11e | | Service Class | | Used |User Priority| Access Category | |===============+======+=========+=============+===================| |Network Control| CS6 | RFC2474 | 0 |AC_BE (Best Effort)| +---------------+------+---------+-------------+-------------------+ | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | +---------------+------+---------+-------------+-------------------+ | Signaling | CS5 | RFC2474 | 4 | AC_VI (Video) | +---------------+------+---------+-------------+-------------------+ | Multimedia | AF41 | | | | | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | | | AF43 | | | | +---------------+------+---------+-------------+-------------------+ | Real-Time | CS4 | RFC2474 | 5 | AC_VI (Video) | | Interactive | | | | | +---------------+------+---------+-------------+-------------------+ | Multimedia | AF31 | | | | | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | | | AF33 | | | | +---------------+------+---------+-------------+-------------------+ |Broadcast Video| CS3 | RFC2474 | 5 | AC_VI (Video) | +---------------+------+---------+-------------+-------------------+ | Low- | AF21 | | | | | Latency | AF22 | RFC2597 | 3 |AC_BE (Best Effort)| | Data | AF23 | | | | +---------------+------+---------+-------------+-------------------+ | OAM | CS2 | RFC2474 | 3 |AC_BE (Best Effort)| +---------------+------+---------+-------------+-------------------+ | High- | AF11 | | | | | Throughput | AF12 | RFC2597 | 2 | AC_BK (Background)| | Data | AF13 | | | | +---------------+------+---------+-------------+-------------------+ | Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| +---------------+------+---------+-------------+-------------------+ | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| | Data | | | | | +------------------------------------------------------------------+
Figure 4: Summary of Downstream DSCP to IEEE 802.11e UP and AC Mapping Recommendations
There are two main models than are commonly used in the upstream (wireless-to-wired) direction to affect the DSCP used in the wired network:
UP-to-DSCP mapping generates a DSCP value for the IP packet (either the final IP packet or an IP packet encapsulated within a tunneling protocol such as CAPWAP - and destined towards a wireless LAN controller for decapsulation and forwarding) from the Layer 2 IEEE UP markings of the wireless frame.
It should be noted that any explicit remarking policy to be performed on such a packet only takes place at the nearest classification and marking policy enforcement point, which may be:
As such, UP-to-DSCP mapping allows for wireless L2 markings to affect the QoS treatment of a packet over the wired IP network (that is, until the packet reaches the nearest classification and marking policy enforcement point).
It should be noted that nowhere in the IEEE 802.11 specifications is there an intent expressed for 802.11e UP to be used to influence QoS treatment over wired IP networks. Furthermore, both RFC 2474 and RFC 2475 allow for the host to set DSCP markings for QoS treatment over IP networks. Therefore, it is NOT RECOMMENDED that wireless access points trust UP markings as set by these hosts and subsequently perform a UP-to-DSCP mapping in the upstream direction, but rather, if wireless host markings are to be trusted (as per business requirements, technical constraints and administrative preference), then it is RECOMMENDED to trust the DSCP markings set by these wireless hosts.
On platforms that support the trusting of DSCP markings encapsulated within wireless frames it is RECOMMENDED to trust these DSCP markings in the upstream direction by the wireless access point, for the following reasons:
This memo asks the IANA for no new parameters.
As mentioned in Section 4.1.1, a Denial-of-Service attack vector exists at the edges of wired and wireless networks due to the requirement of trusting traffic markings to ensure end-to-end QoS. As such, it is RECOMMENDED to remark or drop any DSCP or UP values not in use.
| [RFC2597] | Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. |
| [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, March 2002. |
| [RFC3439] | Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002. |
| [RFC5127] | Chan, K., Babiarz, J. and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, February 2008. |