...
Leverage ETSI standards for VNF LCM in SO
Build SO VNFM Adapter
Use SOL003 APIs (2.5.1) for VNF LCM
Support operations such as create, instantiate, grant, query, LCN subscription and LCN
- Support terminate is a stretch goal
Enhance SO BPMN workflows & recipes
VNF-level and VF-Module workflows, leveraging VNFM Adapter
Passing VNF LCM requests to VNFM using VNFM Adapter
Policy based VNF scale out thru VNFM Adapter (Stretch Goal)VNFM Adapter interfaces for VES eventPolicy Framework for scaling decisionsSO workflows for VNF Scale out
Provide VNF package management for VNFM (Stretch Goal; under investigation)
VNF-level and VF Module-level Assignment modeling in SDNC and A&AI (open issue)
VNF Application Configuration thru VNFM Adapter and VNFM (open issue & not for Dublin)
...
- 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
...
- Choose a use case for demonstrating the VNFM Adapter capabilities
- Under investigation (will determine soon)
VNFM Adapter Design
- 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, and/or non-OOF decision
- SOL003Lcn APIs
- Support VnfIdentifierCreationNotification, VnfIdentifierDeletionNotification, VnfLcmOperationOccurrenceNotification
...
- SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
- Once a Service workflow chooses a new workflow path for VNFM Adapter, the subsequent requests for the same VNF will follow the new path.
- an association between VNF and VNFM will be made in A&AI.
- SO BPMN VNF-level resource workflows handle:
- Assign VNF and VF-Module Network to SDNC
- Retrieve the VNF and VF-Module Network Assignment from SDNC
- Invoke VNFM Adapter Client with required parameters
- VNFM Adapter Client manages:
- Populate parameter structures based on data from SO workflows
- Invoke VNFM Adapter NBI with required parameters
- VNFM Adapter gets GenericVNF from A&AI
- VNFM Adapter locates the corresponding VNF and VNFM registration info form A&AI (ESR). Two methods are suggested
- Current one: based on VNF NF Type and VNFM Type in A&AI
- Could use VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud Region, vendor - logic is being designed
- VNFM Adapter gets VimConnectionInfo from A&AI
- Queries A&AI based on the cloud region and tenant id
- Builds the VimConnectionInfo based on the type, service-url, user-name, password, cloud-domain, etc.
- VNFM Adapter uses network assignment (e.g., IP Address) from SO (thru SDNC) and builds the extVirtualLinks and other parameters.
- SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
VF-Module Deduction from SOL001 (under investigation)
- 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:
- 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.
- After finishing the loop, the SO workflows will send a structure to the VNFM Adapter that includes the aggregate assignments at the VNF level.
- The VNFM Adapter aggregates all the VF-Module level assignments and transforms the assignment data into SOL003 API parameters before sending them to SVNFM
- 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)
- In doing so, the VNFM Adapter would need to know to ignore the VF Module groupings of these assignments
- 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.
...
SO BPMN VNF Workflow
TBD
SO BPMN VF-Module Workflow
TBD
VNFM Adapter Client
- TBD
SDNC Assignment
- TBD
VNFM Adapter VNF Package Management (Stretch Goal; under investigation)
VNF Package Management Interface
...
- 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 NFVO 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"
- Open Issues:
- How to and from where fill up ExternalVirtualLinks: IP Address, and OAM IPAddress? Use of Additional Parameters to pass IP Addresses that are extracted from HEAT templates?
- Design
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)
...