draft-ietf-mptcp-api-03.txt   draft-ietf-mptcp-api-04.txt 
Internet Engineering Task Force M. Scharf Internet Engineering Task Force M. Scharf
Internet-Draft Alcatel-Lucent Bell Labs Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Informational A. Ford Intended status: Informational A. Ford
Expires: June 2, 2012 November 30, 2011 Expires: August 19, 2012 Cisco
February 16, 2012
MPTCP Application Interface Considerations MPTCP Application Interface Considerations
draft-ietf-mptcp-api-03 draft-ietf-mptcp-api-04
Abstract Abstract
Multipath TCP (MPTCP) adds the capability of using multiple paths to Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session. Even though it is designed to be totally a regular TCP session. Even though it is designed to be totally
backward compatible to applications, the data transport differs backward compatible to applications, the data transport differs
compared to regular TCP, and there are several additional degrees of compared to regular TCP, and there are several additional degrees of
freedom that applications may wish to exploit. This document freedom that applications may wish to exploit. This document
summarizes the impact that MPTCP may have on applications, such as summarizes the impact that MPTCP may have on applications, such as
changes in performance. Furthermore, it discusses compatibility changes in performance. Furthermore, it discusses compatibility
skipping to change at page 1, line 40 skipping to change at page 1, line 41
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 June 2, 2012. This Internet-Draft will expire on August 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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 46 skipping to change at page 2, line 47
5. Basic API for MPTCP-aware Applications . . . . . . . . . . . . 13 5. Basic API for MPTCP-aware Applications . . . . . . . . . . . . 13
5.1. Design Considerations . . . . . . . . . . . . . . . . . . 13 5.1. Design Considerations . . . . . . . . . . . . . . . . . . 13
5.2. Requirements on the Basic MPTCP API . . . . . . . . . . . 14 5.2. Requirements on the Basic MPTCP API . . . . . . . . . . . 14
5.3. Sockets Interface Extensions by the Basic MPTCP API . . . 15 5.3. Sockets Interface Extensions by the Basic MPTCP API . . . 15
5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Enabling and Disabling of MPTCP . . . . . . . . . . . 16 5.3.2. Enabling and Disabling of MPTCP . . . . . . . . . . . 16
5.3.3. Binding MPTCP to Specified Addresses . . . . . . . . . 17 5.3.3. Binding MPTCP to Specified Addresses . . . . . . . . . 17
5.3.4. Querying the MPTCP Subflow Addresses . . . . . . . . . 18 5.3.4. Querying the MPTCP Subflow Addresses . . . . . . . . . 18
5.3.5. Getting a Unique Connection Identifier . . . . . . . . 18 5.3.5. Getting a Unique Connection Identifier . . . . . . . . 18
6. Other Compatibility Issues . . . . . . . . . . . . . . . . . . 18 6. Other Compatibility Issues . . . . . . . . . . . . . . . . . . 18
6.1. Usage of the SCTP Socket API . . . . . . . . . . . . . . . 18 6.1. Usage of the SCTP Socket API . . . . . . . . . . . . . . . 19
6.2. Incompatibilities with other Multihoming Solutions . . . . 19 6.2. Incompatibilities with other Multihoming Solutions . . . . 19
6.3. Interactions with DNS . . . . . . . . . . . . . . . . . . 19 6.3. Interactions with DNS . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Requirements on a Future Advanced MPTCP API . . . . . 22 Appendix A. Requirements on a Future Advanced MPTCP API . . . . . 23
A.1. Design Considerations . . . . . . . . . . . . . . . . . . 22 A.1. Design Considerations . . . . . . . . . . . . . . . . . . 23
A.2. MPTCP Usage Scenarios and Application Requirements . . . . 22 A.2. MPTCP Usage Scenarios and Application Requirements . . . . 23
A.3. Potential Requirements on an Advanced MPTCP API . . . . . 24 A.3. Potential Requirements on an Advanced MPTCP API . . . . . 25
A.4. Integration with the SCTP Socket API . . . . . . . . . . . 25 A.4. Integration with the SCTP Socket API . . . . . . . . . . . 26
Appendix B. Change History of the Document . . . . . . . . . . . 26 Appendix B. Change History of the Document . . . . . . . . . . . 27
1. Introduction 1. Introduction
Multipath TCP adds the capability of using multiple paths to a Multipath TCP adds the capability of using multiple paths to a
regular TCP session [1]. The motivations for this extension include regular TCP session [1]. The motivations for this extension include
increasing throughput, overall resource utilisation, and resilience increasing throughput, overall resource utilisation, and resilience
to network failure, and these motivations are discussed, along with to network failure, and these motivations are discussed, along with
high-level design decisions, as part of the Multipath TCP high-level design decisions, as part of the Multipath TCP
architecture [4]. The MPTCP protocol [5] offers the same reliable, architecture [4]. The MPTCP protocol [5] offers the same reliable,
in-order, byte-stream transport as TCP, and is designed to be in-order, byte-stream transport as TCP, and is designed to be
skipping to change at page 4, line 46 skipping to change at page 4, line 46
interface. This document provides an abstract definition of MPTCP- interface. This document provides an abstract definition of MPTCP-
specific extensions to this interface. These are operations that can specific extensions to this interface. These are operations that can
be used by an application to get or set additional MPTCP-specific be used by an application to get or set additional MPTCP-specific
information on a socket, in order to provide an equivalent level of information on a socket, in order to provide an equivalent level of
information and control over MPTCP as exists for an application using information and control over MPTCP as exists for an application using
regular TCP. It is up to the applications, high-level programming regular TCP. It is up to the applications, high-level programming
languages, or libraries to decide whether to use these optional languages, or libraries to decide whether to use these optional
extensions. For instance, an application may want to turn on or off extensions. For instance, an application may want to turn on or off
the MPTCP mechanism for certain data transfers, or limit its use to the MPTCP mechanism for certain data transfers, or limit its use to
certain interfaces. The abstract specification is in line with the certain interfaces. The abstract specification is in line with the
Posix standard [8] as much as possible. Posix standard [17] as much as possible.
There are also various related extensions of the sockets interface: There are also various related extensions of the sockets interface:
[12] specifies sockets API extensions for a multihoming shim layer. [11] specifies sockets API extensions for a multihoming shim layer.
The API enables interactions between applications and the multihoming The API enables interactions between applications and the multihoming
shim layer for advanced locator management and for access to shim layer for advanced locator management and for access to
information about failure detection and path exploration. information about failure detection and path exploration.
Experimental extensions to the sockets API are also defined for the Experimental extensions to the sockets API are also defined for the
Host Identity Protocol (HIP) [13] in order to manage the bindings of Host Identity Protocol (HIP) [12] in order to manage the bindings of
identifiers and locator. Further related API extensions exist for identifiers and locator. Further related API extensions exist for
IPv6 [10], Mobile IP [11], and SCTP [14]. There can be interactions IPv6 [9], Mobile IP [10], and SCTP [13]. There can be interactions
or incompatibilities of these APIs with MPTCP, which are discussed or incompatibilities of these APIs with MPTCP, which are discussed
later in this document. later in this document.
Some network stack implementations, specially on mobile devices, have Some network stack implementations, specially on mobile devices, have
centralized connection managers or other higher-level APIs to solve centralized connection managers or other higher-level APIs to solve
multi-interface issues, as surveyed in [16]. Their interaction with multi-interface issues, as surveyed in [15]. Their interaction with
MPTCP is outside the scope of this note. MPTCP is outside the scope of this note.
The target readers of this document are application developers whose The target readers of this document are application developers whose
software may benefit significantly from MPTCP. This document also software may benefit significantly from MPTCP. This document also
provides the necessary information for developers of MPTCP to provides the necessary information for developers of MPTCP to
implement the API in a TCP/IP network stack. implement the API in a TCP/IP network stack.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 6 skipping to change at page 8, line 6
presence of TCP options, or they may strip TCP options. If this is presence of TCP options, or they may strip TCP options. If this is
the case, MPTCP should fall back to regular TCP. Although this will the case, MPTCP should fall back to regular TCP. Although this will
not create a problem for the application (its communication will be not create a problem for the application (its communication will be
set up either way), there may be additional (and indeed, user- set up either way), there may be additional (and indeed, user-
perceivable) delay while the first handshake fails. Therefore, an perceivable) delay while the first handshake fails. Therefore, an
alternative approach could be to try both MPTCP and regular TCP alternative approach could be to try both MPTCP and regular TCP
connection attempts at the same time, and respond to whichever connection attempts at the same time, and respond to whichever
replies first (or apply a timeout on the MPTCP attempt, while having replies first (or apply a timeout on the MPTCP attempt, while having
TCP SYN/ACK ready to reply to, thus reducing the setup delay by a TCP SYN/ACK ready to reply to, thus reducing the setup delay by a
RTT) in a similar fashion to the "Happy Eyeballs" proposal for IPv6 RTT) in a similar fashion to the "Happy Eyeballs" proposal for IPv6
[17]. [16].
An MPTCP implementation can learn the rate of MPTCP connection An MPTCP implementation can learn the rate of MPTCP connection
attempt successes or failures to particular hosts or networks, and on attempt successes or failures to particular hosts or networks, and on
particular interfaces, and could therefore learn heuristics of when particular interfaces, and could therefore learn heuristics of when
and when not to use MPTCP. A detailed discussion of the various and when not to use MPTCP. A detailed discussion of the various
fallback mechanisms, for failures occurring at different points in fallback mechanisms, for failures occurring at different points in
the connection, is presented in [5]. the connection, is presented in [5].
There may also be middleboxes that transparently change the length of There may also be middleboxes that transparently change the length of
content. If such middleboxes are present, MPTCP's reassembly of the content. If such middleboxes are present, MPTCP's reassembly of the
skipping to change at page 9, line 6 skipping to change at page 9, line 6
to another host during the lifetime of an MPTCP connection. to another host during the lifetime of an MPTCP connection.
3.2.3. Security Implications 3.2.3. Security Implications
The support for multiple IP addresses within one MPTCP connection can The support for multiple IP addresses within one MPTCP connection can
result in additional security vulnerabilities, such as possibilities result in additional security vulnerabilities, such as possibilities
for attackers to hijack connections. The protocol design of MPTCP for attackers to hijack connections. The protocol design of MPTCP
minimizes this risk. An attacker on one of the paths can cause harm, minimizes this risk. An attacker on one of the paths can cause harm,
but this is hardly an additional security risk compared to single- but this is hardly an additional security risk compared to single-
path TCP, which is vulnerable to man-in-the-middle attacks, too. A path TCP, which is vulnerable to man-in-the-middle attacks, too. A
detailed thread analysis of MPTCP is published in [6]. detailed threat analysis of MPTCP is published in [6].
4. Operation of MPTCP with Legacy Applications 4. Operation of MPTCP with Legacy Applications
4.1. Overview of the MPTCP Network Stack 4.1. Overview of the MPTCP Network Stack
MPTCP is an extension of TCP, but it is designed to be backward MPTCP is an extension of TCP, but it is designed to be backward
compatible for legacy applications. TCP interacts with other parts compatible for legacy (MPTCP-unaware) applications. TCP interacts
of the network stack by different interfaces. The de facto standard with other parts of the network stack by different interfaces. The
API between TCP and applications is the sockets interface. The de facto standard API between TCP and applications is the sockets
position of MPTCP in the protocol stack can be illustrated in interface. The position of MPTCP in the protocol stack can be
Figure 1. illustrated in Figure 1.
+-------------------------------+ +-------------------------------+
| Application | | Application |
+-------------------------------+ +-------------------------------+
^ | ^ |
~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~ ~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~
| v | v
+-------------------------------+ +-------------------------------+
| MPTCP | | MPTCP |
+ - - - - - - - + - - - - - - - + + - - - - - - - + - - - - - - - +
skipping to change at page 9, line 47 skipping to change at page 9, line 47
port pair, to one sockets endpoint, to one network interface, or to a port pair, to one sockets endpoint, to one network interface, or to a
given path through the network. given path through the network.
This means that there are two classes of applications: This means that there are two classes of applications:
o Legacy applications: These applications are unaware of MPTCP and o Legacy applications: These applications are unaware of MPTCP and
use the existing API towards TCP without any changes. This is the use the existing API towards TCP without any changes. This is the
default case. default case.
o MPTCP-aware applications: These applications indicate support for o MPTCP-aware applications: These applications indicate support for
an enhance MPTCP interface. This document specified a minimum set an enhanced MPTCP interface. This document specified a minimum
of API extensions for such applications. set of API extensions for such applications.
In the following, it is discussed to which extent MPTCP affects In the following, it is discussed to what extent MPTCP affects legacy
legacy applications using the existing sockets API. The existing applications using the existing sockets API. The existing sockets
sockets API implies that applications deal with data structures that API implies that applications deal with data structures that store,
store, amongst others, the IP addresses and TCP port numbers of a TCP amongst others, the IP addresses and TCP port numbers of a TCP
connection. A design objective of MPTCP is that legacy applications connection. A design objective of MPTCP is that legacy applications
can continue to use the established sockets API without any changes. can continue to use the established sockets API without any changes.
However, in MPTCP there is a one-to-many mapping between the socket However, in MPTCP there is a one-to-many mapping between the socket
endpoint and the subflows. This has several subtle implications for endpoint and the subflows. This has several subtle implications for
legacy applications using sockets API functions. legacy applications using sockets API functions.
4.2. Address Issues 4.2. Address Issues
4.2.1. Specification of Addresses by Applications 4.2.1. Specification of Addresses by Applications
skipping to change at page 11, line 44 skipping to change at page 11, line 44
getsockopt() function gets information. In general, the existing getsockopt() function gets information. In general, the existing
sockets interface functions cannot configure each MPTCP subflow sockets interface functions cannot configure each MPTCP subflow
individually. In order to be backward compatible, existing APIs individually. In order to be backward compatible, existing APIs
therefore SHOULD apply to all subflows within one connection, as far therefore SHOULD apply to all subflows within one connection, as far
as possible. as possible.
4.3.2. Disabling of the Nagle Algorithm 4.3.2. Disabling of the Nagle Algorithm
One commonly used TCP socket option (TCP_NODELAY) disables the Nagle One commonly used TCP socket option (TCP_NODELAY) disables the Nagle
algorithm as described in [2]. This option is also specified in the algorithm as described in [2]. This option is also specified in the
Posix standard [8]. Applications can use this option in combination Posix standard [17]. Applications can use this option in combination
with MPTCP exactly in the same way. It then SHOULD disable the Nagle with MPTCP exactly in the same way. It then SHOULD disable the Nagle
algorithm for the MPTCP connection, i.e., all subflows. algorithm for the MPTCP connection, i.e., all subflows.
In addition, the MPTCP protocol instance MAY use a different path In addition, the MPTCP protocol instance MAY use a different path
scheduler algorithm if TCP_NODELAY is present. For instance, it scheduler algorithm if TCP_NODELAY is present. For instance, it
could use an algorithm that is optimized for latency-sensitive could use an algorithm that is optimized for latency-sensitive
traffic. Specific algorithms are outside the scope of this document. traffic. Specific algorithms are outside the scope of this document.
4.3.3. Buffer Sizing 4.3.3. Buffer Sizing
skipping to change at page 14, line 42 skipping to change at page 14, line 42
REQ1: Turn on/off MPTCP: An application should be able to request to REQ1: Turn on/off MPTCP: An application should be able to request to
turn on or turn off the usage of MPTCP. This means that an turn on or turn off the usage of MPTCP. This means that an
application should be able to explicitly request the use of application should be able to explicitly request the use of
MPTCP if this is possible. Applications should also be able MPTCP if this is possible. Applications should also be able
to request not to enable MPTCP and to use regular TCP to request not to enable MPTCP and to use regular TCP
transport instead. This can be implicit in many cases, since transport instead. This can be implicit in many cases, since
MPTCP must disabled by the use of binding to a specific MPTCP must disabled by the use of binding to a specific
address. MPTCP may also be enabled if an application uses a address. MPTCP may also be enabled if an application uses a
dedicated multipath address family (such as AF_MULTIPATH, dedicated multipath address family (such as AF_MULTIPATH,
[9]). [8]).
REQ2: An application should be able to restrict MPTCP to binding to REQ2: An application should be able to restrict MPTCP to binding to
a given set of addresses. a given set of addresses.
REQ3: An application should be able obtain information on the REQ3: An application should be able obtain information on the
addresses used by the MPTCP subflows. addresses used by the MPTCP subflows.
REQ4: An application should be able to extract a unique identifier REQ4: An application should be able to extract a unique identifier
for the connection (per endpoint). for the connection (per endpoint).
skipping to change at page 17, line 7 skipping to change at page 17, line 7
5.3.2. Enabling and Disabling of MPTCP 5.3.2. Enabling and Disabling of MPTCP
An application can explicitly indicate multipath capability by An application can explicitly indicate multipath capability by
setting TCP_MULTIPATH_ENABLE to a value larger than 0. In this case, setting TCP_MULTIPATH_ENABLE to a value larger than 0. In this case,
the MPTCP implementation SHOULD try to negitiate MPTCP for that the MPTCP implementation SHOULD try to negitiate MPTCP for that
connection. Note that multipath transport will not necessarily be connection. Note that multipath transport will not necessarily be
enabled, as it requires multiple addresses and support in the other enabled, as it requires multiple addresses and support in the other
end-system and potentially also on middleboxes. end-system and potentially also on middleboxes.
Building on the backwards-compatibility specified in Section 4.2.1,
if an application enables MPTCP but binds to a specific address or
interface, MPTCP MUST be enabled, but MPTCP MUST respect the
application's choice and only use addresses that are explicitly
provided by the application. Note that it would be possible for an
application to use the legacy bindings, and then expand on them by
using TCP_MULTIPATH_ADD. Note also that it is possible for more than
one local address to be initially available to MPTCP in this case, if
an application has bound to a specific interface with multiple
addresses.
An application can disable MPTCP setting TCP_MULTIPATH_ENABLE to a An application can disable MPTCP setting TCP_MULTIPATH_ENABLE to a
value of 0. In that case, MPTCP MUST NOT be used on that connection. value of 0. In that case, MPTCP MUST NOT be used on that connection.
After connection establishment, an application can get the value of After connection establishment, an application can get the value of
TCP_MULTIPATH_ENABLE. A value of 0 then means lack of MPTCP support. TCP_MULTIPATH_ENABLE. A value of 0 then means lack of MPTCP support.
Any value equal to or larger than 1 means that MPTCP is supported. Any value equal to or larger than 1 means that MPTCP is supported.
As alternative to setting an explicit value, an application could As alternative to setting an explicit value, an application could
also use a new, separate address family called AF_MULTIPATH [9]. also use a new, separate address family called AF_MULTIPATH [8].
This separate address family can be used to exchange multiple This separate address family can be used to exchange multiple
addresses between an application and the standard sockets API, and addresses between an application and the standard sockets API, and
additionally acts as an explicit indication that an application is additionally acts as an explicit indication that an application is
MPTCP-aware, i.e., that it can deal with the semantic changes of the MPTCP-aware, i.e., that it can deal with the semantic changes of the
sockets API, in particular concerning getpeername() and sockets API, in particular concerning getpeername() and
getsockname(). The usage of AF_MULTIPATH is also more flexible with getsockname(). The usage of AF_MULTIPATH is also more flexible with
respect to multipath transport, either IPv4 or IPv6, or both in respect to multipath transport, either IPv4 or IPv6, or both in
parallel [9]. parallel [8].
5.3.3. Binding MPTCP to Specified Addresses 5.3.3. Binding MPTCP to Specified Addresses
Before connection establishment, an application can use Before connection establishment, an application can use
TCP_MULTIPATH_ADD socket option to indicate a set of local IP TCP_MULTIPATH_ADD function to indicate a set of local IP addresses
addresses that MPTCP may bind to. The parameter of the function is a that MPTCP may bind to. The parameter of the function is a list of
list of addresses in a corresponding data structure. By extension, addresses in a corresponding data structure. By extension, this
this operation will also control the list of addresses that can be operation will also control the list of addresses that can be
advertised to the peer via MPTCP signalling. advertised to the peer via MPTCP signalling.
If an application binds to a specific address or interface, it is not
required to use the TCP_MULTIPATH_ADD operation for that address. As
explained in Section 5.3.2, MPTCP MUST only use the explicitly
specified addresses in that case.
An application MAY also indicate a TCP port number that MPTCP should An application MAY also indicate a TCP port number that MPTCP should
bind to for a given address. The port number MAY be different to the bind to for a given address. The port number MAY be different to the
one used by existing subflows. If no port number is provided by the one used by existing subflows. If no port number is provided by the
application, the port number is automatically selected by the MPTCP application, the port number is automatically selected by the MPTCP
implementation, and will usually be the same across all subflows. implementation, and will usually be the same across all subflows.
This operation can also be used to modify the address list in use This operation can also be used to modify the address list in use
during the lifetime of an MPTCP connection. In this case, it is used during the lifetime of an MPTCP connection. In this case, it is used
to indicate a set of additional local addresses that the MPTCP to indicate a set of additional local addresses that the MPTCP
connection can make use of, and which can be signalled to the peer. connection can make use of, and which can be signalled to the peer.
skipping to change at page 18, line 33 skipping to change at page 19, line 4
An application that wants a unique identifier for the connection, An application that wants a unique identifier for the connection,
analogous to an (address, port) pair in regular TCP, can query the analogous to an (address, port) pair in regular TCP, can query the
TCP_MULTIPATH_CONNID value to get a local connection identifier for TCP_MULTIPATH_CONNID value to get a local connection identifier for
the MPTCP connection. the MPTCP connection.
This is a 32-bit number, and SHOULD be the same as the local This is a 32-bit number, and SHOULD be the same as the local
connection identifier sent in the MPTCP handshake. connection identifier sent in the MPTCP handshake.
6. Other Compatibility Issues 6. Other Compatibility Issues
6.1. Usage of the SCTP Socket API 6.1. Usage of the SCTP Socket API
For dealing with multi-homing, several socket API extensions have For dealing with multi-homing, several socket API extensions have
been defined for SCTP [14]. As MPTCP realizes multipath transport been defined for SCTP [13]. As MPTCP realizes multipath transport
from and to multi-homed endsystems, some of these interface function from and to multi-homed endsystems, some of these interface function
calls are actually applicable to MPTCP in a similar way. calls are actually applicable to MPTCP in a similar way.
API developers MAY wish to integrate SCTP and MPTCP calls to provide API developers MAY wish to integrate SCTP and MPTCP calls to provide
a consistent interface to the application. Yet, it must be a consistent interface to the application. Yet, it must be
emphasized that the transport service provided by MPTCP is different emphasized that the transport service provided by MPTCP is different
to SCTP, and this is why not all SCTP API functions can be mapped to SCTP, and this is why not all SCTP API functions can be mapped
directly to MPTCP. Furthermore, a network stack implementing MPTCP directly to MPTCP. Furthermore, a network stack implementing MPTCP
does not necessarily support SCTP and its specific socket interface does not necessarily support SCTP and its specific socket interface
extensions. This is why the basic API of MPTCP defines additional extensions. This is why the basic API of MPTCP defines additional
socket options only, which are a backward compatible extension of socket options only, which are a backward compatible extension of
TCP's application interface. An integration with the SCTP API is TCP's application interface. An integration with the SCTP API is
outside the scope of the basic API. outside the scope of the basic API.
6.2. Incompatibilities with other Multihoming Solutions 6.2. Incompatibilities with other Multihoming Solutions
The use of MPTCP can interact with various related sockets API The use of MPTCP can interact with various related sockets API
extensions. The use of a multihoming shim layer conflicts with extensions. The use of a multihoming shim layer conflicts with
multipath transport such as MPTCP or SCTP [12]. Care should be taken multipath transport such as MPTCP or SCTP [11]. Care should be taken
for the usage not to confuse with the overlapping features of other for the usage not to confuse with the overlapping features of other
APIs: APIs:
o SHIM API [12]: This API specifies sockets API extensions for the o SHIM API [11]: This API specifies sockets API extensions for the
multihoming shim layer. multihoming shim layer.
o HIP API [13]: The Host Identity Protocol (HIP) also results in a o HIP API [12]: The Host Identity Protocol (HIP) also results in a
new API. new API.
o API for Mobile IPv6 [11]: For Mobile IPv6, a significantly o API for Mobile IPv6 [10]: For Mobile IPv6, a significantly
extended socket API exists as well. extended socket API exists as well.
In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be
enabled if a network stack uses SHIM6, HIP, or Mobile IPv6. enabled if a network stack uses SHIM6, HIP, or Mobile IPv6.
Furthermore, applications should not try to use both the MPTCP API Furthermore, applications should not try to use both the MPTCP API
and another multihoming or mobility layer API. and another multihoming or mobility layer API.
It is possible, however, that some of the MPTCP functionality, such It is possible, however, that some of the MPTCP functionality, such
as congestion control, could be used in a SHIM6 or HIP environment. as congestion control, could be used in a SHIM6 or HIP environment.
Such operation is outside the scope of this document. Such operation is outside the scope of this document.
6.3. Interactions with DNS 6.3. Interactions with DNS
In multihomed or multiaddressed environments, there are various In multihomed or multiaddressed environments, there are various
issues that are not specific to MPTCP, but have to be considered, issues that are not specific to MPTCP, but have to be considered,
too. These problems are summarized in [15]. too. These problems are summarized in [14].
Specifically, there can be interactions with DNS. Whilst it is Specifically, there can be interactions with DNS. Whilst it is
expected that an application will iterate over the list of addresses expected that an application will iterate over the list of addresses
returned from a call such as getaddrinfo(), MPTCP itself MUST NOT returned from a call such as getaddrinfo(), MPTCP itself MUST NOT
make any assumptions about multiple A or AAAA records from the same make any assumptions about multiple A or AAAA records from the same
DNS query referring to the same host, as it is possible that multiple DNS query referring to the same host, as it is possible that multiple
addresses refer to multiple servers for load balancing purposes. addresses refer to multiple servers for load balancing purposes.
7. Security Considerations 7. Security Considerations
Will be added in a later version of this document. This document first defines the behaviour of the standard TCP/IP API
for MPTCP-unaware applications. As the function offered by this
interface is equivalent to existing APIs and does not offer
additional functionality, the interface design does not result in new
security issues. In general, enabling MPTCP has some security
implications for applications, which are introduced in Section 5.3.3,
and these threats are further detailed in [6]. The protocol
specification of MPTCP [5] defines several mechanism to protect MPTCP
against those attacks.
In addition, the basic MPTCP API for MPTCP-aware applications defines
functions that provide an equivalent level of control and information
as exists for regular TCP. New functions enable adding and removing
local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and
TCP_MULTIPATH_REMOVE). These functions don't add security threats if
the MPTCP stack verifies that the addresses provided by the
application are indeed available as source addresses for subflows.
However, applications should use the TCP_MULTIPATH_ADD function with
care, as new subflows might get established to those addresses.
Furthermore, it could result in some form of information leakage
since MPTCP might advertise those addresses to the other connection
endpoint, which could learn IP addresses of interfaces that are not
visible otherwise.
Use of different addresses should not be assumed to lead to use of
different paths, especially for security purposes.
MPTCP-aware applications should also take care when querying and
using information about the addresses used by subflows
(TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close
subflows, a list of addresses queried once can get outdated during
the lifetime of an MPTCP connection. Then, the list may contain
invalid entries, i.e. addresses that are not used any more, or that
might not even be valid. Applications that want to ensure that MPTCP
only uses a certain set of addresses should explicitly bind to those
addresses.
8. IANA Considerations 8. IANA Considerations
No IANA considerations. No IANA considerations.
9. Conclusion 9. Conclusion
This document discusses MPTCP's application implications and This document discusses MPTCP's application implications and
specifies a basic MPTCP API. For legacy applications, it is ensured specifies a basic MPTCP API. For legacy applications, it is ensured
that the existing sockets API continues to work. MPTCP-aware that the existing sockets API continues to work. MPTCP-aware
applications can use the basic MPTCP API that provides some control applications can use the basic MPTCP API that provides some control
over the transport layer equivalent to regular TCP. A more fine- over the transport layer equivalent to regular TCP. A more fine-
granular interaction between applications and MPTCP requires an granular interaction between applications and MPTCP requires an
advanced MPTCP API, which is not specified in this document. advanced MPTCP API, which is not specified in this document.
10. Acknowledgments 10. Acknowledgments
Authors sincerely thank to the following people for their helpful Authors sincerely thank to the following people for their helpful
comments and reviews of the document: Costin Raiciu, Philip Eardley, comments and reviews of the document: Costin Raiciu, Philip Eardley,
Javier Ubillos, and Michael Tuexen. Javier Ubillos, Michael Tuexen, and John Leslie.
Michael Scharf is supported by the German-Lab project Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de/) funded by the German Federal Ministry of (http://www.german-lab.de/) funded by the German Federal Ministry of
Education and Research (BMBF). Alan Ford was supported by Roke Manor Education and Research (BMBF). Alan Ford was previously supported by
Research and by Trilogy (http://www.trilogy-project.org/), a research Roke Manor Research and by Trilogy (http://www.trilogy-project.org/),
project (ICT-216372) partially funded by the European Community under a research project (ICT-216372) partially funded by the European
its Seventh Framework Program. The views expressed here are those of Community under its Seventh Framework Program. The views expressed
the author(s) only. The European Commission is not liable for any here are those of the author(s) only. The European Commission is not
use that may be made of the information in this document. liable for any use that may be made of the information in this
document.
11. References 11. References
11.1. Normative References 11.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] Braden, R., "Requirements for Internet Hosts - Communication [2] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, [4] 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.
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP [5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Extensions for Multipath Operation with Multiple Addresses", Extensions for Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-04 (work in progress), draft-ietf-mptcp-multiaddressed-06 (work in progress),
July 2011. January 2012.
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", RFC 6181, March 2011. Operation with Multiple Addresses", RFC 6181, March 2011.
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion [7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Control for Multipath Transport Protocols", RFC 6356, Control for Multipath Transport Protocols", RFC 6356,
October 2011. October 2011.
[8] "IEEE Std. 1003.1-2008 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 7, 2008.".
11.2. Informative References 11.2. Informative References
[9] Sarolahti, P., "Multi-address Interface in the Socket API", [8] Sarolahti, P., "Multi-address Interface in the Socket API",
draft-sarolahti-mptcp-af-multipath-01 (work in progress), draft-sarolahti-mptcp-af-multipath-01 (work in progress),
March 2010. March 2010.
[10] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced [9] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6", Sockets Application Program Interface (API) for IPv6",
RFC 3542, May 2003. RFC 3542, May 2003.
[11] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for [10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for
Mobile IPv6", RFC 4584, July 2006. Mobile IPv6", RFC 4584, July 2006.
[12] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets [11] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets
Application Program Interface (API) for Multihoming Shim", Application Program Interface (API) for Multihoming Shim",
RFC 6316, July 2011. RFC 6316, July 2011.
[13] Komu, M. and T. Henderson, "Basic Socket Interface Extensions [12] Komu, M. and T. Henderson, "Basic Socket Interface Extensions
for the Host Identity Protocol (HIP)", RFC 6317, July 2011. for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
[14] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, [13] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich,
"Sockets API Extensions for Stream Control Transmission "Sockets API Extensions for the Stream Control Transmission
Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-32 (work in Protocol (SCTP)", RFC 6458, December 2011.
progress), October 2011.
[15] Blanchet, M. and P. Seite, "Multiple Interfaces and [14] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", Provisioning Domains Problem Statement", RFC 6418,
draft-ietf-mif-problem-statement-15 (work in progress), November 2011.
May 2011.
[16] Wasserman, M. and P. Seite, "Current Practices for Multiple [15] Wasserman, M. and P. Seite, "Current Practices for Multiple-
Interface Hosts", draft-ietf-mif-current-practices-12 (work in Interface Hosts", RFC 6419, November 2011.
progress), July 2011.
[17] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [16] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-05 (work in Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 (work in
progress), October 2011. progress), December 2011.
[17] "IEEE Std. 1003.1-2008 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 7, 2008.".
Appendix A. Requirements on a Future Advanced MPTCP API Appendix A. Requirements on a Future Advanced MPTCP API
A.1. Design Considerations A.1. Design Considerations
Multipath transport results in many degrees of freedom. The basic Multipath transport results in many degrees of freedom. The basic
MPTCP API only defines a minimum set of the API extensions for the MPTCP API only defines a minimum set of the API extensions for the
interface between the MPTCP layer and applications, which does not interface between the MPTCP layer and applications, which does not
offer much control of the MPTCP implementation's behaviour. A offer much control of the MPTCP implementation's behaviour. A
future, advanced API could address further features of MPTCP and future, advanced API could address further features of MPTCP and
skipping to change at page 26, line 17 skipping to change at page 27, line 17
o sctp_connectx() o sctp_connectx()
o sctp_getladdrs() o sctp_getladdrs()
o sctp_getpaddrs() o sctp_getpaddrs()
o sctp_freeladdrs() o sctp_freeladdrs()
o sctp_freepaddrs() o sctp_freepaddrs()
The syntax and semantics of these functions are described in [14]. The syntax and semantics of these functions are described in [13].
A potential objective for the advanced API is to provide a consistent A potential objective for the advanced API is to provide a consistent
MPTCP and SCTP interface to the application. This is left for MPTCP and SCTP interface to the application. This is left for
further study in this document. further study in this document.
Appendix B. Change History of the Document Appendix B. Change History of the Document
Changes compared to version draft-ietf-mptcp-api-03:
o Security consideration section
o Better explanation of the implications of explicitly specified
addresses, most notably during the bind call
o Editorial changes
Changes compared to version draft-ietf-mptcp-api-02: Changes compared to version draft-ietf-mptcp-api-02:
o Updated references o Updated references
o Editorial changes o Editorial changes
Changes compared to version draft-ietf-mptcp-api-01: Changes compared to version draft-ietf-mptcp-api-01:
o Additional text on outdated assumptions if an MPTCP application o Additional text on outdated assumptions if an MPTCP application
does not use fate sharing. does not use fate sharing.
skipping to change at page 28, line 22 skipping to change at page 29, line 32
Michael Scharf Michael Scharf
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
EMail: michael.scharf@alcatel-lucent.com EMail: michael.scharf@alcatel-lucent.com
Alan Ford Alan Ford
Cisco
Ruscombe Business Park
Ruscombe, Berkshire RG10 9NN
UK
EMail: alan.ford@gmail.com EMail: alanford@cisco.com
 End of changes. 48 change blocks. 
85 lines changed or deleted 148 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/