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, the SDN team had already worked on 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) – based orchestrators and Network Function Virtualization (NFV) – based orchestrators.
To do so, and also to make a step towards automatizing the SFC management with Netfloc, we created a Heat plugin for Netfoc. It 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, the IP and the port of the Netfloc node, along with the Neutron port IDs of the VNF instances.
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 type 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 to a virtual proxy VNF and a deep packet inspection VNF.
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:
Create Chain:
POST [Netfloc_URL]/restconf/operations/netfloc:create-service-chain
Headers: Content-Type: application/json
Body: {"input": { neutron-ports : $neutron_ports } }
Response: 201 (application/json)
Body: {"output“: { "service-chain-id":$chain_id }Delete Chain:
POST [Netfloc_URL]/restconf/operations/netfloc:delete-service-chain
Headers: Content-Type: application/json
Body: {"input": {service-chain-id :$chain_id }}This library grants to Netfloc an interoperability with OpenStack based orchestration engines. An example of how to use it, has been shown within the scope of the T-Nova project for an SFC demonstration. We have also integrated it with our home made Hurtle orchestrator shown in a joint 5G-cloud demo at the EUCNC conference.
Apart from the standard inclusion of the netfloc.py file in your heat plugin repo, you need to have a Netfloc-controlled OpenStack cloud, to be able make a use of it. Employing Netfloc achieves a full 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 the de facto Neutron-based GRE/VxLAN encapsulation mechanisms, to exclusively L2-based SDN environment.
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 has to be converted to ETSI-MANO specific template. This implies describing the SFC using the parameters of the Network Service Descriptor (NSD) template that is used by the NFV Orchestrator to instantiate a Network Service.
According to ETSI-MANO specification for Network Functions Virtualization (NFV) Management and Orchestration, the NSD describes the relationship between virtual and/or physical network functions, VNFs and PNFs, defining their connection links (VLDs) in the NFVI network.
Figure1: Network Service information elements
Figure 1 depicts the NS building blocks from the specification. The NSD is a template file that includes the descriptors of the NS constituent components: VNFs/PNFs, VNFFG, and VLDs.
- VNF Descriptor (VNFD) describes a VNF in terms of its deployment and operational behaviour requirements, such as VNF instantiation and lifecycle management among the others.
- VNF Forwarding Graph Descriptor (VNFFGD) describes a topology of the Network Service with reference to the VNFs and their Virtual Links. A Network Service can define more VNF Forwarding Graphs (VNFFG), to enforce traffic steering on different levels: Control plane, Management plane, and User plane.
- Virtual Link Descriptor (VLD) describes the resource requirements that are needed for a link between VNFs, PNFs and endpoints of the Network Service.
From the above said, it is very simple to convert Netfloc’s SFC specification (from Heat) to ETSI context, by simply adapting the template parameters in the NSD.
Following the T-Nova NSD descriptor template, the example below demonstrates how a Netfloc HoT conversion to ETSI-MANO NSD would look like. The first snippet shows part of the yaml template for chain creation specific to HoT:
chain_create:
type: Netfloc::Service::Chain
depends_on: [ vnf_vTC, vnf_vTC_f, vnf_vProxy, vnf_vTC_out1_port, vnf_vTC_f_in_port, vnf_vTC_f_out_port, vnf_vProxy_in_port ]
properties:
port1:
get_resource: vnf_vTC_out1_port
port2:
get_resource: vnf_vTC_f_in_port
port3:
get_resource: vnf_vTC_f_out_port
port4:
get_resource: vnf_vProxy_in_port
odl_username : { get_param: odl_username }
odl_password: { get_param: odl_password }
netfloc_ip_port: { get_param: netfloc_ip_port }The corresponding VNFFGD for the network chain should look like the following part of a NFV NSD template:
....
vnffgd:
id: "418420e3-e2a8-4338-bc8c-be685548bad2"
vendor: "T-Nova"
version: "1.0"
ns_version: "1.0.0"
vnffg_id:
- vnffg0:
number_of_endpoints: 4
number_of_virtual_links: 2
depedent_virtual_links: ["vld1","vld2"]
network_forwarding_path:
- nfp0:
graph: ["vld1","vld2"]
connection_points: ["data0","data1","data2","data3"]
constituent_vnfs: ["vnfd0:vTC", "vnfd0:vMT", "vnfd2:vProxy"]Since Netfloc SFC requires an ordered list of connection_points to enforce a traffic steering, the parameters [“data0”,”data1″…] should match the Neutron IDs of the VNFs in the chain, equivalent to the “port1”,”port2″… resource properties of the HoT template. Including multiple service function chains, translates to defining multiple network_forwarding_path descriptions in the VNFFGD. Adaptation of the described template to TOSCA-NFV specification can be achieved by applying the same logic.
An example reference project of the discussed ETSI NFV MANO specification is OpenMano that includes own descriptor files, similar as the one described in T-Nova. The Sesame project our lab is involved in, will also implement an adaptation of the descriptor files for its Sesame-specific services. Finally, OpenStack has a Heat-translator project to facilitate the conversion from non-HoT templates (example TOSCA yaml) to HoT-specific templates.