Multipath TCP K. Xue Internet-Draft J. Guo Intended status: Standards Track P. Hong Expires: January 1, 2013 USTC L. Zhu Huawei June 30, 2012 TMPP for Both Two MPTCP-unaware Hosts draft-xue-mptcp-tmpp-unware-hosts-00 Abstract Transparent MPTCP Proxy(TMPP) is a network-based function, which is under MPTCP architecture. It can help two MPTCP-unaware hosts enjoy multipath support, and can be extensively used both in the access networks and operators' networks. Meanwhile, in MPTCP architecture with TMPP, TMPP needs to modify the received packets and transmit them again(just like gateway in NAT environment). In this document, we also discuss the guarantee for data transfer on TMPP's side. The consideration of data transfer can be expanded to the MPTCP architecture with proxy. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 1, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Xue, et al. Expires January 1, 2013 [Page 1] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Xue, et al. Expires January 1, 2013 [Page 2] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. TMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 3.1. TMPP Locates in the Access Networks . . . . . . . . . . . 7 3.2. TMPP Locates in the Operators' Networks . . . . . . . . . 8 4. Operation with TMPP . . . . . . . . . . . . . . . . . . . . . 9 4.1. Connection Establishment . . . . . . . . . . . . . . . . . 9 4.2. Subflow Management with TMPP . . . . . . . . . . . . . . . 10 4.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Xue, et al. Expires January 1, 2013 [Page 3] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 1. Introduction MPTCP can help increase the resilience of the connectivity and the efficiency of the resource usage [RFC 6182]. When two end hosts communicate with each other, the real connection may pass through multiple sections in the networks. The performance of these sections varies since networks can be divided into wired and wireless, backhaul and core networks. In [I-D.draft-hampel-mptcp-proxies-anchors], MPTCP proxy is only introduced to help two end hosts(One is MPTCP-capable, and the other is MPTCP-unware) communicate with each other. In order to take full advantage of MPTCP, we can use multipath transport in a wider environment. For example, when a household access device is used, the link between the access device and one end host(that connect Internet via this device) performs quite well, especially when the access device is private. If the end host is MPTCP-unaware, it's appropriate to use an access device with MPTCP support. Under this situation, the mobile access device provides MPTCP function towards network side, while runs regular TCP towards end hosts. With this method of using MPTCP, there must exist some scenarios in which both the end hosts are MPTCP-unaware. Currently, it's not supported for two MPTCP-unaware hosts to enjoy multipath transport under MPTCP architecture[I-D.draft-hampel-mptcp-proxies-anchors]. Recently, [I-D.draft-ayar-transparent-sca-proxy] presents a new architecture, named SCA (Splitter/Combiner Architecture), which enables non-MPTCP-capable single-homed hosts to benefit from multipath by means of PEPs (Performance Enhancing Proxies) placed in the access networks. This draft corresponds to this case, but it is controversial since it's completely independent of MPTCP architecture. This document complements the work of Proxy in MPTCP by introducing a kind of network-based function, TMPP (Transparent MPTCP Proxy), which is under MPTCP architecture, and can help two MPTCP-unaware hosts enjoy multipath support. Meanwhile, in MPTCP architecture with TMPP, TMPP needs to modify the received packets and transmit them again(just like gateway in NAT environment). In this document, we also discuss the guarantee for data transfer on TMPP's side. The consideration of data transfer can be expanded to the whole MPTCP architecture with proxy, which is also the further key problem for MPTCP proxy. Xue, et al. Expires January 1, 2013 [Page 4] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 1.1. Background With respect to proxy for MPTCP, there are three kinds of proxies according to whether the end points run MPTCP. o The MPTCP proxy allows one end host to run ordinary TCP (the other end is MPTCP), with the proxy talking TCP to one end and MPTCP to the other. o Both end hosts run MPTCP. The MPTCP anchor allows continuing connectivity after two mobile hosts move simultaneously, or one end host moves and the other is behind a firewall. o Neither end host runs MPTCP. The proxy creates multiple paths between the proxy and the other (TCP) host. [I-D.draft-hampel-mptcp-proxies-anchors] discusses relevant features and signaling enhancements needed for MPTCP proxies and MPTCP anchors, which are both especially suited for wireless access environments. MPTCP proxies and MPTCP anchors in that draft correspond to the first two cases. The MPTCP proxy provides multipath support for MPTCP-capable hosts on behalf of their MPTCP-unaware peers, aiming at facilitating incremental deployment of MPTCP, especially for wireless environments, where traffic is dominated by interactions between mobile clients and network-side servers. The MPTCP anchor permits subflow establishment for MPTCP connections when direct interaction between end hosts fails. This permits tolerance to local IP protocol restrictions and it provides robustness in case of break-before-make mobility events. Since proxy in [I-D.draft-hampel-mptcp-proxies-anchors] is designed for specific scenario, it can't apply to the case when two end points are both MPTCP-unaware, although the split model of TCP-MPTCP-TCP seems to be the combination of two TCP-MPTCP models. The reason is that, according to [I-D.draft-hampel-mptcp-proxies-anchors], when the connection-initiating host is MPTCP-unaware, an initial SYN packet would be added with a MP_CAPABLE option in which PROXY flag is set when passing through an implicit MPTCP network node (if there is one residing on the direct routing path).When another implicit MPTCP network node inspects the SYN packet and finds the MP_CAPABLE option with PROXY flag set, it should not insert MP_CAPABLE to the SYN-ACK response. This will lead to no proxy service support for a connection whenever neither end hosts is MPTCP-capable. In order to provide MPTCP support for a MPTCP-unaware couple of Xue, et al. Expires January 1, 2013 [Page 5] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 peers, new signaling enhancement for connection establishment is needed. At the same time, since there will be two network nodes working for MPTCP transport (see the split model in section 2), acknowledgement of data transfer turns to be complicated, then details in data transfer SHOULD also be considered. So not only connection establishment, but also data transfer should be designed complying with the fundamental MPTCP architecture and signaling. Meanwhile the consideration of data transfer can be expanded to the whole MPTCP architecture with proxy. 1.2. Terminology TMPP: Transparent MPTCP Proxy. 2. TMPP TMPP is a kind of MPTCP network functions. That's to say, it interacts with MPTCP connections through MPTCP signaling. TMPP can reside on MPTCP network nodes. TCP MPTCP TCP +--------+IP A0 +--------+ SFL 0 +--------+IP B0 +--------+ | Host A |------| TMPP A |------------| TMPP B |------| Host B | +--------+ +--------+ +--------+ +--------+ | IP TMPP A | IP TMPP B |\ SFL 1 /| | ------------------- | |\ SFL 2 /| | ------------------- | | : | Figure 1: TCP-MPTCP-TCP split connection with TMPP A couple of TMPPs work together to support MPTCP on behalf of MPTCP- unaware hosts. They split the connection between two MPTCP-unaware hosts into two TCP sections and one MPTCP section (Figure 1). All subflows are established by one TMPP and terminate at its TMPP peer. TMPP relays all packets arriving from one end host to another. TMPP's operation involves inserting or removing MPTCP options, translating locators (address and port) and sequence numbers, and allocating subflows to forward packets. As a result, TMPP MUST maintain the translation relationship of locators and sequence numbers. TMPP is designed as an implicit network function. It resides on the Xue, et al. Expires January 1, 2013 [Page 6] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 direct routing path between two communicating hosts. During the connection establishment, on both two end hosts' side, they are treated as interacting with each other directly, while TMPP can obtain information about locators and MPTCP options via packet inspection, modify packets as necessary and thereby create the split connection. 3. Deployment Scenarios TMPP is predominantly used when two MPTCP-unaware hosts are communicating with each other. At least one of them is located in mobile access networks enabling mobile access gateways with MPTCP function towards network side, or one network element in the network supporting multipath. In other words, the connection split-point may locate in the access side or the operators' networks. 3.1. TMPP Locates in the Access Networks The mobile access gateway provides MPTCP function towards network side, and the multipath connection begins and ends both at the access gateway. +--------+ +--------+ +------+ | Access |--------------|Access | +------+ | Host | | Gateway| : : : |Gateway | | Host | | A |---| A |--------------| B |---| B | | | | | : : : | | | | +------+ | |--------------| | +------+ | (TMPP) | : : : | (TMPP) | +--------+ +--------+ Figure 2: TMPP locates in the access networks For instance, o A household access device is connected to the Internet via multiple access methods, while the end devise via a unique way to the access devise. o A vehicle network has several access methods, while the mobile devices hold by passengers can connect it via only one way (e.g. Wi-Fi). While it's not realistic to make all end devises MPTCP-capable, keeping MPTCP function on network-side will be helpful by ensuring the network access devise is MPTCP-capable. Xue, et al. Expires January 1, 2013 [Page 7] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 In this scenario, it simply solves the problem by providing a MPTCP- capable access gateway, then it only needs network edge devices' support. However, it costs much because the edge device should have several SP signings. 3.2. TMPP Locates in the Operators' Networks Currently, the bottleneck is the access side's entrance into the core network. Although the inside core network works well, the low efficiency in backhaul limits the whole system's performance. The earlier for the multiple paths to aggregate, the better, which is the same to separate, so it's suggested to put the split point into an operator network element. In this way, it will be convenient for operators' flexible management and charging. At the same time, since the multiple paths are managed by the operator, this single connection needs only one signing. Here are two cased of this scenario. 1) The sender or the receiver is limited, the un-limited end host locates in Internet, and a MPTCP-capable P-GW manages multipath. +--------+ +--------+ +------+ | |-------------| | +---------+ | Host | | Access | : : | MPTCP | | Host B | | A |---| Gateway|-------------|-capable|---|(locates | | | | | : : | P-GW | | in the | +------+ | |-------------| | |Internet)| | (TMPP) | : : | (TMPP) | +---------+ +--------+ +--------+ Figure 3: Only one end host is limited 2) Both the sender and the receiver are limited, and there are two MPTCP-capable P-GWs working for them separately. +-------+ +--------+ +--------+ +-------+ +----+ | |-----| | | |-----| | +----+ | | |Access |: :| MPTCP | | MPTCP |: :|Access | | | |Host| |Gateway|-----|-capable| |-capable|-----|Gateway| |Host| | |---| A |: :| P-GW A |---| P-GW B |: :| B |---| | | A | | |-----| | | |-----| | | B | | | | |: :| | | |: :| | | | +----+ |(TMPP) |-----| (TMPP) | | (TMPP) |-----|(TMPP) | +----+ +-------+: :+--------+ +--------+: :+-------+ Xue, et al. Expires January 1, 2013 [Page 8] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 Figure 4: Both two end hosts are limited 4. Operation with TMPP 4.1. Connection Establishment As mentioned in section 1.1, with implicit proxy proposed in [I-D.draft-hampel-mptcp-proxies-anchors], it's not supported when both end hosts are MPTCP-unaware, because the MPTCP network node refuses to add MP_CAPABLE option if the MP_CAPABLE option in the first SYN packet is added by some other MPTCP network node. In order to provide chances for a connection between two MPTCP- unaware hosts also to enjoy multipath support, we make a change which requires another implicit MPTCP network node should also insert MP_CAPABLE to the SYN-ACK response even if finding the PROXY flag set in the MP_CAPABLE option in SYN packets. TCP MPTCP NETWORK MPTCP NETWORK TCP HOST A NODE A NODE B HOST B | | add MP_CAPAPBLE | | | SYN |/ | | |------------------X--------------------+----------------->| | TMPP A | | | P add MP_CAPAPBLE | | | P \| SYN-ACK | |<-----------------+--------------------X------------------| | P | | | P TMPP B | | P add MP_CAPAPBLE P | | ACK P/ P | |------------------+--------------------+----------------->| | P P | Figure 5: Connection initiation by MPTCP-unaware host with TMPP The signaling of connection establishment is as follows: o SYN One MPTCP-unaware host (host A in Figure 2) starts a connection by sending a TCP SYN packet. TMPP resides on the routing path inspects the packet, and then caches the locators of host A and its peer (host B). Based on these locators, TMPP identifies and intercepts the peer's SYN-ACK response packet, as well as data packets to be transported after connection established. Here, TMPP does not change Xue, et al. Expires January 1, 2013 [Page 9] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 the locators contained on the packet (which is different from data transfer). The closest TMPP to host A(namely TMPP A) is responsible for initiating multipath support. Inspecting there is no MP_CAPABLE option in SYN packets received from host A, it adds a MP_CAPABLE option (with FLAG set) into the SYN packet, then forwards the packet to host B. Since another TMPP (TMPP B) potentially works for host B and resides on the routing path just as TMPP A does, SYN packet will be received by TMPP B before host B. TMPP B caches the locators of host A and host B, inspects the MP_CAPABLE option with proxy flag set, then becomes aware of that the host A is MPTCP-unaware and there must be a TMPP working for it. After obtaining this information, TMPP B forwards the SYN packet to host B without any change. o SYN-ACK After TMPP B receives the SYN-ACK response from host B, it creates a key on behalf of host B, inserts a MP_CAPABLE option (proxy flag is set) with this key into the SYN-ACK packet, and forwards the packet to host A. When SYN-ACK packet is passing through TMPP A, TMPP A inspects the proxy flag, then caches the key produced by TMPP B for host B. The key will be used for subflow establishment. o ACK When the ACK response from host A arrives at TMPP A, TMPP A still SHOULD insert a MP_CAPABLE option (with PROXY flag set). Further, it produces a key on behalf of host A, and this key will be cached by TMPP B. 4.2. Subflow Management with TMPP Splitting the established connection into two TCP sections and one MPTCP section, the couples of TMPPs become the end points for all further subflows. These subflows may be initiated by one TMPP and ended by the other TMPP. Both these two TMPPs must inform about their existence and IP addresses with each other. The PROXY flag on those MP_CAPABLE options in SYN or SYN-ACK packets can help tell one TMPP that another TMPP exists and works for a MPTCP-unaware host. However, after connection established, TMPP is still unaware of another TMPP's IP addresses. As a result, TMPP needs to advertise its address via ADD_ADDR (as introduced in [I-D.draft-ietf-mptcp-multiaddressed]) to another TMPP. Xue, et al. Expires January 1, 2013 [Page 10] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 In [I-D.draft-hampel-mptcp-proxies-anchors], considering reliability, SEEK_ADDR option is presented. This method is also accepted in this document. 4.3. Data Transfer TMPP is the endpoint of all subflows, while runs a regular TCP connection with an end host, so TMPP SHOULD translate the transformation mode between MPTCP and TCP by replacing IP header and TCP header when forwards data packets. MPTCP features acknowledgements at connection-level as well as subflow-level[I-D.draft-ietf-mptcp-multiaddressed], in order to provide a robust service to the application. When acknowledges a packet, TMPP receiver should send ACK to TMPP sender at subfow level as soon as the packet is accepted, while send date-level (i.e. connection-level) ACK until accept the end host's (the real end receiver) Acknowledgement. TCP host A TMPP A TMPP B TCP host B |(1)Data packet | | | |---------------->| (2) | | | |----------------->| | | | subflow-level ACK| (3) | | |<-----------------|---------------->| | | | (4)ACK | | | (5)Data-level ACK|<----------------| | (6)ACK |<-----------------| | |<----------------| | | Figure 6: Data transfer with TMPP o TCP host A sends a SYN packet that conveys A and B's IP addresses in IP head and ports and sequence number in TCP head to host B. o TMPP A assigns the segments received from host A to subflows already established between TMPP A and TMPP B, then changes IP head and TCP head (the locators will be changed to those of TMPP A and TMPP B's for the assigned subflows). The SN in the new TCP head and the subflow sequence number in MPTCP option should be the SN of the specific subflow, while the data sequence number in MPTCP option should be the original SN of TCP flow (Figure 7). Since the insertion of MPTCP option and the changes of some of fields, the Check sum and TCP header length should also be reset accordingly. Then TMPP A maintains the translation relationship and sends the packet to TMPP B. Xue, et al. Expires January 1, 2013 [Page 11] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 o With the reception of the packet from TMPP A, TMPP B acknowledges it at the subflow level, sending ACK to TMPP A (the ACK number is at the subflow level). o At the same time, TMPP B recovers the locators to those of host A, removes MPTCP option, and sends the packet to host B. o Host B responds with a simple ACK. o TMPP B establishes and sends ACK to TMPP A at the data level. o TMPP A establishes and sends a simple ACK to host A, with host B's locator. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+----------------------+ | Source port | Destination port | +---------------+---------------+-------+----------------------+ | Sequence Number | +---------------+-----------------------+----------------------+ | ACK Number | +---------------+-----------------------+----------------------+ |TCPheader| | | | | | | | Window | | length | | | | | | | | size | +---------------+-----------------------+----------------------+ | Check sum | Urgent pointer | +---------------+-----------------------+----------------------+ | Kind | Length |Subtype| (reserved) |F|m|M|a|A| +---------------+-----------------------+----------------------+ | Data ACK (4 or 8 octets, depending on flags) | +---------------+-----------------------+----------------------+ | Data Sequence Number (4 or 8 octets, depending on flags) | +---------------+-----------------------+----------------------+ | Subflow Sequence Number (4 octets) | +---------------+---------------+-------+----------------------+ | Data-level Length (2 octets) | Checksum (2 octets) | +---------------+---------------+-------+----------------------+ | | ~ data ~ +---------------+-----------------------+----------------------+ Figure 7: TCP header format As a result of the buffer capacity limitation to the network devices, and in order not to bring too much overhead to these nodes, TMPPs are not required to cache data packets. In case TMPP B in Figure 6 Xue, et al. Expires January 1, 2013 [Page 12] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 doesn't receive the ACK response from host B, the lost packet should be retransmitted by the very beginner of the whole connection, i.e. host A. Optimizations could be negotiated in future versions of this protocol. 5. Security Considerations TBD. 6. References 6.1. Normative References [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. 6.2. Informative References [I-D.ayar-transparent-sca-proxy] Ayar, T., Rathke, B., Budzisz, L., and A. Wolisz, "A Transparent Performance Enhancing Proxy Architecture To Enable TCP over Multiple Paths for Single-Homed Hosts", draft-ayar-transparent-sca-proxy-00 (work in progress), February 2012. [I-D.ford-mptcp-multiaddressed] Ford, A., Raiciu, C., Handley, M., and S. Barre, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ford-mptcp-multiaddressed-00 (work in progress), May 2009. [I-D.hampel-mptcp-proxies-anchors] Hampel, G. and T. Klein, "MPTCP Proxies and Anchors", draft-hampel-mptcp-proxies-anchors-00 (work in progress), February 2012. Xue, et al. Expires January 1, 2013 [Page 13] Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2012 Authors' Addresses Kaiping Xue USTC Room 305, EEIS Department, USTC West Campus Shushan District, Hefei 230027 P. R. China Phone: +86-551-3601334 Email: kpxue@ustc.edu.cn Jing Guo USTC Room 305, EEIS Department, USTC West Campus Shushan District, Hefei 230027 P. R. China Phone: +86-551-3601334 Email: guojing1@mail.ustc.edu.cn Peilin Hong USTC Room 305, EEIS Department, USTC West Campus Shushan District, Hefei 230027 P. R. China Phone: +86-551-3601334 Email: plhong@ustc.edu.cn Lei Zhu Huawei Wireless network research department Haidian District, Beijing 100085 P. R. China Phone: +86-10-60611961 Email: lei.zhu@huawei.com Xue, et al. Expires January 1, 2013 [Page 14]