idnits 2.17.1 draft-kaippallimalil-netext-pmip-qos-wifi-03.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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 14, 2013) is 3847 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 134, but not defined == Missing Reference: 'GSMA-IR34' is mentioned on line 195, but not defined -- Looks like a reference, but probably isn't: '0' on line 408 -- Looks like a reference, but probably isn't: '2' on line 415 -- Looks like a reference, but probably isn't: '3' on line 418 -- Looks like a reference, but probably isn't: '1' on line 413 -- Looks like a reference, but probably isn't: '4' on line 421 -- Looks like a reference, but probably isn't: '5' on line 425 -- Looks like a reference, but probably isn't: '6' on line 429 == Unused Reference: 'KEYWORDS' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC 2211' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'RFC 2212' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC 2216' is defined on line 647, 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 (==), 9 comments (--). 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 17, 2014 Rajesh S. Pazhyannur 5 Cisco 6 Parviz Yegani 7 Juniper 8 October 14, 2013 10 Mapping Wi-Fi QoS in a PMIPv6 Mobility Domain 11 draft-kaippallimalil-netext-pmip-qos-wifi-03 13 Abstract 15 This document provides a specification to enable end to end QoS in 16 networks containing a Wi-Fi network coupled with a PMIPv6 mobility 17 domain consisting of a local mobility anchor and mobility access 18 gateway. This enables QoS policing and labeling of packets in a 19 consistent manner on the 802.11 link between the MN and the AP as 20 well as the link between the MAG and the LMA. To enable this, the 21 document specifies mapping between QoS parameters on the 802.11 link 22 and the QoS Mobility options in the PMIPv6 domain. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. QoS in 3GPP based Networks . . . . . . . . . . . . . . . . 4 68 2.2. QoS in PMIPv6 Mobility domain . . . . . . . . . . . . . . . 5 69 2.3. QoS in IEEE 802.11 based Networks . . . . . . . . . . . . . 5 70 3. End-to-End QoS with Admission Control . . . . . . . . . . . . . 6 71 3.1. Case A: MN Initiated QoS Signaling . . . . . . . . . . . . 6 72 3.2. Case B: Network Initiated QoS Signaling (802.11aa based) . 7 73 3.3. Case C: Hybrid (Network Initiated for PMIPv6 and MN 74 initiated for Wi-Fi) . . . . . . . . . . . . . . . . . . . 9 75 3.4. Mapping of Connection Parameters . . . . . . . . . . . . . 10 76 3.5. Service Guarantees in 802.11 . . . . . . . . . . . . . . . 11 77 4. End-to-End QoS without Admission Control . . . . . . . . . . . 11 78 4.1. Default Values and Recommendations . . . . . . . . . . . . 13 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Appendix A: QoS Policy Architecture . . . . . . . . . . . . . . . 16 87 1. Introduction 89 The deployment network considered here is where there is a Wi-Fi 90 access link coupled with a PMIPv6 mobility domain. A MAG is co- 91 located with the Access Point (AP) and in cases where the Wi-Fi 92 network consists of Access Point and a Wireless LAN Controller (WLC), 93 we assume that the MAG is located either at the AP or the WLC. 94 Additionally, the Wi-Fi access network may be part of a 3GPP network. 95 In such a case, the per user QoS Policy may be provided from the 3GPP 96 network. Specifically, the 3GPP network may provision QoS during 97 authorization of the user, and may also dynamically provision QoS for 98 individual flows. [TS23.402] [TS23.273] describe the initial 99 authorization and download of user profile, including QoS profile. In 100 this specification we describe how end to end QoS may be 101 established: spanning the access domain (Wi-Fi access network) and 102 the PMIPv6 mobility domain between the MAG and the LMA. A key 103 question from an end to end QoS standpoint is how QoS policies on the 104 Wi-Fi access link is mapped to QoS in the PMIPv6 mobility domain and 105 further to 3GPP QoS policies for per user/per flow. 107 [PMIP-QoS] defines a QoS option to enable QoS in the PMIPv6 mobility 108 domain. The sub-options defined in the QoS option are mapped into 109 corresponding parameters in the 3GPP specified QoS parameters. [PMIP- 110 QoS] does not explicitly describe how the QoS signaling and QoS sub- 111 options map into corresponding signaling and parameters in the Wi-Fi 112 access network. This mapping is the focus of this document. The key 113 distinction between [PMIP-QoS] and this document is that this focuses 114 on the end-to-end flow (spanning 802.11 access and PMIPv6 domain) 115 while [PMIP-QoS] focuses on the QoS within the PMIPv6 mobility 116 domain. This document provides a systematic way to map to the various 117 QoS parameters available in initial authorization, as well as setup 118 of new sessions (such as a voice/video call). The mapping 119 recommendations allow for proper provisioning and consistent 120 interpretation between the various QoS parameters provided by PMIP 121 QoS, 3GPP and 802.11. 123 The rest of the document is organized as follows. Chapter 2 provides 124 an overview of the QoS mechanisms in 3GPP mobile networks and 802.11 125 networks. Chapter 3 describes different ways how end to end QoS with 126 Wi-Fi admission control is achieved. Chapter 4 describes how end to 127 end QoS without admission control is achieved. 129 1.1. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 1.2. Definitions 137 Guaranteed Bit Rate (GBR) 138 GBR in 3GPP mobile network defines the guaranteed (reserved) bit 139 rate resources of service data flow on a connection (bearer) 140 [TS23.203]. 142 Aggregate Maximum Bit Rate (AMBR) 143 AMBR represents the total bandwidth that all flows of a user is 144 allowed. 146 Allocation Retention Priority (ARP) 147 ARP is used in the mobile network to determine the order in which 148 resources for a flow may be preempted during severe congestion or 149 other resource limitation. ARP of 1 is the highest priority while 150 15 is the lowest [TS23.203]. 152 Mean Data Rate 153 In WMM, Mean Data Rate specifies the average data rate in bits 154 per second. The Mean Data Rate does not include the MAC and PHY 155 overheads [WMM 1.2.0]. 157 1.3. Abbreviations 159 3GPP Third Generation Partnership Project 160 AAA Authentication Authorization Accounting 161 AMBR Aggregate Maximum Bit Rate 162 ARP Allocation and Retention Priority 163 AP Access Point 164 DSCP Differentiated Services Code Point 165 EPC Enhanced Packet Core 166 GBR Guaranteed Bit Rate 167 MAG Mobility Access Gateway 168 MBR Maximum Bit Rate 169 MN Mobile Node 170 PDN-GW Packet Data Network Gateway 171 QCI QoS Class Indicator 172 QoS Quality of Service 173 Tspec Traffic Conditioning Spec 174 WLC Wireless Controller 176 2. Background 178 2.1. QoS in 3GPP based Networks 179 3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release 180 8 [TS 23.107]. 3GPP QoS policy configuration defines access agnostic 181 QoS parameters that can be used to provide service differentiation in 182 multi vendor and operator deployments. The concept of a bearer is 183 used as the basic construct for which the same QoS treatment is 184 applied for uplink and downlink packet flows between the MN (host) 185 and gateway [TS23.402]. A bearer may have more than one packet filter 186 associated and this is called a Traffic Flow Template (TFT). The IP 187 five tuple (IP source address, port, IP destination, port, protocol) 188 identifies a flow. 190 The access agnostic QoS parameters associated with each bearer are 191 QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), 192 MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate). QCI 193 is a scalar that defines packet forwarding criteria in the network. 194 Mapping of QCI values to DSCP is well understood and GSMA has defined 195 standard means of mapping between these scalars [GSMA-IR34]. 197 In a 3GPP radio network, priority and packet delay budget in QCI 198 determines the policy used for rate-shaping, scheduling and queue 199 management. The ARP is used to determine if a connection session 200 request should be allowed (e.g. insufficient radio resource) and the 201 order in which flows should be pre-empted in case of severe 202 congestion. 204 An MN may have more than one IP addresses associated with the same 205 hardware (MAC) address corresponding to each of the networks than it 206 is attached to. This corresponds to more than one PMIP mobility 207 session for which QoS is provisioned in the WLC. 209 2.2. QoS in PMIPv6 Mobility domain 211 [PMIP-QoS] defines a mobility option that can be used by the mobility 212 entities in the Proxy Mobile IPv6 domain to exchange Quality of 213 Service parameters associated with a subscriber's IP flows. Using the 214 QoS option, the local mobility anchor and the mobile access gateway 215 can exchange available QoS attributes and associated values. This 216 enables QoS policing and labeling of packets to enforce QoS 217 differentiation on the path between the local mobility anchor and the 218 mobile access gateway. 220 2.3. QoS in IEEE 802.11 based Networks 222 IEEE 802.11-2012 [802.11-2012] provides an enhancement of the MAC 223 layer in WiFi networks to support QoS--EDCA (Enhanced Distributed 224 Channel Access). EDCA uses a contention based channel access method. 226 The EDCA mechanism provides differentiated, distributed access using 227 eight different UPs (User Priorities). EDCA also defines four access 228 categories (AC) that provide support for the delivery of traffic. In 229 EDCA, the random back-off timer and arbitration inter-frame space is 230 adjusted according to the QoS priority. Frames with higher priority 231 AC have shorter random back-off timers and arbitration inter-frame 232 spaces. Thus, there is a better chance for higher priority frames to 233 be transmitted. The Wi-Fi Alliance has created a specification 234 referred to as WMM (Wi-Fi Multimedia) based on above. 236 In addition to the above, QoS can also be provided using admission 237 control. The MN uses ADDTS (Add Traffic Specs) to setup a traffic 238 stream between itself and the AP, and DELTS to delete that stream. In 239 WMM [WMM 1.2.0], the AP advertises if admission control is mandatory 240 for an access class. Admission control for best effort or background 241 access classes is not recommended. The Wi-Fi Alliance has created a 242 specification referred to as WMM-AC (Wi-Fi Multimedia Admission 243 Control) based on the above. 245 3. End-to-End QoS with Admission Control 247 This section outlines a few use cases to illustrate how the 248 parameters and mapping in section 4 are applied. These cases are not 249 expected to be exhaustive. 251 There are two main types of interaction possible to provision QoS - 252 one is where the UE initiates the QoS request and the network 253 provisions the resources. The second is where the network provisions 254 resources as a result of some out of band signaling (like application 255 signaling). In this scenario, if the MN supports 802.11aa (TCLAS), 256 the network can push the QoS configuration to the MN. If the MN only 257 supports WMM QoS, then MN requests for QoS for the WiFi segment and 258 the MAG provisions based on QoS already provisioned for the MN. 260 3.1. Case A: MN Initiated QoS Signaling 262 When an MN sets up a connection that requires admission control in 263 the WiFi network, the level of QoS for the connection needs to be set 264 up. When the MN is configured (e.g. in SIM, subscription) to start 265 the QoS signaling, it sends an ADDTS request indicating the QoS 266 required for the connection. The AP/WLC (MAG) obtains the 267 corresponding level of QoS to be granted to the flow by sending a 268 PMIPv6 PBU message with QoS options to the LMA. Details of the setup 269 are described below. 271 +--------+ 272 +----+ | AP/WLC | +-------+ 273 | MN | | (MAG) | | LMA | 274 +-+--+ +---+----+ +---+---+ 275 | | | 276 /*************************************************************/ 277 /* [0] connection setup to mobile network */ 278 /*************************************************************/ 279 | | | 280 |[1] ADDTS(TSPEC) | | 281 |-------------------->| | 282 | | PBU(QoS options)[2] | 283 | |---------------------->| Policy request 284 | | |---------------> 285 | | |Policy response 286 | | |<--------------- 287 | | PBA (QoS option) [3] | 288 |[4]ADDTS Response |<----------------------| 289 | (TSPEC) | | 290 |<--------------------| | 291 | | | 293 Figure 1: MN initiated QoS setup 295 [0] The MN starts signaling to setup the connection. In mobile 296 networks, these are not default connections that are setup 297 initially. Default connections are best effort and do not need 298 explicit admission control with ADDTS. 300 [1] If the MN and network support 802.11aa and the MN is configured 301 to start QoS signaling, the MN sends an ADDTS request specifying 302 the QoS requested for the traffic stream including TSPEC element 303 with connection setup identifier. 305 [2] The MAG (AP/WLC) identifies the PMIP based on the connection 306 identifier and sends a PBU with QoS options requested. 308 [3] The LMA responds with the authorized QoS for the connection. 310 [4] The AP/WLC (MAG) provisions the corresponding QoS and replies 311 with ADDTS Response containing authorized QoS in TSPEC. 313 3.2. Case B: Network Initiated QoS Signaling (802.11aa based) 315 When an MN has connections or flows that require admission control, 316 the mobile network may provision correspond QoS in the MAG. This use 317 case illustrates how an MN and WiFi network that supports 802.11aa 318 can provision QoS to the MN. In this case, the network is configured 319 to start the QoS signaling, it sends an ADDTS request indicating the 320 QoS required for the connection. 322 +--------+ 323 +----+ | AP/WLC | +-------+ 324 | MN | | (MAG) | | LMA | 325 +-+--+ +---+----+ +---+---+ 326 | | | 327 | | | 328 /*************************************************************/ 329 /* [0] connection setup to mobile network */ 330 /*************************************************************/ 331 | | | Policy update 332 | |UPN(update session)[2] |<--------------- 333 | |<----------------------| [1] 334 | | PBU(QoS option) [3] | 335 | |---------------------->| 336 | | PBA (QoS option)[4] | 337 | ADDTS Reserve Req |<----------------------| 338 | (TCLAS/app id) [5] | | 339 |<--------------------| | 340 | ADDTS Reserve Response[6] | 341 |-------------------->| | 342 | | | 344 Figure 2: Network initiated QoS setup with 802.1aa 346 [0] The MN starts signaling to setup the connection. In mobile 347 networks, these are not default connections that are setup 348 initially. Default connections are best effort and do not need 349 explicit admission control with ADDTS. 351 [1] The LMA gets a QoS policy update for an existing connection. 353 [2] LMA sends a PMIP UPN (Update Notification) message to the MAG 354 requesting it to update session parameters. 356 [3] The MAG (AP/WLC) replies to UPN with a PBU including QoS 357 options. 359 [4] The LMA responds with the authorized QoS for the connection. 361 [5] If the MN and network support 802.11aa, the AP/WLC (MAG) sends 362 an ADDTS Reserve Request specifying the QoS reserved for the 363 traffic stream including TSPEC and TCLAS element with the 364 connection identifier (from PMIP). 366 [6] The MN notes the QoS reserved in the network and replies with 367 ADDTS Reserve Response. 369 3.3. Case C: Hybrid (Network Initiated for PMIPv6 and MN initiated for 370 Wi-Fi) 372 This example outlines a scenario where an MN attaches to the WiFi and 373 then obtains services in the mobile network. When the MN attaches, 374 PMIP signaling between the MAG and LMA establishes mobile connection 375 and related QoS. Subsequently, the MN starts an application that 376 requires dedicated bandwidth resources and signals that using 377 TSPEC/ADDTS request. The details of this sequence are described 378 below. 380 +--------+ 381 +----+ | AP/WLC | +-------+ 382 | MN | | (MAG) | | LMA | 383 +-+--+ +---+----+ +---+---+ 384 | | | 385 | | | 386 /*************************************************************/ 387 /* [0] connection setup to mobile network */ 388 /*************************************************************/ 389 | | | Policy update 390 | |UPN(update session)[2] |<--------------- 391 | |<----------------------| [1] 392 | | PBU(QoS option) [3] | 393 | |---------------------->| 394 | | PBA (QoS option)[4] | 395 | |<----------------------| 396 +-------------+ | | 397 |upper layer | | | 398 |notification | | | 399 +-+-+-+-+-+-+-+ | | 400 |ADDTS Request(TSPEC)[5] | 401 |-------------------->| | 402 | ADDTS Response [6] | | 403 |<--------------------| | 404 | | | 406 Figure 3: Network initiated QoS setup with WMM 408 [0] The MN starts signaling to setup the connection. In mobile 409 networks, these are not default connections that are setup 410 initially. Default connections are best effort and do not need 411 explicit admission control with ADDTS. 413 [1] The LMA gets a QoS policy update for an existing connection. 415 [2] LMA sends a PMIP UPN (Update Notification) message to the MAG 416 requesting it to update session parameters. 418 [3] The MAG (AP/WLC) replies to UPN with a PBU including QoS 419 options. 421 [4] The LMA responds with the authorized QoS for the connection. 422 Since the MAG or MN does not support 802.11aa, the MAG updates 423 QoS profile of MN and waits for request from MN. 425 [5] When the MN receives upper layer signaling (e.g. SDP) indicating 426 acceptance of codec or other media parameters, the MN requests 427 for corresponding QoS in TSPEC of ADDTS Request. 429 [6] When the(AP/WLC (MAG) receives the ADDTS Request from MN, it 430 checks the QoS profile for the MN to see if the additional QoS 431 requested for the stream is consistent with the QoS profile 432 stored for the MN. The AP/WLC then responds with ADDTS Response. 434 3.4. Mapping of Connection Parameters 436 This section outlines the handling of QoS connection (session) 437 parameters between WiFi 802.11 and PMIP QoS. 439 Connection Mapping: 441 802.11 QoS in TSPEC is used to reserve QoS for a traffic stream 442 (MN MAC, TS(Traffic Stream) id). The QoS reservation is for 443 802.11 frames and here is no IP prefix/flow associated during 444 this reservation. The AP/WLC evaluates this request against 445 policy installed using PMIP QoS. When PMIP QoS policy is 446 installed in AP/WLC, the TSPEC request is granted if the MN 447 (identified by MAC) is authorized. The AP/WLC may police 448 subsequent flows with {MAC, TS, 802.1D, IP prefix} to match QoS 449 policy installed by PMIP QoS for {IP prefix, DSCP}. 451 QoS Class: 453 802.11 QoS Access Class (AC_VO, AC_VI) requests corresponds to 454 DSCP in PMIP QoS setup. Table 1 (section 4.1) below shows the 455 complete mapping. 457 Bandwidth: 459 For flows with reservation, the 802.11 Mean Data Rate should be 460 equal to (or less than) Guaranteed Bit Rate (GBR). If the MN 461 requests Mean Data Rate in ADDTS greater than GBR, then AP/WLC 462 should deny the request in ADDTS Response. 464 For flows with no reservation, the bandwidth should not exceed 465 MBR (Maximum Bit Rate). If such a flow is offloaded at AP/WLC, 466 the policy obtained during authorization is used. 468 The total bandwidth used by all flows of an MN should not exceed 469 AMBR (Aggregate Maximum Bit Rate). 471 Preemption Priority: 473 Mobile networks configure ARP (Allocation Retention Priority) 474 during authorization and in [PMIP QoS]. If there is limited 475 resource and multiple ADDTS requests, ARP should be used by the 476 AP/WLC to determine which requests to grant. ARP has a range 1 477 to 15 with 1 being the highest priority [TS23.203]. 479 During severe congestion or partial failure, if the AP/WLC has 480 to preempt existing reservations, ARP may be used to determine 481 the order of preemption. 483 3.5. Service Guarantees in 802.11 485 The GBR - Guaranteed Bit Rate in mobile networks are used to request 486 and commit resources in the network for providing the bandwidth 487 requested. In WiFi networks, a random backoff timer based on the 488 access class only provides priority access to a shared medium. These 489 mappings and recommendations allow the AP to schedule resources in a 490 fair manner based on subscribed QoS and application request/policy 491 server interaction. 493 However, there are no guaranteed or committed resources in the WiFi 494 network - only prioritization that gives better opportunity for 495 frames to compete for a shared medium. 497 It should also be noted that unlike mobile networks which inform the 498 MN about QoS for established or modified connections (bearers), there 499 is no means for an MN in WiFi networks to find out the QoS that a 500 policy server requests to be granted. Thus, the application in MN 501 should make its determination to downgrade a request based on SDP and 502 media parameters to downgrade to a lower quality. 504 4. End-to-End QoS without Admission Control 505 GSMA and IETF (RFC 4594) have defined mapping between DSCP and IEEE 506 802.11 UP (user Priority). The MAG could be pre-configured to use the 507 mapping from one of these specifications. Per MN connection 508 configuration may be setup at the AP/WLC based by PMIP QoS signaling 509 during connection setup. This is described in [PMIP QoS], section 510 3.5. 512 However, in many cases it may be beneficial to use a different set of 513 mapping and potentially different mappings for different users. For 514 example an operator may choose to provide only best effort service to 515 one subscriber class while providing more enhanced (AF or EF) 516 services to other subscriber classes. To enables such capabilities, a 517 QoS Service Attribute called QoS MAP Set is introduced. This is 518 modeled after an IEEE 802.11 element with the same name (see 8.4.2.97 519 in IEEE 802.11-2012). 521 The QoS Map Set attribute is used as follows. The LMA would send a 522 specific DSCP to UP mapping in the Proxy Binding Update. In cases 523 where the MAG is co-located with the AP, AP/MAG can ensure that 524 received packets from the mobile node have the the correct DSCP to UP 525 mapping(packets with inappropriate marking may be remarked). 526 Similarly, on the downstream, the QoS Map Set enables the MAG/AP to 527 determine the correct UP. This also ensures that a source ineligible 528 for higher grades of service (provided by higher priority UP bits) 529 cannot avail of such a service by marking the packets with DSCP 530 values (for example by marking the packets with EF and AF 531 codepoints). There is an additional benefit of providing the AP/MAG 532 with the QoS Map Set. For mobile nodes that support the IEEE 802.11 533 QoS Map Set capability, the AP can provide the corresponding QoS Map 534 Set information to the mobile node. This can ensure that the mobile 535 node uses the correct DSCP to UP marking. 537 0 1 2 3 538 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 539 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length | Reserved | 541 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | UP0 Range | UP1 Range | UP2 Range | UP3 Range | 543 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | UP4 Range | UP5 Range | UP6 Range | UP7 Range | 545 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | DSCP Ex-0 | DSCP Ex-1 | DSCP Ex-3 .... 547 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ 549 Type: TBD Length: Length of the following data value in octets, 550 greater than or equal to 10. 552 The format of UP0,..,UP7 Range is as follows 553 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 554 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+ 555 | DSCP Low Val | DSCP Hi Val | 556 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+ 558 The format of the DSCP Exception field is as follows 560 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 561 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+ 562 | DSCP Val | UP Value | 563 +=+-+-+-+-+=+-+-+-+-+-+-+-+-+-+-+ 565 4.1. Default Values and Recommendations 567 The table below outlines a recommended mapping between 3GPP QCI, 568 and 802.11 Access Category (AC)/ 802.1D UP. 570 QCI DSCP 802.1D UP WMM AC Example Services 571 ------------------------------------------------------------ 572 1 EF 6(VO) 3 AC_VO conversational voice 573 2 EF 6(VO) 3 AC_VO conversational video 574 3 EF 6(VO) 3 AC_VO real-time gaming 575 4 AF41 5(VI) 2 AC_VI buffered streaming 576 5 AF31 4(CL) 2 AC_VI IMS signaling 577 6 AF32 4(CL) 2 AC_VI buffered streaming 578 7 AF21 3(EE) 0 AC_BE interactive gaming 579 8 AF11 1(BE) 0 AC_BE web access 580 9 BE 0(BK) 1 AC_BK e-mail 582 Table 1: QoS Mapping between QCI/DSCP, 802.1D UP, WMM AC 584 The QoS mapping table above provides recommendations and default 585 mapping between DSCP provided in [PMIP QoS], WMM AC used for TSPEC 586 reservation, and 802.1D UP in 802.11 frames. 588 5. Security Considerations 590 This document describes mapping of 3GPP QoS profile and parameters to 591 IEEE 802.11 QoS parameters. No security concerns are expected as a 592 result of using this mapping. 594 6. IANA Considerations 595 No IANA assignment of parameters are required in this document. 597 7. References 599 7.1. Normative References 601 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, 605 April 1 1995. 607 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 608 April 1 1996. 610 7.2. Informative References 612 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 613 RFC 3514, April 1 2003. 615 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 616 Acronyms", RFC 5513, April 1 2009. 618 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 619 2009. 621 [PMIP-QoS] Liebsch, et al., "Quality of Service Option for Proxy 622 Mobile IPv6", draft-ietf-netext-pmip6-qos-00, June 2012. 624 [WMM 1.2.0] Wi-Fi Multimedia Technical Specification (with WMM-Power 625 Save and WMM-Admission Control) Version 1.2.0 627 [802.11aa] Wireless LAN Medium Access Control (MAC) and Physical 628 Layer (PHY) Specification, Amendment 2: MAC Enhancements 629 for Robust Audio Video Streaming, IEEE 802.11aa-2012. 631 [802.11-2012] 802.11-2012 - IEEE Standard for Information technology- 632 -Telecommunications and information exchange between 633 systems Local and metropolitan area networks--Specific 634 requirements Part 11: Wireless LAN Medium Access Control 635 (MAC) and Physical Layer (PHY) Specifications 637 [GSMA-IR34]Inter-Service Provider Backbone Guidelines 5.0, 22 638 December 2010 640 [RFC 2211] Wroclawski, J., "Specification of the Controlled Load 641 Quality of Service", RFC 2211, September 1997. 643 [RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 644 of Guaranteed Quality of Service", RFC 2212, September 645 1997. 647 [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS 648 Control Service Specification Template", RFC 2216, 649 September 1997. 651 [TS23.107] Quality of Service (QoS) Concept and Architecture, Release 652 10, 3GPP TS 23.107, V10.2.0 (2011-12). 654 [TS23.207] End-to-End Quality of Service (QoS) Concept and 655 Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011- 656 03). 658 [TS23.402] Architecture Enhancements for non-3GPP accesses(Release 659 12), 3GPP TS 23.402, V12.2.0 (2013-09). 661 [TS23.203] Policy and Charging Control Architecture, Release 11, 3GPP 662 TS 23.203, V11.2.0 (2011-06). 664 [TS29.212] Policy and Charging Control over Gx/Sd Reference Point, 665 Release 11, 3GPP TS 29.212, V11.1.0 (2011-06). 667 [TS29.273] 3GPP EPS AAA interfaces(Release 12), 3GPP TS 29.273 668 v12.1.0 (2013-09) 670 Authors' Addresses 672 John Kaippallimalil 673 5340 Legacy Drive, Suite 175 674 Plano, Texas 75024 676 E-Mail: john.kaippallimalil@huawei.com 678 Rajesh Pazhyannur 679 170 West Tasman Drive 680 San Jose, CA 95134 682 E-Mail: rpazhyan@cisco.com 683 Parviz Yegani 684 1194 North Mathilda Ave. 685 Sunnyvale, CA 94089-1206 687 E-Mail: pyegani@juniper.net 689 Appendix A: QoS Policy Architecture 691 The QoS architecture in this section provides a brief outline for 692 provisioning QoS in a consistent manner across the WiFi network, 693 backhaul and PMIP mobile network. 695 QoS information is available to AP/WLC when the MN attaches to the 696 WiFi network and authenticates. The authorization profile includes 697 QoS that the user/MN has subscribed to. When the MN attaches to the 698 network, the LMA returns the session parameters such as IP address 699 and may also include QoS profile as per [PMIP-QoS]. 701 +-----------+ +-----------+ 702 | AAA | | Policy | 703 +-----+-----+ +-----+-----+ 704 | | 705 (Authorization) (Session) 706 | | 707 AP/WLC |(MAG) PDN-GW |(LMA) 708 +----+ +------|-----+ +------|-----+ 709 | | | +----v---+ | PMIP-QoS | +----v---+ | 710 | | | |QoS-Pol <---------------| |QoS-Pol | | 711 | | | +---+----+ | | +---+----+ | 712 | MN | | | | ___ | | | 713 | | 801.11 | +---v----+ | ( ) +---v----+ | 714 | +-------------+ PEP +-+--( IP )-----+ PEP + | 715 | | | +--------+ | (Network ) | +--------+ | 716 +----+ +------------+ \ / +------------+ 717 +---+ 719 Figure 4: Architecture for provisioning QoS Policy on WiFi AP 721 Figure 4 provides an overview of the architecture in which QoS for an 722 MN is provisioned on the AP/WLC. MN QoS policy from initial 723 authorization and PMIP connection establishment is provisioned in the 724 AP/WLC QoS-Pol (logical function). AP/WLC PEP uses the policies for 725 handling QoS flows from an MN. 727 Policy Server provisioning of Admission control for connections has 728 traditionally relied on information from Deep Packet Inspection (DPI) 729 or Application Level Gateways (ALG). DPIs and ALGs cannot however 730 determine the MNs subscribed bandwidth or QoS. The alternative is to 731 provision QoS policy for a user's connections and use subscribed 732 policy and PMIP QoS policy. When the AP/WLC has both the subscribed 733 QoS policy and policy parameters from PMIP QoS, the QoS parameters 734 obtained through PMIP reflect the policy that accounts for current 735 network conditions. 737 In mobile networks, default connections are not setup with a 738 bandwidth reservation and hence do not have a GBR (Guaranteed Bit 739 Rate) associated. However, the PDN-GW (LMA) polices the AMBR 740 (Aggregate Maximum Bandwidth Rate) - the maximum bit rate for all 741 flows to/from the MN. Thus, upstream traffic should be policed by 742 AP/WLC to not exceed the maximum prescribed in AMBR values. The 743 AP/WLC should also schedule traffic for these connections as 744 background or best effort (AC_BK, AC_BE) and the corresponding 745 802.1D 747 For voice, video and other applications that require reservation of 748 QoS resources, a dedicated PMIP connection is setup in mobile 749 networks and the PDN-GW (LMA) reserves resources as per GBR 750 (Guaranteed Bit Rate) for upstream and downstream. In this also, the 751 total bit rate of all flows to/from MN should not exceed the maximum 752 bit rates in AMBR (Aggregate Maximum Bit Rate). Upstream and 753 downstream traffic should be scheduled by MN and AP/WLC using ADDTS 754 (TSPEC) for voice or video (AC_VO, AC_VI). The MN should also include 755 the Mean Data Rate for the connection based on the requirements of 756 the application or negotiated codec. The AP/WLC grants resources 757 based on policy obtained over PMIP QoS. GBR values in PMIP QoS should 758 be used to derive Mean Data Rate as described in section 4.1. When 759 the MN completes the session, it may send DELTS to request release of 760 associated QoS resources. 762 If the MN connection is offloaded to the internet by the AP/WLC, 763 there is no corresponding PMIP session setup to the mobile network. 764 In this case, the AP/WLC may use AMBR obtained during authorization 765 if the MN has no other connections to the mobile network. If the MN 766 has other connections to the mobile network, he AP/WLC should limit 767 the maximum bit rate of all flows of the MN to AMBR obtained in PMIP 768 QoS. 770 When the network is congested and the AP/WLC cannot grant the QoS 771 requested by MN, the AP/WLC should refuse the ADDTS request and not 772 continue the PMIP QoS signaling request. The application in MN may 773 downgrade the codec and re-negotiate a new TSPEC/resource request 774 that the AP/WLC may grant. If the AP/WLC cannot handle committed 775 connections due to network degradation or other partial failures, the 776 AP/WLC may use the ARP (Allocation Retention Priority) values of the 777 connection to gracefully release resources.