Quality of Service Option for Proxy Mobile IPv6
draft-ietf-netext-pmip6-qos-02

The information below is for an old version of the document
Document Type Active Internet-Draft (netext WG)
Last updated 2013-02-25
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd None
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
NETEXT WG                                                     M. Liebsch
Internet-Draft                                                       NEC
Intended status: Standards Track                                P. Seite
Expires: August 29, 2013                         France Telecom - Orange
                                                               H. Yokota
                                                                KDDI Lab
                                                             J. Korhonen
                                                  Nokia Siemens Networks
                                                           S. Gundavelli
                                                                   Cisco
                                                       February 25, 2013

            Quality of Service Option for Proxy Mobile IPv6
                   draft-ietf-netext-pmip6-qos-02.txt

Abstract

   This specification defines a new mobility option that can be used by
   the mobility entities in the Proxy Mobile IPv6 domain to exchange
   Quality of Service parameters associated with a subscriber's IP
   flows.  Using the QoS option, the local mobility anchor and the
   mobile access gateway can exchange available QoS attributes and
   associated values.  This enables QoS policing and labeling of packets
   to enforce QoS differentiation on the path between the local mobility
   anchor and the mobile access gateway.  Furthermore, making QoS
   parameters available on the MAG enables mapping these parameters to
   QoS rules being specific to the access technology which operates
   below the mobile access gateway.  After such mapping, QoS rules can
   be enforced on the access technology components, such as an IEEE
   802.11e Wireless LAN controller.

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 August 29, 2013.

Liebsch, et al.          Expires August 29, 2013                [Page 1]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

Copyright Notice

   Copyright (c) 2013 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.

Liebsch, et al.          Expires August 29, 2013                [Page 2]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  7
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7

   3.  Description of the Technical Approach  . . . . . . . . . . . .  8
     3.1.  Technical Scope and Procedure  . . . . . . . . . . . . . .  8
     3.2.  Use Case A -- Handover of Available QoS Context  . . . . .  9
     3.3.  Use Case B -- Establishment of new QoS Context in
           non-3G Access  . . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Use Case C -- Dynamic Update to QoS Policy . . . . . . . . 11
     3.5.  Relevant QoS Attributes  . . . . . . . . . . . . . . . . . 12
     3.6.  Protocol Operation . . . . . . . . . . . . . . . . . . . . 13
       3.6.1.  Handover of existing QoS rules . . . . . . . . . . . . 14
       3.6.2.  Establishment of QoS rules . . . . . . . . . . . . . . 15

   4.  Protocol Considerations  . . . . . . . . . . . . . . . . . . . 16
     4.1.  Mobile Access Gateway Considerations . . . . . . . . . . . 16
     4.2.  Local Mobility Anchor Considerations . . . . . . . . . . . 17

   5.  Quality of Service Option  . . . . . . . . . . . . . . . . . . 18

   6.  Format of the Quality of Service Attribute . . . . . . . . . . 19
     6.1.  Per Mobile Node Aggregate Maximum Downlink Bit Rate  . . . 19
     6.2.  Per Mobile Node Aggregate Maximum Uplink Bit Rate  . . . . 20
     6.3.  Per Mobility Session Aggregate Maximum Downlink Bit
           Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.4.  Per Mobility Session Aggregate Maximum Uplink Bit Rate . . 21
     6.5.  Allocation and Retention Priority  . . . . . . . . . . . . 21
     6.6.  Guaranteed Downlink Bit Rate . . . . . . . . . . . . . . . 23
     6.7.  Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . . . 23
     6.8.  Traffic Selector . . . . . . . . . . . . . . . . . . . . . 24

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     10.2. Informative References . . . . . . . . . . . . . . . . . . 28

   Appendix A.  Information when implementing PMIP based QoS
                support with IEEE 802.11e . . . . . . . . . . . . . . 30

Liebsch, et al.          Expires August 29, 2013                [Page 3]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   Appendix B.  Information when implementing with a Broadband
                Network Gateway . . . . . . . . . . . . . . . . . . . 34

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35

Liebsch, et al.          Expires August 29, 2013                [Page 4]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

1.  Introduction

   Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to
   enable network-based mobility management for mobile nodes (MN).
   Users can access Internet Protocol (IP) based services from their
   mobile device by using different radio access technologies.  Current
   standardization effort considers strong QoS classification and
   enforcement for cellular radio access technologies.  QoS policies are
   typically controlled by a policy control function, whereas the
   policies are enforced by different gateways in the infrastructure,
   such as the LMA and the MAG, as well as by access network elements.
   Policy control and QoS differentiation for access to the mobile
   operator network through alternative non-cellular access technologies
   is not yet considered, even though some of these access technologies
   are able to support QoS by appropriate traffic prioritization
   techniques.  However, handover and IP Flow Mobility using alternative
   radio access technologies, such as IEEE802.16 and Wireless LAN
   according to the IEEE802.11 specification, are being considered by
   the standards [TS23.402], whereas inter-working with the cellular
   architecture to establish QoS policies in alternative access networks
   has not been focussed on so far.

   In particular the Wireless LAN technology has been identified as
   promising alternative technology to complement cellular radio access.
   Since the 802.11e standard provides QoS extensions to WLAN, it is
   beneficial to apply QoS policies to the WLAN access, which enables
   QoS classification of downlink as well as uplink traffic between an
   MN and its LMA.  Three functional operations have been identified to
   accomplish this:

      (a) Maintenance of QoS classification during a handover between
      cellular radio access and WLAN access by means of establishing QoS
      policies in the handover target access network,

      (b) mapping of QoS classes and associated policies between
      different access systems and

      (c) establishment of QoS policies for new data sessions/flows,
      which are initiated while using WLAN access.

   This document specifies an extension to the PMIPv6 protocol, which
   enables the transport of established QoS descriptions between an LMA
   and the MAG by means of a QoS container option in case the QoS policy
   in the WLAN access is not under explicit control of a policy control
   system.  The specified option allows association between IP session
   keys, such as a Differentiated Services Code Point (DSCP), and the
   expected QoS class for this IP session.  Further handling of QoS
   policies between the MAG and the WLAN Controller (WLC) or WLAN Access

