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]