ONAP Dublin Architecture Requirements Stephen Terrill et al
ONAP Dublin Architecture Requirements Stephen Terrill, et al.
Input • Material input is the Dublin Architecture F 2 F meeting (Montreal) and subsequent discussions. • More information is available here: https: //wiki. onap. org/display/DW/ONAP+Dublin+Release+Architecture +Requirements 2
Service Mesh – Using K 8 s and ISTIO as infrastructure for ONAP • Leverage Kubernetes. - https: //jira. onap. org/browse/ONAPARC-281 • Dublin Scope: - Use native K 8 S facilities (IPVS) for service load balancing. - Use K 8 S Network policies for RBAC (At the service granularity, not at the HTTP protocol level) - Prove few application services using ISTIO citadel using nodeagent and create guideline document - POCs with the ISTIO/Envoy community to reduce the memory footprint of Envoy proxy. - Secure communication (refer to ONAP security sub-committee) • Direction: • use of ISTIO, tightly integrated via ENVOY, as a “REFERENCE”. • Po. C during Dublin timeframe, using in Dublin if ready • Back end integration to AAF. • AAF/CADI direction still supported 3
Fine-grained Placement Service (F-GPS) • Ambition: Support fine-grained placement - https: //jira. onap. org/browse/ONAPARC-383 • Dublin Focus: - Support fine-grained placement in a specific Distributed DC/Availability zone proximal to a group of users for latency sensitive workloads • Details: https: //wiki. onap. org/pages/viewpage. action? page. Id=45306809 • Presentation: https: //wiki. onap. org/pages/viewpage. action? page. Id=45304353 - Leverage capacity alerts (significant change in capacity) from Model-driven Distributed Analytics work • End-to-end use cases: - 5 G 4
K 8 s Cloud region support (1/2) • Continue the journey of support for contain based VNFs. - https: //jira. onap. org/browse/ONAPARC-282 • SDC to support K 8 S Helm charts as artifacts in VNF CSAR • SDC to support multiple cloud technology artifacts in one VNF CSAR. - Note: This is the case where the same VNF executable can run in different cloud environments. • VNF SDK to support the validation of VFND based on Helm changes and also a VNFD supporting multiple cloud technologies • VNF Requirements to describe requirements on a VNFD CSAR • SO to be made independent of Cloud technology • SO to pass user. Params of 'create. VNF' NB API to Multi-Cloud. • CLI and VID to take user. Params as input from the user • Testing SO ability to bypass assignment functionality in SDNC • Ensure (fix any gaps) needed to put information of containers in A&AI such as IP address assigned to it, VNF instance ID returned by Multi-Cloud. 5
K 8 s Cloud region support (122) • Multi-Cloud - SDC Client for artifact distribution. Helm based implementation Upgrade functionality (Change management) [Stretch] Finish R 3 functionality (OVF, Helm, VNF environments etc. . ) • Testing to Ensure that current closed loop (with v. Firewall) works endto-end. • Testing to Ensuring that change management functionality continues to work. 6
Modularity (1/2) • Definitions - Module: Implements a business capability accessed through a defined set of APIs • E. g. A DCAE Data Collector microservice, A&AI data repository - Component: A collection of modules that are related in some form • E. g. SO, Controllers, A&AI, etc - ONAP: A collection of ONAP Components - Microservice: Small, single-capability focused, standalone services E. g. IP address assignment, Tosca parser - Cloud-Native: Container-packaged, dynamically managed, microservicesoriented applications • E. g. Containerized microservices managed by Kubernetes - Service Mesh: Connective tissue between microservices • E. g. traffic control, resiliency, security, observability Control plane (Istio, linked) and Data plane (Envoy, linkerd) Note: This is different from service chaining 7
Modularity (2/2) • Start small. Start with SO and Controllers. • SO: - API handler Request DB BPMN Infra SDC controller Catalog Adapters for the controllers (SDNC/VFC/…) and Cloud Adapter Proposal: Discussion with projects • Controllers: - IP assignment - Tosca Parser 8
ETSI Alignment • VNFM plug-in to SO: SO ETSI Stds i/f - SO, SOL 003 plug-in - SDC, indicate of whether to use VNFM - A&AI: VNF/VF Instance <-> VNFM instance • Other scenarios proposed, more work to do. (not sufficient arch discussions yet) - SOL 005 between SO and ETSI defined NFVO - Exposing SOL 005 NBI from ONAP - ONAP connection of VNF through SOL 002 SOL 003 ETSI defined VNFM SO SOL 005 ONAP ETSI defined NFVO ONAP SOL 002 VNF 9
Joint Arch // Modelling issues • Modelling a Allotted network function - An allotted network function is a network function where part of its capability is allocated to a service. - A number of steps are defined over a few release, starting with the VNFs. • NSD modelling - Does the NSD have to be explicitly modelled or can it use the ONAP defined services. - Note: There is agreement that we need a way to represent a NSD somehow. • Support of SOL 001 v 2. 5. 1 • Orchestration Scenarios - What are the driving network scenarios for ETSI-ONAP alignment. Ongoing. 10
Architectural Support for 5 G use cases • Covered in 5 G Use Case work. • Retained as a placeholder for deepdives if required. 11
General • Increase / Evolve the Architecture documentation • Architecture evolution roadmap 12
TOSCA Task Force • There is a Tosca Task Force with the following objectives: - Establish TOSCA as the "normative", supplier/operator neutral way to package and describe (model) network service and functions in ONAP. - Enable template reuse and orchestration outcome consistency across ONAP related on-boarding, design, instantiation and operation activities. - Identify TOSCA adoption barriers/gaps and recommend closure actions. Priority Requirement 1 Support for ETSI NFV SOL 001 specification v 2. 5. 1 templates 1 Support for TOSCA Simple YAML Profile v 1. 2 and v 1. 3 2 Support for multiple flavors/versions of TOSCA VNFD templates 2 Support for multiple versions of TOSCA language/grammar 3 A "registry" approach for configurable and modifiable properties 3 Preservation of original on-boarded template semantics and content 13
Reviewed usecases and projects • Reviewed and OK: - Broadband Service (BBS) - 5 G use cases (at Arch F 2 F) - CDI (composible desagretated infrasrtructure) • Still requires further re-review - ONAP data lake - OSAM 14
Contacts Topic Contact Service Mesh Mike Elliot, Srini Addepali Model driven (or distributed at edge) Analytics Srini Addepali, ramki krishnan Fine-Graned Placement Service ramki Krishnan K 8 s cloud region support Srini Addepali Modularity Vmial Begwani, John Ng, Seshu Kumar ETSI Alignment (SO plug-in) Ciaran Murphy, byung. woo Jun, Fred Oliverira (overall orchestration scenarios) VFC team for VFC enhancements Tosca Task force Alex Vul Alloted Network Function Gill Bullard 15
Dist Analytics Problem Statement & Solution Direction • Problem Statement: - Management Workloads • Currently, Multiple Orchestrators for Management Workloads (SDC, SO, OOF etc. ) • ONAP Central Management • Analytics Central/Distributed Management – OOM – DCAE (ONAP, SP internal, Third Party) • There is an opportunity to get some alignment across multiple orchestrators which will be greatly beneficial especially in Distributed Edge environment - Managed Workloads • Fully Support for containerized network functions (work in progress) • Support for non-network functions (VM and Container based), e. g. v. Probe, Automation Apps • Solution Direction: - Management Workload: • Align on a single orchestrator solution for all management workloads - Managed Workload: • Enhance SDC, SO, A&AI, MC etc. to support containerized functions • Leverage ONAP for deploying and managing non-network functions - Longer-term: Explore feasibility for orchestration alignment between managed workload and management workload 16
Dist Analitics: R 4 Dublin Scope Towards a Solution Direction • Prove through Po. C that various types of managed workload packages can be uploaded, life cycle management flow designed, deployment can be supported (using SDC/SO/OOF/MC-K 8 S-plugin path via helm charts) - Various types of workloads include • Network functions - v. Firewall (Proposed as part of K 8 S based Cloud region support) • Non-network functions - Edge. XFoundry (Proposed as part of K 8 S based Cloud region support) • Distributed Functions - Analytics (Proposed as Distributed Analytics-as-a-Service use case) • Work on common items independent of Orchestrators - Creation of Helm Charts for Analytics Framework - Creation of docker containers for Analytics Framework - Microservice for Analytics Normalization to ONAP format • OOM Health check enhancements for ONAP Components 17
Dist Analytics: Post R 4 Work Items & Meetings Work Items • Align on a single orchestrator solution for all management workloads • Complete Analysis of single orchestrator feasibility for management and managed workloads Regular Meetings • Progress Work in weekly Edge Automation Meetings and update Arch. team on the findings periodically • Discuss Distribution of functionality for ONAP functions in Arch. Meetings 18
s
Distributed Data Analytics • Ambition: Support distributed (Edge) analytics - https: //jira. onap. org/browse/ONAPARC-280 • Dublin timeframe: Focus on instantiate of edge DCAE • Still under discussion: How to instantiate the edge DCAE, what is instantiated and the trigger. • Stretch goal: Central DCAE - Send signature from Edge DCAE to central DCAE Edge DCAE connectivity Edge site Central site 20
- Slides: 20