end-to-end cloudification of mobile telecomsportugal.chapters.comsoc.org/files/2016/01/... ·...

End-to-End Cloudification of Mobile Telecoms

The MCN Consortium

Presenter: Andy Edmonds (@dizz), ZHAW

© 2012-2015 MCN. All rights reserved. /

Goals of MCN Architecture

Modularity, reusability

Creation of composed (end-to-end) services

Adhere to the NIST cloud computing definition

Enable cloudification of services e.g. EPC

keep functional arch, adapt software arch

Common framework and lifecycle to design services that

accommodates all identified scenarios

No technology specific dependencies

Leverage & influence suitable/relevant standards to ensure interoperability and integration


MCN Key Principles

Service-Oriented Principles Autonomous: The logic governed by a service resides within

an explicit boundary. The service has control within this boundary, and is not tightly coupled to execute.

Share a formal contract: In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange.

Loosely coupled: Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. Services abstract underlying logic, which is invisible to the outside world, beyond what is expressed in the service contract metadata.


MCN Key Principles

Service-Oriented Principles Composable: Services may compose others, allowing logic to

be represented at different levels of granularity. This allows for reusability and the creation of service abstraction layers and/or platforms.

Reusable: Whether immediate reuse opportunities exist, services are designed to support potential reuse.

Stateless: Services should be designed to maximise statelessness even if that means deferring state management elsewhere.

Discoverable: Services should allow their descriptions to be discovered and understood by (possibly) humans and service requestors that may be able to make use of their logic.


MCN Key Principles

Cloud Native Services

• Leverages cloud-platform services for reliable, scalable infrastructure.

• Non-blocking asynchronous communication in a loosely coupled architecture.

• Monitors and manages application logs even as nodes come and go.

• Scales horizontally, adding resources as demand increases and releasing resources as

demand decreases.

• Scales automatically using proactive and reactive actions.

• Cost-optimizes to run efficiently, not wasting resources.

• Handles scaling events without downtime or user experience degradation.

• Handles transient failures without user experience degradation.

• Handles node failures without downtime.

• Upgrades without downtime.

• Uses geographical distribution to minimize network latency.


Terminology

Service

E.g. CDNaaS

Service Instance

E.g. EPC service instance

Service Instance Components (SIC)

E.g. MME or DSS cache

Resources (Physical/Virtual) build services


MCN Service Categories


Lifecycle of a MCN Service


MCN Key Arch Elements

Service Manager

Provides an external interface to the user

Business dimension: encodes agreements

Technical dimension: Management Service Orchestrators of a particular tenant

Service Orchestrator

Oversees (E2E) orchestration of a service instance

Domain specific component

Manages service instance

'Runtime & Management' step of the Service Lifecycle

One SO is instantiated per each tenant within the domain

SO is associated with a Service Manager

Monitors application specific metrics and scales (SOE/SOD)

CloudController

Supports the deployment, provisioning, and disposal of services

Access to atomic services

Access to support services

Configures atomic services (IaaS)


Service Manager Internals

• Main entry point so

service management

for EEU

• Overall management

of SM’s SO’s

• Maintains list of

services offered by

SM


Service Orchestrator Internals

• enforces decisions

towards the CC

• interacts with CC

entities

• Graph of required

services and

resources for service

instance


CloudController Internals


MCN Key Arch Elements Overview

support or MCN

All are used throughout MCN


MCN Services and Arch Elements


Beyond MCN

How does this fit to State of the Art?


MCN and NFV Mapping


MCN and NFV Mapping

Approximate Mapping

CloudController

Service

Orchestrator

i.e.

Openstack

Service Instances

STG, ITG

Service Manager


MCN and NFV Mapping

MCN Arch Entity NFV Entity

Service Instance Virtual Network Function (NVF)

Service Instance Component NVF component

Service Orchestrator VNF Manager, ETSI-NFV orchestrator

Service Manager No entity The service manager provides a north bound interface enabling EEU self-service

CloudController No entity The CloudController abstracts from underlying atomic services. ETSI-NFV Virtualized Infrastructure Manager would sit below

No direct architectural mapping. Maps technically to OpenStack or CloudSigma

Virtualized Infrastructure Manager

SO Bundle Service, VNF and infrastructure description


MCN NFV Scope & Applicable NFV Use Cases

Use Case #1: Network Functions Virtualisation Infrastructure as a

Service

Use Case #2: Virtual Network Function as a Service (VNFaaS)

Use Case #3: Virtual Network Platform as a Service (VNPaaS)

• Use Case #4: VNF Forwarding Graphs

Use Case #5: Virtualisation of Mobile Core Network and IMS

Use Case #6: Virtualisation of Mobile base station

