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

Versions: 00 01 02 03 04 05 06 07 08

clouds                                                     B. Khasnabish
Internet-Draft                                                   ZTE USA
Intended status: Standards Track                                  J. Chu
Expires: January 2, 2012                                           S. Ma
                                                                 Y. Meng
                                                                     ZTE
                                                                   N. So
                                                                 Verizon
                                                            P. Unbehagen
                                                                   Avaya
                                                               M. Morrow
                                        Cisco Systems [Switzerland] GmbH
                                                                M. Hasan
                                                           Cisco Systems
                                                            July 1, 2011


                       Cloud Reference Framework
           draft-khasnabish-cloud-reference-framework-01.txt

Abstract

   This document presents a cloud reference framework.  In general, a
   cloud based system utilizes virtualized resources and applications.
   The reference framework is based on the survey of the SDOs and WGs
   that are focusing on cloud-based systems and services (draft-
   Khasnabish-cloud-sdo-survey-01).  Both intra-cloud and inter-cloud
   reference frameworks are presented and the requirements of each layer
   are discussed.

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 January 2, 2012.

Copyright Notice



Khasnabish, et al.       Expires January 2, 2012                [Page 1]


Internet-Draft          Cloud Reference Framework              July 2011


   Copyright (c) 2011 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.  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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



























Khasnabish, et al.       Expires January 2, 2012                [Page 2]


Internet-Draft          Cloud Reference Framework              July 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Cloud Reference Framework  . . . . . . . . . . . . . . . . . .  6
     3.1.  HORIZONTAL LAYERS  . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Application/Service Layer  . . . . . . . . . . . . . .  7
       3.1.2.  Resources Control Layer  . . . . . . . . . . . . . . .  8
       3.1.3.  Resources Abstraction and Virtualization Layer . . . .  9
       3.1.4.  Physical Resources Layer . . . . . . . . . . . . . . . 10
     3.2.  VERTICAL LAYERS  . . . . . . . . . . . . . . . . . . . . . 10
       3.2.1.  Cloud Management Layer . . . . . . . . . . . . . . . . 10
   4.  Inter-Cloud Framework  . . . . . . . . . . . . . . . . . . . . 17
     4.1.  Inter-Cloud Requirements . . . . . . . . . . . . . . . . . 17
     4.2.  Possible Inter-Clouds Interfaces . . . . . . . . . . . . . 18
   5.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  Virtual Network Management . . . . . . . . . . . . . . . . 19
     5.2.  Telecom Network Virtualization . . . . . . . . . . . . . . 19
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   10. Normative references . . . . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27



























Khasnabish, et al.       Expires January 2, 2012                [Page 3]


Internet-Draft          Cloud Reference Framework              July 2011


1.  Introduction

   We develop a general cloud reference framework.  This reference
   framework describes basic functions in different layers to support
   the requirements of virtualized applications and services.  This
   reference framework can be used to standardize a) features of
   functional elements and b) the interfaces between the functions.

   Basically, the cloud reference framework includes

   o  Five horizontal layers

      *  Data/Content Layer(DCL)

      *  Application/Service Layer(ASL)

      *  Resource Control Layer(RCL)

      *  Resource Abstract and Virtualization Layer(RAVL)

      *  Physical Resource Layer(PRL)

   o  One stacked vertical layer to support

      *  Configuration management, registry, logging and auditing,
         security management, and service level agreement (SLA)
         management
























Khasnabish, et al.       Expires January 2, 2012                [Page 4]


Internet-Draft          Cloud Reference Framework              July 2011


2.  Terminology

   Clouds Discussion Archive:
   http://www.ietf.org/mail-archive/web/clouds/current/maillist.html

   IETF Wiki Website for slides from Clouds bar BoFs:
   http://trac.tools.ietf.org/area/app/trac/wiki/Clouds












































Khasnabish, et al.       Expires January 2, 2012                [Page 5]


Internet-Draft          Cloud Reference Framework              July 2011


3.  Cloud Reference Framework


                                    +-----------------------+
         +-------------------+      |    Data/Content Layer |
         |   Cloud Portal    |      | +------+  +---------+ |
         |(Public & Private) |      | | Data |  | Content | |         +-----------------+
         +-------------------+      | +------+  +---------+ |         |                 |
                  |                 +-----------------------+         |                 |
                  |                             |                     |                 |
                  |                             |                     |                 |
