Intent Models: A Framework for Intent Mapping

The main challenge for intent engines is how to map intent expressions into deployable service topologies. At first glance, this appears to be a daunting task. However, we may have developed just have enough of an understanding of intent to create a high-level mapping framework. Let’s review:

• Declarative orchestrators can either be model-driven or policy-based. Both focus on the WHAT rather than the HOW, but model-driven orchestrators focus on service topologies whereas policy-based orchestrators focus on service outcomes and behaviors.
• We’ve had the notion for a while that policies can be expressed at different levels of abstraction in a policy continuum. Declarative policies expressed in terms of business goals are referred to as intent statements. Intent engines realize services by mapping intent statements into configuration parameters of deployable software components and the resources on which these components are deployed.
• We have come to the realization that it is also possible to model services at different levels of abstraction in a model continuum. Model-driven orchestrators can realize abstract service models by translating them into deployment descriptors that define a low-level service topologies at the device/resource level.

This summary leads to a couple of important observations. First, there appears to be a natural synergy between model-driven and policy-based approaches. Recall that declarative policies are expressed as constraints on capabilities within a given context (the context-capabilities-constraints pattern). But how does one specify context, and what is the mechanism for identifying capabilities within that context? Well, it seems obvious that at a specific level of abstraction, one could define a service model that serves as context for a declarative policy at that same level of abstraction. Observable (and controllable) parameters of that model could then represent capabilities, and policy expressions would specify constraints for those capabilities within the service model context. This suggests that abstract service models and declarative policies must go hand-in-hand in order to fully specify requested service behaviors at a given level of abstraction. I propose to use the term intent model to represent the combination of an abstract service model with a declarative policy that specifies desired outcomes for the modeled service.

A second observation should be clear from the first one: the intent model pattern can be used at all levels of abstraction. At each level of abstraction, one could define an abstract service model that represents the service at that level of abstraction, and that service model could then serve as the context for the corresponding declarative policies at that same level of abstraction. This means we shouldn’t just think about a policy continuum or a model continuum, but rather about an intent model continuum that combines the two.

This then leads to the following strategy for intent mapping: rather than mapping high-level intent statements into low-level deployment descriptors in one fell swoop, intent mapping should be performed recursively. Starting with an intent model expressed at the business view level, intent engines should recursively translate intent models at a higher level of abstraction into corresponding intent models at lower levels of abstraction, traversing the intent model continuum until the mapping process results in deployable service topologies at the device view level. This recursive mapping involves:

• Mapping abstract service models at one level of abstraction into corresponding service models at the next lower level of abstraction
• Mapping constraints on capabilities of a higher-level service model into equivalent constraints on capabilities of the lower-level service model.

This now gives us a much better handle on the problem, since we can borrow from readily-available constructs in software engineering. Software architects are very familiar with the type of model mapping we just described, since they perform such mappings as a matter of course in the context of top-down software design. Proper software design starts with high-level abstractions that are then decomposed recursively into increasingly lower level concepts. Recursive decomposition is a key design pattern that is supported by many software frameworks and architectures. The ETSI NFV architecture positions VNFs as abstract entities that need to be decomposed into sub topologies of VDUs. The ONFs most recent Information Modeling work introduces a component pattern that models most entities in the networking domain as components that can be decomposed into topologies of other components. TOSCA has built-in language support for recursive decomposition using a feature called substitution mappings, which allows any node in a service topology to be ‘substituted’ with an entire service topology consisting of other nodes. It seems natural, then, to use recursive decomposition as the primary construct for mapping abstract service models into lower levels of abstraction.

Once service model mappings have been established, the problem of constraint mapping becomes a whole lot simpler. We are already used to ‘rolling-up’ low-level metrics into higher-level summary metrics, and constraint mapping is nothing more than the inverse of this ‘rolling-up’ activity. I have described previously a number of quality metrics for real-time communications that can be associated with service models at different levels of abstraction. We could go through similar exercises for other uses cases, and in fact this could result in (reusable) constraint mapping functions that can become part of a ‘toolbox’ for intent mapping engines.

I hope to see recursive decomposition of intent models be adopted as a framework to accelerate development of general-purpose intent engines.