| IETF | J. Kaippallimalil |
| Internet-Draft | Huawei |
| Intended status: Informational | R. Pazhyannur |
| Expires: September 5, 2015 | Cisco |
| P. Yegani | |
| Juniper | |
| March 4, 2015 |
Mapping PMIPv6 QoS Procedures with WLAN QoS Procedures
draft-ietf-netext-pmip-qos-wifi-07
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 Mobility 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, Wi-Fi Multimedia - Admission Control (WMM-AC) describes 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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), 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) Wi-Fi segment and 2) 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 Mobility Access Gateway (MAG) and Local Mobility Anchor (LMA) provisions the per MN QoS policies in the MAG. Further details on policy configuration and PCF (Policy Control Function) can be found in [1], Section 6.1. In the IEEE 802.11 access network modeled here, the MAG is located at the Access Point (AP)/ Wireless LAN Controller (WLC). Figure 1 below provides an overview of the entities and protocols.
+-----+ +-------+
| 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
MN and Access Point AP use IEEE 802.11 QoS mechanisms to setup QoS flows in the Wi-Fi segment. The MAG and LMA setup QoS flows using PMIPv6 QoS procedures. The protocols and mechanisms between AP and MAG are out of scope of this document. Some implementations may have AP and MAG in the same network node. However, this document does not exclude various deployments including those where AP and WLC are separate nodes, or the AG control and data planes are separate.
The recommendations in this document use IEEE 802.11 QoS and PMIPv6 QoS [1] mechanisms. State machines for QoS policy setup in IEEE 802.11 and PMIPv6 operate differently. Guidelines for installing QoS in the MN using 802.11 and PMIPv6 segments, and for mapping parameters between them are outlined below.
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.
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.
| AAA | Authentication Authorization Accounting |
| AC | Access Category |
| ADDTS | ADD Traffic Stream |
| AIFS | Arbitration Inter-Frame Space |
| ALG | Application Layer Gateway |
| AMBR | Aggregate Maximum Bit Rate |
| ARP | Allocation and Retention Priority |
| 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 | Mobility 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 |
IEEE 802.11-2012 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, Background. The prioritized access is achieved by using access category 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).
A subset of the QoS mechanisms is defined in WMM - a Wi-Fi Alliance certification of support for a set of features from an 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 802.11e. WMM uses the 802.1P classification scheme developed by the IEEE (which is now a part of the 802.1D specification). The 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 is described in Chapters 3 and 4 for WMM based QoS provisioning
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 AC 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.
The QoS signaling in IEEE 802.11-2012 is initiated by the (non-AP) STA (by sending an ADDTS request). This specification references procedures in IEEE 802.11-2012, WMM and 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 PMIPv6 QoS request. In the second scenario, the LMA can push the QoS configuration to the MAG. However, there are no standards defined way for the AP to initiate a QoS service request to the MN. Recommendations to setup QoS in both these cases are described in this section.
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 PMIPv6 Proxy Binding Update (PBU)/ Proxy Binding Acknowledgement (PBA) sequence with QoS options exchanged with the LMA. Details of the QoS provisioning for the flow are described below.
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 PMIPv6 PBU/PBA sequence with QoS options exchanged with the LMA. Details of the QoS provisioning for the flow are described below.
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) establish connection session to 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: MN initiated QoS service request
In this use case shown in Figure 2, the MN initiates the QoS service request.
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 shown in Figure 3, the MN initiates the release of QoS resources.
+-----------+
+----+ |+--+ +---+| +-------+
| 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
It should be noted that steps 3 and 4 can proceed independently of the DELTS Response (step 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 are no standards 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.
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 a 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.
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-LMA based on previous PMIPv6 QoS procedures. If the MN subsequently requests for data rates of x Mbps or less, the AP can accept it 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 re-negotiate the QoS resource and ask for increased QoS resources or the AP should reject the QoS request.
The network initiated QoS service request scenario poses some challenges outlined here. IEEE 802.11-2012 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-2012) 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 understood by the MN and AP that provides a common stream identifier to both ends. Alternately, the 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.
Appendix A outlines a protocol sequence with PMIPv6 UPN/UPA if the above 802.11aa issues can be resolved.
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.
+-----------+
+----+ |+--+ +---+| +-------+
| 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
In this use case shown in Figure 4, the network initiates the release of QoS resources. When the application session terminates, the LMA receives notification that the session has terminated. The LMA releases local QoS resources associated with the flow and initiates signaling to release QoS resources in the network.
It should be noted that steps 3 and 4 can proceed independently of the UPA (step 2).
TSPEC in IEEE 802.11 is used to reserve QoS for a traffic stream (MN MAC, TS(Traffic Stream) id). The IEEE 802.11 QoS reservation is for IEEE 802.11 frames associated with an MN's MAC address.
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.
QoS reservations in 802.11 are made for a traffic stream (identified in TCLAS) and correspond to PMIPv6 QoS session parameters (identified by 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.
| 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) |
If the MN or AP is not able to convey flow parameters in TCLAS, the QoS reservation request in 802.11 are derived as shown in Table 2.
| 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) |
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:
Table 3 contains a mapping between Access Class (WMM AC) and 802.1D User Priority (UP) tag in IEEE 802.11 frames, and DSCP in IP data packets. The table also provides the mapping between Access Class (WMM 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].
| QCI | DSCP | 802.1D UP | WMM AC | Example Services |
|---|---|---|---|---|
| 1 | EF | 6(V0) | 3 AC_VO | conversational |
| 2 | EF | 6(V0) | 3 AC_VO | conversational video |
| 3 | EF | 6(V0) | 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 |
The MN tags all data packets with DSCP and 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.
For QoS reservations, TSPEC uses WMM AC values and PMIPv6 QoS uses corresponding DSCP values in Traffic Class (TC). IEEE 802.11 QoS Access Class AC_VO, AC_VI are used for QoS reservations. AC_BE, AC_BK should not be used in reservations.
When WMM-AC specifications that do not contain TCLAS are used, it is only possible to have one reservation per Traffic Class / access category (AC). PMIPv6 QoS will not contain any flow specific attributes like Traffic Selector.
Bandwidth parameters that need to be mapped between IEEE 802.11 and PMIPv6 QoS are shown in Table 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 |
In PMIPv6 QoS [1], services using a sending rate smaller than or equal to Guaranteed Bit Rate (GBR) can in general assume 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].
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.
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 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.
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. 802.11 [3] provides the means to secure management frames that are used for ADDTS and DELTS. PMIPv6 [9] specification 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.
The QoS mappings themselves do not introduce additional security concerns.
No IANA assignment of parameters are required.
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, Rajeev, Koodli, Georgios Karagianis, Kent Leung, Marco Liebsch, Basavaraj Patil, Pierrick Seite, 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.
| [1] | Liebsch, M., Seite, P., Yokota, H., Korhonen, J. and S. Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6", RFC 7222, May 2014. |
| [2] | Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H. and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, November 2013. |
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+----------------------------------------------------------------+
| (0) establish connection session to 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
In this use case shown in Figure 5, the LMA initiates the QoS service request and IEEE 802.11aa is used to setup QoS reservation in the Wi-Fi segment.