Internet Engineering Task Force                                R. Winter
Internet-Draft                                                  A. Ripke
Intended status: Informational                   NEC Laboratories Europe
Expires: September 8, 2011                                 March 7, 2011


           Multipath TCP Support for Single-homed End-systems
                     draft-wr-mptcp-single-homed-00

Abstract

   Multipath TCP relies on the existence of multiple paths at the end-
   systems.  While this scenario is certainly becoming increasingly a
   reality (e.g. mobile devices), currently most end-systems are single-
   homed (e.g. residential broadband customers).  This memo describes
   mechanisms to make multiple paths available to multipath TCP that are
   not available at the end-systems but somewhere within the network.
   This can be thought of as a form of proxy multi-homing.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 8, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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



Winter & Ripke          Expires September 8, 2011               [Page 1]


Internet-Draft             single-homed MPTCP                 March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  General Operation . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Other scenarios and extensions  . . . . . . . . . . . . . . . . 5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7



































Winter & Ripke          Expires September 8, 2011               [Page 2]


Internet-Draft             single-homed MPTCP                 March 2011


1.  Introduction

   The IETF is specifying a multipath TCP (MPTCP) architecture and
   protocol where end-systems operate a modified standard TCP stack
   which allows packets of the same TCP connection to be sent via
   different paths to a MPTCP-capable destination
   ([I-D.ietf-mptcp-multiaddressed], [I-D.ietf-mptcp-architecture]).
   Using multiple paths has a number of benefits such as an increased
   reliability of the transport connection and an effect known as
   resource pooling [resource_pooling].  Most end-systems today do not
   have multiple paths available in order to make use of multipath TCP,
   however further within the network multiple paths are the norm rather
   than the exception.  This memo therefore describes a way how a
   network element that is multi-homed can somehow "extend" this multi-
   homing to end-systems and act as a kind of multi-homing proxy for the
   end-system, providing the multipath TCP benefits starting at that
   network element.

   In order to illustrate the general mechanism we make use of a simple
   reference scenario shown in Figure 1.

                               +-------+
                               | DHCP  |
     +-------+      +----------+ Server|
     |       |      |          |       |
     | Host  +------+          +-------+
     |       |      |      +-------+        ISP 1
     +-------+      +------+       |----------
                           | Gatew.|
                           |       |----------
                           +-------+        ISP 2

                       Figure 1: Reference Scenario

   The scenario in Figure 1 depicts e.g. a possible SOHO or enterprise
   setup where a gateway/router is connected to two ISPs and a DHCP
   server gives out leases to hosts connected to the local network.
   Both, the gateway and the DHCP server could be on the same device
   (similar to current home gateway implementations).

   The host is running a multipath-capable IP stack, however it only has
   a single interface.  The method described in the following sections
   is to let the host make use of the gateway's two interfaces without
   requiring modifications to the MPTCP implementation.







Winter & Ripke          Expires September 8, 2011               [Page 3]


Internet-Draft             single-homed MPTCP                 March 2011


