er telecom grade cloud

8/11/2019 Er Telecom Grade Cloud

1/5

Deploying telecom-gradeproducts in the cloudGone are the days when the cloud was simply considered to be extra and unreliable computingcapacity. Today it has developed to become the center of an established business model in whichglobal applications are hosted, resources are efciently managed and economies-of-scale created.The cloud as a platform is now ready for the next level, being remodeled to host critical services.

mainstream cloud-management solu-

tions tends to be limited, support-ing just the basic building blocks of adeployed service: virtual machine (VM)management, software installation and

configuration of some aspects of storage

and networking. Tasks such as securing

optimal placement of workloads, fulfill-

ment of SLAs and resource reallocationare, for the most part, still performedmanually, with limited support fromthe underlying management system.

The lack of automation is a signifi-cant barrier to developing and deliver-ing complex services ones that require

multiple resource types and need tomeet stringent QoS requirements. Toovercome this barrier, cloud manage-ment needs to be enhanced with inno-

vative technologies that automate tasks

such as reallocation of resources andload balancing. Ericssons concept ofmodel-based service definition andautomatic resolution of SLA constraints

is a step toward increased automation.

Functional architecture

The functional architecture of a cloud-management solution is illustrated in

Figure 1. The typical OSS/BSS compo-nents can be reused in the cloud mod-el as follows:

Planning

This component defines cloud services,including dimensions for price, cam-paigns, and SLA characteristics.

Fulfillment

This component creates, sets upand deploys applications and servic-es hosted by the cloud. It uses a PaaS/IaaS approach to employing platform

also in the process of evolving, moving

toward product diversification to matchindividual subscriber requirements and

tastes. To achieve individualized prod-uct offerings, a much higher degree ofautomation is needed to define products

in such a way that they do not conflictwith each other, can ensure a short time

to market, and can be assigned withappropriate Service Level Agreements(SLAs) that can be upheld withoutrequiring manual intervention froman operational center.

Cloud management

Cloud solutions have matured to thepoint of becoming an attractive optionfor hosting complex and mission-critical

systems. The OSS and BSS functionsrequired to define, allocate, superviseand monetize cloud resources, as wellas implement some of the key aspects of

the cloud (automation, self-service, andon-demand resource management) arecollectively referred to as cloud manage-

ment. This is one of the essential com-ponents of the maturing cloud model.However, the level of automation in

FRANCESCO CARUSO, CALIN CURE SCU, CHRISTIAN OLROG, JAN SLVHAMM AR AND ANDRS VAJDA

BOX A Terms and abbreviations

API application programming interface

ASM abstract service map

BSS Business Support Systems

CMDB conguration management database

CPE cloud processing equipment

EMS Extended Messaging Service

HW hardware

IaaS infrastructure as a service

OSS Operations Support Systems

PaaS platform as a service

SaaS software as a service

SDP Service Delivery Platform

SLA Service Level Agreement

SMS Short Message Service

SW software

URL uniform resource locator

VDC virtual data center

VM virtual machine

VoIP voice over IP

XaaS anything as a service

Cloud computing has come a long

way from simply being virtualdata warehousing the shapelessblob used to illustrate a networkowned by another operator ororganization, or to representunknown architecture. Todayscloud solutions manage anythingas a service (XaaS). This includesanything that an enterprise,government, organization orindividual might need to go abouttheir day. Cloud solutions houseapplications, databases, services,software, test environments,

financial platforms and back-office systems. The cloud approachbrings high accessibility throughthin clients and apps, resourcesharing, scalability and recovery all while providing economiesof scale and pay-as-you-gopricing. However, this maturityand readiness to challenge newrequirements results in a need formore stringent security demands.

As the cloud matures, the one-size-fits-all model of telecom products is

284 23-3182 | Uen

30

ERIC SSO N REVIEW 2 2012

Automating the cloud


2/5

resources (such as life-cycle manage-ment and embedded cloud functional-ity) and infrastructure resources, such

as virtualized computing, networkingand storage.

Assurance

This component supervises and, if pos-sible, automatically adjusts allocatedresources. Typical aspects of serviceassurance are monitoring, SLA enforce-ment and fault management.

Security

Due in part to the multi-tenant natureof cloud solutions, security functions inthe cloud context are more important

than they are in traditional data ware-housing. They play a vital support role in

SLA management, and mandatory secu-

rity aspects of any cloud-managementsolution include identity control, access

management, logging and monitoring,auditing and compliance.

Charging

This component implements the pay-as-you-go model of cloud computing, by

generating the corresponding charging

records for external billing systems.