• Use Case #7: Virtualisation of the Home Environment

Use Case #8: Virtualisation of CDNs (vCDN)

• Use Case #9: Fixed Access Network Functions Virtualisation


MCN and TMForum Mapping

MCN Lifecycle inspired and aligned to TMForum Application framework (TAM) / eTOM

Business Service

Manager

Deploy, Provision Runtime Management

MCN also deals

with:

• Design

• Implementation

• Disposal


MCN and TMForum Mapping

TMForum Application framework (TAM) / eTOM

Business Service Manager

Technical Service Manager


CloudController

Support Services

● SLAaaS

● MaaS (CMMS)

● RCBaaS

Atomic Services


How is an E2E MCN Service Instance

Created?

Scenario

4 service providers (C1-C4)

3 services orchestrated - RAN,

Core, CDN

1 value added E2E service

offered to the enterprise end

user

Both public and private cloud

resources

Scenario Assumption

Service designed and

implemented



Created?

EEU requests a service

instance

Providers, Services and

CloudControllers


How is an E2E MCN Service Instance Created?

Deployment phase

Service managers

inside each service

provider



Created?

Deployment phase


created to oversee

instance creation



Created?

Deployment phase


requests necessary

services creation



Created?

Deployment phase

Each required service

provider’s service

manager creates a

service orchestrator



Created?

Deployment phase

Service orchestrators

that require services

from the

CloudController

requests them



Created?

Where are we?

Deployment phase is completed

Eventually all services are created

Not configured however

Provisioning phase begins…



Created?

Provision phase

The SO has access to

all other service

instance management

endpoints

Configuration

information is supplied

to these



Created?

Provision phase

Service orchestrators

may pass on

configuration to

CloudController



Created?

Where are we? Ready for service

Deployment & provisioning phase completed

Service instance management interfaces are available to the

EEU

EUU can use & further customise the service instance

degree of configurability is dependent on service provider

SO of all service instances manage runtime

SOD & SOE


Key Enabling Framework Technologies

Service Manager

Python, Pyssf, OCCI


Python, Pyssf, OCCI

Cloud Controller

OpenShift, OpenStack, Pyssf, OCCI


Upcoming

Architectural Refinement

Based on software development

Software to be released as open

source

Apache 2.0

Submission as NFV prototype to ETSI

Thank You!

Backup

© 2012-2015 MCN. All rights reserved. / Page 38

Federation


EGI FedCloud

Fed & Interop Challenge!


A Solution? EGI FedCloud

Fed & Interop Implemented!


Cloud & Services

• Cloud service categories – IaaS, PaaS & SaaS

• Deployed – Public, private

– Both considered for the MCN Arch


Cloud & MCN

● Cloud-defined (NIST)

○ On-Demand, Self-Service

○ Resource Pooling

○ Broad Network Access

○ Rapid Elasticity

○ Measured Service / Pay-As-You-Go


From...

● System is contained to local resources

● Scaling is limited by local resources

○ Difficult beyond - requires rearchitecting

● Many existing systems are built like this


To...

● System is not contained to local resources

● Scaling is adding as many resources/nodes that are

available

● Elasticity enabled grow and shrink as needed

● Existing systems are not built for this

● Requires additional orchestration and management


Services are made up of Resources

• Resource: Any physical or virtual component of limited availability within a computer or information management system. – Physical Resource: Any one element of hardware, software

or data that is part of a larger system. – Virtual Resource: A virtual computer resource is a

temporal partitioned fraction of any physical resource of limited availability within a computer or information management system.


How to Architect Services?

• Service-Oriented Principles – Autonomous: The logic governed by a service resides within an

explicit boundary. The service has control within this boundary, and is not tightly coupled to execute.

– Share a formal contract: In order for services to interact, they need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange.

– Loosely coupled: Dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. Services abstract underlying logic, which is invisible to the outside world, beyond what is expressed in the service contract metadata.


How to Architect Services?

• Service-Oriented Principles – Composable: Services may compose others, allowing logic to be

represented at different levels of granularity. This allows for reusability and the creation of service abstraction layers and/or platforms.

– Reusable: Whether immediate reuse opportunities exist, services are designed to support potential reuse.

– Stateless: Services should be designed to maximise statelessness even if that means deferring state management elsewhere.

– Discoverable: Services should allow their descriptions to be discovered and understood by (possibly) humans and service requestors that may be able to make use of their logic.


Cloud Native Services

• Leverages cloud-platform services for reliable, scalable infrastructure.

• Non-blocking asynchronous communication in a loosely coupled architecture.

• Monitors and manages application logs even as nodes come and go.

• Scales horizontally, adding resources as demand increases and releasing resources as

