GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7222

Internet Engineering Task Force (IETF) M. Liebsch Request for Comments: 7222 NEC Category: Standards Track P. Seite ISSN: 2070-1721 Orange

                                                             H. Yokota
                                                              KDDI Lab
                                                           J. Korhonen
                                               Broadcom Communications
                                                         S. Gundavelli
                                                                 Cisco
                                                              May 2014
          Quality-of-Service Option for Proxy Mobile IPv6

Abstract

 This specification defines a new mobility option, the 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 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
 approaches.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for 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 this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7222.

Liebsch, et al. Standards Track [Page 1] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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 ....................................................3
 2. Conventions and Terminology .....................................4
    2.1. Conventions ................................................4
    2.2. Terminology ................................................5
 3. Overview of QoS Support in Proxy Mobile IPv6 ....................7
    3.1. Quality-of-Service Option -- Usage Examples ................9
    3.2. Quality-of-Service Attributes -- Usage Examples ...........11
 4. Protocol Messaging Extensions ..................................12
    4.1. Quality-of-Service Option .................................12
    4.2. Quality-of-Service Attributes .............................14
         4.2.1. Per-Mobile-Node Aggregate Maximum Downlink
                Bit Rate ...........................................16
         4.2.2. Per-Mobile-Node Aggregate Maximum Uplink Bit Rate ..17
         4.2.3. Per-Mobility-Session Aggregate Maximum
                Downlink Bit Rate ..................................18
         4.2.4. Per-Mobility-Session Aggregate Maximum
                Uplink Bit Rate ....................................20
         4.2.5. Allocation and Retention Priority ..................22
         4.2.6. Aggregate Maximum Downlink Bit Rate ................23
         4.2.7. Aggregate Maximum Uplink Bit Rate ..................25
         4.2.8. Guaranteed Downlink Bit Rate .......................26
         4.2.9. Guaranteed Uplink Bit Rate .........................27
         4.2.10. QoS Traffic Selector ..............................28
         4.2.11. QoS Vendor-Specific Attribute .....................29
    4.3. New Status Code for Proxy Binding Acknowledgement .........30
    4.4. New Notification Reason for Update Notification Message ...30
    4.5. New Status Code for Update Notification
         Acknowledgement Message ...................................31
 5. Protocol Considerations ........................................31
    5.1. Local Mobility Anchor Considerations ......................31
    5.2. Mobile Access Gateway Considerations ......................35

Liebsch, et al. Standards Track [Page 2] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 6. QoS Services in Integrated WLAN-3GPP Networks ..................39
    6.1. Technical Scope and Procedure .............................39
    6.2. Relevant QoS Attributes ...................................41
 7. IANA Considerations ............................................42
 8. Security Considerations ........................................44
 9. Acknowledgements ...............................................44
 10. References ....................................................44
    10.1. Normative References .....................................44
    10.2. Informative References ...................................45
 Appendix A.  Information When Implementing 3GPP QoS in IP
              Transport Network ....................................47
   A.1.  Mapping Tables ............................................47
   A.2.  Use Cases and Protocol Operations .........................48
     A.2.1.  Handover of Existing QoS Rules ........................48
     A.2.2.  Establishment of QoS Rules ............................50
     A.2.3.  Dynamic Update to QoS Policy ..........................52
 Appendix B.  Information When Implementing PMIP-Based QoS Support
              with IEEE 802.11e ....................................53
 Appendix C.  Information When Implementing with a Broadband
              Network Gateway ......................................57

1. Introduction

 Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to
 enable network-based mobility management for mobile nodes (MNs).
 Users can access IP-based services from their mobile device by using
 various radio access technologies.  The currently supported mobile
 standards have adequate support for 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 (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 are not supported in the currently specified standards.
 Although support for IP session handovers and IP flow mobility across
 access technologies already exists in cellular standards [TS23.402],
 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

Liebsch, et al. Standards Track [Page 3] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 mobility anchor.  For realizing this 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, 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
 that apply on a per-mobile-node, per-mobility-session, or per-flow
 basis.  The specified attributes are not specific to any access
 technology but are compatible with the Third Generation Partnership
 Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications
 [IEEE802.11-2012].
 Additional QoS attributes can be specified and used with the QoS
 option, 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 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].

Liebsch, et al. Standards Track [Page 4] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

2.2. Terminology

 All the mobility-related terms used in this document are to be
 interpreted as defined in the Proxy Mobile IPv6 specifications
 [RFC5213], [RFC5844], and [RFC7077].  Additionally, this document
 uses the following abbreviations:
 Aggregate Maximum Bit Rate (AMBR)
    AMBR defines the upper limit on the bit rate that can be provided
    by the network for a set of IP flows.  IP packets within the flows
    exceeding the AMBR limit may be discarded by the rate-shaping
    function where the AMBR parameter is enforced.  Variants of 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, or flow direction.  For example, Per-Mobile-Node
    Aggregate Maximum Downlink Bit Rate, Per-Mobile-Node Aggregate
    Maximum Uplink Bit Rate, Per-Mobility-Session Aggregate Maximum
    Downlink Bit Rate, and 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 Service Requests.  It is used primarily
    by the Admission Control function to determine whether a
    particular Service Request must be rejected due to lack of
    resources or honored by preempting an existing 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 behavior is known as DSCP.  Refer to [RFC2474],
    [RFC2475], [RFC4594], and [RFC2983] for a complete explanation.
 Downlink (DL) Traffic
    The mobile node's IP packets that the mobile access gateway
    receives from the local mobility anchor 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,
    and it implies traffic heading towards the mobile node.

