Network Working Group J. Yang Internet-Draft Huawei Intended status: Standards Track C. Li Expires: May 3, 2012 China Telecom D. Wang Huawei October 31, 2011 Survey and Gap Analysis for State Migration in Data Center draft-wang-opsawg-policies-migration-gap-analysis-01 Abstract In this draft, we made gap analysis with some exisitng IETF work that could be related to State Migration. First of all, a short description of general state migration requirements is listed, and then we presents a brief survey of MIDCOM, PCP and Forces. The goal of this draft is to figure out whether there are existing protocols we can reuse. 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 May 3, 2012. 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 carefully, as they describe your rights and restrictions with respect Yang, et al. Expires May 3, 2012 [Page 1] Internet-Draft GapAnalysis October 2011 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. Terminologies and concepts . . . . . . . . . . . . . . . . . . 3 3. General Requirements on State Migration . . . . . . . . . . . . 3 4. Existing Protocol Gap Analysis . . . . . . . . . . . . . . . . 5 4.1. MIDdlebox COMmunication (MIDCOM) . . . . . . . . . . . . . 5 4.2. Port Control Protocol (PCP) . . . . . . . . . . . . . . . . 5 4.3. Forwarding and Control Element Separation (ForCES) . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . . 7 6.2. Informative Reference . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yang, et al. Expires May 3, 2012 [Page 2] Internet-Draft GapAnalysis October 2011 1. Introduction In this draft, we made gap analysis with some exisitng IETF work that could be related to State Migration. For any new proposal to IETF, we should try to find out whether there is exixting mechanism and protocols can be reused to solve the proposed problem. So, in this draft, we analyze some existing IETF work, including Middlebox Communication [MIDCOM], Port Control Protocol[PCP] and Forwarding and Control Element Separation . [ForCES]We are happy to be noticed about and make analysis on other possible IETF work. Before we can figure out whether an existing work in IETF can be reused in StAte MIgration (SAMI), we need to first be aware of the requirements of SAMI. So, before analyzing any existing IETF work, we list some general requirements on SAMI. 2. Terminologies and concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "WOULD", "COULD", "CANNOT", "MIGHT", and "MAY"in this document are to be interpreted as described in [RFC2119]. Source device: the device from where the VM migrates. Destination device: the device to where the VM migrates. Migration pair, device-pair: a network device and its partner which involved in DIM. VM: Virtual Machine; A completely isolated operation system which is installed by software on a normal operation system. A normal operation system can be virtualized into several VM. 3. General Requirements on State Migration 1) VM Migration Awareness: Be there a third party coordinator, the VM or the Firewall itself that is used to assist state migration[SAMI_SOLUTION_SURVEY], the state migration mechanism must be aware of VM Migration, in order to know VM migrates from where to where and when is the best time to migrate state. 2) Authentication: In Cloud Data Center, not only servers but also clients are reside inside. So it's not safe to assume that the request for state migration is from an authorized party, even if the request is from internal netowrk. For security consideration, mutual authentication between network devices must be supported. Yang, et al. Expires May 3, 2012 [Page 3] Internet-Draft GapAnalysis October 2011 3) Capability Negotiation: The protocol must support capability negotiation between network devices before migration starts. The goal of capability negotiation is to make sure the destination devices supports appropriate functions and has enough software resource to support the state which is going to be migrated. For example, a source Firewall has 6 session table items to be migrated, while the destination Firewall has only 4 items available. That implies the state migration could fail. The source device can be aware of the situation by capability negotiation. The manager can make decision on whether to continue VM migration with the awareness of the risk of failure. 4) States Representation: Different Vendors could have different ways to represent states, e.g. the Firewall session table model of vendor A is different from that of vendor B. There are common parameters, e.g. all sesssion tatbles have 5 tuple (Src IP/Port, Dst IP/Port, Protocol type), but the naming and orders of the parameters could also be different. And some vendor could contain some propriatary parameters. In order to enable devices from different vendors can understand and transform the states to the one they support, there should be a standardized way to represent states 5) Communication with Firewall: From the very rough consideration of the solution, there should be either there is a third party coordinator between two Firewalls to transfer states or a protocol to enable Firewalls to communicate with each other. 6) State Elimination: Once state has been migrated successfully to destination device, it must be eliminated from source device in time, otherwise it might be taken advantage by malicious attackers. 7) Atomicity: Since one device might be involved into several migrations simultaneously, migrations with different partners must be isolated to each other. The migration lanched by one device must not be interrupted by migrations launched by other devices, which can ensure atomicity of migration interactions. 8) Span Administration Domains: Since VM can be migrated to any place within Data Center, even to another Data Center that is not in the same administration domain from the original Data Center, the protocol should be able to apply in different scenarios. 9) Extensibility: The protocol should be designed to be extensible to support migration of new state or between new network devices. Yang, et al. Expires May 3, 2012 [Page 4] Internet-Draft GapAnalysis October 2011 4. Existing Protocol Gap Analysis 4.1. MIDdlebox COMmunication (MIDCOM) The principal motivation behind architecting MIDCOM protocol is to enable complex applications pass through middleboxes, using a trusted third party, i.e., a MIDCOM agent. MIDCOM agents with application intelligence can assist the middleboxes in permitting applications. Middleboxes supporting the MIDCOM will be able to externalize application intelligence into MIDCOM agents. The primary task for MIDCOM protocol is to assist agents in configuring policy rules on middleboxes. Mutual authentication between agent and middlebox are provided for session establishment between them. MIDCOM protocol contains several concepts that DIM could refer to. However, there are still several requirements of DIM cannot be satisfied by MIDCOM protocol. The following table lists the gaps in MIDCOM protocol on DIM. +------------------------------+------------------------+ | State Migration Requirements | If Supported by MIDCOM | +------------------------------+------------------------+ | VM Migration Awareness | No | | Mutual authentication | Yes | | Capability Negotiation | No | | State Representation | No | | Communication with Firewall | Yes | | State Elimination | No | | Atomicity | Yes | | Span Administration Domains | No | +------------------------------+------------------------+ Generally speaking, MIDCOM is developed for policies configuration on Middleboxes. It doesn't deal with the state generated on Middleboxes, e.g. on Firewall. It provides a way to communicate with Firewall. But if we want to reuse MIDCOM, we need to develop the features listed above with "NO". 4.2. Port Control Protocol (PCP) Port Control Protocol (PCP) is, to some extent, similar to MIDCOM. PCP is designed to enable host/gateway to establish explicit dialog with middlebox to open up and/or forward TCP or UDP port. Authentication mechanism is out of the scope of PCP, instead some restrictions are listted for implementation and deployment consideration. [PCP_BASE] Yang, et al. Expires May 3, 2012 [Page 5] Internet-Draft GapAnalysis October 2011 +------------------------------+---------------------+ | State Migration Requirements | If Supported by PCP | +------------------------------+---------------------+ | VM Migration Awareness | No | | Mutual authentication | No | | Capability Negotiation | No | | State Representation | No | | Communication with Firewall | Yes | | State Elimination | No | | Atomicity | Yes | | Span Administration Domains | No | +------------------------------+---------------------+ Generally speaking, PCP is developed to enable an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.policies configuration on Middleboxes. It doesn't deal with the migration of state generated on Middleboxes, e.g. on Firewall. It provides a way to communicate with Firewall. But if we want to reuse MIDCOM, we need to develop the features listed above with "NO". 4.3. Forwarding and Control Element Separation (ForCES) Forwarding and Control Element Separation (ForCES) aims to define a framework and associated mechanisms for standardizing the exchange of information between the logically separate functionality of the control plane, including entities such as routing protocols, admission control, and signaling, and the forwarding plane, where per-packet activities such as packet forwarding, queuing, and header editing occur. For current version of ForCES, Control Element (CE) and Forwarding Element (FE) should be no more than one hop away. But ForCES is supposed to support information exchanging between CE and FE that are more than one hop away by making use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. Also, ForCES provides authentication and security mechanism for communication between CE and FE. Flow-coupled state, e.g. session table on Firewall, could be one type of information that is exchanged between CE and PE. In state migration scenario, let's suppose that CE is a third party coordinator and FE is the Firewall with lots of Logical Function Block (LFB). According to , we can get the following gap analysis table. [ForCES_BASE_PROTOCOL] Yang, et al. Expires May 3, 2012 [Page 6] Internet-Draft GapAnalysis October 2011 +------------------------------+------------------------+ | State Migration Requirements | If Supported by ForCES | +------------------------------+------------------------+ | VM Migration Awareness | No | | Mutual authentication | Yes | | Capability Negotiation | Yes | | State Representation | No | | Communication with Firewall | Yes | | State Elimination | Yes | | Atomicity | Yes | | Span Administration Domains | No | +------------------------------+------------------------+ ForCES provides a good base for state migration. But we need to redesign the roles of CE and FE, and need to resolve the 'No' items in the above table. And because ForCES doesn't provide a non-stop tranferring of state, which only has GET and SET without none interruption consideration, we also need to develop a new mechanism to guarantee the state migration only introduce acceptable interruption time to VM live migration. 5. Security Considerations To be added. 6. References 6.1. Normative Reference [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", August 2002. [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", August 2002. [RFC5189] Stiemerling, M., Quittek, J., and J. Quittek, "Middlebox Communication (MIDCOM) Protocol Semantics", March 2008. [RFC5190] Stiemerling, M., Quittek, J., and J. Quittek, "Definitions of Managed Objects for Middlebox Communication", March 2008. [ForCES_BASE_PROTOCOL] Dong, L., Doria, A., Gopal, R., Haas, R., Salim, J., Yang, et al. Expires May 3, 2012 [Page 7] Internet-Draft GapAnalysis October 2011 Khosravi, H., and W. Wang, "ForCES Protocol Specification", March 2009. 6.2. Informative Reference [Data_Center_Fundamentals] "Data Center Fundamentals", 2003. [draft-gu-opsawg-policies-migration] "State Migration", October 2011. [SAMI_SOLUTION_SURVEY] Gu, Y., "draft-gu-opsawg-policies-migraiton-solution-survey". [MIDCOM] "MIDdlebox COMmunication, RFC3303, RFC 3304, RFC5189, RFC5190.". [PCP] "Port Control Protocol , http://tools.ietf.org/wg/pcp/charters". [ForCES] "Forwarding and Control Element Separation, http://tools.ietf.org/wg/forces/". [PCP_BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)". Authors' Addresses Jingtao Yang Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210001 P.R.China Email: yangjingtao@huawei.com Li Chen China Telecom Email: lichenyj@chinamobile.com Yang, et al. Expires May 3, 2012 [Page 8] Internet-Draft GapAnalysis October 2011 Wang Danhua Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210001 P.R.China Email: wangdanhua@huawei.com Yang, et al. Expires May 3, 2012 [Page 9]