Deploying complex servicesOver the past decade cloud-based offer-ings have evolved constantly, becoming

more complex and highly integrated.Today, the dependency hierarchy ofmost cloud applications and servicesis non-trivial. A cloud service may, forexample, use another mash-up, rely ona networking feature or be dependenton a web service provisioned by anoth-er vendor. Failures or delays that occurin one service can impact multipledependent services, creating situationsthat can become difficult to manage or

recover from manually.To reduce the knock-on effect of

failures in highly dependent systems,current research and development ismoving towards building platformsthat manage this complexity throughautomated creation, composition, pub-lishing, marketing, bidding, contract-ing and revenue-sharing functions.The next step in the evolution of thecloud model will support portable self-described cloud applications and servic-

es that use model-driven configuration,

interaction and management.

Telecom-grade and other regulatedservices place strong requirementson end-to-end performance and non-functional parameters, such as latency,throughput, localization, security, avail-

ability and reliability. For SaaS deploy-ments, such requirements need to betranslated into cloud-platform SLAs that

guarantee sustained and verifiable end-

to-end performance.

Models

Service Delivery Platforms (SDPs) have

been used to great advantage in com-munication services for life-cycle man-agement. These platforms generallyinclude a framework for creating ser-vices, an order/fulfillment subsystem,and an execution platform to host com-munication services. An SDP enablesproducts to be created from groups ofresources, value-added services, multi-ple configurations and billing plans. Bypicking and mixing in this way, com-munication service providers can usean SDP to define and offer services witha short time to market.

High availability, elastic scalabili-ty and provision for disaster recoveryare among the key benefits of a clouddeployment. To maximize these ben-efits, complex and QoS-sensitive appli-cations need to be specified within theservice creation environment and SLAsneed to be handled automatically at thefulfillment stage. In other words, byextending the space where services arecreated, complex applications can alsobe made scalable, available and suitablefor cloud deployment.

The Ericsson model

To create value-added services,Ericssons concept of an extended cre-ation environment for cloud services isbased on modeling the characteristics of

a virtual data center (VDC) and virtualzones. The concept models applicationsand services in terms of logical com-ponents that are available in a palette,where embedded integrity and valida-tion rules are used to guide the compo-sition of cloud services and avoid anyinvalid combinations.

Logging service

Automatedauditing

ID and access

managementChargingand billing

AnalyticsKey management

service

Cloud provider portal

IaaS APIs

Virtual and physical resource management

Virtualization layer

Computing Storage DC networking

IaaSmanagement

Service bus and cloud management API

Service-catalogand service-order

management

Activation Fault management

Performance

management

SW provisioning

and management

Cloud orchestration

CMDB

SLAmanagement

Planning Fulfillment Assurance Security

Cloud-servicemanagement

Backupmanagement

Analytics

Cloud tenant portal

Cloud-provider

planning and

management

FIGURE 1 Functional architecture of cloud management

31

ERIC SSON REVIEW 2 2012


3/5

products provide a complex end-to-

end service with dened business and

billing characteristics, such as a package

including free voice calls in the homenetwork, free SMS, and mobile data

provided at a at rate.

As shown in Figure 3, an SLA can beapplied as an additional constraint atany level. When a service component isdeployed in the cloud, a description forit is created, which includes:

basic properties an informal

description;

offering the functions that are

included, used to construct the

dependency tree;

characteristics xed properties, suchas memory or processing consumption

needs, and variable, deployment-

dependent properties such as price

or location;

conguration information needed

for service instantiation, such as

installation scripts and download URLs;

dependencies other service compo-

nents that the service being described

depends on; and

constraints that describe non-

functional requirements the SLA core.

In the Ericsson concept, SLAs can speci-

fy both traditional networking aspects,such as bandwidth and delay, as well asnon-functional aspects, such as proces-sor speed, available memory, placement

of VMs at specific locations in the net-work topology, and the cost associatedwith a certain component.

For traditional networking aspects,SLAs are defined in terms of specificdependencies, such as the geographiclocation of a given service componentor the throughput that a particular net-work component should provide. TheEricsson concept extends the SLA defini-

tion mechanism to include aggregatedconstraints. For example, a service pro-vider is more likely to be interested inthe total price of a service including itsdependencies, or the total (aggregated)reliability of a service from an end-to-end perspective, than the cost or reli-ability of its individual components. The

freedom to mix and match potentialdependencies without restraint, as long

as the aggregated SLA is fulfilled, opti-mizes the service-selection process. The

aggregation mathematical functionalso needs to be specified, which in the