+----------------------------------------------------------------+    |                 |
|                          Application/Service Layer             |    |      Cloud      |
| +-----------+ +----+ +---------------------------------------+ |    |   Management    |
| |           | |    | |   SaaS(Applications)                  | |    |                 |
| |           | |    | | +------------+ +--------------------+ | |    |                 |
| |           | |    | | |BusinessApps| |    ConsumerApps    | | |    |                 |
| |           | |    | | |(M-payment) | |(Mobile Data backup)| | |    |                 |
| | +-------+ | |    | | +------------+ +--------------------+ | |    |                 |
| | |Desktop| | |    | | +------------+ +--------------------+ | |    |                 |
| | +-------+ | |    | | |NetworkApps | | CommunicationApps  | | |    |                 |
| |           | |    | | |(Hosted PBX)| |(VoIP, Video Serv.) | | |    | +-------------+ |
| |           | |    | | +------------+ +--------------------+ | |    | |Configuration| |
| |           | |    | +---------------------------------------+ |    | |  Management | |
| |           | |    +-----------------------------------------+ |    | +-------------+ |
| | +-------+ | |  PaaS(Software Environment)                  | |    |                 |
| | |Server | | |              +-----------+  +-----------+    | |<-->| +-------------+ |
| | +-------+ | |              |Development|  |Test       |    | |    | | Registry &  | |
| |           | |              |Environment|  |Environment|    | |    | | Repository  | |
| |           | |              +-----------+  +-----------+    | |    | +-------------+ |
| |           | +----------------------------------------------+ |    |                 |
| |           +------------------------------------------------+ |    | +-------------+ |
| | IaaS(Infrastructure)     +----------+  +--------+          | |    | |   Audit &   | |
| |                          | Database |  |Security|          | |    | |   Logging   | |
| |                          +----------+  +--------+          | |    | +-------------+ |
| |                          +----------+  +--------+          | |    |                 |
| |                          |MiddleWare|  |  VLAN  |          | |    | +-------------+ |
| |                          +----------+  +--------+          | |    | |     SLA     | |
| +------------------------------------------------------------+ |    | +-------------+ |
+----------------------------------------------------------------+    |                 |
         |                    |                    |                  | +-------------+ |
         |                    |                    |                  | |   Security  | |
+----------------------------------------------------------------+    | +-------------+ |
|                               Resource Control Layer           |    |                 |
| +---------+ +--------+ +--------+ +------------+ +-----------+ |    |                 |
| |Resource | |Resource| |Resource| |Resource    | |Inter-Cloud| |    |                 |
| |Admission| |Authen. | |Schedule| |Availability| |Resource   | |<-->|                 |
| |Control  | |&Author.| |Control | |Control     | |Control    | |    |                 |



Khasnabish, et al.       Expires January 2, 2012                [Page 6]


Internet-Draft          Cloud Reference Framework              July 2011


| |         | |Control | |        | |            | |           | |    |                 |
| +---------+ +--------+ +--------+ +------------+ +-----------+ |    |                 |
+----------------------------------------------------------------+    |                 |
         |                      |                    |                |                 |
         |                      |                    |                |                 |
+----------------------------------------------------------------+    |                 |
|                  Resource Abstract&Virtualization Layer        |    |                 |
| +------------------------------------------------------------+ |    |                 |
| |                                  Virtualized Resource      | |    |                 |
| | +---------+  +--------+  +------+  +------------+  +-----+ | |    |                 |
| | |   V-    |  |  V-    |  |  V-  |  |    V-      |  | VPN | | |    |                 |
| | |Computing|  |Storage |  |Switch|  |Netwk Intf. |  +-----+ | |    |                 |
| | +---------+  +--------+  +------+  +------------+          | |    |                 |
| | +---------+  +--------+  +------+  +------------+          | |    |                 |
| | |   V-    |  |   V-   |  |  V-  |  |     V-     |  +-----+ | |    |                 |
| | |Database |  |FireWall|  |Router|  |Network Link|  |Other| | |    |                 |
| | +---------+  +--------+  +------+  +------------+  +-----+ | |    |                 |
| +------------------------------------------------------------+ |<-->|                 |
|----------------------------------------------------------------|    |                 |
|      +----+      +----+      +----+      +----+      +----+    |    |                 |
|      | VM |      | VM |      | VM |      | VM |      | VM |    |    |                 |
| +------------------------------------------------------------+ |    |                 |
| |                             Hypervisor                     | |    |                 |
| +------------------------------------------------------------+ |    |                 |
+----------------------------------------------------------------+    |                 |
         |                   |                     |                  |                 |
         |                   |                     |                  |                 |
