Download - Enabling the Digital Services Marketplace with Onboarding Automation

© 2016 TM Forum | 1

A radically simplified approach to

onboarding and lifecycle

management

Enabling the Digital Services

Marketplace with Standards

© 2016 TM Forum | 2

Rise of Platforms disrupting industries

Tectonic shift from static vertical-integrationto horizontal dynamic eco-systems

To curated,

governed

Peer-2-Peer

From Central

Command

& Control

Virtualization and the Rise of the Platform Economy

© 2016 TM Forum | 3

Background image: TM Forum Frameworx, Barry Graham, TM Forum, April 7, 2016

https://www.youtube.com/watch?v=1fQESPMpkCA

Multi-Cloud

Hybrid Workloads‘Smart’

Services

Digital Service Provider Platform

Virtual Function Marketplace

SBC

IMS

EPC

CPE

DSRDPI

VF Packages are

the Unit of Work

in a Virtualized

Environment

... driving interest in Platform business models to connect partners and customers in a value-fabric

The Platform Business Model

https://www.youtube.com/watch?v=1fQESPMpkCA

© 2016 TM Forum | 4

Enabling the Digital Services Marketplace

it needs to be easy to onboard partner functions

In order for service providers to realize platform business models,

and automatetheir handling across end-to-end processes.

it needs to be easy

© 2016 TM Forum | 5

Current Situation

Sell VNF Sell Services

Value !

Use Services

Value !Value !VNF Providers Service Providers Customers

Receive New RequestsSeek New Capabilities in Marketplace

While seemingly simple, this has been extremely difficult in practice

Time

Costs

Service Providers report 6-8 weeks to onboard a single Virtual Network Function

• Increases costs

• Slows down service velocity

• Ties up resources

• Holds back Carrier Virtualization

© 2016 TM Forum | 6

Why is onboarding partner functions and automating processes so darn hard?

The Challenge

© 2016 TM Forum | 7

Vendor Onboarding

•Market place

•B2B Partnership

Procurement

•Market Intelligence

•Procurement Strategy

•Product Maturity

Capability Onboarding

•Validation

•Acceptance

•Cataloging (product, service, resource)

Offer Creation

•Composition

•Blueprinting

•Cataloguing (offering)

Use

•Service design

•Configure (service)

•Instantiate

•Inventory

Manage

•Monitor

•Update

•Upgrade

•Billing

•Usage/metrics

Retire

Migrate User

SPs Bottom Line: Business and Operations LCM

VNF Suppliers Focus: Service & Software Component LCM

Heterogeneous multi-tenant & vendor LCMs

Gaps between Operations and Technology Lifecycle Management

© 2016 TM Forum | 8

Maturity Metrics

SLA License Package Descriptors

Testing Descriptors

Metrics Descriptors

8

Vendor Onboarding

• Market place

• B2B Partnership

Procurement

• Market Intelligence

• Procurement Strategy

• Product Maturity


• Validateion

• Acceptance

• Cataloging (product, service, resource)

Offer Creation

• Composition

• Blueprinting

• Cataloguing (offering)

Use

• Service design

• Configure (service)

• Instantiate

• Inventory

Manage

• Monitor

• Update

• Upgrade

• Billing

• Usage/metrics

Retire

Migrate User

Ve

nd

or

Ha

d-o

ff

info

rma

tio

n

SP

lif

ec

yc

le

Service designer

Service component builder

Service implementer

Implementation project manager

Product manager

Service delivery manager

Partner manager

Subscriber/Enterprise

Product end user

Policy engineer

Customer care

Market Analyst/ Procurement

Product solution designer

Process engineer

sta

ke

ho

lde

rsNature of arbitrary complexity in a multi-stakeholder ecosystem

© 2016 TM Forum | 9

The Root Cause – Lack of Standards

The Telecom industry is rich with standards and Open Source projects

However, these are discrete activities, leading to siloed operations and manual integration. There is no unifying model-of-models or ‘metamodel’ that provides comprehensive metadata that facilitates automated on-boarding and end-to-end lifecycle management.

© 2016 TM Forum | 10

There is currently no standard metamodel for customer-facing services or standard way of modeling IT services.

Leading-edge telcos say this is the largest service orchestration challenge they face.

“The Composable Telco” Report, Caroline Chappell, Heavy Reading, October 2016

The Result – the missing link breaks the ecosystem value fabric

VNF Providers Service Providers

Chasm

© 2016 TM Forum | 11

Modeling Arbitrary Complexity of Virtual Functions

