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]