+----------------------------------------------------------------+    |                 |
|                               Physical Resource Layer          |    |                 |
| +----------+ +-------------+ +-------------------------------+ |    |                 |
| |  SERVER  | |  STORAGE    | |          NETWORK              | |<-->|                 |
| | +------+ | | +---------+ | | +------+ +--------+ +------+  | |    |                 |
| | | CPU  | | | |Hard Disk| | | |Router| |FireWall| |Switch|  | |    |                 |
| | +------+ | | +---------+ | | +------+ +--------+ +------+  | |    |                 |
| | +------+ | |             | | +-----------+ +------------+  | |    |                 |
| | |MEMORY| | |             | | |Netwk Intf.| |Network Link|  | |    |                 |
| | +------+ | |             | | +-----------+ +------------+  | |    |                 |
| +----------+ +-------------+ +-------------------------------+ |    |                 |
+----------------------------------------------------------------+    +-----------------+


3.1.  HORIZONTAL LAYERS

3.1.1.  Application/Service Layer

   Application/Service Layer defines the requirements of the basic
   functional entities based on the virtual resources needed to perform
   any tasks.  The tasks are classified according to the 3 services



Khasnabish, et al.       Expires January 2, 2012                [Page 7]


Internet-Draft          Cloud Reference Framework              July 2011


   models IaaS, PaaS & SaaS.  Some cloud services are illustrated as an
   example of applications like:

   o  Server, desktop, database and VLAN for IaaS,

   o  Development environment and test environment for PaaS,

   o  Business, consumer, network and communication applications for
      SaaS.

   The requirements the basic functional entities provided include the
   following characteristics and parameters of the virtual resources:

   o  Type of resources: CPU, memory, hard disk space, bandwidth,
      latency, jitter, and so on

   o  Amount of resources

   o  Nature of the resources: dedicated vs. shared, transport media
      exclusions, and so on

   o  Timing of the resources: scheduled vs. on-demand

   o  Duration of the Resources

3.1.2.  Resources Control Layer

   Resources Control Layer manages the virtual resources, ensuring that
   the resources are efficient, secure and reliable.  With the interface
   of virtual resources, the layer integrates the resources as a whole
   supplied to upper layer.  The layer has the following
   responsibilities:

   o  Resource security management.  Resources must be accessed and
      owned by the right user, there are several function modules to
      fulfill this responsibility, include resource admission control,
      resource authentication and authorization control;

   o  Resource schedule control.  The layer manages resources in form of
      resource pool.  In a resource pool, the layer balances the virtual
      resources on a set of physical equipments to achieve higher
      hardware utilization.  Virtual resources can be migrated between
      physical equipments if necessary, and also can be allocated
      according to user's priority grade.

   o  Inter-cloud resource control.  Resources in a cloud can be shared
      with another cloud in some circumstances, so a cloud must control
      resources in other cloud, and supply cloud service to end users.



Khasnabish, et al.       Expires January 2, 2012                [Page 8]


Internet-Draft          Cloud Reference Framework              July 2011


      End users have no need to know where the resources are from.

   o  Resource availability control.  The layer supports fault-tolerance
      on resources.  It can allocate another copy of resources as a
      backup, and switch over when some faults raised.

3.1.3.  Resources Abstraction and Virtualization Layer

   Physical resources at the lowest level are the most complex to share
   among multiple users.  There are several hardware details that don't
   need to visible to users, so we need a level of abstraction.  In
   fact, these physical resources are abstracted first.  The function of
   resources abstraction and virtualization layer is to convert physical
   resources to virtual resources.  Virtual resources are contained in
   resource pool.  Resources can be allocated to users from the resource
   pool, and released to resource pool when it's not needed.

   Virtual resources are isolated from physical equipments, and have the
   features:

   o  Have all features as physical resources, resource users can't
      distinguish the difference between them;

   o  Can be allocated and released on demand;

   o  Support heterogeneous physical equipments, and supply a
      consistency view of resources to users;

   o  Support resource mobility, virtual resource can move from a
      physical equipment to another seamlessly;

   There are several types of resources, such as computing resource,
   storage resource, database, bandwidth and network.  According to the
   type of resource, there are different methods to realize
   virtualization.  The variety function modules for virtualization are
   contained in Resources abstraction and virtualization layer.  The
   layer has the following responsibilities:

   o  Through the interface of physical equipment to manage physical
      resource, mapping the virtual resources to physical resource;

   o  Supply the interface to upper layer to manage and access virtual
      resources;

   o  Hide the details of physical equipments, mask the difference
      between physical equipments.





Khasnabish, et al.       Expires January 2, 2012                [Page 9]


Internet-Draft          Cloud Reference Framework              July 2011