One of the challenges of thisapproach is to identify the right levelof abstraction in the service-creationenvironment somewhere betweena business abstraction and a technicalspecification so that the service canbe monetized and meaningful SLAscan be defined from a user perspec-tive. For example, if a service includes

disaster recovery, this may be imple-mented through geographic replication.

However, the service users only need toknow that several levels of backup areavailable with sliding payment pack-ages; they need not be concerned withhow recovery from disaster is achieved.

The typical service model of a triple-play product enhanced with a VDC

cloud offering is shown inFigure 2. Thebasic building blocks are specificationcomponents for resources, services andproducts, which allow capabilities to bedescribed in a modular way:

resources network, storage and

computational resources are the basic

functions of the platform, they support

the execution of services and need to be

allocated quantitatively;

services represent an identied piece

of basic functionality (such as SMS) or

value-added services such as internet

access or voice; and

Internetservice

Internalprocess component identifiers

Externalprocess component identifiers

Resourceinventory

Accessselection

Resourcedispatch

CPE

ResourceEMS

ActivateINET

ActivateWi-Fi

Base station

antenna

tuning

Input from PC CPE equipment Access type

Activate internet over Wi-Fi PC Outputs

Control Invoice Cancel Cancel/

rollback

Startflow

BasestationEMS

Fixedsubscriber

EMS

Activateservice over

Wi-Fi

Success

Fail

Orderdata

ResourceVoIP provider

ProvisionVoIP

ActivateVoIP

ProvisionIPTV

ActivateIPTV

ResourceIPTV provider

VoIPservice

Product

triple play

Order for triple playVoIP with VM feature IPTV with sports package Internet gold package Activation date dd-mm-yyyy

IPTVproductExternally d iscovered

catalog specificationsVoIP product

catalog

IPTVservice

ResourceIaaS

provider

VDCservice

Cloud model

FIGURE 2 Model-based service definition

ResourceIaaS

provider

VDCservice

Cloud model

Availability

Elasticscalability

Security

FIGURE 3 SLA management

32




4/5

case of delay and pricing is addition, and

for availability is multiplication.Each service component has an

associated process component, whichgoverns its life cycle from activationthrough assurance and decommis-sioning. For example, the ExtendedMessaging Service (EMS) resource isassociated with the procedure for acti-vating internet access over Wi-Fi. Atorder time, all process components arecollected to form a service-compositionplan macro flow which includes adependency structure that specifies:when various process componentsshould be invoked; what data is definedas input to the component; and the pos-

sible set of logical operations that canoccur between components.

The SLA resolver ensures the SLAs are

upheld. At order time, the creation envi-

ronment sends the order description the top-level service dependencies andSLA aspects chosen by the consumer to the SLA resolver. Based on the avail-able service components and theircharacteristics, the resolver automat-ically creates the entire service treeand deployment plan for use by thefulfillment component.

SLA managementTo fulfill end-to-end SLAs, they must betranslated into resource-related require-

ments on the cloud infrastructure. This

is more challenging in a cloud contextthan in traditional data centers as ser-vice component characteristics vary.They may be allocated in different loca-tions, accessible over different networklinks or share infrastructure with other

applications dynamically.Manually constructing a cloud-

deployment graph that defines whichservices to use and how and where to

create the necessary VMs and networklinks is a complex and maintenance-intensive process. An automatic process

that builds the dependency tree basedon the service model and resolves SLAsinto resource parameters suitable forinstantiation would be very beneficial.Such an automated process the SLAresolver in the concept uses a resolu-tion engine to settle constraints andbuild the dependency tree. Startingwith the top-level service description,and including the SLAs agreed with theconsumers of the service, the engine

chooses the services that match thedependencies and fulfill the constraints.

The resolver algorithm is applied itera-tively to each of the dependencies andemploys backtracking when a con-straint is not fulfilled.

With a fully built resolution tree, itis possible to identify the components

needed to support a service and thengroup them into a virtual node. Theresources needed by the virtual nodeto host the allocated software stackcan also be computed automatically. Toprepare for infrastructure allocation,the resolved service-description treeis packed into an abstract service map(ASM) consisting of nodes, each with itsown software stack and network links.The ASM is handed off to the fulfillment

function, which determines the avail-able physical infrastructure, based oninformation stored in the configuration

management database (CMDB). Oncethe necessary VMs are instantiated, theprovisioning mechanism uses the VMsservice description sub-tree to deploythe software stack in the right order and

according to the configuration scriptsspecified in the service description.

Figure 4illustrates the SLA resolver.

