NETEXT WG M. Liebsch Internet-Draft NEC Intended status: Standards Track P. Seite Expires: April 25, 2013 France Telecom - Orange H. Yokota KDDI Lab J. Korhonen Nokia Siemens Networks S. Gundavelli Cisco October 22, 2012 Quality of Service Option for Proxy Mobile IPv6 draft-ietf-netext-pmip6-qos-01.txt Abstract This specification defines a new mobility option that can be used by the mobility entities in the Proxy Mobile IPv6 domain to exchange Quality of Service parameters associated with a subscriber's IP flows. Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values. This enables QoS policing and labeling of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway. After such mapping, QoS rules can be enforced on the access technology components, such as an IEEE 802.11e Wireless LAN controller. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2013. Liebsch, et al. Expires April 25, 2013 [Page 1] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liebsch, et al. Expires April 25, 2013 [Page 2] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 3. Description of the Technical Approach . . . . . . . . . . . . 8 3.1. Technical Scope and Procedure . . . . . . . . . . . . . . 8 3.2. Use Case A -- Handover of Available QoS Context . . . . . 9 3.3. Use Case B -- Establishment of new QoS Context in non-3G Access . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Relevant QoS Attributes . . . . . . . . . . . . . . . . . 11 3.5. Protocol Operation . . . . . . . . . . . . . . . . . . . . 12 3.5.1. Handover of existing QoS rules . . . . . . . . . . . . 13 3.5.2. Establishment of QoS rules . . . . . . . . . . . . . . 14 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 15 4.1. Mobile Access Gateway Considerations . . . . . . . . . . . 15 4.2. Local Mobility Anchor Considerations . . . . . . . . . . . 16 5. Quality of Service Option . . . . . . . . . . . . . . . . . . 17 6. QoS Policy Attributes (Type-Length-Values) . . . . . . . . . . 18 6.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate . . . 18 6.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate . . . . 18 6.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate . . 19 6.5. Allocation and Retention Priority . . . . . . . . . . . . 20 6.6. Guaranteed Downlink Bit Rate . . . . . . . . . . . . . . . 21 6.7. Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . . . 22 6.8. Traffic Selector . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Information when implementing PMIP based QoS support with IEEE 802.11e . . . . . . . . . . . . . . 28 Liebsch, et al. Expires April 25, 2013 [Page 3] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Appendix B. Information when implementing with a Broadband Network Gateway . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Liebsch, et al. Expires April 25, 2013 [Page 4] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 1. Introduction Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to enable network-based mobility management for mobile nodes (MN). Users can access Internet Protocol (IP) based services from their mobile device by using different radio access technologies. Current standardization effort considers strong QoS classification and enforcement for cellular radio access technologies. QoS policies are typically controlled by a policy control function, whereas the policies are enforced by different gateways in the infrastructure, such as the LMA and the MAG, as well as by access network elements. Policy control and QoS differentiation for access to the mobile operator network through alternative non-cellular access technologies is not yet considered, even though some of these access technologies are able to support QoS by appropriate traffic prioritization techniques. However, handover and IP Flow Mobility using alternative radio access technologies, such as IEEE802.16 and Wireless LAN according to the IEEE802.11 specification, are being considered by the standards [TS23.402], whereas inter-working with the cellular architecture to establish QoS policies in alternative access networks has not been focussed on so far. In particular the Wireless LAN technology has been identified as promising alternative technology to complement cellular radio access. Since the 802.11e standard provides QoS extensions to WLAN, it is beneficial to apply QoS policies to the WLAN access, which enables QoS classification of downlink as well as uplink traffic between an MN and its LMA. Three functional operations have been identified to accomplish this: (a) Maintenance of QoS classification during a handover between cellular radio access and WLAN access by means of establishing QoS policies in the handover target access network, (b) mapping of QoS classes and associated policies between different access systems and (c) establishment of QoS policies for new data sessions/flows, which are initiated while using WLAN access. This document specifies an extension to the PMIPv6 protocol, which enables the transport of established QoS descriptions between an LMA and the MAG by means of a QoS container option in case the QoS policy in the WLAN access is not under explicit control of a policy control system. The specified option allows association between IP session keys, such as a Differentiated Services Code Point (DSCP), and the expected QoS class for this IP session. Further handling of QoS policies between the MAG and the WLAN Controller (WLC) or WLAN Access Liebsch, et al. Expires April 25, 2013 [Page 5] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Point is out of scope of this specification. Liebsch, et al. Expires April 25, 2013 [Page 6] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 2. Conventions and Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Proxy Mobile IPv6 specifications [RFC5213], [RFC5844], [RFC5845] and [RFC5846]. Additionally, this document uses the following abbreviations: o WLAN (Wireless Local Area Network) - A wireless network. o WTP (Wireless Termination Point): The entity that functions as the termination point for the network-end of the IEEE 802.11 based air interface from the mobile node. It is also known as the Wireless Access Point. o WLC (Wireless LAN Controller): The entity that provides the centralized forwarding, routing function for the user traffic. All the user traffic from the mobile nodes attached to the WTP's is typically tunneled to this centralized WLAN access controller. Liebsch, et al. Expires April 25, 2013 [Page 7] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 3. Description of the Technical Approach 3.1. Technical Scope and Procedure The QoS option specified in this document supports the setup of states on the LMA and the MAG to allow enforcement of QoS policies for packet differentiation on the network path between the LMA and the MAG providing non-cellular access to the mobile operator network. QoS differentiation is typically enabled in the mobile operator's network using Differentiated Services techniques in the IP transport network, whereas radio access specific QoS differentiation depends on the radio technology in use. Whereas very accurate and fine granular traffic classes are specified for the cellular radio access, the IP transport network only supports enforcement of few Differentiated Services classes according to well-known Differentiated Services Code Points (DSCP) [GSMA.IR.34]. Central control from a Policy Control Function (PCF) is deployed in current cellular mobile communication standards to assign an appropriate QoS class to an MN's individual flows. Non-cellular access technologies are not yet considered for per-flow QoS policing under control of a common PCF. The QoS option specified in this document enables exchange of QoS policies, which have been setup for an MN's IP flows on the cellular network, between the LMA and a new MAG during handover from the cellular access network to the non- cellular access network. Furthermore, the QoS option can be used to exchange QoS policies for new IP flows, which are initiated while the MN is attached to the non-cellular MAG. Figure 1 illustrates a generalized architecture where the QoS option can be used. During an MN's handover from cellular access to non- cellular access, e.g. a wireless LAN (WLAN) radio access network, the MN's QoS policy rules, as previously established on the LMA for the MN's communication through the cellular access network, are moved to the handover target MAG serving the non-cellular access network. Such non-cellular MAG can have an access technology specific controller or function co-located, e.g. a Wireless LAN Controller (WLC), as depicted in option (I) of Figure 1. Alternatively, the access specific architecture can be distributed and the access technology specific control function is not co-located with the MAG, as depicted in option (II). In case of a distributed access network architecture as per option (II), the MAG and the access technology specific control function (e.g. the WLC) must provide some protocol for QoS inter-working. Details of such inter-working are out of scope of this specification. Liebsch, et al. Expires April 25, 2013 [Page 8] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Non-cellular access | Cellular Core Network Cellular (e.g. WLAN) | +--------+ Access | |Policy | | |Control +-----+ | |Function| | +----+ | +---+----+ | |WiFi| (I) | | | | AP |---+ +---+---+ | | | ((O)) +----+ | |WiFi AR| | PMIPv6 +-----+ +---+ | +----+ (MAG) +=|============| LMA |=====|MAG+--| | | WLC | | tunnel +-----+ +---+ | +----+ | +-------+ | // |WiFi|---+ | // | AP | | // +----+ (II) | // +-------+ | // +----+ +------+ |WiFi AR| | // |WiFi+----+ WLC +------+ (MAG) |=|=======// | AP | | | | | | +----+ +------+ +------ + | ^ ^ | | | | +------------+ QoS inter-working Figure 1: Architecture for QoS inter-working between cellular access and non-cellular access Based on the architecture illustrated in Figure 1, two key use cases can be supported by the QoS option. Use case A assumes a MN is attached to the network through cellular access and its LMA has QoS policy rules for the MN's data flows available. This specification does not depend on the approach how the cellular specific QoS policies have been configured on the LMA. During its handover, the available QoS policies are established on the handover target MAG, which serves the non-cellular access network. Use case B assumes that new policies need to be established for a MN as a new IP flow is initiated while the MN is attached to the network through the non- cellular network. These use cases are described in more detail in the subsequent sections Section 3.2 and Section 3.3 respectively. 3.2. Use Case A -- Handover of Available QoS Context The MN is first connected to the LTE network and having a multimedia session such as a video call with appropriate QoS parameters set by the policy control function. Then, the MN discovers a WiFi AP (e.g., at home or in a cafe) and switches to it provided that WiFi access has a higher priority when available. Not only is the session Liebsch, et al. Expires April 25, 2013 [Page 9] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 continued, but also the QoS is maintained after moving to the WiFi access. In order for that to happen, the LMA delivers the QoS parameters to the MAG on the WLC via the PMIPv6 signaling and the equivalent QoS treatment is provided toward the MN on the WiFi link. +--------+ |Policy | |Control | |Function| +---+----+ | +----+ +-------+ +---+----+ +--+ |LTE |_______| SGW | | PGW | |MN|~~|eNB | | |==============| (LMA) | +--+ +----+ +-------+ //+--------+ : // : // V +----+ +-------+ PMIPv6 // +--+ |WiFi|_______| WLC |========= |MN|~~| AP | | (MAG) | tunnel +--+ +----+ +-------+ Figure 2: Handover Scenario 3.3. Use Case B -- Establishment of new QoS Context in non-3G Access A single operator has deployed both a fixed access network and a mobile access network. In this scenario, the operator may wish a harmonized QoS management on both accesses. However the fixed access network does not implement a QoS control framework. So, the operator chooses to rely on the 3GPP policy control function, which is a standard framework to provide a QoS control, and to enforce the 3GPP QoS policy to the Wi-Fi Access network. The PMIP interface is used to realize this QoS policy provisioning. The use-case is depicted on Figure 3. The MN is first attaching to the Wi-Fi network. During attachment process, the LMA, which may be in communication with Policy Control Function (this step of the process is out of the scope of this document), provides the QoS parameters to the MAG piggy-backing the PMIP signaling (i.e. PBA). Subsequently, an application on the MN may trigger the request for enhanced QoS resources, e.g., by use of the WMM-API [80211e]. The MN may request traffic resources be reserved using L2 signalling, e.g., sending an ADDTS message [80211e]. The request is relayed to the MAG Liebsch, et al. Expires April 25, 2013 [Page 10] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 which piggybacks the QoS parameters on the PMIP signalling (i.e. PBU initiated on the flow creation). The LMA, in co-ordination with the PCF, can then authorize the enforcement of such QoS policy. Then, the QoS parameters are provided to the MAG piggy-backing the PMIP signaling and the equivalent QoS treatment is provided towards the MN on the WiFi link. | | | +--------+ | |Policy | | |Control | | |Function| | +---+----+ | | | +---+----+ +----+ +-------+ PMIPv6 | | PGW | +--+ |WiFi|_______| WLC |========|=| (LMA) | |MN|~~| AP | | (MAG) | tunnel | +--------+ +--+ +----+ +-------+ | | Wi-Fi Access | Network | Cellular | Network | Figure 3: QoS policy provisioning 3.4. Relevant QoS Attributes The QoS Option shall, at least, contain DSCP values associated with IP flows. Optional QoS information could also be added. For instance, in order to comply with 3GPP networks QoS, at minimum there is a need to convey the following additional QoS parameters for each PMIPv6 mobility session: 1. Per Mobile Node Aggregate Maximum Bit Rate (MN-AMBR) to both uplink and downlink directions. 2. Per mobility session Aggregate Maximum Bit Rate (MS-AMBR) to both uplink and downlink directions. The following attributes represent a useful set of QoS parameters to negotiate during the session setup: Liebsch, et al. Expires April 25, 2013 [Page 11] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 1. Allocation and Retention Priority (ARP). 2. Guaranteed Bit Rate (GBR) 3. Maximum Bit Rate (MBR) Additional attributes can be appended to the QoS option, but their definition and specification is out of scope of this document and left to their actual deployment. Informational Note: If DSCP values follow the 3GPP specification and deployment, the code point can carry intrinsically additional attributes according to a pre-defined mapping table: This is the GSMA/3GPP mapping for EPC/LTE: QCI DiffServ PHB DSCP 1 EF 101110 2 EF 101110 3 EF 101110 4 AF41 100010 5 AF31 011010 6 AF32 011100 7 AF21 010010 8 AF11 001010 9 BE 000000 3.5. Protocol Operation Liebsch, et al. Expires April 25, 2013 [Page 12] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 3.5.1. Handover of existing QoS rules +--+ +--+ +---+ +---+ |MN| |AP| |MAG| |LMA| +--+ +--+ +---+ +---+ || | | To |data |+--detach | | cellular<-==data[DSCP]==-|<---- +----attach-----+ | access [QoS rules] | |-INFO[MNattach]->| | | | |------PBU[handover]------->| | | | | | | |<----PBA[QoS option]-------| | |<-INFO[QoSrules]-| | | | | | | Apply Establish Update | mapped MN's uplink MN's downlink | QoS rules DSCP rules DSCP rules | | +===========================+ | | | | | |(B) |(A) |data |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- | | | | | | | |data |---data[QC]--->|--->data[DSCP]-->|-=======data[DSCP]=======->|----> | |(C) |(D) | | | | | (A): Apply DSCP at link to AP (B): Enforce mapped QoS rules to access technology (C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or validate MN-indicated QC and apply DSCP on the AP.-MAG link according to rule (D): Validate received DSCP and apply DSCP according to rule Figure 4: Handover of QoS rules Liebsch, et al. Expires April 25, 2013 [Page 13] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 3.5.2. Establishment of QoS rules +--+ +--+ +---+ +---+ |MN| |AP|-------------|MAG|-----------------------|LMA| +--+ +--+ +---+ +---+ | | | | | | | | +----attached---+ | [QoS rules] | | | | new session | |(F) |data |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|----> | |(E) |--PBU[update, QoS option]->|(C) | | | Validate and | | | add QoS rule | | |<----PBA[QoS option]-------| | |<-INFO[QoSrules]-| [QoS rules'] | | | | | Apply Establish | | adapted MN's uplink | | QoS rules DSCP rules | | | | | | | | | | | | |data |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- | | | | | | | |data |---data[QC]--->|--->data[DSCP]-->|-=======data[DSCP]=======->|----> | | | | | | | | (E): AP may enforce uplink QoS rules according to priority class set by the MN (F): MAG can enforce a default QoS class until LMA has classified the new flow (notified with PBA) or MAG classifies new flow and proposes the associated QoS class to the LMA for validation (proposed with PBU, notification of validation result with PBA) Figure 5: Adding new QoS profile for MN initiated flow Liebsch, et al. Expires April 25, 2013 [Page 14] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 4. Protocol Considerations For supporting this specification, there are protocol extensions needed on both the local mobility anchor and mobile access gateway. The following sections identify those extensions. 4.1. Mobile Access Gateway Considerations The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], MUST be extended to store the QoS parameters received from the local mobility anchor. QoS parameters can apply either to the flow or to the mobility session or to the mobile node. Specifically, the following parameters must be defined. 1. Flow Selectors (if QoS parameters are expected to apply at the flow level) 2. DSCP Value 3. List of QoS parameters encoded in TLV format If a mobile access gateway is enabled to support Quality of Service option, upon accepting a Proxy Binding Acknowledgement with Quality of Service option, it SHOULD update the Binding Update List for that mobility session with the quality of service parameters received from the local mobility anchor. However, if the mobile access gateway is not enabled to support Quality of Service option, it SHOULD just skip the option and continue to process the rest of the message. The mobility access gateway SHOULD enforce the Quality of Service rules on the mobile node's uplink and downlink traffic as notified by the local mobility anchor. The traffic selectors in the received Quality of Service option are to be used for the flow identification. The DSCP field in the option along with the other parameters in the QoS Information field are to be used for the flow treatment. In deployments where the mobile access gateway is collocated with a WLAN controller, there is interworking needed between the two functions for exchanging the Quality of Service parameters. The WLAN controller can potentially deliver the Quality of Service parameters to the Access Point/WTP over CAPWAP or other control protocol interface. The specific details on how that is achieved is outside the scope of this document. Liebsch, et al. Expires April 25, 2013 [Page 15] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 4.2. Local Mobility Anchor Considerations The conceptual Binding Cache entry data structure maintained by the local mobility anchor, described in Section 5.1 of [RFC5213], MUST be extended to store the Quality of Service parameters received from the local mobility anchor. Specifically, the following parameters must be defined. 1. Flow Selectors 2. DSCP Value 3. List of parameters encoded in TLV format Upon accepting a Proxy Binding Update message [RFC5213] from a mobile access gateway, and if the local mobility anchor is enabled to enforce the Quality of Service rules, it SHOULD construct the Quality of Service mobility option and include it in the Proxy Binding Acknowledgement message. The Quality of Service MUST be constructed as specified in Section 5. The flow selectors and the parameters for flow treatment MUST be included in the option only if QoS policy is expected to apply at the flow level. The local mobility anchor SHOULD enforce the Quality of Service rules on the mobile node's uplink and downlink traffic as specified for that mobility session. Liebsch, et al. Expires April 25, 2013 [Page 16] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 5. Quality of Service Option A new option, Quality of Service option, is defined for use with a Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for providing QoS policies and information to the mobile access gateway. The alignment requirement for this option is 4n. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS Information (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: QoS Option o Type: To be assigned by IANA o Length: 8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. o Reserved : This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. o DSCP: An 6-bit unsigned integer indicating the code point value, as defined in [RFC2475] to be used for the flow. o QoS Information: one or more Type-Length-Value (TLV) encoded QoS policies. The interpretation and usage of the QoS information is specific to the TLV. Liebsch, et al. Expires April 25, 2013 [Page 17] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 6. QoS Policy Attributes (Type-Length-Values) 6.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate The maximum downlink bit rate for a single Mobile Node. The maximum is an aggregate of all mobility session the Mobile Node has. When provided in a request, it indicates the maximum requested bandwidth. When provided in an answer, it indicates the maximum bandwidth accepted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Bandwidth-DL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA o Length: The length of following data value in octets. Set to 4. o Max-Bandwidth-DL: is of type unsigned 32 bit integer, and it indicates the maximum bandwidth in bits per second for a downlink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 6.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate The maximum uplink bit rate for a single Mobile Node. The maximum is an aggregate of all mobility session the Mobile Node has. When provided in a request, it indicates the maximum requested bandwidth. When provided in an answer, it indicates the maximum bandwidth accepted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Bandwidth-UL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA o Length: The length of following data value in octets. Set to 4. Liebsch, et al. Expires April 25, 2013 [Page 18] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 o Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it indicates the maximum bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 6.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate The maximum downlink bit rate for a single specific mobility session the Mobile Node has. When provided in a request, it indicates the maximum requested bandwidth. When provided in an answer, it indicates the maximum bandwidth accepted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Bandwidth-DL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA o Length: The length of following data value in octets. Set to 4. o Max-Requested-Bandwidth-DL: is of type unsigned 32 bit integer, and it indicates the maximum bandwidth in bits per second for a downlink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 6.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate The maximum uplink bit rate for a single specific mobility session the Mobile Node has. When provided in a request, it indicates the maximum requested bandwidth. When provided in an answer, it indicates the maximum bandwidth accepted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Bandwidth-UL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA Liebsch, et al. Expires April 25, 2013 [Page 19] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 o Length: The length of following data value in octets. Set to 4. o Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it indicates the maximum bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 6.5. Allocation and Retention Priority The allocation and retention priority indicate the priority of allocation and retention for the corresponding mobility session or flow. If the attribute is expected to apply at the flow level, the traffic selector (Section 6.8) MUST be included in the QoS option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority-Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pre-emption-Capability | Pre-emption-Vulnerability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA o Length: The length of following data values in octets. Set to 8. o Priority-Level: is of type unsigned 32 bit integer, and it used for deciding whether a mobility session establishment or modification request can be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic). The priority-level can also be used to decide which existing mobility session to pre-empt during resource limitations. The priority level defines the relative importance of a resource request. Values 1 to 15 are defined, with value 1 as the highest level of priority. Values 1 to 8 should only be assigned for services that are authorized to receive prioritized treatment within an operator domain. Values 9 to 15 may be assigned to resources that are authorized by the home network and thus applicable when a MN is roaming. o Pre-emption-Capability: defines whether a service data flow can get resources that were already assigned to another service data Liebsch, et al. Expires April 25, 2013 [Page 20] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 flow with a lower priority level. The following values are defined: Enabled (0): This value indicates that the service data flow is allowed to get resources that were already assigned to another IP data flow with a lower priority level. Disabled (1): This value indicates that the service data flow is not allowed to get resources that were already assigned to another IP data flow with a lower priority level. o Pre-emption-Vulnerability: defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. The following values are defined: Enabled (0): This value indicates that the resources assigned to the IP data flow can be pre-empted and allocated to a service data flow with a higher priority level. Disabled (1): This value indicates that the resources assigned to the IP data flow shall not be pre-empted and allocated to a service data flow with a higher priority level. 6.6. Guaranteed Downlink Bit Rate The guaranteed downlink bit rate for a specific flow or mobility session the Mobile Node has. When provided in a request, it indicates the maximum requested bandwidth. When provided in an answer, it indicates the maximum bandwidth accepted. If the attribute is expected to apply at the flow level, the traffic selector (Section 6.8) MUST be included in the QoS option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed-DL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA o Length: The length of following data value in octets. Set to 4. o Guaranteed-DL: is of type unsigned 32 bit integer, and it indicates the guaranteed bandwidth in bits per second for downlink Liebsch, et al. Expires April 25, 2013 [Page 21] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 IP flows. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 6.7. Guaranteed Uplink Bit Rate The guaranteed downlink bit rate for a specific flow or mobility session the Mobile Node has. When provided in a request, it indicates the maximum requested bandwidth. When provided in an answer, it indicates the maximum bandwidth accepted. If the attribute is expected to apply at the flow level, traffic selector (Section 6.8) MUST be included in the QoS option . 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed-UL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA o Length: The length of following data value in octets. Set to 4. o Guaranteed-UL: is of type unsigned 32 bit integer, and it indicates the guaranteed bandwidth in bits per second for uplink IP flows. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 6.8. Traffic Selector MUST be included if QoS parameters (Options according to Section 6.5 to Section 6.7) are expected to apply at the flow level 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | TS Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Selector ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: To be assigned by IANA Liebsch, et al. Expires April 25, 2013 [Page 22] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 o Length: The length of following data value in octets. o TS Format: An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and MUST NOT be used. The value of (1) is assigned for IPv4 Binary Traffic Selector, as defined in section 3.1 of [RFC6088]. o Traffic Selector: variable-length opaque field for including the traffic specification identified by the TS format field. Liebsch, et al. Expires April 25, 2013 [Page 23] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 7. IANA Considerations This specification defines a new Mobility Header option, the Quality of Service (QoS) option. The format of this option is described in Section 5. The Type value for this option needs to be assigned from the same numbering space as allocated for the other mobility options [RFC6275]. Liebsch, et al. Expires April 25, 2013 [Page 24] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 8. Security Considerations The quality of service option defined in this specification is for use in Proxy Binding Update and Proxy Binding Acknowledgement messages. This option is carried like any other mobility header option as specified in [RFC5213] and does not require any special security considerations. Carrying quality of service information does not introduce any new security vulnerabilities. Liebsch, et al. Expires April 25, 2013 [Page 25] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 9. Acknowledgements The authors of this document thank the NetExt Working Group for the valuable feedback on early versions of this document. In particular the authors want to thank Basavaraj Patil, Behcet Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson and Tricci So for their valuable comments and suggestions to improve this specification. Liebsch, et al. Expires April 25, 2013 [Page 26] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 10.2. Informative References [80211e] IEEE, "IEEE part 11: Wireless LAN Medium Access Control(MAC) and Physical Layer (PHY) specifications. Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements", 2005. [GSMA.IR.34] GSMA, "Inter-Service Provider IP Backbone Guidelines 5.0", December 2010. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010. [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010. [TS23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", 2010. Liebsch, et al. Expires April 25, 2013 [Page 27] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Appendix A. Information when implementing PMIP based QoS support with IEEE 802.11e This section shows, as an example, the end-to-end QoS management with a 802.11e capable WLAN access link and a PMIP based QoS support. The 802.11e, or Wi-Fi Multimedia (WMM), specification provides prioritization of packets for four types of traffic, or access categories (AC): Voice (AC_VO): Very high priority queue with minimum delay. Time- sensitive data such as VoIP and streaming mode are automatically sent to this queue. Video (AC_VI): High priority queue with low delay. Time-sensitive video data is automatically sent to this queue. Best effort (AC_BE): Medium priority queue with medium throughput and delay. Most traditional IP data is sent to this queue. Background (AC_BK): Lowest priority queue with high throughput. Bulk data that requires maximum throughput but is not time- sensitive (for example, FTP data) is sent to the queue. The access point uses the 802.11e indicator to prioritize traffic on the WLAN interface. On the wired side, the access point uses the 802.1p priority tag and DiffServ code point (DSCP). To allow consistent QoS management on both wireless and wired interfaces, the access point relies on the 802.11e specification which define mapping between the 802.11e access categories and the IEEE 802.1D priority (802.1p tag). The end-to-end QoS architecture is depicted on Figure 7 and the 802.11e/802.1D priority mapping is reminded in the following table: +-----------+------------------+ | 802.1e AC | 802.1D priority | +-----------+------------------+ | AC_VO | 7,6 | +-----------+------------------+ | AC_VI | 5,4 | +-----------+------------------+ | AC_BE | 0,3 | +-----------+------------------+ | AC_BK | 2,1 | +-----------+------------------+ Liebsch, et al. Expires April 25, 2013 [Page 28] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 +=============+ +-----+ DSCP/802.1p | PDP | mapping table +-----+ +=============+ PEP | `._ +---+---+ | `._ |WiFi AR| PMIPv6 +-----+ - + (MAG) +===============| LMA | | WLC | tunnel +-----+ +-------+ PEP | ==Video== 802.11p/DSCP ==Voice== | == B.E.== +----+ +----+ |WLAN| PEP | MN |----802.11e----| AP | +----+ +----+ Figure 7: End-to-end QoS management with 802.11e When receiving a packet from the MN, the AP checks whether the frame contains 802.11e markings in the L2 header. If not, the AP checks the DSCP field. If the uplink packet contains the 802.11e marking, the access point maps the access categories to the corresponding 802.1D priority as per the table above. If the frame does not contain 802.11e marking, the access point examines the DSCP field. If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e 802.1D priority). This mapping is not standardized and may differ between operator; a mapping example given in the following table. +-------------------+--------+------------+ | Type of traffic | 802.1p | DSCP value | +-------------------+--------+------------+ | Network Control | 7 | 56 | +-------------------+--------+------------+ | Voice | 6 | 46 (EF) | +-------------------+--------+------------+ | Video | 5 | 34 (AF 41) | +-------------------+--------+------------+ | voice control | 4 | 26 (AF 31) | +-------------------+--------+------------+ | Background Gold | 2 | 18 (AF 21) | +-------------------+--------+------------+ | Background Silver | 1 | 10 (AF 11) | +-------------------+--------+------------+ | Best effort | 0,3 | 0 (BE) | +-------------------+--------+------------+ The access point prioritizes ingress traffic on the Ethernet port Liebsch, et al. Expires April 25, 2013 [Page 29] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 based on the 802.1p tag or the DSCP value. If 802.1p priority tag is not present, the access point checks the DSCP/802.1p mapping table. The next step is to map the 802.1p priority to the appropriate egress queue. When 802.11e support is enabled on the wireless link, the access point uses the IEEE standardized 802.1p/802.11e correspondence table to map the traffic to the appropriate hardware queues. When the 802.11e capable client sends traffic to the AP, it usually marks packets with a DSCP value. In that case, the MAG/LMA can come into play for QoS renegotiation and call flows depicted in Section 3.5 apply. Sometimes, when communication is initiated on the WLAN access, the application does not mark upstream packets. If the uplink packet does not contain any QoS marking, the AP/MAG could determine the DSCP field according to traffic selectors received from the LMA. Figure 8 gives the call flow corresponding to that use-case and shows where QoS tags mapping does come into play. The main steps are as follows: (A): during MN attachment process, the MAG fetches QoS policies from the LMA. After this step, both MAG and LMA are provisionned with QoS policies. (B): the MN starts a new IP communication without making IP packets with DSCP tags. The MAG uses the traffic selector to determine the DSCP value, then it marks the IP packet and forwards within the PMIP tunnel. (C): the LMA checks the DSCP value with respect to the traffic selector. If the QoS policies is valid, the LMA forwards the packet without renegociate QoS rules. (D): when receiving a marked packet, the MAG, the AP and the MN use 802.11e (or WMM), 802.11p tags and DSCP values to prioritize the traffic. Liebsch, et al. Expires April 25, 2013 [Page 30] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 +--+ +--+ +---+ +---+ |MN| |AP| |MAG| |LMA| +--+ + -+ +---+ +---+ (A)|----attach-----|---------------->|-----------PBU---------->| |<--------------|---------------- |<----PBA[QoS option]-----| . . [QoS rules] [QoS rules] (B). . . | new session | | | |----data[]---->|---data[]------->|-======data[DSCP]======->| | | | | (C)| | | Validate QoS rule | | | |----> | | |<======data[DSCP]========|<---- | | | | | | mapping | (D)| | DSCP/802.1p | | |<----data--------| | | | [802.1p/DSCP] | | | | | | | mapping | | 802.1p/802.11e | | |<--data[WMM]---| | | | | | | |---data[WMM]-->|-----data------->|=======data[DSCP]=======>|----> | | [802.1p/DSCP] | | | | | | Figure 8: Prioritization of a flow created on the WLAN access Liebsch, et al. Expires April 25, 2013 [Page 31] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Appendix B. Information when implementing with a Broadband Network Gateway This section shows an example of QoS interworking between the PMIPv6 domain and the broadband access. The Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS) has the MAG function and the CPE (Customer Premise Equipment) or Residential Gateway (RG) is connected via the broadband access network. The MN is attached to the RG via e.g., WiFi AP in the broadband home network. In the segment of the broadband access network, the BNG and RG are the Policy Enforcement Point (PEP) for the downlink and uplink traffic, respectively. The QoS information is downloaded from the LMA to the BNG via the PMIPv6 with the QoS option defined in this document. Based on the received QoS parameters (e.g., DSCP values), the broadband access network and the RG provide appropriate QoS treatment to the downlink and uplink traffic to/from the MN. +-----+ | PDP | +-----+ PEP | +-------+ | | BNG/ | PMIPv6 +-----+ | BRAS +===============| LMA | | (MAG) | tunnel +-----+ +-------+ PEP Broadband ( | ) Access ( DSCP ) Network ( | ) +-----+ +----+ | CPE | PEP | MN |-------------| /RG | +----+ Broadband +-----+ Home Network Figure 9: End-to-end QoS management with the broadband access network In the segment of the broadband access network, QoS mapping between 3GPP QCI values and DSCP described in Section 3.4 is applied. In the segment of the broadband home network, if the MN is attached to the RG via WiFi, the same QoS mapping as described in Appendix A can be applied. Liebsch, et al. Expires April 25, 2013 [Page 32] Internet-Draft QoS Support for Proxy Mobile IPv6 October 2012 Authors' Addresses Marco Liebsch NEC Kurfuersten-Anlage 36 Heidelberg D-69115 Germany Email: liebsch@neclab.eu Pierrick Seite France Telecom - Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange.com Hidetoshi Yokota KDDI Lab 2-1-15 Ohara Saitama, Fujimino 356-8502 Japan Email: yokota@kddilabs.jp Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo FI-02600 Finland Email: jouni.nospam@gmail.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Liebsch, et al. Expires April 25, 2013 [Page 33]