Liebsch, et al. Standards Track [Page 5] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 Guaranteed Bit Rate (GBR)
    GBR denotes the assured 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" 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, 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" 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 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 (for example,
    Internet Service and Voice Over IP Service) and has an identifier
    called "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 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,
    and it implies traffic originating from the mobile node.

Liebsch, et al. Standards Track [Page 6] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

3. Overview of QoS Support in Proxy Mobile IPv6

 The Quality-of-Service support in Proxy Mobile IPv6 specified in this
 document is based on the Differentiated Services Architecture
 ([RFC2474] and [RFC2475]).  The access and the home network in the
 Proxy Mobile IPv6 domain are assumed to be DiffServ-enabled, with
 every network node in the forwarding path for the mobile node's IP
 traffic being 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.  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, 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 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
 Rate) as well as for realizing relative performance treatment by way
 of class-based differentiation.  The subscriber's policy and the
 charging profile (for example, [TS22.115]) are key 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
 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 or signaling to any other node in the network.

Liebsch, et al. Standards Track [Page 7] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

   +=======+
   |  MN-1 |
   +=======+
     | | |                                                    Flow-6
     Flow-1<--(GBR: 64 Kbps)                                       |
     |                                                      Flow-4 |
       Flow-2                                                  | | |
     | |                                                  Flow-1 | |
       | Flow-3                                                | | |
     |_|_|                                            DSCP-X   | | |
    (     )<--(Per-Session-AMBR: 1 Mbps)                   :   | | |
     | | |                                          DSCP-Z :   | | |
       | |                                               : :   | | |
     | | |             +=====+                        +==:=v+  | | |
       | '- -- - - - --|     |                        |  : o|--' | |
     | '- - ---  - -  -|     |           __           |  v o|----' |
     '- - - - -  - -  -|     |       _--'  '--_       |  o--|------'
                       |     |      (          )      |     |
                       | MAG |=====( IP Network )=====| LMA |
                       |     |      (          )      |     |
     ,- - - - - - - - -|     |        '--__--'        |    o|-- - -,
       ,- - -- - -- - -|     |                        |    o|--- , |
     | | ,- -  - - -- -|     |                        |    o|--, | |
       | |             +=====+                        +====^+  | | |
     |_|_|                                                 :   | | |
    ( _ _ )<--(Per-Session-AMBR: 2 Mbps)                   :   | | |
     | | |                                            DSCP-Y   | | |
       | |                                                     | | |
     | | |                                                     | | |
       | Flow-6                                           Flow-2 | |
     | |                                                         | |
       Flow-5 (MBR: 100 Kbps)                               Flow-3 |
     |                                                             |
     Flow-4  (GBR: 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.  The negotiated QoS parameters include a Per-Session-
 AMBR of 1 Mbps and 2 Mbps for MN-1 and MN-2 respectively.
 Furthermore, different IP flows from MN-1 and MN-2 are given

Liebsch, et al. Standards Track [Page 8] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 different QoS service treatment, for example, a GBR of 64 Kbps for
 Flow-1 and Flow-4 is assured, a DSCP marking enforcement of "Z" on
 Flow-6, and an MBR of 100 Kbps on Flow-5.

3.1. Quality-of-Service Option – Usage Examples

 Use Case 1: Figure 2 illustrates a scenario where a local mobility
 anchor initiates a QoS 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 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.
    Upon completing the signaling, the LMA and MAG establish the
    mobility session and the forwarding state.
 o  (5) to (8): The LMA initiates a QoS Service Request to the mobile
    access gateway.  The trigger for this service can be based on a
    trigger from a policy 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), which includes a
    set of QoS parameters.  On determining that it cannot support the

Liebsch, et al. Standards Track [Page 9] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    requested QoS Service Request for that 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 by
    sending a new Update Notification message including the updated
    QoS option.
 o  (9) to (11): Upon successfully negotiating a QoS Service Request,
    the MAG and the LMA install the QoS rules for that Service
    Request.  Furthermore, the MAG (using access-technology-specific
    mechanisms) 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 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 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.
    Upon completing the signaling, the LMA and MAG establish the
    mobility session and the forwarding state.
 o  (5) to (6): The MAG initiates a QoS Service 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
    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

Liebsch, et al. Standards Track [Page 10] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    option (Section 4.1), which includes a set of QoS parameters.  The
    LMA agrees to the proposed QoS Service Request by sending a Proxy
    Binding Acknowledgement (PBA) message.
 o  (7) to (9): Upon successfully negotiating a QoS Service Request,
    the MAG and the LMA install the QoS rules for that Service
    Request.  Furthermore, the MAG using access-technology-specific
    mechanisms installs the QoS rules on the access network.

3.2. Quality-of-Service Attributes – Usage Examples

 This section identifies the use cases where the 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 Per-Session-Agg-Max-DL-Bit-Rate
    (Section 4.2.3) and Per-Session-Agg-Max-UL-Bit-Rate
    (Section 4.2.4) 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 Guaranteed-DL-Bit-Rate (Section 4.2.8) and
    Guaranteed-UL-Bit-Rate (Section 4.2.9) 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 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
    Guaranteed-DL-Bit-Rate (Section 4.2.8), Guaranteed-UL-Bit-Rate
    (Section 4.2.9), and QoS-Traffic-Selector (Section 4.2.10) is used
    for this purpose.

