WO2022267070A1

WO2022267070A1 - Devices and methods for supporting intent driven networking

Info

Publication number: WO2022267070A1
Application number: PCT/CN2021/102575
Authority: WO
Inventors: Vincenzo Mario Riccobene; Olga HAVEL; Eduardo BARBOSA
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-06-26
Filing date: 2021-06-26
Publication date: 2022-12-29
Also published as: EP4140123A1; EP4140123A4

Abstract

The present disclosure relates to a device for supporting Intent Driven Networking (IDN). The device may obtain an input database comprising a plurality of intent instances, and may further determine the plurality of intent instances based on an analysis of the input database. Furthermore, the device may obtain an output database based on the plurality of intent instances and hierarchical information of the input database.

Description

DEVICES AND METHODS FOR SUPPORTING INTENT DRIVEN NETWORKING

TECHNICAL FIELD

The present disclosure relates generally to the field of Intent Driven Networking (IDN) , and, more particularly, to a device and a method for supporting IDN. For example, the present disclosure may further relate to an IDN system and, in more detail, to its application to brownfield scenarios, wherein a pre-existing configuration exists on the network and an IDN system is starting to manage the network.

BACKGROUND

Generally, IDN may ensure that a communication network remains in an intended state or follows an intended behavior, for instance, as described by a so-called intent provided by an application or the like. For instance, IDN may provide an intended network configuration to the communication network. To this end, IDN may include analyzing the performance of the communication network, or optimizing a configuration of the communication network.

Conventional devices and methods for IDN may perform intent grouping (grouping similar intents) , and typically operate in an unsupervised approach. These devices and methods can automatically identify patterns in an overall distribution of intent attributes, for example, hierarchical key-value pairs. Furthermore, the conventional devices and methods may determine an optimal distribution of the intent attributes, and may further split the distributed intent attributes into the intent groups.

Moreover, a conventional device and method may perform a clustering algorithm that deals with structured data. This conventional device identifies clusters in an input database, thus capturing pattern similarity among intents (particularly intent instances or objects) . The conventional device converts the input database into an output database by creating one set of Linked Lists for each intent attribute of an intent instance (e.g., an action, additional data, or a category associated with the intent instance) that needs to be taken into account for the clustering. However, an issue of such conventional device is that it works for a smaller number of intent attributes, but with a higher number of intent attributes the performance of the system degrades.

A conventional device and method is suggested for clustering documents based on a presence of specific words in the documents. However, an issue of such conventional devices and methods is their scalability and proper management of semantic meaning in a database.

SUMMARY

In view of the above-mentioned problems and disadvantages, embodiments of the present disclosure aim to provide an improved device and method for supporting IDN.

An objective is to provide an improved device and a method to support IDN, for example, the device and the method of the present disclosure may support IDN using semi-structured data. The device and method should enable scalability and a proper management of semantic meanings in a database

The objective is achieved by the embodiments of the disclosure as described in the enclosed independent claims. Advantageous implementations of the embodiments of the disclosure are further defined in the dependent claims.

A first aspect of the present disclosure provides a device for supporting Intent Driven Networking (IDN) , the device being configured to obtain an input database comprising a plurality of intent instances, determine the plurality of intent instances based on an analysis of the input database, and obtain an output database based on the plurality of intent instances and hierarchical information of the input database.

The device may be, or may be incorporated in, an electronic device such as a personal computer, a server computer, a client computer, a laptop and a notebook computer, a tablet device, a mobile phone, a smart phone, etc.

The IDN may be used for network management, wherein the input is given by the intent (i.e., a description of a desired network behavior) instead of configuration steps.

The device of the first aspect may overcome the scalability issue and proper management of semantic meaning issues mentioned above. Accordingly, the device of the first aspect is an improved device for supporting IDN. For example, the device may support IDN using semi-structured database.

The device may obtain the input database which may be based on any kind of data. For example, the input database may be a structured database, a semi-structured database, etc. Moreover, the content of the input database may be known content, unknown content, etc., without limiting the present disclosure.

For instance, the input database may be based on a JSON (JavaScript Object Notation (JSON) structure for which the content is not known in advance) , without limiting the present disclosure to this specific type of input database.