Need to model in 3-dimensions

1) Metadata to describe the Virtual Function;

2) Metadata to describe the Service Configurations;

3) Metadata to describe the Package DevOps

Virtual Functions are sophisticated applications.

No two VFs, even of the same ‘type’, will be designed the same or have the same requirements or operations

The Onboarding Automation/well-enabled VNF Package Catalyst is to demonstrate a radically simplified approach to

onboard and manage virtual functions/software components.

© 2016 TM Forum | 12

Catalyst Overarching Goal – Same Day Onboarding

Service providers are faced with some simple, but surprisingly hard

challenges in NFV transformation.

1) What am I getting?

2) How can I trust what I am getting?

3) How long is it going to take to generate value ?

VNF Providers Service Providers CustomersSell VNF Sell Services

Value !

Use Services

Value !

Onboarding : LESS THAN A DAY Create, Sell Services : 1 to 24 Weeks

Value !

© 2016 TM Forum | 13

Champions:

Solution Providers:

Collaboration Communities:

Catalyst Participants

© 2016 TM Forum | 14

There’s cleverExisting approaches are ‘code-first’. This is manual, development-centric custom interface work with some cool tools, but these short-cuts still result in, tightly-coupled, one-off, brittle integrations that are expensive to deploy and maintain

“Self-Operating Napkin”, Rube Goldberg, 1931

Conventional Integration

© 2016 TM Forum | 15

... and then there is smart:The demonstration will showcase a dynamic implementation that uses a standards-based template to rapidly on-board partner capabilities (no code) and then leverages the related metadata for composition, policies and orchestration

Metamodel-driven Interoperability

Suggest we talk some technical

details here i.e. TOSCA slides to

entice people go to see the demo in

action

© 2016 TM Forum | 16

The API Problem

Every Partner APIis a ‘snowflake’

1) Unique un-modeled interfaces;

2) Manually integrated per use;

3) not automatically interoperable

Note: As the number of connected elements in a solution increases it exposes the need for a common interface pattern to abstract integration complexity and support model-driven automation

© 2016 TM Forum | 17

This is not Carrier Virtualization

Manual integration does not scale

© 2016 TM Forum | 18

The Catalyst demonstrates a radically simplified approach to onboarding and lifecycle management

• A TOSCA-like engine for packaging virtual functions using a standards-based template

• A “Metamodel for a Virtual Function” that is being contributed to ZOOM by EnterpriseWeb

• A schema with mappings between industry standards (TMF OpenAPIs, OASIS TOSCA, and ETSI NFV)

• “Dynamic APIs” providing a common machine-readable pattern to abstract handling of heterogeneous interfaces

Frameworx Impacts: ZOOM, DOCF, Open APIs, DPRA, DSRA, Value-Fabric

Catalyst Objectives

© 2016 TM Forum | 19

Modeling Arbitrary Complexity of Virtual Functions

Need to model in 3-dimensions1) Metadata to describe the Virtual Function;

2) Metadata to describe the Service Configurations;

3) Metadata to describe the Package DevOps

Virtual Functions are sophisticated applications.

No two VFs, even of the same ‘type’, will be designed the same or have the same requirements or operations

© 2016 TM Forum | 20

The Application Graph

In addition, a “Package” must include models of the required middleware components, automation tools, and run-time engines (including Orchestrators and Controllers) and their behaviors

A Virtual Function has a highly-connected and

deeply-networked application topology

E Pluribus Unum

© 2016 TM Forum | 21

Carrier Virtualization starts in the Cloud

You need a Cloud-native container to organize and distribute all the artifacts

© 2016 TM Forum | 22

Package ID Maturity Metrics

SLA License Package Descriptors

Testing Descriptors

Metrics Descriptors

[body of package]

Vendor Onboarding

• Market place

• B2B Partnership

Procurement





• Validateion

• Acceptance


Offer Creation

• Composition

• Blueprinting


Use

• Service design


• Instantiate

• Inventory

Manage

• Monitor

• Update

• Upgrade

• Billing

• Usage/metrics

Retire

Migrate User

pa

ck

ag

eli

fec

yc

le

Service designer


Service implementer


Product manager


Partner manager


Product end user

Policy engineer

Customer care



Process engineer

sta

ke

ho

lde

rsScoping Metadata Requirements

© 2016 TM Forum | 23

Vendor Onboarding

• Market place

• B2B Partnership

Procurement





• Validateion

• Acceptance


Offer Creation

• Composition

• Blueprinting


Use

• Service design


• Instantiate

• Inventory

