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.