Page History

...

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

• EPICs

  Tasks

...

• 
  
  1. SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
     1. Once a Service workflow chooses a new workflow path for VNFM Adapter, the subsequent requests for the same VNF will follow the new path.
     2. an association between VNF and VNFM will be made in A&AI.
  2. SO BPMN VNF-level resource workflows handle:
     1. Assign VNF and VF-Module Network to SDNC
     2. Retrieve the VNF and VF-Module 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 (

  under investigation)

  It is a candidate for the El Alto release)

  • Note: VF-Module deduction will not be supported in Dublin. ETSI-based scaling will not be supported in Dublin.

• • 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 SVNFM
         1. The VNFM Adapter would need to be able to parse the VNF-level assignments structure received from SO to obtain the per-VDUconnection 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.

...

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

• SO BPMN VNF Workflow

  • A new VNF-level Building Block workflow will be created.

  • <to add more details>TBD

• SO BPMN VF-Module Workflow

  • TBD

• VNFM Adapter Client 

  • TBD

• SDNC Assignment

• Preload Assignment...

• • For ETSI-based VNF package, VF-Module level workflows will NOT be used. 

  • SO VNFM Adapter will interface with SVNFM at the VNF level.

• VNFM Adapter Client 

  • SO Workflows (Building Blocks) will invoke Java-based VNFM Adapter Client. 
  • This Adapter client will invoke the SO VNFM Adapter NBI thru SO proprietary interfaces.

• SDNC Assignment

• • Even though SO Building Blocks are used for the SO VNFM Adapter, assignment data will be pre-loaded into SDNC for the Dublin release.
  • In El Alto release, preload data could be replaced with SO request data (TBD)
  • Possible preload data structure. The additionalParams and extVirtualLinks data will be preloaded to SDNC, and the SO VNFM Adapter will retrieve the data from SDNC.

    • {  
         "additionalParams ":"{\"param_1\": \"value_1\",\"param_2\": \"value_2\",\"param_3\": \"value_3\"}",
         "extVirtualLinks":"[{\"id\": \"vlaue\",\"resourceId\": \"value\",\"extCps\": [{\"cpdId\": \"cpdId_value\",\"fixedAddresses\": [{\"fixedAddresses\": {\"macAddress\": [\"macAddress_1\", \"macAddress_2\"]}}]}]}]"
      }

• VNFM Adapter Locating SVNFM

• • VNFM Adapter locates a proper SVNFM based on VNF NF Type/VNFD  and VNFM registration
  • Two methods are suggested as follows, and one of them will be chosen.

Image Added

• Design

• • Current method (Green Dots)
    • VnfLCM::locateVnfm(GenericVnf vnf)
    • Get a vnfm list from AAI ESR
    • Find a matched Vnfm, where vnfmInfo.getType() == vnf.getNfType
  • New method (Orange Dots)
    • Under development (TBD)

• VNFM Adapter VNF Package Management (It is deferred to the next release, e.g, El Alto)

  • In Dublin, VNF packages will be onboarded into SVNFM separately/manually. The SVNFM will onboard SOL004 VNF package in their own way.
  • In the future release (e.g., El Alto), VNFM Adapter will support VNF package management for SVNFM.

• Image Added

  
  

  • 
    

    • VNF Package Management Execution Flow

  • • • VNFM Adapter supports VNF Package Management Interface
        • Accepts the "Get VNF packages" request and returns "200 OK" with VnfPkgInfo[]
        • Accepts the "Get VNFD" request and returns "200 OK" with Vnfd
        • Accepts the "Get VNF artifact" request and returns "200 OK" with 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

• VNFM Adapter VNF Package Management (Stretch Goal; under investigation)

Image Removed

• VNF Package Management Execution Flow

• • • VNFM Adapter supports VNF Package Management Interface
      • Accepts the "Get VNF packages" request and returns "200 OK" with VnfPkgInfo[]
      • Accepts the "Get VNFD" request and returns "200 OK" with Vnfd
      • Accepts the "Get VNF artifact" request and returns "200 OK" with 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.

• VNFM Adapter Locating SVNFM

• • VNFM Adapter locates a proper SVNFM based on VNF NF Type/VNFD  and VNFM registration
  • Two methods are suggested as follows, and one of them will be chosen.

Image Removed

• Design

