Skip to main content

ALTO Extensions for Collecting Data Center Resource Information
draft-lee-alto-ext-dc-resource-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Young Lee , Greg M. Bernstein , Dhruv Dhody
Last updated 2013-01-09
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lee-alto-ext-dc-resource-01
Network Working Group                                         Young Lee
Internet Draft                                                   Huawei
Intended status: standard                                Greg Bernstein
                                                      Grotto Networking
                                                             Sreekanthm
                                                                 Huawei
                                                            Dhruv Dhody
                                                                 Huawei
                                                            Taesang Choi
                                                                    ETRI

                                                        January 9, 2013

      ALTO Extensions for Collecting Data Center Resource Information

                   draft-lee-alto-ext-dc-resource-01.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 9, 2011.

Copyright Notice

Bernstein & Lee, et al.  Expires July 9, 2013                  [Page 1]
Internet-Draft     Data Center Resource Information        January 2013

   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.

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 July 9, 2013 [Page 2]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 3]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 4]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 5]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 6]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 7]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 8]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 9]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 10]
Internet-Draft     Data Center Resource Information        January 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 July 9, 2013 [Page 11]