NETEXT WG
Internet Engineering Task Force (IETF)                        M. Liebsch
Internet-Draft
Request for Comments: 7222                                           NEC
Intended status:
Category: Standards Track                                       P. Seite
Expires: September 29, 2014
ISSN: 2070-1721                                                   Orange
                                                               H. Yokota
                                                                KDDI Lab
                                                             J. Korhonen
                                                 Broadcom Communications
                                                           S. Gundavelli
                                                                   Cisco
                                                          March 28,
                                                                May 2014

            Quality of Service

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

Abstract

   This specification defines a new mobility option, the Quality of Quality-of-
   Service (QoS) option, for Proxy Mobile IPv6.  This option can be used
   by the local mobility anchor and the mobile access gateway for
   negotiating Quality of Service Quality-of-Service parameters for a mobile node's IP
   flows.  The negotiated QoS parameters can be used for QoS policing
   and marking 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 mobile access
   gateway enables mapping of these parameters to QoS rules that are
   specific to the access technology and allows those rules to be
   enforced on the access network using access technology specific access-technology-specific
   approaches.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 29, 2014.
   http://www.rfc-editor.org/info/rfc7222.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 ....................................................3
   2. Conventions and Terminology  . . . . . . . . . . . . . . . . .  6 .....................................4
      2.1. Conventions  . . . . . . . . . . . . . . . . . . . . . . .  6 ................................................4
      2.2. Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6 ................................................4
   3. Overview of QoS Support in Proxy Mobile IPv6 . . . . . . . . .  9 ....................6
      3.1.  Quality of Service Quality-of-Service Option - -- Usage Examples . . . . . . . . 11 ................9
      3.2.  Quality of Service Quality-of-Service Attributes - -- Usage Examples . . . . . . 13 ...........11
   4. Protocol Messaging Extensions  . . . . . . . . . . . . . . . . 15 ..................................12
      4.1.  Quality of Service Quality-of-Service Option  . . . . . . . . . . . . . . . . 15 .................................12
      4.2.  Quality of Service Attribute . . . . . . . . . . . . . . . 17 Quality-of-Service Attributes .............................14
           4.2.1.  Per Mobile Node Per-Mobile-Node Aggregate Maximum Downlink
                  Bit Rate  . 19 ...........................................16
           4.2.2.  Per Mobile Node Per-Mobile-Node Aggregate Maximum Uplink Bit Rate  . . 20 ..17
           4.2.3.  Per Mobility Session Per-Mobility-Session Aggregate Maximum
                  Downlink Bit Rate . . . . . . . . . . . . . . . . . . . . . . . 21 ..................................18
           4.2.4.  Per Mobility Session Per-Mobility-Session Aggregate Maximum
                  Uplink Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . 23 ....................................20
           4.2.5. Allocation and Retention Priority  . . . . . . . . . . 25 ..................22
           4.2.6. Aggregate Maximum Downlink Bit Rate  . . . . . . . . . 27 ................23
           4.2.7. Aggregate Maximum Uplink Bit Rate  . . . . . . . . . . 28 ..................25
           4.2.8. Guaranteed Downlink Bit Rate . . . . . . . . . . . . . 29 .......................26
           4.2.9. Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . 30 .........................27
           4.2.10. QoS Traffic Selector . . . . . . . . . . . . . . . . . 31 ..............................28
           4.2.11. QoS Vendor Specific Vendor-Specific Attribute  . . . . . . . . . . . . 32 .....................29
      4.3. New Status Code for Proxy Binding Acknowledgement  . . . . 33 .........30
      4.4. New Notification Reason for Update Notification Message  . 33 ...30
      4.5. New Status Code for Update Notification
           Acknowledgement Message  . . . . . . . . . . . . . . . . . 33 ...................................31
   5. Protocol Considerations  . . . . . . . . . . . . . . . . . . . 35 ........................................31
      5.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35 ......................31
      5.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 ......................35
   6. QoS Services in Integrated WLAN-3GPP Networks  . . . . . . . . 43 ..................39
      6.1. Technical Scope and Procedure  . . . . . . . . . . . . . . 43 .............................39
      6.2. Relevant QoS Attributes  . . . . . . . . . . . . . . . . . 45 ...................................41
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 47 ............................................42
   8.  Implementation Status  . . . . . . . . . . . . . . . . . . . . 50

   9. Security Considerations  . . . . . . . . . . . . . . . . . . . 52

   10. ........................................44
   9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53

   11. ...............................................44
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
     11.1. ....................................................44
      10.1. Normative References . . . . . . . . . . . . . . . . . . . 54
     11.2. .....................................44
      10.2. Informative References . . . . . . . . . . . . . . . . . . 54 ...................................45
   Appendix A.  Information when implementing When Implementing 3GPP QoS in IP
                transport network . . . . . . . . . . . . . . . . . . 56
                Transport Network ....................................47
     A.1.  Mapping tables . . . . . . . . . . . . . . . . . . . . . . 56 Tables ............................................47
     A.2.  Use cases Cases and protocol operations  . . . . . . . . . . . . 57 Protocol Operations .........................48
       A.2.1.  Handover of existing Existing QoS rules . . . . . . . . . . . . 57 Rules ........................48
       A.2.2.  Establishment of QoS rules . . . . . . . . . . . . . . 59 Rules ............................50
       A.2.3.  Dynamic Update to QoS Policy . . . . . . . . . . . . . 61 ..........................52
   Appendix B.  Information when implementing PMIP based When Implementing PMIP-Based QoS
                support Support
                with IEEE 802.11e . . . . . . . . . . . . . . 63 ....................................53
   Appendix C.  Information when implementing When Implementing with a Broadband
                Network Gateway . . . . . . . . . . . . . . . . . . . 67

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 ......................................56

1.  Introduction

   Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to
   enable network-based mobility management for mobile nodes (MN). (MNs).
   Users can access Internet Protocol (IP) based IP-based services from their mobile device by using
   various radio access technologies.  The currently supported mobile
   standards have adequate support for QoS-
   based QoS-based service differentiation
   for subscriber traffic in cellular radio access networks.  QoS
   policies are typically controlled by a policy control function,
   whereas the policies are enforced by one or more gateways in the
   infrastructure, such as the local mobility anchor (LMA) and the
   mobile access gateway, gateway (MAG), as well as by access network elements.
   Policy control and in-band QoS differentiation for access to the
   mobile operator network through alternative non-cellular access
   technologies is are not supported in the currently specified standards.  All though
   Although support for IP session handovers and IP flow mobility across
   access technologies already exists in cellular standards [TS23.402], however,
   QoS policy handovers across access technologies has not received much
   attention so far.

   Based on the deployment trends, Wireless LAN (WLAN) can be considered
   as the dominant alternative access technology to complement cellular
   radio access.  Since the 802.11e extension [IEEE802.11e-2005]
   provides QoS extensions to WLAN, it is beneficial to apply QoS
   policies to WLAN access, which enables QoS classification of downlink
   as well as uplink traffic between a mobile node and its local
   mobility anchor.  For realizing this capability capability, this specification
   identifies three functional operations:

      (a) Maintaining 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 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 [RFC5213]
   to establish QoS policies for a mobile node's data traffic on the
   local mobility anchor and the mobile access gateway.  QoS policies
   are conveyed in-band with PMIPv6 signaling using the specified QoS
   option and are enforced on the local mobility anchor for downlink
   traffic and on the mobile access gateway and its access network for
   the uplink traffic.  The specified option allows association between
   IP session classification characteristics, such as a Differentiated
   Services Code Point (DSCP) [RFC2474], and the expected QoS class for
   the IP session.  This document specifies fundamental QoS attributes
   which
   that apply on a per mobile node, mobility session per-mobile-node, per-mobility-session, or on a per-flow
   basis.  The specified attributes are not specific to any access
   technology,
   technology but are compatible with the Third Generation Partnership
   Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications. specifications
   [IEEE802.11-2012].

   Additional QoS attributes can be specified and used with the QoS
   option, e.g. e.g., to represent more specific descriptions of latency
   constraints or jitter bounds.  The specification of such additional
   QoS attributes as well as the handling of QoS policies between the
   mobile access gateway and the access network are out of the scope for of
   this specification.

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 mobility-related terms used in this document are to be
   interpreted as defined in the Proxy Mobile IPv6 specifications
   [RFC5213], [RFC5844], and [RFC7077].  Additionally, this document
   uses the following abbreviations:

   Aggregate Maximum Bit Rate (AMBR)

      AMBR defines the upper limit on the bit-rate bit rate that can be provided
      by the network for a set of IP flows.  IP packets within the flows
      exceeding the AMBR limit will may be discarded by the rate-shaping
      function where the AMBR parameter is enforced.  Variants of AMBR the
      "AMBR" term can be defined by restricting the target set of IP
      flows on which the AMBR is applied to a mobile node, mobility session
      session, or flow direction.  For example, Per Mobile Node Per-Mobile-Node
      Aggregate Maximum Downlink Bit Rate, Per Mobile Node Per-Mobile-Node Aggregate
      Maximum Uplink Bit Rate, Per Mobility Session Per-Mobility-Session Aggregate Maximum
      Downlink Bit Rate Rate, and
      Per Mobility Session Per-Mobility-Session Aggregate Maximum
      Uplink Bit Rate are used in this document.

   Allocation and Retention Priority (AARP)

      AARP is used in congestion situations when there are insufficient
      resources for meeting all services requests. Service Requests.  It is used primarily
      by the Admission Control function to determine whether a
      particular service request Service Request must be rejected due to lack of
      resources,
      resources or if it must be honored by preempting an existing low-
      priority low-priority
      service.

   Differentiated Services Code Point (DSCP)

      In the Differentiated Services Architecture [RFC2474], packets are
      classified and marked to receive a particular per-hop forwarding
      behavior on nodes along their path based on the marking present on
      the packet.  This marking on IPv4 and IPv6 packets that defines a
      specific Per-hop per-hop behavior is known as DSCP.  Refer to [RFC2474],
      [RFC2475], [RFC4594] [RFC4594], and [RFC2983] for a complete explanation.
      Please also refer to

   Downlink (DL) Traffic

      The mobile node's IP packets that the mobile access gateway
      receives from the local mobility anchor is are referred to as the
      Downlink traffic.  The "Downlink" term used in the QoS attribute
      definition is always from the reference point of the mobile node node,
      and it implies traffic heading towards the mobile node.

   Guaranteed Bit Rate (GBR)

      GBR denotes the assured bit-rate bit rate that will be provided by the
      network for a set of IP flows.  It is assumed that the network
      reserves the resources for supporting the GBR parameter.  Variants
      of the GBR "GBR" term can be defined by limiting the scope of the
      target IP flows on which the GBR is applied to a mobile node,
      mobility
      session session, or flow direction.  For example, Guaranteed
      Downlink Bit Rate and Guaranteed Uplink Bit Rate are used in this
      document.

   Mobility Session

      The term mobility session, "mobility session" is defined in [RFC5213].  It refers to
      the creation or existence of state associated with the mobile
      node's mobility binding on the local mobility anchor and on the
      mobile access gateway.

   QoS Service Request

      A QoS Service Request is a set of QoS parameters that are defined
      to be enforced on one or more mobile node's IP flows.  The
      parameters at the minimum include a DSCP marking and additionally
      may include Guaranteed Bit Rate or Aggregate Maximum Bit Rate.
      The Quality of Service Quality-of-Service option defined in this document represents
      a QoS Service Request.

   Service Identifier

      In some mobility architectures, multiple services within the same
      mobility service subscription are offered to a mobile node.  Each
      of those services provide a specific service (examples: (for example,
      Internet
      Service, Service and Voice Over IP Service) and has an identifier
      called
      Service Identifier. "Service Identifier". 3GPP APN (Access Point Name) is an
      example of a Service Identifier.  Refer to [RFC5149] for the
      definition of the Service Identifier and the mobility option used
      for carrying the Service Identifier.

   Uplink (UL) Traffic

      The mobile node's IP packets that the mobile access gateway
      forwards to the local mobility anchor is are referred to as the
      Uplink traffic.  The "Uplink" term used in the QoS attribute
      definitions is based on the reference point of the mobile node node,
      and "Uplink" it implies traffic originating from the mobile node.

3.  Overview of QoS Support in Proxy Mobile IPv6

   The Quality of Service Quality-of-Service support in Proxy Mobile IPv6 specified in this
   document is based on the Differentiated-Services architecture Differentiated Services Architecture
   ([RFC2474] and [RFC2475]).  The access and the home network in the
   Proxy Mobile IPv6 domain are assumed to be DiffServ enabled, DiffServ-enabled, with
   every network node in the forwarding path for the mobile node's IP
   traffic being Diffserv compliant. DiffServ-compliant.  The per-hop behavior for providing
   differential treatment based on the DiffServ marking in the packet is
   assumed to be supported in the Proxy Mobile IPv6 domain.

   The local mobility anchor in the home network and the mobile access
   gateway in the access network define the network boundary between the
   access and the home network.  These entities being  As the tunnel entry and exit points for
   the mobile node's IP traffic, these entities are the logical choice
   for being chosen as the QoS enforcement points.  The basic QoS
   functions such as marking, metering, policing policing, and rate-shaping on
   the mobile node's IP flows can be enforced at these nodes.

   The local mobility anchor and the mobile access gateway can negotiate
   the Quality of Service Quality-of-Service parameters for a mobile node's IP flows based
   on the signaling extensions defined in this document.  The QoS
   services that can be enabled for a mobile node are for meeting both
   the quantitative performance requirements (such as Guaranteed Bit- Bit
   Rate) and as well as for realizing relative performance treatment by the
   ways way
   of class-based differentiation.  The subscriber's policy and the
   charging profile [TS22.115] is a (for example, [TS22.115]) are key consideration considerations for
   the mobility entities in the QoS service negotiation.  The decision
   on the type of QoS services that are to be enabled for a mobile node
   is based on the subscriber profile and based on available network
   resources.  The negotiated QoS parameters are used for providing QoS service
   differentiation on the path between the local mobility anchor and the
   mobile access gateway.  The signaling related to QoS services is
   strictly between the mobility entities and does not result in per-
   flow state, state or signaling to any other node in the network.

     +=======+
     |  MN-1 |
     +=======+
       | | |                                                    Flow-6
       Flow-1<--(GBR: 64Kbps) 64 Kbps)                                       |
       |                                                      Flow-4 |
         Flow-2                                                  | | |
       | |                                                  Flow-1 | |
         | Flow-3                                                | | |
       |_|_|                                            DSCP-X   | | |
      (     )<--(Per-Session-AMBR: 1Mbps) 1 Mbps)                   :   | | |
       | | |                                          DSCP-Z :   | | |
         | |                                               : :   | | |
       | | |             +=====+                        +==:=v+  | | |
         | '- -- - - - --|     |                        |  : o|--' | |
       | '- - ---  - -  -|     |           __           |  v o|----' |
       '- - - - -  - -  -|     |       _--'  '--_       |  o--|------'
                         |     |      (          )      |     |
                         | MAG |=====( IP Network )=====| LMA |
                         |     |      (          )      |     |
       ,- - - - - - - - -|     |        '--__--'        |    o|-- - -,
         ,- - -- - -- - -|     |                        |    o|--- , |
       | | ,- -  - - -- -|     |                        |    o|--, | |
         | |             +=====+                        +====^+  | | |
       |_|_|                                                 :   | | |
      ( _ _ )<--(Per-Session-AMBR: 2Mbps) 2 Mbps)                   :   | | |
       | | |                                            DSCP-Y   | | |
         | |                                                     | | |
       | | |                                                     | | |
         | Flow-6                                           Flow-2 | |
       | |                                                         | |
         Flow-5 (MBR: 100Kbps) 100 Kbps)                               Flow-3 |
       |                                                             |
       Flow-4  (GBR: 64Kbps) 64 Kbps)                                   Flow-5
       | | |
     +=======+
     |  MN-2 |
     +=======+

                           Figure 1: QoS Support

   Figure 1 illustrates the support of QoS services in a Proxy Mobile
   IPv6 domain.  The local mobility anchor and the mobile access gateway
   have negotiated QoS parameters for the mobility sessions belonging to
   MN-1 and MN-2.  A Per-Session-AMBR  The negotiated QoS parameters include a Per-Session-
   AMBR of 1Mbps 1 Mbps and 2 Mbps for MN-1 and MN-2 respectively.
   Furthermore, different IP flows from MN-1 and MN-2 are given
   different QoS service treatment.  For treatment, for example, a GBR of 64Kbps 64 Kbps for
   Flow-1 and Flow-5 Flow-4 is assured, a DSCP marking enforcement of "Z" on
   Flow-6, and an MBR of 100 Kbps on Flow-5; Flow-5.

