Towards declarative intent processing and conflict resolution in IBN

Intent-based networking aims at achieving automated network management by allowing users to express desired outcomes rather than manually configure network resources. In this poster paper, by means of an example, we illustrate our proposal for a declarative and vendor-agnostic methodology to perform intent processing and translation, including static conflict detection and resolution between intents, by leveraging logic programming to determine feasible placements of Virtual Network Function chains. We conclude by pointing out lines for future work.


INTRODUCTION
Intent-based networks (IBNs) are expected to ingest user-specified high-level goals (viz.intents) and autonomically adapt to achieve those goals with no need for human intervention [3].Thus, intents must be suitably modelled and translated into target network objects and configurations, finally deployed to the infrastructure through a multi-tier orchestration and control platform.Last, the network state is monitored and acted upon to guarantee that specified intents are continuously fulfilled [5].
Ideally, such autonomic intent processing should meet some desirable properties [6].Among these, it should: P1 be declarative, to ease focussing on what the intent aims at achieving rather than how, P2 exploit vendor-agnostic specifications to abstract intent declarations from technical network details, P3 detect & resolve conflicts that can arise among different intents specified over the same network.In our previous work [1], we have proposed a declarative methodology and the associated open-source Prolog prototype 1 , DIPS, which (i) models IBN intents that can be fulfilled through the provisioning of Virtual Network Function (VNF) chains, and (ii) processes those intents to assemble and place a VNF chain that fulfils them.Apropos, chained virtual network functions are a natural candidate to fulfil intents as they provide a way to compose and offer network services with specified performance to final users.Relying on a Prolog specification for intent modelling and translation, DIPS is declarative (i.e. it meets P1) and vendor-agnostic (i.e. it meets P2).Nevertheless, the version of DIPS described in [1] does not handle conflict detection and resolution (needed to meet P3).
Handling conflicts, however, is a crucial part of intent processing [2].Consider a simple scenario with only two leading stakeholder roles, namely the IBN infrastructure provider -offering an IBN network -and the application operator -expressing intents over applications to be deployed.Conflicts may arise within a single intent of one specific stakeholder (i.e.intra-intent conflict) or between different intents from the same or distinct stakeholders (i.e.inter-intent conflict).Besides, they can arise at compile-time (i.e.static) and at run-time (i.e.dynamic).This scenario calls for conflict detection and resolution mechanisms and the possibility of declaring ad-hoc mediation policies for different intent properties.
To the best of our knowledge, only a few works pursued such a research line.Very recently, Sharma et al. [2] describe the architecture of a framework for intent provisioning that reconciles conflicts by composing intents through suitable arithmetic functions (e.g.average).Regarding specific types of intents, Zheng et al. [7] propose a procedural conflict detection algorithm that compares new intents with existing intents in the system.Conflicts are possibly solved by gradually and repeatedly modifying conflicting intents.Last, Comer and Rastegarnia [8] propose a set of resolution strategies targeting only conflicts in forwarding rules in software-defined networks.
In this work, through the help of examples and focussing on VNF chains, we describe the high-level functioning of an extension of our DIPS framework 2 to perform declarative intent processing with static conflict detection and resolution (Sect.2).We present some simple resolution policies (Sect.3), and conclude by identifying some immediate next steps (Sect.4).

MOTIVATING EXAMPLE
Consider a scenario where an application operator AppOp wants to deploy a high-throughput streaming service over an infrastructure managed by an infrastructure provider InfraOp.The AppOp expresses some intents by specifying requirements such as low latency, high bandwidth, redundancy for its streaming service and expected properties, like caching and encoding/decoding of its multimedia contents.Besides accommodating the application operator's needs by deploying suitable VNF chains, InfraOp can express overall goals and objectives (i.e.global expectations) such as optimising resource utilisation or ensuring energy efficiency across its data centres.The challenge lies in reconciling these intent-driven requirements with the infrastructure provider's general objectives while delivering a reliable and efficient streaming service to end-users.
Intents I1 and I2 are expressed by AppOp and InfraOp, respectively: (I1) Provision a streamingService featuring MP4 encode/decode capabilities.Data must be stored on a dedicated node to guarantee suitable performance.Besides, the service should be deployed in such a way it features an end-to-end bandwidth of at least 40 Mbps.Finally, encoding must take place where data is stored.
(I2) To avoid network congestion, limit end-to-end bandwidth of placed VNF chains to 25 Mbps.
Clearly, these intents feature some conflicts: (C1) I1 requires a node to be both dedicated and shared between two services, so the encoding service cannot be performed on the same node where the data is stored, as this requirement would violate the request to have a dedicated node for storage.
(C2) I1 optionally requires a higher minimum end-to-end bandwidth than I2 allows, so meeting the 40 Mbps requirement of I1 would violate the 25 Mbps limit set by I2.
Both conflicts can be detected statically since we do not need to assess the infrastructure and application status after implementing the intent (i.e.placing the VNFs chain) to capture them.Moreover, C1 is an intra-intent conflict since it involves different properties of the same intent.Instead, C2 involves both intents, so we classify it as an inter-intent conflict.

HANDLING CONFLICTS IN IBN LANDSCAPES
To show the behaviour of the proposed methodology, we refer to the motivating example described in Section 2. The whole procedure is depicted in Fig. 1, and starts with the intent modelling), which takes as input the set of expected properties to complete the initial chain associated with the AppOp intent.The output of this stage is a chain with two newly added services responsible for suitably encoding and decoding stored data before streaming them.
The next phase (i.e.conflict detection) is implemented via Prolog predicates3 that declaratively define when two intents conflict.For instance, two properties of the same intent involving the same VNF may collide if their boundaries conflict (e.g.> and <, or dedicated and same node).The solution also considers the properties' levels (i.e.hard/soft), prioritising the highest ones: (C1) Because both criteria are hard, the tool stops processing the request and returns control to the user, who must alter the requirements to allow for shared node usage or restrict to dedicated use while meeting the performance and resource constraints.(C2) Between the two conflicting properties, the bandwidth required by the AppOp is optional, unlike the limit imposed by the InfraOp, which is mandatory to use infrastructure resources.The first property can then be ignored, so it is removed.
The last step (intent translation) retrieves an eligible placement for each VNF of the chain on the provided infrastructure.

CONCLUDING REMARKS
In this work, we showed how we can support intent modelling, conflict detection and resolution, and the subsequent translation of intents related to VNF service provisioning.We complete the initial VNF chain structure by inserting VNFs that satisfy desired properties and offer a set of solutions (when possible) to detect conflicts, w.r.t the kind of conflicting properties.The output is a set of candidate solutions that either fully or partially (due to lack of resources) fulfil the intent, thus supporting either the autonomous decision of the intent handler or negotiation mechanisms.
We plan to extend our work and Prolog prototype towards closedloop management by: (i) enhancing the intent model for identifying and solving other types of conflicts (e.g.dynamic); (ii) implementing more complex conflict resolution/mediation policies, which consider priorities/hierarchies/relations over properties; (iii) implementing and assessing incremental analysis of the current intent fulfilment to efficiently decide on intent assurance actions (e.g. via continuous reasoning [4]); (iv) integrating our work with activation and assurance functionalities of an actual NFV Management and Orchestration stack, to assess our proposal in testbed settings.