Internet DRAFT - draft-haddad-homenet-multihomed

draft-haddad-homenet-multihomed







Network Working Group                                          W. Haddad
Internet-Draft                                                  Ericsson
Intended status: Informational                                 D. Saucez
Expires: April 3, 2016                            INRIA Sophia Antipolis
                                                              J. Halpern
                                                                Ericsson
                                                         October 1, 2015


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

Abstract

   Multihoming becomes popular in residential and SOHO networks
   indicating the absolute necessity of fully supporting multihoming in
   Homenet.  While the approach followed in Homenet is to delegate
   multihoming management to hosts, we propose to enable multihoming in
   Homenet by the mean of the infrastructure instead of the hosts.

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 3, 2016.

Copyright Notice

   Copyright (c) 2015 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



Haddad, et al.            Expires April 3, 2016                 [Page 1]

Internet-Draft           Multihoming in Homenet             October 2015


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

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 one 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 sketches a possible solution to that
   problem.




Haddad, et al.            Expires April 3, 2016                 [Page 2]

Internet-Draft           Multihoming in Homenet             October 2015


2.  Homenet multihoming without host involvement

   It is known 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 and SOHO 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.  Also,
   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 also 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 at the Homenet user level.  Multihoming must be
   transparent for users and devices.

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

   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




Haddad, et al.            Expires April 3, 2016                 [Page 3]

Internet-Draft           Multihoming in Homenet             October 2015


   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 residential
   and SOHO networks, a dedicated middlebox is added to 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 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.





















Haddad, et al.            Expires April 3, 2016                 [Page 4]

Internet-Draft           Multihoming in Homenet             October 2015


                      `.     MSP    ,'
                        `.---+----.'
                             |
      .-----.        .+------+--------+.
    .'       '.   .'                    `-.
    | REMOTE  |.-'                         `\
    .         .                              `.
     '.-----.'            Internet             \
            |                                  +
            :    .-----.            .-----.    ;
            `. .'       '.        .'       '. .'
             '.|  ISP1   |        |  ISP2   |-'
               .         .`------'.         .
                '.--+--.'          '.--+--.'
                    |                  |
              .-----|-------------------|------.
            .'   +--+--+             +--+--+    '.
           /     | 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.





Haddad, et al.            Expires April 3, 2016                 [Page 5]

Internet-Draft           Multihoming in Homenet             October 2015


   As Homenet is targeting IPv6 networks, communications between the
   Homenet and the MSP cannot rely on NAT but instead they might use
   encapsulation.  For that purpose, LISP [RFC6830] is a perfect
   candidate.  In this case, the MSPMB is an xTR.  To ensure zero
   configuration at the Homenet level, the EID-to-RLOC Cache can be
   populated on the fly by a mapping system hosted and managed by the
   MSP.  A major advantage of using LISP for communications between the
   MSP and the Homenet is that residential and SOHO networks would then
   have access the IPv6 Internet without the need of subscribing to IPv6
   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 (which is straightforward with LISP).  Finally,
   UPnP can be used for special services provided to the Homenet by its
   ISPs.

5.  Security Considerations

   Traffic redirection can be used for DoS or eavesdropping.

6.  Conclusion

   Multihoming in Homenet is 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, DOI 10.17487/RFC5533,
              June 2009, <http://www.rfc-editor.org/info/rfc5533>.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
              <http://www.rfc-editor.org/info/rfc6182>.




Haddad, et al.            Expires April 3, 2016                 [Page 6]

Internet-Draft           Multihoming in Homenet             October 2015


   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

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 April 3, 2016                 [Page 7]