3.1.  Quality of Service  Quality-of-Service Option - -- Usage Examples

   Use Case 1: Figure 2 illustrates a scenario where a local mobility
   anchor initiates a QoS service request Service Request to a mobile access gateway.

      +-----+            +-----+              +-----+
      | MN  |            | MAG |              | LMA |
      +-----+            +-----+              +-----+
         |                   |                   |
   1)    |---- MN Attach ----|                   |
   2)    |                   |------ PBU ------->|
   3)    |                   |<----- PBA --------|
         |                   |                   |
   4)    |                   |o=================o|
         |                   |   PMIPv6 Tunnel   |
         |                   |                   |
         |  (LMA initiates QoS Service Request)  |
   5)    |                   |<----- UPN (QoS)---|
         |                   |                   |
         |  (MAG proposes a revised QoS Request) |
   6)    |                   |------ UPA (QoS')->|
         |                   |                   |
   7)    |                   |<----- UPN (QoS')--|
   8)    |                   |------ UPA (QoS')->|
         |  QoS Rules     ---|                   |
   9)    | Established <-|   |  QoS Rules     ---|
   10)   |                ---| Established <-|   |
         |                   |                ---|
   11)   |<----------------->|                   |

      Figure 2: LMA Initiated LMA-Initiated QoS Service Request

   o  (1) to (4): MAG detects the mobile node's attachment to the access
      link and initiates the signaling with the local mobility anchor.
      The
      Upon completing the signaling, the LMA and MAG upon completing the signaling establish the
      mobility session and the forwarding state.

   o  (5) to (8): The LMA initiates a QoS Service request Request to the mobile
      access gateway.  The trigger for this service can be based on a
      trigger from a policy function function, and the specific details of that
      trigger are outside the scope of this document.  The LMA sends an
      Update Notification (UPN) message [RFC7077] to the MAG.  The
      message includes the QoS option Section 4.1 (Section 4.1), which includes a
      set of QoS parameters.  The MAG on  On determining that it cannot support the
      requested QoS service request Service Request for that mobile mobile, the MAG sends an
      Update Notification Acknowledgement (UPA) message.  The message
      contains a revised QoS option with an updated set of QoS
      attributes.  The LMA accepts the revised QoS service request Service Request by
      sending a new Update Notification message including the updated
      QoS option.

   o  (9) to (11): Upon successfully negotiating a QoS service request Service Request,
      the MAG and the LMA install the QoS rules for that service
      request. Service
      Request.  Furthermore, the MAG (using access technology specific access-technology-specific
      mechanisms) install installs the QoS rules on the access network.

   Use Case 2: Figure 3 illustrates a scenario where a mobile access
   gateway initiates a QoS service request Service Request to a local mobility anchor.

      +-----+            +-----+              +-----+
      | MN  |            | MAG |              | LMA |
      +-----+            +-----+              +-----+
         |                   |                   |
   1)    |---- MN Attach ----|                   |
   2)    |                   |------ PBU ------->|
   3)    |                   |<----- PBA --------|
         |                   |                   |
   4)    |                   |o=================o|
         |                   |   PMIPv6 Tunnel   |
         |                   |                   |
         |  (MAG initiates QoS Service Request)  |
   5)    |                   |------ PBU (QoS)-->|
   6)    |                   |<----- PBA (QoS)---|
         |  QoS Rules     ---|                   |
   7)    | Established <-|   |  QoS Rules     ---|
   8)    |                ---| Established <-|   |
         |                   |                ---|
   9)    |<----------------->|                   |

       Figure 3: MAG Initiated MAG-Initiated QoS Service Request

   o  (1) to (4): MAG detects the mobile node's attachment to the access
      link and initiates the signaling with the local mobility anchor.
      The
      Upon completing the signaling, the LMA and MAG upon completing the signaling establish the
      mobility session and the forwarding state.

   o  (5) to (6): The MAG initiates a QoS Service request Request to the local
      mobility anchor.  The trigger for this service can be based on a
      trigger from the mobile node using access technology specific access-technology-specific
      mechanisms.  The specific details of that trigger are outside the
      scope of this document.  The MAG sends a Proxy Binding Update
      (PBU) message [RFC5213] to the LMA.  The message includes the QoS
      option
      Section 4.1 (Section 4.1), which includes a set of QoS parameters.  The
      LMA agrees to the proposed QoS service request Service Request by sending a Proxy
      Binding Acknowledgement (PBA) message.

   o  (7) to (9): Upon successfully negotiating a QoS service request Service Request,
      the MAG and the LMA install the QoS rules for that service
      request. Service
      Request.  Furthermore, the MAG using access technology specific access-technology-specific
      mechanisms install installs the QoS rules on the access network.

3.2.  Quality of Service  Quality-of-Service Attributes - -- Usage Examples

   This section identifies the use-cases use cases where the Quality of Service
   Option Quality-of-Service
   option (Section 4.1) and its attributes (Section 4.2) defined in this
   document are relevant.

   o  The subscription policy offered to a mobile subscriber requires
      the service provider to enforce Aggregate Maximum Bit Rate (AMBR)
      limits on the subscriber's IP traffic.  The local mobility anchor
      and the mobile access gateway negotiate the uplink and the
      downlink AMBR values for the mobility session and enforce them in
      the access and the home network.  The QoS option (Section 4.1)
      with the QoS Attributes, attributes Per-Session-Agg-Max-DL-Bit-Rate
      (Section 4.2.3) and Per-Session-Agg-Max-UL-Bit-Rate
      (Section 4.2.4) are is used for this purpose.

   o  In Community Wi-Fi deployments, the residential gateway
      participating in the Wi-Fi service is shared between the home user
      and the community Wi-Fi users.  In order to ensure the home user's
      Wi-Fi service is not impacted because of the community Wi-Fi
      service, the service provider enables Guaranteed Bit Rate (GBR)
      for the home user's traffic.  The QoS option (Section 4.1) with
      the QoS Attributes, attributes Guaranteed-DL-Bit-Rate (Section 4.2.8), 4.2.8) and
      Guaranteed-UL-Bit-Rate (Section 4.2.9) are is used for this purpose.

   o  A mobile user using the service provider's Voice over IP
      infrastructure establishes a VoIP call with some other user in the
      network.  The negotiated call parameters for the VoIP call require
      a dedicated bandwidth of certain fixed value for the media flows
      associated with that VoIP session.  The Application application function in
      the VoIP infrastructure notifies the local mobility anchor to
      enforce the GBR limits on that IP flow identified by the flow
      definition.  The QoS option (Section 4.1) with the QoS Attributes, attributes
      Guaranteed-DL-Bit-Rate (Section 4.2.8), Guaranteed-UL-Bit-Rate
      (Section 4.2.9), and QoS-Traffic-Selector (Section 4.2.10) are is used
      for this purpose.

   o  An emergency service may require network resources in conditions
      when the network resources have been fully allocated to other
      users and the network may be experiencing severe congestion and in congestion.  In
      such cases cases, the service provider may want to revoke resources that
      have been allocated and reassign them to emergency services.  The
      local mobility anchor and the mobile access gateway negotiate
      Allocation and Retention Priority (AARP) values for the IP
      sessions associated with the emergency applications.  The QoS
      option (Section 4.1) with the QoS Attribute, attribute Allocation-Retention-
      Priority (Section 4.2.5) are is used for this purpose.

