Internet DRAFT - draft-xue-mptcp-tmpp-unware-hosts
draft-xue-mptcp-tmpp-unware-hosts
Multipath TCP K. Xue
Internet-Draft J. Guo
Intended status: Standards Track P. Hong
Expires: December 22, 2013 USTC
L. Zhu
F. Yu
Huawei
June 20, 2013
TMPP for Both Two MPTCP-unaware Hosts
draft-xue-mptcp-tmpp-unware-hosts-02
Abstract
Transparent MPTCP Proxy(TMPP) is an introduced 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 December 22, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xue, et al. Expires December 22, 2013 [Page 1]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. TMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 6
3.1. TMPP Locates in the Access Networks . . . . . . . . . . . 6
3.2. TMPP Locates in the Operators' Networks . . . . . . . . . 7
4. Operation with TMPP . . . . . . . . . . . . . . . . . . . . . 8
4.1. Connection Establishment . . . . . . . . . . . . . . . . 8
4.2. Subflow Management with TMPP . . . . . . . . . . . . . . 9
4.3. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Xue, et al. Expires December 22, 2013 [Page 2]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
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. There are differences in these
sections 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 the 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(the end host connects Internet via this device) performs quite
well. If the end host is MPTCP-unaware, it's appropriate to use an
access device with MPTCP support in MPTCP environment. Under this
situation, the mobile access device provides MPTCP function towards
network side, while runs traditional TCP towards end hosts.
With this method of using MPTCP, there must be some scenarios in
which both the end hosts are MPTCP-unaware. Currently, it's not
supported for both 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 December 22, 2013 [Page 3]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
1.1. Background
With respect to proxy for MPTCP, there are three kinds of proxies
according to whether the end points run MPTCP fuction.
o One end host runs MPTCP, and the other end runs traditional TCP.
The MPTCP proxy allows two one end hosts separately run traditional
TCP and MPTCP. to run ordinary TCP (the other end is MPTCP), Twith
the proxy uses talking TCP to communicate with one end and MPTCP to
communicate with the other end
o Both end hosts run MPTCP. 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 of two end hosts runs MPTCP, which is not supported in
current MPTCP architecture[I-D.draft-hampel-mptcp-proxies-anchors].
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.
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.
MPTCP anchor permits subflow establishment for MPTCP connections when
direct interaction between end hosts fails. This permits tolerance
to local IP protocol restrictions and provides robustness in case of
break-before-make mobility events.
Since proxy in [I-D.draft-hampel-mptcp-proxies-anchors] is designed
for specific scenarios, which 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
Xue, et al. Expires December 22, 2013 [Page 4]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
response. This will lead to no proxy service supports for a
connection whenever neither end hosts is MPTCP-capable.
In order to provide MPTCP support for a MPTCP-unaware couple of
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. 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 operations involve inserting or removing MPTCP options,
translating locators (address and port) and sequence numbers, and
allocating subflows to forward packets. As a result, TMPP MUST
Xue, et al. Expires December 22, 2013 [Page 5]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
maintain the translation relationship of locators and sequence
numbers.
TMPP is designed as an implicit network function. It resides on the
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 device via a unique way to the access
device.
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).
Xue, et al. Expires December 22, 2013 [Page 6]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
While it's not realistic to make all end devices MPTCP-capable,
keeping MPTCP function on network-side will be helpful by ensuring
the network access device is MPTCP-capable.
In this scenario, it simply solves the problem by providing a MPTCP-
capable access gateway, and it only needs network edge devices'
support. However, it costs nuch 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 cases 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.
Xue, et al. Expires December 22, 2013 [Page 7]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
+-------+ +--------+ +--------+ +-------+
+----+ | |-----| | | |-----| | +----+
| | |Access |: :| MPTCP | | MPTCP |: :|Access | | |
|Host| |Gateway|-----|-capable| |-capable|-----|Gateway| |Host|
| |---| A |: :| P-GW A |---| P-GW B |: :| B |---| |
| A | | |-----| | | |-----| | | B |
| | | |: :| | | |: :| | | |
+----+ |(TMPP) |-----| (TMPP) | | (TMPP) |-----|(TMPP) | +----+
+-------+: :+--------+ +--------+: :+-------+
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 nodes.
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
Xue, et al. Expires December 22, 2013 [Page 8]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
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
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
Xue, et al. Expires December 22, 2013 [Page 9]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
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.
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 that
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
Xue, et al. Expires December 22, 2013 [Page 10]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
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.
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.
Xue, et al. Expires December 22, 2013 [Page 11]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
0 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
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
It is recommended that before two TMPPs establish MPTCP connection,
security preservation is provided by TLS/SSL, which can be further
discussed in the next future work.
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., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", draft-ford-
mptcp-multiaddressed-03 (work in progress), March 2010.
[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 December 22, 2013 [Page 12]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
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 December 22, 2013 [Page 13]
Internet-Draft TMPP for Both Two MPTCP-unaware Hosts June 2013
Fang Yu
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 December 22, 2013 [Page 14]