3.1.3.1.  Networking (Resources) Layer

   Networking (Resources) layer converts and communicates network (LAN/
   MAN/WAN) capabilities and capacities(such as Bandwidth, ports,
   Latency matrices, Jitter matrices, Availability, Restoration
   capabilities, etc) into a set of resource pools that can be
   understood and used by the above layers.  The resource pools include

   o  Virtual Switch

   o  Virtual Router

   o  Virtual Firewall

   o  Virtual Network Interface

   o  Virtual Network Link

   o  VPN

3.1.4.  Physical Resources Layer

   Physical Resources Layer include

   o  CPU

   o  Memory

   o  Hard Disk

   o  Network Interface Card

   o  Network Link

      *  Ports

      *  Bandwidth

3.2.  VERTICAL LAYERS

3.2.1.  Cloud Management Layer

   Cloud Management Layer (CML) provides monitoring and administration
   of the cloud network platform to keep the whole cloud operating
   normally.

   Key features of the Virtual System Management Layer include:




Khasnabish, et al.       Expires January 2, 2012               [Page 10]


Internet-Draft          Cloud Reference Framework              July 2011


   o  Automatically deploying the cloud system based on the
      configuration data and policy

   o  Real-time monitoring and alerting of cloud status, resource usage
      and performance of cloud

   o  Reporting and charting of historical events and performance
      metrics

   o  Flexible IT management and operational status displays

   o  Authenticating/Authorizing the published cloud service registry

   o  Auditing the cloud environment to check whether its running
      smoothly

   o  Controlling the SLA implemented in the cloud system

   o  Maintenance concerned with performing repairs, upgrades and new
      nodes join into the Cloud

   o  Providing Security mechanism for the Cloud

   Basically CML includes four Functions:

   o  Cloud Configuration Management

   o  Cloud Service Registry and Audit Management

   o  Cloud SLA Management

   o  Cloud Service Security Management

3.2.1.1.  Cloud Configuration Management

   Cloud Configuration Management (CCM) is responsible for establishing
   and maintaining the consistent performance of the Clouds system or
   product and its functional and physical attributes throughout its
   life-cycle.  It mainly focuses on configuring the cloud system and
   retrieving the configuration information automatically.  Requirements
   on Configuration Management are as follows:

   o  Provide efficient and reliable means to provision large amounts of
      configuration data.  Current versions of provision configuration
      data are CLI, SNMP and NETCONF.

   o  Provide secure means to provision configuration data.  The system
      must provide support for access control, authentication,



Khasnabish, et al.       Expires January 2, 2012               [Page 11]


Internet-Draft          Cloud Reference Framework              July 2011


      integrity-checking, replay- protection and/or privacy security
      services.

   o  Provide means to send feedback information to the management
      system.  Feedback information include configuration data
      confirmation, network status and monitoring information, specific
      events, etc.

   o  Provide expiration time and effective time capabilities to
      configuration data.  It is required that some configuration data
      items be set to expire, and other items be set to never expire.

   o  Provide facilities to help in tracing back configuration changes

   o  Be flexible and extensible to accommodate future needs.
      Configuration management data models are not fixed for all time
      and are subject to evolution like any other management data model.

   o  Leverage knowledge of the existing SNMP management infrastructure,
      such as the knowledge of and experience with MIBs and SMI.

   o  Basically, the CM includes CM database, CM policy, system change
      management and version management.

   o  Related protocol: CLI, SNMP, NETCONF

3.2.1.2.  Cloud Service Registry/Repository

   Service Registry/Repository provides management and governance
   capabilities that enable the published cloud service to be
   authenticated in the cloud system and accessed by service client.  It
   facilitates storing, accessing and managing service information,
   called service metadata, so that the cloud service can be easily
   published, selected, invoked, enriched, governed and reused.

   Requirements on Service Registry/Repository are as follows:

   o  Authentication & Authorization.  Once a service is published by
      the service provider to the Cloud system, it should be
      authenticated to check the authority of the provider and the
      support capability of the Cloud.  If the check is passed, the
      service is authorized and put into the repository, and the
      services and related metadata are classified into groups.

   o  Publication & Discovery.  The authorized service is published in
      the Cloud system, and you can keep an accurate record of the
      deployed services in your repository platform.  The user can find
      the service from the repository platform using the service



Khasnabish, et al.       Expires January 2, 2012               [Page 12]


