1. Rationalizing ONAP Architecture for R2 and Beyond Vimal Begwani – AT&T

2. ONAP R2+ Architecture – Current Draft View
OSS
BSS
ONAP Portal – Design Studio & Dashboard
Design-time (SDC)
Run-time
ONAP Operations Management (OOM)
External Data Movement & APIs
Resource Onboarding
Orchestration (SO)
Inventory/Topology (AAI)
Data & Analytics (DCAE)
Policy
VNF/PNF SDK
Service Level Orchestration
Active / Available
DCAE Analytic µServices
Service & Product Design
Policy Execution Engine
Entitlements
CDAP
Holmes …
Policy Creation & Validation
Resource Level Orchestration
Resource / Service Topology
Data Distribution
ESR
Data Collection Layer
Analytic Application Design
Common
Services
DMaaP
AAF
Logging
Micro Services Bus
Catalog
Multi-VIM Interface
Open
Stack
AWS
Azure
MEC
Infrastructure
Adaption Layer
Adaption Layer
Service Logic
Interpreter
Config
Database
Yang
Netconf
CLI
Life Cycle Mgmt Func
L0-3 Network Controller (SDN-C)
3rd Party Network
controller
L4-7 Controller (App-C)
Testing & Certification
Vendor VNFM
Adaption Layer
(VF-C)
Products
Resources
Eng. Rules
Services
Policies
Analytics
Config Database
Service Logic Interpreter
Life Cycle Mgmt funcs
Life Cycle Mgmt funcs
Standard Adaption Layer
Vendor OA&M Adaptor
Vendor A
Vendor B
Chef
Netconf
Ansible
Recipe / Engineering Rules & Policy Distribution
sVNFM
sVNFM
sVNFM
Further Rationalization
Opportunities …
VNF1
VNF2
VNF3
PNF 1
VNFn
Infrastructure
OpenStack
VMware
RackSpace
Azure
Peripherals

3. Open Issues:
What is the right Orchestration Implementation in ONAP & How to provide deployment flexibility?
Rationalization of Controller Family within ONAP

4. Role Of Controllers in ONAP:
ONAP Controllers configure and maintain the health of services, networks, and functional elements throughout their lifecycle, for PNFs / VNFs
Programmable network application management platform
Behavior patterns programmed via models and policies
Manage initial and update configurations
Standards based models & protocols for multi-vendor implementation
Operational control and coordinated state changes across devices under its management
Manages the health of elements in its scope
Policy-based optimization to meet SLAs
Control loop automation as triggered by external stimulus (e.g. DCAE / Policy driven event, fault event, etc.)
Auto-healing and auto-scaling
Local source of truth
Manages inventory within its scope
All stages/states of lifecycle
Configuration audits

5. ONAP Controller Guiding Principles:
Controllers manage the state of services & network functions (VNFs / PNFs)
There could be multiple controllers to support different technology domains – e.g. L3 Networks, Optical networks, L4-7 network applications, etc.
Controller instances are intimate with domain specific protocols
However, all ONAP controllers must support one set of common north bound APIs (for ONAP modules, all controllers look and behave the same)
There should be functional parity amongst various controllers
This is a critical requirement, otherwise SO and other ONAP module has to keep track of differences between the controllers
We must leverage common controller framework, as much as possible (reduce complexity, development and maintenance cost)
All controllers have common functional modules and structure (accepting models from SDC, parsing it, north bound APIs, topology database, lifecycle management functions, etc.)
Differences are only at the VNF / PNF interface layer
Leveraging common controller framework provides tremendous advantage, much smaller total code, changes are made once and leveraged by all instances, etc.
Avoid having two controllers within ONAP supporting same technology domain (e.g. L3 Networking, Optical, IMS, etc.)
All controllers must support ONAP management standards and interfaces to deploy controller instances and lifecycle manage them

6. Leveraging Common Controller Framework
Service & Resource LCM Actions
VNFs
PNFs
Multi-VIM
Common Controller Framework
Plugins/Adapters*
M-VIM APIs
API Handler
Rebuild
VNF Configure
Network Config
Stop
Audit
Start
Scale
μSvcs APIs
Models
TOSCA engine
DGs
SLI
Service Chain
Heal
Common Control Functions
Model Parser
Policy Engine
Topology & Engineering Rules
ODL / MDSAL
* Plugins/Adapters could include Ansible, Chef, Puppet, Netconf / Yang, CLI, SNMP, standard APIs, EMS, VNFM, etc.
Personas …
Note: Common controller framework is a rich collection of libraries. Each domain specific controller can include only applicable modules.

7. ONAP Controller Rationalization Opportunities:
L4-7 Controller (App-C)
Vendor VNFM
Adaption Layer
(VF-C)
Config Database
Service Logic Interpreter
Life Cycle Mgmt funcs
Life Cycle Mgmt funcs
Standard Adaption Layer
Vendor OA&M Adaptor
Vendor A
Vendor B
Chef
Netconf
Ansible
L4-7 Generic ONAP Controller
Model Parser
API Handler
DGs
SLI
TOSCA engine
Policy Engine
Models
Topology & Engineering Rules
Common Control Functions
Rebuild
Audit
VNF Configure
Stop
Scale
Network Config
Start
Heal
Service Chain
ODL / MDSAL
Plugins/Adapters*
μSvcs APIs
M-VIM APIs
VNFs
PNFs
EMS
sVNFM
Multi-VIM
VNFs
PNFs
VNFs
PNFs
Note: Team can decide which Common controller framework library is applicable for L4-7 VNF controller.

8. Conclusions
ONAP community should create a rich library in Common Controller Framework – This offers maximum reusability and benefits are shared amongst all ONAP members
Each Domain Specific Controller should be created using applicable libraries from Common Controller Framework
However, we should avoid multiple controllers covering same domain or family of VNFs (e.g RAN, IMS, etc.)
Each Controller must follow agreed upon architecture principles:
All ONAP controllers must support one set of common north bound APIs (for ONAP modules, all controllers look and behave the same)
There should be functional parity amongst various controllers
Allow operator deployment flexibility meet their unique scalability, resiliency and geographic distribution requirements