Liebsch, et al.          Expires August 29, 2013                [Page 5]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   Point is out of scope of this specification.

Liebsch, et al.          Expires August 29, 2013                [Page 6]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

2.  Conventions and Terminology

2.1.  Conventions

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

2.2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in the Proxy Mobile IPv6 specifications
   [RFC5213], [RFC5844], [RFC5845] and [RFC5846].  Additionally, this
   document uses the following abbreviations:

   o  WLAN (Wireless Local Area Network) - A wireless network.

   o  WTP (Wireless Termination Point): The entity that functions as the
      termination point for the network-end of the IEEE 802.11 based air
      interface from the mobile node.  It is also known as the Wireless
      Access Point.

   o  WLC (Wireless LAN Controller): The entity that provides the
      centralized forwarding, routing function for the user traffic.
      All the user traffic from the mobile nodes attached to the WTP's
      is typically tunneled to this centralized WLAN access controller.

Liebsch, et al.          Expires August 29, 2013                [Page 7]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

3.  Description of the Technical Approach

3.1.  Technical Scope and Procedure

   The QoS option specified in this document supports the setup of
   states on the LMA and the MAG to allow enforcement of QoS policies
   for packet differentiation on the network path between the LMA and
   the MAG providing non-cellular access to the mobile operator network.
   QoS differentiation is typically enabled in the mobile operator's
   network using Differentiated Services techniques in the IP transport
   network, whereas radio access specific QoS differentiation depends on
   the radio technology in use.  Whereas very accurate and fine granular
   traffic classes are specified for the cellular radio access, the IP
   transport network only supports enforcement of few Differentiated
   Services classes according to well-known Differentiated Services Code
   Points (DSCP) [GSMA.IR.34].

   Central control from a Policy Control Function (PCF) is deployed in
   current cellular mobile communication standards to assign an
   appropriate QoS class to an MN's individual flows.  Non-cellular
   access technologies are not yet considered for per-flow QoS policing
   under control of a common PCF.  The QoS option specified in this
   document enables exchange of QoS policies, which have been setup for
   an MN's IP flows on the cellular network, between the LMA and a new
   MAG during handover from the cellular access network to the non-
   cellular access network.  Furthermore, the QoS option can be used to
   exchange QoS policies for new IP flows, which are initiated while the
   MN is attached to the non-cellular MAG.

   Figure 1 illustrates a generalized architecture where the QoS option
   can be used.  During an MN's handover from cellular access to non-
   cellular access, e.g. a wireless LAN (WLAN) radio access network, the
   MN's QoS policy rules, as previously established on the LMA for the
   MN's communication through the cellular access network, are moved to
   the handover target MAG serving the non-cellular access network.
   Such non-cellular MAG can have an access technology specific
   controller or function co-located, e.g. a Wireless LAN Controller
   (WLC), as depicted in option (I) of Figure 1.  Alternatively, the
   access specific architecture can be distributed and the access
   technology specific control function is not co-located with the MAG,
   as depicted in option (II).  In case of a distributed access network
   architecture as per option (II), the MAG and the access technology
   specific control function (e.g. the WLC) must provide some protocol
   for QoS inter-working.  Details of such inter-working are out of
   scope of this specification.

Liebsch, et al.          Expires August 29, 2013                [Page 8]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

           Non-cellular access       |  Cellular Core Network   Cellular
              (e.g. WLAN)            |           +--------+     Access
                                     |           |Policy  |
                                     |           |Control +-----+
                                     |           |Function|     |
             +----+                  |           +---+----+     |
             |WiFi|           (I)    |               |          |
             | AP |---+    +---+---+ |               |          |  ((O))
             +----+   |    |WiFi AR| |  PMIPv6    +-----+     +---+  |
                      +----+ (MAG) +=|============| LMA |=====|MAG+--|
                      |    |  WLC  | |  tunnel    +-----+     +---+  |
             +----+   |    +-------+ |             //
             |WiFi|---+              |            //
             | AP |                  |           //
             +----+           (II)   |          //
                           +-------+ |         //
   +----+    +------+      |WiFi AR| |        //
   |WiFi+----+  WLC +------+ (MAG) |=|=======//
   | AP |    |      |      |       | |
   +----+    +------+      +------ + |
                 ^            ^      |
                 |            |      |
                 +------------+
                QoS inter-working

   Figure 1: Architecture for QoS inter-working between cellular access
                          and non-cellular access

   Based on the architecture illustrated in Figure 1, two key use cases
   can be supported by the QoS option.  Use case A assumes a MN is
   attached to the network through cellular access and its LMA has QoS
   policy rules for the MN's data flows available.  This specification
   does not depend on the approach how the cellular specific QoS
   policies have been configured on the LMA.  During its handover, the
   available QoS policies are established on the handover target MAG,
   which serves the non-cellular access network.  Use case B assumes
   that new policies need to be established for a MN as a new IP flow is
   initiated while the MN is attached to the network through the non-
   cellular network.  These use cases are described in more detail in
   the subsequent sections Section 3.2 and Section 3.3 respectively.

3.2.  Use Case A -- Handover of Available QoS Context

   The MN is first connected to the LTE network and having a multimedia
   session such as a video call with appropriate QoS parameters set by
   the policy control function.  Then, the MN discovers a WiFi AP (e.g.,
   at home or in a cafe) and switches to it provided that WiFi access
   has a higher priority when available.  Not only is the session

