Rationalizing ONAP Architecture for R 2 and Beyond
Rationalizing ONAP Architecture for R 2 and Beyond Vimal Begwani – AT&T
ONAP R 2+ Architecture – Current Draft View VNF/PNF SDK Design-time (SDC) Resource Onboarding Service & Product Design Policy Creation & Validation Testing & Certification Analytic Application Design Catalog Products Services Resources Policies Eng. Rules Analytics Recipe / Engineering Rules & Policy Distribution Further Rationalization Opportunities ONAP Operations Management (OOM) Run-time External Data Movement & APIs Orchestration (SO) Inventory/Topology (AAI) Ø Service Level Orchestration Active / Available Entitlements Ø Resource Level Orchestration Resource / Service Topology ESR Common Services DMaa. P Multi-VIM Interface Infrastructure Adaption Layer Open Stack AAF Logging AWS Azure MEC Data & Analytics (DCAE) Policy DCAE Analytic µServices Policy Execution Engine … Holmes CDAP Data Distribution Data Collection Layer Micro Services Bus L 0 -3 Network Controller (SDN-C) L 4 -7 Controller (App-C) Config Service Logic Life Cycle Database Interpreter Mgmt Func Config Service Logic Life Cycle Database Interpreter Mgmt funcs Adaption Layer Netconf rd Network Yang CLI 3 Party controller Standard Adaption Layer Chef Netconf Ansible Vendor OA&M Adaptor Vendor VNFM Adaption Layer (VF-C) Life Cycle Mgmt funcs Vendor A B s. VNFM VNF 1 Infrastructure 2 BSS ONAP Portal – Design Studio & Dashboard VNF 2 Open. Stack VNF 3 VMware PNF 1 Rack. Space … Azure VNFn Peripherals
Open Issues: § What is the right Orchestration Implementation in ONAP & How to provide deployment flexibility? § Rationalization of Controller Family within ONAP 3
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 4
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. L 3 Networks, Optical networks, L 4 -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. L 3 Networking, Optical, IMS, etc. ) • All controllers must support ONAP management standards and interfaces to deploy controller instances and lifecycle manage them 5
Leveraging Common Controller Framework Service & Resource LCM Actions Common Controller Framework API Handler SLI Policy Engine TOSCA engine Models DGs Model Parser Common Control Functions VNF Configure Audit Rebuild Scale Network Config Stop Topology & Engineering Rules Start Heal Service Chain ODL / MDSAL Plugins/Adapters* VNFs μSvcs APIs PNFs M-VIM APIs Multi-VIM * 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. 6
ONAP Controller Rationalization Opportunities: L 4 -7 Controller (App-C) Config Service Logic Life Cycle Database Interpreter Mgmt funcs Standard Adaption Layer Chef Netconf Ansible Vendor OA&M Adaptor Vendor VNFM Adaption Layer (VF-C) Life Cycle Mgmt funcs Vendor A Vendor B L 4 -7 Generic ONAP Controller API Handler SLI TOSCA engine Policy Engine Models DGs Model Parser Common Control Functions VNF Configure Audit Rebuild Scale Network Config Stop Topology & Engineering Rules Start Heal Service Chain ODL / MDSAL μSvcs APIs Plugins/Adapters* VNFs PNFs EMS VNFs PNFs s. VNFM VNFs M-VIM APIs Multi-VIM PNFs Note: Team can decide which Common controller framework library is applicable for L 4 -7 VNF controller. 7
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 8
- Slides: 8