1. External QoS Mapping Date: 2006-02-17 Authors: March 2006 Month Year
doc.: IEEE yy/xxxxr0
March 2006
External QoS Mapping
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Abstract
This document describes a complete proposal for requirement R9U3.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

3. Month Year
doc.: IEEE yy/xxxxr0
March 2006
TGu Requirement R9U3
Provide mapping from external QoS information, e.g. DSCP, to IEEE specific parameters
This proposal describes:
Brief review of 802.1/ priority
A flexible information element which provides DSCP to UP mapping (also referred to herein as “DSCP Map”)
Transmission mechanism used by QAP to provide IE to QSTA
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

4. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Background
To date, a mechanism to map L3 traffic QoS priority to L2 priority has not be defined in the standards bodies
As described in the RFCs, the IETF has provided operators flexibility in the assignment of differentiated services code points to per-hop packet forwarding behavior
What is needed is a flexible way to enable uniform L3 to L2 mapping amongst STAs so that over-the-air resources are utilized in a planned manner
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

5. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Assumptions
The values and method by which QSTAs are configured for DSCP is outside the scope of this proposal.
The DSCP to UP map will be the same for all BSSs in an ESS.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

6. 802.1d Priorities and 802.11e EDCA Access Categories
Month Year
doc.: IEEE yy/xxxxr0
March 2006
802.1d Priorities and e EDCA Access Categories
802.1d user_priority
Access Category
Acronym
Traffic Type 1
AC_BK BK
Background 2 -
Spare
0 (Default)
AC_BE BE
Best Effort 3 EE
Excellent Effort 4
AC_VI CL
Controlled Load 5 VI
“Video”, <100ms latency and jitter 6
AC_VO VO
“Voice”, <10ms latency and jitter 7 NC
Network Control
Note: e uses a non-configurable UP to AC mapping
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

7. “Required” Flexibility of DSCP to UP Map
Month Year
doc.: IEEE yy/xxxxr0
March 2006
“Required” Flexibility of DSCP to UP Map
Since the IETF has provided a lot of flexibility for operators to map DSCP to PHB, the DSCP Map needs flexibility too. Examples:
Class selector code points having higher numerical value should have higher priority (RFC 2474)
RFC 2474 permits different administration domains to map CSn to PHB differently
Assured forwarding PHB provides no relative priority between AF4x, AF3x, AF2x and AF1x (RFC 2597)
Different administrative domains may use AF code points differently
DSCP Map should be flexible enough to accommodate EDCA priority “inversion”
E.g., UP=0 has higher OTA priority than UP=2, but CS2 may have higher PHB priority than CS0
EDCA can be configured for mandatory admission control on an AC basis; so some flexibility to map DSCPs to AC requiring admission control or not is desirable.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

8. DSCP Map Information Element
Month Year
doc.: IEEE yy/xxxxr0
March 2006
DSCP Map Information Element
Field
Size
Description
Element ID
Uint8
Value TBD
Length
DSCP Exception Element #1 (optional)
Uint8 * 2
DSCP value, UP
DSCP Exception Element #N (optional)
UP 7 DSCP Range
Low value, High value
UP 6 DSCP Range
UP 5 DSCP Range
UP 4 DSCP Range
UP 3 DSCP Range
UP 2 DSCP Range
UP 1 DSCP Range
UP 0 DSCP Range
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

9. DSCP Map Description (cont.)
Month Year
doc.: IEEE yy/xxxxr0
March 2006
DSCP Map Description (cont.)
DSCP Exception Element:
The first octet is the DSCP exception value, the second octet is the transmit UP to employ. Any packet to be transmitted by a QSTA whose DSCP matches any exception value in the DSCP Map IE shall use the corresponding UP for transmission; that is, it overrides the UP values provided in the UP n DSCP Range portion of the IE.
Each Exception Element shall have a different DSCP value.
The maximum number of Exception Elements permitted is 8.
UP n DSCP Range:
All DSCP values are 6-bit values which are right justified in the octet (i.e., the octet can take on values between 0 and 63 inclusive). When an application on the QSTA employs a DSCP contained within the range (inclusive of the high and low values) for a given UP, then the packet shall be transmitted with that UP.
DSCP ranges shall be non-overlapping.
Range with low value equal to high value is permitted.
If the High value = Low value = 255, then the corresponding UP shall not be used.
For any packet to be transmitted by a QSTA whose DSCP does not match any of the DSCP Ranges or DSCP Exception elements, that packet shall be transmitted at UP=0.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

