Network Working Group W. Haddad
Internet-Draft Ericsson
Intended status: Informational D. Saucez
Expires: March 29, 2013 INRIA Sophia Antipolis
J. Halpern
Ericsson
September 25, 2012
Multihoming in Homenet
draft-haddad-homenet-multihomed-00
Abstract
So far, multihoming in Homenet must be supported by the hosts as
there is no mean to use simultaneously the different Internet Service
Providers of the "Homenet" without risking flow disruption. In this
memo, we describe the problem statement for multihoming in Homenet.
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 March 29, 2013.
Copyright Notice
Copyright (c) 2012 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 March 29, 2013 [Page 1]
Internet-Draft Multihoming in Homenet September 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Homenet multihoming with MSP . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Haddad, et al. Expires March 29, 2013 [Page 2]
Internet-Draft Multihoming in Homenet September 2012
1. Introduction
So far, multihoming in Homenet must be supported by the hosts with
solutions like Shim6 or MPTCP as there is no mean to allow
simultaneous use of different Internet Service Providers (ISPs)
without risking flow disruption. In this memo, we propose the
creation of a new multihoming service for Homenets. The concept
relies on installing a middlebox between the home network and its
gateways with ISPs. On one hand, such middlebox would be in charge
of redirecting home network traffic to a "Multihoming Service
Provider (MSP)" by selecting the most appropriate Homenet's ISPs. On
the other hand, the MSP is also in charge of attracting traffic
normally destined to the home network and then eventually, redirect
the traffic to its final destination, i.e., the Homenet itself, such
that it enters the Homenet via the most appropriate ISP.
Section 2 gives a problem statement for multihoming in Homenet.
Section 3 gives the necessary requirements. Section 4 proposes a
high level description of a possible solution to that problem.
2. Problem statement
It is known for fact that multihoming has allowed dramatic cost
reduction for ISPs by allowing higher aggregated bandwidth, better
quality of service, and higher robustness.
Alternatively, simultaneous access to multiple ISPs serving
residential users is now a reality, e.g., ADSL + Cable + 4G, but
there is currently no simple solution for home networks to fully
exploit its potential. Indeed, the only solution would be to modify
end-hosts with protocols like Shim6 or MPTCP such that the hosts can
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 "multi-
homing capable" is too far fetched, as some devices are very limited
in term of functionalities to meet multi-homing requirements.
Furthermore, it would dramatically slow down the adoption of
multihoming in the Homenet. Finally, letting every home device to
decide of the routing strategy (e.g., shall I route my traffic via
left or right ISP?) is not common!
The above description pushes us to ask the following question: How
can we achieve multihoming in Homenets, without requiring change on
devices connected to the Homenet nor on the protocols and operations
of the Homenet's ISPs?
Haddad, et al. Expires March 29, 2013 [Page 3]
Internet-Draft Multihoming in Homenet September 2012
3. Requirements
In order to fix the solutions space of our problem, we highlight few
requirements.
As we are in the context of Homenet, requirement (1) is to have zero
configuration.
Also, residential network operators (i.e., John Doe's) lack
incentive(s) to make specific settlements or conduct negotiations
with other (competitor) ISPs. It follows that the solution have to
be completely independent of home network's ISPs AND ISPs should not
have the mean to forbid the solution. Thus, requirement (2) is 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.com" to only "go via one
particular ISP" at a given speed. Thus, requirement (3) is policies/
capabilities.
On a related topic, the system must be able to ensure that applied
policies/capabilities can meet the expected end-user's "Quality of
Experience (QoE)". We call such requirement (4) "Quality of
Experience".
Finally, it is worthy mentioning that the above multi-homing
requirements are also applicable and desirable by small and medium
enterprises (SMEs).
4. Homenet multihoming with MSP
To offer fast and efficient deployment of multihoming in home
networks, we suggest adding a new (logical) dedicated middlebox that
would be in charge of dealing with multihoming, on behalf of homenet
devices. Such middlebox is logically linked with an MSP whose role
is to achieve multihoming for Homenet by using offloading: the
Homenet, from the middlebox perspective, offloads all its Internet
traffic to the MSP. Offloading is such that the traffic leverages
the Homenet's multihoming capabilities.
The MSP can logically be described as a service in the cloud (e.g.,
in a remote network or in devices widely deployed by the MSP in the
ISPs). The service is two-fold. On one hand, the MSP must attract
the traffic sent by the Homenet to the Internet; this part is taken
care of by the middlebox deployed at the Homenet. On the other hand,
Haddad, et al. Expires March 29, 2013 [Page 4]
Internet-Draft Multihoming in Homenet September 2012
the MSP must attract traffic sent by the Internet to the Homenet
before the latter receive it. Then, the MSP can send incoming
traffic to the Homenet via the most relevant ISP.
The figure below gives a reference network for the multihomming
service for Homenet.
`. MSP ,'
`.---+----.'
|
.-----. .+------+--------+.
.' '. .' `-.
| REMOTE |.-' `\
. . `.
'.-----.' Internet \
| +
: .-----. .-----. ;
`. .' '. .' '. .'
'.| ISP1 | | ISP2 |-'
. .`------'. .
'.--+--.' '.--+--.'
| |
.-----|-------------------|------.
.' +--+--+ +--+--+ '.
/ | Gw1 | HOMENET | Gw2 | \
.' +--+--+ +--+--+ '.
'. .'
\ +-------+ ./
'.| MSPMB |.'
+---+---+
|
____+____ LAN
Figure 1: Reference Network
The above figure shows a logical distribution of different boxes in a
typical multihomed Homenet. As illustrated, HOMNET is connected to
ISP1 via gateway Gw1 and to ISP2 via gateway Gw2. The remote end of
communications with 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 way to send traffic from HOMENET to
REMOTE is to go via ISP2 while for traffic sent from REMOTE to
HOMENET, it is better to go via ISP1. In such scenario, traffic
generated from HOMENET's LAN is caught by MSPMB which diverts traffic
to Gw2, then crosses ISP2 and the Internet to reach MSP, then REMOTE.
In the other direction, traffic sent by REMOTE goes to MSP that sends
Haddad, et al. Expires March 29, 2013 [Page 5]
Internet-Draft Multihoming in Homenet September 2012
the traffic on the Internet to ISP1, then it goes to Gw1, MSPMB and
finally reach HOMENET.
Note that in real deployment, MSPMB functionality would be integrated
with both Gw1 and Gw2, i.e., only one physical box would connect
HOMENET to both ISPs.
The Multihoming Service Provider (MSP) would typically be operated on
an AS which is well connected to all Homenet's ISPs. Or
alternatively, a service provider that has its own devices deployed
at the ISPs
As we can observe, the service we propose answers the problem
statement 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 preconfigured to access
the MSP service provider. If it is not the case, the process can be
simplified if a generalized name and protocol are 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. Note also that UPnP can be used for special
services provided to the Homenet by its ISPs.
5. Security Considerations
Obviously, traffic redirection can be used for DoS or eavesdropping.
6. Conclusion
In this memo, we claim that multihoming can be of great help for home
networks to reduce costs and improve their resiliency and
performance. Based on that, we give a general problem statement for
multihoming in Homenet and state four fundamental requirements that
encompass zero configuration, independence from Internet Service
Providers, enabling implementation of policies and capabilities, and
providing means for improving QoE.
In addition to describing the problem, we propose a general solution
that leverages the use of a settop box to deviate traffic to the
cloud via any of the Homenet's ISPs. The multihoming service is
operated by a Multihoming Service Provider or MSP.
Haddad, et al. Expires March 29, 2013 [Page 6]
Internet-Draft Multihoming in Homenet September 2012
7. Acknowledgments
Special thanks to Luigi Ianone and Florin Coras for their valuable
feedback.
Authors' Addresses
Wassim Haddad
Ericsson
300 Holger Way
San Jose, CA 95134
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 Halpern
Ericsson
P.O. Box 6049
Leesburg, VA 20178
USA
Email: Joel.Halpern@ericsson.com
Haddad, et al. Expires March 29, 2013 [Page 7]