draft-ietf-tsvwg-ieee-802-11-06.txt   draft-ietf-tsvwg-ieee-802-11-07.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: February 17, 2018 F. Baker Expires: March 12, 2018 F. Baker
August 16, 2017 September 8, 2017
Diffserv to IEEE 802.11 Mapping Diffserv to IEEE 802.11 Mapping
draft-ietf-tsvwg-ieee-802-11-06 draft-ietf-tsvwg-ieee-802-11-07
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
IEEE 802.11 wireless networks. IEEE 802.11 wireless networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 February 17, 2018. This Internet-Draft will expire on March 12, 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 5, line 47 skipping to change at page 5, line 47
the shared, half-duplex nature of the wireless medium. the shared, half-duplex nature of the wireless medium.
o Section 7 on notes IANA considerations o Section 7 on notes IANA considerations
o Section 8 presents security considerations relative to DSCP-to-UP, o Section 8 presents security considerations relative to DSCP-to-UP,
UP-to-DSCP mapping and remarking UP-to-DSCP mapping and remarking
1.5. Requirements Language 1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
RECOMMENDED" in this document are to be interpreted as described in document are to be interpreted as described in [RFC2119].
[RFC2119].
1.6. Terminology Used in this Document 1.6. Terminology Used in this Document
Key terminology used in this document includes: Key terminology used in this document includes:
AC: Access Category. A label for the common set of enhanced AC: Access Category. A label for the common set of enhanced
distributed channel access (EDCA) parameters that are used by a distributed channel access (EDCA) parameters that are used by a
quality-of-service (QoS) station (STA) to contend for the channel quality-of-service (QoS) station (STA) to contend for the channel
in order to transmit medium access control (MAC) service data in order to transmit medium access control (MAC) service data
units (MSDUs) with certain priorities. [IEEE.802.11-2016] units (MSDUs) with certain priorities. [IEEE.802.11-2016]
skipping to change at page 8, line 28 skipping to change at page 8, line 28
typically extended at Layer 3 (by accepting the DSCP), but may typically extended at Layer 3 (by accepting the DSCP), but may
also be extended at lower layers, such as at Layer 2 by accepting also be extended at lower layers, such as at Layer 2 by accepting
User Priority markings. For example, if an access point is User Priority markings. For example, if an access point is
configured to trust DSCP markings and it receives a packet marked configured to trust DSCP markings and it receives a packet marked
EF, then it would treat the packet with the Expedite Forwarding EF, then it would treat the packet with the Expedite Forwarding
PHB and propagate the EF marking value (DSCP 46) as it transmits PHB and propagate the EF marking value (DSCP 46) as it transmits
the packet. Alternatively, if a network device is configured to the packet. Alternatively, if a network device is configured to
operate in an untrusted manner, then it would remark packets as operate in an untrusted manner, then it would remark packets as
these entered the device, typically to DF (or to a different these entered the device, typically to DF (or to a different
marking value at the network administrator's preference). Note: marking value at the network administrator's preference). Note:
The terms "trusted" and "untrusted" are used extensively in RFC The terms "trusted" and "untrusted" are used extensively in
4594. [RFC4594].
UP: User Priority. A value associated with a medium access UP: User Priority. A value associated with a medium access
control (MAC) service data unit (MSDU) that indicates how the MSDU control (MAC) service data unit (MSDU) that indicates how the MSDU
is to be handled. The UP is assigned to an MSDU in the layers is to be handled. The UP is assigned to an MSDU in the layers
above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a above the MAC [IEEE.802.11-2016] Section 3.1. The UP defines a
level of priority for the associated frame, on a scale of 0 to 7. level of priority for the associated frame, on a scale of 0 to 7.
Wi-Fi: An interoperability certification defined by the Wi-Fi Wi-Fi: An interoperability certification defined by the Wi-Fi
Alliance. However, this term is commonly used, including in the Alliance. However, this term is commonly used, including in the
present document, to be the equivalent of IEEE 802.11. present document, to be the equivalent of IEEE 802.11.
skipping to change at page 14, line 26 skipping to change at page 14, line 26
protocols, again, per [RFC4594] Section 3.2. protocols, again, per [RFC4594] Section 3.2.
By default (as described in Section 2.2), packets marked DSCP CS7 By default (as described in Section 2.2), packets marked DSCP CS7
will be mapped to UP 7 and serviced within the Voice Access Category will be mapped to UP 7 and serviced within the Voice Access Category
(AC_VO). This represents the RECOMMENDED mapping for CS7, that is, (AC_VO). This represents the RECOMMENDED mapping for CS7, that is,
packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7. packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.
However, by default (as described in Section 2.2), packets marked However, by default (as described in Section 2.2), packets marked
DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access DSCP CS6 will be mapped to UP 6 and serviced within the Voice Access
Category (AC_VO); such mapping and servicing is a contradiction to Category (AC_VO); such mapping and servicing is a contradiction to
the intent expressed in [RFC 4594] section 3.2. As such, it is the intent expressed in [RFC4594] Section 3.2. As such, it is
RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per
[IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting
it to the Voice Access Category (AC_VO), albeit with a marking it to the Voice Access Category (AC_VO), albeit with a marking
distinguishing it from (data-plane) voice traffic. distinguishing it from (data-plane) voice traffic.
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.
skipping to change at page 33, line 23 skipping to change at page 33, line 23
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, 2016, Layer (PHY) specifications", IEEE Standard 802.11, 2016,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.11-2016.html>. standard/802.11-2016.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[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,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
<http://www.rfc-editor.org/info/rfc2597>. <https://www.rfc-editor.org/info/rfc2597>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>. <https://www.rfc-editor.org/info/rfc3246>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <https://www.rfc-editor.org/info/rfc3662>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic", Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010, RFC 5865, DOI 10.17487/RFC5865, May 2010,
<http://www.rfc-editor.org/info/rfc5865>. <https://www.rfc-editor.org/info/rfc5865>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/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-02 (work in progress), June 2017. draft-ietf-tsvwg-le-phb-02 (work in progress), June 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>.
[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, [RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,
"Mapping Quality of Service (QoS) Procedures of Proxy "Mapping Quality of Service (QoS) Procedures of Proxy
Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, Mobile IPv6 (PMIPv6) and WLAN", RFC 7561,
DOI 10.17487/RFC7561, June 2015, DOI 10.17487/RFC7561, June 2015,
<http://www.rfc-editor.org/info/rfc7561>. <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>.
Appendix A. Change Log Appendix A. Change Log
Initial Version: July 2015 Initial Version: July 2015
Authors' Addresses Authors' Addresses
Tim Szigeti Tim Szigeti
Cisco Systems Cisco Systems
Vancouver, British Columbia V6K 3L4 Vancouver, British Columbia V6K 3L4
 End of changes. 18 change blocks. 
34 lines changed or deleted 33 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/