MPTCP proxy mechanisms
draft-wei-mptcp-proxy-mechanism-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Xinpeng Wei , Chunshan Xiong , Edward Lopez | ||
| Last updated | 2015-03-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wei-mptcp-proxy-mechanism-01
INTERNET-DRAFT X.Wei
Intended Status: Standards Track C.Xiong
Expires: September 10, 2015 Huawei Technologies
E. Lopez
Fortinet
March 9, 2015
MPTCP proxy mechanisms
draft-wei-mptcp-proxy-mechanism-01
Abstract
Multipath TCP provides the ability to simultaneously use multiple
paths between peers for a TCP/IP session, and it could improve
resource usage within the network and, thus, improve user experience
through higher throughput and improved resilience to network failure.
This document discusses the mechanism of a new network entity, named
MPTCP proxy, which is aimed to assist MPTCP capable peer to use MPTCP
session in case of one of the peers not being MPTCP capable or to act
as an aggregation point for sublfows.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
X.Wei Expires September 10, 2015 [Page 1]
INTERNET DRAFT MPTCP proxy March 9, 2015
Copyright (c) 2015 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
(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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 MPTCP Proxy models . . . . . . . . . . . . . . . . . . . . . . 4
4 MPTCP Proxy Solutions . . . . . . . . . . . . . . . . . . . . . 5
4.1 Mechanisms for on-path MPTCP proxy . . . . . . . . . . . . 5
4.2 Mechanisms for off-path MPTCP proxy . . . . . . . . . . . . 7
5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 10
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
X.Wei Expires September 10, 2015 [Page 2]
INTERNET DRAFT MPTCP proxy March 9, 2015
1 Introduction
Nowadays, the volume of mobile devices, e.g. smart phone, has
increased greatly, and most of these devices have more than one
interface for network communication, for example it's very common for
a smart phone to have one cellular network interface and one WLAN
interface; at the same time, multi-homing scenarios have been more
and more common. All these situations provide a good pre-condition
for the implementation of MPTCP [MPTCP Protocol]. Some network
operators also show interests in MPTCP, they want to utilize MPTCP's
multipath feature to realize optimization of their network
performances, such as resource pooling, network mobility etc.
But there are still some barriers existing for the promotion of
MPTCP, and one of them is that now all most all of the ICP (Internet
Content Provider) servers on the Internet are traditional TCP servers
and there seems no motivation for these traditional servers to embed
MPTCP into their protocol stack, this situation leads to the fact
that when communicating with these servers the MPTCP capable devices
have to fall back to traditional TCP and cannot fully utilize their
MPTCP capability.
Besides, the multipath feature of MPTCP protocol brings impacts on
the performances of some kinds of network middleboxes which are
deployed to enhance network performance or to provide traffic
optimization for network traffic. For example, middleboxes, such as
HTTP proxy, video/audio optimizer and firewall are deployed enroute
by network operators to provide performance enhancements, and all of
these middleboxes need to have knowledge about the entire content of
the traffic flow in order to function properly on the flow. But for
MPTCP traffic, it is likely that only a part of subflows traverse the
middlebox, and leads these middleboxes to be blind about the traffic.
A more detailed description of MPTCP's impacts on middleboxes can be
found in [Lopez]. For all the middlebox scenarios, we can conclude a
basic requirement that the MPTCP traffic should be aggregated at
these middlebox.
To support the use of MPTCP session between a MPTCP host and a TCP
host, and to make MPTCP traffic get benefits from network middlebox
that providing performance enhancement, this document defines a new
entity named MPTCP proxy (or proxy for abbreviation).
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
X.Wei Expires September 10, 2015 [Page 3]
INTERNET DRAFT MPTCP proxy March 9, 2015
MPTCP proxy (proxy): An entity used to support MPTCP session between
MPTCP capable host and non-MPTCP capable host.
UE: User Equipment.
ICP: Internet Content Provider.
3 MPTCP Proxy models
There are mainly two models of proxy for different network scenarios:
the first one is that the proxy is deployed on the common direct routing
path of traffic from different access network, and this kind of proxy is
referred as on-path proxy, an example is shown in Figure 1; the second
one is that the proxy locates only on the direct routing path of traffic
from one of the access networks the MPTCP capable host attached to, and
this kind of proxy is referred as off-path proxy, an example is shown in
Figure 2. In both scenarios, the MPTCP communication could occur between
a MPTCP host and a TCP host, or two MPTCP hosts.
_.---..
,' `.
.' 3GPP
+--| Cellular|-------+
| `. ,' |
+--------+ | `.._,,,' +-|-+ +--------+ +--------------+
|Host(A) |--+ | GW|---|MPTCP |----| Host(B) |
| |--+ ,--'''--. +- -+ |Proxy | | |
+--------+ | ,' `. | +--------+ +--------------+
+-- WLAN ---------+
'
`.._ _,,'
`''
Figure 1: Scenario of on-path proxy deployment
For the scenario shown in Figure 1, the 3GPP cellular network and WLAN
network are usually deployed by a single network operator, and the MPTCP
capable UE supports both 3GPP cellular network interface and WLAN
network interface, in this case operator could locate the proxy on the
path shared by both 3GPP cellular network traffic and WLAN network
traffic.
X.Wei Expires September 10, 2015 [Page 4]
INTERNET DRAFT MPTCP proxy March 9, 2015
_.---..
,' `.
.' 3GPP
+--| Cellular|-------+
| `. ,' |
+--------+ | `.._,,,' +-|-+ +--------+ +--------------+
|Host(A) |--+ | GW|---|MPTCP |----|Host(B) |
| |--+ ,--'''--. +- -+ |Proxy(P)| | |
+--------+ | ,' `. +--|-----+ +--------------+
+-- WLAN . |
------------------+
`.._ _,,'
`''
Figure 2: Scenario of off-path proxy deployment
For the scenario shown in Figure 2, the 3GPP cellular network is
deployed by one mobile network operator, and the WLAN network is
deployed by other operator, e.g. another fixed-line operator. In this
case, the mobile network operator could only locate the proxy on the
direct routing path of 3GPP cellular network traffic.
The following sections will discuss the detailed mechanisms of on-path
proxy and off-path proxy as introduced above.
4 MPTCP Proxy Solutions
4.1 Mechanisms for on-path MPTCP proxy
When the direct routing path of all the sub-flows of a MPTCP capable UE
pass through the same proxy, the proxy will act as on-path proxy, and
the on-path proxy could be transparent to the end host, i.e. end host
itself knows nothing about the existence of the proxy.
X.Wei Expires September 10, 2015 [Page 5]
INTERNET DRAFT MPTCP proxy March 9, 2015
+-------+ +--------------+ +--------------+
|UE(A) | |MPTCP Proxy(P)| |ICP Server(B) |
|(MPTCP)| +--------|-----+ |(TCP) |
+-|-----+ | +-------|------+
|-----SYN+MP_CAPABLE(Key-A)--->|--SYN+MP_CAPABLE(Key-A)-->|
| +---------------------------------+ |
| |create temp. entry for connection| |
| +---------------------------------+ |
| |<--------SYN+ACK ---------|
| +------------+ |
| |create Key-P| |
| +------|-----+ |
<--SYN+ACK+MP_CAPABLE(Key-P)---| |
| | |
-ACK+MP_CAPABLE(Key-A,Key-P)---> |
| |---------ACK-------------->
| +------------+ |
|<------Data----------->|Data Mapping|<----Data---------->|
| +------|-----+ |
| +--|------+ |
|---------SYN+MP_JOIN-------> | |
| | inspect | |
<-----SYN+ACK+MP_JOIN-------- MPTCP | |
| | signal | |
|--- -----ACK+MP_JOIN-------> and | |
| |establish| |
<---------ACK --------------|sub-flow | |
| +--|------+ |
| +------------+ |
|<======Data===========>|Data Mapping|<----Data---------->|
| +------|-----+ |
Figure 3: On-path proxy for connection between MPTCP UE and TCP Server
The function of on-path proxy could mainly be divided into three sub-
functions: supporting for initial MPTCP capability negotiation,
supporting for sub-flow establishment and data mapping. Figure 3 shows
an example signal flow for on-path proxy. The following clauses focus on
the description of each sub-function.
(1) Supporting for initial MPTCP capability negotiation
The MPTCP capable UE starts a connection establishment procedure by
sending the first handshake packet with MP_CAPABLE option, including
UE's Key-A, to ICP server; proxy inspects the packet and creates a
temporary entry, which will be used to match SYN/ACK response from ICP
server, for the connection, then the proxy forwards the packet to ICP
X.Wei Expires September 10, 2015 [Page 6]
INTERNET DRAFT MPTCP proxy March 9, 2015
server.
(2)Supporting for sub-flow establishment
After the initial MPTCP connection established, UE could choose to start
a new MPTCP sub-flow. Because UE is unaware of the existence of proxy,
so UE will start the new sub-flow with ICP server, i.e. the destination
IP address of SYN/MP_JOIN packet is ICP server's IP address.
The proxy inspects sub-flow establishment signal packet, i.e.
SYN/MP_JOIN, and decides whether it has provided proxy function for the
MPTCP session through the token included in MP_JOIN. If proxy has
provided proxy function for the MPTCP session, then it will provide
proxy function for the sub-flow; otherwise proxy will not take any
action on the establishment of sub-flow.
(3)Data mapping
Proxy implements two separate kind of data mapping: forward mapping and
reverse mapping. Forward mapping means mapping data from MPTCP session
to TCP session; reverse mapping means mapping data from TCP session to
MPTCP session. Figure 4 shows the data mapping function of proxy. In
forward mapping, proxy maps data from all sub-flows belonging to MPTCP
session to a single TCP flow in TCP session.
+-----------------------+
MPTCP | Mapping | TCP
+--+ | +-----+ +---+ | +----------+
|UE|<====|>|MPTCP|<<<<>>>>|TCP|<-+-->|ICP server|
+--+ | +-----+ +---+ | +----------+
|proxy |
+-----------------------+
Figure 4: Data mapping function of proxy
4.2 Mechanisms for off-path MPTCP proxy
When proxy locates on the initial sub-flow's direct routing path, but
some other sub-flow's direct routing path might not go through the same
proxy, then proxy could act in off-path model. The main difference
between on-path model proxy and off-path model proxy is that in off-path
model proxy needs to steer sub-flows to proxy, and UE will start new
sub-flow with proxy, but not with its peer host.
X.Wei Expires September 10, 2015 [Page 7]
INTERNET DRAFT MPTCP proxy March 9, 2015
+-------+ +--------------+ +--------------+
|UE(A) | |MPTCP Proxy(P)| |ICP Server(B) |
|(MPTCP)| +--------|-----+ |(TCP) |
+-|-----+ | +-------|------+
|-----SYN+MP_CAPABLE(Key-A)--->|--SYN+MP_CAPABLE(Key-A) ->|
| +---------------------------------+ |
| |create temp. entry for connection| |
| +---------------------------------+ |
| |<--------SYN+ACK ---------|
| +------------+ |
| |create Key-P| |
| +------|-----+ |
<--SYN+ACK+MP_CAPABLE(Key-P,P)-| |
| | |
-ACK+MP_CAPABLE(Key-A,Key-P)--->---------ACK-------------->
| +------------+ |
|<------Data----------->|Data Mapping|<----Data---------->|
| +------|-----+ |
|<------ADD_ADDR(proxy IP)-----| |
| +--|------+ |
|------SYN+MP_JOIN----------> | |
| | inspect | |
<-----SYN+ACK+MP_JOIN-------- MPTCP | |
| | signal | |
|------ACK+MP_JOIN----------> and | |
| |establish| |
<---------ACK --------------|sub-flow | |
| +--|------+ |
| +------------+ |
|<======Data===========>|Data Mapping|<----Data---------->|
| +------|-----+ |
Figure 5: Off-path proxy for connection between MPTCP UE and TCP Server
Similar to on-path model proxy, the function of off-path proxy could
also be divided into three sub-functions: supporting for initial MPTCP
capability negotiation, supporting for sub-flow establishment and data
mapping. Figure 5 shows an example signal flow for on-path proxy.
(1) Supporting for initial MPTCP capability negotiation
The MPTCP capable UE starts a connection establishment procedure by
sending the first handshake packet with MP_CAPABLE option, including
Key-A, to ICP server; proxy inspects the packet and creates a temporary
entry, which is used by proxy to match SYN/ACK response from ICP server,
then the proxy forwards the packet to ICP server.
Proxy inspects the second handshake SYN/ACK packet from ICP server, if
X.Wei Expires September 10, 2015 [Page 8]
INTERNET DRAFT MPTCP proxy March 9, 2015
MP_CAPABLE option is included in SYN/ACK packet, then it means the ICP
server is MPTCP capable and the proxy could choose whether to act as
proxy or not for the connection, for example if the proxy wants to act
as an aggregation point for MPTCP subflow traffics then it could choose
to act proxy function for the MPTCP session; but if the purpose of proxy
is just provide MPTCP support for communication between MPTCP host and
legacy TCP host, then it could choose not to act proxy function; if no
MP_CAPABLE option is included in SYN/ACK, the proxy will generate Key-P
on behalf of ICP server to finish MPTCP connection with UE.
To avoid UE starts the establishment of sub-flow with ICP server's IP
address, proxy notifies UE the existence of itself through sending a P
flag in MP_CAPABLE option in SYN/ACK packet. When UE receives this P
flag it SHOULD NOT start the new sub-flow with ICP server's IP address
any more, but chooses to establish sub-flow with proxy after obtaining
proxy's IP address.
There are reasons why a new P flag needs to be defined for explicit
indication the existence of proxy, instead of implicitly inject the
proxy into MPTCP session using existing MPTCP signaling , e.g. using
ADD_ADDR/ADDR_JOIN to inform MPTCP host of proxy's IP address, and using
REMOVE_ADDR to disable initial subflow between MPTCP host and its peer
host:When a new subflow is to be established, the subflow management
strategy should be considered. As stated in [MPTCP Experience], "The
subflows are created immediately after the creation of the initial
subflow", so MPTCP host might have started a new subflow before a
REMOVE_ADDR is received, due to message delay or lost of REMOVE_ADDR, in
that case the new subflow might be established between MPTCP host and
its peer host but not between MPTCP host and proxy.
(2)Supporting for sub-flow establishment
In off-path model, after MPTCP capable UE has established the initial
sub-flow in MPTCP session with the assistance of proxy, proxy could
advertise its own IP address in ADD_ADDR option to UE, and then UE could
establish new sub-flow with proxy.
(3)Data mapping
The data mapping function for off-path proxy is the same as the function
described in on-path model.
5 Conclusion
This document provides two kinds of proxy modes, which could be used to
support MPTCP capable UE in two different scenarios. For the first on-
path MPTCP proxy, there is no need to modify the current MPTCP stack
implementation of the host; for the off-path MPTCP proxy, it requires
X.Wei Expires September 10, 2015 [Page 9]
INTERNET DRAFT MPTCP proxy March 9, 2015
the MPTCP capable host needs to support a new defined P flag.
6 Security Considerations
The P flag provides a method for explicitly interpose a proxy function
in MPTCP session, but this does not bring more security risks than MPTCP
protocol itself, because even without P flag, an on-path middlebox could
still interpose it in MPTCP session using existing MPTCP protocol
signaling.
7 IANA Considerations
A new flag 'P' in MPTCP MP_CAPABLE option [MPTCP Protocol] needs to be
defined refer to RFC 6824, Section 3.1. This flag is used by proxy to
inform MPTCP capable host the existence of proxy, besides the 'P' flag
could also be used to inform other potential MPTCP proxy its presence.
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
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype|Version|A|P|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Option Sender's Key (64 bits) |
| |
| |
+---------------------------------------------------------------+
| Option Receiver's Key (64 bits) |
| (if option Length == 20) |
| |
+---------------------------------------------------------------+
8 References
8.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[MPTCP Protocol]Ford, A., Raiciu, C., Handley, M., and O.
Bonaventure, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
X.Wei Expires September 10, 2015 [Page 10]
INTERNET DRAFT MPTCP proxy March 9, 2015
8.2 Informative References
[Deng] L.Deng, D.Liu, T.Sun. "draft-deng-mptcp-mobile-network-proxy-
01", April 18, 2014
[Lopez] E. Lopez. "draft-lopez-mptcp-middlebox-00", November 11, 2014
[MPTCP Experience] O. Bonaventure et al. "draft-ietf-mptcp-
experience-00". September 16, 2014
Authors' Addresses
Xinpeng Wei
Huawei Technoligies
Beijing, China
EMail: weixinpeng@huawei.com
Chunshan Xiong
Huawei Technoligies
Beijing, China
EMail: sam.xiongchunshan@huawei.com
Edward Lopez
Fortinet
899 Kifer Road
Sunnyvale, CA 94086
EMail: elopez@fortinet.com
X.Wei Expires September 10, 2015 [Page 11]