Liebsch, et al.          Expires August 29, 2013                [Page 9]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   continued, but also the QoS is maintained after moving to the WiFi
   access.  In order for that to happen, the LMA delivers the QoS
   parameters to the MAG on the WLC via the PMIPv6 signaling and the
   equivalent QoS treatment is provided toward the MN on the WiFi link.

                                              +--------+
                                              |Policy  |
                                              |Control |
                                              |Function|
                                              +---+----+
                                                  |
          +----+       +-------+              +---+----+
    +--+  |LTE |_______|  SGW  |              |  PGW   |
    |MN|~~|eNB |       |       |==============| (LMA)  |
    +--+  +----+       +-------+            //+--------+
     :                                     //
     :                                    //
     V    +----+       +-------+ PMIPv6  //
    +--+  |WiFi|_______|  WLC  |=========
    |MN|~~| AP |       | (MAG) | tunnel
    +--+  +----+       +-------+

                        Figure 2: Handover Scenario

3.3.  Use Case B -- Establishment of new QoS Context in non-3G Access

   A single operator has deployed both a fixed access network and a
   mobile access network.  In this scenario, the operator may wish a
   harmonized QoS management on both accesses.  However the fixed access
   network does not implement a QoS control framework.  So, the operator
   chooses to rely on the 3GPP policy control function, which is a
   standard framework to provide a QoS control, and to enforce the 3GPP
   QoS policy to the Wi-Fi Access network.  The PMIP interface is used
   to realize this QoS policy provisioning.

   The use-case is depicted on Figure 3.  The MN is first attaching to
   the Wi-Fi network.  During attachment process, the LMA, which may be
   in communication with Policy Control Function (this step of the
   process is out of the scope of this document), provides the QoS
   parameters to the MAG piggy-backing the PMIP signaling (i.e.  PBA).
   Subsequently, an application on the MN may trigger the request for
   enhanced QoS resources, e.g., by use of the WMM-API [80211e].  The MN
   may request traffic resources be reserved using L2 signalling, e.g.,
   sending an ADDTS message [80211e].  The request is relayed to the MAG

Liebsch, et al.          Expires August 29, 2013               [Page 10]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   which piggybacks the QoS parameters on the PMIP signalling (i.e.  PBU
   initiated on the flow creation).  The LMA, in co-ordination with the
   PCF, can then authorize the enforcement of such QoS policy.  Then,
   the QoS parameters are provided to the MAG piggy-backing the PMIP
   signaling and the equivalent QoS treatment is provided towards the MN
   on the WiFi link.

                                            |
                                            |
                                            | +--------+
                                            | |Policy  |
                                            | |Control |
                                            | |Function|
                                            | +---+----+
                                            |     |
                                            | +---+----+
              +----+       +-------+ PMIPv6 | |  PGW   |
        +--+  |WiFi|_______|  WLC  |========|=| (LMA)  |
        |MN|~~| AP |       | (MAG) | tunnel | +--------+
        +--+  +----+       +-------+        |
                                            |
                         Wi-Fi Access       |
                          Network           |   Cellular
                                            |    Network
                                            |

                     Figure 3: QoS policy provisioning

3.4.  Use Case C -- Dynamic Update to QoS Policy

   A mobile node is attached to the WLAN access and has obtained QoS
   parameters from the LMA for that mobility session.  Having obtained
   the QoS parameters, a new application, e.g.  IMS application, gets
   launched on the mobile node that requires certain QoS support.

   The application on the mobile node initiates the communications via a
   dedicated network function (e.g.  IMS Call Session Control Function).
   Once the communication is established, the application network
   function notifies the PCRF function about the new IP flow.  The PCRF
   function in turn notifies the LMA about the needed QoS parameters
   identifying the IP flow and QoS parameters.  LMA sends a Update
   Notification message [I-D.ietf-netext-update-notifications] to the
   MAG with the "Notification Reason" value set to "Force REREGISTER".

   The MAG, on receiving the Update Notification message, completes the
   PBU/PBA signaling for obtaining the new QoS parameters.  MAG

Liebsch, et al.          Expires August 29, 2013               [Page 11]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   provisions the newly obtained QoS parameters on the access network to
   ensure the newly established IP flow gets some dedicated network
   resources.  Upon termination of the new flow, the application network
   function again notifies the PCRF function for removing the
   established bearers.  The PCRF notifies the LMA for withdrawing the
   QoS resources establishes for that voice flow.  LMA sends a Update
   Notification message to the MAG with the "Notification Reason" value
   set to "Force REREGISTER".  MAG on receiving this message
   UpdateNotification Ack and completes the PBU/PBA signaling for
   obtaining the new QoS parameters.  MAG provisions the newly obtained
   QoS parameters on the access network to ensure the dedicated network
   resources are now removed.

3.5.  Relevant QoS Attributes

   The QoS Option shall at least contain a DSCP value being associated
   with IP flows of a mobility session.  Optional QoS information could
   also be added.  For instance, in order to comply with 3GPP networks
   QoS, at minimum there is a need to convey the following additional
   QoS parameters for each PMIPv6 mobility session:

   1.  Per Mobile Node Aggregate Maximum Bit Rate (MN-AMBR) to both
       uplink and downlink directions.

   2.  Per mobility session Aggregate Maximum Bit Rate (MS-AMBR) to both
       uplink and downlink directions.

   The following attributes represent a useful set of QoS parameters to
   negotiate during the session setup:

   1.  Allocation and Retention Priority (ARP).

   2.  Guaranteed Bit Rate (GBR)

   3.  Maximum Bit Rate (MBR)

   For some optional QoS attributes the signaling can differentiate
   enforcement per mobility session and per IP flow.  Additional
   attributes can be appended to the QoS option, but their definition
   and specification is out of scope of this document and left to their
   actual deployment.

   Informational Note: If DSCP values follow the 3GPP specification and
   deployment, the code point can carry intrinsically additional
   attributes according to a pre-defined mapping table:

