idnits 2.17.1 draft-mcdysan-sdnp-cloudbursting-usecase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 68 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([VPN4DC], [CSO]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DVNSEC' is mentioned on line 178, but not defined == Unused Reference: 'CLO' is defined on line 374, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 sdnp discussion group D. McDysan 2 Internet Draft Verizon 3 Intended Status: Informational 4 Expires: April 21, 2012 6 October 24, 2011 8 Cloud Bursting Use Case 10 draft-mcdysan-sdnp-cloudbursting-usecase-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering Task 18 Force (IETF), its areas, and its working groups. Note that other groups 19 may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on April 17, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the document 37 authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 40 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 41 effect on the date of publication of this document. Please review these 42 documents carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this document 44 must include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 This draft describes a use case for the overall coordination, control 51 and management of "cloud bursting" in a hybrid cloud computing 52 environment involving a private data center and a public or virtual 53 private multi-tenant data center. This use case may be relevant to the 54 Software Driven Network Protocol [SDN_UC], VPN for Data Center [VPN4DC], 55 or Cross Stratum Optimization [CSO] discussions in the IETF. 57 Table of Contents 59 1. Introduction...................................................2 60 2. Conventions used in this document..............................2 61 2.1. Acronyms..................................................2 62 2.2. Terminology...............................................3 63 3. Motivation and Background......................................3 64 4. Proposed Use Case..............................................3 65 4.1. General Dynamic Cloud Computing Functionality.............3 66 4.2. Private Data Center Use Case Elements.....................5 67 4.3. Public of Virtual Private Data Center Elements............6 68 5. Security Considerations........................................7 69 6. IANA Considerations............................................7 70 7. References.....................................................7 71 7.1. Normative References......................................7 72 7.2. Informative References....................................7 73 8. Acknowledgments................................................8 75 1. Introduction 77 This draft describes the cloud bursting use case for implementing 78 dynamic cloud computing in a multi-tenant environment that addresses the 79 case where computing, storage, application, security, networking 80 resources are dynamically assigned. 82 Section 3 provides some motivation and background for the cloud bursting 83 use case. Section 4 provides more details on the cloud bursting use 84 case. 86 The draft cites a number of references that provide further detail on 87 specific aspects of the use case and/or requirements. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC-2119 [RFC2119]. 95 2.1. Acronyms 97 SDNP Software Driven Network Protocol 99 VPN4DC VPN for Data Center 101 CSO Cross Stratum Optimization 103 2.2. Terminology 105 Private Cloud - operated by an enterprise 107 Public Cloud - multitenant data center operated by a service provider 108 accessed via the "Public" Internet 110 Virtual Private Cloud - multitenant data center operated by a service 111 provider accessed via a L2 and/or L3 Virtual Private Network (VPN) 113 Hybrid Cloud - Dynamically instantiated instance of a public or virtual 114 private cloud to (temporarily) augment capacity of a private cloud 116 3. Motivation and Background 118 Currently, mostly static L1/L2/L3 networks interconnect customer 119 applications in Private Enterprise data centers. Note that an Enterprise 120 application network may also contain sites that support sensor data 121 collection and other forms of input or output. In order to provide 122 capacity in support of dynamic application demand from Enterprises, 123 cloud service providers are deploying virtualized resources (e.g., 124 processing, storage, apps/OS) in Cloud Computing Centers. 126 Some dynamic bandwidth on demand being done in access networks, but this 127 is often not automatically coordinated with networking in a cloud data 128 center. Furthermore, assignment, reservation and configuration of other 129 resources needed by the application, such as computing, storage, access 130 to databases, or specific software instances is not well coordinated 131 with the assignment of network capacity. An opportunity exists to 132 standardize methods to optimize the assignment of L1, L2, L3 network 133 capacity, Cloud Computing site selection and/or resource allocation more 134 dynamically. 136 Such an optimization may be done proactively on a reservation basis, 137 reactively in response to ad hoc requests, reactively in response to 138 detected changes in load using pre-defined policies, or reactively by 139 the provider in response to an aggregate of a number of smaller requests 140 and/or reservations in order to make the system more efficient, and/or 141 prepare for honoring a future reservation. 143 4. Proposed Use Case 145 This draft describes a use case for the overall coordination, control 146 and management of "cloud bursting" in a hybrid cloud computing 147 environment involving a private data center and a public or virtual 148 private multi-tenant data center. This use case describes more details 149 for a similar use case described in section 6.2 of [SDN_UC], section 3 150 of [CSO] or [VPN4DC]. 152 4.1. General Dynamic Cloud Computing Functionality 154 A cloud computing instance requires control and management at least the 155 following. Further details on use cases and requirements are listed as 156 references for many of the items below. 158 o .Layer 2/Layer 3 bandwidth configuration and monitoring (scheduler 159 weight setting, policer setting, reserving bandwidth (e.g., MS-PW), 160 counter collection) 162 o .VPN membership (e.g., VLAN, PBB, L2VPN/L3VPN), reachability and any 163 restrictions on communication within the VPN [VPN4DC], [VROM] 165 o .Compute resource allocation: virtual machines, virtual memory, OS, 166 software assignment and activation on a physical computer [VROM] 168 o .Storage resources: Partition(s) (e.g., Logical Unit Name (LUN)) 169 assigned to physical storage [VROM] 171 There may also be a need to configure the following to align with the 172 above 174 o Firewall rules (e.g., ACLs) and other settings [FWLBDC] 176 o Load balancers and settings [FWLBDC] 178 o Security functions (encryption) [VDC_SEC], [DVNSEC] 180 o Network Address Translation (NAT) settings [DVN_SEC] 182 o Dynamic IP and/or L2 address mobility support 184 Furthermore, the request may also have performance related parameters, 185 such as [CSO] 187 o Packet transfer performance between sites (e.g., latency, delay 188 variation, loss) 190 o Availability and failure recovery time objectives for classes of 191 resources (e.g., percentage up time and time to recover from an 192 interface failure) 194 o Diversity or fate sharing avoidance constraints (e.g., sets of cloud 195 resources are placed in sites that do not share fate for failure 196 events) 198 A Private Cloud Enterprise customer desires a single unified method to 199 invoke all of the above aspects of a hybrid cloud service in a 200 transaction such that either all aspects are instantiated, or if any 201 aspect cannot be instantiated then the overall transaction will either 202 fail or result in the next step in a capability/performance negotiation. 203 Previously, this unified methods has been called a "Northbound API," and 204 more recently an "Application-to-Orchestrator protocol" [SDN_PS]. In 205 some cases, a negotiation could occur where the SDN system responds with 206 a capability and/or performance indication that is "closest" to what was 207 requested as a next step in a negotiation process. The Enterprise 208 customer could then have the option to accept this offer, or make 209 another request with changed parameters. 211 A higher-level system could use interfaces (many of them already 212 standardized by the IETF or other SDOs) to implement the above 213 control/management interfaces to accomplish this objective as 214 illustrated in Figure 1. The SDN controller could be viewed as 215 implementing a set of "plug-ins" [SDN_PS] for controlling the 216 management, control and/or data plane of the various devices listed 217 above (a subset being illustrated in Figure 1). 219 Alternatively, signaling between some of these elements for implementing 220 some functions and state/configuration communication could be employed, 221 for example, as described in [VPN4DC]. 223 Furthermore, not all of these interfaces need be standardized in all 224 cases. For example, the private cloud site(s) could have its own 225 controller and the cloud provider another controller. The required 226 interaction is then between these data center controllers and the 227 interfaces within the private cloud need not be standardized. 229 +------------+ 230 |Enterprise |-----------------+ 231 |Controller | | "Northbound API" or 232 +------------+ + <--"Application-to-Orchestrator 233 Protocol" 234 | 235 | 236 +------------+ 237 +----------------------| |-----------------------+ 238 | +-------------| |-------------+ | 239 | | +-----| SDN |----+ | | 240 | | | | Controller | | | | 241 | | | +------------+ | | | 242 | | | | | | 243 | | | ^^^^^^ | | | 244 | | | ( ) | | | 245 +---+ +---+--+ +----+ ( ) +----+ +------+ +---+ 246 |NAS|---|Server|---|CE |---( L2/L3 )---|CE |--|Server|---|NAS| 247 +---+ +------+ +----+ ( VPN ) +----+ +------+ +---+ 248 ( ) 249 vvvvvv 250 Private Data Center Virtual Private Data Center 252 Figure 1 Hybrid Cloud Bursting Use Case Context 254 4.2. Private Data Center Use Case Elements 256 Private Data Center controller (may be automated, or a combination of 257 manual and automatic actions) requests the following.at one or more 258 private Cloud sites: 260 o Configure VM assignment/movement within private cloud 262 o Configure storage, LUN assignment/movement within private cloud 264 o Configure private cloud switch/router access to networking (e.g., 265 scheduler weights, policer, enable specific L2/L3 addresses) 267 o Configuration of any VPN reachability and the requested components 268 from the cloud service provider within the private cloud sites 270 o Private cloud Load Balancer, NAT settings 272 o Private cloud Firewall, Security function settings 274 o Configuration needed to meet performance objectives and/or 275 constraints in Private Cloud Elements. 277 Usually, the Enterprise operator of the private data center would do all 278 of the above. However, a service provider could do settings for some 279 components. For example, setting the scheduler weights on the 280 switch/router that interfaces to the L2/L3 VPN or Internet access could 281 be done via the service provider. 283 4.3. Public of Virtual Private Data Center Elements 285 The SDN controller function of Figure 1 accepts a "Northbound API" 286 request from an Enterprise controller and performs following actions at 287 one or more cloud provider Virtual Private or Public cloud sites. 289 o .Configure VM assignment/movement within the Enterprise and provider 290 data center(s). Note that this may require usage of the same or 291 compatible hypervisors with appropriate communication and/or 292 permissions between the hypervisor controllers. 294 o .Configure storage, LUN assignment/movement within the provider data 295 center(s). Note that this may require usage of the same or compatible 296 network attached storage systems with appropriate communication 297 and/or permissions between the storage controllers. 299 o .Configure bandwidth related characteristics of L2/L3 packet network 300 (e.g., bandwidth for an MS-PW, additional (logical) ports, scheduler 301 weights, policers, addresses). This includes logical connectivity 302 between and enterprise and a provide cloud site as well as between 303 enterprise sites, and between provider cloud sites. 305 o .Configure VPN-related characteristics within public or virtual 306 private data center (e.g., mapping to L2/L3 VPN service, firewall) 308 o This may include further definitions of reachability within the 309 L2/L3 VPN or the notion of a Virtual Data Center. See [VPN4DC]. 311 o .Configure access to networking (e.g., scheduler weights, policer, 312 enable specific L2/L3 addresses) on the Public Virtual Private data 313 center switches or routers 315 o Virtual, multi-tenant Private Firewall and security function settings 317 o Virtual, multi-tenant Private Load balancer and NAT settings 318 o Configuration needed to meet performance objectives and/or 319 constraints. In some cases, the service provider may need to propose 320 an alternative to progress a negotiation if not all objectives or 321 constraints can simultaneously be met. Furthermore, the SDN 322 controller must perform composition across all Enterprise private 323 cloud sites and candidate public or virtual private cloud sites to 324 ensure that the requested performance objectives are delivered. 326 Usually, the service provider of the public or virtual private cloud 327 data center would do all of the above. 329 5. Security Considerations 331 A number of virtual data center security requirements and gaps are 332 described in [VDC_SEC] and [DVN_SEC]. This draft addresses some of these 333 requirements as follows. 335 Consistent, automatic configuration of VPN membership in the private and 336 public/virtual private cloud is necessary to provide isolation between 337 customers. 339 Consistent, automatic configuration of firewalls in the private and 340 public/virtual private cloud is necessary to provide fine-grained access 341 control for various virtual data center resources. 343 Consistent, automatic configuration of security functions (e.g., 344 encryption, authentication, intrusion detection, etc.) in the private 345 and public/virtual private cloud is necessary to provide 346 confidentiality, non-repudiation, and authentication for various virtual 347 data center resources. 349 6. IANA Considerations 351 None 353 7. References 355 7.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 7.2. Informative References 362 [SDN_UC] Ping Pan, Tom Nadeau, "Software-Defined Network (SDN) Problem 363 Statement and Use Cases for Data Center Applications," Work in Progress 365 [SDN_PS] Tom Nadeau, "Software Driven Networks Problem Statement," Work 366 in Progress. 368 [VPN4DC] Ning So et al, "Requirements of Layer 3 Virtual Private Network 369 for Data Centers," work in progress. 371 [CSO] Greg Bernstein, Young Lee, "Cross Stratum Optimization Use-cases," 372 work in progress. 374 [CLO] Young Lee et al, "Problem Statement for Cross-Layer Optimization," 375 work in progress. 377 [VROM] V. Grado, T. Tsou, N. So, "Virtual Resource Operations & 378 Management in the Data Center," work in progress 380 [FWLBDC] Y. Gu, Y.Fan, "Policies and dynamic information migration in 381 DCs," work in progress 383 [VDC_SEC] S. Karavettil et al, "Security Framework for Virtualized Data 384 Center Services," work in progress 386 [DVN_SEC] M. Ko, E. Wang, "Problem Statement for Setting Up Dynamic 387 Virtual Network," work in progress 389 8. Acknowledgments 391 This document was prepared using 2-Word-v2.0.template.dot. 393 Copyright (c) 2011 IETF Trust and the persons identified as authors of 394 the code. All rights reserved. 396 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 397 IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 398 TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 399 PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 400 OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 401 EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 402 PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 403 PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 404 LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 405 NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 406 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 408 This code was derived from IETF RFC [insert RFC number]. Please 409 reproduce this note if possible. 411 Authors' Addresses 413 Dave McDysan 414 Verizon 415 22001 Loudoun County PKWY 416 Ashburn, VA 20147 417 Email: dave.mcdysan@verizon.com