OPEN-O O-Common Project Proposal - PowerPoint Presentation

Slide1

OPEN-O O-Common Project Proposal

Version 0.

3

Draft – For Review

Arthur Berezin

Slide2

Overview

Project Name

‘

O-Common

’

Re

pository name [

tbd by TSC/LF ‘o

-common

’

?]

Project Description:

O-Common provides shared components for designing, modeling, validating, executing and storage of VNFs, Network Services(NS) and Service Function Chaining(SFC) and related resources

needed for GS-O, NFV-O and SDN-O.

Participants:

GigaSpaces, ZTE, others?

Slide3

Project DescriptionArchitecture is micro-services style.

RESTful APIs between components.

GS-O, NFV-O and SDNO consume RESTful APIs for functionality

O-Common will have several sub-projects, includes following modules as part of phase 1 :

TOSCA Parser and execution engine(ARIA) with OpenStack VIM Plugin and NETCONF Plugin(phase1)

Workflow Engine (ARIA)

Graphical Modeling Designer

Catalog

Inventory

Slide4

Common (TOSCA)

Common Service

Micro-Service

Bus

Auth.

Log

Workflow

Catalog

SDN-O

SDN Res.

Mgr.

Abstract NBI

Abstract SBI

NFV-O

NFV Res. Mgr.

NFV Monitor

Model Designer

NS Lifecycle Mgr.

Abstract NBI

Abstract SBI

GUI Portal

TOOLs

Foreman

…

Ansible

GS-O

Service Decomposer

Service Lifecycle Mgr.

Abstract NBI

VPN

SDN Lifecycle Mgr.

Traffic Optimize

SDN

Monitor

Runtime engine

Common

Parser

Compass

Protocol Stack

HA

Driver

ACCESS/WAN SDN Controller Drivers

EMS/NMS Drivers

Driver

VNFM Drivers

VIM Drivers

NFV SDN

Controller Drivers

GUI Portal

GUI Portal

Service layer

Inventory

O-Common Architecture Alignment

Slide5

Resources

Contact person - Arthur Berezin

Arthur

@GigaSpaces.com

Committers

of

the project

Lior Mizrahi -

lior@gigaspaces.comTal Liron - tal@gigaspaces.com

Denys Makogon Denys@GigaSpaces.com

Meng Zhaoxing meng.zhaoxing1@zte.com.cnZhao Huabing

zhao.huabing@zte.com.cn ..?

Slide6

Project Scope and modules

TOSCA Parser and Execution Engine with OpenStack VIM Driver and NETCONF Driver

Workflow Engine

Model Des

igner

Catalogue

Inventory

Slide7

TOSCA Parser and ExecutionProblem being solved

GS-O,NFVO and SDN-O Orchestrator are required to onboard VNFs using

descriptive

and

standard

modeling language.

Language ought to be able to natively model VIM resources and to be able to support native network configuration models

Language ought to be as robust as object oriented:

Normative, Extendible, Abstractable, and Composable

Slide8

TOSCA Parser and ExecutionProject Scope

TOSCA

natively supports modeling of

VIM virtual resources

and allows integrating YANG models for native network device configuration.

RESTful service to parse and validate TOSCA YAML Templates, and execute workflows based on the orchestration graph(Install, Uninstall, custom)

Phase 1 includes OpenStack VIM plugin for VNF Modeling and YANG plugin for network device modeling.

Slide9

TOSCA (topology Orchestration Spec for Cloud Application )

Types, Nodes and Interfaces

Inputs and Outputs

Requirements and Capabilities

Workflows and Policies

openstack.compute

DNS

aria.compute

vRounter

(+YANG)

vmware.server

vFirewall

Hosted on

Network(Neutron)

Network(+YANG)

Slide10

TOSCA Composition for SFC

vRouter

Blueprint

vDNS Service

Blueprint

vFirewall

Blueprint

http://getcloudify.org/2015/10/13/nfv-vnf-network-topology-architecture-automation-tosca-service-chaining-orchestration.ht

Slide11

TOSCA Service

TOSCA Orchestration Library

IaaS APIs

SDN APIs

Container APIs

Custom APIs

gVNFM(Juju/etc’)

Pluggable Node Types (SBI)

NBI

VNF Service

TOSCA(+YANG)

RESTful API (NBI)

sVNFM

(Hua

wei/ZTE/..)

Slide12

DSL Parser

Workflows

Lifecycle Workflows

Install, Uninstall

Custom Workflows

ARIA Execution Engine

IaaS Plugins

Conf. mgmt Plugins

Container Plugins

SDN Plugins

Custom Plugins

TOSCA

YAML DSL

OpenStack

VMWare

AWSAzure

Puppet

Chef

AnsibleSaltStack

Docker

Kubernetes

NETFONF/YANGOpenDaylight

VNF/Service

TOSCA(+YANG)

Phase 1

Phase 2

Slide13

Gaps and Roadmap

Support for SCAR.

The TOSCA SPEC is a moving target, need to align with latest reversion.

Work with OASIS to standardize workflows, then alight project according to SPEC.

Slide14

Common TOSCA Orchestration

Parser & Engine Library

(ASF)

TOSCA

Defines and Refines TOSCA SPEC

