With all the hype around NFV, it would be great to say that we have made massive progress to realize the open, transformative technology it will be -- but we have only just crossed the starting line. Thankfully, the conversations have moved from the esoteric discussions of architectural boxes, lines, and interfaces – the value and demarcation of which are still being hotly debated in an architectural diagram – to a sharp focus on the interoperability and testing of specific modules in that architecture. Many of us in the industry are years into the deployment, when the proof of the pudding is in the eating!

NFV’s (and in general) virtualization of current specific processing appliances will impact our industry – one of sweeping change. As an architecture, orchestrated NFV is not just about the ETSI NFVI. NFV is a “means to an end,” and that “end” is service creation. In that light, NFV without service function chaining (SFC) is incomplete.

Service creation requires a new, layered model of networking that incorporates policy and service abstraction that creates a “whole stack” with the underlying network topology and resources. Any ideas that don’t include the service overlay, underlay, containers, storage, etc., are woefully incomplete. In deployment reality, a new cadence of operation, a new type of developer/operator for that environment (a “full stack developer”) and new tools to enable them becomes abundantly clear.

The “whole stack” concept is derived from some fundamental Unix principles (via Doug McIlroy):

• “Write programs that do one thing and do it well”
• “Write programs that work well together”

Given the potential scope of NFV and SFC, this modularity is well advised. Now that OPNFV is launched, it is important not to see the requirements of NFVI as entirely satisfied by or the sole responsibility of a single component like OpenStack or just OVS or solely OpenDaylight.

Further, the coming cycle of NFVI optimizations through hardware and software innovations and the transparency of those innovations through open NFVI tooling should be “givens,” if there is to be a robust open NFV (platform vendors are motivated to do both) and developer community. While it’s a welcome start to get something tangible working in an open framework like OPNFV, we also need to look to the value of NFV that can be derived above the infrastructure.

We could approach the NFV architecture, transport and tooling by emulating the past interconnection technologies, extending traditional transport encapsulations and overloading orchestration (with these parameters). This path just repeats history. By extending the stack with group-based policy (GBP) and service function chaining (SFC), we can create a more suitable level of abstraction while maintaining the speed required coupled with architectural modularity, openness, and flexibility. Instead of managing “elements” in a network, we can program the service and corresponding full stack – top to bottom.

Everyone recognizes that NFV involves virtualizing the network topology, but very few have stopped to ask “how” and “to what degree.”  To presume that we should simply take the traditional nodes (switches/routers) and edges (links, vLANs, tunnels) of legacy networking and virtualize them (out of familiarity) would be a gross mistake. In fact, if that was the only way to build NFV, the movement would be extremely boring – a flash in the pan. It wouldn’t be less expensive (probably more expensive, given recent analyses) and would only prove to be faster to deploy. This is a necessary, but insufficient outcome.

To create services, we are going to need more than the historical view. Policy and service chaining are two useful abstractions of the traditional topology view to consider

Figure 1. A policy view can be used to render a service chain, which in turn is realized at a higher level of abstraction (Topology Overlay) on a physical implementation (Topology Underlay) consuming a set of managed and monitored resources.

In Figure 1, policy is a top-level abstraction in which “nodes” are groups of endpoints and edges are the directional policy that applies between such groups. Policy adds and specifies the semantic what we want for network flows between those groups.

Below policy, in the service/SFC view, we add the semantic how for service graph traversal. Here, nodes are network functions (physical or virtual) and edges indicate the direction, order, and sequence of the flow of traffic through those chains.

Beneath these abstractions are the familiar virtual topology (if we deploy an overlay) and the physical topology and resource pools (i.e., compute, storage, and memory).

There are scoped linkages between these views. For example, the “policy” layer must be able to specify the handoff to the service/SFC layer. However, the service/SFC layer inner workings should be beyond the scope of the policy layer’s awareness.  The legacy network – whether network overlays, vLANs or other connectivity paradigms are deployed – is similarly beyond the scope of both the service/SFC or policy layers.

To recap, NFV is intrinsically about the dynamic provisioning of end-to-end service through the network. All of the low-level details of providing that service, from the addresses of the customer devices to the locations of the VNFs, are dynamically subject to change.

It is a massive industrial error to consider the historical practice of trying to specify those low-level mechanical details directly. This was the exact error SDN generation 1.0 followed, and thankfully we’ve all learned and invented 2.0, 3.0, and so on. For example, through concepts of GBP, we can establish a policy about the kind of treatment traffic from one endpoint group (EPG) to another must receive, and be able to dynamically specify which endpoints (EPs) are in a EPG and how they relate to the VNFs that will serve them.

Figure 2 A policy establishes the treatment of traffic from one endpoint group to another must receive via the contract concept.

Simply put, the VNFs of a service chain are unlikely to be found in the natural path of the traffic, so traffic will have to follow a (bounded) graph independent of the underlying network topology. From policy, we can render and instantiate the mechanics of the graph. The logical service topology eliminates the need to constantly churn the network underlay/overlay topologies to constitute a network-level natural path for a service.

With respect to standardization, the IETF SFC Working Group provides this graph traversal mechanism through its reference service chaining architecture and an “SFC encapsulation” known as Network Service Header (NSH). As announced and demonstrated recently at Mobile World Congress, NSH already enjoys widespread support from a large array of operators and vendors. NSH-capable software forwarder support is available from both private and open source.

Aside from enabling a network topology independent service graph (via the embedded service path and sequence), NSH provides the ability to pass metadata between functions. This emulates the intrinsic advantages of the current generation of fully integrated network service appliances, while allowing greater modularity of service components and a tool to imagine and create new, distributed services. “Cloudifying” and modularizing the centralized appliance or service chain into independently scalable pieces is the desired trajectory of the NFV movement