[要約] RFC 7561は、Proxy Mobile IPv6（PMIPv6）とWLANの品質サービス（QoS）手順のマッピングに関するものです。このRFCの目的は、PMIPv6とWLANの統合におけるQoSの実装と相互運用性を向上させることです。
Internet Engineering Task Force (IETF) J. Kaippallimalil
Request for Comments: 7561 Huawei
Category: Informational R. Pazhyannur
ISSN: 2070-1721 Cisco
P. Yegani
Juniper
June 2015
Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN
プロキシモバイルIPv6（PMIPv6）およびWLANのサービス品質（QoS）手順のマッピング
Abstract
概要
This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.
このドキュメントでは、アクセスネットワークがIEEE 802.11に基づいているプロキシモバイルIPv6（PMIPv6）ドメインでエンドツーエンドのサービス品質（QoS）を達成するためのガイドラインを提供します。 RFC 7222は、PMIPv6モビリティドメイン内のモバイルアクセスゲートウェイ（MAG）とローカルモビリティアンカー（LMA）間のQoSネゴシエーションについて説明しています。ネゴシエートされたQoSパラメータは、パケットのQoSポリシングとマーキングに使用して、MAGとLMA間のパスにQoSの差別化を適用できます。 IEEE 802.11およびWi-Fiマルチメディア-アドミッションコントロール（WMM-AC）では、Wi-Fiステーション（PMIPv6用語ではMN）とアクセスポイント間のQoSネゴシエーションの方法について説明しています。このドキュメントでは、上記の2組のQoS手順と関連するQoSパラメータの間のマッピングについて説明します。このドキュメントは、エンドツーエンドQoSの実装を可能にするためにRFC 7222の関連ドキュメントとして使用することを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7561.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7561で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 7
3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 . . . . 7
3.1. MN-Initiated QoS Service Request . . . . . . . . . . . . 8
3.1.1. MN-Initiated QoS Reservation Request . . . . . . . . 8
3.1.2. MN-Initiated QoS De-allocation Request . . . . . . . 11
3.2. LMA-Initiated QoS Service Request . . . . . . . . . . . . 12
3.2.1. LMA-Initiated QoS Reservation Request . . . . . . . . 12
3.2.2. Discussion on QoS Request Handling with IEEE 802.11aa 13
3.2.3. LMA-Initiated QoS De-allocation Request . . . . . . . 14
4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters . . 15
4.1. Connection Parameters . . . . . . . . . . . . . . . . . . 15
4.2. QoS Class . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. LMA-Initiated QoS Service Flow with IEEE 802.11aa . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
PMIPv6 QoS [1] describes an access-network-independent way to negotiate Quality of Service (QoS) for Proxy Mobile IPv6 (PMIPv6) mobility sessions. IEEE 802.11, Wi-Fi Multimedia (WMM), and Wi-Fi Multimedia - Admission Control (WMM-AC) describe ways to provide QoS for Wi-Fi traffic between the Wi-Fi Station (STA) and Access Point (AP). This document describes how QoS can be implemented in a network where the access network is based on IEEE 802.11 (Wi-Fi). It requires a mapping between QoS procedures and information elements in two segments: 1) the Wi-Fi segment and 2) the PMIPv6 segment. (See Figure 1.) The recommendations here allow for dynamic QoS policy information per Mobile Node (MN) and session to be configured by the IEEE 802.11 access network. PMIPv6 QoS signaling between the Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) provisions the per-MN QoS policies in the MAG. Further details on policy configuration and the Policy Control Function (PCF) can be found in [1], Section 6.1. In the IEEE 802.11 access network modeled here, the MAG is located at the AP / Wireless LAN Controller (WLC). Figure 1 below provides an overview of the entities and protocols.
PMIPv6 QoS [1]は、プロキシモバイルIPv6（PMIPv6）モビリティセッションのサービス品質（QoS）をネゴシエートするためのアクセスネットワークに依存しない方法について説明しています。 IEEE 802.11、Wi-Fi Multimedia（WMM）、およびWi-Fi Multimedia-Admission Control（WMM-AC）では、Wi-Fiステーション（STA）とアクセスポイント（AP）間のWi-FiトラフィックにQoSを提供する方法について説明しています。このドキュメントでは、アクセスネットワークがIEEE 802.11（Wi-Fi）に基づいているネットワークでQoSを実装する方法について説明します。 QoSプロシージャと2つのセグメントの情報要素間のマッピングが必要です。1）Wi-Fiセグメントと2）PMIPv6セグメントです。 （図1を参照してください。）ここでの推奨事項により、モバイルノード（MN）およびセッションごとの動的QoSポリシー情報をIEEE 802.11アクセスネットワークで構成できます。モバイルアクセスゲートウェイ（MAG）とローカルモビリティアンカー（LMA）の間のPMIPv6 QoSシグナリングは、MAGにMNごとのQoSポリシーをプロビジョニングします。ポリシー構成とポリシー制御機能（PCF）の詳細については、[1]のセクション6.1を参照してください。ここでモデル化されたIEEE 802.11アクセスネットワークでは、MAGはAP /ワイヤレスLANコントローラー（WLC）にあります。下の図1は、エンティティとプロトコルの概要を示しています。
+-----+ +-------+
| AAA | | PCF |
+--+--+ +---+---+
| |
| |
+----+ +--+--------+ +---+---+
| | IEEE 802.11, WMM-AC |+-++ +---+| PMIPv6 | |
| MN <---------------------->|AP+--+MAG|<==========> LMA |
| | (ADDTS, DELTS) |+--+ +---+| QoS | |
+----+ +-----------+ +-------+
Figure 1: End-to-End QoS in Networks with IEEE 802.11 Access
図1：IEEE 802.11アクセスのネットワークにおけるエンドツーエンドQoS
The MN and Access Point (AP) use IEEE 802.11 QoS mechanisms to set up QoS flows in the Wi-Fi segment. The MAG and LMA set up QoS flows using PMIPv6 QoS procedures. The protocols and mechanisms between the AP and MAG are outside the scope of this document. Some implementations may have the AP and MAG in the same network node. However, this document does not exclude various deployments including those in which the AP and WLC are separate nodes or in which the MAG control and data planes are separate.
MNとアクセスポイント（AP）は、IEEE 802.11 QoSメカニズムを使用して、Wi-FiセグメントにQoSフローをセットアップします。 MAGおよびLMAは、PMIPv6 QoS手順を使用してQoSフローをセットアップします。 APとMAG間のプロトコルとメカニズムは、このドキュメントの範囲外です。一部の実装では、APとMAGが同じネットワークノードにある場合があります。ただし、このドキュメントでは、APとWLCが別々のノードである場合や、MAGコントロールプレーンとデータプレーンが別々である場合など、さまざまな展開を除外していません。
The recommendations in this document use IEEE 802.11 QoS and PMIPv6 QoS mechanisms [1]. State machines for QoS policy setup in IEEE 802.11 and PMIPv6 operate differently. Guidelines for installing QoS in the MN using IEEE 802.11 and PMIPv6 segments and for mapping parameters between them are outlined below.
このドキュメントの推奨事項では、IEEE 802.11 QoSおよびPMIPv6 QoSメカニズムを使用しています[1]。 IEEE 802.11とPMIPv6でQoSポリシーを設定するためのステートマシンは、動作が異なります。 IEEE 802.11およびPMIPv6セグメントを使用してMNにQoSをインストールするためのガイドラインと、それらの間のパラメーターのマッピングに関するガイドラインを以下に示します。
- Procedure Mapping:
- プロシージャのマッピング：
PMIPv6-defined procedures for QoS setup, as specified in [1], may be triggered by the LMA or MAG. IEEE 802.11 QoS setup, on the other hand, is always triggered by the MN (IEEE 802.11 QoS Station (QSTA)). The end-to-end QoS setup across these network segments should accommodate QoS that is triggered by the network or by the end user.
[1]で指定されているQoSセットアップのPMIPv6で定義された手順は、LMAまたはMAGによってトリガーされます。一方、IEEE 802.11 QoSセットアップは、常にMN（IEEE 802.11 QoS Station（QSTA））によってトリガーされます。これらのネットワークセグメントにわたるエンドツーエンドのQoS設定は、ネットワークまたはエンドユーザーによってトリガーされるQoSに対応する必要があります。
- Parameter Mapping:
- パラメータマッピング：
There is no systematic method of mapping of specific parameters between PMIPv6 QoS parameters and IEEE 802.11 QoS. For example, parameters like Allocation and Retention Priority (AARP) in PMIPv6 QoS have no equivalent in IEEE 802.11.
PMIPv6 QoSパラメータとIEEE 802.11 QoSの間で特定のパラメータをマッピングする体系的な方法はありません。たとえば、PMIPv6 QoSのAllocation and Retention Priority（AARP）のようなパラメータは、IEEE 802.11では同等ではありません。
The primary emphasis of this specification is to handle the interworking between WMM-AC signaling/procedures and PMIPv6 QoS signaling/procedures. When the client does not support WMM-AC, then the AP/MAG uses the connection mapping in Table 2 and DSCP-to-AC mapping as shown in Table 3.
この仕様の主な重点は、WMM-ACシグナリング/手順とPMIPv6 QoSシグナリング/手順の間のインターワーキングを処理することです。クライアントがWMM-ACをサポートしていない場合、AP / MAGは、表2の接続マッピングと、表3に示すDSCP-to-ACマッピングを使用します。
The rest of the document is organized as follows. Section 2 provides an overview of IEEE 802.11 QoS. Section 3 describes a mapping of QoS signaling procedures between IEEE 802.11 and PMIPv6. The mapping of parameters between IEEE 802.11 and PMIPv6 QoS is described in Section 4.
ドキュメントの残りの部分は次のように構成されています。セクション2では、IEEE 802.11 QoSの概要を説明します。セクション3では、IEEE 802.11とPMIPv6間のQoSシグナリング手順のマッピングについて説明します。 IEEE 802.11とPMIPv6 QoSの間のパラメータのマッピングについては、セクション4で説明します。
AAA Authentication, Authorization, and Accounting AARP Allocation and Retention Priority AC Access Category ADDTS ADD Traffic Stream AIFS Arbitration Inter-Frame Space ALG Application Layer Gateway AMBR Aggregate Maximum Bit Rate AP Access Point CW Contention Window DELTS DELete Traffic Stream DL DownLink DSCP Differentiated Services Code Point DPI Deep Packet Inspection EDCA Enhanced Distributed Channel Access EPC Evolved Packet Core GBR Guaranteed Bit Rate MAC Media Access Control MAG Mobile Access Gateway MBR Maximum Bit Rate MN Mobile Node MSDU Media Access Control Service Data Unit PBA Proxy Binding Acknowledgement PBU Proxy Binding Update PCF Policy Control Function PHY Physical Layer QCI QoS Class Identifier QoS Quality of Service QSTA QoS Station SIP Session Initiation Protocol STA Station TC Traffic Class TCLAS Type Classification TCP Transmission Control Protocol TS Traffic Stream TSPEC Traffic Conditioning Specification UDP User Datagram Protocol UL UpLink UP User Priority WLAN Wireless Local Area Network WLC Wireless Controller WMM Wi-Fi MultiMedia WMM-AC Wi-Fi MultiMedia Admission Control
AAA認証、承認、アカウンティングAARP割り当てと保持の優先度ACアクセスカテゴリADDTS ADDトラフィックストリームAIFSアービトレーションフレーム間スペースALGアプリケーションレイヤーゲートウェイAMBR集約最大ビットレートAPアクセスポイントCWコンテンションウィンドウDELTS DELeteトラフィックストリームDL DownLink DSCP差別化サービスコードポイントDPIディープパケットインスペクションEDCA拡張分散チャネルアクセスEPC進化型パケットコアGBR保証ビットレートMACメディアアクセスコントロールMAGモバイルアクセスゲートウェイMBR最大ビットレートMNモバイルノードMSDUメディアアクセスコントロールサービスデータユニットPBAプロキシバインディング確認PBUプロキシバインディングアップデートPCFポリシー制御機能PHY物理層QCI QoSクラス識別子QoSサービス品質QSTA QoSステーションSIPセッション開始プロトコルSTAステーションTCトラフィッククラスTCLASタイプ分類TCP伝送制御プロトコルTSトラフィックストリームTSPECトラフィック条件仕様UDPユーザーデータグラムプロトコルULアップリンクUPユーザー優先度W LANワイヤレスローカルエリアネットワークWLCワイヤレスコントローラーWMM Wi-FiマルチメディアWMM-AC Wi-Fiマルチメディアアドミッションコントロール
Peak Data Rate
ピークデータレート
In WMM-AC, Peak Data Rate specifies the maximum data rate in bits per second. The Maximum Data Rate does not include the MAC and PHY overheads [4]. Data rate includes the transport of the IP packet and header.
WMM-ACでは、ピークデータレートは最大データレートをビット/秒で指定します。最大データレートには、MACおよびPHYオーバーヘッドは含まれません[4]。データレートには、IPパケットとヘッダーの転送が含まれます。
TSPECs for both uplink and downlink may contain Peak Data Rate.
アップリンクとダウンリンクの両方のTSPECには、ピークデータレートが含まれる場合があります。
Mean Data Rate
平均データレート
This is the average data rate in bits per second. The Mean Data Rate does not include the MAC and PHY overheads [4]. Data rate includes the transport of the IP packet and header.
これは、ビット/秒の平均データレートです。平均データレートには、MACおよびPHYのオーバーヘッドは含まれません[4]。データレートには、IPパケットとヘッダーの転送が含まれます。
TSPECs for both uplink and downlink must contain the Mean Data Rate.
アップリンクとダウンリンクの両方のTSPECには、平均データレートが含まれている必要があります。
Minimum Data Rate
最小データレート
In WMM-AC, Minimum Data Rate specifies the minimum data rate in bits per second. The Minimum Data Rate does not include the MAC and PHY overheads [4]. Data rate includes the transport of the IP packet and header.
WMM-ACでは、最小データレートはビット/秒で最小データレートを指定します。最小データレートには、MACおよびPHYのオーバーヘッドは含まれません[4]。データレートには、IPパケットとヘッダーの転送が含まれます。
Minimum Data Rate is not used in QoS provisioning as it is described here.
ここで説明するように、最小データレートはQoSプロビジョニングでは使用されません。
QCI
QCI
The QoS Class Identifier (QCI) is a scalar parameter that points to standardized characteristics of QoS as opposed to signaling separate parameters for resource type, priority, delay, and loss [8].
QoSクラス識別子（QCI）は、リソースタイプ、優先度、遅延、および損失の個別のパラメーターをシグナリングするのではなく、QoSの標準化された特性を指すスカラーパラメーターです[8]。
STA
STA
A station (STA) is a device that has the capability to use the IEEE 802.11 protocol. For example, a station maybe a laptop, a desktop PC, an access point, or a Wi-Fi phone [3].
ステーション（STA）は、IEEE 802.11プロトコルを使用する機能を持つデバイスです。たとえば、ステーションはラップトップ、デスクトップPC、アクセスポイント、またはWi-Fi電話です[3]。
An STA that implements the QoS facility is a QoS Station (QSTA) [3].
QoS機能を実装するSTAは、QoSステーション（QSTA）です[3]。
TSPEC
TSPEC
The TSPEC element in IEEE 802.11 contains the set of parameters that define the characteristics and QoS expectations of a traffic flow [3].
IEEE 802.11のTSPEC要素には、トラフィックフローの特性とQoS期待値を定義する一連のパラメーターが含まれています[3]。
TCLAS
TCLAS
The TCLAS element specifies an element that contains a set of parameters necessary to identify incoming MSDUs (MAC Service Data Units) that belong to a particular TS (Traffic Stream) [3].
TCLAS要素は、特定のTS（トラフィックストリーム）[3]に属する着信MSDU（MACサービスデータユニット）を識別するために必要なパラメーターのセットを含む要素を指定します。
IEEE 802.11 defines a way of providing prioritized access for different traffic classes (video, voice, etc.) by a mechanism called EDCA (Enhanced Distributed Channel Access). The levels of priority in EDCA are called access categories (ACs) and there are four levels (in decreasing order of priority): Voice, Video, Best-Effort, and Background. Prioritized access is achieved by using AC-specific values for Contention Window (CW) and Arbitration Inter-Frame Space (AIFS). (Higher-priority categories have smaller values for minimum and maximum CW and AIFS.)
IEEE 802.11は、EDCA（Enhanced Distributed Channel Access）と呼ばれるメカニズムによって、さまざまなトラフィッククラス（ビデオ、音声など）に優先アクセスを提供する方法を定義しています。 EDCAの優先度のレベルはアクセスカテゴリ（AC）と呼ばれ、4つのレベル（優先度の降順）があります。音声、ビデオ、ベストエフォート、およびバックグラウンドです。優先アクセスは、コンテンションウィンドウ（CW）およびアービトレーションフレーム間スペース（AIFS）にAC固有の値を使用することで実現されます。 （優先度の高いカテゴリほど、CWとAIFSの最小値と最大値が小さくなります）。
A subset of the QoS mechanisms is defined in WMM -- a Wi-Fi Alliance certification of support for a set of features from an IEEE 802.11e draft (now part of IEEE 802.11). This certification is for both clients and APs and certifies the operation of WMM. WMM is primarily the implementation of the EDCA component of IEEE 802.11e. WMM uses the IEEE 802.1P classification scheme developed by the IEEE (which is now a part of the 802.1D specification). The IEEE 802.1P classification scheme has eight priorities, which WMM maps to four access categories: AC_BK, AC_BE, AC_VI, and AC_VO. The lack of support in WMM for the TCLAS (used in identifying an IP flow) has an impact on the QoS provisioning. The impact on WMM-based QoS provisioning is described in Sections 3 and 4.
QoSメカニズムのサブセットは、WMM-IEEE 802.11eドラフト（現在はIEEE 802.11の一部）からの機能セットのサポートのWi-Fi Alliance認定で定義されています。この認証はクライアントとAPの両方を対象とし、WMMの動作を認証します。 WMMは主に、IEEE 802.11eのEDCAコンポーネントの実装です。 WMMは、IEEEによって開発されたIEEE 802.1P分類方式（現在は802.1D仕様の一部）を使用しています。 IEEE 802.1P分類方式には8つの優先順位があり、WMMはAC_BK、AC_BE、AC_VI、AC_VOの4つのアクセスカテゴリにマップします。 （IPフローの識別に使用される）TCLASのWMMでのサポートの欠如は、QoSプロビジョニングに影響を与えます。 WMMベースのQoSプロビジョニングへの影響については、セクション3および4で説明します。
IEEE 802.11 defines the way a (non-AP) STA can request QoS to be reserved for an access category. Correspondingly, the AP can determine whether to admit or deny the request depending on the available resources. Further, the AP may require that Admission Control is mandatory for an access category. In such a case, the STA is expected to use the access category only after being successfully admitted. WMM-AC is a Wi-Fi Alliance certification of support for Admission Control based on a set of features in IEEE 802.11.
IEEE 802.11は、（非AP）STAがアクセスカテゴリ用に予約するQoSを要求できる方法を定義しています。同様に、APは、使用可能なリソースに応じて、要求を許可するか拒否するかを決定できます。さらに、APは、アクセスカテゴリにアドミッションコントロールが必須であることを要求する場合があります。そのような場合、STAは正常に承認された後でのみアクセスカテゴリを使用することが期待されます。 WMM-ACは、IEEE 802.11の一連の機能に基づくアドミッションコントロールのサポートのWi-Fi Alliance認定です。
The QoS signaling in IEEE 802.11 is initiated by the (non-AP) STA (by sending an ADDTS request). This specification references procedures in IEEE 802.11, WMM, and WMM-AC.
IEEE 802.11のQoSシグナリングは、（非AP）STAによって（ADDTS要求を送信することによって）開始されます。この仕様は、IEEE 802.11、WMM、およびWMM-ACの手順を参照しています。
There are two main types of interaction possible to provision QoS for flows that require Admission Control -- one where the MN initiates the QoS request and the network provisions the resources. The second is where the network provisions resources as a result of a PMIPv6 QoS request. In the second scenario, the LMA can push the QoS configuration to the MAG. However, there is no standard way for the AP to initiate a QoS service request to the MN. Recommendations to set up QoS in both these cases are described in this section.
アドミッションコントロールを必要とするフローにQoSをプロビジョニングするには、主に2つのタイプの対話が可能です。1つは、MNがQoS要求を開始し、ネットワークがリソースをプロビジョニングするものです。 2つ目は、PMIPv6 QoS要求の結果としてネットワークがリソースをプロビジョニングする場所です。 2番目のシナリオでは、LMAはQoS構成をMAGにプッシュできます。ただし、APがMNへのQoSサービス要求を開始する標準的な方法はありません。このセクションでは、これら両方のケースでQoSをセットアップするための推奨事項について説明します。
This procedure outlines the case where the MN is configured to start the QoS signaling. In this case, the MN sends an ADDTS request indicating the QoS required for the flow. The AP/MAG obtains the corresponding level of QoS to be granted to the flow by using the PMIPv6 PBU/PBA sequence that contains the QoS options exchanged with the LMA. Details of the QoS provisioning for the flow are provided below.
この手順では、MNがQoSシグナリングを開始するように設定されている場合の概要を説明します。この場合、MNは、フローに必要なQoSを示すADDTS要求を送信します。 AP / MAGは、LMAと交換されたQoSオプションを含むPMIPv6 PBU / PBAシーケンスを使用して、フローに許可されるQoSの対応するレベルを取得します。フローのQoSプロビジョニングの詳細を以下に示します。
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) establish session with mobile network |
+-------------------------------------------------------------+
| | | |
+-------------+ | | |
|upper-layer | | | |
|notification | | | |
+-+-+-+-+-+-+-+ | | |
| | | |
| ADDTS Request(TCLAS(opt),TSPEC),AC| |
|---------------------------->| | |
| (1) |---->|PBU(QoS options)(2)|
| | |------------------>|
| | | | Policy
| | |PBA(QoS option)(3) |<----->
| | |<------------------|
| |<----| |
|ADDTS Response(TCLAS(opt),TSPEC),AC| |
|<----------------------------| | |
| (4) | |
Figure 2: MS-Initiated QoS Service Request
図2：MSによって開始されたQoSサービス要求
In the use case shown in Figure 2, the MN initiates the QoS service request.
図2に示す使用例では、MNはQoSサービス要求を開始します。
(0) The MN establishes a session as described in steps 1-4 of Use Case 2 (MAG-Initiated QoS Service Request) in Section 3.1 of [1]. At this point, a connection with a PMIPv6 tunnel is established to the LMA. This allows the MN to start application-level signaling.
（0）MNは、[1]のセクション3.1のユースケース2（MAG-Initiated QoS Service Request）のステップ1〜4で説明されているように、セッションを確立します。この時点で、PMIPv6トンネルとの接続がLMAに対して確立されます。これにより、MNはアプリケーションレベルのシグナリングを開始できます。
(1) The trigger for the MN to request QoS is an upper-layer notification. This may be the result of end-to-end application signaling and setup procedures (e.g., SIP [10]).
（1）MNがQoSを要求するトリガーは、上位層通知です。これは、エンドツーエンドのアプリケーションシグナリングとセットアップ手順の結果である可能性があります（SIP [10]など）。
Since the MN is configured to start QoS signaling, it sends an ADDTS request with TSPEC and TCLAS identifying the flow for which QoS is requested.
MNはQoSシグナリングを開始するように構成されているので、QoSが要求されているフローを識別するTSPECおよびTCLASとともにADDTS要求を送信します。
It should be noted that WMM-AC specifications do not contain TCLAS. When TCLAS is not present, there is no direct way to derive flow-specific attributes like Traffic Selector in PMIPv6. In this case, functionality to derive IP flow details from information in upper-layer protocols (e.g., SIP [10]) and associate them with a subsequent QoS request may be used. This is not described further here, but it may be functionality in an Application Layer Gateway (ALG) or Deep Packet Inspection (DPI). It should be noted that an ALG or DPI can increase the complexity of the AP/MAG implementation and affect its scalability. If no TCLAS is derived, the reservation applies to all flows of the MN. Parameter mapping in this case is shown in Table 2.
WMM-AC仕様にはTCLASが含まれていないことに注意してください。 TCLASが存在しない場合、PMIPv6のトラフィックセレクターのようなフロー固有の属性を直接取得する方法はありません。この場合、上位層プロトコル（SIP [10]など）の情報からIPフローの詳細を導出し、それらを後続のQoS要求に関連付ける機能を使用できます。これについてはここでは詳しく説明しませんが、アプリケーション層ゲートウェイ（ALG）またはディープパケットインスペクション（DPI）の機能である可能性があります。 ALGまたはDPIはAP / MAGの実装を複雑にし、そのスケーラビリティに影響を与える可能性があることに注意してください。 TCLASが導出されない場合、予約はMNのすべてのフローに適用されます。この場合のパラメーターのマッピングを表2に示します。
(2) If there are sufficient resources at the AP/WLC to satisfy the request, the MAG sends a PBU with QoS options, Operational Code ALLOCATE, and the Traffic Selector identifying the flow. The Traffic Selector is derived from the TCLAS to identify the flow requesting QoS. IEEE 802.11 QoS parameters in TSPEC are mapped to PMIPv6 parameters. The mapping of TCLAS to PMIPv6 is shown in Table 1. TSPEC parameter mapping is shown in Table 4.
（2）AP / WLCに要求を満たすのに十分なリソースがある場合、MAGはQoSオプション、オペレーションコードALLOCATE、およびフローを識別するトラフィックセレクターを含むPBUを送信します。トラフィックセレクターはTCLASから派生し、QoSを要求するフローを識別します。 TSPECのIEEE 802.11 QoSパラメータは、PMIPv6パラメータにマッピングされます。 TCLASからPMIPv6へのマッピングを表1に示します。TSPECパラメータのマッピングを表4に示します。
If TCLAS is not present (when WMM-AC is used), TCLAS may be derived from information in upper-layer protocols (as described in step 1) and populated in the Traffic Selector. If TCLAS cannot be derived, the Traffic Selector field is not included in the QoS options.
TCLASが存在しない場合（WMM-ACが使用されている場合）、TCLASは（手順1で説明したように）上位層プロトコルの情報から取得され、トラフィックセレクターに入力されます。 TCLASを導出できない場合、トラフィックセレクタフィールドはQoSオプションに含まれません。
(3) The LMA obtains the authorized QoS for the flow and responds to the MAG with Operational Code set to RESPONSE. Mapping of PMIPv6 to IEEE 802.11 TCLAS is shown in Table 1, and mapping of TSPEC parameters is shown in Table 4.
（3）LMAはフローの許可されたQoSを取得し、オペレーションコードをRESPONSEに設定してMAGに応答します。 PMIPv6からIEEE 802.11 TCLASへのマッピングを表1に示し、TSPECパラメータのマッピングを表4に示します。
Reserved bandwidth for flows is calculated separately from the non-reserved session bandwidth. The Traffic Selector identifies the flow for which the QoS reservations are made.
フローの予約済み帯域幅は、予約されていないセッション帯域幅とは別に計算されます。トラフィックセレクターは、QoS予約が行われるフローを識別します。
If the LMA offers downgraded QoS values to the MAG, it should send a PBU to the LMA with Operational Code set to DE-ALLOCATE. (The LMA would respond with PBA to confirm completion of the request.)
LMAがダウングレードされたQoS値をMAGに提供する場合、オペレーションコードがDE-ALLOCATEに設定されたPMAをLMAに送信する必要があります。 （LMAは要求の完了を確認するためにPBAで応答します。）
(4) The AP/MAG provisions the corresponding QoS and replies with ADDTS Response containing authorized QoS in TSPEC, the flow identification in TSPEC, and ResultCode set to SUCCESS.
（4）AP / MAGは、対応するQoSをプロビジョニングし、TSPECでの承認済みQoS、TSPECでのフロー識別、および成功に設定されたResultCodeを含むADDTS応答で応答します。
The AP polices these flows according to the QoS provisioning.
APは、QoSプロビジョニングに従ってこれらのフローをポリシングします。
In step 3, if the LMA sends a downgraded QoS or a PBA message with status code CANNOT_MEET_QOS_SERVICE_REQUEST (179), then the AP should respond to the MN with ADDTS Response and ResultCode set as follows:
ステップ3で、LMAがダウングレードされたQoSまたはステータスコードCANNOT_MEET_QOS_SERVICE_REQUEST（179）のPBAメッセージを送信した場合、APはMNにADDTS ResponseおよびResultCodeを次のように設定して応答する必要があります。
- for downgraded QoS from LMA, ResultCode is set to REJECTED_WITH_SUGGESTED_CHANGES. Downgraded QoS values from LMA are mapped to TSPEC as per Table 4. This is still a rejection, but the MN may revise the QoS to a lower level and repeat this sequence if the application can adapt.
- LMAからダウングレードされたQoSの場合、ResultCodeはREJECTED_WITH_SUGGESTED_CHANGESに設定されます。 LMAからのダウングレードされたQoS値は、表4に従ってTSPECにマップされます。これは依然として拒否ですが、アプリケーションが適応できる場合、MNはQoSをより低いレベルに修正し、このシーケンスを繰り返すことがあります。
- if LMA cannot meet the QoS service request, ResultCode is set to TCLAS_RESOURCES_EXHAUSTED.
- LMAがQoSサービス要求に対応できない場合、ResultCodeはTCLAS_RESOURCES_EXHAUSTEDに設定されます。
Either REJECTED_WITH_SUGGESTED_CHANGES or TCLAS_RESOURCES_EXHAUSTED results in the rejection of the QoS reservation, but it does not cause the removal of the session itself.
REJECTED_WITH_SUGGESTED_CHANGESまたはTCLAS_RESOURCES_EXHAUSTEDは、QoS予約を拒否しますが、セッション自体は削除されません。
QoS resources reserved for a session are released on completion of the session. When the application session completes, the LMA or the MN may signal for the release of resources. In the use case shown in Figure 3, the MN initiates the release of QoS resources.
セッション用に予約されたQoSリソースは、セッションの完了時に解放されます。アプリケーションセッションが完了すると、LMAまたはMNはリソースの解放を通知できます。図3に示す使用例では、MNはQoSリソースの解放を開始します。
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) Establishment of application session |
| and reservation of QoS resources |
| |
| (Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | |
| DELTS Request (TS INFO)(1) | | |
|---------------------------->| | |
| |---->| |
| |<----| |
| DELTS Response (TS INFO)(2) | | |
|<----------------------------| | |
| | |PBU(QoS,DE-ALLOC)(3)|
| | |------------------->|Policy
| | | |<---->
| | | |Update
| | |PBA(QoS,RESPONSE)(4)|
| | |<-------------------|
| | | |
Figure 3: MN-Initiated QoS Resource Release
図3：MNが開始したQoSリソースの解放
(0) The MN establishes and reserves QoS resources. When the application session terminates, the MN prepares to release QoS resources.
（0）MNはQoSリソースを確立して予約します。アプリケーションセッションが終了すると、MNはQoSリソースを解放する準備をします。
(1) The MN releases its own internal resources and sends a DELTS Request to the AP with TS (Traffic Stream) INFO.
（1）MNは自身の内部リソースを解放し、TS（トラフィックストリーム）INFOを使用してDELTS要求をAPに送信します。
(2) The AP receives the DELTS request, releases local resources, and responds to the MN with a DELTS response.
（2）APはDELTS要求を受信し、ローカルリソースを解放し、DELTS応答でMNに応答します。
(3) The MAG initiates a PBU, with the Operational Code set to DE-ALLOCATE, and with the Traffic Selector constructed from TCLAS and PMIPv6 QoS parameters from TSPEC.
（3）MAGは、操作コードをDE-ALLOCATEに設定し、TCLASから構築されたトラフィックセレクターとTSPECからのPMIPv6 QoSパラメーターを使用して、PBUを開始します。
When TCLAS is not present, the MAG should de-allocate all flows with the same access category as indicated in the DELTS Request. In the typical case, if the client does not support TCLAS and only MN-initiated QoS Service requests are supported, then the MAG will have at most one QoS Service request per access category.
TCLASが存在しない場合、MAGは、DELTS要求に示されているように、同じアクセスカテゴリを持つすべてのフローの割り当てを解除する必要があります。一般的なケースでは、クライアントがTCLASをサポートせず、MNによって開始されたQoSサービス要求のみがサポートされる場合、MAGはアクセスカテゴリごとに最大で1つのQoSサービス要求を持ちます。
(4) LMA receives the PBU and releases local resources. The LMA then responds with a PBA.
（4）LMAはPBUを受け取り、ローカルリソースを解放します。次に、LMAはPBAで応答します。
It should be noted that steps 3 and 4 can proceed independently of the DELTS Response (step 2).
ステップ3と4は、DELTS応答（ステップ2）とは無関係に続行できることに注意してください。
This section describes the case when the QoS service request is initiated by the LMA. For example, an application such as voice may request the network to initiate configuration of additional QoS policy as in [8], Section 7.4.2. In the current WLAN specifications, there is no standard-defined way for the AP to initiate a QoS service request to the MN. As a result, when the MAG receives a QoS request from the LMA, it does not have any standard mechanisms to initiate any QoS requests to the MN over the access network. Given this, the PMIPv6 QoS service requests and any potential WLAN service requests (such as described in Section 3.1) are handled asynchronously.
このセクションでは、QoSサービス要求がLMAによって開始される場合について説明します。たとえば、音声などのアプリケーションは、[8]のセクション7.4.2のように、追加のQoSポリシーの構成を開始するようネットワークに要求する場合があります。現在のWLAN仕様では、APがMNへのQoSサービス要求を開始するための標準的に定義された方法はありません。その結果、MAGはLMAからQoS要求を受信したときに、アクセスネットワークを介してMNへのQoS要求を開始する標準的なメカニズムがありません。この場合、PMIPv6 QoSサービス要求と潜在的なWLANサービス要求（セクション3.1で説明されているような）は非同期で処理されます。
The PMIPv6 QoS service requests and WLAN QoS service request could still be coordinated to provide an end-to-end QoS. If the MAG receives an Update Notification (UPN) request from the LMA to reserve QoS resources for which it has no corresponding QoS request from the MN, the MAG may, in consultation with the AP, provision a policy that can grant a subsequent QoS request from the MN. If the MN initiates QoS procedures after the completion of PMIPv6 QoS procedures, the AP/ MAG can ensure consistency between the QoS resources in the access network and QoS resources between the MAG and LMA.
PMIPv6 QoSサービス要求とWLAN QoSサービス要求は、エンドツーエンドQoSを提供するように調整できます。 MAGがLMAから更新通知（UPN）要求を受信して、MNからの対応するQoS要求がないQoSリソースを予約すると、MAGはAPと協議して、後続のQoS要求を許可できるポリシーをプロビジョニングできます。 MNから。 MNがPMIPv6 QoS手順の完了後にQoS手順を開始した場合、AP / MAGはアクセスネットワークのQoSリソースとMAGとLMAのQoSリソース間の整合性を確保できます。
For example, if the MN is requesting a mean data rate of x Mbps, the AP and MAG can ensure that the rate can be supported on the network between MAG and LMA based on previous PMIPv6 QoS procedures. If the MN subsequently requests data rates of x Mbps or less, the AP can accept a request based on the earlier PMIPv6 QoS provisioning. For the case where there is a mismatch, i.e., the network does not support the x Mbps, then either the MAG should renegotiate the QoS resource and ask for increased QoS resources or the AP should reject the QoS request.
たとえば、MNがx Mbpsの平均データレートを要求している場合、APとMAGは、以前のPMIPv6 QoS手順に基づいて、MAGとLMA間のネットワークでレートがサポートされることを保証できます。その後、MNがx Mbps以下のデータレートを要求した場合、APは以前のPMIPv6 QoSプロビジョニングに基づいて要求を受け入れることができます。不一致がある場合、つまりネットワークがx Mbpsをサポートしていない場合、MAGはQoSリソースを再ネゴシエートしてQoSリソースの増加を要求するか、APがQoS要求を拒否する必要があります。
The network-initiated QoS service request scenario poses some challenges outlined here. IEEE 802.11 does not provide any mechanisms for the AP to initiate a QoS request. As a result, the AP/MAG cannot explicitly make any reservations in response to a QoS reservation request made using UPN. IEEE 802.11aa [5] (which is an amendment to IEEE 802.11) has a mechanism that enables the AP to ask the client to reserve QoS for a traffic stream. It does this via the ADDTS Reserve Request. The ADDTS Reserve Request contains a TSPEC, an optional TCLAS, and a mandatory stream identifier. The specification does not describe how the AP would obtain such a stream identifier. As a result, there needs to be a new higher-layer protocol defined that is understood by the MN and AP and that provides a common stream identifier to both ends. Alternately, the IEEE 802.11aa specification could be modified to make the usage optional. When (or if) the stream identifier is made optional, the TCLAS can provide information about the traffic stream.
ネットワークによって開始されるQoSサービス要求シナリオでは、ここで概説するいくつかの課題が発生します。 IEEE 802.11では、APがQoS要求を開始するためのメカニズムは提供されていません。その結果、UPNを使用して行われたQoS予約要求に応答して、AP / MAGは明示的に予約を行うことができません。 IEEE 802.11aa [5]（これはIEEE 802.11の修正版です）には、APがクライアントにトラフィックストリームのQoSを予約するように要求できるようにするメカニズムがあります。これは、ADDTS予約リクエストを介して行われます。 ADDTS予約要求には、TSPEC、オプションのTCLAS、および必須のストリーム識別子が含まれています。この仕様では、APがこのようなストリーム識別子を取得する方法については説明していません。その結果、MNとAPが理解し、両端に共通のストリーム識別子を提供する、新しい上位層プロトコルが定義される必要があります。あるいは、IEEE 802.11aa仕様を変更して、使用をオプションにすることもできます。ストリーム識別子をオプションにした場合（またはその場合）、TCLASはトラフィックストリームに関する情報を提供できます。
Appendix A outlines a protocol sequence with PMIPv6 UPN / Update Notification Acknowledgement (UPA) if the above IEEE 802.11aa issues can be resolved.
付録Aは、上記のIEEE 802.11aaの問題を解決できる場合のPMIPv6 UPN /更新通知確認（UPA）のプロトコルシーケンスの概要を示しています。
QoS resources reserved for a session are released on completion of the session. When the application session completes, the LMA or the MN may signal for the release of resources. In this use case, the network initiates the release of QoS resources.
セッション用に予約されたQoSリソースは、セッションの完了時に解放されます。アプリケーションセッションが完了すると、LMAまたはMNはリソースの解放を通知できます。この使用例では、ネットワークがQoSリソースの解放を開始します。
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| Establishment of application session |
| and reservation of QoS resources |
| |
| (Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | | Policy
| | | |<------
| | |UPN(QoS,DE-ALLOC) |
| | |<------------------|
| |<----| (1) |
| |---->|UPA(QoS,RESPONSE) |
| | |------------------>|
| | | (2) |
| | | |
| DELTS Request (TS INFO)(3) | | |
|<----------------------------| | |
| DELTS Response (TS INFO)(4) | | |
|---------------------------->| | |
| | | |
Figure 4: LMA-Initiated QoS Resource Release
図4：LMAによって開始されたQoSリソースの解放
In the use case shown in Figure 4, the network initiates the release of QoS resources. When the application session terminates, the LMA receives notification of that event. The LMA releases local QoS resources associated with the flow and initiates signaling to release QoS resources in the network.
図4に示す使用例では、ネットワークがQoSリソースの解放を開始します。アプリケーションセッションが終了すると、LMAはそのイベントの通知を受け取ります。 LMAは、フローに関連付けられたローカルQoSリソースを解放し、シグナリングを開始して、ネットワーク内のQoSリソースを解放します。
(1) The LMA sends a UPN with QoS options identifying the flow for which QoS resources are to be released and Operational Code set to DE-ALLOCATE. No additional LMA QoS parameters are sent.
（1）LMAは、QoSリソースを解放するフローを識別するQoSオプションとオペレーションコードがDE-ALLOCATEに設定されたUPNを送信します。追加のLMA QoSパラメータは送信されません。
(2) The MAG replies with a UPA confirming the acceptance and Operational Code set to RESPONSE.
（2）MAGは、UPAを使用して応答を確認し、オペレーションコードをRESPONSEに設定します。
(3) The AP/WLC (MAG) releases local QoS resources associated with the flow. The AP derives the corresponding access category from the Traffic Class (TC) field provided in the QoS option. In addition, if the AP supports TCLAS and the QoS option contains a Traffic Selector field, then the AP shall map the Traffic Selector into a TCLAS element. In the case where the AP does not support TCLAS (for example, an AP compliant with WMM-AC), then the AP shall only use the access category. The AP sends a DELTS Request with TS INFO identifying the reservation.
（3）AP / WLC（MAG）は、フローに関連付けられたローカルQoSリソースを解放します。 APは、QoSオプションで提供されるトラフィッククラス（TC）フィールドから対応するアクセスカテゴリを取得します。さらに、APがTCLASをサポートし、QoSオプションにトラフィックセレクタフィールドが含まれている場合、APはトラフィックセレクタをTCLAS要素にマップします。 APがTCLASをサポートしない場合（たとえば、WMM-ACに準拠したAP）、APはアクセスカテゴリのみを使用します。 APは、予約を識別するTS INFOを含むDELTS要求を送信します。
(4) The MN sends DELTS Response confirming release.
（4）MNはリリースを確認するDELTS応答を送信します。
It should be noted that steps 3 and 4 can proceed independently of the UPA (step 2).
ステップ3および4は、UPA（ステップ2）とは無関係に続行できることに注意してください。
TSPEC in IEEE 802.11 is used to reserve QoS for a traffic stream (MN MAC, TS ID). The IEEE 802.11 QoS reservation is for IEEE 802.11 frames associated with an MN's MAC address.
IEEE 802.11のTSPECは、トラフィックストリーム（MN MAC、TS ID）のQoSを予約するために使用されます。 IEEE 802.11 QoS予約は、MNのMACアドレスに関連付けられたIEEE 802.11フレーム用です。
The TCLAS element with Classifier 1 (TCP/UDP Parameters) is used to identify a PMIPv6 QoS flow. We should note that WMM-AC procedures do not support TCLAS. When TCLAS is present, a one-to-one mapping between the TCLAS-defined flow and the Traffic Selector is given below.
分類子1（TCP / UDPパラメーター）を含むTCLAS要素は、PMIPv6 QoSフローを識別するために使用されます。 WMM-AC手順はTCLASをサポートしないことに注意してください。 TCLASが存在する場合、TCLASで定義されたフローとトラフィックセレクターの間の1対1のマッピングを以下に示します。
QoS reservations in IEEE 802.11 are made for a traffic stream (identified in TCLAS) and correspond to PMIPv6 QoS session parameters (identified by the Traffic Selector). PMIPv6 QoS [1] specifies that when QoS-Traffic-Selector is included along with the per-session bandwidth attributes described in Section 4.3 below, the attributes apply at a per-session level.
IEEE 802.11のQoS予約は、（TCLASで識別される）トラフィックストリームに対して行われ、（トラフィックセレクターによって識別される）PMIPv6 QoSセッションパラメーターに対応します。 PMIPv6 QoS [1]は、QoS-Traffic-Selectorが、以下のセクション4.3で説明するセッションごとの帯域幅属性とともに含まれる場合、属性がセッションごとのレベルで適用されることを指定します。
+--------------------------------+----------------------------+
| MN <--> AP (IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+--------------------------------+----------------------------+
| (TCLAS Classifier 1)TCP/UDP IP | Traffic Selector (IP flow) |
| (TCLAS Classifier 1) DSCP | Traffic Class (TC) |
+--------------------------------+----------------------------+
Table 1: IEEE 802.11 - PMIPv6 QoS Connection Mapping
表1：IEEE 802.11-PMIPv6 QoS接続マッピング
If the MN or AP is not able to convey flow parameters in TCLAS, the QoS reservation request in IEEE 802.11 is derived as shown in Table 2.
MNまたはAPがTCLASでフローパラメーターを伝達できない場合、表2に示すように、IEEE 802.11でのQoS予約要求が導出されます。
+------------------------------+--------------------------+
| MN <--> AP (WMM) | MAG <--> LMA (PMIPv6) |
+------------------------------+--------------------------+
| (no IP flow parameter/TCLAS) | (a) applies to all flows |
| | (b) derived out-of-band |
| | |
| User Priority (802.1D) | Traffic Class (TC) |
| | (derived using Table 3) |
+------------------------------+--------------------------+
Table 2: WMM - PMIPv6 QoS Connection Mapping
表2：WMM-PMIPv6 QoS接続マッピング
When WMM [4] is used, and TCLAS is not present to specify IP flow, one of two options apply for the MAG - LMA (PMIPv6) segment:
WMM [4]が使用され、IPフローを指定するためにTCLASが存在しない場合、MAG-LMA（PMIPv6）セグメントには次の2つのオプションのいずれかが適用されます。
(a) Bandwidth parameters described in Section 4.3 apply to all flows of the MN. This is not a preferred mode of operation if the LMA performs reservation for a single flow, e.g., a voice flow identified by an IP 5-tuple.
（a）セクション4.3で説明されている帯域幅パラメータは、MNのすべてのフローに適用されます。 LMAが単一のフロー（IP 5タプルで識別される音声フローなど）の予約を実行する場合、これは好ましい動作モードではありません。
(b) The IP flow for which the MN requests reservation is derived out-of-band. For example, the AP/MAG observes application-level signaling (e.g., SIP [10]) or session-level signaling (e.g., 3GPP WLCP (WLAN Control Protocol) [7]), associates subsequent ADDTS requests using heuristics, and then derives the IP flow / Traffic Selector field.
（b）MNが予約を要求するIPフローは、帯域外で導出されます。たとえば、AP / MAGは、アプリケーションレベルのシグナリング（たとえば、SIP [10]）またはセッションレベルのシグナリング（たとえば、3GPP WLCP（WLAN Control Protocol）[7]）を観察し、ヒューリスティックを使用して後続のADDTS要求を関連付け、次に導出します。 IPフロー/トラフィックセレクタフィールド。
Table 3 contains a mapping between access category (AC) and IEEE 802.1D User Priority (UP) tag in IEEE 802.11 frames, and DSCP in IP data packets. The table also provides the mapping between AC and DSCP for use in IEEE 802.11 TSPEC and PMIPv6 QoS (Traffic Class). Mapping of QCI to DSCP uses the tables in [6].
表3は、IEEE 802.11フレームのアクセスカテゴリ（AC）とIEEE 802.1Dユーザー優先順位（UP）タグ、およびIPデータパケットのDSCP間のマッピングを示しています。この表は、IEEE 802.11 TSPECおよびPMIPv6 QoS（トラフィッククラス）で使用するためのACとDSCP間のマッピングも示しています。 QCIからDSCPへのマッピングは、[6]の表を使用します。
+-----+------+-----------+---------+----------------------+
| QCI | DSCP | 802.1D UP | AC | Example Services |
+-----+------+-----------+---------+----------------------+
| 1 | EF | 6(VO) | 3 AC_VO | conversational voice |
| 2 | EF | 6(VO) | 3 AC_VO | conversational video |
| 3 | EF | 6(VO) | 3 AC_VO | real-time gaming |
| 4 | AF41 | 5(VI) | 2 AC_VI | buffered streaming |
| 5 | AF31 | 4(CL) | 2 AC_VI | signaling |
| 6 | AF32 | 4(CL) | 2 AC_VI | buffered streaming |
| 7 | AF21 | 3(EE) | 0 AC_BE | interactive gaming |
| 8 | AF11 | 1(BE) | 0 AC_BE | web access |
| 9 | BE | 0(BK) | 1 AC_BK | email |
+-----+------+-----------+---------+----------------------+
Table 3: QoS Mapping between QCI/DSCP, 802.1D UP, AC
表3：QCI / DSCP、802.1D UP、AC間のQoSマッピング
The MN tags all data packets with DSCP and IEEE 802.1D UP corresponding to the application and the subscribed policy or authorization. The AP polices sessions and flows based on the configured QoS policy values for the MN.
MNは、アプリケーションとサブスクライブされたポリシーまたは許可に対応するDSCPおよびIEEE 802.1D UPですべてのデータパケットにタグを付けます。 APは、MNに設定されたQoSポリシー値に基づいてセッションとフローをポリシングします。
For QoS reservations, TSPEC uses WMM-AC values and PMIPv6 QoS uses corresponding DSCP values in Traffic Class (TC). IEEE 802.11 QoS Access Category AC_VO and AC_VI are used for QoS reservations. AC_BE and AC_BK should not be used in reservations.
QoS予約の場合、TSPECはWMM-AC値を使用し、PMIPv6 QoSは対応するDSCP値をトラフィッククラス（TC）で使用します。 IEEE 802.11 QoSアクセスカテゴリAC_VOおよびAC_VIはQoS予約に使用されます。 AC_BEとAC_BKは予約では使用しないでください。
When WMM-AC specifications that do not contain TCLAS are used, it is only possible to have one reservation per Traffic Class / access category. PMIPv6 QoS will not contain any flow-specific attributes like Traffic Selector.
TCLASを含まないWMM-AC仕様を使用する場合、トラフィッククラス/アクセスカテゴリごとに1つの予約のみが可能です。 PMIPv6 QoSには、Traffic Selectorのようなフロー固有の属性は含まれません。
Bandwidth parameters that need to be mapped between IEEE 802.11 and PMIPv6 QoS are shown in Table 4.
IEEE 802.11とPMIPv6 QoSの間でマッピングする必要がある帯域幅パラメーターを表4に示します。
+-------------------------+---------------------------+
| MN <--> AP(IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+-------------------------+---------------------------+
| Mean Data Rate, DL | Guaranteed-DL-Bit-Rate |
| Mean Data Rate, UL | Guaranteed-UL-Bit-Rate |
| Peak Data Rate, DL | Aggregate-Max-DL-Bit-Rate |
| Peak Data Rate, UL | Aggregate-Max-UL-Bit-Rate |
+-------------------------+---------------------------+
Table 4: Bandwidth Parameters for Admission-Controlled Flows
表4：アドミッション制御フローの帯域幅パラメーター
In PMIPv6 QoS [1], services using a sending rate smaller than or equal to the Guaranteed Bit Rate (GBR) can assume, in general, that congestion-related packet drops will not occur [8]. If the rate offered by the service exceeds this threshold, there are no guarantees provided. IEEE 802.11 radio networks do not offer such a guarantee, but [4] notes that the application (service) requirements are captured in TSPEC by the MSDU (MAC Service Data Unit) and Mean Data Rate. The TSPEC should contain Mean Data Rate, and it is recommended that it be mapped to the GBR parameters, Guaranteed-DL-Bit-Rate and Guaranteed-UL-Bit-Rate in PMIPv6 QoS [1].
PMIPv6 QoS [1]では、保証ビットレート（GBR）以下の送信レートを使用するサービスは、一般に、輻輳関連のパケットドロップは発生しないと想定できます[8]。サービスによって提供されるレートがこのしきい値を超える場合、保証は提供されません。 IEEE 802.11無線ネットワークはそのような保証を提供しませんが、アプリケーション（サービス）の要件はMSDU（MACサービスデータユニット）と平均データレートによってTSPECで取得されることに注意してください。 TSPECには平均データレートが含まれている必要があり、PMIPv6 QoS [1]のGBRパラメーター、Granteded-DL-Bit-RateおよびGuaranted-UL-Bit-Rateにマップすることをお勧めします。
IEEE 802.11 TSPEC requests do not require all fields to be completed. [4] specifies a list of TSPEC parameters that are required in the specification. Peak Data Rate is not required in WMM; however, for MNs and APs that are capable of specifying the Peak Data Rate, it should be mapped to MBR (Maximum Bit Rate) in PMIPv6 QoS. The AP should use the MBR parameters Aggregate-Max-DL-Bit-Rate and Aggregate-Max-UL-Bit-Rate to police these flows on the backhaul segment between MAG and LMA.
IEEE 802.11 TSPEC要求では、すべてのフィールドに入力する必要はありません。 [4]は、仕様で必要なTSPECパラメータのリストを指定します。ピークデータレートはWMMでは必要ありません。ただし、ピークデータレートを指定できるMNおよびAPの場合は、PMIPv6 QoSでMBR（最大ビットレート）にマップする必要があります。 APは、MBRパラメータAggregate-Max-DL-Bit-RateおよびAggregate-Max-UL-Bit-Rateを使用して、MAGとLMA間のバックホールセグメントでこれらのフローをポリシングする必要があります。
During the QoS reservation procedure, if the MN requests Mean Data Rate, or Peak Data Rate in excess of values authorized in PMIPv6 QoS, the AP should deny the request in an ADDTS response. The AP may set the reject cause code to REJECTED_WITH_SUGGESTED_CHANGES and send a revised TSPEC with Mean Data Rate and Peak Data Rate set to acceptable GBR and MBR, respectively, in PMIPv6 QoS.
QoS予約手順中に、MNがPMIPv6 QoSで許可された値を超える平均データレートまたはピークデータレートを要求した場合、APはADDTS応答で要求を拒否する必要があります。 APは拒否原因コードをREJECTED_WITH_SUGGESTED_CHANGESに設定し、平均データレートとピークデータレートを設定した改訂TSPECを、PMIPv6 QoSでそれぞれ許容可能なGBRとMBRに送信できます。
This document describes mapping of PMIPv6 QoS parameters to IEEE 802.11 QoS parameters. Thus, the security in the WLAN and PMIPv6 signaling segments and the functional entities that map the two protocols need to be considered. IEEE 802.11 [3] provides the means to secure management frames that are used for ADDTS and DELTS. The PMIPv6 specification [9] recommends using IPsec and IKEv2 to secure protocol messages. The security of the node(s) that implement the QoS mapping functionality should be considered in actual deployments.
このドキュメントでは、PMIPv6 QoSパラメータのIEEE 802.11 QoSパラメータへのマッピングについて説明します。したがって、WLANおよびPMIPv6シグナリングセグメントのセキュリティと、2つのプロトコルをマップする機能エンティティを考慮する必要があります。 IEEE 802.11 [3]は、ADDTSおよびDELTSに使用される管理フレームを保護する手段を提供します。 PMIPv6仕様[9]では、プロトコルメッセージを保護するためにIPsecおよびIKEv2を使用することを推奨しています。 QoSマッピング機能を実装するノードのセキュリティは、実際の展開で考慮する必要があります。
The QoS mappings themselves do not introduce additional security concerns.
QoSマッピング自体は、追加のセキュリティ問題をもたらしません。
[1] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, <http://www.rfc-editor.org/info/rfc7222>.
[1] Liebsch、M.、Seite、P.、Yokota、H.、Korhonen、J.、and S. Gundavelli、 "Quality-of-Service Option for Proxy Mobile IPv6"、RFC 7222、DOI 10.17487 / RFC7222、May 2014、< http://www.rfc-editor.org/info/rfc7222>。
[2] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, DOI 10.17487/RFC7077, November 2013, <http://www.rfc-editor.org/info/rfc7077>.
[2] Krishnan、S.、Gundavelli、S.、Liebsch、M.、Yokota、H。、およびJ. Korhonen、「プロキシモバイルIPv6の更新通知」、RFC 7077、DOI 10.17487 / RFC7077、2013年11月、<http：// www.rfc-editor.org/info/rfc7077>。
[3] 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 Standard 802.11.
[3] IEEE、「IEEE Standard for Information Technology-Telecommunications and information exchange between system-Local and metropolitan area network-Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、IEEE Standard 802.11。
[4] Wi-Fi Alliance, "Wi-Fi Multimedia Technical Specification (with WMM-Power Save and WMM-Admission Control)", Version 1.2.0, May 2012.
[4] Wi-Fi Alliance、「Wi-Fi Multimedia Technical Specification（with WMM-Power Save and WMM-Admission Control）」、バージョン1.2.0、2012年5月。
[5] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification, Amendment 2: MAC Enhancements for Robust Audio Video Streaming", IEEE 802.11aa.
[5] IEEE、「Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specification、Amendment 2：MAC Enhancements for Robust Audio Video Streaming」、IEEE 802.11aa。
[6] 3GPP, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)", GSMA Official Document IR.34 v11.0, November 2014, <http://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>.
[6] 3GPP、「IPXプロバイダーネットワークのガイドライン（以前のサービス間プロバイダーIPバックボーンガイドライン）」、GSMA公式ドキュメントIR.34 v11.0、2014年11月、<http://www.gsma.com/newsroom/wp-content/アップロード/ IR.34-v11.0.pdf>。
[7] 3GPP, "Technical Specification Group Core Network and Services; Wireless LAN control plane protocols for trusted WLAN access to EPC; Stage 3 (Release 12)", 3GPP TS 23.244 12.1.0, December 2014, <http://www.3gpp.org/ftp/specs/archive/24_series/24.244/>.
[7] 3GPP、「技術仕様グループのコアネットワークとサービス、EPCへの信頼できるWLANアクセスのための無線LANコントロールプレーンプロトコル、ステージ3（リリース12）」、3GPP TS 23.244 12.1.0、2014年12月、<http：//www.3gpp。 org / ftp / specs / archive / 24_series / 24.244 />。
[8] 3GPP, "Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture (Release 13)", 3GPP TS 23.203 13.2.0, December 2014, <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
[8] 3GPP、「Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture（Release 13）」、3GPP TS 23.203 13.2.0、December 2014、<http://www.3gpp.org/ftp/specs/archive/23_series /23.203 />。
[9] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[9] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、DOI 10.17487 / RFC5213、August 2008、<http：// www.rfc-editor.org/info/rfc5213>。
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[10] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261 、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+----------------------------------------------------------------+
| (0) establish session with mobile network |
+----------------------------------------------------------------+
| | | |
| | | | Policy
| | | |<----------
| | |UPN(QoS opt(2) | Update(1)
| ADDTS Reserve Request | |<-----------------|
| (TCLAS, TSPEC)(3) |<----| |
|<-------------------------| | |
| ADDTS Reserve Response | | |
| (TCLAS, TSPEC)(4) | | |
|------------------------->| | |
| |---->|UPA(QoS opt)(5) |
| | |----------------->|
| | | |
Figure 5: LMA-Initiated QoS Service Request with 802.11aa
図5：802.11aaを使用したLMA開始のQoSサービス要求
In the use case shown in Figure 5, the LMA initiates the QoS service request and IEEE 802.11aa is used to set up the QoS reservation in the Wi-Fi segment.
図5に示す使用例では、LMAがQoSサービス要求を開始し、IEEE 802.11aaを使用してWi-FiセグメントでQoS予約をセットアップします。
(0) The MN sets up a best-effort session. This allows the MN to perform application-level signaling and setup.
（0）MNはベストエフォートセッションをセットアップします。これにより、MNはアプリケーションレベルのシグナリングとセットアップを実行できます。
(1) The policy server sends a QoS reservation request to the LMA. This is usually sent in response to an application that requests the policy server for higher QoS for some of its flows.
（1）ポリシーサーバーがQoS予約要求をLMAに送信します。これは通常、一部のフローに対してより高いQoSをポリシーサーバーに要求するアプリケーションに応答して送信されます。
The LMA reserves resources for the flow requested.
LMAは、要求されたフローのためにリソースを予約します。
(2) The LMA sends a PMIPv6 UPN (Update Notification) [2], as outlined in Section 3.2.1, to the MAG with Notification Reason set to QOS_SERVICE_REQUEST and Acknowledgement Requested flag set to 1. The Operational Code in the QoS option is set to ALLOCATE, and the Traffic Selector identifies the flow for QoS.
（2）LMAは、セクション3.2.1で概説されているように、通知理由がQOS_SERVICE_REQUESTに設定され、確認要求フラグが1に設定されたMAGに、PMIPv6 UPN（更新通知）[2]を送信します。QoSオプションのオペレーションコードはALLOCATEに設定すると、トラフィックセレクタはQoSのフローを識別します。
The LMA QoS parameters include Guaranteed-DL-Bit-Rate/Guaranteed-UL-Bit-Rate and Aggregate-Max-DL-Bit-Rate/Aggregate-Max-UL-Bit-Rate for the flow. The reserved bandwidth for flows is calculated separately from the non-reserved session bandwidth.
LMA QoSパラメータには、フローの保証されたDLビットレート/保証されたULビットレートおよび集約された最大DLビットレート/集約された最大ULビットレートが含まれます。フローの予約済み帯域幅は、予約されていないセッション帯域幅とは別に計算されます。
(3) If there are sufficient resources to satisfy the request, the AP/ MAG sends an ADDTS Reserve Request (IEEE 802.11aa) specifying the QoS reserved for the traffic stream, including the TSPEC and TCLAS elements mapped from the PMIPv6 QoS Traffic Selector to identify the flow.
（3）要求を満たすのに十分なリソースがある場合、AP / MAGはADDTS Reserve Request（IEEE 802.11aa）を送信し、PMIPv6 QoSトラフィックセレクターからマップされたTSPECおよびTCLAS要素を含む、トラフィックストリーム用に予約されたQoSを指定します。流れを特定します。
PMIPv6 parameters are mapped to TCLAS (Table 1) and TSPEC (Table 4). If there are insufficient resources at the AP/WLC, the MAG will not send an ADDTS message and will continue the processing of step 5.
PMIPv6パラメータは、TCLAS（表1）およびTSPEC（表4）にマッピングされます。 AP / WLCに十分なリソースがない場合、MAGはADDTSメッセージを送信せず、ステップ5の処理を続行します。
The higher-level stream identifier in IEEE 802.11aa should be encoded as discussed in Section 3.2.2.
IEEE 802.11aaの上位レベルのストリーム識別子は、セクション3.2.2で説明されているようにエンコードする必要があります。
(4) MN accepts the QoS reserved in the network and replies with ADDTS Reserve Response.
（4）MNはネットワークで予約されたQoSを受け入れ、ADDTS予約応答で応答します。
(5) The MAG (AP/WLC) replies with a UPA confirming the acceptance of QoS options and Operational Code set to RESPONSE. The AP/WLC polices flows based on the new QoS.
（5）MAG（AP / WLC）は、応答オプションに設定されたQoSオプションとオペレーションコードの受け入れを確認するUPAで応答します。 AP / WLCは、新しいQoSに基づいてフローをポリシングします。
If there are insufficient resources at the AP in step 3, the MAG sends a response with UPA status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (130).
ステップ3でAPに十分なリソースがない場合、MAGはUPAステータスコードをCANNOT_MEET_QOS_SERVICE_REQUESTに設定して応答を送信します（130）。
Acknowledgements
謝辞
The authors thank the NETEXT Working Group for the valuable feedback to different versions of this specification. In particular, the authors wish to thank Sri Gundavelli, Georgios Karagianis, Rajeev Koodli, Kent Leung, Marco Liebsch, Basavaraj Patil, Pierrick Seite, and Hidetoshi Yokota for their suggestions and valuable input. The authors also thank George Calcev, Mirko Schramm, Mazin Shalash, and Marco Spini for detailed input on parameters and scheduling in IEEE 802.11 and 3GPP radio networks.
著者は、この仕様のさまざまなバージョンに対する貴重なフィードバックを提供してくれたNETEXTワーキンググループに感謝します。特に、著者は、彼らの提案と貴重な情報提供に対して、Sri Gundavelli、Georgios Karagianis、Rajeev Koodli、Kent Leung、Marco Liebsch、Basavaraj Patil、Pierrick Seite、Hidetoshi Yokotaに感謝します。著者はまた、IEEE 802.11および3GPP無線ネットワークでのパラメータとスケジューリングの詳細な入力について、George Calcev、Mirko Schramm、Mazin Shalash、およびMarco Spiniに感謝します。
Authors' Addresses
著者のアドレス
John Kaippallimalil Huawei 5340 Legacy Dr., Suite 175 Plano, TX 75024 United States
John Kaippallimalil Huawei 5340 Legacy Dr.、Suite 175 Plano、TX 75024 United States
EMail: john.kaippallimalil@huawei.com
Rajesh Pazhyannur Cisco 170 West Tasman Drive San Jose, CA 95134 United States
Rajesh Pazhyannur Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
EMail: rpazhyan@cisco.com
Parviz Yegani Juniper 1194 North Mathilda Ave. Sunnyvale, CA 94089-1206 United States
Parviz Yegani Juniper 1194 North Mathilda Ave.サニーベール、CA 94089-1206アメリカ合衆国
EMail: pyegani@juniper.net