Liebsch, et al. Standards Track [Page 11] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 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.  In
    such 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 Allocation-Retention-
    Priority (Section 4.2.5) is used for this purpose.

4. Protocol Messaging Extensions

4.1. Quality-of-Service Option

 The Quality-of-Service option is a mobility header option used by
 local mobility anchors and mobile access 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) [RFC7077] messages.
 There can be more than one instance of the Quality-of-Service option
 in a single message.  Each instance of the Quality-of-Service option
 represents a specific QoS 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
 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): An 8-bit unsigned integer used
    for identifying the QoS Service Request.  Its uniqueness is within
    the scope of a mobility session.  The local mobility anchor always
    allocates the Service Request Identifier.  When a new QoS Service

Liebsch, et al. Standards Track [Page 12] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    Request is initiated by a mobile access gateway, the Service
    Request Identifier in the initial request message is set to a
    value of (0), and the local mobility anchor allocates a Service
    Request Identifier and includes it in the response.  For any new
    QoS Service Requests initiated by a local mobility anchor, the
    Service Request Identifier is set to the allocated value.
 o  Traffic Class (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, which provides the
       flow selectors.  In the absence of any such Traffic Selector
       attribute, the DSCP marking applies to all the IP flows
       associated with the mobility session.
    Reserved
       The last 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): 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
    QUERY:   (4)
       Query to list the previously negotiated QoS Service Requests
       that are still active

Liebsch, et al. Standards Track [Page 13] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    NEGOTIATE:   (5)
       Response to a QoS 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.
 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): Zero or more TLV-encoded QoS 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 field.

4.2. Quality-of-Service Attributes

 This section identifies the format of a Quality-of-Service attribute.
 A QoS attribute can be included in the Quality-of-Service option
 defined in Section 4.1.  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 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 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 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 Aggregate Maximum
       Downlink Bit Rate, is defined in Section 4.2.3.

Liebsch, et al. Standards Track [Page 14] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    (4) -  Per-Session-Agg-Max-UL-Bit-Rate
       This QoS attribute, 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 Attribute, is defined
       in Section 4.2.11.
    (12) to (254) -  Reserved
       These values are reserved for future allocation.
    (255) -  Reserved
       This value is reserved and cannot be 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.

Liebsch, et al. Standards Track [Page 15] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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

 This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum
 downlink bit rate for a mobile node.  It is a variant of the "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 option
 defined in Section 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 or in an Update Notification message sent by a
 local mobility anchor, it indicates the maximum aggregate downlink
 bit rate that is being requested for the mobile node at the peer.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the maximum aggregate downlink bit rate that the peer
 agrees to offer.
 If multiple mobility sessions are established for a mobile node,
 through multiple mobile access gateways with sessions anchored either
 on a single local mobility anchor or 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 attribute (Section 4.2.10),
 then the 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).

Liebsch, et al. Standards Track [Page 16] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 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 that
    indicates the aggregate maximum downlink 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
    second.

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

 This attribute, Per-MN-Agg-Max-UL-Bit-Rate, represents the maximum
 uplink bit rate for the mobile node.  It is a variant of the "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 option
 defined in Section 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 or in an Update Notification message sent by
 the local mobility anchor, it indicates the maximum aggregate uplink
 bit rate that is being requested for the mobile node at the peer.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the maximum aggregate uplink 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 with sessions anchored either
 on a single local mobility anchor or 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 attribute (Section 4.2.10),
 then the QoS-Traffic-Selector attribute does not apply to this
 attribute.

Liebsch, et al. Standards Track [Page 17] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

  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 a 32-bit unsigned integer that
    indicates the aggregate maximum uplink bit rate that is requested/
    allocated for the mobile node's IP flows.  The measurement units
    for Per-MN-Agg-Max-UL-Bit-Rate are bits per second.

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

 This attribute, Per-Session-Agg-Max-DL-Bit-Rate, represents the
 maximum downlink bit rate for the mobility session.  It is a variant
 of the "AMBR" term defined in Section 2.2.
 This attribute can be included in the Quality-of-Service option
 defined in Section 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 or in an Update Notification message sent by
 the local mobility anchor, it indicates the maximum aggregate
 downlink bit rate that is being requested for that mobility session.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the maximum aggregate downlink 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 attribute (Section 4.2.10),
 then the QoS-Traffic-Selector attribute does not apply to this
 attribute.

Liebsch, et al. Standards Track [Page 18] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

  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. 3GPP Access Point Name (APN) is an example of 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 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) when there is no

Service Identifier associated with the mobility session.

 o  Exclude (E) flag: This flag is used to request that 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 is measured.
  • When the (E) flag is set to a value of (1), then the request is

to exclude the IP flows for which Guaranteed-DL-Bit-Rate

       (Section 4.2.8) is negotiated from the flows for which Per-
       Session-Agg-Max-DL-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-DL-Bit-Rate is measured.

Liebsch, et al. Standards Track [Page 19] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

  • When the (S) flag and (E) flag are both set to a value of (1),

