idnits 2.17.1 draft-reddy-rtcweb-mobile-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 : ---------------------------------------------------------------------------- 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 (May 09, 2013) is 4004 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC5389' is defined on line 603, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-dhesikan-tsvwg-rtcweb-qos-01 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-04 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-06 == Outdated reference: A later version (-05) exists of draft-korhonen-dmm-prefix-properties-03 == Outdated reference: A later version (-07) exists of draft-wing-mmusic-ice-mobility-03 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB T. Reddy 3 Internet-Draft Cisco 4 Intended status: Informational J. Kaippallimalil 5 Expires: November 10, 2013 Huawei 6 Ram. Mohan. Ravindranath 7 Cisco 8 R. Ejzak 9 Alcatel-Lucent 10 May 09, 2013 12 Considerations with WebRTC in Mobile Networks 13 draft-reddy-rtcweb-mobile-03 15 Abstract 17 This document discusses some of the issues with WebRTC applications 18 in Mobile Networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 10, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 56 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Cellular Networks - QOS . . . . . . . . . . . . . . . . . . . 3 58 4.1. RTP Session Multiplexing . . . . . . . . . . . . . . . . 4 59 4.1.1. Disable RTP Multiplexing . . . . . . . . . . . . . . 5 60 4.1.2. Extend Packet Filter to include RTP SSRC . . . . . . 5 61 4.1.3. Extend Packet Filter to include RTP payload type . . 6 62 4.1.4. Data Channel multiplexed with RTP . . . . . . . . . . 6 63 4.2. Bearer Resource Modification triggered by UE . . . . . . 7 64 4.3. WebRTC server deployed in 3GPP Network . . . . . . . . . 8 65 4.4. WebRTC server deployed in a 3rd party network trusted by 66 Mobile Network . . . . . . . . . . . . . . . . . . . . . 8 67 4.5. Deep Packet Inspection . . . . . . . . . . . . . . . . . 8 68 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. 3GPP SIPTO . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. IPv4 traffic offload for Proxy Mobile IPv6 . . . . . . . 10 71 5.3. IPv6 Prefix with Mobility . . . . . . . . . . . . . . . . 11 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 9. Informative References . . . . . . . . . . . . . . . . . . . 12 76 Appendix A. OS Support . . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 The use of cellular broadband for accessing the Internet and other 82 data services via smartphones, tablets, and notebook/netbook 83 computers has increased rapidly as a result of high-speed packet data 84 networks such as HSPA and HSPA+; and now Long-Term Evolution (LTE) is 85 being deployed. Browsers on these devices are becoming similar in 86 capability to their desktop counterparts. So, from that perspective, 87 it is feasible to run WebRTC applications in them. This draft 88 enumerates concerns when real time applications like WebRTC are used 89 on such devices in the above listed networks. 91 This note focuses on QOS and traffic offload aspects, and does not 92 address other mobile network related topics like power consumption, 93 interface switching and congestion control related issues already 94 being discussed in [I-D.isomaki-rtcweb-mobile]. 96 2. Notational Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 This note uses terminology defined in [RFC6459] 104 UE, MS, MN, and Mobile : The terms UE (User Equipment), MS (Mobile 105 Station), MN (Mobile Node), and mobile refer to the devices that are 106 hosts with the ability to obtain Internet connectivity via a 3GPP 107 network. 109 WebRTC Server : Web Server which supports WebRTC. 111 3. Scope 113 This document can be used as a tool to design solution(s) for WebRTC 114 QoS and traffic offload in cellular broadband networks. It describes 115 key use cases, factors common to the use cases, and key solution 116 elements. This note aids WebRTC server designers and network 117 architects to facilitate proper deployment of WebRTC in mobile 118 networks. The WebRTC server could either be deployed in the Mobile 119 Network, in a 3rd party network trusted by the Mobile Network, or in 120 a public network as a Public WebRTC server. 122 4. Cellular Networks - QOS 124 3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release 125 8 [TS23.107]. 3GPP QoS policy configuration defines access agnostic 126 QoS parameters that can be used to provide service differentiation in 127 multi vendor and operator deployments. The concept of a bearer is 128 used as the basic construct for which QoS treatment is applied for 129 uplink and downlink packet flows between the MN and gateway 130 [TS23.401]. A bearer may have more than one packet filter associated 131 and this is called a Traffic Flow Template (TFT). IP source address, 132 source port, IP destination, destination port, L4 protocol, Type of 133 service/Traffic class type, Security parameter index etc identify a 134 packet filter. Each MN can have one or multiple bearers associated 135 with its registration, each supporting different QoS characteristics. 136 An UpLink Traffic Flow Template (UL TFT) is the set of uplink packet 137 filters in a TFT. A DownLink Traffic Flow Template (DL TFT) is the 138 set of downlink packet filters in a TFT. 140 The access agnostic QoS parameters associated with each bearer are 141 QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), 142 MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate). QCI 143 is a scalar that defines packet forwarding criteria in the network. 145 Mapping of QCI values to DSCP is well understood and GSMA has defined 146 standard means of mapping between these scalars [GSMA-IR34]. 147 Primarily LTE offers two types of bearer: Guaranteed Bit rate bearer 148 for real time communication, e.g., Voice calls etc. and Non- 149 Guaranteed bit rate bearer, e.g., best effort traffic for web access 150 etc. Packets mapped to the same EPS bearer receive the same bearer 151 level packet forwarding treatment. 153 The Web Real-Time communication (WebRTC) [I-D.ietf-rtcweb-overview] 154 framework provides the protocol building blocks to support direct, 155 interactive, real-time communication using audio, video, 156 collaboration, games, etc., between two peers' web-browsers. WebRTC 157 application would use Interactive Connectivity Establishment (ICE) 158 protocol [RFC5245] for gathering candidates, prioritizing them, 159 choosing default ones, exchanging them with the remote party, pairing 160 them and ordering them into check lists. Once all of the above have 161 been completed then the participating ICE agents can begin a phase of 162 connectivity checks and eventually select the pair of candidates that 163 will be used for real-time communication. 165 The following subsections describe different aspects of QoS for 166 WebRTC application in a 3GPP Network. 168 4.1. RTP Session Multiplexing 170 [I-D.ietf-rtcweb-rtp-usage] in section 4.4 suggests to put 171 interactive audio and interactive video over the same 5-tuple {dest 172 addr, source addr, protocol, dest port, source port}. Without 173 special handling, the same QoS treatment will be applied to the audio 174 and video flows in the 5-tuple. One potential solution is for the 175 endpoints to set DSCP appropriately on a per-packet basis, as 176 proposed in [I-D.dhesikan-tsvwg-rtcweb-qos]. The packet filters in 177 UL TFT and DL TFT created for each media stream must also include 178 DSCP values, so that multiplexed upstream and downstream traffic is 179 separated and mapped to the correct bearer. That means that there 180 could be multiple bearers (packet filters) with the same 5-tuple but 181 with different DSCP values. 183 In all cases where the browser multiplexes different priority media 184 flows on a single 5-tuple and RTP session, the browser should ensure 185 that the RTCP packets for each media flow receive the same or better 186 priority as the corresponding RTP packets. One way for the browser 187 to ensure this is to construct compound RTCP packets only with RTCP 188 packets of the same priority. 190 RTCWEB is designed for Internet calling, so there are occasions where 191 the remote peer will not be on the same carrier's network, might be 192 on DSL, might be on a DOCSIS network. In that situation, the DSCP 193 bits might not be preserved across the remote peer's network, over 194 the Internet, and into the local carrier's network. When this occurs 195 DSCP markings set by the remote peer are likely to be modified by the 196 intervening network(s). Also, DSCP markings requested by a JS 197 application for upstream traffic may not survive on the path to the 198 radio modem because of OS limitations. Given the limitations 199 described above the following techniques can be used to solve the 200 problem : 202 4.1.1. Disable RTP Multiplexing 204 [I-D.ietf-rtcweb-rtp-usage] in section 4.4 also proposes not to 205 multiplex interactive audio and interactive video over the same 206 5-tuple for compatibility with legacy systems. If DSCP cannot be 207 propagated to differentiate the required QoS treatment of the traffic 208 within the same 5-tuple then RTP Multiplexing can be disabled by 209 either the JS application or a middle box involved in signaling. 210 Even though DSCP markings are frequently modified by intervening 211 equipment, it is preferable to set them appropriately at each browser 212 to reduce the chance of blocking of higher priority packets in common 213 queues on the path between each browser and their corresponding radio 214 bearer(s). 216 4.1.2. Extend Packet Filter to include RTP SSRC 218 RTCWEB is pursuing a option where SSRC(s) for each flow be explicitly 219 signaled in the SDP, thus providing an other way of identifying each 220 flow (i.e., filtering on five-tuple and SSRC value). If 3GPP agrees 221 to extend the packet filter definition to include RTP SSRC, then the 222 UL and DL TFTs would not include any DSCP values and the system would 223 be able to assign each flow to the appropriate bearer/QoS based 224 solely on the assigned SSRC values within the 5-tuple. This requires 225 modification to the 3GPP specifications to extend the TFT filtering 226 mechanism to also support matching on RTP SSRC values. With this 227 extension, multiplexed audio and video media streams using known RTP 228 SSRC values can to be mapped to different EPS bearers, thus receiving 229 different packet forwarding treatment. 231 The TFT with RTP SSRC might not be applicable in some non-WebRTC use 232 cases and in some WebRTC use cases involving interoperation with 233 legacy peers. In some applications the SSRC value associated with a 234 particular media flow might change over time due to resource 235 switching. In any case where the SSRC value might not be known for 236 every media flow, a signaling level entity can either disable 237 multiplexing, assign only media flows that are intended to receive 238 the same QoS treatment to any one 5-tuple, establish another means of 239 determining the SSRC value for each flow so that the TFT can be 240 updated, or introduce a media gateway to map the SSRC value in each 241 flow to an explicitly signaled value. Any solution other than the 242 first (disabling multiplexing) requires further study. 244 4.1.3. Extend Packet Filter to include RTP payload type 246 BUNDLE requires that each payload type (PT) value used across media 247 lines in a bundled group is unique, thus providing a way of 248 identifying the media flow(s) associated with an m line (i.e., 249 filtering on five-tuple and PT values). If 3GPP agrees to extend the 250 packet filter definition to include RTP PT, then the system would be 251 able to assign the flow(s) associated with each m line to the 252 appropriate bearer/QoS based solely on the PT values within the RTP 253 header of packets in the 5-tuple. With this extension, multiplexed 254 audio and video media streams using known RTP PT values can to be 255 mapped to different EPS bearers, thus receiving different packet 256 forwarding treatment. 258 Although this approach is applicable to any use of BUNDLE, there are 259 some limitations. Since a typical m line negotiates the use of 260 multiple payload type values, the TFTs for a typical m line are 261 likely to be more complex then those based on SSRC. Note that if 262 multiple media flows are associated with a particular m line then the 263 network could not distinguish among them and they would of necessity 264 receive the same QoS treatment. Most significantly, since the PT 265 field has a different meaning in RTCP packets, the TFTs for RTP 266 packets do not apply to RTCP and there is no information in the RTCP 267 packets to identify the priority treatment they should receive, even 268 if only RTCP packets of the same intended priority are assembled in 269 any one compound RTCP packet (assuming the DSCP value cannot be 270 trusted). The only solution in this case is to create a TFT for all 271 RTCP packets to assign them the highest priority assigned to any of 272 the RTP packets in the bundle. It is not desirable to use higher 273 priority bandwidth for lower priority RTCP packets but it is less 274 desirable to assign high priority RTCP packets to a lower priority 275 bearer under congestion. SSRC and PT seem viable solutions and and 276 could be used in future based on further study. 278 4.1.4. Data Channel multiplexed with RTP 280 RTCWEB is pursuing designs which multiplex non-RTP flows with RTP 281 flows in the same 5-tuple. In particular for WebRTC, data channel 282 will use SCTP/DTLS/UDP, potentially on the same 5-tuple as SRTP/UDP. 283 Further a data channel could have multiple streams with different 284 priorities multiplexed within it as explained in section 5.1 of 285 [I-D.ietf-rtcweb-data-channel] and a mechanism is required to 286 identify and provide differential QoS per stream. If DSCP marking 287 set by the remote peer is preserved and the OS allows setting per- 288 packet DSCP then data channel can be multiplexed with the media 289 streams. However when DSCP is changed along the path or OS does not 290 allow setting per-packet DSCP then the following aspects needs to be 291 considered : 293 Since SCTP stream IDs are encrypted, there is no way to enhance the 294 TFT definition to enable differential QoS treatment among the 295 multiple streams multiplexed within an single SCTP association on a 296 5-tuple. It is possible to provide the same treatment to all streams 297 within the SCTP association, using one of the following two 298 approaches: 1) after assigning traffic that matches on specific RTP 299 SSRC values within a 5-tuple to certain EPC bearers, assign the 300 remaining traffic within the 5-tuple to another EPC bearer/QoS; or 2) 301 create new TFT extensions to allow identification of other protocols 302 and protocol-specific flow IDs to the extent this information is 303 available in unencrypted fields. Approach 1) is available if only 304 the RTP SSRC or RTP payload extension is defined for TFTs. Approach 305 2) is for further study. The browser can still provide differential 306 treatment to streams with different priority within the available 307 bandwidth provided for a data channel among packets it transmits 308 within a 5-tuple. 310 4.2. Bearer Resource Modification triggered by UE 312 If the UE is using a Public WebRTC server then the UE can request 313 bearer resource modification for an E-UTRAN as explained in section 314 5.4.5 of [TS23.401]. The procedure allows the UE to request 315 modification of bearer resources (e.g., allocation or release of 316 resources) for one traffic flow aggregate with a specific QoS demand. 317 Alternatively, the procedure allows the UE to request modification of 318 the packet filters used for an active traffic flow aggregate, without 319 changing QoS. If accepted by the network, the request invokes either 320 the Dedicated Bearer Activation Procedure or the Bearer Modification 321 Procedure. 323 Problems with this approach are: 325 o When the UE initiates a call using WebRTC application and 326 candidate pairs are successfully nominated for each media stream 327 then WebRTC application should signal the packet filter, QCI and 328 GBR values for each media stream that would initiate bearer 329 resource modification or dedicated bearer activation. The WebRTC 330 application needs to be aware of the QCI/GBR values required for 331 the media streams. 333 o The WebRTC application requires API's to indicate to the OS/Modem 334 the packet filters for each media stream to be added, modified or 335 deleted. The WebRTC application would need API's to indicate to 336 the OS/Modem the QCI and GBR values for each of the packet 337 filters. The OS/Modem would in turn signal this information to 338 the 3GPP network that would result in either bearer resource 339 modification or creation using the Dedicated Bearer Activation 340 Procedure. 342 o WebRTC application may also need API's to trigger the modification 343 of the GBR value for existing packet filters. 345 This problem is not unique to WebRTC and is applicable to any other 346 application that wants to trigger bearer resource modification from 347 the MN. 349 4.3. WebRTC server deployed in 3GPP Network 351 Currently 3GPP networks prioritize flows by examining the SDP in SIP 352 signaling. As WebRTC also uses SDP in signaling to establish a 353 PeerConnection, similar mechanisms can be used to deploy a WebRTC 354 server in a 3GPP network. 356 o 3GPP network cannot prioritize all a=candidate lines described in 357 [RFC5245] until WebRTC server receives an indication of the active 358 media path from the controlling ICE agent. WebRTC server is aware 359 of the active media path only after the controlling ICE endpoint 360 follows the procedures in Section 11.1 of [RFC5245], specifically 361 to send updated offer if the candidates in the m and c lines for 362 the media stream (called the DEFAULT CANDIDATES) do not match 363 ICE's SELECTED CANDIDATES (also see Appendix B.9 of [RFC5245]). 365 o WebRTC server deployed in 3GPP network would need "Rx" interface 366 to the Policy and Charging Rules Function (PCRF). The PCRF is the 367 policy server in the EPC. WebRTC server would act as "Application 368 Function". Dynamic PCC (policy and charging control) rules are 369 derived within the PCRF from information supplied by the AF (such 370 as requested bandwidth for the 5-tuple, Application Identity etc). 371 PCRF forwards PCC rules for the media stream to the Policy 372 Charging and Enforcement Function (PCEF) for packet scheduling, 373 data packet (Diffserv) marking, etc., to allow QOS to be 374 provisioned in the EPC. Bearers would have be modified/created 375 for media streams, assigned and installed on the UE. 377 4.4. WebRTC server deployed in a 3rd party network trusted by Mobile 378 Network 380 TODO 382 4.5. Deep Packet Inspection 383 3GPP has a current work item on "Service Awareness and Privacy 384 Policies" that is chartered to add DPI-related extensions to the PCC 385 architecture [TS23.203]. The (optional) DPI entity in the EPC is 386 called "Traffic Detection Function" (TDF), and it performs 387 application detection and reporting of detected application and its 388 service data flow description to the Policy Control and Charging 389 Rules Function (PCRF) for performing functions such as traffic 390 blocking, redirection, policing for selected flows. 392 If UE is using Public WebRTC server then 394 o The session signaling between the WebRTC application running in 395 the browser and the web server could be using TLS. Moreover 396 WebRTC does not enforce a particular session signaling protocol to 397 be used, so network gateways in 3GPP network would fail to inspect 398 the signalling to identify the 5-tuple used for media stream and 399 thus fail to prioritize media traffic. Hence derived service 400 identification [RFC5897] would not succeed. 402 o Network Gateways by inspecting L7 traffic can only identify RTP 403 but fail to distinguish between IPTV vs. Multimedia, Gaming vs. 404 Voice Chat, Gaming vs. Voice Chat #2 etc as explained in section 405 3.1 - 3.3 of [RFC5897]. 407 5. Mobility 409 The following section lists the potential problems If UE uses Public 410 WebRTC server : 412 5.1. 3GPP SIPTO 414 Given the exponential growth in the mobile data traffic, Mobile 415 Operators are looking for ways to offload some of the IP traffic 416 flows at the nearest access edge that has an Internet peering point. 417 This approach results in efficient usage of the mobile packet core 418 and helps lower the transport cost. Since Release 10, 3GPP starts 419 supporting of Selected IP Traffic Offload (SIPTO) function defined in 420 [TS23.060], [TS23.401]. The SIPTO function allows an operator to 421 offload certain types of traffic at a network node close to the UE's 422 point of attachment to the access network. Limited Mobility support 423 available with SIPTO is explained in section 2.3.3 of 424 [I-D.zuniga-dmm-gap-analysis]. 426 If SIPTO is carried out in a Traffic offload Function (TOF) entity 427 located at the interface of the Radio Access Network i.e. In the 428 path between the Radio stations and the Mobile Gateway (MGW). The 429 TOF decides which traffic to offload and enforces NAT for that 430 traffic. The deployment of a TOF is totally transparent for the UE 431 and hence does not know which traffic is subject to TOF (NATed at the 432 TOF) and which traffic is processed by the MGW. 434 The problem with WebRTC application in such network is that 436 o TOF is not aware of the 5-tuple that will used for media and data 437 channels. ICE agent would gather server reflexive candidates 438 using STUN and relayed candidates are obtained through TURN. If 439 STUN messages are offloaded at TOF then UE would learn the 440 External IP Address/Port provided by the NAT at TOF. Similarly 441 ICE connectivity checks could also be offloaded at TOF. If UE 442 roams, though host candidate addresses may not change but NAT will 443 change resulting in failure to reach the remote peer for the 444 existing media and data channels. If the media and data channels 445 are offloaded at the TOF then UE Mobility would result in 446 disruption of media and data channel traffic. 448 o If UE is using local relayed candidate to reach the remote peer 449 and roams out of the coverage of RNC/HNB GW then NAT between UE 450 and TURN server changes, so UE cannot use the previous TURN 451 allocations and fail to reach the remote peer using local relayed 452 candidate. 454 [I-D.wing-mmusic-ice-mobility] can be used in such scenarios to 455 provide media session mobility. 457 5.2. IPv4 traffic offload for Proxy Mobile IPv6 459 Proxy Mobile IPv6 (or PMIPv6, or PMIP) is a network-based mobility 460 management protocol specified in [RFC5213]. Network-based mobility 461 management enables the same functionality as Mobile IP, without any 462 modifications to the host's Protocol stack. With PMIP the host can 463 change its point-of-attachment to the Internet without changing its 464 IP address.[I-D.ietf-netext-pmipv6-sipto-option] defines a way to 465 signal the Traffic Offload capability of a Mobile Access Gateway 466 (MAG) to the Local Mobility Anchor (LMA) in Proxy Mobile IP Networks. 467 Mobile access gateway has the ability to offload some of the IPv4 468 traffic flows based on the traffic selectors it receives from the 469 local mobility anchor. Using IP Traffic Offload Selector option 470 [I-D.ietf-netext-pmipv6-sipto-option] mobile access gateway will 471 negotiate IP Flows that can be offloaded to the local access network. 473 The problem with WebRTC application in such network is that 475 o MAG and LMA are not aware of the 5-tuple that will used for media 476 and data channels. If STUN messages are offloaded at local access 477 network then UE would learn the External IP Address/Port provided 478 by the NAT at local access network. Similarly ICE connectivity 479 checks could also be offloaded at local access network. If UE 480 roams out of the coverage of Local Access Network though host 481 candidate addresses may not change but NAT will change resulting 482 in failure to reach the remote peer for the existing media and 483 data channels. If the media and data channels are offloaded at 484 the local access network then UE Mobility will result in 485 disruption of media and data channel traffic. 487 o If UE is using local relayed candidate to reach the remote peer 488 and roams out of the coverage of Local Access Network then NAT 489 between UE and TURN server changes, so UE cannot use the previous 490 TURN allocations and fail to reach the remote peer using local 491 relayed candidate. 493 [I-D.wing-mmusic-ice-mobility] can be used in such scenarios to 494 provide media session mobility. 496 5.3. IPv6 Prefix with Mobility 498 The [I-D.korhonen-dmm-prefix-properties] proposes extensions to 499 Prefix Information Option [RFC4861] with a mobility flag bit. This 500 would allow for network based mobility solutions, such as Proxy 501 Mobile IPv6 [RFC5213] or GTP [TS.29274] to explicitly indicate that 502 their prefixes have mobility and therefore, the UE IP stack can make 503 an educated selection between prefixes that have mobility and those 504 that do not. If WebRTC application requires mobility for media 505 streams then it can pick source addresses generated from prefixes 506 with 'M' Flag set to 1 in Prefix Information Option or pick IPv6 507 prefixes without 'M' flag set to 1 if both the endpoints support 508 [I-D.wing-mmusic-ice-mobility]. If WebRTC application requires 509 mobility for media streams and the remote peer does not support 510 [I-D.wing-mmusic-ice-mobility] then it can still pick prefixes 511 without 'M' flag set to 1 when it uses relayed local candidates for 512 the media streams and TURN supports Mobility as explained in section 513 5 of [I-D.wing-mmusic-ice-mobility]. 515 TODO: This section needs more details to be added for WebRTC 516 application to pick suitable prefix. 518 6. Security Considerations 520 This document does not define an architecture nor a protocol; as such 521 it does not raise any security concern. 523 7. IANA Considerations 525 This document does not require any action from IANA. 527 8. Acknowledgments 529 Authors would like to thank Dan Wing, Basavraj Patil, Magnus 530 Westerlund, Markus Isomaki, Cullen Jennings, Harold Lassers, Thomas 531 Anderson, Charles Eckel, Subha Dhesikan , Parthasarathi R, Reinaldo 532 Penno, Prashanth Patil for their comments and review. 534 9. Informative References 536 [GSMA-IR34] 537 , "Inter-Service Provider Backbone Guidelines 5.0, 22 538 December 2010", September 2012. 540 [I-D.dhesikan-tsvwg-rtcweb-qos] 541 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 542 other packet markings for RTCWeb QoS", draft-dhesikan- 543 tsvwg-rtcweb-qos-01 (work in progress), March 2013. 545 [I-D.ietf-netext-pmipv6-sipto-option] 546 Gundavelli, S., Zhou, X., Korhonen, J., and R. Koodli, 547 "IPv4 Traffic Offload Selector Option for Proxy Mobile 548 IPv6", draft-ietf-netext-pmipv6-sipto-option-12 (work in 549 progress), February 2013. 551 [I-D.ietf-rtcweb-data-channel] 552 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 553 Channels", draft-ietf-rtcweb-data-channel-04 (work in 554 progress), February 2013. 556 [I-D.ietf-rtcweb-overview] 557 Alvestrand, H., "Overview: Real Time Protocols for Brower- 558 based Applications", draft-ietf-rtcweb-overview-06 (work 559 in progress), February 2013. 561 [I-D.ietf-rtcweb-rtp-usage] 562 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 563 Communication (WebRTC): Media Transport and Use of RTP", 564 draft-ietf-rtcweb-rtp-usage-06 (work in progress), 565 February 2013. 567 [I-D.isomaki-rtcweb-mobile] 568 Isomaki, M., "RTCweb Considerations for Mobile Devices", 569 draft-isomaki-rtcweb-mobile-00 (work in progress), July 570 2012. 572 [I-D.korhonen-dmm-prefix-properties] 573 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 574 Liu, "IPv6 Prefix Mobility Management Properties", draft- 575 korhonen-dmm-prefix-properties-03 (work in progress), 576 October 2012. 578 [I-D.wing-mmusic-ice-mobility] 579 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 580 "Mobility with ICE (MICE)", draft-wing-mmusic-ice- 581 mobility-03 (work in progress), January 2013. 583 [I-D.zuniga-dmm-gap-analysis] 584 Zuniga, J., Bernardos, C., Melia, T., and C. Perkins, 585 "Mobility Practices and DMM Gap Analysis", draft-zuniga- 586 dmm-gap-analysis-03 (work in progress), December 2012. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997. 591 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 592 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 593 September 2007. 595 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 596 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 598 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 599 (ICE): A Protocol for Network Address Translator (NAT) 600 Traversal for Offer/Answer Protocols", RFC 5245, April 601 2010. 603 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 604 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 605 October 2008. 607 [RFC5897] Rosenberg, J., "Identification of Communications Services 608 in the Session Initiation Protocol (SIP)", RFC 5897, June 609 2010. 611 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 612 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 613 Partnership Project (3GPP) Evolved Packet System (EPS)", 614 RFC 6459, January 2012. 616 [TS.29274] 617 3GPP, , "3GPP, "3GPP Evolved Packet System (EPS); Evolved 618 General Packet Radio Service (GPRS) Tunnelling Protocol 619 for Control plane (GTPv2-C)", 3GPP TS 29.060 8.11.0, 620 December 2010.", September 2012. 622 [TS23.060] 623 3GPP, , ""General Packet Radio Service (GPRS); Service 624 description; Stage 2", June 2012.", September 2012. 626 [TS23.107] 627 3GPP, , "End-to-End Quality of Service (QoS) Concept and 628 Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011- 629 03)", September 2012. 631 [TS23.203] 632 3GPP, , "3GPP, "Policy and charging control architecture", 633 3GPP TS 23.203 10.5.0, December 2011.", September 2012. 635 [TS23.401] 636 3GPP, , "General Packet Radio Service (GPRS) enhancements 637 for Evolved Universal Terrestrial Radio Access Network (E- 638 UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 639 06).", September 2012. 641 Appendix A. OS Support 643 o TODO : In Windows setsockopt is completely disabled. See 644 Knowledge Base Article http://support.microsoft.com/kb/248611. 646 o DSCP is supported and user settable on Symbian S60, Linux, MacOS 647 X. 649 The below program is to set DSCP value of 0x2E was tested 650 on Linux successfully. 651 (Linux k2-server-lnx1 2.6.38-8-generic #42-Ubuntu) 653 #include 654 #include 655 #include 656 #include 657 #include 658 #include 659 #include 660 #include 661 #include 662 #include 664 #define MSG "Hello, World!" 666 int 667 main(void) { 668 int sock = -1; 669 struct sockaddr *local_addr = NULL; 670 struct sockaddr_in sockin, host; 671 int tos = 46 << 2; /* Expedited forwarding (0x2e) */ 672 socklen_t socksiz = 0; 673 char *buffer = NULL; 675 sock = socket(AF_INET, SOCK_DGRAM, 0); 676 if (sock < 0) { 677 fprintf(stderr,"Error: %s\n", strerror(errno)); 678 exit(-1); 679 } 681 memset(&sockin, 0, sizeof(sockin)); 682 sockin.sin_family = PF_INET; 683 sockin.sin_addr.s_addr = inet_addr("10.104.52.145"); 684 socksiz = sizeof(sockin); 686 local_addr = (struct sockaddr *) &sockin; 687 /* Set ToS/DSCP */ 688 if (setsockopt(sock, IPPROTO_IP, IP_TOS, &tos, 689 sizeof(tos)) != 0) { 690 printf("Error setting TOS: %s\n", strerror(errno)); 691 } 692 /* Bind to a specific local address */ 693 if (bind(sock, local_addr, socksiz) != 0) { 694 printf("Error binding to socket: %s\n", strerror(errno)); 695 close(sock); sock=-1; 696 exit(-1); 697 } 699 buffer = (char *) malloc(strlen(MSG) + 1); 700 if ( buffer == NULL ) { 701 printf("Error allocating memory: %s\n", strerror(errno)); 702 close( sock ); sock=-1; 703 exit(-1); 704 } 705 strncpy(buffer, MSG, strlen(MSG) + 1); 706 memset(&host, 0, sizeof(host)); 707 host.sin_family = PF_INET; 708 host.sin_addr.s_addr = inet_addr("10.106.3.95"); 709 host.sin_port = htons(12345); 710 if (sendto(sock, buffer, strlen(buffer), 0, 711 (struct sockaddr *) &host, sizeof(host)) < 0) { 712 printf("Error sending message: %s\n", strerror(errno)); 713 close(sock); sock=-1; 714 free(buffer); buffer=NULL; 715 exit(-1); 716 } 717 free(buffer); buffer=NULL; 718 close(sock); sock=-1; 719 return 0; 720 } 722 Authors' Addresses 724 Tirumaleswar Reddy 725 Cisco Systems, Inc. 726 Cessna Business Park, Varthur Hobli 727 Sarjapur Marathalli Outer Ring Road 728 Bangalore, Karnataka 560103 729 India 731 Email: tireddy@cisco.com 733 John Kaippallimalil 734 Huawei 735 5340 Legacy Drive, Suite 175 736 Plano Texas 75024 738 Email: john.kaippallimalil@huawei.com 740 Ram Mohan Ravindranath 741 Cisco Systems, Inc. 742 Cessna Business Park, Varthur Hobli 743 Sarjapur Marathalli Outer Ring Road 744 Bangalore, Karnataka 560103 745 India 747 Email: rmohanr@cisco.com 749 Richard Ejzak 750 Alcatel-Lucent 751 1960 Lucent Lane 752 Naperville, Illinois 60563-1594 753 US 755 Email: richard.ejzak@alcatel-lucent.com