...
Epic | User Story | Description | Guilin Plan? | JIRA | |||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Maintenance | Support the substitution_mappings in the VNFD. | Currently, the substitution_mappings is not supported by SDC. Lack of this support blocks SOL004 VNF package management and ETSI Catalog Manager:
Support of the substitution_mappings and user-defined node_types will remove the issues and support ETSI package management and others. Support of the user-defined node types is handled by another task. This task needs to handle the substitution_mappings only. For the testing, use the vgw6.csar For the Frankfurt release workaround, we added the following to the MainServiceTemplate.yaml, so the ETSI Catalog Manager can retrieve the descriptor_id from the metadata, instead of from the node_type. Once the substitution_mapping is supported by SDC, we don't have to use the descriptor_id in the metadata section.
| Yes |
| |||||||||||||||||||||||||||||||||||||||||||||||||
Onboard and Design ETSI SOL004 compliant VNF packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant VNF package including an ETSI SOL001 VNF Descriptor to be onboarded into ONAP for composition into an ONAP Service Business Impact - Enables operators and service providers to use same ETSI compliant VNF packages with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators that are currently using ETSI packages to deploy VNFs Funding/Financial Impacts - Reduction in operations expense from using industry standard VNF packaging. Reduction in capital expense from vendors using a single packaging methodology. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | No |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1) | Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1)
| No |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model | Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model VNF Mapping: | Onboard and Design ETSI SOL004 compliant VNF packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant VNF package including an ETSI SOL001 VNF Descriptor to be onboarded into ONAP for composition into an ONAP Service Business Impact - Enables operators and service providers to use same ETSI compliant VNF packages with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators that are currently using ETSI packages to deploy VNFs Funding/Financial Impacts - Reduction in operations expense from using industry standard VNF packaging. Reduction in capital expense from vendors using a single packaging methodology. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes |
| Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1) |
| Yes | SDC-2611 - SDC supports onboarding of the SOL004 VNF Package includes SOL001 VNFD OPEN | Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model | Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model VNF Mapping:
VDU Mapping:
VF-Module Mapping:
| Yes |
| Support for editing ETSI v2.7.1 SOL001 VNF Descriptor |
| Yes |
|
VDU Mapping:
VF-Module Mapping:
| No |
| |||||||||||||||||||||||||||||||||
Support for editing ETSI v2.7.1 SOL001 VNF Descriptor |
| No | Support for using an ETSI v2.7.1 VNF in an ONAP Service |
| TBD | Support the substitution_mappings in the VNFD. | Currently, the substitution_mappings is not supported by SDC. Lack of this support blocks SOL004 VNF package management and ETSI Catalog Manager:
Support of the substitution_mappings and user-defined node_types will remove the issues and support ETSI package management and others. Support of the user-defined node types is handled by another task. This task needs to handle the substitution_mappings only. For the testing, use the vgw6.csar For the Frankfurt release workaround, we added the following to the MainServiceTemplate.yaml, so the ETSI Catalog Manager can retrieve the descriptor_id from the metadata, instead of from the node_type. Once the substitution_mapping is supported by SDC, we don't have to use the descriptor_id in the metadata section.
|
| |||||||||||||||||||||||||||||||||||||||||||||
Support for using an ETSI v2.7.1 VNF in an ONAP Service |
| TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||
Onboard ETSI SOL007 compliant Network Service Descriptor packages | Executive Summary - Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1) Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) to be onboarded into ONAP for composition into an ONAP Service or deployment using an ETSI compliant NFVO.
Business Markets - All operators and service providers that are developing ETSI compatible Network Services Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | stretch goalNo |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Support onboarding for Cataloging and Preserving the original SOL007 package | Support onboarding for Cataloging and Preserving the original SOL007 package (Link to ETSI SOL001 v2.7.1) | stretch goalNo |
| Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model | |||||||||||||||||||||||||||||||||||||||||||||||||
Design ETSI SOL007 compliant Network Service Descriptor & packages | Support for deploying a service that contains an ETSI SOL001 v2 Executive Summary - Design, catalog and distribute an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 Support for mapping of ETSI v2.7.1 SOL001 ) Network Service Descriptor in the SOL007 package into SDC AID Data Model
| stretch goal |
| package including an ETSI version 2.7.1 compliantSOL001 Network Service using VF-C as the NFVODescriptor (NSD) for deployment using an ETSI compliant NFVO.
| Close this, expect the current SDC distribution is sufficient
| Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are developing ETSI compatible Network Services Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes |
Note: there is a PoC for this. Soon, the PoC design could be shared as initial input for discussions | |||||||||||||||||||||||||||||||||||||||||||||
Design ETSI SOL001 NSD and generate | Close this, expect the current SDC distribution is sufficient | Design ETSI SOL007 compliant Network Service Descriptor & packages | Executive Summary - Design, catalog and distribute an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1) Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO. Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are developing ETSI compatible Network Services Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes | Descriptor & package | Design ETSI SOL001 NSD and generate ETSI SOL007 compliant Network Service package
| Yes |
Note: there is a PoC for this. Soon, the PoC design could be shared as initial input for discussions
| |||||||||||||||||||||||||||||||||||||||||||||
Support for mapping of ETSI Design ETSI SOL001 NSD and generate an ETSI SOL001 v2.7.1 compliant SOL001 Network Service Descriptor & package | Design ETSI SOL001 NSD and generate ETSI SOL007 v2.7.1 compliant Network Service package
| in the SOL007 package into SDC AID Data Model | Support for mapping of ETSI SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
| Yes |
| ||||||||||||||||||||||||||||||||||||||||||||||||
Support design of Service templates, leveraging NSDs | Support design of Service templates, leveraging NSDs | NoYes |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory | Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory | Yes |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Support for Nested/Hierarchical |
| Close this, expect the current SDC distribution is sufficient | Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVODescriptor | Executive Summary - Onboard an ETSI SOL007 Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO
| Close this, expect the current SDC distribution is sufficient | Support design of Service templates, leveraging NSDs | Support design of Service templates, leveraging NSDs | Yes |
| Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory | Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory | (Link to ETSI SOL007 v2.7.1) Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) that includes references to other Network Service Descriptors for composition into an ONAP Service or deployment using an ETSI compliant NFVO. Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are developing ETSI compatible Network Services especially for 5G Slicing where each Slice Subnet is associated with a Network Service Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | NoYes |
| |||||||||||||||||||||||||||||||||||||||
Support for Nested/Hierarchical ETSI SOL001 v2.7.1 Network Service DescriptorExecutive Summary - Onboard an ETSI onboarding of the SOL007 v2.7.1 compliant (Link to ETSI SOL007 NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service | Support for onboarding of the SOL007 v2.7.1 ) Network Service Descriptor compliant NSD package including an ETSI version 2.7.1 SOL001 Network Service Descriptor ( NSD ) that includes references to other NSDs for composition into ONAP Service | No |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Onboard ETSI SOL004 compliant PNF packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant PNF package including an ETSI SOL001 PNF Descriptor to be onboarded into ONAP Network Service Descriptors for composition into an ONAP Service or deployment using an ETSI compliant NFVO. Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors same ETSI compliant PNF packages with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are developing ETSI compatible Network Services especially for 5G Slicing where each Slice Subnet is associated with a Network Service currently using ETSI packages to deploy PNFs Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packagingPNF packaging. Reduction in capital expense from vendors using a single packaging methodology. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | No |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
SDC supports onboarding of the | SOL007 SOL004 PNF package includes SOL001 PNFD
|
| compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service
| Support for onboarding of the SOL007
| compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP ServiceNo |
| 2811
| ||||||||||||||||||||||||||||||||||||||||||||||
Support for mapping of ETSI v2.7.1 SOL001 PNF Descriptor into SDC AID Data Model | SOL001 PNFD 2.7.1 Mapping to SDC AID DM | No |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
Support additional package artifact Indicators for ETSI packages and Non-ETSI packages | SDC supports additional package artifact types to split ETSI packages from other non-ETSI TOSCA packages
| No | Onboard ETSI SOL004 compliant PNF packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant PNF package including an ETSI SOL001 PNF Descriptor to be onboarded into ONAP for composition into an ONAP Service Business Impact - Enables operators and service providers to use same ETSI compliant PNF packages with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators that are currently using ETSI packages to deploy PNFs Funding/Financial Impacts - Reduction in operations expense from using industry standard PNF packaging. Reduction in capital expense from vendors using a single packaging methodology. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes |
| |||||||||||||||||||||||||||||||||||||||||||||||
SDC | supports onboarding of the SOL004 PNF package includes SOL001 PNFD
| Yes |
Jira | ||||||
---|---|---|---|---|---|---|
|
Support for mapping of ETSI v2.7.1 SOL001 PNF Descriptor into SDC AID Data Model
SDC (Notification) supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages
- for SOL004 and SOL007 packages, artifact type = ONBOARDED_ETSI_PACKAGE
- for non-ETSI TOSCA package, artifact type = ONBOARDED_ONAP_PACKAGE
Jira | ||||||
---|---|---|---|---|---|---|
|
SDC client supports additional package filtering on the artifact types to split for distinguishing between ETSI packages from other nonand Non-ETSI TOSCA packages
- SDC (notification) generates additional artifact types
- SDC client filters on the additional artifact types
SDC (Notification) supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages
- for SOL004 and SOL007 packages, filtering for artifact type = ONBOARDED_ETSI_PACKAGE
- for non-ETSI TOSCA package, filtering for artifact type = ONBOARDED_ONAP_PACKAGE
Jira | ||||||
---|---|---|---|---|---|---|
|
SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages
- for SOL004 and SOL007 packages, filtering for artifact type = ONBOARDED_ETSI_PACKAGE
- for non-ETSI TOSCA package, filtering for artifact type = ONBOARDED_ONAP_PACKAGE
|
ONAP supports vendor ETSI Package Security and validation
Jira | ||||||
---|---|---|---|---|---|---|
|
ONAP supports vendor ETSI Package Security and validation
- If the vendor package includes signature and certificate, ONAP supports the package security
Jira | ||||||
---|---|---|---|---|---|---|
|
- SOL004 VNF/PNF Package security will be supported by SDC, based on the package signature and certificate
- ONAP SDC supports the package security
- SOL007 NS Package security will be supported by SDC, based on the package signature and certificate
- ONAP SDC supports the package security
Jira | ||||||
---|---|---|---|---|---|---|
|
...
Among the SOL004/SOL007 VNF package security options, the SDC supports the option2 as depicted below. In the option 2, there are two ways to zip the VNF packages, and SDC supports both.
SDC validates the VNF packages based on the embedded signature and certificate by leveraging CA.
- Vendor SOL004/SOL007 VNF Package with certificate and signature is onboarded into SDC
- ZIP-format VNF package includes CSAR, Signature and Certificate
- SDC validates VNF package based on the certificate and signature
- SDC generates SDC internal model plus the vendor SOL004/SOL007 package CSAR and ZIP (with certificate and signature) – the supported format is TBD based on the security requirement
Package Security
A VNF package uses the signature and certificate to ensure package integrity and validity. A CSAR file is digitally signed with the VNF provider private key. During the VNF package onboarding to SDC, SDC validates the package and then does the following:
- Transform SOL001-based VNFD into SDC internal models
- Store the original Vendor package into the ETSI_PACKAGE directory
- If the original vendor package is a zip file with signature and certificate, the ETSI_PACKAGE directory will contain the zip file.
- VNFM and VF-C will receive the zip-format file.
- For Frankfurt, the SVNFM and external NFVO will receive a zip-format package with signature and certificate if the original vendor package contains signature and certificate.
- SVNFM and NFVO will unzip the incoming zip package files and extract CSAR files from the zip package files without validation.
- After the Frankfurt release, it is assumed that SVNFM and NFVO validate the incoming packages based on signature and certificate.
SOL001 Mapping to SDC AID DM
The following diagram depicts SOL001 Mapping to SDC AID DM.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Current Mapping Support (as of Frankfurt)
Note: AAI impacts are under discussion.
Presentation Slide (as a summary)
The following is a presentation slide that summarizes the Mapping.
ways to zip the VNF packages, and SDC supports both.
SDC validates the VNF packages based on the embedded signature and certificate by leveraging CA.
- Vendor SOL004/SOL007 VNF Package with certificate and signature is onboarded into SDC
- ZIP-format VNF package includes CSAR, Signature and Certificate
- SDC validates VNF package based on the certificate and signature
- SDC generates SDC internal model plus the vendor SOL004/SOL007 package CSAR and ZIP (with certificate and signature) – the supported format is TBD based on the security requirement
Package Security
A VNF package uses the signature and certificate to ensure package integrity and validity. A CSAR file is digitally signed with the VNF provider private key. During the VNF package onboarding to SDC, SDC validates the package and then does the following:
- Transform SOL001-based VNFD into SDC internal models
- Store the original Vendor package into the ETSI_PACKAGE directory
- If the original vendor package is a zip file with signature and certificate, the ETSI_PACKAGE directory will contain the zip file.
- VNFM and VF-C will receive the zip-format file.
- For Frankfurt, the SVNFM and external NFVO will receive a zip-format package with signature and certificate if the original vendor package contains signature and certificate.
- SVNFM and NFVO will unzip the incoming zip package files and extract CSAR files from the zip package files without validation.
- After the Frankfurt release, it is assumed that SVNFM and NFVO validate the incoming packages based on signature and certificate.
SOL001 Mapping to SDC AID DM
The following diagram depicts SOL001 Mapping to SDC AID DM.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Current Mapping Support (as of Frankfurt)
Note: AAI impacts are under discussion.
Presentation Slide (as a summary)
The following is a presentation slide that summarizes the Mapping.
Note:
The following is being implemented for the Guilin release:
- SOL007 Design and SOL004 Onboarding
- ONAP ETSI-Alignment Modeling Hierarchy (partially)
- NS Mapping
- NS-Level VirtualLink (between VNFs) Mapping
The following mapping will be implemented in the Honolulu release:
- VNF Mapping
- VDU and VFC Mapping
- PNF Mapping
- SOL001 VNFD and SDC AID DM VF Template Mapping
- VF-Module Deduction from SOL001 VNFD
View file | ||||
---|---|---|---|---|
|
SOL007 Design and SOL004 Onboarding
- SDC takes the vendor provided package and adds some files or changes files and meta data according to SDC procedure.
- SDC NS/VNF/PNF Onboarding Procedure and Original Vendor VNF/PNF Package Handling
- SDC onboarding enhancement was made to the SDC Dublin to support SOL004 PNF/VNF onboarding with .zip and .csar file extensions. We continue to support the current onboarding mechanism with some enhancements.
- SOL007 NS onboarding (stretch goal for Guilin) will follow the same procedure; i.e., storing the vendor SOL007 NS package into the “ETSI_PACKAGE” directory.
- SOL007 NS design will allow users to build SOL007 NS package including SOL001 NSD from scratch
- SDC VSP and Resource csar files have the “ETSI_PACKAGE” directory, which will contain the original vendor VNF/NS/PNF package.
- The “ONBOARDED_PACKAGE” directory name will be changed to “ETSI_PACKAGE” as a common ETSI directory name. This change is necessary to support design of SOL007 package
- ONAP-ETSI Catalog Manager will be extracted the ETSI packages from the “ETSI_PACKAGE” directory.
- The VNFM and external NFVO use the original vendor VNF/NS/PNF packages through ETSI Catalog Manager.
- SDC provides mapping from ETSI SOL001 NSD/VNFD/PNFD (PNF in the future) to SDC AID DM
- See the subsequent slides for mapping.
- Note: ETSI 2.7.1 handling will be discussed separately.
SDC CSAR for NS structure
ONAP Service CSAR
|-- Artifacts
|-- ETSI_PACKAGE
|-- etsi nsd csar
|-- <VF 1>
|-- Deployment
|-- ETSI_PACKAGE
|-- etsi vnf package
...
|-- <VF n>
|-- Deployment
|-- ETSI_PACKAGE
|-- etsi vnf package View file
Mapping of ETSI Information NS-related Elements with TOSCA types
...
- The following diagram depicts ONAP ETSI-Alignment Modeling hierarchy.
- Note: the ONAP VFC model represents the design time VFC, not runtime VFC instance(s).
- Note: VNF, VFC and PNF node types continue to be discussed for the Honolulu release.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
...
SOL001 Data Model | SDC AID DM | Comments | Release |
---|---|---|---|
N/A | org.openecomp.resource.abstracts.nodes.service | represents OSS Service models | |
tosca.nodes.nfv.NS | tosca.nodes.nfv.NS | NS; use of SOL001 as SDC AID DM NS | Guilin |
tosca.nodes.nfv.NsVirtualLink | tosca.nodes.nfv.NsVirtualLink | NS VirtualLink; use of SOL001 as SDC AID DM VL | Guilin |
tosca.nodes.nfv.Vnf | org.openecomp.resource.abstract.nodes.ETSI.VNF | VNF | Plan for Honolulu |
tosca.nodes.nfv.vdu | org.openecomp.resource.abstract.nodes.ETSI.VFC | VDU and SDC VFC | Plan for Honolulu |
tosca.nodes.nfv.VirtualLink | org.openecomp.resources.vl | VNF VL | Plan for Honolulu |
tosca.nodes.nfv.VduCp | org.openecomp.resources.cp | VDU CP | Plan for Honolulu |
N/A | org.openecomp.resource.allottedResource | allotted resource; could not find any from SOL001 | |
tosca.nodes.nfv.Pnf | org.openecomp.resource.abstract.nodes.ETSI.PNF | PNF | Plan for Honolulu (PNF support is under discussion for Honolulu |
Current SDC Resource Models
...
SOL001 VNF (tosca.nodes.nfv.VNF) | Mapping | New SDC AID DM VNF (org.openecomp.resource.abstract.nodes.ETSI.VNF) derived from org.openecomp.resource.abstract.nodes.VF | ||||
---|---|---|---|---|---|---|
name | required | type | name | required | type | |
<SOL001 tosca.nodes.nfv.VNF attributes > | <SOL001 tosca.nodes.nfv.VNF attributes > | |||||
descriptor_id | yes | string | <--> | descriptor_id | yes | string |
descriptor_version | yes | string | <--> | descriptor_version | yes | string |
provider | yes | string | <--> | provider | yes | string |
product_name | yes | string | <--> | product_name | yes | string |
software_version | yes | string | <--> | software_version | yes | string |
product_info_name | no | string | <--> | product_info_name | no | string |
vnfm_info | yes | list of string | <--> | vnfm_info | yes | list of string |
localization_languages | no | list of string | <--> | localization_languages | no | list of string |
default_localization_language | no | string | <--> | default_localization_language | no | string |
configurable_properties | no | tosca.datatypes.nfv.VnfconfigurableProperties | <--> | configurable_properties | no | tosca.datatypes.nfv.VnfconfigurableProperties |
modifiable_attributes | no | tosca.datatypes.nfv.VnfInfoModifiableAttributes | <--> | modifiable_attributes | no | tosca.datatypes.nfv.VnfInfoModifiableAttributes |
lcm_operations_configuration | no | tosca.datatypes.nfv.VnfLcmOperationsConfiguration | <--> | lcm_operations_configuration | no | tosca.datatypes.nfv.VnfLcmOperationsConfiguration |
monitoring_parameters | no | list of tosca.datatypes.nfv.VnfMonitoringParameter | <--> | monitoring_parameters | no | list of tosca.datatypes.nfv.VnfMonitoringParameter |
flavour_id | yes | string | <--> | flavour_id | yes | string |
flavour_description | yes | string | <--> | flavour_description | yes | string |
vnf_profile | no | tosca.datatypes.nfv.VnfProfile | <--> | vnf_profile | no | tosca.datatypes.nfv.VnfProfile |
<SDC AID DM VF attributes that are inherited from org.openecomp.resource.abstract.nodes.VF> | ||||||
<the followings are being considered> | nf_function | no | string | |||
requirements | Yes | nf_role | no | string | ||
interfaces | yes | tosca.interfaces.nfv.VnfLcm | nf_type | no | string | |
nf_naming_code | no | string | ||||
nf_naming | no | org.openecomp.datatypes.Naming | ||||
availability_zone_max_count | no | integer | ||||
min_instances | no | integer | ||||
max_instances | no | integer | ||||
multi_stage_design | no | boolean | ||||
sdnc_model_name | no | string | ||||
sdnc_artifact_name | no | string | ||||
skip_post_instantiation_configuration | no | boolean (default true)
| ||||
controller_actor | no | string (default: SO-REF-DATA)
| ||||
...
SOL001 VNFD | SDC AID DM VFD | |||
---|---|---|---|---|
Name | Grammar | Name | Grammar | |
tosca_definitions_version | string (tosca_simple_yaml_1_2) | tosca_definitions_version | string (tosca_simple_yaml_1_2) | |
description | string | description | string | |
metadata | map of <string> | metadata | map of <string> | |
imports | Single-line grammar
Multi-line grammar
| imports | Identifies the lower level models (VFC, CP, VL, heat) | |
data_types | <data_type_name>: derived_from: <existing_type_name> version: <version_number> metadata: <map of string> description: <datatype_description> constraints: - <type_constraints> properties: <property_definitions> | data_types | <data_type_name>: derived_from: <existing_type_name> version: <version_number> metadata: <map of string> description: <datatype_description> constraints: - <type_constraints> properties: <property_definitions> | |
node_types | <node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata: <map of string> description: <node_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> capabilities: <capability_definitions> interfaces: <interface_definitions> artifacts: <artifact_definitions> | node_types | <node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata: <map of string> description: <node_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> capabilities: <capability_definitions> interfaces: <interface_definitions> artifacts: <artifact_definitions> | |
topology_template | topology_template: description: <template_description> inputs: <input_parameter_list> outputs: <output_parameter_list> node_templates: <node_template_list> relationship_templates: <relationship_template_list> groups: <group_definition_list> policies: - <policy_definition_list> workflows: <workflow_list> # Optional declaration that exports the Topology Template # as an implementation of a Node Type. substitution_mappings: <substitution_mappings> | topology_template | similar, but the following are different
| |
| string |
| string | |
|
| <parameter name>: type: <parameter_type> description: <parameter_description> required: <parameter_required> default: <parameter_default_value> constraints: - <parameter_constraints> | ||
| vnf: tosca.nodes.nfv.Vnf vdu: tosca.nodes.nfv.Vdu vl: tosca.nodes.nfv.VnfVirtualLink vduCp: tosca.nodes.nfv.VduCp vduCompute: tosca.nodes.nfv.Vdu.Compute |
| vfc: type: org.openecomp.resources.vfc.<> vl: type: org.openecomp.resources.vl.<> cp: type: org.openecomp.resources.cp.<> allotted_resource: type: org.openecomp.resource.allottedResource.<> | |
| <workflow name> | |||
policies
| tosca.datatypes.nfv.ScalingAspect
|
| list of VF Modules VFModule_Base: type: org.openecomp.groups.VfModule VFModule_Expansion: type: org.openecomp.groups.VfModule | |
| optional list of policies | |||
substitution_mappings | substitution_mappings | |||
|
| |||
| <capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ] | capabilities | <capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ] | |
|
| |||
group | not defined | group | <group_type_name>: derived_from: <parent_group_type_name> version: <version_number> metadata: <map of string> description: <group_description> properties: <property_definitions> members: [ <list_of_valid_member_types> ] requirements: - <requirement_definitions> capabilities: | |
policy | only the Abstract.SecurityGroupRule policy type is defined
| policy | <policy_type_name>: derived_from: <parent_policy_type_name> version: <version_number> metadata: <map of string> description: <policy_description> properties: <property_definitions> targets: [ <list_of_valid_target_types> ] triggers: <list_of_trigger_definitions> | |
relationship | tosca.relationships.nfv.VirtualBindsTo tosca.relationships.nfv.AttachesTo | relationship | <relationship_type_name>: derived_from: <parent_relationship_type_name> version: <version_number> metadata: <map of string> description: <relationship_description> properties: <property_definitions> attributes: <attribute_definitions> interfaces: <interface_definitions> valid_target_types: [ <capability_type_names> ] | |
annotation_type | <annotation_type_name>: version: <version_number> description: <annotation_type_description> properties: <property_definitions> | |||
annotation | <annotation_name>: type: <annotation_type> properties: <property_assignments> | |||
...