One document matched: draft-boucadair-mptcp-plain-mode-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-mptcp-plain-mode-09"
ipr="trust200902">
<front>
<title abbrev="Plain MPTCP Transport Mode">An MPTCP Option for
Network-Assisted MPTCP</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." role="editor"
surname="Jacquenet">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Olivier Bonaventure" initials="O." role="editor"
surname="Bonaventure">
<organization>Tessares</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Belgium</country>
</postal>
<phone></phone>
<email>olivier.bonaventure@tessares.net</email>
</address>
</author>
<author fullname="Denis Behaghel" initials="D." surname="Behaghel">
<organization>OneAccess</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>Denis.Behaghel@oneaccess-net.com</email>
</address>
</author>
<author fullname="Stefano Secci" initials="S." surname="Secci">
<organization>UPMC</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>stefano.secci@lip6.fr</email>
<uri></uri>
</address>
</author>
<author fullname="Wim Henderickx" initials="W." role="editor"
surname="Henderickx">
<organization>Nokia/Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country>Belgium</country>
</postal>
<email>wim.henderickx@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Robert Skog" initials="R." role="editor" surname="Skog">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>robert.skog@ericsson.com</email>
</address>
</author>
<author fullname="Suresh Vinapamula " initials="S." surname="Vinapamula">
<organization>Juniper</organization>
<address>
<postal>
<street>1137 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>Sureshk@juniper.net</email>
<uri></uri>
</address>
</author>
<author fullname="SungHoon Seo" initials="S." surname="Seo">
<organization>Korea Telecom</organization>
<address>
<postal>
<street></street>
<city>Seoul</city>
<region></region>
<code></code>
<country>Korea</country>
</postal>
<phone></phone>
<email>sh.seo@kt.com</email>
</address>
</author>
<author fullname="Wouter Cloetens" initials="W." surname="Cloetens">
<organization>SoftAtHome</organization>
<address>
<postal>
<street>Vaartdijk 3 701</street>
<city>3018 Wijgmaal</city>
<region></region>
<code></code>
<country>Belgium</country>
</postal>
<email>wouter.cloetens@softathome.com</email>
</address>
</author>
<author fullname="Ullrich Meyer" initials="U." surname="Meyer">
<organization>Vodafone</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Germany</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>ullrich.meyer@vodafone.com</email>
<uri></uri>
</address>
</author>
<author fullname="Luis M. Contreras" initials="LM." surname="Contreras">
<organization>Telefonica</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Spain</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>luismiguel.contrerasmurillo@telefonica.com</email>
<uri></uri>
</address>
</author>
<author fullname="Bart Peirens" initials="B." surname="Peirens">
<organization>Proximus</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>bart.peirens@proximus.com</email>
<uri></uri>
</address>
</author>
<date />
<abstract>
<t>Because of the lack of Multipath TCP (MPTCP) support at the server
side, some service providers now consider a network-assisted model that
relies upon the activation of a dedicated function called MPTCP
Conversion Point (MCP). Network-Assisted MPTCP deployment models are
designed to facilitate the adoption of MPTCP for the establishment of
multi-path communications without making any assumption about the
support of MPTCP by the communicating peers. MCPs located in the network
are responsible for establishing multi-path communications on behalf of
endpoints, thereby taking advantage of MPTCP capabilities to achieve
different goals that include (but are not limited to) optimization of
resource usage (e.g., bandwidth aggregation), of resiliency (e.g.,
primary/backup communication paths), and traffic offload management.</t>
<t>This document specifies an MPTCP option that is used in the context
of Network-Assisted MPTCP: MP_CONVERT.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The overall quality of connectivity services can be enhanced by
combining several access network links for various purposes - resource
optimization, better resiliency, etc. Some transport protocols, such as
Multipath TCP <xref target="RFC6824"></xref>, can help achieve such
better quality, but failed to be massively deployed so far.</t>
<t>The support of multipath transport capabilities by communicating
hosts remains a privileged target design so that such hosts can directly
use the available resources provided by a variety of access networks
they can connect to. Nevertheless, network operators do not control end
hosts while the support of MPTCP by content servers remains close to
zero.</t>
<t>Network-Assisted MPTCP deployment models are designed to facilitate
the adoption of MPTCP for the establishment of multi-path communications
without making any assumption about the support of MPTCP capabilities by
communicating peers. Network-Assisted MPTCP deployment models rely upon
MPTCP Conversion Points (MCPs) that act on behalf of hosts so that they
can take advantage of establishing communications over multiple paths.
MCPs can be deployed in CPEs (Customer Premises Equipment), as well as
in the provider's network. MCPs are responsible for establishing
multi-path communications on behalf of endpoints. Further details about
the target use cases are provided in <xref target="tuc"></xref>.</t>
<t>Most of the current operational deployments that take advantage of
multi-interfaced devices rely upon the use of an encapsulation scheme
(such as <xref target="I-D.zhang-gre-tunnel-bonding"></xref><xref
target="TR-348">, </xref>). The use of encapsulation is motivated by the
need to steer traffic towards the concentrator and also to allow the
distribution of any kind of traffic besides TCP (e.g., UDP) among the
available paths without requiring any advanced traffic engineering
tweaking technique in the network to intercept traffic and redirect it
towards the appropriate MCP.</t>
<t>Current operational MPTCP deployments by network operators are
focused on the forwarding of TCP traffic. The design of such deployments
sometimes assumes the use of extra signalling provided by SOCKS <xref
target="RFC1928"></xref>, at the cost of additional management
complexity and possible service degradation (e.g., up to 8 SOCKS
messages may have to be exchanged between two MCPs before an MPTCP
connection is established, thereby yielding several tens of milliseconds
of extra delay before the connection is established) .</t>
<t>To avoid the burden of encapsulation and additional signalling
between MCPs, this document explains how a plain transport mode is
enabled, so that packets are exchanged between a device and its upstream
MCP without requiring the activation of any encapsulation scheme (e.g.,
IP-in-IP <xref target="RFC2473"></xref>, GRE <xref
target="RFC1701"></xref>). This plain transport mode also avoids the
need for out-of-band signalling, unlike the aforementioned SOCKS
context.</t>
<t>The solution described in this document also works properly when NATs
are present in the communication path between a device and its upstream
MCP. In particular, the solution in this document accommodates
deployments that involve CGN (Carrier Grade NAT) upstream the MCP.</t>
<t>Network-Assisted MPTCP deployment and operational considerations are
discussed in <xref
target="I-D.nam-mptcp-deployment-considerations"></xref>.</t>
<t>The plain transport mode is characterized as follows:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>No encapsulation required (no tunnels, whatsoever).</t>
<t>No out-of-band signaling for each MPTCP subflow is required.</t>
<t>Carries any protocol for the benefit of massive MPTCP
adoption.</t>
<t>Avoids interference with native MPTCP connections.</t>
<t>Targets both on-path and off-path MCPs.</t>
<t>Accommodates various deployment contexts, such as those that
require the preservation of the source IP address and others
characterized by an address sharing design.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Terminology">
<t>The reader should be familiar with the terminology defined in <xref
target="RFC6824"></xref>.</t>
<t>This document makes use of the following terms:<list style="symbols">
<t>Client: an endhost that initiates transport flows forwarded along
a single path. Such endhost is not assumed to support multipath
transport capabilities.</t>
<t>Server: an endhost that communicates with a client. Such endhost
is not assumed to support multipath transport capabilities.</t>
<t>Multipath Client: a Client that supports multipath transport
capabilities.</t>
<t>Multipath Server: a Server that supports multipath transport
capabilities. Both the client and the server can be single-homed or
multi-homed. However, for the use cases discussed in this document,
the number of interfaces available at the endhosts is not
relevant.</t>
<t>Transport flow: a sequence of packets that belong to a
unidirectional transport flow and which share at least one common
characteristic (e.g., the same destination address). TCP and SCTP
flows are composed of packets that have the same source and
destination addresses, the same protocol number and the same source
and destination ports.</t>
<t>Multipath Conversion Point (MCP): a function that terminates a
transport flow and relays all data carried in the flow into another
transport flow. <vspace blankLines="1" />MCP is a function that
converts a multipath transport flow and relays it over a single path
transport flow and vice versa.</t>
</list></t>
</section>
<section anchor="tuc" title="Target Use Cases">
<t>We consider two important use cases in this document. We briefly
introduce them in this section and leave the details to <xref
target="uc1"></xref> and <xref target="uc2"></xref>. The first use case
is a Multipath Client that interacts with a remote Server through a MCP
(<xref target="mpc"></xref>). The second use case is a multi-homed CPE
that includes a MCP and interacts with a remote Server through a
downstream MCP (<xref target="mcpe"></xref>).</t>
<section anchor="mpc" title="Multipath Client">
<t>In this use case, the Multipath Client would like to take advantage
of MPTCP even if the Server does not support MPTCP. A typical example
is a smartphone that could use both WLAN and LTE access networks to
reach a Server in order to achieve higher bandwidth or better
resilience.</t>
<t><figure align="center" anchor="legs2"
title="Network-assisted MPTCP (Host-based Model)">
<artwork><![CDATA[+--+ +-----+ +--+
|H1| | MCP | |RM|
+--+ +-----+ +--+
| | |
|<==================MPTCP Leg==============>|<---TCP -->|
| | |
Legend:
H1: Host 1
MCP: Multipath Conversion Point
RM: Remote Machine
]]></artwork>
</figure>In reference to <xref target="legs2"></xref>, the MCP
terminates the MPTCP connection established by the Client and binds it
to a TCP connection towards the remote Server. Two deployments of this
use case are possible.</t>
<t>A first deployment is when the MCP is on the path between the
Multipath Client and the Server. In this case, the MCP can terminate
the MPTCP connection initiated by the Client and binds it to a TCP
connection that the MCP establishes with the Server. Because the MCP
is not located on all default forwarding paths, the MPTCP connection
must be initiated by using the path where the MCP is located.</t>
<t>A second deployment is when the MCP is not on the path between the
Multipath Client and the Server. In this case, the Client must first
initiate a connection towards the MCP and request it to initiate a TCP
connection towards the Server. This is what the SOCKS protocol
performs by exchanging control messages to create appropriate mappings
to handle the connection. Unfortunately, this requires additional
round-trip-time that affects the performance of the end-to-end data
transfer, in particular for short-lived connections. This document
proposes the MP_CONVERT option which is carried in the SYN segment of
the initial subflow. This SYN segment is sent towards the MCP. The
MP_CONVERT option contains the destination address (and optionally a
port number) of the Server. Thanks to this information, the MCP can
immediately establish the TCP connection with the Server without any
additional round-trip-time, unlike a SOCKS-based design.</t>
</section>
<section anchor="mcpe" title="Multipath CPE">
<t>In this use case, neither the Client nor the Server support MPTCP.
Two MCPs are used as illustrated in <xref target="legs"></xref>. The
upstream MCP is embedded in the CPE while the downstream MCP is
located in the provider's network. The CPE is attached to multiple
access networks (e.g., xDSL and LTE). The upstream MCP transparently
terminates the TCP connections initiated by the Client and converts
them into MPTCP connections.</t>
<t><figure align="center" anchor="legs"
title="Network-assisted MPTCP (CPE-based Model)">
<artwork align="center"><![CDATA[ Upstream Downstream
+--+ +-----+ +-----+ +--+
|H1| | MCP | | MCP | |RM|
+--+ +-----+ +-----+ +--+
| | | |
|<---TCP--->|<========MPTCP Leg===========>|<---TCP--->|
| | | |
]]></artwork>
</figure></t>
<t>The same considerations detailed in <xref target="mpc"></xref>
apply for the insertion of the downstream MCP in an MPTCP
connection.</t>
</section>
</section>
<section anchor="plain" title="MP_CONVERT Option">
<t>The MP_CONVERT (MC) option carries the source/destination IP
addresses and/or port numbers of the origin source and destination
nodes. It is also used to indicate whether the data carried in the
packet is relayed from a native TCP connection or refers to the use of
another transport protocol.</t>
<t>The format of the option is shown in <xref target="pm"></xref>.</t>
<t><figure align="center" anchor="pm" title="MP_CONVERT Option">
<artwork><![CDATA[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|D|Flags| Protocol |
+---------------+---------------+-------+-+-----+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) |
+-------------------------------+
]]></artwork>
</figure>The description of the fields is as follows:</t>
<t><list style="symbols">
<t>Kind and Length: are the same as those defined in Section 3 of
<xref target="RFC6824"></xref>. The minimum size of this option is 4
bytes.</t>
<t>Subtype: to be defined by IANA (<xref target="IANA"></xref>).
Implementations may use the "0xe" subtype encoding for early
deployment purposes in managed networks.</t>
<t>D-bit (Direction bit): this flag indicates whether the enclosed
IP address (and port number) reflects the source or the destination
IP address (and port number). When the D-bit is set, the enclosed IP
address must be interpreted as the source IP address. When the D-bit
is unset, the enclosed IP address must be interpreted as the
destination IP address.</t>
<t>"Flags" bits: are reserved bits for future assignment as
additional flag bits. These additional flag bits MUST each be set to
zero and MUST be ignored upon receipt.</t>
<t>Protocol: conveys the protocol number as assigned by IANA <xref
target="proto_numbers"></xref>.</t>
<t>Address: includes a source or destination IP address. The address
family is determined by the "Length" field. Concretely, a MP_CONVERT
option that carries an IPv4 address has a Length field of 8 bytes
(or 10, if a port number is included). A MP_CONVERT option that
carries an IPv6 address has a Length of 20 bytes (or 22, if a port
number is included). This field is optional.</t>
<t>Port: If the D-bit is set (resp. unset), a source (resp.
destination) port number may be associated with the IP address. This
field is valid for protocols that use a 16 bit port number (e.g.,
UDP, TCP, SCTP). This field is optional.</t>
</list></t>
<t>The MP_CONVERT option is a variable length MPTCP option that MUST NOT
be used in TCP segments whose SYN flag is reset. This option can only
appear in the SYN used to create the initial subflow of a Multipath TCP
connection (see the example in <xref target="pmf"></xref>). </t>
<t>Up to two MP_CONVERT options can appear inside a SYN segment. If two
MP_CONVERT options are included, these options MUST NOT have the same
D-bit value.</t>
<t><figure align="center" anchor="pmf"
title="Carrying the MP_CONVERT Option">
<artwork align="center"><![CDATA[+----+ +-----+ +--+
| C | | MCP | |S |
+----+ +-----+ +--+
| | ________________________________| |
| / Initial subflow \ |
| |========SYN(MP_CAPABLE+MC(S))===>| |
| | |--SYN------->|
| | |<--SYN/ACK---|
| |<====SYN/ACK(MP_CAPABLE)=========| |
| | ... | |
| \ ________________________________/ |
.... ....
| | ________________________________| |
| / Additional subflow \ |
| \ ________________________________/ |
Legend:
<===>: MPTCP leg
<--->: TCP leg ]]></artwork>
</figure>The MP_CONVERT option MUST be included in the SYN payload.
<list style="empty">
<t>NOTE 1: Given the length of the MP_CONVERT option, especially
when IPv6 addresses are used, and the set of TCP options that are
likely to be included in a SYN message, it will not always be
possible to place the MP_CONVERT option inside the dedicated TCP
option space.</t>
<t>NOTE 2: Including data in a SYN payload is allowed as per Section
3.4 of <xref target="RFC0793"></xref>.</t>
<t>NOTE 3: Stateless approaches that rely on inserting the
MP_CONVERT option in all packets are out of scope.</t>
<t>DISCUSSION NOTE: ADD DETAILS ABOUT THE NEED FOR AN EXPLICIT
SIGNAL THAT MPTCP OPTIONS ARE INCLUDED IN THE SYN PAYLOAD?</t>
</list></t>
<t>If the MP_CONVERT option appears in either a SYN segment that does
not include the MP_CAPABLE option or a segment whose SYN flag is reset,
it MUST be ignored. An implementation MAY log this event since it likely
indicates an operational issue.</t>
<t>If the original SYN message contains data in its payload (e.g., <xref
target="RFC7413"></xref>), that data MUST be placed right after the
MP_CONVERT and "End of Options List" (EOL) options when generating the
SYN in the MPTCP leg. The EOL option serves as a marker to delineate the
end of the TCP options and the beginning of the data included in the
original SYN .</t>
<t>An implementation MUST ignore MP_CONVERT options that include
multicast, broadcast, and host loopback addresses <xref
target="RFC6890"></xref>. Concretely, an implementation that receives an
MP_CONVERT option with such addresses MUST silently tear down the MPTCP
connection.</t>
<t>When an MCP creates an MPTCP connection triggered by an incoming
packet, it MUST copy in the 'Protocol' field of the MP_CONVERT option
the value of the 'Protocol' field (resp. type of the transport header)
of the IPv4 (resp. IPv6) header of this incoming packet. The MCP may be
configured to enable traffic aggregation for some transport protocols
because of the nature of the service they relate to. By default, the
'Protocol' field MUST be set to 6 (TCP).</t>
</section>
<section anchor="uc1"
title="MPTCP Connections from a Multipath TCP Client">
<t></t>
<section title="Description">
<t>The simplest usage of the MP_CONVERT option is when a Multipath TCP
Client wants to use MPTCP to efficiently utilise different network
paths (e.g., WLAN and LTE from a smartphone) to reach a server that
does not support Multipath TCP. The basic operation is illustrated in
<xref target="ex1"></xref>.</t>
<t>To use its multipath capabilities to establish an MPTCP connection
over the available networks, the Client splits its end-to-end
connection towards the TCP Server into two:<list style="format (%d)">
<t>An MPTCP connection, that typically relies upon the
establishment of one subflow per network path, is established
between the client and the MCP.</t>
<t>A TCP connection that is established by the MCP with the
server.</t>
</list></t>
<t>Any data that is eligible to be transported over the MPTCP
connection is sent by the Client towards the MCP over the MPTCP
connection. The MCP then forwards these data over the regular TCP
connection until they reach the server. The same forwarding principle
applies for the data sent by the Server over the TCP connection with
the MCP.</t>
<t><figure align="center" anchor="ex1"
title="A Multipath TCP Client interacts with a Server through a Multipath Conversion Point">
<artwork><![CDATA[ C <===========>MCP <------------> S
+<============>+
Legend:
<===>: subflows of the upstream MPTCP connection
<--->: downstream TCP connection
]]></artwork>
</figure></t>
</section>
<section anchor="oneproxy" title="Theory of Operation">
<t>We assume in this section that the Multipath TCP Client has been
configured with the IP address of one or more MCPs which convert the
Multipath TCP connection into a regular TCP connection. The address of
such MCPs can be statically configured on the Client, dynamically
provisioned to the MPTCP Client by means of a DHCP option <xref
target="I-D.boucadair-mptcp-dhc"></xref> or by any other means that
are outside the scope of this document.</t>
<t>Conceptually, the MCP acts as a relay between an upstream MPTCP
connection and a downstream TCP connection. The MCP has at least a
single IP address that is reachable from the Multipath TCP Client. It
may be assigned other IP addresses. For the sake of simplicity, we
assume in this section that the MCP has a single IP address denoted
MCP@. Similarly, we assume that the client has two addresses C@1 and
C@2 while address S@ is assigned to the server.</t>
<t>The MCP maps an upstream MPTCP connection (and its associated
subflows) onto a downstream TCP connection. On the MCP, an established
Multipath TCP connection can be identified by the local Token that was
assigned upon reception of the SYN segment.</t>
<t>This Token is guaranteed to be unique on the MCP (provided that it
has a single IP address) during the entire lifetime of the MPTCP
connection. The 4-tuple (IP src, IP dst, Port src, Port dst) is used
to identify the downstream TCP connection.</t>
<t>To initiate a connection to a remote server S, the Multipath TCP
Client sends a SYN segment towards the MCP that includes the
MP_CONVERT option described in <xref target="pm"></xref>. The
destination address of the SYN segment is the IP address of the MCP.
The MP_CONVERT option included in the SYN contains the IP address and
optionally the destination port of the Server (see <xref
target="fe1"></xref>).</t>
<t><figure align="center" anchor="fe1"
title="Single-ended MCP Flow Example">
<artwork align="center"><![CDATA[+----+ +-----+ +--+
| C | | MCP | |S |
+----+ +-----+ +--+
C@1 C@2 MCP@ S@
| | ________________________________| |
| / Initial subflow \ |
| |=======SYN(MP_CAPABLE+MC(S@))===>| |
| | |--SYN---->|
| | |<-SYN/ACK-|
| |<====SYN/ACK(MP_CAPABLE)=========| |
| | ... | |
| \ ________________________________/ |
.... ....
| | ________________________________| |
| / Additional subflow \ |
| \ ________________________________/ |
Legend:
<===>: MPTCP leg
<--->: TCP leg ]]></artwork>
</figure></t>
<t>The MCP processes this SYN segment as follows. First, it generates
the local key and a unique Token for the Multipath TCP connection.
This Token identifies the MPTCP connection. It is passed to the MCP
together with the contents of the MP_CONVERT option (i.e., the address
of the destination server) and the destination port.</t>
<t>The MCP then establishes a TCP connection with the destination
server. If the received MP_CONVERT option contains a port number, it
is used as the destination port of the outgoing TCP connection that is
being established by the MCP. Otherwise, the destination port of the
upstream MPTCP connection is used as the destination port of the
downstream TCP connection. The MCP creates a flow entry for the
downstream TCP connection and maps the upstream MPTCP connection onto
the downstream TCP connection.</t>
<t>The downstream TCP connection is considered to be active upon
reception of the SYN+ACK segment sent by the destination server. The
reception of this segment triggers the MCP that confirms the
establishment of the upstream MPTCP connection by sending a SYN+ACK
segment towards the Multipath TCP Client.</t>
<t>At this point, there are two established connections. The endpoints
of the upstream Multipath TCP connection are the Multipath TCP Client
and the MCP. The endpoints of the downstream TCP connection are the
MCP and the Server. These two connections are bound by the MCP.</t>
<t>All the techniques defined in <xref target="RFC6824"></xref> can be
used by the upstream Multipath TCP connection. In particular, the
subflows established over the different network paths can be
controlled by either the Multipath TCP Client or the MCP. It is likely
that the network operators that deploy MCPs will define policies for
the utilisation of the MCP. These policies are discussed in <xref
target="I-D.nam-mptcp-deployment-considerations"></xref>.</t>
<t>Any data received by the MCP on the upstream Multipath TCP
connection will be forwarded by the MCP over the bound downstream TCP
connection. The same applies for data received over the downstream TCP
connection which will be forwarded by the MCP over the upstream
Multipath TCP connection.</t>
<t>One of the functions of the MCP is to maintain the binding between
the upstream Multipath TCP connection and the downstream TCP
connection. If the downstream TCP connection fails for some reason
(excessive retransmissions, reception of a RST segment, etc.), then
the MCP SHOULD force the teardown of the upstream Multipath TCP
connection by transmitting a FASTCLOSE. Similarly, if the upstream
Multipath TCP connection fails for some reason (e.g., reception of a
FASTCLOSE), the MCP SHOULD tear the downstream TCP connection down and
remove the flow entries.</t>
<t>The same reasoning applies when the upstream Multipath TCP
connection ends with the transmission of DATA_FINs. In this case, the
MCP SHOULD also terminate the bound downstream TCP connection by using
FIN segments. If the downstream TCP connection terminates with the
exchange of FIN segments, the MCP SHOULD initiate a graceful
termination of the bound upstream Multipath TCP connection.</t>
<t>An MCP SHOULD associate a lifetime with the Multipath TCP and TCP
flow entries. In this case, it SHOULD use the same lifetime for each
pair of bounded connections.</t>
</section>
</section>
<section anchor="uc2"
title="MPTCP Connections Between Single Path Client and Server">
<t></t>
<section title="Description">
<t>There are situations where neither the client nor the server can
use multipath transport protocols albeit network providers would want
to optimize network resource usage by means of multi-path
communication techniques. Hybrid access service offerings are typical
business incentives for such situations, where network operators
combine a fixed network (e.g., xDSL) with a wireless network (e.g.,
LTE). In this case, as illustrated in <xref target="ex2"></xref>, two
MCPs are used for each flow. The first MCP, located downstream of the
client, converts the single path TCP connection originated from the
client into a Multipath TCP connection established with a second MCP.
The latter will then establish a TCP connection with the destination
server.</t>
<t><figure align="center" anchor="ex2"
title="A Client interacts with a Server through an upstream and a downstream Multipath Conversion Points">
<artwork><![CDATA[ Upstream Downstream
C <---> MCP <===========> MCP <------------> S
+<=============>+
Legend:
<===>: MPTCP leg
<--->: TCP leg ]]></artwork>
</figure></t>
</section>
<section title="Theory of Operation">
<t></t>
<section title="Downstream MCP">
<t>The downstream MCP can be deployed on-path or off-path. If the
downstream MCP is deployed off-path, its behavior is described in
<xref target="oneproxy"></xref>.</t>
<t>If the downstream MCP is deployed on-path, it only terminates
MPTCP connections that carry an empty MP_CONVERT option inside their
SYN (i.e., no address is conveyed). If the MCP receives a SYN
segment that contains the MP_CAPABLE option but no MP_CONVERT
option, it MUST forward the SYN to its final destination without any
modification.</t>
</section>
<section title="Upstream MCP">
<t>The upstream and downstream MCPs cooperate. The upstream MCP may
be configured with the addresses of downstream MCPs. If the
downstream MCP is deployed on-path, the upstream MCP inserts an
MP_CONVERT option that carries no IP address.</t>
<t>In this section, we assume that the upstream MCP has been
configured with one address of the downstream MCP. This address can
be configured statically, dynamically distributed by means of a DHCP
option <xref target="I-D.boucadair-mptcp-dhc"></xref> or by any
other means that are outside the scope of this document.</t>
<t>We assume that the upstream MCP has two addresses uMCP@1 and
uMCP@2 while the downstream MCP is assigned a single IP address
dMCP@.</t>
<t>The upstream MCP maps an upstream TCP connection onto a
downstream MPTCP connection (and its associated subflows) . On the
upstream MCP, an established MPTCP connection can be identified by
the local Token that was assigned upon reception of the SYN segment
from the Client.</t>
<t>To initiate a connection with a remote server S, the Client sends
a SYN segment that is intercepted by the upstream MCP which in turns
initiates an MPTCP connection towards its downstream MCP that
includes the MP_CONVERT option described in <xref
target="pm"></xref>. The destination address of the SYN segment is
the IP address of the downstream MCP. The MP_CONVERT option included
in the SYN contains the IP address and optionally the destination
port of the Server; this information is extracted from the SYN
message received over the upstream TCP connection.</t>
<t>Concretely, the upstream MCP processes the SYN segment received
from the Client as follows.</t>
<t>First, it generates the local key and a unique Token for the
Multipath TCP connection to identify the MPTCP connection. It
extracts the destination IP address and, optionally, the destination
port that will then be carried in a MP_CONVERT option. The upstream
MCP establishes an MPTCP connection with the downstream MCP. The
upstream MCP creates a flow entry for the downstream MPTCP
connection and maps the upstream TCP connection onto the downstream
MPTCP connection.</t>
<t>The downstream MPTCP connection is considered to be active upon
reception of the SYN+ACK segment from the downstream MCP. The
reception of this segment triggers the upstream MCP that confirms
the establishment of the upstream TCP connection by sending a
SYN+ACK segment towards the TCP Client.</t>
<t>At this point, there are two established connections maintained
by the upstream MCP:<list style="format (%d)">
<t>The endpoints of the upstream TCP connection are the Client
and the upstream MCP.</t>
<t>The endpoints of the downstream MPTCP connection are the
upstream MCP and the downstream MCP.</t>
</list></t>
<t>These two connections are bound by the upstream MCP. An example
is shown in <xref target="fe2"></xref>.</t>
<t><figure align="center" anchor="fe2"
title="Dual-Ended MCP Flow Example">
<artwork><![CDATA[ Upstream Downstream
+--+ +-----+ +-----+ +--+
|C1| | MCP | | MCP | |S1|
+--+ +-----+ +-----+ +--+
C@1 uMCP@1 uMCP@2 dMCP@ S@
| | |______________________________| |
|--SYN--->|/ Initial subflow \ |
| |=======SYN(MP_CAPABLE+MC(S@))==>| |
| | |--SYN---->|
| | |<-SYN/ACK-|
| |<====SYN/ACK(MP_CAPABLE)========| |
|<SYN/ACK-| ... | |
| \ ______________________________/ |
.... ....
| | | ____________________________ | |
| | |/ Additional subflow \| |
| | |\ ___________________________/| |
....
]]></artwork>
</figure>All the techniques defined in <xref
target="RFC6824"></xref> can be used by the MPTCP connection. In
particular, the utilisation of the different network paths can be
controlled by one MCP or the other.</t>
<t>Any data received by the upstream MCP over the upstream TCP
connection will be forwarded by the MCP over the bound downstream
MPTCP connection, assuming such data are eligible to MPTCP
transport. The same applies for data received over the downstream
MPTCP connection which will be forwarded by the upstream MCP over
the upstream TCP connection.</t>
<t>The same considerations as in <xref target="oneproxy"></xref>
apply for the maintenance of the connections by the upstream
MCP.</t>
</section>
</section>
</section>
<section title="Demux Native MPTCP Connections From Proxied MPTCP Connections">
<t><xref target="uc2"></xref> assumes that the Clients that use the
upstream MCP do not support MPTCP. If a Multipath Client is attached to
the upstream MCP, it should be possible for this client to establish an
MPTCP connection with a Multipath Server without using the MCPs.</t>
<t>Because MPTCP connections are not destined explicitly to an MCP, an
on-path MCP instance will need extra means to distinguish "native" MPTCP
connections from "proxied" ones. The subsequent risk is that native
MPTCP communications will be reverted to TCP connections as shown in
<xref target="uc1a"></xref>. In this example, we suppose that C2 and S2
are MPTCP-compatible, but C1 and S1 are not.</t>
<t><figure align="center" anchor="uc1a"
title="Example of a Broken E2E MPTCP Connection (On-path)">
<artwork><![CDATA[ Upstream Downstream
+--+ +-----+ +-----+ +--+
|C1| | MCP | | MCP | |S1|
+--+ +-----+ +-----+ +--+
| | | |
|src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<-TCP Leg->|<========MPTCP Leg===========>|<-TCP Leg->|
| dst:s1@| | dst:s1@|
| | | |
\_________________SINGLE PATH CLIENT/SERVER_____________/
_________________MULTIPLE PATH CLIENT/SERVER___________
/ \
| |
| | | |
|src:c2@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<=MPTCP====|=============================>|<-TCP Leg->|
| dst:s2@| | dst:s2@|
| | | |
+--+ +-----+ +-----+ +--+
|C2| | MCP | | MCP | |S2|
+--+ +-----+ +-----+ +--+
Upstream Downstream]]></artwork>
</figure></t>
<t>To mitigate this, the upstream MCP may be instructed to insert a
MP_CONVERT option only for the MPTCP connections it establishes. The
absence of MP_CONVERT option instances is an explicit indication that
this MPTCP connection is a native one. As such, an on-path MCP will not
revert this connection into a TCP connection, but will forward packets
without any modification to the next hop.</t>
<t><xref target="uc1b"></xref> illustrates the results of such
procedure: native MPTCP connections are established between
MPTCP-compliant client and server, while Networok-Assisted MPTCP
connections are established with the help of MCPs.</t>
<t>Concretely, if the upstream MCP receives a SYN that includes the
MP_CAPABLE option, it MAY decide to forward it towards its final
destination without modifying it. When the downstream MCP receives a SYN
that does not include an MP_CONVERT option, it forwards it towards its
final destination.</t>
<t><figure align="center" anchor="uc1b"
title="Example of a Successful E2E MPTCP Connection (On-path)">
<artwork><![CDATA[ Upstream Downstream
+--+ +-----+ +-----+ +--+
|C1| | MCP | | MCP | |S1|
+--+ +-----+ +-----+ +--+
| | | |
|src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<-TCP Leg->|<========MPTCP Leg(MC)=======>|<-TCP Leg->|
| dst:s1@| | dst:s1@|
| | | |
\_________________SINGLE PATH CLIENT/SERVER_____________/
_________________MULTIPLE PATH CLIENT/SERVER___________
/ \
| |
| | | |
|src:c2@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<==========|============MPTCP========================>|
| dst:s2@| | dst:s2@|
| | | |
+--+ +-----+ +-----+ +--+
|C2| | MCP | | MCP | |S2|
+--+ +-----+ +-----+ +--+
Upstream Downstream]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests an MPTCP subtype code for this option:<list
style="symbols">
<t>MP_CONVERT option<vspace blankLines="1" />NOTE: Implementations
may use "0xe" subtype encoding for early deployment purposes in
managed networks.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>MPTCP-related security threats are discussed in <xref
target="RFC6181"></xref> and <xref target="RFC6824"></xref>. Additional
considerations are discussed in the following sub-sections.</t>
<section title="Privacy">
<t>The MCP may have access to privacy-related information (e.g., IMSI,
link identifier, subscriber credentials, etc.). The MCP MUST NOT leak
such sensitive information outside a local domain.</t>
</section>
<section title="Denial-of-Service (DoS) ">
<t>Means to protect the MCP against Denial-of-Service (DoS) attacks
MUST be enabled. Such means include the enforcement of ingress
filtering policies at the network boundaries <xref
target="RFC2827"></xref>.</t>
<t>In order to prevent the exhaustion of MCP resources by establishing
a great number of simultaneous subflows for each MPTCP connection, the
MCP administrator SHOULD limit the number of allowed subflows per CPE
for a given connection. Means to protect against SYN flooding attacks
MUST also be enabled (<xref target="RFC4987"></xref>).</t>
<t>Attacks that originate outside of the domain can be prevented if
ingress filtering policies are enforced. Nevertheless, attacks from
within the network between a host and an MCP instance are yet another
actual threat. Means to ensure that illegitimate nodes cannot connect
to a network should be implemented.</t>
</section>
<section title="Illegitimate MCP">
<t>Traffic theft is a risk if an illegitimate MCP is inserted in the
path. Indeed, inserting an illegitimate MCP in the forwarding path
allows traffic intercept and can therefore provide access to sensitive
data issued by or destined to a host. To mitigate this threat, secure
means to discover an MCP should be enabled.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
Nishida, and Christoph Paasch for their valuable comments.</t>
<t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos
Aires).</t>
<t>Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
Xavier Grall for their inputs.</t>
<t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
Srinivasan, and Raghavendra Mallya for the discussion.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6824'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.0793'?>
<?rfc include='reference.RFC.6890'?>
<reference anchor="proto_numbers">
<front>
<title>Protocol Numbers</title>
<author fullname="IANA">
<organization>http://www.iana.org/assignments/protocol-numbers</organization>
</author>
<date />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.zhang-gre-tunnel-bonding'?>
<?rfc include='reference.RFC.7413'?>
<?rfc include='reference.RFC.1928'?>
<?rfc include='reference.RFC.2473'?>
<?rfc include='reference.RFC.1701'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.I-D.boucadair-mptcp-dhc'?>
<?rfc include='reference.RFC.4987'?>
<?rfc include='reference.RFC.6181'?>
<?rfc include='reference.I-D.nam-mptcp-deployment-considerations'?>
<reference anchor="TR-348">
<front>
<title>Hybrid Access Broadband Network Architecture</title>
<author fullname="BBF">
<organization>BBF</organization>
</author>
<date month="July" year="2016" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:16 |