Manage

• Monitor

• Update

• Upgrade

• Billing

• Usage/metrics

Retire

Migrate User

life

cyc

le

Service designer


Service implementer


Product manager


Partner manager


Product end user

Policy engineer

Customer care



Process engineer

sta

ke

ho

lde

rs

Common Metamodel supporting Event-driven Tasks and Flows “Game of Actors”

Programmability

High-Level Abstraction

End-to-End Process Automation requires Unified Model

© 2016 TM Forum | 24

… can be used to enable the portability of cloud applications and related IT services for telecom operators. There are many telco cloud applications for TOSCA because of its utility in the configuration of NFV equipment and applications.

“TOSCA in the Telco Cloud”, SDxCentral

https://www.sdxcentral.com/nfv/definitions/tosca-cloud/

describes a

Domain Specific Language (DSL)

Topology Orchestration Specification for Cloud Applications

https://www.sdxcentral.com/nfv/definitions/tosca-cloud/

© 2016 TM Forum | 25

Summary Analysis

TOSCA Benefits

Cloud-native container for application portability

Provides generic model for packaging Cloud, IoT, NFV/SDN, Enterprise, Open Source applications

Supports DevOps automation

Promotes interoperability

Wide support and adoption

TOSCA Gaps

Generic model lacks detailed schema, requires custom types

Artifacts are not modeled limiting DevOps automation

Simple NFV profile does not cover operational concerns

TOSCA packages generally tightly coupled to Target Hosts

TOSCA packages generally tightly coupled to engines

Recommendations

Propose TMF FrameworxDescriptor (FWxD) for TOSCA

Propose custom Artifact Typesfor TOSCA

Implement Dynamic APIs contributed by EnterpriseWeb to abstract interface complexity

© 2016 TM Forum | 26

Metamodel for Virtual Function Package Overview

Metamodel for Virtual Function Package

TMF Profile (FWxD)

TOSCA Base Types

Simple NFV Profile

Custom Artifact Types

Role of Dynamic APIs

Reduce Package complexity by abstracting dozens of discrete interfaces with a consistent pattern for API

specification. It allows developers to reason over the set of APIs in a Package and across Packages

allowing the use of common methods making them easier to integrate, automate and maintain.

TMF Frameworx

OPEN APIs

Proposed TOSCA extension to so Packages can map to TMF concepts

Existing TOSCA extension that adds ETSI NFV concepts (NSD, VNFD, VNF-FG VLD, CP, etc.)

Proposed TOSCA extension to allow detailed modeling of components, tools and run-times the Virtual Function requires to run (including

orchestrators and controllers)

© 2016 TM Forum | 27

Technology Independent: Mix & Match


TMF Profile (FWxD)

TOSCA Base Types

Simple NFV Profile


Attach Model Type: YANG, YAML, MIB, BPEL, HEAT, JSON, RDF, UML (new Types can be added)

Utilize Standard Protocols: HTTP, NETCONF, RESTCONF, SNMP, SOAP (new Standards can be added)

Reference any Artifacts: BPEL, Cassandra, Mongo DB, Chef, Puppet, Python, JavaScript, RHEL, CentOS, Ubuntu (new components, tools and runtimes can be added)

Support one-or-more Target Hosts: OpenStack, VMware ESXi, Docker Containers, Servlet Containers, Bare Metal (new Virtualization Technologies can be added)

The Metamodel grows with use-cases and scope of connected elements

Nobody likes an Opinionated PaaS!

© 2016 TM Forum | 28

VF Package Metamodel for Process Automation


TMF Profile (FWxD)

TOSCA Base Types

Simple NFV Profile


TMF Frameworx

OPEN APIs

Role of Dynamic APIs

While the initial scope of the Metamodel is a minimum viable standard, the Dynamic API

pattern lends the Metamodel a ‘structure’ for extension and adaptation that supports an

iterative and agile evolution.


© 2016 TM Forum | 29

VF Package Metamodel for Change Management


TMF Profile (FWxD)

TOSCA Base Types

Simple NFV Profile


TMF Frameworx

OPEN APIs

Continuous Delivery

The approach links partner Application Lifecycle with Service Provider onboarding processes to enabling agile development practices for VF

updates, upgrades and replacements

v3v2v1


© 2016 TM Forum | 30

VF Package Metamodel for DevOps Automation


TMF Profile (FWxD)

TOSCA Base Types

Simple NFV Profile


Install/Start/

Re-install

Stop/Uninstall

Time

NFVI environmentsare volatile & VNFs

