Why a Model-Driven NFV Architecture is Critical (and How Ciena’s Looks)

In the fall of 2013 I had a meeting with five Tier One operators to discuss what was needed to make NFV work.  At the meeting, one of the key figures in the NFV ISG and a representative of a big operator made two comments I think are critical and have stood the test of time.  The first, referencing the fact that capex savings for NFV were now expected to be at most 20%, was “If I want a 20% reduction in capex I’ll just beat Huawei up on price!”  That meant that savings for NFV had to come from opex, and to demonstrate opex, my contact said, “You have to present an NFV architecture in the context of a service lifecycle.”

A service lifecycle, to an operator, has four distinct phases:

  1. Architecting, which is the process of defining a service as a structure made up of feature components that eventually decompose downward into resource commitments.
  2. Ordering, meaning the connection between an orderable service model and a customer, made through a self-service portal or a customer service rep.
  3. Deployment, the conversion of a service model that’s been ordered into a set of resource commitments that fulfill the service description and SLA.
  4. Management, the support of the service in its operational state, responding to conditions that would break the SLA, create inefficiency risks, or to customer-initiated changes or termination.

I took this to heart in my ExperiaSphere project, which divides the tutorial slides into this same four phases, and I’ve used these phases to assess the various vendor “NFV solutions”.  Most of the solutions were incomplete, as you can probably see just from the names of the phases.  Even where there were complete solutions, the specifics available from a vendor in online or distributed documentation was rarely enough to allow me to present the solution in detail.

Ciena’s is one of the six vendors I believe have a complete service-lifecycle story.  Their just-announced Blue Planet DevOps Toolkit also provides the requisite detail in their analyst preso, which I’m referencing here, and so I want to talk about it to illustrate why that first architecting phase is the key to the whole NFV story.

The Architect phase of a service lifecycle is really a series of iterations that are intended to build a decomposable model of a service that can then be offered as a retail product.  It’s always been my view that the model should be hierarchical and should describe a service as a feature composition, each feature of which eventually linked to some resource management/deployment task.  This corresponds to the “declarative” model of DevOps, for those familiar with the software development world.

There are two pieces to the Architect phase, one to model the services and the other to control the resources.  This corresponds to Ciena’s notion of a Service Template and Resource Adapters, with the latter being roughly equivalent to the ETSI NFV ISG’s Virtual Infrastructure Managers.  Ciena uses the OASIS TOSCA (Topology and Orchestration Specification for Cloud Applications) language, which I’ve said for several years now is the most logical way to describe what are effectively cloud-deployed services.  The real intent of the Ciena Blue Planet DevOps Toolkit is to build these Templates and RAs and to then provide a framework in which they can be maintained, almost like the elements of an application, in a lifecycle management process that’s somewhat independent from the lifecycle management of the deployed services.

The Template and RA separation corresponds to what I’ve called “service domain” and “resource domain” activities in the Architect phase of a service.  The service domain is building services from feature elements that have been previously defined.  These can be augmented as features evolve, and revised as needed for market reasons, and it’s this add-and-revise process that’s analogous to software evolution for a running application.  The RAs associate in most cases with management systems or resource controllers that can configure, deploy feature elements, and change resource state.  Service Templates, at some point, reference RAs.

Service providers can use the Toolkit to build all this themselves, conforming to their own requirements and their own network infrastructure.  Vendors or third parties can also build them and submit them for use, and it would be logical IMHO to assume that many vendors would eventually realize that building an RA or Infrastructure Manager is essential if their stuff is to be used to host virtual functions, connect them, etc.

There is nothing as important to NFV’s success as the notion of service and resource models, yet little or nothing is said in the NFV specifications about how these things would be created and used.  The Ciena approach uses TOSCA to describe service characteristics and parameters (the NFV ISG is now looking at a liaison with OASIS/TOSCA to describe how the parameters they’re suggesting would be stored in a model).  These fall into three categories—parameter values used to guide decomposition of model elements, parameters used to describe service conditions upward toward the user, and parameters that are sent directly or indirectly to RAs for deployment and management.

Ciena’s focus on model-building here is critical because it would facilitate just what their preso says, which is vendor independence and facile integration of resources.  The only thing needed to make this story complete is a way of authoring the lifecycle processes too.

Lifecycle processes could be defined in this kind of model, for each model element.  That’s critical in making the models reusable, since each model element is a kind of self-contained and self-described service unit that knows how to deploy and sustain itself.  Since ordering a service is logically the first lifecycle stage, the entire operations process can be defined and composed this way, at every level.

The implicit Ciena approach is that a service template, or model, has built into each element the rules associated with that element’s life, both as an order template and when instantiated, as a piece of a service.  No matter where you put this element, geographically or in a service context, its model will determine how it is sustained, and nothing else is needed.  Give a model to a partner or subsidiary, or to a customer, and if they have the right RAs they can deploy it.  That will be true if you can define lifecycle processes into the service templates, and if you can’t then there’s a hole that will invalidate at least some of the benefits of the Ciena approach.  That means the question of whether the Toolkit supports lifecycle definitions, and how that works, is critical.

Most of you know that I don’t accept verbal inputs from vendors on important points because they’re not public disclosures.  I’d invite Ciena to respond by commenting on LinkedIn to my question here.  Alternatively, I’d like to see a document that describes the approach to lifecycle definition, without an NDA so I can reference it.

The good news is that I have been assured by two TOSCA experts that there would be no problem defining lifecycle processes in state/event form within a TOSCA template.  It’s only a matter of providing the mechanism to build it through something like the Toolkit, then steering events through it.  I’d love to see someone describe this in public, and if your company has it, I’d like to hear from you.

I’ve also realized with this announcement that I need a way of getting information on purported NFV implementations in depth and with confidence that the vendor really has what they say.  That’s the kind of information I want to base my assessments on, and pass on to those who read this blog.  I’m going to be working out an approach, and I’ll publish it as an open document for vendors when I’m done.