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]