idnits 2.17.1 draft-kaippallimalil-netext-pmip-qos-wifi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 301 has weird spacing: '...ons, or tunne...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 20, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 142, but not defined == Missing Reference: 'GSMA-IR34' is mentioned on line 183, but not defined == Unused Reference: 'KEYWORDS' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC 2211' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC 2212' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC 2216' is defined on line 446, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netext-pmip6-qos-00 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Kaippallimalil 3 Intended Status: Informational Huawei 4 Expires: April 23, 2013 October 20, 2012 6 Mapping PMIP Quality of Service in WiFi Network 7 draft-kaippallimalil-netext-pmip-qos-wifi-01 9 Abstract 11 This document proposes a model for mapping PMIP QoS parameters of a 12 mobile network session to the corresponding connection at a WiFi 13 Access Point. In congested network conditions, it is possible that a 14 user's flows from the WiFi AP are metered and shaped at the WLC to 15 match the bandwidth constraints or service priority of the user's 16 subscription and PMIP QoS parameters. Applying similar QoS policing 17 at the WiFi AP allows optimal use of scarce radio network resources. 18 Currently, the WiFi AP does not have information on the MNs 19 subscribed bandwidth, or relative priority of its flows or services 20 for per user QoS handling at the WiFi AP. This document provides a 21 model for mapping PMIP QoS to corresponding 802.11e QoS parameters. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. QoS Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1 QoS in Mobile Networks . . . . . . . . . . . . . . . . . . . 4 66 2.2 QoS in WiFi Networks . . . . . . . . . . . . . . . . . . . . 5 67 3. Policy Provisioning Architecture . . . . . . . . . . . . . . . 5 68 4. Connections and QoS Mapping . . . . . . . . . . . . . . . . . . 7 69 4.1 Connection Model . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2 PMIP - 802.11e QoS Configuration . . . . . . . . . . . . . . 8 71 5. Mapping Recommendations and Default Values . . . . . . . . . . 9 72 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1 Introduction 82 This document provides a description of how the QoS profile for a 83 PMIP session maps to QoS for the corresponding 802.11 connection 84 segment of the MN (Mobile Node). When a mobile network user attaches 85 via a WiFi access, the WLC (MAG) obtains a QoS profile for each PMIP 86 session. [PMIP-QoS] proposes a mechanism by which QoS policy 87 parameters in the mobile network are delivered from the LMA to the 88 the WLC (MAG) using PMIP QoS extensions. [PMIP-QoS] further describes 89 how the DSCP value for the PMIP session is mapped to corresponding 90 802.1p value that may be used by IP backhaul network or WiFi APs to 91 prioritize IP flows of a host (MN). 93 [PMIP-QoS] outlines a model in which the QoS in PMIP flows can be 94 reflexively mapped to IP flows over 802.11 or backhaul network. The 95 WiFi AP can infer the QoS priority associated with an IP flow based 96 on the the DSCP value in the downstream packets of the PMIP flow, and 97 apply the same priority to upstream packets of the flow. It should be 98 noted that the WLC (MAG) uses DSCP priority as well as other 99 parameters of the MN such as subscribed bandwidth and service 100 priority in [PMIP-QoS] to police IP flows of the MN. In congested 101 network conditions, it is possible that upstream flows from the WiFi 102 AP are throttled by the WLC to match the bandwidth constraints or 103 service priority. This will result in sub-optimal use of network 104 resources. Currently, the WiFi AP does not have information on the 105 MNs subscribed bandwidth, or relative priority of its flows or 106 services. In addition to uneven policing between WiFi AP and WLC, 107 when the WiFi network itself is congested, the MN subscribed 108 bandwidth and service priority can be useful to schedule and use the 109 radio network resources more effectively. 111 This proposal aims to provide the WiFi AP with per MN QoS profile to 112 allow more effective overall use of network resources - both WiFi 113 radio and IP backhaul. The QoS parameters needed are available to the 114 WLC during MN authorization and establishment of the PMIP session 115 with QoS extensions. Since an MN may establish tunneled IP flows, 116 direct IP connections or offloaded connections, the relationship of 117 PMIP QoS to 802.11e QoS is explained. It is possible that an MN (with 118 a single 802.11 interface) has more than one PMIP session. The QoS 119 policy for the MN may be applied by the AP to schedule and control 120 WiFi radio network resources and upstream user flows in the IP 121 backhaul network. If per session QoS policy is not available, the AP 122 may be provisioned to apply QoS based on the subscribed QoS values 123 obtained during 3GPP user authorization. 125 In order to provision QoS in the WiFi network, a consistent mapping 126 of QoS parameters and values between 3GPP and 802.11e is needed. 127 Recommendations to map 3GPP QCI to DSCP for mobility sessions are 128 available in [PMIP-QoS]. This document adds the configuration of QoS 129 per PMIP mobility session to a WiFi radio access. 131 The rest of the document is organized as follows. Chapter 2 outlines 132 the QoS mechanisms in 3GPP mobile networks and 802.11 networks. 133 Chapter 3 provides an overview of the architecture in which QoS is 134 provisioned on the WiFi AP. Chapters 4 and 5 describe the connection 135 model in the access network and the QoS mapping itself. 137 1.1 Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 1.2 Definitions 145 1.3 Abbreviations 147 3GPP Third Generation Partnership Project 148 AAA Authentication Authorization Accounting 149 ARP Allocation and Retention Priority 150 AP Access Point 151 DSCP Differentiated Services Code Point 152 EPC Enhanced Packet Core 153 GBR Guaranteed Bit Rate 154 MAG Mobility Access Gateway 155 MBR Maximum Bit Rate 156 MN Mobile Node 157 PDN-GW Packet Data Network Gateway 158 QCI QoS Class Indicator 159 QoS Quality of Service 160 Tspec Traffic Conditioning Spec 161 WLC Wireless Controller 163 2. QoS Mechanisms 165 2.1 QoS in Mobile Networks 167 3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release 168 8 [TS 23.107]. 3GPP QoS policy configuration defines access agnostic 169 QoS parameters that can be used to provide service differentiation in 170 multi vendor and operator deployments. The concept of a bearer is 171 used as the basic construct for which the same QoS treatment is 172 applied for uplink and downlink packet flows between the MN (host) 173 and gateway [TS23.401]. A bearer may have more than one packet filter 174 associated and this is called a Traffic Flow Template (TFT). The IP 175 five tuple (IP source address, port, IP destination, port, protocol) 176 identifies a flow. 178 The access agnostic QoS parameters associated with each bearer are 179 QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), 180 MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate). QCI 181 is a scalar that defines packet forwarding criteria in the network. 182 Mapping of QCI values to DSCP is well understood and GSMA has defined 183 standard means of mapping between these scalars [GSMA-IR34]. 185 An MN may have more than one IP addresses associated with the same 186 hardware (MAC) address corresponding to each of the networks than it 187 is attached to. This corresponds to more than one PMIP mobility 188 session for which QoS is provisioned in the WLC. 190 2.2 QoS in WiFi Networks 192 802.11e [802.11e] defined by IEEE provides an enhancement of the MAC 193 layer in WiFi networks to support QoS. Basic 802.11 WiFi uses CSMA 194 and collision avoidance to provide best effort access to the medium. 195 802.11e defines a Hybrid Coordination Function (HCF) that provides a 196 priority based access and also admission control based access. 198 HCF contention based channel access provides prioritized access to 199 the 802.11 medium. Four access categories (AC) are defined based on 200 traffic type. Each arriving frame is mapped into one of four FIFO 201 queues corresponding to different user priority (UP) values. The 202 highest priority frame is transmitted when access is obtained in a 203 contention window. Access categories and their mapping to 802.1D user 204 priorities is provided [802.11e]. 206 HCF controlled channel access uses a central coordinator to provide 207 contention free access to the medium based on admission control. The 208 HCCA (HCF Controlled Channel Access) based scheduling can use 209 configured policies to grant exclusive access to a QSTA (user) for 210 limited contention free slots. 212 3. Policy Provisioning Architecture 214 This section describes the architecture in which the PMIP QoS 215 configuration of MN sessions is applied to the corresponding traffic 216 flows in the WiFi Access Point. Following MN attach to the WiFi 217 network and authentication with the mobile network, the WLC gets QoS 218 parameters and other policy for the authorized MN. When the PMIP 219 connection is created, the PDN-GW returns QoS policy using [PMIP-QoS] 220 extensions. 222 In [PMIP-QoS], the Access Point (AP) is not directly provisioned with 223 QoS for an MN connection. As a result, the AP is only able to 224 prioritize flows based on observed downlink DSCP values. 225 Additionally, the AP does not know the maximum bandwidth of a 226 subscriber or flow to be applied on the WiFi radio network. This can 227 result in sub-optimal utilization of scarce WiFi network resources, 228 and of the overall access network. This solution provides a 229 description to provision the AP with QoS policy associated to an MN. 231 The paragraphs that follow outline the overall architecture and 232 subsequent chapters provide details on QoS parameters provisioned in 233 the AP. 235 +-----+ 236 | AAA | 237 +--+--+ 238 | 239 |Auth 240 | 241 WiFi AP WLC(MAG)| 242 +----------+ +------|------+ 243 |+--------+| QoS | +----v----+ | PMIP-QoS +------+ 244 ||QoS-Ctrl<------------+QoS-Ctrl <------------+PDN-GW+ 245 |+---+----+| Policy | +----+----+ | +--+---+ 246 | | | | | | | 247 801.11 |+---v----+| _____ | +----V----+ | ________ | 248 [MN]--------+ PEP +--/ IP )---+ PEP +----/ IP ) | 249 |+--------+| Network | +---------+ | | Network|-+ 250 +----------+ ( / +-------------+ ( / 251 ----- .------. 253 Figure 1: Architecture for provisioning QoS Policy on WiFi AP 255 Figure 1 provides an overview of the architecture in which QoS for an 256 MN is provisioned on the AP. MN QoS policy from initial session 257 authorization and PMIP connection establishment is provisioned in the 258 WLC QoS-Ctrl (logical function). QoS-Ctrl in WLC installs QoS to the 259 WLC PEP as described in [PMIP-QoS]. 260 In this solution, the WLC translates the 3GPP QoS policy to 261 equivalent parameters for 802.11e and IP flows and sends them to the 262 WiFi AP. The protocols used to exchange QoS parameters between the 263 WLC and AP are not discussed in this document. The AP maps the 264 received QoS policy configuration and applies them to upstream and 265 downstream forwarding of data packets in the WiFi radio network. The 266 AP also applies these QoS policies for upstream user IP flows to the 267 WLC. The WLC should provide the AP with a policy that applies to each 268 MN (MAC address in WiFi network) and parameters per IP flow. This 269 model is described further in the following chapter. 271 4. Connections and QoS Mapping 273 4.1 Connection Model 275 MNs that attach to the mobile network have QoS policies associated to 276 the corresponding PMIP connection. This section outlines the 277 connection model for QoS mapping on the WiFi AP. 279 WiFi AP WLC(MAG) 280 +----------+ +-------------+ 281 |+--------+| | +---------+ | 282 +---+ || PEP || | + PEP + | 283 |MN | |+--------+| | +---------+ | 284 | 1 ===========================[conn-1]================[PMIP-1] 285 +---+ | | | | 286 +---+ | | | | 287 |MN +--------------------------[conn2a]---------=======[PMIP-2] 288 | 2 +--------------------------[conn2b]--------- | 289 +---+ +----------+ +------|------+ 290 V 291 [offload 292 path] 294 Figure 2: MN Connection and QoS Mapping 296 Figure 2 shows MN1 and MN2 attached to the WLC via a WiFi AP. An MN 297 may have a tunneled connection to the mobile network (MN1, conn-1, 298 PMIP-1), or an IP cpnnection to the mobile network (MN2, conn2a, 299 PMIP-2) and an IP connection that is offloaded at the WLC (MN2, 300 conn2b, offload). The connection segment between MN and WLC may be IP 301 connections, or tunneled connections such as IPSec. 303 For an MN - WLC connection segment with IP address configured via 304 PMIP (e.g. MN2 conn2a), the corresponding PMIP QoS would be 305 applicable to flows with this IP address and MAC address. 306 For tunneled connections in MN - WLC segment (e.g. MN1 conn-1), MN1 307 first gets a local IP address from the WLC. MN1 then establishes an 308 IPSec connection to the WLC and in the IKE signaling indicates 309 parameters for PMIP connection setup. The corresponding PMIP QoS 310 parameters are applicable to flows identified by local IP address, 311 port (IPSec source port at MN1) and MAC address. 312 WiFi AP may use a default QoS profile for connection flows that are 313 offloaded (e.g. MN2 conn2b in figure). 315 The WiFi AP would get QoS traffic filters corresponding to PMIP 316 flows. These flows would be identified by the tuple {MAC, IP address, 317 port}. The port field may be specified for tunneled or NATed 318 connections and wildcarded otherwise. 320 4.2 PMIP - 802.11e QoS Configuration 322 The WiFi Access Point (AP) gets QoS configuration per IP session from 323 the WLC. The QoS information per IP session provided to the AP 324 includes: 325 - Hardware (MAC) address of host for which PMIP session is 326 established. 327 - IP prefix or address of PMIP mobility session. 328 - IP port address of tunneled flow or NATed connection. 329 - DSCP. Diffserv PHB value of PMIP QoS for the mobility session. 330 - QCI. The WLC provides the 3GPP QCI value if available, for example, 331 from authorization profile of APN (i.e. subscribed values per 332 established PMIP mobility session). 333 - ARP (Allocation and Retention Priority). This value is obtained 334 from the PMIP QoS for the mobility session. It determines the 335 priority of a flow (1 has highest priority). 336 - MBR (Maximum Bit Rate) for mobility session uplink and downlink. 337 This should not exceed the AMBR (Aggregate MBR) of the 338 subscription. 339 - GBR (Guaranteed Bit Rate) for mobility session uplink and downlink, 340 if required. 342 The WiFi AP uses the above QoS configuration to implement 343 classification, admission control and forwarding of MN flows. The 344 WiFi AP maps DSCP (or QCI) to 802.11e AC (Access Categories) for each 345 IP session / hardware (MAC) address of the host (3GPP user). The 346 mapping from DSCP or QCI to 802.11e AC is shown in table in chapter 4 347 below. 349 In the WiFi radio network, the AP uses 802.11e AC values for 350 contention (HCF) based forwarding based on priority. The AP schedules 351 downstream flows in the WiFi radio network and for upstream IP 352 backhaul to the WLC. For contention free scheduling (based on HCCA), 353 the WiFi AP additionally uses the QoS configuration per user to 354 admit flows based on 802.11e ADDTS (ADD TSpec) requests from the host 355 (3GPP user). The WiFi AP may drops packet that fall outside the 356 configured MBR and GBR. In case of severe radio congestion, the WiFi 357 AP can use ARP in addition to DSCP drop precedence to determine the 358 flows to be dropped. 360 5. Mapping Recommendations and Default Values 362 The table below outlines a recommended mapping between 3GPP QCI, 363 and 802.11e Access Category (AC) priorities. QCI packet delay budget 364 and packet error loss rate may be used by the WiFi access point in 365 scheduling contention free access when HCCA scheduling is used. 367 QCI DSCP 802.11e AC Example 3GPP service 368 ------------------------------------------------------------- 369 1 EF 3 AC_VO conversational voice 370 2 EF 3 AC_VO conversational video 371 3 EF 3 AC_VO real-time gaming 372 4 AF41 2 AC_VI buffered streaming 373 5 AF31 2 AC_VI IMS signaling 374 6 AF31 2 AC_VI buffered streaming 375 7 AF21 0 AC_BE interactive gaming 376 8 AF11 0 AC_BE web access 377 9 BE 1 AC_BK e-mail 379 Table 1: QoS Mapping between QCI, WMM, 802.11e AC 381 6. Next Steps 383 This document has described a basic model for mapping PMIP QoS 384 parameters to 802.11e parameters. However, there are a few questions 385 that need to be explored further. 387 The draft that the protocol between WLC and AP is not considered 388 further here. There needs to be some work to determine the protocol 389 parameters and other details if it is desired that WLC and AP should 390 interwork. 391 Another aspect is this draft does not describe multiple PDN 392 connections per MN in much detail. This is work in progress in 3GPP 393 and the results should be compatible with the model in this draft. 394 RTC Web flows introduce cases where the same IP flow (5-tuple) can 395 have multiple DSCP values - for example when the IP flow carries 396 audio and video applications. This would impact the QCI and DSCP 397 parameters of IP flows, but this is not only this description that is 398 affected. A 399 Finally, the QoS values listed in the table in chapter 5 needs to be 400 aligned with [PMIP-QoS] and GSMA. 402 7. Security Considerations 404 This document describes mapping of 3GPP QoS profile and parameters to 405 IEEE 802.11e parameters. No security concerns are expected as a 406 result of using this mapping. 408 8. IANA Considerations 410 No IANA assignment of parameters are required in this document. 412 9. References 414 9.1 Normative References 416 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 420 1 1995. 422 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 423 April 1 1996. 425 9.2 Informative References 427 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 428 RFC 3514, April 1 2003. 430 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 431 Acronyms", RFC 5513, April 1 2009. 433 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 434 2009. 436 [PMIP-QoS] Liebsch, et al., "Quality of Service Option for Proxy 437 Mobile IPv6", draft-ietf-netext-pmip6-qos-00, June 2012. 439 [RFC 2211] Wroclawski, J., "Specification of the Controlled Load 440 Quality of Service", RFC 2211, September 1997. 442 [RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 443 of Guaranteed Quality of Service", RFC 2212, September 444 1997. 446 [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS 447 Control Service Specification Template", RFC 2216, 448 September 1997. 450 [TS23.107] Quality of Service (QoS) Concept and Architecture, Release 451 10, 3GPP TS 23.107, V10.2.0 (2011-12). 453 [TS23.207] End-to-End Quality of Service (QoS) Concept and 454 Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011- 455 03). 457 [TS23.401] General Packet Radio Service (GPRS) enhancements for 458 Evolved Universal Terrestrial Radio Access Network (E- 459 UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 460 06). 462 [TS23.203] Policy and Charging Control Architecture, Release 11, 3GPP 463 TS 23.203, V11.2.0 (2011-06). 465 [TS29.212] Policy and Charging Control over Gx/Sd Reference Point, 466 Release 11, 3GPP TS 29.212, V11.1.0 (2011-06). 468 [802.11e] IEEE, "IEEE part 11: Wireless LAN Medium Access 469 Control(MAC) and Physical Layer (PHY) specifications. 470 Amendment 8: Medium Access Control (MAC) Quality of 471 Service Enhancements" 802.11e-2005, 22 September 2005. 473 [GSMA-IR34]Inter-Service Provider Backbone Guidelines 5.0, 22 474 December 2010 476 Authors' Addresses 478 John Kaippallimalil 479 5340 Legacy Drive, Suite 175 480 Plano Texas 75024 482 E-Mail: john.kaippallimalil@huawei.com