If you look around tech these days, you can't excape the notion of "virtualization". The term, in tech at least, means the presentation of resources as a set of classed property sets rather than as a discrete collection of devices/components. Users and applications bind to the property set they need, and that in turn binds them to assigned resources.
The concept of "virtualization" is probably best known in the server world where products like VMware create a "virtual machine" as a software segment within a server. In networking, the same notion has been explored implicitly since the days when packet switching was first invented (1976, if you're curious!) and explicitly for about five years. In the networking world, the term "abstraction" has been used as well, and that seems to be gaining the upper hand in usage. We'll use it here, but we want to put things a bit into perspective first.
An abstraction, in general, is a logical representation of something or a virtualization. Just what gets abstracted depends on the specific mission of the thing that's creating the abstraction in the first place. For example, one common problem with network operations and management is the multiplicity of systems that are trying to examine and control resources. This can create multiple polls for device status, loading the device and the network. If every network element is "virtualized" or "abstracted", then the virtual device can poll the real device and be polled by all of the software elements. That is perhaps the most basic of the abstraction missions.
You can make this even more abstract, of course. You could start by making each of the "virtual devices" appear to higher layers as the same kind of box from the same vendor, even if they're a diverse collection of stuff. That makes management of the devices easier. You could also then say a collection of virtual devices might appear as a single device, and so creating a complex route could look like simply cross-connecting two ports within a box. You can go still further, and make the collective resources used to create a service appear as though they were a decicated mini-network. In short, abstraction/virtualization is a very powerful tool in converting a resource-centric view of networking (an essential view since resources create everything) into a service-centric view (essential because services are what people buy). But all abstractions are not the same, and what you'd like ideally is to have an abstraction capability that lets every individual network operator decide what views they want, and when, and derived from what. That's ExperiaSphere's goal.
Let's now bring this down to our own concept of abstraction. Abstraction in ExperiaSphere is the ability to create a logical view of a network, a service, or components of either one and to support the manipulation of the "real thing" through manipulations of the abstraction. If you look at this at a very simple level it may seem to be a stupid waste; why manipulate a "virtual node" when you can manipulate a real one? One answer is that the management of systems of resources can be simplified if the resource systems are viewed by the management systems and those who use them as a single atomic resource. That’s because it is possible to abstract not only resources but the process that control those resources, so that when you “activate” an abstract service the things you need to do to make that happen are all done without the knowledge of the process that did the initial activation.
You can apply this vision in a resource-centric way. A good example of this is the routing of a path from one place to another inside a network that has automatic discovery or another tool to facilitate path routing. An operator might create a path from access to the real nodes and trunks, threading the path from one place to the other, but it would be time-consuming and would risk the operator making a non-optimal (or even non-functional) decision. On the other hand, if the operator viewed the resource system that makes up the network as a single node, a command "Connect Port A to Port B" is all that's required, and software inside the abstraction layer would do the rest.
In a service-centric view, we might want to talk about "managing Corporation X's Carrier Ethernet Service" as though this service was an independent collection of stuff, so that when something happened to it a network operations type could simply click on a service icon, have it dissected into the switches and paths involved, and then look at each. To create the service, the order system might say "connect these five sites into a virual LAN" and that would take an abstract concept "E-LAN" and make it into a provisioned reality, without requiring that the system that supported the order ever know just how that was done.
Multi-stakeholder or syndicated services is yet another view. An operator wants to view a service that crosses multiple providers in a way that shows them in detail what their own contribution is, but abstracts the contributions of others in a way that is appropriate to the amount of management visibility each partner offers the other in the relationship. Ever see those funny maps "A New Yorker's View of the World" that show one area outsized and everything else tiny? That's a pretty good reflection of what an individual operator inside a multi-operator relationship would like to see.
Abstraction of this type has been supported in many standards over the years, but the support has been more theoretical than practical. What is bringing abstraction to the fore today is a real business focus on the kind of multi-party “componentized” services that may be “syndicated” to other partners that we just mentioned. All of this creates real service management problems, problems that a meatier form of abstraction is needed to solve.
A "service" is another kind of abstraction, and the latest work in the TMF on what is called the NGOSS (Next Generation Operations Support System) Contract is an embodiment of the emerging service issues. The NGOSS Contract work defines a set of “views” of a contract, some of which relate to how the contract is implemented and deployed on real resources. This, according to the early documentation, provides a critical context, relating the operations processes and parameters to a service commitment. By activating the commitment, you have access to the context that defines how the commitment is fulfilled.
We contend there are still opportunities for further abstraction, beyond even what TMF currently proposes. Services are not of a specific collection of resources but of a collection of resource behaviors. If you think of how our path above would look in an IP or Ethernet network, you realize that it's logically invisible. How then do you manage it? It was created by a committing of resources, and if that commitment was somehow recorded as an abstraction, the service that today is just a coordinated set of behaviors could look like a collection of dedicated resources. In this case, it could look like a line or wire that hops between nodes. With this new service vision, we can now do "real" things to our virtual or logical structure. We can make it faster or slower, change its path, test the status of the pieces of it, and correlate problems with one of its components back to the behavior of the service.
Two things make this important today. First, customers pay for services and not for abstract network commitments. That means that I really need to focus my management system around services--the things that are generating the revenue. Despite this, management systems today often create a break or boundary between the notion of services, which they view as contracts and commercial terms, and networks that create the services. In fact, most network operators have only vague and imprecise bindings between the two. Which brings us to the second factor. An abstraction layer can create the linkage between networks and services without requiring that either network or service management as it currently exists get changed to accommodate that link. You can sell a "service", have an OSS/BSS system provision that "service" as though it were really committing resources, but have the resource part managed in the abstraction layer. Why? Because the OSS/BSS doesn't do services the way they need to be done. Standards today demand the notion of "service mashups" where services are created by bonding pieces that are sometimes network behaviors, sometimes hosted features or applications, sometimes content, and sometimes supplied by a partner rather than created internally. The abstraction layer can manage that orchestration or composition or syndication, something that would be very difficult and time-consuming to retro into current OSS/BSS products.
There are benefits on the network side too. Abstraction can simplify the way that service creation and problem management are handled in the network by creating a natural structure through which faults can be correlated back to behaviors. If a "service" to a customer is a share of hosting capacity and a share of QoS-assured delivery bandwidth, those two components can each perform or not perform, and in the latter case the fact that you know what services the components are used to create, you know what customers are impacted.
ExperiaSphere is an abstraction layer in every sense we’ve described. In fact, it’s essentially an unlimited set of linked abstractions that are easiest to visualize if you think of them in two layers. The higher layer, the service layer, is a business-driven model of the service that deals with its logical components (behaviors) created by resources, and how those behaviors are combined to present something commercial to the customer. The lower layer, the resource layer, creates behavior sets from compatible resources of any type, so that multiple types of resources can be organized to create the same behavior, and thus support the same service mission without changes to the service logic. The two bind at the conception of behaviors in a very logical and flexible way. Service-layer logic can decompose high-layer services and provide problem correlations. Resource-layer logic can manage the behaviors of all of the resources toward the goal of meeting the service commitment. You can absorb (abstract) or expose as much of either as you like, and how much is exposed is a function of the capabilities of the management processes that operate there. You can create software in either layer that performs complex service coordination/automation tasks and have the functionality exposed as an abstract to the other layer, even making it look like a human operator did it.
The real world has begun to impinge on the abstract world of standards, and the current work on abstraction in areas like the TMF and OMG are examples of this injection of market reality. The market is clearly going to get a lot more real over the next several years, as operators try to monetize network investments in difficult economic times. We contend that abstraction is the current goal of the key standards processes in the Telemanagement Forum (TMF) and other bodies, and that it will quickly become a requirement in all major NGN installations. ExperiaSphere is ready to provide it.