{"id":10402,"date":"2016-08-02T14:21:37","date_gmt":"2016-08-02T12:21:37","guid":{"rendered":"https:\/\/blog.zhaw.ch\/icclab\/?p=10402"},"modified":"2016-08-04T15:08:29","modified_gmt":"2016-08-04T13:08:29","slug":"orchestrate-your-network-service-with-netfloc-plugin-for-openstack-heat","status":"publish","type":"post","link":"https:\/\/blog.zhaw.ch\/icclab\/orchestrate-your-network-service-with-netfloc-plugin-for-openstack-heat\/","title":{"rendered":"Orchestrate your network service with Netfloc plugin for OpenStack Heat"},"content":{"rendered":"

Stitching virtual network functions (VNFs) together in a so called Network (Service) Function Chain is not a novelty any longer. Described in our previous post<\/a>, the SDN team had already worked\u00a0on creating SFC library support for OpenStack in our SDK for SDN. In this blog we describe the advances made towards integrating Netfloc services with both, Heat Orchestration Template (HoT) \u2013 based orchestrators and Network Function Virtualization (NFV) \u2013 based orchestrators.<\/p>\n

To do so, and also to make a\u00a0step towards automatizing the SFC management with Netfloc, we created a Heat plugin for Netfoc<\/a>.\u00a0It is based on the Netfloc API library for managing network service chains in OpenStack clouds. The parameters required to create the service include: OpenDaylight credentials<\/em>, the IP<\/em> and the port<\/em> of the Netfloc node<\/em>, along with the Neutron port IDs<\/em> of the VNF instances.<\/p>\n

For a network service operator, applying the plugin makes it very simple to deploy multiple chains in OpenStack cloud infrastructure. An example includes a packet inspection VNF that determines if the traffic is video and the\u00a0type of the video service, and sends it further to a virtual transcoding unit VNF for quality adjustment. If data traffic is detected, packets are steered to a virtual security appliance acting as a virtual firewall, which sends them further\u00a0to a virtual proxy VNF and a deep packet inspection VNF.<\/p>\n

<\/p>\n

The functionality boils down to collecting the Neutron port IDs of the VNFs to be chained, and handing them over to the following APIs calls:<\/p>\n

Create Chain:<\/p>\n

POST [Netfloc_URL]\/restconf\/operations\/netfloc:create-service-chain\r\nHeaders: Content-Type: application\/json\r\nBody: {\"input\": {\u00a0neutron-ports : $neutron_ports\u00a0} }\r\nResponse: 201 (application\/json)\r\nBody: {\"output\u201c: { \"service-chain-id\":$chain_id }<\/code><\/pre>\n
Delete Chain:<\/p>\n
POST [Netfloc_URL]\/restconf\/operations\/netfloc:delete-service-chain\r\nHeaders: Content-Type: application\/json\r\nBody: {\"input\": {service-chain-id :$chain_id }}<\/code><\/pre>\n
This library grants to Netfloc an interoperability with OpenStack based orchestration engines.\u00a0An example of how to use it, has been shown within the scope of the T-Nova project for an\u00a0SFC demonstration<\/a>. We have also integrated it with\u00a0our home made Hurtle orchestrator<\/a> shown in a joint 5G-cloud demo at the EUCNC conference<\/a>.<\/p>\n
Apart from the standard inclusion of the\u00a0netfloc.py<\/em>\u00a0file in your heat plugin repo, you need to have a Netfloc-controlled OpenStack cloud, to be able make a use of it. Employing\u00a0Netfloc\u00a0achieves\u00a0a\u00a0full SDN based cloud via the OpenStack Neutron ML2 plugin. In your infrastructure, this changes the wiring between the OVS ports of the switch and the physical interfaces on the OpenStack hosts and substitutes\u00a0the\u00a0de facto Neutron-based GRE\/VxLAN encapsulation mechanisms, to exclusively L2-based SDN environment.<\/p>\n
To leverage NFV architectures with Netfloc services, few adaptations are required. The NFV orchestrators are bind to the ETSI-MANO model (see below), thus to automatically deploy Netfloc services, the Netfloc HoT template\u00a0has to be converted to ETSI-MANO specific template.\u00a0This implies describing the SFC using the parameters of the\u00a0Network Service Descriptor (NSD) template that is used by the NFV Orchestrator to instantiate a Network Service.<\/p>\n
According to ETSI-MANO specification<\/a>\u00a0for\u00a0Network Functions Virtualization (NFV) Management and Orchestration,\u00a0the NSD describes the relationship between virtual and\/or physical network functions, VNFs and PNFs, defining their connection links (VLDs) in the NFVI network.<\/p>\n
\"nfv-mano\"<\/a><\/p>\n
\n
\n
\n
Figure1: Network Service information elements<\/p>\n<\/div>\n<\/div>\n<\/div>\n
Figure 1 depicts the NS building blocks from the specification. The\u00a0NSD is a template file that includes the descriptors of the NS constituent components: VNFs\/PNFs, VNFFG, and VLDs.<\/p>\n