| RFC 9316 | Intent Classification | October 2022 |
| Li, et al. | Informational | [Page] |
Intent is an abstract, high-level policy used to operate a network. An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle.¶
This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development.¶
This document is a product of the IRTF Network Management Research Group (NMRG).¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Network Management Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9316.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The vision of intent-based networks has attracted a lot of attention because it promises to simplify the management of networks by human operators. This is done by simply specifying what should happen on the network without giving any instructions on how to do it. This promise caused many researcher-led activities and telecom companies to start researching this new vision and many Standards Development Organizations (SDOs) to propose different intent frameworks.¶
This document proposes an intent classification methodology and an intent taxonomy. The scope of these proposals is to ensure a common understanding in the research community in terms of what the intent users, intent types, or intent solutions, etc., are for specific scenarios that are being considered.¶
The document represents the consensus of the Network Management Research Group (NMRG). It has been reviewed extensively by the Research Group (RG) members who are actively involved in the research and development of the technology covered by this document. It is not an IETF product and is not a standard.¶
Intent-based networking is an active research topic spanning across different areas that could benefit from an intent classification and taxonomy.¶
Some examples include:¶
Furthermore, this document is already proving to be extremely relevant to the research community as it has been used as the basis for proposing self-generated Intent-based systems [Bezahaf19], for advancing Virtual Network Function (VNF) placement solutions based on Internet-Based Networks (IBNs) that rely on defining user intent profiles corresponding to abstract network services [Leivadeas21], for improving existing solutions in provisioning intent-based networks, for proposing new approaches to service management [Davoli21], and even for defining grammars for users to specify the high-level requirements for blockchain selection in the form of intent [Padovan20]. As well, the document has been mentioned in surveys addressing the topic of intelligent intent-based autonomous networks [Mehmood21] [Szilagyi21].¶
This document also describes an example on how this proposal has been successfully applied in an academic environment [POC-IBN] by researchers in the area of Software-Defined Networking / Network Function Virtualization (SDN/NFV) for defining the scope of their project. The specific problem addressed by researchers is how to apply intent concepts at different levels that correspond to different stakeholders.¶
The IEEE Communications Society Technical Committee on Network Operation and Management (IEEE-CNOM), IRTF Network Management Research Group, and IFIP WG6.6 have developed a taxonomy for network and service management [IFIP-NSM] that is used by the research community in network management and operations to structure the research area through a well-defined set of keywords and to improve quality of reviews in submissions to journals, conferences, and workshops. The proposed intent taxonomy may be contributed as an extension to this taxonomy for intent-driven management.¶
Several SDOs and open-source projects, such as the IRTF NMRG, Open Networking Foundation (ONF) [ONF] / Open Network Operating System (ONOS) [ONOS], European Telecommunications Standards Institute (ETSI) / Experiential Networked Intelligence (ENI), and TMF with its autonomous networks, have proposed intents for defining a set of network operations to execute in a declarative manner.¶
More recently, the IRTF NMRG is working on "Intent-Based Networking - Concepts and Definitions" [RFC9315]. This document clarifies the concept of "Intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions.¶
The present document, together with [RFC9315], aims to become the foundation for future intent-related topic discussions regarding the NMRG.¶
The SDOs usually come up with their own way of specifying an intent and their own understanding of what an intent is. Additionally, each SDO defines a set of terms and level of abstraction, its intent users, and the applications and usage scenarios.¶
However, most intent approaches proposed by SDOs share the same features:¶
The focus of this document is on the definition of criteria enabling the categorization of intents from viewpoint of the stakeholders. Concepts and definitions related to IBN are provided in [RFC9315].¶
This document mostly addresses intents in the context of network intents; however, other types of intents are not excluded, as presented in Sections 4.4 and 6.2.¶
It is impossible to fully differentiate intents only by the common characteristics followed by concepts, terms, and intentions. This document clarifies what an intent represents for different stakeholders through a classification on various dimensions, such as solutions, intent users, and intent types. This classification ensures common understanding among all participants and is used to determine the scope and priority of individual projects, proof of concepts (PoCs), research initiatives, or open-source projects.¶
The scope of intent classification in this document includes solutions, intent users, and intent types; the initial classification table is made according to this scope. The methodology presented can be used to update the classification tables by adding or removing different solutions, intent users, or intent types to cater to future scenarios, applications, or domains.¶
A common and shared understanding of terms and definitions related to IBN is provided in [RFC9315] as follows:¶
Other definitions relevant to this document, such as intent scope, intent network scope, intent abstraction, intent abstraction, and intent life cycle are available in Section 5.¶
In order to understand the different intent requirements that would drive intent classification, we first need to understand what intent means for different intent users.¶
The term "Intent" has become very widely used in the industry for different purposes; sometimes its use is not even in agreement with SDO-shared principles mentioned in Section 1. [RFC9315] brings clarification with relation to what an intent is and how it differentiates from policies and services.¶
Different stakeholders have different perspectives of the network; therefore, they have different intent requirements. Their intent is sometimes technical, non-technical, abstract, or technology specific. Therefore, it is important to start a discussion in the industry and academic communities about what intent is for different solutions and intent users. It is also imperative to try to propose some intent categories/classifications that could be understood by a wider audience. This would help us define intent interfaces, domain-specific languages, and models.¶
Intent types are defined by all aspects that are required to profile different requirements to easily distinguish between them. However, in order to facilitate a clustered classification, we can focus on two aspects: the solution and intent user. They can be considered to be the main keys to classify intents, as we can easily group requirements by solution and intent user.¶
On the one hand, different solutions and intent users have different requirements, expectations, and priorities for intent-based networking. Therefore, intent users require different intent types, depending on their context, since they participate in different use cases. For instance, some intent users are more technical and require intents that expose more technical information. Other intent users do not have knowledge of the network infrastructure and require intents that shield them from different networking concepts and technologies.¶
The following are the solutions and intent users that intent-based networking needs to support:¶
| Solutions | Intent Users |
|---|---|
| Carrier Networks | Network Operators, Service Designers / App Developers, Service Operators, Customers / Subscribers |
| DC Networks | Cloud Administrators, Underlay Network Administrators, Application Developers, Customers / Tenants |
| Enterprise Networks | Enterprise Administrators, Application Developers, End Users |
These intent solutions and intent users represent a starting point for the classification and are expendable through the methodology presented in Section 6.1.¶
Current network APIs and CLIs are too complex because they are highly integrated with the low-level concepts exposed by networks. Customers, application developers, and end users must not be required to set IP addresses, VLANs, subnets, or ports, whereas operators may still want to have both more technical and network visibility. All stakeholders would benefit from simpler interfaces, such as:¶
Operators and administrators manually troubleshoot and fix their networks and services. They instead want to:¶
Currently, intent users cannot build their own services and policies without becoming technical experts and performing manual maintenance actions. They instead want to be able to:¶
Next to the intent solutions and intent users, another way to categorize the intent is through the intent types. The following intent types and subtypes need to be supported in order to address the requirements from different solutions and intent users.¶
Customer service intent¶
Network and underlay network service intent¶
Network and underlay network intent¶
Cloud management intent¶
Cloud resource management intent¶
Strategy intent¶
Operational task intents¶
It is important to mention all of the previously mentioned types and subtypes may affect other intents. For example, operational task intent can modify many other intents. The task itself is short lived, but the modification of other intents has an impact on their life cycle, so those changes must continue to be continuously monitored and self corrected/optimized.¶
Intent can be used to operate immediately on a target (much like issuing a command) or whenever it is appropriate (e.g., in response to an event). In either case, intent has a number of behaviors that serve to further organize its purpose, as described by the following subsections.¶
The modeling of intents can be abstracted using the following three-tuple:¶
{Context, Capabilities, Constraints}¶
Metadata can be attached via strategy templates to each of the elements of the three-tuple and may be used to describe how the intent should be used and how it operates as well as prescribe any operational dependencies that must be taken into account.¶
Although different intent categories share the same abstracted intent model, each category will have its own specific context, capabilities, and constraints.¶
Expanding on the introduction in Section 4.2, intent user types represent the intent users that define and issue the intent request. Depending on the intent solutions, there are specific intent users. Examples of intent users are customers, network operators, service operators, enterprise administrators, cloud administrators, underlay network administrators, or application developers.¶
Intents are used to manage the behavior of the networks they are applied to and all intents are applied within a specific scope, such as:¶
These intent scopes are expendable through the methodology presented in Section 6.1.¶
Regardless of the intent user type, their intent request affects the network, or network components, which are representing the intent targets.¶
Thus, the intent network scope, or policy target as known in the area of declarative policy, can represent VNFs or PNFs, physical network elements, campus networks, SD-WANs, RANs, cloud edges, cloud cores, branches, etc.¶
Intent can be classified by whether it is necessary to feed back technical network information or non-technical information to the intent user after the intent is executed. As well, intent abstraction covers the level of technical details in the intent itself.¶
As per the definition of "intent" provided in [RFC9315], lower-level intents are not considered to qualify as intents. However, we kept this classification to identify any PoCs / Demos / Use Cases that still either require or implement a lower level of abstraction for intents.¶
Intents can be classified into transient and persistent intents:¶
In different phases of the autonomous driving network [TMF-AUTO], the intents are different. Depending on the Autonomous Network Level of the overall solution, we may have different intent requirements and types. For example, at lower levels, the customer intent is:¶
Typical examples of autonomous driving networks level 0 to 5 are shown below.¶
O&M personnel manually control the network and obtain network alarms and logs.¶
- No intent¶
Automated scripts are used to automate service provisioning, network deployment, and maintenance. The network provides shallow perception of the network status and decision making suggestions.¶
- No intent¶
This entails the automation of most service provisioning, network deployment, and maintenance of a comprehensive perception of network status and local machine decision-making.¶
- simple intent on service provisioning¶
This entails a deep awareness of network status and automatic network control, meeting requirements of intent users of the network.¶
- Intent based on network status cognition¶
In a limited environment, people do not need to participate in decision-making and networks can adjust themselves.¶
- Intent based on limited AI¶
In different network environments and network conditions, the network can automatically adapt and adjust to meet people's intentions.¶
- Intent based on AI¶
This section proposes an approach to intent classification that may help to classify mainstream intent-related demos/tools.¶
The three classifications in this document have been proposed from scratch (following the methodology presented) through three iterations: one for a carrier network intent solution, one for a DC intent solution, and one for an enterprise intent solution. For each intent solution, we identified the specific intent users and intent types. Then, we further identified intent scope, network scope, abstractions, and life-cycle requirements.¶
These classifications and the generated tables can be easily extended. For example, for the DC intent solution, a new category "resource scope" is identified, and the classification table has been extended accordingly.¶
In the future, as new scenarios, applications, and domains emerge, new classifications and taxonomies can be identified, following the proposed methodology.¶
The intent classifications have been documented to the best of our knowledge at the time of writing. Additional classifications will most likely come to light in the future.¶
The output of the intent classification is the intent taxonomy introduced in the subsections of this section.¶
Thus, the subsections of Section 6 introduce the proposed intent classification methodology, the consolidated intent taxonomy for three intent solutions, and the concrete examples of intent classifications for three different intent solutions (e.g., carrier network, data center, and enterprise) that were derived using the proposed methodology and can be filled in for PoCs, demos, research projects, or future documents.¶
This section describes the methodology used to derive the initial classification proposed in the document. The proposed methodology can be used to create new intent classifications from scratch by analyzing the solution knowledge. As well, the methodology can be used to update existing classification tables by adding or removing different solutions, intent users, or intent types in order to cater to future scenarios, applications, or domains.¶
+------------------------------------------+
|Solution Knowledge (requirements, |
|use cases, technologies, network, intent |
|users, intent requirements) |
+----------------+-------------------------+
| Input Rx=Read
| Ux=Update (Add/Remove)
+--------V--------+
|1.Identify Intent|
| Solution +------------+
| | |
+---------^-+-----+ |
R1 | | U1 |
+---------------+ U8 | | R2 +--v----------------+
|8.Identify New +---------+ | | +-----------> 2.Identify |
| Categories | R8 | | | | U2 | Intent |
| <-------- | | | | +---------+ User Types |
+--------^------+ | | | | | | +-------|-----------+
| | | | | | | |
| ++-+-v-v---+-v-+ |
+--------+------+ U7 | | R3 +------v------------+
|7.Identify +------> Intent +--------> 3.Identify |
| Life-Cycle | R7 |Classification| U3 | Type |
| Requirements <------+ <--------+ of Intent |
+--------^------+ +^--^-+--^-+---+ +------|------------+
| || | | | | |
| || | | | | |
+--------+-----+ || | | | | R4 +-------v-----------+
|6.Identify | U6 || | | | +-----------> 4.Identify |
| Abstractions+---------| | | | U4 | Intent |
| <---------+ | | +-------------+ Scope |
+-------^------+ R6 | | +-------+-----------+
| | | |
| U5 | |R5 |
| +-------+-v--------+ |
| |5.Identify Network| |
+----------+ Scope <---------------+
+------------------+
The intent classification workflow starts from the solution knowledge, which can provide information on requirements, use cases, technologies used, network properties, intent users that define and issue the intent request, and requirements. The following defines the steps to classify an intent:¶
The following taxonomy describes the various intent solutions, intent user types, intent types, intent scopes, network scopes, abstractions, and life cycles. The taxonomy represents the output of the intent classification tables for each of the solutions addressed (i.e., carrier, data center, and enterprise solutions).¶
The intent scope categories in Figure 2 are shared among the carrier, DC, and enterprise solutions. The abbreviations (Cx) in Sections 6.3.2 and 6.4.2 are introduced with the scope of fitting as column title in the following tables.¶
+--------------------------------+
+-->|Carrier Enterprise Data Center|
| +--------------------------------+
| +--------------------------------+
| |Customer/Subscriber/End User |
+----------+ | |Network or Service Operator |
+>+Solution +--+ |Application Developer |
| +----------+ +->|Enterprise Administrator |
| | |Cloud Administrator |
| +----------+ | |Underlay Network Administrator |
+>+Intent +---+ +--------------------------------+
| |User | +--------------------------------+
| |Type | |Customer Service Intent |
| +----------+ |Strategy Intent |
| +----------+ |Network Service Intent |
+>+Intent +----->|Underlay Network Service Intent |
+------+ | |Type | |Network Intent |
|Intent+-+ +----------+ |Underlay Network Intent |
+------+ | |Operational Task Intent |
| +----------+ |Cloud Management Intent |
+>+Intent +---+ |Cloud Resource Management Intent|
| |Scope | | +--------------------------------+
| +----------+ | +--------------------------------+
| +->|Connectivity Application QoS |
| +----------+ |Security/Privacy Storage Compute|
+>+Network +---+ +--------------------------------+
| |Scope | | +--------------------------------+
| +----------+ | |Radio Access Branch |
| +->|Transport Access SD-WAN |
| +----------+ |Transport Aggr. VNF PNF |
+>+Abstrac- +----+ |Transport Core Physical |
| |tion | | |Cloud Edge Logical |
| +----------+ | |Cloud Core Campus |
| +----------+ | +--------------------------------+
+>+Life | | +--------------------------------+
|Cycle +--+ +>|Technical Non-Technical |
+----------+ | +--------------------------------+
| +--------------------------------+
+-->|Persistent Transient |
+--------------------------------+
This section addresses steps 1, 2, and 3 from Figure 1. The following table describes the intent users in carrier solutions and intent types with their descriptions for different intent users.¶
| Intent User | Intent Type | Intent Type Description |
|---|---|---|
| Customer/Subscriber | Customer Service Intent |
Customer self service with SLA and value-added service.¶ Example: Always maintain a high quality of service and high bandwidth for gold-level subscribers.¶ Operation statement: Measure the network congestion status, give different adaptive parameters to stations of different priority; thus, in a heavy load situation, make the bandwidth of the high-priority customers guaranteed. At the same time, ensure the overall utilization of the system and improve the overall throughput of the system.¶ |
| Strategy Intent |
Customer designs models and policy intents to be used by customer service intents.¶ Example: Request reliable service during peak traffic periods for video-type apps.¶ |
|
| Network Operator | Network Service Intent |
Service provided by the network service operator to the customer (e.g., the service operator).¶ Example: Request network service with delay guarantee for access customer A.¶ |
| Network Intent |
Network operator requests network-wide (service underlay or other network-wide configuration) or network-resource configurations (switches, routers, routing, or policies). Includes connectivity, routing, QoS, security, application policies, traffic steering policies, alarm generation for non-compliance, auto-recovery, etc.¶ Example: Request high priority queuing for traffic of class A.¶ |
|
| Operational Task Intent |
Network operator requests execution of any automated task other than network service intent and network intent (e.g., network migration, server replacements, device replacements, or network software upgrades).¶ Example: Request migration of all services in network N to backup path P.¶ |
|
| Strategy Intent |
Network operator designs models, policy intents, and workflows to be used by network service intents, network intents, and operational task intents. Workflows can automate any tasks that the network operator often performs in addition to network service intents and network intents.¶ Example: Ensure the load on any link in the network is not higher than 50%.¶ |
|
| Service Operator | Customer Service Intent |
Service operator's customer orders, customer service, or SLA.¶ Example: Provide service S with guaranteed bandwidth for customer A.¶ |
| Network Service Intent |
Service operator's network orders / network SLA.¶ Example: Provide network guarantees in terms of security, low latency, and high bandwidth.¶ |
|
| Operational Task Intent |
Service operator requests execution of any automated task other than customer service intent and network service intent.¶ Example: Update service operator portal platforms and their software regularly. Move services from network operator 1 to network operator 2.¶ |
|
| Strategy Intent |
Service operator designs models, policy intents, and workflows to be used by customer service intents, network service intents, and operational task intents. Workflows can automate any task that the service operator often performs in addition to network service intents and network intents.¶ Example: Request network service guarantee to avoid network congestion during special periods such as Black Friday and Christmas.¶ |
|
| Application Developer | Customer Service Intent |
Customer service intent API provided to the application developers.¶ Example: API to request network to watch HD video (4K/8K).¶ |
| Network Service Intent |
Network service intent API provided to the application developers.¶ Example: API to request network service, monitoring, and traffic grooming.¶ |
|
| Network Intent |
Network intent API provided to the application developers.¶ Example: API to request network resource configurations.¶ |
|
| Operational Task Intent |
Operational task intent API provided to the application developers. This is for the trusted internal operator / service providers / customer DevOps.¶ Example: API to request server migrations.¶ |
|
| Strategy Intent |
Application developer designs models, policy, and workflows to be used by customer service intents, network service intents, and operational task intents. This is for the trusted internal operator / service provider / customer DevOps.¶ Example: API to design network load-balancing strategies during peak times.¶ |
This subsection addresses steps 4 to 7 from Figure 1. The following are the proposed categories:¶
This section contains an example of how the methodology described in Section 6.1 can be used in order to classify intents introduced in the "A Multi-Level Approach to IBN" PoC demonstration [POC-IBN]. This PoC is led by academics carrying out research in the area of SDN/NFV, and the specific problem they are addressing is the application of the intent concept at different levels that correspond to different stakeholders. For this research work, they considered two types of intents: slice intents and service chain intents.¶
In this PoC [POC-IBN], a slice intent expresses a request for a network slice with two types of components: a set of top-layer virtual functions and a set of virtual switches and/or routers of L2/L3 VNFs. A service chain intent expresses a request for a service operated through a chain of service components running in L4-L7 virtual functions.¶
Following the intent classification methodology described step by step in Section 6.1, the following can be derived:¶
The following table shows how to represent this information in a tabular form. The "X" in the table refers to the slice intent; the "Y" in the table refers to the service chain intent.¶
+==========+===========+===========+=====+=================+=====+=====+ |Intent |Intent Type|Intent |NF |Network |ABS |L-C | |User | |Scope |Scope|Scope | | | | | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| +==========+===========+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ |Customer/ |Customer | | | | | | | | | | | | | | | | | |Subscriber|Service | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Strategy | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |Network |Network |X | |X | |X | | | | | |X | |X | |X | | |Operator |Service | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Network | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Operational| | | | | | | | | | | | | | | | | | |Task Intent| | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Strategy | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | | |Operator |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Network | | | | | | | | | | | | | | | | | | |Service | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Op Task | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Strategy | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |App |Customer | | | | | | | | | | | | | | | | | |Developer |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Network | | | | | | | | | | | | | | | | | | |Service | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Network | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Op Task | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |Strategy | | | | | | | | | | | | | | | | | | |Intent | | | | | | | | | | | | | | | | | +----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The following table describes the intent users in DC network solutions and intent types with their descriptions for different intent users.¶
| Intent User | Intent Type | Intent Type Description |
|---|---|---|
| Customer/Tenants | Customer Service |
Customer self service via tenant portal.¶ Example: Request GPU computing and storage resources to meet 10k video surveillance services.¶ |
| Strategy Intent |
This includes models and policy intents designed by customers/tenants to be reused later during instantiation.¶ Example: Request dynamic computing and storage resources of the service in special and daily times.¶ |
|
| Cloud Administrator | Cloud Management Intent |
Configuration of VMs, DB Servers, app servers, and communication between servers and VMs.¶ Example: Request connectivity between VMs A, B, and C in network N1.¶ |
| Cloud Resource Management Intent |
Policy-driven self configuration and recovery/optimization.¶ Example: Request automatic life-cycle management of VM cloud resources.¶ |
|
| Operational Task Intent |
Cloud administrator requests execution of any automated task other than cloud management intents and cloud resource management intents.¶ Example: Request upgrade operating system to version X on all VMs in network N1.¶ Operational statement: An intent to update a system might reconfigure the system topology (connect to a service and to peers), exchange data (update the content), and uphold a certain QoE level (allocate sufficient network resources). Thus, the network carries out the necessary configuration to best serve such an intent, e.g., setting up direct connections between terminals and allocating fair shares of router queues considering other network services.¶ |
|
| Strategy Intent |
Cloud administrator designs models, policy intents, and workflows to be used by other intents. Automate any tasks that administrator often performs in addition to life cycle of cloud management intents and cloud management resource intents.¶ Example: In case of emergency, automatically migrate all cloud resources to DC2.¶ |
|
| Underlay Network Administrator | Underlay Network Service Intent |
Service created and provided by the underlay network administrator.¶ Example: Request underlay service between DC1 and DC2 with bandwidth B.¶ |
| Underlay Network Intent |
Underlay network administrator requests some DCN-wide underlay network configuration or network resource configurations.¶ Example: Establish and allocate DHCP address pool.¶ |
|
| Operational Task Intent |
Underlay network administrator requests execution of any automated task other than underlay network service and resource intent.¶ Example: Request automatic rapid detection of device failures and pre-alarm correlation.¶ |
|
| Strategy Intent |
Underlay network administrator designs models, policy intents, and workflows to be used by other intents. Automate any tasks that the administrator often performs.¶ Example: For all traffic flows that need NFV service chaining, restrict the maximum load of any VNF node/container below 50% and the maximum load of any network link below 70%.¶ |
|
| Application Developer | Cloud Management Intent |
Cloud management intent API provided to the application developers.¶ Example: API to request configuration of VMs or DB Servers.¶ |
| Cloud Resource Management Intent |
Cloud resource management intent API provided to the application developers.¶ Example: API to request automatic life-cycle management of cloud resources.¶ |
|
| Underlay Network Service Intent |
Underlay network service API provided to the application developers.¶ Example: API to request real-time monitoring of device condition.¶ |
|
| Underlay Network Intent |
Underlay network resource API provided to the application developers.¶ Example: API to request dynamic management of IPv4 address pool resources.¶ |
|
| Operational Task Intent |
Operational task intent API provided to the trusted application developer (internal DevOps).¶ Example: API to request automatic rapid detection of device failures and pre-alarm correlation.¶ |
|
| Strategy Intent |
Application developer designs models, policy intents, and building blocks to be used by other intents. This is for the trusted internal DCN DevOps.¶ Example: API to request load-balancing thresholds.¶ |
The following are the proposed categories:¶
This section depicts an example on how the methodology described in Section 6.1 can be used by the research community to classify intents. As mentioned in Section 6.3.3, a successful use of the classification proposed in this document is introduced in the PoC demonstration titled "A Multi-Level Approach to IBN" [POC-IBN]. The PoC is led by academics carrying out research in the area of SDN/NFV; the specific problem they are addressing is the application of the intent concept at different levels that correspond to different stakeholders.¶
For their research work, they considered two types of intents: slice intents and service chain intents. For the data center solution, only the slice intent is relevant.¶
As already mentioned in Section 6.3.3, a slice intent expresses a request for a network slice with two types of components: a set of top-layer virtual functions and a set of virtual switches and/or routers of L2/L3 VNFs.¶
Following the intent classification methodology described step by step in Section 6.1, we identify the following:¶
The following table shows how to represent this information in a tabular form; the "X" in the table refers to the slice intent.¶
+===========+=============+=================+=====+=====+=====+=====+ |Intent User| Intent Type |Intent |DCN |DCN |ABS |L-C | | | |Scope |Res |Net | | | | | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+ | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2| +===========+=============+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ |Customer/ | Customer | | | | | | | | | | | | | | | |Tenants | Service | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |Cloud Admin| Cloud |X | |X | | | |X | |X | |X | |X | | | | Management | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Cloud | | | | | | | | | | | | | | | | | Resource | | | | | | | | | | | | | | | | | Management | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Operational | | | | | | | | | | | | | | | | | Task Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |Underlay | Underlay | | | | | | | | | | | | | | | |Network | Network | | | | | | | | | | | | | | | |Admin | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Underlay | | | | | | | | | | | | | | | | | Network | | | | | | | | | | | | | | | | | Resource | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Operational | | | | | | | | | | | | | | | | | Task Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |App | Cloud | | | | | | | | | | | | | | | |Developer | Management | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Cloud | | | | | | | | | | | | | | | | | Resource | | | | | | | | | | | | | | | | | Management | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Underlay | | | | | | | | | | | | | | | | | Network | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Underlay | | | | | | | | | | | | | | | | | Network | | | | | | | | | | | | | | | | | Resource | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Operational | | | | | | | | | | | | | | | | | Task Intent | | | | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | | | +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The following table describes the intent users in enterprise solutions and their intent types.¶
| Intent User | Intent Type | Intent Type Description |
| End User | Customer Service Intent |
Enterprise end user self service or applications; enterprise may have multiple types of end users.¶ Example: Request access to VPN service. Request video conference between end user A and B.¶ |
| Strategy Intent |
This includes models and policy intents designed by end users to be used by end-user intents and their applications.¶ Example: Create a video conference type for a weekly meeting.¶ |
|
| Enterprise Administrator (internal or MSP) | Network Service Intent |
Service provided by the administrator to the end users and their applications.¶ Example: For any end user of application X, the arrival of hologram objects of all the remote tele-presenters should be synchronized within 50 ms to reach the destination viewer for each conversation session. Create management VPN connectivity for type of service A.¶ Operational statement: The job of the network layer is to ensure that the delay is between 50-70 ms through the routing algorithm. At the same time, the node resources need to meet the bandwidth requirements of 4K video conferences.¶ |
| Network Intent |
Administrator requires network-wide configuration (e.g., underlay or campus) or resource configuration (switches, routers, or policies).¶ Example: Configure switches in campus network 1 to prioritize traffic of type A. Configure YouTube as business non-relevant.¶ |
|
| Operational Task Intent |
Administrator requests execution of any automated task other than network service intents and network intents.¶ Example: Request network security automated tasks such as web filtering and DDoS cloud protection.¶ |
|
| Strategy Intent |
Administrator designs models, policy intents, and workflows to be used by other intents. Automate any tasks that the administrator often performs.¶ Example: In case of emergency, automatically shift all traffic of type A through network N.¶ |
|
| Application Developer | End-User Intent |
End-user service / application intent API provided to the application developers.¶ Example: API for request to open a VPN service.¶ |
| Network Service Intent |
Network service API provided to application developers.¶ Example: API for request network bandwidth and latency for hosting a video conference.¶ |
|
| Network Intent |
Network API provided to application developers.¶ Example: API for requesting network device configuration.¶ |
|
| Operational Task Intent |
Operational task intent API provided to the trusted application developer (internal DevOps).¶ Example: API for requesting automatic monitoring and interception for network security.¶ |
|
| Strategy Intent |
Application developer designs models, policy intents, and building blocks to be used by other intents. This is for the trusted internal DevOps.¶ Example: API for strategy intent in case of emergencies.¶ |
The following are the proposed categories:¶
The following is the intent classification table example for enterprise solutions.¶
+---------------+-------------+-----------+--------+-----+-----+ | Intent User | Intent Type | Intent | Net | ABS | L-C | | | | Scope | | | | | | +-----------+--------+-----+-----+ | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2| +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | End User | Customer | | | | | | | | | | | | | | Service | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | Intent | | | | | | | | | | | | +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | Enterprise | Network | | | | | | | | | | | | | Administrator | Service | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Network | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Operational | | | | | | | | | | | | | | Task | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | Intent | | | | | | | | | | | | +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ | Application | End-User | | | | | | | | | | | | | Developer | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Network | | | | | | | | | | | | | | Service | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Network | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Operational | | | | | | | | | | | | | | Task | | | | | | | | | | | | | | Intent | | | | | | | | | | | | | +-------------+--+--+--+--+--+--+--+--+--+--+--+ | | Strategy | | | | | | | | | | | | | | Intent | | | | | | | | | | | | +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
This document is aligned with the RG objectives and supports investigations into intent-based networking by proposing an intent categorization methodology and taxonomy. It brings clarification to what an intent represents for different stakeholders through the proposal of an intent classification approach, ensuring that a common understanding among all the participants exists. This, together with the proposed intent taxonomy provides a solid foundation for future intent-related discussions within the NMRG.¶
The benefits of this intent classification document in the research community have been demonstrated through a PoC implementation [POC-IBN] in which the document's concepts have been applied at different levels corresponding to different stakeholders.¶
This document identifies security and privacy as categories of the intent scope. The intents could be solely security intents and privacy intents, or security can be embedded in the intents that include also connectivity, application, and QoS scope.¶
Security and privacy scope is when the intent specifies the security characteristics of the network, customers, or end users, and privacy for customers and end users.¶
More details of these security intents will be described in future documents that specify architecture, functionality, user intents, and models. An analysis of the security considerations of the overall intent-based system is provided in Section 9 of [RFC9315].¶
This document has no IANA actions.¶
This document has benefited from reviews, suggestions, comments, and proposed text provided by the following members listed in alphabetical order: Mehdi Bezahaf, Brian E. Carpenter, Laurent Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, and Jeff Tantsura.¶
We thank Barbara Martini, Walter Cerroni, Molka Gharbaoui, and Davide Borsatti for contributing with their "A multi-level approach to IBN" PoC demonstration, a first attempt to adopt the intent classification methodology.¶
The following people all contributed to creating this document:¶
Contributed significant text:¶
Contributed text in early draft versions of this document:¶