The document outlines a public tutorial series on the Experiasphere model, which aims to provide an open-source framework for management and orchestration of network services by combining various revolutionary technologies like SDN, NFV, and cloud computing. It emphasizes the need for universal management tools and structured intelligence to automate the service lifecycle, positing that built services must effectively bridge the gap between virtual models and real-world resources through a carefully defined architecture and data management techniques. Ultimately, the goal is to create a cohesive open-source approach that integrates existing technologies and provides a flexible, efficient solution for managing service provisioning and orchestration.

1. 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. 2

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. We now have to look at that bridge between resources and services, a bridge that starts
with 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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 any
underlying 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

41. 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

42. 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

43. 33

44. 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

45. 35

46. 36

47. 37