Content Comparison

ID

catalog

How MultiCloud is concerned

NF1.1

S3P-security

CII Silver badge(Including no critical and high known vulnerabilities > 60 days old and other requirements),plus

"All communication shall be able to be encrypted and have common rolebased access control and authorization. "

CII Badging Program

 single site horizontal scaling

 All application logging to adhere to ONAP Application Logging Specification v1.2 

ONAP Application Logging Specification v1.2 (Casablanca)

All existing APIs must be documented in Swagger 2.0

All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines

https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Proposal

NF2

Architecture Alignment

API improvement

All APIs between internal components & external APIs should be generated by Swagger

F1

Centralized Representation and Consistent ID of Cloud Regions

ONAP need centralized representation and consistent ID of cloud regions to enable multiple cloud/VIM orchestration, and multicloud is the consumer of the ID

F2

HPA

Changes to VF-C will be required in order to incorporate use of HPA into instantiation and related operation.

F3

Scaling

Auto scaling

UC1

vCPE

VF-C integrates with opensource CPE VNFs via GVNFM in C Release

UC2

vVoLTE

VF-C integrates with SVNFM in C Release

O4

Jira-945 Support multiple VNFM instances

Problem statement: The SVNFM driver can not list all possible VNFM instances using the VF-C NSLCM API, because the API only allows to query VNFM information based on the UUID of the VNFM. The driver must know the UUID of the managed VNFMs to be able to query the VNFM information from VF-C LCM API. Even if the UUID of the VNFM is passed during a LCM operation (ex. scale) from VF-C to SVNFM driver. The possible VNFM instances must be know by the driver even if there is no API call executed from VF-C to driver, since the VNFM driver may want to subscribe to ETSI LCN as part of the driver startup.

Use case: Manage multiple VNFM instances from a single ONAP instance.

Proposed solution: Add a new API to VF-C LCM that allows to query the list of the VNFM instances.

O5

Jira-946  Separate configuration parameters of runtime from design time

Orange lab is pike-based, new placement API available for HPA discovery

Problem statement: The VNF package (CSAR file) currently holds a section that contains runtime information (concrete image names, availability zones, IPs, ...). This section should be  only specified at the point when the VNF / NS / E2E service is created via use-case UI / VID. The current VNF package hold environment specific values resulting in that it can only be deployed in one specific environment. Currently VF-C NSLCM API allows to specify additional data for a VNF and NS, but this section is never filled out by SO/usecase UI.

Use case: The single VNF package can be deployed into different cloud environment (ex. difference availability zone) without modification.

Proposed solution: Extend the use case UI to be able to specify key value pairs for each VNF and NS. The VNF / NS operator could specify the value for these as part of the NS creation. These values would be passed from use case UI to SO and then to VF-C NSLCM API.

O6

Jira-947 Support custom operation

Problem statement: Operations that is not covered by the current ETSI specifications / VF-C LCM implementation can not be triggered from the use case UI / VF-C LCM API.

Use case: Trigger a VNF upgrade operation from the use case UI.

Proposed solution:

• Extend the VF-C API to support the execution of custom operation
• Extend SO workflows to be able to trigger custom operation
• Extend usecase UI / VID to trigger the execution of custom operations

Jira-948  Multi tenancy support

Problem description: The cloud connection in A&AI is located under /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}. This may hold multiple esr-system-info elements. Each esr-system-info collection of many attributes including URL, username, password and default-tenant. To establish a connection with OpenStack the URL, username, password and default-tenant fields are required. VF-C NSLCM identifies a cloud by a vimId field which is a composition of {cloud-owner}/_{cloud-region-id}. This two fields does not select the cloud credentials, since an cloud region may have multiple esr-system-info entries.

Use case: Deploy two VNF on different tenants on the same cloud.

Proposed solution: Change the vimId on VF-C API to be constructed from the {cloud-owner}/{cloud-region-id}{tenantId} tuple making the cloud credential selection unique.

Jira-949  Support VNFMs with multiple end points

Problem description: A VNFM in ETSI have different endpoints (IP address) for different purpose. A couple of examples for endpoints are: authentication, LCM or LCN. The VNFM in A&AI is located under /external-system/esr-vnfm-list/esr-vnfm/

{vnfm-id}

. The VNFM in A&AI may have multiple esr-system-info entries. Each entry may have many attributes (username, password, URL). VF-C only exposes the first element from the esr-system-info list.

Use case: Register a VNFM with multiple API end points.

Proposed solution: Change the ESR UI to be able to register multiple end points. Change the VNFM query API of VF-C LCM to return the full collection of end points instead of the first element.