Internet-Draft          Cloud Reference Framework              July 2011


      discovery engine.  Cloud Service Registry/Repository is capable of
      a powerful query mechanism allows you to search and find the
      services that best fit the requirements of a given process.

   o  Service Access Control.  The service repository enables dynamic
      and efficient access to services information by enabling selection
      of services based on service metadata.

   o  Optimize service usage.  Service manage capability enables
      management of service metadata, as well as service interactions,
      dependencies and redundancies.  You can classify services based on
      business objectives, manage policies for service usage and monitor
      how services are changed and versioned.  This capability helps you
      optimize the use of services in cloud system by exchanging service
      metadata with runtime monitoring tools and operational data
      stores.

   o  Impact analysis.  By maintaining relationships, Cloud Service
      Registry/Repository has extensive support for analyzing the impact
      of service introduction, deletion or alteration.

   o  Service life cycle.  By creating user-definable entities and
      customizing the service life cycle, you can configure Cloud
      Service Registry/Repository precisely according to your business
      needs.  You can easily implement best practices for service life-
      cycle management with the ability to promote services and life-
      cycle validations.

   o  Policy support.  You can publish policies that apply to services
      stored in Cloud Service Registry/Repository.  These policies help
      you institute best practices in your Cloud deployment.

   o  Governance profile.  To help you get started easily and quickly,
      Cloud Service Registry/Repository provides a welldefined service
      model that includes templates, associated life cycles, governance
      policies, a classification system, roles and perspectives.

3.2.1.3.  Cloud Audit Management

   Cloud Audit Management (CAM) is to provide an agent through which
   cloud providers and authorized consumers automate the Audit,
   Assertion, Assessment, and Assurance of the cloud infrastructure
   (IaaS), platform (PaaS), and application (SaaS) environments to
   reduce the risk.  A common interface and namespace can be used by the
   CAM to facilitate these audit functions.

   Requirements on CAM are as follows:




Khasnabish, et al.       Expires January 2, 2012               [Page 13]


Internet-Draft          Cloud Reference Framework              July 2011


   o  A well-defined objective and scope tied to quality compliance and
      risk management processes

   o  Establish clear policies, procedures, and metrics.  Audit
      management should incorporate defined policies, procedures, and
      metrics as performance benchmarks.  These elements should be
      reviewed periodically for continuous improvement.

   o  Integrate essential quality management processes.  An effective
      audit management system should automate the entire audit process
      and include integration of the following processes:

      *  Corrective and preventive actions

      *  Change control

      *  Non-conformance tracking and management

      *  Regulatory document/content management

      *  Custom reporting, analysis and analytics

      *  Training

      *  Compliance intelligence dashboard

3.2.1.4.  Cloud SLA Management (CSM)

   SLA is a part of a service contract where the level of service is
   formally defined between Cloud service providers and Cloud customers.
   Within the terms of their contracts, the SLA will have a technical
   definition, typical terms as MTTF (Mean Time To Failures), MTTR (Mean
   Time To Repair), ABA (Abandonment Rate), ASA (Average Speed to
   Answer), TSF (Time Service Factor), FCR (First Call Resolution), TAT
   (Turn Around Time), Uptime Agreements, various data rates, etc.

   SM is to control the usage and receipt of resources from and by third
   parties.  The strategy of CSM includes the negotiation of the
   contract and the monitoring of its realization in real-time.  Thus,
   CSM encompasses the SLA contract definition (basic schema within QoS
   parameters), the SLA negotiation, the SLA monitoring, and the SLA
   enforcement.

   SM also need define rate reductions and discounts that are applied
   when a service provider fails to meet the desired service parameters
   or does not fulfill an agreement.

   Requirements on CSM are as follows:



Khasnabish, et al.       Expires January 2, 2012               [Page 14]


Internet-Draft          Cloud Reference Framework              July 2011


   o  SLA template specification. when service provider publishes a new
      service, an SLA template which describes the contract type that
      goes with the resource usage will be specified.  Such a template
      may be hard to define we propose to develop a skeleton of a
      template with the corresponding write-up procedure.

   o  Negotiation.  Service client and service providers have to agree
      on the terms of the SLA binding them and also with the
      consequences to violations.

   o  Resource Optimization.  When the SLA processes the service access
      request from the service client, it also has to keep in mind the
      optimization of the usage of resources, and the QoS guaranteed in
      the SLA.

   o  Monitoring.  Once the cloud system has started providing access to
      its resources, it should monitor the operating resources.  The
      monitored information is then used to prove the QoS agreed within
      the SLA being satisfied.

   o  Re-negotiation.  Some party of the contract may wish to change the
      resource usage policy while the system is running, in order to
      comply with a change in external conditions.  In order to keep the
      behaviour of the process continuous, the agreed SLA need adjust to
      assure the process vitality after migration and resource shortage.

   o  Evaluation.  Besides the running information is interested by the
      managers and users, other data like contract violations or global
      statistics are also needed in order to verify the SLA.  Evaluation
      is the process of analyzing the previously monitored information.
      An evaluation daemon may be proposed, based on the monitoring
      tools developed.

   o  Accounting.  The use of a resource generates an accounting sheet
      which describes the resources used and aligns them with the
      billing rules agreed in the SLA.  This is a base to draft the real
      financial exchange, which can be in disfavour of the provider in
      case of failure to comply with the compromised QoS.  This subject
      is very sensible, and the development of tools for such themes
      should not be taken lightly.

   Related Language: WSLA, ITIL

