Internet DRAFT - draft-mcdysan-sdnp-cloudbursting-usecase
draft-mcdysan-sdnp-cloudbursting-usecase
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]