2.  General Operation

   Multipath TCP distinguishes paths by their source and destination IP
   addresses.  Assuming a certain level of path diversity in the
   Internet, using different source and destination IP addresses for a
   given subflow of a multipath TCP connection will, with a certain
   probability, result in different paths taken by packets of different
   subflows.  Even in case subflows share a common bottleneck, the
   proposed multipath congestion control algorithm will make sure that
   multipath TCP will play nicely with regular TCP flows.

   In order to not impact the TCP implementation, we keep the above
   assumptions multipath TCP makes, i.e. working with different IP
   addresses to use different paths.  Since the end-system is single-
   homed, all IP addresses are bound to the same physical interface.  In
   our reference scenario in Figure 1, the host would receive more than
   one RFC1918 [RFC1918] private IP address from the DHCP server.

       Host                Gateway

                         +-----------------+     ISP1
     +--------+          | src.            |
     |  virt. | 10.1.2.5 | 10.1.0.0/16  __.+----------
     |        +---+      |        __.--'   |
     |  phys. |   |      |  __.--'      N  |
     |        +----------+.:_           A  |
     |        | 10.2.2.6 |   `-.._      T  |
     +--------+          | src.   `-.._    |     ISP2
                         | 10.2.0.0/16 `-..+----------
                         |                 |
                         +-----------------+       |

                        Figure 2: Gateway internals

   The gateway in the figure has received two IP addresses, one from
   each ISP.  The NAT that the gateway is implementing needs to map each
   private IP address of the host consistently to a one of the
   addresses, each private IP to a different public IP.  The way the
   gateway funtions is depicted in more detail in Figure 2.  This way,
   depending on the source address of the host, the packets will either
   go through ISP 1 or ISP 2 and TCP will balance the traffic across
   those two links using its built-in congestion control mechanism.

   The way the gateway has received it's public IP addresses is not
   relevant.  It could be via via DHCP, IPCP or static configuration.
   In order to configure the host via DHCP, we propose two new DHCP
   options.  The first option "mp-proxy-avail" will be sent by single-
   homed multipath TCP-enabled clients in the "Parameter Request List".



Winter & Ripke          Expires September 8, 2011               [Page 4]


Internet-Draft             single-homed MPTCP                 March 2011


   This will show the DHCP server that the client is multipath-capable.
   The DHCP server will answer with "mp-proxy-avail" and the option
   value is set to the number of additional interfaces the gateway can
   offer to the client (in our reference scenario that value would be 1;
   see Figure 3).

    client                                                server
      |                 request mp-proxy-avail              |
      |--------------------------------------------------- >|
      |             mp-proxy-avail 1 + other config         |
      |< ---------------------------------------------------|
      |                                                     |
      |------+                                              |
      |      | configure physical and                       |
      |      | create virtual interface                     |
      |      |                                              |
      |< ----+                                              |
      |                                                     |
      |   virt. interf. 1                                   |
      |      |               send mp-range 1                |
      |      |-------------------------------------------- >|
      |      |        virt. interface config                |
      |      |< --------------------------------------------|
      |      |                                              |
      |      |                                              |


                      Figure 3: DHCP Sequence Diagram

   Upon receipt of the "mp-proxy-avail" option from the server, the
   client can create up to n virtual interfaces, where n is the option
   value.  Each virtual interface will contact the DHCP server and will
   include the "mp-range" option.  The option value will tell the DHCP
   server that the client is requesting an IP out of an IP range that
   the gateway will be forwarding through a different interface.

   The above has been implemented using the ISC DHCP server and client
   version 4.2.1 and the multipath TCP kernel patch 0.5 and a 2.6.36
   Linux kernel.


3.  Other scenarios and extensions

   The reference scenario is only one conceivable setting.  Other
   scenarios such as DSL broadband customers or mobile phones are
   conceivable as well.  As an example, take the DSL scenario.  The home
   gateway could be provided with multiple IP addresses using extensions
   to IPCP.  The home gateway in turn can then implement the DHCP server



Winter & Ripke          Expires September 8, 2011               [Page 5]


Internet-Draft             single-homed MPTCP                 March 2011


   and gateway functionality as described before.  These scenarios will
   be described in future versions of this document.


4.  Acknowledgements

   The authors are supported by Trilogy
   (http://www.trilogy-project.org), a research project (ICT-216372)
   partially funded by the European Community under its Seventh
   Framework Program.  The views expressed here are those of the
   author(s) only.  The European Commission is not liable for any use
   that may be made of the information in this document.


5.  IANA Considerations

   Two new DHCP options are required by this version of this document.


6.  Security Considerations

   TBD.


7.  References

7.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

7.2.  Informative References

   [I-D.ietf-mptcp-architecture]
              Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", draft-ietf-mptcp-architecture-05 (work in
              progress), January 2011.

   [I-D.ietf-mptcp-multiaddressed]
              Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
              Multipath Operation with Multiple Addresses",
              draft-ietf-mptcp-multiaddressed-02 (work in progress),
              October 2010.

   [resource_pooling]
              Wischik, D., Handley, M., and M. Bagnulo Braun, "The



Winter & Ripke          Expires September 8, 2011               [Page 6]


Internet-Draft             single-homed MPTCP                 March 2011


              Resource Pooling Principle", October 2008,
              <http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf>.


Authors' Addresses

   Rolf Winter
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Email: rolf.winter@neclab.eu


   Andreas Ripke
   NEC Laboratories Europe
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Email: andreas.ripke@neclab.eu





























Winter & Ripke          Expires September 8, 2011               [Page 7]