Create Autonomous Networks with Intent-Based Closed Loops
Identify solutions through resolution
Based on the concept shown in Figure 1 and the work of the TM Forum Autonomous Network Project, we designed an autonomous network with a multi-layered architecture. Exploitation begins with the intention of expressing abstract business requirements – a profitable video service should be provided to the silver level user group, for example. This specifies the topic of a video service, the high-level preference, such as profitability, and the targeted user group as the context.
A business intent handler would receive the intent along with the business requirements. It should translate this into an intent for a service intent management function. This translation, or resolution, would include selecting eligible service plans from the built-in service definitions. They would be further contextualized by interpreting and transforming abstract requirements into more concrete objectives. Policies and applications typically implement transformation business logic. In our simple example, the customer group would imply certain locations where the service should be available. It would further translate the business requirements of the service into an expected user experience with video quality and availability goals.
An intent management function associated with service management would receive these requirements for the necessary service into an intent of the business intent manager. The primary purpose of the service intent handler would be the delivery of a service instance that fulfills that intent. A key aspect of this process would be the distribution of application and network function components across the network and cloud infrastructure. A proposed solution in the intent management loop on the service layer would describe the full topology of these artifacts.
Operator concerns, such as resource usage, energy consumption, and cost, would be factored into the policies that determine the solution. These concerns can also be expressed by an intention and constitute additional requirements for the operator.
In the process of finding solutions, the requirements for the service would then be translated into lower level requirements by component. For example, a network function would be required in a particular location with latency and bandwidth targets. This would help provide the required user experience.
Executing the service-level solution typically involves a service orchestrator that coordinates the execution of distributed actions. Some of these actions may involve sending additional intents to standalone intent-aware domains containing intent-handling functionality. In our example, we focus on intent-based management of a cloud-native function. A cognitive intention management loop such as that of FIG. 2 also coordinates the operation at this level of intention management.
The proposal agent used to determine a solution strategy is primarily concerned with identifying all atomic deployment function artifacts and allocating them in the data center. Deployment function candidates are always technology independent, but we assume that there is a direct mapping from each atomic function to some deployment artifacts that are understood by the administrative domain’s orchestrator or virtualization manager.
Deployment function candidates may contain other functional dependencies such as the existence of an operation and maintenance function. These dependencies would be resolved recursively until the process reaches a set of atomic functions that satisfies all dependencies and their connectivity requirements. The process can also involve functional decomposition, when a logical function is replaced by a set of atomic components. For example, a gateway function is decomposed into user plane and control plane components, each of which meets certain resiliency and scaling requirements.
Ultimately, the multiple layers of resolutions of a new business intent provide a service instance design that breaks down into locations (such as data centers and transport paths), deployment artifacts (represented by Helm charts, for example) and initial resource allocation with respect to bandwidth, QoS class, vCPUs, memory, storage, etc.
The solution proposals in each layer may come from a separate set of different resolvers, or one resolver may be able to provide multiple solution alternatives. In the next step of the cognitive intention management loop, the most preferential solution can be chosen by evaluation logic in each layer.
Once the service is instantiated according to the preferred solution, information becomes available that allows monitoring of the service. This means that the intent management loop becomes an assurance loop that takes corrective action if the intent requirements do not match the measured state of the system.