NETEXT WG                                            John Kaippallimalil
Internet-Draft                                                    Huawei
Intended Status: Informational                      Rajesh S. Pazhyannur
Expires: June 5, 2015                                              Cisco
                                                           Parviz Yegani
                                                                 Juniper
                                                        December 2, 2014


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

Abstract

   This document provides guidelines for achieving end to end QoS in a
   PMIPv6 domain where the access network is based on IEEE 802.11.
   RFC 7222 describes QoS negotiation between a MAG and 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, 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 to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html




Kaippallimalil, et al.    Expires June 5, 2015                  [Page 1]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


Copyright and License Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . .  5
   2. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . .  5
   3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 . . . . .  6
     3.1. MN Initiated QoS Service Request  . . . . . . . . . . . . .  6
       3.1.1. MN Initiated QoS Service Request  . . . . . . . . . . .  6
       3.1.2. MN Initiated QoS De-allocation Request  . . . . . . . .  9
     3.2. LMA Initiated QoS Service Request . . . . . . . . . . . . . 10
       3.2.1. LMA Initiated QoS Reservation Request . . . . . . . . . 10
       3.2.2. Discussion on QoS Request Handling with IEEE 802.11aa . 11
       3.2.3. LMA Initiated QoS De-allocation Request . . . . . . . . 11
   4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters . . . 13
     4.1 Connection Parameters  . . . . . . . . . . . . . . . . . . . 13
     4.2 QoS Class  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.3 Bandwidth  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 16
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
   7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 16
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1. Normative References  . . . . . . . . . . . . . . . . . . . 17
     8.2. Informative References  . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   APPENDIX A: LMA Initiated QoS Service Flow with IEEE 802.11aa  . . 19









Kaippallimalil, et al.    Expires June 5, 2015                  [Page 2]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


1. Introduction

   [RFC 7222] describes an access network independent way to negotiate
   QoS for PMIPv6 mobility sessions. IEEE 802.11, WMM, WMM-AC describe
   ways to provide QoS for Wi-Fi traffic between the STA and 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 MAG and LMA provisions
   the per MN QoS policies in the MAG. 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 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 [RFC 7222] 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



Kaippallimalil, et al.    Expires June 5, 2015                  [Page 3]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


      always triggered by the MN (IEEE 802.11 QSTA). The end-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 ARP in PMIPv6 QoS have no equivalent in IEEE
      802.11.

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2. Definitions

   Peak Data Rate
       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 [WMM 1.2.0]. 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 [WMM1.2.0]. IP
       packet including header is included in the data rate.

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

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

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




Kaippallimalil, et al.    Expires June 5, 2015                  [Page 4]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


   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, PDN, access point or WiFi phone [802.11-2012].

   TSPEC
       The TSPEC element in IEEE 802.11 contains the set of parameters
       that define the characteristics and QoS expectations of a traffic
       flow [802.11-2012].

   TCLAS
       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) [802.11-
       2012].

1.3. Abbreviations

   AAA          Authentication Authorization Accounting
   AC           Access Category
   ADDTS                ADD Traffic Stream
   AMBR         Aggregate Maximum Bit Rate
   ARP          Allocation and Retention Priority
   AP           Access Point
   DELTS                DELete Traffic Stream
   DSCP         Differentiated Services Code Point
   EPC          Enhanced Packet Core
   GBR          Guaranteed Bit Rate
   MAG          Mobility Access Gateway
   MBR          Maximum Bit Rate
   MN           Mobile Node
   PCF          Policy Control Function
   QCI          QoS Class Indicator
   QoS          Quality of Service
   STA          Station
   TC           Traffic Class
   TCLAS                Type Classification
   TSPEC                Traffic Conditioning Spec
   WLC          Wireless Controller

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): Voice, Video, Best-Effort, Background. The
   prioritized access is achieved by using access category specific



Kaippallimalil, et al.    Expires June 5, 2015                  [Page 5]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


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

3.1. MN Initiated QoS Service Request

3.1.1. MN Initiated QoS Service 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



Kaippallimalil, et al.    Expires June 5, 2015                  [Page 6]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


   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

    [0] The MN establishes a connectivity session as described in [RFC
        7222], 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).

        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



Kaippallimalil, et al.    Expires June 5, 2015                  [Page 7]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


        derive flow specific attributes like Traffic Selector in PMIPv6.
        In this case, the IP flow details are derived from information
        in upper layer protocols (e.g. SIP), or 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.

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

        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.




