Internet DRAFT - draft-liebsch-netext-pmip6-qos

draft-liebsch-netext-pmip6-qos






NETEXT WG                                                     M. Liebsch
Internet-Draft                                                       NEC
Intended status: Standards Track                                P. Seite
Expires: September 13, 2012                      France Telecom - Orange
                                                               H. Yokota
                                                                KDDI Lab
                                                             J. Korhonen
                                                  Nokia Siemens Networks
                                                           S. Gundavelli
                                                                   Cisco
                                                          March 12, 2012


            Quality of Service Option for Proxy Mobile IPv6
                 draft-liebsch-netext-pmip6-qos-01.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 September 13, 2012.



Liebsch, et al.        Expires September 13, 2012               [Page 1]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


Copyright Notice

   Copyright (c) 2012 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 September 13, 2012               [Page 2]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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.  Relevant QoS Attributes  . . . . . . . . . . . . . . . . . 11
     3.5.  Protocol Operation . . . . . . . . . . . . . . . . . . . . 12
       3.5.1.  Handover of existing QoS rules . . . . . . . . . . . . 13
       3.5.2.  Establishment of QoS rules . . . . . . . . . . . . . . 14

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

   5.  Quality of Service Option  . . . . . . . . . . . . . . . . . . 17

   6.  QoS Information Attributes (Type-Length-Values)  . . . . . . . 18
     6.1.  Per Mobile Node Aggregate Maximum Downlink Bit Rate  . . . 18
     6.2.  Per Mobile Node Aggregate Maximum Uplink Bit Rate  . . . . 18
     6.3.  Per Mobility Session Aggregate Maximum Downlink Bit
           Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     6.4.  Per Mobility Session Aggregate Maximum Uplink Bit Rate . . 19
     6.5.  Allocation and Retention Priority  . . . . . . . . . . . . 20
     6.6.  Guaranteed Downlink Bit Rate . . . . . . . . . . . . . . . 21
     6.7.  Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . . . 22

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     10.2. Informative References . . . . . . . . . . . . . . . . . . 26

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

   Appendix B.  Information when implementing with a Broadband



Liebsch, et al.        Expires September 13, 2012               [Page 3]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


                Network Gateway . . . . . . . . . . . . . . . . . . . 31

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
















































Liebsch, et al.        Expires September 13, 2012               [Page 4]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 September 13, 2012               [Page 5]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   Point is out of scope of this specification.


















































Liebsch, et al.        Expires September 13, 2012               [Page 6]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 September 13, 2012               [Page 7]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 supports enforcement of solely four Differentiated
   Services classes according to four well-known Differentiated Services
   Code Points (DSCP).

   Central control from a Policy Control Function (PCF) is considered 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 September 13, 2012               [Page 8]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


           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 September 13, 2012               [Page 9]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   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 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 September 13, 2012              [Page 10]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   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.  Relevant QoS Attributes

   The QoS Option shall, at least, contain DSCP values associated with
   IP flows.  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.

   3.  QoS Class Identifier (QCI) mapped to a DSCP.

   The following QoS parameters are good to negotiate during the session
   setup:



Liebsch, et al.        Expires September 13, 2012              [Page 11]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   1.  Allocation and Retention Priority (ARP).

   2.  Guaranteed Bit Rate (GBR)

   3.  Maximum Bit Rate (MBR)


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

   QCI    DiffServ PHB    DSCP
   1          EF         101110
   2          EF         101110
   3          EF         101110
   4         AF41        100010
   5         AF31        011010
   6         AF32        011100
   7         AF21        010010
   8         AF11        001010
   9          BE         000000

3.5.  Protocol Operation






























Liebsch, et al.        Expires September 13, 2012              [Page 12]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


3.5.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 September 13, 2012              [Page 13]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


3.5.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 September 13, 2012              [Page 14]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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.  Specifically, the following parameters must be
   defined.

   Flow Selectors

   DSCP Value

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

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



Liebsch, et al.        Expires September 13, 2012              [Page 15]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   local mobility anchor.  Specifically, the following parameters must
   be defined.

   Flow Selectors

   DSCP Value

   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.

   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.  The traffic selectors and the associated flow
   treatment is as specified for that mobility session.




























Liebsch, et al.        Expires September 13, 2012              [Page 16]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


5.  Quality of Service Option

   A new option, Quality of Service option, is defined for using it in
   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    |    TS Format  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Traffic Selector ...                   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         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  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  TS Selector : variable-length opaque field for including the
      traffic specification identified by the TS format field.

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




Liebsch, et al.        Expires September 13, 2012              [Page 17]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


6.  QoS Information Attributes (Type-Length-Values)

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.

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-DL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: To be assigned by IANA

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

   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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-UL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: To be assigned by IANA

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





Liebsch, et al.        Expires September 13, 2012              [Page 18]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   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.

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-DL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: To be assigned by IANA

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

   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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Max-Bandwidth-UL                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: To be assigned by IANA





Liebsch, et al.        Expires September 13, 2012              [Page 19]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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

   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.

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Priority-Level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Pre-emption-Capability     |  Pre-emption-Vulnerability    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: To be assigned by IANA

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

   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:



Liebsch, et al.        Expires September 13, 2012              [Page 20]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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

   o  Type: To be assigned by IANA

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

   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.







Liebsch, et al.        Expires September 13, 2012              [Page 21]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


6.7.  Guaranteed Uplink Bit Rate

   The guaranteed 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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Guaranteed-UL                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: To be assigned by IANA

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

   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.




























Liebsch, et al.        Expires September 13, 2012              [Page 22]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


7.  IANA Considerations

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












































Liebsch, et al.        Expires September 13, 2012              [Page 23]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 September 13, 2012              [Page 24]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


9.  Acknowledgements

   The authors of this document thank the NetExt Working Group for the
   valuable feedback on the initial version of this document.  In
   particular the authors want to thank Basavaraj Patil, Behcet Sarikaya
   and Mark Grayson for their valuable comments and suggestions to
   improve this specification.












































Liebsch, et al.        Expires September 13, 2012              [Page 25]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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.

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

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









Liebsch, et al.        Expires September 13, 2012              [Page 26]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 7 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 September 13, 2012              [Page 27]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


                +=============+                          +-----+
                 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 7: 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 September 13, 2012              [Page 28]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


   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.5 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 8 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 September 13, 2012              [Page 29]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


     +--+            +--+             +---+                     +---+
     |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 8: Prioritization of a flow created on the WLAN access






















Liebsch, et al.        Expires September 13, 2012              [Page 30]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 9: 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.4 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 September 13, 2012              [Page 31]

Internet-Draft      QoS Support for Proxy Mobile IPv6         March 2012


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 September 13, 2012              [Page 32]