A Very Early Look at What NFV Needs

A lot has been said, and written, about NFV since ten network operators published their “Call for Action” white paper in the fall of 2012.  I’ve contributed my share in blogs and website material relating to how NFV could and should be implemented.  What I’m finding now, admittedly with some frustration, is that many of the points raised early on seem to have been pushed to the background.  Now, late in the process and with little time to fix things, we’re suddenly raising them again.

Back in April of 2013 I gathered a group of vendors at the ISG meeting in California and launched what became CloudNFV.  I became the Chief Architect of the group.  The initiative went public with an approach that summer (you can find the information on the website reference just provided), and in the fall of 2013 we demonstrated the architecture to operators at two separate events.  CloudNFV was also presented as a PoC, and had the honor of being the very first one approved.  In January 2014, the first phase of the PoC was completed and demonstrated to the operator sponsors (Sprint and Telefonica).

The original CloudNFV PoC defined eight goals (quoting from the original PoC applicaton):

  • PoC Project Goal Number One: Demonstrate a framework for the application of NFV principles to actual service provider service creation, deployment and management practices.  We propose to demonstrate four CloudNFV service processes—NodeBuilder, ServiceBuilder, ServiceBroker, and ServiceManager—and to align these both with NFV use cases and architecture and with OSS/BSS/NMS systems and service/operations practices.  The goal is to provide a way of visualizing the potential impact of NFV on service velocity and agility, management efficiency and opex, and reliability/availability.
  • PoC Project Goal Number Two: Identify the optimum way of describing the structure of a service in an NFV environment, including the definition of the NFVs, NFV connectivity with other NFVs, NFV connectivity with the overall end-to-end service, and NFV connectivity with “Infrastructure Services” that may have been pre-deployed and are shared by multiple services.  We have implemented a model that composes low-level structures (“Nodes”) that can represent not only VNFs or VNF packages, but also devices and services.  We believe that many of the suggestions on describing VNF deployment and connection would not describe enough about either to permit them to be used with existing software elements that could provide network functionality—particularly open-source.  That would mean that this software base could not be easily used to support NFV goals.  VNF connectivity must define the network environment that the VNFs were written to run in; anything else is either superfluous or insufficient.
  • PoC Project Goal Number Three: Demonstrate the optimum way of deploying a service, suitable to apply to VNF deployment in the cloud, on virtualized servers, on bare metal servers, and in network devices or CPE, including chips such as the EZChip or other network processors.  We believe that a service will cross over between cloud-deployed VNFs, dedicated-server VNFs, VNFs that run on special blades in devices, etc.  It is critical that all of these hosting options be supported or some of the valuable capabilities of specialized hosting may be lost, and cost savings reduced.
  • PoC Project Goal Number Four: Establish the optimum way of defining management practices as “co-functions” of the service, composed in the same way and at the same time, and representing the service and its elements in the optimum way based on one or more existing sets of operations practices, or in a new way optimized for the virtual world.  The functionality created by combining VNFs defines not only how a service works but how it should/must be managed, and the only way to harmonize management with functionality and at the same time create a link between virtualized elements and real services is to link them at the time of deployment by composing both side-by-side.
  • PoC Project Goal Number Five: Develop the requirements for an NFV-compliant data center, including the hardware issues that would impact performance and stability, the platform software issues, and the mechanism for virtualization.  We have created a harmonized, optimized, model for an NFV data center but have also learned the lessons of how that can be extended.  We have already added a new vendor to our Active Data Center structure (Mellanox) and we are looking to integrate others.  Our practices here can be a guide for NFV deployment in general.
  • PoC Project Goal Number Six: Define the requirements for authoring VNFs and making them portable across multiple implementations.  We have defined an architecture that does not require VNFs be authored to a specialized set of APIs, but we can support an arbitrary “Platform-as-a-Service” developer framework providing that the NFV user has licenses for the APIs involved and that they can be exposed as network interfaces (a URL, for example).  Our goal from the first was to be able to create a VNF by “wrapping” any software component that exposed an interface, any hardware device, or any deployed service, in a CloudNFV description that would allow it to be deployed and managed using our model.  That means that all these things, including existing devices and services, look like NFV to us, which is critical in transitioning to VNF-based service features.
  • PoC Project Goal Number Seven: Determine the attributes for VNFs and VNF packages that would make them suitable/optimum in achieving the requirements defined by the ISG.  For example, we have determined in our use of Metaswitch Clearwater IMS how VNF connectivity must be described and managed and what is needed to make a VNF horizontally scalable.  We evaluated existing open-source software to meet the ISG use-case goals, and found Clearwater IMS from Metaswitch.  The package was not intended to be a VNF, and we were able to deploy it without any changes to the software, largely because it has attributes that make it easy to convert into a VNF.  We can describe those attributes and thus help guide selection of candidate software, and provide specification goals for real software.
  • PoC Project Goal Number Eight: Evaluate the adequacy of explicit and implicit steps to assure openness from the NFV ISG work, and recommend additions/modifications.  We seek to establish whether the current model for NFV and the current functional separation is adequate to insure openness and optimum in addressing the functional requirements set by the two white papers.  We believe that our “totally open” approach allows the ISG to consider whether additional interfaces or functional separation would help advance the ISG’s goals by encouraging component substitution, helping to break down proprietary barriers already being built.

