Network Working Group K. Shima Internet-Draft IIJ Innovation Institute Inc. Intended status: Informational Y. Sekiya Expires: September 12, 2011 The University of Tokyo March 11, 2011 Network Portability Requirements and Models for Cloud Environment draft-shima-clouds-net-portability-reqs-and-models-00 Abstract Recent progress of virtual machine technology made it possible to host various Internet service nodes in a so called cloud environment. The virtual machine hosting technology provides a method to migrate a virtual machine from one hypervisor to another. However, such a technology is mainly focusing on a migration between hypervisors attached to the same link, and tend not to consider migration over the Internet. This document mentions the purpose of that type of operation and describe several possible operation methods to provide network portability in cloud systems. 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 12, 2011. Copyright Notice Copyright (c) 2011 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 Shima & Sekiya Expires September 12, 2011 [Page 1] Internet-Draft Network Portability March 2011 carefully, as they describe your rights and restrictions with respect 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. Network Portability Requirements . . . . . . . . . . . . . . . 3 3. Network Portability Models . . . . . . . . . . . . . . . . . . 4 3.1. Host-oriented Portability Model . . . . . . . . . . . . . . 4 3.2. Network-oriented Portability Model . . . . . . . . . . . . 4 4. Implementation Examples . . . . . . . . . . . . . . . . . . . . 4 4.1. Wide area VLAN-based Network Porability . . . . . . . . . . 5 4.2. Mobile IPv6-based Network Porability . . . . . . . . . . . 5 4.3. NEMO-based Network Porability . . . . . . . . . . . . . . . 6 4.4. Routing based network portability . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Shima & Sekiya Expires September 12, 2011 [Page 2] Internet-Draft Network Portability March 2011 1. Introduction The document describes requirements and methodology of network migration for inter-datacenter and inter-clouds. The progress of virtualization technology makes changes for services on the Internet to work on the infrastructure of virtual nodes, called PaaS (Platform as a Services.) A PaaS is built and provided in single datacenter by single organization nowadays, however, the needs of building distributed, inter-datacenters PaaS and inter-connecting existing PaaS(es) are growing. Because inter-datacenters PaaS is required for administrative points. If a datacenter is encountered network circuit or power troubles, administrators or users of PaaS want to move the virtual nodes in a datacenter to other datacenters or other PaaS(es) without service interruption. In order to migrate virtual nodes between inter-datacenters and inter-clouds without service interruptions and changes, network portability technologies are required between the datacenters and clouds. 2. Network Portability Requirements The requirements of network portability for migrating vitrual nodes between datacenters and between clouds are below. o providing the same user service networks between each datacenter and cloud Each user has different service networks and it should be possible for users to use their networks on any datacenters or clouds. If the service infrastructure is operated by a single administrative organization, it is possible to use VLAN and VPN technologies to achieve this property, however, building user networks using such technologies is difficult in inter-datacenters or inter-clouds cases where administrative organizations differ. Since VLAN is a layer-2 technology and it requires direct circuit between datacenters, it is difficult from costly point of view. VPN is a cost-effective technology and it is possible to provide user networks on each datacenters and clouds, however, if the clouds are administrated by different organizations, it is difficult and costly for administrators to build a lot of VPN connection for all user networks. o High-Availability of user networks Shima & Sekiya Expires September 12, 2011 [Page 3] Internet-Draft Network Portability March 2011 Even if using VLAN and VPN technologies, each user network has a single connecting point to the Internet. It may be a single point of failure of inter-datacenter and inter-clouds PaaS service. Network potability in inter-datacenters and inter-clouds should provide High-Availability capability. 3. Network Portability Models We consider two kinds of network portability models in this draft. One is the host-oriented portability model, and the other is the network-oriented portability model. 3.1. Host-oriented Portability Model In this model, each host (virtual machine) manages the network portability. To adpot this model, each host must be equipped with some kinds of host mobility support. Every time a host migrates from one hypervisor to another hypervisor and the attached network environment of the migrated host changes, the host must be trigger mobility function to adapt the current attached network environment. Examples implementation of this model are using host mobility protocols such as Mobile IPv6 or HIP, and advertising host route entry from the moving node. 3.2. Network-oriented Portability Model In this model, the network resource to which the host is attached before migration and after migration does not change. Since the migrated host doesn't notice the network environment change, it can continue to work after the migration. To provide the same network environment, the cloud system must support network resource migration between the previous location and current location of the host. Examples of this model is using VLAN, and using VPN connection. 4. Implementation Examples In this section, we show some of the implementation example of network portability in cloud system. Section 4.1 describes an example of the network-based network portability implementation using wide area VLAN configuration. Section 4.2 describes an example of the host-based network portability implementation using Mobile IPv6 [RFC3775]. Section 4.3 describes another example of the network- based network portability implementation using NEMO BS. [RFC3963] Section 4.4 describes another example of the host-based network portability implementation using host route technology. Shima & Sekiya Expires September 12, 2011 [Page 4] Internet-Draft Network Portability March 2011 4.1. Wide area VLAN-based Network Porability One possible solution to provide network portability in a cloud system is that to provide a seamless layer 2 network to the entire cloud system. Recently, since the wide area connectivity is getting faster and faster, so it becomes realistic to extend a layer 2 network from one site to other site where is geographically far. In this case, the hypervisor and host configuration become simple. All the hypervisors are attached to the same layer 2 link which is widely extended to every sites which consist the entire cloud system. A host is configured with the network which is bridged to the wide area layer 2 network. The migration procedure does not require any additional configuration or operation. Since all the hypervisors share the same layer 2 network, hosts can migrate to any one of the hypervisors attached to the layer 2 network. 4.2. Mobile IPv6-based Network Porability In this case, all the hosts (which are virtual machines in a cloud system) are assumed to have Mobile IP function. A home agent must also exist as a part of the cloud system to serve home network of the mobile hosts. Each host attaches to any one of the virtual or bridged networks that hypervisors provide. Based on the procedure of the Mobile IPv6, the host configures its care-of address using some kinds of address configuration mechanisms provided at the attached network, and register it with its home address to the home agent. The detailed Mobile IPv6 operation procedure and configuration procedures is not described here. When a host is migrated from one hypervisor to another hypervisor, the network to which the migrated host attached changes, if the hypervisors are not attached to the same network segment. The migrated host detects the new network environment using the Mobile IPv6 function, and acquire a new care-of address of the network under the new hypervisor. Similar to Mobile IPv6, the system may need to deploy some mechanisms to add high availability function to the home agent, since it is a single point of failure of Mobile IPv6-based mechanism. The mechanism for high availability of home agents is out of scope of this document. Shima & Sekiya Expires September 12, 2011 [Page 5] Internet-Draft Network Portability March 2011 4.3. NEMO-based Network Porability Another way to provide network portability is to use network mobility technology such as NEMO BS [RFC3963]. In this model, the cloud operator puts several mobile routers (MRs) in the cloud and assigns mobile network prefixes (MNPs) to each of the MR. The MRs are basically hidden to the users of the cloud system. Users do not need to know what is happning when the network migration occurs. The MRs are prepared as virtual machines in the cloud system as same as other normal host machines. Since the MNP bound to each MR moves with the MR, all the hosts attached to the MNP must also move with the MR. Below is an example operation of the migration procedure performed in this case. The cloud system first prepares a home network prefix used as a base network of all the MRs in the cloud system, and prepares a home agent (HA) to serve the network mobility function. Each MR has two network interfaces; one is for the local attachment point to get a care-of address, the other is for the presistent network to host other virtual machines which move with the MR. As many virtual machies as possible can be put on the persistent network of the MR, however, when network migration is performed, all the machines inside the persistent network must be moved altogether. So, if we want to move a virtual machine one by one, we must put only one virtual machine in the persistent segment. It depends on the configuration of the service system. For example, if we design a kind of web service system that consists of a web server and a backend database server, then we may put these two into the one persistent network. Because those two servers must be on the same segment anyway, simultaneous migration will not be a limitation in this scenario. The persistent networks that are bound to MNPs are virtual networks defined in hypervisors. The requirement to the virtual network is that the network must be identified by a virtual machine with a static identifier (e.g. the name of the virtual network) independent of the hypervisors on which the virtual machine runs. For example, if a virtual machine attaches to a virtual network whose name is 'mobile-net-1' on hypervisor A and migrates to hypervisor B, then the hypervisor B must be able to provide a virtual network which is identified by the name 'mobile-net-1'. Whem a network is migrated, all the related virtual machines must be moved to the same destination hypervisor. That includes a MR, all the hosts attached to the MNP of the MR. Once a MR migrates to other hypervisor, it will detect the external interface status and find Shima & Sekiya Expires September 12, 2011 [Page 6] Internet-Draft Network Portability March 2011 that the network is changed. The MR then initiates the procedure of NEMO BS, acquires a new care-of address, and registers its new location to the HA. For the hosts inside the MNP, no additional action is required, since the network environment of the MNP is maintained by the MR and no change happens to that network. Similar to Mobile IPv6, the system may need to deploy some mechanisms to add high availability function to the home agent, since it is a single point of failure of Mobile IPv6-based mechanism. The mechanism for high availability of home agents is out of scope of this document. 4.4. Routing based network portability Using host route entry is another way to implement host-based network portability. In order to use this mothod, every host which is moving between different networks must run routing daemon program on it. The node advertises its host route entry to the upstream router of the attached segment periodically. As you can see, this method needs access right to the routing repository of the attached cloud system. Also, distributing host route entry is impossible from different AS domain. So this method is usually limited to one administrative domain. 5. Acknowledgements We thank the members of the WIDE project for discussion on this network migration technologies, and their bravery to use the experimental cloud system we constructed. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations The management NEMO HA shuld be secure and the tunnels between NEMO nodes should use secure transportation, such as SSL or IPsec. 8. Normative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Shima & Sekiya Expires September 12, 2011 [Page 7] Internet-Draft Network Portability March 2011 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. Authors' Addresses Keiichi Shima IIJ Innovation Institute Inc. 1-105 Kanda-Jinbocho Chiyoda-ku, Tokyo 101-0051 Japan Email: keiichi@iijlab.net Yuji Sekiya The University of Tokyo 2-11-16 Yayoi Bunkyo-ku, Tokyo 113-8658 Japan Email: sekiya@wide.ad.jp Shima & Sekiya Expires September 12, 2011 [Page 8]