can be sensitive

Common Metamodel supporting Event-drivenTasks and Flows “Game of Actors”

scale, heal, update

DevOps Operations = TOSCA Plans

(generally as attached or generated BPEL or

HEAT files).

© 2016 TM Forum | 31

VF Package Metamodel for Network Service Configuration


TMF Profile (FWxD)

TOSCA Base Types

Simple NFV Profile


Install/Start/

Re-install

Stop/Uninstall

scale, heal, update

Time

NFVI environmentsare volatile & VNFs

can be sensitive

Customer requirementsevolve continuously

dynamically re-config

Common Metamodel supporting Event-drivenTasks and Flows “Game of Actors”

NS Configurations= TOSCA Plans

(generally as attached or generated HTTP/REST,

NETCONF/YANG, RESTCONF/YANG,

SNMP/MIB, SOAP/WSDL files).

© 2016 TM Forum | 32

Explore a structure to enable business agility and interoperability of multi-vendor solutions, allows parallel working in the industry for detailed

specification development and open source implementation.

Procurable package metadata – rough draft

Metadata Comments

Package ID • e.g. vendor id, package id, version, VF components contained within the package

Usage/Licensing • License policy descriptor• License metrics descriptor

Package Descriptor(s) • Functional APIs• Management APIs (e.g. OPNFV VES,

TM Forum APIs)• Functional topology• Management topology• Configuration

Testing Descriptor(s) • (what has been certified/conformancetested e.g. specific NFVO implementation etc.)

• Test scripts• Simulator

SLA • SLA of this package

Metrics Descriptor(s) • Descriptor of metrics supported by this package (e.g. procurement, maturity, performance etc.)

……

VNF Package Catalyst

ZOOM cross team discussion with• OASIS TOSCA• ETSI ISG NFV SOL

(TOSCA, IFA011, IFA014)

Open Source alignment to support Hybrid network scenarios

TR263: Manage NS and VNF package for automation (12/2016)

Contribution to ETSI ISG License discussion (TMF IG1143)

IG1143: VNF license management whitepaper (12/2016)

ETSI ISG NFV TSTLed by Huawei Open Lab initiative

IG1137 & IG1137A DevOps and Testing methodology , eTOM updates (12/2016)

IG1141: procurement and onboarding automation (12/2016)

Whitepaper: NFV Marketplace Enabler for Smart Cities (1Q/2017)

TR262: DPRA for Hybrid Network Management (12/2016)

TM Forum Working Teams

Zero-touchOrchestration,

Operations, Management

(ZOOM)

Catalogue Management

OpenAPIs

Digital Platform Reference

Architecture(DPRA)

Process Framework

Information Framework

Customer Experience

Mgmt (CEM)

Multi-SDO Workgroups• SLA (2012-2014)• metrics (2015-2017)

IG1146: metrics framework whitepaper (9/2016)Metrics template, meta-model and online repository for multi-SDO crowdsourcing (2Q2017)

Industry Collaborations

Alig

n a

nd

pro

vid

e in

pu

ts t

o

Mem

ber co

mp

an

ies con

tribu

te an

d d

rive ind

ustry a

lign

men

t

Flexibly connecting functions, technologies, protocols

© 2016 TM Forum | 33

Monitoring/Reporting

TOSCAEngine

Vendor

Artifact Repository

Test

Binaries,

Scripts, Etc.

SBC (VNF)

SIPp Binary

AO (VNFM)

Image

VF Marketplace

SBC (VNF)

SIPp Binary

AO (VNFM)

Image

Catalog

Definition

Portal

SBC (VNF)

SIPp Binary

AO (VNFM)

Image

Inventory

ConsumersSession Border

ControllerSIP Call

Infrastructure

AO (VNFM)

VF Package Metamodel

Execution

Digital Service

Provider

Logs

TOSCAProcessor

Orchestrator Service

Controller Service

Modeling Service

Process Service

Decision Service

Policy Service

Catalyst Demo Architecture

© 2016 TM Forum | 34

Catalyst Outputs

Working model of standards-based template-driven on-

boarding of a Virtual Function in minutes

A Metamodel that maps to TMF Open APIs, Oasis TOSCA

and ETSI NFV concepts

A flexible and sustainable solution to current on-boarding

and lifecycle management challenges

Contributed our learning to ZOOM Working Group, IG1141

© 2016 TM Forum | 35

Catalyst Learnings

Virtual Functions are the Unit-of-Work in Digital Operations Center of the Future (dOCF), they are 1st class citizens

