...
- Onboard ETSI SOL004 compliant VNF packages
- Support for onboarding ETSI v2.7.1 SOL004 CSAR Packages (Link to ETSI SOL004 v2.7.1 )
- Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1)
- Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model
- Support for using an ETSI v2.7.1 VNF in an ONAP Service
- Onboard ETSI SOL007 compliant Network Service Descriptor packages (stretch goal for Guilin)
- Support for Cataloging and Preserving the original SOL007 package
- Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
- Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO
- Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO
- Design ETSI SOL007 compliant Network Service Descriptor packages
- Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using VF-C as the NFVO
- Support for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external NFVO
- Support for Nested/Hierarchical ETSI SOL001 v2.7.1 Network Service Descriptor (not for Guilin)
- Design Service templates, leveraging NSDs
- Support Service templates including NSDs
...
Feature | Description |
---|---|
SDC ETSI Package Management |
|
ETSI Package Security | If the vendor package includes signature and certificate, ONAP supports the package security.
|
ETSI Package Validation |
|
...
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. | 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 |
| Yes |
| Support for editing ETSI v2.7.1 SOL001 VNF Descriptor |
| TBD |
| ||||||||||||||||||||||||||||||||||||||||||||||||
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 | 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 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 or deployment using an ETSI compliant NFVO.Support for Cataloging and Preserving the original SOL007 package ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data ModelSupport for deploying a service that contains anVNF 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 compliant Network Service using VF-C as the NFVOSupport for deploying a service that contains an ETSI SOL001 v2.7.1 compliant Network Service using an external 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. | Yes |
| 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) | Yes |
| Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model | Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model | Yes |
| Close this, expect the current SDC distribution is sufficient | 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.
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 | )
| 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:
VDU Mapping:
VF-Module Mapping:
| No | Design and generate an ETSI SOL001 v2.7.1 compliant Network Service Descriptor & package | Design and generate an ETSI SOL001 v2.7.1 compliant Network Service package
| Yes |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Support for deploying a service that contains an ETSI SOL001 for editing ETSI v2.7.1 compliant Network Service using VF-C as the NFVOSOL001 VNF Descriptor |
| Close this, expect the current SDC distribution is sufficient |
| No |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Support for using an ETSI Support for deploying a service that contains an ETSI SOL001v2.7.1 compliant Network Service using an external NFVOVNF in an ONAP Service |
| Close this, expect the current SDC distribution is sufficient |
| TBD | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Onboard ETSI SOL007 compliant Network Service Descriptor packages Support for Nested/Hierarchical ETSI SOL001 v2.7.1 Network Service Descriptor | Executive Summary - Onboard an 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) that includes references to other Network Service Descriptors 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 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. | YesNo |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Support onboarding for onboarding of Cataloging and Preserving the original SOL007 v2.7.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service | Support onboarding for onboarding ofCataloging and Preserving the original SOL007 package (Link to ETSI SOL001 v2.7.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service) | NoYes |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Onboard Design ETSI SOL004 compliant PNFSOL007 compliant Network Service Descriptor & packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant PNF - 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 SOL001 PNF Descriptor to be onboarded into ONAP for composition into an ONAP Serviceversion 2.7.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO.
Business Impact - Enables operators and service providers to use same ETSI compliant PNF packages vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are currently using ETSI packages to deploy PNFsdeveloping ETSI compatible Network Services Funding/Financial Impacts - Reduction in operations expense from using industry standard PNF packaging. Reduction in capital expense from vendors using a single packaging methodologyNSD 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 an ETSI SOL001 v2.7.1 compliant Network Service Descriptor & package | Design ETSI SOL001 NSD and generate ETSI SOL007 compliant Network Service package
| 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
SOL001 PNFD 2.7.1 Mapping to SDC AID DMJira | ||||||
---|---|---|---|---|---|---|
|
Support for mapping of ETSI SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
- use SOL001 NSD as SDC AID DM
- support only ETSI NS and NsVirtualLink only
Jira | ||||||
---|---|---|---|---|---|---|
|
Jira | ||||||
---|---|---|---|---|---|---|
|
SDC supports additional package artifact types to split ETSI packages from other non-ETSI TOSCA packages
Jira | ||||||
---|---|---|---|---|---|---|
|
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 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
|
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) 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.
Jira | ||||||
---|---|---|---|---|---|---|
|
ONAP supports vendor ETSI Package Security and validation
- If the vendor package includes signature and certificate, ONAP supports the package security
|
Jira | ||||||
---|---|---|---|---|---|---|
|
|
- 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 | ||||||
---|---|---|---|---|---|---|
|
ETSI Package Management Architecture
The diagram depicts the package management architecture.
- SDC supports SOL004 VNF/PNF package onboarding, and stores the original vendor VNF/PNF package inside the SDC package
- SOL004 package includes SOL001 VNFD/PNFD
- PNF onboarding has been tested
- SDC will support SOL007 NS package onboarding and store the original vendor NS package inside the SDC package
- NS onboarding will be supported
- NS onboarding will be tested
- SDC supports VNF/PNF package management interfaces from OSS/BSS via SOL005 Package Management APIs (TBD)
- SO supports NS package management interfaces from OSS via SOL005 Package Management APIs (TBD)
- ETSI Catalog Manager stores SOL004/SOL007 Packages for other ONAP runtime components such as SO, SOL003/SOL005 Adapters, VFC and others
- ONAP-ETSI Catalog Manager will store SOL004 packages for VNF and PNF
- ONAP-ETSI Catalog Manager will store SOL007 packages for NS
- SOL003 VNFM Adapter provides VNFMs Query/Fetch VNF packages/contents/artifacts, Reading VNFD and subscription/notification services
- SOL005 Adapter provides NS/PNF/VNF package management to VF-C/External NFVO by leveraging SOL005 package management APIs
Onboarding
SDC NS/VNF/PNF/NS Onboarding and Distribution
This section describes SDC VNF/PNF onboarding and the End-to-End package distribution from SDC to SVNFM/external NFVOs.
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
- Enhancement (Ericsson contribution) was made to the SDC Dublin to support SOL004 PNF/VNF onboarding with .zip and .csar file extensions.
- SDC VSP and Resource csar files have the ONBOARDED_PACKAGE, which contains the original vendor VNF package.
- The VNFM and external NFVO use the original vendor VNF/NS packages.
- ONAP-ETSI Catalog Manager will be changed for the location of the original vendor package.
- SOL007 NS onboarding will follow the same procedure; i.e., storing the vendor SOL007 NS package into the ONBOARDED_PACKAGE directory.
- SDC VSP and Resource csar files have the ONBOARDED_PACKAGE, which contains the original vendor VNF package.
- At onboarding, SDC checks the file extension and performs the following procedures
- If the file is .zip, SDC unzips
- If it has .cert & .cms, it is a package with security and security validation will be performed.
- If it does not include .cert & .cms, it is an existing Heat template onboarding, and SDC follows the Heat template onboarding procedure
- If the file is .zip, SDC unzips
- If the file is .csar, it is a package without security.
- Next, SDC will check the TOSCA.meta file.
- If it contains SOL004v2.x.1 keywords, the package will be handled as SOL004v2.x.1. In the Guilin release, v2.7.1 will be supported.
- Otherwise, it will be handled as existing TOSCA (non-SOL004) package onboarding which will not have the ONBOARDED_PACKAGE artifact.
NS Onboarding Design
- extend OrchestrationTemplateProcessCsarHandler.java to handle SOL007
- create ToscaSolModelDrivenConverterNS class
- create NSdNodeTemplateTransformationEngine class
- transform() to SDC AID DM NS
- create NSdNodeTemplateTransformationEngine class
- generate the SDC package for NS with the original vendor SOL007 NS package
VNF Onboarding Design
- leverage the existing SOL004 VNF onboarding mechanism
- create a transform class to transform to SDC AID DM VNF
- generate the SDC package for VNF with the original vendor SOL004 VNF package
PNF Onboarding Design
- leverage the existing SOL004 PNF onboarding mechanism
- the transformation to SDC AID DM is already done
- It is already done: generate the SDC package for PNF with the original vendor SOL004 VNF package
The following diagram depicts the onboarding procedures for VNF/NS/PNF.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Design NS
NSD Structure
SDC supports NSD design that meets the following requirements.
- The NSD shall reference the VNFDs applicable to its constituent VNFs.
- The NSD shall include the VLDs applicable to the VLs used by the NS to interconnect its constituent NFs.
- The NSD shall reference the PNFDs applicable to its constituent PNFs.
- The NSD shall include the descriptors of the VNFFGs applicable to the NS (stretch goal).
- The NSD shall support the capability to include or reference NS LCM scripts.
- The NSD shall support the capability to providing monitoring parameters to be tracked during the lifetime of a NS instance (stretch goal).
- The NSD shall support the capability to describe auto scale rules, associating criteria to scaling actions (stretch goal).
- The NSD shall include package security information enabling validating its authenticity and integrity.
- The NSD shall include a globally unique identifier for identifying each descriptor instance.
- The NSD shall include an identifier to select to controller compatible with the NSD.
- A VLD shall enable specifying the type of connectivity provided by the link between VNFs.
NSD Information Element
- SDC supports the following NSD Information Elements.
- SDC supports the netestedNsdId(s) for nested NSDs.
- SDC UI should be able to manage the NSD attributes.
- SDC supports the virtualLinkDesc(s) to define constituent VLs.
Sample Use Cases
VCPE
The following is an example of VCPE model hierarchy. In VCPE, the E2E Service model includes one NS (vCPE). And the vCPE NS model includes vbng, vbrgemu, vgmux and vgw VNFs and a network VL.
- SDC should be able to reference the vCPE NSD from the E2E Service model.
- SDC should be able to reference all the constituent VNFs and VL(s).
Other Use Case
To represent nested NS cases, we will choose another use case.
- TBD
NSD Design Process in SDC
VNF Composition
The following diagram depicts how SDC
- creates a NSD
- drags and drops constituent VFs
- generates SOL007 NS package
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
VL Composition
- SDC supports NSVLDs that are defined in the ETSI IFA 014, as part of NS design.
- SDC UI should be able to handle the following VLD attributes.
VNFD Composition
The NSD references the VNFD of a constituent VNFs.
- Drag and drops onboarded VNFs
The following depicts the VNFD information element.
SapD Composition
SapD fulfills the following information element.
Distribution
ETSI packages will be distributed from SDC to the ETSI Catalog Manager for other ONAP runtime components such as SO (SOL003/SOL005 Adapter) and VF-C.
- The original vendor package format could be one of the following.
- Vendor package including certificate and signature (Zip format)
- Vendor package without certificate and signature (CSAR format)
ETSI Catalog Manager Enhancements
ETSI Catalog Manager will interface with the SDC directly, without a help from ONAP SO.
Package Distribution Components Interactions
The following diagram depicts the ETSI package distribution.
...
ETSI Package Distribution Flows
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant OSS_BSS
participant SDC
participant ONAP_ETSI_Catalog_Mgr
participant SOL003_Adapter
participant SOL005_Adapter
participant VNFM
participant VFC
participant Ext_NFVO
autonumber
OSS_BSS -> SDC : Vendor SOL004/SOL007 package onboarding,\nincluding SOL001
SDC --> SDC : onboard SOL004/SOL007 package and put the vendor package\ninto the ONBOARD_PACKAGE directory
ONAP_ETSI_Catalog_Mgr -> SDC : register for SDC notification
SDC -> ONAP_ETSI_Catalog_Mgr : send a notification for SDC CSAR with the original vendor CSAR/Zip
ONAP_ETSI_Catalog_Mgr -> SDC : query the SDC CSAR with the SDC CSAR id
ONAP_ETSI_Catalog_Mgr --> ONAP_ETSI_Catalog_Mgr : extract SOL004/Sol007 package CSAR/Zip from the SDC CSAR \nand store it
group VNF PACKAGE TO SVNFM
ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : send a notification to SOL003_Adapter
SOL003_Adapter -> VNFM : send a notification
VNFM -> SOL003_Adapter : query for a VNF package
SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF package
ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : send a VNF package
SOL003_Adapter -> VNFM : sends a VNF package
end
group VNF PACKAGE TO Ext NFVO
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a notification to SOL005_Adapter
SOL005_Adapter -> Ext_NFVO : send a notification
Ext_NFVO -> SOL005_Adapter : query for a VNF/PNF/NS package
SOL005_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package
SOL005_Adapter -> Ext_NFVO : sends a VNF/PNF/NS package
end
group VNF PACKAGE TO VFC
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a notification to SOL005_Adapter
SOL005_Adapter -> VFC : send a notification
VFC -> SOL005_Adapter : query for a VNF/PNF/NS package
SOL005_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package
SOL005_Adapter -> VFC : sends a VNF/PNF/NS package
end
@enduml |
SDC SOL004/SOL007 VNF Package Security
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 ONBOARDED_PACKAGE directory
- If the original vendor package is a zip file with signature and certificate, the ONBOARDED_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)
NSD Mapping to SDC AID DM
Initial Input
NSD Mapping to SDC AID DM
SOL001 NSD mapping to/from NS SDC AID DM
- The SDC NSD node type, org.openecom.resource.vfc.NSD, is modelled as a component of a VF to represent an allotted resource. But, it is not derived from the org.openecomp.resource.vfc.AllottedResource, either.
- The SDC NSD might be designed for Volte use case support, and used by the VFC.
- It is recommended to deprecate the current SDC NSD node type, and to replace with SOL001 tosca.nodes.nfv.NSD node type.
- Solution:
- SDC generates SOL001 tosca.nodes.nfv.NSD node type
- SDC takes SOL001 NSD with tosca.nodes.nfv.NSD node type as is, without mapping; i.e., no mapping is necessary
- VFC uses the SOL001 NSD
VNFD Mapping to SDC AID DM
SOL001 VNF mapping to/from VNF SDC AID DM
- There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
- SDC VF node types has very few properties.
- a lot of common properties are added to each node type created by SDC
- new common properties are mainly about networking and ONAP specific properties
- There is no clear mapping logic between the current node types
- SDC creates new data type as ONAP deployment configuration.
...
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. | No |
| |||||||||
SDC supports onboarding of the SOL004 PNF package includes SOL001 PNFD
|
| No |
| |||||||||
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 |
| |||||||||
SDC Notification supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages | SDC (Notification) supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages
| No |
| |||||||||
SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages | SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages
| No |
| |||||||||
Support ETSI Package Security and validation |
| No |
| |||||||||
|
| Done | ||||||||||
|
| No |
| |||||||||
Support of ETSI Package Validation | VNF SDK will support ETSI package validation for VNF and NS | TBD | ||||||||||
VNF SDK will support ETSI VNF package pre-onboarding for validation | VNF SDK will support ETSI VNF package pre-onboarding for validation | TBD | ||||||||||
VNF SDK will support ETSI NS package pre-onboarding for validation | VNF SDK will support ETSI NS package pre-onboarding for validation | TBD |
ETSI Package Management Architecture
The diagram depicts the package management architecture.
- SDC supports SOL004 VNF/PNF package onboarding, and stores the original vendor VNF/PNF package inside the SDC package
- SOL004 package includes SOL001 VNFD/PNFD
- PNF onboarding has been tested
- SDC will support SOL007 NS package onboarding and store the original vendor NS package inside the SDC package
- NS onboarding will be supported
- NS onboarding will be tested
- SDC supports VNF/PNF package management interfaces from OSS/BSS via SOL005 Package Management APIs (TBD)
- SO supports NS package management interfaces from OSS via SOL005 Package Management APIs (TBD)
- ETSI Catalog Manager stores SOL004/SOL007 Packages for other ONAP runtime components such as SO, SOL003/SOL005 Adapters, VFC and others
- ONAP-ETSI Catalog Manager will store SOL004 packages for VNF and PNF
- ONAP-ETSI Catalog Manager will store SOL007 packages for NS
- SOL003 VNFM Adapter provides VNFMs Query/Fetch VNF packages/contents/artifacts, Reading VNFD and subscription/notification services
- SOL005 Adapter provides NS/PNF/VNF package management to VF-C/External NFVO by leveraging SOL005 package management APIs
Onboarding
SDC NS/VNF/PNF/NS Onboarding and Distribution
This section describes SDC VNF/PNF onboarding and the End-to-End package distribution from SDC to SVNFM/external NFVOs.
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
- Enhancement (Ericsson contribution) was made to the SDC Dublin to support SOL004 PNF/VNF onboarding with .zip and .csar file extensions.
- SDC VSP and Resource csar files have the ETSI_PACKAGE, which contains the original vendor VNF package.
- The VNFM and external NFVO use the original vendor VNF/NS packages.
- ONAP-ETSI Catalog Manager will be changed for the location of the original vendor package.
- SOL007 NS onboarding will follow the same procedure; i.e., storing the vendor SOL007 NS package into the ETSI_PACKAGE directory.
- SDC VSP and Resource csar files have the ETSI_PACKAGE, which contains the original vendor VNF package.
- In Guilin, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE directory.
- At onboarding, SDC checks the file extension and performs the following procedures
- If the file is .zip, SDC unzips
- If it has .cert & .cms, it is a package with security and security validation will be performed.
- If it does not include .cert & .cms, it is an existing Heat template onboarding, and SDC follows the Heat template onboarding procedure
- If the file is .zip, SDC unzips
- If the file is .csar, it is a package without security.
- Next, SDC will check the TOSCA.meta file.
- If it contains SOL004v2.x.1 keywords, the package will be handled as SOL004v2.x.1. In the Guilin release, v2.7.1 will be supported.
- Otherwise, it will be handled as existing TOSCA (non-SOL004) package onboarding which will not have the ETSI_PACKAGE artifact.
NS Onboarding Design
- extend OrchestrationTemplateProcessCsarHandler.java to handle SOL007
- processCsar()
- instantiateToscaConverterFor(resourceType).convert(fileContentHandler)
- calling ToscaSolModelDrivenConverterPNF()
- pndfTransformationEngine.transform()
- calling ToscaSolConverterVnf()
- vnfTopologyTemplateConverter().convertTopologyTemplate(serviceTemplate, readerService)
- convertInputs()
- convertNodeTemplates()
- convertOutputs()
- convertSubstitutionMappings()
- convertPolicies()
- vnfTopologyTemplateConverter().convertTopologyTemplate(serviceTemplate, readerService)
- need to call ToscaSolModelDrivenConverterNS()
- calling ToscaSolModelDrivenConverterPNF()
- instantiateToscaConverterFor(resourceType).convert(fileContentHandler)
- processCsar()
- create ToscaSolModelDrivenConverterNS class
- create NSdNodeTemplateTransformationEngine class
- transform() to SDC AID DM NS
- create NSdNodeTemplateTransformationEngine class
- generate the SDC package for NS with the original vendor SOL007 NS package
VNF Onboarding Design
- leverage the existing SOL004 VNF onboarding mechanism
- create a transform class to transform to SDC AID DM VNF
- generate the SDC package for VNF with the original vendor SOL004 VNF package
PNF Onboarding Design
- leverage the existing SOL004 PNF onboarding mechanism
- the transformation to SDC AID DM is already done
- It is already done: generate the SDC package for PNF with the original vendor SOL004 VNF package
The following diagram depicts the onboarding procedures for VNF/NS/PNF.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
- SOL004 VNF/PNF and SOL007 NS Packages are onboarded to SDC.
- SDC creates its Resource CSAR by adding ONAP-specific files and metadata according to SDC procedure.
- For VNF onboarding, SOL001 VNFD is mapped to SDC Data Model.
- For NS onboarding, SOL001 NSD is mapped to SDC Data Model. Note: the SDC NS Data Model would be SOL001 NSD-based.
- For PNF onboarding, SOL001 PNFD is mapped to SDC Data Model.
- The original SOL004 VNF/PNF and SOL007 NS packages will be stored in the ETSI_PACKAGE directory.
- SDC shall have a capability to design SOL007 NSDs and generates SOL007 NS packages
- Since SDC does not have a proper NS Model, it will follow SOL001 NSD.
- SDC embeds the Resource CSAR into its Service CSAR for distribution.
- After SDC validates the onboarded packages, the Service CSAR is distributed.
- SDC sends the package notification to DMaaP for its package notification subscribers.
- ETSI Catalog Manager receives the package notification from SDC.
- ETSI Catalog Manager queries SDC for the SDC CSAR.
- ETSI Catalog Managers examines the SDC CSAR. If the SDC CSAR contains the ETSI_PACKAGE directory, it extracts the SOL004/SOL007 packages from the directory.
- ETSI Catalog Manager stores the SOL004/SOL007 packages to its Catalog Database.
- ETSI Catalog Manager provides APIs for the SOL003/SOL005 Adapters to distribute the packages to SVNFM/NFVO.
- ETSI Catalog Manager queries SDC for the SDC CSAR.
Design NS
NSD Structure
SDC supports NSD design that meets the following requirements.
- The NSD shall reference the VNFDs applicable to its constituent VNFs.
- The NSD shall include the VLDs applicable to the VLs used by the NS to interconnect its constituent NFs.
- The NSD shall reference the PNFDs applicable to its constituent PNFs.
- The NSD shall include the descriptors of the VNFFGs applicable to the NS (stretch goal).
- The NSD shall support the capability to include or reference NS LCM scripts.
- The NSD shall support the capability to providing monitoring parameters to be tracked during the lifetime of a NS instance (stretch goal).
- The NSD shall support the capability to describe auto scale rules, associating criteria to scaling actions (stretch goal).
- The NSD shall include package security information enabling validating its authenticity and integrity.
- The NSD shall include a globally unique identifier for identifying each descriptor instance.
- The NSD shall include an identifier to select to controller compatible with the NSD.
- A VLD shall enable specifying the type of connectivity provided by the link between VNFs.
NSD Information Element
- SDC supports the following NSD Information Elements.
- SDC supports the netestedNsdId(s) for nested NSDs. (not for Guilin)
- SDC UI should be able to manage the NSD attributes.
- SDC supports the virtualLinkDesc(s) to define constituent VLs.
Use Cases for Guilin
VCPE
The following is an example of VCPE model hierarchy. In VCPE, the E2E Service model includes one NS (vCPE). And the vCPE NS model includes vbng, vbrgemu, vgmux and vgw VNFs and a network VL.
- SDC should be able to reference the vCPE NSD from the E2E Service model.
- SDC should be able to reference all the constituent VNFs and VL(s).
<example>
- Test with vGW and VGMUX with a VL first.
Latest vCPE CSARs
The latest (Frankfurt) vCPE CSARs can be retrieved from the https://git.onap.org/demo/tree/tosca/vCPE_F. There are one NS CSAR and five VNF CSARs:
- ns.csar
- infra.csar
- vbng.csar
- vbrgemu.csar
- vgmux.csar
- vgw.csar
Other Use Case
To represent nested NS cases, we will choose another use case.
- TBD
NSD Design Process in SDC
VNF Composition
The following diagram depicts how SDC
- creates a NSD, based on SOL001 NSD
- generates SDC AID DM for NS, based on SOL001 NSD
- drags and drops constituent VFs
- generates SOL007 NS package
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
VL Composition
- SDC supports NSVLDs that are defined in the ETSI IFA 014, as part of NS design.
- SDC UI should be able to handle the following VLD attributes.
VNFD Composition
The NSD references the VNFD of a constituent VNFs.
- Drag and drops onboarded VNFs
The following depicts the VNFD information element.
SapD Composition
SapD fulfills the following information element.
Distribution
ETSI packages will be distributed from SDC to the ETSI Catalog Manager for other ONAP runtime components such as SO (SOL003/SOL005 Adapter) and VF-C.
- The original vendor package format could be one of the following.
- Vendor package including certificate and signature (Zip format)
- Vendor package without certificate and signature (CSAR format)
ETSI Catalog Manager Enhancements
ETSI Catalog Manager will interface with the SDC directly, without a help from ONAP SO.
Package Distribution Components Interactions
The following diagram depicts the ETSI package distribution.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
ETSI Package Distribution Flows
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant OSS_BSS
participant SDC
participant ONAP_ETSI_Catalog_Mgr
participant SO_NFVO
participant SOL003_Adapter
participant SOL005_Adapter
participant VNFM
participant VFC
participant Ext_NFVO
autonumber
OSS_BSS -> SDC : Vendor SOL004/SOL007 package onboarding,\nincluding SOL001
SDC --> SDC : onboard SOL004/SOL007 package and put the vendor package\ninto the ONBOARD_PACKAGE directory
ONAP_ETSI_Catalog_Mgr -> SDC : register for SDC notification
SDC -> ONAP_ETSI_Catalog_Mgr : send a notification for SDC CSAR with the original vendor CSAR/Zip
ONAP_ETSI_Catalog_Mgr -> SDC : query the SDC CSAR with the SDC CSAR id
ONAP_ETSI_Catalog_Mgr --> ONAP_ETSI_Catalog_Mgr : extract SOL004/Sol007 package CSAR/Zip from the SDC CSAR \nand store it
group NS PACKAGE TO SO_NFVO
ONAP_ETSI_Catalog_Mgr -> SO_NFVO : send a notification to SO_NFVO
SO_NFVO -> ONAP_ETSI_Catalog_Mgr : query for a NS package
end
group VNF PACKAGE TO SVNFM
ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : send a notification to SOL003_Adapter
SOL003_Adapter -> VNFM : send a notification
VNFM -> SOL003_Adapter : query for a VNF package
SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF package
ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : send a VNF package
SOL003_Adapter -> VNFM : sends a VNF package
end
group NS/VNF/PNF PACKAGE TO Ext NFVO
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a notification to SOL005_Adapter
SOL005_Adapter -> Ext_NFVO : send a notification
Ext_NFVO -> SOL005_Adapter : query for a VNF/PNF/NS package
SOL005_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package
SOL005_Adapter -> Ext_NFVO : sends a VNF/PNF/NS package
end
group NS/VNF/PNF PACKAGE TO VFC
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a notification to SOL005_Adapter
SOL005_Adapter -> VFC : send a notification
VFC -> SOL005_Adapter : query for a VNF/PNF/NS package
SOL005_Adapter -> ONAP_ETSI_Catalog_Mgr : query for a VNF/PNF/NS package
ONAP_ETSI_Catalog_Mgr -> SOL005_Adapter : send a VNF/PNF/NS package
SOL005_Adapter -> VFC : sends a VNF/PNF/NS package
end
@enduml |
SDC SOL004/SOL007 VNF Package Security
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.
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
Mapping of ETSI Information NS-related Elements with TOSCA types
- For E2E (OSS Service) modeling, use org.openecomp.resource.abstract.nodes.service
- E2E (OSS Service-Level) is outside of ETSI scope, and it could be ONAP-specific that is orchestrated by ONAP SO
- The E2E (OSS Service-Level) model references/includes associated NSs
- For the E2E service level, the org.openecop.resource.abstract.nodes.service type is still used as the base type of the service. SDC will use the ETSI SOL001 NS type and attach the NSs to the E2E (OSS Service).
- For NS modeling, use tosca.nodes.nfv.NS
- ONAP SO-NFVO, VFC and external NFVO manage the NS models and packages
ONAP ETSI-Alignment Modeling Hierarchy
- 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 | ||||||
---|---|---|---|---|---|---|
|
Mapping between SOL001 Data Model and SDC AID DM
The following summarizes the mapping between two models:
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
SDC: nfv-types | SDC: heat-types | ||||||
ETSI NFV IE | SDC Descriptor / SOL001 | TOSCA Type | Derived from | SDC Descriptor | TOSCA Type | Derived from | |
---|---|---|---|---|---|---|---|
NSD | nodes.yml / SOL001 | tosca.nodes.nfv.NS | tosca.nodes.Root | Generic_Service.yml | org.openecomp.resource.abstract.nodes.service (use it for both E2E (OSS Service) and NS) | tosca.nodes.Root | |
NSD.yml | org.openecomp.resource.vfc.NSD | tosca.nodes.Root | N/A | ||||
SapD | SOL001 | tosca.nodes.nfv.Sap | tosca.nodes.Root | ||||
NsVirtualLinkDesc | SOL001 | tosca.nodes.nfv.NsVirtualLink (there is tosca.nodes.nfv.VnfVirtualLink) | tosca.nodes.Root | vl.yml | org.openecomp.resource.vl.VL | tosca.nodes.network.Network | |
extVl.yml | org.openecomp.resource.vl.extVL | tosca.nodes.Root | |||||
internalVl.yml | org.openecomp.resource.vl.internalVL | tosca.nodes.network.Network | |||||
extZteVL.yml | tosca.nodes.nfv.ext.zte.VL | tosca.nodes.Root | |||||
Pnfd | tosca.nodes.nfv.PNF | tosca.nodes.Root | Generic_PNF.yml | org.openecomp.resource.abstract.nodes.PNF | tosca.nodes.Root | ||
Vnfd | VNF.yml | tosca.nodes.nfv.VNF | tosca.nodes.Root | Generic_VF.yml | org.openecomp.resource.abstract.nodes.VF | tosca.nodes.Root | |
Vnffgd | tosca.groups.nfv.VNFFG | tosca.groups.Root | forwardingPath.yml(?) | org.openecomp.nodes.ForwardingPath | tosca.nodes.Root | ||
NSD Mapping to SDC AID DM
Initial Input
NSD Mapping to SDC AID DM
A benefit of mapping an onboarded ETSI NS to the internal representation of an ONAP Service is that the ETSI NS can access the standard ONAP runtime functionality implemented or planned for support of ONAP Services.
SOL001 NSD mapping to/from NS SDC AID DM
- ONAP previous analysis
- The SDC NSD node type, org.openecom.resource.vfc.NSD, is modeled as a component of a VF to represent an allotted resource. But, it is not derived from the org.openecomp.resource.vfc.AllottedResource, either.
- The SDC NSD might be designed for Volte use case support, and used by the VFC.
- It is recommended to deprecate the current SDC NSD node type, and to replace with SOL001 tosca.nodes.nfv.NS node type.
- Solutions
- SDC generates SOL001 tosca.nodes.nfv.NS node type
- SDC takes SOL001 NSD with tosca.nodes.nfv.NS node type as is, without mapping; i.e., no mapping is necessary
- ONAP SO NFVO uses the SOL001 NSD
- VFC needs to use the SOL001 NSD
- There could be some impact on VID and ONAP SO Catalog DB for the SOL001 NSD - to be analyzed.
- Guilin Decisions
- SDC generates SOL001 tosca.nodes.nfv.NSD node type, and uses it as SDC AID DM.
SOL001 NS
SOL001 NS (tosca.nodes.nfv.NS) - Chosen |
| |||||
---|---|---|---|---|---|---|
name | required | type | ||||
descriptor_id | yes | string | ||||
designer | yes | string | ||||
version | yes | string | ||||
name | yes | string | ||||
invariant_id | yes | string | ||||
flavor_id | yes | string | ||||
ns_profile | no | tosca.datatypes.nfv.NsProfile |
<tosca.datatypes.nfv.NsProfile>
SDC TOSCA Repository
SDC nfv-types
SDC nfv-types/NSD
SDC TOSCA repository: /catalog-be/src/main/resources/import/tosca/nfv-types/NSD/
- need to update to tosca_simple_yaml_1.2
<nodes.yml: org.openecomp.resource.vfc.NSD>
org.openecomp.resource.vfc.NSD:
derived_from: tosca.nodes.Root
description: ECOMP Allotted Resource base type all other allotted resources node types derive from
properties:
nsd_id:
type: string
required: true
description: ID of the NSD
nsd_designer:
type: string
required: true
description: Designer of the NSD
nsd_version:
type: string
required: true
description: Version of the NSD
nsd_name:
type: string
required: true
description: Name of the NSD
providing_service_uuid:
type: string
required: true
description: The depending service uuid in order to map the allotted resource to the specific service version
providing_service_invariant_uuid:
type: string
required: true
description: The depending service invariant uuid in order to map the allotted resource to the specific service version
providing_service_name:
type: string
required: true
description: The depending service name in order to map the allotted resource to the specific service version
requirements:
- virtualLink:
capability: tosca.capabilities.network.Linkable
relationship: tosca.relationships.network.LinksTo
capabilities:
virtual_linkable:
type: tosca.capabilities.network.Linkable
VNFD Mapping to SDC AID DM
SOL001 VNF mapping to/from VNF SDC AID DM
- ONAP previous analysis
- There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
- SDC VF node types has very few properties.
- a lot of common properties are added to each node type created by SDC
- new common properties are mainly about networking and ONAP specific properties
- There is no clear mapping logic between the current node types
- SDC creates new data type as ONAP deployment configuration.
- In ETSI, the descriptor_id is used to reference to the VNF, but in ONAP, the UUID is used to reference to the VNF.
- There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
- Solutions
- map between SOL001 VNF and SDC AID DM VNF selectively.
- data in the SOL001 that would be considered Cloud Provider automation data could be remained unmapped
- Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
- HPA requirements needed by OOF to determine cloud feasibility
- Input parameters passed to the Cloud provider
- ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
- UUID and invariantUUID must not be modeled as metadata type, per TOSCA YAML because the data provided within metadata, maybe ignored by TOSCA orchestrator and should not affect runtime behavior.
- Identify Cloud Provider automation-related data and remove it from the mapping
- Identify Service Provider data and map it to SDC AID DM
- ONAP SO NFVO uses SOL001 VNF; other ONAP runtime components could use the new mapped org.openecomp.resource.abstract.nodes.ETSI.VNF
- map between SOL001 VNF and SDC AID DM VNF selectively.
Current VNF Modeling in ETSI and SDC
SOL001 VNF (tosca.nodes.nfv.VNF)
| SDC AID DM VNF (org.openecomp.resource.abstract.nodes.VF)
| org.openecomp.resource.vf.vcpeInfrastructureGwDemoApp (derived from org.openecomp.resource.abstract.nodes.VF) | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
name | required | type | name | required | type | name | required | type | ||
descriptor_id | yes | string | nf_function | string | nf_function | string | ||||
descriptor_version | yes | string | nf_role | string | nf_role | string | ||||
provider | yes | string | nf_type | string | nf_type | string | ||||
product_name | yes | string | nf_naming_code | string | nf_name_code | string | ||||
software_version | yes | string | nf_naming | org.openecomp.datatyhpes.Naming | nf_naming | org.openecomp.datatyhpes.Naming | ||||
product_info_name | no | string | availability_zone_max_count | integer | availablity_zone_max_count | integer | ||||
vnfm_info | yes | list of string | min_instances | integer | min_instances | integer | ||||
localization_languages | no | list of string | max_instances | integer | max_instances | integer | ||||
default_localization_language | no | string | multi_stage_design | boolean | multi_stage_design | boolean | ||||
configurable_properties | no | tosca.datatypes.nfv.VnfconfigurableProperties | sdnc_model_name | string | vf_module_id | no | ||||
modifiable_attributes | no | tosca.datatypes.nfv.VnfInfoModifiableAttributes | sdnc_artifact_name | string | vcpe_image_name | no | ||||
lcm_operations_configuraion | no | tosca.datatypes.nfv.VnfLcmOperationsConfiguration | skip_post_instantiation_configuration | boolean (default true)
| public_net_id | no | ||||
monitoring_parameters | no | list of tosca.dataypes.nfv.VnfMonitoringParameter | controller_actor | string (default: SO-REF-DATA)
| vgw_name_0 | no | ||||
flavour_id | yes | string | nexus_artifact_repo | no | ||||||
flavour_description | yes | string | mux_ip_addr | no | ||||||
vnf_profile | no | tosca.datatyhpes.nfv.VnfProfile | vnf_id | no | ||||||
cpe_public_net_cidr | no | |||||||||
vg_vgmux_tunnel_vni | no | |||||||||
nf_naming | no | |||||||||
multi_stage_design | no | |||||||||
<tosca.datatypes.nfv.VnfProfile> | nf_naming_code | no | ||||||||
instantiation_level | no | string | vgw_private_ip_0 | no | ||||||
min_number_of_instances | yes | integer | vgw_private_ip_1 | no | ||||||
max_number_of_instances | yes | integer | vgw_private_ip_2 | no | ||||||
pub_key | no | |||||||||
install_script_version | no | |||||||||
onap_private_net_cidr | no | |||||||||
cpe_public_net_id | no | |||||||||
mux_gw_private_net_id | no | |||||||||
dcae_collector_ip | no | |||||||||
dcae_collector_port | no | |||||||||
onap_private_net_id | no | |||||||||
cloud_env | no |
Solutions:
There are two options. For now, we chose the option A. The option B is under discussion.
Option A (chosen):
Define a new data type based on the org.openecomp.resource.abstract.nodes.VF with ETSI SOL001 VNF data type attributes.
- Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
- During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VNF
- In Guilin, SO NFVO, VFC and SVNFM get those SOL001 VNF attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
- SOL001 VNF attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Guilin.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
- For the Honolulu release, it is under consideration
- to sync up between those modified SOL001 VNF attributes and the vendor ETSI Package attributes
- to reflect those modified SOL001 VNF attributes in the orchestration
- ONAP specific attributes that are inherited from the org.openecomp.resource.abstract.nodes.VF will be filled up by SDC (design time)
- Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied
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)
| ||||
Option B:
Define a new data type based on the tosca.nodes.nfv.VNF with SDC AID DM VNF data type attributes.
SDC AID DM VNF data type attributes will be handled as the 'additionalAttributes', which is a map of key, value pairs.Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied.
| ||
---|---|---|
SOL001 VDU mapping to/from VNF SDC AID DM VFC
Current SOL001 VDU vs. SDC AID DM VFC
- no 1:1 mapping
- note: the SDC AID DM VFC represents design-time VFC (like VDU), not VFC instances in runtime
SOL001 VDU | SDC AID DM VFC (org.openecomp.resource.abstract.nodes.VFC) | ||||
---|---|---|---|---|---|
Name | Required | Type | Name | Required | Type |
name | yes | string | nfc_function | string | |
description | yes | string | high_availability | no | string |
boot_order | no | boolean | vm_image_name | string | |
nfvi_constraints | no | map of string | vm_flavor_name | yes | string |
monitoring_parameters | no | list of tosca.datatypes.nfv.VnfcMonitoringParameter | nfc_naming_code | no | string |
configurable_properties | no | map of tosca.datatypes.nfv.VnfcConfigurableProperties | vm_type_tag | no | string |
boot_data | no | tosca.datatypes.nfv.BootData | nfc_naming | org.openecomp.datatypes.Naming
| |
vdu_profile | yes | tosca.datatypes.nfv.VduProfile | min_instances | no | integer |
sw_image_data | no | tosca.datatypes.nfv.SwImageData | |||
Solutions for VDU and VFC mapping
- Make the org.openecomp.resource.abstract.nodes.ETSI.VFC a superset of both tosca.nodes.nfv.Vdu and org.openecomp.resource.abstract.nodes.VFC
- Note: the org.openecomp.resource.abstract.nodes.VFC represents design-time VFC, not VFC instances
- During VNF onboarding, SDC copies SOL001 VDU attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VFC
- In Guilin, SO NFVO, VFC and SVNFM get those SOL001 VDU attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
- SOL001 VDU attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Guilin.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
- For the Honolulu release, it is under consideration
- to sync up between those modified SOL001 VDU attributes and the vendor ETSI Package attributes
- to reflect those modified SOL001 VDU / VFC attributes in the orchestration
New SDC AID DM VFC type (org.openecomp.resource.abstract.nodes.ETSI.VFC)
SOL001 VDU | Mapping | org.openecomp.resource.abstract.nodes.ETSI.VFC (derived from org.openecomp.resource.abstract.nodes.VFC) | ||||
---|---|---|---|---|---|---|
Name | Required | Type | <--> | Name | Required | Type |
name | yes | string | <--> | name | yes | string |
description | yes | string | <--> | description | yes | string |
boot_order | no | boolean | <--> | boot_order | no | boolean |
nfvi_constraints | no | map of string | <--> | nfvi_constraints | no | map of string |
monitoring_parameters | no | list of tosca.datatypes.nfv.VnfcMonitoringParameter | <--> | monitoring_parameters | no | list of tosca.datatypes.nfv.VnfcMonitoringParameter |
configurable_properties | no | map of tosca.datatypes.nfv.VnfcConfigurableProperties | <--> | configurable_properties | no | map of tosca.datatypes.nfv.VnfcConfigurableProperties |
boot_data | no | tosca.datatypes.nfv.BootData | <--> | boot_data | no | tosca.datatypes.nfv.BootData |
vdu_profile | yes | tosca.datatypes.nfv.VduProfile | <--> | vdu_profile | yes | tosca.datatypes.nfv.VduProfile |
sw_image_data | no | tosca.datatypes.nfv.SwImageData | <--> | sw_image_data | no | tosca.datatypes.nfv.SwImageData |
<SDC AID DM VFC attributes that are inherited from the org.openecomp.resource.abstract.nodes.VFC> | ||||||
nfc_function | no | string | ||||
high_availability | no | string | ||||
vm_image_name | no | string | ||||
vm_flavor_name | no | string | ||||
nfc_naming_code | no | string | ||||
vm_type_tag | no | string | ||||
nfc_naming | no | org.openecomp.datatypes.Naming
| ||||
min_instances | no | integer |
SOL001 2.7.1 VNFD Mapping from/to SDC AID DM VNFD
SOL001 2.7.1 VNFD Template
tosca_definitions_version: tosca_simple_yaml_1_2
description:
imports:
data_types:
node_types:
topology_template:
inputs:
node_templates:
VNF
substitution_mappings:
capabilities:
requirements:
SDC VFD Template
tosca_definitions_version: tosca_simple_profile_for_ecomp_1_0
descriptions:
imports:
data_types:
node_types:
topology_template:
inputs:
node_templates:
vfc:
type: org.openecomp.resource.vfc
extCP:
type: org.openecomp.resources.cp
groups:
VFModule_Base:
type: org.openecomp.groups.VfModule
VFModule_Expansion:
type: org.openecomp.groups.VfModule
workflows:
policies:
anti_collated_az_policy:
substitution_mappings:
node_type: org.openecomp.resources.vf.<vf_name>
capabilities:
requirements:
SOL001 VNFD mapping to/from SDC AID DM VFD
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> | |||
VF-Module Initial Input
The following is a summary of initial input from Gil Bullard (AT&T).
Mapping Scope Challenges and Suggestions
ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
- See the ONAP MultiVim Proposal on the separation of concerns.
- SDC AID was created before a separation of concerns was envisioned, thus there are data structures in the SDC AID that would be considered Cloud Provider automation data and that we would likely take out of the SDC AID.
- Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
- HPA requirements needed by OOF to determine cloud feasibility
- Input parameters passed to the Cloud provider
- There is probably some data in the SOL001 that would be considered Cloud Provider automation data. Any such data could remain unmapped
- SOL001 content needed to drive ONAP automation (SO, OOF, SDNC, AAI, DCAE, etc.) would need to be mapped
- Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
- The VNFM should not be aware of the VF Module structure, though the current SO-SDNC interactions to get assignment are by VF Module, and the VF Module entity plays prominent in AAI. That means there needs to be two adaptation points as we have discussed:
- An SDC function to extract VF Module information from the SOL001 VNFD prior to distribution to runtime
- A VNFM Adapter function to flatten the VF Module structure prior to handoff to the VNFM
VF-Module Deduction from SOL001
- There is an assumption that SDC transforms the vendor provided VNF package into ONAP-compliant one; i.e., deducing VF Modules based on VNFD ScalingAspects and Delta.
- If SDC supports the transformation in Dublin time-frame, the transformed CSAR will be imported to SO, and SO VNF- and VF-Module-level workflows will manage VNF and VF Module topology towards SDNC with the following changes - Input from Gil Bullard (AT&T)
- Today the VNF-level workflow has an embedded per-VF Module loop that a) retrieves the SDNC assignments for that VF Module, and then b) sends those VF Module-level assignments down to the VIM (e.g., OpenStack); the loop then moves to repeat "a" with the next VF Module.
- The new VNF-level flow will have the following sequences:
- an embedded per-VF Module loop that only retrieves the SDNC assignments for each VF Module; because the VIM is hidden from SO's sight, beneath the VNFM Adapter/VNFM.
- After finishing the loop, the SO workflows will send a structure to the VNFM Adapter that includes the aggregate assignments at the VNF level.
- The VNFM Adapter aggregates all the VF-Module level assignments and transforms the assignment data into SOL003 API parameters before sending them to SVNFM
- The VNFM Adapter would need to be able to parse the VNF-level assignments structure received from SO to obtain the per-VDUconnection point assignments information and any per-VDU parameter information (e.g., hostnames)
- In doing so, the VNFM Adapter would need to know to ignore the VF Module groupings of these assignments
- Further know how to map the ONAP data structure and parameter names into the ETSI (e.g., VM=VDU, VNFC=VNFC, vNIC=vNIC, etc.). Note that the above assumes that in ONAP, as in ETSI, there will be a one-to-one correspondence between VM/VDU and VNFC.
Assumptions for deducing VF-Module from SOL001 (Gil Bullard's input)
- SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
- SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
- SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
- ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
- ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.
- In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
- What to do
- ONAP will be extended to incorporate the constructs of Aspect and Scaling Level. This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect.
- If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD. (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. ) However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below. “Structure” in this case includes the VDU topology, connection points and associated parameters. This algorithm will:
- Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
- Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
- Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
- Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
- Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
- Determine if there is an artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived. If so, associate that HOT file with the VF Module.
- Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
- Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
- Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
- Note: As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.
Solution:
- SDC deduces the VF-Module from the SOL001 VNFD Policies>scaling_aspects>properties>aspects
- Additional VF-Module attributes are deduced as the following table
- SOL003 Adapter may need to transform the VF-Module back to the SOL001 VNFD policies for the scaling and healing requests from VNFM(s) – not part of Guilin
Gliffy Diagram macroId 4e072032-7cad-4d7d-befc-a60416101d10 name ONAP ETSI-Alignment VF-Module Mapping pagePin 7
macroId | 4e072032-7cad-4d7d-befc-a60416101d10 |
---|---|
name | ONAP ETSI-Alignment VF-Module Mapping |
pagePin | 7 |
org.openecomp.group.VfModule Attribute and SOL001 VNF Policies deduction
Name | Required | Type | SOL001 VNFD Policies |
vf_module_type | yes | string valid values: Base, Expansion | Base default: Base |
vf_module_label | yes | string | aspects: <A> |
min_vf_module_instances | yes | integer | initial_delta: 0 |
max_vf_module_instances | no | integer | max_scale_level |
initial_count | yes | integer | initial_data: number_of_instances |
vf_module_description | no | string | aspects: description |
volume_group | yes | Boolean | default to false |
group_naming | no | org.openecomp.datatypes.Naming | optional field, leave it empty |
VirtualLink Mapping to SDC AID DM
SOL001 VL mapping to/from VL SDC AID DM
- ONAP previous analysis
- Each vendor/operator defined their own VL node types (e.g., tosca.nodes.nfv.ext.zte.VL)
- The vendor/operator-specific node types have no direct 1:1 mapping to tosca.nodes.nfv.NsVirtualLink
- Solutions
- Deprecate vendor/operator-specific VLs
- Use SOL001 tosca.nodes.nfv.NsVirtualLink
- ONAP SO NFVO uses the SOL001 tosca.nodes.nfv.NsVirtualLink
- VFC needs to adapt SOL001 tosca.nodes.nfv.NsVirtualLink
SOL001 VL
<tosca.nodes.nfv.NsVirtualLink>
<tosca.datatypes.nfv.NsVlProfile>
<tosca.datatypes.nfv.ConnectivityType>
<tosca.datatypes.nfv.LinkBitrateRequirements>
<tosca.datatypes.nfv.NsVirtualLinkQos>
<tosca.datatypes.nfv.ServiceAvailability>
Current SDC VL
<tosca.nodes.nfv.ext.zte.VL>
tosca.nodes.nfv.ext.zte.VL | ||
---|---|---|
name | required | type |
segmentation_id | false | string |
network_name | false | string |
is_predefined | false | boolean |
mtu | false | integer |
dns_nameservers | false | list |
physical_network | false | string |
dhcp_enabled | false | boolean |
network_id | false | string |
host_routes | false | list |
ip_version | false | integer |
vendor | false | string |
name | false | string |
start_ip | false | string |
vlan_transparent | false | boolean |
cidr | false | string |
gateway_ip | false | string |
network_type | false | string |
end_ip | false | string |
location_info | false | tosca.datatypes.nfv.ext.LocationInfo |
tosca.nodes.nfv.ext.zte.VL:
derived_from: tosca.nodes.Root
description: Ext ZTE VL
properties:
segmentation_id:
type: string
required: false
network_name:
type: string
required: false
is_predefined:
type: boolean
required: false
mtu:
type: integer
required: false
dns_nameservers:
type: list
required: false
entry_schema:
type: string
physical_network:
type: string
required: false
dhcp_enabled:
type: boolean
required: false
network_id:
type: string
required: false
host_routes:
type: list
required: false
entry_schema:
type: tosca.datatypes.nfv.ext.HostRouteInfo
ip_version:
type: integer
required: false
vendor:
type: string
required: false
name:
type: string
required: false
start_ip:
type: string
required: false
vlan_transparent:
type: boolean
required: false
cidr:
type: string
required: false
gateway_ip:
type: string
required: false
network_type:
type: string
required: false
end_ip:
type: string
required: false
location_info:
type: tosca.datatypes.nfv.ext.LocationInfo
required: false
capabilities:
virtual_linkable:
type: tosca.capabilities.nfv.VirtualLinkable
occurrences:
- 1
- UNBOUNDED
valid_source_types: [
]
PNF Mapping to SDC AID DM
SOL001 PNF mapping to/from VL SDC AID DM
...
VF-Module Initial Input
The following is a summary of initial input from Gil Bullard (AT&T).
Mapping Scope Challenges and Suggestions
ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
- See the ONAP MultiVim Proposal on the separation of concerns.
- SDC AID was created before a separation of concerns was envisioned, thus there are data structures in the SDC AID that would be considered Cloud Provider automation data and that we would likely take out of the SDC AID.
- Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
- HPA requirements needed by OOF to determine cloud feasibility
- Input parameters passed to the Cloud provider
- There is probably some data in the SOL001 that would be considered Cloud Provider automation data. Any such data could remain unmapped
- SOL001 content needed to drive ONAP automation (SO, OOF, SDNC, AAI, DCAE, etc.) would need to be mapped
- Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
- The VNFM should not be aware of the VF Module structure, though the current SO-SDNC interactions to get assignment are by VF Module, and the VF Module entity plays prominent in AAI. That means there needs to be two adaptation points as we have discussed:
- An SDC function to extract VF Module information from the SOL001 VNFD prior to distribution to runtime
- A VNFM Adapter function to flatten the VF Module structure prior to handoff to the VNFM
VF-Module Deduction from SOL001
- There is an assumption that SDC transforms the vendor provided VNF package into ONAP-compliant one; i.e., deducing VF Modules based on VNFD ScalingAspects and Delta.
- If SDC supports the transformation in Dublin time-frame, the transformed CSAR will be imported to SO, and SO VNF- and VF-Module-level workflows will manage VNF and VF Module topology towards SDNC with the following changes - Input from Gil Bullard (AT&T)
- Today the VNF-level workflow has an embedded per-VF Module loop that a) retrieves the SDNC assignments for that VF Module, and then b) sends those VF Module-level assignments down to the VIM (e.g., OpenStack); the loop then moves to repeat "a" with the next VF Module.
- The new VNF-level flow will have the following sequences:
- an embedded per-VF Module loop that only retrieves the SDNC assignments for each VF Module; because the VIM is hidden from SO's sight, beneath the VNFM Adapter/VNFM.
- After finishing the loop, the SO workflows will send a structure to the VNFM Adapter that includes the aggregate assignments at the VNF level.
- The VNFM Adapter aggregates all the VF-Module level assignments and transforms the assignment data into SOL003 API parameters before sending them to SVNFM
- The VNFM Adapter would need to be able to parse the VNF-level assignments structure received from SO to obtain the per-VDUconnection point assignments information and any per-VDU parameter information (e.g., hostnames)
- In doing so, the VNFM Adapter would need to know to ignore the VF Module groupings of these assignments
- Further know how to map the ONAP data structure and parameter names into the ETSI (e.g., VM=VDU, VNFC=VNFC, vNIC=vNIC, etc.). Note that the above assumes that in ONAP, as in ETSI, there will be a one-to-one correspondence between VM/VDU and VNFC.
Assumptions for deducing VF-Module from SOL001 (Gil Bullard's input)
- SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
- SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
- SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
- ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
- ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.
- In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
- What to do
- ONAP will be extended to incorporate the constructs of Aspect and Scaling Level. This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect.
- If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD. (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. ) However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below. “Structure” in this case includes the VDU topology, connection points and associated parameters. This algorithm will:
- Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
- Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
- Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
- Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
- Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
- Determine if there is an the artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived. If so, associate that HOT file with the VF Module.
- Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
- Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
- Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
- Note: As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.
VirtualLink Mapping to SDC AID DM
SOL001 VL mapping to/from VL SDC AID DM
...