Samuli Silvius <s.silvius@partner.samsung.com> CNF Modeling ONAP Joint Subcommittee Meeting · Antwerp, Belgium · September 26–27, 2019 Samuli Silvius <s.silvius@partner.samsung.com>

Slides:



Advertisements
Similar presentations
Sadegh Aliakbary Sharif University of Technology Fall 2011.
Advertisements

Raffaele Di Fazio Connecting to the Clouds Cloud Brokers and OCCI.
Object Oriented Software Development
Open Source and Info Models 17 Dec 2015 Bryan Sullivan, AT&T.
Sadegh Aliakbary Sharif University of Technology Fall 2010.
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)
Orchestration and Controller Architecture Alignment Vimal Begwani AT&T
Open Network Automation Platform (ONAP) Controller Architecture Proposal DRAFT.
ONAP Architecture Meeting 8/8
Mapping between NFV model and TOSCA
Multi-VIM/Cloud High Level Architecture
ONAP SDC VoLTE Model Support
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,
Defining ONAP VNF Package Model
Multi-VIM/Cloud High Level Architecture
Multi-VIM/Cloud High Level Architecture
ARC: Definitions and requirements for SO/APP-C/VF-C discussion Chris Donley Date , 2017.
ONAP Architecture Meeting 8/8
ONAP SDC TOSCA Import Gap Analysis
The Object-Oriented Thought Process Chapter 1
MEF LSO Legato SDK 24 October 2017 Andy Mayer, Ph.D. Tara Cummings.
Multi-VIM/Cloud High Level Architecture
VoLTE Use Case Proposal
17 Dec 2015 Bryan Sullivan, AT&T
11.1 The Concept of Abstraction
ONAP Optimization Framework - HAS Shankar Narayanan - AT&T Labs Research 08/15/2017.
Component Based Software Engineering
OASIS TOSCA Report for December ONAP Event
ONAP – Centralised Parser Distribution Atul Purohit - Vodafone
Deployment Flavor Model – Challenges and Emerging trends for ONAP adaptation Priya TG, NetCracker Technology.
Enhanced Platform Awareness (EPA) Alex Vul Intel Corporation
OASIS TOSCA Report for December ONAP Modeling Workshop
VF-C R2 Feature Planning & Implementation Yan Yang
TOSCA Matching Or how the orchestrator provides implementation for abstract nodes or dangling requirements.
Isasku, Srini, Alex, Ramki, Seshu, Bin Hu, Munish, Gil, Victor
Documenting ONAP components (functional)
DF design as a node type (output by Chris and shitao)
Multi-VIM/Cloud High Level Architecture
DF design as a node type (output by Chris and shitao)
FUNCTIONAL Architecture for R2+
ONAP Beijing Architecture Chris Donley 1/9/18
Defining ONAP VNF Package Model
ONAP Architecture for Rel 1
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 (Network Deployment, Slicing, Network Optimization and Automation Framework) 5G Use Case Team.
TOSCA Native Service Orchestration SO State of the Union
Deployment Flavour as VNF Capability: Alt1_r2
Programming with ANSI C ++
MUMT611: Music Information Acquisition, Preservation, and Retrieval
ONAP 5G USE CASE ENHANCEMENTS
ARC Alignment ExtAPI ExtAPI Team.
ONAP Network Slice Model
Open Source Projects Collaborations with ONAP
NFV adhoc Shitao li.
ONAP and ONAP Edge Orchestration Cloud Native Proposal
GNFC Architecture and Interfaces
LTP Port and Spec enhancements for “2.0” Preparing to make the change
11.1 The Concept of Abstraction
ONAP Architecture Principle Review
Proposed Approach for ONAP Runtime Support of Network Service Onboarding Gil Bullard, AT&T.
Title: Robust ONAP Platform Controller for LCM in a Distributed Edge Environment (In Progress) Source: ONAP Architecture Task Force on Edge Automation.
Chapter 11 Abstraction - The concept of abstraction is fundamental in
August 26, 2019 Use Case Sub-Committee
Presentation transcript:

Samuli Silvius <s.silvius@partner.samsung.com> CNF Modeling ONAP Joint Subcommittee Meeting · Antwerp, Belgium · September 26–27, 2019 Samuli Silvius <s.silvius@partner.samsung.com>

Agenda CNF Modeling Problem ONAP Modeling Situation Resource Definition Languages Solution Remaining Challenges

CNF Modeling Problem There is no way of modeling Kubernetes based things in ONAP Helm package is passed as a black box instead As there are no models, the various runtime components cannot do anything interesting with the package without custom coding, which mostly does not exist DCAE is already modeling and orchestrating some kubernetes kinds in a limited way with Cloudify As Kubernetes is a generic orchestrator itself, it can be used to orchestrate anything, and an extensible set of things, on its own Thus there is not, and cannot be, full support of Kubernetes applications (CNF) modeling in ONAP The open-ended nature of Kubernetes kinds applies to all major kinds For compute, there are multiple supported container runtimes and multiple VM- in-a-pod runtimes For networking, there is a plethora of plugins that can further be combined in many ways. Ovn4nfv and Kuryr are explored later in a bit more detail On storage side there are even more options and every public cloud for example has support for their own storage types

ONAP Modeling Situation ONAP has multiple attempts to generalize over resource modeling and orchestration: TOSCA ETSI NFV VNF and NS descriptors Cloudify Blueprints etc. All of these are used (in some places, in some forms) in ONAP already ONAP is standardizing on TOSCA, at least in modeling, but still needs to be able to talk these various other languages and dialects for compatibility There is already Heat -> TOSCA converter in SDC for Heat VFs TOSCA -> Cloudify Blueprint converter in SDC for DCAE models DCAE Spec -> TOSCA converter in DCAE for DCAE models Probably a bunch of other converters in MultiCloud (like Azure ARM)

