Versions Compared

Old Version 24

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version 25

changes.mady.by.user Byung-Woo Jun

Saved on

Key

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

...

    • Use Cases
    • SOL001/SOL004 Support
    • SOL003 API Support
    • SO VNFM Adapter SOL003 API Support Design
    • VNFM Adapter VNF Package Management
    • SO BPMN Infra & VNFM Adapter Run-time Scenario
    • SDNC Assignment Management
    • VNFM Adapter Locating SVNFM
    • VNF Life-cycle Granting
    • VNFM Adapter Homing Decision for VNF Granting
    • VNF and VF-Module Deduction


  • Use Cases


    • TBD

  • SOL001/SOL004 Support & Design

    • CSAR Import, Store and Retrieve Sequences 

Image Removed

    1. SO SDC Controller gets a SOL004 VNF package with an SOL001 VNFD
    2. SO SDC Controller stores a VNF CSAR file reference to the SO Catalog DB (e.g., TOSCA_CSAR database table)
    3. VNFM Adapter gets a CSAR package URL from the SO TOSCA_CSAR database table
    4. VNFM Adapter gets an original CSAR package file from the SDC repository
      1. It is assumed that the Adapter retrieves the original vendor provided CSAR package from SDC repository directory before it passes the package to SVNFM, where SVNFM handles the original CSAR. For that, SDC copy the full original package.
      2. There would be two CSAR packages for a service: one original package, one SDC transformed package.
      3. VNFM Adapter passes the original CSAR package to SVNFM because the SVNFM is outside of ONAP and is designed to handle the vendor CSAR package.

Note: SO future release could consider SOL001/SOL004 internal representation in its Catalog DB, or using the Run-time Catalog DB

  • Design

    • TBD

  • VNFM Adapter Run-time Scenarios

    • The following diagram depicts BPMN Infra and VNFM Adapter Run-time scenarios.

