ONAP Beijing Architecture Chris Donley 1918 ONAP Target
ONAP Beijing Architecture Chris Donley 1/9/18
ONAP Target Architecture for R 2 and Beyond (High-Level Functional View) VNF / PNF Onboarding Resource Onboarding Service Design U-UI Data Collection, Analytics, and Events Event Correlation Active & Available Inventory External Registry Orchestration Policy Creation & Validation Analytic Application Design ONAP Portal RUN-TIME Dashboard OA&M Policy Framework CLI Micro Services Bus / Data Movement (see Note 1) Closed Loop Design Change Management Design Test & Certification Generic NF Controllers (L 4 -L 7) Multi-Cloud Adaptation SDN Controller (L 0 -L 3) Network Function Layer ONAP Optimization Framework Hypervisor / OS Layer Open. Stack Note 1 – Consistent APIs between Orchestration layer and Controllers 2 Private Edge Cloud Specific VNF Manager Public Cloud Commercial VIM Private DC Cloud Element Management System … VNFs MPLS Logging Others (see Note 1) Optional External Systems 3 rd Party Controller Recipe/Eng Rules & Policy Distribution Application Authorization Framework ONAP Common Optimization Services Framework Life Cycle Management & Config (see Note 1) Catalog Common Services IP Public Cloud PNFs Managed Environment DESIGN-TIME OSS / BSS ONAP External APIs ONAP Operations Manager External Gateway Draft
New projects to be added following TSC approval ARC review: Jan 5, TSC approval: Feb 15 3 VNF Validation Program VNF Requirements Modeling (Utilities) (High-Level View with Projects) 1/5 Integration ONAP Beijing Architecture
Recommendations for Beijing Release • Release Theme is Platform Maturity/S 3 P • Architecture Principles highlight Modular, Microservices, Model-driven • Modular: - Improve APIs between components. Document them using Swagger to improve alignment between components - Align interfaces with industry standards, where available/appropriate (e. g. , ETSI SOL-003 SOL-005, MEF Interlude, Legato, etc. ) • Microservices-based - Use OOM for onboarding, instantiation (support MSB natively), scalability, ISSU (for R 3) - Register with MSB - Use microservices best practices (e. g. , separate data from the component, use common KV stores/databases, for KV stores – prefer Consul, etc. ) • Model-driven - Align with info/data models from the Modeling Subcommittee (published last month) - Explore ways to use model-driven principles inside each component as well as across various components (SDC, SO, VFC, APPC, . . ) • S 3 P - Use common libraries/SDKs/common services for S 3 P enhancements to improve overall system resiliency/reliability More focus on common services (where possible) also to help reduce testing MUSIC for managing various ONAP components states, DB replication in a consistent manner Enhanced AAF to support credential management for certificates Support Image Management service to enhance security, virus checking, etc.
Suggestions for Casablanca (in progress) 1. External APIs: External actors view ONAP as a black box. This should simplify the ONAP architecture/interfaces, leveraging the APIs developed by the Ext API project (eg, MEF LSO, TM Forum etc). 2. Explore Database harmonization: Reduce number of databases in ONAP – perhaps one per type? (SQL/no. SQL/KV store/etc). a. Support for DB as a service, rather than independent DB per component? 3. API Improvements: Currently, ONAP internal interactions are mostly handled via RESTlike APIs. We need to enhance the ONAP architecture to support RESTFUL APIs. We also need to ensure that the ONAP platform can handle cloud-native APIs and models. 4. API Versioning Support 5. Support for Identity Management in SDC 6. Support for Security Management. 7. Support for Beijing->Casablanca upgrade. In-service upgrades per component? 8. Geo-redundancy – move from real-time (strong) consistency to eventual consistency model 9. Multi-tenancy support 5
- Slides: 5