The input database comprises the plurality of input instances. The intent instances may be or may comprise an entire set of configuration instructions, which can also span across multiple network elements and/or network controllers. For example, the intent instances may be related to a specific network management intention (e.g., for creating a tunnel between two sites) . Moreover, when the IDN Orchestrator starts managing the network, some intent instances are already configured on the network.

An instance of a desired network behavior may be a Virtual Private Network (VPN) tunnel. In some embodiments, the intent instance may also include the full set of configuration items (referred to as intent nodes) that may be necessary to realize the intent on the network.

Furthermore, the hierarchical information of the input database may be the relationship between different intent instances, and/or between intent nodes, and/or between node attributes (intent attributes) , and/or between values of node attributes, etc. Furthermore, an overall structure of an intent instance may be hierarchical, which means that all the intent nodes that are part of an intent instance are organized in a hierarchy of dependencies. For example, an intent instance may comprise an intent node which may be a network configuration item. For instance, an intent node may refer to one configuration item, e.g., an intent node could include all the configuration parameters for a network interface, or for a specific protocol on a device. Moreover, an intent node may comprise a node attribute which may be a property of a network. Moreover, a node attribute may have a value and thus, the intent instance, intent node, node attribute and the value of the node attribute may have hierarchical relationship.

Furthermore, the device of the first aspect may obtain the input database which is, for example, a semi structured database. The input database may comprise the plurality of the input instances. Moreover, the device may analyze the input database, for example, the device may extract the intent instances and may further group those (pre-existing) intent instances into categories, e.g., based on intent similarity. For instance, the device may categorize or group the input instances according to how similar those instances are among themselves.

Moreover, the device may further generate a skeleton. The skeleton may be a category representation for each category of input instances.

In some embodiments, the device may further convert the skeleton to a template for uploading to IDN Orchestrator.

In some embodiments, the device may be or may be implemented in an entity that is part of a broader set of components which form a system called “Intent Restoration” (IR) . For instance, the IR may be a system that reads the pre-existing network configuration instructions, e.g., directly from network devices and or controllers, and splits them into different “intent instances” . The intent instances may be represented in hierarchical key-value elements using the input database. The device may obtain the input database and may determine the input instances.

The IR or restoration pipeline may discover a real network configuration and may convert it into one or more intent instances. For example, collecting a set of configuration items under the intent for creating a Virtual Private Network (VPN) tunnel between two end points.

The device of the first aspect may perform an intent grouping by grouping the different intent instances into categories. The device may use an unsupervised clustering approach. For example, since the intent instances (input to Intent Grouping) are produced in a semi-structured format (e.g., JSON format) , a clustering algorithm for semi-structured data may be used. For example, the intent instances may be grouped according to the presence or absence of node attributes and the value of the node attributes. The more similar the intent instances are, the more likely they should be in the same category.

For example, by using the unsupervised approach, the device may automatically identify patterns in the overall distribution of the node attributes such as the hierarchical key-value pairs and may further determine the optimal split into node groups.

The device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

In an implementation form of the first aspect, the plurality of intent instances indicating one or more intent nodes, and wherein the analysis comprises extracting at least one intent node from the input database, for each intent instance from the plurality of intent instances.

For example, each of instances may include the one or more intent nodes. Moreover, the device may extract from the input database, at least one intent node for each intent instance.

For example, the intent node may be a network configuration item, a configuration element, etc. For instance, an intent node may include all the configuration parameters for a network interface, or for a specific protocol on a device. . Hereinafter the terms “intent node” and “configuration item” and “configuration element” are used interchangeably, without limiting the present disclosure.

In a further implementation form of the first aspect, each intent node indicates one or more node attributes, and wherein the analysis further comprises extracting, for the intent node, at least one node attribute from the input database.

For example, each intent node may include the one or more node attributes. A node attribute may be, for example, a type of an intent node, a property of an intent node, a location of an intent node in a network, a task of an intent node in a network, etc. Moreover, each node attribute has a value. Further, the device may analyze the input database, and may further extract the at least one node attribute of the intent node.

The node attribute may be an attribute within an intent node, which may refer to a specific configuration property of the node. For example, the attribute “Internet Protocol (IP) Address” of the intent node “Interface” .

In a further implementation form of the first aspect, the analysis further comprises obtaining a node attribute value for the at least one node attribute.