4.  Protocol Messaging Extensions

4.1.  Quality of Service  Quality-of-Service Option

   The Quality of Service Quality-of-Service option is a mobility header option used by
   local mobility anchor anchors and mobile access gateway gateways for negotiating QoS
   parameters associated with a mobility session.  This option can be
   carried in Proxy Binding Update (PBU) [RFC5213], Proxy Binding
   Acknowledgement (PBA) [RFC5213], Update Notification (UPN) [RFC7077]
   and Update Notification Acknowledgement(UPA) Acknowledgement (UPA) [RFC7077] messages.
   There can be more than one instance of the Quality of Service Quality-of-Service option
   in a single message.  Each instance of the Quality of Service Quality-of-Service option
   represents a specific QoS service request. Service Request.

   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     |     SR-ID     |       TC      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OC      |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        QoS Attribute(s)                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 4: QoS Option

      Type

         <IANA-1>

      Length

   o  Type: 58

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

   o  Service Request Identifier (SR-ID)

         A (SR-ID): An 8-bit unsigned integer used
      for identifying the QoS service
         request. Service Request.  Its uniqueness is within
      the scope of a mobility session.  The local mobility anchor always
      allocates the
         identifier value. Service Request Identifier.  When the a new QoS Service request
      Request is initiated by a mobile access gateway, it sets the value Service
      Request Identifier in the initial request message is set to (0) a
      value of (0), and the local mobility anchor allocates a Service
      Request Identifier and includes the value it in the response.  For any new
      QoS service requests Service Requests initiated by a local mobility anchor, the
      Service Request Identifier is set to the allocated value.

   o  Traffic Class (TC) (TC): Traffic Class consists of a 6-bit DSCP field
      followed by a 2-bit reserved field.

      Differentiated Services Code Point (DSCP)

         A 6-bit unsigned integer indicating the code point value, as
         defined in [RFC2475] to be used for the mobile node's IP flows.
         When this DSCP marking needs to be applied only for a subset of
         a mobile node's IP flows, there will be a Traffic Selector
         attribute (Section 4.2.10) in the option option, which provides the
         flow selectors.  In the absence of any such
            traffic selector Traffic Selector
         attribute, the DSCP marking applies to all the IP flows
         associated with the mobility session.

         Two-bit

      Reserved Field

         The last two-bits two bits in the Traffic Class field are currently
         unused.  These bits MUST be initialized by the sender to (0)
         and MUST be ignored by the receiver.

   o  Operational Code (OC)

         One-Octet (OC): 1-octet Operational code indicates the type
      of QoS request.

      RESPONSE:   (0)
         Response to a QoS request

      ALLOCATE:   (1)
         Request to allocate QoS resources

      DE-ALLOCATE:   (2)
         Request to de-Allocate QoS resources

      MODIFY:   (3)
         Request to modify QoS parameters for a previously negotiated
         QoS service request Service Request

      QUERY:   (4)
         Query to list the previously negotiated QoS service requests
            and Service Requests
         that are still active
      NEGOTIATE:   (5)
         Response to a QoS service request Service Request with a counter QoS proposal

      Reserved:   (6) to (255)
         Currently not used.  Receiver MUST ignore the option received
         with any value in this range.

      Reserved

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

   o  QoS Attribute(s) Attribute(s): Zero or more Type-Length-Value (TLV) encoded TLV-encoded QoS Attributes. attributes.  The
      format of the QoS attribute is defined in Section 4.2.  The
      interpretation and usage of the QoS attribute is based on the
      value in the "Type" Type field.

4.2.  Quality of Service Attribute  Quality-of-Service Attributes

   This section identifies the format of a Quality of Service Quality-of-Service attribute.
   A QoS attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1.  The latter part of this  This section identifies the QoS attributes
   defined by this specification.

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

            Figure 5: Format of a Quality of Service Quality-of-Service Attribute

   o  Type: 8-bit unsigned integer indicating the type of the QoS
      attribute.  This specification reserves the following values.

      (0) -  Reserved
         This value is reserved and cannot be used

      (1) -  Per-MN-Agg-Max-DL-Bit-Rate
         This QoS attribute, Per Mobile Node Per-Mobile-Node Aggregate Maximum Downlink
         Bit Rate, is defined in Section 4.2.1.

      (2) -  Per-MN-Agg-Max-UL-Bit-Rate
         This QoS attribute, Per Mobile Node Per-Mobile-Node Aggregate Maximum Uplink
         Bit Rate, is defined in Section 4.2.2.

      (3) -  Per-Session-Agg-Max-DL-Bit-Rate
         This QoS attribute, Per Mobility Session Per-Mobility-Session Aggregate Maximum
         Downlink Bit Rate, is defined in Section 4.2.3.

      (4) -  Per-Session-Agg-Max-UL-Bit-Rate
         This QoS attribute, Per Mobility Session Per-Mobility-Session Aggregate Maximum
         Uplink Bit Rate, is defined in Section 4.2.4.

      (5) -  Allocation-Retention-Priority
         This QoS attribute, Allocation and Retention Priority, is
         defined in Section 4.2.5.

      (6) -  Aggregate-Max-DL-Bit-Rate
         This QoS attribute, Aggregate Maximum Downlink Bit Rate, is
         defined in Section 4.2.6.

      (7) -  Aggregate-Max-UL-Bit-Rate
         This QoS attribute, Aggregate Maximum Uplink Bit Rate, is
         defined in Section 4.2.7.

      (8) -  Guaranteed-DL-Bit-Rate
         This QoS attribute, Guaranteed Downlink Bit Rate, is defined in
         Section 4.2.8.

      (9) -  Guaranteed-UL-Bit-Rate
         This QoS attribute, Guaranteed Uplink Bit Rate, is defined in
         Section 4.2.9.

      (10) -  QoS-Traffic-Selector
         This QoS attribute, QoS Traffic Selector, is defined in
         Section 4.2.10.

      (11) -  QoS-Vendor-Specific-Attribute
         This QoS attribute, QoS Vendor Specific Vendor-Specific Attribute, is defined
         in Section 4.2.11.

      (12) to (254) -  Reserved
         These values are are reserved for future allocation.

      (255) -  Reserved
         This value is reserved and cannot be used used.

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

   o  Value: The format of this field is based on the Type value.

4.2.1.  Per Mobile Node  Per-Mobile-Node Aggregate Maximum Downlink Bit Rate

   This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum
   downlink bit-rate bit rate for a mobile node.  It is a variant of the AMBR "AMBR"
   term defined in Section 2.2.  This value is an aggregate across all
   mobility sessions associated with that mobile node.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in a an Update Notification message sent by a
   local mobility anchor, it indicates the maximum aggregate downlink
   bit-rate
   bit rate that is being requested for the mobile node at the peer.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the maximum aggregate downlink bit-rate bit rate that the peer
   agrees to offer.

   If multiple mobility sessions are established for a mobile node,
   through multiple mobile access gateways and with sessions anchored either
   on a single local mobility anchor, anchor or when spread out across multiple local
   mobility anchors, then it depends on the operator's policy and the
   specific deployment as to how the total bandwidth for the mobile node
   on each MAG-LMA pair is computed.

   When a QoS option includes both the Per-MN-Agg-Max-DL-Bit-Rate
   attribute and the QOS Traffic Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the QOS Traffic Selector QoS-Traffic-Selector attribute does not apply to this
   attribute.

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Per-MN-Agg-Max-DL-Bit-Rate                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 1

   o  Length: The length in octets of the attribute, excluding the Type
      and Length fields.  This value is set to (6).

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

   o  Per-MN-Agg-Max-DL-Bit-Rate: This is a 32-bit unsigned integer, and it integer that
      indicates the aggregate maximum downlink bit-rate bit rate that is
      requested/allocated for all the mobile node's IP flows.  The
      measurement units for Per-MN-Agg-Max-DL-Bit-Rate are bits-per- bits per
      second.

4.2.2.  Per Mobile Node  Per-Mobile-Node Aggregate Maximum Uplink Bit Rate

   This attribute, Per-MN-Agg-Max-UL-Bit-Rate, represents the maximum
   uplink bit-rate bit rate for the mobile node.  It is a variant of the AMBR "AMBR"
   term defined in Section 2.2.  This value is an aggregate across all
   mobility sessions associated with that mobile node.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in an Update Notification message sent by
   the local mobility anchor, it indicates the maximum aggregate uplink
   bit-rate
   bit rate that is being requested for the mobile node at the peer.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the maximum aggregate uplink bit-rate bit rate that the peer agrees
   to offer for that mobile node.

   If multiple mobility sessions are established for a mobile node,
   through multiple mobile access gateways and with sessions anchored either
   on a single local mobility anchor, anchor or when spread out across multiple local
   mobility anchors, then it depends on the operator's policy and the
   specific deployment as to how the total bandwidth for the mobile node
   on each MAG-LMA pair is computed.

   When a QoS option includes both the Per-MN-Agg-Max-UL-Bit-Rate
   attribute and the QOS Traffic Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the QOS Traffic Selector QoS-Traffic-Selector attribute does not apply to this
   attribute.

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Per-MN-Agg-Max-UL-Bit-Rate                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 2

   o  Length: The length in octets of the attribute, excluding the Type
      and Length fields.  This value is set to (6).

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

   o  Per-MN-Agg-Max-UL-Bit-Rate: This is of type unsigned a 32-bit integer,
      and it unsigned integer that
      indicates the aggregate maximum uplink bit-rate bit rate that is
      requested/allocated requested/
      allocated for the mobile node's IP flows.  The measurement units
      for Per-MN-Agg-Max-UL-Bit-Rate are bits-per- bits per second.

4.2.3.  Per Mobility Session  Per-Mobility-Session Aggregate Maximum Downlink Bit Rate

   This attribute, Per-Session-Agg-Max-DL-Bit-Rate, represents the
   maximum downlink bit-rate bit rate for the mobility session.  It is a variant
   of the AMBR "AMBR" term defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in an Update Notification message sent by
   the local mobility anchor, it indicates the maximum aggregate
   downlink bit-rate bit rate that is being requested for that mobility session.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the maximum aggregate downlink bit-rate bit rate that the peer
   agrees to offer for that mobility session.

   When a QoS option includes both the Per-Session-Agg-Max-DL-Bit-Rate
   attribute and the QOS Traffic Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the QOS Traffic Selector QoS-Traffic-Selector attribute does not apply to this
   attribute.

    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    |S|E|        Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Per-Session-Agg-Max-DL-Bit-Rate               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 3

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (6).

   o  Service (S) flag: This flag is used for extending the scope of the
      target flows for Per-Session-Agg-Max-DL-Bit-Rate to the mobile
      node's other mobility sessions sharing the same service identifier. Service
      Identifier. 3GPP Access Point Name (APN) is an example of service identifier a
      Service Identifier, and that identifier is carried using the
      Service Selection mobility option [RFC5149].

      *  When the (S) flag is set to a value of (1), then the Per-
         Session-Agg-Max-DL-Bit-Rate is measured as an aggregate across
         all the mobile node's other mobility sessions sharing the same
         service identifier
         Service Identifier associated with this mobility session.

      *  When the (S) flag is set to a value of (0), then the target
         flows are limited to the current mobility session.

      *  The (S) flag MUST NOT be set to a value of (1), (1) when there is no service identifier
         Service Identifier associated with the mobility session.

   o  Exclude (E) flag: This flag is used to request that some the downlink
      flows for which the network is providing Guaranteed-Bit-Rate
      service be excluded from the target IP flows for which Per-Session-Agg-Max-
      DL-Bit-Rate Per-
      Session-Agg-Max-DL-Bit-Rate is measured.

      *  When the (E) flag is set to a value of (1), then the request is
         for excluding
         to exclude the IP flows for which Guaranteed-DL-Bit-Rate
         (Section 4.2.8) is negotiated, negotiated from the flows for which Per-
         Session-Agg-Max-DL-Bit-Rate applies is measured.

      *  When the (E) flag is set to a value of (0), then the request is
         not to excluded exclude any IP flows from the target IP flows for which
         Per-Session-Agg-Max-DL-Bit-Rate is measured.

      *  When the (S) flag and (E) flag are both set to a value of (1),
         then the request is for excluding to exclude all the IP flows sharing the
         service identifier
         Service Identifier associated with this mobility session, session from
         the target flows for which Per-Session-Agg-Max-DL-Bit-Rate is
         measured.

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

   o  Per-Session-Agg-Max-DL-Bit-Rate: This is a 32-bit unsigned integer, and
      it integer
      that indicates the aggregate maximum downlink bit-rate bit rate that is
      requested/allocated for all the IP flows associated with that
      mobility session.  The measurement units for Per-Session-Agg-Max-
      DL-Bit-Rate are bits-per-second. bits per second.

