Service chaining is one of those heavily overloaded terms used in the industry in relation to SDN at this moment, but really it’s just a catch-all phrase for being able to have multiple services strung together and have the output of one service move into the input of another.
All providers have services that interact with each other and when you make the choice to use one service the next service downstream is the next link in the chain. So, whenever information is sent across a network it passes through various key points that are most probably on several different networks. This could include for example wireless networks, private networks, the public internet, or a metro link, and each network boundary will have a device or devices that set the specific policies for all traffic requesting to traverses that network.
Traditionally these devices have been inline network appliances such as firewalls and WAN optimizers that each set specific policies - for a firewall this might be access control as well as Deep Packet Inspection, for example.
Automation through virtualization
Network Functions Virtualization (NFV), that often accompanies an SDN deployment abstracts the services from the specialist hardware and puts them on a more generic multi-purpose box. The benefit here is that with inline, specialist hardware, all traffic has to flow through each appliance, whether it needs to or not. With virtual services, although all traffic flows through the appliance, you can choose which services apply to it, so the service chain is customized on a case-by-case basis, increasing agility and reducing network overhead.
The consideration for most IT and network managers is that for every choice you make along the way in terms of network controller or even provider that you use, it affects the options downstream on that service chaining tree. When what you want to do is make your options as broad as possible.
And there’s no escaping it because most organizations are already consuming most, if not all of these services - from firewalls, to DoS mitigation, and packet analysis to see what’s going on in your network and ensure your privacy controls comply with local laws. But traditionally you would be manually stitching these services together so you would have to figure out where the interaction points are and what needs to occur to traffic going from one service into the next, which adds a lot of unnecessary burden to the whole process.
Respond dynamically to environment changes
But the ability of SDN is to automate these various flows and monitor them and then react to them in real-time - a capability that is becoming increasingly critical to business. It’s almost like a machine learning type behavior in that you can dynamically respond to and influence your traffic flow by programming it so that the output of the firewall takes one route, or traffic that needs to stay within a certain region takes another route.
From a security perspective, if you do come under attack, you want the system to be able to go ahead and respond and take actions that you have designed for your infrastructure, rather than having to wait for someone to see a blip on a dashboard in the network operations center before taking any action.
Ultimately, the concept of service chaining benefits the business both by reducing your time to market and increasing the ability to be agile. As with many benefits of SDN, automation is the primary advantage of network service chaining when it comes to the way virtual network connections can be set up to handle traffic flows for connected services. It’s essentially automating what network administrators do when they connect up a series of physical devices to handle incoming and outgoing traffic, through a series of manual steps.