Internet DRAFT - draft-ietf-netext-pmip6-qos
draft-ietf-netext-pmip6-qos
NETEXT WG M. Liebsch
Internet-Draft NEC
Intended status: Standards Track P. Seite
Expires: September 29, 2014 Orange
H. Yokota
KDDI Lab
J. Korhonen
Broadcom Communications
S. Gundavelli
Cisco
March 28, 2014
Quality of Service Option for Proxy Mobile IPv6
draft-ietf-netext-pmip6-qos-12.txt
Abstract
This specification defines a new mobility option, the Quality of
Service (QoS) option, for Proxy Mobile IPv6. This option can be used
by the local mobility anchor and the mobile access gateway for
negotiating Quality of Service parameters for a mobile node's IP
flows. The negotiated QoS parameters can be used for QoS policing
and marking of packets to enforce QoS differentiation on the path
between the local mobility anchor and the mobile access gateway.
Furthermore, making QoS parameters available on the mobile access
gateway enables mapping of these parameters to QoS rules that are
specific to the access technology and allows those rules to be
enforced on the access network using access technology specific
approaches.
Status of this Memo
This 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 29, 2014.
Liebsch, et al. Expires September 29, 2014 [Page 1]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of QoS Support in Proxy Mobile IPv6 . . . . . . . . . 9
3.1. Quality of Service Option - Usage Examples . . . . . . . . 11
3.2. Quality of Service Attributes - Usage Examples . . . . . . 13
4. Protocol Messaging Extensions . . . . . . . . . . . . . . . . 15
4.1. Quality of Service Option . . . . . . . . . . . . . . . . 15
4.2. Quality of Service Attribute . . . . . . . . . . . . . . . 17
4.2.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate . 19
4.2.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate . . 20
4.2.3. Per Mobility Session Aggregate Maximum Downlink
Bit Rate . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.4. Per Mobility Session Aggregate Maximum Uplink Bit
Rate . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.5. Allocation and Retention Priority . . . . . . . . . . 25
4.2.6. Aggregate Maximum Downlink Bit Rate . . . . . . . . . 27
4.2.7. Aggregate Maximum Uplink Bit Rate . . . . . . . . . . 28
4.2.8. Guaranteed Downlink Bit Rate . . . . . . . . . . . . . 29
4.2.9. Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . 30
4.2.10. QoS Traffic Selector . . . . . . . . . . . . . . . . . 31
4.2.11. QoS Vendor Specific Attribute . . . . . . . . . . . . 32
4.3. New Status Code for Proxy Binding Acknowledgement . . . . 33
4.4. New Notification Reason for Update Notification Message . 33
4.5. New Status Code for Update Notification
Acknowledgement Message . . . . . . . . . . . . . . . . . 33
Liebsch, et al. Expires September 29, 2014 [Page 2]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 35
5.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35
5.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38
6. QoS Services in Integrated WLAN-3GPP Networks . . . . . . . . 43
6.1. Technical Scope and Procedure . . . . . . . . . . . . . . 43
6.2. Relevant QoS Attributes . . . . . . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 50
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.1. Normative References . . . . . . . . . . . . . . . . . . . 54
11.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Information when implementing 3GPP QoS in IP
transport network . . . . . . . . . . . . . . . . . . 56
A.1. Mapping tables . . . . . . . . . . . . . . . . . . . . . . 56
A.2. Use cases and protocol operations . . . . . . . . . . . . 57
A.2.1. Handover of existing QoS rules . . . . . . . . . . . . 57
A.2.2. Establishment of QoS rules . . . . . . . . . . . . . . 59
A.2.3. Dynamic Update to QoS Policy . . . . . . . . . . . . . 61
Appendix B. Information when implementing PMIP based QoS
support with IEEE 802.11e . . . . . . . . . . . . . . 63
Appendix C. Information when implementing with a Broadband
Network Gateway . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
Liebsch, et al. Expires September 29, 2014 [Page 3]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
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 various radio access technologies. The
currently supported mobile standards have adequate support for QoS-
based service differentiation for subscriber traffic in cellular
radio access networks. QoS policies are typically controlled by a
policy control function, whereas the policies are enforced by one or
more gateways in the infrastructure, such as the local mobility
anchor and the mobile access gateway, as well as by access network
elements. Policy control and in-band QoS differentiation for access
to the mobile operator network through alternative non-cellular
access technologies is not supported in the currently specified
standards. All though support for IP session handovers and IP flow
mobility across access technologies already exists in cellular
standards [TS23.402], however, QoS policy handovers across access
technologies has not received much attention so far.
Based on the deployment trends, Wireless LAN (WLAN) can be considered
as the dominant alternative access technology to complement cellular
radio access. Since the 802.11e extension provides QoS extensions to
WLAN, it is beneficial to apply QoS policies to WLAN access, which
enables QoS classification of downlink as well as uplink traffic
between a mobile node and its local mobility anchor. For realizing
this capability this specification identifies three functional
operations:
(a) Maintaining QoS classification during a handover between
cellular radio access and WLAN access by means of establishing QoS
policies in the handover target access network,
(b) mapping of QoS classes and associated policies between
different access systems and
(c) establishment of QoS policies for new data sessions/flows,
which are initiated while using WLAN access.
This document specifies an extension to the PMIPv6 protocol [RFC5213]
to establish QoS policies for a mobile node's data traffic on the
local mobility anchor and the mobile access gateway. QoS policies
are conveyed in-band with PMIPv6 signaling using the specified QoS
option and are enforced on the local mobility anchor for downlink
traffic and on the mobile access gateway and its access network for
the uplink traffic. The specified option allows association between
IP session classification characteristics, such as a Differentiated
Services Code Point (DSCP) [RFC2474], and the expected QoS class for
Liebsch, et al. Expires September 29, 2014 [Page 4]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
the IP session. This document specifies fundamental QoS attributes
which apply on a per mobile node, mobility session or on a per-flow
basis. The specified attributes are not specific to any access
technology, but are compatible with the Third Generation Partnership
Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications.
Additional QoS attributes can be specified and used with the QoS
option, e.g. to represent more specific descriptions of latency
constraints or jitter bounds. The specification of such additional
QoS attributes as well as the handling of QoS policies between the
mobile access gateway and the access network are out of scope for
this specification.
Liebsch, et al. Expires September 29, 2014 [Page 5]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
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], and [RFC7077]. Additionally, this document
uses the following abbreviations:
Aggregate Maximum Bit Rate (AMBR)
AMBR defines the upper limit on the bit-rate that can be provided
by the network for a set of IP flows. IP packets exceeding the
AMBR limit will be discarded by the rate-shaping function where
the AMBR parameter is enforced. Variants of AMBR term can be
defined by restricting the target set of IP flows on which the
AMBR is applied to a mobile node, mobility session or flow
direction. For example, Per Mobile Node Aggregate Maximum
Downlink Bit Rate, Per Mobile Node Aggregate Maximum Uplink Bit
Rate, Per Mobility Session Aggregate Maximum Downlink Bit Rate and
Per Mobility Session Aggregate Maximum Uplink Bit Rate are used in
this document.
Allocation and Retention Priority (AARP)
AARP is used in congestion situations when there are insufficient
resources for meeting all services requests. It is used primarily
by the Admission Control function to determine whether a
particular service request must be rejected due to lack of
resources, or if it must be honored by preempting an existing low-
priority service.
Differentiated Services Code Point (DSCP)
In Differentiated Services Architecture [RFC2474], packets are
classified and marked to receive a particular per-hop forwarding
behavior on nodes along their path based on the marking present on
the packet. This marking on IPv4 and IPv6 packets that defines a
specific Per-hop behavior is known as DSCP. Refer to [RFC2474],
[RFC2475], [RFC4594] and [RFC2983] for a complete explanation.
Please also refer to
Liebsch, et al. Expires September 29, 2014 [Page 6]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Downlink (DL) Traffic
The mobile node's IP packets that the mobile access gateway
receives from the local mobility anchor is referred to as the
Downlink traffic. The "Downlink" term used in the QoS attribute
definition is always from the reference point of the mobile node
and it implies traffic heading towards the mobile node.
Guaranteed Bit Rate (GBR)
GBR denotes the assured bit-rate that will be provided by the
network for a set of IP flows. It is assumed that the network
reserves the resources for supporting the GBR parameter. Variants
of the GBR term can be defined by limiting the scope of the target
IP flows on which the GBR is applied to a mobile node, mobility
session or flow direction. For example, Guaranteed Downlink Bit
Rate and Guaranteed Uplink Bit Rate are used in this document.
Mobility Session
The term mobility session, is defined in [RFC5213]. It refers to
the creation or existence of state associated with the mobile
node's mobility binding on the local mobility anchor and on the
mobile access gateway.
QoS Service Request
A set of QoS parameters that are defined to be enforced on one or
more mobile node's IP flows. The parameters at the minimum
include a DSCP marking and additionally may include Guaranteed Bit
Rate or Aggregate Maximum Bit Rate. The Quality of Service option
defined in this document represents a QoS Service Request.
Service Identifier
In some mobility architectures, multiple services within the same
mobility service subscription are offered to a mobile node. Each
of those services provide a specific service (examples: Internet
Service, Voice Over IP Service) and has an identifier called
Service Identifier. 3GPP APN (Access Point Name) is an example of
a Service Identifier. Refer to [RFC5149] for the definition of
the Service Identifier and the mobility option used for carrying
the Service Identifier.
Uplink (UL) Traffic
Liebsch, et al. Expires September 29, 2014 [Page 7]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
The mobile node's IP packets that the mobile access gateway
forwards to the local mobility anchor is referred to as the Uplink
traffic. The "Uplink" term used in the QoS attribute definitions
is based on the reference point of the mobile node and "Uplink"
implies traffic originating from the mobile node.
Liebsch, et al. Expires September 29, 2014 [Page 8]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
3. Overview of QoS Support in Proxy Mobile IPv6
The Quality of Service support in Proxy Mobile IPv6 specified in this
document is based on the Differentiated-Services architecture
([RFC2474] and [RFC2475]). The access and the home network in the
Proxy Mobile IPv6 domain are assumed to be DiffServ enabled, with
every network node in the forwarding path for the mobile node's IP
traffic being Diffserv compliant. The per-hop behavior for providing
differential treatment based on the DiffServ marking in the packet is
assumed to be supported in the Proxy Mobile IPv6 domain.
The local mobility anchor in the home network and the mobile access
gateway in the access network define the network boundary between the
access and the home network. These entities being the entry and exit
points for the mobile node's IP traffic, are the logical choice for
being chosen as the QoS enforcement points. The basic QoS functions
such as marking, metering, policing and rate-shaping on the mobile
node's IP flows can be enforced at these nodes.
The local mobility anchor and the mobile access gateway can negotiate
the Quality of Service parameters for a mobile node's IP flows based
on the signaling extensions defined in this document. The QoS
services that can be enabled for a mobile node are for meeting both
the quantitative performance requirements (such as Guaranteed Bit-
Rate) and as well for realizing relative performance treatment by the
ways of class-based differentiation. The subscriber's policy and the
charging profile [TS22.115] is a key consideration for the mobility
entities in the QoS service negotiation. The decision on the type of
QoS services that are to be enabled for a mobile node is based on the
subscriber profile and based on available network resources. The
negotiated QoS parameters are used for providing QoS service
differentiation on the path between the local mobility anchor and the
mobile access gateway. The signaling related to QoS services is
strictly between the mobility entities and does not result in per-
flow state, or signaling to any other node in the network.
Liebsch, et al. Expires September 29, 2014 [Page 9]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+=======+
| MN-1 |
+=======+
| | | Flow-6
Flow-1<--(GBR: 64Kbps) |
| Flow-4 |
Flow-2 | | |
| | Flow-1 | |
| Flow-3 | | |
|_|_| DSCP-X | | |
( )<--(Per-Session-AMBR: 1Mbps) : | | |
| | | DSCP-Z : | | |
| | : : | | |
| | | +=====+ +==:=v+ | | |
| '- -- - - - --| | | : o|--' | |
| '- - --- - - -| | __ | v o|----' |
'- - - - - - - -| | _--' '--_ | o--|------'
| | ( ) | |
| MAG |=====( IP Network )=====| LMA |
| | ( ) | |
,- - - - - - - - -| | '--__--' | o|-- - -,
,- - -- - -- - -| | | o|--- , |
| | ,- - - - -- -| | | o|--, | |
| | +=====+ +====^+ | | |
|_|_| : | | |
( _ _ )<--(Per-Session-AMBR: 2Mbps) : | | |
| | | DSCP-Y | | |
| | | | |
| | | | | |
| Flow-6 Flow-2 | |
| | | |
Flow-5 (MBR: 100Kbps) Flow-3 |
| |
Flow-4 (GBR: 64Kbps) Flow-5
| | |
+=======+
| MN-2 |
+=======+
Figure 1: QoS Support
Figure 1 illustrates the support of QoS services in a Proxy Mobile
IPv6 domain. The local mobility anchor and the mobile access gateway
have negotiated QoS parameters for the mobility sessions belonging to
MN-1 and MN-2. A Per-Session-AMBR of 1Mbps and 2 Mbps for MN-1 and
MN-2 respectively. Furthermore, different IP flows from MN-1 and
MN-2 are given different QoS service treatment. For example, a GBR
of 64Kbps for Flow-1 and Flow-5 is assured, a DSCP marking
Liebsch, et al. Expires September 29, 2014 [Page 10]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
enforcement of "Z" on Flow-6, and MBR of 100 Kbps on Flow-5;
3.1. Quality of Service Option - Usage Examples
Use Case 1: Figure 2 illustrates a scenario where a local mobility
anchor initiates a QoS service request to a mobile access gateway.
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
1) |---- MN Attach ----| |
2) | |------ PBU ------->|
3) | |<----- PBA --------|
| | |
4) | |o=================o|
| | PMIPv6 Tunnel |
| | |
| (LMA initiates QoS Service Request) |
5) | |<----- UPN (QoS)---|
| | |
| (MAG proposes a revised QoS Request) |
6) | |------ UPA (QoS')->|
| | |
7) | |<----- UPN (QoS')--|
8) | |------ UPA (QoS')->|
| QoS Rules ---| |
9) | Established <-| | QoS Rules ---|
10) | ---| Established <-| |
| | ---|
11) |<----------------->| |
Figure 2: LMA Initiated QoS Service Request
o (1) to (4): MAG detects the mobile node's attachment to the access
link and initiates the signaling with the local mobility anchor.
The LMA and MAG upon completing the signaling establish the
mobility session and the forwarding state.
o (5) to (8): The LMA initiates a QoS Service request to the mobile
access gateway. The trigger for this service can be based on a
trigger from a policy function and the specific details of that
trigger are outside the scope of this document. The LMA sends an
Update Notification message [RFC7077] to the MAG. The message
includes the QoS option Section 4.1 which includes a set of QoS
parameters. The MAG on determining that it cannot support the
requested QoS service request for that mobile sends an Update
Notification Acknowledgement message. The message contains a
Liebsch, et al. Expires September 29, 2014 [Page 11]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
revised QoS option with updated set of QoS attributes. The LMA
accepts the revised QoS service request by sending a new Update
Notification message including the updated QoS option.
o (9) to (11): Upon successfully negotiating a QoS service request
the MAG and the LMA install the QoS rules for that service
request. Furthermore, the MAG (using access technology specific
mechanisms) install the QoS rules on the access network.
Use Case 2: Figure 3 illustrates a scenario where a mobile access
gateway initiates a QoS service request to a local mobility anchor.
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
1) |---- MN Attach ----| |
2) | |------ PBU ------->|
3) | |<----- PBA --------|
| | |
4) | |o=================o|
| | PMIPv6 Tunnel |
| | |
| (MAG initiates QoS Service Request) |
5) | |------ PBU (QoS)-->|
6) | |<----- PBA (QoS)---|
| QoS Rules ---| |
7) | Established <-| | QoS Rules ---|
8) | ---| Established <-| |
| | ---|
9) |<----------------->| |
Figure 3: MAG Initiated QoS Service Request
o (1) to (4): MAG detects the mobile node's attachment to the access
link and initiates the signaling with the local mobility anchor.
The LMA and MAG upon completing the signaling establish the
mobility session and the forwarding state.
o (5) to (6): The MAG initiates a QoS Service request to the local
mobility anchor. The trigger for this service can be based on a
trigger from the mobile node using access technology specific
mechanisms. The specific details of that trigger are outside the
scope of this document. The MAG sends a Proxy Binding Update
message [RFC5213] to the LMA. The message includes the QoS option
Section 4.1 which includes a set of QoS parameters. The LMA
agrees to the proposed QoS service request by sending Proxy
Liebsch, et al. Expires September 29, 2014 [Page 12]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Binding Acknowledgement message.
o (7) to (9): Upon successfully negotiating a QoS service request
the MAG and the LMA install the QoS rules for that service
request. Furthermore, the MAG using access technology specific
mechanisms install the QoS rules on the access network.
3.2. Quality of Service Attributes - Usage Examples
This section identifies the use-cases where the Quality of Service
Option (Section 4.1) and its attributes (Section 4.2) defined in this
document are relevant.
o The subscription policy offered to a mobile subscriber requires
the service provider to enforce Aggregate Maximum Bit Rate (AMBR)
limits on the subscriber's IP traffic. The local mobility anchor
and the mobile access gateway negotiate the uplink and the
downlink AMBR values for the mobility session and enforce them in
the access and the home network. The QoS option (Section 4.1)
with the QoS Attributes, Per-Session-Agg-Max-DL-Bit-Rate
(Section 4.2.3) and Per-Session-Agg-Max-UL-Bit-Rate
(Section 4.2.4) are used for this purpose.
o In Community Wi-Fi deployments, the residential gateway
participating in the Wi-Fi service is shared between the home user
and the community Wi-Fi users. In order to ensure the home user's
Wi-Fi service is not impacted because of the community Wi-Fi
service, the service provider enables Guaranteed Bit Rate (GBR)
for the home user's traffic. The QoS option (Section 4.1) with
the QoS Attributes, Guaranteed-DL-Bit-Rate (Section 4.2.8),
Guaranteed-UL-Bit-Rate (Section 4.2.9) are used for this purpose.
o A mobile user using the service provider's Voice over IP
infrastructure establishes a VoIP call with some other user in the
network. The negotiated call parameters for the VoIP call require
a dedicated bandwidth of certain fixed value for the media flows
associated with that VoIP session. The Application function in
the VoIP infrastructure notifies the local mobility anchor to
enforce the GBR limits on that IP flow identified by the flow
definition. The QoS option (Section 4.1) with the QoS Attributes,
Guaranteed-DL-Bit-Rate (Section 4.2.8), Guaranteed-UL-Bit-Rate
(Section 4.2.9), QoS-Traffic-Selector (Section 4.2.10) are used
for this purpose.
o An emergency service may require network resources in conditions
when the network resources have been fully allocated to other
users and the network may be experiencing severe congestion and in
such cases the service provider may want to revoke resources that
Liebsch, et al. Expires September 29, 2014 [Page 13]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
have been allocated and reassign them to emergency services. The
local mobility anchor and the mobile access gateway negotiate
Allocation and Retention Priority (AARP) values for the IP
sessions associated with the emergency applications. The QoS
option (Section 4.1) with the QoS Attribute, Allocation-Retention-
Priority (Section 4.2.5) are used for this purpose.
Liebsch, et al. Expires September 29, 2014 [Page 14]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
4. Protocol Messaging Extensions
4.1. Quality of Service Option
The Quality of Service option is a mobility header option used by
local mobility anchor and mobile access gateway for negotiating QoS
parameters associated with a mobility session. This option can be
carried in Proxy Binding Update (PBU) [RFC5213], Proxy Binding
Acknowledgement (PBA) [RFC5213], Update Notification (UPN) [RFC7077]
and Update Notification Acknowledgement(UPA) [RFC7077] messages.
There can be more than one instance of the Quality of Service option
in a single message. Each instance of the Quality of Service option
represents a specific QoS service request.
The alignment requirement for this option is 4n.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SR-ID | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ QoS Attribute(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: QoS Option
Type
<IANA-1>
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the Type and Length fields.
Service Request Identifier (SR-ID)
A 8-bit unsigned integer used for identifying the QoS service
request. Its uniqueness is within the scope of a mobility
session. The local mobility anchor always allocates the
identifier value. When the QoS Service request is initiated by
a mobile access gateway, it sets the value to (0) and the local
mobility anchor allocates and includes the value in the
Liebsch, et al. Expires September 29, 2014 [Page 15]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
response. For any QoS service requests initiated by a local
mobility anchor, the Service Request Identifier is set to the
allocated value.
Traffic Class (TC)
Traffic Class consists of a 6-bit DSCP field followed by a
2-bit reserved field.
Differentiated Services Code Point (DSCP)
A 6-bit unsigned integer indicating the code point value, as
defined in [RFC2475] to be used for the mobile node's IP
flows. When this DSCP marking needs to be applied only for
a subset of mobile node's IP flows, there will be a Traffic
Selector attribute (Section 4.2.10) in the option which
provides the flow selectors. In the absence of any such
traffic selector attribute, the DSCP marking applies to all
the IP flows associated with the mobility session.
Two-bit Reserved Field
The last two-bits in the Traffic Class field are currently
unused. These bits MUST be initialized by the sender to (0)
and MUST be ignored by the receiver.
Operational Code (OC)
One-Octet Operational code indicates the type of QoS request.
RESPONSE: (0)
Response to a QoS request
ALLOCATE: (1)
Request to allocate QoS resources
DE-ALLOCATE: (2)
Request to de-Allocate QoS resources
MODIFY: (3)
Request to modify QoS parameters for a previously negotiated
QoS service request
QUERY: (4)
Query to list the previously negotiated QoS service requests
and that are still active
Liebsch, et al. Expires September 29, 2014 [Page 16]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
NEGOTIATE: (5)
Response to a QoS service request with a counter QoS
proposal
Reserved: (6) to (255)
Currently not used. Receiver MUST ignore the option
received with any value in this range.
Reserved
This field is unused for now. The value MUST be initialized to
a value of (0) by the sender and MUST be ignored by the
receiver.
QoS Attribute(s)
Zero or more Type-Length-Value (TLV) encoded QoS Attributes.
The format of the QoS attribute is defined in Section 4.2. The
interpretation and usage of the QoS attribute is based on the
value in the "Type" field.
4.2. Quality of Service Attribute
This section identifies the format of a Quality of Service attribute.
QoS attribute can be included in the Quality of Service option
defined in Section 4.1. The latter part of this section identifies
the QoS attributes defined by this specification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of a Quality of Service Attribute
Type: 8-bit unsigned integer indicating the type of the QoS
attribute. This specification reserves the following values.
(0) - Reserved
This value is reserved and cannot be used
Liebsch, et al. Expires September 29, 2014 [Page 17]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
(1) - Per-MN-Agg-Max-DL-Bit-Rate
This QoS attribute, Per Mobile Node Aggregate Maximum Downlink
Bit Rate, is defined in Section 4.2.1.
(2) - Per-MN-Agg-Max-UL-Bit-Rate
This QoS attribute, Per Mobile Node Aggregate Maximum Uplink
Bit Rate, is defined in Section 4.2.2.
(3) - Per-Session-Agg-Max-DL-Bit-Rate
This QoS attribute, Per Mobility Session Aggregate Maximum
Downlink Bit Rate, is defined in Section 4.2.3.
(4) - Per-Session-Agg-Max-UL-Bit-Rate
This QoS attribute, Per Mobility Session Aggregate Maximum
Uplink Bit Rate, is defined in Section 4.2.4.
(5) - Allocation-Retention-Priority
This QoS attribute, Allocation and Retention Priority, is
defined in Section 4.2.5.
(6) - Aggregate-Max-DL-Bit-Rate
This QoS attribute, Aggregate Maximum Downlink Bit Rate, is
defined in Section 4.2.6.
(7) - Aggregate-Max-UL-Bit-Rate
This QoS attribute, Aggregate Maximum Uplink Bit Rate, is
defined in Section 4.2.7.
(8) - Guaranteed-DL-Bit-Rate
This QoS attribute, Guaranteed Downlink Bit Rate, is defined in
Section 4.2.8.
(9) - Guaranteed-UL-Bit-Rate
This QoS attribute, Guaranteed Uplink Bit Rate, is defined in
Section 4.2.9.
Liebsch, et al. Expires September 29, 2014 [Page 18]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
(10) - QoS-Traffic-Selector
This QoS attribute, QoS Traffic Selector, is defined in
Section 4.2.10.
(11) - QoS-Vendor-Specific-Attribute
This QoS attribute, QoS Vendor Specific Attribute, is defined
in Section 4.2.11.
(12) to (254) - Reserved
These values are are reserved for future allocation.
(255) - Reserved
This value is reserved and cannot be used
Length: 8-bit unsigned integer indicating the number of octets
needed to encode the Value, excluding the Type and Length fields.
Value: The format of this field is based on the Type value.
4.2.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate
This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum
downlink bit-rate for a mobile node. It is a variant of the AMBR
term defined in Section 2.2. This value is an aggregate across all
mobility sessions associated with that mobile node.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in a Update Notification message sent by a
local mobility anchor, it indicates the maximum aggregate downlink
bit-rate that is being requested for the mobile node at the peer.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement message, it
indicates the maximum aggregate downlink bit-rate that the peer
agrees to offer.
If multiple mobility sessions are established for a mobile node,
through multiple mobile access gateways and with sessions anchored
either on a single local mobility anchor, or when spread out across
multiple local mobility anchors, then it depends on the operator's
Liebsch, et al. Expires September 29, 2014 [Page 19]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
policy and the specific deployment as how the total bandwidth for the
mobile node on each MAG-LMA pair is computed.
When a QoS option includes both the Per-MN-Agg-Max-DL-Bit-Rate
attribute and the QOS Traffic Selector attribute (Section 4.2.10),
then the QOS Traffic Selector attribute does not apply to this
attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Per-MN-Agg-Max-DL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 1
o Length: The length in octets of the attribute, excluding the Type
and Length fields. This value is set to (6).
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Per-MN-Agg-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it
indicates the aggregate maximum downlink bit-rate that is
requested/allocated for all the mobile node's IP flows. The
measurement units for Per-MN-Agg-Max-DL-Bit-Rate are bits-per-
second.
4.2.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate
This attribute, Per-MN-Agg-Max-UL-Bit-Rate, represents the maximum
uplink bit-rate for the mobile node. It is a variant of the AMBR
term defined in Section 2.2. This value is an aggregate across all
mobility sessions associated with that mobile node.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in an Update Notification message sent by
the local mobility anchor, it indicates the maximum aggregate uplink
bit-rate that is being requested for the mobile node at the peer.
When this attribute is present in a Proxy Binding Acknowledgement
Liebsch, et al. Expires September 29, 2014 [Page 20]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
message, or in an Update Notification Acknowledgement message, it
indicates the maximum aggregate uplink bit-rate that the peer agrees
to offer for that mobile node.
If multiple mobility sessions are established for a mobile node,
through multiple mobile access gateways and with sessions anchored
either on a single local mobility anchor, or when spread out across
multiple local mobility anchors, then it depends on the operator's
policy and the specific deployment as how the total bandwidth for the
mobile node on each MAG-LMA pair is computed.
When a QoS option includes both the Per-MN-Agg-Max-UL-Bit-Rate
attribute and the QOS Traffic Selector attribute (Section 4.2.10),
then the QOS Traffic Selector attribute does not apply to this
attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Per-MN-Agg-Max-UL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 2
o Length: The length in octets of the attribute, excluding the Type
and Length fields. This value is set to (6).
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Per-MN-Agg-Max-UL-Bit-Rate: is of type unsigned 32-bit integer,
and it indicates the aggregate maximum uplink bit-rate that is
requested/allocated for the mobile node's IP flows. The
measurement units for Per-MN-Agg-Max-UL-Bit-Rate are bits-per-
second.
4.2.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate
This attribute, Per-Session-Agg-Max-DL-Bit-Rate, represents the
maximum downlink bit-rate for the mobility session. It is a variant
of the AMBR term defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
Liebsch, et al. Expires September 29, 2014 [Page 21]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in an Update Notification message sent by
the local mobility anchor, it indicates the maximum aggregate
downlink bit-rate that is being requested for that mobility session.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement message, it
indicates the maximum aggregate downlink bit-rate that the peer
agrees to offer for that mobility session.
When a QoS option includes both the Per-Session-Agg-Max-DL-Bit-Rate
attribute and the QOS Traffic Selector attribute (Section 4.2.10),
then the QOS Traffic Selector attribute does not apply to this
attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |S|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Per-Session-Agg-Max-DL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 3
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (6).
o Service (S) flag: This flag is used for extending the scope of the
target flows for Per-Session-Agg-Max-DL-Bit-Rate to mobile node's
other mobility sessions sharing the same service identifier. 3GPP
Access Point Name (APN) is an example of service identifier and
that identifier is carried using the Service Selection mobility
option [RFC5149].
* When the (S) flag is set to a value of (1), then the Per-
Session-Agg-Max-DL-Bit-Rate is measured as an aggregate across
all the mobile node's other mobility sessions sharing the same
service identifier associated with this mobility session.
* When the (S) flag is set to a value of (0), then the target
flows are limited to the current mobility session.
* The (S) flag MUST NOT be set to a value of (1), when there is
no service identifier associated with the mobility session.
Liebsch, et al. Expires September 29, 2014 [Page 22]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
o Exclude (E) flag: This flag is used to request that some flows be
excluded from the target IP flows for which Per-Session-Agg-Max-
DL-Bit-Rate is measured.
* When the (E) flag is set to a value of (1), then the request is
for excluding the IP flows for which Guaranteed-DL-Bit-Rate
(Section 4.2.8) is negotiated, from the flows for which Per-
Session-Agg-Max-DL-Bit-Rate applies is measured.
* When the (E) flag is set to a value of (0), then the request is
not to excluded any IP flows from the target IP flows for which
Per-Session-Agg-Max-DL-Bit-Rate is measured.
* When the (S) flag and (E) flag are both set to a value of (1),
then the request is for excluding all the IP flows sharing the
service identifier associated with this mobility session, from
the target flows for which Per-Session-Agg-Max-DL-Bit-Rate is
measured.
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Per-Session-Agg-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and
it indicates the aggregate maximum downlink bit-rate that is
requested/allocated for all the IP flows associated with that
mobility session. The measurement units for Per-Session-Agg-Max-
DL-Bit-Rate are bits-per-second.
4.2.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate
This attribute, Per-Session-Agg-Max-UL-Bit-Rate, represents the
maximum uplink bit-rate for the mobility session. It is a variant of
the AMBR term defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in an Update Notification message [RFC7077]
sent by the local mobility anchor, it indicates the maximum aggregate
uplink bit-rate that is being requested for that mobility session.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement [RFC7077]
message, it indicates the maximum aggregate uplink bit-rate that the
peer agrees to offer for that mobility session.
Liebsch, et al. Expires September 29, 2014 [Page 23]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
When a QoS option includes both the Per-Session-Agg-Max-UL-Bit-Rate
attribute and the QOS Traffic Selector attribute (Section 4.2.10),
then the QOS Traffic Selector attribute does not apply to this
attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |S|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Per-Session-Agg-Max-UL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 4
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (6).
o Service (S) flag: This flag is used for extending the scope of the
target flows for Per-Session-Agg-Max-UL-Bit-Rate to mobile node's
other mobility sessions sharing the same service identifier. 3GPP
Access Point Name (APN) is an example of service identifier and
that identifier is carried using the Service Selection mobility
option [RFC5149].
* When the (S) flag is set to a value of (1), then the Per-
Session-Agg-Max-UL-Bit-Rate is measured as an aggregate across
all the mobile node's other mobility sessions sharing the same
service identifier associated with this mobility session.
* When the (S) flag is set to a value of (0), then the target
flows are limited to the current mobility session.
* The (S) flag MUST NOT be set to a value of (1), when there is
no service identifier associated with the mobility session.
o Exclude (E) flag: This flag is used to request that some flows be
excluded from the target IP flows for which Per-Session-Agg-Max-
UL-Bit-Rate is measured.
* SGS When the (E) flag is set to a value of (1), then the
request is for excluding the IP flows for which Guaranteed-UL-
Bit-Rate (Section 4.2.9) is negotiated, from the flows for
which Per-Session-Agg-Max-UL-Bit-Rate is measured.
* When the (E) flag is set to a value of (0), then the request is
not to exclude any IP flows from the target IP flows for which
Per-Session-Agg-Max-UL-Bit-Rate is measured.
Liebsch, et al. Expires September 29, 2014 [Page 24]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
* When the (S) flag and (E) flag are both set to a value of (1),
then the request is for excluding all the IP flows sharing the
service identifier associated with this mobility session, from
the target flows for which Per-Session-Agg-Max-UL-Bit-Rate is
measured.
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Per-Session-Agg-Max-UL-Bit-Rate: is a 32-bit unsigned integer, and
it indicates the aggregate maximum uplink bit-rate that is
requested/allocated for all the IP flows associated with that
mobility session. The measurement units for Per-Session-Agg-Max-
UL-Bit-Rate are bits-per-second.
4.2.5. Allocation and Retention Priority
This attribute, Allocation-Retention-Priority, represents allocation
and retention priority for the mobility session or a set of IP flows.
It is defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When the QoS option includes both the Allocation and Retention
Priority attribute and the QOS Traffic Selector attribute
(Section 4.2.10), then the Allocation and Retention Priority
attribute is to be applied at a flow level. The traffic selector in
the QOS Traffic Selector attribute identifies the target flows.
When the QoS option including the Allocation and Retention Priority
attribute does not include the QOS Traffic Selector attribute
(Section 4.2.10), then the Allocation and Retention Priority
attribute is to be applied to all the IP flows associated with that
mobility session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | PL |PC |PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 5
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (10).
Liebsch, et al. Expires September 29, 2014 [Page 25]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Priority-Level (PL): is a 4-bit unsigned integer value. It is
used to decide whether a mobility session establishment or
modification request can be accepted; this is typically used for
admission control of Guaranteed Bit Rate traffic in case of
resource limitations. The priority level can also be used to
decide which existing mobility session to pre-empt during resource
limitations. The priority level defines the relative timeliness
of a resource request.
Values 1 to 15 are defined, with value 1 as the highest level of
priority.
Values 1 to 8 should only be assigned for services that are
authorized to receive prioritized treatment within an operator
domain. Values 9 to 15 may be assigned to resources that are
authorized by the home network and thus applicable when a mobile
node is roaming.
o Preemption-Capability (PC): is a 2-bit unsigned integer value. It
defines whether a service data flow can get resources that were
already assigned to another service data flow with a lower
priority level. The following values are defined:
Enabled (0): This value indicates that the service data flow is
allowed to get resources that were already assigned to another IP
data flow with a lower priority level.
Disabled (1): This value indicates that the service data flow is
not allowed to get resources that were already assigned to another
IP data flow with a lower priority level. The values (2) and (3)
are reserved.
o Preemption-Vulnerability (PV): is a 2-bit unsigned integer value.
It defines whether a service data flow can lose the resources
assigned to it in order to admit a service data flow with 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. The values (2)
Liebsch, et al. Expires September 29, 2014 [Page 26]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
and (3) are reserved.
4.2.6. Aggregate Maximum Downlink Bit Rate
This attribute, Aggregate-Max-DL-Bit-Rate, represents the maximum
downlink bit-rate for the mobility session. It is a variant of the
AMBR term defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in an Update Notification message sent by
the local mobility anchor, it indicates the maximum aggregate bit-
rate for downlink IP flows that is being requested.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement message, it
indicates the maximum aggregate downlink bit-rate that the peer
agrees to offer.
When a QoS option includes both the Aggregate-Max-DL-Bit-Rate
attribute and the QOS-Traffic-Selector attribute (Section 4.2.10),
then the Aggregate-Max-DL-Bit-Rate attribute is to be enforced at a
flow level and the traffic selectors present in the QOS-Traffic-
Selector attribute identifies those target flows.
When the QoS option that includes the Aggregate-Max-DL-Bit-Rate
attribute does not include the QOS-Traffic-Selector attribute
(Section 4.2.10), then the Aggregate-Max-DL-Bit-Rate attribute is to
be applied to all the IP flows associated with the mobility session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregate-Max-DL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 6
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (6).
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
Liebsch, et al. Expires September 29, 2014 [Page 27]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
receiver.
o Aggregate-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it
indicates the aggregate maximum downlink bit-rate that is
requested/allocated for downlink IP flows. The measurement units
for Aggregate-Max-DL-Bit-Rate are bits-per-second.
4.2.7. Aggregate Maximum Uplink Bit Rate
This attribute, Aggregate-Max-UL-Bit-Rate, represents the maximum
uplink bit-rate for the mobility session. It is a variant of the
AMBR term defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in an Update Notification message sent by
the local mobility anchor, it indicates the maximum aggregate uplink
bit-rate that is being requested.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement message, it
indicates the maximum aggregate uplink bit-rate that the peer agrees
to offer.
When a QoS option includes both the Aggregate-Max-UL-Bit-Rate
attribute and the QOS-Traffic-Selector attribute (Section 4.2.10),
then the Aggregate-Max-UL-Bit-Rate attribute is to be enforced at a
flow level and the traffic selectors present in the QOS-Traffic-
Selector attribute identifies those target flows.
When the QoS option that includes the Aggregate-Max-UL-Bit-Rate
attribute does not include the QOS-Traffic-Selector attribute
(Section 4.2.10), then the Aggregate-Max-UL-Bit-Rate attribute is to
be applied to all the IP flows associated with the mobility session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregate-Max-UL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Liebsch, et al. Expires September 29, 2014 [Page 28]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
o Type: 7
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (6).
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Per-Session-Agg-Max-UL-Bit-Rate: is a 32-bit unsigned integer, and
it indicates the aggregate maximum uplink bit-rate that is
requested/allocated for all the IP flows associated with that
mobility session. The measurement units for Aggregate-Max-UL-Bit-
Rate are bits-per-second.
4.2.8. Guaranteed Downlink Bit Rate
This attribute, Guaranteed-DL-Bit-Rate, represents the assured bit-
rate on the downlink path that will be provided for a set of IP flows
associated with a mobility session. It is a variant of the GBR term
defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in a Update Notification message sent by
the local mobility anchor, it indicates the guaranteed downlink bit-
rate that is being requested.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement message, it
indicates the guaranteed downlink bit-rate that the peer agrees to
offer.
When a QoS option includes both the Guaranteed-DL-Bit-Rate attribute
and the QOS-Traffic-Selector attribute (Section 4.2.10), then the
Guaranteed-DL-Bit-Rate attribute is to be enforced at a flow level
and the traffic selectors present in the QOS-Traffic-Selector
attribute identifies those target flows.
When the QoS option that includes the Guaranteed-DL-Bit-Rate
attribute does not include the QOS-Traffic-Selector attribute
(Section 4.2.10), then the Guaranteed-DL-Bit-Rate attribute is to be
applied to all the IP flows associated with the mobility session.
Liebsch, et al. Expires September 29, 2014 [Page 29]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Guaranteed-DL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 8
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (6).
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Guaranteed-DL-Bit-Rate: is of type unsigned 32-bit integer, and it
indicates the guaranteed bandwidth in bits-per-second for downlink
IP flows. The measurement units for Guaranteed-DL-Bit-Rate are
bits-per-second.
4.2.9. Guaranteed Uplink Bit Rate
This attribute, Guaranteed-UL-Bit-Rate, represents the assured bit-
rate on the uplink path that will be provided for a set of IP flows
associated with a mobility session. It is a variant of the GBR term
defined in Section 2.2.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can
only be a single instance of this attribute present in a QoS option.
When this attribute is present in a Proxy Binding Update sent by a
mobile access gateway, or in a Update Notification message sent by
the local mobility anchor, it indicates the guaranteed uplink bit-
rate that is being requested.
When this attribute is present in a Proxy Binding Acknowledgement
message, or in an Update Notification Acknowledgement message, it
indicates the guaranteed uplink bit-rate that the peer agrees to
offer.
When a QoS option includes both the Guaranteed-UL-Bit-Rate attribute
and the QOS-Traffic-Selector attribute (Section 4.2.10), then the
Guaranteed-UL-Bit-Rate attribute is to be enforced at a flow level
and the traffic selectors present in the QOS-Traffic-Selector
attribute identifies those target flows.
Liebsch, et al. Expires September 29, 2014 [Page 30]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
When the QoS option that includes the Guaranteed-UL-Bit-Rate
attribute does not include the QOS-Traffic-Selector attribute
(Section 4.2.10), then the Guaranteed-UL-Bit-Rate attribute is to be
applied to all the IP flows associated with the mobility session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Guaranteed-UL-Bit-Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 9
o Length: The length of the attribute in octets, excluding the Type
and Length fields. This value is set to (6).
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Guaranteed-UL-Bit-Rate: is of type unsigned 32-bit integer, and it
indicates the guaranteed bandwidth in bits-per-second for uplink
IP flows. The measurement units for Guaranteed-UL-Bit-Rate are
bits-per-second.
4.2.10. QoS Traffic Selector
This attribute, QoS-Traffic-Selector, includes the parameters used to
match packets for a set of IP flows.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute.
When a QoS option that includes the QoS-Traffic-Selector also
includes any one or more of the attributes, Allocation-Retention-
Priority (Section 4.2.5), Aggregate-Max-DL-Bit-Rate (Section 4.2.6),
Aggregate-Max-UL-Bit-Rate (Section 4.2.7), Guaranteed-DL-Bit-Rate
(Section 4.2.8), and Guaranteed-UL-Bit-Rate (Section 4.2.9), then
those included attributes are to be enforced at a flow level and the
traffic selectors present in the QoS-Traffic-Selector attribute
identifies those target flows. Furthermore, the DSCP marking in the
QoS option is to be applied only to partial set of mobile node's IP
flows and the traffic selectors present in the QoS-Traffic-Selector
attribute identifies those target flows.
Liebsch, et al. Expires September 29, 2014 [Page 31]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | TS Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Selector ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 10
o Length: The length of the attribute in octets, excluding the Type
and Length fields.
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o TS Format: An 8-bit unsigned integer indicating the Traffic
Selector Format. The values are allocated from the "Traffic
Selector Format" namespace for the traffic selector sub-option
defined in [RFC6089]; those defined in [RFC6089] are repeated here
for clarity. Value (0) is reserved and MUST NOT be used. When
the value of TS Format field is set to (1), the format that
follows is the IPv4 Binary Traffic Selector specified in section
3.1 of [RFC6088], and when the value of TS Format field is set to
(2), the format that follows is the IPv6 Binary Traffic Selector
specified in section 3.2 of [RFC6088].
o Traffic Selector: variable-length field for including the traffic
specification identified by the TS format field.
4.2.11. QoS Vendor Specific Attribute
This attribute is used for carrying vendor specific QoS attributes.
The interpretation and the handling of this option is specific to the
vendor implementation.
This attribute can be included in the Quality of Service option
defined in Section 4.1 and it is an optional attribute. There can be
multiple instances of this attribute with different sub-type values
present in a single QoS option.
Liebsch, et al. Expires September 29, 2014 [Page 32]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 11
o Length: The length of the attribute in octets, excluding the Type
and Length fields.
o Reserved: This field is unused for now. The value MUST be
initialized by the sender to 0 and MUST be ignored by the
receiver.
o Vendor ID: The Vendor ID is the SMI (Structure of Management
Information) Network Management Private Enterprise Code of the
IANA-maintained Private Enterprise Numbers registry [SMI].
o Sub-Type: An 8-bit field indicating the type of vendor-specific
information carried in the option. The name space for this Sub-
type is managed by the Vendor identified by the Vendor ID field.
4.3. New Status Code for Proxy Binding Acknowledgement
This document defines the following new Status Code value for use in
Proxy Binding Acknowledgement message.
CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request):
<IANA-2>
4.4. New Notification Reason for Update Notification Message
This document defines the following new Notification Reason value for
use in Update Notification message.
QOS_SERVICE_REQUEST (QoS Service Requested): <IANA-3>
4.5. New Status Code for Update Notification Acknowledgement Message
This document defines the following new Status code value for use in
Update Notification Acknowledgement message.
CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request ):
Liebsch, et al. Expires September 29, 2014 [Page 33]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
<IANA-4>
Liebsch, et al. Expires September 29, 2014 [Page 34]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
5. Protocol Considerations
5.1. Local Mobility Anchor Considerations
o The conceptual Binding Cache entry data structure maintained by
the local mobility anchor, described in Section 5.1 of [RFC5213],
can be extended to store a list of negotiated Quality of Service
requests to be enforced. There can be multiple such entries and
each entry must include the Service Request Identifier, DSCP value
and the attributes defined in Section Section 4.2.
LMA Receiving a QoS Service Request:
o On receiving a Proxy Binding Update message with one or more
instances of Quality of Service option included in the message,
the local mobility anchor processes the option(s) and determines
if the QoS service request for the proposed QoS service request(s)
can be met. Each instance of the Quality of Service option
represents a specific QoS service request. This determination to
accept the request(s) can be based on policy configured on the
local mobility anchor, available network resources, or based on
other considerations.
o If the local mobility anchor can support the proposed QoS service
requests in entirety, then it sends a Proxy Binding
Acknowledgement message with a status code value of (0).
* The message includes all the Quality of Service option
instances copied (including all the option content) from the
received Proxy Binding Update message. However, if the
Operational Code field in the request is a QUERY, then the
message includes all the Quality of Service option(s)
reflecting the currently negotiated QoS service requests for
that mobility session.
* The Operational Code field in each of the Quality of Service
option(s) is set to RESPONSE.
* The local mobility anchor should enforce the Quality of Service
rules for all the negotiated QoS service requests on the mobile
node's uplink and downlink traffic.
o If the local mobility anchor cannot support any of the requested
QoS service requests in entirety, it rejects the request and sends
a Proxy Binding Acknowledgement message with the status code value
set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service
Request).
Liebsch, et al. Expires September 29, 2014 [Page 35]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
* The denial for QoS service request MUST NOT result in removal
of the mobility session for that mobile node.
* The Operational Code field in each of the Quality of Service
option(s) is set to RESPONSE.
* The Proxy Binding Acknowledgement message may include the
Quality of Service option based on the following
considerations.
+ If the local mobility anchor cannot support QoS services for
that mobile node, then Quality of Service option is not
included in the Proxy Binding Acknowledgement message. This
serves as an indication to the mobile access gateway that
QoS services are not supported for that mobile node.
+ If the local mobility anchor can support QoS services for
that mobile node, but for a downgraded/revised QoS service
request, or for a partial set of QoS service requests, the
updated Quality of Service option(s) is included in the
Proxy Binding Acknowledgement message. This includes the
case, where the Attributes in a QoS option have conflicting
requirements, Ex: Per-Session-Agg-Max-UL-Bit-Rate is lower
than the Guaranteed-UL-Bit-Rate. The contents of each of
the option (including the QoS attributes) reflect the QoS
service parameters that the local mobility anchor can
support for that mobile node. The Operational Code field in
each of the Quality of Service option(s) is set to
NEGOTIATE. This serves as an indication for the mobile
access gateway to resend the Proxy Binding Update message
with the revised QoS parameters.
LMA Sending a QoS Service Request:
o The local mobility anchor, at any time, can initiate a QoS service
request for mobile node, by sending an Update Notification message
[RFC7077]. The Notification Reason in the Update Notification
message is set to a value of QOS_SERVICE_REQUEST and the
Acknowledgement Requested (A) flag set to a value of (1).
* New QoS service request:
+ The message includes a Quality of Service option with one or
more QoS attributes included in the option.
+ The Operational Code field in the Quality of Service option
is set to ALLOCATE.
Liebsch, et al. Expires September 29, 2014 [Page 36]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+ The Service Request Identifier is set to a value of (0).
+ The DSCP field in the Traffic Class (TC) field reflects the
requested DSCP value.
* Modification of an existing QoS Service Request:
+ The message includes a Quality of Service option with the
QoS attributes reflecting the updated values in the
Attributes, and the updated list of Attributes.
+ The Operational Code field in the Quality of Service option
is set to MODIFY.
+ The Service Request Identifier is set to a value that was
allocated for that QoS service request.
+ There can be more than one QOS service request in a single
message. If so, the message includes an instance of a
Quality of Service option for each of those service
requests.
* Deletion of an existing QoS Service Request:
+ The Operational Code field in the Quality of Service option
is set to DE-ALLOCATE.
+ The Service Request Identifier is set to a value that was
allocated for that QoS service request.
+ The message includes a Quality of Service option with the
QoS attributes reflecting the updated values for the
attributes.
* Query for the previously negotiated QoS Service Requests:
+ The Operational Code field in the Quality of Service option
is set to QUERY.
+ The Service Request Identifier is set to a value of (0).
+ The message includes a single instance of the Quality of
Service option without including any QoS Attributes.
o Handling a Response to the QoS Service Request:
* If the received Update Notification Acknowledgement [RFC7077]
message has the status code field set to value of (0), the
Liebsch, et al. Expires September 29, 2014 [Page 37]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
local mobility anchor should enforce the Quality of Service
rules for the negotiated QoS parameters on the mobile node's
uplink and downlink traffic.
* If the received Update Notification Acknowledgement message is
with the status code field set to value of
(CANNOT_MEET_QOS_SERVICE_REQUEST), the local mobility anchor
applies the following considerations.
+ The denial of QoS service request results in removal of any
of the mobile node's Binding Cache entries.
+ If the message did not include any Quality of Service
option(s), then it is an indication from the mobile access
gateway that QoS services are not enabled for the mobile
node.
+ If the Operational Code field in the Quality of Service
option is set to a value of NEGOTIATE and the message
includes one or more instances of the Quality of Service
option, but the option contents reflect a downgraded/revised
set of QoS parameters, then the local mobility anchor MAY
choose to agree to proposed QoS service request by resending
a new Proxy Binding Update message with the updated Quality
of Service option.
General Considerations:
o Any time the local mobility anchor removes a mobile node's
mobility session by removing a Binding Cache entry [RFC5213], for
which QoS resources have been previously allocated, those
allocated resources are released.
o Any time the local mobility anchor receives a Proxy Binding Update
with HI hint = 3 (inter-MAG handover), the local mobility anchor
when sending a Proxy Binding Acknowledgement message includes the
QoS option(s) for each of the QoS service requests that are active
for that mobile node. This allows the mobile access gateway to
allocate QoS resources on the current path. This is relevant for
the scenario where a mobile node performs an handover to a new
mobile access gateway which is unaware of the previously
negotiated QoS services.
5.2. Mobile Access Gateway Considerations
o The conceptual Binding Update List entry data structure maintained
by the mobile access gateway, described in Section 6.1 of
[RFC5213], can be extended to store a list of negotiated Quality
Liebsch, et al. Expires September 29, 2014 [Page 38]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
of Service requests to be enforced. There can be multiple such
entries and entry including the Service Request Identifier, DSCP
value and the attributes defined in Section Section 4.2.
MAG Receiving a QoS Service Request:
o On receiving a Update Notification message with one or more
instances of Quality of Service option included in the message,
the mobile access gateway processes the option(s) and determine if
the QoS service request for the proposed QoS service request(s)
can be met. Each instance of the Quality of Service option
represents a specific QoS service request. This determination to
accept the request(s) can be based on policy configured on the
mobile access gateway, available network resources, or based on
other considerations.
o If the mobile access gateway can support the proposed QoS service
requests in entirety, then it sends a an Update Notification
Acknowledgement message with status code value of (0).
* The message includes all the Quality of Service option
instances copied (including all the option content) from the
received Update Notification message. However, if the
Operational Code field in the request is a QUERY, then the
message includes all the Quality of Service option(s)
reflecting the currently negotiated QoS service requests for
that mobility session.
* The Operational Code field in each of the Quality of Service
option(s) is set to RESPONSE.
* The mobile access gateway should enforce the Quality of Service
rules for all the negotiated QoS service requests on the mobile
node's uplink and downlink traffic.
o If the mobile access gateway cannot support any of the requested
QoS service requests in entirety, then it rejects the request and
send an Update Notification Acknowledgement message with the
status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet
QoS Service Request).
* The denial for QoS service request MUST NOT result in removal
of the mobility session for that mobile node.
* The Operational Code field in each of the Quality of Service
option(s) is set to RESPONSE.
Liebsch, et al. Expires September 29, 2014 [Page 39]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
* The Update Notification Acknowledgement message may include the
Quality of Service option(s) based on the following
considerations.
+ If the mobile access gateway cannot support QoS services for
that mobile node, then Quality of Service option is not
included in the Update Notification Acknowledgement message.
This serves as an indication to the local mobility anchor
that QoS services are not supported for that mobile node.
+ If the mobile access gateway can support QoS services for
that mobile node, but for a downgraded/revised QoS service
request, or for a partial set of QoS service requests, then
the updated Quality of Service option(s) is included in the
Update Notification Acknowledgement message. This includes
the case, where the Attributes in a QoS option have
conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit-
Rate is lower than the Guaranteed-UL-Bit-Rate. The contents
of each of the option (including the QoS attributes) reflect
the QoS service parameters that the mobile access gateway
can support for that mobile node. The Operational Code
field in each of the Quality of Service option(s) is set to
NEGOTIATE. This serves as an indication to the local
mobility anchor to resend the Update Notification message
with the revised QoS parameters.
MAG Sending a QoS Service Request:
o The mobile access gateway, at any time, can initiate a QoS service
request for a mobile node, by sending a Proxy Binding Update
message. The QoS service request can be initiated as part of the
initial Binding registration, or during binding re-registrations.
* New QoS service request:
+ The message includes a Quality of Service option with one or
more QoS attributes included in the option.
+ The Operational Code field in the Quality of Service option
is set to ALLOCATE.
+ The Service Request Identifier is set to a value of (0).
+ The DSCP value in the Traffic Class field reflects the
requested DSCP value.
Liebsch, et al. Expires September 29, 2014 [Page 40]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
* Modification of an existing QoS Service Request:
+ The message includes a Quality of Service option with the
QoS attributes reflecting the updated values in the
Attributes, and the updated list of Attributes.
+ The Operational Code field in the Quality of Service option
is set to MODIFY.
+ The Service Request Identifier is set to a value that was
allocated for that QoS service request.
+ There can be more than one QOS service request in a single
message. If so, the message includes an instance of a
Quality of Service option for each of those service
requests.
* Deletion of an existing QoS Service Request:
+ The Operational Code field in the Quality of Service option
is set to DE-ALLOCATE.
+ The Service Request Identifier is set to a value that was
allocated for that QoS service request.
+ The message includes a Quality of Service option with the
QoS attributes reflecting the updated values for the
attributes.
* Query for the previously negotiated QoS Service Requests:
+ The Operational Code field in the Quality of Service option
is set to QUERY.
+ The Service Request Identifier is set to a value of (0).
+ The message includes a single instance of the Quality of
Service option without including any QoS Attributes.
o Handling a Response to the QoS Service Request:
* If the received Proxy Binding Acknowledgement message has the
status code field set to a value of (0), the mobile access
gateway should enforce the Quality of Service rules for the
negotiated QoS parameters on the mobile node's uplink and
downlink traffic.
Liebsch, et al. Expires September 29, 2014 [Page 41]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
* If the received Proxy Binding Acknowledgement message has the
status code field set to a value of
(CANNOT_MEET_QOS_SERVICE_REQUEST), the mobile access gateway
applies the following considerations.
+ The denial of QoS service request MUST NOT result in removal
of any of the mobile node's Binding Update list entries.
+ If the message did not include any Quality of Service
option(s), then it is an indication from the local mobility
anchor that QoS services are not enabled for the mobile
node.
+ If the Operational Code field in the Quality of Service
option is set to a value of NEGOTIATE and the message
includes one or more instances of the Quality of Service
option, but the option contents reflect a downgraded/revised
set of QoS parameters, then the mobile access gateway MAY
choose to agree to proposed QoS service request by resending
a new Proxy Binding Update message with the updated Quality
of Service option.
* General Considerations:
+ There can be more than one QOS service request in a single
message. If so, the message includes an instance of a
Quality of Service option for each of those service
requests. Furthermore, the DSCP value is different in each
of those requests.
+ Any time the mobile access gateway removes a mobile node's
mobility session by removing a Binding Update List entry
[RFC5213], for which QoS resources have been previously
allocated, those allocated resources are released.
Liebsch, et al. Expires September 29, 2014 [Page 42]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
6. QoS Services in Integrated WLAN-3GPP Networks
6.1. Technical Scope and Procedure
The QoS option specified in this document can provide the equivalent
level of QoS information defined in 3GPP, which is used to enforce
QoS policies for IP flows, which have been established while the
mobile node is attached to WLAN access, or moved from 3GPP to WLAN
access. The QoS classification defined by the 3GPP specification is
provided by Differentiated Services techniques in the IP transport
network and translated as appropriate into WLAN QoS specification in
WLAN access, the details of which are described in Appendix A and
Appendix B.
Figure 6 illustrates a generalized architecture where the QoS option
can be used. The QoS policies could be retrieved from a Policy
Control Function (PCF), such as defined in current cellular mobile
communication standards, which aims to assign an appropriate QoS
class to a mobile node's individual flows. Alternatively, more
static and default QoS rules could be made locally available, e.g. on
a local mobility anchor, through administration.
Liebsch, et al. Expires September 29, 2014 [Page 43]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Non-cellular access | Cellular Core Network Cellular
(e.g. WLAN) | (e.g. EPC) Access
| (e.g.
| +-----------+ EUTRAN)
| | PCF |
| |(e.g. PCRF)|
+----+ | +-----+-----+
|WiFi| (I) | |
| AP |---+ +---+---+ | | ((O))
+----+ | |WiFi AR| | PMIPv6 +-----+ +---+ |
+----+ (MAG) +=|============| LMA |=====|MAG+--|
| | WLC | | tunnel +-----+ +---+ |
+----+ | +-------+ | //
|WiFi|---+ | //
| AP | | //
+----+ (II) | //
+-------+ | //
+----+ +------+ |WiFi AR| | //
|WiFi+----+ WLC +------+ (MAG) |=|=======//
| AP | | | | | |
+----+ +------+ +------ + |
^ ^ |
| | |
+------------+
QoS inter-working
Figure 6: Architecture for QoS inter-working between cellular access
and non-cellular access
During a mobile node's handover from cellular access to non-cellular
access, e.g. a wireless LAN (WLAN) radio access network, the mobile
node's QoS policy rules, as previously established on the local
mobility anchor for the mobile node's communication through the
cellular access network, are moved to the handover target mobile
access gateway serving the non-cellular access network. Such non-
cellular mobile access gateway can have an access technology specific
controller or function co-located, e.g. a Wireless LAN Controller
(WLC), as depicted in option (I) of Figure 6. Alternatively, the
access specific architecture can be distributed and the access
technology specific control function is located external to the
mobile access gateway, as depicted in option (II). In this case, the
mobile access gateway and the access technology specific control
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 29, 2014 [Page 44]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
6.2. Relevant QoS Attributes
The QoS Option shall at least contain a DSCP value being associated
with IP flows of a mobility session. The DSCP value should
correspond to the 3GPP QoS Class Index (QCI), which identifies the
type of service in term of QoS characteristics (e.g. conversational
voice, streaming video, signalling, best effort,...); more details on
DSCP and QCI mapping are given on section Appendix A. Optional QoS
information could also be added. For instance, in order to comply
with the bearer model defined in 3GPP [TS23.203], the following QoS
parameters are conveyed for each PMIPv6 mobility session:
o Default, non-GBR bearer (QCI=5-9)
* DSCP=(BE, AF11, AF21, AF31, AF32)
* Per-MN AMBR-UL/DL
* Per-Session AMBR-UL/DL {S=1,E=1}
* AARP
APN (Access Point Name) is provided via the Service Selection ID
defined in [RFC5149]. If APN is not interpreted by Wi-Fi AP, the
latter will police only based on Per-MN AMBR-UL/DL (without Per-
Session AMBR-UL/DL) on the Wi-Fi link.
o Dedicated, GBR bearer (QCI=1-4)
* DSCP=(EF, AF41)
* GBR-UL/DL
* MBR-UL/DL
* AARP
* TS
Wi-Fi AP will perform the policy enforcement with the minimum bit-
rate=GBR and the maximum bit-rate=MBR.
o Dedicated, non-GBR bearer (QCI=5-9)
* DSCP=(BE, AF11, AF21, AF31, AF32}
* Per-MN AMBR-UL/DL
Liebsch, et al. Expires September 29, 2014 [Page 45]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
* Per-Session AMBR-UL/DL {S=1,E=1}
* AARP
* TS
If APN is not interpreted by Wi-Fi AP, it will police based only
on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi
link.
If DSCP values follow the 3GPP specification and deployment, the code
point can carry intrinsically additional attributes according to
Figure 7.
For some optional QoS attributes the signalling can differentiate
enforcement per mobility session and per IP flow. For the latter, as
long as the AMBR constraints are met, the rule associated with the
identified flow(s) overrules the aggregated rules which apply per
Mobile Node or per Mobility Session. Additional attributes can be
appended to the QoS option, but their definition and specification is
out of scope of this document and left to their actual deployment.
Liebsch, et al. Expires September 29, 2014 [Page 46]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
7. IANA Considerations
This document requires the following IANA actions.
o Action-1: This specification defines a new mobility option, the
Quality of Service (QoS) option. The format of this option is
described in Section 4.1. The type value <IANA-1> for this
mobility option needs to be allocated from the Mobility Options
registry at <http://www.iana.org/assignments/mobility-parameters>.
RFC Editor: Please replace <IANA-1> in Section 4.1 with the
assigned value and update this section accordingly.
o Action-2: This specification defines a new mobility attribute
format, Quality of Service attribute. The format of this
attribute is described in Section Section 4.2. This attribute can
be carried in the Quality of Service mobility option. The type
values for this attribute need to be managed by IANA in a new
Registry, the "Quality of Service Attribute Registry". This
registry is maintained under "Mobile IPv6 Parameters" registry at
<http://www.iana.org/assignments/mobility-parameters>. This
specification reserves the following type values. All other
values (12 - 254) are unassigned and may be assigned by IANA using
the Specification Required policy [RFC5226]. Designated Expert
reviewing the value assignment is expected to verify that the
protocol extension follows the Proxy Mobile IPv6 architecture and
does not raise backward compatibility issues with existing
deployments.
Liebsch, et al. Expires September 29, 2014 [Page 47]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+=====+=================================+=================+
|Value| Description | Reference |
+=====+=================================+=================+
| 0 | Reserved | <this draft> |
+=====+===================================================+
| 1 | Per-MN-Agg-Max-DL-Bit-Rate | <this draft> |
+=====+===================================================+
| 2 | Per-MN-Agg-Max-UL-Bit-Rate | <this draft> |
+=====+===================================================+
| 3 | Per-Session-Agg-Max-DL-Bit-Rate | <this draft> |
+=====+===================================================+
| 4 | Per-Session-Agg-Max-UL-Bit-Rate | <this draft> |
+=====+===================================================+
| 5 | Allocation-Retention-Priority | <this draft> |
+=====+===================================================+
| 6 | Aggregate-Max-DL-Bit-Rate | <this draft> |
+=====+===================================================+
| 7 | Aggregate-Max-UL-Bit-Rate | <this draft> |
+=====+===================================================+
| 8 | Guaranteed-DL-Bit-Rate | <this draft> |
+=====+===================================================+
| 9 | Guaranteed-UL-Bit-Rate | <this draft> |
+=====+===================================================+
| 10 | QoS-Traffic-Selector | <this draft> |
+=====+===================================================+
| 11 | QoS-Vendor-Specific-Attribtute | <this draft> |
+=====+===================================================+
| 255 | Reserved | <this draft> |
+=====+===================================================+
o Action-3: This document defines a new status value,
CANNOT_MEET_QOS_SERVICE_REQUEST (<IANA-2>) for use in Proxy
Binding Acknowledgement message, as described in Section 4.3.
This value is to be assigned from the "Status Codes" registry at
<http://www.iana.org/assignments/mobility-parameters>. The
allocated value has to be greater than 127. RFC Editor: Please
replace <IANA-2> in Section 4.3 with the assigned value and update
this section accordingly.
o Action-4: This document defines a new Notification Reason,
QOS_SERVICE_REQUEST (<IANA-3>) for use in Update Notification
message [RFC7077] as described in Section 4.4. This value is to
be assigned from the "Update Notification Reasons Registry" at
<http://www.iana.org/assignments/mobility-parameters>. RFC
Editor: Please replace <IANA-3> in Section 4.4 with the assigned
value and update this section accordingly.
Liebsch, et al. Expires September 29, 2014 [Page 48]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
o Action-5: This document defines a new Notification Reason,
CANNOT_MEET_QOS_SERVICE_REQUEST (<IANA-4>) for use in Update
Notification Acknowledgement message [RFC7077] as described in
Section 4.5. This value is to be assigned from the "Update
Notification Acknowledgement Status Registry" at
<http://www.iana.org/assignments/mobility-parameters>. RFC
Editor: Please replace <IANA-4> in Section 4.5 with the assigned
value and update this section accordingly.
Liebsch, et al. Expires September 29, 2014 [Page 49]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
8. Implementation Status
Note to RFC Editor: Please remove this section and the reference to
[RFC6982] before publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Cisco Implementation
Organization: Cisco
Description: QoS Extensions to Cisco IOS-based MAG and LMA
Implementations. Engineering prototype code under development.
Coverage: Support includes QoS signaling from MAG to LMA based on
PBU/PBA and LMA to MAG based on the recently standardized UPN/UPA
messages. Implementation includes only a partial set of QoS
attributes and support for other Attributes is under development.
The QoS option is based on the Vendor-specific mobility option,
but it has all the parameters defined in -07 version of the
document. We have plans to show a demo in the next IETF.
Licensing: Closed. However, cisco has plans to release the MAG
portion of the code for Linux as open source.
Implementation Experience: The feedback from the developer
suggests that the protocol extensions needed for this
specification proved to be reasonably straightforward. Numerous
draft revisions were made based on the questions and comments from
the developer. The effort to most part appears to be around
Liebsch, et al. Expires September 29, 2014 [Page 50]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
interfacing with the platform specific QoS features for enforcing
the negotiated QoS parameters for a subscriber's IP session/flows.
On Cisco IOS, there is a programmatic interface with rich
semantics for interfacing with IOS MQC. It needs to be seen as
how this can be realized on a Linux OS.
Contact: Sri Gundavelli (sgundave@cisco.com)
Liebsch, et al. Expires September 29, 2014 [Page 51]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
9. Security Considerations
The quality of service option defined in this specification is for
use in Proxy Binding Update, Proxy Binding Acknowledgement, Update
Notification, and Update Notification Acknowledgement messages. This
option is carried in these message like any other mobility header
option. [RFC5213] and [RFC7077] identify the security considerations
for these signalling messages. The quality of service option when
included in these signalling messages does not require additional
security considerations.
Liebsch, et al. Expires September 29, 2014 [Page 52]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
10. Acknowledgements
The authors of this document thank the members of NetExt Working
Group for the valuable feedback to different versions of this
specification. In particular the authors want to thank Basavaraj
Patil, Behcet Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson,
Tricci So, Ahmad Muhanna, Pete McCann, Byju Pularikkal, John
Kaippallimalil, Rajesh Pazhyannur, Carlos J. Bernardos Cano, Michal
Hoeft, Ryuji Wakikawa, Liu Dapeng, Seil Jeon, Georgios Karagiannis.
The authors would like to thank all the IESG reviewers and specially,
Ben Campbell, Barry Leiba, Jari Arkko, Alissa Cooper, Stephen
Farrell, Ted Lemon and Alia Atlas for their valuable comments and
suggestions to improve this specification.
Finally, the authors would like to express sincere and profound
appreciation to our Internet Area Director, Brian Haberman for his
guidance and great support in allowing us to complete this work.
Liebsch, et al. Expires September 29, 2014 [Page 53]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
January 2011.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, November 2013.
11.2. Informative References
[GSMA.IR.34]
GSMA, "Inter-Service Provider IP Backbone Guidelines 5.0",
May 2013.
[IEEE802.11-2012]
IEEE, "Part 11: Wireless LAN Medium Access Control(MAC)
and Physical Layer (PHY) specifications", 2012.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Liebsch, et al. Expires September 29, 2014 [Page 54]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
July 2013.
[SMI] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
Private Enterprise Codes, February 2011.
[TS22.115]
3GPP, "Technical Specification Group Services and System
Aspects, Service aspects; Charging and Billing", 2002.
[TS23.203]
3GPP, "Policy and charging control architecture", 2013.
[TS23.402]
3GPP, "Architecture enhancements for non-3GPP accesses",
2010.
Liebsch, et al. Expires September 29, 2014 [Page 55]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Appendix A. Information when implementing 3GPP QoS in IP transport
network
A.1. Mapping tables
Mapping between 3GPP QCI values and DSCP is defined in [GSMA.IR.34]
as follows.
+=====+================+===========================+======+
| QCI | Traffic Class | DiffServ Per-Hop-Behavior | DSCP |
+=====+================+===========================+======+
| 1 | Conversational | EF |101110|
+=====+===================================================+
| 2 | Conversational | EF |101110|
+=====+===================================================+
| 3 | Conversational | EF |101110|
+=====+===================================================+
| 4 | Streaming | AF41 |100010|
+=====+===================================================+
| 5 | Interactive | AF31 |011010|
+=====+===================================================+
| 6 | Interactive | AF32 |011100|
+=====+===================================================+
| 7 | Interactive | AF21 |010010|
+=====+===================================================+
| 8 | Interactive | AF11 |001010|
+=====+===================================================+
| 9 | Background | BE |000000|
+=====+===================================================+
Figure 7: QCI/DSCP Mapping Table
Mapping between QoS attributes defined in this document and 3GPP QoS
parameters is as follows.
Liebsch, et al. Expires September 29, 2014 [Page 56]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+=======+===============================+=============+
|Section| PMIPv6 QoS | 3GPP QoS |
| | Attribute | Parameter |
+=======+===============================+=============+
| 4.2.1 | Per-MN-Agg-Max-DL-Bit-Rate | UE AMBR-DL |
+-------+-------------------------------+-------------+
| 4.2.2 | Per-MN-Agg-Max-UL-Bit-Rate | UE AMBR-UL |
+-------+-------------------------------+-------------+
| 4.2.3 |Per-Session-Agg-Max-DL-Bit-Rate| APN AMBR-DL |
| | Flags: (S=1, E=1) | |
+-------+-------------------------------+-------------+
| 4.2.4 |Per-Session-Agg-Max-UL-Bit-Rate| APN AMBR-UL |
| | Flags: (S=1, E=1) | |
+-------+-------------------------------+-------------+
| 4.2.5 | Allocation-Retention-Priority | ARP |
+-------+-------------------------------+-------------+
| 4.2.6 | Aggregate-Max-DL-Bit-Rate | MBR-DL |
+-------+-------------------------------+-------------+
| 4.2.7 | Aggregate-Max-UL-Bit-Rate | MBR-UL |
+-------+-------------------------------+-------------+
| 4.2.8 | Guaranteed-DL-Bit-Rate | GBR-DL |
+-------+-------------------------------+-------------+
| 4.2.9 | Guaranteed-UL-Bit-Rate | GBR-UL |
+-------+-------------------------------+-------------+
| 4.2.10| QoS-Traffic-Selector | TFT |
+-------+-------------------------------+-------------+
Figure 8: QoS attributes and 3GPP QoS parameters Mapping Table
A.2. Use cases and protocol operations
This subsections provide example message flow charts for scenarios
where the QoS option extensions will apply as described in
(Section 6.1), to the protocol operation for QoS rules establishment
as shown in Appendix A.2.1 and Appendix A.2.2, and modification as
show in Appendix A.2.3.
A.2.1. Handover of existing QoS rules
In Figure 9, 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 Wi-Fi AP (e.g., at home or in a cafe) and switches to it
provided that Wi-Fi access has a higher priority when available. Not
only is the session continued, but also the QoS is maintained after
moving to the Wi-Fi access. In order for that to happen, the LMA
delivers the QoS parameters according to the bearer type on the 3GPP
Liebsch, et al. Expires September 29, 2014 [Page 57]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
access to the MAG via the PMIPv6 signaling with the QoS option
(OC=ALLOCATE, SR-ID, QoS attributes, etc.). The equivalent QoS
treatment is provided by the Wi-Fi AP toward the MN on the Wi-Fi
link.
+--------+
|Policy |
|Control |
|Function|
+---+----+
|
+----+ +-------+ +---+----+
+--+ |LTE |_______| SGW | | PGW |
|MN|~~|eNB | | |==============| (LMA) |
+--+ +----+ +-------+ //+--------+
: //
: //
V +----+ +-------+ PMIPv6 //
+--+ |WiFi|_______| WLC |=========
|MN|~~| AP | | (MAG) | tunnel
+--+ +----+ +-------+
Figure 9: Handover Scenario (from LTE to WLAN)
Figure 10 shows an example of how the QoS rules can be conveyed and
enforced between the LMA and MN in the case of handover from 3GPP
access to WLAN access.
Liebsch, et al. Expires September 29, 2014 [Page 58]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+--+ +--+ +---+ +---+
|MN| |AP| |MAG| |LMA|
+--+ +--+ +---+ +---+
|| | | To |data
|+--detach | | cellular<-==data[DSCP]==-|<----
+----attach-----+ | access [QoS rules]
| |-INFO[MNattach]->| |
| | |-------PBU[handover]------>|
| | | |
| | |<--PBA[QoS option(OC=1 )]--|
| |<-INFO[QoSrules]-| |
| | | |
| Apply Establish Update
| mapped MN's uplink MN's downlink
| QoS rules DSCP rules DSCP rules
| | +===========================+
| | | |
| |(B) |(A) |data
|<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<----
| | | |
| | | |data
|---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|--->
| |(C) |(D) |
| | | |
(A): Apply DSCP at link to AP
(B): Enforce mapped QoS rules to access technology
(C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or
validate MN-indicated QC and apply DSCP on the AP-MAG link
according to QoS rules
(D): Validate received DSCP and apply DSCP according to QoS rules
Figure 10: Handover of QoS rules
A.2.2. Establishment of QoS rules
A single operator has deployed both a fixed access network and a
mobile access network. In this scenario, the operator may wish a
harmonized QoS management on both accesses, but the fixed access
network does not implement a QoS control framework. So, the operator
chooses to rely on the 3GPP policy control function, which is a
standard framework to provide a QoS control, and to enforce the 3GPP
QoS policy on the Wi-Fi Access network. The PMIP interface is used
to realize this QoS policy provisioning.
The use-case is depicted on Figure 11. The MN first attaches to the
Wi-Fi network. During the attachment process, the LMA, which may
Liebsch, et al. Expires September 29, 2014 [Page 59]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
communicate with Policy Control Function (using procedures outside
the scope of this document), provides the QoS parameters to the MAG
via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e. PBA).
Subsequently, an application on the MN may trigger the request for
alternative QoS resources, e.g., by use of the WMM-API. The MN may
request traffic resources be reserved using L2 signaling, e.g.,
sending an ADDTS message [IEEE802.11-2012]. The request is relayed
to the MAG which includes the QoS parameters in the QoS option
(OC=ALLOCATE) on the PMIP signaling (i.e. the PBU initiated upon flow
creation). The LMA, in co-ordination with the PCF, can then
authorize the enforcement of such QoS policy. Then, the QoS
parameters are provided to the MAG via the QoS option (OC=ALLOCATE,
SR-ID, QoS attributes, etc.) in the PMIP signaling and the equivalent
QoS treatment is provided towards the MN on the Wi-Fi link.
|
|
| +--------+
| |Policy |
| |Control |
| |Function|
| +---+----+
| |
| +---+----+
+----+ +-------+ PMIPv6 | | PGW |
+--+ |WiFi|_______| WLC |========|=| (LMA) |
|MN|~~| AP | | (MAG) | tunnel | +--------+
+--+ +----+ +-------+ |
|
Wi-Fi Access |
Network | Cellular
| Network
|
Figure 11: QoS policy provisioning
Figure 12 shows an example of how the QoS rules can be conveyed and
enforced between the LMA and MN in the case of initial attachment to
WLAN access.
Liebsch, et al. Expires September 29, 2014 [Page 60]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+--+ +--+ +---+ +---+
|MN| |AP|-------------|MAG|-----------------------|LMA|
+--+ +--+ +---+ +---+
| | | |
| | | |
+----attached---+ | [QoS rules]
| | | |
new session |(E) |(F) |data
|----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|--->
| | |--PBU[update,QoS option]-->|
| | | (ReReg) (OC=1) Validate and
| | | add QoS rule
| | |<----PBA[QoS option]----|
| |<-INFO[QoSrules]-| (OC=1, SR-ID)[QoS rules']
| | | |
| Apply Establish |
| adapted MN's uplink |
| QoS rules DSCP rules |
| | | |
| | | |
| | | |data
|<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<----
| | | |
| | | |data
|---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|--->
| | | |
| | | |
(E): AP may enforce uplink QoS rules according to priority class
set by the MN
(F): MAG can enforce a default QoS class until local mobility anchor
has classified the new flow (notified with PBA) or mobile
access gateway classifies new flow and proposes the associated
QoS class to the local mobility anchor for validation (proposed
with PBU, notification of validation result with PBA)
Figure 12: Adding new QoS Service Request for MN initiated flow
A.2.3. Dynamic Update to QoS Policy
A mobile node is attached to the WLAN access and has obtained QoS
parameters from the LMA for that mobility session. Having obtained
the QoS parameters, a new application, e.g. IMS application, gets
launched on the mobile node that requires certain QoS support.
The application on the mobile node initiates the communications via a
dedicated network function (e.g. IMS Call Session Control Function).
Liebsch, et al. Expires September 29, 2014 [Page 61]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Once the communication is established, the application network
function notifies the PCF about the new IP flow. The PCF function in
turn notifies the LMA about the needed QoS parameters identifying the
IP flow and QoS parameters. LMA sends an Update Notification message
[RFC7077] to the MAG with the Notification Reason value set to
"QOS_SERVICE_REQUEST". The MAG, on receiving the Update Notification
message, completes the PBU/PBA signaling for obtaining the new QoS
parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes,
etc.). The MAG provisions the newly obtained QoS parameters on the
access network to ensure the newly established IP flow gets its
requested network resources.
Upon termination of the established IP flow, the application network
function again notifies the PCF function for removing the established
QoS parameters. The PCF notifies the LMA for withdrawing the QoS
resources established for that voice flow. The LMA sends an Update
Notification message to the MAG with the "Notification Reason" value
set to "FORCE-REREGISTRATION". The MAG on receiving this message
Update Notification Acknowledgement and completes the PBU/PBA
signaling for removing the existing QoS rules (OC=DE-ALLOCATE,
SR-ID). The MAG then removes the QoS parameters from the
corresponding IP flow and releases the dedicated network resources on
the access network.
Liebsch, et al. Expires September 29, 2014 [Page 62]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Appendix B. Information when implementing PMIP based QoS support with
IEEE 802.11e
This section shows, as an example, the end-to-end QoS management with
a 802.11e capable WLAN access link and a PMIP based QoS support.
The 802.11e, or Wi-Fi Multimedia (WMM), specification provides
prioritization of packets for four types of traffic, or access
categories (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 13 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 29, 2014 [Page 63]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+=============+ +-----+
DSCP/802.1p | PDP |
mapping table +-----+
+=============+ PEP |
`._ +---+---+ |
`._ |WiFi AR| PMIPv6 +-----+
- + (MAG) +===============| LMA |
| WLC | tunnel +-----+
+-------+ PEP
|
==Video== 802.1p/DSCP
==Voice== |
== B.E.== +----+
+----+ |WLAN| PEP
| MN |----802.11e----| AP |
+----+ +----+
Figure 13: End-to-end QoS management with 802.11e
When receiving a packet from the MN, the AP checks whether the frame
contains 802.11e markings in the L2 header. If not, the AP checks
the DSCP field. If the uplink packet contains the 802.11e marking,
the access point maps the access categories to the corresponding
802.1D priority as per the table above. If the frame does not
contain 802.11e marking, the access point examines the DSCP field.
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 29, 2014 [Page 64]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
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 Appendix A
apply. Sometimes, when communication is initiated on the WLAN
access, the application does not mark upstream packets. If the
uplink packet does not contain any QoS marking, the AP/MAG could
determine the DSCP field according to traffic selectors received from
the LMA. Figure 14 gives the call flow corresponding to that use-
case and shows where QoS tags mapping does come into play. The main
steps are as follows:
(A): during MN attachment process, the MAG fetches QoS policies
from the LMA. After this step, both MAG and LMA are provisioned
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 renegotiating the QoS rules.
(D): when receiving a marked packet, the MAG, the AP and the MN
use 802.11e (or WMM), 802.1p tags and DSCP values to prioritize
the traffic.
Liebsch, et al. Expires September 29, 2014 [Page 65]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
+--+ +--+ +---+ +---+
|MN| |AP| |MAG| |LMA|
+--+ + -+ +---+ +---+
(A)|----attach-----|---------------->|-----------PBU---------->|
|<--------------|---------------- |<----PBA[QoS option]-----|
. . [QoS rules] [QoS rules]
(B). . . |
new session | | |
|----data[]---->|----data[]------>|-======data[DSCP]======->|
| | | |
(C)| | | Validate QoS rule
| | | |--->
| | |<======data[DSCP]========|<----
| | | |
| | mapping |
(D)| | DSCP/802.1p |
| |<----data--------| |
| | [802.1p/DSCP] | |
| | | |
| mapping | |
| 802.1p/802.11e | |
|<--data[WMM]---| | |
| | | |
|---data[WMM]-->|------data------>|=======data[DSCP]=======>|--->
| | [802.1p/DSCP] | |
| | | |
Figure 14: Prioritization of a flow created on the WLAN access
Liebsch, et al. Expires September 29, 2014 [Page 66]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Appendix C. Information when implementing with a Broadband Network
Gateway
This section shows an example of QoS interworking between the PMIPv6
domain and the broadband access. The Broadband Network Gateway (BNG)
or Broadband Remote Access Server (BRAS) has the MAG function and the
CPE (Customer Premise Equipment) or Residential Gateway (RG) is
connected via the broadband access network. The MN is attached to
the RG via e.g., Wi-Fi AP in the broadband home network. In the
segment of the broadband access network, the BNG and RG are the
Policy Enforcement Point (PEP) for the downlink and uplink traffic,
respectively. The QoS information is downloaded from the LMA to the
BNG via the PMIPv6 with the QoS option defined in this document.
Based on the received QoS parameters (e.g., DSCP values), the
broadband access network and the RG provide appropriate QoS treatment
to the downlink and uplink traffic to/from the MN.
+-----+
| PDP |
+-----+
PEP |
+-------+ |
| BNG/ | PMIPv6 +-----+
| BRAS +===============| LMA |
| (MAG) | tunnel +-----+
+-------+ PEP
Broadband ( | )
Access ( DSCP )
Network ( | )
+-----+
+----+ | CPE | PEP
| MN |-------------| /RG |
+----+ Broadband +-----+
Home Network
Figure 15: End-to-end QoS management with the broadband access
network
In the segment of the broadband access network, QoS mapping between
3GPP QCI values and DSCP described in Section 6.2 is applied. In the
segment of the broadband home network, if the MN is attached to the
RG via Wi-Fi, the same QoS mapping as described in Appendix B can be
applied.
Liebsch, et al. Expires September 29, 2014 [Page 67]
Internet-Draft QoS Support for Proxy Mobile IPv6 March 2014
Authors' Addresses
Marco Liebsch
NEC
Kurfuersten-Anlage 36
Heidelberg D-69115
Germany
Email: liebsch@neclab.eu
Pierrick Seite
Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange.com
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara
Saitama, Fujimino 356-8502
Japan
Email: yokota@kddilabs.jp
Jouni Korhonen
Broadcom Communications
Porkkalankatu 24
Helsinki FIN-00180
Finland
Email: jouni.nospam@gmail.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Liebsch, et al. Expires September 29, 2014 [Page 68]
