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

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

3. Where We Are (Amsterdam)

4. 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

5. 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

6. Where We’re Going (Target Architecture)

7. Architecture Design Considerations
Architecture Principles:
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

8. 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

9. 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)

10. How We’ll Get There (Beijing)

11. 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.

12. 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

13. 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+