One document matched: draft-boucadair-mptcp-symmetric-00.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="exp" docName="draft-boucadair-mptcp-symmetric-00"
ipr="trust200902">
<front>
<title abbrev="Symmetrical MPTCP">An Extension to MPTCP for Symmetrical
Sub-Flow Management</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</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." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date />
<abstract>
<t>This document specifies a MPTCP extension that allows to achieve
symmetrical subflow management. In particular, this extension allows
both endpoints to add new subflows whenever needed without waiting for
the endpoint which initiated the first subflow to add new ones.</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>This document specifies a MPTCP <xref target="RFC6824"></xref>
extension to achieve symmetrical subflow management. The problem space
is further described in <xref target="problem"></xref>, while a proposed
solution is discussed in <xref target="solution"></xref>.</t>
<t>This document assumes Port Control Protocol (PCP)-enabled networks
<xref target="RFC6887"></xref>. But other procedures can be used to
instantiate mappings and discover the external lP address/port assigned
by an upstream flow-aware device (e.g., CGN <xref
target="RFC6888"></xref>, firewall, etc.).</t>
</section>
<section anchor="problem" title="Problem Space">
<t>The following is extracted from<xref
target="I-D.ietf-mptcp-experience"></xref>:</t>
<t><list style="empty">
<t>From a subflow viewpoint, the Multipath TCP protocol is
completely symmetrical. Both the clients and the server have the
capability to create subflows. However in practice the existing
Multipath TCP implementations <xref
target="I-D.eardley-mptcp-implementations-survey"></xref> have opted
for a strategy where only the client creates new subflows. The main
motivation for this strategy is that often the client resides behind
a NAT or a firewall, preventing passive subflow openings on the
client.</t>
</list></t>
<t>This means that in practice only the client (that is the TCP endpoint
that initiated the first subflow) can initiate new subflows. This is not
optimal in situations where (1) the remote endpoints want to boost their
sending rate or handover to a new IP address without waiting for the
client to add new subflows, (2) or when the traffic distribution as
observed by the remote endpoint does not meet its local policies. Adding
new subflows should be subject to both the client's and server's local
policies, not only those of the client.</t>
</section>
<section anchor="solution" title="Proposed Solution">
<t>This procedure can be activated upon bootstrap or when a network
attachment change occurs (e.g., attach to a new network); it is not
executed for every new MPTCP connection:<list style="symbols">
<t>Each endpoint proceeds to the discovery of upstream flow-aware
devices (e.g., NAT, Firewall).<vspace blankLines="1" />This can be
achieved by various means, e.g., using UPnP IGD <xref
target="IGD1"></xref><xref target="IGD2"></xref>, PCP server
discovery <xref target="RFC6887"></xref>, PCP DHCP option <xref
target="RFC7225"></xref>, DS-Lite AFTR <xref
target="RFC6334"></xref>, etc.<vspace blankLines="1" />A
NAT/firewall can be embedded in a CPE (Customer Premises Equipment)
and/or hosted in the network provider's side.</t>
<t>Appropriate mappings are instantiated in those discovered
flow-aware devices. In particular, external IP address(es) and port
numbers are retrieved. <vspace blankLines="1" />This can be achieved
using PCP <xref target="RFC6887"></xref>. Note, mappings created by
PCP MAP requests are, by definition, endpoint-independent mappings
(EIMs) with endpoint-independent filtering (EIF). Filters can be
associated with the PCP MAP request to restrict a mapping to be
bound to specific remote peer(s). <vspace blankLines="1" />PCP
allows to dynamically control both NATs and firewalls. Furthermore,
PCP allows to retrieve the lifetime associated with an external IP
address and external port number. <vspace blankLines="1" />If the
host is a UPnP IGD Control Point, <xref target="RFC6970"></xref>
allows to relay UPnP IGD primitives into PCP messages. PCP can also
be used to control multi-layered NATs/firewall owing to the
activation of <xref target="I-D.ietf-pcp-proxy"></xref> in
intermediate NATs/firewalls.</t>
<t>When initiating an MPTCP connection, external IP addresses and
port numbers are communicated to the remote peer. <vspace
blankLines="1" />This can be achieved using ADD_ADDR together with a
new option that will indicate that the address/port pair (identified
by Address ID) enclosed in ADD_ADDR has been checked so that
incoming flows can be sent to this address/port.<vspace
blankLines="1" />Another implementation flavor is to define a new
option, similar to ADD_ADDR, but which will include an optional
field (lifetime). The lifetime can be used as an input to the
traffic management block at the remote side. This field can be
derived from the lease returned in DHCP, or in PCP requests. The use
of this option is an indication that appropriate actions were
undertaken at the remote side to receive incoming packets. A remote
peer can use the enclosed address/port to add a new subflow without
any risk to experience failures at the client side.<figure>
<artwork><![CDATA[ 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 |TBD | IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets) |Lifetime (Optional) (4 octets) |
+-------------------------------+-------------------------------+
| Lifetime (Optional)(continued)|
+-------------------------------+
]]></artwork>
</figure></t>
</list></t>
<t></t>
</section>
<section anchor="security" title="Security Considerations">
<t>PCP-related security considerations are discussed in <xref
target="RFC6887"></xref>. MPTCP-related security considerations are
documented in <xref target="RFC6824"></xref> and <xref
target="I-D.ietf-mptcp-attacks"></xref>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>TBC.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBC</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6824'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-mptcp-experience'?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.RFC.7225'?>
<?rfc include='reference.RFC.6334'?>
<?rfc include='reference.RFC.6970'?>
<?rfc include='reference.I-D.ietf-mptcp-attacks'?>
<?rfc include='reference.I-D.eardley-mptcp-implementations-survey'?>
<?rfc include='reference.I-D.ietf-pcp-proxy'?>
<reference anchor="IGD1">
<front>
<title>WANIPConnection:1 Service
(http://www.upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf)</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date day="" month="November" year="2001" />
</front>
</reference>
<reference anchor="IGD2">
<front>
<title>WANIPConnection:2 Service
(http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf)</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date day="15" month="September" year="2010" />
</front>
</reference>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:37 |