Network Service Descriptor support¶
https://blueprints.launchpad.net/tacker/+spec/nsd-support
This proposal describes the plan to add Network Service Descriptor(NSD) support in Tacker. To enable dynamic composition of network services, NFV introduces Network Service Descriptors (NSDs) that specify the network service to be created.
TOSCA NFV
+-----------------------------------+ +----------------+
| Service Template | | Network Service|
| +-------------------+ | | Descriptor |
| | Topology Template | | | |
| | +---------+ | +----------+| | +-----+ |
| | | Node | <--+-| NodeTypes|<----+----| VNFD| |
| | | Template| | +----------+| | +-----+ |
| | +---------+ | | | |
| | +---------+ | +----------+| | +-----+ |
| | | Node | <--+-| NodeTypes|<----+----| VLD | |
| | | Template| | +----------+| | +-----+ |
| | +---------+ | | | |
| | +---------+ | +----------+| | +-------+ |
| | | Node | <--+-| NodeTypes|<----+----| VNFFGD| |
| | | Template| | +----------+| | +-------+ |
| | +---------+ | | | |
| | +---------+ | +----------+| | +-----+ |
| | | Node | <--+-| NodeTypes|<----+----| PNFD| |
| | | Template| | +----------+| | +-----+ |
| | +---------+ | | | |
| +-------------------+ | | |
+-----------------------------------+ +----------------+
- As shown in above picture, NSD can includes VNFD, VNFFGD, VLD and PNFD.
VNFD –> Virtual Network Function Descriptor
VNFFGD –> VNF Forwarding Graph
VLD –> Virtual Link Descriptor
PNFD –> Physical Network Function
In current scope Tacker does not includes PNFD.
Problem description¶
Tacker builds a generic VNF Manager and a NFV Orchestrator to deploy and operate Virtual Network Functions (VNFs) on an NFV infrastructure platform like OpenStack. But currently needs the ability to describe and orchestrate a collection of VNFs to render a Network Service. It is desired by community to manage and orchestrate network service. NSD template is the way to introduce that capability.
To enable dynamic composition of network services, NFV introduces Network Service Descriptors (NSDs) that describe the network service to be created. NSDs mainly describes the what all network services to be instantiated in the NFVI. An NFV Orchestrator can use NSD to instantiate a network service which may have one or more VNFs, VLs and VNFFGs.
Tacker will provide the support for NSD so that user can orchestrate the collection of VNFs and network services. With NSD support, Tacker will provide a end-to-end TOSCA based network service.
Proposed change¶
Introduce a new template for network service which contains VNFs, connection points and virtual links.
+---------------------------------+
| Network Service Descriptor |
| |
| +--------+ |
| | VNF1 | |
| +--------+ |
| |
| +--------+ |
| | VNF2 | |
| +--------+ |
| |
| |
| |
| +--------+ |
| | VNFn | |
| +--------+ |
| |
| +------------+ |
| | End Point1 | |
| +------------+ |
| |
| +------------+ |
| | End Point2 | |
| +------------+ |
| |
| +-------------+ |
| |VirtualLink 1| |
| +-------------+ |
| |
| +-------------+ |
| |VirtualLink 2| |
| +-------------+ |
| |
| |
| +-------------+ |
| |VirtualLink m| |
| +-------------+ |
| |
+---------------------------------+
Multiple changes will be required, which includes changes to Tacker Client, Horizon, and Server.
+-------------------------------------------+
| +------------------+ |
| |Client Application| |
| +--------+---------+ |
| | |
| +------v-----+ |
| | NFVO NS +----------------+ |
| | API | | |
| +------+-----+ +--v---+ |
| | | VNFM | |
| | +---+--+ |
| | | |
| +------------v-------------+ +---v-+ |
| |Network Service Descriptor| | VNF | |
| +--------------------------+ +-----+ |
+-------------------------------------------+
API changes
New APIs in NFVO plugin will be introduced for NSD and NS.
DB Changes
New tables will be added in database for ‘nsd’ and ‘ns’. Changes in existing ‘vnfd’ will be required which involves substitution_mappings.
Mistral driver Changes
A new mistral driver layer between NFVO plugin and VNFM plugin to translate tosca template into mistral workflow and all mistral APIs to instantiate NS. This intermediate layer will provide a co-ordination between NFVO and Mistral. Like:
Generate workflow from TOSCA template.
Call Mistral interfaces for NS requests.
Wait in PENDING_CREATE state for NS until all VNFs goes to ACTIVE state.
Decide to move forward/backward in case of partial failure.
TOSCA Parser Changes
To handle nsd template, TOSCA parser should be configured. TOSCA parser will be updated to handle VNFD, VLD and CP for network service descriptor.
A sample Tosca template for VNFD is below.
Please refer appendix section for complete template.
node_types:
tosca.nodes.nfv.VNF1:
requirements:
- virtualLink1:
type: tosca.nodes.nfv.VL
required: true
capabilities:
forwarder1:
type: tosca.capabilities.nfv.Forwarder
topology_template:
substitution_mappings:
node_type: tosca.nodes.nfv.VNF1
requirements:
virtualLink1: [CP11, virtualLink]
capabilities:
forwarder1: [CP11, forwarder]
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
.
.
CP11:
type: tosca.nodes.nfv.CP.Tacker
.
.
CP12:
type: tosca.nodes.nfv.CP.Tacker
.
.
VDU2:
type: tosca.nodes.nfv.VDU.Tacker
.
.
CP13:
type: tosca.nodes.nfv.CP.Tacker
.
.
VL1:
type: tosca.nodes.nfv.VL
.
.
VL2:
type: tosca.nodes.nfv.VL
.
.
Proposed sample Tosca template for NSD:
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0
imports:
- VNF1
- VNF2
topology_template:
VNF1:
type: tosca.nodes.nfv.VNF1
requirements:
- virtualLink1: VL1
VNF2:
type: tosca.nodes.nfv.VNF2
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: net_mgmt
vendor: tacker
- Regarding above template:
‘CP’ property represents the connection points that will be exposed as part of VNF(mainly to support VNF forwarding graph in future).
For each VNF, VIM can be mentioned in properties section, otherwise pick the default one. In current scope, all VNF will be landed on the same VIM, which can be provided in input.
NOTE: The scope of this spec is to handle existing vnfd and defining APIs for NS and support creation of NS without creating the forwarding path.
Data model impact¶
Data model impact includes the creation of ‘NetworkServiceTemplate’, and ‘NetworkService’ resource model. The schema for these are as:
+--------------------------+
| nsd |
+--------------------------+
| id |
| name |
| type |
| description |
| network_service_template |
| project_id |
+--------------------------+
+-----------------+
| ns |
+-----------------+
| id |
| name |
| description |
| nsd_id |
+-----------------+
There is an impact on existing vnfd resource model. A new field ‘nsd_id’ will be added in vnfd for nsd. In normal VNFD list call, rows corresponding to ‘nsd_id’ will be empty.
REST API impact¶
NSD will needs to be created to instantiate Network Services. The method of creating NSD follows the TOSCA template scheme we mentioned in the above section.
Example CLI calls:
First create required VNFDs:
tacker vnfd-create vnf1 --vnfd-file samples/nsd/tosca-vnf1.yaml
tacker vnfd-create vnf2 --vnfd-file samples/nsd/tosca-vnf2.yaml
To create NSD:
tacker nsd-create --name NSD1 --nsd-file samples/nsd/tosca-nsd.yaml
To create NS
tacker ns-create --name ns1 --nsd-name NSD1 --vim-name VIM1 --param-file <PARAM-FILE>
--config-file <CONFIG-FILE>
Example param file:
vnfs:
VNF1:
vdu-name: VDU1
cp-name: CP11
nsd:
virtual-link: VL1
Example config file:
vnfs:
VNF1:
....config
/nsd
+------------------------------------------------------------------------+
|Attribute |Type |Access |Default |Validation/ |Description |
|Name | | |Value |Conversion | |
+------------------------------------------------------------------------+
|id |string |RO, All |generated |N/A |identity |
| |(UUID) | | | | |
+------------------------------------------------------------------------+
|name |string |RW, All |None |string |human+readable |
| | | |(required)| |name |
+------------------------------------------------------------------------+
|description |string |RW, All |'' |string |description of |
| | | | | |NSD |
+------------------------------------------------------------------------+
|network_servic|dict |RW, All |None |template/ |network service |
|e_template | | | |dict |template |
+------------------------------------------------------------------------+
|project_id |string |RW, All |None |string |project id to |
| | | |(required)| |launch NSD |
+------------------------------------------------------------------------+
+--------------------------------------------------------------------------+
|REST Calls |Type |Expected |Request |Response |Description |
| | |Response |Body Schema |Body Schema | |
+--------------------------------------------------------------------------+
|create_nsd |post |201 |create_req |create_resp |Creates NSD |
| | |Created | | | |
+--------------------------------------------------------------------------+
|delete_nsd |delete|204 No |None | |Deletes NSD by |
| | |Content | | |name or ID |
+--------------------------------------------------------------------------+
|show_nsd |get |200 OK |None |show_resp |Returns output of|
| | | | | |specific NSD ID |
+--------------------------------------------------------------------------+
|list_nsd |get |200 OK |None |list_resp |Returns list of |
| | | | | |NSD Names/IDs |
+--------------------------------------------------------------------------+
JSON Request and Response Sample:
POST /v1.0/nsds
create_req:
{
"nsd": {
"name": "NSD_demo",
"service_types": [
{
"service_type": "nsd",
}
],
"description": "Sample NSD",
"project_id": "4dd6c1d7b6c94af980ca886495bcfed0",
"network_service_template": {
"nsd": "vnf1: template_name: \r\ndescription: template_description\r\n "vnf2: template_name: OpenWRT \r\ndescription: template_description
},
}
}
create_resp:
{
"nsd": {
"name": "NSD_demo",
"service_types": [
{
"service_type": "nsd",
"id": "336fe422-9fba-47c7-87fb-d48475c3e0ce"
}
],
"description": "Sample NSD",
"project_id": "4dd6c1d7b6c94af980ca886495bcfed0",
"network_service_template": {
"nsd": "template_name: OpenWRT \r\ndescription:
template_description <sample_vnfd_template>"
},
"id": "ab10a543-22ee-43af-a441-05a9d32a57da",
}
}
GET /v1.0/nsds
List nsds - List nsds stored in the catalog.
list_res:
{
"nsds": [
"nsd": {
"name": "NSD_demo",
"service_types": [
{
"service_type": "nsd",
"id": "336fe422-9fba-47c7-87fb-d48475c3e0ce"
}
],
"description": "Sample NSD",
"project_id": "4dd6c1d7b6c94af980ca886495bcfed0",
"network_service_template": {
"nsd": "template_name: OpenWRT \r\ndescription:
template_description <sample_vnfd_template>"
},
"id": "ab10a543-22ee-43af-a441-05a9d32a57da",
}
]
}
GET /v1.0/nsds/{nsd_id}
Show nsd - Show information for a specified nsd id.
show_res:
{
"nsd": {
"name": "NSD_demo",
"service_types": [
{
"service_type": "nsd",
"id": "336fe422-9fba-47c7-87fb-d48475c3e0ce"
}
],
"description": "Sample NSD",
"project_id": "4dd6c1d7b6c94af980ca886495bcfed0",
"network_service_template": {
"nsd": "template_name: OpenWRT \r\ndescription:
template_description <sample_vnfd_template>"
},
"id": "ab10a543-22ee-43af-a441-05a9d32a57da",
}
}
/ns
+-----------------------------------------------------------------------+
|Attribute |Type |Access |Default |Validation/ |Description |
|Name | | |Value |Conversion | |
+-----------------------------------------------------------------------+
|id |string |RO, All |generated |N/A |identity |
| |(UUID) | | | | |
+-----------------------------------------------------------------------+
|name |string |RW, All |None |string |human+readable |
| | | |(required)| |name |
+-----------------------------------------------------------------------+
|description |string |RW, All |'' |string |description of |
| | | | | |NSD |
+-----------------------------------------------------------------------+
|vim_id |string |RW, All |None |string |VIM ID where it |
| | | |(required)| |launches |
+-----------------------------------------------------------------------+
|project_id |string |RW, All |None |string |project id to |
| | | |(required)| |launch NSD |
+-----------------------------------------------------------------------+
|nsd_id |string |RW, All |None |string |NSD id to launch |
| | | |(required)| | |
+-----------------------------------------------------------------------+
|attributes |dict |RW, All |None |dict |dict containing |
| | | |(required)| |config and/or |
| | | | | |param values |
+-----------------------------------------------------------------------+
+-----------------------------------------------------------------------+
|REST Calls |Type |Expected |Body Data |Response |Description |
| | |Response |Schema |Body Schema| |
+-----------------------------------------------------------------------+
|create_ns |post |202 |schema 1 | |Creates NSD |
| | |Accepted | | | |
+-----------------------------------------------------------------------+
|delete_ns |delete|202 |None | |Deletes NSD by |
| | |Accepted | | |name or ID |
+-----------------------------------------------------------------------+
|show_ns |get |200 OK |None | |Returns output of |
| | | | | |specific NSD ID |
| | | | | | |
+-----------------------------------------------------------------------+
|list_ns |get |200 OK |None | |Returns list of |
| | | | | |NSD Names/IDs |
+-----------------------------------------------------------------------+
Security impact¶
Notifications impact¶
None
Other end user impact¶
Performance Impact¶
None
Other deployer impact¶
Developer impact¶
Using Mistral workflow for nsd:
Use Mistral workflow for nsd feature. Tacker NFVO will generate Mistral workflow through workflow generator and call to Mistral for generated workflow request. Mistral will create the resources(VNFs, FFG) and respond to NFVO.
+-------------------------------------------+
| +------------------+ |
| |Client Application| |
| +--------+---------+ |
| | +-------------+ |
| +-----v----+ | Workflow | |
| | NFVO:NSD +-------> Generator | |
| +-----+----+ +---------+---+ |
| | | |
| +------------v-------------+ +----v---+ |
| |Network Service Descriptor| | Mistral| |
| +--------------------------+ +----+---+ |
| | |
| +---v--+ |
| | VNFM | |
| +------+ |
+-------------------------------------------+
- Pros:
1: Workflow can already handle multiple cases. 2: In case of failure at any point of time, rollback possible. 3: I think implementation of nsd like feature by using mistral workflow should be easy. 4: After embading mistral with Tacker, any workflow or other already coded such remediation will be in the reach of Tacker.
- Cons:
- Mistral as third Component:
- 1: As the Mistral is third components, so:
Any changes in mistral may impact the nsd flow.
Sometimes in case of compatibility or other issues may be we needs to work with Mistral team.
Mistral takes json file in input, so first we needs to create these json data. In case of large number of VNFDs, multiple files will be created. Needs to handle these creation/cleanup. (an investigation in this part required)
- For an ns call:
tacker –> Mistral –> tackerClient –> tacker Multiple context switching leads time consuming.
- 2: An auto-generated workflow can be error prone, should be more
careful while creating mistral workflow to handle corner cases.
- 3: We have to generate workflow for each resource in nsd
template(i.e . vnfd/vnf) which might be complex in case of large number of vnfs etc.
Implementation¶
Assignee(s)¶
- Primary assignee:
Dharmendra Kushwaha
- Other contributors:
Bharath Thiruveedula <bharath_ves@hotmail.com>
Work Items¶
New APIs in NFVO plugin for NSD and NS
NFVO plugin side implementation.
Tacker DB configuration for ‘NetworkServiceTemplate’ and ‘NetworkService’.
TOSCA parser support for NSD.
Mapping of TOSCA node to workflow task.
Workflow generator: TOSCA parser will iterate through the each nodes in template and then convert them into tasks.
Calls from NFVO-NSD plugin to Mistral to instantiate NS.
Logic to wait in PENDING_CREATE state for NS until all VNFs goes to ACTIVE state
Logic to take parameters at NS level and pass it onto VNFs
Changes for in tacker-horizon and python-tackerclient for NSD.
Documentation to explain NSD support feature.
Unit test cases
Functional test cases
Dependencies¶
None
Testing¶
Unit testing¶
Unit tests will be added for new interfaces. New test cases will be introduced in VNFM for the related extensions.
Functional testing¶
Functional tests will be added to check the deployed state of all the VNFs.
Documentation Impact¶
User Documentation¶
User documentation will describe the NSD features, operations with samples. Python-tackerclient and tacker-horizon side documentation will be added to describe cli/interface details.
Developer documentation¶
Add developer documentation for the api and usage details
References¶
Appendix¶
TOSCA sample vnf1¶
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Demo example
node_types:
tosca.nodes.nfv.VNF1:
requirements:
- virtualLink1:
type: tosca.nodes.nfv.VL
required: true
- virtualLink2:
type: tosca.nodes.nfv.VL
required: true
capabilities:
forwader1:
type: tosca.capabilities.nfv.Forwarder
forwader2:
type: tosca.capabilities.nfv.Forwarder
topology_template:
substitution_mappings:
node_type: tosca.nodes.nfv.VNF1
requirements:
virtualLink1: [CP11, virtualLink]
virtualLink2: [CP14, virtualLink]
capabilities:
forwarder1: [CP11, forwarder]
forwarder2: [CP14, forwarder]
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
properties:
image: cirros-0.3.4-x86_64-uec
flavor: m1.tiny
availability_zone: nova
mgmt_driver: noop
config: |
param0: key1
param1: key2
CP11:
type: tosca.nodes.nfv.CP.Tacker
properties:
management: true
anti_spoofing_protection: false
requirements:
- virtualBinding:
node: VDU1
- virtualLink:
node: VL1
CP12:
type: tosca.nodes.nfv.CP.Tacker
properties:
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL2
- virtualBinding:
node: VDU1
VDU2:
type: tosca.nodes.nfv.VDU.Tacker
properties:
image: cirros-0.3.4-x86_64-uec
flavor: m1.medium
availability_zone: nova
mgmt_driver: noop
config: |
param0: key1
param1: key2
CP13:
type: tosca.nodes.nfv.CP.Tacker
properties:
management: true
requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU2
CP14:
type: tosca.nodes.nfv.CP.Tacker
requirements:
- virtualBinding:
node: VDU2
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: net_mgmt
vendor: Tacker
VL2:
type: tosca.nodes.nfv.VL
properties:
network_name: net0
vendor: Tacker
TOSCA sample vnf2¶
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Demo example
node_types:
tosca.nodes.nfv.VNF2:
capabilities:
forwarder1:
type: tosca.capabilities.nfv.Forwarder
topology_template:
substitution_mappings:
node_type: tosca.nodes.nfv.VNF2
capabilities:
forwarder1: [CP21, forwarder]
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
properties:
image: cirros-0.3.4-x86_64-uec
flavor: m1.tiny
availability_zone: nova
mgmt_driver: noop
config: |
param0: key1
param1: key2
CP21:
type: tosca.nodes.nfv.CP.Tacker
properties:
management: true
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU1
VDU2:
type: tosca.nodes.nfv.VDU.Tacker
properties:
image: cirros-0.3.4-x86_64-uec
flavor: m1.medium
availability_zone: nova
mgmt_driver: noop
config: |
param0: key1
param1: key2
CP22:
type: tosca.nodes.nfv.CP.Tacker
requirements:
- virtualLink:
node: VL2
- virtualBinding:
node: VDU2
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: net_mgmt
vendor: Tacker
VL2:
type: tosca.nodes.nfv.VL
properties:
network_name: net0
vendor: Tacker
TOSCA sample nsd template¶
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
imports:
- VNF1
- VNF2
topology_template:
node_templates:
VNF1:
type: tosca.nodes.nfv.VNF1
requirements:
- virtualLink1: VL1
VNF2:
type: tosca.nodes.nfv.VNF2
VL1:
type: tosca.nodes.nfv.VL
properties:
network_name: net_mgmt
vendor: tacker
TOSCA sample nsd params¶
vnfs:
vnf1:
vdus:
vdu1:
param:
vdu-name: ns-test-vdu11
vdu2:
param:
vdu-name: ns-test-vdu12
cp11:
param:
cp-name: ns-test-cp11
cp12:
param:
cp-name: ns-test-cp12
vnf2:
vdus:
vdu1:
param:
vdu-name: ns-test-vdu21
vdu2:
param:
vdu-name: ns-test-vdu22
cp21:
param:
cp-name: ns-test-cp21
cp22:
param:
cp-name: ns-test-cp22