



IETF                                                   J. Kaippallimalil
Internet-Draft                                                    Huawei
Intended status: Informational                             R. Pazhyannur
Expires: October 12, 2015                                          Cisco
                                                               P. Yegani
                                                                 Juniper
                                                          April 10, 2015


         Mapping PMIPv6 QoS Procedures with WLAN QoS Procedures
                   draft-ietf-netext-pmip-qos-wifi-08

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 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-2012, 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.

Status of This Memo

   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 October 12, 2015.






Kaippallimalil, et al.  Expires October 12, 2015                [Page 1]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     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  . . . . . . .  10
     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 . . . . . . .  13
   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.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Appendix A.  LMA Initiated QoS Service Flow with IEEE 802.11aa  .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   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



Kaippallimalil, et al.  Expires October 12, 2015                [Page 2]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


   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 MAG 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.

   - Procedure Mapping:

       PMIPv6 [RFC 7222] defined procedures for QoS setup maybe
       triggered by the LMA or MAG.  IEEE 802.11 QoS setup on the other
       hand is always triggered by the MN (IEEE 802.11 QSTA).  The end-




Kaippallimalil, et al.  Expires October 12, 2015                [Page 3]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


       to-end QoS setup across these network segments should accommodate
       both network triggered and end-user triggered 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 Retention Priority (ARP) in PMIPv6 QoS
       have no equivalent in 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.

   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.

1.1.  Abbreviations




























Kaippallimalil, et al.  Expires October 12, 2015                [Page 4]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


              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

1.2.  Definitions

   Peak Data Rate





Kaippallimalil, et al.  Expires October 12, 2015                [Page 5]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


       In WMM, 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].  IP packet including header is included in the
       data rate.

       TSPECs for both uplink and downlink may contain Peak Data Rate.

   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].  IP packet
       including header is included in the data rate.

       TSPECs for both uplink and downlink must contain the Mean Data
       Rate.

   Mimimum Data Rate

       In WMM, 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].  IP packet including header is included in the
       data rate.

       Minimum Data Rate is not used in QoS provisioning described here.

   QCI

       Quality of Service 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].

   STA

       A station (STA) is a device that has the capability to use the
       802.11 protocol.  For example, a station maybe a laptop, a
       desktop PC, access point or WiFi phone [3].

       An STA that implements the QoS facility is a QoS Station (QSTA)
       [3].

   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].

   TCLAS



Kaippallimalil, et al.  Expires October 12, 2015                [Page 6]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


       The TCLAS element specifies an element that contains a set of
       parameters necessary to identify incoming MSDU (MAC Service Data
       Unit) that belong to a particular TS (Traffic Stream) [3].

2.  Overview of IEEE 802.11 QoS

   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.

3.  Mapping QoS Procedures between IEEE 802.11 and PMIPv6

   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



Kaippallimalil, et al.  Expires October 12, 2015                [Page 7]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


   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.

3.1.  MN Initiated QoS Service Request

3.1.1.  MN Initiated QoS Reservation Request

   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.




Kaippallimalil, et al.  Expires October 12, 2015                [Page 8]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


   (0) The MN establishes a connectivity session as described in [1],
       Section 3.1, MAG-initiated QoS service request, steps 1-4.  At
       this point, a connection with PMIPv6 tunnel is established to the
       LMA.  This allows the MN to start application level signaling.

   (1) The trigger for 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]).

       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.

       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 to subsequent QoS request may be used.  This is not
       described further here, but it maybe 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
       (not desired).  Parameter mapping in this case is shown in
       Table 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 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.

       If TCLAS is not present (when WMM-AC is used), TCLAS maybe
       derived from information in upper layer protocols (as described
       in step 1) and populated in Traffic Selector.  If TCLAS cannot be
       derived, the Traffic Selector field is not included in the QoS
       options.

   (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, TSPEC parameters in
       Table 4.






Kaippallimalil, et al.  Expires October 12, 2015                [Page 9]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


       Reserved bandwidth for flows are accounted separately from the
       non-reserved session bandwidth.  The Traffic Selector identifies
       the flow for which the QoS reservations are made.

       If the LMA offers downgraded QoS values to the MAG, it should
       send a PBU to LMA with operational code set to DE-ALLOCATE (the
       LMA would respond with PBA to confirm completion of the request).

   (4) The AP/MAG provisions the corresponding QoS and replies with
       ADDTS Response containing authorized QoS in TSPEC and flow
       identification in TSPEC and ResultCode set to SUCCESS.

       The AP polices these flows according to the QoS provisioning.

       If in step (3), 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:

       -   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.

       -   if LMA cannot meet QoS service request, ResultCode is set to
         TCLAS_RESOURCES_EXHAUSTED.

       REJECTED_WITH_SUGGESTED_CHANGES and TCLAS_RESOURCES_EXHAUSTED
       results in the rejection of the QoS reservation, but does not
       cause the removal of the session itself.

3.1.2.  MN Initiated QoS De-allocation 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.













Kaippallimalil, et al.  Expires October 12, 2015               [Page 10]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


                                 +-----------+
    +----+                       |+--+  +---+|             +-------+
    | 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

   (0) The MN establishes and reserves QoS resources.  When the
       application session terminates, the MN prepares to release QoS
       resources.

   (1) MN releases its own internal resources and sends a DELTS Request
       to the AP with TS (Traffic Stream) INFO.

   (2) AP receives the DELTS request, releases local resources and
       responds to MN with a DELTS response.

   (3) MAG initiates a PBU, operational code set to DE-ALLOCATE and with
       Traffic Selector constructed from TCLAS and PMIPv6 QoS parameters
       from TSPEC.

       When TLCAS is not present, the MAG should de-allocate all flows
       with the same access category (AC) 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,



Kaippallimalil, et al.  Expires October 12, 2015               [Page 11]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


       then the MAG will have at most one QoS Service request per access
       category (AC).

   (4) LMA receives the PBU and releases local resources.  The LMA then
       responds with a PBA.

   It should be noted that steps 3 and 4 can proceed independently of
   the DELTS Response (step 2).

3.2.  LMA Initiated QoS Service Request

3.2.1.  LMA Initiated QoS Reservation Request

   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.







Kaippallimalil, et al.  Expires October 12, 2015               [Page 12]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


3.2.2.  Discussion on QoS Request Handling with IEEE 802.11aa

   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.

3.2.3.  LMA Initiated QoS De-allocation 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, the
   network initiates the release of QoS resources.























Kaippallimalil, et al.  Expires October 12, 2015               [Page 13]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


                                  +-----------+
    +----+                       |+--+  +---+|            +-------+
    | 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.

   (1) LMA sends a UPN with QoS options identifying the flow for which
       QoS resources are to be released, and operation code set to DE-
       ALLOCATE.  No additional LMA QoS parameters are sent.

   (2) MAG replies with UPA confirming the acceptance and operation code
       set to RESPONSE.

   (3) 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



Kaippallimalil, et al.  Expires October 12, 2015               [Page 14]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


       Selector into a TCLAS element.  In the case where the AP does not
       support TCLAS (for example a WMM-AC compliant AP) then the AP
       SHALL only use the Access Category.  The AP sends a DELTS Request
       with TS INFO identifying the reservation.

   (4) MN sends DELTS Response confirming release.

   It should be noted that steps 3 and 4 can proceed independently of
   the UPA (step 2).

4.  Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters

4.1.  Connection Parameters

   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)     |
      +--------------------------------+----------------------------+

           Table 1: IEEE 802.11 - PMIPv6 QoS Connection mapping

   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.









