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