idnits 2.17.1 draft-deng-mptcp-mobile-network-proxy-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (February 14, 2014) is 3714 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3550' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC3611' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'IFOM' is defined on line 225, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group L. Deng 3 INTERNET-DRAFT D. Liu 4 Intended Status: Informational T. Sun 5 Expires: August 14, 2014 China Mobile 6 February 14, 2014 8 MPTCP Proxy for Mobile Networks 9 draft-deng-mptcp-mobile-network-proxy-00 11 Abstract 13 This document discusses the motivation and usecases for ISP deployed 14 MPTCP proxies in mobile networks. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3 Considerations for MPTCP Proxy . . . . . . . . . . . . . . . . . 3 57 4 Use-cases for Network deployed MPTCP Proxy . . . . . . . . . . . 4 58 4.1 Dynamic traffic offloading based on network information . . 4 59 4.2 Resource pooling for reduced expense . . . . . . . . . . . . 4 60 5 Requirements for MPTCP Proxy . . . . . . . . . . . . . . . . . 5 61 5.1 Protocol transition . . . . . . . . . . . . . . . . . . . . 5 62 5.2 Traffic mediation . . . . . . . . . . . . . . . . . . . . . 5 63 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1 Introduction 71 Due the scarcity of wireless frequency resources and the instability 72 of wireless signals, combined with the operators' strong motive to 73 preserve service upgrade with smooth network evolution, make full use 74 of mobile terminal's multi-homing capability has long been a quest 75 for mobile networks. 77 In particular, the motivations include resource pooling for better 78 performance (where the network could provide a better performance for 79 resource-intensive services by allowing them to transparently using 80 combined capacities from different RATs) as well as intelligent 81 selection for better accommodation and seamless handover for better 82 mobility. 84 Since R6, 3GPP network defined GAN, interfaces for non-3GPP RATs 85 through GERAN simulation. In R7, I-WLAN was introduced to 3GPP 86 network, for inter-working of PLMN with WLAN RAT. In R8, it is 87 specified that a shared anchor could be used for both I-WLAN and PS 88 RATs, yielding seamless handover. Since R8, there have been work on 89 EPS's mobility support for simultaneous multiple RATs through 90 different PDN connections (MAPCON). Most recently, in R10, it is 91 possible to use EPS's mobility support for simultaneous multiple RATs 92 through a single PDN connection (IFOM). 94 However, there is still not possible for a single IP flow to make 95 full use of multiple interfaces simultaneously. 97 2 Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3 Considerations for MPTCP Proxy 105 MPTCP[RFC6824] offers transparent wireless resource pooling for a 106 single "IP flow" for multi-homing UEs with least network 107 complications, as it effectively implements automatic RAT 108 selection/handover/pooling through TCP's adaptive end-to-end rating 109 mechanism[RFC6356]. 111 However, end-to-end MPTCP solution deprives network's control over 112 service/RAT preference, which is considered to be essential for 113 better operation and service provision in 3GPP networks. As the same 114 time, it has to suffer from compatibility issues with legacy 115 application SPs who are reluctant to support MPTCP natively. 117 Therefore, network deployed MPTCP proxy comes as a compromise, which 118 would certainly benefit MPTCP-enabled UEs without SP's MPTCP 119 deployment by providing protocol adaptation, and at the same time 120 maintain as the wireless network operator's policy enforcement point 121 for their preferred network selection/usage strategies. 123 4 Use-cases for Network deployed MPTCP Proxy 125 For 3rd party service provider who does not supporting MPTCP in their 126 servers, the network deployed proxy could be used to enable MPTCP 127 capability in resource pooling from various radio access networks for 128 enhanced QoE/mobility. 130 As for 3rd party service providers supporting MPTCP, the network 131 deployed proxy could also bring benefits to both the operator and the 132 users by enabling the following benefits. 134 4.1 Dynamic traffic offloading based on network information 136 For real-time interactive services with higher QoS requirements it is 137 expected that 3GPP network can provide better guarantees on the 138 average case. For bulk data transfer who is satisfied with best- 139 effort delivery, Wi-Fi would be a great choice. But the vertical 140 partition does not fit everywhere for the wireless condition itself 141 is quite dynamic and hard to predict. It is important to implement 142 adaptive offloading mechanisms in order to achieve higher resource 143 utility with ever changing radio environment for a possibly moving 144 terminal based on network status, e.g. cell load, AP's signal 145 intensity, user's subscription type, etc. 147 4.2 Resource pooling for reduced expense 149 Due to its low construction and operation expenses, Wi-Fi has been 150 adopted by mobile operators as a complementary RAT for their 151 traditional 3GPP networks. However, different construction and 152 operation expenses of various radio networks result in differences in 153 charging rates/policies for different RATs. 155 For instance, Wi-Fi access may be charged by the access duration, 156 while the 3GPP access may be charged by the consumed data volume. 157 Even if using the same policy, Wi-Fi service is expected to be much 158 cheaper than 3GPP data service. 160 Moreover, different subscription packages may offer various data 161 plans for various RATs. For instance, a basic 4G package may contain 162 free data volume as well free Wi-Fi access too. 164 By enabling MPTCP session between UE and network proxy, via mediating 165 sub-flow data traffic based on their Radio access types and the 166 user's subscription package, it is possible to further reduce the 167 usage expenses from both sides of the network and user. 169 5 Requirements for MPTCP Proxy 171 In order to realize the above use-cases, it is expected that a 172 network deployed MPTCP proxy provide the following functionality: 174 5.1 Protocol transition 176 To allow a MPCTP-enabled UE to make full use of the multiple radio 177 interfaces even if it is communicating with a non-MPTCP server, the 178 proxy should support 180 (a) Detection of UE's MPTCP capability; 182 (b) Negotiation with MPTCP UE on behalf of non-MPTCP SP; 184 (c) Translation/Mapping between TCP and MPTCP sessions. 186 5.2 Traffic mediation 188 (a) Anchoring of sub-flow traffic: On one hand, it is not always 189 possible for a single GW be sitting on the path of every sub-flow 190 from a MPTCP session, hence explicit traffic anchoring to enable a 191 single point of general control over MPTCP sub-flows should be 192 considered. 194 (b) Mediation of sub-flow traffic: On the other hand, for fine- 195 grained mediation of sub-flow traffic, both static and dynamic 196 selection/offloading/pooling policies should be allowed. For 197 instance, "always prefer Wi-Fi over 3GPP" could be a static policy 198 for bulk data transfer services, while "use 3GPP only for backup 199 unless Wi-Fi is congested" could be a dynamic offloading policy for a 200 un-prioritized VoIP service. 202 5 Security Considerations 204 TBA. 206 6 IANA Considerations 208 There is no IANA action in this document. 210 7 References 212 7.1 Normative References 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, March 1997. 217 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 218 Jacobson, "RTP: A Transport Protocol for Real-Time 219 Applications", STD 64, RFC 3550, July 2003. 221 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 222 "RTP Control Protocol Extended Reports (RTCP XR)", 223 RFC 3611, November 2003. 225 [IFOM] IP Flow Mobility and seamless WLAN offload. 3GPP work item 226 450041. 228 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 229 "TCP Extensions for Multipath Operation with Multiple 230 Addresses", RFC 6824, January 2013. 232 [RFC6356] Raiciu, C., Handley, M., and D. Wischik , "Coupled 233 Congestion Control for Multipath Transport Protocols", 234 RFC 6356, October 2011. 236 Authors' Addresses 238 Lingli Deng 239 China Mobile 241 Email: Email: denglingli@chinamobile.com 243 Dapeng Liu 244 China Mobile 246 Email: Email: liudapeng@chinamobile.com 248 Tao Sun 249 China Mobile 251 Email: Email: suntao@chinamobile.com