3.2.1.5.  Cloud Service Security Management

   Cloud Service Security (CSS) provides a set of mechanisms (e.g.  IP
   address filtering, message integrity & confidentiality, private key
   encryption, dynamic session key encryption, user authentication and



Khasnabish, et al.       Expires January 2, 2012               [Page 15]


Internet-Draft          Cloud Reference Framework              July 2011


   Service certification) to protect Cloud Services and their operating
   environment from damage.

   Requirements on CSS are as follows

   o  Licensing.  It is likely that your service is made up of many
      different components, most of which have some type of licensing
      agreement associated with them.  You will need to review each of
      those agreements to determine if, or how, those licenses will be
      affected by deployment in a cloud.  If your service uses a
      component that is licensed by CPU and you deploy it in a cloud
      environment designed to launch new instances and request more
      resources as load increases, for example, you could easily exceed
      your CPU license limit.  You will need to understand how your
      licenses affect your ability to scale.

   o  Processing requirements and memory locks.  If dynamic scalability
      is your main reason for looking to the cloud, then your
      application should be designed to take advantage of a parallel
      architecture.  If the application is designed with multi-threaded
      code that allows processing to be split into small chunks, it's
      well-suited for use within the cloud.  An application that is
      designed around single monolithic thread processing, on the other
      hand, will find it difficult to take advantage of the cloud's
      distributed nature.

   o  Communication protocol.  The cloud is based on the Internet
      Protocol (IP), so for an service to be considered, it must use IP
      as its communication mechanism.  While there are many protocols
      that can be run over IP, the IP layer can provide security
      mechanism to protect the security of the transmitted data.

   o  Data security.  The service needs to provide security at the data
      storage, processing and transmission stages.  Data at rest must be
      protected by the service, that is the service must provide a
      mechanism to protect the data stored in the cloud.  Data in
      transit needs to be protected either at the service or the
      transmission level.  Most services choose the transmission level
      for protection and the Secure Sockets Layer (SSL)/Transport Layer
      Security (TLS) protocols are often used.  Server to server
      communications need to ensure the security from one cloud instance
      to another cloud instance.









Khasnabish, et al.       Expires January 2, 2012               [Page 16]


Internet-Draft          Cloud Reference Framework              July 2011


4.  Inter-Cloud Framework

   A Cloud Service Provider (CSP) can offer services using one or more
   date centers (DCs).  These DCs can provide virtualized compute,
   storage, and networking resources on on-demand basis to the Cloud
   Service Consumers (CSC).  Therefore, the DC infrastructure does not
   necessarily need to be a static entity as in a traditional DC.  The
   infrastructure resources can span multiple CSPs and the entity that
   is offered to the consumer can be referred to as the Infrastructure
   as a Service (IaaS).

   With the IaaS, a CSC can acquire and release resources on on-demand
   basis.

   We therefore define an Inter-Cloud as a interconnction of clouds
   where two or more cloud service providers (any combination of
   Service-Provider-owned, private, public, etc.) can collaborate.  The
   objective of the collaboration is to dynamically distribute the
   workloads based on mutually agreed upon service level agreement
   (SLA).

                            Inter-Cloud Interface
                                     |
  +---------------------------+   ICI-1      +-------------------------+
  |             Cloud 1       |<-----|------>|   Cloud 2               |
  |            +-----------+  |      |       |  +-----------+          |
  |            |Inter-Cloud|  |   ICI-2      |  |Inter-Cloud|          |
  |            |Resource   |  |<-----|------>|  |Resource   |          |
  |            |Control    |  |      |       |  |Control    |          |
  |            +-----------+  |   ICI-3      |  +-----------+          |
  |                           |<-----|------>|                         |
  +---------------------------+      |       +-------------------------+


4.1.  Inter-Cloud Requirements

   Inter-cloud requirements may be articulated as follows:

   o  Provide a mechanism for resource search and discovery, to
      determine which serving cloud might have certain resources
      available (including a match making mechanism).

   o  Provide a mechanism to authenticate participating entities.

   o  Provide a mechanism for requesting, controlling, and releasing
      resources between two clouds.





Khasnabish, et al.       Expires January 2, 2012               [Page 17]


