One of the emerging topics of conversation related to Software-Defined Networking (SDN) has been something called “service chaining”. The topic has gotten a fair bit of media focus of late, resulting in an increase in the amount of inquiry on this topic. From the questions I’ve been getting, though, its become obvious to me that most network professionals don’t fully understand how service chaining works, or when it might be used, so I thought I would explain it as best as I can
Whenever information is sent across a network it passes through a number of points on various networks. Depending on where the packets are travelling from and to this could include wireless networks, private networks, Internet connections, a metro link, or another type of network. As the packets cross these network boundaries, each of the network owners has a specific set of policies that take action on the packets before they are allowed to traverse that network.
To enforce these policies, the network owners (enterprises, mobile operators, or service providers) put appliances in the path of packet flow. These appliances could include things like firewalls, ADCs, and WAN Optimizers. There’s nothing really new or innovative here as these have been core building blocks of networks for years.
However, let’s consider these devices and what they do. All of these network devices actually provide a set of services, not a single function. A firewall provides firewalling capabilities but also other network services such deep packet inspection, access control, and network address translation. Similarly, a WAN optimizer can compress traffic, apply QoS policies, or perform other functions related to traffic optimization. However, there’s no real reason that every packet must have every service applied to it. Heck, there’s no real reason why each packet even has to flow through every device. But, that’s exactly what happens today with in-line appliances. They’re in-line, so by definition, all packets must go through them.
Network functions virtualization (NFV) allows for the services within a box to be pulled out of the box and run on off-the-shelf hardware. The network owner merely needs to spin up a VM per function to run each service on. They’re not exactly “in-line” per se, but traffic flows can be directed to whatever service is required on a per-flow basis.
With this architecture the network owner can run the packets through only the services that are required. So flow A can pass through virtual services 1, 2 and 4, where flow B will be routed through only services 2 and 5. Services can be inserted into the flow simply by spinning up more VMs and the traffic flow is controlled by an SDN controller, script, or other method. The key is that the “service chain” can be customized on a per-flow basis, resulting in less overhead on the network appliances.
The downside of service chains is that the extra routing of packets adds a bit of latency to the overall flow. Most in-line devices are built for wire speed performance so there’s little latency added. VMs on general-purpose hardware add agility but it generally isn’t wire speed. Also, the traffic engineering can become more difficult as the packet flows need to be managed independently.
It seems that, in life, everything has trade offs and service chaining is no different. To me, the benefit you get from it far outweighs the downside and I’m expecting this to be a hot topic moving into 2015.