One document matched: draft-boucadair-mptcp-probe-subflow-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-probe-subflow-00"
ipr="trust200902" updates="6824">
<front>
<title abbrev="MPTCP Probing">Probing MPTCP Subflows</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 an extension to Multipath TCP (MPTCP) that is
meant to assess whether a path used to establish a given subflow is
MPTCP-friendly, i.e., intermediate nodes involved in that path do not
alter nor strip MPTCP options, which would prevent the establishment of
MPTCP communications along that path. A new flag bit, called Probe Flag
(P-flag) is defined for this purpose.</t>
<t>This document updates RFC6824.</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 anchor="introduction" title="Introduction">
<t>This document specifies an extension to Multipath TCP (MPTCP, <xref
target="RFC6824"></xref>) that is meant to assess whether a path used to
establish a given subflow is MPTCP-friendly. That is, intermediate nodes
involved in that path do not alter nor strip MPTCP options, which would
prevent the establishment of MPTCP communications along that path.</t>
<t>The problem is summarized briefly in <xref target="pb"></xref> while
the probe flag is defined in <xref target="sol"></xref>.</t>
<t>The solution proposed in this document allows to anticipate failures
due to the presence of MPTCP-unfriendly devices in the communication
paths.</t>
</section>
<section anchor="pb" title="The Problem">
<t>MPTCP supports a backup mode that relies on a dedicated flag, called
backup flag carried in the MP_JOIN option: when set, this flag informs
the remote peer that this is a backup subflow. Several problems may be
arise such as. For example:</t>
<t><list style="symbols">
<t>A peer decides to use a backup subflow but MPTCP cannot be used
for that subflow because an intermediate function removes DSS
options, for example. This failure will have a negative impact on
the quality of experience.</t>
<t>Several subflows can be candidate to be used as backup but the
participating nodes do not know in advance whether associated
forwarding paths are MPTCP-friendly, i.e., they can actually support
MPTCP subflows. The participating nodes need some "hints" to decide
which subflows are to be used as regular ones and those as backup.
This lack of information may also affect the perceived quality of
experience.</t>
</list></t>
</section>
<section anchor="sol" title="Probe Flag (P-flag)">
<t>As a solution to the problem described in <xref target="pb"></xref>,
a meaning is associated with one of the reserved bits in MP_JOIN. This
new flag bit is called: Probe Flag (P-flag). This flag bit is used to
explicitly inform the remote peer that a probing procedure is associated
with the corresponding subflow.</t>
<t><xref target="fig1"></xref> and <xref target="fig2"></xref> show the
required update to the MP_JOIN option format in SYN and SYN/ACK.</t>
<t><figure anchor="fig1"
title="Join Connection (MP_JOIN) Option (for Initial SYN)">
<artwork><![CDATA[OLD:
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 = 12 |Subtype| |B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
NEW:
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 = 12 |Subtype|r|r|P|B| Address ID |
+---------------+---------------+-------+-+-+-+-+---------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
where "rr" are reserved bits for future assignment as
additional flag bits. r bits MUST each be sent as zero and MUST be
ignored on receipt.
]]></artwork>
</figure><figure anchor="fig2"
title="Join Connection (MP_JOIN) Option (for Responding SYN/ACK)">
<artwork><![CDATA[OLD:
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 = 16 |Subtype| |B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| |
| Sender's Truncated HMAC (64 bits) |
| |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
NEW:
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 = 16 |Subtype|r|r|P|B| Address ID |
+---------------+---------------+-------+-+-+-+-+---------------+
| |
| Sender's Truncated HMAC (64 bits) |
| |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
where "rr" are reserved bits for future assignment as
additional flag bits. r bits MUST each be sent as zero and MUST be
ignored on receipt.
]]></artwork>
</figure></t>
<t>When set, the P-Flag bit indicates to the remote peer that a probing
is associated with this subflow. The probing logic is to be further
defined in future versions of this specification. Only probing data MUST
be sent over a subflow that is tagged to be under probing. Probing MUST
NOT interfere with data exchange over regular subflows, if any.</t>
<t>An MPTCP endpoint that receives an MP_JOIN with a P-flag set, MUST
echo the P-flag in the SYN/ACK if it supports the probing mechanism. If
not, the P-flag MUST be ignored (i.e., the P-flag of the MP_JOIN
included in the SYN/ACK must be set to 0).</t>
<t>P-flag can be set independently of the backup flag.</t>
<t>The handling of the B flag when P-flag is also set, is not altered by
this specification.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>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>This document does not require any action from IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBC</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6824'?>
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-mptcp-attacks"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:13 |