Multihoming in Homenet
draft-haddad-homenet-multihomed-01

Network Working Group                                          W. Haddad
Internet-Draft                                                  Ericsson
Intended status: Informational                                 D. Saucez
Expires: September 30, 2013                       INRIA Sophia Antipolis
                                                              J. Halpern
                                                                Ericsson
                                                          March 29, 2013

                         Multihoming in Homenet
                   draft-haddad-homenet-multihomed-01

Abstract

   So far, multihoming in Homenet must be supported by the hosts as
   there is no mean to use simultaneously the different ISPs of the
   Homenet without risking flow disruption.  In this memo, we propose to
   revise the way multihoming is conceived in Homenet by relying on the
   infrastructure instead of the hosts.  We also propose a high level
   solution that answers this particular problem.

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 30, 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

Haddad, et al.         Expires September 30, 2013               [Page 1]
Internet-Draft           Multihoming in Homenet               March 2013

   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Homenet multihoming without host involvement  . . . . . . . .   3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Homenet multihoming with MSP  . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   So far, multihoming in Homenet must be supported by the hosts with
   solutions like Shim6 [RFC5533] or MPTCP [RFC6182] as there is no mean
   to use simultaneously the different ISPs of the Homenet without
   risking flow disruption.  In this memo, we propose the creation of a
   new multihoming service for Homenets.  The concept relies on a
   middlebox added between the home network and its gateways with the
   ISPs.  On the on hand, this middlebox is in charge to redirect the
   home network traffic to a multihoming service provider (MSP) by
   selecting the most appropriate Homenet's ISPs.  On the other hand,
   the MSP is in charge of attracting traffic normally destined to the
   home network and then, the MSP can eventually redirect the traffic to
   its final destination, the Homenet itself, such that it enters the
   Homenet via the most appropriate ISP.

   Section 2 describes the multihoming problem in Homenet when hosts
   cannot support it directly.  Section 3 gives the necessary
   requirements.  Section 4 proposes a high level description of a
   possible solution to that problem.

Haddad, et al.         Expires September 30, 2013               [Page 2]
Internet-Draft           Multihoming in Homenet               March 2013

2.  Homenet multihoming without host involvement

   It is known for fact that multihoming reduces costs for ISPs by
   allowing higher aggregated bandwidth, better quality of service, and
   higher robustness.

   Alternatively, the access to multiple ISPs at the same time for
   residential users is now a reality, e.g., ADSL + Cable + 4G, but
   there is currently no simple solution for home networks to exploit
   it.  For now, the only solution is to modify end-hosts with protocols
   such as Shim6 or MPTCP in order for hosts to change IP addresses on
   elapsing communications.

   We claim that multihoming for Homenets will become a reality and will
   provide the same benefits as those observed for the ISPs.  We also
   claim that requiring every single device in the Homenet to be
   modified to support multihoming is not acceptable as some devices
   have limited resources and cannot achieve it correctly and because it
   would dramatically slow down the adoption of multihoming in the
   Homenet.  Finally, letting every device deciding of the routing
   strategy (e.g., shall I route my traffic via left or right ISP?)
   might cause management issues.

   At the light of this, the question can be: How can we achieve
   multihoming in Homenets, without changing neither the devices
   connected to the Homenet, nor the protocols and operations of the
   Homenet's ISPs?

3.  Requirements

   In order to fix the solutions space of our problem, we have isolated
   fours requirements.

   As we are in the context of Homenet, requirement (1) is to have zero
   configuration need.  Multihoming must be transparent for users and
   devices.

   Also, residential network operators (i.e., John Does) do not have
   enough power to make specific settlements or negotiations with their
   ISP, the solution thus have to be completely independent of the home
   network's ISPs and the ISPs cannot have any mean to forbid the
   solution.  Requirement (2) is thus ISP independence.

Haddad, et al.         Expires September 30, 2013               [Page 3]
Internet-Draft           Multihoming in Homenet               March 2013

   Multihoming offers the possibility to implement policies, and to some
   extend even capabilities, at any arbitrary level.  For example, the
   home network can determine the number of ISPs it is using
   simultaneously or limit flows for example to only go via one
   particular ISP at a given speed.  Requirement (3) is thus policies/
   capabilities.

   Finally, and this is related to policies and capabilities, the system
   must be able to provide quality of service (to some extend)to ensure
   Quality of Experience.  We call the requirement (4) Quality of
   Service.

