Deployment Model

Edge using certain ONAP management workload functions as an Offload

Note: In this context, Offload is the process of moving certain functions from central to edge locations to address various requirements such a WAN bandwidth constraint, higher resiliency, real-time service assurance etc.

Edge and Central Provider are same

• Allows ONAP Central Controller function to install ONAP SW components (purely ONAP mgmt. based or 3rd party integrated with ONAP mgmt.).
• This also supports ONAP specific K8S cluster installation.

Priority - High

Rationale:

• Analytics and closed loop offloads are key edge use cases.

Note: Analytics is currently addressed by a Distributed DCAE Orchestrator based on Cloudify.

Participant Operator Priority

• AT&T - High; To distribute DCAE services (Analytics, collectors etc.) and other ONAP components for resiliency.
• Verizon - Medium; Primarily distributed DCAE collectors and data mediation
• Vodafone - High; Distribute both DCAE and ONAP components

Edge and Central Providers are different

Note: In this case, Central provider is still managing the management functionality running at the edge, but using another operators infrastructure.

• Use Existing VPCs (VPC creation out of scope for ONAP)
• Rest - Same as above.

Note: A Virtual Private Cloud (VPC) provides a dedicated pool of compute/network/storage resources using a infrastructure as a service approach.

Priority - Medium

Vodafone (question): should this model be at a lower priority? For a first phase it's sufficient to enable the case where edge and central providers are the same.

• Valid point - lowered priority to medium

Existing infrastructure that is available in ONAP •Use SDC for onboarding management applications if they are independent of VNF Or make management app also part of VNF if it needs to be dynamic •Use SO to bring up the management app like any other VNF •Leverage MC for talking to various cloud-regions of different technologies (Management App as VM or container or public cloud entity) •Leverage OOF to make placement decisions (such as HPA, affinity, anti-affinity)

Using Existing DCAE orchestration to deploy and manage lifecycle for all management application (central and edge)

DCAE orchestration supports deployments of Ms (collectors, and analytics services); primary orchestrator is cloudify. The current orchestration can be extended for supporting deployment of helm charts and Tosca_blueprints to deploy wide ranges of managed applications/services at multiple sites.

Cloud Native K8S Ecosystem - https://landscape.cncf.io/

ONAP OOM Project - Prescriptive Helm Charts for various ONAP management plane components

Yes

(Using SDC. SDC allows to define it as VNF with multiple management applications as VNFCs. SDC allows multiple VNFs in a service and there could be multiple services)

Supported through DCAE, SDC*, Policy, CLAMP.

Onboarded application artifact stored in DCAE inventory (ready for instantiation)

Yes

(SDC now supports Helm, based description. It is possible to introduce dependency via initContainers and helm hooks)

Supported through DCAE, SDC (DS)

Through Cloudify/Tosca models - different components can be linked and deployed as single entity in dynamic fashion.

Yes

(SDC has a way to provide licensing information)

Partially

(SO has ability to select the cloud-region while deploying the VNF and hence same is applicable for management applications. But there is no bulk deployment by selecting multiple cloud regions.It require enhancements. But we believe this requirement is needed for NFs too)

Yes

(Complete control at the SO. One can terminate the management application bundle at any time)

Ability to deploy management applications in selected cloud regions that are not owned by ONAP operator, but has business relationship

(Examples: Public Clouds or Edge Clouds owned by some other organization)

Yes

(Multi-Cloud has ability to deploy workloads in any cloud-region - whether owned by operators or even public clouds as long as right credentials are used)

Supported by design.

Work in Dublin - Target edge cloud (with right credentials maintained in ONAP central) will be provided as input to deployment

Existing OOM functionality.

Cloud regions are defined in onap-central as kube configs. Kube configs already contain credentials for communicating with any cloud region - public, private and regardless of ownership model.

Yes

(SO provides API at various granularity)

Existing capability.

Supported under both Tosca and Helm.

Yes

(SDC/SO with their bundling approaches - management app can be added as VFC in a VNF or as a VNF in a service)

Can be triggered from CLAMP currently.

Functionality can be built to support based on AAI event as future enhancement.

There are 2 options.

