Uploaded image for project: 'ONAP Architecture Committee'
  1. ONAP Architecture Committee
  2. ONAPARC-390

ONAP tracking of VNF dependency on an external ETSI compliant VNF Manager (VNFM)


      An ONAP Service may be defined which references a VNF which needs to be deployed and managed by an external VNFM. There may be many instances of external orchestrators with varying lifetimes. Any LCM operation on the VNF instance will need to use the same external VNFM instance. In order to accomplish this, ONAP needs to maintain the relationship between the VNF instance and the external VNFM that was used to deploy that VNF instance.  A proposed mechanism would be to store a reference to the specific external VNFM instance in the VNF instance record.

      Byung-Woo Jun:

      The tracking which VNFM instance managed which VNF instance is resolved under the SO VNFM Adapter in Dublin by setting A&AI DB Edge rules:

      • AAI: Trace which VNFM instance managed which VNF instance, the following rule will be added to A&AI DB Edge (DbEdgeRules_esr_v15.json, DbEdgeRules_esr_v16.json).
        • { "from": "generic-vnf", "to": "esr-vnfm", "label": "tosca.relationships.DependsOn", "direction": "OUT", "multiplicity": "MANY2ONE", "contains-other-v": "NONE", "delete-other-v": "NONE", "prevent-delete": "NONE", "default": "true", "description":"" }
      • SO: SO VNFM Adapter updates the relationship between generic-vnf and esr-vnfm based on the rule.


            byungwoojun byungwoojun
            foliveira foliveira
            0 Vote for this issue
            2 Start watching this issue