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]