Network functions virtualization (NFV) promises greater agility for service providers while lowering costs by consolidating network functions into merchant silicon-based cloud and virtualized data-center infrastructure.  The business case is clear, the underpinning virtualization technologies are established, and the vendor landscape is evolving to meet requirements.

However, as in most things in life, the devil is in the details.  Service providers, like most large organizations that have been around for a while, have a tremendously long tail of legacy infrastructure, including vast deployments of dedicated servers, blades in network devices, and proprietary service delivery appliances and chassis.  In addition to network infrastructure, there are thousands of legacy OSS and BSS applications that are also part of the picture.

So the question must be asked: How is NFV going to work with all this legacy stuff?  This is where orchestration solutions come into play. But just saying "orchestration" doesn’t explain much, because orchestration is one of those terms that is used to mean a variety of different things.  To achieve interworking between legacy and virtualized network functions requires orchestration at multiple layers of the production network side of the business, and also requires a distinct form of orchestration in the devtest side of the business.

For the production side of the network, we can think of orchestration in a few different layers:

1. Network data plane.  At the simplest level, orchestration needs to be able to create ease of coordination of both physical and virtualized network functions.  This means that some functions can be accessed and formed into service chains using logical connectivity notions like VXLAN or GRE tunnels, while some need to be service-chained across actual cables.  One of the important automation technology developments that contributes at this level is the advent of model-based or declarative configuration management or orchestration languages.  Model-based configuration management can abstract multiple vendor interfaces and provide a common automation “language” that OSS and BSS systems can use to configure services from disparate vendor equipment and functions, whether physical or virtual.  The ability to express end-to-end networking connectivity schemes such as MPLS VPNs and inter-cloud data center connectivity in a unified manner is very helpful for orchestrating legacy and virtual network functions.

2. Network control plane.  Unlike modern cloud data centers, where infrastructure is all local, bandwidth is nearly unlimited and all compute, storage and virtualization resources are simply generic items in a highly liquid resource pool (at least in theory), wide-area networks are characterized by constraints.  Bandwidth is constrained in places due to the limits of physical infrastructure — how much fiber is in place, and what generation of optical switching is in place.  Long-distance communication spans create latency due to immutable laws of physics.  These constraints are part of the legacy of the network, but are also part of the future, so they must be dealt with.  WAN orchestration solutions that run algorithmic computations of the best constraint-based path selections and provide an optimized view of how the control plane should function are another important ingredient in bridging legacy and virtual resources for NFV.

3. End-to-end cloud service plane.  A reality today is that there are separate orchestration layers envisioned for the cloud data center and the network.  The premiere cloud data center orchestrator is OpenStack, and this is probably the choice of most service providers today.  Network-layer orchestrators, when supporting end-to-end cloud services, must plug into OpenStack or equivalent orchestration.

4. OSS/BSS.  It’s all very well to abstract network functions and services and to push optimizations to the control plane, but ultimately in a production service-provider network the purpose is to deliver competitive service and make money, so there must be a level of management, policy and charging/billing orchestration at the OSS/BSS level that can deal equally with physical and virtualized network functions.  While it seems obvious, it’s easy for those dealing with network architecture and low-level data plane issues to forget about this.

From the devtest side of the service-provider business, a distinct type of orchestration is needed that can enables these teams to deliver agility of NFV production service delivery.

• Unified self-service for the devtest with appropriate governance.  In a production NFV service operation, self-service is governed by a complex set of OSS and BSS applications.  In the devtest environment, it’s highly desirable to have self-service of a variety of different environments, from development VMs configured with platform tools to full pre-production network test topologies including both physical and virtual functions.  However, it’s unlikely that any service provider will want to use a production-like OSS and BSS system to govern usage. A more appropriate level of governance will be lightweight. Devtest self-service orchestration will provide a governance system over devtest resources based on the notions of resource reservation, auto-provisioning, and reclamation. These lightweight governance notions maintain the collaborative, agile culture needed for the devtest side of the business.
• Rapid technology integration.  Production services and their infrastructure must be extensively qualified and stable before they are released to customer use.  By contrast, agile approaches to devtest in the age of SDN and NFV require the ability to rapidly integrate new technologies — even those that are merely being considered for production usage.  This means that devtest orchestration should have DIY integration tools, rather than being dependent on external vendors.
• Ease of use for network and IT engineers.  It is surprising how commonly internal user communities are forgotten in the process of modernization.  Like the proverbial cobbler’s children going shoeless, network and IT engineers are often forgotten when systems are built to support production services.  In the world of SDN and NFV, when agility of service creation, instantiation, and launch to the market is paramount, it’s critical that the devtest community not be left with inappropriate tools to achieve these results.  Since most network and IT engineers aren’t software developers, they need GUI-driven tools that construct productivity-enhancing processes such as continuous integration for NFV services.
• Tight integration with test automation and continuous integration workflows:  Ultimately, true agility in delivering certified NFV service chains in production is going to depend on the ability to achieve high degrees of automation around testing and a progression toward continuous integration against the full network stack including apps, NFV topologies, and the ever-changing, underlying physical infrastructure.

NFV is casting a vision of a more agile and cost-competitive service provider.  By paying attention to the different types of orchestration at different layers of the network and on different sides of the business, service providers can ensure that they will achieve that vision.