Internet Engineering Task Force (IETF) T. Szigeti
Request for Comments: 8325 J. Henry
Category: Standards Track Cisco Systems
ISSN: 2070-1721 F. Baker
February 2018
Internet Engineering Task Force (IETF) T. Szigeti
Request for Comments: 8325 J. Henry
Category: Standards Track Cisco Systems
ISSN: 2070-1721 F. Baker
February 2018
Mapping Diffserv to IEEE 802.11
将Diffserv映射到IEEE 802.11
Abstract
摘要
As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) 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.
随着互联网流量越来越多地来源于无线端点并以无线端点为目的地，服务质量（QoS）在有线和无线网络之间保持一致至关重要；但是，默认情况下并非总是如此。本文件规定了从区分服务代码点（DSCP）到IEEE 802.11用户优先级（UP）的一组映射，以协调IETF和IEEE提供的标记建议，从而在有线和IEEE 802.11无线网络之间保持一致的QoS处理。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8325.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8325.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.4. Document Organization . . . . . . . . . . . . . . . . . . 5
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.6. Terminology Used in This Document . . . . . . . . . . . . 6
2. Service Comparison and Default Interoperation of Diffserv and
IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11
3. Recommendations for Capabilities of Wireless Device Marking
and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Recommendations for DSCP-to-UP Mapping . . . . . . . . . . . 13
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14
4.1.2. Operations, Administration, and Maintenance (OAM) . 15
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 17
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 17
4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 17
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 18
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 18
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18
4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 19
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 20
4.3. Summary of Recommendations for DSCP-to-UP Mapping . . . . 20
5. Recommendations for Upstream Mapping and Marking . . . . . . 21
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client
Operating System . . . . . . . . . . . . . . . . . . . . 22
5.2. Upstream UP-to-DSCP Mapping at the Wireless AP . . . . . 22
5.3. Upstream DSCP-Passthrough at the Wireless AP . . . . . . 23
5.4. Upstream DSCP Marking at the Wireless AP . . . . . . . . 24
6. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 24
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 25
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Interframe Space (IFS) . . . . . . . . . . . . . . . 26
6.1.3. Contention Window (CW) . . . . . . . . . . . . . . . 26
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 28
6.2.3. Arbitration Interframe Space (AIFS) . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.4. Document Organization . . . . . . . . . . . . . . . . . . 5
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.6. Terminology Used in This Document . . . . . . . . . . . . 6
2. Service Comparison and Default Interoperation of Diffserv and
IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11
3. Recommendations for Capabilities of Wireless Device Marking
and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Recommendations for DSCP-to-UP Mapping . . . . . . . . . . . 13
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14
4.1.2. Operations, Administration, and Maintenance (OAM) . 15
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 17
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 17
4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 17
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 18
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 18
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18
4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 19
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 20
4.3. Summary of Recommendations for DSCP-to-UP Mapping . . . . 20
5. Recommendations for Upstream Mapping and Marking . . . . . . 21
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client
Operating System . . . . . . . . . . . . . . . . . . . . 22
5.2. Upstream UP-to-DSCP Mapping at the Wireless AP . . . . . 22
5.3. Upstream DSCP-Passthrough at the Wireless AP . . . . . . 23
5.4. Upstream DSCP Marking at the Wireless AP . . . . . . . . 24
6. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 24
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 25
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Interframe Space (IFS) . . . . . . . . . . . . . . . 26
6.1.3. Contention Window (CW) . . . . . . . . . . . . . . . 26
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 28
6.2.3. Arbitration Interframe Space (AIFS) . . . . . . . . . 29
6.2.4. Access Category CWs . . . . . . . . . . . . . . . . . 29
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Recommendations for General QoS . . . . . . . . 31
8.2. Security Recommendations for WLAN QoS . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.4. Access Category CWs . . . . . . . . . . . . . . . . . 29
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Recommendations for General QoS . . . . . . . . 31
8.2. Security Recommendations for WLAN QoS . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
The wireless medium defined by IEEE 802.11 [IEEE.802.11-2016] has become the preferred medium for endpoints connecting to business and private networks. However, it presents several design challenges for ensuring end-to-end QoS. Some of these challenges relate to the nature of the IEEE 802.11 Radio Frequency (RF) medium itself, being a half-duplex and shared medium, while other challenges relate to the fact that the IEEE 802.11 standard is not administered by the same standards body as IP networking standards. While the IEEE has developed tools to enable QoS over wireless networks, little guidance exists on how to maintain consistent QoS treatment between wired IP networks and wireless IEEE 802.11 networks. The purpose of this document is to provide such guidance.
IEEE 802.11[IEEE.802.11-2016]定义的无线介质已成为端点连接到商业和专用网络的首选介质。然而，它为确保端到端QoS提出了一些设计挑战。其中一些挑战与IEEE 802.11射频（RF）介质本身的性质有关，它是一种半双工和共享介质，而其他挑战与IEEE 802.11标准与IP网络标准不由同一标准机构管理这一事实有关。虽然IEEE已经开发了一些工具来实现无线网络上的QoS，但对于如何在有线IP网络和无线IEEE 802.11网络之间保持一致的QoS处理，几乎没有指导。本文件旨在提供此类指导。
Several RFCs outline Diffserv QoS recommendations over IP networks, including:
几个RFC概述了IP网络上的Diffserv QoS建议，包括：
RFC 2474 Specifies the Diffserv Codepoint Field. This RFC also details Class Selectors, as well as the Default Forwarding (DF) PHB for best effort traffic. The Default Forwarding PHB is referred to as the Default PHB in RFC 2474.
RFC 2474指定Diffserv代码点字段。此RFC还详细说明了类选择器以及尽力而为流量的默认转发（DF）PHB。默认转发PHB在RFC 2474中称为默认PHB。
RFC 2475 Defines a Diffserv architecture.
RFC 2475定义了一种区分服务体系结构。
RFC 3246 Specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB).
RFC 3246指定每跳加速转发（EF）行为（PHB）。
RFC 2597 Specifies the Assured Forwarding (AF) PHB.
RFC2597指定保证转发（AF）PHB。
RFC 3662 Specifies a Lower-Effort Per-Domain Behavior (PDB).
RFC3662指定了较低的每个域的工作行为（PDB）。
RFC 4594 Presents configuration guidelines for Diffserv service classes.
RFC4594提供了区分服务类的配置指南。
RFC 5127 Presents the aggregation of Diffserv service classes.
RFC5127提供了Diffserv服务类的聚合。
RFC 5865 Specifies a DSCP for capacity-admitted traffic.
RFC 5865为容量允许流量指定DSCP。
Note: [RFC4594] is intended to be viewed as a framework for supporting Diffserv in any network, including wireless networks; thus, it describes different types of traffic expected in IP networks and provides guidance as to what DSCP marking(s) should be associated with each traffic type. As such, this document draws heavily on [RFC4594], as well as [RFC5127], and [RFC8100].
注：[RFC4594]旨在被视为在任何网络（包括无线网络）中支持区分服务的框架；因此，它描述了IP网络中预期的不同类型的通信量，并提供了与每种通信量类型相关联的DSCP标记的指导。因此，本文件大量引用了[RFC4594]，以及[RFC5127]和[RFC8100]。
In turn, the relevant standard for wireless QoS is IEEE 802.11, which is being progressively updated; at the time of writing, the current version of which is [IEEE.802.11-2016].
反过来，无线QoS的相关标准是IEEE 802.11，该标准正在逐步更新；在撰写本文时，其当前版本为[IEEE.802.11-2016]。
There is also a recommendation from the Global System for Mobile Communications Association (GSMA) on DSCP-to-UP Mapping for IP Packet eXchange (IPX), specifically their Guidelines for IPX Provider networks [GSMA-IPX_Guidelines]. These GSMA Guidelines were developed without reference to existing IETF specifications for various services, referenced in Section 1.1. In turn, [RFC7561] was written based on these GSMA Guidelines, as explicitly called out in [RFC7561], Section 4.2. Thus, [RFC7561] conflicts with the overall Diffserv traffic-conditioning service plan, both in the services specified and the codepoints specified for them. As such, these two plans cannot be normalized. Rather, as discussed in [RFC2474], Section 2, the two domains (IEEE 802.11 and GSMA) are different Differentiated Services Domains separated by a Differentiated Services Boundary. At that boundary, codepoints from one domain are translated to codepoints for the other, and maybe to Default (zero) if there is no corresponding service to translate to.
全球移动通信系统协会（GSMA）还建议DSCP向上映射IP分组交换（IPX），特别是其IPX提供商网络指南[GSMA-IPX_指南]。这些GSMA指南的制定未参考第1.1节中引用的各种服务的现有IETF规范。反过来，[RFC7561]是根据这些GSMA指南编写的，如[RFC7561]第4.2节中明确指出的。因此，[RFC7561]在指定的服务和为其指定的代码点中与整个Diffserv流量调节服务计划冲突。因此，这两个计划无法正常化。相反，如[RFC2474]第2节所述，这两个域（IEEE 802.11和GSMA）是由区分服务边界分隔的不同区分服务域。在该边界处，来自一个域的代码点被转换为另一个域的代码点，如果没有相应的服务可转换，则可能转换为默认值（零）。
This document is applicable to the use of Differentiated Services that interconnect with IEEE 802.11 wireless LANs (referred to as Wi-Fi, throughout this document, for simplicity). 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 AP is the bridge between wired and wireless media.
本文档适用于与IEEE 802.11无线局域网互连的差异化服务的使用（为简单起见，本文档通篇称为Wi-Fi）。无论无线接入点（AP）是以自主方式部署、由（集中式或分布式）WLAN控制器管理，还是某些混合部署选项，这些指南都适用。这是因为，在所有这些情况下，无线AP是有线和无线媒体之间的桥梁。
This document applies to IP networks using Wi-Fi infrastructure at the link layer. Such networks typically include wired LANs with wireless APs at their edges; however, such networks can also include Wi-Fi backhaul, wireless mesh solutions, or any other type of AP-to-AP wireless network that extends the wired-network infrastructure.
本文档适用于在链路层使用Wi-Fi基础设施的IP网络。此类网络通常包括在其边缘具有无线ap的有线lan；然而，此类网络还可以包括Wi-Fi回程、无线网状解决方案或扩展有线网络基础设施的任何其他类型的AP-to-AP无线网络。
This document is organized as follows:
本文件的组织结构如下：
Section 1 introduces the wired-to-wireless QoS challenge, references related work, outlines the organization of the document, and specifies both the requirements language and the terminology used in this document.
第1节介绍了有线到无线QoS挑战，参考了相关工作，概述了文档的组织结构，并指定了本文档中使用的需求语言和术语。
Section 2 begins the discussion with a comparison of IETF Diffserv QoS and Wi-Fi QoS standards and highlights discrepancies between these that require reconciliation.
第2节首先对IETF Diffserv QoS和Wi-Fi QoS标准进行了比较，并强调了这些标准之间需要协调的差异。
Section 3 presents the marking and mapping capabilities that wireless APs and wireless endpoint devices are recommended to support.
第3节介绍了建议无线AP和无线端点设备支持的标记和映射功能。
Section 4 presents DSCP-to-UP mapping recommendations for each of the [RFC4594] service classes, which are primarily applicable in the downstream (wired-to-wireless) direction.
第4节为[RFC4594]服务类别中的每一个提供了从DSCP到UP的映射建议，这些服务类别主要适用于下游（有线到无线）方向。
Section 5, in turn, considers upstream (wireless-to-wired) QoS options, their respective merits and recommendations.
第5节依次考虑了上行（无线到有线）QoS选项及其各自的优点和建议。
Section 6 (in the form of an Appendix) presents a brief overview of how QoS is achieved over IEEE 802.11 wireless networks, given the shared, half-duplex nature of the wireless medium.
第6节（以附录的形式）简要概述了无线介质的共享、半双工性质，如何在IEEE 802.11无线网络上实现QoS。
Section 7 contains IANA considerations.
第7节包含IANA注意事项。
Section 8 presents security considerations relative to DSCP-to-UP mapping, UP-to-DSCP mapping, and re-marking.
第8节介绍了与DSCP到上映射、到DSCP映射和重新标记相关的安全注意事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Key terminology used in this document includes:
本文件中使用的关键术语包括：
AC: Access Category. A label for the common set of enhanced distributed channel access (EDCA) parameters that are used by a QoS station (STA) to contend for the channel in order to transmit medium access control (MAC) service data units (MSDUs) with certain priorities; see [IEEE.802.11-2016], Section 3.2.
AC：访问类别。用于增强分布式信道接入（EDCA）参数的公共集合的标签，QoS站（STA）使用该集合来争夺信道，以便传输具有特定优先级的媒体接入控制（MAC）服务数据单元（MSDU）；参见[IEEE.802.11-2016]第3.2节。
AIFS: Arbitration Interframe Space. Interframe space used by QoS stations before transmission of data and other frame types defined by [IEEE.802.11-2016], Section 10.3.2.3.6.
AIFS：仲裁帧间空间。传输[IEEE.802.11-2016]第10.3.2.3.6节定义的数据和其他帧类型之前，QoS站使用的帧间空间。
AP: Access Point. An entity that contains one station (STA) and provides access to the distribution services, via the wireless medium (WM) for associated STAs. An AP comprises a STA and a distribution system access function (DSAF); see [IEEE.802.11-2016], Section 3.1.
AP：接入点。包含一个站点（STA）并通过相关STA的无线介质（WM）提供对分发服务的访问的实体。AP包括STA和分配系统接入功能（DSAF）；参见[IEEE.802.11-2016]第3.1节。
BSS: Basic Service Set. Informally, a wireless cell; formally, a set of stations that have successfully synchronized using the JOIN service primitives and one STA that has used the START primitive. Alternatively, a set of STAs that have used the START primitive specifying matching mesh profiles where the match of the mesh profiles has been verified via the scanning procedure. Membership in a BSS does not imply that wireless communication with all other members of the BSS is possible. See the definition in [IEEE.802.11-2016], Section 3.1.
基本服务集。非正式地说，无线小区；正式地说，一组使用连接服务原语成功同步的站点和一个使用启动原语的STA。或者，一组STA已使用开始原语指定匹配的网格轮廓，其中网格轮廓的匹配已通过扫描过程验证。BSS的成员资格并不意味着可以与BSS的所有其他成员进行无线通信。参见[IEEE.802.11-2016]第3.1节中的定义。
Contention Window: See CW.
争用窗口：请参阅CW。
CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. A MAC method in which carrier sensing is used, but nodes attempt to avoid collisions by transmitting only when the channel is sensed to be "idle". When these do transmit, nodes transmit their packet data in its entirety.
CSMA/CA：具有冲突避免的载波侦听多址接入。一种MAC方法，其中使用载波感知，但节点仅当信道被感知为“空闲”时才尝试通过发送来避免冲突。当这些节点发送数据包时，它们会发送整个数据包数据。
CSMA/CD: Carrier Sense Multiple Access with Collision Detection. A MAC method (used most notably in early Ethernet technology) for local area networking. It uses a carrier-sensing scheme in which a transmitting station detects collisions by sensing transmissions from other stations while transmitting a frame. When this collision condition is detected, the station stops transmitting that frame, transmits a jam signal, and then waits for a random time interval before trying to resend the frame.
CSMA/CD：带冲突检测的载波侦听多址接入。一种用于局域网的MAC方法（在早期的以太网技术中最为常用）。它使用载波感测方案，其中发射站在发射帧时通过感测来自其他站的传输来检测冲突。当检测到该冲突情况时，站点停止发送该帧，发送干扰信号，然后在尝试重新发送该帧之前等待随机时间间隔。
CW: Contention Window. Limits a CWMin and CWMax, from which a random backoff is computed.
竞争窗口。限制计算随机退避的CWMin和CWMax。
CWMax: Contention Window Maximum. The maximum value (in units of Slot Time) that a CW can take.
CWMax：争用窗口最大值。CW可以采用的最大值（以时隙时间为单位）。
CWMin: Contention Window Minimum. The minimum value that a CW can take.
CWMin：争用窗口最小值。CW可以采用的最小值。
DCF: Distributed Coordinated Function. A class of coordination function where the same coordination function logic is active in every station (STA) in the BSS whenever the network is in operation.
分布式协调功能。一类协调功能，其中每当网络运行时，BSS中的每个站点（STA）都会激活相同的协调功能逻辑。
DIFS: Distributed (Coordination Function) Interframe Space. A unit of time during which the medium has to be detected as idle before a station should attempt to send frames, as per [IEEE.802.11-2016], Section 10.3.2.3.5.
DIFS：分布式（协调功能）帧间空间。根据[IEEE.802.11-2016]第10.3.2.3.5节，在站点尝试发送帧之前，媒体必须被检测为空闲的时间单位。
DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. The DSCP is carried in the first 6 bits of the IPv4 Type of Service (TOS) field and the IPv6 Traffic Class field (the remaining 2 bits are used for IP Explicit Congestion Notification (ECN) [RFC3168]).
DSCP：区分服务代码点[RFC2474]和[RFC2475]。DSCP携带在IPv4服务类型（TOS）字段和IPv6流量类别字段的前6位（其余2位用于IP显式拥塞通知（ECN）[RFC3168]）。
EIFS: Extended Interframe Space. A unit of time that a station has to defer before transmitting a frame if the previous frame contained an error, as per [IEEE.802.11-2016], Section 10.3.2.3.7.
EIFS：扩展帧间空间。根据[IEEE.802.11-2016]第10.3.2.3.7节，如果前一帧包含错误，则站点在传输前必须延迟的时间单位。
HCF: Hybrid Coordination Function. A coordination function that combines and enhances aspects of the contention-based and contention-free access methods to provide QoS stations (STAs) with prioritized and parameterized QoS access to the WM, while continuing to support non-QoS STAs for best-effort transfer; see [IEEE.802.11-2016], Section 3.1.
混合协调功能。协调功能，其组合并增强基于竞争和无竞争的接入方法的方面，以向WM提供具有优先级和参数化QoS接入的QoS站（sta），同时继续支持非QoS sta以进行尽力而为的传输；参见[IEEE.802.11-2016]第3.1节。
IFS: Interframe Space. Period of silence between transmissions over IEEE 802.11 networks. [IEEE.802.11-2016] describes several types of Interframe Spaces.
IFS：帧间空间。IEEE 802.11网络上传输之间的静默期。[IEEE.802.11-2016]描述了几种类型的帧间空间。
Random Backoff Timer: A pseudorandom integer period of time (in units of Slot Time) over the interval (0,CW), where CWmin is less than or equal to CW, which in turn is less than or equal to CWMax. Stations desiring to initiate transfer of data frames and/or management frames using the DCF shall invoke the carrier sense mechanism to determine the busy-or-idle state of the medium. If the medium is busy, the STA shall defer until the medium is determined to be idle without interruption for a period of time
随机退避计时器：间隔（0，CW）上的伪随机整数时间段（以时隙时间为单位），其中CWmin小于或等于CW，而CWmin又小于或等于CWMax。希望使用DCF发起数据帧和/或管理帧传输的站点应调用载波检测机制，以确定媒体的忙或空闲状态。如果介质忙，STA应延迟，直到确定介质空闲一段时间而不中断
equal to DIFS when the last frame detected on the medium was received correctly or after the medium is determined to be idle without interruption for a period of time equal to EIFS when the last frame detected on the medium was not received correctly. After this DIFS or EIFS medium idle time, the STA shall then generate a random backoff period for an additional deferral time before transmitting. See [IEEE.802.11-2016], Section 10.3.3.
当在介质上检测到的最后一帧被正确接收时或在介质被确定为空闲且没有中断一段时间后等于DIFS，当在介质上检测到的最后一帧未被正确接收时等于EIFS。在该DIFS或EIFS介质空闲时间之后，STA随后应在发送之前为额外的延迟时间生成随机退避周期。参见[IEEE.802.11-2016]第10.3.3节。
RF: Radio Frequency.
射频：无线电频率。
SIFS: Short Interframe Space. An IFS used before transmission of specific frames as defined in [IEEE.802.11-2016], Section 10.3.2.3.3.
SIFS：短帧间空间。在传输[IEEE.802.11-2016]第10.3.2.3.3节中定义的特定帧之前使用的IFS。
Slot Time: A unit of time used to count time intervals in IEEE 802.11 networks; it is defined in [IEEE.802.11-2016], Section 10.3.2.13.
时隙：IEEE 802.11网络中用于计算时间间隔的时间单位；其定义见[IEEE.802.11-2016]第10.3.2.13节。
Trust: From a QoS-perspective, "trust" refers to the accepting of the QoS markings of a packet by a network device. Trust is typically extended at Layer 3 (by accepting the DSCP), but may also be extended at lower layers, such as at Layer 2 by accepting UP markings. For example, if an AP is configured to trust DSCP markings and it receives a packet marked EF, then it would treat the packet with the Expedite Forwarding PHB and propagate the EF marking value (DSCP 46) as it transmits the packet. Alternatively, if a network device is configured to operate in an untrusted manner, then it would re-mark packets as these entered the device, typically to DF (or to a different marking value at the network administrator's preference). Note: The terms "trusted" and "untrusted" are used extensively in [RFC4594].
信任：从QoS的角度来看，“信任”是指网络设备接受数据包的QoS标记。信任通常在第3层扩展（通过接受DSCP），但也可以在较低层扩展，例如在第2层通过接受向上标记。例如，如果AP被配置为信任DSCP标记，并且它接收到标记为EF的分组，那么它将使用加速转发PHB处理该分组，并在发送分组时传播EF标记值（DSCP 46）。或者，如果网络设备被配置为以不受信任的方式运行，则当数据包进入设备时，它将重新标记数据包，通常标记为DF（或网络管理员首选的不同标记值）。注：术语“受信任”和“不受信任”在[RFC4594]中广泛使用。
UP: User Priority. A value associated with an MSDU that indicates how the MSDU is to be handled. The UP is assigned to an MSDU in the layers above the MAC; see [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.
UP：用户优先级。与MSDU关联的值，指示如何处理MSDU。UP被分配给MAC上面的层中的MSDU；参见[IEEE.802.11-2016]第3.1节。UP以0到7的比例定义关联帧的优先级。
Wi-Fi: An interoperability certification defined by the Wi-Fi Alliance. However, this term is commonly used, including in the present document, to be the equivalent of IEEE 802.11.
Wi-Fi：由Wi-Fi联盟定义的互操作性认证。然而，包括在本文件中，该术语通常被用于等效于IEEE 802.11。
Wireless: In the context of this document, "wireless" refers to the media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G LTE or any other radio telecommunications specification.
无线：在本文件的上下文中，“无线”是指IEEE 802.11[IEEE.802.11-2016]中定义的媒体，而不是3G/4G LTE或任何其他无线电信规范。
2. Service Comparison and Default Interoperation of Diffserv and IEEE 802.11
2. Diffserv与IEEE 802.11的服务比较和默认互操作
(Section 6 provides a brief overview of IEEE 802.11 QoS.)
（第6节简要概述了IEEE 802.11 QoS。）
The following comparisons between IEEE 802.11 and Diffserv services should be noted:
应注意IEEE 802.11和Diffserv服务之间的以下比较：
[IEEE.802.11-2016] does not support an EF PHB service [RFC3246], as it is not possible to assure that a given access category will be serviced with strict priority over another (due to the random element within the contention process)
[IEEE.802.11-2016]不支持EF PHB服务[RFC3246]，因为无法确保给定的访问类别将以严格的优先级提供服务（由于争用过程中的随机元素）
[IEEE.802.11-2016] does not support an AF PHB service [RFC2597], again because it is not possible to assure that a given access category will be serviced with a minimum amount of assured bandwidth (due to the non-deterministic nature of the contention process)
[IEEE.802.11-2016]不支持AF PHB服务[RFC2597]，这也是因为无法确保给定的接入类别将以最小的保证带宽提供服务（由于争用过程的不确定性）
[IEEE.802.11-2016] loosely supports a Default PHB ([RFC2474]) via the Best Effort Access Category (AC_BE)
[IEEE.802.11-2016]通过尽力而为访问类别（AC_BE）松散地支持默认PHB（[RFC2474]）
[IEEE.802.11-2016] loosely supports a Lower Effort PDB service ([RFC3662]) via the Background Access Category (AC_BK)
[IEEE.802.11-2016]通过后台访问类别（AC_BK）松散地支持较低工作量的PDB服务（[RFC3662]）
As such, these high-level considerations should be kept in mind when mapping from Diffserv to [IEEE.802.11-2016] (and vice versa); however, APs may or may not always be positioned at Diffserv domain boundaries, as will be discussed next.
因此，当从Diffserv映射到[IEEE.802.11-2016]（反之亦然）时，应牢记这些高层考虑因素；然而，ap可能或可能不总是位于区分服务域边界，这将在下面讨论。
It is important to recognize that the wired-to-wireless edge may or may not function as an edge of a Diffserv domain or a domain boundary.
重要的是要认识到，有线到无线边缘可能作为区分服务域的边缘或域边界起作用，也可能不起作用。
In most commonly deployed WLAN models, the wireless AP represents not only the edge of the Diffserv domain, but also the edge of the network infrastructure itself. As such, only client endpoint devices (and no network infrastructure devices) are downstream from the access points in these deployment models. Note: security considerations and recommendations for hardening such Wi-Fi-at-the-edge deployment models are detailed in Section 8; these recommendations include mapping network control protocols (which are not used downstream from the AP in this deployment model) to UP 0.
在最常见的部署WLAN模型中，无线AP不仅代表区分服务域的边缘，还代表网络基础设施本身的边缘。因此，在这些部署模型中，只有客户端端点设备（没有网络基础设施设备）位于访问点的下游。注：第8节详细介绍了在边缘部署模式中强化此类Wi-Fi的安全注意事项和建议；这些建议包括将网络控制协议（在此部署模型中AP下游不使用）映射到0。
Alternatively, in other deployment models, such as Wi-Fi backhaul, wireless mesh infrastructures, wireless AP-to-AP deployments, or in cases where a Wi-Fi link connects to a device providing service via another technology (e.g., Wi-Fi to Bluetooth or Zigbee router), the wireless AP extends the network infrastructure and thus, typically, the Diffserv domain. In such deployments, both client devices and infrastructure devices may be expected downstream from the APs, and, as such, network control protocols are RECOMMENDED to be mapped to UP 7 in this deployment model, as is discussed in Section 4.1.1.
或者，在其他部署模型中，例如Wi-Fi回程、无线网状基础设施、无线AP到AP部署，或者在Wi-Fi链路通过另一种技术（例如，Wi-Fi到蓝牙或Zigbee路由器）连接到提供服务的设备的情况下，无线AP扩展了网络基础设施，因此通常，区分服务域。在此类部署中，客户端设备和基础设施设备都可能位于AP的下游，因此，建议在此部署模型中将网络控制协议映射到UP 7，如第4.1.1节所述。
Thus, as can be seen from these two examples, the QoS treatment of packets at the AP will depend on the position of the AP in the network infrastructure and on the WLAN deployment model.
因此，从这两个示例可以看出，AP处的分组的QoS处理将取决于AP在网络基础设施中的位置和WLAN部署模型。
However, regardless of whether or not the AP is at the Diffserv boundary, marking-specific incompatibilities exist from Diffserv to 802.11 (and vice versa) that must be reconciled, as will be discussed next.
但是，无论AP是否位于Diffserv边界，Diffserv与802.11之间（反之亦然）都存在必须协调的特定不兼容，这将在下文中讨论。
[IEEE.802.11-2016] displays a reference implementation queuing model in Figure 10-24, which depicts four transmit queues, one per access category.
[IEEE.802.11-2016]在图10-24中显示了一个参考实施排队模型，该模型描述了四个传输队列，每个访问类别一个。
However, in practical implementations, it is common for WLAN network equipment vendors to implement dedicated transmit queues on a per-UP (versus a per-AC) basis, which are then dequeued into their associated AC in a preferred (or even in a strict priority manner). For example, it is common for vendors to dequeue UP 5 ahead of UP 4 to the hardware performing the EDCA function (EDCAF) for the Video Access Category (AC_VI).
然而，在实际实现中，WLAN网络设备供应商通常在每次（相对于每次AC）的基础上实现专用传输队列，然后以首选方式（甚至以严格的优先级方式）将这些队列排到相关AC中。例如，对于视频访问类别（AC_VI），供应商通常会在最多4个硬件执行EDCA功能（EDCAF）之前排5个队列。
Some of the recommendations made in Section 4 make reference to this common implementation model of queuing per UP.
第4节中提出的一些建议参考了这种按次排队的常见实现模型。
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), a common practice in the networking industry is to map these by what we will refer to as "default DSCP-to-UP mapping" (for lack of a better term), wherein the three Most Significant Bits (MSBs) of the DSCP are used as the corresponding L2 markings.
虽然在将（6位）第3层DSCP值映射到（3位）第2层标记（如IEEE 802.1D、802.1p或802.11e）方面没有提供明确的指导，但网络行业的一种常见做法是通过我们称之为“默认DSCP向上映射”（缺少更好的术语）来映射这些值，其中三个最高有效位（MSB）DSCP的第二个标记用作相应的L2标记。
Note: There are mappings provided in [IEEE.802.11-2016], Annex V Tables V-1 and V2, but it bears mentioning that these mappings are provided as examples (as opposed to explicit recommendations). Furthermore, some of these mappings do not align with the intent and recommendations expressed in [RFC4594], as will be discussed in this and the following section (Section 2.4).
注：[IEEE.802.11-2016]，附录V表V-1和V2中提供了映射，但值得一提的是，这些映射是作为示例提供的（与明确的建议相反）。此外，其中一些映射不符合[RFC4594]中表达的意图和建议，本节和下一节（第2.4节）将对此进行讨论。
However, when this default DSCP-to-UP mapping method is applied to packets marked per recommendations in [RFC4594] and destined to 802.11 WLAN clients, it will yield a number of inconsistent QoS mappings, specifically:
但是，当此默认DSCP向上映射方法应用于[RFC4594]中按建议标记并发送至802.11 WLAN客户端的数据包时，它将产生大量不一致的QoS映射，具体而言：
o Voice (EF-101110) will be mapped to UP 5 (101), and treated in the Video Access Category (AC_VI) rather than the Voice Access Category (AC_VO), for which it is intended
o 语音（EF-101110）将映射到最多5（101），并在视频访问类别（AC_VI）中处理，而不是其预期的语音访问类别（AC_VO）
o Multimedia Streaming (AF3-011xx0) will be mapped to UP 3 (011) and treated in the Best Effort Access Category (AC_BE) rather than the Video Access Category (AC_VI), for which it is intended
o 多媒体流（AF3-011xx0）将映射到UP 3（011），并在尽力而为的访问类别（AC_be）中处理，而不是其预期的视频访问类别（AC_VI）
o Broadcast Video (CS3-011000) will be mapped to UP 3 (011) and treated in the Best Effort Access Category (AC_BE) rather than the Video Access Category (AC_VI), for which it is intended
o 广播视频（CS3-011000）将映射到UP 3（011），并在尽力而为的访问类别（AC_be）中处理，而不是其预期的视频访问类别（AC_VI）
o OAM traffic (CS2-010000) will be mapped to UP 2 (010) and treated in the Background Access Category (AC_BK), which is not the intent expressed in [RFC4594] for this service class
o OAM流量（CS2-010000）将映射到UP 2（010）并在后台访问类别（AC_BK）中处理，这不是[RFC4594]中对此服务类别所表达的意图
It should also be noted that while [IEEE.802.11-2016] 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), [IEEE.802.11-2016] does not:
还应注意，虽然[IEEE.802.11-2016]通过AC命名约定定义了每个接入类别的预期用途（例如，UP 6和UP 7属于语音接入类别AC_VO），但[IEEE.802.11-2016]并未：
o define how upper-layer markings (such as DSCP) should map to UPs (and, hence, to ACs)
o 定义上层标记（如DSCP）应如何映射到UPs（从而映射到ACs）
o define how UPs should translate to other mediums' Layer 2 QoS markings
o 定义UPs应如何转换为其他介质的第2层QoS标记
o strictly restrict each access category to applications reflected in the AC name
o 严格将每个访问类别限制为AC名称中反映的应用程序
In the opposite direction of flow (the upstream direction, that is, from wireless-to-wired), many APs use what we will refer to as "default UP-to-DSCP mapping" (for lack of a better term), wherein DSCP values are derived from UP values by multiplying the UP values
在相反的流动方向（上游方向，即从无线到有线），许多AP使用我们将称之为“默认到DSCP映射”（缺少更好的术语），其中DSCP值是通过将向上值相乘从向上值导出的
by 8 (i.e., shifting the three UP bits to the left and adding three additional zeros to generate a DSCP value). This derived DSCP value is then used for QoS treatment between the wireless AP and the nearest classification and marking policy enforcement point (which may be the centralized wireless LAN controller, relatively deep within the network). Alternatively, in the case where there is no other classification and marking policy enforcement point, then this derived DSCP value will be used on the remainder of the Internet path.
乘以8（即，将三个向上位向左移位，并添加三个额外的零以生成DSCP值）。该导出的DSCP值随后用于无线AP和最近的分类和标记策略实施点（可能是网络中相对较深的集中式无线LAN控制器）之间的QoS处理。或者，在没有其他分类和标记策略实施点的情况下，将在Internet路径的其余部分上使用此派生的DSCP值。
It goes without saying that when six bits of marking granularity are derived from three, then information is lost in translation. Servicing differentiation cannot be made for 12 classes of traffic (as recommended in [RFC4594]), but for only eight (with one of these classes being reserved for future use (i.e., UP 7, which maps to DSCP CS7).
不言而喻，当标记粒度的六位由三位派生而来时，信息在翻译过程中就会丢失。不能对12类流量（如[RFC4594]中建议的）进行服务区分，但只能对8类流量进行服务区分（其中一类流量保留供将来使用（即UP 7，映射到DSCP CS7）。
Such default upstream mapping can also yield several inconsistencies with [RFC4594], including:
这种默认的上游映射也会产生与[RFC4594]不一致的情况，包括：
o Mapping UP 6 (which would include Voice or Telephony traffic, see [RFC4594]) to CS6, which [RFC4594] recommends for Network Control
o 将CS6（包括语音或电话流量，请参见[RFC4594]）映射到[RFC4594]建议用于网络控制的CS6
o Mapping UP 4 (which would include Multimedia Conferencing and/or Real-Time Interactive traffic, see [RFC4594]) to CS4, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.3 and 4.4
o 按照[RFC4594]第4.3节和第4.4节的建议，将4（包括多媒体会议和/或实时交互通信，请参见[RFC4594]）映射到CS4，从而失去区分这两种不同服务类别的能力
o Mapping UP 3 (which would include Multimedia Streaming and/or Broadcast Video traffic, see [RFC4594]) to CS3, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.5 and 4.6
o 将3（包括多媒体流和/或广播视频流量，请参见[RFC4594]）映射到CS3，从而失去区分这两种不同服务类别的能力，如[RFC4594]第4.5节和第4.6节所建议
o Mapping UP 2 (which would include Low-Latency Data and/or OAM traffic, see [RFC4594]) to CS2, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.7 and 3.3, and possibly overwhelming the queues provisioned for OAM (which is typically lower in capacity (being Network Control Traffic), as compared to Low-Latency Data queues (being user traffic))
o 将2（包括低延迟数据和/或OAM流量，请参见[RFC4594]）映射到CS2，从而失去区分这两个不同服务类别的能力，如[RFC4594]第4.7节和第3.3节中所建议的，并可能使为OAM提供的队列无法承受（通常容量较低）（网络控制流量），与低延迟数据队列（用户流量）相比
o Mapping UP 1 (which would include High-Throughput Data and/or Low-Priority Data traffic, see [RFC4594]) to CS1, thus losing the ability to differentiate between these two distinct service classes, as recommended in [RFC4594], Sections 4.8 and 4.10, and causing legitimate business-relevant High-Throughput Data to receive a [RFC3662] Lower-Effort PDB, for which it is not intended
o 将1（包括高吞吐量数据和/或低优先级数据通信，请参见[RFC4594]）映射到CS1，从而失去区分这两个不同服务类别的能力，如[RFC4594]第4.8节和第4.10节所建议，并导致合法的业务相关高吞吐量数据接收[RFC3662]较低的工作量PDB，不适用于此
The following sections address these limitations and concerns in order to reconcile [RFC4594] and [IEEE.802.11-2016]. First downstream (wired-to-wireless) DSCP-to-UP mappings will be aligned and then upstream (wireless-to-wired) models will be addressed.
为了协调[RFC4594]和[IEEE.802.11-2016]，以下章节讨论了这些限制和问题。首先对下游（有线到无线）DSCP到上行的映射进行对齐，然后对上游（无线到有线）模型进行寻址。
3. Recommendations for Capabilities of Wireless Device Marking and Mapping
3. 无线设备标记和映射功能的建议
This document assumes and RECOMMENDS that all wireless APs (as the interconnects between wired-and-wireless networks) support the ability to:
本文件假设并建议所有无线AP（作为有线和无线网络之间的互连）支持以下能力：
o mark DSCP, per Diffserv standards
o 根据Diffserv标准标记DSCP
o mark UP, per the [IEEE.802.11-2016] standard
o 根据[IEEE.802.11-2016]标准进行标记
o support fully configurable mappings between DSCP and UP
o 支持DSCP和UP之间的完全可配置映射
o process DSCP markings set by wireless endpoint devices
o 处理无线端点设备设置的DSCP标记
This document further assumes and RECOMMENDS that all wireless endpoint devices support the ability to:
本文档进一步假设并建议所有无线端点设备支持以下功能：
o mark DSCP, per Diffserv standards
o 根据Diffserv标准标记DSCP
o mark UP, per the [IEEE.802.11-2016] standard
o 根据[IEEE.802.11-2016]标准进行标记
o support fully configurable mappings between DSCP (set by applications in software) and UP (set by the operating system and/ or wireless network interface hardware drivers)
o 支持DSCP（由软件中的应用程序设置）和UP（由操作系统和/或无线网络接口硬件驱动程序设置）之间的完全可配置映射
Having made the assumptions and recommendations above, it bears mentioning that, while the mappings presented in this document are RECOMMENDED to replace the current common default practices (as discussed in Sections 2.3 and 2.4), these mapping recommendations are not expected to fit every last deployment model; as such, they MAY be overridden by network administrators, as needed.
在作出上述假设和建议后，值得一提的是，虽然本文件中提出的映射建议用于取代当前常见的默认做法（如第2.3节和第2.4节所述），但这些映射建议并不适用于所有最后的部署模型；因此，网络管理员可以根据需要覆盖它们。
The following section specifies downstream (wired-to-wireless) mappings between [RFC4594], "Configuration Guidelines for Diffserv Service Classes" and [IEEE.802.11-2016]. As such, this section draws heavily from [RFC4594], including service class definitions and recommendations.
下一节规定了[RFC4594]、“Diffserv服务类配置指南”和[IEEE.802.11-2016]之间的下游（有线到无线）映射。因此，本节大量引用了[RFC4594]，包括服务类定义和建议。
This section assumes [IEEE.802.11-2016] wireless APs and/or WLAN controllers that support customizable, non-default DSCP-to-UP mapping schemes.
本节假设[IEEE.802.11-2016]无线AP和/或WLAN控制器支持可定制的非默认DSCP向上映射方案。
This section also assumes that [IEEE.802.11-2016] APs and endpoint devices differentiate UP markings with corresponding queuing and dequeuing treatments, as described in Section 2.2.
本节还假设[IEEE.802.11-2016]接入点和终端设备将上行标记与相应的排队和退队处理区分开来，如第2.2节所述。
Network Control Traffic is defined as packet flows that are essential for stable operation of the administered network [RFC4594], Section 3. 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:
网络控制流量定义为对受管网络稳定运行至关重要的数据包流[RFC4594]，第3节。网络控制流量不同于可能由某些应用程序或服务生成的用户应用程序控制（信令）。网络控制流量可分为两个服务类别：
o Network Control, and
o 网络控制，以及
o Operations, Administration, and Maintenance (OAM)
o 运营、管理和维护（OAM）
The Network Control service class is used for transmitting packets between network devices (e.g., 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.
网络控制服务类用于在需要在管理域内的节点之间交换控制（路由）信息的网络设备（例如路由器）之间以及在不同管理域之间的对等点之间传输分组。
[RFC4594], Section 3.2, recommends that Network Control Traffic be marked CS6 DSCP. Additionally, as stated in [RFC4594], Section 3.1: "CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols."
[RFC4594]第3.2节建议将网络控制流量标记为CS6 DSCP。此外，如[RFC4594]第3.1节所述：“CS7 DSCP值应保留供将来使用，可能用于将来的路由或控制协议。”
By default (as described in Section 2.4), packets marked DSCP CS7 will be mapped to UP 7 and serviced within the Voice Access Category (AC_VO). This represents the RECOMMENDED mapping for CS7, that is, packets marked to CS7 DSCP are RECOMMENDED to be mapped to UP 7.
默认情况下（如第2.4节所述），标记为DSCP CS7的数据包将映射到UP 7，并在语音访问类别（AC_VO）内提供服务。这表示CS7的建议映射，即，标记为CS7 DSCP的数据包建议映射到最多7个。
However, by default (as described in Section 2.4), packets marked 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 the intent expressed in [RFC4594], Section 3.2. As such, it is 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 it to the Voice Access Category (AC_VO), albeit with a marking distinguishing it from (data-plane) voice traffic.
但是，默认情况下（如第2.4节所述），标记为DSCP CS6的数据包将映射到最多6个，并在语音访问类别（AC_VO）内提供服务；此类映射和服务与[RFC4594]第3.2节中表达的意图相矛盾。因此，建议将标记为CS6的网络控制流量映射到最多7（根据[IEEE.802.11-2016]，第10.2.4.2节，表10-1），从而将其纳入语音访问类别（AC_VO），尽管标记将其与（数据平面）语音流量区分开来。
It should be noted that encapsulated routing protocols for encapsulated or overlay networks (e.g., VPN, Network Virtualization Overlays, etc.) are not Network Control Traffic for any physical network at the AP; hence, they SHOULD NOT be marked with CS6 in the first place.
应注意，用于封装或覆盖网络（例如，VPN、网络虚拟化覆盖等）的封装路由协议不是AP处任何物理网络的网络控制流量；因此，它们首先不应标有CS6。
Additionally, and as previously noted, the Security Considerations section (Section 8) contains additional recommendations for hardening Wi-Fi-at-the-edge deployment models, where, for example, network control protocols are not expected to be sent nor received between APs and client endpoint devices that are downstream.
此外，如前所述，安全注意事项一节（第8节）包含了加强边缘部署模型Wi-Fi的其他建议，例如，在边缘部署模型中，预计不会在AP和下游客户端端点设备之间发送或接收网络控制协议。
The OAM (Operations, Administration, and Maintenance) service class is recommended for OAM&P (Operations, Administration, and Maintenance and Provisioning). The OAM service class can include network management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog, etc., as well as network services, such as NTP, DNS, DHCP, etc. [RFC4594], Section 3.3, recommends that OAM traffic be marked CS2 DSCP.
OAM（操作、管理和维护）服务类别建议用于OAM&P（操作、管理、维护和资源调配）。OAM服务类可以包括网络管理协议，如SNMP、Secure Shell（SSH）、TFTP、Syslog等，以及网络服务，如NTP、DNS、DHCP等。[RFC4594]，第3.3节，建议将OAM流量标记为CS2 DSCP。
By default (as described in Section 2.3), packets marked DSCP CS2 will be mapped to UP 2 and serviced with the Background Access Category (AC_BK). Such servicing is a contradiction to the intent expressed in [RFC4594], 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, thereby admitting it to the Best Effort Access Category (AC_BE).
默认情况下（如第2.3节所述），标记为DSCP CS2的数据包将映射到UP 2，并使用后台访问类别（AC_BK）进行服务。此类维修与[RFC4594]第3.3节中表达的意图相矛盾。因此，建议对OAM通信量应用非默认映射，以便将CS2 DSCP映射到最多0，从而允许其进入尽力而为访问类别（AC_be）。
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 [RFC4594], Section 4.
用户流量定义为不同用户或订户之间的数据包流。它是发送到终端或从终端发送的流量，支持非常广泛的应用和服务[RFC4594]，第4节。
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
对于要求实时、极低延迟、极低抖动和相对恒定速率业务源（非弹性业务源）的极低数据包丢失的应用，建议使用电话服务类别。此服务类应用于IP电话服务。为电话业务提供的基本服务
service class is minimum jitter, delay, and packet loss service up to a specified upper bound. [RFC4594], Section 4.1, recommends that Telephony traffic be marked EF DSCP.
服务类别是最小抖动、延迟和分组丢失服务，达到指定的上限。[RFC4594]第4.1节建议将电话流量标记为EF DSCP。
Traffic marked to DSCP EF will map by default (as described in Section 2.3) to UP 5 and, thus, to the Video Access Category (AC_VI) rather than to the Voice Access Category (AC_VO), for which it is intended. Therefore, a non-default DSCP-to-UP mapping is RECOMMENDED, such that EF DSCP is mapped to UP 6, thereby admitting it into the Voice Access Category (AC_VO).
默认情况下（如第2.3节所述），标记为DSCP EF的流量将映射到最多5个，从而映射到视频访问类别（AC_VI），而不是语音访问类别（AC_VO）。因此，建议使用非默认的DSCP到UP映射，以便EF DSCP映射到UP 6，从而允许其进入语音访问类别（AC_VO）。
Similarly, the VOICE-ADMIT DSCP (44 decimal / 101100 binary) described in [RFC5865] is RECOMMENDED to be mapped to UP 6, thereby admitting it also into the Voice Access Category (AC_VO).
类似地，建议将[RFC5865]中描述的语音接入DSCP（44十进制/101100二进制）映射到最多6个，从而将其也纳入语音接入类别（AC_VO）。
The Signaling service class is recommended for delay-sensitive client-server (e.g., traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between 1) IP phone and soft-switch, 2) soft-client and soft-switch, and 3) 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. [RFC4594], Section 4.2, recommends that Signaling traffic be marked CS5 DSCP.
建议将信令服务类别用于对延迟敏感的客户端服务器（例如，传统电话）和对等应用程序信令。电话信令包括1）IP电话和软交换之间的信令，2）软客户端和软交换之间的信令，以及3）媒体网关和软交换之间的信令，以及使用各种协议的对等信令。此服务类用于控制会话和应用程序。[RFC4594]第4.2节建议将信令流量标记为CS5 DSCP。
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 (AC_VI), which it will map to by default (as described in Section 2.3). Therefore, it is RECOMMENDED to map Signaling traffic marked CS5 DSCP to UP 5, thereby admitting it to the Video Access Category (AC_VI).
虽然建议信令接收相对于默认类别（即AC_-BE）更高级别的服务，但它不需要最高级别的服务（即AC_-VO）。这只剩下视频访问类别（AC_VI），默认情况下将映射到该类别（如第2.3节所述）。因此，建议将标记为CS5 DSCP的信令流量映射到UP 5，从而将其纳入视频接入类别（AC_VI）。
Note: Signaling traffic is not control-plane traffic from the perspective of the network (but rather is data-plane traffic); as such, it does not merit provisioning in the Network Control service class (marked CS6 and mapped to UP 6). However, Signaling traffic is control-plane traffic from the perspective of the voice/video telephony overlay-infrastructure. As such, Signaling should be treated with preferential servicing versus other data-plane flows. This may be achieved in common WLAN deployments by mapping Signaling traffic marked CS5 to UP 5. On APs supporting per-UP EDCAF queuing logic (as described in Section 2.2), this will result in preferential treatment for Signaling traffic versus other video flows in the same access category (AC_VI), which are marked to UP 4, as well as preferred treatment over flows in the Best Effort (AC_BE) and Background (AC_BK) Access Categories.
注：从网络的角度来看，信令业务不是控制平面业务（而是数据平面业务）；因此，它不值得在网络控制服务类（标记为CS6并映射到UP 6）中进行配置。然而，从语音/视频电话覆盖基础设施的角度来看，信令业务是控制平面业务。因此，相对于其他数据平面流，信令应优先处理。这可以在普通WLAN部署中通过将标记为CS5的信令流量映射到UP 5来实现。在支持per UP EDCAF排队逻辑（如第2.2节所述）的AP上，这将导致优先处理同一接入类别（AC_VI）中的信令流量和其他视频流（标记为UP 4），以及优先处理尽最大努力（AC_BE）和背景（AC_BK）接入类别中的流量。
The Multimedia Conferencing service class is recommended for applications that require real-time service for rate-adaptive traffic. [RFC4594], Section 4.3, recommends Multimedia Conferencing traffic be marked AF4x (that is, AF41, AF42, and AF43, according to the rules defined in [RFC2475]).
多媒体会议服务类建议用于需要速率自适应通信实时服务的应用程序。[RFC4594]第4.3节建议将多媒体会议流量标记为AF4x（即，根据[RFC2475]中定义的规则，标记为AF41、AF42和AF43）。
The primary media type typically carried within the Multimedia Conferencing service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it does by default (as described in Section 2.3). Specifically, it is RECOMMENDED to map AF41, AF42, and AF43 to UP 4, thereby admitting Multimedia Conferencing into the Video Access Category (AC_VI).
多媒体会议服务类中通常携带的主要媒体类型是视频；因此，建议将此类映射到视频访问类别（AC_VI），默认情况下会这样做（如第2.3节所述）。具体而言，建议将AF41、AF42和AF43映射到最多4，从而将多媒体会议纳入视频访问类别（AC_VI）。
The Real-Time Interactive service class is recommended for applications that require low loss and jitter and very low delay for variable-rate inelastic traffic sources. Such applications may include inelastic video-conferencing applications, but may also include gaming applications (as pointed out in [RFC4594], Sections 2.1 through 2.3 and Section 4.4). [RFC4594], Section 4.4, recommends Real-Time Interactive traffic be marked CS4 DSCP.
实时交互服务类建议用于要求低损耗和抖动以及可变速率非弹性业务源极低延迟的应用。此类应用可能包括非弹性视频会议应用，但也可能包括游戏应用（如[RFC4594]第2.1节至第2.3节和第4.4节所述）。[RFC4594]第4.4节建议将实时交互流量标记为CS4 DSCP。
The primary media type typically carried within the Real-Time Interactive service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it does by default (as described in Section 2.3). Specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into the Video Access Category (AC_VI).
实时交互服务类中通常携带的主要媒体类型是视频；因此，建议将此类映射到视频访问类别（AC_VI），默认情况下会这样做（如第2.3节所述）。具体而言，建议将CS4映射到UP 4，从而允许实时交互流量进入视频访问类别（AC_VI）。
The Multimedia Streaming service class is recommended for applications that require near-real-time packet forwarding of variable-rate elastic traffic sources. Typically, these flows are unidirectional. [RFC4594], Section 4.5, recommends Multimedia Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33, according to the rules defined in [RFC2475]).
建议将多媒体流服务类用于需要可变速率弹性业务源的近实时数据包转发的应用程序。通常，这些流是单向的。[RFC4594]第4.5节建议将多媒体流媒体流量标记为AF3x（即，根据[RFC2475]中定义的规则，标记为AF31、AF32和AF33）。
The primary media type typically carried within the Multimedia Streaming service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it will by default (as described in Section 2.3). Specifically, it is RECOMMENDED to map AF31, AF32, and AF33 to UP 4, thereby admitting Multimedia Streaming into the Video Access Category (AC_VI).
通常在多媒体流服务类中携带的主要媒体类型是视频；因此，建议将该类映射到视频访问类别（AC_VI），默认情况下将映射到该类别（如第2.3节所述）。具体而言，建议将AF31、AF32和AF33映射到最多4，从而允许将多媒体流纳入视频访问类别（AC_VI）。
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. Typically these flows are unidirectional. [RFC4594] Section 4.6 recommends Broadcast Video traffic be marked CS3 DSCP.
建议将广播视频服务类别用于需要近实时数据包转发且恒定速率和可变速率非弹性业务源的数据包丢失非常低的应用。通常，这些流是单向的。[RFC4594]第4.6节建议将广播视频流量标记为CS3 DSCP。
As directly implied by the name, the primary media type typically carried within the Broadcast Video service class is video; as such, it is RECOMMENDED to map this class into the Video Access Category (AC_VI); however, by default (as described in Section 2.3), this service class will map to UP 3 and, thus, the Best Effort Access Category (AC_BE). Therefore, a non-default mapping is RECOMMENDED, such that CS4 maps to UP 4, thereby admitting Broadcast Video into the Video Access Category (AC_VI).
如名称所直接暗示的，通常在广播视频服务类别内携带的主要媒体类型是视频；因此，建议将此类映射到视频访问类别（AC_VI）；但是，在默认情况下（如第2.3节所述），该服务类别将映射到最多3个，从而映射到尽力而为访问类别（AC_BE）。因此，建议使用非默认映射，以便CS4映射到最多4，从而允许广播视频进入视频访问类别（AC_VI）。
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 are considered foreground traffic, with delays or drops to such traffic directly impacting user productivity. [RFC4594], Section 4.7, recommends Low-Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according to the rules defined in [RFC2475]).
低延迟数据服务类建议用于弹性和时间敏感的数据应用程序，通常具有事务性，其中用户通过网络等待响应以继续手头的任务。因此，这些流量被视为前台流量，此类流量的延迟或下降直接影响用户生产力。[RFC4594]第4.7节建议将低延迟数据标记为AF2x（即，根据[RFC2475]中定义的规则，标记为AF21、AF22和AF23）。
By default (as described in Section 2.3), Low-Latency Data will map to UP 2 and, thus, to the Background Access Category (AC_BK), which is contrary to the intent expressed in [RFC4594].
默认情况下（如第2.3节所述），低延迟数据将映射到最多2个，从而映射到后台访问类别（AC_BK），这与[RFC4594]中表达的意图相反。
Mapping Low-Latency Data to UP 3 may allow targeted traffic to receive a superior level of service via per-UP transmit queues servicing the EDCAF hardware for the Best Effort Access Category (AC_BE), as described in Section 2.2. Therefore it is RECOMMENDED to map Low-Latency Data traffic marked AF2x DSCP to UP 3, thereby admitting it to the Best Effort Access Category (AC_BE).
如第2.2节所述，将低延迟数据映射到最多3个可允许目标流量通过为EDCAF硬件提供服务的每向上传输队列接收更高级别的服务，以达到最佳努力访问类别（AC_BE）。因此，建议将标记为AF2x DSCP的低延迟数据流量映射到最多3个，从而将其纳入尽力而为访问类别（AC_BE）。
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 not user interactive. According to [RFC4594], Section 4.8, it can be assumed that this class will consume any available bandwidth and that packets
高吞吐量数据服务类建议用于需要对可变速率流量源进行及时数据包转发的弹性应用程序，更具体地说，它被配置为为为TCP寿命更长的流提供高效但受限的（必要时）吞吐量。这些流通常不是用户交互的。根据[RFC4594]第4.8节，可以假设该类将消耗任何可用带宽和该数据包
traversing congested links may experience higher queuing delays or packet loss. It is also assumed that this traffic is elastic and responds dynamically to packet loss. [RFC4594], Section 4.8, recommends High-Throughput Data be marked AF1x (that is, AF11, AF12, and AF13, according to the rules defined in [RFC2475]).
穿越拥挤的链路可能会经历更高的排队延迟或数据包丢失。还假设该流量是弹性的，并对数据包丢失作出动态响应。[RFC4594]第4.8节建议将高通量数据标记为AF1x（即，根据[RFC2475]中定义的规则，标记为AF11、AF12和AF13）。
By default (as described in Section 2.3), High-Throughput Data will map to UP 1 and, thus, to the Background Access Category (AC_BK), which is contrary to the intent expressed in [RFC4594].
默认情况下（如第2.3节所述），高通量数据将映射到最多1，从而映射到后台访问类别（AC_BK），这与[RFC4594]中表达的意图相反。
Unfortunately, there really is no corresponding fit for the High-Throughput Data service class within the constrained 4 Access Category [IEEE.802.11-2016] model. If the High-Throughput Data service class is assigned to the Best Effort Access Category (AC_BE), then it would contend with Low-Latency Data (while [RFC4594] recommends a distinction in servicing between these service classes) as well as with the default service class; alternatively, if it is assigned to the Background Access Category (AC_BK), then it would receive a less-then-best-effort service and contend with Low-Priority Data (as discussed in Section 4.2.10).
不幸的是，在受限4访问类别[IEEE.802.11-2016]模型中，高吞吐量数据服务类别实际上没有相应的适用性。如果将高吞吐量数据服务类别分配给尽力而为的访问类别（AC_BE），那么它将与低延迟数据（而[RFC4594]建议区分这些服务类别）以及默认服务类别进行竞争；或者，如果它被分配到后台访问类别（AC_BK），那么它将收到一个不太尽力而为的服务，并与低优先级数据竞争（如第4.2.10节所述）。
As such, since there is no directly corresponding fit for the High-Throughout Data service class within the [IEEE.802.11-2016] model, it is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE).
因此，由于[IEEE.802.11-2016]模型中的高通量数据服务类别没有直接对应的适用性，因此通常建议将高通量数据映射到0，从而将其纳入尽力而为的访问类别（AC_BE）。
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. [RFC4594], Section 4.9, states that the "Standard service class MUST use the Default Forwarding (DF) PHB".
对于在Diffserv网络域中未分类为其他受支持的转发服务类别之一的流量，建议使用标准服务类别。此服务类提供Internet的“尽力”转发行为。[RFC4594]第4.9节规定“标准服务类必须使用默认转发（DF）PHB”。
The Standard service class loosely corresponds to the [IEEE.802.11-2016] Best Effort Access Category (AC_BE); therefore, it is RECOMMENDED to map Standard service class traffic marked DF DSCP to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE). This happens to correspond to the default mapping (as described in Section 2.3).
标准服务类别大致对应于[IEEE.802.11-2016]尽力而为的接入类别（AC_BE）；因此，建议将标记为DF DSCP的标准服务类通信量映射到最多0，从而将其纳入尽力而为的访问类别（AC_BE）。这恰好对应于默认映射（如第2.3节所述）。
The Low-Priority Data service class serves applications that the user is willing to accept without service assurances. This service class is specified in [RFC3662] and [LE-PHB].
低优先级数据服务类服务于用户愿意在没有服务保证的情况下接受的应用程序。[RFC3662]和[LE-PHB]中规定了该服务类别。
[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP.
[RFC3662]和[RFC4594]都建议将低优先级数据标记为CS1 DSCP。
Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic.
注：由于[LE-PHB]为低优先级数据流量定义了较低努力（LE）PHB，并为该流量推荐了一个额外的DSCP，因此该标记建议将来可能会改变。
The Low-Priority Data service class loosely corresponds to the [IEEE.802.11-2016] Background Access Category (AC_BK); therefore, 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). This happens to correspond to the default mapping (as described in Section 2.3).
低优先级数据服务类别大致对应于[IEEE.802.11-2016]后台访问类别（AC_BK）；因此，建议将标记为CS1 DSCP的低优先级数据流量映射为UP 1，从而将其纳入后台访问类别（AC_BK）。这恰好对应于默认映射（如第2.3节所述）。
Figure 1 summarizes the [RFC4594] DSCP marking recommendations mapped to [IEEE.802.11-2016] UP and Access Categories applied in the downstream direction (i.e., from wired-to-wireless networks).
图1总结了[RFC4594]DSCP标记建议，这些建议对应于[IEEE.802.11-2016]上行和下行方向（即从有线网络到无线网络）应用的接入类别。
+-------------------------------------------------------------------+
| IETF Diffserv | PHB |Reference | IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category |
|===============+======+==========+=============+====================|
| | | | 7 | AC_VO (Voice) |
|Network Control| CS7 | RFC 2474 | OR |
|(reserved for | | | 0 | AC_BE (Best Effort)|
| future use) | | |See Security Considerations-Sec.8 |
+---------------+------+----------+-------------+--------------------+
| | | | 7 | AC_VO (Voice) |
|Network Control| CS6 | RFC 2474 | OR |
| | | | 0 | AC_BE (Best Effort)|
| | | | See Security Considerations |
+---------------+------+----------+-------------+--------------------+
| Telephony | EF | RFC 3246 | 6 | AC_VO (Voice) |
+---------------+------+----------+-------------+--------------------+
| VOICE-ADMIT | VA | RFC 5865 | 6 | AC_VO (Voice) |
| | | | | |
+---------------+------+----------+-------------+--------------------+
| Signaling | CS5 | RFC 2474 | 5 | AC_VI (Video) |
+-------------------------------------------------------------------+
| IETF Diffserv | PHB |Reference | IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category |
|===============+======+==========+=============+====================|
| | | | 7 | AC_VO (Voice) |
|Network Control| CS7 | RFC 2474 | OR |
|(reserved for | | | 0 | AC_BE (Best Effort)|
| future use) | | |See Security Considerations-Sec.8 |
+---------------+------+----------+-------------+--------------------+
| | | | 7 | AC_VO (Voice) |
|Network Control| CS6 | RFC 2474 | OR |
| | | | 0 | AC_BE (Best Effort)|
| | | | See Security Considerations |
+---------------+------+----------+-------------+--------------------+
| Telephony | EF | RFC 3246 | 6 | AC_VO (Voice) |
+---------------+------+----------+-------------+--------------------+
| VOICE-ADMIT | VA | RFC 5865 | 6 | AC_VO (Voice) |
| | | | | |
+---------------+------+----------+-------------+--------------------+
| Signaling | CS5 | RFC 2474 | 5 | AC_VI (Video) |
+---------------+------+----------+-------------+--------------------+
| Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC 2597 | 4 | AC_VI (Video) |
| | AF43 | | | |
+---------------+------+----------+-------------+--------------------+
| Real-Time | CS4 | RFC 2474 | 4 | AC_VI (Video) |
| Interactive | | | | |
+---------------+------+----------+-------------+--------------------+
| Multimedia | AF31 | | | |
| Streaming | AF32 | RFC 2597 | 4 | AC_VI (Video) |
| | AF33 | | | |
+---------------+------+----------+-------------+--------------------+
|Broadcast Video| CS3 | RFC 2474 | 4 | AC_VI (Video) |
+---------------+------+----------+-------------+--------------------+
| Low- | AF21 | | | |
| Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|
| Data | AF23 | | | |
+---------------+------+----------+-------------+--------------------+
| OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| High- | AF11 | | | |
| Throughput | AF12 | RFC 2597 | 0 | AC_BE (Best Effort)|
| Data | AF13 | | | |
+---------------+------+----------+-------------+--------------------+
| Standard | DF | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+--------------------------------------------------------------------+
+---------------+------+----------+-------------+--------------------+
| Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC 2597 | 4 | AC_VI (Video) |
| | AF43 | | | |
+---------------+------+----------+-------------+--------------------+
| Real-Time | CS4 | RFC 2474 | 4 | AC_VI (Video) |
| Interactive | | | | |
+---------------+------+----------+-------------+--------------------+
| Multimedia | AF31 | | | |
| Streaming | AF32 | RFC 2597 | 4 | AC_VI (Video) |
| | AF33 | | | |
+---------------+------+----------+-------------+--------------------+
|Broadcast Video| CS3 | RFC 2474 | 4 | AC_VI (Video) |
+---------------+------+----------+-------------+--------------------+
| Low- | AF21 | | | |
| Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|
| Data | AF23 | | | |
+---------------+------+----------+-------------+--------------------+
| OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| High- | AF11 | | | |
| Throughput | AF12 | RFC 2597 | 0 | AC_BE (Best Effort)|
| Data | AF13 | | | |
+---------------+------+----------+-------------+--------------------+
| Standard | DF | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+--------------------------------------------------------------------+
Note: All unused codepoints are RECOMMENDED to be mapped to UP 0 (See Security Considerations below)
注意：建议将所有未使用的代码点映射到0（请参阅下面的安全注意事项）
Figure 1: Summary of Mapping Recommendations from Downstream DSCP to IEEE 802.11 UP and AC
图1：从下游DSCP到IEEE 802.11以上和AC的映射建议摘要
In the upstream direction (i.e., wireless-to-wired), there are three types of mapping that may be implemented:
在上游方向（即，无线到有线），可以实现三种类型的映射：
o DSCP-to-UP mapping within the wireless client operating system, and
o 无线客户端操作系统内的DSCP向上映射，以及
o UP-to-DSCP mapping at the wireless AP, or
o 在无线AP上最多进行DSCP映射，或
o DSCP-Passthrough at the wireless AP (effectively a 1:1 DSCP-to-DSCP mapping)
o 无线AP上的DSCP直通（实际上是1:1的DSCP到DSCP映射）
As an alternative to the latter two options, the network administrator MAY choose to use the wireless-to-wired edge as a Diffserv boundary and explicitly set (or reset) DSCP markings according to administrative policy, thus making the wireless edge a Diffserv policy enforcement point; this approach is RECOMMENDED whenever the APs support the required classification and marking capabilities.
作为后两个选项的替代方案，网络管理员可以选择使用无线到有线边缘作为区分服务边界，并根据管理策略显式设置（或重置）DSCP标记，从而使无线边缘成为区分服务策略实施点；只要AP支持所需的分类和标记功能，就建议采用这种方法。
Each of these options will now be considered.
现在将考虑每一种选择。
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating System
5.1. 无线客户端操作系统中上游DSCP到上行映射
Some operating systems on wireless client devices utilize a similar default DSCP-to-UP mapping scheme as that described in Section 2.3. As such, this can lead to the same conflicts as described in that section, but in the upstream direction.
无线客户端设备上的某些操作系统使用与第2.3节所述类似的默认DSCP向上映射方案。因此，这可能会导致与该节中所述相同的冲突，但在上游方向。
Therefore, to improve on these default mappings, and to achieve parity and consistency with downstream QoS, it is RECOMMENDED that wireless client operating systems instead utilize the same DSCP-to-UP mapping recommendations presented in Section 4. Note that it is explicitly stated 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 re-mark 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).
因此，为了改进这些默认映射，并实现与下游QoS的奇偶性和一致性，建议无线客户端操作系统改为使用第4节中提出的相同的DSCP向上映射建议。请注意，明确指出，请求标记CS6或CS7 DSCP的数据包应映射到最多0（而不是最多7）。此外，在这种情况下，无线客户端操作系统应将此类分组重新标记为DSCP 0。这是因为CS6和CS7 DSCP以及多达7个标记是用于网络控制协议的，而这些协议不应来自无线客户端端点设备。本建议在安全注意事项一节（第8节）中有详细说明。
UP-to-DSCP mapping generates a DSCP value for the IP packet (either an unencapsulated IP packet or an IP packet encapsulated within a tunneling protocol such as Control and Provisioning of Wireless Access Points (CAPWAP) -- and destined towards a wireless LAN controller for decapsulation and forwarding) from the Layer 2 [IEEE.802.11-2016] UP marking. This is typically done in the manner described in Section 2.4.
最多DSCP映射为来自第2层的IP数据包（未封装的IP数据包或封装在隧道协议内的IP数据包，如无线接入点的控制和供应（CAPWAP）——生成DSCP值，并发送到无线LAN控制器进行解封装和转发[IEEE.802.11-2016]提高分数。这通常按照第2.4节所述的方式进行。
It should be noted that any explicit re-marking policy to be performed on such a packet generally takes place at the nearest classification and marking policy enforcement point, which may be:
应注意的是，对此类数据包执行的任何明确的重新标记策略通常发生在最近的分类和标记策略实施点，这可能是：
o At the wireless AP, and/or
o 在无线AP，和/或
o At the wired network switch port, and/or
o 在有线网络交换机端口，和/或
o At the wireless LAN controller
o 在无线局域网控制器上
Note: Multiple classification and marking policy enforcement points may exist, as some devices have the capability to re-mark at only Layer 2 or Layer 3, while other devices can re-mark at either/both layers.
注意：可能存在多个分类和标记策略实施点，因为某些设备只能在第2层或第3层重新标记，而其他设备可以在其中一层/两层重新标记。
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).
因此，最多DSCP映射允许无线L2标记影响有线IP网络上数据包的QoS处理（即，直到数据包到达最近的分类和标记策略实施点）。
It should be further noted that nowhere in the [IEEE.802.11-2016] specification is there an intent expressed for UP markings to be used to influence QoS treatment over wired IP networks. Furthermore, [RFC2474], [RFC2475], and [RFC8100] all allow for the host to set DSCP markings for end-to-end QoS treatment over IP networks. Therefore, wireless APs MUST NOT leverage Layer 2 [IEEE.802.11-2016] UP markings as set by wireless hosts and subsequently perform a UP-to-DSCP mapping in the upstream direction. But rather, if wireless host markings are to be leveraged (as per business requirements, technical constraints, and administrative policies), then it is RECOMMENDED to pass through the Layer 3 DSCP markings set by these wireless hosts instead, as is discussed in the next section.
应该进一步注意的是，[IEEE.802.11-2016]规范中没有明确表示要使用UP标记来影响有线IP网络上的QoS处理。此外，[RFC2474]、[RFC2475]和[RFC8100]都允许主机为IP网络上的端到端QoS处理设置DSCP标记。因此，无线AP不得利用无线主机设置的第2层[IEEE.802.11-2016]上行标记，并随后在上行方向执行上行至DSCP映射。但是，如果要利用无线主机标记（根据业务需求、技术约束和管理策略），则建议通过这些无线主机设置的第3层DSCP标记，如下一节所述。
It is generally NOT RECOMMENDED to pass through DSCP markings from unauthenticated and unauthorized devices, as these are typically considered untrusted sources.
通常不建议通过未经验证和未经授权设备的DSCP标记，因为这些设备通常被视为不受信任的来源。
When business requirements and/or technical constraints and/or administrative policies require QoS markings to be passed through at the wireless edge, then it is RECOMMENDED to pass through Layer 3 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the upstream direction, with the exception of CS6 and CS7 (as will be discussed further), for the following reasons:
当业务需求和/或技术约束和/或管理策略要求在无线边缘通过QoS标记时，建议在上游方向通过第3层DSCP标记（第2层[IEEE.802.11-2016]上行标记），CS6和CS7除外（将进一步讨论），基于以下原因：
o [RFC2474], [RFC2475], and [RFC8100] all allow for hosts to set DSCP markings to achieve an end-to-end differentiated service
o [RFC2474]、[RFC2475]和[RFC8100]都允许主机设置DSCP标记以实现端到端区分服务
o [IEEE.802.11-2016] does not specify that UP markings are to be used to affect QoS treatment over wired IP networks
o [IEEE.802.11-2016]未规定使用上行标记来影响有线IP网络上的QoS处理
o Most present wireless device operating systems generate UP values by the same method as described in Section 2.3 (i.e., by using the 3 MSBs of the encapsulated 6-bit DSCP); then, at the AP, these 3-bit markings are converted back into DSCP values, typically in the default manner described in Section 2.4; as such, information is lost in the translation from a 6-bit marking to a 3-bit marking (which is then subsequently translated back to a 6-bit marking); passing through the original (encapsulated) DSCP marking prevents such loss of information
o 大多数现有的无线设备操作系统通过第2.3节中描述的相同方法生成UP值（即，通过使用封装的6位DSCP的3个MSB）；然后，在AP，这些3位标记被转换回DSCP值，通常以第2.4节中描述的默认方式；因此，信息在从6位标记转换为3位标记的过程中丢失（随后转换回6位标记）；通过原始（封装）DSCP标记可防止此类信息丢失
o A practical implementation benefit is also realized by passing through the DSCP set by wireless client devices, as enabling applications to mark DSCP is much more prevalent and accessible to programmers of applications running on wireless device platforms, vis-a-vis trying to explicitly set UP values, which requires special hooks into the wireless device operating system and/or hardware device drivers, many of which do not support such functionality
o 通过通过无线客户端设备设置的DSCP，还可以实现实际的实施好处，因为使应用程序能够标记DSCP更为普遍，并且对于在无线设备平台上运行的应用程序的程序员来说，相对于试图显式设置值，这需要无线设备操作系统和/或硬件设备驱动程序中的特殊挂钩，其中许多不支持此类功能
CS6 and CS7 are exceptions to this passthrough recommendation because wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with those two markings poses a threat to operation of the wired network (see Section 8.2). CS6 and CS7 SHOULD NOT be passed through to the wired network in the upstream direction unless the AP has been specifically configured to do that by a network administrator or operator.
CS6和CS7是本直通建议的例外情况，因为无线主机不应使用它们（见第5.1节），且具有这两个标记的通信量对有线网络的运行构成威胁（见第8.2节）。CS6和CS7不应通过上行方向的有线网络，除非AP已被网络管理员或运营商专门配置为这样做。
An alternative option to mapping is for the administrator to treat the wireless edge as the edge of the Diffserv domain and explicitly set (or reset) DSCP markings in the upstream direction according to administrative policy. This option is RECOMMENDED over mapping, as this typically is the most secure solution because the network administrator directly enforces the Diffserv policy across the IP network (versus an application developer and/or the developer of the operating system of the wireless endpoint device, who may be functioning completely independently of the network administrator).
映射的另一种选择是管理员将无线边缘视为Diffserv域的边缘，并根据管理策略在上游方向显式设置（或重置）DSCP标记。建议在映射上使用此选项，因为这通常是最安全的解决方案，因为网络管理员直接在IP网络上实施区分服务策略（相对于无线终端设备的应用程序开发人员和/或操作系统开发人员，他们可能完全独立于网络管理员工作）。
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).
QoS是通过混合协调功能（HCF）在无线网络上实现的。为了给HCF中支持QoS的增强提供更好的上下文，首先回顾一下原始的分布式协调功能（DCF）可能会有所帮助。
As has been noted, the Wi-Fi medium is a shared medium, with each station -- including the wireless AP -- 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.
如前所述，Wi-Fi媒体是一种共享媒体，每个站点（包括无线AP）都在平等地争夺该媒体。因此，它与任何其他共享媒体一样面临着同样的挑战，需要一种机制来防止（或避免）冲突，当两个（或更多）站点尝试同时传输时，可能会发生冲突。
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 predefined set of rules was invoked that required stations to back off and wait random periods of time before reattempting 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.
IEEE以太网工作组通过实施载波侦听多址/冲突检测（CSMA/CD）机制解决了这一难题，该机制可以检测共享物理电缆上的冲突（因为冲突可以检测为物理导线上的反射能量脉冲）。一旦检测到冲突，就会调用一组预定义的规则，要求电台在重新尝试传输之前后退并等待随机时间段。虽然CSMA/CD改进了以太网作为共享介质的使用，但应注意解决以太网冲突的最终解决方案是交换技术的进步，它将每条以太网电缆视为专用冲突域。
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 IEEE 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 CWs.
因此，IEEE修改了CSMA/CD机制，使其适应无线网络，以提供载波侦听多址/冲突避免（CSMA/CA）。IEEE 802.11中使用的原始CSMA/CA机制是分布式协调功能。DCF是一个基于计时器的系统，它利用了三组关键的计时器，即时隙时间、帧间空间和CWs。
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 [IEEE.802.11-2016]. For example, [IEEE.802.11-2016] specifies the slot time to be 20 microseconds ([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 newer implementations (including IEEE 802.11g, 802.11a, 802.11n, and 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per spatial stream) define a shorter slot time of 9 microseconds ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
时隙时间是DCF和HCF的基本时间度量单位，所有其他计时器都基于此。时隙持续时间随[IEEE.802.11-2016]中描述的不同代数据速率和性能而变化。例如，[IEEE.802.11-2016]指定传统实现（如IEEE 802.11b，支持1、2、5.5和11 Mbps数据速率）的时隙时间为20微秒（[IEEE.802.11-2016]，表15-5），而较新的实现（包括IEEE 802.11g、802.11a、802.11n和802.11ac，支持从6.5 Mbps到每个空间流超过2 Gbps的数据速率）定义了9微秒的较短时隙时间（[IEEE.802.11-2016]，第17.4.4节，表17-21）。
The time interval between frames that are transmitted over the air is called the Interframe Space (IFS). Several IFSs are defined in [IEEE.802.11-2016], with the most relevant to DCF being the Short Interframe Space (SIFS), the DCF Interframe Space (DIFS), and the Extended Interframe Space (EIFS).
通过空中传输的帧之间的时间间隔称为帧间空间（IFS）。[IEEE.802.11-2016]中定义了几个IFS，其中与DCF最相关的是短帧间空间（SIFS）、DCF帧间空间（DIFS）和扩展帧间空间（EIFS）。
The SIFS is the amount of time in microseconds required for a wireless interface to process a received RF signal and its associated frame (as specified in [IEEE.802.11-2016]) and to generate a response frame. Like slot times, the SIFS can vary according to the performance implementation of [IEEE.802.11-2016]. The SIFS for IEEE 802.11a, 802.11n, and 802.11ac (in 5 GHz) is 16 microseconds ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
SIFS是无线接口处理接收到的RF信号及其相关帧（如[IEEE.802.11-2016]中规定）和生成响应帧所需的时间量（以微秒为单位）。与时隙时间一样，SIF可以根据[IEEE.802.11-2016]的性能实现而变化。IEEE 802.11a、802.11n和802.11ac（5 GHz）的SIF为16微秒（[IEEE.802.11-2016]，第17.4.4节，表17-21）。
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 to be idle for the duration of a DIFS interval. The DIFS is calculated as:
此外，站点必须在发送之前感知无线媒体的状态。如果它发现介质在DIFS期间持续空闲，则允许它尝试传输帧（在等待额外的随机退避周期之后，将在下一节中讨论）。如果在DIFS间隔期间发现信道繁忙，则站点必须延迟其传输，直到发现介质在DIFS间隔期间处于空闲状态。DIF的计算公式如下：
DIFS = SIFS + (2 * Slot time)
DIFS = SIFS + (2 * Slot time)
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 CW.
然而，如果所有站点在尝试传输之前只等待固定的时间量，那么冲突将是频繁的。为了抵消这一点，每个站点必须在传输之前等待，不仅是固定的时间量（DIF），而且是随机的时间量（随机退避）。生成的随机退避计时器的范围由CW限定。
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 CW minimum value (CWmin), inclusive. The CWmin for DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
争用窗口限制了生成的随机退避计时器的范围，每个站点在尝试传输之前必须等待（除了DIF）。初始范围设置在0和CW最小值（CWmin）之间，包括0和CWmin。DCF的CWmin（5 GHz）指定为15个时隙时间（[IEEE.802.11-2016]，第17.4.4节，表17-21）。
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 may 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
但是，有可能两个（或更多）台站恰好在该范围内拾取完全相同的随机值。如果发生这种情况，则可能发生碰撞。此时，站点有效地再次开始该过程，等待DIF并生成新的随机退避值。然而，一个关键的区别是，对于这个后续的
attempt, the CW approximately 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 CW size (CWmax) is reached. The CWmax for DCF is specified as 1023 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21).
尝试时，CW的大小约为原来的两倍（因此，以指数方式增加随机值的范围）。如果碰撞继续发生，此过程会根据需要重复，直到达到最大CW大小（CWmax）。DCF的CWmax指定为1023个时隙时间（[IEEE.802.11-2016]，第17.4.4节，表17-21）。
At this point, transmission attempts may still continue (until some other predefined limit is reached), but the CW sizes are fixed at the CWmax value.
此时，传输尝试仍可能继续（直到达到某些其他预定义限制），但CW大小固定在CWmax值。
Incidentally it may be observed that a significant amount of jitter can be introduced by this contention process for wireless transmission access. For example, the incremental transmission delay of 1023 slot times (CWmax) using 9-microsecond slot times may be as high as 9 ms of jitter per attempt. And, as previously noted, multiple attempts can be made at CWmax.
顺便提一下，可以观察到，对于无线传输接入的该争用过程可以引入大量抖动。例如，使用9微秒时隙时间的1023时隙时间（CWmax）的增量传输延迟可高达每次尝试9毫秒的抖动。而且，如前所述，可以在CWmax进行多次尝试。
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 IEEE 802.11, which was integrated into the main IEEE 802.11 standard in 2007.
因此，从前面对DCF的描述中可以看出，在争夺共享无线媒体时，没有一个站对另一个站的优先待遇；在同一争用过程中，也没有一种类型的通信量优先于另一种类型的通信量。为了支持后一个要求，IEEE在2005年增强了DCF以支持QoS，在IEEE 802.11中指定了HCF，该标准于2007年集成到主要的IEEE 802.11标准中。
One of the key changes to the frame format in [IEEE.802.11-2016] 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.
[IEEE.802.11-2016]中对帧格式的关键更改之一是加入了QoS控制字段，其中3位专用于QoS标记。这些位是指用户优先级（UP）位，它们支持八个不同的标记值：0-7，包括0-7。
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 the Access Categories (ACs) from [IEEE.802.11-2016] that generate differentiated treatment over wireless media.
虽然此类标记允许区分框架，但仅这些标记不会直接影响空气处理。相反，正是[IEEE.802.11-2016]中不可配置和标准规定的向上标记到接入类别（ACs）的映射在无线媒体上产生了差异化的处理。
Pairs of UP values are mapped to four defined access categories that correspondingly 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 2 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1).
向上值对映射到四个定义的访问类别，这些类别相应地指定空中帧的不同处理方式。这些访问类别（按照从上到下的相对优先级顺序）及其相应的向上映射如图2所示（改编自[IEEE.802.11-2016]，第10.2.4.2节，表10-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 |
+-----------------------------------------+
+-----------------------------------------+
| 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 2: Mappings between IEEE 802.11 Access Categories and User Priority
图2:IEEE 802.11访问类别和用户优先级之间的映射
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 their respective types of traffic, as will be discussed next.
这四种接入类别在空中实现差异化服务的方式主要是通过调整固定和随机定时器来实现的，站点在发送各自类型的业务之前必须等待这些定时器，这将在下面讨论。
As previously mentioned, each station must wait a fixed amount of time to ensure the medium is idle before attempting transmission. With DCF, the DIFS is constant for all types of traffic. However, with [IEEE.802.11-2016], 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). AIFSs are defined in slot times and the AIFSs per access category are shown in Figure 3 (adapted from [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137).
如前所述，在尝试传输之前，每个站点必须等待固定的时间，以确保介质处于空闲状态。对于DCF，DIF对于所有类型的流量都是恒定的。然而，在[IEEE.802.11-2016]中，站点必须等待的固定时间取决于接入类别，称为仲裁帧间空间（AIFS）。AIF在时隙时间中定义，每个接入类别的AIF如图3所示（改编自[IEEE.802.11-2016]，第9.4.2.29节，表9-137）。
+-------------------------------------------+
| Access | Designative | AIFS |
| Category | (informative) |(slot times)|
|============+=================+============|
| AC_VO | Voice | 2 |
+------------+-----------------+------------+
| AC_VI | Video | 2 |
+------------+-----------------+------------+
| AC_BE | Best Effort | 3 |
+------------+-----------------+------------+
| AC_BK | Background | 7 |
+------------+-----------------+------------+
+-------------------------------------------+
| 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 3: Arbitration Interframe Spaces by Access Category
图3：按访问类别划分的仲裁帧间空间
Not only is the fixed amount of time that a station has to wait skewed according to its [IEEE.802.11-2016] access category, but so are the relative sizes of the CWs that bound the random backoff timers, as shown in Figure 4 (adapted from [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137).
根据[IEEE.802.11-2016]访问类别，站点必须等待的固定时间量不仅是扭曲的，而且束缚随机退避计时器的CWs的相对大小也是扭曲的，如图4所示（改编自[IEEE.802.11-2016]，第9.4.2.29节，表9-137）。
+-------------------------------------------------------+
| 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 |
+-----------+-----------------+------------+------------+
+-------------------------------------------------------+
| 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 4: CW Sizes by Access Category
图4：按访问类别划分的CW大小
When the fixed and randomly generated timers are added together on a per-access-category basis, then traffic assigned to the Voice Access Category (i.e., traffic marked to UP 6 or 7) will receive a statistically superior service relative to traffic assigned to the Video Access Category (i.e., traffic marked UP 5 and 4), which, in turn, will receive a statistically superior service relative to traffic assigned to the Best Effort Access Category traffic (i.e., traffic marked UP 3 and 0), which finally will receive a statistically superior service relative to traffic assigned to the Background Access Category traffic (i.e., traffic marked to UP 2 and 1).
当在每个访问类别的基础上将固定和随机生成的计时器添加在一起时，分配给语音访问类别的流量（即标记为6或7的流量）将接收到相对于分配给视频访问类别的流量（即标记为5和4的流量）的统计上优越的服务，这反过来，将收到相对于分配给尽力而为访问类别流量（即标记为3和0的流量）的统计上优越的服务，最终将收到相对于分配给后台访问类别流量（即标记为2和1的流量）的统计上优越的服务。
IEEE 802.11u [IEEE.802-11u-2011] is an addendum that has now been included within the main standard ([IEEE.802.11-2016]), and which includes, among other enhancements, a mechanism by which wireless APs can communicate DSCP to/from UP mappings that have been configured on the wired IP network. Specifically, a QoS Map Set information element (described in [IEEE.802.11-2016], Section 9.4.2.95, and commonly referred to as the "QoS Map element") is transmitted from an AP to a wireless endpoint device in an association / re-association Response frame (or within a special QoS Map Configure frame).
IEEE 802.11u[IEEE.802-11u-2011]是一个附录，现已包含在主要标准（[IEEE.802.11-2016]）中，其中包括一种机制，通过该机制，无线AP可以与有线IP网络上配置的UP映射进行通信。具体而言，QoS映射集信息元素（如[IEEE.802.11-2016]第9.4.2.95节所述，通常称为“QoS映射元素”）在关联/重新关联响应帧（或特殊QoS映射配置帧）中从AP传输到无线端点设备。
The purpose of the QoS Map element is to provide the mapping of higher-layer QoS constructs (i.e., DSCP) to User Priorities. One intended effect of receiving such a map is for the wireless endpoint device (that supports this function and is administratively configured to enable it) to perform corresponding DSCP-to-UP mapping within the device (i.e., between applications and the operating system / wireless network interface hardware drivers) to align with what the APs are mapping in the downstream direction, so as to achieve consistent end-to-end QoS in both directions.
QoS映射元素的目的是提供高层QoS构造（即DSCP）到用户优先级的映射。接收这样的映射的一个预期效果是无线端点设备（支持此功能并且管理上配置为使其能够）在设备内执行相应的DSCP到UP映射（即，在应用程序和操作系统/无线网络接口硬件驱动器之间）与AP在下游方向上的映射一致，以便在两个方向上实现一致的端到端QoS。
The QoS Map element includes two key components:
QoS映射元素包括两个关键组件：
1) each of the eight UP values (0-7) is associated with a range of DSCP values, and
1) 八个向上值（0-7）中的每一个都与一系列DSCP值相关联，并且
2) (up to 21) exceptions from these range-based DSCP to/from UP mapping associations may be optionally and explicitly specified.
2) （最多21个）这些基于范围的DSCP到/来自向上映射关联的例外情况可以选择性地明确指定。
In line with the recommendations put forward in this document, the following recommendations apply when the QoS Map element is enabled:
根据本文件中提出的建议，当启用QoS映射元素时，以下建议适用：
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 Section 8.2, and
1) 建议将八个上限值（0-7）中的每一个映射到DSCP 0（作为基线，以满足第8.2节中的建议），以及
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 Codepoints that are in use over the IP network.
2) （最多21个）根据第4.3节，建议对此基线映射进行例外，以对应于IP网络上使用的Diffserv代码点。
It is important to note that the QoS Map element is intended to be transmitted from a wireless AP to a non-AP station. As 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 extends the Diffserv domain by connecting other APs and infrastructure devices through the IEEE 802.11 medium are not included in the cases covered by the presence of the QoS Map element, and therefore are not included in the present recommendation.
重要的是要注意，QoS映射元素打算从无线AP发送到非AP站。因此，使用此元素的模型是AP为区分服务域边缘的网络模型。AP通过IEEE 802.11介质连接其他AP和基础设施设备来扩展区分服务域的网络不包括在QoS映射元素的存在所覆盖的情况中，因此不包括在本建议中。
This document has no IANA actions.
本文档没有IANA操作。
The recommendations in this document concern widely deployed wired and wireless network functionality, and, for that reason, do not present additional security concerns that do not already exist in these networks. In fact, several of the recommendations made in this document serve to protect wired and wireless networks from potential abuse, as is discussed further in this section.
本文档中的建议涉及广泛部署的有线和无线网络功能，因此，不存在这些网络中尚不存在的其他安全问题。事实上，本文件中提出的一些建议旨在保护有线和无线网络免受潜在的滥用，本节将对此进行进一步讨论。
It may be possible for a wired or wireless device (which could be either a host or a network device) to mark packets (or map packet markings) in a manner that interferes with or degrades existing QoS policies. Such marking or mapping may be done intentionally or unintentionally by developers and/or users and/or administrators of such devices.
有线或无线设备（可以是主机或网络设备）可能以干扰或降低现有QoS策略的方式标记分组（或映射分组标记）。此类标记或映射可由此类设备的开发人员和/或用户和/或管理员有意或无意地进行。
To illustrate: A gaming application designed to run on a smartphone 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 forwarded without change over a business network, then this could interfere with QoS policies intended to provide priority services for business voice applications.
举例说明：设计用于在智能手机或平板电脑上运行的游戏应用程序可能会请求将其所有数据包标记为DSCP EF和/或UP 6。然而，如果来自这样一个应用程序的流量在业务网络上被转发而没有改变，那么这可能会干扰旨在为业务语音应用程序提供优先服务的QoS策略。
To mitigate such scenarios, it is RECOMMENDED to implement general QoS security measures, including:
为缓解此类情况，建议实施一般QoS安全措施，包括：
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., re-marked 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 Internet of Things (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.
o 设置反映业务目标和策略的流量调节策略，以便来自授权用户和/或应用程序和/或端点的流量将被网络接受；否则，数据包标记将被“漂白”（即，重新标记为DSCP DF和/或0以上）。此外，第5.3节明确指出，通常不建议从未经授权和/或未经认证的设备上穿过DSCP标记，因为这些设备通常被视为不受信任的来源。这对于物联网（IoT）部署尤其重要，在IoT部署中，数百亿台设备连接到IP网络，几乎没有或几乎没有安全功能，因此容易被用作DDoS攻击的代理。如果这些设备的数据包标记是可信的，这些攻击可以通过优先的QoS处理被放大。
o Policing EF marked packet flows, as detailed in [RFC2474], Section 7, and [RFC3246], Section 3.
o 监管EF标记的数据包流，详见[RFC2474]第7节和[RFC3246]第3节。
In addition to these general QoS security recommendations, WLAN-specific QoS security recommendations can serve to further mitigate attacks and potential network abuse.
除了这些一般的QoS安全建议外，WLAN特定的QoS安全建议还可以进一步减轻攻击和潜在的网络滥用。
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.
无线局域网呈现独特的DoS攻击向量，因为端点设备在完全平等的基础上与网络争夺共享媒体（如AP所表示）。这意味着任何无线客户端都可能通过在上行方向发送标记为首选上行值（即上行值4-7）的分组来垄断空中业务。同样，如果将过多的下游流量标记/映射到这些相同的首选上行值，则广播时间可能被垄断。因此，应控制标记/映射到这些首选上限值（上限为4-7）的能力。
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 (as described in Section 2.3) 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. Similarly, an uninformed application developer may request all traffic from his/her application be marked CS7 or CS6, thinking this would achieve the best overall servicing of their application traffic, while not realizing that such a marking (if honored by the client operating system) could cause not only WLAN DoS, but also IP
例如，如果此类标记/映射未得到控制，则恶意用户可能会通过向下游泛滥标记为CS7 DSCP的流量而导致WLAN拒绝服务。默认情况下（如第2.3节所述），此代码点将映射到最多7个，并将分配给语音访问类别（AC_VO）。这样的洪水不仅会导致无线语音应用程序拒绝服务，还会导致所有其他流量类别的拒绝服务。类似地，不知情的应用程序开发人员可能会要求将其应用程序中的所有流量标记为CS7或CS6，认为这将实现对其应用程序流量的最佳总体服务，但没有意识到这样的标记（如果客户机操作系统遵守）不仅会导致WLAN拒绝服务，还会导致IP拒绝服务
network instability, as the traffic marked CS7 or CS6 finds its way into queues intended for servicing (relatively low-bandwidth) network control protocols, potentially starving legitimate network control protocols in the process.
网络不稳定，因为标记为CS7或CS6的流量进入用于服务（相对较低带宽）网络控制协议的队列，这可能会导致过程中合法网络控制协议的匮乏。
Therefore, to mitigate such an attack, it is RECOMMENDED that all packets marked to Diffserv Codepoints not authorized or explicitly provisioned for use over the wireless network by the network administrator be mapped to UP 0; this recommendation applies both at the AP (in the downstream direction) and within the operating system of the wireless endpoint device (in the upstream direction).
因此，为了减轻这种攻击，建议将所有标记为Diffserv代码点的数据包映射到0，这些数据包未经网络管理员授权或明确设置用于无线网络；本建议既适用于AP（在下游方向），也适用于无线终端设备的操作系统（在上游方向）。
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.
这种将未使用的代码点映射到0的策略还可以防止使用非标准代码点导致WLAN拒绝服务的攻击。考虑使用范围函数将代码点映射到上值的情况（例如，DSCP值45-55所有映射到6），然后攻击者可以在WLAN上的上游或下游方向上对例如DSCP 49标记的包进行洪泛，从而导致DOS对过程中的所有其他流量类。
In the majority of WLAN deployments, the AP represents not only the edge of the Diffserv domain, but also the edge of the network infrastructure itself; that is, only wireless client endpoint devices are downstream from the AP. In such a deployment model, CS6 and CS7 also fall into the category of codepoints that are not in use over the wireless LAN (since only wireless client endpoint devices are downstream from the AP in this model and 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 Wi-Fi-at-the-edge deployment models. Otherwise, it would be easy for a malicious application 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 (as described in Section 2.3), be mapped to UP 6, causing all other traffic classes on the WLAN to be starved, as well as 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 re-marked to DSCP 0 and mapped to UP 0 by the wireless client operating system.
在大多数WLAN部署中，AP不仅代表区分服务领域的边缘，而且代表网络基础设施本身的边缘；也就是说，只有无线客户端端点设备位于AP的下游。在这样的部署模型中，CS6和CS7也属于不在无线LAN上使用的代码点类别（因为在此模型中，只有无线客户端端点设备位于AP的下游，并且这些设备不（合法地）参与网络控制协议交换）。因此，建议在这些Wi-Fi边缘部署模式中，CS6和CS7 DSCP最多映射到0。否则，恶意应用程序开发人员，甚至无意中编程不良的IoT设备，很容易通过洪泛标记为CS6 DSCP的流量，导致WLAN拒绝服务，甚至有线IP网络不稳定，默认情况下（如第2.3节所述），该流量将映射到最多6，导致WLAN上的所有其他流量类别被饿死，以及有线IP网络上用于路由协议服务的劫持队列。在这一点上，第5.1节还建议，请求标记CS6或CS7 DSCP的数据包应重新标记为DSCP 0，并由无线客户端操作系统映射到最多0。
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 mitigate security risks of both wired and wireless networks deploying QoS include strong device- and/or user-authentication, access-control, rate-limiting, control-plane policing, encryption, and other techniques; however, the implementation recommendations for such
最后，应注意，本文件中提出的建议并非旨在解决利用QoS标记滥用的所有攻击向量。可进一步帮助减轻部署QoS的有线和无线网络的安全风险的机制包括强大的设备和/或用户认证、访问控制、速率限制、控制平面监管、加密和其他技术；然而，这类项目的实施建议
mechanisms are beyond the scope of this document to address in detail. Suffice it to say that the security of the devices and networks implementing QoS, including QoS mapping between wired and wireless networks, merits consideration in actual deployments.
这些机制超出了本文件详细论述的范围。可以说，实现QoS的设备和网络的安全性，包括有线和无线网络之间的QoS映射，在实际部署中值得考虑。
[IEEE.802.11-2016] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December 2016, <https://standards.ieee.org/findstds/ standard/802.11-2016.html>.
【IEEE.802.11-2016】IEEE，“IEEE信息技术标准-系统间电信和信息交换-局域网和城域网-特定要求-第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE 802.11，DOI 10.1109/IEEESTD.2016.7786995，2016年12月， <https://standards.ieee.org/findstds/ 标准/802.11-2016.html>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<https://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <https://www.rfc-editor.org/info/rfc2597>.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 2597，DOI 10.17487/RFC2597，1999年6月<https://www.rfc-editor.org/info/rfc2597>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[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, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 3246，DOI 10.17487/RFC3246，2002年3月<https://www.rfc-editor.org/info/rfc3246>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <https://www.rfc-editor.org/info/rfc3662>.
[RFC3662]Bless，R.，Nichols，K.和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 3662，DOI 10.17487/RFC3662，2003年12月<https://www.rfc-editor.org/info/rfc3662>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<https://www.rfc-editor.org/info/rfc4594>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <https://www.rfc-editor.org/info/rfc5865>.
[RFC5865]Baker，F.，Polk，J.，和M.Dolly，“容量允许流量的差异化服务代码点（DSCP）”，RFC 5865，DOI 10.17487/RFC5865，2010年5月<https://www.rfc-editor.org/info/rfc5865>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[GSMA-IPX_Guidelines] GSM Association, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) Version 11.0", Official Document IR.34, November 2014, <https://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>.
[GSMA-IPX_指南]GSM协会，“IPX提供商网络指南（以前的服务提供商IP主干网指南）11.0版”，官方文件IR.342014年11月<https://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>。
[IEEE.802-11u-2011] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment 9: Interworking with External Networks", IEEE 802.11, DO 10.1109/IEEESTD.2011.5721908, February 2011, <http://standards.ieee.org/getieee802/ download/802.11u-2011.pdf>.
【IEEE.802-11u-2011】IEEE，“IEEE信息技术标准-系统间电信和信息交换-局域网和城域网-特定要求-第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：修改件9：与外部网络的互通”，IEEE 802.11，DO 10.1109/IEEESTD.2011.57219082011年2月<http://standards.ieee.org/getieee802/ 下载/802.11u-2011.pdf>。
[LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Work in Progress, draft-ietf-tsvwg-le-phb-02, June 2017.
[LE-PHB]Bless，R.，“较低的每跳努力行为（LE-PHB）”，正在进行的工作，草稿-ietf-tsvwg-LE-PHB-022017年6月。
[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>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 2475，DOI 10.17487/RFC2475，1998年12月<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>.
[RFC5127]Chan，K.，Babiarz，J.和F.Baker，“区分服务类的聚合”，RFC 5127，DOI 10.17487/RFC5127，2008年2月<https://www.rfc-editor.org/info/rfc5127>.
[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani, "Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN", RFC 7561, DOI 10.17487/RFC7561, June 2015, <https://www.rfc-editor.org/info/rfc7561>.
[RFC7561]Kaippallimalil，J.，Pazhyannur，R.，和P.Yegani，“代理移动IPv6（PMIPv6）和WLAN的服务质量（QoS）映射程序”，RFC 7561，DOI 10.17487/RFC7561，2015年6月<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>.
[RFC8100]Geib，R.，Ed.和D.Black，“区分服务互连类别和实践”，RFC 8100，DOI 10.17487/RFC8100，2017年3月<https://www.rfc-editor.org/info/rfc8100>.
Acknowledgements
致谢
The authors wish to thank David Black, Gorry Fairhurst, Ruediger Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, David Benham, and the TSVWG.
作者希望感谢大卫·布莱克、戈里·费尔赫斯特、鲁迪格·盖布、文森特·罗卡、布赖恩·卡彭特、大卫·布莱克、卡伦·詹宁斯、大卫·本汉姆和TSVWG。
The authors also acknowledge a great many inputs, notably from David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, Ramachandra Murthy, and many others.
作者还感谢了大量的投入，特别是来自大卫·克洛普、马克·蒙塔内兹、格伦·拉维斯、迈克尔·芬格尔顿、萨拉夫·拉德哈克里希南、卡提克·达奇纳莫沃斯、西蒙娜·阿雷纳、兰加·马拉埃、拉玛钱德拉·穆尔西和其他许多人的投入。
Authors' Addresses
作者地址
Tim Szigeti Cisco Systems Vancouver, British Columbia V6K 3L4 Canada
Tim Szigeti思科系统加拿大不列颠哥伦比亚省温哥华V6K 3L4
Email: szigeti@cisco.com
Email: szigeti@cisco.com
Jerome Henry Cisco Systems Research Triangle Park, North Carolina 27709 United States of America
美国北卡罗来纳州Jerome Henry Cisco系统研究三角园27709
Email: jerhenry@cisco.com
Email: jerhenry@cisco.com
Fred Baker Santa Barbara, California 93117 United States of America
加利福尼亚州圣巴巴拉市弗雷德·贝克93117美利坚合众国
Email: FredBaker.IETF@gmail.com
Email: FredBaker.IETF@gmail.com