Is it a service chain or a service chain?

Huh? What did you just say? Yes, that’s an odd question to ask. But in the world of SDN, NFV and L4-L7 services it’s a relevant one. This is a problem we’ve taken head on at CPLANE with our new Multi-Site Manager product.

Service chains are important in the new world of programmable and virtualized networks. They determine the order in which things should happen. They impose discipline. So what is a service chain, and why the question?

Service chain (or service chaining as it is often used) is a term that has been used interchangeably when referring to a sequence of actions that are applied to a data stream as it passes through an ingress or egress point in a physical or virtual network device. For example, you can have a service chain in a gateway router that performs several different functions. Drop any non-HTTP traffic. Load balance across a series of destinations. Tweak the QoS. Convert from one protocol to another. Etc. Pretty much the typical stuff we’ve done for years. The difference is that the functions can now be easily “ordered” or “chained.” And the beauty of the NFV model is that now these functions can be injected into a service chain with relative ease. More importantly, the functions can be arranged according to pre-defined policies and then deployed using automated processes.

This is where the second aspect of a service chain comes into play. The process of reliably deploying the components that make up a service chain. The industry also uses the term (or, service chaining as described above) to describe this process. At CPLANE NETWORKS we use the term “service orchestration” to describe the process of deploying a pre-defined set of virtual or physical network functions. A collection of functions can be grouped into a service, which can be repeatedly and reliably deployed, using specific policies to guide the ultimate outcome. The key is being able to abstract the service definition from the underlying virtual or physical resources. Otherwise you end up with an unmanageable library of device or vendor-specific services.

We also take it a step (or two) further. Given the centralized topology view we maintain, we can also apply “state” to the deployment process. This becomes very important for services that are sensitive to the behavior of the network, such as bandwidth allocation. We also approach service orchestration from an “end-to-end” view. This simply means that through our centralized topology and state model, we have deep understanding of all the components, both virtual and physical, that are utilized as part of a service – including the relationships between individual elements.

So how do we accomplish all this? We started from the ground up with a SDN Service Orchestration Platform as the core of our offering. Orchestrating complex service chains without it would be an impossible. The platform provides the basis for all the functions and services mentioned above. And, it provides the common framework on which all of our network services are built – data center networking, wide area networking, gateway services, multi-site OpenStack management.

Service chains are key to deploying agile and flexible network services. Without them the network will continue to be “segmented”, leading to over-allocation and under-utilization of both virtual and physical resources.

Suggested Blogs