Welcome to my first public tutorial on my ExperiaSphere model for open-source-friendly management and orchestration. My goal here is not to build a product or even assemble an open-source project. It�s to show that such a project COULD be built, such an assembly could be done. As an independent consultant I simply cannot donate the time to do either of those things. What I can do and feel I must do is put some detail behind my conviction, and public assertion, that it can be done.

There will be at least four more tutorials in this series, and they�re not going to be light-hearted blowing of kisses. This should be enough detail for a good software architect to use as the framework of a project. It may be a bit of an effort, but the results can be worthwhile.

1

2

Networking, as a business is. We think of networks as tools for moving things around or connecting things, but that has become a tough business. For a long time now, the fixed-price Internet service model has driven revenue per bit downward at 50% per year in most major markets, to the point where some network operators are investing more outside their home territory than inside. Everyone wants to climb the food chain, or as we say it in ExperiaSphere, to think outside the bit. The problem is that we�ve not learned anything from history.

IP proved that service-specific networks weren�t the solution, but we have technology-specific revolutions staring us in the face. Operators want to secure overall improvements in service agility and operations efficiency but they�re contending with a set of strategies for the cloud, for SDN, and also for NFV. All this microsegmentation and siloing isn�t making it easy to control costs or move quicker. We need to have one consistent revolution that suits all.

Operators have hoped vendors would give it to them, but for almost a decade my surveys have shown that operators are dissatisfied with their vendors� support for operator transformation. They want to drive their own projects, and anti-trust rules make that hard�except for open source.

3

Years ago, Stevens commented in his book on computer networking that the great thing about standards was that there were so many to choose from! Things haven�t gotten easier in standards terms since Stevens� day. Arguably they�re worse because many of our current standards activities are driven by things widely considered to be �revolutionary�. Choosing among revolutions is really hard, so hard that in CIMI Corporation�s surveys the largest reported impediment to refreshing infrastructure investment is the risk that revolutionary change will strand the near-term steps by compromising the goals. One revolution at a time would be nice.

Another issue we�re facing is that the media coverage of all our revolutions has created a whole new generation of �washing� where companies adopt a little piece of something dramatic and then paint themselves with the mantle of the whole concept. Carried to extremes, this can cut off a revolution from its primary business drivers because implementing those drivers is just too much work.

Virtualization in any form demands some mechanism for treating services and applications and resources as sets of interrelated abstractions linked to reality only when the service or application is actually deployed. Service automation is the process of making this whole abstraction/instantiation process into an application. If we have one goal, that�s not an insurmountable task. If SDN and NFV and the cloud are all independent revolutions, then

4

service automation serves three masters. If we can combine them, they�re one compelling revolution, and the goal of ExperiaSphere is to roll all the revolutionary changes that exploit virtualization into a common open-source package.

4

What we�re proposing to do is support the need for universal management and orchestration by supporting, via open-source tools, the service lifecycle processes involved. Obviously we have to start by defining what those processes are, so that�s what we do here.

The first step is to have an Architect define a set of models that represent first how resources build up to expose service features and second how logical functions decompose downward to resources. A service is a cooperative behavior created among resources to fulfill a useful consumer mission, and the architect defines how everything cooperates. The output of the Architect is a Service Model consisting of packages of Service Objects,.

To create a real service, a Broker takes a set of service models and from that selects one that is suitable for the mission. The Broker could be a self-service portal or a customer service rep with an order entry terminal. Either way, a service model is selected and populated with service variables that are expected to be set at order time. The result is a Service Instance, and it�s this instance that we must track from its creation through use to eventual removal. That starts by what the industry has come to know as orchestration, which is the automated, structured, commitment of resources. It ends with the management processes that respond to service changes and environment/resource changes through the life of the service.

5

What we need to make the management/orchestration process work is a combination of two principles, which I�ve called �Structured Intelligence� and �Derived Operations�.

Structured intelligence is the use of a data model to define the relationship between service elements, service goals, and infrastructure. A service is really an assembly of logical or functional components, each of which is mapped to resources in various ways. If we can define the model, and find tools to convert the model into a set of recipes for deploying something, then we can automate service creation.

