One document matched: draft-ietf-netext-pmip-qos-wifi-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use numeric references tags -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-netext-pmip-qos-wifi-07" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="WiFi PMIPv6 QoS">
Mapping PMIPv6 QoS Procedures with WLAN QoS Procedures</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="John Kaippallimalil" initials="J.K."
surname="Kaippallimalil">
<organization>Huawei</organization>
<address>
<postal>
<street>5340 Legacy Dr., Suite 175</street>
<city>Plano</city>
<region>TX</region>
<code>75024</code>
<country>USA</country>
</postal>
<email>john.kaippallimalil@huawei.com</email>
</address>
</author>
<author fullname="Rajesh Pazhyannur" initials="R.P."
surname="Pazhyannur">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>rpazhyan@cisco.com</email>
</address>
</author>
<author fullname="Parviz Yegani" initials="P.Y."
surname="Yegani">
<organization>Juniper</organization>
<address>
<postal>
<street>1194 North Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1206</code>
<country>USA</country>
</postal>
<email>pyegani@juniper.net</email>
</address>
</author>
<date month="March" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>IETF</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>PMIPv6</keyword>
<keyword>Wi-Fi</keyword>
<keyword>QoS</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document provides guidelines for achieving 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 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, Wi-Fi Multimedia - Admission Control (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.
</t>
</abstract>
</front>
<middle>
<!-- chapter 1 ********************** -->
<section title="Introduction">
<t>PMIPv6 QoS <xref target="RFC7222"/> describes an access network independent
way to negotiate Quality-of-Service (QoS) for Proxy Mobile IPv6
(PMIPv6) mobility sessions. IEEE 802.11, Wi-Fi Multimedia (WMM),
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 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
Mobility Access Gateway (MAG) and Local Mobility Anchor (LMA)
provisions the per MN QoS policies in the MAG. Further details
on policy configuration and PCF (Policy Control Function) can be
found in <xref target="RFC7222"/>, Section 6.1.
In the IEEE 802.11 access network modeled here, the MAG is located
at the Access Point (AP)/ Wireless LAN Controller (WLC).
<xref target="figure-1"/> below provides an overview of the
entities and protocols.
</t>
<figure align="center" anchor="figure-1" title="End-to-End
QoS in Networks with IEEE 802.11 Access">
<artwork align="center"><![CDATA[
+-----+ +-------+
| AAA | | PCF |
+--+--+ +---+---+
| |
| |
+----+ +--+--------+ +---+---+
| | IEEE 802.11, WMM-AC |+-++ +---+| PMIPv6 | |
| MN <---------------------->|AP+--+MAG|<==========> LMA |
| | (ADDTS, DELTS) |+--+ +---+| QoS | |
+----+ +-----------+ +-------+
]]></artwork>
</figure>
<t>MN and Access Point 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
AG control and data planes are separate.
</t>
<t>The recommendations in this document use IEEE 802.11 QoS and PMIPv6
QoS <xref target="RFC7222"/> mechanisms. State machines for QoS policy
setup in IEEE 802.11 and PMIPv6 operate differently. Guidelines for
installing QoS in the MN using 802.11 and PMIPv6 segments, and for mapping
parameters between them are outlined below.
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="- Procedure Mapping:"><vspace blankLines="1"/>
PMIPv6 [RFC 7222] 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.
</t>
<t hangText="- Parameter Mapping:"><vspace blankLines="1"/>
There is no systematic method of mapping of specific parameters
between PMIPv6 QoS parameters and IEEE 802.11 QoS. For example,
parameters like Allocation Retention Priority (ARP) in PMIPv6 QoS
have no equivalent in IEEE 802.11.
</t>
</list>
</t>
<t>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 <xref target="table-2"/> and
DSCP to AC mapping as shown in <xref target="table-3"/>.
</t>
<t>The rest of the document is organized as follows.
<xref target="chapter-2"/> provides an overview of IEEE 802.11 QoS.
<xref target="chapter-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 <xref target="chapter-4"/>.
</t>
<!-- chapter 1.1 ********************* -->
<section title="Abbreviations">
<texttable style="none">
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<c>AAA </c><c>Authentication Authorization Accounting</c>
<c>AC </c><c>Access Category</c>
<c>ADDTS </c><c>ADD Traffic Stream</c>
<c>AIFS </c><c>Arbitration Inter-Frame Space</c>
<c>ALG </c><c>Application Layer Gateway</c>
<c>AMBR </c><c>Aggregate Maximum Bit Rate</c>
<c>ARP </c><c>Allocation and Retention Priority</c>
<c>AP </c><c>Access Point</c>
<c>CW </c><c>Contention Window</c>
<c>DELTS </c><c>DELete Traffic Stream</c>
<c>DL </c><c>DownLink</c>
<c>DSCP </c><c>Differentiated Services Code Point</c>
<c>DPI </c><c>Deep Packet Inspection</c>
<c>EDCA </c><c>Enhanced Distributed Channel Access</c>
<c>EPC </c><c>Evolved Packet Core</c>
<c>GBR </c><c>Guaranteed Bit Rate</c>
<c>MAC </c><c>Media Access Control</c>
<c>MAG </c><c>Mobility Access Gateway</c>
<c>MBR </c><c>Maximum Bit Rate</c>
<c>MN </c><c>Mobile Node</c>
<c>MSDU </c><c>Media Access Control Service Data Unit</c>
<c>PBA </c><c>Proxy Binding Acknowledgement</c>
<c>PBU </c><c>Proxy Binding Update</c>
<c>PCF </c><c>Policy Control Function</c>
<c>PHY </c><c>Physical Layer</c>
<c>QCI </c><c>QoS Class Identifier</c>
<c>QoS </c><c>Quality of Service</c>
<c>QSTA </c><c>QoS Station</c>
<c>SIP </c><c>Session Initiation Protocol</c>
<c>STA </c><c>Station</c>
<c>TC </c><c>Traffic Class</c>
<c>TCLAS </c><c>Type Classification</c>
<c>TCP </c><c>Transmission Control Protocol</c>
<c>TS </c><c>Traffic Stream</c>
<c>TSPEC </c><c>Traffic Conditioning Specification</c>
<c>UDP </c><c>User Datagram Protocol</c>
<c>UL </c><c>UpLink</c>
<c>UP </c><c>User Priority</c>
<c>WLAN </c><c>Wireless Local Area Network</c>
<c>WLC </c><c>Wireless Controller</c>
<c>WMM </c><c>Wi-Fi MultiMedia</c>
<c>WMM-AC</c><c>Wi-Fi MultiMedia Admission Control</c>
</texttable>
</section>
<!-- chapter 1.2 ********************* -->
<section title="Definitions">
<t><list style="hanging" hangIndent="4">
<t hangText="Peak Data Rate"><vspace blankLines="1"/>
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 <xref target="WMM-1.2.0"/>. IP packet including header
is included in the data rate.
<vspace blankLines="1"/>
TSPECs for both uplink and downlink may contain Peak Data Rate.
</t>
<t hangText="Mean Data Rate"><vspace blankLines="1"/>
This is the average data rate in bits per second. The Mean Data Rate
does not include the MAC and PHY overheads <xref target="WMM-1.2.0"/>.
IP packet including header is included in the data rate.
<vspace blankLines="1"/>
TSPECs for both uplink and downlink must contain the Mean Data Rate.
</t>
<t hangText="QCI"><vspace blankLines="1"/>
Quality of Service Identifier (QCI) is a scalar parameter that points to
standardized characteristics of QoS as opposed to signaling separate
parameters for resource type, priority, delay and loss
<xref target="TS23.203"/>.
</t>
<t hangText="STA"><vspace blankLines="1"/>
A station (STA) is a device that has the capability to use the
802.11 protocol. For example, a station maybe a laptop, a desktop PC,
access point or WiFi phone <xref target='IEEE-802.11'/>.
<vspace blankLines="1"/>
An STA that implements the QoS facility is a QoS Station (QSTA)
<xref target="IEEE-802.11"/>.
</t>
<t hangText="TSPEC"><vspace blankLines="1"/>
The TSPEC element in IEEE 802.11 contains the set of parameters that
define the characteristics and QoS expectations of a traffic flow
<xref target='IEEE-802.11'/>.
</t>
<t hangText="TCLAS"><vspace blankLines="1"/>
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)
<xref target="IEEE-802.11"/>.
</t>
</list>
</t>
</section>
</section>
<!-- chapter 2 ********************* -->
<section anchor="chapter-2" title="Overview of IEEE 802.11 QoS">
<t>IEEE 802.11-2012 <!--<xref target='802.11'/> --> 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 of priority): Voice, Video,
Best-Effort, Background.
The prioritized access is achieved by using access category specific
values for contention window (CW) and arbitration inter frame space (AIFS).
(Higher priority categories have smaller values for minimum and maximum
CW and AIFS).
</t>
<t>A subset of the QoS mechanisms is defined in WMM - 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. The lack of support in WMM for the TCLAS (used in identifying
an IP flow) has an impact on the QoS provisioning. The impact is described
in Chapters 3 and 4 for WMM based QoS provisioning
</t>
<t>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 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.
</t>
<t>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.
</t>
</section>
<!-- chapter 3 ********************* -->
<section anchor="chapter-3" title="Mapping QoS Procedures between IEEE 802.11 and PMIPv6">
<t>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 PMIPv6 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.
</t>
<!-- chapter 3.1 ********************* -->
<section anchor="chapter-3.1" title="MN Initiated QoS Service Request">
<t>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 Proxy Binding Update (PBU)/ Proxy Binding Acknowledgement (PBA)
sequence with QoS options exchanged with the LMA.
Details of the QoS provisioning for the flow are described below.
</t>
<!-- chapter 3.1.1 ********************* -->
<section anchor="chapter-3.1.1" title="MN Initiated QoS Reservation Request">
<t>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 exchanged with the LMA. Details of the QoS provisioning for the
flow are described below.
</t>
<figure align="center" anchor="figure-2" title="MN initiated QoS service
request">
<artwork align="center"><![CDATA[
+-----------+
+----+ |+--+ +---+| +-------+
| 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) | |
]]></artwork>
</figure>
<t>In this use case shown in <xref target="figure-2"/>,
the MN initiates the QoS service request.
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="(0)">The MN establishes a connectivity session as described in
<xref target="RFC7222"/>, 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.
</t>
<t hangText="(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 <xref target="RFC3261"/>).
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
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 attributes like Traffic Selector in PMIPv6.
In this case functionality to derive IP flow details from information
in upper layer protocols (e.g., SIP <xref target="RFC3261"/>) and
associate to subsequent QoS request may be used.
This is not described further here, but it
maybe 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). Parameter mapping in this case is shown in
<xref target="table-2"/>.
</t>
<t hangText="(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 <xref target="table-4"/>.
<vspace blankLines="1"/>
If TCLAS is not present (when WMM-AC is used), TCLAS maybe derived from
information in upper layer protocols (as described in step 1)
and populated in Traffic Selector. If TCLAS cannot be derived, the
Traffic Selector field is not included in the QoS options.
</t>
<t hangText="(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
<xref target="table-1"/>, TSPEC parameters in <xref target="table-4"/>.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
If the LMA offers downgraded QoS values to the MAG, it should send a
PBU to LMA with operational code set to DE-ALLOCATE (the LMA would
respond with PBA to confirm completion of the request).
</t>
<t hangText="(4)">The AP/MAG provisions the corresponding QoS and
replies with ADDTS Response containing authorized QoS in TSPEC and
flow identification in TSPEC and ResultCode set to SUCCESS.
<vspace blankLines="1"/>
The AP polices these flows according to the QoS provisioning.
<vspace blankLines="1"/>
If in step (3), 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:
<list style="hanging" hangIndent="2">
<t hangText="- ">for downgraded QoS from LMA, ResultCode is set to
REJECTED_WITH_SUGGESTED_CHANGES. Downgraded QoS values from LMA are
mapped to TSPEC as per <xref target="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.
</t>
<t hangText="- ">if LMA cannot meet QoS service request,
ResultCode is set to TCLAS_RESOURCES_EXHAUSTED.
</t>
</list>
<vspace blankLines="1"/>
REJECTED_WITH_SUGGESTED_CHANGES and TCLAS_RESOURCES_EXHAUSTED results
in the rejection of the QoS reservation, but does not cause the removal
of the session itself.
</t>
</list></t>
</section> <!-- end of 3.1.1. -->
<!-- chapter 3.1.2 ********************* -->
<section anchor="chapter-3.1.2" title="MN Initiated QoS De-allocation Request">
<t>QoS resources reserved for a session are released on completion of
the session. When the application session completes, the LMA, or the MN
may signal for the release of resources. In this use case shown in
<xref target="figure-3"/>, the MN initiates the release of QoS resources.
</t>
<figure align="center" anchor="figure-3" title="MN Initiated QoS resource
release">
<artwork align="center"><![CDATA[
+-----------+
+----+ |+--+ +---+| +-------+
| 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(QoS,DE-ALLOC)(3)|
| | |------------------->|Policy
| | | |<---->
| | | |Update
| | |PBA(QoS,RESPONSE)(4)|
| | |<-------------------|
| | | |
]]></artwork>
</figure>
<t><list style="hanging" hangIndent="4">
<t hangText="(0)">The MN establishes and reserves QoS resources.
When the application session terminates, the MN prepares to release
QoS resources.
</t>
<t hangText="(1)">MN releases its own internal resources and sends a
DELTS Request to the AP with TS (Traffic Stream) INFO.
</t>
<t hangText="(2)">AP receives the DELTS request, releases local
resources and responds to MN with a DELTS response.
</t>
<t hangText="(3)">MAG initiates a PBU, operational code set to
DE-ALLOCATE and with Traffic Selector constructed from TCLAS and
PMIPv6 QoS parameters from TSPEC.
<vspace blankLines="1"/>
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 Service requests are supported, then the MAG will
have at most one QoS Service request per access category (AC).
</t>
<t hangText="(4)">LMA receives the PBU and releases local resources.
The LMA then responds with a PBA.
</t>
</list></t>
<t>It should be noted that steps 3 and 4 can proceed independently of
the DELTS Response (step 2).
</t>
</section> <!-- end of 3.1.2 -->
</section> <!-- end of 3.1 -->
<!-- chapter 3.2 ********************* -->
<section anchor="chapter-3.2" title="LMA Initiated QoS Service Request">
<!-- chapter 3.2.1 ********************* -->
<section anchor="chapter-3.2.1" title="LMA Initiated QoS Reservation Request">
<t>This section describes the case when the QoS service request is
initiated by the LMA. For example an application such as voice may
request the network to initiate configuration of additional QoS policy
as in <xref target="TS23.203"/>, Section 7.4.2. 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 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 <xref target="chapter-3.1"/>)
are handled asynchronously.
</t>
<t>The PMIPv6 QoS service requests and WLAN QoS service request could
still be coordinated to provide an end to end QoS.
If the MAG receives a UPN request from the LMA to reserve QoS resources
for which it has no corresponding QoS request from the MN, the MAG may in
consultation with the 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 the AP/MAG can ensure consistency between the QoS resources
in the access network and QoS resources between the MAG and LMA.
</t>
<t>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.
</t>
</section> <!-- end of 3.2.1. -->
<!-- chapter 3.2.2 ********************* -->
<section anchor="chapter-3.2.2" title="Discussion on QoS Request Handling with IEEE 802.11aa">
<t>The network initiated QoS service request scenario poses some
challenges outlined here. IEEE 802.11-2012 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
<xref target="IEEE-802.11aa"/>(which is an amendment to IEEE 802.11-2012)
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.
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 protocol
defined understood by the MN and AP that provides a common stream
identifier to both ends. Alternately, the 802.11aa specification could
be modified to make the usage optional.
When (or if) the Stream Identifier is made optional, the TCLAS can provide
information about the traffic stream.
</t>
<t>Appendix A outlines a protocol sequence with PMIPv6 UPN/UPA if the
above 802.11aa issues can be resolved.
</t>
</section> <!-- end of 3.2.2 -->
<!-- chapter 3.2.3 ********************* -->
<section anchor="chapter-3.2.3" title="LMA Initiated QoS De-allocation Request">
<t>QoS resources reserved for a session are released on completion of
the session. When the application session completes, the LMA, or the
MN may signal for the release of resources. In this use case, the
network initiates the release of QoS resources.
</t>
<figure align="center" anchor="figure-4" title="LMA initiated QoS resource
release">
<artwork align="center"><![CDATA[
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| Establishment of application session |
| and reservation of QoS resources |
| |
| ( 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) | | |
|---------------------------->| | |
| | | |
]]></artwork>
</figure>
<t>In this use case shown in <xref target="figure-4"/>, the network
initiates the release of QoS resources.
When the application session terminates, the LMA receives notification
that the session has terminated. The LMA releases local QoS resources
associated with the flow and initiates signaling to release QoS resources
in the network.
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="(1)">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.
</t>
<t hangText="(2)">MAG replies with UPA confirming the acceptance
and operation code set to RESPONSE.
</t>
<t hangText="(3)">AP/WLC (MAG) releases local QoS resources associated
with the flow. The AP derives the corresponding 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 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.
</t>
<t hangText="(4)">MN sends DELTS Response confirming release.
</t>
</list></t>
<t>It should be noted that steps 3 and 4 can proceed independently
of the UPA (step 2).
</t>
</section> <!-- end of 3.2.3 -->
</section> <!-- end of 3.2 -->
</section> <!-- end of 3 -->
<!-- chapter 4 ********************* -->
<section anchor="chapter-4" title="Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters">
<!-- chapter 4.1 ********************* -->
<section anchor="chapter-4.1" title="Connection Parameters">
<t>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.
</t>
<t>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.
</t>
<t>QoS reservations in 802.11 are made for a traffic stream
(identified in TCLAS) and correspond to PMIPv6 QoS session parameters
(identified by Traffic Selector). PMIPv6 QoS <xref target="RFC7222"/>
specifies that when QoS-Traffic-Selector is included along with the
per-session bandwidth attributes described in <xref target="chapter-4.3"/>
below, the attributes apply at a per-session level.
</t>
<texttable anchor="table-1" title="IEEE 802.11 - PMIPv6 QoS Connection
mapping">
<ttcol align='center'>MN <--> AP(IEEE 802.11)</ttcol>
<ttcol align='center'>MAG <--> LMA (PMIPv6)</ttcol>
<c>(TCLAS Classifier 1)TCP/UDP IP</c>
<c>Traffic Selector (IP flow)</c>
<c>(TCLAS Classifier 1) DSCP</c>
<c>Traffic Class (TC)</c>
</texttable>
<t>If the MN or AP is not able to convey flow parameters in TCLAS,
the QoS reservation request in 802.11 are derived as shown in
<xref target="table-2"/>.
</t>
<texttable anchor="table-2" title="WMM - PMIPv6 QoS Connection mapping">
<ttcol align='center'>MN <--> AP(WMM)</ttcol>
<ttcol align='left'>MAG <--> LMA (PMIPv6)</ttcol>
<c>(no IP flow parameter/TCLAS)</c><c>(a) applies to all flows</c>
<c> </c><c>(b) derived out-of-band </c>
<c> </c><c> </c>
<c>User Priority (802.1D)</c><c> Traffic Class (TC)</c>
<c> </c><c>(derived using <xref target="table-3"/>)</c>
</texttable>
<t>When WMM <xref target="WMM-1.2.0"/> is used, and TCLAS is not present
to specify IP flow, one of two options apply for the MAG - LMA (PMIPv6)
segment:
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="(a)">Bandwidth parameters described in
<xref target="chapter-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. a voice flow identified by an
IP 5-tuple.
</t>
<t hangText="(b)">The IP flow for which the MN requests reservation
is derived out-of-band. For example, the AP/MAG observes application
level signaling (e.g. SIP <xref target="RFC3261"/>) or session level
signaling (e.g. 3GPP WLCP (WLAN Control Protocol)
<xref target="TS24.244"/>)and associates
subsequent ADDTS request using heuristics and then derives the
IP flow/Traffic Selector field.
</t>
</list></t>
</section> <!-- end of 4.1 -->
<!-- chapter 4.2 ********************* -->
<section anchor="chapter-4.2" title="QoS Class">
<t><xref target="table-3"/> contains a mapping between Access Class
(WMM AC) and 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) and
DSCP for use in IEEE 802.11 TSPEC and PMIPv6 QoS (Traffic Class).
Mapping of QCI to DSCP uses the tables in <xref target="GSMA-IR34"/>.
</t>
<texttable anchor="table-3" title="QoS Mapping between QCI/DSCP, 802.1D UP,
WMM AC">
<ttcol align='center'>QCI</ttcol>
<ttcol align='center'>DSCP</ttcol>
<ttcol align='center'>802.1D UP</ttcol>
<ttcol align='center'>WMM AC</ttcol>
<ttcol align='left'>Example Services</ttcol>
<c>1</c><c>EF </c><c>6(V0)</c><c>3 AC_VO</c><c>conversational</c>
<c>2</c><c>EF </c><c>6(V0)</c><c>3 AC_VO</c><c>conversational video</c>
<c>3</c><c>EF </c><c>6(V0)</c><c>3 AC_VO</c><c>real-time gaming</c>
<c>4</c><c>AF41</c><c>5(VI)</c><c>2 AC_VI</c><c>buffered streaming</c>
<c>5</c><c>AF31</c><c>4(CL)</c><c>2 AC_VI</c><c>signaling</c>
<c>6</c><c>AF32</c><c>4(CL)</c><c>2 AC_VI</c><c>buffered streaming</c>
<c>7</c><c>AF21</c><c>3(EE)</c><c>0 AC_BE</c><c>interactive gaming</c>
<c>8</c><c>AF11</c><c>1(BE)</c><c>0 AC_BE</c><c>web access</c>
<c>9</c><c>BE </c><c>0(BK)</c><c>1 AC_BK</c><c>e-mail</c>
</texttable>
<t>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.
</t>
<t>For QoS reservations, TSPEC uses WMM AC values and PMIPv6 QoS uses
corresponding DSCP values in Traffic Class (TC).
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.
</t>
<t>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). PMIPv6 QoS will not contain any flow specific
attributes like Traffic Selector.
</t>
</section> <!-- end of 4.2 -->
<!-- chapter 4.3 ********************* -->
<section anchor="chapter-4.3" title="Bandwidth">
<t>Bandwidth parameters that need to be mapped between IEEE 802.11 and
PMIPv6 QoS are shown in <xref target="table-4"/>.
</t>
<texttable anchor="table-4" title="Bandwidth Parameters for Admission
Controlled Flows">
<ttcol align='center'>MN <--> AP(IEEE 802.11)</ttcol>
<ttcol align='left'>MAG <--> LMA (PMIPv6)</ttcol>
<c>Mean Data Rate, DL</c>
<c>Guaranteed-DL-Bit-Rate</c>
<c>Mean Data Rate, UL</c>
<c>Guaranteed-UL-Bit-Rate</c>
<c>Peak Data Rate, DL</c>
<c>Aggregate-Max-DL-Bit-Rate</c>
<c>Peak Data Rate, UL</c>
<c>Aggregate-Max-UL-Bit-Rate</c>
</texttable>
<t>In PMIPv6 QoS <xref target="RFC7222"/>, 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
<xref target="TS23.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
<xref target="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
<xref target="RFC7222"/>.
</t>
<t>IEEE 802.11 TSPEC requests do not require all fields to be completed.
<xref target="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.
</t>
<t>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.
</t>
</section> <!-- end of 4.3 -->
</section> <!-- end of 4 -->
<!-- chapter 5 ********************* -->
<section anchor="chapter-5" title="Security Considerations">
<t>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 <xref target="IEEE-802.11"/> provides the means to secure
management frames that are used for ADDTS and DELTS.
PMIPv6 <xref target="RFC5213"/> specification recommends using 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.
</t>
<t>The QoS mappings themselves do not introduce additional security
concerns.
</t>
</section>
<!-- chapter 6 ********************* -->
<section anchor="chapter-6" title="IANA Considerations">
<t>No IANA assignment of parameters are required.
</t>
</section>
<!-- chapter 7 ********************* -->
<section anchor="chapter-7" title="Acknowledgements">
<t>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.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.7222.xml"?>
<?rfc include="reference.RFC.7077.xml"?>
</references>
<references title="Informative References">
<reference anchor='IEEE-802.11'>
<front>
<title> 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.
</title>
<author><organization>IEEE</organization></author>
<date day='29' month='March' year='2012' />
</front>
</reference>
<reference anchor='WMM-1.2.0'>
<front>
<title>Wi-Fi Multimedia Technical Specification
(with WMM-Power Save and WMM-Admission Control) Version 1.2.0.
</title>
<author><organization>Wi-Fi Alliance</organization></author>
<date day='07' month='May' year='2012' />
</front>
</reference>
<reference anchor="IEEE-802.11aa">
<front>
<title>Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specification, Amendment 2: MAC Enhancements for Robust Audio
Video Streaming, IEEE 802.11aa-2012.
</title>
<author><organization>IEEE</organization></author>
<date day='29' month='May' year='2012' />
</front>
</reference>
<reference anchor='GSMA-IR34'>
<front>
<title>Guidelines for IPX Provider networks (Previously
Inter-Service Provider IP Backbone Guidelines) Version 11.0
</title>
<author><organization>3GPP</organization></author>
<date day='19' month='November' year='2014' />
</front>
<seriesInfo name='GSMA Official Document' value='IR.34 v11.0'/>
<format type='PDF' target='http://www.gsma.com/newsroom/wp-content/uploads//IR.34-v11.0.pdf'/>
</reference>
<reference anchor='TS24.244'>
<front>
<title>3rd Generation Partnership Project; Technical Specification
Group Core Network and Services; Wireless LAN control plane
protocols for trusted WLAN access to EPC; Stage 3 (Release 12)
</title>
<author><organization>3GPP</organization></author>
<date month='December' year='2014' />
</front>
<seriesInfo name='3GPP TS' value='23.244 12.1.0'/>
<format type='HTML' target='http://www.3gpp.org/ftp/specs/archive/24_series/24.244/'/>
</reference>
<reference anchor='TS23.203'>
<front>
<title>3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Policy and Charging Control
Architecture (Release 13)
</title>
<author><organization>3GPP</organization></author>
<date month='December' year='2014' />
</front>
<seriesInfo name='3GPP TS' value='23.203 13.2.0'/>
<format type='HTML' target='http://www.3gpp.org/ftp/specs/archive/23_series/23.203/'/>
</reference>
<?rfc include="reference.RFC.5213.xml"?>
<?rfc include="reference.RFC.3261.xml"?>
</references>
<section anchor="appendix-A" title="LMA Initiated QoS Service Flow with IEEE 802.11aa">
<figure align="center" anchor="figure-5" title="LMA initiated QoS service
request with 802.11aa">
<artwork align="center"><![CDATA[
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+----------------------------------------------------------------+
| (0) establish connection session to 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) |
| | |----------------->|
| | | |
]]></artwork>
</figure>
<t>In this use case shown in <xref target="figure-5" />, the LMA initiates
the QoS service request and IEEE 802.11aa is used to setup QoS reservation
in the Wi-Fi segment.
</t>
<t><list style="hanging" hangIndent="4">
<t hangText="(0)">MN sets up best effort connectivity session.
This allows the MN to perform application level signaling and setup.
</t>
<t hangText="(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.
<vspace blankLines="1"/>
The LMA reserves resources for the flow requested.
</t>
<t hangText="(2)">LMA sends PMIPv6 UPN (Update Notification)
<xref target="RFC7077"/>, as outlined in <xref target="chapter-3.2.1"/>,
to the MAG with notification reason set to QOS_SERVICE_REQUEST and
acknowledgement requested flag set to value of 1.
The operational code in QoS option SHOULD be set to ALLOCATE and the
Traffic Selector identifies the flow for QoS.
<vspace blankLines="1"/>
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 separately from the
non-reserved session bandwidth.
</t>
<t hangText="(3)">If there are sufficient resources to satisfy the
request, the AP /MAG sends an ADDTS Reserve Request (IEEE 802.11aa)
specifying the QoS reserved for the traffic stream including TSPEC and
TCLAS element mapped from PMIPv6 QoS Traffic Selector to identify the flow.
<vspace blankLines="1"/>
PMIPv6 parameters are mapped to TCLAS (<xref target="table-1"/>) and
TSPEC (<xref target="table-4"/>).
If there are insufficient resources at the AP/WLC, the MAG will not
send and ADDTS message and will continue processing of step (5).
<vspace blankLines="1"/>
Higher level StreamId in IEEE 802.11aa should be encoded as discussed
in <xref target="chapter-3.2.2"/>.
</t>
<t hangText="(4)">MN accepts the QoS reserved in the network and
replies with ADDTS Reserve Response.
</t>
<t hangText="(4)">The MAG (AP/WLC) replies with UPA confirming the
acceptance of QoS options and operational code set to RESPONSE.
The AP/WLC polices flows based on the new QoS.
<vspace blankLines="1"/>
If there are insufficient resources at the AP in step (3),
the MAG sends a response with UPA status code set to
CANNOT_MEET_QOS_SERVICE_REQUEST (130).
</t>
</list>
</t>
</section>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:02:59 |