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


The following slide deck provides a summary of ETSI SOL001 Data Mapping to SDC AID DM.

Please review this slide deck for the modeling team's approval poll.

Current status: reviewed it with both SDC and AAI, and SDC and AAI approved this proposal. Waiting for the Modeling team's approval.



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



ONAP ETSI-Alignment Modeling Hierarchy

  • For OSS Service-level modeling, continue to use org.openecomp.resource.abstract.nodes.service
  • For NS modeling, use SOL001 tosca.nodes.nfv.NS as SDC AID DM NS node type
  • The OSS-Service model references/includes associated NSs (1:M)
  • In ONAP, tosca.nodes.nfv.NS references, a new VNF node type, org.openecomp.resource.abstract.nodes.ETSI.VNF (1:M) and a new PNF node type, org.openecomp.resource.abstract.nodes.ETSI.PNF (1:M) are used
  • In ONAP, tosca.nodes.nfv.NS includes SOL001 tosca.nodes.nfv.NsVirtualLink (1:M)


NS Mapping

  • SDC adopts SOL001 tosca.nodes.nfv.NS node type as the SDC NS node type; i.e., no mapping is necessary
    • A new SDC SOL007 Design process generates SOL001 tosca.nodes.nfv.NS for the NS node type
    • A new SDC SOL007 Onboarding process (stretch goal) copies the onboarded SOL001 tosca.nodes.nfv.NS contents to SDC AID DM tosca.nodes.nfv.NS contents
  • The following covers the properties. Handling/Mapping of Requirements and Interfaces are under discussion.



NS-Level VirtualLink (between VNFs) Mapping

  • SDC adopts SOL001 tosca.nodes.nfv.NsVirtualLink node type for the SDC NS-level VirtualLink node type; i.e., no mapping is necessary
    • A new SDC SOL007 Design process generates SOL001 tosca.nodes.nfv.NsVirtualLink for the VirtualLink node type, and includes it in the NSD
    • A new SDC SOL007 Onboarding process copies the onboarded SOL001 tosca.nodes.nfv.NsVirtualLink to SDC AID DM tosca.nodes.nfv.NsVirtualLink
    • SDC deprecates vendor/operator-specific VLs from SOL007 design and onboarding



VNF Mapping

  • SDC adopts a new VNF node type, org.openecomp.resource.abstract.nodes.ETSI.VNF, which is derived from org.openecomp.resource.abstract.nodes.VF.
    • Merge of SOL001 VNF SDC VF node type attributes
    • Non-ETSI modeling continues to use the existing org.openecomp.resource.abstract.nodes.VF
    • ETSI VNF Design/Onboarding process uses the new VNF node type, org.openecomp.resource.abstract.nodes.ETSI.VNF as SDC AID DM VF
  • For SOL001 VNF to SDC AID DM VNF mapping, SDC copies SOL001 VNF attributes to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VNF.
  • SOL001 VNF attributes in SDC AID DM will be visible from SDC UI, so those attributes can be changed by SDC UI.
    • But the onboarded vendor ETSI package will not be changed by the SDC UI users in Guilin.
    • In Honolulu, the sync-up behavior will be be considered.
  • For the reverse mapping, only the corresponding SOL001 VNF attributes will be copied
  • In Guilin, SO NFVO, VFC and SVNFM get the SOL 001 attributes from descriptors, not from AAI
    • AAI schema changes are not expected in Guilin
  • The following covers the properties. Handling/Mapping of Requirements and Interfaces are under discussion.



VDU and VFC Mapping

  • SDC adopts a new VFC node type, org.openecomp.resource.abstract.nodes.ETSI.VFC, which is derived from org.openecomp.resource.abstract.nodes.VFC
    • Non-ETSI modeling continues to use the existing org.openecomp.resource.abstract.nodes.VFC
    • ETSI VNF Onboarding process uses the new VDU node type, org.openecomp.resource.abstract.nodes.ETSI.VFC for SDC AID DM VFC
    • SDC copies SOL001 VDU attributes to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VFC.
  • SOL001 VDU attributes in SDC AID DM will be visible from SDC UI, so those attributes can be changed by SDC UI.
    • But the onboarded vendor ETSI package will not be changed by the SDC UI users in Guilin.
    • In Honolulu, the sync-up behavior will be be considered.
  • In Guilin, SO NFVO, VFC and SVNFM get the SOL 001 attributes from descriptors, not from AAI
    • AAI schema changes are not expected in Guilin
  • Note: org.openecomp.resource.abstract.nodes.VFC represents design-time VFC, not VFC instances



Mapping between SOL001 Data Model and SDC AID DM Overall Summary

  • Overall Mapping Summary



SOL001 VNFD and SDC AID DM VF Template Mapping

  • Templates between SOL001 VNFD and SDC AID DM are similar, but the contents of node_templates and groups are different



VF-Module Deduction from SOL001 VNFD

  • 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



For more details (rationale, history, design, epics), please see the ETSI Package Management (SDC Enhancements)- Guilin#SOL001MappingtoSDCAIDDM.











  • No labels

1 Comment

  1. Thinh Nguyenphu

    Enclosed attachment includes my review comments of the proposal. Thinh