Liebsch, et al.          Expires August 29, 2013               [Page 12]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   This is the GSMA/3GPP mapping for EPC/LTE:

   QCI  Traffic Class   DiffServ PHB    DSCP
   1    Conversational       EF        101110
   2    Conversational       EF        101110
   3    Conversational       EF        101110
   4       Streaming        AF41       100010
   5      Interactive       AF31       011010
   6      Interactive       AF32       011100 (Not approved)
   7      Interactive       AF21       010010
   8      Interactive       AF11       001010
   9      Background         BE        000000

3.6.  Protocol Operation

Liebsch, et al.          Expires August 29, 2013               [Page 13]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

3.6.1.  Handover of existing QoS rules

   +--+            +--+             +---+                       +---+
   |MN|            |AP|             |MAG|                       |LMA|
   +--+            +--+             +---+                       +---+
    ||              |                 |     To                    |data
    |+--detach      |                 |  cellular<-==data[DSCP]==-|<----
    +----attach-----+                 |   access             [QoS rules]
    |               |-INFO[MNattach]->|                           |
    |               |                 |------PBU[handover]------->|
    |               |                 |                           |
    |               |                 |<----PBA[QoS option]-------|
    |               |<-INFO[QoSrules]-|                           |
    |               |                 |                           |
    |             Apply            Establish                   Update
    |             mapped          MN's uplink              MN's downlink
    |            QoS rules        DSCP rules                 DSCP rules
    |               |                 +===========================+
    |               |                 |                           |
    |               |(B)              |(A)                        |data
    |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<----
    |               |                 |                           |
    |               |                 |                           |data
    |---data[QC]--->|--->data[DSCP]-->|-=======data[DSCP]=======->|---->
    |               |(C)              |(D)                        |
    |               |                 |                           |

    (A): Apply DSCP at link to AP
    (B): Enforce mapped QoS rules to access technology
    (C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or
         validate MN-indicated QC and apply DSCP on the AP.-MAG link
         according to rule
    (D): Validate received DSCP and apply DSCP according to rule

                      Figure 4: Handover of QoS rules

Liebsch, et al.          Expires August 29, 2013               [Page 14]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

3.6.2.  Establishment of QoS rules

   +--+            +--+             +---+                       +---+
   |MN|            |AP|-------------|MAG|-----------------------|LMA|
   +--+            +--+             +---+                       +---+
    |               |                 |                           |
    |               |                 |                           |
    +----attached---+                 |                      [QoS rules]
    |               |                 |                           |
   new session      |                 |(F)                        |data
    |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|---->
    |               |(E)              |--PBU[update, QoS option]->|(C)
    |               |                 |                     Validate and
    |               |                 |                     add QoS rule
    |               |                 |<----PBA[QoS option]-------|
    |               |<-INFO[QoSrules]-|                     [QoS rules']
    |               |                 |                           |
    |             Apply           Establish                       |
    |            adapted         MN's uplink                      |
    |           QoS rules        DSCP rules                       |
    |               |                 |                           |
    |               |                 |                           |
    |               |                 |                           |data
    |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<----
    |               |                 |                           |
    |               |                 |                           |data
    |---data[QC]--->|--->data[DSCP]-->|-=======data[DSCP]=======->|---->
    |               |                 |                           |
    |               |                 |                           |

    (E): AP may enforce uplink QoS rules according to priority class
         set by the MN
    (F): MAG can enforce a default QoS class until LMA has classified
         the new flow (notified with PBA) or MAG classifies new flow and
         proposes the associated QoS class to the LMA for validation
         (proposed with PBU, notification of validation result with
         PBA)

          Figure 5: Adding new QoS profile for MN initiated flow

Liebsch, et al.          Expires August 29, 2013               [Page 15]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

4.  Protocol Considerations

   For supporting this specification, there are protocol extensions
   needed on both the local mobility anchor and mobile access gateway.
   The following sections identify those extensions.

4.1.  Mobile Access Gateway Considerations

   The conceptual Binding Update List entry data structure maintained by
   the mobile access gateway, described in Section 6.1 of [RFC5213],
   MUST be extended to store the QoS parameters received from the local
   mobility anchor.  QoS parameters can apply either to the flow or to
   the mobility session or to the mobile node.  Specifically, the
   following parameters must be defined.

   1.  Flow Selectors (if QoS parameters are expected to apply at the
       flow level)

   2.  DSCP Value

   3.  List of QoS parameters encoded in TLV format

   If a mobile access gateway is enabled to support Quality of Service
   option, upon accepting a Proxy Binding Acknowledgement with Quality
   of Service option, it SHOULD update the Binding Update List for that
   mobility session with the quality of service parameters received from
   the local mobility anchor.  However, if the mobile access gateway is
   not enabled to support Quality of Service option, it SHOULD just skip
   the option and continue to process the rest of the message.

   The mobility access gateway SHOULD enforce the Quality of Service
   rules on the mobile node's uplink and downlink traffic as notified by
   the local mobility anchor.  The traffic selectors in the received
   Quality of Service option are to be used for the flow identification.
   The DSCP field in the option along with the other parameters in the
   QoS Information field are to be used for the flow treatment.

   In deployments where the mobile access gateway is collocated with a
   WLAN controller, there is interworking needed between the two
   functions for exchanging the Quality of Service parameters.  The WLAN
   controller can potentially deliver the Quality of Service parameters
   to the Access Point/WTP over CAPWAP or other control protocol
   interface.  The specific details on how that is achieved is outside
   the scope of this document.

Liebsch, et al.          Expires August 29, 2013               [Page 16]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

4.2.  Local Mobility Anchor Considerations

   The conceptual Binding Cache entry data structure maintained by the
   local mobility anchor, described in Section 5.1 of [RFC5213], MUST be
   extended to store the Quality of Service parameters received from the
   local mobility anchor.  Specifically, the following parameters must
   be defined.

   1.  Flow Selectors

   2.  DSCP Value

   3.  List of parameters encoded in TLV format

   Upon accepting a Proxy Binding Update message [RFC5213] from a mobile
   access gateway, and if the local mobility anchor is enabled to
   enforce the Quality of Service rules, it SHOULD construct the Quality
   of Service mobility option and include it in the Proxy Binding
   Acknowledgement message.

   The Quality of Service MUST be constructed as specified in Section 5.
   The flow selectors and the parameters for flow treatment MUST be
   included in the option only if QoS policy is expected to apply at the
   flow level.

   The local mobility anchor SHOULD enforce the Quality of Service rules
   on the mobile node's uplink and downlink traffic as specified for
   that mobility session.

Liebsch, et al.          Expires August 29, 2013               [Page 17]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

5.  Quality of Service Option

   A new option, Quality of Service option, is defined for use with a
   Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA)
   messages exchanged between a local mobility anchor and a mobile
   access gateway.  This option is used for providing QoS policies and
   information to the mobile access gateway.

   The alignment requirement for this option is 4n.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |    Reserved   |      DSCP     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   QoS Information (optional)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 6: QoS Option

   o  Type: To be assigned by IANA

   o  Length: 8-bit unsigned integer indicating the length in octets of
      the option, excluding the type and length fields.

   o  Reserved : This field is unused for now.  The value MUST be
      initialized to 0 by the sender and MUST be ignored by the
      receiver.

   o  DSCP: An 6-bit unsigned integer indicating the code point value,
      as defined in [RFC2475] to be used for the flow.

   o  QoS Information: one or more Type-Length-Value (TLV) encoded QoS
      policies.  The interpretation and usage of the QoS information is
      specific to the TLV.

Liebsch, et al.          Expires August 29, 2013               [Page 18]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

6.  Format of the Quality of Service Attribute

   The QoS Attribute are used for carrying QoS policy attributes.  These
   sub-options can be included in the QoS option defined in Section 5.
   The format of this sub-option is as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type       |     Length    |         Option Data           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: Quality of Service Attribute

   QoS Attribute Type:  8-bit unsigned integer indicating the type of
      the QoS Attribute.

      0 -  Reserved

      1 -  Per Mobile Node Aggregate Maximum Downlink Bit Rate

      2 -  Per Mobile Node Aggregate Maximum Uplink Bit Rate

      3 -  Per Mobility Session Aggregate Maximum Downlink Bit Rate

      4 -  Per Mobility Session Aggregate Maximum Uplink Bit Rate

      5 -  Allocation and Retention Priority

      6 -  Traffic Selector

      7 -  Guaranteed Uplink Bit Rate

   Length:  8-bit unsigned integer indicating the number of octets
      needed to encode the Option Data, excluding the Type and Length
      fields.

6.1.  Per Mobile Node Aggregate Maximum Downlink Bit Rate

   The maximum downlink bit rate for a single Mobile Node.  The maximum
   is an aggregate of all mobility session the Mobile Node has.  When
   provided in a request, it indicates the maximum requested bandwidth.
   When provided in an answer, it indicates the maximum bandwidth
   accepted.

Liebsch, et al.          Expires August 29, 2013               [Page 19]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-DL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 1

   o  Length: The length of following data value in octets.  Set to 6.

   o  Max-Bandwidth-DL: is of type unsigned 32 bit integer, and it
      indicates the maximum bandwidth in bits per second for a downlink
      IP flow.  The bandwidth contains all the overhead coming from the
      IP-layer and the layers above, e.g.  IP, UDP, RTP and RTP payload.

6.2.  Per Mobile Node Aggregate Maximum Uplink Bit Rate

   The maximum uplink bit rate for a single Mobile Node.  The maximum is
   an aggregate of all mobility session the Mobile Node has.  When
   provided in a request, it indicates the maximum requested bandwidth.
   When provided in an answer, it indicates the maximum bandwidth
   accepted.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-UL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 2

   o  Length: The length of following data value in octets.  Set to 6.

   o  Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it
      indicates the maximum bandwidth in bits per second for an uplink
      IP flow.  The bandwidth contains all the overhead coming from the
      IP-layer and the layers above, e.g.  IP, UDP, RTP and RTP payload.

6.3.  Per Mobility Session Aggregate Maximum Downlink Bit Rate

   The maximum downlink bit rate for a single specific mobility session
   the Mobile Node has.  When provided in a request, it indicates the
   maximum requested bandwidth.  When provided in an answer, it
   indicates the maximum bandwidth accepted.

Liebsch, et al.          Expires August 29, 2013               [Page 20]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-DL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 3

   o  Length: The length of following data value in octets.  Set to 6.

   o  Max-Requested-Bandwidth-DL: is of type unsigned 32 bit integer,
      and it indicates the maximum bandwidth in bits per second for a
      downlink IP flow.  The bandwidth contains all the overhead coming
      from the IP-layer and the layers above, e.g.  IP, UDP, RTP and RTP
      payload.

6.4.  Per Mobility Session Aggregate Maximum Uplink Bit Rate

   The maximum uplink bit rate for a single specific mobility session
   the Mobile Node has.  When provided in a request, it indicates the
   maximum requested bandwidth.  When provided in an answer, it
   indicates the maximum bandwidth accepted.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-UL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 4

   o  Length: The length of following data value in octets.  Set to 6.

   o  Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it
      indicates the maximum bandwidth in bits per second for an uplink
      IP flow.  The bandwidth contains all the overhead coming from the
      IP-layer and the layers above, e.g.  IP, UDP, RTP and RTP payload.

6.5.  Allocation and Retention Priority

   The allocation and retention priority indicate the priority of
   allocation and retention for the corresponding mobility session or
   flow.  If the attribute is expected to apply at the flow level, the
   traffic selector (Section 6.8) MUST be included in the QoS option.

Liebsch, et al.          Expires August 29, 2013               [Page 21]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Priority-Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Pre-emption-Capability     |  Pre-emption-Vulnerability    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 5

   o  Length: The length of following data values in octets.  Set to 10.

   o  Priority-Level: is of type unsigned 32 bit integer, and it used
      for deciding whether a mobility session establishment or
      modification request can be accepted or needs to be rejected in
      case of resource limitations (typically used for admission control
      of GBR traffic).  The priority-level can also be used to decide
      which existing mobility session to pre-empt during resource
      limitations.  The priority level defines the relative importance
      of a resource request.

      Values 1 to 15 are defined, with value 1 as the highest level of
      priority.

      Values 1 to 8 should only be assigned for services that are
      authorized to receive prioritized treatment within an operator
      domain.  Values 9 to 15 may be assigned to resources that are
      authorized by the home network and thus applicable when a MN is
      roaming.

   o  Pre-emption-Capability: defines whether a service data flow can
      get resources that were already assigned to another service data
      flow with a lower priority level.  The following values are
      defined:

      Enabled (0): This value indicates that the service data flow is
      allowed to get resources that were already assigned to another IP
      data flow with a lower priority level.

      Disabled (1): This value indicates that the service data flow is
      not allowed to get resources that were already assigned to another
      IP data flow with a lower priority level.

   o  Pre-emption-Vulnerability: defines whether a service data flow can
      lose the resources assigned to it in order to admit a service data
      flow with higher priority level.  The following values are

Liebsch, et al.          Expires August 29, 2013               [Page 22]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

      defined:

      Enabled (0): This value indicates that the resources assigned to
      the IP data flow can be pre-empted and allocated to a service data
      flow with a higher priority level.

      Disabled (1): This value indicates that the resources assigned to
      the IP data flow shall not be pre-empted and allocated to a
      service data flow with a higher priority level.

6.6.  Guaranteed Downlink Bit Rate

   The guaranteed downlink bit rate for a specific flow or mobility
   session the Mobile Node has.  When provided in a request, it
   indicates the maximum requested bandwidth.  When provided in an
   answer, it indicates the maximum bandwidth accepted.

   If the attribute is expected to apply at the flow level, the traffic
   selector (Section 6.8) MUST be included in the QoS option.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Guaranteed-DL                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 6

   o  Length: The length of following data value in octets.  Set to 6.

   o  Guaranteed-DL: is of type unsigned 32 bit integer, and it
      indicates the guaranteed bandwidth in bits per second for downlink
      IP flows.  The bandwidth contains all the overhead coming from the
      IP-layer and the layers above, e.g.  IP, UDP, RTP and RTP payload.

6.7.  Guaranteed Uplink Bit Rate

   The guaranteed downlink bit rate for a specific flow or mobility
   session the Mobile Node has.  When provided in a request, it
   indicates the maximum requested bandwidth.  When provided in an
   answer, it indicates the maximum bandwidth accepted.

   If the attribute is expected to apply at the flow level, traffic
   selector (Section 6.8) MUST be included in the QoS option .

Liebsch, et al.          Expires August 29, 2013               [Page 23]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Guaranteed-UL                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 7

   o  Length: The length of following data value in octets.  Set to 6.

   o  Guaranteed-UL: is of type unsigned 32 bit integer, and it
      indicates the guaranteed bandwidth in bits per second for uplink
      IP flows.  The bandwidth contains all the overhead coming from the
      IP-layer and the layers above, e.g.  IP, UDP, RTP and RTP payload.

6.8.  Traffic Selector

   MUST be included if QoS parameters (Options according to Section 6.5
   to Section 6.7) are expected to apply at the flow level

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |   Reserved    |    TS Format  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Traffic Selector ...                   ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 8

   o  Length: The length of following data value in octets.

   o  TS Format: An 8-bit unsigned integer indicating the Traffic
      Selector Format.  Value "0" is reserved and MUST NOT be used.  The
      value of (1) is assigned for IPv4 Binary Traffic Selector, as
      defined in section 3.1 of [RFC6088].

   o  Traffic Selector: variable-length opaque field for including the
      traffic specification identified by the TS format field.

Liebsch, et al.          Expires August 29, 2013               [Page 24]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

7.  IANA Considerations

   This document requires the following IANA actions.

   o  Action-1: This specification defines a new Mobility Header option,
      the Quality of Service (QoS) option.  The format of this option is
      described in Section 5.  The Type value for this option needs to
      be assigned from the same numbering space as allocated for the
      other mobility options, as defined in [RFC6275].

   o  Action-2: This specification defines a new mobility sub-option
      format,Quality of Service Attribute.  The format of this mobility
      sub-option is described in Section 6.  This sub-option can be
      carried in Quality of Service option.  The type values for this
      sub-option needs to be managed by IANA, under the Registry,
      Quality of Service Attribute Registry.  This specification
      reserves the following type values.  Approval of new Quality of
      Service Attribute type values are to be made through IANA Expert
      Review.

      0 -  Reserved

      1 -  Per Mobile Node Aggregate Maximum Downlink Bit Rate

      2 -  Per Mobile Node Aggregate Maximum Uplink Bit Rate

      3 -  Per Mobility Session Aggregate Maximum Downlink Bit Rate

      4 -  Per Mobility Session Aggregate Maximum Uplink Bit Rate

      5 -  Allocation and Retention Priority

      6 -  Traffic Selector

      7 -  Guaranteed Uplink Bit Rate

Liebsch, et al.          Expires August 29, 2013               [Page 25]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

8.  Security Considerations

   The quality of service option defined in this specification is for
   use in Proxy Binding Update and Proxy Binding Acknowledgement
   messages.  This option is carried like any other mobility header
   option as specified in [RFC5213] and does not require any special
   security considerations.  Carrying quality of service information
   does not introduce any new security vulnerabilities.

Liebsch, et al.          Expires August 29, 2013               [Page 26]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

9.  Acknowledgements

   The authors of this document thank the NetExt Working Group for the
   valuable feedback on early versions of this document.  In particular
   the authors want to thank Basavaraj Patil, Behcet Sarikaya, Charles
   Perkins, Dirk von Hugo, Mark Grayson and Tricci So for their valuable
   comments and suggestions to improve this specification.

Liebsch, et al.          Expires August 29, 2013               [Page 27]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              January 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

10.2.  Informative References

   [80211e]   IEEE, "IEEE part 11: Wireless LAN Medium Access
              Control(MAC) and Physical Layer (PHY) specifications.
              Amendment 8: Medium Access Control (MAC) Quality of
              Service Enhancements", 2005.

   [GSMA.IR.34]
              GSMA, "Inter-Service Provider IP Backbone Guidelines 5.0",
              February 2012.

   [I-D.ietf-netext-update-notifications]
              Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
              J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
              draft-ietf-netext-update-notifications-00 (work in
              progress), November 2012.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC5845]  Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "Generic Routing Encapsulation (GRE) Key Option for Proxy
              Mobile IPv6", RFC 5845, June 2010.

   [RFC5846]  Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
              and P. Yegani, "Binding Revocation for IPv6 Mobility",
              RFC 5846, June 2010.

