One document matched: draft-lee-alto-ext-dc-resource-02.txt
Differences from draft-lee-alto-ext-dc-resource-01.txt
Network Working Group Young Lee
Internet Draft Huawei
Intended status: standard Greg Bernstein
Grotto Networking
Sreekanthm
Huawei
Dhruv Dhody
Huawei
Taesang Choi
ETRI
July 8, 2013
ALTO Extensions for Collecting Data Center Resource Information
draft-lee-alto-ext-dc-resource-02.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 July 8, 2011.
Copyright Notice
Bernstein & Lee, et al. Expires January 8, 2014 [Page 1]
Internet-Draft Data Center Resource Information July 2013
Copyright (c) 2013 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.
Table of Contents
1. Introduction..................................................3
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 (Srikant, please review this section
thoroughly).......................................................7
4.1. Pull Based Query/Response.................................7
4.2. Push Based Query/Response.................................8
5. Security Considerations........................................9
6. IANA Considerations............................................9
7. References.....................................................9
7.1. Informative References....................................9
Author's Addresses...............................................10
Intellectual Property Statement..................................10
Disclaimer of Validity...........................................11
Lee & Bernstein Expires January 8, 2014 [Page 2]
Internet-Draft Data Center Resource Information July 2013
1. Introduction
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 (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.
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
Lee & Bernstein Expires January 8, 2014 [Page 3]
Internet-Draft Data Center Resource Information July 2013
Figure 1 shows that ALTO Client can establish an ALTO-interface to
each data center to collect the abstracted 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.
Lee & Bernstein Expires January 8, 2014 [Page 4]
Internet-Draft Data Center Resource Information July 2013
[TO DO: give examples of some instance types from Amazon or
OpenStack.]
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 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.
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
request, the application orchestrator can make decisions whether it
Lee & Bernstein Expires January 8, 2014 [Page 5]
Internet-Draft Data Center Resource Information July 2013
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.
[To do: 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. Note
also that how to represent physical resources information to
abstract information is out of the scope of this document and is
subject to further research.
Lee & Bernstein Expires January 8, 2014 [Page 6]
Internet-Draft Data Center Resource Information July 2013
4. ALTO Protocol Extension (Srikant, please review this section
thoroughly)
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",
Lee & Bernstein Expires January 8, 2014 [Page 7]
Internet-Draft Data Center Resource Information July 2013
srvload: 25,
ramusage: 60
}
}
4.2. Push Based Query/Response
Push based Query:
object
{
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" : {
Lee & Bernstein Expires January 8, 2014 [Page 8]
Internet-Draft Data Center Resource Information July 2013
"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, 2014 [Page 9]
Internet-Draft Data Center Resource Information July 2013
Author's Addresses
Greg M. Bernstein
Grotto Networking
Fremont California, USA
Phone: (510) 573-2237
Email: gregb@grotto-networking.com
Young Lee
Huawei Technologies
5360 Legacy Drive, Building 3
Plano, TX 75024 USA
Email: leeyoung@huawei.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
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
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
Lee & Bernstein Expires January 8, 2014 [Page 10]
Internet-Draft Data Center Resource Information July 2013
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, 2014 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 01:55:59 |