Link Search Menu Expand Document

Service Function Chaining

Table of contents

Overview

Service Function Chaining (SFC) refers to the use of Software-Defined Networking (SDN) programmability to create a service chain of connected (virtual) network services. One advantage of using SFC is to automate the way virtual network connections can be set up to handle different types of traffic flows. This image below from an SDXCentral article is an example of how SFC is set up and operate.

SFC example

In Gini5, the SFC feature is an extra component of POX controller and cloud instances. It can only be activated when a cloud instance is connected to an OVS, and the OVS is connected to a POX controller.

For further reading on Service Function Chaining design and architecture, you can visit these pages:

Virtual network functions (VNF)

Similar to many virtualization techniques, VNF is an attempt to bring networking hardwares into compact and much more extensible software programs. Examples include firewalls, intrusion protection systems, network monitor, etc. Gini5 provides some lightweight virtual network functions, packaged into Docker images and make use of built-in UNIX networking utilities like iptables. It is very easy to add more custom VNF images as users want.

Cloud manager and SDN controller

As introduced in previous section about Cloud component, a cloud manager is a Python script capable of controlling all services running within a single cloud instance. In addition to handling all services, said program can also be used to manage VNF and SFC, as long as an SDN controller is present.

The SFC feature of Gini5 is quite simplified so some components of modern SFC might be missing, such as Network Service Headers (NSH). For the most part, the SDN controller (POX) has a component that communicates with the cloud manager to update what VNF is being added to the network, and what Service Chain is created in order to install flow rules in relevant virtual switches. VNF and SFC are specified by users, and routing is done in the background by the SDN controller. There are some terminologies used in Gini5 that may not be familiar:

  • Service node: refers to a single instance of VNF, running in a Docker container
  • Service chain: ordered list of service nodes
  • Service path: path from a source machine to a destination machine that traverses a service chain in order. For example, the list Host A -> Firewall -> IPS -> Rate limiter -> Host B forms a service path with source A and destination B, and a service chain made up of 3 different VNFs in the middle.

Using the cloud manager command-line interface

Here are the commands that can be used for SFC-related actions:

Command Description
sfc_init This command MUST be used before using any other SFC-related commands
sfc_addnode SERVICE NAME Create a new VNF instance
sfc_delnode NAME Delete an active VNF instance
sfc_listnode List all active VNF instances and display their information
sfc_addchain SERVICE_LIST Create a service function chain from active VNF instances, the unique ID of the created chain will be returned on success
sfc_delchain CHAIN_ID Delete an existing SFC using its unique ID
sfc_listchain List all existing SFC and display their information
sfc_addpath SRC DST CHAIN_ID Create a service path from source to destination that goes through a service chain. Either source or destination can be the Internet, which means all traffic from external network. Only one service path from source to destination can exist
sfc_delpath SRC DST Delete a service path from source to destination
sfc_listpath List all existing service paths and display their information

Examples

To improve security and Quality-of-Service (QoS) for cloud services, redirecting traffic through a set of predefined network functions for firewall filtering, Intrusion Protection System (IPS) investigation is often a good idea and a common use case for Service Function Chaining.

Let’s look at this network topology with a cloud instance connected by an OVS:

SFC topology

Start the network, and then right click the POX Controller icon > Load modules > Custom > gini.custom.service_function_chaining. We can then open Cloud_1’s terminal, and do the following:

$ start citelab/flask-server:latest web 80

This starts a web service running on port 80. Open Mach_4’s terminal and send an HTTP request to the proxy IP address. It will return a reply from the actual container hosting the web application. Suppose that we want to block all traffic from the internet to this web service. This is equivalent to applying a block-all filter on this specific flow of traffic. Here is what we can do using SFC:

$ sfc_init
SFC orchestrator started
$ sfc_addnode firewall f01
Service added
$ sfc_addchain f01
Service chain created with id 7a93b5007f40-1
$ sfc_addpath internet web 7a93b5007f40-1

Mach_4 will no longer see reply from the web server container because traffic distributed from the proxy to containers running web now has to go through a middle container running a firewall application. By default, the firewall drops all traffic instead of forward them. So the web container cannot receive any request from the proxy server, or more correctly, Mach_4.

To remove this service chain, run the following command:

$ sfc_delpath internet web

And send HTTP requests from Mach_4 again, we can now see replies from the web server like before.