[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
sdnp discussion group                                         D. McDysan
Internet Draft                                                   Verizon
Intended Status: Informational
Expires: April 21, 2012

                                                        October 24, 2011

                           Cloud Bursting Use Case

               draft-mcdysan-sdnp-cloudbursting-usecase-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups.  Note that other groups
   may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 17, 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 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.












McDysan                 Expires April 24, 2012                 [Page 1]


   Abstract

   This draft describes a use case for the overall coordination, control
   and management of "cloud bursting" in a hybrid cloud computing
   environment involving a private data center and a public or virtual
   private multi-tenant data center.  This use case may be relevant to the
   Software Driven Network Protocol [SDN_UC], VPN for Data Center [VPN4DC],
   or Cross Stratum Optimization [CSO] discussions in the IETF.

Table of Contents


   1. Introduction...................................................2
   2. Conventions used in this document..............................2
      2.1. Acronyms..................................................2
      2.2. Terminology...............................................3
   3. Motivation and Background......................................3
   4. Proposed Use Case..............................................3
      4.1. General Dynamic Cloud Computing Functionality.............3
      4.2. Private Data Center Use Case Elements.....................5
      4.3. Public of Virtual Private Data Center Elements............6
   5. Security Considerations........................................7
   6. IANA Considerations............................................7
   7. References.....................................................7
      7.1. Normative References......................................7
      7.2. Informative References....................................7
   8. Acknowledgments................................................8

1. Introduction

   This draft describes the cloud bursting use case for implementing
   dynamic cloud computing in a multi-tenant environment that addresses the
   case where computing, storage, application, security, networking
   resources are dynamically assigned.

   Section 3 provides some motivation and background for the cloud bursting
   use case. Section 4 provides more details on the cloud bursting use
   case.

   The draft cites a number of references that provide further detail on
   specific aspects of the use case and/or requirements.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

2.1.  Acronyms

   SDNP     Software Driven Network Protocol

   VPN4DC      VPN for Data Center

   CSO         Cross Stratum Optimization


McDysan                 Expires April 24, 2012                 [Page 2]


2.2. Terminology

   Private Cloud - operated by an enterprise

   Public Cloud - multitenant data center operated by a service provider
   accessed via the "Public" Internet

   Virtual Private Cloud - multitenant data center operated by a service
   provider accessed via a L2 and/or L3 Virtual Private Network (VPN)

   Hybrid Cloud - Dynamically instantiated instance of a public or virtual
   private cloud to (temporarily) augment capacity of a private cloud

3. Motivation and Background

   Currently, mostly static L1/L2/L3 networks interconnect customer
   applications in Private Enterprise data centers. Note that an Enterprise
   application network may also contain sites that support sensor data
   collection and other forms of input or output. In order to provide
   capacity in support of dynamic application demand from Enterprises,
   cloud service providers are deploying virtualized resources (e.g.,
   processing, storage, apps/OS) in Cloud Computing Centers.

   Some dynamic bandwidth on demand being done in access networks, but this
   is often not automatically coordinated with networking in a cloud data
   center. Furthermore, assignment, reservation and configuration of other
   resources needed by the application, such as computing, storage, access
   to databases, or specific software instances is not well coordinated
   with the assignment of network capacity. An opportunity exists to
   standardize methods to optimize the assignment of L1, L2, L3 network
   capacity, Cloud Computing site selection and/or resource allocation more
   dynamically.

   Such an optimization may be done proactively on a reservation basis,
   reactively in response to ad hoc requests, reactively in response to
   detected changes in load using pre-defined policies, or reactively by
   the provider in response to an aggregate of a number of smaller requests
   and/or reservations in order to make the system more efficient, and/or
   prepare for honoring a future reservation.

4. Proposed Use Case

   This draft describes a use case for the overall coordination, control
   and management of "cloud bursting" in a hybrid cloud computing
   environment involving a private data center and a public or virtual
   private multi-tenant data center. This use case describes more details
   for a similar use case described in section 6.2 of [SDN_UC], section 3
   of [CSO] or [VPN4DC].

4.1. General Dynamic Cloud Computing Functionality

   A cloud computing instance requires control and management at least the
   following. Further details on use cases and requirements are listed as
   references for many of the items below.



McDysan                 Expires April 24, 2012                 [Page 3]


   o  .Layer 2/Layer 3 bandwidth configuration and monitoring (scheduler
      weight setting, policer setting, reserving bandwidth (e.g., MS-PW),
      counter collection)

   o  .VPN membership (e.g., VLAN, PBB, L2VPN/L3VPN), reachability and any
      restrictions on communication within the VPN [VPN4DC], [VROM]

   o  .Compute resource allocation: virtual machines, virtual memory, OS,
      software assignment and activation on a physical computer [VROM]

   o  .Storage resources: Partition(s) (e.g., Logical Unit Name (LUN))
      assigned to physical storage [VROM]

   There may also be a need to configure the following to align with the
   above

   o  Firewall rules (e.g., ACLs) and other settings [FWLBDC]

   o  Load balancers and settings [FWLBDC]

   o  Security functions (encryption) [VDC_SEC], [DVNSEC]

   o  Network Address Translation (NAT) settings [DVN_SEC]

   o  Dynamic IP and/or L2 address mobility support

   Furthermore, the request may also have performance related parameters,
   such as [CSO]

   o  Packet transfer performance between sites (e.g., latency, delay
      variation, loss)

   o  Availability and failure recovery time objectives for classes of
      resources (e.g., percentage up time and time to recover from an
      interface failure)

   o  Diversity or fate sharing avoidance constraints (e.g., sets of cloud
      resources are placed in sites that do not share fate for failure
      events)

   A Private Cloud Enterprise customer desires a single unified method to
   invoke all of the above aspects of a hybrid cloud service in a
   transaction such that either all aspects are instantiated, or if any
   aspect cannot be instantiated then the overall transaction will either
   fail or result in the next step in a capability/performance negotiation.
   Previously, this unified methods has been called a "Northbound API," and
   more recently an "Application-to-Orchestrator protocol" [SDN_PS]. In
   some cases, a negotiation could occur where the SDN system responds with
   a capability and/or performance indication that is "closest" to what was
   requested as a next step in a negotiation process. The Enterprise
   customer could then have the option to accept this offer, or make
   another request with changed parameters.

   A higher-level system could use interfaces (many of them already
   standardized by the IETF or other SDOs) to implement the above


McDysan                 Expires April 24, 2012                 [Page 4]


   control/management interfaces to accomplish this objective as
   illustrated in Figure 1. The SDN controller could be viewed as
   implementing a set of "plug-ins" [SDN_PS] for controlling the
   management, control and/or data plane of the various devices listed
   above (a subset being illustrated in Figure 1).

   Alternatively, signaling between some of these elements for implementing
   some functions and state/configuration communication could be employed,
   for example, as described in [VPN4DC].

   Furthermore, not all of these interfaces need be standardized in all
   cases. For example, the private cloud site(s) could have its own
   controller and the cloud provider another controller. The required
   interaction is then between these data center controllers and the
   interfaces within the private cloud need not be standardized.

   +------------+
   |Enterprise  |-----------------+
   |Controller  |                 |         "Northbound API" or
   +------------+                 +  <--"Application-to-Orchestrator
   Protocol"
                                  |
                                  |
                             +------------+
      +----------------------|            |-----------------------+
      |        +-------------|            |-------------+         |
      |        |       +-----|    SDN     |----+        |         |
      |        |       |     | Controller |    |        |         |
      |        |       |     +------------+    |        |         |
      |        |       |                       |        |         |
      |        |       |         ^^^^^^        |        |         |
      |        |       |        (      )       |        |         |
   +---+   +---+--+   +----+    (        )    +----+  +------+   +---+
   |NAS|---|Server|---|CE  |---(  L2/L3   )---|CE  |--|Server|---|NAS|
   +---+   +------+   +----+    (  VPN   )    +----+  +------+   +---+
                                 (      )
                                  vvvvvv
      Private Data Center                    Virtual Private Data Center

               Figure 1 Hybrid Cloud Bursting Use Case Context

4.2. Private Data Center Use Case Elements

   Private Data Center controller (may be automated, or a combination of
   manual and automatic actions) requests the following.at one or more
   private Cloud sites:

   o  Configure VM assignment/movement within private cloud

   o  Configure storage, LUN assignment/movement within private cloud

   o  Configure private cloud switch/router access to networking (e.g.,
      scheduler weights, policer, enable specific L2/L3 addresses)




McDysan                 Expires April 24, 2012                 [Page 5]


   o  Configuration of any VPN reachability and the requested components
      from the cloud service provider within the private cloud sites

   o  Private cloud Load Balancer, NAT settings

   o  Private cloud Firewall, Security function settings

   o  Configuration needed to meet performance objectives and/or
      constraints in Private Cloud Elements.

   Usually, the Enterprise operator of the private data center would do all
   of the above. However, a service provider could do settings for some
   components. For example, setting the scheduler weights on the
   switch/router that interfaces to the L2/L3 VPN or Internet access could
   be done via the service provider.

4.3. Public of Virtual Private Data Center Elements

   The SDN controller function of Figure 1 accepts a "Northbound API"
   request from an Enterprise controller and performs following actions at
   one or more cloud provider Virtual Private or Public cloud sites.

   o  .Configure VM assignment/movement within the Enterprise and provider
      data center(s). Note that this may require usage of the same or
      compatible hypervisors with appropriate communication and/or
      permissions between the hypervisor controllers.

   o  .Configure storage, LUN assignment/movement within the provider data
      center(s). Note that this may require usage of the same or compatible
      network attached storage systems with appropriate communication
      and/or permissions between the storage controllers.

   o  .Configure bandwidth related characteristics of L2/L3 packet network
      (e.g., bandwidth for an MS-PW, additional (logical) ports, scheduler
      weights, policers, addresses). This includes logical connectivity
      between and enterprise and a provide cloud site as well as between
      enterprise sites, and between provider cloud sites.

   o  .Configure VPN-related characteristics within public or virtual
      private data center (e.g., mapping to L2/L3 VPN service, firewall)

       o This may include further definitions of reachability within the
          L2/L3 VPN or the notion of a Virtual Data Center. See [VPN4DC].

   o  .Configure access to networking (e.g., scheduler weights, policer,
      enable specific L2/L3 addresses) on the Public Virtual Private data
      center switches or routers

   o  Virtual, multi-tenant Private Firewall and security function settings

   o  Virtual, multi-tenant Private Load balancer and NAT settings






McDysan                 Expires April 24, 2012                 [Page 6]


   o  Configuration needed to meet performance objectives and/or
      constraints. In some cases, the service provider may need to propose
      an alternative to progress a negotiation if not all objectives or
      constraints can simultaneously be met. Furthermore, the SDN
      controller must perform composition across all Enterprise private
      cloud sites and candidate public or virtual private cloud sites to
      ensure that the requested performance objectives are delivered.

   Usually, the service provider of the public or virtual private cloud
   data center would do all of the above.

5. Security Considerations

   A number of virtual data center security requirements and gaps are
   described in [VDC_SEC] and [DVN_SEC]. This draft addresses some of these
   requirements as follows.

   Consistent, automatic configuration of VPN membership in the private and
   public/virtual private cloud is necessary to provide isolation between
   customers.

   Consistent, automatic configuration of firewalls in the private and
   public/virtual private cloud is necessary to provide fine-grained access
   control for various virtual data center resources.

   Consistent, automatic configuration of security functions (e.g.,
   encryption, authentication, intrusion detection, etc.) in the private
   and public/virtual private cloud is necessary to provide
   confidentiality, non-repudiation, and authentication for various virtual
   data center resources.

6. IANA Considerations

   None

7. References

7.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References

   [SDN_UC] Ping Pan, Tom Nadeau, "Software-Defined Network (SDN) Problem
   Statement and Use Cases for Data Center Applications," Work in Progress

   [SDN_PS] Tom Nadeau, "Software Driven Networks Problem Statement," Work
   in Progress.

   [VPN4DC] Ning So et al, "Requirements of Layer 3 Virtual Private Network
   for Data Centers," work in progress.

   [CSO] Greg Bernstein, Young Lee, "Cross Stratum Optimization Use-cases,"
   work in progress.


McDysan                 Expires April 24, 2012                 [Page 7]


   [CLO] Young Lee et al, "Problem Statement for Cross-Layer Optimization,"
   work in progress.

   [VROM] V. Grado, T. Tsou, N. So, "Virtual Resource Operations &
   Management in the Data Center," work in progress

   [FWLBDC] Y. Gu, Y.Fan, "Policies and dynamic information migration in
   DCs,"  work in progress

   [VDC_SEC] S. Karavettil et al, "Security Framework for Virtualized Data
   Center Services," work in progress

   [DVN_SEC] M. Ko, E. Wang, "Problem Statement for Setting Up Dynamic
   Virtual Network," work in progress

8. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

   Copyright (c) 2011 IETF Trust and the persons identified as authors of
   the code. All rights reserved.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
   IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
   TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
   PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
   OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
   PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
   PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

   This code was derived from IETF RFC [insert RFC number]. Please
   reproduce this note if possible.

Authors' Addresses

      Dave McDysan
      Verizon
      22001 Loudoun County PKWY
      Ashburn, VA  20147
      Email: dave.mcdysan@verizon.com













McDysan                 Expires April 24, 2012                 [Page 8]