Liebsch, et al.          Expires August 29, 2013               [Page 28]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   [TS23.402]
              3GPP, "Architecture enhancements for non-3GPP accesses",
              2010.

Liebsch, et al.          Expires August 29, 2013               [Page 29]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

Appendix A.  Information when implementing PMIP based QoS support with
             IEEE 802.11e

   This section shows, as an example, the end-to-end QoS management with
   a 802.11e capable WLAN access link and a PMIP based QoS support.

   The 802.11e, or Wi-Fi Multimedia (WMM), specification provides
   prioritization of packets for four types of traffic, or access
   categories (AC):

      Voice (AC_VO): Very high priority queue with minimum delay.  Time-
      sensitive data such as VoIP and streaming mode are automatically
      sent to this queue.

      Video (AC_VI): High priority queue with low delay.  Time-sensitive
      video data is automatically sent to this queue.

      Best effort (AC_BE): Medium priority queue with medium throughput
      and delay.  Most traditional IP data is sent to this queue.

      Background (AC_BK): Lowest priority queue with high throughput.
      Bulk data that requires maximum throughput but is not time-
      sensitive (for example, FTP data) is sent to the queue.

   The access point uses the 802.11e indicator to prioritize traffic on
   the WLAN interface.  On the wired side, the access point uses the
   802.1p priority tag and DiffServ code point (DSCP).  To allow
   consistent QoS management on both wireless and wired interfaces, the
   access point relies on the 802.11e specification which define mapping
   between the 802.11e access categories and the IEEE 802.1D priority
   (802.1p tag).  The end-to-end QoS architecture is depicted on
   Figure 8 and the 802.11e/802.1D priority mapping is reminded in the
   following table:

                      +-----------+------------------+
                      | 802.1e AC | 802.1D priority  |
                      +-----------+------------------+
                      |  AC_VO    |       7,6        |
                      +-----------+------------------+
                      |  AC_VI    |       5,4        |
                      +-----------+------------------+
                      |  AC_BE    |       0,3        |
                      +-----------+------------------+
                      |  AC_BK    |       2,1        |
                      +-----------+------------------+

