an introduction to onap - netsia · simple virtual firewall “demo” entire lifecycle through 40+...

5G & NETWORK TRANSFORMATION

CONFERENCE

An Introduction to ONAPAmar Kapadia

© 2017 Aarna Networks, Inc.

My Introduction

● Author of “Understanding OPNFV”, “ONAP Demystified”

● NFV specialist with background in OpenStack, Ceph,

dataplane acceleration technologies

● Co-founder Aarna Networks, Inc.

● Previously at Mirantis, Seagate, Emulex, Philips, HP

● MS EE from University of California, Berkeley


Aarna and Argela Partnership

● Aarna Networks provides the

only LF-approved ONAP

training courses

● Aarna and Argela are strategic

partners around ONAP


What is ONAP

OPEN NETWORK AUTOMATION PLATFORM:

Comprehensive platform for real-time, policy-driven

orchestration and automation of physical and virtual network

functions. 100% open source, part of Linux Foundation.

Born Mar/2017


Who is Behind ONAP

Operators represent

60+% of mobile users

worldwide

AT&T ECOMP + Linux Foundation Open-O merger in

Q2’2017

100% open source, part of Linux Foundation


Why ONAP?

High levels of agility for 5G and MEC will

require a sophisticated automation tool

such as ONAP


ONAP in the NFV Architecture Context

NFVI Hardware servers, storage, switches

NFVI Software Virtual compute, storage, networking, dataplane acceleration

VNFs

EMSs NFVO

VNFMs/

PNFMs

VIM

Global

DC

OSS / BSS / E-

Services / Big Data

SDN Controller

Modified ETSI NFV Architecture


ONAP Scope

Design

Framework

Runtime

Framework

ETSI NFVO,

VNFM, PNFM

Monitoring

and Service

Assurance


ONAP & Other Software Systems

*ONAP supports sVNFM, but eliminates external policy engine or EMS✝Fault, configuration, accounting, performance, security

ONAP

NFVI/VIM/SDN Controller

OSS/BSS/Big Data/E-Services

Exte

rna

l m

od

ule

s &

art

ifa

cts

(e

.g. V

NF

pa

cka

ge

s, a

na

lytic

ap

ps, sV

NF

M,

EM

S)


ONAP Architectural Principles

Model

Driven

Cloud

NativeDevOps

Automated without hard-

coding

Built for the cloud and to

manage cloud native VNFs

Built using CI/CD

manage VNFs using CI/CD


Additional Architectural Considerations

● Pluggable modules

● Centralized design studio

● Policy driven

● Real-time

● Self-service (users, operators)

● Multi-tenant

● Secure

● Closed loop (and open loop) automation

● Alignment with standards e.g. ETSI, MEF,

TMForum


A Day in the Life of ONAP

1

Vendor provided VNF

(cloud-hosted,

optimized or native)

2

Vendor packages VNF as

per ONAP requirements;

can use VNF SDK

3 4

5

BSS system triggers

service deployment

6

Service lifecycle

management

7

Designers create products,

services, recipes

Design/test teams

onboard VNFs

VNF

Vendor

Design

Run-

Time

Closed

Loop Constant monitoring

& service assurance

PNFs need to be

packaged as well


Design-time

SDC

CLAMP

Run-time

ONAP Beijing Release

Controllers

External Data Movement & APIs

Common Service

DCAE

Inte

gra

tio

n

SDN-C APP-C

CLI

Mo

de

ling

Be

nch

mark

Holmes

Use Case UI Portal Framework

OF

ONAP Operations

Manager

Portal/API

A&AI

VN

F V

alid

ation

Multi

Cloud

OA&M

Dashboard

(VID)SO

VN

F R

equ

ire

me

nts

Supporting

Projects

VN

F S

DK

Policy

MSB/DMaaP

VF-C

Logging

AAF

CCSDK

MUSIC

Docu

me

nta

tio

n


ONAP Design Time Environment Operations

Onboard VNFs Create Services Create Recipes Onboard Functions

- Create license model

- Onboard VNF

- Test VNF

- Store VNF in catalog

- Create service/product

- Test service

- Store in catalog

- Approve

- Distribute

- Create policies

- Create workflows

- Create closed loop flows

- Create change mgmt

- Onboard collectors

- Onboard analytics apps

- Onboard microservices

- Onboard datastores

if high_load scale_out

backup:

quiesce

snapshot

restart service

geo-repl snapshot