I believed at the time, and still believe, that these PoC goals covered all of the critical issues of NFV, from proving the technical concepts to proving the benefits that could make a business case.  Unfortunately, commercial pressure has done a lot to NFV, and it did a lot to CloudNFV as well.  The objectives of the vendors, understandably, became increasingly commercial as time passed.  That made my position a volunteer, unpaid, architect untenable, and I withdrew in late January 2014, just after Phase One of the PoC completed.  I had prepared a report on findings before my withdrawal as Chief Architect, and after that step I didn’t attempt to socialize the report through the rest of the group for formal publication.  In any event, the goals and structure of the PoC were amended after my departure, and many of the original points dropped, making my comments on them moot.  Operators who knew of the work did ask me for a copy offline, and I provided the report to them as a personal document not a group contribution.

I’m publishing that document now (the link is HERE), because I think it and the original CloudNFV goals show that most of the issues that seem to be perplexing vendors and operators today were recognized in the very first PoC ever approved.  I believe that had the PoC proceeded as it was originally approved, we’d have much better insights on these matters than we have now, and be closer to a full deployment of NFV.  As the PoC goals and this Phase One report show, my own views on what’s needed for NFV to succeed haven’t changed.  I don’t think the needs themselves have changed either, and it’s not too late to take these matters up and resolve them.  Hopefully this publication will help that along.

Posted in Uncategorized | Comments Off on A Very Early Look at What NFV Needs

What Now for ExperiaSphere?

Some of you have asked me what I plan to do next with ExperiaSphere, given that I’ve just published the last of the five tutorials I promised.  The answer is “nothing specific” or maybe “it’s up to you!”

I believe that NFV specifically, and the whole notion of an NGN model in a more general sense, needs a holistic end-to-end, top-to-bottom architecture that virtualizes everything, because I don’t think you can efficiently adopt virtualization in little islands.  We virtualize services, resources, and processes, or we anchor agile things in legacy inertia.

When ExperiaSphere launched as a project back in 2007, the goal was to prove that you could represent service and resource abstractions with software objects.  That was proved, and that concept was the basis for my CloudNFV project in 2013, and for the new ExperiaSphere work directed at an open NFV model that has just been completed.  I think all of this adds up to a pretty well documented proof that this can be done right.

Some of you have expected me to form a company or launch another CloudNFV-like consortium to implement the model I’ve described.  I’m not prepared to do either.  I’m a strategy consultant, and that’s what I want to be.  The job of running a startup is more work than I want at this stage in my life.  I can’t dedicate more uncompensated time to running a group of companies in a cooperative project like CloudNFV was.  So I’ve done as much as I can do with this, and the industry at large now has to decide if the work was useful or not.

I won’t regret my efforts here even if nothing comes of it.  Strategy consulting involves giving a lot of advice you know your client isn’t going to take, but it’s still the truth and still what they should do.  I’ve done my part, and now others are welcome to use as much of this concept as they find useful, and build what serves your own goals.  If further industry activity suggests something more can be done here, within my constraints of donating time, then I’ll take up that something when it arises.

Posted in Uncategorized | Comments Off on What Now for ExperiaSphere?

The Final ExperiaSphere Tutorial is Available!

I’m happy to say that I’ve completed and posted the final ExperiaSphere Tutorial.  You can find this on the ExperiaSphere website or download from below.
Tutorial Five:  ExperiaSphere Service Lifecycle Phase 4: Deployment

  • Slides for the Management phase are available HERE.
  • Annotated slides for the Management p;hase are available HERE; we recommend you use for the notes per slide.