OPEN-O

Consumes ARIA library

for TOSCA orchestration

ARIA

Defined Spec

Use Cases

Slide15

Project Scope and modules

TOSCA Parser and Execution Engine

VIM Drivers and NETCONF Drivers

Workflow Engine

Model Des

igner

Catalogue

Inventory

Slide16

Problem being Solved

The Model Designer is a Web-based GUI environment to design service templates and plans for lifecycle management of the services.

Slide17

Model Designer Scope

Create service template

NS/VL/VNF

SFC(VNFFG)

Create Plan(lcm workflow)

Import

CSAR package into designer

Export template as CSAR package

Deploy template to Catalog

Slide18

Model Designer Architecture

Slide19

External Interface of Model Designer

Model Designer

Catalog

Common Parser

②rest

①rest

Interface Description:

① Save CSAR Package to Catalog

② Parser Tosca YAML File

Slide20

Modules

Workflow

Common Parser

Runtime Engine

Model Designer

Catalog

Inventory

Slide21

Problem being Solved

The Catalog includes NFV Service Catalog and VNF Catalog.

The NFV Service Catalog is the repository of all of the

Network

Services, supporting the management of the NS deployment templates (NSD, VLD, and VNFFGD).

The VNF Catalog is the repository of all of

the VNF

Packages, supporting the management of the VNF deployment templates (VNFD and Artifacts). Both NFVO and VNFM can query the VNF Catalog for finding and retrieving a VNFD, to support different operations (e.g. validation, checking instantiation feasibility).

The Catalog also provide artifacts download function.

Slide22

Catalog Scope

CSAR upload, download, delete, query, status management.

Provide REST API interface to query information model.

Provide artifacts download(software pkg. , image, scripts, policy, plan, etc

.).

Support layered/nested Service template

A (nested) NS can be referenced in other NS

–Release 1

A abstract NS model expose standard capabilities to high layer, and the implementation can be any vendors

– Future Release

Slide23

Layered and Nested NS Model

NS1

VNF1

NS 2

NS2 is referenced by NS1 as a nested NS.

The Nested Ns in the example can also be a nested

VNF

– Release 1

VNF2

NS2

VNF3

VNF4

VNF5

reference

NS1

VNF1

VNF2

VNF3

VNF2(Abstract Type)

reference

VNF2 (Vendor1)

VNF2(Vendor1)

VNF2(…..)

Could VNF2 be an abstract type and have multiple implementation by different vendors? –need to work with modeling project/architecture

committee(Not in Release 1)

Choose appreciate concrete VNF according to policy(location, availability , cost, latency, etc.) when deployment

Slide24

Catalog Architecture

Process Model

TOSCA XML Parser

TOSCA YAML Parser

ETSI-NFV

YANG Parser

TOSCA-NFV YAML Parser

Model

Repository

APIs

File

Repository

APIs

NFV Service Package

VNF Package

…

Common

Parser

APIs

APIs

Process Files

Package Download URL

Image URL

Package

Parser

Upload

Http Server

Database

Storage

Storage

Support

NFV Service Descriptor Restful Interface

VNF Descriptor Restful Interface

Support

Slide25

External Interfaces of Catalog

Catalog

Model Designer

Common Parser

GS-O/SDN-O/NFV-O

1

4

2

REST API

Common Service

3

Slide26

Interfaces Description

1 Deploy CSAR package.

2 Parse information model.

3 Service registration, Auth, logs.

4 Query NFV descriptor or download artifacts(scripts, plan, policy, etc).

Slide27

Upload CSAR Package to

Catalog

Catalog

Parser

1 Upload CSAR Package

2

Validate &

un

compress package

(

Signature, Meta-info, etc.

)

3

Parse service

template

4

Validate service template

5 S

tore model in the model repository

6

S

tore artifacts in the file repository

(Package, image, scripts, plan, etc.)

Slide28

Catalog

Interaction with GSO/NFVO/SDNO

Catalog

GSO

SDNO

NFVO

1

4

2

VNFM

Portal/BSS

5

3

6

7

Portal/BSS send an E2E service request to GSO

GSO get the E2E NSD from catalog

GSO

decompose the E2E NSD to WAN VL and domain NS, then send the request to SDNO and NFVO respectively

SDN get VLD from Catalog(yang with TOSCA), then call SDNC driver to create the VL

NFVO get Domain NSD from Catalog, then decompose the NSD to VLs and VNFs

NFVO call VNFM Driver SBI to create the VNF

VNFM get VNF Package from Catalog

Model

Repository

File

Repository

Slide29

ETSI NFV Model

Slide30

Modules

Workflow

Common Parser

Runtime Engine

Model Designer

Catalog

Inventory

Slide31

Problem being Solved

The requirement of centralized management and maintenance resources, services and their relationships.

Provide a global resource view for GS-O, NFV-O, SDN-O.

Dynamic extension resource properties

Slide32

Inventory Scope

Provide resources centralized storage function

Support schemaless data stores for easily model evolution

Provide CURD(create, update, read, delete) REST interface for GS-O/SDN-O/NFV-O to manage the resource instance. Like NS, VNF, VL, VDU etc.

Maintain the relationship of resource instance

Support subscription the resources change notification