Service Design & Creation (SDC) & Closed Loop Automation Management

Platform (CLAMP) : Graphical, Guided, Extensible, Role-based


ONAP Run Time Environment

Service LCM Monitoring & Service Assurance

Service Orchestrator (SO): TOSCA /Heat descriptors for network

service + config parameters + workflow

SDN Controller

(SDN-C)

APP-C or VF-C

gVNFM/sVNFM interfaceMultiCloud

API or GUI API or GUI

Data Collection Analytics and

Events (DCAE)

(Collectors, data stores,

microservices, analytic apps)

DCAE controller

(Cloudify)

Active & Available Inventory

(A&AI) graph from

subscriber → network

service → VNFs → virtual

infrastructure → physical

infrastructure


ONAP VNF Onboarding Projects

VNF

Requirements

VNF

SDK

VNF Validation

Document used by VNF designers to

create the VNF and associated

artifacts (VNF-D, Yang models, CI/CD

tests, VES etc.)

Tool used by VNF designers to create

the TOSCA based VNF package

Tool that validates a VNF and provides

an ONAP compatible label

APP-C

(Heat), VF-

C

(TOSCA)?


ONAP Beijing Release

*From onap.biterg.io 11/27/17 to 5/16/18

2nd Release

June 2018

286 ↑ 452 Authors

9.6K ↑ 14.8K

Commits


What’s New in Beijing?

● NB Interface alignment with standards

● S3P○ Stability

○ Security

○ Scalability

○ Performance

● Change Management○ One case: in-place update

● Scaling○ One case: manual trigger

● DCAE containerized for OOM

● New initiatives: MUSIC, benchmarking,

CDT


Use Cases in Beijing Release

vFW: Virtual Firewall/

vDNS: Virtual DNS

vCPE: Virtual Customer

Premise EquipmentVoLTE: Voice over LTE


vFW

● Simple virtual firewall “demo”

● Entire lifecycle through 40+ steps:○ VNF Onboarding

○ Service, policy creation

○ Service, policy distribution

○ Service deployment

○ Traffic generation

○ Closed loop automation

● Useful to see how ONAP works and

perform validation on a deployment


vCPE

● Residential gateway split between

Bridged Residential Gateway (on-prem)

and virtual Gateway (cloud-based)

● All open source VNFs○ Several optimized for FD.io/VPP

○ Use gVNFM

● Six network services created

● Steps:○ ESR, VNF onboarding, hardware platform

awareness (HPA) policies, service creation,

instantiation, monitoring, closed-loop

automation, in-place upgrade, termination


VoLTE

● vEPC + vIMS complex service

● Proprietary VNFs with sVNFMs○ vEPC: ZTE/Huawei

○ vIMS: Huawei/Nokia

○ sVNFM/EMS: Huawei/ZTE/Nokia

○ PE: Huawei (not virtualized)

○ DC/WAN/SPTN controller: ZTE

● Steps:○ VNF onboarding, vEPC/vIMS service

design, underlay/overlay VPN template

import, VoLTE service design, closed-

loop automation (with Holmes), manually

triggered scaling, termination; via Use

case UI


ONAP Getting Involved

● Start with ONAP wiki

● Join the community (free)

● Read about project(s)

● Join mailing list, calls

● Read about developing on

ONAP, download tools

● Or Read about integrating

with ONAP

● Attend events

● Start with ONAP wiki

● Join the community (free)

● Read about project(s)

● Join mailing list, calls

● Deploy ONAP

● Try vFW, vCPE use cases

● Deploy PoC with all artifacts

and interfaces developed

● Attend events

Developer User


Open Source Alternatives to ONAP

Open Source MANO (OSM)

● Under ETSI

● NFVO/VNFM/Design focus

● Extensible via ecosystem S/W

● 5th release

● 5G, MEC focus

● Led by Telefonica

OpenBaton

● ETSI compliant MANO

● SDKs for integrating with VIM,

sVNFMs

● Extensible/customizable

● Powered by Fraunhofer Fokus

● Part of 5G Berlin


Joint Argela-Aarna ONAP Training

● Private ONAP training can

be scheduled any time at

your site

● Public ONAP training

planned for Q1’19 at

Argela 5G Center of

Excellence in Ankara

Questions?

[email protected]

@akapadia_usa

mailto:[email protected]

an introduction to onap - netsia · simple virtual firewall “demo” entire lifecycle through 40+...

Documents