Intent NBI is a declarative paradigm for interaction between service consumers and service providers that allows consumers to specify “what” services are requested without having to be concerned about “how” those services are to be delivered.
The key to intent NBIs is the use of mappings that serve as a mechanism to translate Intent NBI requests (the “what”) expressed by consumers into forms that lower level service provider entities can understand (the “how”). Mappings may resolve aliases, addresses, etc. into terms relevant to lower-level systems.
In the ONF reference model, mappings are key-value stores accessible through APIs to interpret terms that appear in Intent NBI requests to the detailed, provider frame-of-reference terms that permit the provider to execute those requests. Mappings act as a sort of dictionary that translates terms from a language understood by the consumer into a language understood by the provider.
I believe the ONF’s reference model for Intent NBIs is spot-on. In fact, Intent NBIs should be used not just for SDN controllers but for any orchestration system managing cloud entities. However, a key-value mapping service is somewhat limiting and may not be powerful enough to accomplish true intent.
A true mapping service needs the following additional features:
- Context: no translation can be accomplished by simply mapping word from one language into words in a different language. Words need to be interpreted within a larger context in order to derive their true meaning.
- Translation of structure: Simplicity in the Intent NBI is accomplished not just by using consumer-focused terms but also by abstracting away unnecessary details that that are not relevant to the consumer. However, these details are required by the service provider in order to service the request and need to be re-introduced somehow as part of the mapping process. This means that high-level consumer-focused abstractions may need to be mapped into more complex provider abstractions. This cannot be accomplished by a simple mapping of terms, but rather requires a mapping of high-level components into lower-level structures that make up those components.
Both of these features can be accomplished by using service models in Intent NBIs. Service models are consumer-focused descriptions of services that don’t just describe desired service functionality but also provide a high-level abstract view of the components that make up the service—the service topology if you will. If Intent NBIs carried service models, they would accomplish not only the goal of simplified service requests but would also provide the necessary context for mappings and would enable mapping of service structure.
This is where TOSCA comes into play. I believe TOSCA is the ideal technology for Intent NBIs, since it has all the required features already built-in:
- TOSCA is a service modeling standard, which means it is designed to carry all the necessary context within which to manage services.
- It supports various levels of abstraction, which allow for consumer-friendly service requests.
- It has a mapping component built-in. TOSCA mappings are substitution mappings that can map each component in a service model into a more detailed service topology that makes up that component. This allows for recursive decomposition of high-level abstract service models into increasingly more detailed service descriptions.
- It can be used not just for SDN but for all layers in the cloud stack. This promotes the use of a uniform Intent paradigm for all aspects of cloud service management.
Intent NBIs are clearly the right paradigm for communication between service consumers and service providers, and TOSCA can help make them a reality not just for SDN but for all layers in the cloud stack.