Liebsch, et al.          Expires August 29, 2013               [Page 30]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

                +=============+                          +-----+
                 DSCP/802.1p                             | PDP |
                 mapping table                           +-----+
                +=============+     PEP                     |
                         `._     +---+---+                  |
                            `._  |WiFi AR|    PMIPv6     +-----+
                               - + (MAG) +===============| LMA |
                                 |  WLC  |    tunnel     +-----+
                                 +-------+                 PEP
                                     |
                    ==Video==   802.11p/DSCP
                    ==Voice==        |
                    == B.E.==     +----+
             +----+               |WLAN| PEP
             | MN |----802.11e----| AP |
             +----+               +----+

             Figure 8: End-to-end QoS management with 802.11e

   When receiving a packet from the MN, the AP checks whether the frame
   contains 802.11e markings in the L2 header.  If not, the AP checks
   the DSCP field.  If the uplink packet contains the 802.11e marking,
   the access point maps the access categories to the corresponding
   802.1D priority as per the table above.  If the frame does not
   contain 802.11e marking, the access point examines the DSCP field.
   If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e
   802.1D priority).  This mapping is not standardized and may differ
   between operator; a mapping example given in the following table.

                +-------------------+--------+------------+
                | Type of traffic   | 802.1p | DSCP value |
                +-------------------+--------+------------+
                |  Network Control  |   7    |     56     |
                +-------------------+--------+------------+
                |  Voice            |   6    |  46 (EF)   |
                +-------------------+--------+------------+
                |  Video            |   5    | 34 (AF 41) |
                +-------------------+--------+------------+
                |  voice control    |   4    | 26 (AF 31) |
                +-------------------+--------+------------+
                | Background Gold   |   2    | 18 (AF 21) |
                +-------------------+--------+------------+
                | Background Silver |   1    | 10 (AF 11) |
                +-------------------+--------+------------+
                |  Best effort      |  0,3   |  0 (BE)    |
                +-------------------+--------+------------+

   The access point prioritizes ingress traffic on the Ethernet port