1. The management applications that are directly related to instantiation and termination of a Service (VNFs) are an extension of the Service. Therefore it makes sense that the management applications (Helm Charts) under this scenario should remain as part of the Service Orchestration flow.
   
   
2. Alternatively, the Cloud Native approach would be to deploy all needed management applications to the cloud region but with a replicaCount=0. Only the specifications for the management applications are stored (etcd). No other resources are consumed until its replicaCount becomes > 0. This would happen in response to a monitored metric that is set (or increases) when a VNF is deployed. Likewise the management application would free all consumed resources and return to its dormant state (replicaCount=0) once the monitored metric clears (or reduces) after VNF is terminated. Horizontal scalability and the Custom Metric APIs, are existing Kubernetes capabilities.

Yes

(SDC supports adding default Day0 configuration of workloads)

Existing capability

Day0 configuration can be provided part of designer or operator as input.

Yes

(SDC supports multiple Day0 profles - either through customization or as artifacts in case of K8S)

Yes

Supported through Policy/DCAE for Tosca work flow.

Helm chart configuration update supported via custom helm plugin

Yes

(SO can talk to OOF to get the right flavor for workloads in a VFM)

Do we need full blown OOF functionality - Note 1?

Not currently exist for Tosca workflow.

Helm charts supported.

Can be enhanced to interface  with OOF to determine required placement

Do we need full blown OOF functionality - Note 1?

N/A

Do we need full blown OOF functionality - Note 1?

Yes

(Work is going on in K8S plugin to ensure that Day 2 configuration is also supported as Helm charts as Day0 configuration. This is made possible due to microservices supporting K8S operators for their configurations)

Yes

Supported through Policy/DCAE for Tosca work flow.

Helm chart configuration update supported via custom helm plugin

Yes

(APPC support for Day2 configuration. Also Day2 configuration support in K8S plugin - Ongoing. One can select cloud-region, instance while applying Day2 configuration)

Yes

Supported through Policy/DCAE for Tosca work flow.

Helm chart configuration update supported via custom helm plugin

Yes

(In case of K8S world, as long as day2 configuration is also supported via K8S resources, it is possible. K8s Plugin does support this)

Functionality supported under current design; for Tosca workflow installed component but not currently exist in ONAP.

The Cloud Native approach would be to deploy all needed management applications to the cloud region but with a replicaCount=0. Only the specifications for the management applications are stored (etcd). No other resources are consumed until its replicaCount becomes > 0. This would happen in response to a monitored metric that is set (or increases) when a VNF is deployed. Likewise the management application would free all consumed resources and return to its dormant state (replicaCount=0) once the monitored metric clears (or reduces) after VNF is terminated. Horizontal scalability and the Custom Metric APIs, are existing Kubernetes capabilities.

Yes

(Using SSL/TLS)

Supported via securing DMAAP topics.

Platform support dynamic topic creation and AAF role assignment using DMAAP DBCL

N/A

This is an application requirement and not a requirement of the Platform Orchestrator.

Application needs to support SSL/TLS.

Or use of Istio or like technologies.

Yes

(No restriction. it is based on management application)

N/A

This is an application requirement and not a requirement of the Platform Orchestrator.

Partial

(Same monitoring schemes as available for VNFs, but suggest that all management components acts prometheus target)

Cloudify UI provides the relation of the multiple MS (based on node types).

Consul integration supported

Dashboard - Provides unified console for Operation to check/manage deployment of application

Yes

(but testing is required with a use case to ensure that there are no gaps)

(This work is slated for Release E - configuration of ISTIO for L7 workloads and NSM for L2/L3/L4 workloads)

Even though K8S can bring up more instances, traffic distribution is expected to be configure properly)

Existing capability

(relies on k8s)

Existing OOM functionality.

Existing Kubernetes Horizontal scalability capabilities. Traffic management achieved using additional open source technologies (ie. ISTIO).

Yes

((but testing is required with a use case to ensure that there are no gaps)

(This work is slated for Release E - configuration of ISTIO for L7 workloads and NSM for L3/L3/L4 workloads)

Loss of functionality requires careful configuration of traffic rules of ISTIO or NSM)

Existing capability; supported for both Tosca and Helm

(relies on k8s)

Existing OOM functionality.

