draft-ietf-mptcp-rfc6824bis-08.txt   draft-ietf-mptcp-rfc6824bis-09.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Pexip Internet-Draft Pexip
Obsoletes: 6824 (if approved) C. Raiciu Obsoletes: 6824 (if approved) C. Raiciu
Intended status: Experimental U. Politechnica of Bucharest Intended status: Standards Track U. Politechnica of Bucharest
Expires: January 4, 2018 M. Handley Expires: January 29, 2018 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
C. Paasch C. Paasch
Apple, Inc. Apple, Inc.
July 3, 2017 July 28, 2017
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-08 draft-ietf-mptcp-rfc6824bis-09
Abstract Abstract
TCP/IP communication is currently restricted to a single path per TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network and, thus, improve user improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to experience through higher throughput and improved resilience to
network failure. network failure.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on January 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 6 skipping to change at page 3, line 6
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 27 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 27
3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34
3.3.7. Congestion Control Considerations . . . . . . . . . . 35 3.3.7. Congestion Control Considerations . . . . . . . . . . 35
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36
3.4. Address Knowledge Exchange (Path Management) . . . . . . 37 3.4. Address Knowledge Exchange (Path Management) . . . . . . 37
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 39 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42
3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43
3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44
3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46 3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46
3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51
3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 51 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 51
3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 52 3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 52
3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52
3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53
skipping to change at page 18, line 17 skipping to change at page 18, line 17
the source address and port, and therefore the receiver MUST NOT the source address and port, and therefore the receiver MUST NOT
try to open any additional subflows towards this address and port. try to open any additional subflows towards this address and port.
This is an efficiency improvement for situations where the sender This is an efficiency improvement for situations where the sender
knows a restriction is in place, for example if the sender is knows a restriction is in place, for example if the sender is
behind a strict NAT, or operating behind a legacy Layer 4 load behind a strict NAT, or operating behind a legacy Layer 4 load
balancer. balancer.
D through H: The remaining bits, labeled "D" through "H", are used D through H: The remaining bits, labeled "D" through "H", are used
for crypto algorithm negotiation. Currently only the rightmost for crypto algorithm negotiation. Currently only the rightmost
bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC- bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC-
SHA1 (as defined in Section 3.2). An implementation that only SHA256 (as defined in Section 3.2). An implementation that only
supports this method MUST set bit "H" to 1, and bits "D" through supports this method MUST set bit "H" to 1, and bits "D" through
"G" to 0. "G" to 0.
A crypto algorithm MUST be specified. If flag bits D through H are A crypto algorithm MUST be specified. If flag bits D through H are
all 0, the MP_CAPABLE option MUST be treated as invalid and ignored all 0, the MP_CAPABLE option MUST be treated as invalid and ignored
(that is, it must be treated as a regular TCP handshake). (that is, it must be treated as a regular TCP handshake).
The selection of the authentication algorithm also impacts the The selection of the authentication algorithm also impacts the
algorithm used to generate the token and the Initial Data Sequence algorithm used to generate the token and the Initial Data Sequence
Number (IDSN). In this specification, with only the SHA-256 Number (IDSN). In this specification, with only the SHA-256
skipping to change at page 20, line 28 skipping to change at page 20, line 28
subflow, but it is expected that this will normally be the original subflow, but it is expected that this will normally be the original
connection initiator (see Section 3.10 for heuristics). connection initiator (see Section 3.10 for heuristics).
A new subflow is started as a normal TCP SYN/ACK exchange. The Join A new subflow is started as a normal TCP SYN/ACK exchange. The Join
Connection (MP_JOIN) MPTCP option is used to identify the connection Connection (MP_JOIN) MPTCP option is used to identify the connection
to be joined by the new subflow. It uses keying material that was to be joined by the new subflow. It uses keying material that was
exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that
handshake also negotiates the crypto algorithm in use for the MP_JOIN handshake also negotiates the crypto algorithm in use for the MP_JOIN
handshake. handshake.
This section specifies the behavior of MP_JOIN using the HMAC-SHA1 This section specifies the behavior of MP_JOIN using the HMAC-SHA256
algorithm. An MP_JOIN option is present in the SYN, SYN/ACK, and ACK algorithm. An MP_JOIN option is present in the SYN, SYN/ACK, and ACK
of the three-way handshake, although in each case with a different of the three-way handshake, although in each case with a different
format. format.
In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the
initiator sends a token, random number, and address ID. initiator sends a token, random number, and address ID.
The token is used to identify the MPTCP connection and is a The token is used to identify the MPTCP connection and is a
cryptographic hash of the receiver's key, as exchanged in the initial cryptographic hash of the receiver's key, as exchanged in the initial
MP_CAPABLE handshake (Section 3.1). In this specification, the MP_CAPABLE handshake (Section 3.1). In this specification, the
skipping to change at page 37, line 17 skipping to change at page 37, line 17
In the event that the available set of paths changes, a host may wish In the event that the available set of paths changes, a host may wish
to signal a change in priority of subflows to the peer (e.g., a to signal a change in priority of subflows to the peer (e.g., a
subflow that was previously set as backup should now take priority subflow that was previously set as backup should now take priority
over all remaining subflows). Therefore, the MP_PRIO option, shown over all remaining subflows). Therefore, the MP_PRIO option, shown
in Figure 11, can be used to change the 'B' flag of the subflow on in Figure 11, can be used to change the 'B' flag of the subflow on
which it is sent. which it is sent.
1 2 3 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 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| |B| AddrID (opt) | | Kind | Length |Subtype| |B|
+---------------+---------------+-------+-----+-+--------------+ +---------------+---------------+-------+-----+-+
Figure 11: Change Subflow Priority (MP_PRIO) Option Figure 11: Change Subflow Priority (MP_PRIO) Option
It should be noted that the backup flag is a request from a data It should be noted that the backup flag is a request from a data
receiver to a data sender only, and the data sender SHOULD adhere to receiver to a data sender only, and the data sender SHOULD adhere to
these requests. A host cannot assume that the data sender will do these requests. A host cannot assume that the data sender will do
so, however, since local policies -- or technical difficulties -- may so, however, since local policies -- or technical difficulties -- may
override MP_PRIO requests. Note also that this signal applies to a override MP_PRIO requests. Note also that this signal applies to a
single direction, and so the sender of this option could choose to single direction, and so the sender of this option could choose to
continue using the subflow to send data even if it has signaled B=1 continue using the subflow to send data even if it has signaled B=1
to the other host. to the other host.
This option can also be applied to other subflows than the one on
which it is sent, by setting the optional Address ID field. This
applies the given setting of B to all subflows in this connection
that use the address identified by the given Address ID. The
presence of this field is determined by the option length; if
Length==4 then it is present. If Length==3, then it applies to the
current subflow only. The use case of this is that a host can signal
to its peer that an address is temporarily unavailable (for example,
if it has radio coverage issues) and the peer should therefore drop
to backup state on all subflows using that Address ID.
3.4. Address Knowledge Exchange (Path Management) 3.4. Address Knowledge Exchange (Path Management)
We use the term "path management" to refer to the exchange of We use the term "path management" to refer to the exchange of
information about additional paths between hosts, which in this information about additional paths between hosts, which in this
design is managed by multiple addresses at hosts. For more detail of design is managed by multiple addresses at hosts. For more detail of
the architectural thinking behind this design, see the MPTCP the architectural thinking behind this design, see the MPTCP
Architecture document [RFC6182]. Architecture document [RFC6182].
This design makes use of two methods of sharing such information, and This design makes use of two methods of sharing such information, and
both can be used on a connection. The first is the direct setup of both can be used on a connection. The first is the direct setup of
skipping to change at page 63, line 23 skipping to change at page 63, line 23
| Flag | Meaning | Reference | | Flag | Meaning | Reference |
| Bit | | | | Bit | | |
+---------+----------------------------------+----------------------+ +---------+----------------------------------+----------------------+
| A | Checksum required | This document, | | A | Checksum required | This document, |
| | | Section 3.1 | | | | Section 3.1 |
| B | Extensibility | This document, | | B | Extensibility | This document, |
| | | Section 3.1 | | | | Section 3.1 |
| C | Do not attempt to connect to | This document, | | C | Do not attempt to connect to | This document, |
| | source address | Section 3.1 | | | source address | Section 3.1 |
| D-G | Unassigned | | | D-G | Unassigned | |
| H | HMAC-SHA1 | This document, | | H | HMAC-SHA256 | This document, |
| | | Section 3.2 | | | | Section 3.2 |
+---------+----------------------------------+----------------------+ +---------+----------------------------------+----------------------+
Table 3: MPTCP Handshake Algorithms Table 3: MPTCP Handshake Algorithms
Note that the meanings of bits D through H can be dependent upon bit Note that the meanings of bits D through H can be dependent upon bit
B, depending on how Extensibility is defined in future B, depending on how Extensibility is defined in future
specifications; see Section 3.1 for more information. specifications; see Section 3.1 for more information.
Future assignments in this registry are also to be defined by Future assignments in this registry are also to be defined by
 End of changes. 10 change blocks. 
23 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/