Network Working Group Young Lee Internet Draft Huawei Intended status: standard Greg Bernstein Grotto Networking Sreekanth Madhavan Huawei Dhruv Dhody Huawei Taesang Choi ETRI July 8, 2012 ALTO Extensions for Collecting Data Center Resource Information draft-lee-alto-ext-dc-resource-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 January 8, 2011. Copyright Notice Bernstein & Lee, et al. Expires January 8, 2013 [Page 1] Internet-Draft Data Center Resource Information July 2012 Copyright (c) 2012 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. Abstract In a networked application environment where resources (e.g., computing, storage, etc.) are geographically distributed in Data Centers, a key decision is to allocate the application request to an "optimal" Data Center location in which to host the application request. Key constraints in this decision include resource availability, network cost, infrastructure constraints (e.g., power) and others. This draft proposes an ALTO extension to support data center resource information model and its related protocol extensions as part of the infrastructure to application information exposure (i2aex) initiative. Table of Contents 1. Introduction ....................................... 2 2. Data Center Compute Resource Models ..................... 4 2.1. Current IaaS User Resource Models .................. 4 2.1.1. Cost or Pricing Models ....................... 5 2.2. Internal Data Center Resource Models ................ 6 3. ALTO-Interface Data Center Resource Information Model....... 6 4. ALTO Protocol Extension .............................. 7 4.1. Pull Based Query/Response ......................... 7 4.2. Push Based Query/Response ......................... 7 5. Security Considerations .............................. 8 6. IANA Considerations ................................. 8 7. References ........................................ 8 7.1. Informative References ........................... 8 Author's Addresses .................................... 9 Intellectual Property Statement .......................... 9 Disclaimer of Validity ................................ 10 1. Introduction In a networked application environment where resources (e.g., computing, storage, etc.) are geographically distributed in Data Lee & Bernstein Expires January 8, 2013 [Page 2] Internet-Draft Data Center Resource Information July 2012 Centers, a key decision is to allocate the application request to an "optimal" Data Center location in which to host the application request. Key constraints in this decision include resource availability (e.g., memory, storage, CPU, etc.), DC network cost, DC network resource constraints (e.g., bandwidth), structure constraints (e.g., Data Center power consumption) and others. This draft describes data center resource information model in the context of i2aex (infrastructure to application exchange) and proposes its related ALTO protocol extensions as part of the infrastructure to application information exposure (i2aex) initiative. The following figure depicts the key components in a networked application environment where Data Centers provide resources for an application. +--------------+ Resource Request | Application | -----------> | Orchestrator | +-------+------+ | +--------+ +----+----+ +--------+ | | | | | | | DC 1 |<--------+------->| ALTO |<-------+------->| DC 2 | | | ALTO-interface | Client | ALTO-interface | | +--------+ +---------+ +--------+ /|\ | + ALTO-interface | \|/ +---------+ | | | DC 3 | | | +---------+ Figure 1 ALTO Architecture in Distributed Data Center Networks Figure 1 shows that ALTO Client can establish an ALTO-interface to each data center (running ALTO server) to collect the abstracted Lee & Bernstein Expires January 8, 2013 [Page 3] Internet-Draft Data Center Resource Information July 2012 data center resource information and then select an "optimal" data center location based on the collected resource information for the resource request. Resource request arrives to the "application orchestrator" which is a separate functional entity from the ALTO Client. The collected Data Center resource information by the ALTO Client needs to be sent to the "application orchestrator" where the optimal data center selection is made. How the application orchestrator interfaces with the ALTO Client is out of the scope of this document. The potential information to be shared concerning capacity, performance, structure, and/or network costs associated with a data center may be considered sensitive to the data center owner/operator. It is assumed that ALTO client interfaces with data centers in a trusted relationship. Combined compute and network resource optimization is of value to both application owners and data center operators. For example a data center operator with multiple buildings in a metropolitan area may also want to balance compute and network costs. When looking to model compute resources we consider both application owner and data center owner perspectives. 2. Data Center Compute Resource Models 2.1. Current IaaS User Resource Models In a typical infrastructure as a service (IaaS) data center model, application software runs within one or more virtual machines (VMs). These VMs are allocated to physical hardware by IaaS scheduling software where they are run under the supervision of a virtualization hypervisor. To achieve a given level of performance a particular VM within an application needs a specified amount of compute resources. The raw compute resources are (fast dynamic) memory, virtual CPUs (VCPUs), and dedicated local disk storage. One can think of a virtual CPU as an execution thread on a processor core, however, the notion maybe hypervisor specific. [Editor's note: we have currently only looked at details on the Xen hypervisor.] Currently IaaS data center operators offer a fixed number of combinations of resources (memory, VCPUs, local disk) on which an application may run a VM. These are referred to as instance types. [TBD: give examples of some instance types from Amazon or OpenStack.] Lee & Bernstein Expires January 8, 2013 [Page 4] Internet-Draft Data Center Resource Information July 2012 A scalable application is typically implemented so that it can run on a number of VMs with the number varying depending on load or other conditions. Different VMs may assume different roles in the application, e.g., a controller/dispatcher, request processor, data base engine, etc... These different roles may dictate the use of different instance types for the different VMs. We are led to a model where an application will utilized a variable number of VMs over time. These VMs may play different roles within the application and hence require different combinations of processing resources. The data center can furnish a limited number of instance types (combination of resources) for an application to use. In addition there is a finite amount of resources that the data center may have to offer a particular application. Currently two different approaches appear to be used by IaaS providers: (a) Provide no information about available compute capacity and respond positively or negatively to requests for resources, i.e., a specified number of VM instances of a given type. (b) Provide overall quotas (limits) on memory, number of VCPUs, and local storage [OpenStackQuotas]. In this document, we consider the latter model. In such case, ALTO client will collect the overall data center resource information: memory, numbers of VCPUs, local storage, etc. This point will be elaborated in details in Section 2.2. This model allows application orchestrator to make better decision in optimizing geographically dispersed data center resources. 2.1.1. Cost or Pricing Models IaaS service providers have introduced a number of pricing models. One provider [EC2Price] currently offers three different models based on the notions of (a) reserved instances, (b) on demand instances, and (c) spot instances. For the more complicated models http based interfaces are given to facilitate queries and purchases. [TBD: Are there generic or parameterized pricing models that could represent a significant fraction of important cases?] The pricing models discussed in this section are envisioned to be implemented by application orchestrator shown in Figure 1. As the user interacts with the application orchestrator and sends its Lee & Bernstein Expires January 8, 2013 [Page 5] Internet-Draft Data Center Resource Information July 2012 request, the application orchestrator can make decisions whether it should honor the request or not based on the collected information via the ALTO client interface. The information collection to the ALTO client from various data centers is the critical piece that facilitates this process of selecting the optimal data center. 2.2. Internal Data Center Resource Models When previously discussing data center resources from an application perspective, the IaaS provider abstracts away the specifics of the hardware to a large degree. However when an IaaS provider is seeking to minimize its costs to provide services then the particulars of hardware resources are important: in particular, the cost of power at one site versus another site, the efficiency of physical hosts in delivering a given number of VCPUs and/or memory. Such information along with actual hardware capacity and usage can be used to weigh data center resource costs relative to bandwidth costs. [TBD: compare Amazon's ECU (elastic compute unit) with VCPU notion or other hypervisor computation unit notions.] 3. ALTO-Interface Data Center Resource Information Model ALTO Client collects a set of the abstracted resource information from each participating Data Centers. The following information is the list of Data Center resource abstract information that will give the ALTO Client a good level of abstracted view of the status of each participating Data Center. This collected information will be used for the ALTO Client to find the data center where the requested resource can be provided (via an interface with the application orchestrator). . Data Center Identifier (DCI) . Data Center Location Identifier (e.g., IP address of the gateway node) . Time Stamp . Abstracted Memory Usage . Abstracted CPU Level . Abstracted Power Consumption Level . DC Network Cost . DC Network Resource Constraints The list above is not an exhaustive list and can be expanded. How to represent DC Network Cost and DC Network Resource Constraints is yet to be determined. Note also that how to represent physical resources Lee & Bernstein Expires January 8, 2013 [Page 6] Internet-Draft Data Center Resource Information July 2012 information to abstract information is out of the scope of this document and is subject to further research. 4. ALTO Protocol Extension 4.1. Pull Based Query/Response Pull based Query: Based on GET URL /getdcinfo Pull based response: object { VersionTag vtag; [OPTIONAL] TypedEndpointAddrall addr; JSONNumber srvload; JSONNUmber ramusage; ... } InfoDCProperty; GET /dcinfo HTTP/1.1 Host: alto.example.com Accept: application/alto-dcinfo+json HTTP/1.1 200 OK Content-Length: [TODO] Content-Type: application/alto-dcinfo+json { "meta" : {}, "data" : { "vtag" : "1266506139",, addr : "ipv4: 10.18.51.151:5060", srvload: 25, ramusage: 60 } } 4.2. Push Based Query/Response Push based Query: object { Lee & Bernstein Expires January 8, 2013 [Page 7] Internet-Draft Data Center Resource Information July 2012 VersionTag vtag; [OPTIONAL] TypedEndpointAddrall addr; JSONNumber srvload; JSONNUmber ramusage; ... } InfoDCProperty; Push based response: 200 OK with body NUl POST /dcinfo HTTP/1.1 Host: alto.example.com Content-Length: [TODO] Content-Type: application/alto-dcinfo+json { "meta" : {}, "data" : { "vtag" : "1266506139", addr : "ipv4: 10.18.51.151:5060", srvload: 25, ramusage: 60 } } HTTP/1.1 200 OK Host: alto.example.com 5. Security Considerations TBD 6. IANA Considerations TBD 7. References 7.1. Informative References Lee & Bernstein Expires January 8, 2013 [Page 8] Internet-Draft Data Center Resource Information July 2012 Author's Addresses Young Lee Huawei Technologies 1700 Alma Drive, Suite 500 Plano, TX 75075 USA Phone: (972) 509-5599 Email: ylee@huawei.com Greg M. Bernstein Grotto Networking Fremont California, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Sreekanth Madhavan Huawei Technologies, India Email: sreekanth.madhavan@huawei.com Dhruv Dhody Huawei Technologies, India Email: dhruv.dhody@huawei.com Tae-Sang Choi ETRI 161 Gajong-Dong, Yusong-Gu Daejon, Republic of Korea Phone: (8242) 860-5628 Email: choits@etri.re.kr Contributor's Addresses Nandiraju Ravi Shankar Huawei Technologies, India Email: nandiraju.shankar@huawei.com Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be Lee & Bernstein Expires January 8, 2013 [Page 9] Internet-Draft Data Center Resource Information July 2012 claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee & Bernstein Expires January 8, 2013 [Page 10]