then the request is to exclude all the IP flows sharing the

       Service Identifier associated with this mobility 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
    that indicates the aggregate maximum downlink 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.

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

 This attribute, Per-Session-Agg-Max-UL-Bit-Rate, represents the
 maximum uplink bit rate for the mobility session.  It is a variant of
 the "AMBR" term defined in Section 2.2.
 This attribute can be included in the Quality-of-Service option
 defined in Section 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 or in an Update Notification message [RFC7077]
 sent by the local mobility anchor, it indicates the maximum aggregate
 uplink bit rate that is being requested for that mobility session.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement [RFC7077]
 message, it indicates the maximum aggregate uplink 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 attribute (Section 4.2.10),
 then the 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             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Liebsch, et al. Standards Track [Page 20] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 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. 3GPP Access Point Name (APN) is an example of 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 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) when there is no

Service Identifier associated with the mobility session.

 o  Exclude (E) flag: This flag is used to request that 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 is measured.
  • When the (E) flag is set to a value of (1), then the request is

to exclude the IP flows for which Guaranteed-UL-Bit-Rate

       (Section 4.2.9) is negotiated from the flows for which 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 to exclude all the IP flows sharing the

       Service Identifier associated with this mobility 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.

Liebsch, et al. Standards Track [Page 21] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 o  Per-Session-Agg-Max-UL-Bit-Rate: This is a 32-bit unsigned integer
    that indicates the aggregate maximum uplink 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.

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 option
 defined in Section 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-Retention-Priority
 attribute and the QoS-Traffic-Selector attribute (Section 4.2.10),
 then the Allocation-Retention-Priority attribute is to be applied at
 a flow level.  The traffic selector in the QoS-Traffic-Selector
 attribute identifies the target flows.
 When the QoS option including the Allocation-Retention-Priority
 attribute does not include the QoS-Traffic-Selector attribute
 (Section 4.2.10), then the 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 (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

Liebsch, et al. Standards Track [Page 22] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    decide which existing mobility session to 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 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 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 for the mobility session.  It is a variant of the
 "AMBR" term defined in Section 2.2.

Liebsch, et al. Standards Track [Page 23] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 This attribute can be included in the Quality-of-Service option
 defined in Section 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 or in an Update Notification message sent by
 the local mobility anchor, it indicates the maximum aggregate bit
 rate for downlink IP flows that is being requested.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the maximum aggregate downlink 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 attribute (Section 4.2.10),
 then the Aggregate-Max-DL-Bit-Rate attribute is to be enforced at a
 flow level, and the traffic selectors present in the QoS-Traffic-
 Selector attribute identify those target flows.
 When the QoS option that includes the Aggregate-Max-DL-Bit-Rate
 attribute does not include the 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 that
    indicates the aggregate maximum downlink bit rate that is
    requested/allocated for downlink IP flows.  The measurement units
    for Aggregate-Max-DL-Bit-Rate are bits per second.

Liebsch, et al. Standards Track [Page 24] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

4.2.7. Aggregate Maximum Uplink Bit Rate

 This attribute, Aggregate-Max-UL-Bit-Rate, represents the maximum
 uplink bit rate for the mobility session.  It is a variant of the
 "AMBR" term defined in Section 2.2.
 This attribute can be included in the Quality-of-Service option
 defined in Section 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 or in an Update Notification message sent by
 the local mobility anchor, it indicates the maximum aggregate uplink
 bit rate that is being requested.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the maximum aggregate uplink 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 attribute (Section 4.2.10),
 then the Aggregate-Max-UL-Bit-Rate attribute is to be enforced at a
 flow level, and the traffic selectors present in the QoS-Traffic-
 Selector attribute identify those target flows.
 When the QoS option that includes the Aggregate-Max-UL-Bit-Rate
 attribute does not include the 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.

Liebsch, et al. Standards Track [Page 25] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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

4.2.8. Guaranteed Downlink Bit Rate

 This attribute, Guaranteed-DL-Bit-Rate, represents the assured 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"
 term defined in Section 2.2.
 This attribute can be included in the Quality-of-Service option
 defined in Section 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 or in an Update Notification message sent by
 the local mobility anchor, it indicates the guaranteed downlink bit
 rate that is being requested.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the guaranteed downlink 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 attribute (Section 4.2.10), then the
 Guaranteed-DL-Bit-Rate attribute is to be enforced at a flow level,
 and the traffic selectors present in the QoS-Traffic-Selector
 attribute identify those target flows.
 When the QoS option that includes the Guaranteed-DL-Bit-Rate
 attribute does not include the 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

Liebsch, et al. Standards Track [Page 26] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 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 a 32-bit unsigned integer that
    indicates the guaranteed bandwidth in bits per second for downlink
    IP flows.  The measurement units for Guaranteed-DL-Bit-Rate are
    bits per second.

4.2.9. Guaranteed Uplink Bit Rate

 This attribute, Guaranteed-UL-Bit-Rate, represents the assured 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"
 term defined in Section 2.2.
 This attribute can be included in the Quality-of-Service option
 defined in Section 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 or in an Update Notification message sent by
 the local mobility anchor, it indicates the guaranteed uplink bit
 rate that is being requested.
 When this attribute is present in a Proxy Binding Acknowledgement
 message or in an Update Notification Acknowledgement message, it
 indicates the guaranteed uplink 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 attribute (Section 4.2.10), then the
 Guaranteed-UL-Bit-Rate attribute is to be enforced at a flow level,
 and the traffic selectors present in the QoS-Traffic-Selector
 attribute identify those target flows.
 When the QoS option that includes the Guaranteed-UL-Bit-Rate
 attribute does not include the 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.

Liebsch, et al. Standards Track [Page 27] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

  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 a 32-bit unsigned integer that
    indicates the guaranteed bandwidth in bits per second for uplink
    IP flows.  The measurement units for Guaranteed-UL-Bit-Rate are
    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 option
 defined in Section 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 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, and the
 traffic selectors present in the QoS-Traffic-Selector attribute
 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, and the traffic selectors present in the QoS-
 Traffic-Selector attribute identify those target flows.

Liebsch, et al. Standards Track [Page 28] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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

 This attribute is used for carrying vendor-specific QoS attributes.
 The interpretation and the handling of this option are specific to
 the vendor implementation.
 This attribute can be included in the Quality-of-Service option
 defined in Section 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.

Liebsch, et al. Standards Track [Page 29] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

  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 Enterprise Numbers" registry [SMI].
 o  Sub-Type: An 8-bit field indicating the type of vendor-specific
    information carried in the option.  The namespace for this sub-
    type is managed by the vendor identified by the Vendor ID field.

4.3. New Status Code for Proxy Binding Acknowledgement

 This document defines the following new status code value for use in
 Proxy Binding Acknowledgement message.
 CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request):
 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): 5