For example, the node attribute value may be a value assigned to a node attribute. For example, the Interface having an IP Address equal to “10.1.1.1” .

In a further implementation form of the first aspect, the device is further configured to obtain a flattened node attribute by refining the node attribute based on the hierarchical information of the input database.

For example, a node attribute may be represented by one or more relationships in the input database, which may be an unstructured database. Moreover, the flattening may comprise structuring the node attribute in such a way that the information representing the node attribute is stored in a flatten structure such as a row, a table, etc.

For instance, semi-structured data, such as data in JSON format, can be hierarchical, as follows:

Example of hierarchical data:

{

“Param1” : {

“Param2: {

“Param3” : “Value1”

}

Moreover, the device may flatten the hierarchical data, for example, in order for the clustering to be able to process that type of data.

Moreover, the device may refine the above hierarchical data, and may obtain the flattened data as follow:

Param1. Param2. Param3 = Value1

In a further implementation form of the first aspect, the device is further configured to receive one or more rules and/or one or more filters, and process the flattened node attribute based on the one or more rules and/or the one or more filters.

In a further implementation form of the first aspect, the processing comprises selecting the flattened node attribute.

In a further implementation form of the first aspect, the processing comprises discarding the flattened node attribute.

In a further implementation form of the first aspect, the output database is obtained further by encoding at least one of the intent instance, the intent node, the node attribute, and the node attribute value.

In a further implementation form of the first aspect, the encoding comprises obtaining a binary value for at least one combination of the intent instance, the intent node, the node attribute, and the node attribute value.

For instance, the device may obtain the binary value of 1 for the above example of the flattened data (i.e., Param1. Param2. Param3 = Value1) , as follows:

Param1. Param2. Param3-Value1 = 1

In a further implementation form of the first aspect, the binary value being 1 indicates a presence of a corresponding intent instance, intent node, node attribute and node attribute value in the input database, and wherein the binary value being 0 indicates an absence of a corresponding intent instance, intent node, node attribute and node attribute value in the input database.

In a further implementation form of the first aspect, the device is further configured to classify the plurality of intent nodes into one or more node categories, and/or classify the plurality of intent instances into one or more intent categories.

In a further implementation form of the first aspect, the device is further configured to generate a skeleton for at least one intent category from the one or more intent categories based on the output database.

For example, the skeleton may be the category representation for the category of input instances. The skeleton of the input instances may provide a description that provides common elements across all the intents within the same category. Moreover, the skeleton of the input instances may provide a description to the IDN orchestration system describing the type of intent for each instance, etc.

For example, in some embodiments, there is no pre-defined set of categories. The device may consider the overall set of intent instances and intent nodes and, based on how similar or different they are, it may split them into categories.

In a further implementation form of the first aspect, the device is further configured to convert the generated skeleton for the at least one intent category into an IDN template of the at least one intent category, and provide the IDN template of the at least one intent category to an IDN orchestration system.

The skeleton may be a piece of information in a structured format (e.g., JSON) that may represent the structure of all the intent instances, which have been classified to be part of a category.

Moreover, the template may be a predefined template that the IDN system can receive, which technically describes how to translate the intent itself into a set of configuration items on the network devices. The template may enable a deployment of the intents on the network (e.g., VPN tunnel) , e.g., without worrying about the actual configuration that will need to go into the network devices.

For example, in a brown-field scenario, in which the network already has some configuration and the IDN is added afterwards, it may be desired that the IDN system becomes aware of the legacy network configuration. For example, the device may group all the existing configurations into intent instances, and then for each intent instance, it may further create a skeleton.

Moreover, the device may generate a template based on the skeleton, so that the IDN system may obtain and control the legacy configuration.

For example, the device may provide the IDN template. For example, the IDN template may be uploaded to the IDN Orchestrator, enabling it to manage also the pre-existing configuration.

A second aspect of the disclosure provides a method for supporting IDN, the method comprising obtaining an input database comprising a plurality of intent instances, determining the plurality of intent instances based on an analysis of the input database, and obtaining an output database based on the plurality of intent instances and hierarchical information of the input database.

In an implementation form of the second aspect, the plurality of intent instances indicating one or more intent nodes, and wherein the method further comprises extracting at least one intent node from the input database, for each intent instance from the plurality of intent instances.

In a further implementation form of the second aspect, each intent node indicates one or more node attributes, and wherein the method further comprises extracting, for the intent node, at least one node attribute from the input database.

In a further implementation form of the second aspect, the method further obtaining a node attribute value for the at least one node attribute.

In a further implementation form of the second aspect, the method further comprises obtaining a flattened node attribute by refining the node attribute based on the hierarchical information of the input database.

In a further implementation form of the second aspect, the method further comprises receiving one or more rules and/or one or more filters, and processing the flattened node attribute based on the one or more rules and/or the one or more filters.

In a further implementation form of the second aspect, the processing comprises selecting the flattened node attribute.

In a further implementation form of the second aspect, the processing comprises discarding the flattened node attribute.

In a further implementation form of the second aspect, the method further comprises obtaining the output database by encoding at least one of the intent instance, the intent node, the node attribute, and the node attribute value.

In a further implementation form of the second aspect, the method further comprises obtaining a binary value for at least one combination of the intent instance, the intent node, the node attribute, and the node attribute value.

In a further implementation form of the second aspect, the binary value being 1 indicates a presence of a corresponding intent instance, intent node, node attribute and node attribute value in the input database, and wherein the binary value being 0 indicates an absence of a corresponding intent instance, intent node, node attribute and node attribute value in the input database.

In a further implementation form of the second aspect, the method further comprises classifying the plurality of intent nodes into one or more node categories, and/or classifying the plurality of intent instances into one or more intent categories.

In a further implementation form of the second aspect, the method further comprises generating a skeleton for at least one intent category from the one or more intent categories based on the output database.

In a further implementation form of the second aspect, the method further comprises converting the generated skeleton for the at least one intent category into an IDN template of the at least one intent category, and providing the IDN template of the at least one intent category to an IDN orchestration system.

The method of the third aspect achieves the advantages and effects described for the transmitter device of the first aspect.

A third aspect of the present disclosure provides a computer program comprising a program code for performing the method according to the second aspect or any of its implementation forms.

A fourth aspect of the present disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to the second aspect or any of its implementation forms to be performed.

It has to be noted that the devices, elements, units and means described in the present application could be implemented in software or hardware elements or any kind of combination thereof. The steps which are performed by the various entities described in the present application, as well as the functionalities described to be performed by the various entities, are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 depicts a schematic view of a device for supporting IDN, according to an embodiment of the disclosure;

FIG. 2 depicts a flowchart of a method for intent restoration, according to an embodiment of the disclosure;

FIG. 3 depicts a flowchart of a method for intent grouping, according to an embodiment of the disclosure;

FIG. 4 depicts exemplarily intent instances and intent nodes in an input database; FIG. 5 depicts an example of obtaining flattened node attribute;

FIG. 6 depicts an example of analyzing the input database for determining the plurality if input instances and node attributes;

FIG. 7 depicts an example of three different node attributes obtained from the input database;

FIG. 8 depicts an example of classifying the plurality of intent nodes into node categories;

FIG. 9 depicts a flowchart of a method for classifying the intent instances;

FIG. 10 depicts an example of generating an skeleton for an intent category; and FIG. 11 depicts a flowchart of a method for supporting IDN, according to an embodiment of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a device 100 for supporting IDN according to an embodiment of the present disclosure.

The device 100 may be an electronic device such as a computer.

The device 100 is configured to obtain an input database 110 comprising a plurality of intent instances (exemplarily, three

intent instances

111, 112, and 113 are shown) .

The input database 110 may be based on semi-structured data.

The device 100 is further configured to determine the plurality of

intent instances

111, 112, 113 based on an analysis of the input database 110.

For example, the device 100 may analyze the input database 110 and may extract the plurality of

intent instances

111, 112, 113.

The device 100 is further configured to obtain an output database 120 based on the plurality of

intent instances

111, 112, 113, and based further on hierarchical information of the input database 110.

The device 100 of FIG. 1 may solve an issue of the conventional device regarding the grouping of intent instances. For example, the device 100 may enable or support grouping of intent instances into predefined or non-predefined categories in a scalable, partially or fully semantically meaningful way.

For example, the device 100 may be configured to define a performant encoding pipeline, which may convert the input database 110 into an easy-to-store database. Moreover, the device 100 may process data, which may indicate the information related to the presence or absence of node attributes into each instance, and the values that those node attributes. Moreover, the device 100 may be configured to support the efficient and intelligent clustering of intent instances into categories, in a realistic amount of time and with a substantially high accuracy.

The device 100 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the device 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device 100 to perform, conduct or initiate the operations or methods described herein.

Reference is now made to FIG. 2, which is a flowchart of a method 200 for intent restoration.

The method 200 may be performed by the device 100 as described above. For example, the device 100 may perform the method 200 for intent grouping, which may be a component within the overall intent restoration procedure.

For example, the device 100 may perform the method 200 for intent grouping, which may be provided to fulfil the needs of a bigger system, such as an intelligent intent restoration system, which has the objective of enabling the recognition and management of legacy configuration from a new IDN Orchestration System.

At 201, the device 100 may start discovery of the network configuration items from the network 1. For example, the device 100 may obtain an overall network configuration graph.

At 202, the device 100 may determine the plurality of

intent instances

111, 112, 113.

For example, the device 100 may perform an intent identification process for identifying

intent instances

111, 112, 113 among all the network configuration items such as the network configuration graph split in intent instances.

At 203, the device 100 may classify the plurality of

intent instances

111, 112, 113 into one or more intent categories.

For example, the device 100 may perform an intent grouping procedure for clustering the

intent instances

111, 112, 113 in categories and generate a skeleton for each category.

At 204, the device 100 may convert the generated skeleton for the intent category into an IDN template.

For example, the device 100 may generate the model by converting skeleton to an IDN template and relates each instance to the template of its category.

At 205, the device 100 may provide the IDN template of the intent category to an IDN orchestration system.

For example, the device 100 may upload the templates and the instances on the IDN orchestration system.

FIG. 3 depicts a flowchart of a method 300 for intent grouping, according to an embodiment of the disclosure.

The method 300 may be performed by the device 100 as described above. For example, the device 100 may perform the method 300, which may be a multi-step algorithm for the clustering of intent instances. Two main parts of the pipeline have been designed to realize the categorization: an Encoding pipeline, which is responsible for preparing the data before the clustering, and a Clustering pipeline, which is responsible for dividing all the instances into categories.

For example, the device 100 may convert all the input JSON files into a one hot encoding table, implement a two way clustering to categorize all the intents, and create templates (skeletons) representing the common ground of each category, to be used for the upload on the IDN Orchestration System.

At 301, the device 100 may extracting, for the intent node, at least one node attribute from the input database 110, and may further obtain a node attribute value for the at least one node attribute.

For example, the device 100 may extract information from the input database (e.g., a JSON) about attributes and values.

At 302, the device 100 may obtain a flattened node attribute by refining the node attribute based on the hierarchical information 114 of the input database 110.

For example, the device 100 may flatten properties according to JSON hierarchy being the hierarchical information 114.

At 303, the device 100 may process the flattened node attribute based on the one or more rules and/or the one or more filters.

For example, the device 100 may apply pre-processing user defined rules or filters.

At 304, the device 100 may encode one or more of

intent instance

11, 112, 113, the intent node, the node attribute, and the node attribute value.

For example, the device 100 may perform an encoding of JSON nodes and properties.

At 305, the device 100 may classify the plurality of intent nodes into one or more node categories.

For example, the device 100 may cluster intent nodes (configuration items included in the JSON) .

At 306, the device 100 may classify the plurality of

intent instances

111, 112, 113 into one or more intent categories.

For example, the device 100 may cluster intent instances across all JSON structures.

At 307, the device 100 may generate a skeleton for at least one intent category from the one or more intent categories based on the output database 120.

For example, the device 100 may generate the skeleton for each intent category.

References are now made to FIG. 4 which is exemplarily intent instances and intent nodes in an input database 110.

Each intent instance may represents a group of network configuration items, where each configuration item might be either simple or complex. For instance, a configuration item might just be about one configuration line on Command Line Interface (CLI) , such as enable an interface on a network device, or something way more complex, such as an entire configuration for an Access Point (AP) for the customer site to the network.

The “Configuration Item” are exemplarily “Intent Node” . Furthermore, each intent Instance JSON is composed of one or more intent node, each of them containing attributes (key-value pairs) .

In FIG. 4, the intent instances with three nodes are shown. Note that the values shown in the figure are such as placeholders and do not show specific network information, but this is done on purpose, to stress the point that the grouping has no networking knowledge incorporated and its only scope is to be able to distinguish between different instances of JSON in a generic way.

This may be due to the system not being able to be fully aware in advance of what type of configuration will be retrieved from the network, as this needs to support multi-vendor and multi-technology scenarios.

FIG. 5 depicts an example of obtaining flattened node attribute.

The device 100 may obtain the flattened node attribute shown in FIG. 5. For instance, the device 100 may refine each hierarchical attribute (also referred to as property) such that it becomes flat.

FIG. 6 depicts an example of analyzing the input database for determining the plurality of input instances and node attributes.

At 601, the device 100 may extract information from the input database (JSON) about attributes and values. For example, each intent instance may comprise one or multiple nodes. For each intent instance and each node, the device 100 may extract all the high level attributes and may further store either on a file database, in-memory database or message bus.

At 602, the device 100 may flatten properties according to JSON hierarchy. For example, each hierarchical attribute (also referred to as property) may be refined in such a way that it becomes flat.

At 603, the device 100 may apply pre-processing of user defined rules or filters. For example, the device 100 may process some rules received from the end user (expert about the devices and the technologies involved in the process) which provides hints to the system in terms of which attributes to prioritize or discard in the following steps.

At 604, the device 100 may encode the intent nodes and properties. For example, the device 100 may convert the attributes and values of each node and each intent instance into a binary representation that expresses presence or absence of attributes and their values.

At next step, the device 100 may cluster nodes included in the input database 110 (JSON) . For example, some intent instances might have the same types of node types, but with different attributes within each node type and this can sometimes lead to errors in tracking the differences between intent instances. An example is provided in FIG. 7.

FIG. 7 depicts an example of three different node attributes obtained from the input database.

In FIG. 7, three intent instances are represented. Those intent instances have the same types of nodes (each intent instance has three nodes of Type “A” ) . Moreover, that

intent instances

2 and 3 are exactly the same, whereas Intent Instance 1 is different. The

Moreover, the differences between intent instances are made explicit. For ease of description, a clustering of the nodes of the same type is shown. The device 100 may cluster all the nodes of the same type, in this example all the nodes of Type “A” , and may obtain the node category.

The result looks like indicated by the circles in Fig. 7, where four clusters 701, 702, 703, and 704 have been identified, and instances have been assigned to each cluster. The cluster 701 comprises “attribute_1” and “attribute_2” . Furthermore, the cluster 702 comprises “attribute_2” and “attribute_3” . Furthermore, the cluster 703 comprises “attribute_3” and “attribute_4” . Moreover, the cluster 704 comprises “attribute_1” and “attribute_4” .

Afterwards, the device 100 may encode the obtained intent nodes. The results may be an adjustment of the one hot encoding, according to this result, as shown in FIG. 8. The results is shown in FIG. 8. FIG. 8 depicts an example of classifying the plurality of intent nodes into node categories.

At next the device 100 may classify the

intent instances

111, 112, 113. For example, the device 100 may cluster intent instances (across all JSONs) .

FIG. 9 depicts a flowchart of a method 900 for classifying the intent instances.

The method 300 may be performed by the device 100 as described above. For example, the device 100 may perform the method 900 for classifying the intent instances.

At 901, the device 100 may obtain the output database 120 which may be the encoded aggregated data.

At 902, the device 100 may use a technique which combines two algorithms including Multiple Correspondence Analysis (MCA) and the K-Means clustering algorithm.

At 903, the device 100 classify the

intent instances

111, 112, 113 into the intent category.

Reference is now made From FIG. 10 which depicts an example of generating a skeleton for an intent category.

For example, the device 100 may comprise a skeleton generator unit which may receive as input the results of the intent implementation graph clustering. The Clustering results and the structure of the JSON may be used to build a Skeleton for each group, which identifies if properties are mandatory or optional and which category that properties belong to.

Moreover, the device 100 may combine the results of the encoding pipeline with the grouping pipeline and analyses the attributes of all the intents belonging to each group, assigning them a category (constant, instance specific or enumeration) . Furthermore, the device 100 may create a “template” for the group that can be used by IDN systems to ingest the pre-existing instances. An example of an obtained Skelton by the device 100 is shown in FIG. 10.

For instance, the device 100 may generate a Skeleton (template) for each category, which acts as a summary of all the intent instances belonging to each category. The Skeleton represents the common ground of each category and it is used to generate the intent model that may be uploaded on the IDN Orchestration System.

FIG. 11 shows a method 1100 according to an embodiment of the disclosure for supporting IDN. The method 1100 may be carried out by the device 100, as it described above.

The method 1100 comprises a step 1101 of obtaining an input database 110 comprising a plurality of

intent instances

111, 112, 113.

The method 1100 further comprises a step 1102 of determining the plurality of

intent instances

111, 112, 113 based on an analysis of the input database 110.

The method 1100 further comprises a step 1103 of obtaining an output database 120 based on the plurality of

intent instances

111, 112, 113 and hierarchical information of the input database 110.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

A device (100) for supporting Intent Driven Networking, IDN, the device (100) being configured to:

obtain an input database (110) comprising a plurality of intent instances (11, 112, 113) ;

determine the plurality of intent instances (111, 112, 113) based on an analysis of the input database (110) ; and

obtain an output database (120) based on the plurality of intent instances (111, 112, 113) and hierarchical information of the input database (110) .
The device (100) according to claim 1, wherein:

the plurality of intent instances (111, 112, 113) indicating one or more intent nodes, and wherein the analysis comprises extracting at least one intent node from the input database, for each intent instance from the plurality of intent instances.
The device (100) according to claim 2, wherein:

each intent node indicates one or more node attributes, and wherein the analysis further comprises extracting, for the intent node, at least one node attribute from the input database (110) .
The device (100) according to claim 3, wherein:

the analysis further comprises obtaining a node attribute value for the at least one node attribute.
The device (100) according to claim 3 or 4, further configured to:

obtain a flattened node attribute by refining the node attribute based on the hierarchical information of the input database (110) .
The device (100) according to claim 5, further configured to:

receive one or more rules and/or one or more filters; and

process the flattened node attribute based on the one or more rules and/or the one or more filters.
The device (100) according to claim 6, wherein:

the processing comprises selecting the flattened node attribute.
The device (100) according to claim 6, wherein:

the processing comprises discarding the flattened node attribute.
The device (100) according to one of the claims 3 to 8, wherein:

the output database (120) is obtained further by encoding at least one of the intent instance (11, 112, 113) , the intent node, the node attribute, and the node attribute value.
The device (100) according to claim 9, wherein:

the encoding comprises obtaining a binary value for at least one combination of the intent instance (111, 112, 113) , the intent node, the node attribute, and the node attribute value.
The device (100) according to claim 10, wherein:

the binary value being 1 indicates a presence of a corresponding intent instance (111, 112, 113) , intent node, node attribute and node attribute value in the input database (110) , and wherein the binary value being 0 indicates an absence of a corresponding intent instance (111, 112, 113) , intent node, node attribute and node attribute value in the input database (110) .
The device (100) according to one of the claims 1 to 11, further configured to:

classify the plurality of intent nodes into one or more node categories; and/or

classify the plurality of intent instances (111, 112, 113) into one or more intent categories.
The device (100) according to claims 12, further configured to:

generate a skeleton for at least one intent category from the one or more intent categories based on the output database (120) .
The device (100) according to claim 13, further configured to:

convert the generated skeleton for the at least one intent category into an IDN template of the at least one intent category; and

provide the IDN template of the at least one intent category to an IDN orchestration system.
A method (1100) for supporting Intent Driven Networking, IDN, the method (1100) comprising:

obtaining (1101) an input database (110) comprising a plurality of intent instances (111, 112, 113) ;

determining (1102) the plurality of intent instances (111, 112, 113) based on an analysis of the input database (110) ; and

obtaining (1103) an output database (120) based on the plurality of intent instances (111, 112, 113) and hierarchical information of the input database (110) .
A computer program product comprising instructions, which, when the program is executed by a computer, cause the computer to carry out the steps of the method (1100) of claim 15 to be performed.