CloudNFV was started as a response to the initial industry Call For Action issued by 10 global network operators in the fall of 2012. It was this Call for Action that generated the ETSI Industry Specification Group. Tom Nolle of CIMI Corporation responded to the operators with this document, which proposed that there were two critical steps needed to optimally advance the goals of network functions virtualization. One was a presumption that cloud infrastructure would be the platform for NFV, and the other was that prototyping should begin as soon as possible to insure that actual implementations emerged and could be used to test assumptions during the standardization process.
Tom worked on the architecture through the winter, and in April of 2013 at the NFV ISG meeting, he collected a group of vendors who collectively filled all of the functional requirements of the architecture with best-of-breed strategies and who were willing to commit their companies to the ambitious task of prototyping something as comprehensive as NFV even as the actual work on the standards was still proceeding. You can meet this team here. The group began cooperative work immediately, and basic development was completed in August 2013. This was the point at which we decided that we would go public with our architecture and our founding members, and at the same time publish our policies for integration.
The name “CloudNFV” was selected because our fundamental position is that NFV must be a cloud-hosted process. We embraced OpenStack as our cloud architecture, and we also adopted a unified data repository model, a goal we believe operators have sought for some time. Finally, we structured our service definition framework according to the principles of the Telemanagement Forum (TMF) Frameworx Services Domain (GB922) because we found that structure to be ideal for describing both the organization/composition and the management of virtual-resource-based services.
CloudNFV is about openness. None of the big network vendors was involved in the process because we feared it would become proprietary, but we welcome integration with all vendors. We will publish our data models and interfaces, conform to the ISG interfaces as they are finalized, and work to integrate our platform with network functions software, network and data center hardware, and management systems just as much as our resources will permit. We’ll contribute our findings and practices back into the NFV ISF and into the TMF through appropriate liaison processes. We’ll publish material as fast as we can, but remember this activity isn’t funded and all of the work is donated by the companies involved.
Use of the SDxCentral service directory is governed by our Terms of Service, including without limitation those sections under the headings "CONTENT", "LICENSING AND OTHER TERMS APPLYING TO CONTENT POSTED ON THE SDXCENTRAL SITES", "INDEMNITY; DISCLAIMER; LIMITATION OF LIABILITY" AND "COPYRIGHTS". Under no circumstances will SDxCentral be liable in any way for any Content, including, but not limited to, liability for any errors or omissions in any Content or for any loss or damage of any kind incurred as a result of the use of any Content posted, emailed or otherwise transmitted via the Sites.