ONAP Beijing Architecture Review & Discussion Santa Clara Developer Meeting Chris Donley

Agenda Where we are (Amsterdam Architecture) Where we’re going (Long-term Target) How we get there (Beijing Architecture)

Where We Are (Amsterdam)

ONAP Amsterdam Architecture ONAP Operations Manager (OOM) Portal Framework, U-UI, ONAP CLI Dashboard OA&M (VID) RUN-TIME External API Framework DESIGN-TIME (SDC) Resource Onboarding Policy Framework DCAE Correlation Engine (Holmes) Service Orchestration A&AI/ESR Service & Product Design Policy Creation & Validation Common Services DMaaP CCSDK Logging Micro Services Bus (MSB) AAF VNF SDK CLAMP Multi-VIM/Cloud Infrastructure Adaptation Layer SDN-C (L0-L3 Controller) Application Controller (L4-L7) Virtual Function Controller (ETSI-aligned) Key points: Unified framework for design-time & run-time Common platform for service design and netops to drive collaboration Simultaneous orchestration of physical and virtual networks Vendor-agnostic orchestration can only happen in open source context Real-time analytics and closed-loop automation Easy re-use of service concepts Iterative service improvements based on network feedback Catalog External Systems 3rd Party Controller sVNFM EMS Managed Environment … Network Function Layer VNFs PNFs … Recipe/Eng Rules & Policy Distribution Hypervisor / OS Layer OpenStack Commercial VIM Public Cloud MPLS IP Private Edge Cloud Private DC Cloud Public Cloud

Amsterdam Status The Amsterdam release was designed to unify seed code from OpenECOMP and OPEN-O (plus a few new projects) Based on the ONAP Charter and discussions last spring Minimized changes to allow on-time delivery Identified several open issues: Controller/orchestration layer alignment Better alignment between APP-C and VF-C Cloud-native, model-driven, microservices vision Platform maturity

Where We’re Going (Target Architecture)

Architecture Design Considerations Architecture Principles: https://wiki.onap.org/display/DW/Contributions?preview=/8225716/8232492/Architectural%20principles_v3.docx ONAP Target Goal is: Modular, Model-driven, Microservices-based architecture Models drive interfaces between layers/components Agree to unified modeling for integration across all modules: VES in DCAE, Logging & monitor inside ONAP and more ONAP is a layered architecture – Orchestration, Multi-Cloud, Controller, etc. Functional role of each layer should be well defined ONAP should support integrated design studio to capture full lifecycle management models ONAP Should Support Cloud Agnostic Model and Multi-Cloud adaption layer while hiding infrastructure details ONAP should define well-described and consistent NB-APIs at all layers Keep flexible capability for commercial solution (no vendor lock-in) ARC charterted “tiger team” to develop long-term target

ONAP Target Architecture for R2 and Beyond (High-Level Functional View) Draft External Gateway OSS / BSS CLI U-UI ONAP Portal ONAP External APIs DESIGN-TIME Dashboard OA&M RUN-TIME Common Services Resource Onboarding Data Collection, Analytics, and Events Event Correlation Common Services Policy Framework Active & Available Inventory External Registry Orchestration Service Design Application Authorization Framework Policy Creation & Validation ONAP Operations Manager Analytic Application Design Micro Services Bus / Data Movement (see Note 1) ONAP Optimization Framework VNF / PNF Onboarding Closed Loop Design Generic NF Controllers (L4-L7) Change Management Design Logging Multi-Cloud Adaptation SDN Controller (L0-L3) Design Test & Certification Life Cycle Management & Config Others Functional view, not project view. Long-term, think of each function as one or more microservices. Interconnection driven by modeling, recipes, not code. Make if flexible to add new components in the future. (see Note 1) (see Note 1) Catalog Optional External Systems 3rd Party Controller Specific VNF Manager Element Management System … Network Function Layer Managed Environment Recipe/Eng Rules & Policy Distribution ONAP Optimization Framework VNFs PNFs Hypervisor / OS Layer OpenStack Commercial VIM Public Cloud Note 1 – Consistent APIs between Orchestration layer and Controllers Public Cloud Private Edge Cloud DC Cloud IP MPLS

Future Considerations Functions as microservices Recursive/hierarchical functions East-west (federation) vs. north-south (delegation) Common & consistent information/data models Platform improvements Storage, logging, parsers, etc. HA and platform resiliency features Security enhancements (e.g., certificate/secret storage)

How We’ll Get There (Beijing)

Process Beijing architecture starts with the Amsterdam (1.0.0) version The theme of the release is “platform maturity”.  Beijing architecture changes must improve S3P metrics. HA/Resiliency features Common services (storage, logging, parsers, etc.) Incremental progress towards the target architecture. Team identifying steps to take us from current state to future state. Beijing release will make a down payment, balancing current resources, new features, and platform maturity priorities.

ONAP Beijing Architecture (High-Level View with Projects) Draft 12/8 Modeling (Utilities) Integration VNF Requirements VNF Validation Program New projects to be added following TSC approval ARC review: Jan 5, TSC approval: Feb 15

Next Steps Tiger Team will provide recommendation to ARC by 1/5 Meeting with key PTLs (this week) TSC approval of new projects (this week) ARC will also discuss/refine platform capabilities through M1 See SW architecture session later today Please provide feedback through ARC calls (Tuesdays) ARC to present Beijing architecture for TSC approval by 2/8 (M2) Locked down, with only minor editing after M1 (1/18) After M2, ARC will focus on Casablanca+