draft-ietf-mptcp-rfc6824bis-03.txt   draft-ietf-mptcp-rfc6824bis-04.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: Experimental U. Politechnica of Bucharest
Expires: April 30, 2015 M. Handley Expires: September 8, 2015 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
October 27, 2014 March 7, 2015
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-03 draft-ietf-mptcp-rfc6824bis-04
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 4 skipping to change at page 2, line 4
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 April 30, 2015. This Internet-Draft will expire on September 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 47 skipping to change at page 2, line 47
2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 12 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 12
2.7. Notable Features . . . . . . . . . . . . . . . . . . . . . 12 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . . 12
3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 14 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 14
3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 18 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 18
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 23 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 23
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 25 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 25
3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . . 28 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . . 28
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 29 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 29
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 30 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 30
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 31 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 32
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 32 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 32
3.3.7. Congestion Control Considerations . . . . . . . . . . 33 3.3.7. Congestion Control Considerations . . . . . . . . . . 34
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 34 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 34
3.4. Address Knowledge Exchange (Path Management) . . . . . . . 35 3.4. Address Knowledge Exchange (Path Management) . . . . . . . 36
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 37 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 37
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 39 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 40
3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . . 40 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 42 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 42
3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 47 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . . 47
3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 48 3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 48 3.9.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 48
3.9.2. Delayed Subflow Start and Subflow Symmetry . . . . . . 48 3.9.2. Delayed Subflow Start and Subflow Symmetry . . . . . . 48
3.9.3. Failure Handling . . . . . . . . . . . . . . . . . . . 49 3.9.3. Failure Handling . . . . . . . . . . . . . . . . . . . 50
4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 50 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 54 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 54
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1. Normative References . . . . . . . . . . . . . . . . . . . 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 60
9.2. Informative References . . . . . . . . . . . . . . . . . . 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . . 61 Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . . 62
Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 63 Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 63
B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 63 B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 64
B.1.1. Authentication and Metadata . . . . . . . . . . . . . 64 B.1.1. Authentication and Metadata . . . . . . . . . . . . . 64
B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 64 B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 64
B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 64 B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 65
B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 65 B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 65
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 65 B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 65
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 65 B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 65
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 65 Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
Multipath TCP (MPTCP) is a set of extensions to regular TCP [1] to Multipath TCP (MPTCP) is a set of extensions to regular TCP [1] to
provide a Multipath TCP [2] service, which enables a transport provide a Multipath TCP [2] service, which enables a transport
connection to operate across multiple paths simultaneously. This connection to operate across multiple paths simultaneously. This
document presents the protocol changes required to add multipath document presents the protocol changes required to add multipath
capability to TCP; specifically, those for signaling and setting up capability to TCP; specifically, those for signaling and setting up
multiple paths ("subflows"), managing these subflows, reassembly of multiple paths ("subflows"), managing these subflows, reassembly of
data, and termination of sessions. This is not the only information data, and termination of sessions. This is not the only information
skipping to change at page 18, line 10 skipping to change at page 18, line 10
fall back to single-path TCP (i.e., without the MP_CAPABLE option) in fall back to single-path TCP (i.e., without the MP_CAPABLE option) in
order to work around middleboxes that may drop packets with unknown order to work around middleboxes that may drop packets with unknown
options; however, the number of multipath-capable attempts that are options; however, the number of multipath-capable attempts that are
made first will be up to local policy. It is possible that MPTCP and made first will be up to local policy. It is possible that MPTCP and
non-MPTCP SYNs could get reordered in the network. Therefore, the non-MPTCP SYNs could get reordered in the network. Therefore, the
final state is inferred from the presence or absence of the final state is inferred from the presence or absence of the
MP_CAPABLE option in the third packet of the TCP handshake. If this MP_CAPABLE option in the third packet of the TCP handshake. If this
option is not present, the connection SHOULD fall back to regular option is not present, the connection SHOULD fall back to regular
TCP, as documented in Section 3.7. TCP, as documented in Section 3.7.
If a host supports multiple versions of MPTCP, the sender of the
MP_CAPABLE option SHOULD signal the highest version number it
supports. The passive opener, on receipt of this, will signal the
version number it wishes to use, which MUST be equal to or lower than
the version number indicated in the initial MP_CAPABLE. The
connection initiator, when sending the third packet (the ACK with
MP_CAPABLE), will either echo this version number as given in the
SYN/ACK (if it supports it), or will cancel the use of MPTCP and fall
back to regular TCP by not including the MP_CAPABLE option, if it
does not support, or does not wish to use, this requested version.
The initial data sequence number on an MPTCP connection is generated The initial data sequence number on an MPTCP connection is generated
from the key. The algorithm for IDSN generation is also determined from the key. The algorithm for IDSN generation is also determined
from the negotiated authentication algorithm. In this specification, from the negotiated authentication algorithm. In this specification,
with only the SHA-1 algorithm specified and selected, the IDSN of a with only the SHA-1 algorithm specified and selected, the IDSN of a
host MUST be the least significant 64 bits of the SHA-1 hash of its host MUST be the least significant 64 bits of the SHA-1 hash of its
key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). This key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). This
deterministic generation of the IDSN allows a receiver to ensure that deterministic generation of the IDSN allows a receiver to ensure that
there are no gaps in sequence space at the start of the connection. there are no gaps in sequence space at the start of the connection.
The SYN with MP_CAPABLE occupies the first octet of data sequence The SYN with MP_CAPABLE occupies the first octet of data sequence
space, although this does not need to be acknowledged at the space, although this does not need to be acknowledged at the
 End of changes. 18 change blocks. 
19 lines changed or deleted 30 lines changed or added

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