• • • • • of the applicable artifact file from the VNF package in the payload body (VNFM Adapter → VNFM); 200 OK (artifact file)
  • • 
      

      • Note: Package management subscription and notification are not consider at this time, future consideration.

• ***** Design *****

• Current method (Green Dots)
  • VnfLCM::locateVnfm(GenericVnf vnf)
  • Get a vnfm list from AAI ESR
  • Find a matched Vnfm, where vnfmInfo.getType() == vnf.getNfType
New method (Orange Dots)Under development (TBD)

• SOL003 Lifecycle Management (LCM) Support and Design

...

• • • 
      
      • Design
        • VNFM Adapter sends a POST request to the Task resource that represents the lifecycle operation to be executed on the VNF instance, and includes in the payload body a data structure of type InstantiateVNFRequest (VNFM Adapter → VNFM); POST ../vnf_instances/{vnfInstanceId}/instantiate
        • VNFM Creates a "VNF LCM operation occurrence" resource for the request (VNFM → VNFM Adapter)
        • VNFM returns a "202 Accepted" response with an empty payload body and a "Location" HTTP header that points to the new "VNF LCM operation occurrence" resource (VNFM → VNFM Adapter); .../vnf_lcm_op_occs/{vnfLcmOpOccId}
        • VNFM sends to the VNFM Adapter a VNF lifecycle management operation occurrence notification to indicate the start of the lifecycle management operation occurrence with the "STARTING" state
        • VNFM and VNFM Adapter exchange granting information (see Granting section)
        • VNFM sends to the VNFM Adapter a VNF lifecycle management operation occurrence notification to indicate that the VNF LCM operation occurrence enters the "PROCESSING" state
        • VNFM Adapter polls the "VNF LCM operation occurrence" resource to obtain information about the ongoing operation by sending a GET request to the resource that represents the VNF LCM operation occurrence.
        • VNFM returns to the VNFM Adapter information of the operation, such as the operation status, by providing in the payload body a data structure of type "VnfLcmOpOcc"
        • VNFM has finished the operation <<Operation>>
        • VNFM sends a VNF lifecycle management operation occurrence notification to VNFM Adapter to indicate the completion of the lifecycle management operation occurrence with the success state "COMPLETED"

        • Parameters and data source

          Parameter	Required?	Data Source	Note
          flavorId	Optional	From user input or from the VNFD	This parameter is optional for NBI but it is mandatory for southbound. The value from the user; otherwise it takes the default value from VNFD
          instantiationLevelId	Optional	From VNFD
          extVirtualLinks	Optional	From preload data or user input	The user input requires UI enhancement - See below for design proposal If the external connection point ip_address_assignment is set to false, extVirtualLink is not necessary since the ip address is set by VIM dynamically.
          extManagedVirtualLinks	Optional	from user input	Externally-managed internal VL; Not supported in Dublin
          vimConnectionInfo	Optional	From AAI	In Dublin, the direct resource mode is supported, that means all the VIM resources are created directly by VNFM
          localizationLanguage	Optional	Not supported in Dublin
          additonalParams	Optional	From VNFD	It is a mechanism to pass vendor-specific parameters

          Image Removed

          		Not supported in Dublin
          additonalParams	Optional	From VNFD	It is a mechanism to pass vendor-specific parameters

          Image Added

          
          

• • • • • Population of User Inputs for SOL003 Instantiation. Two options are discussed and the Option #1 is chosen for Dublin for simplicity. It will be revisited for the El Alto release. 
          • Option #1. Preload configuration solution (it would be an option for the Dublin release)
          • • For the VNFD, pre-configure the mapping between the external virtual links and the ip addresses
            • VNFM Adapter retrieves the mapping from preload data and fill up the extVirtualLink parameters based on the mapping
          • Option #2: model-driven user data population from UI (which is attached to VID) - TBD
            • The external virtual links user input is shown for illustration purposes. 
          extVirtualLinks data population
          • • VNFD does not define external virtual links, but it lists the external virtual links as requirements for the VNF.
              • If the connection point ip_address_assignment is set to false, no extVirtualLinks ip address assignment is necessary.
              • In this case, VIM will assign IP addresses dynamically.
              • This could be an option for the Dublin release for simplifying the solution.

Image Removed