Posted in Uncategorized | Comments Off on The Final ExperiaSphere Tutorial is Available!

Deployment Phase Tutorial Now Available!

I’m happy to announce that the tutorial for the Deployment lifecycle phase of ExperiaSphere is now complete and posted on the ExperiaSphere website.  Click HERE for the page.

There is one more tutorial remaining, on the general Service Management lifecycle phase.  We’ll get to that as work permits!

Posted in Uncategorized | Comments Off on Deployment Phase Tutorial Now Available!

Service Order Phase Tutorial Now Available!

I’ve completed the service order phase tutorial for ExperiaSphere, and posted the tutorials on the ExperiaSphere website.  We have two tutorial formats, one in PDF ONLY for those who want only the slides, and one in ANNOTATED PDF form with my slide notes attached.  As always, this material can be exchanged freely as long as our copyright notices and trademarks are intact.

Please use our Google+ Group to post questions and comments!

Posted in Uncategorized | Comments Off on Service Order Phase Tutorial Now Available!

Service Architect Lifecycle Phase Tutorial is Now Available!

I’m happy to say that I’ve completed the slides and annotated slides for the Service Architect tutorial for ExperiaSphere.  They are now available on the ExperiaSphere website as follows:

  • The slide deck without annotations and in PDF form is available HERE.
  • The annotated slide deck in the same form is available HERE.  We recommend that you use this deck for learning since the notes are highly valuable.

These documents can be shared freely as long as they remain in PDF form with our copyright and trademark notices intact.  You may not use the term “ExperiaSphere” except to describe the documents unless you contact us for permission.

There is no obligation for you to reference us or the ExperiaSphere project or design in your own work, even if it is derived from ExperiaSphere.  We’d hope that you would voluntarily do that, and provide a link to the website, if you do incorporate ExperiaSphere principles into your design or product.

Posted in Uncategorized | Comments Off on Service Architect Lifecycle Phase Tutorial is Now Available!

The Second Tutorial is Coming in August

I’m happy to say that the second of the ExperiaSphere tutorials will be available in August 2014, likely toward the middle of the month.  For those who found the first one heavy going, this one is going to be even worse, but the good news is that successors will get much easier.

The second tutorial is the first of the four “service lifecycle” tutorials aimed at explaining what ExperiaSphere will do and how it will work by following the path of a service from conception to deployment and management.  The tutorial is aimed at the first lifecycle phase, that of the Architect.

ExperiaSphere builds services by harnessing resources.  The inherent behaviors available from cooperative systems of resources like networks or data centers are framed into useful groupings called service models, and these then form the lowest-level building blocks of the services themselves.  The critical step in this evolution from resource to service model is the creation of Logical Resources that are virtual functional chunks that can be instantiated as needed.  ExperiaSphere builds down from them to the actual networks and data centers and up from them to services.  Architects control all this by building object containers for resources, both logical and physical, and these are then used as proxies for the resources in assembling stuff and committing infrastructure to customers.

I know this tutorial is going to be a challenge; it’s over 50 slides.  But it’s the heart of ExperiaSphere, the thing that makes everything else work, and so getting it right will set up for the simpler tutorials on ordering, deployment, and management.

Posted in Uncategorized | Comments Off on The Second Tutorial is Coming in August

ExperiaSphere Tutorial One Slides Available!

I’m pleased to say that the slides (both plain and annotated) for the first of the ExperiaSpere tutorials are now available and the ExperiaSphere website has been updated to track the new open-source-driven management and orchestration model.  Carol Wilson of Light Reading published a nice piece on ExperiaSphere HERE, and I’m happy to finally have the architecture overview complete and published for review.

The slide decks in PDF form can be found at:

http://www.experiasphere.com/ExperiaSphereTutorial1Slides.zip (slides only)

http://www.experiasphere.com/ExperiaSphereTutorial1Annotated.zip (slides and notes)

This tutorial is not a light-hearted romp, and the slide decks aren’t small (37 slides).  I wanted to be sure to convey enough detail to permit a technical planner or architect to evaluate what I suggest and take a stab at laying out a project based on the architecture.  I can be a bit more explanatory in the video that will come next, at the expense of making it an hour and a half long, perhaps!

With this release, I’m moving all of the ExperiaSphere activity to the ExperiaSphere website and blog, and to the Google+ ExperiaSphere Community.  I’ll not be updating the LinkedIn Group further, so be sure you’re registered for the new Community.  I’ve also created an ExperiaSphere Insiders Community on Google+, for those who contact me and commit to actual implementation work.  Not to keep harping on this point, but I can’t support Q&A and clarifications on the approach in any form except posts in the ExperiaSphere Community, so please don’t send me emails with questions or ask for phone calls.  I will try to cooperate with the media, of course.

