[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

ALTO                                                              Y. Lee
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                            G. Bernstein
Expires: July 8, 2014                                  Grotto Networking
                                                                D. Dhody
                                                     Huawei Technologies
                                                                 T. Choi
                                                                    ETRI
                                                         January 4, 2014


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

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 8, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Lee, et al.               Expires July 8, 2014                  [Page 1]


Internet-Draft      Data Center Resource Information        January 2014


   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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   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  . . . . . . . . . .   5
   3.  ALTO-Interface Data Center Resource Information Model . . . .   6
   4.  ALTO Protocol Extension . . . . . . . . . . . . . . . . . . .   6
     4.1.  Pull Based Query/Response . . . . . . . . . . . . . . . .   7
     4.2.  Push Based Query/Response . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9

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.





Lee, et al.               Expires July 8, 2014                  [Page 2]


Internet-Draft      Data Center Resource Information        January 2014


                               +--------------+
             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 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.  Also note that
   the "application orchestrator" and the ALTO client maybe co-located.

   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




Lee, et al.               Expires July 8, 2014                  [Page 3]


Internet-Draft      Data Center Resource Information        January 2014


   model compute resources we consider both application owner and data
   center owner perspectives.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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.

   [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



Lee, et al.               Expires July 8, 2014                  [Page 4]


Internet-Draft      Data Center Resource Information        January 2014


   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
   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.




Lee, et al.               Expires July 8, 2014                  [Page 5]


Internet-Draft      Data Center Resource Information        January 2014


   [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).

   o  Data Center Identifier (DCI)

   o  Data Center Location Identifier (e.g., IP address of the gateway
      node)

   o  Time Stamp

   o  Abstracted Memory Usage

   o  Abstracted CPU Level

   o  Abstracted Power Consumption Level

   o  DC Network cost

   o  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.

4.  ALTO Protocol Extension













Lee, et al.               Expires July 8, 2014                  [Page 6]


Internet-Draft      Data Center Resource Information        January 2014


      Information Model:
      object
      {
        DCInfo dc-info;
      } InfoDCResource : ResponseEntityBase;

      object
      {
        VersionTag         vtag; [OPTIONAL]
        JSONNumber         dcid;
        TypedEndpointAddr  addr;
        JSONString         timestamp;
        JSONNumber         ramusage;
        JSONNumber         srvload;
        JSONNumber         powerusage;
        JSONNumber         cost;
        ...
      } DCInfo;


4.1.  Pull Based Query/Response

   In this case, the ALTO client should make HTTP request for DC Info to
   the ALTO server.  The ALTO server will respond only when the request
   is made by the ALTO client.


























Lee, et al.               Expires July 8, 2014                  [Page 7]


Internet-Draft      Data Center Resource Information        January 2014


      GET /getdcinfo HTTP/1.1
      Host: alto.example.com
      Accept: application/alto-dcinfo+json,application/alto-error+json

      HTTP/1.1 200 OK
      Content-Length: [TODO]
      Content-Type: application/alto-dcinfo+json
      {
        "meta" : {},
        "dc-info"   : {
        "vtag"      : ["1266506139"],
        "dcid"      : 1,
        "addr"      : ["ipv4: 10.18.51.151"],
        "timestamp" : "02 January 2014 0000H UTC",
        "ramusage"  : 60,
        "srvload"   : 25,
        "cost"      : 10
         .
         .
         .
         }
      }


4.2.  Push Based Query/Response

   In this case, the ALTO client should make an initial HTTP request for
   DC Info to the ALTO server.  Further the ALTO server can continue to
   refresh the information to ALTO client.

   Initial Request and Response is similar to Section 4.1.

   Further the ALTO server MAY refresh by sending Response on its own,
   based on future ALTO server notification/refresh mechanisms.

   [Editor's Note: should be aligned to the ALTO server notification/
   refresh mechanisms]

5.  Security Considerations

   TBD.

6.  IANA Considerations

   TBD






Lee, et al.               Expires July 8, 2014                  [Page 8]


Internet-Draft      Data Center Resource Information        January 2014


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [OpenStackQuotas]
              "OpenStack Quotas", <http://docs.openstack.org/trunk/
              openstack-ops/content/quotas.html>.

   [EC2Price]
              "Amazon EC2 Pricing",
              <http://aws.amazon.com/ec2/pricing/>.

Authors' Addresses

   Young Lee
   Huawei Technologies
   1700 Alma Drive, Suite 500
   Plano, TX  75075
   USA

   EMail: leeyoung@huawei.com


   Greg M. Bernstein
   Grotto Networking
   Fremont, California
   USA

   EMail: gregb@grotto-networking.com


   Dhruv Dhody
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: dhruv.ietf@gmail.com








Lee, et al.               Expires July 8, 2014                  [Page 9]


Internet-Draft      Data Center Resource Information        January 2014


   Tae-Sang Choi
   ETRI
   161 Gajong-Dong
   Yusong-Gu Daejon
   Republic of Korea

   EMail: choits@etri.re.kr












































Lee, et al.               Expires July 8, 2014                 [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/