Liebsch, et al.          Expires August 29, 2013               [Page 31]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

   based on the 802.1p tag or the DSCP value.  If 802.1p priority tag is
   not present, the access point checks the DSCP/802.1p mapping table.
   The next step is to map the 802.1p priority to the appropriate egress
   queue.  When 802.11e support is enabled on the wireless link, the
   access point uses the IEEE standardized 802.1p/802.11e correspondence
   table to map the traffic to the appropriate hardware queues.

   When the 802.11e capable client sends traffic to the AP, it usually
   marks packets with a DSCP value.  In that case, the MAG/LMA can come
   into play for QoS renegotiation and call flows depicted in
   Section 3.6 apply.  Sometimes, when communication is initiated on the
   WLAN access, the application does not mark upstream packets.  If the
   uplink packet does not contain any QoS marking, the AP/MAG could
   determine the DSCP field according to traffic selectors received from
   the LMA.  Figure 9 gives the call flow corresponding to that use-case
   and shows where QoS tags mapping does come into play.  The main steps
   are as follows:

      (A): during MN attachment process, the MAG fetches QoS policies
      from the LMA.  After this step, both MAG and LMA are provisionned
      with QoS policies.

      (B): the MN starts a new IP communication without making IP
      packets with DSCP tags.  The MAG uses the traffic selector to
      determine the DSCP value, then it marks the IP packet and forwards
      within the PMIP tunnel.

      (C): the LMA checks the DSCP value with respect to the traffic
      selector.  If the QoS policies is valid, the LMA forwards the
      packet without renegociate QoS rules.

      (D): when receiving a marked packet, the MAG, the AP and the MN
      use 802.11e (or WMM), 802.11p tags and DSCP values to prioritize
      the traffic.