I’m asking everyone in the ExperiaSphere Community to obey common-sense rules about questions and postings.  Don’t post irrelevant information or something that’s self-serving without advancing the topic.  I don’t want to pull someone from the group or limit admissions, but we all need this forum to be open and useful at the same time, and if we have to sacrifice the former to get the later, so be it.

I’m starting on the four ExperiaSphere lifecycle presentations, and also preparing the audio for the YouTube version of the first tutorial.  I can’t promise exactly when any of this will come out but my goal is to have at least the slide decks (annotated and plain) for all the tutorials available by the end of August.  I look forward to working with those who are really interested through the Community.

Posted in Uncategorized | Comments Off on ExperiaSphere Tutorial One Slides Available!

Tuesday June 24 is the Release of the First Tutorial Slides

On Tuesday June 24th I’ll be releasing the first public tutorial on my ExperiaSphere universal open-source management and orchestration model. From the first, this activity has been aimed at defining a way to deploy and manage services made up of any combination of legacy technology, SDN, virtual network functions from NFV, and cloud application components. It’s also been a goal to integrate with any OSS, BSS, EMS, or NMS component, to support virtual functions and cloud components without modification or the use of specialized APIs, and above all to utilize open-source technology wherever possible.
Those who have followed my interest in the management and orchestration space know that there were two previous projects with goals that were substantially similar. The first, the original Java open-source ExperiaSphere project, was aimed at validating a model of service management where Java objects representing service features could be composed into applications that would then, through those objects, create services. This “Service Factory” approach was the source of much of my insight into service management, and it derived from work of the IPsphere Forum and the TMF’s NGOSS Contract and SDF activities.

Last year I launched a project to demonstrate that Network Functions Virtualization could be implemented in an open, multi-vendor, manner using these principles. CloudNFV was an implementation project involving a half-dozen vendors, and I served as its Chief Architect from the foundation through the end of January 2014. The project garnered a lot of press and won a TMF Catalyst award in Nice in June 2014, so it’s fair to ask how ExperiaSphere and CloudNFV are related.

To understand the technical differences between CloudNFV and ExperiaSphere we have to start with a technical commonality. Both were based on my “Structured Intelligence” and “Derived Operations” principles that were aimed at making service event handling and management totally virtual. The primary difference between the approaches at the ExperiaSphere technical level arise from the goal of supporting open-source elements, which was not a goal in CloudNFV. Because of the unique capabilities of EnterpriseWeb’s software, CloudNFV combined the service, resource, management, and process models into a single structure called “Active Virtualization”. Active Virtualization glued the work of a lot of other dedicated companies and people into “CloudNFV” and it’s been successfully demonstrated many times.

Operators told me loud and clear that they really wanted an open-source option. Since I could not identify an open-source equivalent to Active Virtualization, ExperiaSphere creates a virtualized service domain to which service lifecycle processes are linked, but it records management data, service variables, and lifecycle event-to-process and resource-to-service bindings in a Management Repository that is linked to but separate from the service modeling domain. Modeling and management are functionally unified but still explicitly separate, because that fits with how open-source tools have evolved. The rest of the goals of the two projects are congruent.

The way that virtual functions are deployed and managed is, from the perspective of the virtual functions themselves, the same for both approaches. VNFs in ExperiaSphere are resources just like devices or architected NMS services like VPNs. Their management interfaces are linked to proxies that populate the Repository with their data as the IETF’s i2aex recommendation describes. That Repository is then the source of information for query-based management proxies that can present aggregated and complex management views through whatever interface is convenient. Any virtual network function that could be deployed by ExperiaSphere could, with proper proxies, be deployed by CloudNFV and vice versa.

SDN and higher-level legacy network features (like “VPN” again) are represented in both architectures by “Service Models” that are presented to the service layer for functional orchestration and that are realized on resources through an Infrastructure Manager (in CloudNFV this was called a “Service Model Handler”). An IM can represent a Service Model “imported” from another provider, so the architecture is self-federating and that is also true for CloudNFV. Because the ExperiaSphere work has to support open source development and integration, the process of building service models and integrating Infrastructure Managers is defined in greater detail for ExperiaSphere, but CloudNFV could be made to work the same way.

