NETEXT WG John Kaippallimalil
Internet-Draft Huawei
Intended Status: Informational Rajesh S. Pazhyannur
Expires: January 4, 2015 Cisco
Parviz Yegani
Juniper
July 3, 2014
Mapping PMIPv6 QoS Procedures with WLAN QoS procedures
draft-ietf-netext-pmip-qos-wifi-01
Abstract
This document provides guidelines for achieving end to end QoS in a
PMIPv6 domain where the access network is based on IEEE 802.11.
RFC 7222 describes QoS negotiation between a MAG and 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, WMM-AC describes
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 QoS.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Kaippallimalil, et al. Expires January 4, 2015 [Page 1]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . . 5
3. Mapping QoS Signaling procedures between IEEE 802.11 and
PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. MN Initiated QoS Service Request . . . . . . . . . . . . . 6
3.1.1. MN Initiated QoS Service Request . . . . . . . . . . . 6
3.1.2. MN Initiated QoS De-allocation Request . . . . . . . . 8
3.2. LMA Initiated QoS Service Request . . . . . . . . . . . . . 10
3.2.1. LMA Initiated QoS Reservation Request . . . . . . . . . 10
3.2.2. LMA Initiated QoS De-allocation Request . . . . . . . . 10
4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters . . . 12
4.1 Connection Parameters . . . . . . . . . . . . . . . . . . . 12
4.2 QoS Class . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Kaippallimalil, et al. Expires January 4, 2015 [Page 2]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
1. Introduction
[RFC 7222] describes an access network independent way to negotiate
QoS for PMIPv6 mobility sessions. IEEE 802.11, WMM, WMM-AC describes
ways to provide QoS for Wi-Fi traffic between the STA and AP. This
document describes how QoS can be implemented in a network where the
access network is based on IEEE 802.11 (Wi-Fi). This requires a
mapping between QoS procedures and information elements in two
segments 1) Wi-Fi segment and 2) PMIPv6 segment (see Figure 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 MAG and LMA provisions
the per MN QoS policies in the MAG. In the IEEE 802.11 access network
modeled here, the MAG is located at the Access Point (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
MN and AP use IEEE 802.11 QoS mechanisms to setup QoS flows in the
Wi-Fi segment. The MAG and LMA setup QoS flows using PMIPv6 QoS
procedures. The protocols and mechanisms between AP and MAG are out
of scope of this document. Some implementations may have AP and MAG
in the same network node. However, this document does not exclude
various deployments including those where AP and WLC are separate
nodes, or the MAG control and data planes are separate.
The recommendations in this document for IEEE 802.11 accesses
supplement RFC 7222 specifically as outlined below.
- Procedure Mapping:
PMIPv6 defined procedures for QoS setup maybe triggered by the LMA
or MAG. IEEE 802.11 QoS setup on the other hand is always
triggered by the MN (IEEE 802.11 QSTA). The end-to-end QoS setup
across these network segments should accommodate both network
triggered and end-user triggered QoS.
Kaippallimalil, et al. Expires January 4, 2015 [Page 3]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
- 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 ARP in PMIPv6 QoS have no equivalent in IEEE
802.11.
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. Terminology
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].
1.2. Definitions
Peak Data Rate
In WMM, Peak Data Rate specifies the maximum data rate in bits
per second. The Maximum Data Rate does not include the MAC and
PHY overheads [WMM 1.2.0].
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 [WMM1.2.0]
Minimum Data Rate
In WMM, Minimum Data Rate specifies the minimum data rate in bits
per second. The Minimum Data Rate does not include the MAC and
PHY overheads [WMM 1.2.0].
TSPEC
The TSPEC element in IEEE 802.11 contains the set of parameters
that define the characteristics and QoS expectations of a traffic
flow.
TCLAS
The TCLAS element specifies an element that contains a set of
parameters necessary to identify incoming MSDU (MAC Service Data
Unit) that belong to a particular TS (Traffic Stream) [802.11-
2012].
1.3. Abbreviations
AAA Authentication Authorization Accounting
Kaippallimalil, et al. Expires January 4, 2015 [Page 4]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
AMBR Aggregate Maximum Bit Rate
ARP Allocation and Retention Priority
AP Access Point
DSCP Differentiated Services Code Point
EPC Enhanced Packet Core
GBR Guaranteed Bit Rate
MAG Mobility Access Gateway
MBR Maximum Bit Rate
MN Mobile Node
QCI QoS Class Indicator
QoS Quality of Service
TCLAS Type Classification
TSPEC Traffic Conditioning Spec
WLC Wireless Controller
2. Overview of IEEE 802.11 QoS
IEEE 802.11-2012 defines a way of providing prioritized access for
different traffic classes (video, voice, 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): Voice, Video, Best-Effort, Background. The
prioritized access is achieved by using access category specific
values for contention window (CW) and arbitration inter frame service
(AIFS). (Higher priority categories have smaller values for minimum
and maximum CW and AIFS.). WMM is a Wi-Fi Alliance certification of
support for a set of features from an 802.11e draft (now part of IEEE
802.11). This certification is for both clients and APs, and
certifies the operation of WMM. WMM is primarily the implementation
of the EDCA component of 802.11e. WMM uses the 802.1P classification
scheme developed by the IEEE (which is now a part of the 802.1D
specification). The 802.1P classification scheme has eight
priorities, which WMM maps to four access categories: AC_BK, AC_BE,
AC_VI, and AC_VO.
IEEE 802.11 also defines a way a (non-AP) STA can request QoS 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 only after being successfully admitted.
WMM-AC is a Wi-Fi Alliance certification of support for admission
control based on a set of features in IEEE 802.11.
The QoS signaling in IEEE 802.11-2012 is initiated by the (non-AP)
STA (by sending an ADDTS request). This specification references
procedures in IEEE 802.11-2012, WMM and WMM-AC.
Kaippallimalil, et al. Expires January 4, 2015 [Page 5]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
3. Mapping QoS Signaling procedures between IEEE 802.11 and PMIPv6
There are two main types of interaction possible to provision QoS for
flows that require 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 PMIP QoS
request. In the second scenario, the LMA can push the QoS
configuration to the MAG. However, there are no standards defined way
for the AP to initiate a QoS service request to the MN.
Recommendations to setup QoS in both these cases are described in
this section.
3.1. MN Initiated QoS Service Request
3.1.1. MN Initiated QoS Service 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 PMIPv6
PBU/PBA sequence with QoS options with the LMA. Details of the QoS
provisioning for the flow are described below.
Kaippallimalil, et al. Expires January 4, 2015 [Page 6]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| [0] establish connection session to mobile network |
+-------------------------------------------------------------+
| | | |
+-------------+ | | |
|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 QoS service request
[0] The MN establishes a connectivity session as described in [RFC
7222], section 3.1, MAG-initiated QoS service request, steps 1-
4. At this point, a connection with PMIPv6 tunnel is established
to the LMA. This allows the MN to start application level
signaling.
[1] The trigger for MN to request QoS is an upper layer
notification. This may be the result of end-to-end application
signaling and setup procedures (e.g. SIP).
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, the PMIPv6 QoS shall not
contain any flow specific attributes like Traffic Selector.
Thus, with WMM-AC, only a single reservation per access category
(AC) is possible.
Kaippallimalil, et al. Expires January 4, 2015 [Page 7]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
The TSPECs for both uplink and downlink in this request should
contain the Mean Data Rate and and may contain Peak Data Rate.
[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 and Traffic Selector identifying the flow. The Traffic
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 3.
[3] The LMA obtains the authorized QoS for the flow and responds to
the MAG with operational code set to RESPONSE. Mapping of PMIPv6
to IEEE 802.11 TCLAS is shown in Table 1, TSPEC parameters in
Table 3.
Reserved bandwidth for flows are accounted separately from the
non-reserved session bandwidth. The Traffic Selector identifies
the flow for which the QoS reservations are made.
[4] The AP/MAG provisions the corresponding QoS and replies with
ADDTS Response containing authorized QoS in TSPEC and flow
identification in TSPEC.
The AP polices these flows according to the QoS provisioning.
3.1.2. 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 policy
server, or the MN may signal for the release of resources. In this
use case, the network initiates the release of QoS resources.
Kaippallimalil, et al. Expires January 4, 2015 [Page 8]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| [0] Establishment of application session |
| and reservation of QoS resources |
| |
| ( Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | |
| DELTS Request (TS INFO)[1] | | |
|---------------------------->| | |
| |---->| |
| |<----| |
| DELTS Response (TS INFO)[2] | | |
|<----------------------------| | |
| | |PBU(QoSx,DE-ALLOC)[3]
| | |------------------->|Policy
| | | |<---->
| | | |Update
| | |PBA(QoSx,RESPONSE)[4]
| | |<-------------------|
| | | |
Figure 3: Network initiated QoS resource release
[0] The MN establishes and reserves QoS resources.
When the application session terminates, the MN prepares to
release QoS resources.
[1] MN releases its own internal resources and sends a DELTS Request
to the AP with TS (Traffic Stream) INFO.
[2] AP receives the DELTS request, releases local resources and
responds to MN with a DELTS response.
[3] MAG initiates a PBU with Traffic Selector constructed from TCLAS
and PMIPv6 QoS parameters from TSPEC (QoSx).
When TLCAS 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 QoS Services requested are
supported, then the MAG will have at most one QoS Service
Kaippallimalil, et al. Expires January 4, 2015 [Page 9]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
request per access category (AC).
[4] LMA receives the PBU, releases local resources and informs
policy server. The LMA then responds with a PBA.
3.2. LMA Initiated QoS Service Request
3.2.1. LMA Initiated QoS Reservation Request
This section describes the case when the QoS service request is
initiated by the LMA (see RFC 7222 for further details). In the
current WLAN specifications, there are no standards 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 cannot 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 QoS. If the MN
initiates WMM-AC procedures after the completion of PMIPv6 QoS
procedures the 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 based on previous PMIPv6 QoS procedures. If the MN
subsequently requests for data rates of x Mbps or less, the AP can
accept it 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 the QoS resource and
ask for increased QoS resources or the AP should reject the QoS
request.
3.2.2. 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 policy
server, or the MN may signal for the release of resources. In this
use case, the network initiates the release of QoS resources.
Kaippallimalil, et al. Expires January 4, 2015 [Page 10]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| [0] Establishment of application session |
| and reservation of QoS resources |
| |
| ( Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | | Policy
| | | |<------
| | |UPN(QoSx,DE-ALLOC) | [1]
| | |<------------------|
| |<----| [2] |
| |---->|UPA(QoSx,RESPONSE) |
| | |------------------>|
| | | [3] |
| | | |
| DELTS Request (TS INFO)[4] | | |
|<----------------------------| | |
| DELTS Response (TS INFO)[5] | | |
|---------------------------->| | |
| | | |
Figure 5: LMA initiated QoS resource release
[0] The MN establishes and reserves QoS resources as in use cases A,
B or C.
When the application session terminates, the policy server
receives notification that the session has terminated.
[1] LMA receives a policy update indicating that QoS for flow (QoSx)
should be released. The LMA releases local resources associated
with the flow.
[2] LMA sends a UPN with QoS options identifying the flow for which
QoS resources are to be released, and operation code set to DE-
ALLOCATE. No additional LMA QoS parameters are sent.
[3] MAG replies with UPA confirming the acceptance and operation
code set to RESPONSE.
[4] AP/WLC (MAG) releases local QoS resources associated with the
flow. The AP derives the corresponding Access Category from the
Kaippallimalil, et al. Expires January 4, 2015 [Page 11]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
DSCP 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 map the Traffic Selector into a TCLAS
element. In the case where the AP does not support TCLAS (for
example a WMM-AC compliant AP) then the AP shall only use the
Access Category. The AP sends a DELTS Request with TS INFO
identifying the reservation.
[5] MN sends DELTS Response confirming release.
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). 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 flow and the Traffic Selector is given
below.
+------------------------------+------------------------------+
| MN <--> AP(IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+------------------------------+------------------------------+
| (TCLAS) TCP/UDP IP | Traffic Selector (IP flow) |
| (TCLAS) |User Priority | DSCP |
+------------------------------+------------------------------+
Table 1: IEEE 802.11 - PMIPv6 QoS Connection mapping
If the MN or AP is not able to convey flow parameters in TCLAS,
the AP should use out of band methods to determine the IP flow for
which QoS is requested. This may include higher level connection
setup signaling (e.g., WCS in [TS23.402]).
4.2 QoS Class
Table 2 contains a mapping between Access Class (WMM AC) and
802.1D in IEEE 802.11 frames, and DSCP in IP data packets. The
table also provides the mapping between Access Class (WMM AC) and
DSCP for use in IEEE 802.11 TSPEC and PMIPV6 QoS reservations.
Kaippallimalil, et al. Expires January 4, 2015 [Page 12]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
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
Table 2: QoS Mapping between QCI/DSCP, 802.1D UP, WMM AC
The MN tags all data packets with DSCP and 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 values and PMIPV6 QoS uses
corresponding DSCP values in Traffic Selector. IEEE 802.11 QoS Access
Class AC_VO, AC_VI are used for QoS reservations. AC_BE, 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 DSCP / access category
(AC). PMIPv6 QoS will not contain any flow specific attributes like
Traffic Selector.
4.3 Bandwidth
Bandwidth parameters that need to be mapped between IEEE 802.11 and
PMIP QoS are shown in Table 3.
Table 3 shows the mapping of bandwidth parameters.
+-------------------------+------------------------------+
| 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 3: Bandwidth Parameters for Admission Controlled Flows
Kaippallimalil, et al. Expires January 4, 2015 [Page 13]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
In PMIPV6 QoS, services using a sending rate smaller than or equal
to Guaranteed Bit Rate (GBR) can in general assume that congestion
related packet drops will not occur [TS 23.203]. 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 [WMM 1.2.0] 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
and it is recommended that it be mapped to the GBR parameters,
Guaranteed-DL-Bit-Rate and Guaranteed-UL-Bit-Rate in PMIPV6 QoS.
IEEE 802.11 TSPEC requests do not require all fields to be
completed. [WMM 1.2.0] specifies a list of TSPEC parameters that
are required in the specification. Peak Data Rate is not required
in 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, 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 ADDTS 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 in PMIPV6 QoS.
5. Security Considerations
This document describes mapping of PMIPv6 QoS parameters to IEEE
802.11 QoS parameters. No security concerns need to be addressed
as a result of this mapping.
6. IANA Considerations
No IANA assignment of parameters are required.
7. Acknowledgements
The authors of this document 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.
Kaippallimalil, et al. Expires January 4, 2015 [Page 14]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7222] Liebsch, et al., "Quality of Service Option for Proxy
Mobile IPv6", RFC 7222, May 2014.
[RFC 5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
5226, May 2008.
8.2. Informative References
[802.11-2012] 802.11-2012 - IEEE Standard for Information Technology-
-Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications
[WMM 1.2.0] Wi-Fi Multimedia Technical Specification (with WMM-
Power Save and WMM-Admission Control) Version 1.2.0
[GSMA-IR34] Inter-Service Provider Backbone Guidelines 5.0, 22
December 2010
[TS23.402] Architecture Enhancements for non-3GPP accesses(Release
12), 3GPP TS 23.402, V12.2.0 (2013-09).
[TS23.203] Policy and Charging Control Architecture, Release 11,
3GPP TS 23.203, V11.2.0 (2011-06).
[RFC 2211] Wroclawski, J., "Specification of the Controlled Load
Quality of Service", RFC 2211, September 1997.
[RFC 2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS
Control Service Specification Template", RFC 2216,
September 1997.
Authors' Addresses
Kaippallimalil, et al. Expires January 4, 2015 [Page 15]
Internet-Draft Mapping PMIPv6 QoS with 802.11 QoS July 3, 2014
John Kaippallimalil
5340 Legacy Drive, Suite 175
Plano, Texas 75024
E-Mail: john.kaippallimalil@huawei.com
Rajesh Pazhyannur
170 West Tasman Drive
San Jose, CA 95134
E-Mail: rpazhyan@cisco.com
Parviz Yegani
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
E-Mail: pyegani@juniper.net
Kaippallimalil, et al. Expires January 4, 2015 [Page 16]