**1 Scope**
=============
-The scope of the present document is to describe the GVNFM exposed API specification over Or-Vnfm reference point and Ve-Vnfm-vnf reference point.
+The scope of the this document is to describe the GVNFM exposed API specification over Or-Vnfm reference point and Ve-Vnfm-vnf reference point.
Some content has been updated, about the API Swagger definition, you can find here 'GVNFM_LCM_APIs<https://gerrit.onap.org/r/gitweb?p=vfc/gvnfm/vnflcm.git;a=blob;f=lcm/lcm/swagger/swagger.json;h=f098d282927d3535f5e9e6950f26b9171e04d30c;hb=HEAD>'.
**2 Terms, Definitions and Abbreviations**
===========================================
- For the purposes of the present document, the following
+ For the purpose of the present document, the following
abbreviations apply:
+------------------------+-----------------------------------------------------+
+-----------------+-----------+-------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------+
| vimId | M | 1 | Identifier | The identifier of the VIM. |
+-----------------+-----------+-------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------+
-| interfaceInfo | M | 0..N | KeyValuePair | Information about the interface to the VIM, including VIM provider type, API version, and protocol type. |
+| interfaceInfo | M | 0..N | KeyValuePair | Information about the interface to the VIM, including VIM provider type, API version and protocol type. |
+-----------------+-----------+-------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------+
| accessInfo | M | 0..N | KeyValuePair | Authentication credentials for accessing the VIM. Examples may include those to support different authentication schemes, e.g., OAuth, |
-| | | | | Token, etc. |
+| | | | | Token etc. |
+-----------------+-----------+-------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------+
| interface | M | 1 | String | Information about the interface endpoint. An example is a URL. |
-| Endpoint | | | | Token, etc. |
+| Endpoint | | | | Token etc. |
+-----------------+-----------+-------------+--------------+------------------------------------------------------------------------------------------------------------------------------------------+
**interfaceInfo:**
+==================+===============+======================================+
| vimType | String | The type of the VIM. |
+------------------+---------------+--------------------------------------+
-| apiVersion | String | The Version of the api of the VIM. |
+| apiVersion | String | The version of the api of the VIM. |
+------------------+---------------+--------------------------------------+
| protocolType | String | http https |
+------------------+---------------+--------------------------------------+
.. |image0| image:: VNFM_API.png
:width: 5.07047in
- :height: 5.6320in
\ No newline at end of file
+ :height: 5.6320in
+-------------+-----------------------------------------------+
|Abbreviation | |
+-------------+-----------------------------------------------+
-|NFVO |Network Functions Virtualization Orchestrator |
+|NFVO |Network Function Virtualization Orchestrator |
+-------------+-----------------------------------------------+
|VNFM |Virtual Network Function Manager |
+-------------+-----------------------------------------------+
| | | | | manages this resource. |
| | | | | This attribute shall be supported |
| | | | | and present if VNF-related resource |
-| | | | | management in direct applicable. |
+| | | | | management is direct applicable. |
+--------------+------------+-------------+----------+----------------------------------------+
| networkId | M | 1 | String | The network UUID of VIM |
+--------------+------------+-------------+----------+----------------------------------------+
| vduid | M | 1 | String | Defines the id of vdu. |
+--------------------+------------+-------------+-------------+---------------------------------+
| vmname | M | 1 | | Defines the name of virtual |
-| | | | | machines. |
+| | | | | machine. |
+--------------------+------------+-------------+-------------+---------------------------------+
.. code-block:: json
:depth: 2
Now VF-C provides the NS life cycle management APIs to UUI,SO,Policy and package management APIs to UUI.
-For VNFM vendor, VF-C also provides the VNFM integration APIs, they can reference these APIs to implmemet their VNFMDriver to integrate with VF-C and ONAP.
+For VNFM vendor, VF-C also provides the VNFM integration APIs, they can reference these APIs to implement their VNFMDriver to integrate with VF-C and ONAP.
|image0|
----------------------------------
VF-C provides the Generic VFNM , it can be as the GVNFM reference implementaton.
-Now the Northbound APIs of GVNFM has been compli1t with SOL003 and it now can be integrate with VF-C NFVO.
-In tosca-based vCPE use case, the GVNFM founction have been verified in Casablanca release.
+Now the Northbound APIs of GVNFM has been compete with SOL003 and it now can be integrate with VF-C NFVO.
+In tosca-based vCPE use case, the GVNFM function have been verified in Casablanca release.
GVNFM Northbound & Southbound APIs for VNF Integration
.. toctree::
:maxdepth: 1
- CATALOG_API/index
\ No newline at end of file
+ CATALOG_API/index
* nslcm is the core components, mainly responsible for network service management.
* catalog is used to package management, including NS/VNF/PNF package management.
-* Resource Manager is used to management the instance created by VF-C and also responsible for resource granting.
+* Resource Manager is used to manage the instance created by VF-C and also responsible for resource granting.
* SVNFM Driver, now VF-C has three vendor's Specific VNFM driver, including nokia/huawei/zte driver, each driver is a microservice.
* GVNFM Driver, now have two generic VNFM driver, including gvnfm driver and juju driver.
* SFC Driver, it migrate from Open-O seed code and now haven't been used in any usecase in ONAP.
* Wfengine-activiti, it is as the activiti work flow microservice.
* Multivim-proxy,provide the multivim indirect mode proxy which can forward virtual resource requests to multivim and do some resource checking.
* EMS Driver, used for VNF performance and alarm data collection and report to DCAE VES collector.
-* GVNFM, it includes three micorservice: vnflcm, vnfmgr and vnfres and the core is vnflcm which responsible for VNF life cycle management.
+* GVNFM, it includes three micorservice: vnflcm, vnfmgr and vnfres and the core is vnflcm which is responsible for VNF life cycle management.
* DB, provide database services for each VF-C component.
Note:
a. SFC Driver migrated from Open-O seed code and now haven't been used in any usecase in ONAP.
- b. Resource resmanagement is used to do the resource granting, but now VF-C has been integrated with OOF, this component will be deprecated in the future release.
+ b. Resource Management is used to do the resource granting, but now VF-C has been integrated with OOF, this component will be deprecated in the future release.
c. DB provides the stand-alone database microservice in casablanca release, but now VF-C leverages OOM shared MariaDB-Gelera cluster. This repo still has redis to be used by VF-C component.
As you can see in this picture, VF-C has many dependencies with other projects, such as SO, Policy, A&AI, SDC, DCAE, Multi-cloud and so on.
-* NFVO provides north bound interface to SO to take part in fulfilling the orchestration and operation of end2end service.And provides standard south bound interface to VNFMs.
+* NFVO provides north bound interface to SO to take part in fulfilling the orchestration and operation of end2end service and provides standard south bound interface to VNFMs.
* GVNFM provides LCM for VNFs which do not require a vendor VNFM and works with NFV-O component to take part in fulfilling the LCM of NS.
-* VF-C provides VNFM driver interfaces, vendor can implement these integrates to integrate with VF-C. Now, VF-C has integrated with three vendor VNFM, including ZTE, Huawe, Nokia.
+* VF-C provides VNFM driver interfaces, vendor can implement these to integrate with VF-C. Now, VF-C has integrated with three vendor VNFM, including ZTE, Huawe, Nokia.
* In addition, VF-C also provides interface to Policy and works with DCAE for Close Loop Automation.
-* In Casablanca release, VF-C also integrated with OOF to do the resource homing and placement.
+* In Casablanca release, VF-C is also integrated with OOF to do the resource homing and placement.
VF-C Usecase and Workflow
The workflow:
* SO send request to LCM to deploy vIMS+vEPC network service.
-* LCM talk with Res Manager and then A&AI to create NS instances in A&AI inventory.
+* LCM talk with Resource Manager and then A&AI to create NS instances in A&AI inventory.
* LCM get NSD from VF-C catalog.
* LCM parse the NS model via TOSCA parser to decompose NS to VNFs and recognize the relationship between VNFs.
* LCM init workflow context and execute NS instantiation.
* Workflow will invoke LCM to instantiate VLs between VNFs.
* LCM talk with Multi-VIM to create virtual network connections between VNFs if needed.
-* LCM talk with Res manager to create related virtual link instances to A&AI inventory(Not included in R1).
-* When VL created ,workflow will invoke LCM to instantiate VNFs.
-* LCM send request to S-VNFM Driver and wok with S-VNFM to deploy each VNFs.
-* Aligned with ETSI specs work flow, VNFM need to send granting resource request to LCM,LCM transfer this request to Res manager and then response the granting result and related VIM information(such as url/username/password, etc) to VNFM.
+* LCM talk with Resource manager to create related virtual link instances to A&AI inventory(Not included in R1).
+* When VL is created ,workflow will invoke LCM to instantiate VNFs.
+* LCM send request to S-VNFM Driver and work with S-VNFM to deploy each VNFs.
+* Aligned with ETSI specs work flow, VNFM need to send granting resource request to LCM,LCM transfer this request to Resource manager and then response the granting result and related VIM information(such as url/username/password etc) to VNFM.
* VNFM call VIM API to deploy VNF into VIM.
-* VNFM send notification to LCM to notify the changes of virtual resources, including VDU/VL/CP/VNFC, etc.
-* LCM talk to Res manager to create/update related records in A&AI inventory
+* VNFM send notification to LCM to notify the changes of virtual resources, including VDU/VL/CP/VNFC etc.
+* LCM talk to Resource manager to create/update related records in A&AI inventory
2.VF-C Terminate
The workflow:
* SO talk with VF-C to request deletion of vIMS/vEPC network services
-* Lcm work with Res manager to check all vIMS/vEPC instances in A&AI
+* Lcm work with Resource Manager to check all vIMS/vEPC instances in A&AI
* LCM invoke workflow to delete NS instance
-* First, workflow will execute deleting VNFs by invoke LCM
-* LCM talk with S-VNFM Driver o request deletion of VNFs and related resources
+* First, workflow will execute deleting VNFs by invoking LCM
+* LCM talk with S-VNFM Driver to request deletion of VNFs and related resources
* Aligned with ETSI specs work flow, VNFM will delete/release virtual resources with the granting to LCM
-* LCM transfer the grant request to Res Manager and then response the granting result and related VIM information(such as url/username/password, etc) to VNFM.
+* LCM transfer the grant request to Resource Manager and then response the granting result and related VIM information(such as url/username/password etc) to VNFM.
* VNFM delete VNFs and related resources and notify the changes(releasing) of virtual resources to LCM
-* Lcm talk with Res Manager to update/delete related resource instances in A&AI inventory
+* Lcm talk with Resource Manager to update/delete related resource instances in A&AI inventory
* When above work finish, workflow will delete VLs
* LCM talk with Multi-VIM to request deletion of virtual network connected to VNFs
-* Multi-VIM delete related virtual network resources, such as network, sub-network and port, etc.
-* LCM talk with Res Manager to update/delete related VL resource instances in A&AI inventory(Not included in R1)
-* LCM talk with Res Manager to update/delete related NS instances in A&AI inventory
+* Multi-VIM delete related virtual network resources, such as network, sub-network and port etc.
+* LCM talk with Resource Manager to update/delete related VL resource instances in A&AI inventory(Not included in R1)
+* LCM talk with Resource Manager to update/delete related NS instances in A&AI inventory
3. VF-C Healing
The workflow:
* EMS Driver collects VNF service level FCAPS in real-time or period.
-* EMS Driver will transfe VNF service level FCAPS metrics to DCAE with VES data format.
-* Data filtering/cleaning inside DCAE, DCAE can send related events to data bus. Holmes can keep track the events published to data bus and do the alarm correlation analysis based on the imported rules and Holmes send the result, the root cause, to the event bus.
+* EMS Driver will transfer VNF service level FCAPS metrics to DCAE with VES data format.
+* Data filtering/cleaning inside DCAE, DCAE can send related events to data bus. Holmes can keep track of the events published to data bus and do the alarm correlation analysis based on the imported rules then Holmes send the result and root cause to the event bus.
* Policy engine subscribe related topic on event bus. After receiving auto-healing triggering events, matching the events with exist rules.
* Policy invoke VF-C APIs to do the action of auto-healing once matching events with healing rules.
* LCM talk with VNFM driver to restart VNF and receive the changes of virtual resources.
-* LCM talk with Res manager to update/create related instances information to A&AI inventory according to the changes of resources.
+* LCM talk with Resource Manager to update/create related instance information to A&AI inventory according to the changes of resources.
If you would like to know more details about vCPE, you can refer https://wiki.onap.org/display/DW/vCPE+with+Tosca+VNF+Test+Guide
-
\ No newline at end of file
+
NFVO consumed interfaces:
- - VNF LCM Interface, from: Generic VNFM controller, SVNFM
- - Inventory Service Interface, from: Available and Active Inventory
- - Catalog Synchronization Interface, from: SDC
- - Generic VIM Interface, From: Multi-cloud
- - Data report Interface, From: DCAE
- - Tosca parser Interface, From: Modeling
- - Service registration and discovery, From: MSB
- - Homing Request Interface, from: Optimization Framework
+ - VNF LCM Interface from Generic VNFM controller, SVNFM
+ - Inventory Service Interface from Available and Active Inventory
+ - Catalog Synchronization Interface from SDC
+ - Generic VIM Interface from Multi-cloud
+ - Data report Interface from DCAE
+ - Tosca parser Interface from Modeling
+ - Service registration and discovery from MSB
+ - Homing Request Interface from Optimization Framework
GVNFM consumed interfaces:
- - Catalog and notification Interface, from: NFVO
- - Inventory Interface, from: A&AI
- - Tosca parser Interface, From: Modeling
- - Generic VIM Interface, From: Multi-cloud
- - Service registration and discovery, From: MSB
+ - Catalog and notification Interface from NFVO
+ - Inventory Interface from A&AI
+ - Tosca parser Interface from Modeling
+ - Generic VIM Interface from Multi-cloud
+ - Service registration and discovery from MSB
* Catalog is used to store the package distributed by SDC, it is a runtime catalog.
-* Workflow include two micro service, one is workflow manage service and the other is workflow-activiti engine service, this two service will onboard workflow to workflow engine and parse workflow.
+* Workflow includes two micro service: workflow manage service and workflow-activity engine service, this two services will onboard workflow to workflow engine and parse workflow.
-* For NS lifecycle manager,it mainly completes the NS lifecycle management,such as NS Instantiation/termination and auto-healing.
+* For NS Lifecycle Manager,it mainly completes the NS lifecycle management,such as NS Instantiation/termination and auto-healing.
* For Resource manager, it will communicate with NS lifecycle manager to update instance data to A&AI.
-* In VF-C southbound, it includes Gvnfmdriver and SVNFM driver which will interact with GVNFM and Vendor VNFM respectively to execute VNF lifecycle management,VF-C provides vnfm driver northbound api,then Vendor can implement this APIs to integrate with VF-C.
+* In VF-C southbound, it includes Gvnfmdriver and SVNFM driver which will interact with GVNFM and Vendor VNFM respectively to execute VNF lifecycle management,VF-C provides vnfm driver northbound api,then vendor can implement this APIs to integrate with VF-C.
* For the EMS driver,it can collect VNF lay’s Fcaps data from Vendor EMS, and then translate and put these data to DCAE Vescollector
- vfc-gvnfm-vnfres
Workflow
- workflow-engine-mgr-service
- - activiti-extension
+ - activity-extension
VF-C support VolTE use case in R1 and R2, following are the vVoLTE releated Workflow in VF-C.
.. |image3| image:: Auto-healing.png
:width: 5.97047in
- :height: 5.63208in
\ No newline at end of file
+ :height: 5.63208in
* compliant with ETSI NFV MANO architecture and information model,
* providing resource orchestration and full life cycle management and FCAPS for NS,
* providing standard south bound interface to VNFMs,
- * providing north bound interface to SO, to take part in fulfilling the orchestraion and operation of end2end service,
+ * providing north bound interface to SO, to take part in fulfilling the orchestration and operation of end2end service,
* providing interface and work with DCAE and Policy for Close Loop Automation.
* GVNFM component
* compliant with ETSI NFV MANO architecture and information model
* providing full life cycle management and FCAPS for VNFs which do not require a vendor VNFM,
- * providing interface and work with NFV-O component, to take part in fulfiiling the LCM and FCAPS management of NS,
+ * providing interface and work with NFV-O component, to take part in fulfilling the LCM and FCAPS management of NS,
* providing interface and work with DCAE and Policy for Close Loop Automation.
Logging & Diagnostic Information
--------------------------------
-In Amsterdam release, VF-Clogs are kept inside the docker containers.
+In Amsterdam release, VF-C logs are kept inside the docker containers.
You can get the log when the dockers start.
Where to Access Information
-----------------------
VF-C supports vCPE use case in R3, all VNFs are deployed through VF-C GVNFM .
-This page describes how to use VF-C to instantiate NS
+This page describe how to use VF-C to instantiate NS
Before you try, please prepare two csar file:
* VNF csar
Environment
+++++++++++
-VF-C components can run as docker, docker service should be installed before install VF-C components.
+VF-C components can run as docker, docker service should be installed before installing VF-C components.
-The following scripts show the docker service install commands in centos7.
+The following scripts show the docker service install commands in centos 7.
::
-If you want to try VF-C, the small project set should include: VF-C , Multicloud, MSB, A&AI.
+If you want to try VF-C, the small project set should include: VF-C , Multicloud, MSB and A&AI.
VF-C components need to register to MSB when starting, so MSB components should be installed first,you can refer the following link to install MSB.
Before onboarding a package, should create one record first.
-1. Create VNF package record in catalog DB
+1. Create VNF package record in catalog DB
::
:width: 5.97047in
:height: 2.63208in
- c. before instantiate, you should create one volumntype which called root.
+ c. before instantiate, you should create one volumntype which is called root.
3. NS Heal
-H 'cache-control: no-cache'
Note:
- a. f0b4c09f-c653-438a-b091-5218b0f806ec is the ns instance id which create in step 1 : NS create
\ No newline at end of file
+ a. f0b4c09f-c653-438a-b091-5218b0f806ec is the ns instance id which create in step 1 : NS create
"is-provider-network": True,
"is-shared-network": True,
"is-external-network": True,
- "subnets": {
- "subnet": [
- {
- "subnet-id": self.related_subnetwork_id,
- "dhcp-enabled": False
- }
- ]
- },
+ # "subnets": {
+ # "subnet": [
+ # {
+ # "subnet-id": self.related_subnetwork_id,
+ # "dhcp-enabled": False
+ # }
+ # ]
+ # },
"relationship-list": {
"relationship": [
{
Code Review / vfc / nfvo / lcm.git / commitdiff