Agenda Overview High Level Architecture Design time Architecture

Slides:



Advertisements
Similar presentations
© 2016 TM Forum | 1 NFV Ecosystem Enabler: A well-enabled VNF package Catalyst Theater Presentation, May 10, 2016.
Advertisements

Service Design & Onboarding
SDN-O LCM for Mercury Release Key Points and Overview
ONAP E2E Flow `.
ONAP Management Requirements
ARC: Definitions and requirements for SO/APP-C/VF-C discussion including call notes Chris Donley July 5, 2017.
Master Service Orchestrator (MSO)
ONAP and MEF LSO External API Framework Functional Reference Architecture 12 July 2017 Andy Mayer, Ph.D. © 2016 AT&T Intellectual Property. All rights.
Orchestration and Controller Architecture Alignment Vimal Begwani AT&T
Rationalizing ONAP Architecture for R2 and Beyond Vimal Begwani – AT&T
Data Collection Framework
ONAP Architecture Meeting 8/8
Enterprise vCPE September 27, 2017.
Multi-VIM/Cloud High Level Architecture
Lifecycle Service Orchestration (LSO) Models in context
Orchestration and Controller Alignment for ONAP Release 1
ONAP Architecture Slides Current Plan of Record
ONAP Multi-VIM/Cloud Long Term Architecture and Use Cases (Under Community Discussion across Use Case, Optimization Framework, OOM,
CLAMP Flows for vCPE Use Case in ONAP R1 Ron Shacham AT&T
Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs.
Defining ONAP VNF Package Model
Multi-VIM/Cloud High Level Architecture
Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs.
Rationalizing ONAP Architecture for R2 and Beyond
Interface to External Controllers and SD-WAN Use Case
ONAP Interface to External Controllers
ARC: Definitions and requirements for SO/APP-C/VF-C discussion Chris Donley Date , 2017.
OPEN-O Modeling Directions (DRAFT 0)
ARC 5: Deployment Options Chris Donley
MEF LSO Legato SDK 24 October 2017 Andy Mayer, Ph.D. Tara Cummings.
Target ONAP End-to-End Architecture Vimal Begwani – AT&T Parviz Yegani – Futurewei Technologies Jamil Chawki – Orange.
ONAP Integration to External Domain Management Systems (DMS)
Multi-VIM/Cloud High Level Architecture
Enterprise vCPE use case requirement
ONAP Run-time Catalog Project
Target ONAP End-to-End Architecture Tiger Team Presentation Parviz Yegani – Futurewei Technologies Contributors: Vimal Begwani (AT&T), Jamil Chawki.
ONAP Amsterdam Architecture
Centralize Image Management for ONAP
ONAP – Centralised Parser Distribution Atul Purohit - Vodafone
Enhanced Platform Awareness (EPA) Alex Vul Intel Corporation
VF-C R2 Feature Planning & Implementation Yan Yang
Agenda Where we are (Amsterdam Architecture)
ONAP APIs Andrew Mayer, AT&T
Usecase 1 – Upgrade Image
SDNC Roadmap Dan Timoney – AT&T Marcus Williams - Intel
Open Source Access Manager™ ONAP Proposal
ONAP Amsterdam Architecture
ONAP Integration Through Information and Data Modeling
Casablanca Platform Enhancements to Support 5G Use Case (Network Deployment, Slicing, Network Optimization and Automation Framework) 5G Use Case Team.
Casablanca Platform Enhancements to Support 5G Use Case Architecture Review 5G Use Case Team June 26, 2018.
Documenting ONAP components (functional)
Multi-VIM/Cloud High Level Architecture
Casablanca Platform Enhancements to Support 5G Use Case Summary of Planned Enhancement Areas 5G Use Case Team June 14, 2018.
FUNCTIONAL Architecture for R2+
ONAP Beijing Architecture Chris Donley 1/9/18
Defining ONAP VNF Package Model
ONAP Architecture for Rel 1
ONAP 5G USE CASE ENHANCEMENTS FOR PNF DEPLOYMENTS
Casablanca Platform Enhancements to Support 5G Use Case (Network Deployment, Slicing, Network Optimization and Automation Framework) 5G Use Case Team.
Technical Capabilities
5G Use Case Configuration & PNF SW Upgrade using NETCONF ONAP DDF, Jan 9, 2019 Ericsson.
E2E Process Automation Alexis, Andreas, Bin, Catherine, Franck, Scott, Susana, Timo TSC-53 December,
ONAP Optimization Framework (OOF) POC for Physical CellID (PCI) Optimization August 21, 2018.
GNFC Architecture and Interfaces
ONAP Optimization Framework (OOF) POC for Physical CellID (PCI) Optimization July 30, 2018.
ONAP Architecture Overview Template
ONAP Architecture Principle Review
Proposed Approach for ONAP Runtime Support of Network Service Onboarding Gil Bullard, AT&T.
Common NFVI Telco Taskforce Paris Face-To-Face Sessions Compliance & Verification Heather, Kirksey LFN Rabi Abdel, Vodafone Group; July 2019.
Title: Robust ONAP Platform Controller for LCM in a Distributed Edge Environment (In Progress) Source: ONAP Architecture Task Force on Edge Automation.
Presentation transcript:

Agenda Overview High Level Architecture Design time Architecture Run time Architecture Summary

Outline Overview High Level Architecture Design Component Architecture Run-Time Component Architecture Summary

Open ECOMP and Open-O Merger into ONAP harmonized architecture

Overview High Level Architecture Design Component Architecture Run-Time Component Architecture Summary

ONAP Architecture Overview Northbound E-Services BSS/OSS Big Data Three Main Groups Design Deploy Operate DESIGN RUN-TIME Application Controller Service Design and Create Policy Design Closed Loop Design Active and Available Inventory Data Collection, Analytics and Events Policy Engine Network Controller Service Orchestrator Southbound Cloud Infrastructure 3rd Party Controller VNFM/EMS

Overview High Level Architecture Design Main Component Architecture Run-Time Main Component Architecture Summary

ONAP Service Development life cycle 2 Design ONAP Service Development life cycle Endpoint Policies Workflow VNF VNF VNF Endpoint Endpoint 1 Onboarding VNF Workflow Policies VNF VNF Debug and re-design Operations 6 Distribution 5 \ Packaging 4 Testing 3 ISSUE New tooling to fast design and onboard new services & resources Accelerate, simplify & reduce cost to onboard new service designs & resources 1 –The onboarding of VNF Descriptors (models) and associated artifacts (SW images, Documentation, Templates). Our onboarding automates the process and provide a scheme for capturing operational requirements and knowledge from experts via interactive wizards including OS support, VNF component makeup and dependencies, VM CPU size and other general or hypervisor specific platform requirements, network, security, non-functional requirements. Importing of externally provided information (e.g. VNF images or details contained in standard based files formats). Formats like Yang or TOSCA while the standards bodies still mature are generally vendor specific at this time, the import capability can be customized to support these by the addition of an adaptor that provides any bespoke translation. This stage automatically generate an initial resource definition for next stage( design of service) Will reduce integration effort per VNF   2- Visual Design of Service - a graphical environment to define services based on these VNFs including policies, thresholds, deployment process models and factors to be used in their operation. Within the same graphical environment user can combine VNFs into more complex virtual services together with classical resources associated with the physical network. Palettes of re-usable elements, graphical canvas for drag ‘n’ drop assembly of a network service definitions. Customizable support for different scenarios: Service level design templates: vCPE, vEPC, vIMS etc. VNF design templates: multi-VM, multi-component, load-balanced etc. Great simplification and validation of design. 3- Testing – ( maybe debugging is better name) lets you take a definition and use the NFVO component to step through the planning function and see the outcomes of any policies that have been configured. It allows you to view and interact with fixed or derived parameters at each step to make adjustments to any issues in the definition logic, these changes can then be reconciled in the original definition after you have finished debugging. Debugging applies equally at a Service or VNF level within the definition so that individual parts of a service can be debugged in isolation of the others if required. 4- Packaging - Publishing of the predefined and tested services to a catalogue such that they can be offered to the fulfilment process. Significant benefit of using our NCSO is that service design was tested via target system (NCSO) right on design stage. 5 - Distribution of essential artifacts and information such as software images, policy definitions, model definitions, performance thresholds, etc. to key consuming systems –NFV Orchestrators, catalogues, VIM, assurance etc. This process today mainly manual – we targeting to automate distribution – i.e. significantly reduce time and cost of handover from design stage to service build/ fulfillment stage. VNF Managers, SDN Controllers and the VIM itself have their own metadata requirements. This metadata is partial derived but linked to the service and resource definitions used by the orchestrator. The SDC component can build artefacts or other metadata from the service and resource definition model and any associated extensions, store and version these within its registry. EP VNF Policies / Workflow EP VNF Self Service Portal Debug and re-design Service Orchestrator READY ISSUE Policies / Workflow Active & Available Inventory

ONAP SDC Architecture Overview Project Management Portal 3rd Party Vendor Tester DevOps Developers GUI SDC VNF SDK Design Managed Objects Design Managed Functions Resource Onboard & Design Service Design VNF (Product) Design Policy (Rules) Design Process (BPMN) Design Analytics (Event-Driven) Design Certification Studio (ICE) Distribution Studio Content Mgmt & Distribution Testing & Certification Design Studio Reference Data Catalog Repositories Resource Model Product Model Product Model Product Model Product Model Product Model Service Model

Overview High Level Architecture Design Main Component Architecture Run-Time Main Component Architecture Main Process and Flows

ONAP MSO (SO) Architecture and Interfaces Overview OCX/OMX Infrastructure Portal SDC CSI REST REST MSO API Handler Interfaces SDC Distribution of orchestration artifacts UEB event notifications, HTTP artifact retrieval AAI Query and update inventory RESTful API Multi-VIM Instantiation of virtual resources in the cloud Openstack APIs (primarily Heat and Keystone) SDN Controller Assign and configure network resources Yang-based RPC and REST App Controller Assign and configure application resources Yang and/or event based API Request Handlers REST Service Recipes BPEL Execution Engine Data Stores Service Recipe AAI Catalog DB Request DB Service Recipe REST HEAT Templates SOAP Resource/Controller Adapters VNF Resource Adapter Network Adapter Controller Adapter KEYSTONE/ HEAT REST Cloud Platform Orchestrator SDN Controller APP Controller

ONAP SDN-C Architecture and Interfaces Overview DG Builder Directed Graph Files – XML (Eng Rules) Network Data Model Files – YANG (i.e. IPAG EMT) Service Data Model Files - YANG (i.e.UNI port) DMaaP Message Router Security Applications Control Loop Applications Service Orchestrators API (REST) API (REST) API (REST) Service-related Artifacts for SLI, API Handlers, Network Adpaters SDN-C API Handlers API (REST) External API calls Service Logic Interpreter A&AI OpenDaylight SDN-C Database REST Inventory Service Logic/Eng Rules Assigned Resource Inventory Config Tree Operational Tree Network Adapters OpenStack Adapter VOIP VNF Adapter VRR Smart Adapter Support CLI/NetConf/BGP vCE/vPE Smart Adapter BGPCEP Adapter Etc.

ONAP APP-C Architecture Overview Infrastructure Portal Designer App-C MSO Configuration Management Control Loop Actions Restart Rebuild Migrate Suspend / Destroy Other Components APP-C UEB DG Compiler API Service & Config Repository Service Abstraction Layer YANG/SLI Model Driven Services DCAE Adapters A&AI A&AI Adapter PO Adapter NETCONF Adapter VNF / APP Adapter … UEB Adapter VNF AIC PO VNF App2 App1

ONAP A&AI Architecture Overview Central registry to create a global view of inventory and network topology Receives updates from various inventory Provides standard APIs

ONAP DCAE Architecture Overview Data Collection, Analytics, and Events (DCAE) subsystem gathers performance, usage, and configuration data from the managed environment This data is then fed to various analytic applications, and if anomalies or significant events are detected The primary functions of the DCAE subsystem are to Collect, ingest, transform and store data as necessary for analysis Provide a framework for development of analytics

Overview High Level Architecture Design Main Component Architecture Run-Time Main Component Architecture Summary

ONAP Service Lifecycle Management DESIGN ORCHESTRATE OPERATE PRODUCT CATALOG DESIGN—ONBOARDING CONTINUOUS REAL-TIME FULFILMENT REAL TIME OPERATION OFFLINE IN LAB REAL-TIME IN PRODUCTION HYBRID CLOUD

Design Flow – VNF and Service Design Enrich model with monitoring, management dependencies etc. Create VF and Service designs Manually test models in lab Deploy to product servers 3 4 5 6 Build topology from vendor info (HEAT or manual) On board Design Test Deploy 2 Technology Specialist Service Designers and Operations Model vendor license Asset Manager 1 Testers Operations Develop Deliver Quarantine Supplier Security and malware scanning Partners