demand decreases.

• Scales automatically using proactive and reactive actions.

• Cost-optimizes to run efficiently, not wasting resources.

• Handles scaling events without downtime or user experience degradation.

• Handles transient failures without user experience degradation.

• Handles node failures without downtime.

• Upgrades without downtime.

• Uses geographical distribution to minimize network latency.


Business Phase

Design: This is the phase where the service is

conceptualised, the services that cannot be supplied by the

organisation are sourced from other organisations, and

requirements upon the external services to be combined

are collected and studied.

Agreement: Here items such as Pricing, Service Level

Agreement (SLA), Access, etc., are agreed between two or

more organisations. The agreements are generally bilateral

business ones.


MCN Service Lifecycle: Technical

• Design of the service

architecture

• Implementation of the

designed solution

• Deployment of the

implemented solution &

elements

• Activation of the service

such that the user can

actually use it.

• Activities such as scaling,

reconfiguration of Service

Instance Components

(SICs)

• Destroy service instances

or SIC(s)


Technical Phase

Design: Design of the architecture, implementation, deployment, provisioning

and operation solutions. Supports Service Owner to "design" their service


Technical Phase

Implementation: of the designed architecture, functions, interfaces, controllers,

APIs, etc.


Technical Phase

Deployment: Deployment of the implemented elements, e.g. DCs, cloud,

controllers, etc. Provide anything such that the service can be used, but don't

provide access to the service.


Technical Phase

Provisioning: Provisioning of the service environment (e.g. NFs, interfaces,

network, etc.). Activation of the service such that the user can actually use it.


Technical Phase

Operation and Run-Time Management: in

this stage the service instance is ready and

running. Activities such as scaling,

reconfiguration of Service Instance

Components (SICs) are carried out here.


Technical Phase

Disposal: Release of SICs and the service

instance itself is carried out here.


Service Manager

EEU or requesting SO

submits a request for

a service instance

(direct, UI or CLI)


Service Manager

contains a list of the

available services

offered by the

provider

Contains a list of the

available services

offered by the

provider


Service Manager

deploys the SO

bundle to the CC


Service Manager

provisioning of the

service instance incl.

all SICs


Service Manager

Tracks all provisioned

SOs (service

instance)

Also contains info on

all mgt interfaces


Service Manager

Deletes the complete

service instance



All requests by SM to

SO goes through here



Takes decisions on

the run-time

management of the

SICs (e.g. based on

monitoring data)



Responsible for

enforcing the

decisions towards the

CC



What services are

required to support

the SO

implementation.

How they’re

configured.

Model defined by CC



What services are

required to support

the SO

implementation.

How they’re

configured

Diff - live information

from CC


CloudController

Provides a Frontend

and exposes an API

which can be used to

interface with the CC.


CloudController

Allows the listing of

capabilities which the

CC offers


CloudController

Will enable the

deployment of the SO

and its individual SIC


CloudController

Will enable the

configuration of the

SIC


CloudController

Takes care of runtime

operations such as

scaling requests


CloudController

will support the

disposal of each SIC


CloudController

Interface with other

Services, requested

by higher layers


How to Bring All These Together?

Use Support

Services

Cloud Controller

MCN Service

Instance N

Service Manager

(B+T)

Cloud Controller

MCN Service

Instance M

Cloud Controller

MCN Service

Instance K

SO SO

Service Manager

(B+T)

Service Manager

(B+T)

SO

Multiple e2e tenant services:

Tenant 1 - MCN Composed Service, Tenant 2 (MCN Composed Service), Tenant 3 MCN

Service, ....

SICs SICs SICs

Drop this

slide



Sequence diagram in D2.2

Drop this

slide


MCN and NFV Mapping

This is an approximate mapping

Update image

Orch covered only by half


Colors and Halftone Values


The information in this document is provided "as is", and no guarantee or warranty is given that the information

is fit for any particular purpose. The above referenced consortium members shall have no liability for damages

of any kind including without limitation direct, special, indirect, or consequential damages that may result from

the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2012 -

2015 by MCN Consortium.

© 2012-2015 MCN. All Rights Reserved



Use Support

Services

Cloud Controller

MCN Service

Instance N

Service Manager

(B+T)

Cloud Controller

MCN Service

Instance M

Cloud Controller

MCN Service

Instance K

SO SO

Service Manager

(B+T)

Service Manager

(B+T)

SO

Multiple e2e tenant services:

Tenant 1 - MCN Composed Service, Tenant 2 (MCN Composed Service), Tenant 3 MCN

Service, ....

SICs SICs SICs

end-to-end cloudification of mobile telecomsportugal.chapters.comsoc.org/files/2016/01/... ·...

Documents