Rolling upgrade and rollback are existing capabilities of Helm + Kubernetes. Traffic management achieve using additional open source technologies (ie. ISTIO).

Yes

(It is part of K8S)

Existing capability; supported for both Tosca and Helm

(relies on k8s)

Support for ONAP-compliant third party management applications that provide similar functionality as ONAP management applications.

• Some of the key aspects of ONAP-compliance include but are not limited to the following - API compatibility, Cloud Native Packaging in ONAP Helm chart format etc.

Yes

(As long as third party management applications are described using Helm)

Yes

(helm chart deployment will be supported via new helm plugin contributed for Dublin (the policy reconfiguration will require complying to onboarding req#1)

Yes

(Using K8S plugin)

Yes

(Using K8S plugin)

Yes.

Backwards compatibility must be a top priority as we evolution the platform orchestrator.

Decisions was made to maintain separation of concerns.

• SO manages Service (VNF) Orchestration
• single Platform Orchestrator will manage life-cycle of ONAP Platform Components

1.Consolidated view of deployed management component micro-services (in Central and other locations such as Edge) and their relationship for central Orchestrator

AT&T - near-term

Bell Canada - long-term

Orange - long-term

Swisscom - near-term

Verizon- near-term

Vodafone - near-term

2.For a given application configuration management mechanism is the same independent of location (Central and Edge), including dynamic configuration support

AT&T - near-term

Bell Canada - long-term

Orange - long-term

Swisscom - near-term

Verizon- long-term

Vodafone - long-term

Clarification (added 4/11): The requirement indicates configuration management at both central and edge should be consistent. Having different mechanism to handle this at different site will be operational issue.

AT&T - near-term

Bell Canada - long-term

Orange - long-term

Swisscom - near-term

Verizon - long-term

Vodafone - long-term

Clarification (added 4/11): This is relevant to #6 and should be treated under same priority.

This is also existing capability in ONAP and will be required for Day0 in the target architecture for backward compatibility to existing components (DCAE, Policy)

4.Retain the ability to support TOSCA artifacts distributed from SDC and CLAMP.

AT&T - near-term

Bell Canada - long-term

Orange - long-term

Swisscom - near-term

Verizon - long-term

Vodafone - long-term

Clarification (added 4/11): This is relevant to #5 and should be treated under same priority.

This is also existing capability in ONAP and will be required for Day0 in the target architecture for backward compatibility to existing components (DCAE, SDC, Policy, CLAMP). It is not mandatory to follow existing workflow.

With regard to TOSCA support, the relevant standard is ETSI SOL 001.

5.Design flow integration (SDC, DCAE-DS) and Standardized configuration modelling support by Central Orchestrator

AT&T - near-term

Bell Canada - near-term

Orange - near-term

Swisscom - near-term

Verizon - near-term

Vodafone - near-term

6.Dynamic Control Loop flow deployment and support through CLAMP/Policy Integration by Central Orchestrator

AT&T - near-term

Bell Canada - long-term

Orange - near-term

Swisscom - long-term

Verizon - long-term

Vodafone - near-term

Applicable only to management applications (Analytics, 3rd party etc.) which are on boarded after the basic ONAP components are up and running.

Additional Clarification – If the application is using ONAP Control Loop flow, then it shall follow the approach suggested by CLAMP framework.

7.Multi-tenant infrastructure management - Install relevant K8S clusters if they are not already present.

AT&T - near-term (for both a and b)

Bell Canada - N/A - not an ONAP accountability.

Orange - NO. No the ONAP purposes according to us.

Swisscom - not in ONAP scope

Verizon - near-term

Vodafone - near-term

Clarification – This also includes installation of other relevant VIMs (OpenStack etc.) besides K8S if needed.

Can use open source K8S cluster API effort (https://github.com/kubernetes-sigs/cluster-api) as applicable to bring up K8S clusters on various Clouds (Amazon, Azure, OpenStack, VMware etc.)

8. Support for non-K8S based workload deployment

AT&T - near-term

Bell Canada - long-term

Orange - long-term

Swisscom - long-term

Verizon - near-term

Vodafone - long-term

Clarification – This is the ability for ONAP to deploy applications across heterogeneous env (k8s, openstack etc)