clouds B. Khasnabish
Internet-Draft ZTE USA
Intended status: Standards Track J. Chu
Expires: July 4, 2011 S. Ma
Y. Meng
ZTE
N. So
Verizon
P. Unbehagen
Alcatel-Lucent
December 31, 2010
Cloud Reference Framework
draft-khasnabish-cloud-reference-framework-00.txt
Abstract
During IETF 78 Clouds Bar BoF, it was observed that there is no
standard reference framework for Cloud Services. Based on the survey
of Cloud-based systems and services (draft-Khasnabish-cloud-sdo-
survey-00, draft-khasnabish-cloud-Industry-workitems-survey-00),
intra-cloud and inter-cloud reference frameworks are developed and
presented in this document. The requirements of each layer are also
identified and 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 July 4, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Khasnabish, et al. Expires July 4, 2011 [Page 1]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 2]
Internet-Draft Cloud Reference Framework December 2010
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. Possible Inter-Clouds Interfaces . . . . . . . . . . . . . 17
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Virtual Network Management . . . . . . . . . . . . . . . . 18
5.2. Telecom Network Virtualization . . . . . . . . . . . . . . 18
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Normative references . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Khasnabish, et al. Expires July 4, 2011 [Page 3]
Internet-Draft Cloud Reference Framework December 2010
1. Introduction
Based on the discussion among the participants of the Cloud Bar BoF
meetings, the Cloud SDOs and Industry Survey Results, we develop a
general cloud reference framework. This reference framework involves
basic functions or layers to support the general requirements of
Cloud Applications and Services. This reference framework can be
used to standardize the interfaces between the functions or layers.
Basically, the Cloud Framework can be divided into
o Four horizontal layers
* 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 July 4, 2011 [Page 4]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 5]
Internet-Draft Cloud Reference Framework December 2010
3. Cloud Reference Framework
+------------------------------+ +-----------------+
| Cloud Portal | | |
| (Public & Private) | | |
+------------------------------+ | |
| | |
| | |
+----------------------------------------------------------------------+ | |
| Application/Service Layer | | Cloud |
| +-----------+ +------+ +-------------------------------------------+ | | Management |
| | | | | | SaaS(Applications) | | | |
| | | | | | +----------------+ +--------------------+ | | | |
| | | | | | | BusinessApps | | ConsumerApps | | | | |
| | | | | | |(Mobile payment)| |(Mobile Data backup)| | | | |
| | +-------+ | | | | +----------------+ +--------------------+ | | | |
| | |Desktop| | | | | +------------+ +--------------------+ | | | |
| | +-------+ | | | | |NetworkApps | | CommunicationApps | | | | |
| | | | | | |(Hosted PBX)| |(VoIP,Video Service)| | | | +-------------+ |
| | | | | | +------------+ +--------------------+ | | | |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| |Authentication| |Schedule| |Availability| |Resource | |<-->| |
| |Control | |&Authorization| |Control | |Control | |Control | | | |
| | | |Control | | | | | | | | | |
| +---------+ +--------------+ +--------+ +------------+ +-----------+ | | |
Khasnabish, et al. Expires July 4, 2011 [Page 6]
Internet-Draft Cloud Reference Framework December 2010
+----------------------------------------------------------------------+ | |
| | | | |
| | | | |
+----------------------------------------------------------------------+ | |
| Resource Abstract&Virtualization Layer | | |
| +------------------------------------------------------------------+ | | |
| | Virtualized Resource | | | |
| | +---------+ +--------+ +------+ +-----------------+ +------+ | | | |
| | | V- | | V- | | V- | | V- | | VPN | | | | |
| | |Computing| |Storage | |Switch| |Network Interface| +------+ | | | |
| | +---------+ +--------+ +------+ +-----------------+ | | | |
| | +---------+ +--------+ +------+ +-----------------+ | | | |
| | | 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| | | | | |Network Interface| |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
models IaaS, PaaS & SaaS. Some cloud services are illustrated as an
example of applications like:
Khasnabish, et al. Expires July 4, 2011 [Page 7]
Internet-Draft Cloud Reference Framework December 2010
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.
End users have no need to know where the resources are from.
Khasnabish, et al. Expires July 4, 2011 [Page 8]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 9]
Internet-Draft Cloud Reference Framework December 2010
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 Cloud Management Layer include:
Khasnabish, et al. Expires July 4, 2011 [Page 10]
Internet-Draft Cloud Reference Framework December 2010
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 and SNMP.
o Provide secure means to provision configuration data. The system
must provide support for access control, authentication,
Khasnabish, et al. Expires July 4, 2011 [Page 11]
Internet-Draft Cloud Reference Framework December 2010
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 CCM includes CM database, CM policy, system change
management and version management.
o Related protocol: CLI, SNMP
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 July 4, 2011 [Page 12]
Internet-Draft Cloud Reference Framework December 2010
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 Cloud Audit Management are as follows:
Khasnabish, et al. Expires July 4, 2011 [Page 13]
Internet-Draft Cloud Reference Framework December 2010
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.
Cloud SLA Management (CSM) 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.
CSM 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 July 4, 2011 [Page 14]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 15]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 16]
Internet-Draft Cloud Reference Framework December 2010
4. Inter-Cloud Framework
Inter-Cloud Interface
|
+---------------------------+ ICI-1 +-------------------------+
| Cloud 1 |<-----|------>| Cloud 2 |
| +-----------+ | | | +-----------+ |
| |Inter-Cloud| | ICI-2 | |Inter-Cloud| |
| |Resource | |<-----|------>| |Resource | |
| |Control | | | | |Control | |
| +-----------+ | ICI-3 | +-----------+ |
| |<-----|------>| |
+---------------------------+ | +-------------------------+
4.1. 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 July 4, 2011 [Page 17]
Internet-Draft Cloud Reference Framework December 2010
5. Use Cases
5.1. Virtual Network Management
Configuration Management in Cloud Management 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 July 4, 2011 [Page 18]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 19]
Internet-Draft Cloud Reference Framework December 2010
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 July 4, 2011 [Page 20]
Internet-Draft Cloud Reference Framework December 2010
6. Conclusion
We preseneted a high-level cloud reference framework. Two examples
on utilization of the reference framework are also discussed.
Khasnabish, et al. Expires July 4, 2011 [Page 21]
Internet-Draft Cloud Reference Framework December 2010
7. Security Considerations
--[Editor's note] Will be added in future.
Khasnabish, et al. Expires July 4, 2011 [Page 22]
Internet-Draft Cloud Reference Framework December 2010
8. Acknowledgement
We thank T. Sridhar for comments on an earlier version of this
document.
Khasnabish, et al. Expires July 4, 2011 [Page 23]
Internet-Draft Cloud Reference Framework December 2010
9. IANA Considerations
This document has no actions for IANA.
Khasnabish, et al. Expires July 4, 2011 [Page 24]
Internet-Draft Cloud Reference Framework December 2010
10. Normative references
Khasnabish, et al. Expires July 4, 2011 [Page 25]
Internet-Draft Cloud Reference Framework December 2010
Authors' Addresses
Bhumip Khasnabish
ZTE USA
33 Wood Avenue South, 2nd Floor
Iselin, NJ 08830
USA
Phone: +001-781-752-8003
Email: vumip1@gmail.com
JunSheng Chu
ZTE
No.68 Zijinghua Rd,Yuhuatai District
Nanjing
China
Phone: +86-25-5287-1114
Email: chujunsheng@zte.com.cn
SuAn Ma
ZTE
No.68 Zijinghua Rd,Yuhuatai District
Nanjing
China
Phone: +86-25-5287-8189
Email: ma.suan@zte.com.cn
Yu Meng
ZTE
No.68 Zijinghua Rd,Yuhuatai District
Nanjing
China
Phone: +86-25-5287-1277
Email: meng.yu@zte.com.cn
Khasnabish, et al. Expires July 4, 2011 [Page 26]
Internet-Draft Cloud Reference Framework December 2010
Ning So
Verizon
2400 N. Glenville Dr.
Richardson, TX 75082
USA
Phone: +1-972-729-7905
Email: ning.so@verizonbusiness.com
Paul Unbehagen
Alcatel-Lucent
2301 Sugar Bush Rd
Raleigh, NC 27612
USA
Phone: +1-919-606-8845
Email: paul.unbehagen@alcatel-lucent.com
Khasnabish, et al. Expires July 4, 2011 [Page 27]