Some General Thoughts on Service Modeling

Everyone tells us that service composition based on software tools is critical.  Operators say that “agility” in service creation would help them address opportunities faster and better, and vendors think it would promote their products in a market that’s increasingly price-competitive.  Perhaps it’s surprising, then, that there doesn’t seem to be a unified position on just what “service composition” means or what’s needed to provide it.

Network services are created from cooperative relationships among network devices.  Historically this has been simplified by the fact that the “service” and the cooperative relationships were created at the device level, meaning that the system of devices we’d call a “network” had their own rules for cooperative behavior, an offshoot of which was one or more retail services.  Services in this framework are somewhat coerced rather than composed, because the behavior of the network is really the natural underpinning of service behavior.

Even where operators didn’t have continuity of control, as would be the case for multi-provider services, it was routine to define network interconnect points with policy-managed traffic exchange.  As long as the service protocol was the same, NNIs largely eliminated the composition problem.  I say “largely” because multi-provider services still required the coordination of VPN services (for example) and access connections in various regions.  The fact that most early service composition thinking came from OSS/BSS providers and CIOs is likely due to this; the technical provisioning was less an issue than order coordination.

Virtualization messed things up because it created two levels of elasticity.  First, the relationship between features and network resources changed from being static (purpose-built devices) to dynamic (hosted).  Second, the feature composition of services also became elastic.  We can see both these levels of dynamism in virtualization today—you have “functions” that have to be assembled into services, but for those services to work, each function has to be hosted somewhere.  Virtualization, then, mandates explicit service composition.  Most probably agree with that; the issue is in what kind and how much.

At the “light touch” end of the spectrum of possibilities is the administration-centric view.  This is an evolution from the OSS/BSS TMF approach, one that focuses on the idea of assembling functionally complete elements but leaving the implementation of each up to the operator/administrator that owns them.  You can visualize the implementation as being a combination of commanding networks to do something, much as they would do it today, and instantiating software features on servers.

The opposite pole is the “complete composition” approach.  Here, the assumption is that composition actually builds a functioning service by building every feature, hosting it as necessary, and making internal and to-the-user connections in a fairly explicit way.  Services still require features/functions, but the process of including them and hosting them on something are blurred into different faces of the same coin.

There are a lot of differences between these polar approaches, but they tend to be rather subtle and many depend on just how the composition process (and the underlying resources and overarching services) are structured.  Let me give a single example to illustrate the issues, and I’m sure you can work out others on your own.

Where services are modeled at a low level of granularity—the light-touch approach—it’s very difficult to reflect conditions between parts of the model.  That’s because the modeling process abstracts the features/behaviors at the detail level, making it impossible to see what’s happening inside.  As the granularity of the model increases, in the complete composition approach, you have the chance to reflect conditions across the elements of the model.  That changes optimization and management.

In a light-touch scenario, the presumption is that the feature selection process divides the service by domain, meaning geography or administration.  A “service” like VPN, for example, consists of a core VPN service capability coupled with access elements, one for each endpoint.  If something breaks, the presumption is that either the function itself can self-heal (the VPN core can repair around a node or trunk fault) or there’s no healing possible without manual intervention (you can’t fix the cable-cutting backhoe problem without sending a tech to splice things).  Further, the presumption is that the elements can be managed independently.  Doing something to optimize one won’t impact the others.

The complete composition scenario relieves these presumptions.  If the entire service is built from some software-readable recipe, then the decisions made anywhere can be reflected into the decisions to be made in other places.  You can optimize both hosting and connectivity among hosting points together, because your composition recipe defines both connecting and hosting, and does it across the service overall.

Even within the two basic approaches to modeling, you still have the question of what the model looks like.  Modeling that is functionally generalized, meaning that all “access” has a common set of model properties and implementations of “access” all meet them, is key if you want to support interoperability and integration.  Intent modeling, the current favored approach, is an example of functionally generalized modeling.  Where modeling isn’t functionally generalized, you have the risk of exposing something implementation-specific in the model, which would then mean that the model structure is “brittle”.  That term means that it’s easy to break the model by making a small change at a low-level point, in implementation.  Brittle stuff means a lot of work and a lot of errors down the line, because a small technical change can mean that a lot of models and their associated services don’t work.

Even having a strong intent structure doesn’t insure you have interoperability and integration support.  Intent modeling, if it’s to be done right, means that we have to first define our functions to support functional generalization.  We need a kind of model class library that says that “access” is a high-level model that can represent “roaming-enabled access” or “tethered access”, for example, or that “function-hosting” can mean “VM” or “container” subclasses.  With this kind of approach, we can apply intent modeling without having our non-brittle goals stymied by inconsistent definitions and integration.  If Vendor A defines a “my-access-strategy” model, for example, what’s the likelihood that Vendor B will adopt the same approach?

A final point in modeling is just what you’re expecting the model to drive.  Do you want to model a “service lifecycle” for the purposes of automating it?  If so, then you are accepting the notion that service conditions can arise and can be detected at the service level.  While we surely have example of that, the broad trend in the industry since the replacement of TDM services by packet services has been to manage resources at the resource level and remediate based on resource reconfiguration and substitution.  The presumption is that resources are inherently multi-tenant, so individual per-service remediation isn’t practical.

All of this circles back to that original light-versus-full-composition division.  We tend to see network connection services modeled at a light-touch level because we build connection services largely by coercing naturally cooperative device communities to do something.  The question we have yet to answer in our modeling debates is whether the cloud-like virtualization additions we now contemplate will follow that same model—whether a pool of servers augment a pool of functions that augment or replace a pool of devices.

I think the question of “intent” is critical in modeling for more reasons than the classic one.  What do we intend service lifecycle management to be, to mean?  If systems of hosting elements, functions, and connections are to assemble self-managing service elements that are then composed into services, we have one level of problem.  If we want to have greater granularity of composition and control to allow for per-service lifecycle management, we’ll have to model differently.  Now’s the time to think about this, because we are clearly coming to a point where our lack of a modeling strategy will either limit virtualization’s impact, or force operators and vendors to latch onto something—which might or might not fit the long-term needs of the industry.