draft-ietf-tsvwg-ieee-802-11-03.txt   draft-ietf-tsvwg-ieee-802-11-04.txt 
Transport Working Group T. Szigeti Transport Working Group T. Szigeti
Internet-Draft J. Henry Internet-Draft J. Henry
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 25, 2017 F. Baker Expires: January 4, 2018 F. Baker
May 24, 2017 July 3, 2017
Diffserv to IEEE 802.11 Mapping Diffserv to IEEE 802.11 Mapping
draft-ietf-tsvwg-ieee-802-11-03 draft-ietf-tsvwg-ieee-802-11-04
Abstract Abstract
As internet traffic is increasingly sourced-from and destined-to As internet traffic is increasingly sourced-from and destined-to
wireless endpoints, it is crucial that Quality of Service be aligned wireless endpoints, it is crucial that Quality of Service be aligned
between wired and wireless networks; however, this is not always the between wired and wireless networks; however, this is not always the
case by default. This document specifies a set Differentiated case by default. This document specifies a set Differentiated
Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
to reconcile the marking recommendations offered by the IETF and the to reconcile the marking recommendations offered by the IETF and the
IEEE so as to maintain consistent QoS treatment between wired and IEEE so as to maintain consistent QoS treatment between wired and
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4 1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.6. Terminology Used in this Document . . . . . . . . . . . . 5 1.6. Terminology Used in this Document . . . . . . . . . . . . 6
2. Service Comparison and Default Interoperation of Diffserv and 2. Service Comparison and Default Interoperation of Diffserv and
IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 9 2.2. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 10 2.3. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11
3. Wireless Device Marking and Mapping Capability 3. Wireless Device Marking and Mapping Capability
Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 12 4. DSCP-to-UP Mapping Recommendations . . . . . . . . . . . . . 12
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13 4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 13
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 13
4.1.2. Operations Administration Management (OAM) . . . . . 14 4.1.2. Operations Administration Management (OAM) . . . . . 14
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 16
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 16
4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 17 4.2.5. Multimedia-Streaming . . . . . . . . . . . . . . . . 16
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 17
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 17
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 17
4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18 4.2.9. Standard Service Class . . . . . . . . . . . . . . . 18
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 19 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 18
4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 19 4.3. DSCP-to-UP Mapping Recommendations Summary . . . . . . . 18
5. Upstream Mapping and Marking Recommendations . . . . . . . . 20 5. Upstream Mapping and Marking Recommendations . . . . . . . . 20
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client
Operating System . . . . . . . . . . . . . . . . . . . . 21 Operating System . . . . . . . . . . . . . . . . . . . . 20
5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 21 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 21
5.3. Upstream DSCP-Trust at the Wireless Access Point . . . . 22 5.3. Upstream DSCP-Trust at the Wireless Access Point . . . . 21
5.4. Upstream DSCP Marking at the Wireless Access Point . . . 22 5.4. Upstream DSCP Marking at the Wireless Access Point . . . 22
6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 23 6. Appendix: IEEE 802.11 QoS Overview . . . . . . . . . . . . . 22
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23 6.1. Distributed Coordination Function (DCF) . . . . . . . . . 23
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 23
6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24 6.1.2. Interframe Spaces . . . . . . . . . . . . . . . . . . 24
6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 25 6.1.3. Contention Windows . . . . . . . . . . . . . . . . . 24
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 25 6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 25
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25 6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 25
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 26 6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 25
6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 27 6.2.3. Arbitration Inter-Frame Space (AIFS) . . . . . . . . 26
6.2.4. Access Category Contention Windows (CW) . . . . . . . 27 6.2.4. Access Category Contention Windows (CW) . . . . . . . 27
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 28 6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8.1. General QoS Security Recommendations . . . . . . . . . . 29
8.2. WLAN QoS Security Recommendations . . . . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Wireless has become the preferred medium for endpoints connecting to Wireless has become the preferred medium for endpoints connecting to
business and private networks. However, the wireless medium defined business and private networks. However, the wireless medium defined
by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges by IEEE 802.11 [IEEE.802.11-2016] presents several design challenges
for ensuring end-to-end quality of service. Some of these challenges for ensuring end-to-end quality of service. Some of these challenges
relate to the nature of the IEEE 802.11 RF medium itself, being a relate to the nature of the IEEE 802.11 RF medium itself, being a
skipping to change at page 9, line 18 skipping to change at page 9, line 24
o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB o [IEEE.802.11-2016] loosely supports a [RFC3662] Lower Effort PDB
service via the Background Access Category (AC_BK) service via the Background Access Category (AC_BK)
As such, these high-level considerations should be kept in mind when As such, these high-level considerations should be kept in mind when
mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa); mapping from Diffserv to [IEEE.802.11-2016] (and vice-versa);
however, access points may or may not always be positioned at however, access points may or may not always be positioned at
Diffserv domain boundaries, as will be discussed next. Diffserv domain boundaries, as will be discussed next.
2.1. Diffserv Domain Boundaries 2.1. Diffserv Domain Boundaries
It is important to note that the wired-to-wireless edge may or may It is important to recognize that the wired-to-wireless edge may or
not equate to the edge of the Diffserv domain. may not equate to the edge of the Diffserv domain.
In most commonly-deployed WLAN models, the wireless access point In most commonly-deployed WLAN models, the wireless access point
represents not only the edge of the Diffserv domain, but also the represents not only the edge of the Diffserv domain, but also the
edge of the network infrastructure itself. As such, only client edge of the network infrastructure itself. As such, only client
devices (and no infrastructure devices) are downstream from the endpoint devices (and no infrastructure devices) are downstream from
access points in these deployment models. In such deployment models, the access points in these deployment models. Note: security
it is RECOMMENDED that all packets marked to Diffserv Codepoints not considerations and recommendations for hardening such Wifi-at-the-
in use over the wireless network be dropped or remarked at the edge edge deployment models are detailed in Section 8.
of the Diffserv domain, as will be discussed in detail in
Section 4.1.1.
Alternatively, in other deployment models, such as Wi-Fi backhaul, Alternatively, in other deployment models, such as Wi-Fi backhaul,
wireless mesh infrastructures, or other types of wireless AP-to-AP wireless mesh infrastructures, wireless AP-to-AP deployments, or in
deployments, the wireless access points extend the network cases where a Wi-Fi link connects to a device providing service via
infrastructure and thus, typically, the Diffserv domain. In such another technology (e.g. Wi-Fi to Bluetooth or Zigbee router), the
deployments, both client devices and infrastructure devices may be wireless access point extends the network infrastructure and thus,
expected downstream from the access points. typically, the Diffserv domain. In such deployments, both client
devices and infrastructure devices may be expected downstream from
the access points.
Thus the QoS treatment of packets at the access point will depend on Thus the QoS treatment of packets at the access point will depend on
the position of the AP in the network infrastructure and on the WLAN the position of the AP in the network infrastructure and on the WLAN
deployment model. deployment model.
However, regardless of the access point being at the Diffserv However, regardless of the access point being at the Diffserv
boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa) boundary or not, Diffserv to [IEEE.802.11-2016] (and vice-versa)
marking-specific incompatibilities exist that must be reconciled, as marking-specific incompatibilities exist that must be reconciled, as
will be discussed next. will be discussed next.
skipping to change at page 13, line 38 skipping to change at page 13, line 42
(signaling) that may be generated by some applications or services. (signaling) that may be generated by some applications or services.
Network control traffic MAY be split into two service classes: Network control traffic MAY be split into two service classes:
o Network Control, and o Network Control, and
o Operations Administration and Management (OAM) o Operations Administration and Management (OAM)
4.1.1. Network Control Protocols 4.1.1. Network Control Protocols
The Network Control service class is used for transmitting packets The Network Control service class is used for transmitting packets
between network devices (routers) that require control (routing) between network devices (e.g. routers) that require control (routing)
information to be exchanged between nodes within the administrative information to be exchanged between nodes within the administrative
domain as well as across a peering point between different domain, as well as across a peering point between different
administrative domains. The RECOMMENDED DSCP marking for Network administrative domains.
Control is CS6, per [RFC4594] Section 3.2.
Before discussing a mapping recommendation for Network Control
traffic marked CS6 DSCP, it is interesting to note a relevant
recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP:
in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7
DSCP (a codepoint that SHOULD be reserved for future use) be dropped
or remarked at the edge of the Diffserv domain.
Following this recommendation, it is RECOMMENDED that all packets
marked to Diffserv Codepoints not in use over the wireless network be
dropped or remarked at the edge of the Diffserv domain.
It is important to note that the wired-to-wireless edge may or may The RECOMMENDED DSCP marking for Network Control is CS6, per
not equate to the edge of the Diffserv domain, as discussed in [RFC4594] Section 3.2; additionally, CS7 DSCP value SHOULD be
Section 2.1; as such, this recommendation may or may not apply at the reserved for future use, potentially for future routing or control
wired-to-wireless edge (and vice-versa). protocols, again, per [RFC4594] Section 3.2.
In most commonly-deployed WLAN models, where wireless access point By default, packets marked DSCP CS7 will be mapped to UP 7 and
represents not only the edge of the Diffserv domain, but also the serviced within the Voice Access Category (AC_VO). This represents
edge of the network infrastructure itself. Traffic marked CS7 DSCP the RECOMMENDED mapping for CS7, that is, packets marked to CS7 DSCP
SHOULD be dropped or remarked at this edge (as it is typically are RECOMMENDED to be mapped to UP 7.
unused, as CS7 SHOULD be reserved for future use). Network control
traffic marked CS6 DSCP SHOULD also be dropped or remarked at this
edge, considering that only client devices (and no network
infrastructure devices) are downstream from the wireless access
points in these deployment models; such client devices would be
considered as untrusted sources of a network control traffic. In
such cases, no Network control traffic would be (legitimately)
expected to be sent or received from wireless client endpoint
devices, and thus this recommendation would apply.
Alternatively, in other deployment models, where the wireless access However, by default, packets marked DSCP CS6 will be mapped to UP 6
point extends the network infrastructure and thus, typically, the and serviced within the Voice Access Category (AC_VO); such mapping
Diffserv domain, the above recommendation would not apply, as the and servicing is a contradiction to the intent expressed in [RFC
wired-to-wireless edge does not represent the edge of the Diffserv 4594] section 3.2. As such, it is RECOMMENDED to map Network Control
domain. Furthermore, as these deployment models require Network traffic marked CS6 to UP 7 (per [IEEE.802.11-2016] Section 10.2.4.2,
Control traffic to be propagated across the wireless network, it is Table 10-1), thereby admitting it to the Voice Access Category
RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per (AC_VO), albeit with a marking distinguishing it from (data-plane)
[IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting voice traffic.
it to the Voice Access Category (AC_VO). Similarly, if CS7 is in use
as a network control protocol it would be RECOMMENDED to map it also
to UP 7.
It should be noted that encapsulated routing protocols for It should be noted that encapsulated routing protocols for
encapsulated or overlay networks (e.g., VPN, NVO3) are not network encapsulated or overlay networks (e.g., VPN, NVO3) are not network
control traffic for any physical network at the AP, and hence SHOULD control traffic for any physical network at the AP, and hence SHOULD
NOT be marked with CS6 in the first place. NOT be marked with CS6 in the first place.
Addtionally, and as previously noted, the Security Considerations
section (Section 8) contains additional recommendations for hardening
Wifi-at-the-edge deployment models, where, for example, network
control protocols are not expected to be sent nor recevied between
APs and downstream endpoint client devices.
4.1.2. Operations Administration Management (OAM) 4.1.2. Operations Administration Management (OAM)
The OAM (Operations, Administration, and Management) service class is The OAM (Operations, Administration, and Management) service class is
RECOMMENDED for OAM&P (Operations, Administration, and Management and RECOMMENDED for OAM&P (Operations, Administration, and Management and
Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per Provisioning). The RECOMMENDED DSCP marking for OAM is CS2, per
[RFC4594] Section 3.3. [RFC4594] Section 3.3.
By default, packets marked DSCP CS2 will be mapped to UP 2 and By default, packets marked DSCP CS2 will be mapped to UP 2 and
serviced with the Background Access Category (AC_BK). Such servicing serviced with the Background Access Category (AC_BK). Such servicing
is a contradiction to the intent expressed in [RFC4594] Section 3.3. is a contradiction to the intent expressed in [RFC4594] Section 3.3.
skipping to change at page 19, line 23 skipping to change at page 19, line 6
it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to
UP 1, thereby admitting it to the Background Access Category (AC_BK). UP 1, thereby admitting it to the Background Access Category (AC_BK).
4.3. DSCP-to-UP Mapping Recommendations Summary 4.3. DSCP-to-UP Mapping Recommendations Summary
Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped
to [IEEE.802.11-2016] UP and access categories applied in the to [IEEE.802.11-2016] UP and access categories applied in the
downstream direction (i.e. from wired-to-wireless networks). downstream direction (i.e. from wired-to-wireless networks).
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| IETF Diffserv | PHB |Reference| IEEE 802.11 | | IETF Diffserv | PHB |Reference| IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category | | Service Class | | RFC |User Priority| Access Category |
|===============+======+=========+=============+===================| |===============+======+=========+=============+====================|
| | | | 7 | AC_VO (Voice) | | | | | 7 | AC_VO (Voice) |
|Network Control| CS7 | RFC2474 | OR | |Network Control| CS7 | RFC2474 | OR |
|(reserved for | | | Remark/Drop at Diffserv Boundary| |(reserved for | | | 0 | AC_BE (Best Effort)|
| future use) | | | (See Section 4.1.1) | | future use) | | |See Security Considerations-Sec.8)|
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| | | | 7 | AC_VO (Voice) | | | | | 7 | AC_VO (Voice) |
|Network Control| CS6 | RFC2474 | OR | |Network Control| CS6 | RFC2474 | OR |
| | | | Remark/Drop at Diffserv Boundary| | | | | 0 | AC_BE (Best Effort)|
| | | | (See Section 4.1.1) | | | | |See Security Considerations-Sec.8)|
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Telephony | EF | RFC3246 | 6 | AC_VO (Voice) | | Telephony | EF | RFC3246 | 6 | AC_VO (Voice) |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) | | VOICE-ADMIT |VOICE-| RFC5865 | 6 | AC_VO (Voice) |
| |ADMIT | | | | | |ADMIT | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) | | Signaling | CS5 | RFC2474 | 5 | AC_VI (Video) |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Multimedia | AF41 | | | | | Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) | | Conferencing | AF42 | RFC2597 | 4 | AC_VI (Video) |
| | AF43 | | | | | | AF43 | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) | | Real-Time | CS4 | RFC2474 | 4 | AC_VI (Video) |
| Interactive | | | | | | Interactive | | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Multimedia | AF31 | | | | | Multimedia | AF31 | | | |
| Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) | | Streaming | AF32 | RFC2597 | 4 | AC_VI (Video) |
| | AF33 | | | | | | AF33 | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
|Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) | |Broadcast Video| CS3 | RFC2474 | 4 | AC_VI (Video) |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Low- | AF21 | | | | | Low- | AF21 | | | |
| Latency | AF22 | RFC2597 | 3 |AC_BE (Best Effort)| | Latency | AF22 | RFC2597 | 3 | AC_BE (Best Effort)|
| Data | AF23 | | | | | Data | AF23 | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| OAM | CS2 | RFC2474 | 0 |AC_BE (Best Effort)| | OAM | CS2 | RFC2474 | 0 | AC_BE (Best Effort)|
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| High- | AF11 | | | | | High- | AF11 | | | |
| Throughput | AF12 | RFC2597 | 0 |AC_BE (Best Effort)| | Throughput | AF12 | RFC2597 | 0 | AC_BE (Best Effort)|
| Data | AF13 | | | | | Data | AF13 | | | |
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Standard | DF | RFC2474 | 0 |AC_BE (Best Effort)| | Standard | DF | RFC2474 | 0 | AC_BE (Best Effort)|
+---------------+------+---------+-------------+-------------------+ +---------------+------+---------+-------------+--------------------+
| Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background)| | Low-Priority | CS1 | RFC3662 | 1 | AC_BK (Background) |
| Data | | | | | | Data | | | | |
+------------------------------------------------------------------+ +-------------------------------------------------------------------+
Note: All unusued codepoints are recommended to be mapped to UP 0
(See Security Considerations Section - Section 8)
Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping Figure 1: Summary of Downstream DSCP to IEEE 802.11 UP and AC Mapping
Recommendations Recommendations
5. Upstream Mapping and Marking Recommendations 5. Upstream Mapping and Marking Recommendations
In the upstream direction (i.e. wireless-to-wired), there are three In the upstream direction (i.e. wireless-to-wired), there are three
types of mapping that MAY be implemented: types of mapping that MAY be implemented:
o DSCP-to-UP mapping within the wireless client operating system o DSCP-to-UP mapping within the wireless client operating system
skipping to change at page 21, line 15 skipping to change at page 20, line 41
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating 5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating
System System
Some operating systems on wireless client devices utilize a similar Some operating systems on wireless client devices utilize a similar
default DSCP-to-UP mapping scheme as described in Section 2.2. As default DSCP-to-UP mapping scheme as described in Section 2.2. As
such, this can lead to the same conflicts as described in that such, this can lead to the same conflicts as described in that
section, but in the upstream direction. section, but in the upstream direction.
Therefore, to improve on these default mappings, and to achieve Therefore, to improve on these default mappings, and to achieve
parity and consistency with downstream QoS, it is RECOMMENDED that parity and consistency with downstream QoS, it is RECOMMENDED that
such wireless client operating systems utilize instead the same DSCP- wireless client operating systems utilize instead the same DSCP-to-UP
to-UP mapping recommendations presented in Section 4. mapping recommendations presented in Section 4, with the explicit
RECOMMENDATION that packets requesting a marking of CS6 or CS7 DSCP
SHOULD be mapped to UP 0 (and not to UP 7). Furthermore, in such
cases the wireless client operating system SHOULD remark such packets
to DSCP 0. This is because CS6 and CS7 DSCP, as well as UP 7
markings, are intended for network control protocols and these SHOULD
NOT be sourced from wireless client endpoint devices. This
recommendation is detailed in the Security Considerations section
(Section 8).
5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point 5.2. Upstream UP-to-DSCP Mapping at the Wireless Access Point
UP-to-DSCP mapping generates a DSCP value for the IP packet (either UP-to-DSCP mapping generates a DSCP value for the IP packet (either
an unencapsulated IP packet or an IP packet encapsulated within a an unencapsulated IP packet or an IP packet encapsulated within a
tunneling protocol such as CAPWAP - and destined towards a wireless tunneling protocol such as CAPWAP - and destined towards a wireless
LAN controller for decapsulation and forwarding) from the Layer 2 LAN controller for decapsulation and forwarding) from the Layer 2
[IEEE.802.11-2016] UP marking. This is typically done in the manner [IEEE.802.11-2016] UP marking. This is typically done in the manner
described in Section 2.3. described in Section 2.3.
skipping to change at page 22, line 9 skipping to change at page 21, line 45
[IEEE.802.11-2016] UP markings as set by wireless hosts and [IEEE.802.11-2016] UP markings as set by wireless hosts and
subsequently perform a UP-to-DSCP mapping in the upstream direction, subsequently perform a UP-to-DSCP mapping in the upstream direction,
but rather, if wireless host markings are to be trusted (as per but rather, if wireless host markings are to be trusted (as per
business requirements, technical constraints and administrative business requirements, technical constraints and administrative
policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings policies), then it is RECOMMENDED to trust the Layer 3 DSCP markings
set by these wireless hosts instead, as is discussed in the next set by these wireless hosts instead, as is discussed in the next
section. section.
5.3. Upstream DSCP-Trust at the Wireless Access Point 5.3. Upstream DSCP-Trust at the Wireless Access Point
It is NOT RECOMMENDED to trust DSCP markings from devices that are It is generally NOT RECOMMENDED to trust DSCP markings from
not authenticated and authorized; these are considered untrusted unauthenticated and unauthorized devices, as these are typically
sources. considered untrusted sources.
When business requirements and/or technical constraints and/or When business requirements and/or technical constraints and/or
administrative policies require a trust function at the wireless administrative policies require a trust function at the wireless
edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016] edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016]
UP markings) markings in the upstream direction, for the following UP markings) markings in the upstream direction, for the following
reasons: reasons:
o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP o [RFC2474], [RFC2475] and [RFC8100] all allow for hosts to set DSCP
markings to achieve an end-to-end differentiated service markings to achieve an end-to-end differentiated service
skipping to change at page 24, line 14 skipping to change at page 23, line 48
6.1.1. Slot Time 6.1.1. Slot Time
The slot time is the basic unit of time measure for both DCF and HCF, 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 on which all other timers are based. The slot time duration varies
with the different generations of data-rates and performances with the different generations of data-rates and performances
described by the [IEEE.802.11-2016] standard. For example, the described by the [IEEE.802.11-2016] standard. For example, the
[IEEE.802.11-2016] standard specifies the slot time to be 20 us [IEEE.802.11-2016] standard specifies the slot time to be 20 us
([IEEE.802.11-2016] Table 15-5) for legacy implementations (such as ([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 IEEE 802.11b, supporting 1, 2, 5.5 and 11 Mbps data rates), while
newer implementations (including IEEE 802.11g, 80.11a, 802.11n and newer implementations (including IEEE 802.11g, 802.11a, 802.11n and
802.11ac, supporting data rates from 500 Mbps to over 1 Gbps) define 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per
a shorter slot time of 9 us ([IEEE.802.11-2016], Section 17.4.4, spatial stream) define a shorter slot time of 9 us
Table 17-21). ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
6.1.2. Interframe Spaces 6.1.2. Interframe Spaces
The time interval between frames that are transmitted over the air is The time interval between frames that are transmitted over the air is
called the Interframe Space (IFS). Several IFS are defined in called the Interframe Space (IFS). Several IFS are defined in
[IEEE.802.11-2016], with the two most relevant to DCF being the Short [IEEE.802.11-2016], with the two most relevant to DCF being the Short
Interframe Space (SIFS) and the DCF Interframe Space (DIFS). Interframe Space (SIFS) and the DCF Interframe Space (DIFS).
The SIFS is the amount of time in microseconds required for a The SIFS is the amount of time in microseconds required for a
wireless interface to process a received RF signal and its associated wireless interface to process a received RF signal and its associated
skipping to change at page 29, line 20 skipping to change at page 28, line 46
DSCP values, and DSCP values, and
2) (up to 21) exceptions from these range-based DSCP to/from UP 2) (up to 21) exceptions from these range-based DSCP to/from UP
mapping associations may be optionally and explicitly specified. mapping associations may be optionally and explicitly specified.
In line with the recommendations put forward in this document, the In line with the recommendations put forward in this document, the
following recommendations apply when the QoS Map element is enabled: 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 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 DSCP 0 (as a baseline, so as to meet the recommendation made in
Section 4.1.1 that packets marked to unused Diffserv Codepoints be Section 8.2
remarked at the edge of the Diffserv domain), and
2) (up to 21) exceptions from this baseline mapping are RECOMMENDED 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 to be made in line with Section 4.3, to correspond to the Diffserv
Codepoints that are in use over the IP network. Codepoints that are in use over the IP network.
It is important to note that the QoS Map element is intended to be It is important to note that the QoS Map element is intended to be
transmitted from a wireless access point to a non-AP station. As transmitted from a wireless access point to a non-AP station. As
such, the model where this element is used is that of a network where 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 the AP is the edge of the Diffserv domain. Networks where the AP
extends the Diffserv domain by connecting other APs and extends the Diffserv domain by connecting other APs and
skipping to change at page 29, line 48 skipping to change at page 29, line 26
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
8. Security Considerations 8. Security Considerations
The recommendations put forward in this document do not present any The recommendations put forward in this document do not present any
additional security concerns that do not already exist in wired and additional security concerns that do not already exist in wired and
wireless devices. In fact, several of the recommendations made in wireless devices. In fact, several of the recommendations made in
this document serve to mitigate and protect wired and wireless this document serve to mitigate and protect wired and wireless
networks from potential abuse arising from existing vulnerabilities. networks from potential abuse arising from existing vulnerabilities.
For example, it may be possible for a wireless device, either a host 8.1. General QoS Security Recommendations
or a network device, to mark packets in a manner that interferes with
or degrades existing QoS policies. Similarly, it may be possible for
a device to map L2/L3 markings in a manner that causes similar
effects. Such marking or mapping may be done intentionally or
unintentionally by the developers and/or users and/or administrators
of such devices. To illustrate: A gaming application designed to run
on a smart-phone 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 trusted over a business network, then this could
interfere with QoS policies intended to provide priority services for
enterprise voice applications. To mitigate such attack vectors it is
RECOMMENDED to implement security measures, such as policing EF
marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246]
Section 3.
Furthermore, several recommendations have been made in this document It may be possible for a wired or wireless device (which could be
to mitigate the potential for deliberate or inadvertent violations. either a host or a network device) to mark packets (or map packet
Specifically the following recommendations have been made for markings) in a manner that interferes with or degrades existing QoS
primarily security reasons: policies. Such marking or mapping may be done intentionally or
unintentionally by developers and/or users and/or administrators of
such devices.
Section 4.1.1 RECOMMENDED that all packets marked to Diffserv To illustrate: A gaming application designed to run on a smart-phone
Codepoints not in use over the wireless network be dropped or or tablet may request that all its packets be marked DSCP EF and/or
remarked at the edge of the Diffserv domain. This recommendation UP 6. However, if the traffic from such an application is trusted
may help mitigate a Denial-of-Service attack vector that exists at over a business network, then this could interfere with QoS policies
wired-to-wireless edges in the downstream direction. For example, intended to provide priority services for business voice
consider a malicious user flooding traffic marked CS7 or CS6 DSCP applications.
toward the WLAN. These codepoints would map by default to UP 7
and UP 6 (respectively), both of which would be assigned to the
Voice Access Category (AC_VO). Such a flood could cause a Denial-
of-Service to wireless voice applications.
Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP To mitigate such scenarios it is RECOMMENDED to implement general QoS
markings from devices that are not authenticated and authorized, security measures, including:
as these are considered untrusted sources. This is especially
relevant for IoT, as billions of devices are being connected to IP
networks, many of which have little or no security.
Section 5.4 RECOMMENDED that the administrator treat the wireless Setting a trust boundary reflective of business objectives and
edge as the edge of the Diffserv domain and explicitly set (or policy, such that traffic from authorized users and/or
reset) DSCP markings in the upstream direction according to applications and/or endpoints will be accepted by the network;
administrative policy. UP-to-DSCP mapping was explicitly NOT otherwise packet markings will be "bleached" (i.e. remarked to
RECOMMENDED in Section 5.2. Also DSCP-trust was heavily caveated DSCP DF and/or UP 0). Additionally, Section 5.3 made it clear
in Section 5.3. These recommendations collectively serve to that it is generally NOT RECOMMENDED to trust DSCP markings from
mitigate Denial-of-Service attacks in the upstream direction. For unauthorized and/or unauthenticated devices, as these are
example, consider a malicious user flooding traffic from a typically considered untrusted sources. This is especially
wireless endpoint device marked DSCP 48 and/or UP 6. If default relevant for IoT deployments, where tens-of-billions of devices
UP-to-DSCP mapping were enabled at the access-point, these flows are being connected to IP networks, many of which have little or
would be mapped to DSCP 48, and could thus interfere with QoS no security.
policies intended to protect control plane protocols over the IP
network, resulting in potential network instability; such could
likewise happen if DSCP-trust were enabled in the same scenario.
Furthermore, it should be noted that the recommendations put forward Policing EF marked packet flows, as detailed in [RFC2474]
in this document are not intended to address all attack vectors 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. WLAN QoS Security Recommendations
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 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.
Therefore, to mitigate such an attack, it is RECOMMENDED that all
packets marked to Diffserv Codepoints not in use over the wireless
network be mapped to UP 0.
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.
It should be strongly noted that in the wireless deployment model
where the AP represents not only the edge of the Diffserv domain, but
also the edge of the network infrastructure itselt, then CS6 and CS7
also fall into the category of codepoints that are not in use over
the wireless LAN. This is because only wireless endpoint client
devices are downstream from the AP in this model, and as such, 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 Wifi-at-the-edge deployment models.
Otherwise, it would be easy for a malicious 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) be mapped to UP 6, causing all other
traffic classes on the WLAN to be starved, as well 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 remarked 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 leveraging QoS marking abuse. Mechanisms that may further help
mitigate security risks include strong device- and/or user- mitigate security risks include strong device- and/or user-
authentication, access-control, rate limiting, control-plane authentication, access-control, rate limiting, control-plane
policing, encryption and other techniques; however, the policing, encryption and other techniques; however, the
implementation recommendations for such mechanisms are beyond the implementation recommendations for such mechanisms are beyond the
scope of this document to address in detail. Suffice it to say that scope of this document to address in detail. Suffice it to say that
the security of the devices and networks implementing QoS, including the security of the devices and networks implementing QoS, including
QoS mapping between wired and wireless networks, SHOULD be considered QoS mapping between wired and wireless networks, SHOULD be considered
in actual deployments. in actual deployments.
skipping to change at page 32, line 48 skipping to change at page 33, line 22
<http://www.rfc-editor.org/info/rfc5865>. <http://www.rfc-editor.org/info/rfc5865>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <http://www.rfc-editor.org/info/rfc8100>. March 2017, <http://www.rfc-editor.org/info/rfc8100>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-tsvwg-le-phb] [I-D.ietf-tsvwg-le-phb]
Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
draft-ietf-tsvwg-le-phb-01 (work in progress), February draft-ietf-tsvwg-le-phb-02 (work in progress), June 2017.
2017.
[IEEE.802-11u.2011] [IEEE.802-11u.2011]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2011, Layer (PHY) specifications", IEEE Standard 802.11, 2011,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.11u-2011.pdf>. download/802.11u-2011.pdf>.
 End of changes. 38 change blocks. 
187 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/