Derived operations is an essential element of all forms of virtualization, but one that�s gotten overlooked in a world of best-efforts. In a virtual service or with virtual infrastructure, you have a set of abstractions (which are in fact what our structured intelligence can create) that are committed to resources based on some set of optimization policies. The abstractions represent visible pieces of the service, and so they�re likely what we need to manage, at least from the perspective of the service user. But the structures we create are what push the bits and do the work, and if something breaks it has to be fixed in the real world not in the virtual world. This gives rise to the notion that we need to be able to derive an operations view of a service in an elastic way, to accommodate the fact that we have at the minimum two very different perspectives.

6

ExperiaSphere at a very basic level is aimed at using these two principles to support automating the service lifecycle for cloud, SDN, and NFV services in the future.

6

You may be imagining this vast new open-source project aimed at writing code to do all of this, and if somebody wants to use this material for that purpose, that�s fine. I think it�s unnecessary, though. If we decompose the requirements of ExperiaSphere into these chunks, we can then look for open-source tools that take us a long way down the path to a useful solution in each. To complete the work, we�d simply have to augment the tools a bit, and glue them together. This would take perhaps 15% of the effort of doing this from scratch.

We�re starting this with a project we�ll talk more about later on�something Professor Jorge Cardoso at the Universidade da Coimbra in Portugal described in a paper. This is a union of a W3C standard called �USDL� for Universal Service Description Language, and an OASIS standard called TOSCA for Topology and Orchestration Specification for Cloud Applications. You could visualize TOSCA as being a standardized super-OpenStack concept, and USDL as a kind of HTML for service descriptions. We plan to extend Professor Cardoso�s work (with his cooperation to the extent he can offer it) to build a way of describing our Service Objects and Service Model. More on USDL and TOSCA later!

The management side of this isn�t fully addressed in Professor Cardoso�s work, so there we start with the IETF�s model of Infrastructure to Application Exposure, or i2aex. This postulates a management framework in which original management data from �real� stuff

7

is dumped into a repository, from which proxy MIBS expose the data to the service/application layer. We propose to support this model using any convenient open-source DBMS, including Hadoop or MySQL. All that�s needed is the ability to respond to queries, such as those in SQL form.

What about processes, logic? Our third leg here is the lifecycle event management solution. In our Service Objects, we�ll provide a definition of variables that can be either derived from other MIB or Service Object data, or simply asserted internally. Some of these variables will represent the logical contextual states this Service Object recognizes, and others will describe the events that this Object will process. For the intersection of states and events, we�ll allow the definition of a process link based on the Adapter Design Pattern principles common in Java, SOA, and most object-oriented design. This will allow a Service Object to link a state/event combination to any current or new operations or management process or any convenient and useful piece of logic.

So this is ExperiaSphere in a simple fly-by. We now have to dig down to some more detail.

7

That digging starts with the Service Data Model. We propose to use a variant on Professor Cardoso�s combination of Linked USDL and TOSCA (in OpenTOSCA form) to define both the parametric portions and the structural model (respectively) for a Service Object. The green stuff in the slide is represented in Linked USDL and it�s as I�ve already noted the �parametric� data. We�ll talk about these things later on of course. On the right of the slide you see two critical things that are TOSCA-based. One is the structural description of the way the Service Object relates to subordinate elements, and the other is the interfaces the object itself exposes for connection, either upward or downward.

It�s important to note that the Service Objects aren�t fixed-function elements, they are abstractions that describe how something is built. What that something does is inherited from the collective properties of its subordinate elements. That means that we�re not constraining service features by presuming current models, or any models at all. You�ll see more on this later on.

In between these two things we have another element, something we think is really critical. We call it bindings, and as far as we�re concerned you can�t have a respectable MANO strategy without it. Bindings represent the connection between resources and Service Objects, and also between the resources themselves, created when deployment or redeployment occurs. I said I had a black box consisting of three subordinate pieces, and

8

this is what each piece maps to in the real world, for example. Absent bindings nothing about services and resources can be related, which means there�s no SLAs, no management, and likely no payment.

We�re going to talk about each of these things in more detail, starting now.

8

This is the structure Professor Cardoso�s work proposes, with the reference to his material attached (we offer other references at the end of this presentation). What the professor did was to create a commercial vision of a service using Linked USDL, a provider-structural vision of the service using OpenTOSCA, and then bind the two and present them through a SugarCRM portal. Both USDL and TOSCA are open standards (W3C and OASIS, respectively) and there are open-source implementations available for both. The model focused on building cloud applications that could be self-served, and we propose to expand that model to support network services and service management.