Liebsch, et al. Standards Track [Page 30] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

4.5. New Status Code for Update Notification Acknowledgement Message

 This document defines the following new status code value for use in
 Update Notification Acknowledgement message.
 CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service 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
    requests to be enforced.  There can be multiple such entries, and
    each entry must include the Service Request Identifier, DSCP
    value, and the attributes defined in Section 4.2.
 LMA Receiving a QoS Service Request:
 o  On receiving a Proxy Binding Update message with an instance of
    the Quality-of-Service option included in the message and the
    Operational Code field of the Quality-of-Service option set to
    QUERY, then the local mobility anchor includes all the Quality-of-
    Service option(s) reflecting the currently negotiated QoS Service
    Requests for that mobility session in the response message.  The
    Operational Code field in each of the 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 other considerations.
 o  If the local mobility anchor can support the proposed QoS 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 option

instances copied (including all the option content) from the

       received Proxy Binding Update message.  The local mobility

Liebsch, et al. Standards Track [Page 31] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

       anchor assigns a Service Request Identifier to each Service
       Request and sets the SR-ID field of each included Quality-of-
       Service option accordingly.
  • The Operational Code field in each of the Quality-of-Service

option(s) is set to RESPONSE.

  • The local mobility anchor should enforce the Quality-of-Service

rules for all the negotiated QoS 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 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).
  • Since the local mobility anchor cannot support the requested

QoS services for that mobile node, the Proxy Binding

       Acknowledgement 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 the
    mobile node, but only with lower quality values than indicated in
    the QoS attributes of a received QoS option or only for some of
    the received QoS 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 set of
    QoS attributes.
  • If the local mobility anchor cannot support some of the

received QoS Service 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 where the attributes in a QoS
       option have conflicting requirements, for example, Per-Session-
       Agg-Max-UL-Bit-Rate is lower than 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 option (including the QoS

Liebsch, et al. Standards Track [Page 32] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

       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 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 for a mobile 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, and
    the Acknowledgement Requested (A) flag is set to a value of (1).
  • New QoS Service Request:
       +  The message includes one or more instances of the Quality-
          of-Service option.  Each instance of the option will include
          one or more QoS attributes.
       +  The Operational Code field in the Quality-of-Service option
          is set to ALLOCATE.
       +  The Service Request Identifier is set to the allocated
          value.
       +  The DSCP field in the Traffic Class (TC) field is set to the
          requested DSCP value.
  • Modification of an existing QoS Service Request:
       +  The message includes one or more instances of the Quality-
          of-Service option with the QoS attributes reflecting the
          updated values in the attributes and the updated list of
          attributes.
       +  The Operational Code field in the 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.

Liebsch, et al. Standards Track [Page 33] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

       +  The DSCP field in the 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 option
          is set to DE-ALLOCATE.
       +  The Service Request Identifier is set to a value that was
          allocated for that QoS Service Request.
       +  The DSCP field in the Traffic Class (TC) field is set to the
          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 option
          is set to QUERY.
       +  The Service Request Identifier is set to a value of (0).
       +  The DSCP field in the Traffic Class (TC) field is set to a
          value of (0).
 o  Handling a Response to the QoS Service Request:
  • If the received Update Notification Acknowledgement [RFC7077]

message has the Status Code field set to a value (0), the local

       mobility anchor should enforce the 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 has

the Status Code field set to a value

       CANNOT_MEET_QOS_SERVICE_REQUEST, the local mobility anchor
       applies the following considerations:
       +  The denial of a QoS Service Request results in removal of
          any QoS state associated with that request.

Liebsch, et al. Standards Track [Page 34] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

       +  If the message did not include any 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
          option is set to a value of NEGOTIATE and the message
          includes one or more instances of the 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 by resending
          a new Update Notification message with the updated 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] 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 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 a handover to a new
    mobile access gateway 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 requests to be enforced.  There can be multiple such
    entries, and each entry must include the Service Request
    Identifier, DSCP value and the attributes defined in Section 4.2.
 MAG Receiving a QoS Service Request:
 o  On receiving an Update Notification message with one or more
    instances of the Quality-of-Service option included in the
    message, the mobile access gateway 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

Liebsch, et al. Standards Track [Page 35] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    determination to accept the request(s) can be based on policy
    configured on the mobile access gateway, available network
    resources, or other considerations.
 o  If the mobile access gateway can support the proposed QoS Service
    Requests in entirety, then it sends an Update Notification
    Acknowledgement message with a status code value of (0).
  • The message includes all the 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 option(s)
       reflecting the currently negotiated QoS Service Requests for
       that mobility session.
  • The Operational Code field in each of the Quality-of-Service