The engine starts with the MyCinemaabstract service definition, which spec-ifies the service as an IPTV type withspecific SLAs for location, delay andavailability. Dependencies include atranscoder, a database and two provi-sioned links with specific connectivi-ty and bandwidth constraints. The SLAresolver extracts specific componentsand refines the definition by addingcomponents, such as Zencoder for thetranscoding service and MySQL for thedatabase. The aggregation constraint of

the delay is satisfied MyCinema

Servicedescriptionrepository

ZencoderOffers:Transcoding

1.8s delay

Requires:Device DB, decoding

MyCinemaOffers:IPTV

3s delay sum aggregated

99.5% availability multiply

aggregated

Location:

Requires:Transcoding

Relational DB

Link (transcodingExt) 2Gb

Link (transcodingDB) 1Gb

MySQLOffers:Relational DB

0.5s delay

Requires:Linux

NW LinkOffers:Network link

1Gb capacity

0.2s delay

Configuration:Node 1 Node 2

Link 1

Node 1

Node 2

Link 2

NW LinkOffers:Network link

2Gb capacity

0.2s delay

Configuration:Node 1 External

ContainerOffers:Linux, dual core 2GHz

DevIdDB

Offers:Device DB

Requires:Linux

HW dec COffers:Decoding

Requires:Linux, dual core 3GHz

Topology: HW dec

ContainerOffers:Linux, dual core 3GHz

Refinementb

yaddingcomponents

DevIdDB

Zencoder

Softwaredecoder X

Container

NW (1Gb)

FIGURE 4 Example of service model with SLAs

33

ERIC SSON REVIEW 2 2012


5/5

requires a three-second delay andthe sum of the delays of the dependen-cies is less (1.8 + 0.5 + 0.2 + 0.2 = 2.7). Thecorresponding ASM and mapping to the

infrastructure is shown inFigure 5.

Conclusion

Innovative mechanisms for auto-matically managing complex cloudservices and associated QoS and otherSLA requirements are needed to takethe cloud model to the next level, andbring increased automation into theunderlying architecture. Two Ericsson-developed technologies, model-basedservice definition and automatic resolu-

tion of SLAs, will help bring about auto-mation in the cloud by extending the

service-creation environment and sup-porting service providers to create non-conflicting, differentiated offeringswith short times to market and auto-matic SLA fulfillment.

Node 13GHz dual core

Node 22GHz dual core

Link 2 (2Gb)

Link 1 (1Gb)

External

GW

Resolvedrequirements

Mapping tolive data center

Search on the live data centerfor a working deployment and

configure network

FIGURE 5 Mapping of service model to the infrastructure

Francesco Caruso

is a principal cloud

architect within the Cloud

Infrastructure System

Management group at

Ericssons Business Unit Networks. He

joined Ericsson in 2012 from Telcordia

Technologies, where he was director of

the Enterprise Integration Group. He

championed the internal cloud

program to transition OSS to the cloud

environment and to extend the OSS

into the cloud-management domain.

He holds a B.Sc. in computer science

from the University of Pisa, Italy, and

has more than 15 years of expertise in

the telecom OSS domain.

Calin Curescu

is a senior researcher

with the Services and

Software department of

Ericsson Research. He

initiated the research on SLA-driven

management of cloud services, and

has worked with cloud computing,

service composition and network

exposure. He holds a Ph.D. in computer

science from Linkping University,

Sweden.

Jan Slvhammar

is product manager for

OSS products at

Ericssons Business Unit

Support Solutions, where

he has been working with various

software products for multimedia

applications and OSS. He joined

Ericsson in 1990 and has over 20 years

of product-management experience in

different areas. He has worked with

radio-network products for manyyears and holds an M.Sc. in industrial

engineering and management from

Linkping University, Sweden.

Christian Olrog

is a systems manager

and chief architect at

Business Unit Support

Solutions. He holds an

M.Sc. in physics from KTH Royal

Institute of Technology, Stockholm,

Sweden. He joined the department of

New and Special Business Operations

at Ericsson in 1999 and has been

involved in research and development

in areas ranging from wireless LAN

standardization and IP security to

embedded devices and enterprise

applications.

Andrs Vajda

is an expert in cloud

computing and cloudmanagement within

Group Function

Technology and Portfolio

Management. He joined Ericsson in

2001 working within Ericsson

Research and Business Unit Networks.

At Ericsson Research he was one of the

initiators of Ericssons cloud-research

efforts, driving the strategy and

architecture work. He holds a B.Sc. in

mathematics and computer science

and a masters in distributed

computing from Babes-Bolyai

University, Cluj-Napoca, Romania

34



er telecom grade cloud

Documents