Mapping Diffserv to IEEE 802.11
draft-ietf-tsvwg-ieee-802-11-11

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: "David L. Black" <david.black@emc.com>, The IESG <iesg@ietf.org>, tsvwg@ietf.org, david.black@emc.com, draft-ietf-tsvwg-ieee-802-11@ietf.org, spencerdawkins.ietf@gmail.com, rfc-editor@rfc-editor.org, tsvwg-chairs@ietf.org
Subject: Protocol Action: 'Diffserv to IEEE 802.11 Mapping' to Proposed Standard (draft-ietf-tsvwg-ieee-802-11-11.txt)

The IESG has approved the following document:
- 'Diffserv to IEEE 802.11 Mapping'
  (draft-ietf-tsvwg-ieee-802-11-11.txt) as Proposed Standard

This document is the product of the Transport Area Working Group.

The IESG contact persons are Mirja K├╝hlewind and Spencer Dawkins.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/


Technical Summary

   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 document specifies a set Differentiated
   Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
   to reconcile the marking recommendations offered by the IETF and the
   IEEE so as to maintain consistent QoS treatment between wired and
   IEEE 802.11 wireless networks.

Working Group Summary

   This draft is supported by the portion of the tsvwg working group that
   is familiar with and interested in Diffserv.  

   The mappings in this draft have been stable for about the past year and
   are being implemented.  Recent activity on this draft stemming from WG
   Last Call has focused on other aspects, primarily security-related (e.g.,
   network cannot "trust" DSCP markings set by the originator of traffic)
   and related concerns around dealing with possible use and misuse of
   the high priority CS6 and CS7 DSCP markings for network control traffic
   such as routing protocols.  All of these concerns have been resolved,
   and the shepherd is confident that the draft reflects WG rough consensus.

   The TSVWG WG is working on revising and replacing the RFC 3662
   specification of Lower Effort (less than best effort) Diffserv traffic;
   that revision will change the recommended DSCP.  The WG has decided
   that this DSCP to UP mapping draft should reflect current "running code"
   that uses the CS1 codepoint for Lower Effort traffic and not wait for
   completion of work on replacement of RFC 3662 and selection of a new
   recommended default DSCP for Lower Effort traffic.

Document Quality

   The draft has received significant review and critique from a number 
   of Diffserv experts, including the draft shepherd.  the draft has been 
   significantly modified as a result, including revising the mappings 
   to resolve concerns about potential priority inversion between wired 
   and wireless networks.  The WiFi material has also been reviewed 
   by a WiFi expert.

Personnel

   The Document Shepherd is David Black.
   The responsible Area Director is Spencer Dawkins.

RFC Editor Note

OLD

   o  Setting a traffic conditioning policy reflective of business
      objectives and policy, such that traffic from authorized users
      and/or applications and/or endpoints will be accepted by the
      network; otherwise packet markings will be "bleached" (i.e.
      remarked to DSCP DF and/or UP 0).  Additionally, Section 5.3 made
      it clear that it is generally NOT RECOMMENDED to pass through DSCP
      markings from unauthorized and/or unauthenticated devices, as
      these are typically considered untrusted sources.  This is
      especially relevant for IoT deployments, where tens-of-billions of
      devices are being connected to IP networks with little or no
      security capabilities (making such vulernable to be utilized as
      agents for DDoS attacks, the effects of which can be amplified
      with preferential QoS treatments, should the packet markings of
      such devices be trusted).

NEW

   o  Setting a traffic conditioning policy reflective of business
      objectives and policy, such that traffic from authorized users
      and/or applications and/or endpoints will be accepted by the
      network; otherwise packet markings will be "bleached" (i.e.
      remarked to DSCP DF and/or UP 0).  Additionally, Section 5.3 made
      it clear that it is generally NOT RECOMMENDED to pass through DSCP
      markings from unauthorized and/or unauthenticated devices, as
      these are typically considered untrusted sources.  This is
      especially relevant for IoT deployments, where tens-of-billions of
      devices are being connected to IP networks with little or no
      security capabilities, leaving them vulnerable to be utilized as
      agents for DDoS attacks. These attacks can be amplified
      with preferential QoS treatments, should the packet markings of
      such devices be trusted.