draft-ietf-mptcp-multiaddressed-08.txt   draft-ietf-mptcp-multiaddressed-09.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Experimental C. Raiciu Intended status: Experimental C. Raiciu
Expires: November 26, 2012 University Politehnica of Expires: December 8, 2012 University Politehnica of
Bucharest Bucharest
M. Handley M. Handley
University College London University College London
O. Bonaventure O. Bonaventure
Universite catholique de Universite catholique de
Louvain Louvain
May 25, 2012 June 6, 2012
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-multiaddressed-08 draft-ietf-mptcp-multiaddressed-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 1, line 49 skipping to change at page 1, line 49
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 November 26, 2012. This Internet-Draft will expire on December 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 6, line 33 skipping to change at page 6, line 33
term "data-level" is synonymous with "connection level", in term "data-level" is synonymous with "connection level", in
contrast to "subflow-level" which refers to properties of an contrast to "subflow-level" which refers to properties of an
individual subflow. individual subflow.
Token: A locally unique identifier given to a multipath connection Token: A locally unique identifier given to a multipath connection
by a host. May also be referred to as a "Connection ID". by a host. May also be referred to as a "Connection ID".
Host: A end host operating an MPTCP implementation, and either Host: A end host operating an MPTCP implementation, and either
initiating or accepting an MPTCP connection. initiating or accepting an MPTCP connection.
MPTCP's interpretation of, and effect on, regular TCP semantics are MPTCP's interpretation of, and effect on, regular single-path TCP
discussed in Section 4. semantics are discussed in Section 4.
1.4. MPTCP Concept 1.4. MPTCP Concept
This section provides a high-level summary of normal operation of This section provides a high-level summary of normal operation of
MPTCP, and is illustrated by the scenario shown in Figure 2. A MPTCP, and is illustrated by the scenario shown in Figure 2. A
detailed description of operation is given in Section 3. Changes in detailed description of operation is given in Section 3.
semantics from regular, single-path TCP are discussed in Section 4.
o To a non-MPTCP-aware application, MPTCP will behave the same as o To a non-MPTCP-aware application, MPTCP will behave the same as
normal TCP. Extended APIs could provide additional control to normal TCP. Extended APIs could provide additional control to
MPTCP-aware applications [6]. An application begins by opening a MPTCP-aware applications [6]. An application begins by opening a
TCP socket in the normal way. MPTCP signaling and operation is TCP socket in the normal way. MPTCP signaling and operation is
handled by the MPTCP implementation. handled by the MPTCP implementation.
o An MPTCP connection begins similarly to a regular TCP connection. o An MPTCP connection begins similarly to a regular TCP connection.
This is illustrated in Figure 2 where an MPTCP connection is This is illustrated in Figure 2 where an MPTCP connection is
established between addresses A1 and B1 on Hosts A and B established between addresses A1 and B1 on Hosts A and B
skipping to change at page 13, line 34 skipping to change at page 13, line 34
undertaken before processing any MPTCP signals, as described in [10]. undertaken before processing any MPTCP signals, as described in [10].
3.1. Connection Initiation 3.1. Connection Initiation
Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a
single path. Each packet contains the Multipath Capable (MP_CAPABLE) single path. Each packet contains the Multipath Capable (MP_CAPABLE)
TCP option (Figure 4). This option declares its sender is capable of TCP option (Figure 4). This option declares its sender is capable of
performing multipath TCP and wishes to do so on this particular performing multipath TCP and wishes to do so on this particular
connection. connection.
This option is used to declare the sender's 64 bit key, which is used This option is used to declare the sender's 64 bit key, which is
to authenticate the addition of future subflows to this MPTCP uniquely linked to this MPTCP connection. This key is used to
connection. This is the only time the key will be sent in clear on authenticate the addition of future subflows to this connection.
the wire (unless "fast close", Section 3.5, is used); all future This is the only time the key will be sent in clear on the wire
subflows will identify the connection using a 32 bit "token". This (unless "fast close", Section 3.5, is used); all future subflows will
token is a cryptographic hash of this key. The token will be a identify the connection using a 32 bit "token". This token is a
truncated (most significant 32 bits) SHA-1 hash [4]. A different, 64 cryptographic hash of this key. The token will be a truncated (most
bit truncation (the least significant 64 bits) of the hash of the key significant 32 bits) SHA-1 hash [4]. A different, 64 bit truncation
will be used as the Initial Data Sequence Number. (the least significant 64 bits) of the hash of the key will be used
as the Initial Data Sequence Number.
This key is generated by its sender and has local meaning only, and This key is generated by its sender and has local meaning only, and
its method of generation is implementation-specific. The key MUST be its method of generation is implementation-specific. The key MUST be
hard to guess, and it MUST be unique for the sending host at any one hard to guess, and it MUST be unique for the sending host at any one
time. Recommendations for generating random keys are given in [11]. time. Recommendations for generating random keys are given in [11].
Connections will be indexed at each host by the token (the truncated Connections will be indexed at each host by the token (the truncated
SHA-1 hash of the key). Therefore, an implementation will require a SHA-1 hash of the key). Therefore, an implementation will require a
mapping from each token to the corresponding connection, and in turn mapping from each token to the corresponding connection, and in turn
to the keys for the connection. to the keys for the connection.
skipping to change at page 52, line 43 skipping to change at page 52, line 43
Table 3: MPTCP Handshake Algorithms Table 3: MPTCP Handshake Algorithms
Future assignments in this registry are also to be defined by RFCs Future assignments in this registry are also to be defined by RFCs
(RFC Requirement as defined by [21]) Assignments consist of the value (RFC Requirement as defined by [21]) Assignments consist of the value
of the flags, a symbolic name for the algorithm, and a reference to of the flags, a symbolic name for the algorithm, and a reference to
its specification. its specification.
Note that the length of this field is not fixed; it is a definition Note that the length of this field is not fixed; it is a definition
of the meaning of each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10, of the meaning of each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10,
etc). Future specifications may encroach on the non-cryptographic etc). Future specifications may define additional flags using the
flags at the other end of this field so the number of flags available leftmost bits of this field, and therefore the number of bits
for cryptographic algorithm use may change. available for cryptographic negotiation may change.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[2] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, [2] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", "Architectural Guidelines for Multipath TCP Development",
RFC 6182, March 2011. RFC 6182, March 2011.
 End of changes. 8 change blocks. 
20 lines changed or deleted 20 lines changed or added

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