ETSI Package Management (SDC Enhancements) - Honolulu

Support Onboard ETSI 3.3.1 SOL004 compliant VNF / CNF packages

• Executive Summary- Enable a vendor provided ETSI SOL004 v3.3.1 compliant VNF package including an ETSI SOL001 VNF / CNF Descriptor to  be onboarded into ONAP for composition into an ONAP Network Service
  • Support for onboarding ETSI v3.3.1SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1
  • Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptor with minimum CNF enhancements from 4.1.1
  • Support for mapping of ETSI v3.3.1 SOL001 VNF Descriptor with CNF enhancements into SDC AID Data Model
• 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 v3.3.1 SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1

• SDC users need to onboard ETSI v3.3.1 SOL004 VNF CSAR Packages with minimum CNF enhancements from 4.1.1
  • Manifest File (e.g., MainServiceTemplate.mf): a new non-MANO artifact set identifier "onap_cnf_helm" - This would identify the "top-level" helm chart that can be used to deploy the CNF directly, i.e., without utilizing the LCM info the VNF Descriptor
    • e.g., onap_cnf_helm:

                            source: Artifacts/helm/helm_charts.yaml

• note: to support the direct path, the VNFD could be optional (under discussion with ETSI NFV and ONAP Direct Path team)

• SDC users should be also able to onboard the existing ETSI v2.6.1 SOL004 CSAR packages - one level backward compatibility needs to be supported
• For backward compatibility support, SDC needs to check the package manifest file and metadata such as "compatible_specifcation_versions".
  • If it is 3.3.1+, SDC needs to follow a new onboarding path for the ETSI 3.3.1 version package.
  • If the version is prior to 3.3.1, SDC follows the existing 2.x onboarding path. 
• The package version and its descriptor version should match.

• Determine the onboarding path based on the manifest file and metadata "compatible_specification_versions"
• If the version is prior to 3.3.1, invoke the existing 2.x SOL004 VNF package onboarding path
• Otherwise, invoke a new SOL004 VNF package onboarding path
• SDC users should be able to choose the onboarding package version from SDC UI Category selection...to be discussed...

• Create a new onboarding path for 3.3.1
  • Check the CSAR structure differences between 2.7.1 and 3.3.1
• Handle additional artifacts for CNF, such as Helm Charts, Container Image file(s)
  • For the Non-ETSI CNF, handle an optional VNFD case
  • Handle container image files with the limited file size (up to 2MB); larger files will not be handled in this release; support of larger files requires huge effort (AMDOC's help is needed)

Support for onboarding ETSI v3.3.1 SOL001 VNF Descriptors 

• SDC users need to onboard ETSI v3.3.1 SOL001 VNF Descriptors
• SDC users should be also able to onboard the existing ETSI v2.6.1/v2.5.1 SOL001 VNF Descriptors - one level backward compatibility needs to be supported
• For backward compatibility support, SDC needs to recognize the properties changes (e.g., use the VNF package version) for the Version indication. 
• SDC uses a separate onboarding process depending on the version.

• Determine the onboarding path based on the VNFD package version "compatible_specifcation_versions"
• If the version is v2.6.1/v2.5.1, invoke the existing SOL001 VNF onboarding
• Otherwise, invoke a new SOL001 VNFD onboarding path

• Create a new onboarding path for 3.3.1 VNFD
  • Check the VNFD differences between 2.5.1/2.7.1 and 3.3.1
  • Share the common/base SDC data type and node type to represent both 3.3.1 and 2.x; i.e., merge two structures for minimum impact
  • Note: This is the current SDC limitation without versioning, and it will be handled separately in the future.

SDC users need to onboard ETSI 3.3.1 with minimum CNF enhancements from 4.1.1

1. Add tosca.nodes.nfv.VDU.OsContainer type to vnfd_types - aligned with the IFA011 v4.1.1 specification
2. Add mciopProfile type vnfd_types - aligned with the IFA011 v4.1.1 specification
3. Allow OsContainerDesc to be in the VDU section - only one of tosca.nodes.nfv.VDU.osContainer or  tosca.nodes.nfv.VDU.compute in a VNFD
4. Allow mciopProfile in VNF Descriptor

• SDC needs to support new CNF properties / classes / schema / data models based on defined Information Models
• SDC may use a separate onboarding process for CNF
• No backward compatibility for CNF support is necessary

Support the vnfd_type with CNF attributes from 4.1.1:

1. Add tosca.nodes.nfv.VDU.OsContainer type to vnfd_types - aligned with the IFA011 v4.1.1 specification
2. Add mciopProfile type vnfd_types - aligned with the IFA011 v4.1.1 specification
3. Allow OsContainerDesc to be in the VDU section - only one of tosca.nodes.nfv.VDU.osContainer or  tosca.nodes.nfv.VDU.compute in a VNFD
4. Allow mciopProfile in VNF Descriptor

Design ETSI SOL007 compliant Network Service Descriptor packages

• Executive Summary- Design, catalog and distribute  an ETSI SOL007 v3.3.1 compliant Network Service Descriptor package including an ETSI v3.3.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO.
  • Support for designing an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO
  • Compose of one or more VNFs and the Virtual Links that connect them.
  • Support for using VNFs with CNF enhancements
• Business Impact- Enables operators and service providers to use internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility.
• Business Markets- All operators and service providers that are developing and deploying 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 for designing an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO

SDC users need to design an ETSI SOL001 v3.3.1 compliant Network Service that can be deployed with an ETSI compliant NFVO

• SDC needs to support backward compatibility for 2.5.1/2.6.1?
• SDC users need to create NS 
• SDC users need to generate SOL007 NS package

Generate v3.3.1 SOL007 NS package

• No backward compatibility is necessary

Compose of one or more VNFs and the Virtual Links that connect them

SDC users need to compose one or more VNFs and the Virtual Links that connect them in NS

• The NSD and its referenced VNF / CNF versions should be matched. 
• During SDC references VNFs, SDC needs to validate the version of VNFs / CNF, based on the VNF / CNF descriptor metadata (version indicator in the metadata)
  • After 2.6.1, there is a version indicator in the metadata

Note:  cover the VNF version validation... SAP descriptor has a version...

Enhance SDC to allow compose v3.3.1 VNFs and VLs for v3.3.1 NS

Validate NSD and VNFD version match

• The versions of NS and sub models should be matched  

Support for compose VNFs with CNF enhancements

SDC users need to compose VNFs with CNF enhancements

note: virtual CPD ... version... TBD