10. Transmission of the DSCP Map
Month Year
doc.: IEEE yy/xxxxr0
March 2006
Transmission of the DSCP Map
Only non-AP STAs desiring QoS services need to request DSCP Map
DSCP Map must be requested prior to TSPEC bandwidth request
STA should request DSCP Map immediately after association so that all flows will use correct UP (whether or not any ACs are configured for mandatory admission control)
QoS Action frames are used
DSCP Map Request (non-AP QSTA to QAP)
DSCP Map Response (QAP to non-AP QSTA)
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

11. Action Frame Category Name Value See clause Spectrum Management 7.4.1
Month Year
doc.: IEEE yy/xxxxr0
March 2006
Action Frame Category
Name
Value
See clause
Spectrum Management
7.4.1
QoS 1
7.4.2
DLS 2
7.4.3
Block Ack 3
7.4.4
Reserved 4 -
Radio Measurement 5
7.4.5
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

12. QoS Action Frames Action field value Description ADDTS request 1
Month Year
doc.: IEEE yy/xxxxr0
March 2006
QoS Action Frames
Action field value
Description
ADDTS request 1
ADDTS response 2
DELTS 3
Schedule 4
DSCP Map request 5
DSCP Map response
6-255
Reserved
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

13. DSCP Map Request/Response Frame Formats
Month Year
doc.: IEEE yy/xxxxr0
March 2006
DSCP Map Request/Response Frame Formats
Action field value
Description
Category 1
Action 2
Dialog Token
Request
Action field value
Description
Category 1
Action 2
Dialog Token 3
DSCP Map Element
Response
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

14. Month Year
doc.: IEEE yy/xxxxr0
March 2006
G1 Analysis
All proposals (whichever requirements they address) shall describe how they minimize battery consumption for mobile devices.
This proposal has negligible effect on battery consumption.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

15. Month Year
doc.: IEEE yy/xxxxr0
March 2006
G2 Analysis
All proposals (whichever requirements they address) shall describe the security impact of the functions they propose.
This proposal has no security impact as the QSTA must be associated to the QAP before frames containing the DSCP Map are transferred.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

16. Month Year
doc.: IEEE yy/xxxxr0
March 2006
G3 Analysis
All proposals must allow APs to serve legacy STAs in addition to STAs that have been upgraded to 11u. Proposals must describe how this is achieved.
The DSCP Map will not be transmitted to non-TGu capable STA. Legacy STAs will need to be configured for external QoS using some other method.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

17. Month Year
doc.: IEEE yy/xxxxr0
March 2006
Summary
A flexible DSCP to UP Map has been proposed which allows all QSTAs in a BSS to uniformly select the proper UP and AC for transmission.
This map ensures that desired services will be protected via admission control while other services will not be so encumbered
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

18. Feedback? March 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

19. Background March 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

20. Abbreviations AC = 802.11e access category
Month Year
doc.: IEEE yy/xxxxr0
March 2006
Abbreviations
AC = e access category
DSCP = differentiated services code point
PHB = per-hop behavior
UP = e user priority
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

21. 802.1d-Appendix G Traffic Definitions
Month Year
doc.: IEEE yy/xxxxr0
March 2006
802.1d-Appendix G Traffic Definitions
Network Control—characterized by a “must get there” requirement to maintain and support the network infrastructure.
“Voice”—characterized by less than 10 ms delay, and hence maximum jitter (one way transmission through the LAN infrastructure of a single campus).
“Video”—characterized by less than 100 ms delay.
Controlled Load—important business applications subject to some form of “admission control,” from pre-planning of the network requirement at one extreme to bandwidth reservation per flow at the time the flow is started at the other.
Excellent Effort—or “CEO’s best effort,” the best-effort type services that an information services organization would deliver to its most important customers.
Best Effort—LAN traffic as we know it today.
Background—bulk transfers and other activities that are permitted on the network but that should not impact the use of the network by other users and applications.
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company

22. Example DSCP/PHB to UP/AC Mapping
Month Year
doc.: IEEE yy/xxxxr0
March 2006
Example DSCP/PHB to UP/AC Mapping
Application
PHB UP AC
IP routing
CS6 7
AC_VO
Voice EF 6
Video Conferencing
AF41 5
AC_VI
Video Streaming
CS4
Controlled Load
AF21 4
Call Signaling
AF31
Transactional Data
CS2 3
AC_BE
Best Effort
Bulk Data
AF11 2
AC_BK
Scavenger
CS1 1
Dave Stephenson, Cisco Systems, Inc.
John Doe, Some Company