Kaippallimalil, et al.  Expires October 12, 2015               [Page 15]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


        +------------------------------+--------------------------+
        |       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

   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:

   (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.

   (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])and associates subsequent ADDTS
       request using heuristics and then derives the IP flow/Traffic
       Selector field.

4.2.  QoS Class

   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].

















Kaippallimalil, et al.  Expires October 12, 2015               [Page 16]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


        +-----+------+-----------+---------+----------------------+
        | QCI | DSCP | 802.1D UP |  WMM 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 | e-mail               |
        +-----+------+-----------+---------+----------------------+

         Table 3: QoS Mapping between QCI/DSCP, 802.1D UP, WMM AC

   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.

4.3.  Bandwidth

   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 |
          +-------------------------+---------------------------+

       Table 4: Bandwidth Parameters for Admission Controlled Flows





Kaippallimalil, et al.  Expires October 12, 2015               [Page 17]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


   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.

5.  Security Considerations

   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-2012 [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.

6.  IANA Considerations

   No IANA assignment of parameters are required.







Kaippallimalil, et al.  Expires October 12, 2015               [Page 18]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


7.  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, 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.

8.  References

8.1.  Normative References

   [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.

8.2.  Informative References

   [3]        IEEE, "802.11-2012 - 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.",
              March 2012.

   [4]        Wi-Fi Alliance, "Wi-Fi Multimedia Technical Specification
              (with WMM-Power Save and WMM-Admission Control) Version
              1.2.0.", May 2012.

   [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-2012.", May 2012.

   [6]        3GPP, "Guidelines for IPX Provider networks (Previously
              Inter-Service Provider IP Backbone Guidelines) Version
              11.0", GSMA Official Document IR.34 v11.0, November 2014.







Kaippallimalil, et al.  Expires October 12, 2015               [Page 19]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


   [7]        3GPP, "3rd Generation Partnership Project; 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.

   [8]        3GPP, "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; Policy
              and Charging Control Architecture (Release 13)", 3GPP TS
              23.203 13.2.0, December 2014.

   [9]        Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [10]       Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

Appendix A.  LMA Initiated QoS Service Flow with IEEE 802.11aa

                              +-----------+
    +----+                    |+--+  +---+|           +-------+
    | 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.



Kaippallimalil, et al.  Expires October 12, 2015               [Page 20]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


   (0) MN sets up best effort connectivity session.  This allows the MN
       to perform application level signaling and setup.

   (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.

       The LMA reserves resources for the flow requested.

   (2) LMA sends 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
       value of 1.  The operational code in QoS option SHOULD be set to
       ALLOCATE and the Traffic Selector identifies the flow for 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 are
       accounted separately from the non-reserved session bandwidth.

   (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 TSPEC and TCLAS
       element mapped from PMIPv6 QoS Traffic Selector to identify the
       flow.

       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 and ADDTS message and will continue
       processing of step (5).

       Higher level StreamId in IEEE 802.11aa should be encoded as
       discussed in Section 3.2.2.

   (4) MN accepts the QoS reserved in the network and replies with ADDTS
       Reserve Response.

   (4) The MAG (AP/WLC) replies with UPA confirming the acceptance of
       QoS options and operational code set to RESPONSE.  The AP/WLC
       polices flows based on the new 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).







Kaippallimalil, et al.  Expires October 12, 2015               [Page 21]

Internet-Draft               WiFi PMIPv6 QoS                  April 2015


Authors' Addresses

   John Kaippallimalil
   Huawei
   5340 Legacy Dr., Suite 175
   Plano, TX  75024
   USA

   Email: john.kaippallimalil@huawei.com


   Rajesh Pazhyannur
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: rpazhyan@cisco.com


   Parviz Yegani
   Juniper
   1194 North Mathilda Ave.
   Sunnyvale, CA  94089-1206
   USA

   Email: pyegani@juniper.net
























Kaippallimalil, et al.  Expires October 12, 2015               [Page 22]
