RFC 9316
Intent Classification
Intent Classification 🎀
Quick title-block tea ☕: this is RFC 9316, called Intent Classification, and it came out in October 2022. It's an Informational doc from the Internet Research Task Force (IRTF) stream, which isn't a standard, so it's a research vibe, not a rulebook. The ISSN is 2070-1721. The authors are C. Li (China Telecom), O. Havel, A. Olariu (Huawei Technologies), P. Martinez-Julia (NICT), J. Nobre (UFRGS), and D. Lopez (Telefonica, I+D). Nothing in the title block lists anything it obsoletes or updates. 💅
Abstract
Okay so, an intent is an abstract, high-level policy you use to run a network 🦋 An intent-based management system has an interface where users can type in their requests, plus an engine that turns those intents into actual network configuration and keeps track of their whole life cycle 🧚
This doc is mostly about network intents, but it also looks at other kinds of intent 👑 Specifically, it covers how different stakeholders see intent, how to classify and encode it, and the intent taxonomy that comes out of that. It also defines the relevant intent terms where it needs to, sets up a foundation for intent research, and makes solution development easier 🔥
This document is a product of the IRTF Network Management Research Group (NMRG) 🫶
Status of This Memo
Real talk: this doc is not an Internet Standards Track spec. It's published for informational purposes only 📚
It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be ready for deployment 🙈 This RFC reflects the consensus of the Network Management Research Group of the IRTF. Documents approved for publication by the IRSG aren't candidates for any level of Internet Standard, and you can check Section 2 of RFC 7841 for the details 💀
If you want the current status, any errata, or a way to send feedback, head to https://www.rfc-editor.org/info/rfc9316 ✨
Copyright Notice
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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🎀
Table of Contents
1. Introduction
1.1. Research Activities
1.2. Standards and Open-Source Activities
1.3. Scope
2. Abbreviations
3. Definitions
4. Abstract Intent Requirements
4.1. What is intent?
4.2. Intent Solutions and Intent Users
4.3. Benefits of Intents for Different Stakeholders
4.4. Intent Types That Need to Be Supported
5. Functional Characteristics and Behavior
5.1. Abstracting Intent Operation
5.2. Intent User Types
5.3. Intent Scope
5.4. Intent Network Scope
5.5. Intent Abstraction
5.6. Intent Life Cycle
5.7. Autonomous Driving Levels
6. Intent Classification
6.1. Intent Classification Methodology
6.2. Intent Taxonomy
6.3. Intent Classification for Carrier Solution
6.3.1. Intent Users and Intent Types
6.3.2. Intent Categories
6.3.3. Intent Classification Example
6.4. Intent Classification for Data Center Network Solutions
6.4.1. Intent Users and Intent Types
6.4.2. Intent Categories
6.4.3. Intent Classification Example
6.5. Intent Classification for Enterprise Solution
6.5.1. Intent Users and Intent Types
6.5.2. Intent Categories
7. Conclusions
8. Security Considerations
9. IANA Considerations
10. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction ✨
Intent-based networks are the main character right now 💅 Everyone's obsessed with them because they promise to make networks easier for human operators to manage. The trick is you just say what should happen on the network, and you don't have to spell out how to make it happen 🧚 That promise got lots of researchers and telecom companies excited, and it pushed a bunch of Standards Development Organizations (SDOs) to propose their own intent frameworks 🌈
This doc proposes an intent classification methodology and an intent taxonomy 🎀 The goal is to get everyone in the research community on the same page about what intent users, intent types, intent solutions, and so on actually are for the specific scenarios being looked at 🫶
The document represents the consensus of the Network Management Research Group (NMRG). It was reviewed a lot by the Research Group (RG) members who are actively doing research and development on the technology it covers. It is not an IETF product and it is not a standard 💖
1.1. Research Activities
Intent-based networking is a seriously active research topic, spanning lots of areas that could use an intent classification and taxonomy 🔥
A few examples:
- intent expression and recognition ([Bezahaf21], [Bezahaf19], [Jacobs18]). Using a common classification could keep everyone consistent about the different forms of intent expression being proposed and studied 🦋
- the orchestration of cognitive autonomous radio access networks (RANs) [Banerjee21], where intents get classified based on their content 🍓
- intent network verification [Tian19], where the authors are working on proposing a new intent language 🧚
Honestly, this document is already super relevant to the research crowd 😭 It's been used as the basis for proposing self-generated Intent-based systems [Bezahaf19], for pushing forward Virtual Network Function (VNF) placement solutions based on Internet-Based Networks (IBNs) that rely on defining user intent profiles tied to abstract network services [Leivadeas21], for improving existing solutions for provisioning intent-based networks, for proposing new approaches to service management [Davoli21], and even for defining grammars so users can state their high-level requirements for blockchain selection as an intent [Padovan20]. It's also been mentioned in surveys about intelligent intent-based autonomous networks [Mehmood21] [Szilagyi21] ✨
This document also walks through an example of how this proposal was successfully applied in an academic environment [POC-IBN]. Researchers working on Software-Defined Networking / Network Function Virtualization (SDN/NFV) used it to define the scope of their project 🎀 Their specific problem was how to apply intent concepts at different levels that match different stakeholders 👑
The IEEE Communications Society Technical Committee on Network Operation and Management (IEEE-CNOM), the IRTF Network Management Research Group, and IFIP WG6.6 have developed a taxonomy for network and service management [IFIP-NSM]. The research community uses it to structure the field with a well-defined set of keywords, and it helps make reviews of submissions to journals, conferences, and workshops better 🌸 The proposed intent taxonomy may be contributed as an extension to this taxonomy for intent-driven management 💜
1.2. Standards and Open-Source Activities
A bunch of SDOs and open-source projects have proposed intents for defining a set of network operations that run in a declarative way 🌈 Some of the big names are the IRTF NMRG, the 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 🫶
The IRTF NMRG is also working on "Intent-Based Networking - Concepts and Definitions" [RFC9315]. That doc clarifies the concept of "Intent" and gives an overview of the functionality tied to it 🦋 The goal is to build a common, shared understanding of terms, concepts, and functionality, so it can be the foundation for defining related research and engineering problems and their solutions ✨
The present document, together with [RFC9315], is meant to become the foundation for future intent-related discussions in the NMRG 🎀
SDOs usually come up with their own way of specifying an intent and their own idea of what an intent is 🙈 On top of that, each SDO defines its own set of terms and level of abstraction, its own intent users, and its own applications and usage scenarios 💅
Still, most intent approaches proposed by SDOs share the same features 👑
- It must be declarative in nature, meaning an intent user specifies the goal on the network without specifying how to achieve that goal 🧚
- It must be vendor agnostic in the sense that it abstracts the network capabilities or the network infrastructure away from the intent user, and it can be ported across different platforms 🌸
- It must provide an easy-to-use interface, which simplifies the interaction between intent users and the intent system through familiar terminology or concepts 🍓
- It should be able to detect and resolve intent conflicts, which include, for example, static (compile-time) conflicts and dynamic (run-time) conflicts 🔥
1.3. Scope
Okay, the focus of this doc is defining criteria that let you categorize intents from the stakeholders' point of view 💖 Concepts and definitions related to IBN are covered in [RFC9315] 📚
This document mostly addresses intents in the context of network intents. Other types of intents aren't excluded, though, as Sections 4.4 and 6.2 show 🦋
Honestly, you can't fully tell intents apart just from the common characteristics shared by concepts, terms, and intentions 😭 So this document clarifies what an intent represents for different stakeholders by classifying it along several dimensions, like solutions, intent users, and intent types 🎀 That classification keeps everyone on the same page and is used to figure out 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, and the initial classification table is built around that scope ✨ The methodology can also be used to update those classification tables by adding or removing solutions, intent users, or intent types, so it can handle future scenarios, applications, or domains 🌈
2. Abbreviations ✨
okay bestie, first up is the acronym list 💅 Here's what every abbreviation stands for:
- AI: Artificial Intelligence
- CE: Customer Equipment
- CFS: Customer Facing Service
- CLI: Command-Line Interface
- DB: Database
- DC: Data Center
- ECA: Event Condition Action
- GBP: Group-Based Policy
- GPU: Graphics Processing Unit
- IBN: Intent-Based Network
- NFV: Network Function Virtualization
- O&M: OAM & Maintenance
- ONF: Open Networking Foundation
- ONOS: Open Network Operating System
- PNF: Physical Network Function
- QoE: Quality of Experience
- RFS: Resource Facing Service
- SDO: Standards Development Organization
- SD-WAN: Software-Defined Wide-Area Network
- SLA: Service Level Agreement
- SUPA: Simplified Use of Policy Abstractions
- VM: Virtual Machine
- VNF: Virtual Network Function
3. Definitions 🎀
okay so the shared vocab for IBN is pulled from [RFC9315] 🧚 Here are the key terms, no cap:
Intent: a set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver), defined in a declarative way without saying how to achieve or implement them. ✨
Intent-Based Network: a network that can be managed using intent. 🦋
Policy: a set of rules that governs the choices in behavior of a system. 💜
Intent User: a user that defines and issues the intent request to the intent-based management system. 👑
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. 🌸
4. Abstract Intent Requirements 🔥
okay so before we can figure out which intent requirements drive intent classification, we first need to understand what intent means for different intent users. it's giving foundations 🫶
4.1. What is intent?
The word "Intent" has gotten super popular in the industry, and honestly it's being used for all kinds of different purposes 💀. Sometimes that usage doesn't even match the SDO-shared principles from Section 1. [RFC9315] clears things up about what an intent is and how it's different from policies and services ✨.
Different stakeholders see the network from different angles, so they have different intent requirements 🌈. Their intent can be technical, non-technical, abstract, or technology specific. That's why it matters to kick off a conversation in the industry and academic communities about what intent looks like for different solutions and intent users 💖. It's also important to propose some intent categories or classifications that a wider audience can actually understand 🍓. This would help us define intent interfaces, domain-specific languages, and models 🦋.
4.2. Intent Solutions and Intent Users
Intent types are defined by every aspect needed to profile different requirements so you can tell them apart easily 💅. To keep things clustered, though, we can focus on two aspects: the solution and the intent user. These are the main keys for classifying intents, because we can group requirements by solution and intent user with no stress 🎀.
On one hand, different solutions and intent users have different requirements, expectations, and priorities for intent-based networking 👑. So intent users need different intent types depending on their context, since they show up in different use cases 🌸. Some intent users are super technical and want intents that expose more technical information 🤓. Other intent users have zero knowledge of the network infrastructure and need intents that shield them from networking concepts and technologies 🫶.
The following are the solutions and intent users that intent-based networking needs to support:
+============+=====================================+
| Solutions | Intent Users |
+============+=====================================+
| Carrier | Network Operators, Service |
| Networks | Designers / App Developers, Service |
| | Operators, Customers / Subscribers |
+------------+-------------------------------------+
| DC | Cloud Administrators, Underlay |
| Networks | Network Administrators, Application |
| | Developers, Customers / Tenants |
+------------+-------------------------------------+
| Enterprise | Enterprise Administrators, |
| Networks | Application Developers, End Users |
+------------+-------------------------------------+
Table 1: Intent Solutions and Intent UsersThese intent solutions and intent users are a starting point for the classification, and they're expendable through the methodology presented in Section 6.1 🧚.
- For carrier network scenarios, for example, if a customer/subscriber wants to watch high-definition video, then the intent is to convert the video image to 1080p. 📺✨
- For DC network scenarios, administrators have their own clear network intent such as load balancing. For all traffic flows that need NFV service chaining, they can restrict the maximum load of any VNF node / container below 50% and the maximum load of any network link below 70%. 🖥️💜
- For enterprise network scenarios, when hosting a video conference, multiple remote accesses are required. An example of the intent from the network administrator is as follows: for any end user of this application, the arrival time of hologram objects of all the remote tele-presenters should be synchronized within 50 ms to reach the destination viewer for each conversation session. 🌈🦋
4.3. Benefits of Intents for Different Stakeholders
Current network APIs and CLIs are way too complex 😭. They're tightly integrated with the low-level concepts that networks expose. Customers, application developers, and end users must not be required to set IP addresses, VLANs, subnets, or ports 🙈. Operators, on the other hand, may still want more technical, network-level visibility. Everyone would benefit from simpler interfaces, like:
- request gold VPN service between sites A, B, and C 🎀
- provide CE redundancy for the customer sites 🛡️
- add access rules to the network service 🔐
Operators and administrators are stuck manually troubleshooting and fixing their networks and services 😩. What they actually want is to:
- simplify and automate network operations ⚙️
- simplify definitions of network services 📝
- provide simple customer APIs for value-added services (operators) 💅
- be informed if the network or service is not behaving as requested 🚨
- enable automatic optimization and correction for selected scenarios ✨
- have systems that learn from historic information and behavior 🧠
Right now, intent users can't build their own services and policies without becoming technical experts and doing manual maintenance actions 💀. They want to be able to:
- build their own network services with their own policies via simple interfaces, without becoming networking experts 👑
- have their network services up and running based on intent and automation only, without any manual actions or maintenance 🌟
4.4. Intent Types That Need to Be Supported
Besides the intent solutions and intent users, there's another way to categorize intent: by intent type 🧩. The following intent types and subtypes need to be supported to address the requirements from different solutions and intent users 💖.
- Customer service intent
- for customer self service with SLA
- for service operator orders
- Network and underlay network service intent
- for service operator orders
- for intent-driven network configuration, verification, correction, and optimization
- for intent created and provided by the underlay network administrator
- Network and underlay network intent
- for network configuration
- for automated life-cycle management of network configurations
- for network resources (switches, routers, routing, policies, and underlay)
- Cloud management intent
- for DC configuration, VMs, DB servers, and Application servers
- for communication between VMs
- Cloud resource management intent
- for cloud resource life-cycle management (policy-driven self-configuration and auto-scaling and recovery/optimization)
- Strategy intent
- for security, QoS, application policies, traffic steering, etc.
- for configuring and monitoring policies, alarm generation for non-compliance, and auto-recovery
- for design models and policies for network and network service design
- for design workflows, models, and policies for operational task intents
- Operational task intents
- for network migration
- for device replacements
- for network software upgrades
- for automating any other tasks that operators/administrator often perform
It's important to note that all of the types and subtypes above may affect other intents 🕸️. For example, an operational task intent can modify many other intents 🔄. The task itself is short lived, but changing other intents has an impact on their life cycle, so those changes must continue to be continuously monitored and self corrected/optimized 🫧.
5. Functional Characteristics and Behavior 👑
Intent can operate immediately on a target (kinda like issuing a command), or whenever it's appropriate (e.g., in response to an event) ⚡. Either way, intent has a number of behaviors that organize its purpose further, as the following subsections describe 🦋.
5.1. Abstracting Intent Operation
The modeling of intents can be abstracted using the following three-tuple 🔺:
{Context, Capabilities, Constraints}- Context grounds the intent and determines whether it's relevant to the current situation. So context selects intents based on applicability 🎯.
- Capabilities describe the functionality the intent can perform. They take different forms depending on the expressivity of the intent and the programming paradigm(s) used 🛠️.
- Constraints define any restrictions on the capabilities to be used for that particular context 🚧.
Metadata can be attached via strategy templates to each element of the three-tuple. It may be used to describe how the intent should be used and how it operates, and to prescribe any operational dependencies that must be taken into account 🏷️.
Although different intent categories share the same abstracted intent model, each category has its own specific context, capabilities, and constraints 💕.
5.2. Intent User Types 💖
Okay bestie, picking up from the intro in Section 4.2 🫶. Intent user types are the people who define and issue an intent request. Which intent users show up depends on the intent solution. Examples include customers, network operators, service operators, enterprise administrators, cloud administrators, underlay network administrators, or application developers.
- Customers and end users don't necessarily know the functional and operational details of the network they're using 🙈. They usually lack the skills to understand those details, and honestly that knowledge isn't relevant to their job. The network may also not show those details to its intent users. This group cares about the applications they run and the services the network gives them, so they want policies that behave consistently with their business needs. They don't have to worry about how the intents get deployed onto the underlying network, or whether the intents need to be translated so network elements can understand them 💅.
- Application developers work with the abstractions defined by their application and programming environment(s) ✨. For example, lots of app developers think in terms of objects, like a VPN. That makes total sense from their side, but most network devices don't have a VPN object per se. Instead, the VPN is built from a set of configuration statements on that device, combined with configuration statements on the other devices that together make up the VPN 🧩. So the developer's view matches the services the network provides, but it may not directly line up with the views of other intent users.
- Network operators may know the underlying network really well 🌐. However, they may not understand the details of customers' applications and services.
5.3. Intent Scope 🎀
Intents manage the behavior of the networks they're applied to, and every intent is applied within a specific scope. The scopes are:
- connectivity scope, if the intent creates or modifies a connection
- security/privacy scope, if the intent specifies the security characteristics of the network, customers, or end users 🔒
- application scope, when the intent specifies the applications to be affected by the intent request
- QoS scope, when the intent specifies the QoS characteristics of the network
These intent scopes can be expanded using the methodology presented in Section 6.1 🌈.
5.4. Intent Network Scope 🦋
No matter which intent user type it comes from, an intent request affects the network, or the network components, that act as the intent targets 🎯.
So the intent network scope, which is called the policy target in the area of declarative policy, can represent VNFs or PNFs, physical network elements, campus networks, SD-WANs, RANs, cloud edges, cloud cores, branches, and so on ✨.
5.5. Intent Abstraction 🌸
Intents can be classified by whether technical network information or non-technical information needs to be fed back to the intent user after the intent is executed 📬. Intent abstraction also covers how much technical detail appears in the intent itself.
- Non-technical intent users don't care how the intent is executed, and they don't care about the details of the network 🙃. So they don't need the configuration information of the underlying network. They only focus on whether the intent execution achieves the goal, plus the execution effects, like the quality of completion and how long it took ⏱️. In this case, we call it an abstraction without technical feedback.
- Administrators, such as network administrators, perform intents like allocating network resources, selecting transmission paths, handling network failures, and so on 🛠️. After execution, they need multiple feedback indicators for network resource conditions, congestion conditions, fault conditions, and so on 📊. In this case, we call it an abstraction with technical feedback.
As per the definition of "intent" provided in [RFC9315], lower-level intents are not considered to qualify as intents. However, we kept this classification so we can identify any PoCs / Demos / Use Cases that still either require or implement a lower level of abstraction for intents 🔍.
5.6. Intent Life Cycle 🧚
Intents can be sorted into transient and persistent intents 💫:
- Transient: The intent has no life-cycle management. As soon as the specified operation is successfully carried out, the intent is finished and can no longer affect the target object 👋.
- Persistent: The intent has life-cycle management. Once the intent is successfully activated and deployed, the system keeps all relevant intents active until they are deactivated or removed 🔁.
5.7. Autonomous Driving Levels 🚗
Intents change across the different phases of the autonomous driving network [TMF-AUTO] 🛣️. Depending on the Autonomous Network Level of the overall solution, the intent requirements and types may be different. For example, at lower levels, the customer intent is:
- automatically converted to configuration policies only, while at the higher levels,
- covering the full life cycle,
- converted to both configuration and monitoring policies, and
- self assured using AI 🤖.
Here's a rundown of autonomous driving network levels 0 to 5 👇:
- Level 0 - Traditional manual network: O&M personnel manually control the network and obtain network alarms and logs 📟.
- No intent
- Level 1 - Partially automated network: 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
- Level 2 - Automated network: This entails the automation of most service provisioning, network deployment, and maintenance, along with a comprehensive perception of network status and local machine decision-making 🧠.
- simple intent on service provisioning
- Level 3 - Self-optimization network: This entails a deep awareness of network status and automatic network control, meeting the requirements of the intent users of the network 🎯.
- Intent based on network status cognition
- Level 4 - Partial autonomous network: In a limited environment, people don't need to take part in decision-making, and networks can adjust themselves 🌤️.
- Intent based on limited AI
- Level 5 - Autonomous network: In different network environments and network conditions, the network can automatically adapt and adjust to meet people's intentions 👑.
- Intent based on AI
6. Intent Classification 🌈
This section proposes an approach to intent classification that may help classify mainstream intent-related demos and tools 🗂️.
The three classifications in this document were proposed from scratch, following the methodology presented, through three iterations 🔄. The first was for a carrier network intent solution, the second for a DC intent solution, and the third 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", was identified, and the classification table was extended accordingly 🍓.
In the future, as new scenarios, applications, and domains emerge, new classifications and taxonomies can be identified by 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 📋.
So the subsections of Section 6 introduce the proposed intent classification methodology, the consolidated intent taxonomy for three intent solutions, and concrete examples of intent classifications for three different intent solutions (e.g., carrier network, data center, and enterprise). These were derived using the proposed methodology and can be filled in for PoCs, demos, research projects, or future documents 🧁.
6.1. Intent Classification Methodology 🦋
okay so this section is literally the recipe for how the classification gets built, bestie 💅 it explains how you can make a brand new classification from scratch by digging into the solution knowledge, and also how you can tweak an existing table by adding or removing solutions, intent users, or intent types so it stays future-proof for new scenarios, apps, 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 <---------------+
+------------------+
Figure 1: Intent Classification Methodologyso the workflow kicks off with the solution knowledge, which can spill the tea on requirements, use cases, technologies in play, network properties, the intent users who define and issue the intent request, and requirements. here's the step-by-step, no cap 🫶
- Take the solution knowledge as your input and figure out the intent solution (think carrier, enterprise, or data center) 🏢 Check each one against the existing classification. If it's already there, use it. If it's missing, add it. If it's not needed, remove it. That's R1-U1 ✨
- Identify the intent user types (like customer, network operators, service operators, etc.) 👑 Review the existing classification, then use the type if it's there, add it if it's not, or remove it if it's not needed. That's R2-U2 💖
- Identify the types of intent (like network intent or customer service intent) 🎀 Review what's already there, then use, add, or remove the intent type. That's R3-U3 🦋
- Identify the intent scopes (like connectivity or application) based on the solution knowledge 🌸 Review the existing classification, then use, add, or remove the scope. That's R4-U4 💜
- Identify the network scopes (like campus or radio access) 🧚 Review the existing classification, then either use, add, or remove the network scope. That's R5-U5 🌈
- Identify the abstractions (like technical or non-technical) ⭐ Review the existing classification, then either use, add, or remove them. That's R6-U6 ✨
- Identify the life-cycle requirements (like persistent or transient) 🍓 Review the existing classification, then either use, add, or remove them. That's R7-U7 💅
- Identify any new categories 🔥 Use and add the newly identified categories. New categories can show up as new domains or applications emerge, or as new areas of concern (like privacy or compliance) pop up that aren't on the current methodology list. That's R8-U8 👑
6.2. Intent Taxonomy 🌸
okay so this is the taxonomy, aka the big picture of everything: the intent solutions, intent user types, intent types, intent scopes, network scopes, abstractions, and life cycles 🧚 It's the output of the classification tables for each solution covered here (carrier, data center, and enterprise) 🏢
The intent scope categories in Figure 2 are shared across the carrier, DC, and enterprise solutions. The abbreviations (Cx) in Sections 6.3.2 and 6.4.2 are introduced so they fit as column titles in the tables below 💖
+--------------------------------+
+-->|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 |
+--------------------------------+Figure 2: Intent Taxonomy
6.3. Intent Classification for Carrier Solution 🎀
6.3.1. Intent Users and Intent Types 💜
okay so this bit covers steps 1, 2, and 3 from Figure 1 🫶 The table below lays out the intent users in carrier solutions, plus the intent types and their descriptions for each intent user 🌈
okay so the table is still going, and it's giving a lot of intent types for the app developers 💅✨
+=============+=============+=======================================+
| Intent User | Intent Type | Intent Type Description |
+=============+=============+=======================================+
| Customer/ | Customer | Customer self service with SLA |
| Subscriber | Service | and value-added service. |
| | Intent | |
| | | 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 | Customer designs models and |
| | Intent | policy intents to be used by |
| | | customer service intents. |
| | | |
| | | Example: Request reliable |
| | | service during peak traffic |
| | | periods for video-type apps. |
+-------------+-------------+---------------------------------------+
| Network | Network | Service provided by the network |
| Operator | Service | service operator to the customer |
| | Intent | (e.g., the service operator). |
| | | |
| | | Example: Request network service |
| | | with delay guarantee for access |
| | | customer A. |
| +-------------+---------------------------------------+
| | Network | Network operator requests |
| | Intent | 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 | Network operator requests |
| | Task Intent | 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 | Network operator designs models, |
| | Intent | 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 | Customer | Service operator's customer |
| Operator | Service | orders, customer service, or |
| | Intent | SLA. |
| | | |
| | | Example: Provide service S with |
| | | guaranteed bandwidth for |
| | | customer A. |
| +-------------+---------------------------------------+
| | Network | Service operator's network |
| | Service | orders / network SLA. |
| | Intent | |
| | | Example: Provide network |
| | | guarantees in terms of security, |
| | | low latency, and high bandwidth. |
| +-------------+---------------------------------------+
| | Operational | Service operator requests |
| | Task Intent | 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 | Service operator designs models, |
| | Intent | 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 | Customer | Customer service intent API |
| Developer | Service | provided to the application |
| | Intent | developers. |
| | | |
| | | Example: API to request network |
| | | to watch HD video (4K/8K). |
| +-------------+---------------------------------------+
| | Network | Network service intent API |
| | Service | provided to the application |
| | Intent | developers. |
| | | |
| | | Example: API to request network |
| | | service, monitoring, and traffic |
| | | grooming. |
| +-------------+---------------------------------------+
| | Network | Network intent API provided to |
| | Intent | the application developers. |
| | | |
| | | Example: API to request network |
| | | resource configurations. |
| +-------------+---------------------------------------+
| | Operational | Operational task intent API |
| | Task Intent | provided to the application |
| | | developers. This is for the |
| | | trusted internal operator / |
| | | service providers / customer |
| | | DevOps. |
| | | |
| | | Example: API to request server |
| | | migrations. |
| +-------------+---------------------------------------+
| | Strategy | Application developer designs |
| | Intent | 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. |
+-------------+-------------+---------------------------------------+Table 2: Intent Classification for Carrier Solution 🎀
6.3.2. Intent Categories ✨
okay so this subsection covers steps 4 to 7 from Figure 1 🦋 and these are the proposed categories:
- Intent Scope: C1=
Connectivity, C2=Security/Privacy, C3=Application, C4=QoS - Network Scope:
- Network Domain: C1=
Radio Access, C2=Transport Access, C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge, C6=Cloud Core - Network Function (NF) Scope: C1=
VNFs, C2=PNFs
- Network Domain: C1=
- Abstraction (ABS): C1=
Technical (with technical feedback), C2=Non-technical (without technical feedback)(see Section 5.2) 💅 - Life cycle (L-C): C1=
Persistent (full life cycle), C2=Transient (short lived)🌸
6.3.3. Intent Classification Example 🦋
this section is a little example of how the methodology from Section 6.1 can be used to classify the intents from the "A Multi-Level Approach to IBN" PoC demonstration [POC-IBN] 💜 this PoC is led by academics doing research in SDN/NFV, and the problem they're tackling is applying the intent concept at different levels that match different stakeholders. for this research, they looked at two types of intents: slice intents and service chain intents.
in this PoC [POC-IBN], a slice intent is a request for a network slice with two kinds 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 is a request for a service that runs through a chain of service components living in L4-L7 virtual functions ✨
following the intent classification methodology step by step from Section 6.1, here's what you get 👑
- The intent solution for both intents is carrier network.
- The intent user type is network operator for the slice intent and service operator for the service chain intent.
- The type of intent is a network service intent for the slice intent and a customer service intent for the service chain intent.
- The intent scopes are connectivity and application.
- The network scope is VNF, cloud edge, and cloud core.
- The abstractions are with technical feedback for the slice intent and without technical feedback for the service chain intent.
- The life cycle is persistent.
the table below shows how to represent all of this in tabular form 🧚 the "X" in the table refers to the slice intent, and 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 | | | | | | | | | | | | | | | | |
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 3: Intent Classification Example for Carrier Solution
6.4. Intent Classification for Data Center Network Solutions 💅
6.4.1. Intent Users and Intent Types
okay so this table is basically the whole guest list 💅 it's giving "who wants what from the data center network" and each row is a different intent user with their own intent types (and a little description for each one). bestie, it's so organized I'm obsessed 🫶
+===============+=============+====================================+
| Intent User | Intent Type | Intent Type Description |
+===============+=============+====================================+
| Customer/ | Customer | Customer self service via tenant |
| Tenants | Service | portal. |
| | | |
| | | Example: Request GPU computing and |
| | | storage resources to meet 10k |
| | | video surveillance services. |
| +-------------+------------------------------------+
| | Strategy | This includes models and policy |
| | Intent | 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 | Cloud | Configuration of VMs, DB Servers, |
| Administrator | Management | app servers, and communication |
| | Intent | between servers and VMs. |
| | | |
| | | Example: Request connectivity |
| | | between VMs A, B, and C in network |
| | | N1. |
| +-------------+------------------------------------+
| | Cloud | Policy-driven self configuration |
| | Resource | and recovery/optimization. |
| | Management | |
| | Intent | Example: Request automatic life- |
| | | cycle management of VM cloud |
| | | resources. |
| +-------------+------------------------------------+
| | Operational | Cloud administrator requests |
| | Task Intent | 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 | Cloud administrator designs |
| | Intent | 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 | Underlay | Service created and provided by |
| Network | Network | the underlay network |
| Administrator | Service | administrator. |
| | Intent | |
| | | Example: Request underlay service |
| | | between DC1 and DC2 with bandwidth |
| | | B. |
| +-------------+------------------------------------+
| | Underlay | Underlay network administrator |
| | Network | requests some DCN-wide underlay |
| | Intent | network configuration or network |
| | | resource configurations. |
| | | |
| | | Example: Establish and allocate |
| | | DHCP address pool. |
| +-------------+------------------------------------+
| | Operational | Underlay network administrator |
| | Task Intent | 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 | Underlay network administrator |
| | Intent | 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 | Cloud | Cloud management intent API |
| Developer | Management | provided to the application |
| | Intent | developers. |
| | | |
| | | Example: API to request |
| | | configuration of VMs or DB |
| | | Servers. |
| +-------------+------------------------------------+
| | Cloud | Cloud resource management intent |
| | Resource | API provided to the application |
| | Management | developers. |
| | Intent | |
| | | Example: API to request automatic |
| | | life-cycle management of cloud |
| | | resources. |
| +-------------+------------------------------------+
| | Underlay | Underlay network service API |
| | Network | provided to the application |
| | Service | developers. |
| | Intent | |
| | | Example: API to request real-time |
| | | monitoring of device condition. |
| +-------------+------------------------------------+
| | Underlay | Underlay network resource API |
| | Network | provided to the application |
| | Intent | developers. |
| | | |
| | | Example: API to request dynamic |
| | | management of IPv4 address pool |
| | | resources. |
| +-------------+------------------------------------+
| | Operational | Operational task intent API |
| | Task Intent | provided to the trusted |
| | | application developer (internal |
| | | DevOps). |
| | | |
| | | Example: API to request automatic |
| | | rapid detection of device failures |
| | | and pre-alarm correlation. |
| +-------------+------------------------------------+
| | Strategy | Application developer designs |
| | Intent | 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. |
+---------------+-------------+------------------------------------+Table 3: Intent Classification for Data Center Network Solutions
ngl the cloud admin row alone has so many vibes 🎀 the way the operational statement walks through updating a system is literally iconic 🦋
6.4.2. Intent Categories ✨
okay so here are the categories we're proposing, and they're giving organized 💅
- Intent Scope:
C1=Connectivity,C2=Security/Privacy,C3=Application,C4=QoS,C5=Storage,C6=Compute🎀 - Network Scope 🌸
- Network Domain:
DC Network - DCN Network (DCN Net) Scope:
C1=Logical,C2=Physical - DCN Resource (DCN Res) Scope:
C1=Virtual,C2=Physical
- Network Domain:
- Abstraction (ABS):
C1=Technical (with technical feedback),C2=Non-technical (without technical feedback). See Section 5.2. 🦋 - Life cycle (L-C):
C1=Persistent (full life cycle),C2=Transient (short lived)⭐
6.4.3. Intent Classification Example 💖
this section walks through an example of how the methodology from Section 6.1 can be used by the research community to classify intents 🧚 remember how Section 6.3.3 mentioned a working use of this classification? it's shown in the PoC demo called "A Multi-Level Approach to IBN" [POC-IBN]. the PoC is run by academics who study SDN/NFV, and the problem they're tackling is applying the intent concept at different levels, each matching a different stakeholder. literally so cool 😭
for their research, they looked at two types of intents: slice intents and service chain intents. for the data center solution, only the slice intent matters 🔥
like we already said in Section 6.3.3, a slice intent asks for a network slice with two kinds of components: a set of top-layer virtual functions, and a set of virtual switches and/or routers of L2/L3 VNFs 🫶
now, following the intent classification methodology we went through step by step in Section 6.1, here's what we get:
- The intent solution is data center. 🌈
- The intent user type is the cloud administrator for the slice intent and service chain intent. 👑
- The type of intent is a cloud management intent for the slice intent. ✨
- The intent scopes are connectivity and application. 💜
- The network scope is logical; the resource scope is virtual. 🍓
- The abstractions are with technical feedback for the slice intent. 🙈
- The life cycle is persistent. 🦋
the table below shows how to put all of this into a tabular form. the "X" marks refer 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 | | | | | | | | | | | | | | |
+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 4: Intent Classification Example for Data Center Network
Solutions6.5. Intent Classification for Enterprise Solution 🏢💜
6.5.1. Intent Users and Intent Types ✨
okay bestie, let's talk about WHO is asking for WHAT in enterprise land 💅 this table breaks down the intent users in enterprise solutions and the intent types each one gets 🎀
+---------------+-------------+------------------------------------+
| Intent User | Intent Type | Intent Type Description |
+---------------+-------------+------------------------------------+
| End User | Customer | Enterprise end user self service |
| | Service | or applications; enterprise may |
| | Intent | have multiple types of end users. |
| | | |
| | | Example: Request access to VPN |
| | | service. Request video conference |
| | | between end user A and B. |
| +-------------+------------------------------------+
| | Strategy | This includes models and policy |
| | Intent | 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 | Network | Service provided by the |
| Administrator | Service | administrator to the end users and |
| (internal or | Intent | their applications. |
| MSP) | | |
| | | 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 | Administrator requires network- |
| | Intent | 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 | Administrator requests execution |
| | Task Intent | 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 | Administrator designs models, |
| | Intent | 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 | End-User | End-user service / application |
| Developer | Intent | intent API provided to the |
| | | application developers. |
| | | |
| | | Example: API for request to open a |
| | | VPN service. |
| +-------------+------------------------------------+
| | Network | Network service API provided to |
| | Service | application developers. |
| | Intent | |
| | | Example: API for request network |
| | | bandwidth and latency for hosting |
| | | a video conference. |
| +-------------+------------------------------------+
| | Network | Network API provided to |
| | Intent | application developers. |
| | | |
| | | Example: API for requesting |
| | | network device configuration. |
| +-------------+------------------------------------+
| | Operational | Operational task intent API |
| | Task Intent | provided to the trusted |
| | | application developer (internal |
| | | DevOps). |
| | | |
| | | Example: API for requesting |
| | | automatic monitoring and |
| | | interception for network security. |
| +-------------+------------------------------------+
| | Strategy | Application developer designs |
| | Intent | 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. |
+---------------+-------------+------------------------------------+Table 4: Intent Classification for Enterprise Solution
6.5.2. Intent Categories 🌈
okay so here are the proposed categories 💖 each one is its own little lens for sorting intents:
- Intent Scope:
C1=Connectivity,C2=Security/Privacy,C3=Application,C4=QoS - Network (Net) Scope:
C1=Campus,C2=Branch,C3=SD-WAN - Abstraction (ABS):
C1=Technical(with technical feedback),C2=Non-technical(without technical feedback) (see Section 5.2) - Life cycle (L-C):
C1=Persistent(full life cycle),C2=Transient(short lived)
And here's the intent classification table example for enterprise solutions 🦋 it's a blank grid, so you fill in the intent users and types against each category:
+---------------+-------------+-----------+--------+-----+-----+
| 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 | | | | | | | | | | | |
+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+Figure 5: Intent Categories for Enterprise Solution
7. Conclusions ✨
okay so this doc is totally lined up with what the NMRG research group wants 🌸 It digs into intent-based networking by proposing a way to categorize intents plus a taxonomy to go with it. The big win is clarity: it explains what an intent actually means for each different stakeholder, through an intent classification approach, so everyone's on the same page. Combine that with the taxonomy and you've got a solid base for future intent convos in NMRG 💜
The research community has already seen this work in action too 🦋 A PoC implementation [POC-IBN] applied the document's concepts at different levels, one for each stakeholder. Iconic, honestly 👑
8. Security Considerations 🔐
this section is lowkey important, so pay attention bestie 👀 The document treats security and privacy as categories within the intent scope 🛡️ Intents could be purely security intents or purely privacy intents. Or security can be baked right into intents that also cover connectivity, application, and QoS scope 🧩
So when does the security and privacy scope kick in? It's when an intent specifies the security characteristics of the network, of customers, or of end users. Privacy scope covers customers and end users 🙈
More details on these security intents will show up in future documents that specify architecture, functionality, user intents, and models 📚 For the security analysis of the whole intent-based system, check out Section 9 of [RFC9315]. Go read it, it's giving thorough 🫶
9. IANA Considerations 🌷
no IANA actions here, so nothing to register or update, zero drama 💅
10. Informative References 📖
[Banerjee21]Banerjee, A., Mwanje, S., and G. Carle, "Contradiction Management in Intent-driven Cognitive Autonomous RAN", September 2021.[Bezahaf19]Bezahaf, M., Hernandez, M., Bardwell, L., Davies, E., Broadbent, M., King, D., and D. Hutchison, "Self-Generated Intent-Based System", 10th International Conference on Networks of the Future (NoF), DOI 10.1109/NoF47743.2019.9015045, October 2019,<https://doi.org/10.1109/NoF47743.2019.9015045>.[Bezahaf21]Bezahaf, M., Davies, E., Rotsos, C., and N. Race, "To All Intents and Purposes: Towards Flexible Intent Expression", IEEE 7th International Conference on Network Softwarization (NetSoft), DOI 10.1109/NetSoft51509.2021.9492554, July 2021,<https://doi.org/10.1109/NetSoft51509.2021.9492554>.[Davoli21]Davoli, G., "Programmability and Management of Software-Defined Network Infrastructures", 2021.[IFIP-NSM]IFIP, "Network and Service Management Taxonomy",<https://www.simpleweb.org/ifip/taxonomy.html>.[Jacobs18]Jacobs, A., Pfitscher, R., Ferreira, R., and L. Granville, "Refining Network Intents for Self-Driving Networks", Proceedings of the Afternoon Workshop on Self-Driving Networks (SelfDN), DOI 10.1145/3229584.3229590, August 2018,<https://doi.org/10.1145/3229584.3229590>.[Leivadeas21]Leivadeas, A. and M. Falkner, "VNF Placement Problem: A Multi-Tenant Intent-Based Networking Approach", 24th Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), DOI 10.1109/ICIN51074.2021.9385553, March 2021,<https://doi.org/10.1109/ICIN51074.2021.9385553>.[Mehmood21]Mehmood, K., Kralevska, K., and D. Palma, "Intent-driven Autonomous Network and Service Management in Future Networks: A Structured Literature Review", DOI 10.48550/arXiv.2108.04560, August 2021,<https://doi.org/10.48550/arXiv.2108.04560>.[ONF]Open Networking Foundation, "Intent NBI - Definition and Principles", October 2016,<https://opennetworking.wpengine.com/wp-content/uploads/2014/10/TR-523_Intent_Definition_Principles.pdf>.[ONOS]Koshibe, A., "Intent Framework", 2016,<https://wiki.onosproject.org/display/ONOS/Intent+Framework/>.[Padovan20]Padovan, S., "Design and Implementation of a Blockchain Intent Management System", November 2020.[POC-IBN]Martini, B., Cerroni, W., Gharbaoui, M., and D. Borsatti, "A Multi-Level Approach to IBN", IETF 108 Hackathon Report, July 2020,<https://www.ietf.org/proceedings/108/slides/slides-108-nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-ibn-02>.[RFC9315]Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022,<https://www.rfc-editor.org/info/rfc9315>.[Szilagyi21]Szilágyi, P., "I2BN: Intelligent Intent Based Networks", Journal of ICT Standardization, Volume 9, Issue 2, DOI 10.13052/jicts2245-800X.926, June 2021,<https://doi.org/10.13052/jicts2245-800X.926>.[Tian19]Tian, B., Zhang, X., Zhai, E., Liu, H., Ye, Q., Wang, C., Wu, X., Ji, Z., Sang, Y., Zhang, M., Yu, D., Tian, C., Zheng, H., and B. Zhao, "Safely and automatically updating in-network ACL configurations with intent language", SIGCOMM '19: Proceedings of the ACM Special Interest Group on Data Communication, DOI 10.1145/3341302.3342088, August 2019,<https://doi.org/10.1145/3341302.3342088>.[TMF-AUTO]Boasman-Patel, A., Sun, D., Wang, Y., Maitre, C., Domingos, J., Troullides, Y., Mas, I., Traver, G., and G. Lupo, "Autonomous Networks: Empowering Digital Transformation For The Telecoms Industry", May 2019.
Acknowledgments 🫶
this doc got so much love from reviewers, suggestions, comments, and proposed text from these legends, listed alphabetically: 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 💖
and a huge thank you to Barbara Martini, Walter Cerroni, Molka Gharbaoui, and Davide Borsatti for their "A multi-level approach to IBN" PoC demo ✨ It was the first real attempt to adopt the intent classification methodology, which is so cool 🎀
Contributors 🌈
the following people all contributed to creating this document 🧚
Contributed significant text:
- Xueyuan Sun, China Telecom
- Will (Shucheng) Liu, Huawei
Contributed text in early draft versions of this document:
- Ying Chen, China Unicom
- John Strassner, Huawei
- Weiping Xu, Huawei
- Richard Meade, Huawei
Authors' Addresses 💌
Chen Li
China Telecom
Xicheng District
No.118 Xizhimennei street
Beijing
100035
China
Email: lichen6@chinatelecom.cnOlga Havel
Huawei Technologies
Ireland
Email: olga.havel@huawei.comAdriana Olariu
Huawei Technologies
Ireland
Email: adriana.olariu@huawei.comPedro Martinez-Julia
NICT
Japan
Email: pedro@nict.go.jpJeferson Campos Nobre
Federal University of Rio Grande do Sul (UFRGS)
Porto Alegre-RS
Brazil
Email: jcnobre@inf.ufrgs.brDiego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
28006 Madrid
Spain
Email: diego.r.lopez@telefonica.com📦 where this page comes from
- ietf: rfc9316 2022-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms