Service Function Chaining (SFC) leverages Network Function Virtualization (NFV) and Software Defined Networking (SDN) to create a programmable and dynamic network paradigm that allows networks to keep up with modern demands. This article briefly discusses the importance of SFC, how it works, and its architecture.
NFV and SDN in SFC
In a traditional network, network functions such as firewalls exist as hardware devices, and there exists a tight coupling between network functions and the network infrastructure. Since these functions exist as hardware devices, we cannot easily add or remove them. Scaling them both vertically and horizontally also becomes a problem. This is because such actions entail disrupting the network and manually reconfiguring the network topology, neither of which is acceptable in a real-world environment.
Network Function Virtualization (NFV) overcomes this problem by allowing us to deploy network functions as Virtual Network Functions (VNFs) on commercial servers. This allows us to add, remove, and scale network functions easily with minimal service disruption. However, NFV still doesn’t address the topological changes that we may have to make.
Here is where Software Defined Network (SDN) comes into the picture. SDN decouples the control plane of a networking device such as a switch from the data plane and centralizes it in a controller. This means switches only forward data packets to the right destination while the controller takes the forwarding decisions. We can programmatically control these controllers, meaning that we can control the entire network programmatically.
SDN provides the missing piece so that we can now add, remove, and scale network functions while not having to manually configure the network topology. Let’s now see how SFC uses both NFV and SDN to accomplish this in detail.
As we discussed earlier, the problem with traditional network functions is their tight coupling with hardware. SFC addresses this by creating a virtual layer above the physical network. We call this virtual layer a service overlay. Since it is virtual, we can programmatically control this. NFV virtualizes network functions and makes it a part of the overlay. On the other hand, SDN helps establish virtual links between these network functions by programmatically establishing links over the physical network.
The above diagram shows a service overlay on top of a physical network. Here firewall, Intrusion Detection System (IDS), and load balancer are VNFs. We deploy these VNFs on servers on the physical network using NFV. Then, we use SDN to programmatically establish links between the servers so that we can chain these VNFs together to form a Service Function Chain (SFC).
The Internet Engineering Task Force (IETF) defines SFC as “the definition and instantiation of an ordered set of service functions and subsequent ‘steering’ of traffic through them”. SFC has its applications in 5G network slicing, mobile core networks, data centers, and edge computing. Just like how the cloud has replaced on-prem service deployments, with SFC, enterprises can outsource their on-premise network functions to service providers. The service providers can rapidly spin up the needed SFCs for their customers, abstracting away the deployment and maintenance tasks.
Accordingly, a client who needs a firewall, IDS, and load balancer for their web servers can simply request a service provider for an SFC consisting of these network functions and have the traffic routed through the SFC before reaching their servers. However, it is a challenge for a provider to cater to multiple such SFCs. IETF introduced an architecture for SFCs to help with this.
An SFC architecture consists of Service Functions (SFs), Service Classification Function (SCF), Service Function Forwarders (SFFs), and SFC Proxies. Service Functions are VNFs that we deploy on servers. The Service Classification Function classifies incoming traffic and decides which traffic needs to go through which SFC. This helps when a network caters to different clients and requests. To route traffic through different SFCs, SCF uses SFC encapsulation. An SFC encapsulation tells which Service Function Path (SFP) a traffic flow belongs to. An SFP is the path taken by a traffic flow belonging to an SFC.
An SFP can be specific or abstract depending on how the operator designed it. Generally, it is an abstract definition of a path. If we consider our previous example, an SFP could describe the path as firewall > IDS > load balancer. However, a Rendered Service Path (RSP) provides an explicit description of the path that a traffic flow takes. This includes the specific instances of VNFs and the SFFs it needs to go through.
An SFF is responsible for one or more SFs. The traffic meant for an SF has to first go through the corresponding SFF. The SFF then decides which SF to forward the traffic to. Once the SF processes the traffic, it forwards it back to the SFF. If the next VNF in the SFC also belongs to the same SFF, then the SFF forwards the traffic to the next SF. If not, the SFF forwards the traffic to the SFF of the next SF.
At the same time, there could be legacy SFs in the network that may not be aware of SFCs. In such cases, we use an SFC proxy. The proxy removes the SFC encapsulation before forwarding the traffic to the legacy SF. Once it receives the processed traffic, it re-encapsulates the traffic and forwards it to the next entity.
This article introduced the idea of Service Function Chaining (SFC), discussed its importance, and explained the SFC architecture briefly. SFCs make use of NFV and SDN to create a virtual layer consisting of VNFs and virtual links between them. This allows operators to quickly deploy, manage, and scale network functions. This means that enterprises can now outsource their network functions and have them quickly set up for them by service providers. The SFC architecture provides a framework to route traffic from multiple such enterprise clients through SFCs meant for them. Given the many potential benefits they offer, SFCs have a bright future in 5G, mobile core networks, data centers, and edge computing.