OpenStack in 2019: Steady Progress and New Directions
by Curtis Collicutt on May 28, 2019
Predictions for Edge Computing in 2019
by Curtis Collicutt on March 12, 2019
Kubernetes Persistent Volumes with NetApp Trident
by Curtis Collicutt on February 11, 2019
Layer 1 SFC with BigSwitch
by Curtis Collicutt on February 4, 2019
100,000 Carrier Clouds Coming Online
by Curtis Collicutt on January 28, 2019
Service Function Chaining (SFC), which I will describe in this post, is an important feature that arises out of Software Defined Networking (SDN) and Network Function Virtualization (NFV). SFC is most applicable to telecommunications companies or in security applications, but also has broader application.
Currently the networking space is an interesting one. Basic IPv4 networking with layer 3 routing based on some form of Border Gateway Protocol (BGP) has worked well for decades. It’s well understood and has created a considerable amount of value. So, on one hand, generally speaking, large scale networking seems to be working well enough. However, on the other hand, we have all kinds of interesting new network-related technologies such as SDN, generic network automation, disaggregation of network operating systems/hardware, and Intent Based Networking (IBN), to name a few. This is resulting in a ‘push-and-pull’ between standard heritage networking methodologies and new technology.
Regardless of where you stand, SDN is fascinating because once network packets, routing decisions, etcetera, are pushed into software then anything becomes possible. Things like SFC become relatively easy to implement because everything is done in software. While SDN is not exactly like server virtualization, some of the same benefits apply to SDN, and I think by now most will agree that virtualization provides considerable business value. Ultimately, it’s safe to say that some organizations will require SDN in order to continue to be successful.
SFC is a relatively simple idea. Historically telecoms have had physical devices that perform some kind of specialized function. These devices are expensive and are difficult to reconfigure in terms of their networking behavior. The canonical example is several physical devices or appliances directly connected to one another in a chain: they are a series of “bumps in the wire.” SFC takes that physical chain and makes it completely virtual, and what’s more, uses some form of SDN to manage that chain and make it flexible and easy to alter dynamically.
OpenStack, an important component in most NFV deployments, has a relatively new project called networking-sfc which provides this functionality via a plugin to OpenStack’s networking system Neutron. The project’s definition of SFC is one of the best I have read:
Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet’s destination IP address. It is most commonly used in conjunction with Network Function Virtualization when recreating in a virtual environment a series of network functions that would have traditionally been implemented as a collection of physical network devices connected in series by cables.
To sum up, the path a packet takes through an SDN or SFC system is based on any number of arbitrary algorithms and variables, as opposed to the ones we are accustomed to with standard layer 3 hop-by-hop routing or the 5-tuples. SFC looks more like virtual ports that are directly connected to one another in a set of defined ingress/egress port pairs.
At IDX Labs, we have spent considerable effort building SFC implementations with several SDN technologies including networking-sfc. In future posts we will explore some of those SDN systems and discuss other models of SFC as well as examine several use cases and examples of complex implementations.
Hopefully this post has provided a basic introduction to what SFC is and the value it can provide. Once the network is defined in software, anything is possible.