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]