It's Time to Think Outside the Bit!
I'm Tom Nolle, President of CIMI Corporation, and architect of ExperiaSphere. I want to open your experience with ExperiaSphere by explaining what it was, what it is, and how it got there. Along the way, I'll put it into perspective with respect to industry groups and some of my other activities.
The original ExperiaSphere™ project was launched in the spring of 2008, largely as a result of my work with the IPsphere Forum and the TMF’s Service Delivery Framework (SDF) activity. Operators in the latter expressed concern that the work might not translate into implementation. To quote one EU operator who was highly influential in the early activity, “We’re 100% behind implementable standards, but we’re not sure this is one.” Ultimately five operators cooperated in providing me guidance on what would be an implementation-driven approach.
My approach was to define a service as a set of functional objects that were vertically integrated from the service level to resources. The objects were essentially abstractions in the management plane that represented collective cooperative network/resource activity. Manipulate them and you manipulated what they represented.
The objects were created by writing a simple Java application that built an object structure from what I called “Experiams”, instances of a Java class that was the core of the implementation. The Java application so created was called a “Service Factory”, and when instantiated it created an XML document that was a service order template. Such a template could be sent to a Factory when an order was created, and the Factory would then stamp out the service. Each instance of the template created a Service Order XML document that not only contained the parameters that defined the service, it also contained the information on how resources were allocated.
Each Experiam in a Service Factory was a state machine, but state was maintained in the Service Order. Whenever an event occurred, the Service Factory loaded the associated Service Order and ran, which set state for all the Experiams correctly. We made two presentations on this to the TMF and did a demonstration of how it would work.
When NFV came along, I recognized that it was addressing the same overall issue. By that time, I’d decided that while the Experiam approach and service factories had merit (and worked), it might be better to build a data model (equivalent to the Service Order) directly and have logic process that model. In early 2013 I had a conversation with Dave Duggal of EnterpriseWeb, and determined that his software model could implement that model-driven approach fairly quickly. I attended the April ISG meeting in the Bay Area, met Dave in person, and assembled a group of vendors who expressed interest in putting together an open project to implement NFV based on the architecture I’d put forward. That became CloudNFV™. I was chief architect for the CloudNFV project through 2013 and stepped down in January 2014 when it became clear that I couldn’t afford to continue to contribute my time any longer.
The “new” ExperiaSphere project takes the proven approach of ExperiaSphere’s first phase and the basic architecture I contributed to CloudNFV, and frames it in such a way as to make it possible to implement it largely based on open-source tools. Unlike CloudNFV, this ExperiaSphere project is not a consortium activity nor will it result in an implementation—only a series of tutorials that explain the architecture and approach in great detail. If that’s what you’re looking to do, then this is the right place, and you should click on the “New Architecture” tab to get the details. You can still access all the original material by clicking on the “Original Project” tab. You can find the CloudNFV material at http://www.cloudnfv.com.
ExperiaSphere and CloudNFV are Trademarks of CIMI Corporation.