Posted on December 16, 2013 by CIMI
I’m happy to report that the CloudNFV project’s Proof-of-Concept application to the ETSI NFV ISG has been approved. We were the first group to make formal application, the first to be approved (as of today, we’re the only ones in either category, but I expect much more through the first quarter). It’s a validation of CloudNFV, of course, and the work of our term. It’s also a validation of the ETSI NFV work that launched our CloudNFV initiative back in the late fall of 2012. Finally, it’s a validation of the work done by some service-modeling pioneers at the TMF, whose GB942 principles are the foundation not only of CloudNFV but of what I think is the only solution to managing virtualization—anywhere.
The ISG was born out of openness, the desire to open up services by replacing proprietary elements with hosted software, the desire to create the future by selecting among the best standards of the present, and most of all the desire to let the buyers of infrastructure define the playing field so the sellers (individually or collectively) could never dominate it again. The ISG defined the issues, the use cases, the functional framework, for the future of networking.
CloudNFV from the first sought to build on the ISG work, to validate it within the broadest possible framework of service creation and operations, and to incorporate the other critical revolutions of our time—the cloud and SDN. All this while not only sustaining but extending the open principles of the ISG. We are not, nor have we ever intended to be, a “replacement” or “alternative” to the ISG’s approach. We’re an implementation, an extension of their principles into adjacent domains where the ISG can’t realistically go because the scope is too large to hope to progress it in time. Our extensions are based on the work of both the TMF (GB942 and GB922) and the IETF (i2aex).
We are a software architecture that has now become a software implementation. We are running now; we have demonstrated that too many of the founding operators in the ISG. Our goal is to develop a software framework that best meets the goals of operators, goals that include but are not limited to those of the ISG. We are an open software architecture too; we’ve demonstrated that by launching a website, an integration program, a wealth of tutorial material. We’ve also demonstrated it by the fact that our PoC includes not only the original 6 companies (my own CIMI Corp, 6WIND, Dell, EnterpriseWeb, Overture, and Qosmos) but two integration partners (Metaswitch and Mellanox) who have joined us through our open approach, and a TMF/OSS integration partner in Huawei, who has supported our operations evolution even without contributing technology to our platform.
The hard work of dozens of people in the ISG and the TMF are also foundations for what we’ve done even if their names aren’t on the PoC submission. Two operators, Telefonica and Sprint, have agreed to sponsor our PoC, and the representatives of these operators are also key figures in the critical SWA and MANO groups within the ISG. We don’t promise that we have or will conform completely to what any of these bodies develop, but we promise to present our approach, justify any differences, and work with all the bodies involved in good faith to come to the answer that’s best for the industry.
Our PoC is now posted on our website (see the link above) in keeping with our open approach. It defines 16 scenarios to support its eight broad goals, so it’s no trivial NFV-washing. These together define a framework in which we’ll prove out the initiatives of the NFV in an implementation that fully integrates with service creation, deployment, and management. We’ll be starting PoC execution in mid-January, reporting on our results beginning in February, and contributing four major documents to the ISG’s process through the first half of 2014. We’re already planning additional PoCs, some focusing on specific areas and developed by our members and some advancing the boundaries of NFV into the public and private cloud and into the world of pan-provider services and global telecommunications.
These advances will require insight and effort on the part of every one of the companies who have contributed to take us to this point. It will also require further involvement from other companies, involvement we will secure through our commitment to an open approach. We’ve defined an open and adaptable service orchestration process that works not only with NFV elements but also legacy devices and services. We can manage what we deploy, no matter whether it’s built from software or from switches and routers. We can even mix cloud applications like CRM or Unified Communications with network features to build services that are both of the cloud and of the network. We want help with advancing and proving out all of these things, and our call for participation is still open. It’s working too; we have two integration partners involved in this PoC and six others in some stage of development. Even more would be great.
In the first quarter we’ll release open specifications for Service Model Handlers that can link anymanagement system that can deploy software or connect network elements with our high-level deployment orchestration and management model. This will create an open, agile, network and cloud connection and bind SDN and NFV with open interfaces. It also supports the hardware of any vendor. We have also proposed a TMF Catalyst to extend our integration potential upward into operations processes in a fully open way. We hope that interested parties in both these spaces will engage with us to test our theories in future public processes like this PoC and the TMF Catalysts.
The foundation of NFV is the virtual function logic available for deployment, and there’s a real risk that this space will be as proprietary as network appliances. We think it should be fully open to developers of all types. To help that along, we’ll release a specification for an open Virtual Function hosting framework, something that can bring every piece of network code that can run in the cloud today and any application developed for a cloud platform, into the NFV world. That includes specifically open-source software. There’s no proprietary lock-in for network functionality in our architecture, which is how we think it should be.
Our commitment to open virtual functions is demonstrated by the fact that our PoC and Catalyst processes are based in part on Metaswitch’s Project Clearwater IMS project, a project that’s open-source. We have onboarded it to NFV with no modifications required for Project Clearwater software, but we can also demonstrate how to build APIs that virtual network functions can exercise to improve operations and management, using familiar web-service interfaces that work for every software platform and programming language in use today.
There are people who don’t think that something like this can be done in an open way; that it’s too large an undertaking to be advanced except by some giant vendor with a proprietary goal that will deliver a big payday. Hopefully the fact that an open project has received the first formal approval as an ETSI PoC says something about the power of open architectures. We’re going to continue to prove the skeptics wrong, and we ask like-minded people to contact us and be a part of that proof. This PoC approval is a critical step for CloudNFV, but it’s only the beginning.
Original Link: http://blog.cimicorp.com/?p=1553
