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/