4.2.4.  Per Mobility Session  Per-Mobility-Session Aggregate Maximum Uplink Bit Rate

   This attribute, Per-Session-Agg-Max-UL-Bit-Rate, represents the
   maximum uplink bit-rate bit rate for the mobility session.  It is a variant of
   the AMBR "AMBR" term defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in an Update Notification message [RFC7077]
   sent by the local mobility anchor, it indicates the maximum aggregate
   uplink bit-rate bit rate that is being requested for that mobility session.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement [RFC7077]
   message, it indicates the maximum aggregate uplink bit-rate bit rate that the
   peer agrees to offer for that mobility session.

   When a QoS option includes both the Per-Session-Agg-Max-UL-Bit-Rate
   attribute and the QOS Traffic Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the QOS Traffic Selector QoS-Traffic-Selector attribute does not apply to this
   attribute.

    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    |S|E|         Reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Per-Session-Agg-Max-UL-Bit-Rate             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   o  Type: 4

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (6).

   o  Service (S) flag: This flag is used for extending the scope of the
      target flows for Per-Session-Agg-Max-UL-Bit-Rate to the mobile
      node's other mobility sessions sharing the same service identifier. Service
      Identifier. 3GPP Access Point Name (APN) is an example of service identifier a
      Service Identifier, and that identifier is carried using the
      Service Selection mobility option [RFC5149].

      *  When the (S) flag is set to a value of (1), then the Per-
         Session-Agg-Max-UL-Bit-Rate is measured as an aggregate across
         all the mobile node's other mobility sessions sharing the same
         service identifier
         Service Identifier associated with this mobility session.

      *  When the (S) flag is set to a value of (0), then the target
         flows are limited to the current mobility session.

      *  The (S) flag MUST NOT be set to a value of (1), (1) when there is no service identifier
         Service Identifier associated with the mobility session.

   o  Exclude (E) flag: This flag is used to request that some the uplink
      flows for which the network is providing Guaranteed-Bit-Rate
      service be excluded from the target IP flows for which Per-Session-Agg-Max-
      UL-Bit-Rate Per-
      Session-Agg-Max-UL-Bit-Rate is measured.

      *  SGS  When the (E) flag is set to a value of (1), then the request is for excluding
         to exclude the IP flows for which Guaranteed-UL-
         Bit-Rate Guaranteed-UL-Bit-Rate
         (Section 4.2.9) is negotiated, negotiated from the flows for which Per-Session-Agg-Max-UL-Bit-Rate Per-
         Session-Agg-Max-UL-Bit-Rate is measured.

      *  When the (E) flag is set to a value of (0), then the request is
         not to exclude any IP flows from the target IP flows for which
         Per-Session-Agg-Max-UL-Bit-Rate is measured.

      *  When the (S) flag and (E) flag are both set to a value of (1),
         then the request is for excluding to exclude all the IP flows sharing the
         service identifier
         Service Identifier associated with this mobility session, session from
         the target flows for which Per-Session-Agg-Max-UL-Bit-Rate is
         measured.

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

   o  Per-Session-Agg-Max-UL-Bit-Rate: This is a 32-bit unsigned integer, and
      it integer
      that indicates the aggregate maximum uplink bit-rate bit rate that is
      requested/allocated for all the IP flows associated with that
      mobility session.  The measurement units for Per-Session-Agg-Max-
      UL-Bit-Rate are bits-per-second. bits per second.

4.2.5.  Allocation and Retention Priority

   This attribute, Allocation-Retention-Priority, represents allocation
   and retention priority for the mobility session or a set of IP flows.
   It is defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When the QoS option includes both the Allocation and Retention
   Priority Allocation-Retention-Priority
   attribute and the QOS Traffic Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the Allocation and Retention Priority Allocation-Retention-Priority attribute is to be applied at
   a flow level.  The traffic selector in the QOS Traffic Selector QoS-Traffic-Selector
   attribute identifies the target flows.

   When the QoS option including the Allocation and Retention Priority Allocation-Retention-Priority
   attribute does not include the QOS Traffic Selector QoS-Traffic-Selector attribute
   (Section 4.2.10), then the Allocation and Retention Priority Allocation-Retention-Priority attribute is
   to be applied to all the IP flows associated with that 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    |    Reserved   |   PL  |PC |PV |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 5

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (10). (2).

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

   o  Priority-Level (PL): This is a 4-bit unsigned integer value.  It
      is used to decide whether a mobility session establishment or
      modification request can be accepted; this is typically used for
      admission control of Guaranteed Bit Rate traffic in case of
      resource limitations.  The priority level can also be used to
      decide which existing mobility session to pre-empt preempt during resource
      limitations.  The priority level defines the relative timeliness
      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 mobile
      node is roaming.

   o  Preemption-Capability (PC): This is a 2-bit unsigned integer
      value.  It 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.  The values
         (2) and (3) are reserved.

   o  Preemption-Vulnerability (PV): This is a 2-bit unsigned integer
      value.  It defines whether a service data flow can lose the
      resources assigned to it in order to admit a service data flow
      with a 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 preempted 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 preempted and allocated to a
         service data flow with a higher priority level.  The values (2)
         and (3) are reserved.

4.2.6.  Aggregate Maximum Downlink Bit Rate

   This attribute, Aggregate-Max-DL-Bit-Rate, represents the maximum
   downlink bit-rate bit rate for the mobility session.  It is a variant of the
   AMBR
   "AMBR" term defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in an Update Notification message sent by
   the local mobility anchor, it indicates the maximum aggregate bit- bit
   rate for downlink IP flows that is being requested.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the maximum aggregate downlink bit-rate bit rate that the peer
   agrees to offer.

   When a QoS option includes both the Aggregate-Max-DL-Bit-Rate
   attribute and the QOS-Traffic-Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the Aggregate-Max-DL-Bit-Rate attribute is to be enforced at a
   flow level level, and the traffic selectors present in the QOS-Traffic- QoS-Traffic-
   Selector attribute identifies identify those target flows.

   When the QoS option that includes the Aggregate-Max-DL-Bit-Rate
   attribute does not include the QOS-Traffic-Selector QoS-Traffic-Selector attribute
   (Section 4.2.10), then the Aggregate-Max-DL-Bit-Rate attribute is to
   be applied to all the IP flows associated with the 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    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Aggregate-Max-DL-Bit-Rate                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 6

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (6).

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

   o  Aggregate-Max-DL-Bit-Rate: This is a 32-bit unsigned integer, and it integer that
      indicates the aggregate maximum downlink bit-rate bit rate that is
      requested/allocated for downlink IP flows.  The measurement units
      for Aggregate-Max-DL-Bit-Rate are bits-per-second. bits per second.

4.2.7.  Aggregate Maximum Uplink Bit Rate

   This attribute, Aggregate-Max-UL-Bit-Rate, represents the maximum
   uplink bit-rate bit rate for the mobility session.  It is a variant of the
   AMBR
   "AMBR" term defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in an Update Notification message sent by
   the local mobility anchor, it indicates the maximum aggregate uplink
   bit-rate
   bit rate that is being requested.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the maximum aggregate uplink bit-rate bit rate that the peer agrees
   to offer.

   When a QoS option includes both the Aggregate-Max-UL-Bit-Rate
   attribute and the QOS-Traffic-Selector QoS-Traffic-Selector attribute (Section 4.2.10),
   then the Aggregate-Max-UL-Bit-Rate attribute is to be enforced at a
   flow level level, and the traffic selectors present in the QOS-Traffic- QoS-Traffic-
   Selector attribute identifies identify those target flows.

   When the QoS option that includes the Aggregate-Max-UL-Bit-Rate
   attribute does not include the QOS-Traffic-Selector QoS-Traffic-Selector attribute
   (Section 4.2.10), then the Aggregate-Max-UL-Bit-Rate attribute is to
   be applied to all the IP flows associated with the 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    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Aggregate-Max-UL-Bit-Rate                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 7

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (6).

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

   o  Per-Session-Agg-Max-UL-Bit-Rate:  Aggregate-Max-UL-Bit-Rate: This is a 32-bit unsigned integer, and
      it integer that
      indicates the aggregate maximum uplink bit-rate bit rate that is
      requested/allocated requested/
      allocated for all the IP flows associated with that mobility
      session.  The measurement units for Aggregate-Max-UL-Bit-
      Rate Aggregate-Max-UL-Bit-Rate are bits-per-second.
      bits per second.

4.2.8.  Guaranteed Downlink Bit Rate

   This attribute, Guaranteed-DL-Bit-Rate, represents the assured bit- bit
   rate on the downlink path that will be provided for a set of IP flows
   associated with a mobility session.  It is a variant of the GBR "GBR"
   term defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in a an Update Notification message sent by
   the local mobility anchor, it indicates the guaranteed downlink bit- bit
   rate that is being requested.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the guaranteed downlink bit-rate bit rate that the peer agrees to
   offer.

   When a QoS option includes both the Guaranteed-DL-Bit-Rate attribute
   and the QOS-Traffic-Selector QoS-Traffic-Selector attribute (Section 4.2.10), then the
   Guaranteed-DL-Bit-Rate attribute is to be enforced at a flow level level,
   and the traffic selectors present in the QOS-Traffic-Selector QoS-Traffic-Selector
   attribute identifies identify those target flows.

   When the QoS option that includes the Guaranteed-DL-Bit-Rate
   attribute does not include the QOS-Traffic-Selector QoS-Traffic-Selector attribute
   (Section 4.2.10), then the Guaranteed-DL-Bit-Rate attribute is to be
   applied to all the IP flows associated with the 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    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Guaranteed-DL-Bit-Rate                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 8
   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (6).

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

   o  Guaranteed-DL-Bit-Rate: This is of type unsigned a 32-bit integer, and it unsigned integer that
      indicates the guaranteed bandwidth in bits-per-second bits per second for downlink
      IP flows.  The measurement units for Guaranteed-DL-Bit-Rate are
      bits-per-second.
      bits per second.