• • • • • • If the connection point ip_address_assignment is set to true, set extVirtualLink ip address assignment with configuration data from the user input or a preload file.
            • UI solution (build an UI configuration page and invoke it from VID; it would be an option for the post Dublin release): Impact on VID (open issue)
              • Parse VNFD and extract a list of external virtual links
              • Map the external virtual links to the corresponding connection points, and read ip_address_assignment and number_of_ip_address value
              • Render the external virtual links
              • For each external virtual link, render the ip_address_assignment entry fields based on the number_of_ip_address value
              • User configures the mapping and the UI stores the mapping in the database
              • VNFM Adapter retrieves the mapping from database and fill up the extVirtualLink parameters based the mapping
              • UI Example:

Image Removed

Image Added

• • • • • • • If the connection point ip_address_assignment is set to true, set extVirtualLink ip address assignment with configuration data from the user input or a preload file.
              • UI solution (build an UI configuration page and invoke it from VID; it would be an option for the post Dublin release): Impact on VID (open issue)
              • Parse VNFD and extract a list of external virtual links
              • Map the external virtual links to the corresponding connection points, and read ip_address_assignment and number_of_ip_address value
              • Render the external virtual links
              • For each external virtual link, render the ip_address_assignment entry fields based on the number_of_ip_address value
              • User configures the mapping and the UI stores the mapping in the database
              • VNFM Adapter retrieves the mapping from database and fill up the extVirtualLink parameters based the mapping
              • UI Example:

Image Added

• • • • VNFM and GenericVNF relationship

        • 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 VNFM Adapter will update the relationship between generic-vnf and esr-vnfm based on the rule.

      Preload configuration solution (it would be an option for the Dublin release)
      • For the VNFD, pre-configure the mapping between the external virtual links and the ip addresses
      VNFM Adapter retrieves the mapping from preload data and fill up the extVirtualLink parameters based on the mapping

• • • Query VNF Instances

      • HTTP Method Type: GET

      • VNFM Endpoint: /vnf_instances  (for multiple VNFs), /vnf_instances/{vnfInstanceId}  (for single VNF)

      • Request Payload: not applicable

      • Response Header: 200 success

      • Response Body: VnfInstance[] (for multiple VNFs), VnfInstance (for single VNF)

...

• • • • VNFM Adapter Homing Decision for VNF Granting

• • • • • In Dublin, the homing data will be collected during the service decomposition procedures in SO workflows. The SO VNFM Adapter will receive the homing data from the SO workflows. 
        • Some models do not have homing models and policies; i.e., use
        • Note: the following logic concept is inspired by the VFC Homing decision mechanism (location, inventory data, resource availability, business rules, etc.)
        • Use of OOF is optional. For those models without using HPA, VNFM Adapter will make a grant decision based on VIM registration information. In that case, the SO VNFM Adapter will make a gran decision based on VIM registration, cloud region. 
        • The following is based on the current VFC granting mechanism. In the Dublin, the mechanism is not used.

Image Modified

1. 1. 
      
      1. 1. 1. 1. 1. VNFM Adapter sends out homing requests to OOF (OSDF) containing resource info
                  2. OOF (OSDF) pulls all the related homing constraints from Policy
                  3. OOF (HAS) checks AAI database to pull region (flavor) information
                  4. OOF (HAS) communicates with Multi-Cloud to check cloud capacity (vims which fulfill the requirements)
                  5. OOF (OSDF) returns homing allocation solution to VNFM Adapter

• • • • • • • 
              
              • OOF collects information as following:
              • Service and Resource Info, from: AAI
              • HPA Flavors/Capabilities/Capacity Info, from: AAI
              • Policy Models (Homing, PCI) from: Policy
              • Infrastructure Metrics Info (capacity), from: MultiCloud
              • Cloud Agnostic Intent Info, from: MultiCloud
              • PCI configuration data (not yet a part of SDC model)

