Network Working Group P. Sarolahti
Internet-Draft HIIT/ICSI
Intended status: Experimental November 20, 2009
Expires: May 24, 2010
Multipath Interface in the Socket API
draft-sarolahti-mptcp-af-multipath-00.txt
Abstract
This document specifies a new address family to be used for sockets
that are bound to more than one IP address, as motivated by the
Multipath TCP work in the IETF. The goal is to use the same set of
function calls as traditionally, but by new address family make it
possible for them to express multiple addresses to connect or bind
to. The document gives a high-level definition of the behavior of
the traditional function calls, but a detailed specification of the
API syntax is not in the scope of this document.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 24, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sarolahti Expires May 24, 2010 [Page 1]
Internet-Draft AF-Multipath November 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Multipath Address Family . . . . . . . . . . . . . . . . . 4
4. Behaviour with Different Networking Functions . . . . . . . . . 6
4.1. Bind . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Connect . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Name resolution . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Get Local Address / Get Remote Address . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Sarolahti Expires May 24, 2010 [Page 2]
Internet-Draft AF-Multipath November 2009
1. Introduction
This document proposes a new way to use the socket API to better
support protocols that use multiple IP addresses at either end of a
connection. The primary motivation for this specification is the
ongoing work on Multipath TCP (e.g., [I-D.ford-mptcp-architecture],
[I-D.ford-mptcp-multiaddressed]), but the same API can be used with
any other protocol that runs multiple addresses on a single socket.
One of the design goals in this specification is to enable support
for multiple addresses in a socket without changing the set of
networking function calls available in the system. This design also
aims to maintain unchanged semantics with the previously familiar
operations to the extent it is possible.
Using Multipath TCP with a traditional socket API with IPv4 address
family (also known as AF_INET) or IPv6 (AF_INET6) address family can
be problematic, as discussed in the API considerations document
[I-D.scharf-mptcp-api]. The socket API was designed with an
assumption that a socket is using just one address, with this address
being explicitly visible to the applications. When the API is used
with a protocol that uses multiple addresses for communication,
defining the semantics of existing function calls that directly refer
to one IP address becomes problematic, potentially making the
existing applications behave defectively when using the legacy socket
API with Multipath TCP. While the motivation of Multipath TCP to
operate on unmodified legacy APIs is well understandable, eventually
a more expressive API is needed to better manage connections using
multiple addresses at either end.
This document specifies a new multipath-compatible address family to
be used with the familiar socket operations, called AF_MULTIPATH.
This address family is composed as a sequence of one or multiple
elements that are each structured in the same way as one of the
existing address families supported by the system, such as AF_INET or
AF_INET6. At the same time, this lets the application indicate if it
supports the use of multiple addresses for the socket, for example
using multipath TCP. One advantage of the Multipath Address Family
is that it supports using different address families, such as IPv4 or
IPv6, in the same address set, thereby enabling dual-stack
functionality between both IPv4 and IPv6 interfaces (although we note
that IPv4 addresses can be expressed as a AF_INET6 structure).
The AF_MULTIPATH address family could be used also with other
protocols capable of multihoming, for example SCTP [RFC4960]. It may
possibly be applicable also to shim-layer approaches to multihoming
such as SHIM6 [RFC5533] or HIP [RFC5206], although these are based on
a different philosophy of splitting locators (IP addresses) from the
host identity. Different API extensions for multihomed protocols
Sarolahti Expires May 24, 2010 [Page 3]
Internet-Draft AF-Multipath November 2009
have been specified (or are being worked on), for example one using a
set of socket options [I-D.ietf-shim6-multihome-shim-api], and
another extending the set of socket operations in the socket API
[I-D.ietf-tsvwg-sctpsocket]. This document deliberately avoids both
approaches, choosing a method that does not require adding several
new socket options or socket operations. The goal has been to
develop a mechanism that fits with the existing operations in the
socket API.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. The Multipath Address Family
Multipath address family (AF_MULTIPATH) is composed of a sequence of
addresses, each expressed using one of the existing address family
formats supported in the system. A desirable behavior would be that
in a system that supports the multipath address family, opening a
socket using one of the traditional single-address families should be
taken as an indication that multiple addresses should not be used for
that socket. However, to allow migration period for legacy
applications that are not converted to use the new address family,
but would benefit from multipath communication, an additional option
switch may be needed to control the behavior on traditional single-
address families.
The address family is structured according to the generic sockaddress
structure as follows. The fields are given in network byte order.
o Length (8 bits)
o Address family (=AF_MULTIPATH) (8 bits)
o Connection identifier (32 bits) (TODO: discuss if this is needed,
or is the socket descriptor sufficient)
o Number of addresses (8 bits)
o Address 1
o Address 2
Sarolahti Expires May 24, 2010 [Page 4]
Internet-Draft AF-Multipath November 2009
o ....
o Address N
Each of the address records above takes the generic sockaddress
format, i.e.:
o Length (8 bits)
o Address family (8 bits)
o Address (...i.e., the rest of sockaddr structure as defined by the
address family...)
When the API is used with Multipath TCP, the Connection identifier
can be equal to the sender token used by Multipath TCP
[I-D.ford-mptcp-multiaddressed]. Connection identifier is only used
locally, and it is not intended that this identifier is communicated
over the network. Connection identifier MUST be unique among all
active connections in the host, and connection identifier MUST NOT be
changed during the lifetime of the Multipath TCP connection. The
same connection identifier SHOULD NOT be reused immediately after a
socket is closed. Similar semantics are applied also to other
multipath protocols, if AF_MULTIPATH is used with them.
While the connection identifier is stable throughout the connection
lifetime, in a dynamic multipath connection the other fields can
change over time: new addresses may be added and earlier addresses
can be removed.
In today's system with Posix API the address family is commonly
either AF_INET or AF_INET6, but the design is not limited to these
address families. Depending on the address family, the address would
typically in a Posix system be structured as sockaddr_in or
sockaddr_in6 structure, with the length set appropriately. Different
address families can be combined in a single AF_MULTIPATH record.
There is a tradition that the IPv4/IPv6 address family is also used
to indicate the protocol family in the socket call, originally
intended to separate UNIX internal protocols from Internet protocols
or ISO protocols. It is unclear (to the author) why the evolution
has lead to use two separate values to indicate IPv4 and IPv6
protocols in the protocol family parameter of the socket call. It
would seem appropriate that as dual-stack IPv4/IPv6 implementations
are commonplace, a single protocol family would be used for opening a
socket for any Internet protocol.
Sarolahti Expires May 24, 2010 [Page 5]
Internet-Draft AF-Multipath November 2009
4. Behaviour with Different Networking Functions
This section defines the intended behavior of commonly used network
operations when used with AF_MULTIPATH address family. The section
gives a high-level definition of the operations to be applied as
appropriate in different application environments.
4.1. Bind
An AF_MULTIPATH socket can bind to several addresses using a single
call. It is possible to use wildcard ("Any") address in some of
entries of the address set. Multiple "Any" addresses could allow
binding several ports to the same socket, although this does not seem
a sensible action to take. AF_MULTIPATH can also contain just one
address entry, in which case the behavior is similar to traditional
single-homed bind. On return, the function call should indicate how
many addresses were successfully bound, using error codes to indicate
that binding failed to all addresses. "Get Local Address" operation
(getsockname in Posix) can be used to investigate which addresses
were successfully bound.
When binding a new socket with no prior AF_MULTIPATH entry,
connection identifier MUST be set to 0. This call can also be used
by an application to indicate that new local addresses should be
added to the connection. In this case connection identifier refers
to an existing connection. If connection identifier is non-zero and
such connection does not exist in the system, the call returns with
failure.
4.2. Connect
An AF_MULTIPATH socket can give multiple addresses to connect to,
assuming the addresses belong to the same host. The protocol may
need to activate these connections one at a time, if the protocol
logic does not permit connecting to multiple addresses
simultaneously. On return, the function call should indicate how
many of the addresses were successfully connected, or an error code.
It is expected that commonly this call is used together with name
resolution, as described below. "Get Remote Address" (getpeername)
operation can be used to investigate which addresses were
successfully connected to.
When connecting a new, earlier unconnected socket, connection
identifier MUST be set to 0. Application can also indicate by this
call, that the protocol stack should try to add new remote addresses
to the connection. In this case connection identifier refers to an
existing connection. If connection identifier is non-zero and such
connection does not exist in the system, the call returns with
Sarolahti Expires May 24, 2010 [Page 6]
Internet-Draft AF-Multipath November 2009
failure.
A consideration: one failure mode is that new address is reachable,
but points to a different host. MPTCP MUST be able to detect this
before any data gets exchanged. This might be something for the main
MPTCP specification to think about, because this seems like a generic
MPTCP security issue on connection hijacking.
4.3. Name resolution
In a typical usage of a name resolver, multiple addresses may be
returned from a name server, and a client cycles through the given
addresses until connection is successfully established. Sometimes a
client may need to try separately IPv6 addresses and IPv4 addresses,
when it is not certain whether IPv6 is supported on the path.
When name resolver is called with AF_MULTIPATH enabled, the name
server returns the available address records as separate entries in a
single AF_MULTIPATH structure. This would mean that the call returns
a single AF_MULTIPATH host entry that may contain multiple addresses
as specified in the AF_MULTIPATH format. An application may directly
place the returned AF_MULTIPATH structure as a parameter of a connect
call, indicating that a multipath protocol should try these addresses
as subflows of the multipath connection. It is recommended that when
resolver receives an AF_MULTIPATH-enabled call, it invokes name
server queries for both IPv6 and IPv4 addresses, if both are
supported in the system, and records of both types are returned to
the application, if available.
4.4. Get Local Address / Get Remote Address
These calls operate similarly than originally: they return a
sockaddress structure at local or remote end. AF_MULTIPATH address
family is returned if it has been used earlier with the same socket.
The set of local or remote addresses SHOULD be up-to-date with the
currently active set in the protocol implementation. Along with the
current addresses, an application learns also about the connection
identifier with this call. The connection identifier returned with
"Get Remote Address" MUST be the same as the identifier returned with
"Get Local Address", since it only has local meaning, and therefore
the other end of the connection typically gets entirely different
connection identifier for the connection.
5. Security Considerations
No additional security threats known because of the multipath address
family.
Sarolahti Expires May 24, 2010 [Page 7]
Internet-Draft AF-Multipath November 2009
6. References
6.1. Normative References
[I-D.ford-mptcp-architecture]
Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford,
"Architectural Guidelines for Multipath TCP Development",
draft-ford-mptcp-architecture-00 (work in progress),
October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.ford-mptcp-multiaddressed]
Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses",
draft-ford-mptcp-multiaddressed-02 (work in progress),
October 2009.
[I-D.ietf-shim6-multihome-shim-api]
Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
"Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-10
(work in progress), October 2009.
[I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-19 (work in progress),
February 2009.
[I-D.scharf-mptcp-api]
Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-scharf-mptcp-api-00 (work in
progress), October 2009.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
Sarolahti Expires May 24, 2010 [Page 8]
Internet-Draft AF-Multipath November 2009
Author's Address
Pasi Sarolahti
HIIT/ICSI
1947 Center Street (Suite 600)
Berkeley, CA 94704
USA
Phone: +1 (510) 409 - 9972
Email: pasi.sarolahti@iki.fi
URI: http://www.iki.fi/pasi.sarolahti/
Sarolahti Expires May 24, 2010 [Page 9]