Internet-Draft          Cloud Reference Framework              July 2011


   o  Provide a secure transport channel between the interconnecting
      entities.

   o  Provide end-to-end isolation to support multitenancy.

   o  Provide a mechanism for monitoring, assuring, and troubleshooting
      across the interconnection.

   o  Provide a mechanism for defining the monitoring metrics such as
      Delay-Jitter-Loss.  This may be useful for monitoring a flow such
      as TCP/UDP between IP prefix and a destination address across the
      interconnection.

4.2.  Possible Inter-Clouds Interfaces

   o  Provisioning

   o  Signaling

   o  Control

   o  Monitoring

   o  Management

   o  Transport

   o  Security

   o  Naming, Addressing and Translation (if/as needed)





















Khasnabish, et al.       Expires January 2, 2012               [Page 18]


Internet-Draft          Cloud Reference Framework              July 2011


5.  Use Cases

5.1.  Virtual Network Management

   Configuration Management in VSML is responsible for creating and
   managing virtual network through the interface between the
   Configuration Manager and the Resources Abstraction&Virtualization
   Layer or Physical Resource Layer.  This section is based on the
   information available in the following draft: draft-Okita-Clouds-VNM-
   model-for-PaaS-00, Okita-Clouds-VNM-model-for-PaaS-Sept10.pdf


+------------------------------------------------+    +-----------------+
|      Application/Service Layer                 |<-->|     Cloud       |
+------------------------------------------------+    |   Management    |
        |             |             |                 |                 |
        |             |             |                 |                 |
+------------------------------------------------+    |                 |
|      Resource Control Layer                    |<-->|                 |
+------------------------------------------------+    |                 |
        |             |             |                 |                 |
        |             |             |                 |                 |
+------------------------------------------------+    |                 |
|       Resource Abstraction&Virtualization Layer|    | +-------------+ |
|     +---------+  +---------+  +---------+      |    | |Configuration| |
|     |    V-   |  |    V-   |  |    V-   |      |<-->| |  Management | |
|     |  Switch |  |Interface|  |   Link  |      |    | +-------------+ |
|     +---------+  +---------+  +---------+      |    |                 |
+------------------------------------------------+    |                 |
        |             |             |                 |                 |
        |             |             |                 |                 |
+------------------------------------------------+    |                 |
|       Physical Resource Layer                  |    |                 |
|                   +-------+                    |    |                 |
|                   |Network|                    |<-->|                 |
|                   +-------+                    |    |                 |
+------------------------------------------------+    +-----------------+


5.2.  Telecom Network Virtualization

   Telecom Network virtualization is the technology that enables the
   creation of logically isolated network partitions over shared
   physical network infrastructures so that multiple virtual telecom
   networks can simultaneously coexist over the shared infrastructures.

   The objectives of telecom network virtualization is to




Khasnabish, et al.       Expires January 2, 2012               [Page 19]


Internet-Draft          Cloud Reference Framework              July 2011


   o  scale telecom services on demand

   o  improve reliability and availability

   o  efficiently use infrastructure

   In order to facilitate the deployment of telecom network
   virtualization, Manager Node provides control procedures such as
   creating Functional (Service) Entity operating on Execution Node,
   monitoring the status of Functional (Service) Entity and Execution
   Node, measuring the performance, retrieving deployment data from
   Infromation Server, and so on.  This section is based on the
   information available in the following draft: draft-Yokota-Clouds-
   Telecom-Net-Virtualization-00, Yokota-Clouds-Telecom-Net-
   Virtualization-Sept10.pdf


                               +---------------------------+
                               |      Information Server   |\
                               +---------------------------+ \
                                            |                 \
   +------------------------------------------------+    +-------------+
   |      Application/Service Layer                 |<-->|   Cloud     |
   +------------------------------------------------+    | Management  |
           |             |             |                 |             |
           |             |             |                 |             |
   +------------------------------------------------+    | +---------+ |
   |      Resource Control Layer                    |<-->| | Manager | |
   +------------------------------------------------+    | |   Node  | |
           |             |             |                 | +---------+ |
           |             |             |                 |             |
   +------------------------------------------------+    |             |
   |       Resource Abstraction&Virtualization Layer|    |             |
   |   +---------+    +---------+    +---------+    |    |             |
   |   |Execution|----|Execution|----|Execution|    |<-->|             |
   |   |   Node  |    |   Node  |    |   Node  |    |    |             |
   |   +---------+    +---------+    +---------+    |    |             |
   +------------------------------------------------+    |             |
           |             |             |                 |             |
           |             |             |                 |             |
   +------------------------------------------------+    |             |
   |      Physical Resource Layer                   |<-->|             |
   +------------------------------------------------+    +-------------+


   Manager Node manages the Execution Node and communicates with
   Information Server to get configuration data.




