idnits 2.17.1 draft-lee-alto-ext-dc-resource-03.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 286 has weird spacing: '...intAddr addr;...' -- The document date (January 4, 2014) is 3762 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OPTIONAL' is mentioned on line 284, but not defined == Missing Reference: 'TODO' is mentioned on line 306, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Y. Lee 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track G. Bernstein 5 Expires: July 8, 2014 Grotto Networking 6 D. Dhody 7 Huawei Technologies 8 T. Choi 9 ETRI 10 January 4, 2014 12 ALTO Extensions for Collecting Data Center Resource Information 13 draft-lee-alto-ext-dc-resource-03 15 Abstract 17 In a networked application environment where resources (e.g., 18 computing, storage, etc.) are geographically distributed in Data 19 Centers, a key decision is to allocate the application request to an 20 "optimal" Data Center location in which to host the application 21 request. Key constraints in this decision include resource 22 availability, network cost, infrastructure constraints (e.g., power) 23 and others. This draft proposes an ALTO extension to support data 24 center resource information model and its related protocol 25 extensions. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 8, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Data Center Compute Resource Models . . . . . . . . . . . . . 4 64 2.1. Current IaaS User Resource Models . . . . . . . . . . . . 4 65 2.1.1. Cost or Pricing Models . . . . . . . . . . . . . . . 5 66 2.2. Internal Data Center Resource Models . . . . . . . . . . 5 67 3. ALTO-Interface Data Center Resource Information Model . . . . 6 68 4. ALTO Protocol Extension . . . . . . . . . . . . . . . . . . . 6 69 4.1. Pull Based Query/Response . . . . . . . . . . . . . . . . 7 70 4.2. Push Based Query/Response . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 In a networked application environment where resources (e.g., 80 computing, storage, etc.) are geographically distributed in Data 81 Centers, a key decision is to allocate the application request to an 82 "optimal" Data Center location in which to host the application 83 request. Key constraints in this decision include resource 84 availability (e.g., memory, storage, CPU, etc.), DC network cost, DC 85 network resource constraints (e.g., bandwidth), structure constraints 86 (e.g., Data Center power consumption) and others. 88 This draft describes data center resource information model in the 89 context of i2aex (infrastructure to application exchange) and 90 proposes its related ALTO protocol extensions. 92 The following figure depicts the key components in a networked 93 application environment where Data Centers provide resources for an 94 application. 96 +--------------+ 97 Resource Request | Application | 98 -----------> | Orchestrator | 99 +-------+------+ 100 | 101 +--------+ +----+----+ +--------+ 102 | | | | | | 103 | DC 1 |<--------+------->| ALTO |<-------+------->| DC 2 | 104 | | ALTO-interface | Client | ALTO-interface | | 105 +--------+ +---------+ +--------+ 106 /|\ 107 | 108 + ALTO-interface 109 | 110 \|/ 111 +---------+ 112 | | 113 | DC 3 | 114 | | 115 +---------+ 117 Figure 1: ALTO Architecture in Distributed Data Center Networks 119 Figure 1 shows that ALTO Client can establish an ALTO-interface to 120 each data center to collect the abstracted data center resource 121 information and then select an "optimal" data center location based 122 on the collected resource information for the resource request. 124 Resource request arrives to the "application orchestrator" which is a 125 separate functional entity from the ALTO Client. The collected Data 126 Center resource information by the ALTO Client needs to be sent to 127 the "application orchestrator" where the optimal data center 128 selection is made. How the application orchestrator interfaces with 129 the ALTO Client is out of the scope of this document. Also note that 130 the "application orchestrator" and the ALTO client maybe co-located. 132 The potential information to be shared concerning capacity, 133 performance, structure, and/or network costs associated with a data 134 center may be considered sensitive to the data center owner/operator. 135 It is assumed that ALTO client interfaces with data centers in a 136 trusted relationship. 138 Combined compute and network resource optimization is of value to 139 both application owners and data center operators. For example a 140 data center operator with multiple buildings in a metropolitan area 141 may also want to balance compute and network costs. When looking to 142 model compute resources we consider both application owner and data 143 center owner perspectives. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 2. Data Center Compute Resource Models 153 2.1. Current IaaS User Resource Models 155 In a typical infrastructure as a service (IaaS) data center model, 156 application software runs within one or more virtual machines (VMs). 157 These VMs are allocated to physical hardware by IaaS scheduling 158 software where they are run under the supervision of a virtualization 159 hypervisor. 161 To achieve a given level of performance a particular VM within an 162 application needs a specified amount of compute resources. The raw 163 compute resources are (fast dynamic) memory, virtual CPUs (VCPUs), 164 and dedicated local disk storage. One can think of a virtual CPU as 165 an execution thread on a processor core, however, the notion maybe 166 hypervisor specific. [Editor's note: we have currently only looked 167 at details on the Xen hypervisor.] 169 Currently IaaS data center operators offer a fixed number of 170 combinations of resources (memory, VCPUs, local disk) on which an 171 application may run a VM. These are referred to as instance types. 173 [TO DO: give examples of some instance types from Amazon or 174 OpenStack.] 176 A scalable application is typically implemented so that it can run on 177 a number of VMs with the number varying depending on load or other 178 conditions. Different VMs may assume different roles in the 179 application, e.g., a controller/dispatcher, request processor, data 180 base engine, etc... These different roles may dictate the use of 181 different instance types for the different VMs. 183 We are led to a model where an application will utilized a variable 184 number of VMs over time. These VMs may play different roles within 185 the application and hence require different combinations of 186 processing resources. 188 The data center can furnish a limited number of instance types 189 (combination of resources) for an application to use. In addition 190 there is a finite amount of resources that the data center may have 191 to offer a particular a particular application. 193 Currently two different approaches appear to be used by IaaS 194 providers: (a) Provide no information about available compute 195 capacity and respond positively or negatively to requests for 196 resources, i.e., a specified number of VM instances of a given type. 197 (b) Provide overall quotas (limits) on memory, number of VCPUs, and 198 local storage [OpenStackQuotas]. 200 In this document, we consider the latter model. In such case, ALTO 201 client will collect the overall data center resource information: 202 memory, numbers of VCPUs, local storage, etc. This point will be 203 elaborated in details in Section 2.2. 205 2.1.1. Cost or Pricing Models 207 IaaS service providers have introduced a number of pricing models. 208 One provider [EC2Price] currently offers three different models based 209 on the notions of (a) reserved instances, (b) on demand instances, 210 and (c) spot instances. 212 For the more complicated models http based interfaces are given to 213 facilitate queries and purchases. [TBD: Are there generic or 214 parameterized pricing models that could represent a significant 215 fraction of important cases?] 217 The pricing models discussed in this section are envisioned to be 218 implemented by application orchestrator shown in Figure 1. As the 219 user interacts with the application orchestrator and sends its 220 request, the application orchestrator can make decisions whether it 221 should honor the request or not based on the collected information 222 via the ALTO client interface. The information collection to the 223 ALTO client from various data centers is the critical piece that 224 facilitates this process of selecting the optimal data center. 226 2.2. Internal Data Center Resource Models 228 When previously discussing data center resources from an application 229 perspective, the IaaS provider abstracts away the specifics of the 230 hardware to a large degree. However when an IaaS provider is seeking 231 to minimize its costs to provide services then the particulars of 232 hardware resources are important: in particular, the cost of power at 233 one site versus another site, the efficiency of physical hosts in 234 delivering a given number of VCPUs and/or memory. Such information 235 along with actual hardware capacity and usage can be used to weigh 236 data center resource costs relative to bandwidth costs. 238 [To do: compare Amazon's ECU (elastic compute unit) with VCPU notion 239 or other hypervisor computation unit notions.] 241 3. ALTO-Interface Data Center Resource Information Model 243 ALTO Client collects a set of the abstracted resource information 244 from each participating Data Centers. The following information is 245 the list of Data Center resource abstract information that will give 246 the ALTO Client a good level of abstracted view of the status of each 247 participating Data Center. 249 This collected information will be used for the ALTO Client to find 250 the data center where the requested resource can be provided (via an 251 interface with the application orchestrator). 253 o Data Center Identifier (DCI) 255 o Data Center Location Identifier (e.g., IP address of the gateway 256 node) 258 o Time Stamp 260 o Abstracted Memory Usage 262 o Abstracted CPU Level 264 o Abstracted Power Consumption Level 266 o DC Network cost 268 o DC Network resource constraints 270 The list above is not an exhaustive list and can be expanded. Note 271 also that how to represent physical resources information to abstract 272 information is out of the scope of this document and is subject to 273 further research. 275 4. ALTO Protocol Extension 276 Information Model: 277 object 278 { 279 DCInfo dc-info; 280 } InfoDCResource : ResponseEntityBase; 282 object 283 { 284 VersionTag vtag; [OPTIONAL] 285 JSONNumber dcid; 286 TypedEndpointAddr addr; 287 JSONString timestamp; 288 JSONNumber ramusage; 289 JSONNumber srvload; 290 JSONNumber powerusage; 291 JSONNumber cost; 292 ... 293 } DCInfo; 295 4.1. Pull Based Query/Response 297 In this case, the ALTO client should make HTTP request for DC Info to 298 the ALTO server. The ALTO server will respond only when the request 299 is made by the ALTO client. 301 GET /getdcinfo HTTP/1.1 302 Host: alto.example.com 303 Accept: application/alto-dcinfo+json,application/alto-error+json 305 HTTP/1.1 200 OK 306 Content-Length: [TODO] 307 Content-Type: application/alto-dcinfo+json 308 { 309 "meta" : {}, 310 "dc-info" : { 311 "vtag" : ["1266506139"], 312 "dcid" : 1, 313 "addr" : ["ipv4: 10.18.51.151"], 314 "timestamp" : "02 January 2014 0000H UTC", 315 "ramusage" : 60, 316 "srvload" : 25, 317 "cost" : 10 318 . 319 . 320 . 321 } 322 } 324 4.2. Push Based Query/Response 326 In this case, the ALTO client should make an initial HTTP request for 327 DC Info to the ALTO server. Further the ALTO server can continue to 328 refresh the information to ALTO client. 330 Initial Request and Response is similar to Section 4.1. 332 Further the ALTO server MAY refresh by sending Response on its own, 333 based on future ALTO server notification/refresh mechanisms. 335 [Editor's Note: should be aligned to the ALTO server notification/ 336 refresh mechanisms] 338 5. Security Considerations 340 TBD. 342 6. IANA Considerations 344 TBD 346 7. References 348 7.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 7.2. Informative References 355 [OpenStackQuotas] 356 "OpenStack Quotas", . 359 [EC2Price] 360 "Amazon EC2 Pricing", 361 . 363 Authors' Addresses 365 Young Lee 366 Huawei Technologies 367 1700 Alma Drive, Suite 500 368 Plano, TX 75075 369 USA 371 EMail: leeyoung@huawei.com 373 Greg M. Bernstein 374 Grotto Networking 375 Fremont, California 376 USA 378 EMail: gregb@grotto-networking.com 380 Dhruv Dhody 381 Huawei Technologies 382 Leela Palace 383 Bangalore, Karnataka 560008 384 INDIA 386 EMail: dhruv.ietf@gmail.com 387 Tae-Sang Choi 388 ETRI 389 161 Gajong-Dong 390 Yusong-Gu Daejon 391 Republic of Korea 393 EMail: choits@etri.re.kr