• • 
    

    • Terminate VNF

      • HTTP Method Type: POST

      • VNFM Endpoint: /vnf_instances/{vnfInstanceId}/terminate

      • Request Payload: TerminateVnfRequest

      • Response Header: 202 success

      • Response Body: not applicable

      • Design
        • VNF precondition = INSTANTIATED state
        • After the operation, VNF state = NOT_INSTANTIATED 
        • VNFM Adapter sends a POST request to the Task resource that represents the lifecycle operation to be executed on the VNF instance, and includes in the payload body a data structure of type TerminateVNFRequest (VNFM Adapter → VNFM); POST ../vnf_instances/{vnfInstanceId}/terminate
        • VNFM Creates a "VNF LCM operation occurrence" resource for the request (VNFM → VNFM Adapter)
        • VNFM returns a "202 Accepted" response with an empty payload body and a "Location" HTTP header that points to the new "VNF LCM operation occurrence" resource (VNFM → VNFM Adapter); .../vnf_lcm_op_occs/{vnfLcmOpOccId}
        • VNFM sends to the VNFM Adapter a VNF lifecycle management operation occurrence notification to indicate the start of the lifecycle management operation occurrence with the "STARTING" state
        • VNFM and VNFM Adapter exchange granting information (see Granting section)
        • VNFM sends to the VNFM Adapter a VNF lifecycle management operation occurrence notification to indicate that the VNF LCM operation occurrence enters the "PROCESSING" state
        • VNFM Adapter polls the "VNF LCM operation occurrence" resource to obtain information about the ongoing operation by sending a GET request to the resource that represents the VNF LCM operation occurrence.
        • VNFM returns to the VNFM Adapter information of the operation, such as the operation status, by providing in the payload body a data structure of type "VnfLcmOpOcc"
        • VNFM has finished the operation <<Operation>>
        • VNFM sends a VNF lifecycle management operation occurrence notification to VNFM Adapter to indicate the completion of the lifecycle management operation occurrence with the success state "COMPLETED"
        • Note: its communication exchange pattern is the same as the Instantiate VNF.

        • Parameters and Data source

          Parameter	Required?	Data Source	Note
          terminationType	Yes	from user input
          gracefulTerminationTimeout	Optional	from user input	This attribute is only applicable in case of graceful termination. The unit is seconds
          additionalParams	Option	from VNFD

          

          
          

          
          

...

• • • SO 
      • SO Catalog DB for SOL001/SOL004 support
      • BPMN Workflows and Recipes
      • VNFM Adapter
    • SDC 
      • Support SOL001/SOL004
        • Leave the current TOSCA SDC AID DM mapping as is
        • store the original vendor-provided VNF package
      • VF Module deduction based on SOL001 (out of scope from Dublin)
    • SDNC
      • VNF-level Network Assignment, instead of VF-Module
    • A&AI
      • VNF-level Inventory Update
      • VNFM location
    • Policy (Stretch goal) - not for out of scope from Dublin
      • Scale-Out support for ETSI-based scaling
    • Modeling
      • Support SOL001/SOL004
      • ETSI vs. ONAP-compliant VNFD (out of scope from Dublin)
    • VID
      • External Virtual Link Configuration UI to map External CPs and Virtual Links such as IP Address (out of scope from Dublin)

• • Open Items

• • • SDC transformation between ETSI and ONAP internal output and storing the original CSAR package.

    • VNF Application Configuration thru VNFM Adapter and VNFM is under discussion under discussion  (out of scope from Dublin)

      • Architecture subcommittee is defining orchestration scenarios for application configuration

    • Better mechanism for VNFM Adapter to locate VNFMs (two methods are suggested)

      • How do we identify which VNFM to use?

    • Modelling for VNF and VF Modules; mapping between VF Modules and VNF (out of scope from Dublin)

      • Assigning Network resources to SDNC; do we use preload data?

    • Continue to support existing non-ETSI SO workflows along with ETSI-based workflowsVNFM Adapter architectural direction; should it work as a thin layer or should it be evolved as a full-fledged NFVO in the future, e.g., handling grant by itself, updating resources in A&AI and SDNC?

      • After the VNF Instantiation, which component does update VNF resources in A&AI? VNFM Adapter or SO?

    • SOL001/SOL004 SO Representation (for Dublin, the second option was chosen)

      • Option #1: Enhance SO Catalog Database? 

        • VNF_Package (vnfdid, vnfm_info, version, vnf_provider, product, vendor, etc.)

        • VNF_Package_Artifact (child database for VNF_Package, VNFD_URL, SoftwareImage_URL, Additional Files etc)

      • Option #2: Store minimum reference in TOSCA_CSAR database table? This was chosen for Dublin

    • MultiCloud use (not for Dublin)