4.2.9.  Guaranteed Uplink Bit Rate

   This attribute, Guaranteed-UL-Bit-Rate, represents the assured bit- bit
   rate on the uplink path that will be provided for a set of IP flows
   associated with a mobility session.  It is a variant of the GBR "GBR"
   term defined in Section 2.2.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   only be a single instance of this attribute present in a QoS option.

   When this attribute is present in a Proxy Binding Update sent by a
   mobile access gateway, gateway or in a an Update Notification message sent by
   the local mobility anchor, it indicates the guaranteed uplink bit- bit
   rate that is being requested.

   When this attribute is present in a Proxy Binding Acknowledgement
   message,
   message or in an Update Notification Acknowledgement message, it
   indicates the guaranteed uplink bit-rate bit rate that the peer agrees to
   offer.

   When a QoS option includes both the Guaranteed-UL-Bit-Rate attribute
   and the QOS-Traffic-Selector QoS-Traffic-Selector attribute (Section 4.2.10), then the
   Guaranteed-UL-Bit-Rate attribute is to be enforced at a flow level level,
   and the traffic selectors present in the QOS-Traffic-Selector QoS-Traffic-Selector
   attribute identifies identify those target flows.

   When the QoS option that includes the Guaranteed-UL-Bit-Rate
   attribute does not include the QOS-Traffic-Selector QoS-Traffic-Selector attribute
   (Section 4.2.10), then the Guaranteed-UL-Bit-Rate attribute is to be
   applied to all the IP flows associated with the 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    |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Guaranteed-UL-Bit-Rate                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 9

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.  This value is set to (6).

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

   o  Guaranteed-UL-Bit-Rate: This is of type unsigned a 32-bit integer, and it unsigned integer that
      indicates the guaranteed bandwidth in bits-per-second bits per second for uplink
      IP flows.  The measurement units for Guaranteed-UL-Bit-Rate are
      bits-per-second.
      bits per second.

4.2.10.  QoS Traffic Selector

   This attribute, QoS-Traffic-Selector, includes the parameters used to
   match packets for a set of IP flows.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.

   When a QoS option that includes the QoS-Traffic-Selector also
   includes any one or more of the attributes, attributes Allocation-Retention-
   Priority (Section 4.2.5), Aggregate-Max-DL-Bit-Rate (Section 4.2.6),
   Aggregate-Max-UL-Bit-Rate (Section 4.2.7), Guaranteed-DL-Bit-Rate
   (Section 4.2.8), and Guaranteed-UL-Bit-Rate (Section 4.2.9), then
   those included attributes are to be enforced at a flow level level, and the
   traffic selectors present in the QoS-Traffic-Selector attribute
   identifies
   identify those target flows.  Furthermore, the DSCP marking in the
   QoS option is to be applied only to a partial set of the mobile
   node's IP
   flows flows, and the traffic selectors present in the QoS-Traffic-Selector QoS-
   Traffic-Selector attribute identifies identify those target flows.

    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: 10

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.

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

   o  TS Format: An 8-bit unsigned integer indicating the Traffic
      Selector Format.  The values are allocated from the "Traffic
      Selector Format" namespace for the traffic selector sub-option
      defined in [RFC6089]; those defined in [RFC6089] are repeated here
      for clarity.  Value (0) is reserved and MUST NOT be used.  When
      the value of the TS Format field is set to (1), the format that
      follows is the IPv4 Binary Traffic Selector specified in section
      Section 3.1 of [RFC6088], and when the value of TS Format field is
      set to (2), the format that follows is the IPv6 Binary Traffic
      Selector specified in section Section 3.2 of [RFC6088].

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

4.2.11.  QoS Vendor Specific Vendor-Specific Attribute

   This attribute is used for carrying vendor specific vendor-specific QoS attributes.
   The interpretation and the handling of this option is are specific to
   the vendor implementation.

   This attribute can be included in the Quality of Service Quality-of-Service option
   defined in Section 4.1 4.1, and it is an optional attribute.  There can
   be multiple instances of this attribute with different sub-type
   values present in a single 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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Sub-Type   |                   ...                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: 11

   o  Length: The length of the attribute in octets, excluding the Type
      and Length fields.

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

   o  Vendor ID: The Vendor ID is the SMI (Structure of Management
      Information) Network Management Private Enterprise Code of the
      IANA-maintained Private "Private Enterprise Numbers Numbers" registry [SMI].

   o  Sub-Type: An 8-bit field indicating the type of vendor-specific
      information carried in the option.  The name space namespace for this Sub- sub-
      type is managed by the Vendor vendor identified by the Vendor ID field.

4.3.  New Status Code for Proxy Binding Acknowledgement

   This document defines the following new Status Code status code value for use in
   Proxy Binding Acknowledgement message.

   CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request):
   <IANA-2>
   179

4.4.  New Notification Reason for Update Notification Message

   This document defines the following new Notification Reason value for
   use in Update Notification message.

   QOS_SERVICE_REQUEST (QoS Service Requested): <IANA-3> 5

4.5.  New Status Code for Update Notification Acknowledgement Message

   This document defines the following new Status status code value for use in
   Update Notification Acknowledgement message.

   CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request ):

   <IANA-4> Request):
   130

5.  Protocol Considerations

5.1.  Local Mobility Anchor Considerations

   o  The conceptual Binding Cache entry data structure maintained by
      the local mobility anchor, described in Section 5.1 of [RFC5213],
      can be extended to store a list of negotiated Quality of Service Quality-of-Service
      requests to be enforced.  There can be multiple such entries entries, and
      each entry must include the Service Request Identifier, DSCP value
      value, and the attributes defined in Section Section 4.2.

   LMA Receiving a QoS Service Request:

   o  On receiving a Proxy Binding Update message with one or more
      instances of Quality an instance of Service
      the Quality-of-Service option included in the message, message and the
      Operational Code field of the Quality-of-Service option set to
      QUERY, then the local mobility anchor processes includes all the Quality-of-
      Service option(s) and determines
      if reflecting the currently negotiated QoS service request Service
      Requests for that mobility session in the proposed QoS service request(s)
      can be met.  Each instance response message.  The
      Operational Code field in each of the Quality of Service option
      represents a specific QoS service request.  This Quality-of-Service
      option(s), which is included in the response message, is set to
      RESPONSE.

   o  On receiving a Proxy Binding Update message with one or more
      instances of the Quality-of-Service option included in the message
      and the Operational Code field set to ALLOCATE, the local mobility
      anchor processes the option(s) and determines if the QoS Service
      Request for the proposed QoS Service Request(s) can be met.  Each
      instance of the Quality-of-Service option represents a specific
      QoS Service Request.  This determination to accept the request(s)
      can be based on policy configured on the local mobility anchor,
      available network resources, or based on other considerations.

   o  If the local mobility anchor can support the proposed QoS service
      requests Service
      Requests in entirety, then it sends a Proxy Binding
      Acknowledgement message with a status code value of (0).

      *  The message includes all the Quality of Service Quality-of-Service option
         instances copied (including all the option content) from the
         received Proxy Binding Update message.  However, if the
         Operational Code field in the request is  The local mobility
         anchor assigns a QUERY, then the
         message includes all Service Request Identifier to each Service
         Request and sets the Quality SR-ID field of each included Quality-of-
         Service option(s)
         reflecting the currently negotiated QoS service requests for
         that mobility session. option accordingly.

      *  The Operational Code field in each of the Quality of Service Quality-of-Service
         option(s) is set to RESPONSE.

      *  The local mobility anchor should enforce the Quality of Service Quality-of-Service
         rules for all the negotiated QoS service requests Service Requests on the mobile
         node's uplink and downlink traffic.

   o  If the local mobility anchor cannot support any of the requested
      QoS service requests Service Requests in entirety, it rejects the request and sends
      a Proxy Binding Acknowledgement message with the status code value
      set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service
      Request).

      *  The denial for QoS service request MUST NOT result in removal
         of the mobility session for that mobile node.

      *  The Operational Code field in each of the Quality of Service
         option(s) is set to RESPONSE.

      *  The Proxy Binding Acknowledgement message may include the
         Quality of Service option based on the following
         considerations.

         +  If  Since the local mobility anchor cannot support the requested
         QoS services for that mobile node, then Quality of Service option is not
            included in the Proxy Binding
         Acknowledgement message. message will not include any Quality-of-Service
         options.  This serves as an indication to the mobile access
         gateway that QoS services are not supported for that mobile
         node.

         +

      *  The denial of a QoS Service Request MUST NOT result in removal
         of the mobility session for that mobile node.

   o  If the local mobility anchor can support QoS services for
            that the
      mobile node, but for only with lower quality values than indicated in
      the QoS attributes of a downgraded/revised received QoS service
            request, option or only for a partial set some of
      the received QoS service requests, Service Requests, the local mobility anchor
      includes the QoS option for the supported QoS Service Requests in
      the Proxy Binding Acknowledgement message with an updated Quality set of
      QoS attributes.

      *  If the local mobility anchor cannot support some of the
         received QoS Service option(s) Requests for that mobile node, then the
         Quality-of-Service option for these QoS Service Requests is not
         included in the Proxy Binding Acknowledgement message.  This
         serves as an indication to the mobile access gateway that a
         particular QoS Service Request is not supported for that mobile
         node.  This includes the
            case, case where the Attributes attributes in a QoS
         option have conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit-Rate for example, Per-Session-
         Agg-Max-UL-Bit-Rate is lower than the Guaranteed-UL-Bit-Rate.

      *  The local mobility anchor includes only QoS options in the
         Proxy Binding Acknowledgement message for supported QoS
         attributes.  The contents of each of
            the option (including the QoS
         attributes) reflect the QoS service parameters that the local
         mobility anchor can support for that mobile node.  The local
         mobility anchor sets the values of each supported QoS attribute
         according to the level of QoS it can support for the mobile
         node.  The Service Request Identifier in each of the included
         QoS options is set to a value of (0).  The Operational Code
         field in each of the Quality of Service included Quality-of-Service option(s) is
         set to NEGOTIATE.  This serves as an indication for the mobile
         access gateway to resend the Proxy Binding Update message with
         the revised QoS parameters.

   LMA Sending a QoS Service Request:

   o  The local mobility anchor, at any time, can initiate a QoS service
      request Service
      Request for a mobile node, node by sending an Update Notification
      message [RFC7077].  The Notification Reason in the Update
      Notification message is set to a value of QOS_SERVICE_REQUEST QOS_SERVICE_REQUEST, and
      the Acknowledgement Requested (A) flag is set to a value of (1).

      *  New QoS service request: Service Request:

         +  The message includes a Quality one or more instances of Service the Quality-
            of-Service option.  Each instance of the option with will include
            one or more QoS attributes included in the option. attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to ALLOCATE.

         +  The Service Request Identifier is set to a value of (0). the allocated
            value.

         +  The DSCP field in the Traffic Class (TC) field reflects is set to the
            requested DSCP value.

      *  Modification of an existing QoS Service Request:

         +  The message includes a Quality one or more instances of Service the Quality-
            of-Service option with the QoS attributes reflecting the
            updated values in the
            Attributes, attributes and the updated list of Attributes.
            attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to MODIFY.

         +  The Service Request Identifier is set to a value that was
            allocated for that QoS service request. Service Request.

         +  There can be more than one QOS service request  The DSCP field in a single
            message.  If so, the message includes an instance of a
            Quality of Service option for each of those service
            requests.

      *  Deletion Traffic Class (TC) field is set to the
            requested DSCP value.

      *  Deletion of an existing QoS Service Request:

         +  The message includes the Quality-of-Service option(s) with
            the relevant QoS attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to DE-ALLOCATE.

         +  The Service Request Identifier is set to a value that was
            allocated for that QoS service request. Service Request.

         +  The message includes a Quality of Service option with the
            QoS attributes reflecting DSCP field in the updated values for Traffic Class (TC) field is set to the
            attributes.
            DSCP value associated with that request.

      *  Query for the previously negotiated QoS Service Requests:

         +  The message includes a single instance of the Quality-of-
            Service option without including any QoS attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to QUERY.

         +  The Service Request Identifier is set to a value of (0).

         +  The message includes a single instance of DSCP field in the Quality Traffic Class (TC) field is set to a
            value of
            Service option without including any QoS Attributes. (0).

   o  Handling a Response to the QoS Service Request:

      *  If the received Update Notification Acknowledgement [RFC7077]
         message has the status code Status Code field set to a value of (0), the local
         mobility anchor should enforce the Quality of Service Quality-of-Service rules for
         the negotiated QoS parameters on the mobile node's uplink and
         downlink traffic.

      *  If the received Update Notification Acknowledgement message is
         with has
         the status code Status Code field set to a value of
         (CANNOT_MEET_QOS_SERVICE_REQUEST),
         CANNOT_MEET_QOS_SERVICE_REQUEST, the local mobility anchor
         applies the following considerations. considerations:

         +  The denial of a QoS service request Service Request results in removal of
            any
            of the mobile node's Binding Cache entries. QoS state associated with that request.

         +  If the message did not include any Quality of Service Quality-of-Service
            option(s), then it is an indication from the mobile access
            gateway that QoS services are not enabled for the mobile
            node.

         +  If the Operational Code field in the Quality of Service Quality-of-Service
            option is set to a value of NEGOTIATE and the message
            includes one or more instances of the Quality of Service Quality-of-Service
            option, but the option contents reflect a downgraded/revised
            set of QoS parameters, then the local mobility anchor MAY
            choose to agree to proposed QoS service request Service Request by resending
            a new Proxy Binding Update Notification message with the updated Quality
            of Service option. Quality-
            of-Service option(s).

   General Considerations:

   o  Any time the local mobility anchor removes a mobile node's
      mobility session by removing a Binding Cache entry [RFC5213], [RFC5213] for
      which QoS resources have been previously allocated, those
      allocated resources are released.

   o  Any time the local mobility anchor receives a Proxy Binding Update
      with HI hint = 3 (inter-MAG handover), the local mobility anchor
      when sending a Proxy Binding Acknowledgement message includes the
      QoS option(s) for each of the QoS service requests Service Requests that are active
      for that mobile node.  This allows the mobile access gateway to
      allocate QoS resources on the current path.  This is relevant for
      the scenario where a mobile node performs an a handover to a new
      mobile access gateway which that is unaware of the previously negotiated
      QoS services.