4.  Homenet multihoming with MSP

   To offer fast and efficient deployment of multihoming in home
   networks, we suggest the addition of a new special middlebox that
   would be in charge of dealing with multihoming, on behalf of the
   devices.  This middlebox is logically linked with a Multihoming
   Service Provider (MSP).  The role of the MSP is to achieve the
   multihoming for the Homenet by using offloading: the Homenets, by the
   mean of the middlebox, offloads all its Internet traffic to the MSP,
   and the offloading is such that the traffic leverages the Homenet's
   multihoming capability.

   The MSP can logically be seen as a service in the cloud (in a remote
   network or in devices widely deployed by the MSP in the ISPs).  The
   service is two-fold.  On the one hand, the MSP must attract the
   traffic sent by the Homenet to the Internet, this part is ensured by
   the middle-box deployed at the Homenet.  On the other hand, the MSP
   must attract traffic sent by the Internet to the Homenet, before this
   last can receive it.  Then, the MSP can send this traffic to the
   Homenet via the most relevant ISP.

   The figure below gives a reference network for the multihoming
   service for Homenet.

                     `.     MSP    ,'
                       `.---+----.'
                            |
     .-----.        .+------+--------+.
   .'       '.   .'                    `-.
   | REMOTE  |.-'                         `\
   .         .                              `.
    '.-----.'            Internet             \
           |                                  +
           :    .-----.            .-----.    ;
           `. .'       '.        .'       '. .'
            '.|  ISP1   |        |  ISP2   |-'

Haddad, et al.         Expires September 30, 2013               [Page 4]
Internet-Draft           Multihoming in Homenet               March 2013

              .         .`------'.         .
               '.--+--.'          '.--+--.'
                   |                  |
             .-----|-------------------|------.
           .'   +--+--+             +--+--+    '.
          /     | Gw1 |   HOMENET   | Gw2 |      \
        .'      +--+--+             +--+--+       '.
                   '.                .'
                     \  +-------+  ./
                      '.| MSPMB |.'
                        +---+---+
                            |
                        ____+____ LAN

                        Figure 1: Reference Network

   In this figure, HOMENET is the multihomed Homenet, connected to ISP1
   via gateway Gw1 and to ISP2 via gateway Gw2.  The remote end of
   communications with the Homenet is designated by REMOTE.  MSPMB
   designates the MSP middlebox in the home network and is logically
   linked to the MSP multihoming service provider.

   Let's imagine that the best to send traffic from the Homenet to the
   remote end is to go via ISP2 while for the traffic from the remote
   end to the Homenet it is better to go via ISP1.  In this case, the
   traffic generated from Homenet's LAN is caught by MSPMB that divert
   traffic to Gw2, then crosses ISP2 and the Internet to reach MSP, then
   REMOTE.  On the other direction, traffic sent by REMOTE goes to MSP
   that sends the traffic on the Internet to ISP1, then it goes to Gw1,
   MSPMB, and finally the LAN.

   The Multihoming Service Provider (MSP) would typically be operated on
   an AS well connected to Homenet's ISPs.  Or alternatively, a Service
   provider that has its own devices deployed at the Homenet's ISPs.

   The service we propose answers the problem exposed in Section 3 in an
   elegant way.  It also fulfills the four requirements stated above.
   Requirement (1) (zeroconf) is respected if MSPMB is given directly by
   the MSP, which can thus be pre-configured to access the MSP service
   provider.  If it is not the case, the process can be simplified if a
   generalized name and protocol is used to configure the middlebox
   (e.g., msp.example.org).  In addition, if Gw1 and Gw2 provide
   addresses by the mean of DHCPv6 or RA, addresses at the MSPMB will be
   configured automatically as well.  Obviously, policies and
   capabilities need configuration either from the home network operator
   or the MSP directly.  Finally, UPnP can be used for special services
   provided to the Homenet by its ISPs.

Haddad, et al.         Expires September 30, 2013               [Page 5]
Internet-Draft           Multihoming in Homenet               March 2013

5.  Security Considerations

   Traffic redirection can be used for DoS or eavesdropping.

6.  Conclusion

   Multihoming in Homenet is still considered to be solved by the hosts
   directly.  In this memo, we propose to not involving host in
   multihoming operations and instead rely on a Multihoming Service
   Provider deploying a middlebox in the Homenet network in charge of
   operating multihoming services.

7.  Normative References

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, June 2009.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, March 2011.

Authors' Addresses

   Wassim Haddad
   Ericsson
   6210 Spine Road
   Boulder, CO  80301
   USA

   Email: Wassim.Haddad@ericsson.com

   Damien Saucez
   INRIA Sophia Antipolis
   2004, Route des Lucioles BP 93
   06902 Sophia Antipolis CEDEX
   France

   Email: damien.saucez@inria.fr

   Joel
   Ericsson
   P.O. Box 6049
   Leesburg, VA  20178
   USA

   Email: Joel.Halpern@ericsson.com

Haddad, et al.         Expires September 30, 2013               [Page 6]
Internet-Draft           Multihoming in Homenet               March 2013

Haddad, et al.         Expires September 30, 2013               [Page 7]