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

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

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

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

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

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.

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.

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