Khasnabish, et al.       Expires January 2, 2012               [Page 20]


Internet-Draft          Cloud Reference Framework              July 2011


   Execution Node is a physical or virtual machines on which target
   telecomm functions (software) are running.  For example, in IMS, CSCF
   and HSS are candidates of functions.

   Information Server (optional) is used for discovery and assignment of
   Execution Node for a session (e.g., P-CSCF at a UE's registration).













































Khasnabish, et al.       Expires January 2, 2012               [Page 21]


Internet-Draft          Cloud Reference Framework              July 2011


6.  Conclusion

   We presented a high-level cloud reference framework.  Two examples on
   utilization of the reference framework are also discussed.















































Khasnabish, et al.       Expires January 2, 2012               [Page 22]


Internet-Draft          Cloud Reference Framework              July 2011


7.  Security Considerations

   --[Editor's note] Will be added in future.
















































Khasnabish, et al.       Expires January 2, 2012               [Page 23]


Internet-Draft          Cloud Reference Framework              July 2011


8.  Acknowledgement

   We thank T. Sridhar (thsridhar@gmail.com), Simon Leinen
   (simon.leinen@switch.ch) for comments on an earlier version of this
   document.














































Khasnabish, et al.       Expires January 2, 2012               [Page 24]


Internet-Draft          Cloud Reference Framework              July 2011


9.  IANA Considerations

   This document has no actions for IANA.
















































Khasnabish, et al.       Expires January 2, 2012               [Page 25]


Internet-Draft          Cloud Reference Framework              July 2011


10.  Normative references

   [Cloud ServiceMobility]
              Yokota, H., "draft-yokota-cloud-service-mobility-01",
              March 2011.

   [DSP0004]  DMTF, "Common Information Model (CIM) Infrastructure",
              May 2009.

   [DSP1041]  DMTF, "Resource Allocation Profile", June 2009.

   [DSP1042]  DMTF, "System Virtualization Profile", April 2010.

   [DSP1057]  DMTF, "Virtual System Profile", October 2009.

   [DSP1059]  DMTF, "Generic Device Resource Virtualization Profile",
              July 2009.

   [ITU-T FGCC]
              FGCC, "cloud-o-0046-funct_ref_arch", April 2011.

   [ITU-T Y.2011]
              ITU SG13, "Y.2011_General principles and general reference
              model for NGN", October 2004.

   [RFC2119]  IETF, "Key words for use in RFCs to Indicate Requirement
              Levels", March 1997.

   [RFC4741]  IETF, "NETCONF Configuration Protocol", December 2006.

   [UML]      OMG, "Unified Modeling Language", September 2002.

   [VNet Model]
              Okita, H., "draft-okita-ops-vnetmodel-03", April 2011.

















Khasnabish, et al.       Expires January 2, 2012               [Page 26]


Internet-Draft          Cloud Reference Framework              July 2011


Authors' Addresses

   Bhumip Khasnabish
   ZTE USA
   55 Madison Avenue, Suite 160
   Morristown, NJ 07960
   USA

   Phone: +001-781-752-8003
   Email: vumip1@gmail.com


   Chu JunSheng
   ZTE
   No.50 Ruanjian Dadao Road, Yuhuatai District
   Nanjing
   China

   Phone: +86-25-8801-4630
   Email: chujunsheng@zte.com.cn


   Ma SuAn
   ZTE
   No.68 Zijinghua Rd,Yuhuatai District
   Nanjing
   China

   Phone: +86-25-5287-8189
   Email: ma.suan@zte.com.cn


   Meng Yu
   ZTE
   No.50 Ruanjian Dadao Road, Yuhuatai District
   Nanjing
   China

   Phone: +86-25-8801-4631
   Email: meng.yu@zte.com.cn











Khasnabish, et al.       Expires January 2, 2012               [Page 27]


Internet-Draft          Cloud Reference Framework              July 2011


   Ning So
   Verizon
   2400 N. Glenville Dr.
   Richardson, TX 75082
   USA

   Phone: +1-972-729-7905
   Email: ning.so@verizonbusiness.com


   Paul Unbehagen
   Avaya
   USA

   Phone: +1-919-606-8845
   Email: paul@unbehagen.net


   Monique Morrow
   Cisco Systems [Switzerland] GmbH
   Richistrasse 7
   CH-8304 Wallisellen
   Switzerland

   Phone:
   Email: mmorrow@cisco.com


   Masum Hasan
   Cisco Systems
   3675 Cisco Way
   San Jose, California 95134
   USA

   Phone:
   Email: masum@cisco.com















Khasnabish, et al.       Expires January 2, 2012               [Page 28]


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