Liebsch, et al.          Expires August 29, 2013               [Page 32]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

     +--+            +--+             +---+                     +---+
     |MN|            |AP|             |MAG|                     |LMA|
     +--+            + -+             +---+                     +---+
   (A)|----attach-----|---------------->|-----------PBU---------->|
      |<--------------|---------------- |<----PBA[QoS option]-----|
      .               .            [QoS rules]              [QoS rules]
   (B).               .                 .                         |
     new session      |                 |                         |
      |----data[]---->|---data[]------->|-======data[DSCP]======->|
      |               |                 |                         |
   (C)|               |                 |              Validate QoS rule
      |               |                 |                         |---->
      |               |                 |<======data[DSCP]========|<----
      |               |                 |                         |
      |               |               mapping                     |
   (D)|               |            DSCP/802.1p                    |
      |               |<----data--------|                         |
      |               |  [802.1p/DSCP]  |                         |
      |               |                 |                         |
      |             mapping                                       |
      |          802.1p/802.11e         |                         |
      |<--data[WMM]---|                 |                         |
      |               |                 |                         |
      |---data[WMM]-->|-----data------->|=======data[DSCP]=======>|---->
      |               |  [802.1p/DSCP]  |                         |
      |               |                 |                         |

       Figure 9: Prioritization of a flow created on the WLAN access

Liebsch, et al.          Expires August 29, 2013               [Page 33]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

Appendix B.  Information when implementing with a Broadband Network
             Gateway

   This section shows an example of QoS interworking between the PMIPv6
   domain and the broadband access.  The Broadband Network Gateway (BNG)
   or Broadband Remote Access Server (BRAS) has the MAG function and the
   CPE (Customer Premise Equipment) or Residential Gateway (RG) is
   connected via the broadband access network.  The MN is attached to
   the RG via e.g., WiFi AP in the broadband home network.  In the
   segment of the broadband access network, the BNG and RG are the
   Policy Enforcement Point (PEP) for the downlink and uplink traffic,
   respectively.  The QoS information is downloaded from the LMA to the
   BNG via the PMIPv6 with the QoS option defined in this document.
   Based on the received QoS parameters (e.g., DSCP values), the
   broadband access network and the RG provide appropriate QoS treatment
   to the downlink and uplink traffic to/from the MN.

                                                         +-----+
                                                         | PDP |
                                                         +-----+
                                    PEP                     |
                                 +-------+                  |
                                 | BNG/  |    PMIPv6     +-----+
                                 | BRAS  +===============| LMA |
                                 | (MAG) |    tunnel     +-----+
                                 +-------+                 PEP
                      Broadband  (   |   )
                        Access  (   DSCP  )
                       Network   (   |   )
                                  +-----+
               +----+             | CPE | PEP
               | MN |-------------| /RG |
               +----+  Broadband  +-----+
                      Home Network

      Figure 10: End-to-end QoS management with the broadband access
                                  network

   In the segment of the broadband access network, QoS mapping between
   3GPP QCI values and DSCP described in Section 3.5 is applied.  In the
   segment of the broadband home network, if the MN is attached to the
   RG via WiFi, the same QoS mapping as described in Appendix A can be
   applied.

Liebsch, et al.          Expires August 29, 2013               [Page 34]
Internet-Draft      QoS Support for Proxy Mobile IPv6      February 2013

Authors' Addresses

   Marco Liebsch
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  D-69115
   Germany

   Email: liebsch@neclab.eu

   Pierrick Seite
   France Telecom - Orange
   4, rue du Clos Courtel, BP 91226
   Cesson-Sevigne  35512
   France

   Email: pierrick.seite@orange.com

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara
   Saitama, Fujimino  356-8502
   Japan

   Email: yokota@kddilabs.jp

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  FI-02600
   Finland

   Email: jouni.nospam@gmail.com

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

Liebsch, et al.          Expires August 29, 2013               [Page 35]