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

Document Type Active Internet-Draft (individual)
Last updated 2015-10-19
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                                R. Winter
Internet-Draft                                                  M. Faath
Intended status: Informational   University of Applied Sciences Augsburg
Expires: April 21, 2016                                         A. Ripke
                                                 NEC Laboratories Europe
                                                        October 19, 2015

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

Abstract

   Multipath TCP relies on the existence of multiple paths between end-
   systems.  These are typically provided by using different IP
   addresses obtained by different ISPs 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. desktop
   PCs in an enterprise).  It seems also likely that a lot of network
   sites will insist on having all traffic pass a single network element
   (e.g. for security reasons) before traffic is split across multiple
   paths.  This memo therefore 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 April 21, 2016.

Copyright Notice

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

Winter, et al.           Expires April 21, 2016                 [Page 1]
Internet-Draft             single-homed MPTCP               October 2015

   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.

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  . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   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]).  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.
Show full document text