Internet DRAFT - draft-wang-opsawg-policies-migration-gap-analysis
draft-wang-opsawg-policies-migration-gap-analysis
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]