Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

    • 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:
        1. 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.
        2. After finishing the loop, the SO workflows will send a structure  to the VNFM Adapter that includes the aggregate assignments at the VNF level.
        3. The VNFM Adapter aggregates all the VF-Module level assignments and transforms the assignment data into SOL003 API parameters before sending them to SVFNMSVNFM
          1. The VNFM Adapter would need to be able to parse the VNF-level assignments structure received from SO to obtain the per-VDU connection point assignments information and any per-VDU parameter information (e.g., hostnames)
          2. In doing so, the VNFM Adapter would need to know to ignore the VF Module groupings of these assignments
          3. 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.

...

      • VNFM Adapter supports VNF Package Management Interface
        • Accepts the "Get VNF packages" request and returns VnfPkgInfo[]
        • Accepts the "Get VNFD" request and returns Vnfd
        • Accepts the "Get VNF artifact" request and return Artifact file


    • Design


      • Getting multiple VNF packages


        • VNFM queries information about multiple VNF packages  (VNFM → VNFM Adapter); GET .../vnf_packages
        • VNFM Adapter returns a "200 OK" response and includes in the payload body zero or more data structures of type "VnfPkgInfo" (VNFM Adapter → VNFM); 200 OK (VnfPkgInfo[])


      • Getting a particular VNF Package


        • VNFM sends a GET request to the "Individual VNF package" resource (VNFM → VNFM Adapter); GET .../vnf_packages/{vnfPkgId}
        • VNFM Adapter returns a "200 OK" response and includes in the payload body a data structure of type "VnfPkgInfo" (VNFM Adapter → VNFM); 200 OK (VnfPkgInfo)


      • Reading the VNFD of an onboarded VNF Package


        • VNFM sends a GET request to the "VNFD in an individual VNF package" resource (VNFM → VNFM Adapter); GET .../vnf_packages/{vnfPkgId}/vnfd
        • VNFM Adapter returns a "200 OK" response and includes a copy of the VNFD from the VNF package in the payload body (VNFM Adapter → VNFM); 200 OK (Vnfd)


      • Fetching a VNF package artifact

        • VNFM sends a GET request to the "Individual VNF package artifact" resource (VNFM → VNFM Adapter); GET .../vnf_packages/{vnfPkgId}/artifacts/{artifactPath}
        • VNFM Adapter returns a "200 OK" response, and includes a copy of the applicable artifact file from the VNF package in the payload body (VNFM Adapter → VNFM); 200 OK (artifact file)
      • Package management subscription and notification are not consider at this time, future consideration.

        TBD


  • VNFM Adapter Locating SVNFM

...