There’s a non-technical difference between ExperiaSphere and CloudNFV, though. ExperiaSphere is an architecture or a model of open-source management and orchestration. CloudNFV is a project that sought to prove out these principles in an NFV context. It is an implementation, and ExperiaSphere is not, nor is it my intention to make it into one. The architecture I defined was contributed openly into the public domain for CloudNFV and so it is for ExperiaSphere. It will be up to those who believe that the ExperiaSphere model is useful to drive one or more projects from that model.

In just a few days the slide deck presentation on the overall ExperiaSphere approach will be available on the ExperiaSphere website. I hope everyone with interest in management and orchestration reviews it, and since the approach is open to all you can take whatever parts you like without attribution to me or to ExperiaSphere. I’ll try to answer questions on the approach through my Google+ ExperiaSphere Community (please don’t ask questions like “Can you explain the implementation in detail, taking three months or more?”) but I can’t take individual emails or calls on this unless you want to pay consulting fees.

There will be a video tutorial based on this same material, as soon as I can get it done. There will also be at least four and probably five more tutorials coming out between now and the end of August, based on the service lifecycle steps as a framework for a deeper dive, then looking into broad implementation and integration (time permitting). I designed ExperiaSphere to be open-source-ready, but you could do just parts of it in open source or do it all with completely proprietary tools. You could use a different service modeling and description approach than I’ve proposed and still be open-source, too. You may know of open-source elements I didn’t know about. All of this, I hope, will come out in Community discussions.

I’m going to moderate the community. I’ll accept useful posts but not spam or blatant and non-useful promotions. I’ll give offenders a chance, they remove them. We can make the Community work if everyone is reasonable. If I can’t make it work, then the only avenue I have to answer questions on this will disappear. We’re all in this together.


Posted in Uncategorized | Comments Off on Tuesday June 24 is the Release of the First Tutorial Slides

First Tutorial is In Production!

I’ve made a lot of progress with my ExperiaSphere open-source model for cloud, SDN, and NFV management and orchestration.  I’m finalizing the introductory material, which I’ll first share with a key source of insights within the next 10 days.  When I’ve accommodated any changes/suggestions from this final review, I’ll prepare the introductory video tutorial, which I’ll post on my YouTube channel when it’s available.

I had originally intended to use LinkedIn Groups as a means of coordinating questions on the model when the tutorials are published, but I’ve been having ongoing problems with sharing posts on LinkedIn, and so I’m moving my activity to Google+, where I have established an ExperiaSphere Community.  This is where I’ll be making announcements on the availability of videos and answering questions on the model, so if you are interested please join the community.  I’ll not be keeping the LinkedIn Groups active beyond the end of June, though I’ll sustain the groups to protect the name (which is Trademarked by CIMI Corp).

What’s being planned in the way of video tutorials?  Well, my current plan is to do a primary introductory video that will explain the model at a high level.  This will be followed by a series of videos that will cover the details in the form of a walk through an ExperiaSphere-modeled Service Lifecycle Management process.  The steps to be covered in these tutorials are:

  • Component and Resource Architecting: Defining Basic Service Components and Onboarding Functions and Resources
  • Service Architecture: Building Services from Components
  • Service Brokerage: Ordering and Instantiating Services
  • Service Management: Responding to Changes and Events

I’ll also be providing a tutorial on Creating the Glue for the ExperiaSphere Model, which will cover how to develop the connecting logic needed to link the open-source tools and create the models needed to orchestrate and manage services.

These tutorial videos will range from 45 minutes to 90 minutes depending on the topic, and I’ll also be providing PDFs of the annotated slide decks, both on the ExperiaSphere website and on SlideShare.

Please note that the ExperiaSphere model is open and released to the public without restriction, so anyone can implement the model.  The material will be freely distributable in its original form with copyrights intact.  If you want to use the term “ExperiaSphere” to refer to the activity, you must assert the trademark:  ExperiaSphere™ and say that the term is a Trademark of CIMI Corporation.  If you want to assert that you have an ExperiaSphere-compliant implementation, we’ll review your material and provide you permission and logo artwork to use.  This is only required to use the term; you can use the design concept freely without attribution.

I know this has taken some time to mature, but I want to promise that the concept when it’s available will be just what I’ve said it would be, and presented at a greater level of detail than is available for any other management/orchestration approach.  Be patient just a little longer, and thanks for your interest!


Tom Nolle

Posted in Uncategorized | Comments Off on First Tutorial is In Production!