Image Removed

    1. SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
    2. SO BPMN VNF-level resource workflows handle:
      1. Assign VNF Network to SDNC
      2. Retrieve the Network Assignment from SDNC
      3. Invoke VNFM Adapter Client with required parameters
    3. VNFM Adapter Client manages:
      1. Populate parameter structures based on data from SO workflows
      2. Invoke VNFM Adapter NBI with required parameters
    4. VNFM Adapter gets GenericVNF from A&AI
    5. VNFM Adapter locates the corresponding VNF and VNFM registration info form A&AI (ESR). Two methods are suggested
      1. Current one: based on VNF NF Type and VNFM Type in A&AI
      2. Could use VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud Region, vendor - logic is being designed
    6. VNFM Adapter gets VimConnectionInfo from A&AI
      1. Queries A&AI based on the cloud region and tenant id
      2. Builds the VimConnectionInfo based on the type, service-url, user-name, password, cloud-domain, etc.
    7. VNFM Adapter uses network assignment (e.g., IP Address) from SO (thru SDNC) and builds the extVirtualLinks and other parameters.

  • VF-Module Deduction from SOL001

    • 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 SVFNM
          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.

    • Assumptions for deducing VF-Module from SOL001 (Gil Bullard's input)

      • SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
      • SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
      • SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
      • ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
      • ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.  
      • In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
    • What to do
      • ONAP will be extended to incorporate the constructs of Aspect and Scaling Level.  This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect. 
      • If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD.  (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. )  However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below.  “Structure” in this case includes the VDU topology, connection points and associated parameters.  This algorithm will:
      • Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
      • Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
      • Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
      • Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
      • Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
      • Determine if there is an the artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived.  If so, associate that HOT file with the VF Module.
      • Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
      • Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
      • Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
      • Note:  As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.

  • SDNC Assignment

    • TBD

  • VNFM Adapter VNF Package Management

Image Removed

    • VNF Package Management Interface

      • 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

      • TBD

  • VNFM Adapter Design

Image Removed


  • VNFM Adapter Design


    Image Added

      • SO VNFM Adapter component (a sub component of SO; docker image and container manged)
      • North Bound Interface (NBI)
        • RESTful APIs that support createVnf, instantiateVnf, queryVnf, grantVnf
        • Its APIs are SO specific; i.e., not SOL003-based ones
      • Business Logic layer
        • It is invoked by the NBI and provides business logic for createVnf, instantiateVnf, queryVnf
        • SDNC and A&AI access to collect assignment and VimConnectionInfo
        • Access SdcPackageProvider for getting SOL003 package(s) and parameters
      • SdcPackageProvider
        • Supports SOL001/SOL004 package management
        • Provides getPackage, getVnfdId, getFlavorId, getVnfNodeProperty
        • Provides getPackage(s), getVnfd, getArtifactFile for SVNFM
        • Uses SDC Tosca Parser
      • GrantManager
        • Provides requestGrantForInstantiate REST API for SVNFM
        • Invokes OOF for homing decision; HPA support
      • SOL003Lcn APIs
        • Support VnfIdentifierCreationNotification, VnfIdentifierDeletionNotification, VnfLcmOperationOccurrenceNotification


  • SOL001/SOL004 Support & Design


    • CSAR Import, Store and Retrieve Sequences 

Image Added


    1. SO SDC Controller gets a SOL004 VNF package with an SOL001 VNFD
    2. SO SDC Controller stores a VNF CSAR file reference to the SO Catalog DB (e.g., TOSCA_CSAR database table)
    3. VNFM Adapter gets a CSAR package URL from the SO TOSCA_CSAR database table
    4. VNFM Adapter gets an original CSAR package file from the SDC repository
      1. It is assumed that the Adapter retrieves the original vendor provided CSAR package from SDC repository directory before it passes the package to SVNFM, where SVNFM handles the original CSAR. For that, SDC copy the full original package.
      2. There would be two CSAR packages for a service: one original package, one SDC transformed package.
      3. VNFM Adapter passes the original CSAR package to SVNFM because the SVNFM is outside of ONAP and is designed to handle the vendor CSAR package.

Note: SO future release could consider SOL001/SOL004 internal representation in its Catalog DB, or using the Run-time Catalog DB

  • Design

    • TBD


  • VNFM Adapter Run-time Scenarios


    • The following diagram depicts BPMN Infra and VNFM Adapter Run-time scenarios.

Image Added

    1. SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
    2. SO BPMN VNF-level resource workflows handle:
      1. Assign VNF Network to SDNC
      2. Retrieve the Network Assignment from SDNC
      3. Invoke VNFM Adapter Client with required parameters
    3. VNFM Adapter Client manages:
      1. Populate parameter structures based on data from SO workflows
      2. Invoke VNFM Adapter NBI with required parameters
    4. VNFM Adapter gets GenericVNF from A&AI
    5. VNFM Adapter locates the corresponding VNF and VNFM registration info form A&AI (ESR). Two methods are suggested
      1. Current one: based on VNF NF Type and VNFM Type in A&AI
      2. Could use VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud Region, vendor - logic is being designed
    6. VNFM Adapter gets VimConnectionInfo from A&AI
      1. Queries A&AI based on the cloud region and tenant id
      2. Builds the VimConnectionInfo based on the type, service-url, user-name, password, cloud-domain, etc.
    7. VNFM Adapter uses network assignment (e.g., IP Address) from SO (thru SDNC) and builds the extVirtualLinks and other parameters.


  • VF-Module Deduction from SOL001


    • 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 SVFNM
          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.

    • Assumptions for deducing VF-Module from SOL001 (Gil Bullard's input)

      • SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
      • SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
      • SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
      • ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
      • ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.  
      • In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
    • What to do
      • ONAP will be extended to incorporate the constructs of Aspect and Scaling Level.  This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect. 
      • If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD.  (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. )  However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below.  “Structure” in this case includes the VDU topology, connection points and associated parameters.  This algorithm will:
      • Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
      • Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
      • Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
      • Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
      • Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
      • Determine if there is an the artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived.  If so, associate that HOT file with the VF Module.
      • Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
      • Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
      • Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
      • Note:  As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.



  • SDNC Assignment


    • TBD


  • VNFM Adapter VNF Package Management

Image Added


    • VNF Package Management Interface

      • 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


      • TBD
    • SO VNFM Adapter component (a sub component of SO; docker image and container manged)
    • North Bound Interface (NBI)
      • RESTful APIs that support createVnf, instantiateVnf, queryVnf
    • Business Logic layer
      • It is invoked by the NBI and provides business logic for createVnf, instantiateVnf, queryVnf
      • SDNC and A&AI access to collect assignment and VimConnectionInfo
      • Access SdcPackageProvider for getting SOL003 package(s) and parameters
    • SdcPackageProvider
      • Supports SOL001/SOL004 package management
      • Provides getPackage, getVnfdId, getFlavorId, getVnfNodeProperty
      • Provides getPackage(s), getVnfd, getArtifactFile for SVNFM
      • Uses SDC Tosca Parser
    • GrantManager
      • Provides requestGrantForInstantiate REST API for SVNFM
      • Invokes OOF for homing decision; HPA support
      • SOL003Lcn APIsSupport VnfIdentifierCreationNotification, VnfIdentifierDeletionNotification, VnfLcmOperationOccurrenceNotification

  • VNFM Adapter Locating SVNFM

...