Beyond schema, need flexible structure that supports diverse functions, technologies and protocols

Advanced tools enable shift from code-first to metamodel-driven

Service providers need to collaborate to define standard metadata

Domain skills require to solve the problem is beyond single SDO – need a structure beyond liaison to foster effective collaboration in the industry.

© 2016 TM Forum | 37

Business Scenario - Smart City NFV Ecosystem

VNF Suppliers Service Providers CustomerSell VNF Sell Services

Value !

Use Services

Value !Value !

Marketplace &

NFV Suppliers

Infrastructure

Provider

Ottawa City

These tasks

should lead to

something that

we can

demonstrate

Joint Agile Delivery/DevOps Environment

© 2016 TM Forum | 38

Monitoring/Reporting

TOSCAEngine

Vendor

Artifact Repository

Test

Binaries,

Scripts, Etc.

SBC (VNF)

SIPp Binary

AO (VNFM)

Image

VF Marketplace

SBC (VNF)

SIPp Binary

AO (VNFM)

Image

Catalog

Definition

Portal

SBC (VNF)

SIPp Binary

AO (VNFM)

Image

Inventory

ConsumersSession Border

ControllerSIP Call

Infrastructure

AO (VNFM)

VF Package Metamodel

Execution

Digital Service

Provider

Logs

TOSCAProcessor

Orchestrator Service

Controller Service

Modeling Service

Process Service

Decision Service

Policy Service

Catalyst Demo Architecture

© 2016 TM Forum | 39

Phase 2 Catalyst Architecture

VNF

Marketplace

Mockup

VNF

VNF

VNF

VNF

VNF

NFV Catalog

Mock UP in

Enterprise Web

Unified Orchestration

EnterpriseWebService

Catalog

Service

Assurance

and OSS

Service Providers BSS

Product CatalogCustomer Order Manager

NFV O

Oracle VIM

Network DevOps

IBM UrbanCode

Supplier - Oracle

VNF – “SBC” Oracle Lab Cloud

Lifecycle Governance

IBM Rational Team Concert

(Also see JAD Catalyst)

Testing Service

VNFM

Digital

Services

Marketplace

Have we

integrated

everything in the

EW slide?

© 2016 TM Forum | 40

What is Agile Network DevOps?

Accelerate

Network Service delivery –

for faster time to value

Balance speed, cost,

quality and risk –

for increased capacity to

innovate

Reduce time to customer

feedback – for improved

customer experience

Continuous Customer

Feedback &

Optimization Collaborative Network

Development

Continuous Network

Release and Deployment

Continuous

Monitoring

Continuous Network

Business Planning

Continuous Testing

through development and

deployment

Operate Develop/ Test

Deploy

Fulfillment

Design

End-to-End Service Delivery

Design

Develop

Test

Package

Validate

Accept and catalogue (onboard)

Combine

Assemble

Configure (software)

Service design

Configure (service)

Instantiate

Monitor

Update

Upgrade

Service provider

(Service Assurance)

Service provider

(Service Delivery)

Service provider

(Service Design)

VNF Supplier/

Service provider

(procurement)

VNF Supplier

© 2016 TM Forum | 44

City Call Center & Application Benefits

Tourists using Gatineau Park Apps can call the Ottawa city contact center “free” with a “Call Agent” button – avoiding roaming & international fees

Communication could be supported from “Smart” and IoT devices e.g. Information/Map, Parking meters, etc with “Call agent” button

Ottawa city can build multiple applications leveraging their contact center

Could implement Emergency services for international tourists and people without or lost/dead phones

44

© 2016 TM Forum | 45

Service Provider / Buyer

NFV Package Execution Phase

NFV Package Design Phase

NFV Market Place & NFV Suppliers

Business Scenario - Smart City NFV Ecosystem

Delivery & License/

Contract

agreement

3

On-boarding_VNF Package

Interop Testing, Integration Testing,

Acceptance Testing4

5

Vendor on-boarding

Package Design, Development,Validation,

Conformance Testing, and Trustworthiness-

methodology

1

Procurement:

Market Intelligence

Business Strategy

Supply Chaing Mgmt

2 vSBC

package

including

VNFM

Accepted SW

package

( + pre-deployment

metadata)

Well-enabled package

(+ operational metadata)

6

Ottawa City

NFV Product buying & consuming

Deploy

Prod Catalog

a) Comms Apps

b) Contact Center

7Operate

8

Ability to call city

agent from an

application / IoT

device

City selects comms application,

provides sizing requirements and

receives instructions on connectivity