5.2.  Mobile Access Gateway Considerations

   o  The conceptual Binding Update List entry data structure maintained
      by the mobile access gateway, described in Section 6.1 of
      [RFC5213], can be extended to store a list of negotiated Quality
      of Service Quality-
      of-Service requests to be enforced.  There can be multiple such
      entries
      entries, and each entry including must include the Service Request
      Identifier, DSCP value and the attributes defined in Section Section 4.2.

   MAG Receiving a QoS Service Request:

   o  On receiving a an Update Notification message with one or more
      instances of Quality of Service the Quality-of-Service option included in the
      message, the mobile access gateway processes the option(s) and determine
      determines if the QoS service request Service Request for the proposed QoS service request(s) Service
      Request(s) can be met.  Each instance of the Quality of Service Quality-of-Service
      option represents a specific QoS service request. Service Request.  This
      determination to accept the request(s) can be based on policy
      configured on the mobile access gateway, available network
      resources, or based on other considerations.

   o  If the mobile access gateway can support the proposed QoS service
      requests Service
      Requests in entirety, then it sends a an Update Notification
      Acknowledgement message with a status code value of (0).

      *  The message includes all the Quality of Service Quality-of-Service option
         instances copied (including all the option content) from the
         received Update Notification message.  However, if the
         Operational Code field in the request is a QUERY, then the
         message includes all the Quality of Service Quality-of-Service option(s)
         reflecting the currently negotiated QoS service requests Service Requests for
         that mobility session.

      *  The Operational Code field in each of the Quality of Service Quality-of-Service
         option(s) is set to RESPONSE.

      *  The mobile access gateway should enforce the Quality of Service Quality-of-Service
         rules for all the negotiated QoS service requests Service Requests on the mobile
         node's uplink and downlink traffic.

   o  If the mobile access gateway cannot support any of the requested
      QoS service requests Service Requests in entirety, then it rejects the request and
      send
      sends an Update Notification Acknowledgement message with the
      status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet
      QoS Service Request).

      *  The denial for QoS service request Service Request MUST NOT result in removal
         of the mobility session for that mobile node.

      *  The Operational Code field in each of the Quality of Service
         option(s) is set to RESPONSE.

      *  The Update Notification Acknowledgement message may include the
         Quality of Service
         Quality-of-Service option(s) based on the following
         considerations.

         +  If the mobile access gateway cannot support QoS services for
            that mobile node, then Quality of Service the Quality-of-Service option is not
            included in the Update Notification Acknowledgement message.
            This serves as an indication to the local mobility anchor
            that QoS services are not supported for that mobile node.

         +  If the mobile access gateway can support QoS services for
            that
            the mobile node, but for a downgraded/revised only with lower quality values than
            indicated in the QoS service
            request, or for attributes of a partial received QoS option,
            the mobile access gateway includes the QoS option in the
            Update Notification Acknowledgement message with an updated
            set of QoS service requests, then attributes.  The mobile access gateway sets the updated Quality
            values of Service option(s) is included each QoS attribute according to the level of QoS
            it can support for the mobile node.  The mobile access
            gateway includes only QoS options in the Update Notification
            Acknowledgement message for supported QoS attributes.  If
            the mobile access gateway receives one or multiple QoS
            options, whose QoS attributes are not supported, it omits
            these QoS options in the Update Notification Acknowledgement
            message.  This includes the case, case where the Attributes attributes in a
            QoS option have conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit-
            Rate for example, Per-
            Session-Agg-Max-UL-Bit-Rate is lower than the Guaranteed-UL-Bit-Rate. Guaranteed-UL-Bit-
            Rate.  The contents of each of the option (including the QoS
            attributes) reflect the QoS service parameters that the
            mobile access gateway can support for that mobile node.  The
            Operational Code field in each of the Quality of Service Quality-of-Service
            option(s) is set to NEGOTIATE.  This serves as an indication
            to the local mobility anchor to resend the Update
            Notification message with the revised QoS parameters.

   MAG Sending a QoS Service Request:

   o  The mobile access gateway, at any time, can initiate a QoS service
      request Service
      Request for a mobile node, node by sending a Proxy Binding Update
      message.  The QoS service request Service Request can be initiated as part of the
      initial Binding registration, registration or during binding Binding re-registrations.

      *  New QoS service request: Service Request:

         +  The message includes a Quality one or more instances of Service the Quality-
            of-Service option.  Each instance of the option with will include
            one or more QoS attributes included in the option. attributes.

         +  The Operational Code field in the Quality each of Service the Quality-of-Service
            option is set to ALLOCATE.

         +  The Service Request Identifier is set to a value of (0).

         +  The DSCP value in the Traffic Class field reflects the
            requested DSCP value.

      *  Modification of an existing QoS Service Request:

         +  The message includes a Quality one or more instances of Service the Quality-
            of-Service option with the QoS attributes reflecting the
            updated values in the
            Attributes, attributes and the updated list of Attributes.
            attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to MODIFY.

         +  The Service Request Identifier is set to a value that was
            allocated for that QoS service request. Service Request.

         +  There can be more than one QOS service request  The DSCP field in a single
            message.  If so, the message includes an instance of a
            Quality of Service option for each of those service
            requests. Traffic Class (TC) field is set to the
            requested DSCP value.

      *  Deletion of an existing QoS Service Request:

         +  The message includes the Quality-of-Service option(s) with
            the relevant QoS attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to DE-ALLOCATE.

         +  The Service Request Identifier is set to a value that was
            allocated for that QoS service request. Service Request.

         +  The message includes a Quality of Service option with the
            QoS attributes reflecting DSCP field in the updated values for Traffic Class (TC) field is set to the
            attributes.
            DSCP value associated with that request.

      *  Query for the previously negotiated QoS Service Requests:

         +  The message includes a single instance of the Quality-of-
            Service option without including any QoS attributes.

         +  The Operational Code field in the Quality of Service Quality-of-Service option
            is set to QUERY.

         +  The Service Request Identifier is set to a value of (0).

         +  The message includes a single instance of DSCP field in the Quality Traffic Class (TC) field is set to a
            value of
            Service option without including any QoS Attributes. (0).

   o  Handling a Response to the QoS Service Request:

      *  If the received Proxy Binding Acknowledgement message has the
         status code
         Status Code field set to a value of (0), the mobile access
         gateway should enforce the Quality of Service Quality-of-Service rules for the
         negotiated QoS parameters on the mobile node's uplink and
         downlink traffic.

      *  If the received Proxy Binding Acknowledgement message has the
         status code
         Status Code field set to a value of
         (CANNOT_MEET_QOS_SERVICE_REQUEST),
         CANNOT_MEET_QOS_SERVICE_REQUEST, the mobile access gateway
         applies the following considerations.

         +  The denial of a QoS service request MUST NOT result Service Request results in removal of
            any of the mobile node's Binding Update list entries. QoS state associated with that request.

         +  If the message did not include any Quality of Service Quality-of-Service
            option(s), then it is an indication from the local mobility
            anchor that QoS services are not enabled for the mobile
            node.

         +  If the Operational Code field in the Quality of Service Quality-of-Service
            option is set to a value of NEGOTIATE and the message
            includes one or more instances of the Quality of Service Quality-of-Service
            option, but the option contents reflect a downgraded/revised
            set of QoS parameters, then the mobile access gateway MAY
            choose to agree to proposed QoS service request Service Request by resending
            a new Proxy Binding Update message with the updated Quality
            of Service Quality-
            of-Service option.

      *  General Considerations:

         +  There can be more than one QOS service request QoS Service Request in a single
            message.  If so, the message includes an instance of a
            Quality of Service
            Quality-of-Service option for each of those service
            requests. Service
            Requests.  Furthermore, the DSCP value is different in each
            of those requests.

         +  Any time the mobile access gateway removes a mobile node's
            mobility session by removing a Binding Update List entry
            [RFC5213],
            [RFC5213] for which QoS resources have been previously
            allocated, those allocated resources are released.

6.  QoS Services in Integrated WLAN-3GPP Networks

