[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
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]