Resource Definition Languages Every cloud platform has their own declarative resource modeling and orchestration definition language: OpenStack Heat AWS CloudFormation Azure Resource Manager templates Kubernetes manifests Etc. In an extended sense (resource oriented) YANG models can be considered to be similar resource definitions of various network related sub-entities in xNFs Some new architectures to orchestrate, e.g. Service Mesh, serverless, P4, FPGAs, are sure to become feasible and some of them will become fashionable during projected lifetime of ONAP

Solution ONAP needs to be able to organize and orchestrate services that are built with heterogenous application architectures and modeling languages MultiCloud is the adaptation component by design, but centralizing the adaptation to this low level is not sufficient Introducing support for each modeling language to each relevant ONAP component is not feasible Model translation will enable most ONAP components (e.g. SDC, AAI, SO, DCAE, OOF, Policy etc.) to work on only one model language That language is TOSCA Expressive and extensible enough Quite widely already supported around ONAP and somewhat elsewhere Some translators to/from that already exist in ONAP and elsewhere Various levels of code should and do operate on only very limited part of the complete model Full translation is hard and time consuming to get right, a standardization kind of effort Partial translations will enable the most important features The supported subset can be enhanced over time There will not be a guarantee that TOSCA model contains everything, but the native models are distributed as artifacts and orchestrated directly by lower level orchestrators

Partial Translation to Common Model By choosing single common modeling language we can manage with n translators instead of n^2 translators Translations can be partial, and will be, but missing part of translation may exclude some ONAP features The appropriate sub-orchestrator will get the original package and work with all details ETSI TOSCA Azure Arm Kubernetes with Multus networking Only changing of closed set of parameters is possible in modeling and filling those with instance specific values This light-weight modeling via translation aims to enable parameterized composition of services OpenStack Heat Kubernetes with Virtlet and Multus networking ONAP TOSCA AWS Cloud Formation Kubernetes with Neutron/Kuryr networking Any Proprietary Orchestrator P4 Cloudify Blueprint

Example Translation for a network https://github.com/onap/multicloud-k8s/blob/master/kud/demo/firewall/templates/onap-private-net.yaml Note that Translation has to produce reasonable defaults for values that do not exist in the source Some details, even important ones, in the source can be left out. TOSCA network definition, somewhat aligned with ETSI SOL001 network1: type: tosca.nodes.opnfv.ovn4nfv properties: connectivity_type: layer_protocols: [ipv4] vl_profile: max_bitrate_requirements: root: 10 min_bitrate_requirements: virtual_link_protocol_data: - associated_layer_protocol: ipv4 l3_protocol_data: ip_version: ipv4 cidr: 192.168.11.0/24 gateway_ip: 192.168.11.1 OVN4NFV network definition apiVersion: | k8s.plugin.opnfv.org/v1alpha1 kind: Network metadata: name: network1 spec: cniType : ovn4nfv ipv4Subnets: - name: subnet1 subnet: 192.168.11.0/24 gateway: 192.168.11.1

Example Translation for a NIC https://github.com/onap/multicloud-k8s/blob/master/kud/demo/firewall/charts/sink/templates/deployment.yaml Note that Translation has to produce reasonable defaults for values that do not exist in the source Some details, even important ones, in the source can be left out. TOSCA CP definition, somewhat aligned with ETSI SOL001 eth1: type: tosca.nodes.opnfv.Interface properties: layer_protocols: [ipv4] trunk_mode: false protocol: - associated_layer_protocol: ipv4 address_data: - address_type: ip_address l3_address_data: ip_address_assignment: false floating_ip_activated: false fixed_ip_address: - 10.0.10.11 requirements: - virtual_binding: vSink - virtual_link: network2 OVN4NFV NIC definitions k8s.v1.cni.cncf.io/networks: | '[{"name": ”network1”, "namespace": "default"}]' k8s.plugin.opnfv.org/nfn-network: | '{ "type": "ovn4nfv", "interface": [ { "name": ”network2”, "ipAddress": ”10.0.10.11”, "interface": "eth1", "defaultGateway": "false" } ]}'

Example - Kuryr Similar but different translation for other Kubernetes technology choices Kuryr seems translatable too: https://docs.openstack.org/kuryr- kubernetes/latest/specs/rocky/npwg_spec_support.html Abstract ETSI types for VL and CP seems generic enough for most other similar concepts from other technology stacks

Class Structure Sketch tosca.nodes.nfv.VDU.Compute Apps/v1/Deployment Apps/v1/Deployment kubernetes.io/target-runtime: virtlet.cloud Kuryr uses normal Neutron networks tosca.nodes.nfv.VnfVirtualLink tosca.nodes.nfv.Cp k8s.plugin.opnfv.org/Network openstack.org/kuryr-vif k8s.plugin.opnfv.org/nfn-network

Remaining Challenges Some level of ”inheritance” mechanism is needed to AAI. It seems best to preferable if AAI schema extension with properties derived from TOSCA properties (and possibly attribute) could be derived automatically from TOSCA schema. Handling of parameterization Translation must provide a set of parameters for TOSCA model Values, either in modeling or instance specifically, must be passed to lower level orchestrators For example in kubernetes case, the set of parameters is Helm charts Only changing of closed set of parameters is possible in modeling and filling those with instance specific values Full modeling support in SDC needs a modeling language specific editor and more effort to translation This is prohibitively expensive and time consuming Any support for wider set of features needs careful mapping work for that particular