idnits 2.17.1 draft-penno-pcp-mobile-qos-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (July 29, 2013) is 3922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5389' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-security-arch' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC6342' is defined on line 521, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Informational RFC: RFC 6459 == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-01 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-07 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-server-selection-01 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 == Outdated reference: A later version (-03) exists of draft-wing-pcp-third-party-authz-00 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP R. Penno 3 Internet-Draft T. Reddy 4 Intended status: Standards Track D. Wing 5 Expires: January 30, 2014 B. VerSteeg 6 Cisco 7 M. Boucadair 8 France Telecom 9 July 29, 2013 11 PCP Usage for Quality of Service (QoS) in Mobile Networks 12 draft-penno-pcp-mobile-qos-00 14 Abstract 16 There are challenges to request quality of service for an application 17 or network flow that is not part of a mobile network's Evolved Packet 18 Core (EPC). This document addresses this issue by defining a 19 mechanism to signal the desired characteristics of a flow to the 20 Mobile Network from a User Equipment (UE) using Port Control Protocol 21 (PCP). The signaled characteristics allow the Mobile Network to 22 enforce appropriate policies such as prioritize that flow accordingly 23 and trigger dedicated bearer activation or bearer modification 24 procedure. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 30, 2014. 43 Copyright Notice 45 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 62 3. QoS in Cellular Networks . . . . . . . . . . . . . . . . . . 4 63 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Network-triggered QoS . . . . . . . . . . . . . . . . . . 7 65 4.2. PCP to 3GPP . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 A.1. Other techniques . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The use of Mobile Network for accessing the Internet and other data 79 services via smartphones, tablets, and notebook/netbook computers has 80 increased rapidly as a result of high-speed packet data networks such 81 as HSPA and HSPA+; and now Long-Term Evolution (LTE) is being 82 deployed. Mobile devices are becoming similar in capability to their 83 desktop counterparts. From that perspective, it is feasible to run 84 WebRTC, HTTP Adaptive Streaming (HAS), P2P applications on mobile 85 devices. Mobile network needs to have a mechanism to prioritize such 86 packet flows in both directions. 88 The Web Real-Time communication (WebRTC) framework 89 [I-D.ietf-rtcweb-overview] provides the protocol building blocks to 90 support direct, interactive, real-time communication using audio, 91 video, collaboration, games, etc., between peer web-browsers. WebRTC 92 application use Interactive Connectivity Establishment (ICE) protocol 93 [RFC5245] for gathering candidates, prioritizing them, choosing 94 default ones, exchanging them with the remote party, pairing them and 95 ordering them into check lists. Once all of the above steps have 96 been completed the participating ICE agents can begin a phase of 97 connectivity checks and eventually select a pair of candidates that 98 will be used for real-time communication. The P2P streams (audio, 99 video, data-channel) are dynamic, time-bound, encrypted and have 100 different priorities. When WebRTC server is deployed in a 3rd party 101 network trusted by the Mobile Network and the media session need to 102 be prioritized, a mechanism is required to signal the flow 103 characteristics (i.e., traffic performance requirements) of the media 104 streams to the Mobile Network. However, the Mobile Network may not 105 trust the host (UE) to signal the correct flow characteristics 106 permitted by the WebRTC server. 108 PCP [RFC6887] provides a mechanism to describe a given flow to the 109 network prior to actual session establishment. The primary driver 110 for PCP has been creating port mappings on NAT and firewall devices. 111 When doing this, PCP pushes flow information from the host into the 112 network (specifically to the network's NAT or firewall device), and 113 receives information back from the network (from the NAT or firewall 114 device). This document uses PCP FLOWDATA option defined in 115 [I-D.wing-pcp-flowdata] to convey the flow characteristics from the 116 host to the Mobile Network, and allow the Mobile Network to 117 prioritize that flow accordingly and trigger dedicated bearer 118 activation or bearer modification procedure. This document also 119 explains how the PCP Server in the Evolved Packet Core (EPC) maps the 120 fields in PCP FLOWDATA option to 3GPP QCI, GBR values. 122 The mechanism described in this document has several useful 123 properties : 125 a. Differentiated QoS services can be offered to third party 126 applications. For third party applications differentiated QoS 127 services can be installed even if the UE is behind NAT provided 128 by the Mobile Network. In contrast, other mechanisms struggle to 129 install differentiated QOS if the UE is behind NAT. 131 b. Mobile Network can authorize the differentiated service request 132 from third party application because the proposed mechanism is 133 compliant with the 3GPP's network-triggered QoS policy 134 enforcement model. 136 c. This mechanism does not rely on DPI. 138 d. A UE can use single protocol no matter of the access technology; 139 Abstracts layer 2 specifics, so host and applications can avoid 140 layer 2-specific signaling even if their Internet connection is 141 via 3G/4G or DOCSIS. 143 e. Usable at the application level, without needing operating system 144 support 146 f. Robust metadata support, to convey sufficient information to the 147 network about the flow; 149 g. Provides differentiated service for both directions of a flow, 150 including flows that cross administrative boundaries (such as the 151 Internet). 153 h. Both high-priority and low-priority flows can be signalled, so 154 that in overload situations operators can make low-priority flows 155 yield to other flows through policing. 157 Note : 159 1. It is out of scope of this document to discuss the trade-offs 160 between the proposed approach vs. deploying local WebRTC-IMS 161 Gateways within the Mobile Network. 163 2. The mechanism described in this document provides QoS and network 164 feedback for a variety of applications including interactive 165 audio/video application such as WebRTC, streaming video, and 166 network backup. The value is provided for the applications that 167 are orchestrated through EPC and for applications that are 168 delivered over the top. 170 3. Administrative-related considerations between the administrative 171 entity managing the third party application server and the Mobile 172 Network are out of scope of this document. 174 2. Notational Conventions 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 This note uses terminology defined in [RFC5245], [RFC6459]. 182 WebRTC Server : Web Server that supports WebRTC. 184 High-Speed Packet Access : The High-Speed Packet Access (HSPA) and 185 HSPA+ are enhanced versions of the Wideband Code Division Multiple 186 Access (WCDMA) and UTRAN, thus providing more data throughput and 187 lower latencies. 189 3. QoS in Cellular Networks 190 3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release 191 8 [TS23.107]. 3GPP QoS policy configuration defines access agnostic 192 QoS parameters that can be used to provide service differentiation in 193 multi vendor and operator deployments. The concept of a bearer is 194 used as the basic construct for which QoS treatment is applied for 195 uplink and downlink packet flows between the Mobile Node (MN) and 196 gateway [TS23.401]. A bearer may have more than one packet filter 197 associated and this is called a Traffic Flow Template (TFT). IP 198 source address, source port, IP destination, destination port, L4 199 protocol, Type of service/Traffic class type, Security parameter 200 index etc identify a packet filter. Each UE can have one or multiple 201 bearers associated with its registration, each supporting different 202 QoS characteristics. An UpLink Traffic Flow Template (UL TFT) is the 203 set of uplink packet filters in a TFT. A DownLink Traffic Flow 204 Template (DL TFT) is the set of downlink packet filters in a TFT. 206 The access agnostic QoS parameters associated with each bearer are 207 QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), 208 MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate) 209 explained in [TS23.203]. QCI is a scalar that defines packet 210 forwarding criteria in the network. Mapping of QCI values to DSCP is 211 well understood and GSMA has defined standard means of mapping 212 between these scalars [GSMA-IR34]. Primarily LTE offers two types of 213 bearer: Guaranteed Bit rate bearer for real time communication, e.g., 214 Voice calls etc and Non-Guaranteed bit rate bearer, e.g., best effort 215 traffic for web access etc. Packets mapped to the same EPS bearer 216 receive the same bearer level packet forwarding treatment. For 217 example QCI value 1 is typically used for Conversational Voice and 218 the standardized flow characteristics for QCI value 1 are Packet 219 delay of 100 ms and Packet error loss Rate of 10 to the power -2. 221 3G and LTE networks also provide extensive support for accounting and 222 charging already, for example using the Policy Charging Control (PCC) 223 architecture. In the EPS, per-user information is normally part of 224 the user profile (stored in the Home Subscriber Server) that would be 225 accessed by PCC entities such as the PCRF for dynamic updates, 226 enforcement etc. 228 4. Solution Overview 230 In the below topology, The main involved functional elements are: 232 o UE (User Equipment) is a mobile node. 234 o The evolved NodeB (eNB) is a base station entity that supports the 235 Long-Term Evolution (LTE) air interface. It is part of the access 236 network that provides radio resource management, header 237 compression, security and connectivity to the core network through 238 the S1 interface. In an LTE network, the control plane signaling 239 traffic and the data traffic are handled separately. The eNBs 240 transmit the control traffic and data traffic separately via two 241 logically separate interfaces. 243 o The Serving gateway, SGW, is the mobility anchor and manages the 244 user plane data tunnels during the inter-eNB handovers. It 245 tunnels all user data packets and buffers downlink IP packets 246 destined for UEs that happen to be in idle mode. 248 o Policy and Charging Rule Function (PCRF) which is responsible for 249 determining which policy and charging control rules are to be 250 applied [TS23.203]. 252 o Policy and Charging Enforcement Function (PCEF) which performs 253 policy enforcement (e.g., Quality of Service (QoS)) and flow-based 254 charging [TS23.203]. PCEF is co-located with PDN-GW. PDN-GW is 255 also responsible for IP address allocation to the UE, packet 256 filtering, and policy-based control of flows. 258 o Application Function (AF) is an element offering applications that 259 require dynamic policy and/or charging control [TS23.203]. 261 o The Home Subscriber Server, HSS, is a database that contains user 262 subscriptions and QoS profiles. The Mobility Management Entity, 263 MME, is responsible for user authentication, bearer establishment 264 and modification and maintenance of the UE context. 266 +--------+ 267 | HSS | 268 +--------+ 269 | +-------+ 270 | | PCRF | 271 | +-------+ 272 +-------+ | 273 / | MME |\ | 274 / +-------+ \ | 275 / \ | 276 / \ | 277 +----+ +-------+ +-------+ +-------+ 278 |UE | | eNB | | SGW | |PDN-GW | 279 | |========| |============| |======| | 280 +----+ +-------+ +-------+ +-------+ 281 ^ . ^ 282 | . PCP request/response . 283 | .................................................... 284 | 285 | WebRTC Signalling 286 +-------------------------------------------------------+ 287 Mobile Network | 288 | 289 ================================================================== 290 3rd Party Network | 291 | 292 V 293 ========================= 294 | WebRTC Server | 295 ========================= 297 PCP interdomain - WebRTC 299 4.1. Network-triggered QoS 301 This section describes the existing steps applicable to any other 302 network that requires authorization from third party application to 303 permit differentiated QOS service request from UE which has been 304 discussed in [I-D.wing-pcp-third-party-authz]. 306 1. PCP client determines the PCP server to use by using the 307 mechanisms explained in section 8.1 of [RFC6887]. In case of the 308 GTP-based S5/S8 interface, the PDN-GW is the first-hop router for 309 the UE, and in the case of PMIPv6-based S5/S8, the SGW is the 310 first-hop router. PCP server could be co-located with the PDN- 311 GW. For instance PCP client can also learn the PCP server 312 address using DHCP [I-D.ietf-pcp-dhcp] and behavior to be 313 followed by the PCP client to contact its PCP server(s) is 314 explained in [I-D.ietf-pcp-server-selection]. The other benefits 315 of using PCP are explained in [I-D.penno-rtcweb-pcp]. 317 2. Once ICE [RFC5245] processing has completed, an updated offer/ 318 answer exchange takes place. WebRTC server is aware of the 319 active media path after the controlling ICE endpoint follows the 320 procedures in Section 11.1 of [RFC5245], specifically to send 321 updated offer if the candidates in the m and c lines for the 322 media stream (called the DEFAULT CANDIDATES) do not match ICE's 323 SELECTED CANDIDATES (also see Appendix B.9 of [RFC5245]). 325 3. To provide differentiated QOS, the WebRTC server generates 326 cryptographic token and metadata for prioritizing the media 327 streams which is passed to the WebRTC endpoint. In this scenario 328 PCP client on the UE is the third-party application obtaining 329 limited access to an PCP server (resource server) on behalf of 330 the WebRTC server (resource owner). The PCP TOKEN_ACCESS option 331 defined in [I-D.wing-pcp-third-party-authz] must be included in 332 the PCP request sent to the PCP server. This TOKEN_ACCESS option 333 is created by the PCP client using the access token, key id etc 334 received from the authorization server using OAuth 2.0 [RFC6749]. 335 The PCP client populates the fields in FLOWDATA option using the 336 metadata provided by the authorization server. The PCP client 337 sends the PCP request with MAP or PEER opcodes with the above PCP 338 options to the PCP server. This mechanism is required so that 339 the PCP server in the Evolved Packet (EPC) can validate that the 340 PCP request for specific flow characteristics is initiated by the 341 UE because of using a trusted 3rd party WebRTC Server. 343 4. The PCP server identifies the authorization server using the 344 Domain Name in the PCP ACCESS_TOKEN option. The PCP server 345 validates the fields in TOKEN_ACCESS option using the mechanism 346 explained in section 5.2 of [I-D.wing-pcp-third-party-authz]. If 347 the token is successfully validated then the authorization server 348 returns the token bound authorization data in response. The 349 token bound authorization data would be flow characteristics like 350 upstream and downstream minimum bandwidth, delay, loss etc. The 351 PCP server then matches this token bound authorization data with 352 what is requested in the PCP FLOWDATA option. If the 353 authorization sets match, the PCP server honors the PCP request 354 made by the PCP client. 356 4.2. PCP to 3GPP 358 This section describes steps involved with processing PCP FLOWDATA 359 option to initiate bearer activation for each media stream. 361 1. The PCP FLOWDATA option has all the required fields to trigger 362 dedicated bearer activation or modification with relevant QCI, 363 GBR values. UpLink Traffic Flow Template (UL TFT) and DownLink 364 Traffic Flow Template (DL TFT) would be installed in both 365 directions for the media stream. For example IP source address, 366 source port, IP destination address, destination port, L4 367 protocol will be used from the PCP request (PEER opcode) to 368 create packet filter which is associated with UL TFT. The 369 advantage of this technique is no changes are required to TFT 370 definition. PCP success response would be sent without waiting 371 for network-initiated bearer activation or modification to be 372 complete: i.e., PCP success response would be sent based on the 373 resource availability to setup or modify bearers. 375 2. Using the fields in PCP FLOWDATA option listed in the below 376 table, relevant QCI value will be determined to initiate bearer 377 activation or modification procedure. Upstream and Downstream 378 Bandwidth Minimum values will be set to zero in PCP FLOWDATA 379 option to indicate QCI values in the range 5-8. Non-zero 380 Bandwidth Minimum value in FLOWDATA option will be mapped to GBR 381 to determine if the requested bitrate can be provided or not. 382 GBR is provided only for QCI values 1 to 4. 384 (Fields in PCP FLOWDATA option - uDT, uLT, dDT, dLT) 386 +---------------------------------------------------------------+ 387 | QCI | Delay | Loss | Example Services | 388 |---------------------------------------------------------------| 389 | 1 | Low | Medium | Conversational Voice | 390 +---------------------------------------------------------------+ 391 | 2 | Medium | Low | Conversational Video | 392 +---------------------------------------------------------------+ 393 | 3 | Very Low | Low | Real Time Gaming | 394 +---------------------------------------------------------------+ 395 | 4 | Medium | Very Low | Non-conversational Video, | 396 | | | | buffered streaming | 397 +---------------------------------------------------------------+ 398 | 5 | Low | Very Low | IMS Signalling | 399 +---------------------------------------------------------------+ 400 | 6 | Medium | Very Low | Video (Buffered Streaming) | 401 +---------------------------------------------------------------+ 402 | 7 | Low | Low | Voice, Video (Live streaming) | 403 +---------------------------------------------------------------+ 404 | 8 | Medium | Low | web access | 405 +---------------------------------------------------------------+ 406 | 9 | High | Low | e-mail | 407 +---------------------------------------------------------------+ 409 PCP FLOWDATA to QCI Mapping 411 3. The PDN-GW will communicate with the PCRF to trigger the 412 appropriate Policy charging and control (PCC) decision based on 413 which PDN-GW will initiate bearer activation or modification 414 procedure. 416 4. If PCP authentication [I-D.ietf-pcp-authentication] is used then 417 the PCP server can also provide identity of the UE to PCRF. 419 5. After the call is terminated PCP client informs the PCP server to 420 close the mapping. The Authorization Server also informs the PCP 421 server to revoke the access token after the call is terminated 422 which is discussed in section 5.2 of 423 [I-D.wing-pcp-third-party-authz]. This step triggers bearer 424 deactivation procedure discussed in section 5.4.4.1 of 425 [TS23.401]. 427 5. Security Considerations 429 Security considerations discussed in [RFC6887] and PCP authentication 430 [I-D.ietf-pcp-authentication] are to be taken into account. 432 6. IANA Considerations 434 None. 436 7. Acknowledgements 438 Authors would like to thank Harold Lassers, Basavraj Patil, Thomas 439 Anderson for their comments and review. 441 8. References 443 8.1. Normative References 445 [I-D.ietf-rtcweb-overview] 446 Alvestrand, H., "Overview: Real Time Protocols for Brower- 447 based Applications", draft-ietf-rtcweb-overview-06 (work 448 in progress), February 2013. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 454 (ICE): A Protocol for Network Address Translator (NAT) 455 Traversal for Offer/Answer Protocols", RFC 5245, April 456 2010. 458 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 459 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 460 October 2008. 462 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 463 of Interpretation", RFC 6407, October 2011. 465 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 466 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 467 Partnership Project (3GPP) Evolved Packet System (EPS)", 468 RFC 6459, January 2012. 470 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 471 6749, October 2012. 473 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 474 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 475 2013. 477 8.2. Informative References 479 [GSMA-IR34] 480 , "Inter-Service Provider Backbone Guidelines 5.0, 22 481 December 2010", September 2012. 483 [I-D.ietf-pcp-authentication] 484 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 485 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 486 authentication-01 (work in progress), October 2012. 488 [I-D.ietf-pcp-dhcp] 489 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 490 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-07 491 (work in progress), March 2013. 493 [I-D.ietf-pcp-server-selection] 494 Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 495 Reddy, "PCP Server Selection", draft-ietf-pcp-server- 496 selection-01 (work in progress), May 2013. 498 [I-D.ietf-rtcweb-security-arch] 499 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 500 rtcweb-security-arch-07 (work in progress), July 2013. 502 [I-D.penno-rtcweb-pcp] 503 Penno, R., Reddy, T., Wing, D., and M. Boucadair, "PCP 504 Considerations for WebRTC Usage", draft-penno-rtcweb- 505 pcp-00 (work in progress), May 2013. 507 [I-D.reddy-rtcweb-mobile] 508 Reddy, T., Kaippallimalil, J., R, R., and R. Ejzak, 509 "Considerations with WebRTC in Mobile Networks", draft- 510 reddy-rtcweb-mobile-03 (work in progress), May 2013. 512 [I-D.wing-pcp-flowdata] 513 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 514 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 516 [I-D.wing-pcp-third-party-authz] 517 Wing, D., Reddy, T., Patil, P., and R. Penno, "PCP 518 Extension for Third Party Authorization", draft-wing-pcp- 519 third-party-authz-00 (work in progress), May 2013. 521 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 522 Deployment", RFC 6342, August 2011. 524 [TS23.107] 525 3GPP, ., "End-to-End Quality of Service (QoS) Concept and 526 Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011- 527 03)", September 2012. 529 [TS23.203] 530 3GPP, ., "3GPP, "Policy and charging control 531 architecture", 3GPP TS 23.203 10.5.0, December 2011.", 532 September 2012. 534 [TS23.401] 535 3GPP, ., "General Packet Radio Service (GPRS) enhancements 536 for Evolved Universal Terrestrial Radio Access Network (E- 537 UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 538 06).", September 2012. 540 Appendix A. 542 A.1. Other techniques 544 o UE can also request bearer resource modification for an E-UTRAN as 545 explained in Section 5.4.5 of [TS23.401]. The procedure allows 546 the UE to request modification of bearer resources (e.g., 547 allocation or release of resources) for one traffic flow aggregate 548 with a specific QoS demand. Alternatively, the procedure allows 549 the UE to request modification of the packet filters used for an 550 active traffic flow aggregate, without changing QoS. If accepted 551 by the network, the request invokes either the Dedicated Bearer 552 Activation Procedure or the Bearer Modification Procedure. 553 However this technique is not widely deployed and only network- 554 controlled quality of service is widely used. 556 o After certain QoS parameters are established, the UE or the 557 network may want to change those QoS parameters. This is 558 supported in both 3GPP [TS23.401] and PCP FLOWDATA. 560 o Bearers modification, creation procedures when Application Server 561 like WebRTC is deployed in 3GPP network is explained in section 562 4.3 of [I-D.reddy-rtcweb-mobile]. 564 o TODO : OneAPI. 566 Authors' Addresses 567 Reinaldo Penno 568 Cisco Systems, Inc. 569 170 West Tasman Drive 570 San Jose 95134 571 USA 573 Email: repenno@cisco.com 575 Tirumaleswar Reddy 576 Cisco Systems, Inc. 577 Cessna Business Park, Varthur Hobli 578 Sarjapur Marathalli Outer Ring Road 579 Bangalore, Karnataka 560103 580 India 582 Email: tireddy@cisco.com 584 Dan Wing 585 Cisco Systems, Inc. 586 170 West Tasman Drive 587 San Jose, California 95134 588 USA 590 Email: dwing@cisco.com 592 Bill VerSteeg 593 Cisco Systems, Inc. 594 5030 Sugarloaf Parkway 595 Lawrenceville 30044 596 USA 598 Email: billvs@cisco.com 600 Mohamed Boucadair 601 France Telecom 602 Rennes 35000 603 France 605 Email: mohamed.boucadair@orange.com