What is service chaining and where does VNF onboarding fit in?
Service chaining and VNF onboarding aren't easy. Companies interested in these processes need to understand the challenges involved, as well as various requirements for onboarding.
It would be fair to say that service chaining has been the main focus of network functions virtualization, but there's still a lot of confusion about what service chaining is and how it relates to onboarding -- or preparing -- virtual network functions for operation in a service chain.
Enterprises need to understand what's involved -- whether they intend to deploy their own virtual network functions or simply adopt carrier-based VNFs -- or risk lock-in and performance problems later.
Service chaining is a concept that addresses the fact that, in many of the targeted services for network functions virtualization (NFV), end-to-end data streams pass through a sequence of functions. An example sequence is passing through the firewall, encryption and software-defined WAN.
In most cases, enterprises can find these feature sequences at each point where users access a network service -- and, today, they're usually provided by customer premises equipment (CPE). Typically, a service chain is a sequence of VNFs intended to replace a chain of premises equipment.
VNF onboarding challenges
Service-chained VNFs highlight the issues of onboarding the physical functions' feature software so it can perform in an NFV environment. In many cases, users want the ability to obtain their VNF features from the vendors with which they're familiar, which means vendors have to transform the software developed to run inside premises boxes into something that can be hosted on generalized hardware.
Typically, a service chain is a sequence of VNFs intended to replace a chain of premises equipment.
This hardware could be a universal CPE (uCPE) box still located on-premises or it could be part of a cloud resource pool. It's this combination of issues that creates service chain onboarding challenges.
Physical devices are plugged into each other -- and the service chain has to replicate that process. This means each of the software VNFs has to expose a pair of interfaces that can be connected to the rest of the chain, with the user forming one chain termination and the network service demarcation forming the other.
The VNFs selected for onboarding into a service chain have to support compatible connectivity. Furthermore, the interfaces they use must be suitable for network connection when the service chain is deployed.
Chaining the VNFs together
Software is usually deployed on a LAN in an IP subnetwork. This provides open connectivity among the software components, but it's not equivalent to plugging boxes into each other because the normal software components would identify each other by a URL. This means a network team would have to parameterize service chain components to know their adjacent chain members' URL.
Using a tunneling protocol between VNFs in the chain lets the network determine the order of connection and doesn't require changes to the VNFs. The same is true if the VNFs are connected using explicit software-defined network control. Both of these approaches may break down if the VNFs are hosted in uCPE, as all connections are then inside a device. So, uCPE deployment will require special connection attention when onboarding.
What this all means is enterprises must have network expectations and hosting expectations for the service chain to onboard the VNFs and then deploy the chain in a service.
Service chaining links together multiple virtual functions that previously ran on physical equipment.
Three VNF onboarding requirements
Networking within a service chain is only one of the onboarding issues enterprises must consider. NFV broadly requires three compatibilities in the VNFs themselves. First, VNF parameterization must be recorded in a VNF Descriptor for each VNF.
Second, a VNF Manager (VNFM) must be assigned to the task of managing the virtual function itself. This can be done using a generic VNFM if one is available, a VNF-specific VNFM or a hybrid of the two. Whichever mechanism enterprises choose, it is critical that they define the VNFM explicitly for connection during deployment.
These steps are again complicated by the fact that enterprises can deploy service chains within uCPE devices or in the cloud. Where device hosting is involved, it is possible -- and even likely -- that the formal NFV specifications won't apply. In this case, enterprises can use a device-specific mechanism for hosting orchestration and management functions.
The onboarding approach has to match the target. If enterprises can deploy a given service chain in multiple places, they will need a separate service model and onboarding process for each option. That's also true if enterprises are employing cloud-native management and orchestration -- Kubernetes, for example -- rather than the procedures sanctioned by the European Telecommunications Standards Institute NFV Industry Specification Group (ETSI NFV ISG).
Does service chaining make sense?
Even if all of this is properly planned, service chaining for VNFs raises a fundamental question that users rarely consider. Is a service chain of multiple VNFs even a sound concept? Remember that when enterprises separately host and chain two or three VNFs, the result is always harder to manage, less reliable and more resource-intensive than if teams simply bind the same VNFs to a single VNF and deployed it as a unit.
Separately cloud-hosted and chained VNFs have more components to break than the same set of features built as a single VNF. Even if the separate VNFs are hosted within a uCPE device, it increases the management complexity because enterprises must manage all the VNFs separately.
Operators should ask just how often customers are likely to change the makeup of their chained services. Unless considerable dynamism is expected, they should consider packaging the most commonly used combinations of VNFs as separate super VNFs that can be deployed as a unit.
The final point to remember is that not all VNFs are designed to fit the ETSI NFV ISG recommendations. This is particularly true of VNFs, which are designed to be deployed within uCPE devices. Before you dig too deeply into service chaining and VNF onboarding, check with the VNF sources to determine what management and orchestration specifications they're designed to expect. VNF practices have to fit VNF realities.