option(s) is set to RESPONSE.

  • The mobile access gateway should enforce the Quality-of-Service

rules for all the negotiated QoS 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 in entirety, then it rejects the request and
    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 MUST NOT result in removal

of the mobility session for that mobile node.

  • The Update Notification Acknowledgement message may include the

Quality-of-Service option(s) based on the following

       considerations.
       +  If the mobile access gateway cannot support QoS services for
          that mobile node, then 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
          the mobile node, but only with lower quality values than
          indicated in the QoS attributes of a received QoS option,
          the mobile access gateway includes the QoS option in the
          Update Notification Acknowledgement message with an updated
          set of QoS attributes.  The mobile access gateway sets the

Liebsch, et al. Standards Track [Page 36] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

          values of 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 where the attributes in a
          QoS option have conflicting requirements, for example, Per-
          Session-Agg-Max-UL-Bit-Rate is lower than Guaranteed-UL-Bit-
          Rate.  The contents of each 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
          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 for a mobile node by sending a Proxy Binding Update
    message.  The QoS Service Request can be initiated as part of the
    initial Binding registration or during Binding re-registrations.
  • New QoS Service Request:
       +  The message includes one or more instances of the Quality-
          of-Service option.  Each instance of the option will include
          one or more QoS attributes.
       +  The Operational Code field in each of 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 one or more instances of the Quality-
          of-Service option with the QoS attributes reflecting the
          updated values in the attributes and the updated list of
          attributes.
       +  The Operational Code field in the Quality-of-Service option
          is set to MODIFY.

Liebsch, et al. Standards Track [Page 37] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

       +  The Service Request Identifier is set to a value that was
          allocated for that QoS Service Request.
       +  The DSCP field in the 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 option
          is set to DE-ALLOCATE.
       +  The Service Request Identifier is set to a value that was
          allocated for that QoS Service Request.
       +  The DSCP field in the Traffic Class (TC) field is set to the
          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 option
          is set to QUERY.
       +  The Service Request Identifier is set to a value of (0).
       +  The DSCP field in the Traffic Class (TC) field is set to a
          value of (0).
 o  Handling a Response to the QoS Service Request:
  • If the received Proxy Binding Acknowledgement message has the

Status Code field set to a value of (0), the mobile access

       gateway should enforce the 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 field set to a value of

       CANNOT_MEET_QOS_SERVICE_REQUEST, the mobile access gateway
       applies the following considerations.
       +  The denial of a QoS Service Request results in removal of
          any QoS state associated with that request.

Liebsch, et al. Standards Track [Page 38] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

       +  If the message did not include any 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
          option is set to a value of NEGOTIATE and the message
          includes one or more instances of the 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 by resending
          a new Proxy Binding Update message with the updated Quality-
          of-Service option.
  • General Considerations:
       +  There can be more than one QoS Service Request in a single
          message.  If so, the message includes an instance of a
          Quality-of-Service option for each of those 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] 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 that have been established while the mobile
 node is attached to WLAN 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 is further translated to WLAN QoS-specific
 techniques in the WLAN access using appropriate WLAN QoS
 specifications [IEEE802.11aa-2012] [WMM1.2.0].  The details 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