Kaippallimalil, et al.    Expires June 5, 2015                  [Page 8]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


        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 policy
   server, 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  |
      +-+--+                       ++-++--+-+-++             +---+---+
        |                             |     |                    |
      +-------------------------------------------------------------+
      |         [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(QoSx,DE-ALLOC)[3]
        |                             |     |------------------->|Policy
        |                             |     |                    |<---->
        |                             |     |                    |Update
        |                             |     |PBA(QoSx,RESPONSE)[4]
        |                             |     |<-------------------|
        |                             |     |                    |

      Figure 3: Network 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.



Kaippallimalil, et al.    Expires June 5, 2015                  [Page 9]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


    [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 (QoSx).

        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,
        then the MAG will have at most one QoS Service request per
        access category (AC).

    [4] LMA receives the PBU, releases local resources and informs
        policy server. The LMA then responds with a PBA.

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 (see RFC 7222 for further details). 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



Kaippallimalil, et al.    Expires June 5, 2015                 [Page 10]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


   ask for increased QoS resources or the AP should reject the QoS
   request.

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 (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 policy
   server, 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 June 5, 2015                 [Page 11]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


                                   +-----------+
      +----+                       |+--+  +---+|            +-------+
      | MN |                       ||AP|  |MAG||            |  LMA  |
      +-+--+                       ++-++--+-+-++            +---+---+
        |                             |     |                   |
      +-------------------------------------------------------------+
      |         [0] Establishment of application session            |
      |              and reservation of QoS resources               |
      |                                                             |
      |                  ( Session in progress)                     |
      |                                                             |
      |               Release of application session                |
      +-------------------------------------------------------------+
        |                             |     |                   | Policy
        |                             |     |                   |<------
        |                             |     |UPN(QoSx,DE-ALLOC) |  [1]
        |                             |     |<------------------|
        |                             |<----|        [2]        |
        |                             |---->|UPA(QoSx,RESPONSE) |
        |                             |     |------------------>|
        |                             |     |        [3]        |
        |                             |     |                   |
        | DELTS Request (TS INFO)[4]  |     |                   |
        |<----------------------------|     |                   |
        | DELTS Response (TS INFO)[5] |     |                   |
        |---------------------------->|     |                   |
        |                             |     |                   |

      Figure 5: LMA initiated QoS resource release

    [0] The MN establishes and reserves QoS resources.
        When the application session terminates, the policy server
        receives notification that the session has terminated.

    [1] LMA receives a policy update indicating that QoS for flow (QoSx)
        should be released. The LMA releases local resources associated
        with the flow.

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

    [3] MAG replies with UPA confirming the acceptance and operation
        code set to RESPONSE.

    [4] 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



Kaippallimalil, et al.    Expires June 5, 2015                 [Page 12]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


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

    [5] MN sends DELTS Response confirming release.

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 [RFC 7222] 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 June 5, 2015                 [Page 13]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


      +------------------------------+------------------------------+
      |    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 [WMM-1.2.0] 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) or session level signaling (e.g.
          3GPP WLCP (WLAN Control Protocol) [TS23.402])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).

















Kaippallimalil, et al.    Expires June 5, 2015                 [Page 14]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


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

      In PMIPv6 QoS [RFC 7222], services using a sending rate smaller
      than or equal to Guaranteed Bit Rate (GBR) can in general assume



Kaippallimalil, et al.    Expires June 5, 2015                 [Page 15]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


      that congestion related packet drops will not occur [TS 23.203].
      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 [WMM 1.2.0] 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 [RFC 7222].

      IEEE 802.11 TSPEC requests do not require all fields to be
      completed. [WMM 1.2.0] 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 [802.11-2012] provides the
      means to secure management frames that are used for ADDTS and
      DELTS. PMIPv6 [RFC 5213] 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.

7. Acknowledgements

      The authors thank the NetExt Working Group for the valuable



Kaippallimalil, et al.    Expires June 5, 2015                 [Page 16]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


      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
   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7222]     Liebsch, et al., "Quality of Service Option for Proxy
                 Mobile IPv6", RFC 7222, May 2014.

   [RFC 7077]    Krishnan, et al., "Update Notifications for Proxy
                 Mobile IPv6", RFC 7077, November 2013.

   [RFC 5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing
                 an IANA Considerations Section in RFCs", BCP 26, RFC
                 5226, May 2008.

8.2. Informative References

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

   [WMM 1.2.0]   Wi-Fi Multimedia Technical Specification (with WMM-
                 Power Save and WMM-Admission Control) Version 1.2.0.

   [802.11aa]    Wireless LAN Medium Access Control (MAC) and Physical
                 Layer (PHY) Specification, Amendment 2: MAC
                 Enhancements for Robust Audio Video Streaming, IEEE
                 802.11aa-2012.

   [GSMA-IR34]   Inter-Service Provider Backbone Guidelines 9.1, 13 May
                 2013.

   [TS23.402]    Architecture Enhancements for non-3GPP accesses
                 (Release 12), 3GPP TS 23.402, V12.6.0 (2014-09).

   [TS23.203]    Policy and Charging Control Architecture, (Release 13),
                 3GPP TS 23.203, V13.1.0 (2014-09).



Kaippallimalil, et al.    Expires June 5, 2015                 [Page 17]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


   [RFC 5213]    Gundavelli, et al., "Proxy Mobile IPv6", RFC 5213,
                 August 2008.


Authors' Addresses

                 John Kaippallimalil
                 5340 Legacy Drive, Suite 175
                 Plano, Texas 75024

                 E-Mail: john.kaippallimalil@huawei.com


                 Rajesh Pazhyannur
                 170 West Tasman Drive
                 San Jose, CA 95134

                 E-Mail: rpazhyan@cisco.com


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

                 E-Mail: pyegani@juniper.net


























Kaippallimalil, et al.    Expires June 5, 2015                 [Page 18]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


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 option)[2]| Update[1]
        | ADDTS Reserve Request    |     |<-----------------|
        |      (TCLAS, TSPEC)[3]   |<----|                  |
        |<-------------------------|     |                  |
        | ADDTS Reserve Response   |     |                  |
        |      (TCLAS, TSPEC)[4]   |     |                  |
        |------------------------->|     |                  |
        |                          |---->|UPA(QoS option)[5]|
        |                          |     |----------------->|
        |                          |     |                  |

      Figure 6: LMA initiated QoS service request with 802.11aa

    [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 PMIP UPN (Update Notification), 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



Kaippallimalil, et al.    Expires June 5, 2015                 [Page 19]


Internet-Draft     Mapping PMIPv6 QoS with 802.11 QoS   December 2, 2014


        /MAG sends an ADDTS Reserve Request (IEEE 802.11aa) specifying
        the QoS reserved for the traffic stream including TSPEC and
        TCLAS element mapped from PMIP 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.

    [5] 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 June 5, 2015                 [Page 20]