I had an interesting exchange with a big national carrier on the subject of management integration and unified modeling of services. I’ve noted in past blogs that I was a fan of having a unified service model, something that described everything from the tip-top retail experience to the lowest-level deployment. I pointed out that such a model should make management integration easier, but also that it would be possible to have integrated management without a unified model. You’d need only firm abstractions understood by both sides at critical boundary points.
My operator friend had given some thought to the same point, and reached somewhat different conclusions. According to the operator, there is a distinct boundary point between service management and resource management. Above the line, so to speak, you are focused on conformance to an explicit or implied SLA. It’s about what the user of the service is experiencing, not about the state of the resources underneath. In fact, you could have significant faults at the resource level that might not generate any perceptible service impact, in which case nothing needs to be done in service terms.
Taking this even further, the operator says that as you move into virtualized resources, where a service feature is created by assembling hardware/software tools that probably don’t directly bear on what that original feature was, in management terms, the boundary between services and resources gets even more dramatic. So dramatic, says the operator, that you may not want anyone to cross it at all.
Let’s presume that we have a “service layer” and a “resource layer” both of which are modeled for automated deployment and assurance. The boundary between the two layers is a set of abstractions that are the products of resource behaviors. An example might be a “VPN” or a “subnet” or a “VLAN”. The services are built from these abstractions, and it’s the role of the resource layer to make them real.
The operator’s vision here can now be explained a bit more clearly. A “VPN” abstraction has a set of management variables that are logical for the abstraction. The service management side has to be able to relate the state of those variables up the line to the customer or the customer service rep. However, there is no reason for the customer or CSR to dive down through the boundary to see how a given “abstraction property” was derived from the state of resources. After all, what’s underneath the abstraction covers is likely a shared resource pool that you don’t want people diddling in to begin with.
There’s a lot to say for this view, and it may be particularly important in understanding the two camps of operations modernization, the “I want to preserve my OSS/BSS processes and tools” and the “I want to start OSS/BSS over from scratch” groups. If you take my operator friend’s perspective, you can see that things like SDN and NFV can be viewed as “below the line”, down in the resource domain where operations systems and processes that are (after all) primarily about selling and sustaining the service don’t go.
I kind of alluded to this approach in a past blog as the “virtual device” mode, but I think it’s a bit more complicated than the term suggests. The operator is saying that “networks” are responsible for delivering abstract features from which we construct services. There may be many ways a given feature could be created, but however many there are and however different they might be, the goal should be to harmonize them to a single common abstraction with a single set of properties. Management above the line relates those properties to the overall state of the service as defined by the service’s SLA, and management below the line tries to insure that the abstraction’s “abstraction-level agreement” (again, explicit or implied) is met. Both parties build to the same boundary, almost the way an NNI would work.
The difference between this and what I was thinking of as a virtual device approach is that in general the abstractions would be network behaviors, cooperative relationships involving multiple devices and connections. My thought was to make “virtual devices” that mapped primarily to real devices. I have to agree with my operator’s view that the abstraction-boundary model makes more sense than the virtual device model because it fixes the role of OSS/BSS at the service level and lets fulfillment go forward as it has to, given the resources used.
The value of this independence is that “services” know only of network behaviors that are “advertised” at the boundary. Most new network technologies, including SDN and NFV, are considered primarily as alternative ways of doing stuff that’s already being done. We have IP and Ethernet networks; SDN gives us a different way to build them. We have firewalls and NAT and DNS; NFV gives us a different way to deploy those features. In both cases, though, the service is made up of features and not devices or technologies.
Oracle, interestingly, has been touting something it’s working on in conjunction with the MEF, called lifecycle service orchestration or LSO. The Oracle model shares much with Alcatel-Lucent’s vision of how operations and NFV or SDN coexist, but interestingly my operator friend says that Oracle, Alcatel-Lucent, and the MEF don’t articulate that critical notion of a boundary abstraction to the satisfaction of at least this particular operator.
The abstraction-boundary approach would make a two-tier management and orchestration model easier to do and set boundaries on implementation that would largely eliminate the risks of not having a single modeling approach to build both sides of the border. In fact you could argue that it would allow vendors or operators to build service-layer and resource-layer structures using the stuff that made the most sense. Two models to rule them all instead of one.
Or maybe two dozen? In theory, anything that could present an abstraction in the proper form to the service layer would be fine as an implementation of the resource layer. The abstraction model could at least admit to multiple vendor implementations of lower-layer orchestration and resource cooperation. It could even in theory encourage them because the abstraction and the existence of a higher-layer service model would harmonize them into a single service. It’s a bit like telling a programmer to write code to a specific functional interface; it doesn’t matter what language is used because from the outside looking in, all you see is the interface.
I’m not quite ready to give up on my “single model” approach, though. Obviously you can create an abstract-based boundary between services and resources using a single model too; you can create such a boundary anywhere you like whatever model you use. The advantage of the single model first that you can traverse the model from top to bottom with the same tools, and second that you are using the same tools. I confess that current practices might make traversing an entire model less useful than I’ve believed it would be, but we still have to see how practices adapt to new technologies before we can be sure.
This is the sort of input I think we should be trying to solicit from operators. There are many out there who are giving serious thought to how all of our revolutionary technologies would work, and many are basing their views on early experimentation. This sort of thing can only strengthen our vision of the future, and the strength of that vision will be a big part in getting it financed.