6.1.  Technical Scope and Procedure

   The QoS option specified in this document can provide the equivalent
   level of QoS information defined in 3GPP, which is used to enforce
   QoS policies for IP flows, which flows that have been established while the mobile
   node is attached to WLAN access, access or moved from 3GPP to WLAN access.
   The QoS classification defined by the 3GPP specification [TS23.207]
   [TS29.212] is provided by Differentiated Services techniques in the
   IP transport network.  The QoS classification used in the IP
   transport network and is further translated as appropriate into to WLAN QoS specification QoS-specific
   techniques in
   WLAN access, the WLAN access using appropriate WLAN QoS
   specifications [IEEE802.11aa-2012] [WMM1.2.0].  The details of which are
   described in Appendix A and Appendix B.

   Figure 6 illustrates a generalized architecture where the QoS option
   can be used.  The QoS policies could be retrieved from a Policy
   Control Function (PCF), such as defined in current cellular mobile
   communication standards, which aims to assign an appropriate QoS
   class to a mobile node's individual flows.  Alternatively, more
   static and default QoS rules could be made locally available, e.g. e.g.,
   on a local mobility anchor, through administration.

           Non-cellular access       |  Cellular Core Network   Cellular
              (e.g.
              (e.g., WLAN)           |      (e.g.      (e.g., EPC)           Access
                                     |                        (e.g.                        (e.g.,
                                     |         +-----------+     EUTRAN)
                                     |         |    PCF    |
                                     |         |(e.g. PCRF)|         |(e.g.,PCRF)|
             +----+                  |         +-----+-----+
             |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 6: Architecture for QoS inter-working Inter-Working between cellular access Cellular Access
                          and non-cellular access Non-Cellular Access

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

6.2.  Relevant QoS Attributes

   The QoS Option shall at least contain a DSCP value being associated
   with IP flows of a mobility session.  The DSCP value should
   correspond to the 3GPP QoS Class Index (QCI), which identifies the
   type of service in term terms of QoS characteristics (e.g. (e.g., conversational
   voice, streaming video, signalling, signaling, and best effort,...); effort); more details on
   DSCP and QCI mapping are given on section in Appendix A.  Optional QoS
   information could also be added.  For instance, in order to comply
   with the bearer model defined in 3GPP [TS23.203], the following QoS
   parameters are conveyed for each PMIPv6 mobility session:

   o  Default, non-GBR bearer (QCI=5-9)

      *  DSCP=(BE, AF11, AF21, AF31, AF32)

      *  Per-MN AMBR-UL/DL

      *  Per-Session AMBR-UL/DL {S=1,E=1}

      *  AARP

      APN (Access Point Name) is provided via the Service Selection ID
      defined in [RFC5149].  If APN is not interpreted by Wi-Fi AP, the
      latter will police only based on Per-MN AMBR-UL/DL (without Per-
      Session AMBR-UL/DL) on the Wi-Fi link.

   o  Dedicated, GBR bearer (QCI=1-4)

      *  DSCP=(EF, AF41)

      *  GBR-UL/DL

      *  MBR-UL/DL

      *  AARP

      *  TS

      Wi-Fi AP will perform the policy enforcement with the minimum bit- bit
      rate=GBR and the maximum bit-rate=MBR. bit rate=MBR.

   o  Dedicated, non-GBR bearer (QCI=5-9)

      *  DSCP=(BE, AF11, AF21, AF31, AF32} AF32)

      *  Per-MN AMBR-UL/DL

      *  Per-Session AMBR-UL/DL {S=1,E=1}

      *  AARP

      *  TS

      If APN is not interpreted by Wi-Fi AP, it will police based only
      on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi
      link.

   If DSCP values follow the 3GPP specification and deployment, the code
   point can carry intrinsically additional attributes according to
   Figure 7. 7 in Appendix A.

   For some optional QoS attributes attributes, the signalling signaling can differentiate
   enforcement per mobility session and per IP flow.  For the latter, as
   long as the AMBR constraints are met, the rule associated with the
   identified flow(s) overrules the aggregated rules which that apply per
   Mobile Node
   mobile node or per Mobility Session. mobility session.  Additional attributes can be
   appended to the QoS option, but their definition and specification is
   out of scope of this document and are left to their as considerations for
   actual deployment.

7.  IANA Considerations

   This document requires

   IANA has completed the following IANA actions. actions:

   o  Action-1: This specification defines a new mobility option, the
      Quality of Service
      Quality-of-Service (QoS) option.  The format of this option is
      described in Section 4.1.  The type value <IANA-1> 58 for this mobility
      option needs to be has been allocated from the Mobility Options "Mobility Options" registry at
      <http://www.iana.org/assignments/mobility-parameters>.
      RFC Editor: Please replace <IANA-1> in Section 4.1 with the
      assigned value and update this section accordingly.

   o  Action-2: This specification defines a new mobility attribute
      format, Quality of Service the Quality-of-Service attribute.  The format of this
      attribute is described in Section Section 4.2.  This attribute can be
      carried in the Quality of Service Quality-of-Service mobility option.  The type
      values for this attribute need to be are managed by IANA in a new
      Registry, registry,
      the "Quality of Service "Quality-of-Service Attribute Registry".  This registry is
      maintained under the "Mobile IPv6 Parameters" parameters" registry at
      <http://www.iana.org/assignments/mobility-parameters>.  This
      specification reserves the following type values. values listed below.  All other
      values (12 - 254) are unassigned and may be assigned by IANA using
      the Specification Required policy [RFC5226].  The Designated
      Expert reviewing the value assignment is expected to verify that
      the protocol extension follows the Proxy Mobile IPv6 architecture
      and does not raise backward compatibility backward-compatibility issues with existing
      deployments.

   +=====+=================================+=================+
   |Value|       Description               |   Reference     |
   +=====+=================================+=================+
   | 0   | Reserved                        | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 1   | Per-MN-Agg-Max-DL-Bit-Rate      | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 2   | Per-MN-Agg-Max-UL-Bit-Rate      | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 3   | Per-Session-Agg-Max-DL-Bit-Rate | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 4   | Per-Session-Agg-Max-UL-Bit-Rate | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 5   | Allocation-Retention-Priority   | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 6   | Aggregate-Max-DL-Bit-Rate       | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 7   | Aggregate-Max-UL-Bit-Rate       | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 8   | Guaranteed-DL-Bit-Rate          | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 9   | Guaranteed-UL-Bit-Rate          | <this draft>    |
   +=====+===================================================+
   | 10  | QoS-Traffic-Selector            | <this draft>    |
   +=====+===================================================+
   | 11  | QoS-Vendor-Specific-Attribtute  | <this draft>   RFC 7222      |
   +=====+===================================================+
   | 255 | Reserved                        | <this draft>    |
   +=====+===================================================+

   o  Action-3: This document defines a new status value,
      CANNOT_MEET_QOS_SERVICE_REQUEST (<IANA-2>) for use in Proxy
      Binding Acknowledgement message, as described in Section 4.3.
      This value is to be assigned from the "Status Codes" registry at
      <http://www.iana.org/assignments/mobility-parameters>.  The
      allocated value has to be greater than 127.  RFC Editor: Please
      replace <IANA-2> in Section 4.3 with the assigned value and update
      this section accordingly.

   o  Action-4: This document defines a new Notification Reason,
      QOS_SERVICE_REQUEST (<IANA-3>) for use in Update Notification
      message [RFC7077] as described in Section 4.4.  This value is to
      be assigned from the "Update Notification Reasons Registry" at
      <http://www.iana.org/assignments/mobility-parameters>.  RFC
      Editor: Please replace <IANA-3> in Section 4.4 with the assigned
      value and update this section accordingly.

   o  Action-5: This document defines a new Notification Reason,
      CANNOT_MEET_QOS_SERVICE_REQUEST (<IANA-4>) for use in Update
      Notification Acknowledgement message [RFC7077] as described in
      Section 4.5.  This value is to be assigned from the "Update
      Notification Acknowledgement Status Registry" at
      <http://www.iana.org/assignments/mobility-parameters>.  RFC
      Editor: Please replace <IANA-4> in Section 4.5 with the assigned
      value and update this section accordingly.

8.  Implementation Status

   Note to RFC Editor: Please remove this section and the reference to
   [RFC6982] before publication.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   Cisco Implementation

      Organization: Cisco

      Description: QoS Extensions to Cisco IOS-based MAG and LMA
      Implementations.  Engineering prototype code under development.

      Coverage: Support includes QoS signaling from MAG to LMA based on
      PBU/PBA and LMA to MAG based on the recently standardized UPN/UPA
      messages.  Implementation includes only 10  | QoS-Traffic-Selector            |   RFC 7222      |
   +=====+===================================================+
   | 11  | QoS-Vendor-Specific-Attribute   |   RFC 7222      |
   +=====+===================================================+
   | 255 | Reserved                        |   RFC 7222      |
   +=====+===================================================+

   o  Action-3: This document defines a partial set of QoS
      attributes and support new status code,
      CANNOT_MEET_QOS_SERVICE_REQUEST (179), for other Attributes is under development.
      The QoS option is based on the Vendor-specific mobility option,
      but it has all the parameters defined use in -07 version of the
      document.  We have plans to show a demo Proxy Binding
      Acknowledgement messages, as described in the next IETF.

      Licensing: Closed.  However, cisco Section 4.3.  This value
      has plans to release the MAG
      portion of the code for Linux as open source.

      Implementation Experience: The feedback been assigned from the developer
      suggests that the protocol extensions needed "Status Codes" registry at
      <http://www.iana.org/assignments/mobility-parameters>.

   o  Action-4: This document defines a new Notification Reason,
      QOS_SERVICE_REQUEST (5), for this
      specification proved to be reasonably straightforward.  Numerous
      draft revisions were made based on the questions and comments use in Update Notification messages
      [RFC7077] as described in Section 4.4.  This value has been
      assigned from the developer.  The effort to most part appears to be around
      interfacing with the platform specific QoS features for enforcing
      the negotiated QoS parameters for a subscriber's IP session/flows.
      On Cisco IOS, there is "Update Notification Reasons Registry" at
      <http://www.iana.org/assignments/mobility-parameters>.

   o  Action-5: This document defines a programmatic interface with rich
      semantics new status code,
      CANNOT_MEET_QOS_SERVICE_REQUEST (130), for interfacing with IOS MQC.  It needs to be seen use in Update
      Notification Acknowledgement messages [RFC7077] as
      how this can be realized on a Linux OS.

      Contact: Sri Gundavelli (sgundave@cisco.com)

9. described in
      Section 4.5.  This value has been assigned from the "Update
      Notification Acknowledgement Status Registry" at
      <http://www.iana.org/assignments/mobility-parameters>.

8.  Security Considerations

   The quality of service Quality-of-Service option defined in this specification is for
   use in Proxy Binding Update, Proxy Binding Acknowledgement, Update
   Notification, and Update Notification Acknowledgement messages.  This
   option is carried in these message messages like any other mobility header
   option.  [RFC5213] and [RFC7077] identify the security considerations
   for these signalling signaling messages.  The quality of service option when  When included in these signalling messages signaling
   messages, the Quality-of-Service option does not require additional
   security considerations.

10.

9.  Acknowledgements

   The authors of this document thank the members of NetExt Working
   Group working
   group for the valuable feedback to different versions of this
   specification.  In particular particular, the authors want to thank Basavaraj
   Patil, Behcet Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson,
   Tricci So, Ahmad Muhanna, Pete McCann, Byju Pularikkal, John
   Kaippallimalil, Rajesh Pazhyannur, Carlos J. Bernardos Cano, Michal
   Hoeft, Ryuji Wakikawa, Liu Dapeng, Seil Jeon, and Georgios
   Karagiannis.

   The authors would like to thank all the IESG reviewers and specially, reviewers, especially,
   Ben Campbell, Barry Leiba, Jari Arkko, Alissa Cooper, Stephen
   Farrell, Ted Lemon Lemon, and Alia Atlas for their valuable comments and
   suggestions to improve this specification.

   Finally, the authors would like to express sincere and profound
   appreciation to our Internet Area Director, Brian Haberman Haberman, for his
   guidance and great support in allowing us to complete this work.

11.

10.  References

11.1.

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.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 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.

   [RFC7077]  Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
              J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
              RFC 7077, November 2013.

11.2.

10.2.  Informative References

   [GSMA.IR.34]
              GSMA, "Inter-Service "Guidelines for IPX Provider networks (Previously
              Inter-Service Provider IP Backbone Guidelines 5.0", Guidelines)", Official
              Document PRD IR.34, May 2013.

   [IEEE802.11-2012]
              IEEE, "Part 11: Wireless LAN Medium Access Control(MAC) Control (MAC)
              and Physical Layer (PHY) Specifications", 2012.

   [IEEE802.11aa-2012]
              IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
              and Physical Layer (PHY) specifications", Specifications, Amendment 2: MAC
              Enhancements for Robust Audio Video Streaming", 2012.

   [IEEE802.11e-2005]
              IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications, Amendment 8:
              Medium Access Control (MAC) Quality of Service (QoS)
              Enhancements", 2005.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
              1998.

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

   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594, August
              2006.

   [RFC5149]  Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
              Selection for Mobile IPv6", RFC 5149, February 2008.

   [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
              Network Mobility (NEMO) Basic Support", RFC 6089, January
              2011.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              July 2013.

   [SMI]      IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
              Private Enterprise Codes, February 2011. April 2014,
              <http://www.iana.org/assignments/enterprise-numbers>.

   [TS22.115] 3GPP, "Technical Specification Group Services and System
              Aspects,
              Aspects; Service aspects; Charging and Billing", 2002. billing", 3GPP TS
              22.115, 2010.

   [TS23.203] 3GPP, "Policy "Technical Specification Group Services and System
              Aspects; Policy and charging control architecture", 3GPP
              TS 23.203, 2013.

   [TS23.207] 3GPP, "End-to-End Quality of Service (QoS) Concept and
              Architecture, Release 10", 3GPP TS 23.207, 2011.

   [TS23.402] 3GPP, "Architecture "Technical Specification Group Services and System
              Aspects; Architecture enhancements for non-3GPP accesses",
              2010.
              3GPP TS 23.402, 2012.

   [TS29.212] 3GPP, "Policy and Charging Control over Gx/Sd Reference
              Point, Release 11", 3GPP TS 29.212, 2011.

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

Appendix A.  Information when implementing When Implementing 3GPP QoS in IP transport
             network Transport
             Network

A.1.  Mapping tables Tables

   Mapping between 3GPP QCI values and DSCP is defined in [GSMA.IR.34]
   as follows.

   +=====+================+===========================+======+
   | QCI | Traffic Class  | DiffServ Per-Hop-Behavior | 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|
   +=====+===================================================+
   |  7  |  Interactive   |             AF21          |010010|
   +=====+===================================================+
   |  8  |  Interactive   |             AF11          |001010|
   +=====+===================================================+
   |  9  |   Background   |              BE           |000000|
   +=====+===================================================+

                     Figure 7: QCI/DSCP Mapping Table

   Mapping between QoS attributes defined in this document and 3GPP QoS
   parameters is as follows.

          +=======+===============================+=============+
          |Section|        PMIPv6 QoS             |  3GPP QoS   |
          |       |        Attribute              | Parameter   |
          +=======+===============================+=============+
          | 4.2.1 |   Per-MN-Agg-Max-DL-Bit-Rate  |  UE AMBR-DL |
          +-------+-------------------------------+-------------+
          | 4.2.2 |   Per-MN-Agg-Max-UL-Bit-Rate  |  UE AMBR-UL |
          +-------+-------------------------------+-------------+
          | 4.2.3 |Per-Session-Agg-Max-DL-Bit-Rate| APN AMBR-DL |
          |       |          Flags: (S=1, E=1)    |             |
          +-------+-------------------------------+-------------+
          | 4.2.4 |Per-Session-Agg-Max-UL-Bit-Rate| APN AMBR-UL |
          |       |          Flags: (S=1, E=1)    |             |
          +-------+-------------------------------+-------------+
          | 4.2.5 | Allocation-Retention-Priority |     ARP     |
          +-------+-------------------------------+-------------+
          | 4.2.6 |   Aggregate-Max-DL-Bit-Rate   |    MBR-DL   |
          +-------+-------------------------------+-------------+
          | 4.2.7 |   Aggregate-Max-UL-Bit-Rate   |    MBR-UL   |
          +-------+-------------------------------+-------------+
          | 4.2.8 |    Guaranteed-DL-Bit-Rate     |    GBR-DL   |
          +-------+-------------------------------+-------------+
          | 4.2.9 |    Guaranteed-UL-Bit-Rate     |    GBR-UL   |
          +-------+-------------------------------+-------------+
          | 4.2.10|     QoS-Traffic-Selector      |     TFT     |
          +-------+-------------------------------+-------------+

      Figure 8: QoS attributes Attributes and 3GPP QoS parameters Parameters Mapping Table

A.2.  Use cases Cases and protocol operations

   This Protocol Operations

   The following subsections provide example message flow charts for
   scenarios where the QoS option extensions will apply as described in
   (Section 6.1),
   Section 6.1 to the protocol operation for QoS rules establishment
   as shown in Appendix
   (Appendices A.2.1 and Appendix A.2.2, A.2.2) and to modification as
   show in Appendix A.2.3. (Appendix A.2.3).

A.2.1.  Handover of existing Existing QoS rules Rules

   In Figure 9, the MN is first connected to the LTE network, and having network with a
   multimedia session session, such as a video call call, with appropriate QoS
   parameters set by the Policy Control Function.  Then, the MN
   discovers a Wi-Fi AP (e.g., at home or in a cafe) and switches to it it,
   provided that Wi-Fi access has a higher priority when available.  Not
   only is the session continued, but also the QoS is also maintained after
   moving to the Wi-Fi access.  In order for that to happen, the LMA
   delivers the QoS parameters according to the bearer type on the 3GPP
   access to the MAG via the PMIPv6 signaling with the QoS option
   (OC=ALLOCATE, SR-ID, QoS attributes, etc.).  The equivalent QoS
   treatment is provided by the Wi-Fi AP toward the MN on the Wi-Fi
   link.

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

              Figure 9: Handover Scenario (from LTE to WLAN)

   Figure 10 shows an example of how the QoS rules can be conveyed and
   enforced between the LMA and MN in the case of a handover from 3GPP
   access to WLAN access.

   +--+            +--+             +---+                       +---+
   |MN|            |AP|             |MAG|                       |LMA|
   +--+            +--+             +---+                       +---+
    ||              |                 |     To                    |data
    |+--detach      |                 |  cellular<-==data[DSCP]==-|<----
    +----attach-----+                 |   access             [QoS rules]
    |               |-INFO[MNattach]->|                           |
    |               |                 |-------PBU[handover]------>|
    |               |                 |                           |
    |               |                 |<--PBA[QoS option(OC=1 )]--|
    |               |<-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 QoS rules
   (D): Validate received DSCP and apply DSCP according to QoS rules

                     Figure 10: Handover of QoS rules Rules

A.2.2.  Establishment of QoS rules Rules

   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, but 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 on the Wi-Fi Access access network.  The PMIP interface is used
   to realize this QoS policy provisioning.

   The use-case use case is depicted on Figure 11.  The MN first attaches to the
   Wi-Fi network.  During the attachment process, the LMA, which may
   communicate with Policy Control Function (using procedures outside
   the scope of this document), provides the QoS parameters to the MAG
   via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e. (i.e., PBA).
   Subsequently, an application on the MN may trigger the request for
   alternative QoS resources, e.g., by use of the WMM-API. WMM-API (Wi-Fi
   Multimedia - API).  The MN may request that traffic resources be
   reserved using L2 signaling, e.g., sending an ADDTS Add Traffic System
   (ADDTS) message [IEEE802.11-2012].  The request is relayed to the MAG
   MAG, which includes the QoS parameters in the QoS option
   (OC=ALLOCATE) on the PMIP signaling (i.e. (i.e., the PBU initiated upon
   flow creation).  The LMA, in co-ordination coordination with the PCF, can then
   authorize the enforcement of such QoS policy.  Then, the QoS
   parameters are provided to the MAG via the QoS option (OC=ALLOCATE,
   SR-ID, QoS attributes, etc.) in the PMIP signaling signaling, and the
   equivalent QoS treatment is provided towards the MN on the Wi-Fi
   link.

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

                    Figure 11: QoS policy provisioning Policy Provisioning

   Figure 12 shows an example of how the QoS rules can be conveyed and
   enforced between the LMA and MN in the case of initial attachment to
   WLAN access.

   +--+            +--+             +---+                       +---+
   |MN|            |AP|-------------|MAG|-----------------------|LMA|
   +--+            +--+             +---+                       +---+
    |               |                 |                           |
    |               |                 |                           |
    +----attached---+                 |                      [QoS rules]
    |               |                 |                           |
   new session      |(E)              |(F)                        |data
    |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|--->
    |               |                 |--PBU[update,QoS option]-->|
    |               |                 |     (ReReg) (OC=1) Validate and
    |               |                 |                     add QoS rule
    |               |                 |<----PBA[QoS option]----|
    |               |<-INFO[QoSrules]-|        (OC=1, SR-ID)[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 the local mobility
        anchor
         has classified classifies the new flow (notified with PBA) or the mobile
        access gateway classifies new flow and proposes the associated
        QoS class to the local mobility anchor for validation (proposed
        with PBU, notification of validation result with PBA)

      Figure 12: Adding new New QoS Service Request for MN initiated flow MN-Initiated Flow

A.2.3.  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 e.g., IP Multimedia Subsystems
   (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. (e.g., IMS Call Session Control Function).
   Once the communication is established, the application network
   function notifies the PCF about the new IP flow.  The PCF function in
   turn notifies the LMA about the needed QoS parameters identifying the
   IP flow and QoS parameters.  LMA sends an Update Notification message
   [RFC7077] to the MAG with the Notification Reason value set to
   "QOS_SERVICE_REQUEST".  The MAG, on
   QOS_SERVICE_REQUEST.  On receiving the Update Notification message,
   the MAG completes the PBU/PBA signaling for obtaining the new QoS
   parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes,
   etc.).  The MAG provisions the newly obtained QoS parameters on the
   access network to ensure the newly established IP flow gets its
   requested network resources.

   Upon termination of the established IP flow, the application network function
   again notifies the PCF function for removing to remove the established QoS
   parameters.  The PCF notifies the LMA for withdrawing to withdraw the QoS resources
   established for that voice flow.  The LMA sends an Update
   Notification message to the MAG with the "Notification Reason" value
   set to "FORCE-REREGISTRATION".  The MAG on  On receiving this message Update Notification
   Acknowledgement and message, the MAG completes the PBU/PBA signaling for
   removing the existing QoS rules (OC=DE-ALLOCATE, SR-ID).  The MAG
   then removes the QoS parameters from the corresponding IP flow and
   releases the dedicated network resources on the access network.

Appendix B.  Information when implementing PMIP based When Implementing PMIP-Based QoS support Support with
             IEEE 802.11e

   This section shows, as an example, the end-to-end QoS management with
   a 802.11e capable 802.11e-capable WLAN access link and a PMIP based 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): (ACs):

      Voice (AC_VO): Very high priority 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 High-priority queue with low delay.  Time-sensitive
      video data is automatically sent to this queue.

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

      Background (AC_BK): Lowest priority 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). DSCP.  To allow consistent QoS management on
   both wireless and wired interfaces, the access point relies on the
   802.11e specification specification, which define defines 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 in Figure 13 13, and the 802.11e/802.1D 802.11e
   /802.1D priority mapping is reminded shown 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        |
                     +-----------+------------------+

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

             Figure 13: End-to-end End-to-End QoS management 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 (i.e.,
   802.1D priority).  This mapping is not standardized and may differ
   between operator; operators; a mapping example is 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  Voice Control    |   4    | 26 (AF 31) |
                +-------------------+--------+------------+
                | Background Gold   |   2    | 18 (AF 21) |
                +-------------------+--------+------------+
                | Background Silver |   1    | 10 (AF 11) |
                +-------------------+--------+------------+
                |  Best effort Effort      |  0,3   |  0 (BE)    |
                +-------------------+--------+------------+

   The access point prioritizes ingress traffic on the Ethernet port
   based on the 802.1p tag or the DSCP value.  If the 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 802.1p/
   802.11e correspondence table to map the traffic to the appropriate
   hardware queues.

   When the 802.11e capable 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 Appendix A
   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 14 gives the call flow corresponding to that use- use
   case and shows where QoS tags mapping does come into play.  The main
   steps are as follows:

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

      (B): the 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 value; it then marks the IP packet and forwards
      within the PMIP tunnel.

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

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

     +--+            +--+             +---+                     +---+
     |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 14: Prioritization of a flow created Flow Created on the WLAN access Access

Appendix C.  Information when implementing 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 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 via, e.g., Wi-Fi 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 15: End-to-end End-to-End QoS management Management with the broadband access
                                  network Broadband Access
                                  Network

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

Authors' Addresses

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

   Email:

   EMail: liebsch@neclab.eu

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

   Email:

   EMail: pierrick.seite@orange.com

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

   Email:

   EMail: yokota@kddilabs.jp

   Jouni Korhonen
   Broadcom Communications
   Porkkalankatu 24
   Helsinki  FIN-00180
   Finland

   Email:

   EMail: jouni.nospam@gmail.com

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

   Email:

   EMail: sgundave@cisco.com