datatracker.ietf.org
Sign In
Version 4.45, 2013-05-14
Report a bug

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

Active Internet-Draft (None)
Document Stream: No stream defined
Last updated: 2013-02-25
Intended RFC status: (None)
Other versions: plain text, pdf, html

Document shepherd:(None)
Shepherd writeup

IESG State: I-D Exists
Responsible AD: (None)
Send notices to: No addresses provided

Internet Engineering Task Force                                R. Winter
Internet-Draft                   University of Applied Sciences Augsburg
Intended status: Informational                                  A. Ripke
Expires: August 27, 2013                         NEC Laboratories Europe
                                                       February 25, 2013

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

Abstract

   Multipath TCP relies on the existence of multiple paths at the end-
   systems typically provided through different IP addresses obtained by
   different ISPs.  While this scenario is certainly becoming
   increasingly a reality (e.g.  mobile devices), currently most end-
   systems are single-homed (e.g.  desktop PCs in an enterprise).  This
   memo describes mechanisms to make multiple paths available to
   multipath TCP-capable end-systems that are not available directly at
   the end-systems but somewhere within the network.

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 August 27, 2013.

Copyright Notice

   Copyright (c) 2013 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 the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Winter & Ripke          Expires August 27, 2013                 [Page 1]
Internet-Draft             single-homed MPTCP              February 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Approaches to Use Multiple Paths in the Network  . . . . . . .  3
     2.1.  Exposing Multiple Paths Through End-host Auto-configuration 3
     2.2.  Heuristic Use of Multiple Paths  . . . . . . . . . . . . .  5
   3.  Other scenarios and extensions . . . . . . . . . . . . . . . .  5
   4.  Alternative approaches . . . . . . . . . . . . . . . . . . . .  5
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  6
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

1.  Introduction

   The IETF has specified 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 an MPTCP-capable destination ([RFC6824],
   [RFC6182]) where paths are defined by sets of source and destination
   IP addresses.  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/interfaces 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 ways how these multiple paths in the network could
   potentially be made available to multipath TCP-capable hosts that are
   single-homed.

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

                             +-------+
                             | DHCP  |
   +-------+      +----------+ Server|
   |       |      |          |       |
   | Host  +------+          +-------+
   |       |      |      +-------+        ISP 1