9

Linked USDL is an enhancement to basic USDL (W3C) that builds on generalized Resource Description Framework (RDF) vocabularies to optimize compatibility with other work and to improve automated handling of the schemas. Operations types will recognize that principles of Linked USDL, like the notion of business entities and processes, resemble those of the TM Forum�s SID model. Unlike SID, though, Linked USDL doesn�t impose a specific structure, which means that you can accommodate new things easily and adapt to whatever operations/management frameworks you like. It also doesn�t define process mappings, which means there is more flexibility in deciding how something is instantiated once it�s ordered.

I started this process with the goal of leveraging the TMF work, but some objected to that because of the membership requirements involved and others because of the structural factors I�ve just noted. The selection of Linked USDL does not foreclose mapping the parametric part of the Service Object to the TMF SID, it just doesn�t mandate it. This also means that evolution of TMF specifications is not required to build ExperiaSphere, which would likely be the case if we rigorously mapped to SID.

Here�s Professor Cardoso�s description of the evolution of USDL:

�USDL (version 3) was developed by a W3C working group (I developed the first and second

10

version while working at SAP Research). Nonetheless, the lack of commitment from companies to adopt the USDL specification was a showstopper for its standardization. Linked USDL, as you describe, is the successor of USDL. The Core model was published a few weeks ago: Pedrinaci, C.; Cardoso, J. and Leidig, T. Linked USDL: A Vocabulary for Web-scale Service Trading. In 11th Extended Semantic Web Conference (ESWC), Crete, Greece, 2014. (http://eden.dei.uc.pt/~jcardoso/Research/Papers/CP-2014-073-ESWC-Linked-USDL.pdf) We are now working on a Pricing and SLA model following the same principles. I think we will have a paper on them in one or two months. We will also have an implementation. You can find the Pricing implementation and examples here: https://github.com/jorgearj/USDLPricing_API/wiki/Simple-Example �

10

TOSCA, as I�ve already noted, is the OASIS standard for Topology Orchestration and Specification for Cloud Applications. It consists of three things; topology template, node types, relationship types, and plans. The intent in TOSCA is to model a cloud deployment at a high level of detail, and in my view this makes a TOSCA model rather inflexible, something like a DevOps script. The goal of ExperiaSphere is to use TOSCA in a valid but different way. Each Service Object defines its structure not in detail but in terms of subordinate Service Objects, which means that SO is a TOSCA Node and you create new Nodes by enveloping/connecting lower-level ones. Nodes have Interfaces that are satisfied by Relationships that connect the structure into the topology. Plans describe how you do stuff, including deployment and management.

11

Modeling stuff is great but at some point you have to build what you�ve modeled. It was my view that neither Linked USDL nor TOSCA were ideal as means of storing the information that is created during orchestration and deployment, nor of handling management variables for resources. As I noted earlier on, I�ve proposed an i2aex-like Repository for management data, and I also propose to use that Repository to hold what I�ll call the MIB-Set for a service. Each Service Object has an associated MIB-Set for each of its instances, and this is created when the service is deployed. Service parameters are transferred to the MIB-Set, and so are any derived variables, resource commitment records, and all the other good stuff that we indicated were elements of the Service Objects. The instance MIB-Set captures the setup, so changes to the models won�t impact existing services. The MIB-Set is what feeds the processes, so this is what manages the service lifecycle. You can still reference the models if needed, but the model doesn�t store the service instance data.

12

MIB-Sets are essentially a combination of collectors, storage, and viewers. The collectors are proxies like RTG or OpenNMS that can extract data from resource MIBS and store it with the proper indexing information. The storage is any DBMS technology that supports Query capability; I think SQL is the logical thing to focus on here. The viewers are also proxies that maintain a �proxy MIB� by querying the repository. They then format the data for presentation using the selected interface.

Because the MIB-Set is stored in the Repository, anything that can process query output can use it and anything that can be represented as query-able data can be stored. We think this offers an easier link with current tools, because those tools expect variable-format parametric information.

13

One challenge for both Linked USDL and TOSCA is the notion of parameters, variables, and management data. Since our ExperiaSphere model requires a hierarchy of Nodes, we need to understand how Node variables are created and how they can be accessed across a service. We�ll start with parameters.

A �parameter� is a variable that has something to do with nodal operation. Parameters can be asserted by any node if the parameter belongs to the node. They can also be �inherited� from superior nodes if the superior node exposes them, and the same is true for subordinate nodes. There is no provision for parametric flow except adjacent nodes, so if you want to pass across multiple levels that has to be supported by the intermediate nodes.

When you express parametric inheritance you can provide an expression relating your variable to that of your superior or subordinate.

14

Management data can also be inherited from subordinate structures, meaning that a management variable set by a subordinate can be used in an expression to derive a management variable at the higher level. This in fact is essential since a higher-level object�s management state would almost always be derived from the state of the objects below.

15

Now we come to that critical topic of binding. When we build a service model we express logical relationships that have to be converted to real relationships in the real world. That means not only instantiating components but also connecting them, and building the necessary management framework. This is all the responsibility of the binding process.

We currently expect to record bindings in the MIB-Sets of each Service Object. They provide information on the entire service structure and so would permit a �browser� to spin through the structure to look at stuff. The bindings record the superior/subordinate links for each object, and where the object commits resources the links to the resources are provided. This would mean that the Service Objects would not be altered, though it would still be necessary to retain a link between the MIB-Set and the version of the Service Object that created it. However, it could be that an implementation would store the binding data in a copy of the Service Object, the �instance� of it. We�re not sure which approach would be best at this point, but either can be supported as long as the approach is consistent.

16

Derived Operations was the second principle of ExperiaSphere, you�ll recall. The goal here is to manage the heart of all modern network (and IT) technology�virtualization. When you virtualize something you create an abstraction that represents the collective functional properties to be used, then use automated tools to fulfill those properties through commitment of real resources. The maximum value of virtualization can�t be reached without abstracting not only functions, but management as well. Otherwise users see a different set of MIBs and variables representing stuff they don�t even think they have. A virtual firewall may map to a machine image running in a VM on a server in the cloud connected through OVS, but you�d better not show that to somebody who thinks they bought a firewall! On the other hand you can�t send a real tech out there to fix a virtual firewall; the operations people have to see the real stuff, and the bridge between resources and functions that you�ve built.

What this means is that we have to be able to compose management views, not only in the sense that we have to make views compatible in an interface sense with all of those who expect to consume management, but in the sense that we can build a management view for any virtual element we�ve used or find convenient. We also have to be sure that when we expose a virtual management view to a user, they can�t inadvertently change the state of a shared resource that�s used to support that virtual element. They can only manage their own tenancy.

17

The only way to do this is through that IETF concept of infrastructure-to-application exposure or i2aex. In ExperiaSphere we presume that there is a Repository that�s been created using any convenient cloud-ready DBMS that supports a query language like SQL. We then take all the �real� or resource data sources, and all the management data provided by software we�re using/deploying, and collect it through MIB proxies like RTG into the Repository. We store data under a qualified unique source name there, subkeyed by the MIB variable. Note that MIB-Set data from the Service Objects are also stored here in the current thinking, so we have a record of the management variables of both the virtual and real world. Also remember that we�ve provided a binding between the two worlds, so we can derive a virtual management variable using expressions referencing bound resource variables.

When we want to manage something, we have two basic directions we can take. First, and most likely, we can start with what the customer sees, meaning that we start by looking at a Service Model, the Service Objects, and the management state of each of these objects as derived from that of their bound resources. Second, we could start with the structural organization of our resource pool and browse that to find something we want, then use its unique resource name to find the services it�s bound do. We can skip between service and resource views if we have the right policy privilege.

17

This shows our Derived Operations vision as two interdependent flows, the �deposit� side and the �view� side, with the repository in the middle. We propose to use open MIB proxies for the �hourglass� figures here, modified as needed to support the query interface to the repository and the management interface to the management system or user. Some resources may have licensed MIBs or APIs, in which case a proprietary proxy would be needed since an open one would expose the details the license limits exposure for!

18

You can make �Repository deposits� from resources, but also from traffic probes or correlation �daemons� that are running to explore conditions that are unusual as a collection of conditions but not necessarily issues on a per-MIB-variable or per-resource basis. In a sense, anything can make a deposit in the Repository, but it�s important to be sure that when deposits are made the recorded data is bound in some way to either resources or services, or it�s going to be hard to integrate it.

19

So far we�ve modeled and managed things in abstract, but we�ve not talked about how we actually connect logic or processes to this. The answer is that it�s all done through the Service Object. The SO will always define at least one Management Interface that can be used to control the object and determine its state. It also exposes an Event Interface to which events from outside can be posted. This is just a kind of management interface so we don�t have to think of it as new work, just an application of what we�ve already covered.

Inside the SO is a table, and this table relates the operating states of the object (as the architect who built it has determined them) and the events the object must handle. The states and events are just management variables too and so they�re part of the MIB-Set for the SO. When an Event is processed, the SO will vector the event to the associated process depending on the operating state. It�s as simple as that.

20

The state/event table in ExperiaSphere has three elements for each intersection. The first is the process to which the event is to be directed, in the form of a URI. ExperiaSphere will send the MIB-Set of the SO as a package to that process, and expect it to be returned with any updates needed. The second is the next-state value, which can be null if the process is able to set its own next state, and the last is the generated-event value that allows this event to trigger another specified event, which can be directed to a superior or subordinate SO.

The standard process interface model (MIB-Set in/out via URI) can be adapted to any management interface through the use of the Adapter Design Pattern concept, which simply envelopes a different management interface or process API and translates between that and the ExperiaSphere model. This is how any current OSS, BSS, NMS, or other process can be integrated with ExperiaSphere.

Remember that service lifecycles are states, and that therefore the way that a service object is instantiated is a lifecycle process that�s linked through this same table. All logic, including deployment logic, is coupled to the SO in the same way.

21

We�ve described ExperiaSphere functionally at this point, but we should also look at it as it relates to the glorious whole of NFV, SDN, and service operations, which is what we do here.

Networks can be visualized as two �domains�, one representing their abstract, service, or functional image and the other representing the resource pool and its structure and state. MANO functions like ExperiaSphere live mostly in the Service Domain but they test the waters in the other two areas necessarily because they provide services to deploy virtual functions and applications, and they commit resources. We have to define how this cooperation works.

22

The term MANO comes out of the work of the NFV ISG, and TOSCA is about orchestrating and managing cloud components. How do we get software applications deployed and managed? Remember, our goal is to be universal here, which means that we can�t force changes to current application or network software. We have to connect whatever�s out there and make it work.

Well, this shows how that happens. Any deployable software is enveloped in a Service Object. The normal ExperiaSphere practice would be to create one for each VNF component, so in ISG terms the SO parameters make up the VNFD. When the SO is deployed as part of a service, the lifecycle processes in the SO will include one to instantiate the needed VNF�put it into a virtual machine�and connect it. What you end up with is a structure that is essentially a �service element subnet� in which the related components live. Some interfaces are interconnected inside this subnet and some are NAT-proxied or otherwise connected out into the real service address space.

All of the management interfaces exposed by the internal elements of the SO are proxied back into the Repository, and a new Proxy is created (more than one if needed) to expose the management properties of the SO itself. This proxy would work on derived management variables that include some from the bound resources.

23

What this means is that ExperiaSphere builds a kind of adapting shell around whatever software it deploys to make it compatible with the ExperiaSphere management/orchestration framework. No changes are needed to the software, which means that something right out of the software box, including open-source network tools, can deploy and be fully managed as we�ve described, without using any custom APIs and thus without being changed in any way. That�s critical because if MANO platforms do use custom APIs, they can create silos by forcing every VNF or component provider to build a version for every MANO platform. We don�t do that.

23

Let�s now address the other issue of the resource pool, the bottom of those two domains that we talked about a couple of slides back. I also want to make a point, which is that the notion of two domains isn�t arbitrary. You don�t want people designing new services by diving down to how every element of the service is mapped to resources. You�d create a thousand inefficiencies and likely even more inconsistencies. The ExperiaSphere idea is simple; network and IT infrastructure is going to be used in a pretty limited variety of ways, and there are already management systems in place to support them. You want a VPN? You have a perfectly good NMS that can build you one. Why build that same service again by assembling objects? Yes, there will be cases when you want to �compose� or �orchestrate� in the resource domain, and the ExperiaSphere model can support that where it�s necessary. But most times it won�t be. The resource world is already structured, and you need only to describe that structure. The resource world already offers services, and you need only to expose them. That�s what the bridge element between these domains does�the Infrastructure Manager.

24

You need a systematic way to express resources as much as you need a systematic way to express services. The model is more arbitrary at the top, where the goal is to codify unified discrete elements of infrastructure domain. From the top level you�d normally identify facilities like data centers, POPs or other locations, and from that the management domains for devices that live there. These ultimately point to the device or component, whether it�s real or virtual. In ExperiaSphere, we presume that Service-Object-Like elements (identical except for content) called Resource Objects will be used to collect this physical or logical structure. This provides the option, at the bottom, to list devices/resources if you�re going to rely on a higher-level management service to assert their relationships, or to provide a topology diagram if you want the topology exposed. However it�s done, every object has a unique name that�s qualified downward: zone.facility.domain.element. Because each of the structures, the ROs, are represented by objects they have all the same management derivation potential, which means that you can define variables and derivations and provide unique management views for the resource structure.

Formal structuring of the resource domain is important because formal on-boarding of all resources is critical in securing a virtualized, orchestrated, resource pool. You can validate and sign resources when they�re on-boarded and check their authenticity when you deploy. There are many commercial and open-source tools for element-signing and we don�t

25

propose to dictate one here. In particular there are concerns about open-source security frameworks so we�re expecting implementations to at least admit proprietary models.

25

We now have to look at that bridge between resources and services, a bridge that startswith a notion we call a �Service Model�. Service models are really important to ExperiaSphere because they provide a way of bridging between a service-side or consumer-side or functional view of a service, and the set of stuff that the resources themselves, through their own management systems, are capable of doing. You can use ExperiaSphere modeling principles down to the level of devices and VMs if you want, but I think that in most cases the boundary between the Service and Resource domains will be the description of the model that represents the product of the latter and the consumable of the former. Remember, a service model is an abstraction; it can be called anything that�s evocative as long as that something can be created by the resource side and can be understood at the service level.

For SDN, the service model is a critical concept in my view, because it�s an open abstraction that becomes the goal of the �Northbound APIs�. You don�t have to define Ethernet or IP as service models (though you can); you can define any useful combination of forwarding rules. That means that services can go beyond what we can currently define, into new-value, new-revenue territory.

26

A service model, as I said, represents something the resource pool can offer, which ExperiaSphere calls an Infrastructure Service. It�s accessible through an interface or an API and it does something useful, and it doesn�t have to be created because it�s already there�native behavior. Everything on the web or in the cloud can be one. So can SDN controllers, NFVI (you�ll see that an Infrastructure Service is managed by an Infrastructure Manager like the one proposed in the NFV Specs). Most significantly, any proprietary or open management interface or tool that allows something useful to be created can be one. This means that a service model can represent all the stuff that�s already in the network, the cloud, the Internet. We don�t have to do all that over.

The idea behind service models and infrastructure services is to create a boundary abstraction at the place where current service management and IT tools like cloud management systems leave off. We want to be able to describe these services in abstract (a service model) so that we can direct a common request��MakeAVPN� to any of the Infrastructure Services capable of doing that. This lets us avoid coupling services directly to presumed implementations.

We want to make a very important point here, which is that Service Models and Infrastructure Services are �natural� federation tools. A partner provider can offer such a capability, and it would be composed in just like any Service Model, but would invoke

27

infrastructure on the partner�s resource pool. Management visibility and control capabilities are completely buffered by the abstraction of the Service Model; you expose what you choose!

27

Infrastructure Managers publish one or more service models, each of which is a kind of �virtual Service Object�. This means that the Service Model has all the SO properties, including lifecycle stuff, instances, etc. So when a Service Model requests an Infrastructure Service it�s simply linking to another SO as it would normally do. The control logic needed to do what the service model requires is integrated into the virtual Service Object the model represents as part of the lifecycle process, and when a Service Model is instantiated the instance behaves like any SO instance as far as management derivations and so forth. The Service Model, like any SO, is responsible for turning its resource MIB variables into its own management variables for exposure, so it policy-limits the management view of resources available. That creates a barrier that requires management privilege to cross.

An Infrastructure Manager is implemented as a Service Object set. That means that any service model can represent a structure of ROs/SOs as easily as some management interface or provisioned service. Where there are no available native management tools to build something, it can be structured as a set of SO/RO elements. You can also invoke TOSCA cloud provisioning or OpenStack as needed�all from this abstraction.

28

So we�re about done (I�m sure you�re grateful!) These four blocks represent the pieces of ExperiaSphere with the large box showing the open-source elements and the smaller offset ones what we need done in each area. Note that I�ve included a recommended hosting platform for the cloud, NFV and SDN software�Wind River�s CGCS. I think they have the right idea with CGCS and I like their notion of supporting an ecosystem on top of an open-source framework. I hope that ExperiaSphere can add some new open-source options to that ecosystem!

On the data/service model side, we�re basing things on Professor Cardoso�s model of Linked USDL and OpenTOSCA, and you can use SugarCRM as he did to bind this to a presentation framework. There, what would likely be valuable are standard vocabularies for both Linked USDL and TOSCA to structure the information in a common way.

For Derived Operations we can really use anything that can support a query language. There is value, I think, to saying that the query is SQL because you can generally harmonize that to an open DBMS. What�s needed are the proxies that will either make deposits in the Repository from the true management data sources, or link the repository via query to management interfaces and applications.

Linkage to the resources also requires Infrastructure Managers, which are a combination of

29

lifecycle process stuff covered in our next block, and the management interfaces/proxies of the prior blocks. Some standard Design Pattern for these would be logical.

Finally, we need Adapters to provide a link between arbitrary lifecycle processes and other management/logic components and the standard ExperiaSphere RESTful model that links the MIB-Set to a process URL.

We see the rose-colored shapes as representing the actual development needed to implement ExperiaSphere.

29

This slide maps ExperiaSphere to the ETSI NFV E2E architecture model from the ETSI document. If we start with the blue-shaded area, we see that NFVI is the Resource Domain whose native capabilities�Service Models�are exported into the service domain through Infrastructure managers that are a superset of the ETSI VIMs in that they represent anyunderlying resource capabilities, legacy, SDN, and NFV.

The VNFs, the virtual functions, run as the ETSI model describes, but any management relationships they might have (either as the source of management data or to exercise infrastructure control) are proxied and virtualized for policy control and reflection in any convenient form. This is Derived Operations.

Operations processes, management processes, the actual orchestration and deployment steps, or anything else that creates or receives service/resource events is bound to the Service Objects via the state/event logic described for each.

The ETSI model has been declared to be a functional model not a literal implementation diagram, and ExperiaSphere supports all the functions and can also expose all the interfaces.

30

This slide shows how ExperiaSphere maps to SDN, using OpenDaylight as the model for the controller. At the bottom, resources (white-box switches or whatever) contribute their management variables to the Repository to be integrated into Derived Operations. SDN services are created above the Northbound APIs and these services are mapped by the Infrastructure Manager into ExperiaSphere Service Models. ExperiaSphere doesn�t mandate any particular way that SDN can associate application/service state with specific resources; the Repository simply records what�s done and makes it available to the user of the Service Model up in the Service Domain. We think that having some structured way of associating resource state to the services created by the application layer would be logical for SDN and of course it could be supported by a proxy when it�s defined. All we need is to populate the Repository with the bindings between Service Model instance and committed resources.

31

This slide shows how ExperiaSphere fits into the current service context. First, anything that can provide management status or management access can be enveloped by a proxy or Infrastructure Manager, including every device or element of every service we already have. In addition, any event analysis, big-data analytics, or other information derived from operation can be posted into the Repository. Whatever is there now can be connected. Once connected, it can be made available to any management person or process. We�ve build on the basic principles of the TMF NGOSS Contract and GB942, to allow for the completely open and agile virtualization of management data. Even a network with no SDN, no NFV, can be orchestrated and managed using ExperiaSphere principles.

32

33

I have to emphasize that I�m an independent consultant and I can�t launch enormous, time-consuming, free activities. I think the topic is important so I have to navigate the zone between supporting open-source universal management and orchestration and paying the bills. My solution is to produce detailed video tutorials that should be adequate for a software architect or project team to use as the basis for planning the actual implementation and deployment. This video is an introduction, and it will be followed by four other videos that will explain the concept in more detail by explaining the model in terms of a service lifecycle.

34

35

36

37