Liebsch, et al. Standards Track [Page 39] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 class to a mobile node's individual flows.  Alternatively, more
 static and default QoS rules could be made locally available, e.g.,
 on a local mobility anchor, through administration.
         Non-cellular access       |  Cellular Core Network   Cellular
            (e.g., WLAN)           |      (e.g., EPC)           Access
                                   |                        (e.g.,
                                   |         +-----------+     EUTRAN)
                                   |         |    PCF    |
                                   |         |(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 between Cellular Access
                        and Non-Cellular Access
 During a mobile node's handover from cellular access to non-cellular
 access, 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
 controller or function co-located, e.g., a Wireless LAN Controller
 (WLC), as depicted in option (I) of Figure 6.  Alternatively, the
 access-specific architecture can be distributed, and the 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 control

Liebsch, et al. Standards Track [Page 40] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 function (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 terms of QoS characteristics (e.g., conversational
 voice, streaming video, signaling, and best effort); more details on
 DSCP and QCI mapping are given 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
    rate=GBR and the maximum bit rate=MBR.

Liebsch, et al. Standards Track [Page 41] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 o  Dedicated, 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
  • 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 in Appendix A.
 For some optional QoS attributes, the 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 that apply per
 mobile node or per 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 as considerations for
 actual deployment.

7. IANA Considerations

 IANA has completed the following actions:
 o  Action-1: This specification defines a new mobility option, the
    Quality-of-Service (QoS) option.  The format of this option is
    described in Section 4.1.  The type value 58 for this mobility
    option has been allocated from the "Mobility Options" registry at
    <http://www.iana.org/assignments/mobility-parameters>.
 o  Action-2: This specification defines a new mobility attribute
    format, the Quality-of-Service attribute.  The format of this
    attribute is described in Section 4.2.  This attribute can be
    carried in the Quality-of-Service mobility option.  The type
    values for this attribute are managed by IANA in a new registry,
    the "Quality-of-Service Attribute Registry".  This registry is
    maintained under the "Mobile IPv6 parameters" registry at
    <http://www.iana.org/assignments/mobility-parameters>.  This
    specification reserves the type values listed below.  All other

Liebsch, et al. Standards Track [Page 42] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    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 issues with existing
    deployments.
 +=====+=================================+=================+
 |Value|       Description               |   Reference     |
 +=====+=================================+=================+
 | 0   | Reserved                        |   RFC 7222      |
 +=====+===================================================+
 | 1   | Per-MN-Agg-Max-DL-Bit-Rate      |   RFC 7222      |
 +=====+===================================================+
 | 2   | Per-MN-Agg-Max-UL-Bit-Rate      |   RFC 7222      |
 +=====+===================================================+
 | 3   | Per-Session-Agg-Max-DL-Bit-Rate |   RFC 7222      |
 +=====+===================================================+
 | 4   | Per-Session-Agg-Max-UL-Bit-Rate |   RFC 7222      |
 +=====+===================================================+
 | 5   | Allocation-Retention-Priority   |   RFC 7222      |
 +=====+===================================================+
 | 6   | Aggregate-Max-DL-Bit-Rate       |   RFC 7222      |
 +=====+===================================================+
 | 7   | Aggregate-Max-UL-Bit-Rate       |   RFC 7222      |
 +=====+===================================================+
 | 8   | Guaranteed-DL-Bit-Rate          |   RFC 7222      |
 +=====+===================================================+
 | 9   | Guaranteed-UL-Bit-Rate          |   RFC 7222      |
 +=====+===================================================+
 | 10  | QoS-Traffic-Selector            |   RFC 7222      |
 +=====+===================================================+
 | 11  | QoS-Vendor-Specific-Attribute   |   RFC 7222      |
 +=====+===================================================+
 | 255 | Reserved                        |   RFC 7222      |
 +=====+===================================================+
 o  Action-3: This document defines a new status code,
    CANNOT_MEET_QOS_SERVICE_REQUEST (179), for use in Proxy Binding
    Acknowledgement messages, as described in Section 4.3.  This value
    has been assigned from the "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 use in Update Notification messages
    [RFC7077] as described in Section 4.4.  This value has been
    assigned from the "Update Notification Reasons Registry" at
    <http://www.iana.org/assignments/mobility-parameters>.

Liebsch, et al. Standards Track [Page 43] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 o  Action-5: This document defines a new status code,
    CANNOT_MEET_QOS_SERVICE_REQUEST (130), for use in Update
    Notification Acknowledgement messages [RFC7077] as 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 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 messages like any other mobility header
 option.  [RFC5213] and [RFC7077] identify the security considerations
 for these signaling messages.  When included in these signaling
 messages, the Quality-of-Service option does not require additional
 security considerations.

9. Acknowledgements

 The authors of this document thank the members of NetExt working
 group for the valuable feedback to different versions of this
 specification.  In 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, especially,
 Ben Campbell, Barry Leiba, Jari Arkko, Alissa Cooper, Stephen
 Farrell, Ted 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, for his
 guidance and great support in allowing us to complete this work.

10. References

10.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
            and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

Liebsch, et al. Standards Track [Page 44] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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

10.2. Informative References

 [GSMA.IR.34]
            GSMA, "Guidelines for IPX Provider networks (Previously
            Inter-Service Provider IP Backbone Guidelines)", Official
            Document PRD IR.34, May 2013.
 [IEEE802.11-2012]
            IEEE, "Part 11: Wireless LAN Medium Access 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, 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.

Liebsch, et al. Standards Track [Page 45] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 [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.
 [SMI]      IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
            Private Enterprise Codes, April 2014,
            <http://www.iana.org/assignments/enterprise-numbers>.
 [TS22.115] 3GPP, "Technical Specification Group Services and System
            Aspects; Service aspects; Charging and billing", 3GPP TS
            22.115, 2010.
 [TS23.203] 3GPP, "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, "Technical Specification Group Services and System
            Aspects; Architecture enhancements for non-3GPP accesses",
            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.

Liebsch, et al. Standards Track [Page 46] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

Appendix A. Information When Implementing 3GPP QoS in IP Transport

           Network

A.1. Mapping 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.

Liebsch, et al. Standards Track [Page 47] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

        +=======+===============================+=============+
        |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 and 3GPP QoS Parameters Mapping Table

A.2. Use Cases and 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 to the protocol operation for QoS rules establishment
 (Appendices A.2.1 and A.2.2) and to modification (Appendix A.2.3).

A.2.1. Handover of Existing QoS Rules

 In Figure 9, the MN is first connected to the LTE network with a
 multimedia session, such as a video 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,
 provided that Wi-Fi access has a higher priority when available.  Not
 only is the session continued, but 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

Liebsch, et al. Standards Track [Page 48] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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

Liebsch, et al. Standards Track [Page 49] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

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

A.2.2. Establishment of QoS 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 network.  The PMIP interface is used
 to realize this QoS policy provisioning.
 The 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

Liebsch, et al. Standards Track [Page 50] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 the scope of this document), provides the QoS parameters to the MAG
 via the QoS option (OC=ALLOCATE) in the PMIP signaling (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 (Wi-Fi
 Multimedia - API).  The MN may request that traffic resources be
 reserved using L2 signaling, e.g., sending an Add Traffic System
 (ADDTS) message [IEEE802.11-2012].  The request is relayed to the
 MAG, which includes the QoS parameters in the QoS option
 (OC=ALLOCATE) on the PMIP signaling (i.e., the PBU initiated upon
 flow creation).  The LMA, in 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, 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
 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.

Liebsch, et al. Standards Track [Page 51] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 +--+            +--+             +---+                       +---+
 |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 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 QoS Service Request for 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., IP Multimedia Subsystems
 (IMS) application, gets launched on the mobile node that requires
 certain QoS support.

Liebsch, et al. Standards Track [Page 52] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 The application on the mobile node initiates the communications via a
 dedicated network function (e.g., IMS Call Session Control Function).
 Once the communication is established, the application network
 function notifies the 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.  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 function
 again notifies the PCF function to remove the established QoS
 parameters.  The PCF notifies the LMA 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".  On receiving this Update Notification
 Acknowledgement 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 QoS Support with

           IEEE 802.11e
 This section shows, as an example, the end-to-end QoS management with
 a 802.11e-capable WLAN access link and a PMIP-based QoS support.
 The 802.11e, or Wi-Fi Multimedia (WMM), specification provides
 prioritization of packets for four types of traffic, or access
 categories (ACs):
    Voice (AC_VO): Very high-priority queue with minimum delay.  Time-
    sensitive data such as VoIP and streaming mode are automatically
    sent to this queue.
    Video (AC_VI): High-priority queue with low delay.  Time-sensitive
    video data is automatically sent to this queue.
    Best effort (AC_BE): Medium-priority queue with medium throughput
    and delay.  Most traditional IP data is sent to this queue.
    Background (AC_BK): Lowest-priority queue with high throughput.
    Bulk data that requires maximum throughput but is not time-
    sensitive (for example, FTP data) is sent to the queue.

Liebsch, et al. Standards Track [Page 53] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 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 DSCP.  To allow consistent QoS management on
 both wireless and wired interfaces, the access point relies on the
 802.11e specification, which 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 in Figure 13, and the 802.11e
 /802.1D priority mapping is 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 QoS Management with 802.11e
 When receiving a packet from the MN, the AP checks whether the frame
 contains 802.11e markings in the L2 header.  If not, the AP checks
 the DSCP field.  If the uplink packet contains the 802.11e marking,
 the access point maps the access categories to the corresponding
 802.1D priority as per the table above.  If the frame does not
 contain 802.11e marking, the access point examines the DSCP field.

Liebsch, et al. Standards Track [Page 54] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

 If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e.,
 802.1D priority).  This mapping is not standardized and may differ
 between 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    |   4    | 26 (AF 31) |
              +-------------------+--------+------------+
              | Background Gold   |   2    | 18 (AF 21) |
              +-------------------+--------+------------+
              | Background Silver |   1    | 10 (AF 11) |
              +-------------------+--------+------------+
              |  Best Effort      |  0,3   |  0 (BE)    |
              +-------------------+--------+------------+
 The access point prioritizes ingress traffic on the Ethernet port
 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 correspondence table to map the traffic to the appropriate
 hardware queues.
 When the 802.11e-capable client sends traffic to the AP, it usually
 marks packets with a DSCP value.  In that case, the MAG/LMA can come
 into play for QoS renegotiation and call flows depicted in 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
 case and shows where QoS tags mapping does come into play.  The main
 steps are as follows:
    (A): 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.

Liebsch, et al. Standards Track [Page 55] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

    (B): The MN starts a new IP communication without making IP
    packets with DSCP tags.  The MAG uses the traffic selector to
    determine the DSCP value; it then marks the IP packet and forwards
    within the PMIP tunnel.
    (C): The LMA checks the DSCP value with respect to the traffic
    selector.  If the QoS policies are valid, the LMA forwards the
    packet without renegotiating the QoS rules.
    (D): When receiving a marked packet, the MAG, the AP, and the MN
    use 802.11e (or WMM), 802.1p 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 on the WLAN Access

Liebsch, et al. Standards Track [Page 56] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

Appendix C. Information When Implementing with a Broadband Network

           Gateway
 This section shows an example of QoS interworking between the PMIPv6
 domain and the broadband access.  The Broadband Network Gateway (BNG)
 or Broadband Remote Access Server (BRAS) has the MAG function, and
 the CPE (Customer Premise Equipment) or Residential Gateway (RG) is
 connected via the broadband access network.  The MN is attached to
 the RG via, e.g., 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 QoS Management with the Broadband Access
                                Network
 In the segment of the broadband access network, QoS mapping between
 3GPP QCI values and DSCP described in Section 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.

Liebsch, et al. Standards Track [Page 57] RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014

Authors' Addresses

 Marco Liebsch
 NEC
 Kurfuersten-Anlage 36
 Heidelberg  D-69115
 Germany
 EMail: liebsch@neclab.eu
 Pierrick Seite
 Orange
 4, rue du Clos Courtel, BP 91226
 Cesson-Sevigne  35512
 France
 EMail: pierrick.seite@orange.com
 Hidetoshi Yokota
 KDDI Lab
 2-1-15 Ohara
 Saitama, Fujimino  356-8502
 Japan
 EMail: yokota@kddilabs.jp
 Jouni Korhonen
 Broadcom Communications
 Porkkalankatu 24
 Helsinki  FIN-00180
 Finland
 EMail: jouni.nospam@gmail.com
 Sri Gundavelli
 Cisco
 170 West Tasman Drive
 San Jose, CA  95134
 USA
 EMail: sgundave@cisco.com

Liebsch, et al. Standards Track [Page 58]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7222.txt · Last modified: 2014/05/16 21:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki