From: http://www.ietf.org/internet-drafts/draft-shima-cloud-net-portability-reqs-and-models-00.txt Title: Network Portability Requirements and Models for Cloud Environment Reference: draft-shima-cloud-net-portability-reqs-and-models-00 Date: September 07, 2010 Data Tracker: https://datatracker.ietf.org/doc/draft-shima-cloud-net-portability-reqs-and-models/ Tracker Listing: http://ietfreport.isoc.org/idref/draft-shima-cloud-net-portability-reqs-and-models/ Tools: http://tools.ietf.org/html/draft-shima-cloud-net-portability-reqs-and-models-00 (HTML) Announced: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg32994.html See also: IETF Clouds Discussion Archive: http://www.ietf.org/mail-archive/web/clouds/current/maillist.html IETF Cloud Computing bar BOFs in Anaheim (IETF-77) and Maastricht (IETF-78) http://trac.tools.ietf.org/area/app/trac/wiki/Clouds CloudAudit Discussion List http://groups.google.com/group/cloudaudit/ CloudAudit 1.0: Automated Audit, Assertion, Assessment, and Assurance API (A6) http://xml.coverpages.org/draft-hoff-cloudaudit-00.txt =============================================================================== Internet Engineering Task Force K. Shima Internet-Draft IIJ Innovation Institute Inc. Intended status: Informational Y. Sekiya Expires: March 11, 2011 The University of Tokyo September 7, 2010 Network Portability Requirements and Models for Cloud Environment draft-shima-cloud-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 March 11, 2011. Copyright Notice Copyright (c) 2010 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 March 11, 2011 [Page 1] Internet-Draft Network Portability September 2010 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 . . . . . . . . . . 4 4.2. Mobile IPv6-based Network Porability . . . . . . . . . . . 5 4.3. NEMO-based Network Porability . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Shima & Sekiya Expires March 11, 2011 [Page 2] Internet-Draft Network Portability September 2010 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 clouds are below. o providing 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 and clouds. It is provided using VLAN and VPN technologies, however, building user networks using such technologies is difficult in inter- datacenters or inter-clouds environments. VLAN is layer-2 technology and it requires direct circuit between datacenters, so it is difficult from costly point of view. VPN is cost-effective technology and it makes 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 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. Shima & Sekiya Expires March 11, 2011 [Page 3] Internet-Draft Network Portability September 2010 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 protocol. 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. 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. 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] 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. Shima & Sekiya Expires March 11, 2011 [Page 4] Internet-Draft Network Portability September 2010 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. 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 Shima & Sekiya Expires March 11, 2011 [Page 5] Internet-Draft Network Portability September 2010 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 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 Shima & Sekiya Expires March 11, 2011 [Page 6] Internet-Draft Network Portability September 2010 this document. 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. [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 Kandajinbocho Chiyoda-ku, Tokyo 101-0051 Japan Email: keiichi@iijlab.net Shima & Sekiya Expires March 11, 2011 [Page 7] Internet-Draft Network Portability September 2010 Yuji Sekiya The University of Tokyo 2-11-16 Yayoi Bunkyo-ku, Tokyo 113-8658 Japan Email: sekiya@wide.ad.jp Shima & Sekiya Expires March 11, 2011 [Page 8]