IETF
1;2c.
Internet Engineering Task Force (IETF) J. Kaippallimalil
Internet-Draft
Request for Comments: 7561 Huawei
Intended status:
Category: Informational R. Pazhyannur
Expires: October 12, 2015
ISSN: 2070-1721 Cisco
P. Yegani
Juniper
April 10,
June 2015
Mapping PMIPv6 QoS Quality of Service (QoS) Procedures with
of Proxy Mobile IPv6 (PMIPv6) and WLAN QoS Procedures
draft-ietf-netext-pmip-qos-wifi-08
Abstract
This document provides guidelines for achieving end to end Quality-
of-Service end-to-end Quality of
Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access
network is based on IEEE 802.11. RFC 7222 describes QoS negotiation
between a Mobility Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA)
in a PMIPv6 mobility domain. The negotiated QoS parameters can be
used for QoS policing and marking of packets to enforce QoS
differentiation on the path between the MAG and LMA. IEEE 802.11-2012, 802.11 and
Wi-Fi Multimedia - Admission Control (WMM-AC)
describes describe methods for
QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology)
and an Access Point. This document provides a mapping between the
above two sets of QoS procedures and the associated QoS parameters.
This document is intended to be used as a companion document to RFC
7222 to enable implementation of end to end end-to-end QoS.
Status of This Memo
This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a maximum candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2015.
http://www.rfc-editor.org/info/rfc7561.
Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 7
3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 . . . . 7
3.1. MN Initiated MN-Initiated QoS Service Request . . . . . . . . . . . . 8
3.1.1. MN Initiated MN-Initiated QoS Reservation Request . . . . . . . . 8
3.1.2. MN Initiated MN-Initiated QoS De-allocation Request . . . . . . . 10 11
3.2. LMA Initiated LMA-Initiated QoS Service Request . . . . . . . . . . . . 12
3.2.1. LMA Initiated LMA-Initiated QoS Reservation Request . . . . . . . . 12
3.2.2. Discussion on QoS Request Handling with IEEE 802.11aa 13
3.2.3. LMA Initiated LMA-Initiated QoS De-allocation Request . . . . . . . 13 14
4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters . . 15
4.1. Connection Parameters . . . . . . . . . . . . . . . . . . 15
4.2. QoS Class . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations References . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.
6.2. Informative References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . .
Appendix A. LMA-Initiated QoS Service Flow with IEEE 802.11aa . 21
Acknowledgements . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. LMA Initiated QoS Service Flow with IEEE 802.11aa . 20 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 23
1. Introduction
PMIPv6 QoS [1] describes an access network independent access-network-independent way to
negotiate Quality-of-Service Quality of Service (QoS) for Proxy Mobile IPv6 (PMIPv6)
mobility sessions. IEEE 802.11, Wi-Fi Multimedia (WMM), and Wi-Fi
Multimedia - Admission Control (WMM-AC) describe ways to provide QoS
for Wi-Fi traffic between the Wi-Fi Station (STA) and Access Point
(AP). This document describes how QoS can be implemented in a
network where the access network is based on IEEE 802.11 (Wi-Fi). It
requires a mapping between QoS procedures and information elements in
two segments segments: 1) the Wi-Fi segment and 2) the PMIPv6 segment (see segment. (See
Figure 1). 1.) The recommendations here allow for dynamic QoS policy
information per Mobile Node (MN) and session to be configured by the
IEEE 802.11 access network. PMIPv6 QoS signaling between Mobility the Mobile
Access Gateway (MAG) and Local Mobility Anchor (LMA) provisions the per MN
per-MN QoS policies in the MAG. Further details on policy
configuration and PCF
(Policy the Policy Control Function) Function (PCF) can be found in
[1], Section 6.1. In the IEEE 802.11 access network modeled here,
the MAG is located at the
Access Point (AP)/ AP / Wireless LAN Controller (WLC).
Figure 1 below provides an overview of the entities and protocols.
+-----+ +-------+
| AAA | | PCF |
+--+--+ +---+---+
| |
| |
+----+ +--+--------+ +---+---+
| | IEEE 802.11, WMM-AC |+-++ +---+| PMIPv6 | |
| MN <---------------------->|AP+--+MAG|<==========> LMA |
| | (ADDTS, DELTS) |+--+ +---+| QoS | |
+----+ +-----------+ +-------+
Figure 1: End-to-End QoS in Networks with IEEE 802.11 Access
The MN and Access Point AP (AP) use IEEE 802.11 QoS mechanisms to setup set up
QoS flows in the Wi-Fi segment. The MAG and LMA setup set up QoS flows
using PMIPv6 QoS procedures. The protocols and mechanisms between
the AP and MAG are out of outside the scope of this document. Some
implementations may have the AP and MAG in the same network node.
However, this document does not exclude various deployments including
those where in which the AP and WLC are separate nodes, nodes or in which the MAG
control and data planes are separate.
The recommendations in this document use IEEE 802.11 QoS and PMIPv6
QoS [1] mechanisms. mechanisms [1]. State machines for QoS policy setup in IEEE
802.11 and PMIPv6 operate differently. Guidelines for installing QoS
in the MN using IEEE 802.11 and PMIPv6 segments, segments and for mapping
parameters between them are outlined below.
- Procedure Mapping:
PMIPv6 [RFC 7222] defined
PMIPv6-defined procedures for QoS setup maybe setup, as specified in [1], may
be triggered by the LMA or MAG. IEEE 802.11 QoS setup setup, on the
other
hand hand, is always triggered by the MN (IEEE 802.11 QSTA). QoS
Station (QSTA)). The end-
to-end end-to-end QoS setup across these network
segments should accommodate
both network triggered and end-user QoS that is triggered QoS. by the network
or by the end user.
- Parameter Mapping:
There is no systematic method of mapping of specific parameters
between PMIPv6 QoS parameters and IEEE 802.11 QoS. For example,
parameters like Allocation and Retention Priority (ARP) (AARP) in
PMIPv6 QoS have no equivalent in IEEE 802.11.
The primary emphasis of this specification is to handle the
interworking between WMM-AC signaling/procedures and PMIPv6 QoS
signaling/procedures. When the client does not support WMM-AC, then
the AP/MAG uses the connection mapping in Table 2 and DSCP to AC DSCP-to-AC
mapping as shown in Table 3.
The rest of the document is organized as follows. Section 2 provides
an overview of IEEE 802.11 QoS. Section 3 describes a mapping of QoS
signaling procedures between IEEE 802.11 and PMIPv6. The mapping of
parameters between IEEE 802.11 and PMIPv6 QoS is described in
Section 4.
1.1. Abbreviations
AAA Authentication Authorization Authentication, Authorization, and Accounting
AARP Allocation and Retention Priority
AC Access Category
ADDTS ADD Traffic Stream
AIFS Arbitration Inter-Frame Space
ALG Application Layer Gateway
AMBR Aggregate Maximum Bit Rate
ARP Allocation and Retention Priority
AP Access Point
CW Contention Window
DELTS DELete Traffic Stream
DL DownLink
DSCP Differentiated Services Code Point
DPI Deep Packet Inspection
EDCA Enhanced Distributed Channel Access
EPC Evolved Packet Core
GBR Guaranteed Bit Rate
MAC Media Access Control
MAG Mobility Mobile Access Gateway
MBR Maximum Bit Rate
MN Mobile Node
MSDU Media Access Control Service Data Unit
PBA Proxy Binding Acknowledgement
PBU Proxy Binding Update
PCF Policy Control Function
PHY Physical Layer
QCI QoS Class Identifier
QoS Quality of Service
QSTA QoS Station
SIP Session Initiation Protocol
STA Station
TC Traffic Class
TCLAS Type Classification
TCP Transmission Control Protocol
TS Traffic Stream
TSPEC Traffic Conditioning Specification
UDP User Datagram Protocol
UL UpLink
UP User Priority
WLAN Wireless Local Area Network
WLC Wireless Controller
WMM Wi-Fi MultiMedia
WMM-AC Wi-Fi MultiMedia Admission Control
1.2. Definitions
Peak Data Rate
In WMM, WMM-AC, Peak Data Rate specifies the maximum data rate in bits
per second. The Maximum Data Rate does not include the MAC and
PHY overheads [4]. Data rate includes the transport of the IP
packet including header is included in the
data rate. and header.
TSPECs for both uplink and downlink may contain Peak Data Rate.
Mean Data Rate
This is the average data rate in bits per second. The Mean Data
Rate does not include the MAC and PHY overheads [4]. Data rate
includes the transport of the IP packet
including header is included in the data rate. and header.
TSPECs for both uplink and downlink must contain the Mean Data
Rate.
Mimimum
Minimum Data Rate
In WMM, WMM-AC, Minimum Data Rate specifies the minimum data rate in
bits per second. The Minimum Data Rate does not include the MAC
and PHY overheads [4]. Data rate includes the transport of the IP
packet including header is included in the
data rate. and header.
Minimum Data Rate is not used in QoS provisioning as it is
described here.
QCI
Quality of Service
The QoS Class Identifier (QCI) is a scalar parameter that points
to standardized characteristics of QoS as opposed to signaling
separate parameters for resource type, priority, delay delay, and loss
[8].
STA
A station (STA) is a device that has the capability to use the
IEEE 802.11 protocol. For example, a station maybe a laptop, a
desktop PC, an access point point, or WiFi a Wi-Fi phone [3].
An STA that implements the QoS facility is a QoS Station (QSTA)
[3].
TSPEC
The TSPEC element in IEEE 802.11 contains the set of parameters
that define the characteristics and QoS expectations of a traffic
flow [3].
TCLAS
The TCLAS element specifies an element that contains a set of
parameters necessary to identify incoming MSDU MSDUs (MAC Service Data
Unit)
Units) that belong to a particular TS (Traffic Stream) [3].
2. Overview of IEEE 802.11 QoS
IEEE 802.11-2012 802.11 defines a way of providing prioritized access for
different traffic classes (video, voice, etc) etc.) by a mechanism called
EDCA (Enhanced Distributed Channel Access). The levels of priority
in EDCA are called access categories (ACs) and there are four levels
(in decreasing order of priority): Voice, Video, Best-Effort, and
Background. The prioritized Prioritized access is achieved by using access
category specific AC-specific
values for contention window Contention Window (CW) and arbitration
inter frame space Arbitration Inter-Frame Space
(AIFS). (Higher priority (Higher-priority categories have smaller values for minimum
and maximum CW and AIFS). AIFS.)
A subset of the QoS mechanisms is defined in WMM - -- a Wi-Fi Alliance
certification of support for a set of features from an IEEE 802.11e
draft (now part of IEEE 802.11). This certification is for both
clients and APs, APs and certifies the operation of WMM. WMM is primarily
the implementation of the EDCA component of IEEE 802.11e. WMM uses
the IEEE 802.1P classification scheme developed by the IEEE (which is
now a part of the 802.1D specification). The IEEE 802.1P
classification scheme has eight priorities, which WMM maps to four
access categories: AC_BK, AC_BE, AC_VI, and AC_VO. The lack of
support in WMM for the TCLAS (used in identifying an IP flow) has an
impact on the QoS provisioning. The impact on WMM-based QoS
provisioning is described in Chapters Sections 3 and 4 for WMM
based QoS provisioning. 4.
IEEE 802.11 defines the way a (non-AP) STA can request QoS to be
reserved for an access category. Correspondingly, the AP can
determine whether to admit or deny the request depending on the
available resources. Further, the AP may require that Admission
Control is mandatory for an access category. In such a case, the STA
is expected to use the AC access category only after being successfully
admitted. WMM-AC is a Wi-Fi Alliance certification of support for admission
control
Admission Control based on a set of features in IEEE 802.11.
The QoS signaling in IEEE 802.11-2012 802.11 is initiated by the (non-AP) STA (by
sending an ADDTS request). This specification references procedures
in IEEE 802.11-2012, WMM 802.11, WMM, and WMM-AC.
3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6
There are two main types of interaction possible to provision QoS for
flows that require admission control - Admission Control -- one where the MN initiates
the QoS request and the network provisions the resources. The second
is where the network provisions resources as a result of a PMIPv6 QoS
request. In the second scenario, the LMA can push the QoS
configuration to the MAG. However, there are is no standards defined standard way for the
AP to initiate a QoS service request to the MN. Recommendations to setup
set up QoS in both these cases are described in this section.
3.1. MN Initiated MN-Initiated QoS Service Request
3.1.1. MN Initiated MN-Initiated QoS Reservation Request
This procedure outlines the case where the MN is configured to start
the QoS signaling. In this case, the MN sends an ADDTS request
indicating the QoS required for the flow. The AP/MAG obtains the
corresponding level of QoS to be granted to the flow by using the
PMIPv6 PBU/
PBA PBU/PBA sequence with that contains the QoS options exchanged with
the LMA. Details of the QoS provisioning for the flow are described provided
below.
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) establish connection session to with mobile network |
+-------------------------------------------------------------+
| | | |
+-------------+ | | |
|upper layer
|upper-layer | | | |
|notification | | | |
+-+-+-+-+-+-+-+ | | |
| | | |
| ADDTS Request(TCLAS(opt),TSPEC),AC| |
|---------------------------->| | |
| (1) |---->|PBU(QoS options)(2)|
| | |------------------>|
| | | | Policy
| | |PBA(QoS option)(3) |<----->
| | |<------------------|
| |<----| |
|ADDTS Response(TCLAS(opt),TSPEC),AC| |
|<----------------------------| | |
| (4) | |
Figure 2: MN initiated MS-Initiated QoS service request Service Request
In this the use case shown in Figure 2, the MN initiates the QoS service
request.
(0) The MN establishes a connectivity session as described in [1],
Section 3.1, MAG-initiated QoS service request, steps 1-4. 1-4 of Use
Case 2 (MAG-Initiated QoS Service Request) in Section 3.1 of [1].
At this point, a connection with a PMIPv6 tunnel is established
to the LMA. This allows the MN to start application level application-level
signaling.
(1) The trigger for the MN to request QoS is an upper layer upper-layer
notification. This may be the result of end-to-end application
signaling and setup procedures (e.g. (e.g., SIP [10]).
Since the MN is configured to start QoS signaling, it sends an
ADDTS request with TSPEC and TCLAS identifying the flow for which
QoS is requested.
It should be noted that WMM-AC specifications do not contain
TCLAS. When TCLAS is not present, there is no direct way to
derive flow specific flow-specific attributes like Traffic Selector in PMIPv6.
In this case case, functionality to derive IP flow details from
information in upper layer upper-layer protocols (e.g., SIP [10]) and
associate to them with a subsequent QoS request may be used. This
is not described further here, but it maybe may be functionality in an
Application Layer Gateway (ALG) or Deep Packet Inspection (DPI).
It should be noted that an ALG or DPI can increase the complexity
of the AP/MAG implementation and affect its scalability. If no
TCLAS is derived, the reservation applies to all flows of the MN
(not desired). MN.
Parameter mapping in this case is shown in Table 2.
(2) If there are sufficient resources at the AP/WLC to satisfy the
request, the MAG sends a PBU with QoS options, operational code
ALLOCATE Operational Code
ALLOCATE, and the Traffic Selector identifying the flow. The
Traffic
selector Selector is derived from the TCLAS to identify the flow
requesting QoS. IEEE 802.11 QoS parameters in TSPEC are mapped
to PMIPv6 parameters. The mapping of TCLAS to PMIPv6 is shown in
Table 1. TSPEC parameter mapping is shown in Table 4.
If TCLAS is not present (when WMM-AC is used), TCLAS maybe may be
derived from information in upper layer upper-layer protocols (as described
in step 1) and populated in the Traffic Selector. If TCLAS
cannot be derived, the Traffic Selector field is not included in
the QoS options.
(3) The LMA obtains the authorized QoS for the flow and responds to
the MAG with operational code Operational Code set to RESPONSE. Mapping of PMIPv6
to IEEE 802.11 TCLAS is shown in Table 1, and mapping of TSPEC
parameters is shown in Table 4.
Reserved bandwidth for flows are accounted is calculated separately from the
non-reserved session bandwidth. The Traffic Selector identifies
the flow for which the QoS reservations are made.
If the LMA offers downgraded QoS values to the MAG, it should
send a PBU to the LMA with operational code Operational Code set to DE-ALLOCATE (the DE-ALLOCATE.
(The LMA would respond with PBA to confirm completion of the request).
request.)
(4) The AP/MAG provisions the corresponding QoS and replies with
ADDTS Response containing authorized QoS in TSPEC and TSPEC, the flow
identification in TSPEC TSPEC, and ResultCode set to SUCCESS.
The AP polices these flows according to the QoS provisioning.
If in
In step (3), 3, if the LMA sends a downgraded QoS or a PBA message
with status code CANNOT_MEET_QOS_SERVICE_REQUEST (179), then the
AP should respond to the MN with ADDTS Response and ResultCode
set as follows:
- for downgraded QoS from LMA, ResultCode is set to
REJECTED_WITH_SUGGESTED_CHANGES. Downgraded QoS values from
LMA are mapped to TSPEC as per Table 4. This is still a
rejection, but the MN may revise the QoS to a lower level and
repeat this sequence if the application can adapt.
- if LMA cannot meet the QoS service request, ResultCode is set
to TCLAS_RESOURCES_EXHAUSTED.
Either REJECTED_WITH_SUGGESTED_CHANGES and or
TCLAS_RESOURCES_EXHAUSTED results in the rejection of the QoS
reservation, but it does not cause the removal of the session
itself.
3.1.2. MN Initiated MN-Initiated QoS De-allocation Request
QoS resources reserved for a session are released on completion of
the session. When the application session completes, the LMA, LMA or the
MN may signal for the release of resources. In this the use case shown in
Figure 3, the MN initiates the release of QoS resources.
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) Establishment of application session |
| and reservation of QoS resources |
| |
| ( Session (Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | |
| DELTS Request (TS INFO)(1) | | |
|---------------------------->| | |
| |---->| |
| |<----| |
| DELTS Response (TS INFO)(2) | | |
|<----------------------------| | |
| | |PBU(QoS,DE-ALLOC)(3)|
| | |------------------->|Policy
| | | |<---->
| | | |Update
| | |PBA(QoS,RESPONSE)(4)|
| | |<-------------------|
| | | |
Figure 3: MN Initiated MN-Initiated QoS resource release Resource Release
(0) The MN establishes and reserves QoS resources. When the
application session terminates, the MN prepares to release QoS
resources.
(1) The MN releases its own internal resources and sends a DELTS
Request to the AP with TS (Traffic Stream) INFO.
(2) The AP receives the DELTS request, releases local resources resources, and
responds to the MN with a DELTS response.
(3) The MAG initiates a PBU, operational code with the Operational Code set to DE-ALLOCATE
DE-ALLOCATE, and with the Traffic Selector constructed from TCLAS
and PMIPv6 QoS parameters from TSPEC.
When TLCAS TCLAS is not present, the MAG should de-allocate all flows
with the same access category (AC) as indicated in the DELTS Request.
In the typical case, if the client does not support TCLAS and
only MN initiated MN-initiated QoS Service requests are supported, then the
MAG will have at most one QoS Service request per access
category (AC).
category.
(4) LMA receives the PBU and releases local resources. The LMA then
responds with a PBA.
It should be noted that steps 3 and 4 can proceed independently of
the DELTS Response (step 2).
3.2. LMA Initiated LMA-Initiated QoS Service Request
3.2.1. LMA Initiated LMA-Initiated QoS Reservation Request
This section describes the case when the QoS service request is
initiated by the LMA. For example example, an application such as voice may
request the network to initiate configuration of additional QoS
policy as in [8], Section 7.4.2. In the current WLAN specifications,
there are is no standards defined standard-defined way for the AP to initiate a QoS service
request to the MN. As a result, when the MAG receives a QoS request
from the LMA, it does not have any standard mechanisms to initiate
any QoS requests to the MN over the access network. Given this, the
PMIPv6 QoS service requests and any potential WLAN service requests
(such as described in Section 3.1) are handled asynchronously.
The PMIPv6 QoS service requests and WLAN QoS service request could
still be coordinated to provide an end to end end-to-end QoS. If the MAG
receives a UPN an Update Notification (UPN) request from the LMA to reserve
QoS resources for which it has no corresponding QoS request from the
MN, the MAG may may, in consultation with the AP AP, provision a policy that
can grant a subsequent QoS request from the MN. If the MN initiates
QoS procedures after the completion of PMIPv6 QoS procedures procedures, the AP/MAG AP/
MAG can ensure consistency between the QoS resources in the access
network and QoS resources between the MAG and LMA.
For example, if the MN is requesting a mean data rate of x Mbps, the
AP and MAG can ensure that the rate can be supported on the network
between MAG-LMA MAG and LMA based on previous PMIPv6 QoS procedures. If the
MN subsequently requests for data rates of x Mbps or less, the AP can
accept it a request based on the earlier PMIPv6 QoS provisioning. For
the case where there is a mismatch, i.e., the network does not
support the x Mbps, then either the MAG should re-negotiate renegotiate the QoS
resource and ask for increased QoS resources or the AP should reject
the QoS request.
3.2.2. Discussion on QoS Request Handling with IEEE 802.11aa
The network initiated network-initiated QoS service request scenario poses some
challenges outlined here. IEEE 802.11-2012 802.11 does not provide any
mechanisms for the AP to initiate a QoS request. As a result, the
AP/MAG cannot explicitly make any reservations in response to a QoS
reservation request made using UPN. IEEE 802.11aa [5](which [5] (which is an
amendment to IEEE 802.11-2012) 802.11) has a mechanism that enables the AP to ask
the client to reserve QoS for a traffic stream. It does this via the
ADDTS Reserve Request. The ADDTS Reserve Request contains a TSPEC,
an optional TCLAS, and a mandatory Stream Identifier. stream identifier. The
specification does not describe how the AP would obtain such a stream
identifier. As a result, there needs to be a new higher layer higher-layer
protocol defined that is understood by the MN and AP and that
provides a common stream identifier to both ends. Alternately, the
IEEE 802.11aa specification could be modified to make the usage
optional. When (or if) the Stream Identifier stream identifier is made optional, the
TCLAS can provide information about the traffic stream.
Appendix A outlines a protocol sequence with PMIPv6 UPN/UPA UPN / Update
Notification Acknowledgement (UPA) if the above IEEE 802.11aa issues
can be resolved.
3.2.3. LMA Initiated LMA-Initiated QoS De-allocation Request
QoS resources reserved for a session are released on completion of
the session. When the application session completes, the LMA, LMA or the
MN may signal for the release of resources. In this use case, the
network initiates the release of QoS resources.
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| Establishment of application session |
| and reservation of QoS resources |
| |
| ( Session (Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | | Policy
| | | |<------
| | |UPN(QoS,DE-ALLOC) |
| | |<------------------|
| |<----| (1) |
| |---->|UPA(QoS,RESPONSE) |
| | |------------------>|
| | | (2) |
| | | |
| DELTS Request (TS INFO)(3) | | |
|<----------------------------| | |
| DELTS Response (TS INFO)(4) | | |
|---------------------------->| | |
| | | |
Figure 4: LMA initiated LMA-Initiated QoS resource release Resource Release
In this the use case shown in Figure 4, the network initiates the release
of QoS resources. When the application session terminates, the LMA
receives notification of that the session has terminated. event. The LMA releases local QoS
resources associated with the flow and initiates signaling to release
QoS resources in the network.
(1) The LMA sends a UPN with QoS options identifying the flow for
which QoS resources are to be released, released and operation code Operational Code set
to DE-
ALLOCATE. DE-ALLOCATE. No additional LMA QoS parameters are sent.
(2) The MAG replies with a UPA confirming the acceptance and operation code
Operational Code set to RESPONSE.
(3) The AP/WLC (MAG) releases local QoS resources associated with the
flow. The AP derives the corresponding Access Category access category from the
Traffic Class (TC) field provided in the QoS option. In
addition, if the AP supports TCLAS and the QoS option contains a
Traffic Selector field, then the AP SHALL shall map the Traffic
Selector into a TCLAS element. In the case where the AP does not
support TCLAS (for example a WMM-AC example, an AP compliant AP) with WMM-AC), then
the AP
SHALL shall only use the Access Category. access category. The AP sends a DELTS
Request with TS INFO identifying the reservation.
(4) The MN sends DELTS Response confirming release.
It should be noted that steps 3 and 4 can proceed independently of
the UPA (step 2).
4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters
4.1. Connection Parameters
TSPEC in IEEE 802.11 is used to reserve QoS for a traffic stream (MN
MAC, TS(Traffic Stream) id). TS ID). The IEEE 802.11 QoS reservation is for IEEE 802.11
frames associated with an MN's MAC address.
The TCLAS element with Classifier 1 (TCP/UDP Parameters) is used to
identify a PMIPv6 QoS flow. We should note that WMM-AC procedures do
not support TCLAS. When TCLAS is present, a one-to-one mapping
between the TCLAS defined TCLAS-defined flow and the Traffic Selector is given
below.
QoS reservations in IEEE 802.11 are made for a traffic stream
(identified in TCLAS) and correspond to PMIPv6 QoS session parameters
(identified by the Traffic Selector). PMIPv6 QoS [1] specifies that
when QoS-
Traffic-Selector QoS-Traffic-Selector is included along with the per-session
bandwidth attributes described in Section 4.3 below, the attributes
apply at a per-session level.
+--------------------------------+----------------------------+
| MN <--> AP(IEEE AP (IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+--------------------------------+----------------------------+
| (TCLAS Classifier 1)TCP/UDP IP | Traffic Selector (IP flow) |
| (TCLAS Classifier 1) DSCP | Traffic Class (TC) |
+--------------------------------+----------------------------+
Table 1: IEEE 802.11 - PMIPv6 QoS Connection mapping Mapping
If the MN or AP is not able to convey flow parameters in TCLAS, the
QoS reservation request in IEEE 802.11 are is derived as shown in
Table 2.
+------------------------------+--------------------------+
| MN <--> AP(WMM) AP (WMM) | MAG <--> LMA (PMIPv6) |
+------------------------------+--------------------------+
| (no IP flow parameter/TCLAS) | (a) applies to all flows |
| | (b) derived out-of-band |
| | |
| User Priority (802.1D) | Traffic Class (TC) |
| | (derived using Table 3) |
+------------------------------+--------------------------+
Table 2: WMM - PMIPv6 QoS Connection mapping Mapping
When WMM [4] is used, and TCLAS is not present to specify IP flow,
one of two options apply for the MAG - LMA (PMIPv6) segment:
(a) Bandwidth parameters described in Section 4.3 apply to all flows
of the MN. This is not a preferred mode of operation if the LMA
performs reservation for a single flow, e.g. e.g., a voice flow
identified by an IP 5-tuple.
(b) The IP flow for which the MN requests reservation is derived out-
of-band. For example, the AP/MAG observes application level application-level
signaling (e.g. (e.g., SIP [10]) or session level session-level signaling (e.g. (e.g., 3GPP
WLCP (WLAN Control Protocol) [7])and [7]), associates subsequent ADDTS
request
requests using heuristics heuristics, and then derives the IP flow/Traffic flow / Traffic
Selector field.
4.2. QoS Class
Table 3 contains a mapping between Access Class (WMM AC) access category (AC) and IEEE
802.1D User Priority (UP) tag in IEEE 802.11 frames, and DSCP in IP
data packets. The table also provides the mapping between Access Class
(WMM AC) AC and
DSCP for use in IEEE 802.11 TSPEC and PMIPv6 QoS (Traffic Class).
Mapping of QCI to DSCP uses the tables in [6].
+-----+------+-----------+---------+----------------------+
| QCI | DSCP | 802.1D UP | WMM AC | Example Services |
+-----+------+-----------+---------+----------------------+
| 1 | EF | 6(VO) | 3 AC_VO | conversational voice |
| 2 | EF | 6(VO) | 3 AC_VO | conversational video |
| 3 | EF | 6(VO) | 3 AC_VO | real-time gaming |
| 4 | AF41 | 5(VI) | 2 AC_VI | buffered streaming |
| 5 | AF31 | 4(CL) | 2 AC_VI | signaling |
| 6 | AF32 | 4(CL) | 2 AC_VI | buffered streaming |
| 7 | AF21 | 3(EE) | 0 AC_BE | interactive gaming |
| 8 | AF11 | 1(BE) | 0 AC_BE | web access |
| 9 | BE | 0(BK) | 1 AC_BK | e-mail email |
+-----+------+-----------+---------+----------------------+
Table 3: QoS Mapping between QCI/DSCP, 802.1D UP, WMM AC
The MN tags all data packets with DSCP and IEEE 802.1D UP
corresponding to the application and the subscribed policy or
authorization. The AP polices sessions and flows based on the
configured QoS policy values for the MN.
For QoS reservations, TSPEC uses WMM AC WMM-AC values and PMIPv6 QoS uses
corresponding DSCP values in Traffic Class (TC). IEEE 802.11 QoS
Access Class AC_VO, Category AC_VO and AC_VI are used for QoS reservations. AC_BE, AC_BE
and AC_BK should not be used in reservations.
When WMM-AC specifications that do not contain TCLAS are used, it is
only possible to have one reservation per Traffic Class / access
category (AC).
category. PMIPv6 QoS will not contain any flow specific flow-specific attributes
like Traffic Selector.
4.3. Bandwidth
Bandwidth parameters that need to be mapped between IEEE 802.11 and
PMIPv6 QoS are shown in Table 4.
+-------------------------+---------------------------+
| MN <--> AP(IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+-------------------------+---------------------------+
| Mean Data Rate, DL | Guaranteed-DL-Bit-Rate |
| Mean Data Rate, UL | Guaranteed-UL-Bit-Rate |
| Peak Data Rate, DL | Aggregate-Max-DL-Bit-Rate |
| Peak Data Rate, UL | Aggregate-Max-UL-Bit-Rate |
+-------------------------+---------------------------+
Table 4: Bandwidth Parameters for Admission Controlled Admission-Controlled Flows
In PMIPv6 QoS [1], services using a sending rate smaller than or
equal to the Guaranteed Bit Rate (GBR) can assume, in general assume general, that
congestion related
congestion-related packet drops will not occur [8]. If the rate
offered by the service exceeds this threshold, there are no
guarantees provided. IEEE 802.11 radio networks do not offer such a
guarantee, but [4] notes that the application (service) requirements
are captured in TSPEC by the MSDU (MAC Service Data Unit) and Mean
Data Rate. The TSPEC should contain Mean Data Rate Rate, and it is
recommended that it be mapped to the GBR parameters, Guaranteed-DL-
Bit-Rate and Guaranteed-UL-Bit-Rate in PMIPv6 QoS [1].
IEEE 802.11 TSPEC requests do not require all fields to be completed.
[4] specifies a list of TSPEC parameters that are required in the
specification. Peak Data Rate is not required in WMM, however WMM; however, for
MNs and APs that are capable of specifying the Peak Data Rate, it
should be mapped to MBR (Maximum Bit Rate) in PMIPv6 QoS. The AP
should use the MBR parameters, parameters Aggregate-Max-DL-Bit-Rate and
Aggregate-Max-UL-Bit-Rate to police these flows on the backhaul
segment between MAG and LMA.
During the QoS reservation procedure, if the MN requests Mean Data
Rate, or Peak Data Rate in excess of values authorized in PMIPv6 QoS,
the AP should deny the request in an ADDTS Response. response. The AP may set
the reject cause code to REJECTED_WITH_SUGGESTED_CHANGES and send a
revised TSPEC with Mean Data Rate and Peak Data Rate set to
acceptable GBR and MBR respectively MBR, respectively, in PMIPv6 QoS.
5. Security Considerations
This document describes mapping of PMIPv6 QoS parameters to IEEE
802.11 QoS parameters. Thus, the security in the WLAN and PMIPv6
signaling segments and the functional entities that map the two
protocols need to be considered. 802.11-2012 IEEE 802.11 [3] provides the means
to secure management frames that are used for ADDTS and DELTS. The
PMIPv6 [9] specification [9] recommends using IPSec IPsec and IKEv2 to secure
protocol messages. The security of the node(s) that implement the
QoS mapping functionality should be considered in actual deployments.
The QoS mappings themselves do not introduce additional security
concerns.
6. IANA Considerations
No IANA assignment of parameters are required.
7. Acknowledgements
The authors thank the NetExt Working Group for the valuable feedback
to different versions of this specification. In particular, the
authors wish to thank Sri Gundavelli, Rajeev, Koodli, Georgios
Karagianis, Kent Leung, Marco Liebsch, Basavaraj Patil, Pierrick
Seite, Hidetoshi Yokota for their suggestions and valuable input.
The authors also thank George Calcev, Mirko Schramm, Mazin Shalash
and Marco Spini for detailed input on parameters and scheduling in
IEEE 802.11 and 3GPP radio networks.
8. References
8.1.
6.1. Normative References
[1] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S.
Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6",
RFC 7222, DOI 10.17487/RFC7222, May 2014. 2014,
<http://www.rfc-editor.org/info/rfc7222>.
[2] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J.
Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, DOI 10.17487/RFC7077, November 2013.
8.2. 2013,
<http://www.rfc-editor.org/info/rfc7077>.
6.2. Informative References
[3] IEEE, "802.11-2012 - IEEE "IEEE Standard for Information Technology -
Telecommunications and information exchange between systems -
Local and metropolitan area networks- networks - Specific requirements
Part 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications.",
March 2012. Specifications", IEEE Standard 802.11.
[4] Wi-Fi Alliance, "Wi-Fi Multimedia Technical Specification (with
WMM-Power Save and WMM-Admission Control) Control)", Version
1.2.0.", 1.2.0, May
2012.
[5] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specification, Amendment 2: MAC Enhancements for
Robust Audio Video Streaming, Streaming", IEEE
802.11aa-2012.", May 2012. 802.11aa.
[6] 3GPP, "Guidelines for IPX Provider networks (Previously
Inter-Service Provider IP Backbone Guidelines) Version
11.0", Guidelines)", GSMA Official
Document IR.34 v11.0, November 2014. 2014,
<http://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v11.0.pdf>.
[7] 3GPP, "3rd Generation Partnership Project; Technical "Technical Specification Group Core Network and Services;
Wireless LAN control plane protocols for trusted WLAN access to
EPC; Stage 3 (Release 12)", 3GPP TS 23.244 12.1.0, December 2014.
2014, <http://www.3gpp.org/ftp/specs/archive/24_series/24.244/>.
[8] 3GPP, "3rd Generation Partnership Project; Technical "Technical Specification Group Services and System
Aspects; Policy and Charging Control Architecture (Release 13)",
3GPP TS 23.203 13.2.0, December 2014. 2014,
<http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
[9] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213,
DOI 10.17487/RFC5213, August 2008. 2008,
<http://www.rfc-editor.org/info/rfc5213>.
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261,
June 2002. 2002, <http://www.rfc-editor.org/info/rfc3261>.
Appendix A. LMA Initiated LMA-Initiated QoS Service Flow with IEEE 802.11aa
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+----------------------------------------------------------------+
| (0) establish connection session to with mobile network |
+----------------------------------------------------------------+
| | | |
| | | | Policy
| | | |<----------
| | |UPN(QoS opt(2) | Update(1)
| ADDTS Reserve Request | |<-----------------|
| (TCLAS, TSPEC)(3) |<----| |
|<-------------------------| | |
| ADDTS Reserve Response | | |
| (TCLAS, TSPEC)(4) | | |
|------------------------->| | |
| |---->|UPA(QoS opt)(5) |
| | |----------------->|
| | | |
Figure 5: LMA initiated LMA-Initiated QoS service request Service Request with 802.11aa
In this the use case shown in Figure 5, the LMA initiates the QoS service
request and IEEE 802.11aa is used to setup set up the QoS reservation in
the Wi-
Fi Wi-Fi segment.
(0) The MN sets up best effort connectivity a best-effort session. This allows the MN to
perform application level application-level signaling and setup.
(1) The policy server sends a QoS reservation request to the LMA.
This is usually sent in response to an application that requests
the policy server for higher QoS for some of its flows.
The LMA reserves resources for the flow requested.
(2) The LMA sends a PMIPv6 UPN (Update Notification) [2], as outlined
in Section 3.2.1, to the MAG with notification reason Notification Reason set to
QOS_SERVICE_REQUEST and acknowledgement requested Acknowledgement Requested flag set to
value of 1.
The operational code Operational Code in the QoS option SHOULD be is set to
ALLOCATE ALLOCATE, and
the Traffic Selector identifies the flow for QoS.
The LMA QoS parameters include Guaranteed-DL-Bit-Rate/Guaranteed-
UL-Bit-Rate and Aggregate-Max-DL-Bit-Rate/Aggregate-Max-UL-Bit-
Rate for the flow. The reserved bandwidth for flows are
accounted is
calculated separately from the non-reserved session bandwidth.
(3) If there are sufficient resources to satisfy the request, the AP
/MAG AP/
MAG sends an ADDTS Reserve Request (IEEE 802.11aa) specifying the
QoS reserved for the traffic stream stream, including the TSPEC and
TCLAS
element elements mapped from the PMIPv6 QoS Traffic Selector to
identify the flow.
PMIPv6 parameters are mapped to TCLAS (Table 1) and TSPEC
(Table 4). If there are insufficient resources at the AP/WLC,
the MAG will not send and an ADDTS message and will continue the
processing of step (5).
Higher level StreamId 5.
The higher-level stream identifier in IEEE 802.11aa should be
encoded as discussed in Section 3.2.2.
(4) MN accepts the QoS reserved in the network and replies with ADDTS
Reserve Response.
(4)
(5) The MAG (AP/WLC) replies with a UPA confirming the acceptance of
QoS options and operational code Operational Code set to RESPONSE. The AP/WLC
polices flows based on the new QoS.
If there are insufficient resources at the AP in step (3), 3, the MAG
sends a response with UPA status code set to
CANNOT_MEET_QOS_SERVICE_REQUEST (130).
Acknowledgements
The authors thank the NETEXT Working Group for the valuable feedback
to different versions of this specification. In particular, the
authors wish to thank Sri Gundavelli, Georgios Karagianis, Rajeev
Koodli, Kent Leung, Marco Liebsch, Basavaraj Patil, Pierrick Seite,
and Hidetoshi Yokota for their suggestions and valuable input. The
authors also thank George Calcev, Mirko Schramm, Mazin Shalash, and
Marco Spini for detailed input on parameters and scheduling in IEEE
802.11 and 3GPP radio networks.
Authors' Addresses
John Kaippallimalil
Huawei
5340 Legacy Dr., Suite 175
Plano, TX 75024
USA
Email:
United States
EMail: john.kaippallimalil@huawei.com
Rajesh Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email:
United States
EMail: rpazhyan@cisco.com
Parviz Yegani
Juniper
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Email:
United States
EMail: pyegani@juniper.net