Once SDC onboards an ETSI v3.3.1 SOL001 VNF Descriptor, SDC needs to map the ETSI v3.3.1 SOL001 VNF Descriptor into SDC AID Data Model

• No backward compatibility ; SDC supports only ETSI 3.3.1 VNFD mapping to SDC AID DM

VNF Mapping:

• 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

VDU 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

VF-Module Mapping:

• 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)

SDC supports Interface mapping to SDC AID DM for creating Service and connect VNF to external networking, etc. ... TBD

for capacity and requirements, we need to investigate how SDC / ONAP uses... TBD