1. Open Network Automation Platform (ONAP) Business Objectives & Architecture Principles

2. Contributors: Vimal Begwani (AT&T) Dean Bragg (AT&T) Lingi Deng (CMCC)
Christopher Donley (Huawei)
Rajesh Gadiyar (Intel)
Xiaojun Xie (ChinaTelecom)
Alla Goldner (Amdocs)
Ranny Haiby (Nokia)
Jason Hunt (IBM)
Roberto Kung (Orange)
Xinhui Li (VMW)
Dhananjay Pavgi (TechMahindra)
Phil Robb (LF)
David Sauvageau (Bell Canada)
Stephen Terrill (Ericsson)

3. Proposed ONAP Architecture Principles
Support Complete Life Cycle Management of Software Defined Network Functions / Services
From VNF On-Boarding, Service Definition, VNF/Service Instantiation, Monitoring, Upgrade, to retirement
High Level of Automation at Every Phase of Life Cycle Management – e.g. Onboard, Design, Deployment, Instantiation, Upgrade, Monitoring, Management, to end of life cycle:
Rich, User Friendly Design Studio to Capture Full Life Cycle Management (Recipes, Policy, Analytics, etc.)
Common Approach to Manage Various Network Functions from Different Vendors
Standard templates for instantiations
Standard language for configuration
Standard Telemetry for monitoring and management
ONAP Platform is NF / Services / Product Agnostic (each service provider / integrator to use ONAP to manage their specific environment with artifacts created via Design Studio)
Standard Interfaces for Integrating with External OSS / BSS / VNFM/ EMS systems
Standard interfaces / abstraction layer to support multiple infrastructure and network controllers
Maintain ONAP Platform Integrity while Evolving it to Target End State Vision
Maintain Platform Backward Compatibility with Every New Release
Roberto to send further suggestion on item 2.1.

4. BACKUP SLIDE

5. Business Imperatives / Goals:
Define a Design and Operational Management Framework for Next Generation Real- Time Software Defined Networks / Services with the Following Business Objectives:
Support Real-Time Programmable Network / Services
Support Self-Service Environment to On-Board & Define New Functions / Services / Products, avoiding long development cycle
Minimize OpEx / CapEx via Automation
Where Possible, enable Virtualize Network Functions to Run on Commodity Hardware
Platform Must Also Support other Hardware Configurations, such as Peripherals or Appliances
Zero Touch Instantiation / Modification / Termination of Software Defined Functions / Services
Analytics / Policy Driven Closed Loop Automation
Define Management Standards to Support Plug-n-Play Software Defined Functions (VNFs) from Any Vendor
NF Requirements / Packaging Standards
Support Standard Interfaces for Integrating with External OSS / BSS / VNFM/ EMS systems
Platform Must be deployment ready and meet Service Providers’ S3P (Security, Scalability, Stability, Performance) requirements
Support Highly Secure Network / Services
Open Platform that is programable to Various Service Providers and Integrator’s environments
Comments from Stephen
1, intelligent network terms might causes confusion with ITU
2, on-boarding definition clarification needed in VNF Guidelines or other documentation, might have different meaning in different circumstances, e.g. for VNF, Service, and Products.
3, rewording of item 3
4, clarifications on standard OSS/BSS interfaces, TMF etc. (Roberto)
Comments from Roberto
1, clarification on Commodity Hardware, including accelerators, or other hardware
2, to be adaptable with other systems not ONAP compatible through an adaption layer
Comments from Xinhui
1, change adaptable into programable in the last item
Chris
1, S3P