[要約] RFC 8325は、DiffservとIEEE 802.11のマッピングに関するガイドラインを提供するものであり、無線ネットワークにおけるトラフィックの品質を向上させることを目的としています。
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
IEEE 802.11へのDiffservのマッピング
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）を調整することが重要です。ただし、デフォルトでは常にそうであるとは限りません。このドキュメントでは、Differentiated Services Code Point（DSCP）からIEEE 802.11ユーザー優先度（UP）への一連のマッピングを指定して、IETFとIEEEによって提供されるマーキングの推奨事項を調整し、有線ネットワークとIEEE 802.11ワイヤレスネットワーク間で一貫したQoS処理を維持します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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はDiffservアーキテクチャを定義しています。
RFC 3246 Specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB).
RFC 3246は、Expedited Forwarding（EF）Per-Hop Behavior（PHB）を指定しています。
RFC 2597 Specifies the Assured Forwarding (AF) PHB.
RFC 2597は、Assured Forwarding（AF）PHBを指定しています。
RFC 3662 Specifies a Lower-Effort Per-Domain Behavior (PDB).
RFC 3662は、ドメインごとの動作（PDB）を削減することを規定しています。
RFC 4594 Presents configuration guidelines for Diffserv service classes.
RFC 4594は、Diffservサービスクラスの構成ガイドラインを示しています。
RFC 5127 Presents the aggregation of Diffserv service classes.
RFC 5127は、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]は、ワイヤレスネットワークを含む任意のネットワークでDiffservをサポートするためのフレームワークと見なされることを意図しています。したがって、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.
IPパケット交換（IPX）のDSCPからUPへのマッピングに関するモバイルシステムのグローバルシステム（GSMA）からの推奨、特にIPXプロバイダーネットワークのガイドライン[GSMA-IPX_Guidelines]もあります。これらのGSMAガイドラインは、セクション1.1で参照されているさまざまなサービスの既存のIETF仕様を参照せずに作成されました。次に、[RFC7561]はこれらのGSMAガイドラインに基づいて作成され、[RFC7561]、セクション4.2で明示的に呼び出されました。したがって、[RFC7561]は、指定されたサービスとそれらに指定されたコードポイントの両方で、Diffservトラフィック調整サービス計画全体と競合します。そのため、これら2つのプランは正規化できません。むしろ、[RFC2474]のセクション2で説明されているように、2つのドメイン（IEEE 802.11とGSMA）は、Differentiated Services Boundaryによって分離された別のDifferentiated Services Domainsです。その境界では、あるドメインのコードポイントが別のドメインのコードポイントに変換されます。対応するサービスがない場合はデフォルト（ゼロ）に変換されます。
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ワイヤレスLAN（このドキュメントでは、簡単にするために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間ワイヤレスネットワークも含まれます。
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からUPへのマッピング、UPから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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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：アクセスカテゴリ。特定の優先順位でメディアアクセス制御（MAC）サービスデータユニット（MSDU）を送信するためにチャネルを争うためにQoSステーション（STA）で使用される拡張分散チャネルアクセス（EDCA）パラメーターの共通セットのラベル。 [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：アクセスポイント。 1つのステーション（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.
BSS：基本サービスセット。非公式には、無線セル。正式には、JOINサービスプリミティブを使用して正常に同期したステーションのセットと、STARTプリミティブを使用した1つのSTA。または、STARTプリミティブを使用して、一致するメッシュプロファイルを指定した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.
CW：コンテンションウィンドウ。ランダムバックオフが計算される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.
DCF：分散調整機能。ネットワークが動作しているときはいつでも、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 Type of Service（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.
HCF：ハイブリッド調整機能。コンテンションベースおよびコンテンションフリーのアクセス方法の側面を組み合わせて強化し、QoSステーション（STA）に優先順位付けおよびパラメーター化されたWMへのQoSアクセスを提供しながら、ベストエフォート転送の非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：Interframe Space。 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 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.
ランダムバックオフタイマー：インターバル（0、CW）にわたる擬似ランダム整数期間（スロット時間の単位）。CWminはCW以下であり、CWMaxはCWMax以下です。 DCFを使用してデータフレームや管理フレームの転送を開始したいステーションは、キャリアセンスメカニズムを呼び出して、媒体のビジー状態またはアイドル状態を判断します。メディアがビジーの場合、STAは、メディアで検出された最後のフレームが正しく受信されたとき、またはメディアが中断なしでアイドルであると判断された後、DIFSと等しい期間、中断なしでメディアがアイドルであると判断されるまで待機します。メディアで検出された最後のフレームが正しく受信されなかったときのEIFSに等しい期間。このDIFSまたはEIFSのメディアアイドル時間の後、STAは送信前に追加の延期時間のランダムバックオフ期間を生成します。 [IEEE.802.11-2016]、セクション10.3.3を参照してください。
RF: Radio Frequency.
RF：無線周波数。
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マーキングの受け入れを指します。信頼は通常、（DSCPを受け入れることにより）レイヤー3で拡張されますが、UPマーキングを受け入れることで、レイヤー2などの下位層でも拡張できます。たとえば、DSCPマーキングを信頼するようにAPが構成されていて、EFとマークされたパケットを受信する場合、APはパケットをExpedite Forwarding 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 Allianceによって定義された相互運用性認定。ただし、この用語は、現在のドキュメントを含め、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は常にDiffservドメインの境界に配置される場合と配置されない場合があります。
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.
有線から無線へのエッジは、Diffservドメインまたはドメイン境界のエッジとして機能する場合と機能しない場合があることを認識することが重要です。
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はDiffservドメインのエッジだけでなく、ネットワークインフラストラクチャ自体のエッジも表します。そのため、これらの導入モデルでは、クライアントエンドポイントデバイスのみが（ネットワークインフラストラクチャデバイスはなく）アクセスポイントの下流にあります。注：このようなWi-Fi-at-the-edge導入モデルを強化するためのセキュリティの考慮事項と推奨事項については、セクション8で詳しく説明しています。これらの推奨事項には、ネットワーク制御プロトコル（この展開モデルではAPのダウンストリームでは使用されません）のUP 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 BluetoothまたはZigbeeルーターに）、ワイヤレスAPはネットワークインフラストラクチャを拡張し、したがって通常はDiffservドメインを拡張します。このような展開では、クライアントデバイスとインフラストラクチャデバイスの両方がAPのダウンストリームであることが想定される可能性があるため、セクション4.1.1で説明されているように、この展開モデルでネットワーク制御プロトコルをUP 7にマッピングすることをお勧めします。
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.
したがって、これらの2つの例からわかるように、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のリファレンス実装キューイングモデルを示しています。これは、アクセスカテゴリごとに1つずつ、4つの送信キューを示しています。
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ネットワーク機器ベンダーが、UPごと（ACごとではなく）に専用の送信キューを実装するのが一般的です。これは、優先（または厳密な優先方法）。たとえば、ベンダーは、UP 4の前にUP 5をビデオアクセスカテゴリ（AC_VI）のEDCA機能（EDCAF）を実行するハードウェアにデキューするのが一般的です。
Some of the recommendations made in Section 4 make reference to this common implementation model of queuing per UP.
セクション4で行われた推奨事項のいくつかは、UPごとのキューイングのこの一般的な実装モデルを参照しています。
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-to-UPマッピング」（より適切な用語がないため）と呼ばれ、DSCPの3つの最上位ビット（MSB）が対応する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]、Annex V Tables V-1およびV2で提供されているマッピングがありますが、これらのマッピングは例として提供されていることを明記しています（明示的な推奨事項とは対照的です）。さらに、これらのマッピングの一部は、このセクションと次のセクション（セクション2.4）で説明するように、[RFC4594]で表現されている意図と推奨事項と一致していません。
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-to-UPマッピング方法が[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）はUP 5（101）にマップされ、音声アクセスカテゴリ（AC_VO）ではなく、ビデオアクセスカテゴリ（AC_VI）で処理されます。
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_VI）ではなく、ベストエフォートアクセスカテゴリ（AC_BE）で処理されます。
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_VI）ではなく、ベストエフォートアクセスカテゴリ（AC_BE）で処理されます。
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など）をUP（つまりAC）にマッピングする方法を定義する
o define how UPs should translate to other mediums' Layer 2 QoS markings
o UPが他のメディアのレイヤー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 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.
反対方向のフロー（アップストリーム方向、つまりワイヤレスからワイヤードへ）では、多くのAPが「デフォルトのUPからDSCPへのマッピング」と呼ぶものを使用します（より適切な用語がないため）。 DSCP値は、UP値に8を掛けて（つまり、3つのUPビットを左にシフトし、さらに3つのゼロを追加してDSCP値を生成する）、UP値から派生します。この導出されたDSCP値は、ワイヤレスAPと最も近い分類およびマーキングポリシー実施ポイント（ネットワーク内の比較的深い集中型ワイヤレスLANコントローラーである場合があります）間のQoS処理に使用されます。または、他の分類およびマーキングポリシー実施ポイントがない場合、この派生した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).
言うまでもなく、マーキングの細分性の6ビットが3から派生すると、情報は変換時に失われます。 12のトラフィッククラス（[RFC4594]で推奨）に対してサービスの差別化を行うことはできませんが、8のみ（これらのクラスの1つは将来の使用のために予約されています（つまり、DSCP CS7にマップされるUP 7））。
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 UP 6（音声またはテレフォニートラフィックが含まれます。[RFC4594]を参照）をCS6にマッピングします。[RFC4594]はネットワーク制御に推奨しています。
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 UP4（マルチメディア会議および/またはリアルタイムインタラクティブトラフィックを含む、[RFC4594]を参照）をCS4にマッピングし、[RFC4594]のセクション4.3および4.4で推奨されているように、これら2つの異なるサービスクラスを区別する機能を失う
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 UP 3（マルチメディアストリーミングやブロードキャストビデオトラフィック、またはその両方が含まれます。[RFC4594]を参照）をCS3にマッピングすることにより、[RFC4594]、セクション4.5および4.6で推奨されているように、これら2つの異なるサービスクラスを区別できなくなります。
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 UP 2（低遅延データまたはOAMトラフィック、あるいはその両方が含まれる、[RFC4594]を参照）をCS2にマッピングすることにより、[RFC4594]のセクション4.7および3.3で推奨されているように、これら2つの異なるサービスクラスを区別できなくなります。 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 UP1（高スループットデータおよび/または低優先度データトラフィックを含む、[RFC4594]を参照）をCS1にマッピングし、[RFC4594]のセクション4.8で推奨されているように、これら2つの異なるサービスクラスを区別する機能を失うおよび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からUPへのマッピングが調整され、次にアップストリーム（ワイヤレスから有線）モデルに対応します。
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や、デフォルトではないDSCPからUPへのカスタマイズ可能なマッピングスキームをサポートするWLANコントローラを想定しています。
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] APおよびエンドポイントデバイスが、セクション2.2で説明されているように、UPマーキングを対応するキューイングおよびデキューイング処理で区別することを前提としています。
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の安定した動作に不可欠なパケットフローとして定義されます。ネットワーク制御トラフィックは、一部のアプリケーションまたはサービスによって生成される可能性があるユーザーアプリケーション制御（シグナリング）とは異なります。ネットワーク制御トラフィックは、2つのサービスクラスに分割される場合があります。
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値は将来の使用のために、将来のルーティングまたは制御プロトコルのために予約する必要があります（SHOULD）」。
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にマークされたパケットは、UP 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とマークされたパケットはUP 6にマップされ、音声アクセスカテゴリ（AC_VO）内で処理されます。このようなマッピングとサービスは、[RFC4594]のセクション3.2に記載されている意図に反しています。そのため、CS6とマークされたネットワーク制御トラフィックをUP 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）には、たとえば、ネットワーク制御プロトコルがAP間で送受信されることが想定されていないWi-Fi-at-the-edge導入モデルを強化するための追加の推奨事項が含まれていますダウンストリームのクライアントエンドポイントデバイス。
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に記載されている意図に反しています。そのため、CS2 DSCPがUP 0にマッピングされるように、デフォルト以外のマッピングをOAMトラフィックに適用し、それによってベストエフォートアクセスカテゴリ（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.
ネットワーク管理者は、必要な動作のタイプに従ってアプリケーションを分類でき、定義されたサービスクラスのすべてまたはサブセットをサポートすることを選択できます（MAY）。
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 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.
テレフォニーサービスクラスは、比較的一定レートのトラフィックソース（非弾性トラフィックソース）に対してリアルタイムで非常に低い遅延、非常に低いジッター、および非常に低いパケット損失を必要とするアプリケーションに推奨されます。このサービスクラスは、IPテレフォニーサービスに使用する必要があります（SHOULD）。テレフォニーサービスクラスのトラフィックに提供される基本的なサービスは、最小限のジッター、遅延、および指定された上限までのパケット損失サービスです。 [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).
DSCP EFにマークされたトラフィックは、デフォルトで（セクション2.3で説明されているように）UP 5にマップされるため、意図されている音声アクセスカテゴリ（AC_VO）ではなく、ビデオアクセスカテゴリ（AC_VI）にマップされます。したがって、EF DSCPがUP 6にマップされるように、デフォルト以外のDSCPからUPへのマッピングを推奨し、それによって音声アクセスカテゴリ（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]で説明されているVOICE-ADMIT DSCP（10進44/2進101100）は、UP 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にマップされている）でのプロビジョニングに値しません。ただし、シグナリングトラフィックは、音声/ビデオテレフォニーオーバーレイインフラストラクチャの観点から見たコントロールプレーントラフィックです。そのため、シグナリングは、他のデータプレーンフローに対して優先的なサービスで処理する必要があります。これは、CS5とマークされたシグナリングトラフィックをUP 5にマッピングすることにより、一般的なWLAN展開で実現できます。UPごとのEDCAFキューイングロジック（セクション2.2で説明）をサポートするAPでは、シグナリングトラフィックが他のビデオフローに対して優先的に処理されます。 UP 4にマークされた同じアクセスカテゴリ（AC_VI）、およびベストエフォート（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をUP 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.
Real-Time Interactiveサービスクラスは、可変レートの非弾性トラフィックソースに低損失と低ジッター、非常に低い遅延を必要とするアプリケーションに推奨されます。このようなアプリケーションには、非弾性のビデオ会議アプリケーションが含まれる場合がありますが、ゲームアプリケーションも含まれる場合があります（[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).
通常Real-Time Interactiveサービスクラス内で伝送される主要なメディアタイプはビデオです。そのため、このクラスをビデオアクセスカテゴリ（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をUP 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.
Broadcast Videoサービスクラスは、一定速度および可変速度の非弾性トラフィックソースの非常に低いパケット損失で、ほぼリアルタイムのパケット転送を必要とするアプリケーションに推奨されます。通常、これらのフローは単方向です。 [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).
名前から直接暗示されるように、通常、Broadcast Videoサービスクラス内で伝送される主要なメディアタイプはビデオです。そのため、このクラスをビデオアクセスカテゴリ（AC_VI）にマップすることをお勧めします。ただし、デフォルトでは（セクション2.3で説明されているように）、このサービスクラスはUP 3、つまりベストエフォートアクセスカテゴリ（AC_BE）にマップされます。したがって、デフォルト以外のマッピングが推奨され、CS4がUP 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]).
Low-Latency Dataサービスクラスは、ユーザーが目前のタスクを続行するためにネットワークを介して応答を待機している、トランザクションの性質を持つ、多くの場合、柔軟で時間に敏感なデータアプリケーションに推奨されます。そのため、これらのフローはフォアグラウンドトラフィックと見なされ、そのようなトラフィックへの遅延またはドロップが直接ユーザーの生産性に影響を与えます。 [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で説明されているように）、低レイテンシデータはUP 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で説明されているように、低遅延データをUP 3にマッピングすると、ターゲットトラフィックが、ベストエフォートアクセスカテゴリ（AC_BE）のEDCAFハードウェアにサービスを提供するUPごとの送信キューを介して優れたレベルのサービスを受信できるようになります。したがって、AF2x DSCPとマークされた低遅延データトラフィックをUP 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 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]).
High-Throughput Dataサービスクラスは、可変レートのトラフィックソースのタイムリーなパケット転送を必要とする弾性アプリケーションに推奨され、具体的には、TCPのより長寿命のフローに効率的であるが制約された（必要な場合）スループットを提供するように構成されています。これらのフローは通常、ユーザーインタラクティブではありません。 [RFC4594]のセクション4.8によると、このクラスは使用可能な帯域幅を消費し、輻輳したリンクを通過するパケットは、より大きなキューイング遅延またはパケット損失を経験する可能性があると想定できます。このトラフィックは弾力性があり、パケット損失に動的に応答することも想定されています。 [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で説明されているように）、ハイスループットデータはUP 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]モデル内のハイスループットデータサービスクラスに直接対応する適合はないため、通常、ハイスループットデータをUP 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ネットワークドメインでサポートされている他の転送サービスクラスのいずれにも分類されていないトラフィックに推奨されます。このサービスクラスは、インターネットの「ベストエフォート」転送動作を提供します。 [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とマークされた標準サービスクラストラフィックをUP 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は、[IEEE.802.11-2016] UPにマッピングされた[RFC4594] DSCPマーキングの推奨事項と、ダウンストリーム方向（有線から無線ネットワークへ）に適用されるアクセスカテゴリをまとめたものです。
+-------------------------------------------------------------------+
| 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 | | | | |
+--------------------------------------------------------------------+
Note: All unused codepoints are RECOMMENDED to be mapped to UP 0 (See Security Considerations below)
注：未使用のコードポイントはすべて、UP 0にマップすることをお勧めします（以下のセキュリティに関する考慮事項を参照）。
Figure 1: Summary of Mapping Recommendations from Downstream DSCP to IEEE 802.11 UP and AC
図1：ダウンストリームDSCPからIEEE 802.11 UPおよびACへの推奨マッピングの概要
In the upstream direction (i.e., wireless-to-wired), there are three types of mapping that may be implemented:
アップストリーム方向（つまり、ワイヤレスからワイヤードへ）では、3つのタイプのマッピングを実装できます。
o DSCP-to-UP mapping within the wireless client operating system, and
o ワイヤレスクライアントオペレーティングシステム内のDSCP-to-UPマッピング、および
o UP-to-DSCP mapping at the wireless AP, or
o ワイヤレスAPでのUPから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.
後者の2つのオプションの代わりに、ネットワーク管理者は、無線から有線へのエッジをDiffserv境界として使用し、管理ポリシーに従ってDSCPマーキングを明示的に設定（またはリセット）することを選択して、ワイヤレスエッジをDiffservポリシーの実施にすることができます（MAY）。ポイント;このアプローチは、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-to-UPマッピング
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-to-UPマッピングスキームを使用します。そのため、このセクションで説明されているのと同じ競合が発生する可能性がありますが、上流方向です。
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-to-UPマッピングの推奨事項を代わりに利用することをお勧めします。 CS6またはCS7 DSCPのマーキングを要求するパケットは（UP 7ではなく）UP 0にマッピングする必要があります（SHOULD）。さらに、このような場合、ワイヤレスクライアントのオペレーティングシステムは、そのようなパケットをDSCP 0に再マーキングする必要があります。これは、CS6およびCS7 DSCP、およびUP 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.
UP-to-DSCPマッピングは、IPパケットのDSCP値を生成します（カプセル化されていないIPパケット、またはワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）などのトンネリングプロトコル内にカプセル化され、ワイヤレスLANコントローラー宛てのIPパケット）。カプセル化解除と転送用）レイヤ2 [IEEE.802.11-2016] UPマーキングから。これは通常、セクション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 At the wired network switch port, and/or
oワイヤレスAP、および/またはo有線ネットワークスイッチポート、および/または
o At the wireless LAN controller
o ワイヤレスLANコントローラで
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).
したがって、UP-to-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]仕様のどこにも、有線IPネットワーク上のQoS処理に影響を与えるために使用されるUPマーキングの意図が示されていません。さらに、[RFC2474]、[RFC2475]、および[RFC8100]はすべて、ホストがIPネットワークを介したエンドツーエンドのQoS処理のためのDSCPマーキングを設定できるようにします。したがって、ワイヤレスAPは、ワイヤレスホストによって設定されたレイヤ2 [IEEE.802.11-2016] UPマーキングを利用してはならず、その後、アップストリーム方向でUP-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] UPマーキング）を通過させることをお勧めします。以下で説明するように、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処理に影響を与えるためにUPマーキングが使用されることを指定していません
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で説明されているのと同じ方法で（つまり、カプセル化された6ビットDSCPの3つのMSBを使用して）UP値を生成します。次に、APでこれらの3ビットマーキングは、通常2.4で説明されているデフォルトの方法で、DSCP値に変換されます。そのため、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を参照）、これら2つのマーキングのあるトラフィックは有線ネットワークの動作に脅威をもたらすためです（セクション8.2を参照）。 CS6とCS7は、APがネットワーク管理者またはオペレーターによって特別に構成されていない限り、アップストリーム方向の有線ネットワークにパススルーされるべきではありません（SHOULD NOT）。
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ネットワーク全体でDiffservポリシーを直接適用するため（アプリケーション開発者やワイヤレスエンドポイントデバイスのオペレーティングシステムの開発者ではなく）、ネットワーク管理者から完全に独立して機能していること）。
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）を使用してワイヤレスネットワークで有効になります。 QoSを有効にするHCFの機能強化に適切なコンテキストを提供するには、最初の分散調整機能（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を含む）はメディアに関して同等の条件で競合しています。そのため、2つ（またはそれ以上）のステーションが同時送信を試みるときに発生する可能性がある衝突を防止（または回避）するメカニズムを必要とする他の共有メディアと同じ課題を共有します。
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.
ただし、イーサネット（物理ケーブルを使用）とは異なり、RFエネルギーは空中に放射され、衝突するバーストが必ずしも送信ステーションに反射されるとは限らないため、無線媒体で直接衝突を検出することはできません。したがって、この媒体には別のメカニズムが必要です。
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は、タイマーベースのシステムであり、スロット時間、フレーム間スペース、CWの3つの主要なタイマーセットを利用します。
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をサポート）のスロット時間を20マイクロ秒（[IEEE.802.11-2016]、表15-5）に指定します。 11 Mbpsのデータレート）、新しい実装（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）と呼ばれます。いくつかのIFSが[IEEE.802.11-2016]で定義されており、DCFに最も関連するのは、Short Interframe Space（SIFS）、DCF Interframe Space（DIFS）、およびExtended Interframe Space（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]で指定）を処理し、応答フレームを生成するのに必要な時間（マイクロ秒）です。スロット時間と同様に、SIFSは[IEEE.802.11-2016]のパフォーマンス実装に応じて変化する可能性があります。 IEEE 802.11a、802.11n、および802.11ac（5 GHz）のSIFSは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間隔の間アイドルであることが判明するまで、その送信を延期する必要があります。 DIFSは次のように計算されます。
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.
ただし、すべてのステーションが送信を試行する前に一定時間だけ待機した場合、衝突が頻繁になります。これを相殺するには、各ステーションは、固定された時間（DIFS）だけでなく、送信前にランダムな時間（ランダムなバックオフ）も待機する必要があります。生成されるランダムバックオフタイマーの範囲は、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).
コンテンションウィンドウは、送信を試行する前に各ステーションが（DIFSに加えて）待機する必要がある生成されたランダムバックオフタイマーの範囲を制限しました。初期範囲は、0からCW最小値（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 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).
ただし、2つ（またはそれ以上）のステーションが偶然にこの範囲内でまったく同じランダム値を選択する可能性があります。これが発生すると、衝突が発生する可能性があります。この時点で、ステーションは事実上プロセスを再び開始し、DIFSを待機して、新しいランダムバックオフ値を生成します。ただし、重要な違いは、この後続の試行では、CWのサイズが約2倍になることです（したがって、ランダム値の範囲が指数関数的に増加します）。このプロセスは、最大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 msのジッターになる可能性があります。また、前述のように、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年にQoSをサポートするようにDCFを拡張し、2007年に主要なIEEE 802.11標準に統合されたIEEE 802.11でHCFを指定しました。
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]のフレーム形式に対する主な変更点の1つは、QoSマーキング専用の3ビットのQoS制御フィールドを含めることです。これらのビットはユーザー優先度（UP）ビットと呼ばれ、8つの異なるマーキング値（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]からのアクセスカテゴリー（AC）へのUPマーキングの構成不可能で標準仕様のマッピングです。
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).
UP値のペアは4つの定義されたアクセスカテゴリにマップされ、対応する無線でのフレームの異なる処理を指定します。これらのアクセスカテゴリ（上から下への相対的な優先順位の順）とそれに対応するUPマッピングを図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 |
+-----------------------------------------+
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.
これらの4つのアクセスカテゴリが無線で差別化されたサービスを実現する方法は、次に説明するように、ステーションがそれぞれのタイプのトラフィックを送信する前に待機する固定タイマーとランダムタイマーを調整することです。
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では、DIFSはすべてのタイプのトラフィックに対して一定です。ただし、[IEEE.802.11-2016]では、ステーションが待機する必要のある固定時間はアクセスカテゴリに依存し、アービトレーションインターフレームスペース（AIFS）と呼ばれます。 AIFSはスロット時間で定義され、アクセスカテゴリごとのAIFSが図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 |
+------------+-----------------+------------+
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).
図4に示すように、ステーションが[IEEE.802.11-2016]アクセスカテゴリに応じて待機する必要がある固定時間だけでなく、ランダムバックオフタイマーをバインドするCWの相対的なサイズも異なります（ [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 |
+-----------+-----------------+------------+------------+
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).
固定およびランダムに生成されたタイマーがアクセスカテゴリごとに追加されると、音声アクセスカテゴリに割り当てられたトラフィック（つまり、UP 6または7にマークされたトラフィック）は、ビデオアクセスカテゴリ（つまり、UP 5および4とマークされたトラフィック）。これは、ベストエフォートアクセスカテゴリトラフィック（つまり、UP 3および0とマークされたトラフィック）に割り当てられたトラフィックと比較して、統計的に優れたサービスを受け取ります。バックグラウンドアクセスカテゴリトラフィックに割り当てられたトラフィック（つまり、UP 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マッピングとの間のDSCPマッピング。具体的には、QoSマップセット情報要素（[IEEE.802.11-2016]、セクション9.4.2.95で説明され、一般に「QoSマップ要素」と呼ばれます）がAPからアソシエーション内のワイヤレスエンドポイントデバイスに送信されます。再関連付け応答フレーム（または特別なQoSマップ構成フレーム内）。
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-to-UPマッピングを実行することが意図されます。ネットワークインターフェイスハードウェアドライバー）を使用して、APがダウンストリーム方向にマッピングしているものに合わせ、両方向で一貫したエンドツーエンドQoSを実現します。
The QoS Map element includes two key components:
QoSマップ要素には、次の2つの主要コンポーネントが含まれています。
1) each of the eight UP values (0-7) is associated with a range of DSCP values, and
1）8つのUP値（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からUPへの、またはUPへのマッピングアソシエーションからの例外は、オプションで明示的に指定できます。
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）8つのUP値（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がDiffservドメインのエッジであるネットワークのモデルです。 APがIEEE 802.11メディアを介して他のAPとインフラストラクチャデバイスを接続することによりDiffservドメインを拡張するネットワークは、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やUP 0に再マーキングされます）。さらに、セクション5.3では、許可されていないデバイスや認証されていないデバイスからのDSCPマーキングを通過させることは一般に推奨されないことを明確にしました。これは特に、何百億ものデバイスがセキュリティ機能がほとんどまたはまったくないIPネットワークに接続されているため、DDoS攻撃のエージェントとして利用される脆弱性を残したまま、モノのインターネット（IoT）の展開に関連しています。これらの攻撃は、そのようなデバイスのパケットマーキングが信頼できる場合、優先的なQoS処理で増幅できます。
o Policing EF marked packet flows, as detailed in [RFC2474], Section 7, and [RFC3246], Section 3.
o [RFC2474]、セクション7、および[RFC3246]、セクション3で説明されているように、EFマーク付きパケットフローのポリシング。
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.
エンドポイントデバイスがネットワークと完全に平等な基準で共有メディアをめぐって競合するため（APで代表されるように）、ワイヤレスLANは独自のDoS攻撃ベクトルを提示します。これは、どのワイヤレスクライアントも、優先UP値（つまり、UP値4〜7）にマークされたパケットをアップストリーム方向に送信することにより、空気を独占する可能性があることを意味します。同様に、過剰な量のダウンストリームトラフィックがこれらの同じ優先UP値にマーク/マッピングされた場合、通信時間を独占することができます。そのため、これらの推奨UP値（UP 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 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 DSCPとマークされたトラフィックをダウンストリームにフラッディングして、WLAN DoSを引き起こす可能性があります。このコードポイントは、デフォルトで（セクション2.3で説明されているように）UP 7にマップされ、音声アクセスカテゴリ（AC_VO）に割り当てられます。このようなフラッドにより、サービス拒否がワイヤレス音声アプリケーションだけでなく、他のすべてのトラフィッククラスにも発生する可能性があります。同様に、情報のないアプリケーション開発者は、自分のアプリケーションからのすべてのトラフィックにCS7またはCS6のマークを付けるように要求できます。これにより、アプリケーショントラフィックの全体的なサービスが最適になると考えられますが、そのようなマークは実現されません（クライアントのオペレーティングシステムが認める場合）。 CS7またはCS6とマークされたトラフィックがサービス（比較的低帯域幅）のネットワーク制御プロトコルを処理するために意図されたキューに入り、プロセス内の正当なネットワーク制御プロトコルを枯渇させる可能性があるため、WLAN DoSだけでなくIPネットワークの不安定性も引き起こす可能性があります。
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コードポイントにマークされたすべてのパケットをUP 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.
未使用のコードポイントをUP 0にマッピングするこのようなポリシーは、非標準のコードポイントを使用してWLAN DoSを引き起こす攻撃も防止します。コードポイントが範囲関数を使用してUP値にマッピングされる場合（たとえば、DSCP値48〜55がすべてUP 6にマッピングされる）を検討すると、攻撃者は、アップストリームまたはダウンストリームのいずれかで、DSCP 49などにマークされたパケットをフラッディングする可能性があります。 WLANを介した方向付けにより、プロセス内の他のすべてのトラフィッククラスに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はDiffservドメインのエッジだけでなく、ネットワークインフラストラクチャ自体のエッジも表します。つまり、ワイヤレスクライアントエンドポイントデバイスのみがAPのダウンストリームにあります。このような配置モデルでは、CS6とCS7は、ワイヤレスLANで使用されていないコードポイントのカテゴリにも分類されます（ワイヤレスクライアントエンドポイントデバイスのみがこのモデルのAPの下流にあり、これらのデバイスは（正当に）参加しないためネットワーク制御プロトコル交換）。そのため、これらのWi-Fi-at-the-edge導入モデルでは、CS6およびCS7 DSCPをUP 0にマッピングすることをお勧めします。そうしないと、悪意のあるアプリケーション開発者や、誤ってプログラムされたIoTデバイスでも、CS6 DSCPとマークされたトラフィックをフラッディングすることにより、WLAN DoSや有線IPネットワークを不安定にしてしまう可能性があります。 、UP 6にマッピングされ、WLAN上の他のすべてのトラフィッククラスが不足し、ルーティングプロトコルのサービスを目的とした有線IPネットワーク上のキューがハイジャックされます。この時点まで、5.1節では、CS6またはCS7 DSCPのマーキングを要求するパケットをDSCP 0に再マーキングし、無線クライアントオペレーティングシステムによってUP 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 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を展開する有線ネットワークとワイヤレスネットワークの両方のセキュリティリスクを軽減するのにさらに役立つメカニズムには、強力なデバイス認証またはユーザー認証（あるいはその両方）、アクセス制御、レート制限、コントロールプレーンポリシング、暗号化、およびその他の技術が含まれます。ただし、このようなメカニズムの実装に関する推奨事項は、このドキュメントで詳しく説明する範囲を超えています。有線ネットワークと無線ネットワーク間の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：ワイヤレスLANのメディアアクセス制御（MAC）および物理層（PHY）の仕様"、IEEE 802.11、DOI 10.1109 / IEEESTD.2016.7786995、2016年12月、<https://standards.ieee.org/findstds/standard/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]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（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、「Assured Forwarding PHB Group」、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]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「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]デイビー、B、チャーニー、A、ベネット、J、ベンソン、K、ルブーデック、J、コートニー、W、ダヴァリ、S、フィロイ、V、およびDスティリアディス、 Expedited Forwarding PHB（Per-Hop Behavior）」、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、「Differentiated Servicesのドメインごとの動作（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、「DiffServサービスクラスの構成ガイドライン」、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]ベイカー、F。、ポーク、J。、およびM.ドリー、「Capacity-Admitted TrafficのDiffServコードポイント（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_Guidelines] GSMアソシエーション、「IPXプロバイダーネットワークのガイドライン（以前のサービス間プロバイダーIPバックボーンガイドライン）バージョン11.0」、公式ドキュメントIR.34、2014年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 Standard for Information technology-Telecommunications and information exchange between system-Local and Metropolitan Area Networks-Specific requirements-Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY ）仕様：改訂9：外部ネットワークとの相互接続」、IEEE 802.11、DO 10.1109 / IEEESTD.2011.5721908、2011年2月、<http://standards.ieee.org/getieee802/download/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]ブレス、R。、「低ホップのパーホップ動作（LE PHB）」、作業中、draft-ietf-tsvwg-le-phb-02、2017年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.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<https://www.rfc-editor.org/info/rfc2475>。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <https://www.rfc-editor.org/info/rfc5127>.
[RFC5127] Chan、K.、Babiarz、J。、およびF. Baker、「Aggregation of Diffserv Service Classes」、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]ガイブ、R。、エド。 D. Black、「Diffserv-Interconnection Classes and Practice」、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.
著者は、David Black、Gorry Fairhurst、Ruediger Geib、Vincent Roca、Brian Carpenter、David Blake、Cullen Jennings、David Benham、および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.
著者はまた、特にDavid Kloper、Mark Montanez、Glen Lavers、Michael Fingleton、Sarav Radhakrishnan、Karthik Dakshinamoorthy、Simone Arena、Ranga Marathe、Ramachandra Murthy、その他の多くからの非常に多くの入力を認めています。
Authors' Addresses
著者のアドレス
Tim Szigeti Cisco Systems Vancouver, British Columbia V6K 3L4 Canada
Tim Island Cisco Systemsバンクーバー、ブリティッシュコロンビアV6K 3L4カナダ
Email: szigeti@cisco.com
Jerome Henry Cisco Systems Research Triangle Park, North Carolina 27709 United States of America
ジェロームヘンリーシスコシステムズリサーチトライアングルパーク、ノースカロライナ州27709アメリカ合衆国
Email: jerhenry@cisco.com
Fred Baker Santa Barbara, California 93117 United States of America
フレッドベイカーサンタバーバラ、カリフォルニア93117アメリカ合衆国
Email: FredBaker.IETF@gmail.com