Network Working Group
Internet Research Task Force (IRTF) C. Li
Internet Draft
Request for Comments: 9316 China Telecom
Intended status:
Category: Informational O. Havel
Expires: November 2022
ISSN: 2070-1721 A. Olariu
Huawei Technologies
P. Martinez-Julia
NICT
J. Nobre
UFRGS
D. Lopez
Telefonica, I+D
May 18,
October 2022
Intent Classification
draft-irtf-nmrg-ibn-intent-classification-08
Abstract
Intent is an abstract, high-level policy used to operate the a network.
Intent-based
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. life cycle.
This document discusses mostly discusses the concept of network intents, but
other types of intents are also being considered. Specifically, it this
document highlights stakeholder perspectives of intent, methods to
classify and encode intent, and the associated intent taxonomy, and taxonomy; it
also defines relevant intent terms where necessary. This document necessary, provides a
foundation for intent related research intent-related research, and facilitates solution
development.
This document is a product of the IRTF Network Management Research
Group (NMRG).
Status of this This Memo
This Internet-Draft document is submitted in full conformance with 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
provisions results of BCP 78 Internet-related research
and BCP 79.
Internet-Drafts are working documents development activities. These results might not be suitable for
deployment. This RFC represents the consensus of the Network
Management Research Group of the Internet Engineering Research Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts (IRTF).
Documents approved for publication by the IRSG are draft documents valid not candidates for a maximum
any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 18, 2022.
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
(http://trustee.ietf.org/license-info)
(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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................4 Introduction
1.1. Research activities..........................................4 Activities
1.2. Standards and open source activities.........................5 Open-Source Activities
1.3. Scope........................................................6 Scope
2. Acronyms.......................................................7 Abbreviations
3. Definitions....................................................8 Definitions
4. Abstract Intent Requirements...................................8 Requirements
4.1. What is Intent?..............................................8 intent?
4.2. Intent Solutions and Intent Users............................9 Users
4.3. Benefits of Intents for Different Stakeholders..............11 Stakeholders
4.4. Intent Types that need That Need to be supported......................12 Be Supported
5. Functional Characteristics and Behaviour......................13 Behavior
5.1. Abstracting Intent Operation................................13 Operation
5.2. Intent User Types...........................................14 Types
5.3. Intent Scope................................................15 Scope
5.4. Intent Network Scope........................................15 Scope
5.5. Intent Abstraction..........................................16 Abstraction
5.6. Intent Life-cycle...........................................16 Life Cycle
5.7. Autonomous Driving Levels...................................16 Levels
6. Intent Classification.........................................17 Classification
6.1. Intent Classification Methodology...........................18 Methodology
6.2. Intent Taxonomy.............................................21 Taxonomy
6.3. Intent Classification for Carrier Solution..................23 Solution
6.3.1. Intent Users and Intent Types.............................23 Types
6.3.2. Intent Categories.........................................27 Categories
6.3.3. Intent Classification Example.............................27 Example
6.4. Intent Classification for Data Center Network Solutions.....31 Solutions
6.4.1. Intent Users and Intent Types.............................31 Types
6.4.2. Intent Categories.........................................35 Categories
6.4.3. Intent Classification Example.............................35 Example
6.5. Intent Classification for Enterprise Solution...............39 Solution
6.5.1. Intent Users and Intent Types.............................39 Types
6.5.2. Intent Categories.........................................41 Categories
7. Conclusions...................................................43 Conclusions
8. Security Considerations.......................................43 Considerations
9. IANA Considerations...........................................43 Considerations
10. Contributors.................................................44
11. Acknowledgments..............................................44
12. Informative References.......................................44 References
Acknowledgments
Contributors
Authors' Addresses
1. Introduction
The vision of intent-based networks has attracted a lot of attention,
as 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, network without giving any instructions on how to do it. This
promise led caused many researcher-led activities and telecom companies
to start researching this new vision, vision and many Standards Development
Organization
Organizations (SDOs) to propose different intent frameworks.
This draft 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 are the intent
users, intent types, or intent solutions, etc. 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.
1.1. Research activities Activities
Intent-based networking is an active research topic which spans spanning across
different areas that could benefit from an intent classification and
taxonomy.
One such area is
Some examples include:
* intent expression and recognition ([Bezahaf21],
[Bezahaf19]), NILE [Bezahaf19],
[Jacobs18]). The use of a common classification
can could provide
consistency in the understanding of the various forms of intent
expressions being proposed and investigated.
Another area where this intent classification could contribute is
* the orchestration of cognitive autonomous RANs radio access networks
(RANs) [Banerjee21] where intents are classified based on their
content.
The work carried in
* intent network verification [Tian19] [Tian19], where the authors are proposing
working to propose new intent language is another candidate where
intent classification could be used advantageously. language.
Furthermore, this draft document is proving itself 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 [Bezhaf19], [Bezahaf19], for
advancing IBN-based VNF 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, and for proposing new approaches to service management
[Davoli21], or 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 draft document has been mentioned in
surveys addressing the topic of intelligent intent-based autonomous
networks [Mehmood21], [Mehmood21] [Szilagyi21].
This document also describes as well an example on how this proposal has been
successfully applied in an academic environment [IBN-POC] [POC-IBN] by
researchers in the area of SDN/NFV Software-Defined Networking / Network
Function Virtualization (SDN/NFV) for defining the scope of their
project. The specific problem addressed by researches 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-NMRG 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 conferences, and
workshops. The proposed intent taxonomy may be contributed as an
extension to this taxonomy for intent driven intent-driven management.
1.2. Standards and open source activities Open-Source Activities
Several SDOs and open source open-source projects, such as Internet Research Task
Force (IRTF)/ Network Management Research Group (NMRG), the IRTF NMRG, Open
Networking Foundation (ONF) [ONF] / Open Network Operating System
(ONOS) [ONOS], European Telecommunications Standards Institute
(ETSI)/Experiential (ETSI)
/ Experiential Networked Intelligence (ENI), and TMF with its
Autonomous Networks,
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 the Intent-based "Intent-Based Networking -
Concepts and Definitions document, [CLEMM]. 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 [CLEMM], [RFC9315], aims to become the
foundation for future intent-related topic discussions regarding the
NMRG.
The SDOs usually came come up with their own way of specifying an intent, intent
and with their own understanding of what an intent is. Besides that, Additionally, each
SDO defines a set of terms and level of abstraction, its
intended intent
users, and the applications and usage scenarios.
However, most intent approaches proposed by SDOs share the same
following
features:
o
* It must be declarative in nature, meaning that an intent user
specifies the goal on the network without specifying how to
achieve that goal.
o
* It must be vendor agnostic, agnostic in the sense that it abstracts the
network capabilities, capabilities or the network infrastructure from the intent
user, and it can be ported across different platforms.
o
* It must provide an easy-to-use interface, which simplifies the
intent users'
interaction of the intent users with the intent system through the
usage of 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
The focus of this document is on the definition of criteria enabling
to categorize
the categorization of intents from viewpoint of the stakeholders' viewpoint. stakeholders.
Concepts and definitions related to IBN are provided in [CLEMM]. [RFC9315].
This document mostly addresses intents in the context of network
intents, however
intents; however, other types of intents are not excluded, as
presented in section 4.4. Sections 4.4 and section 6.2. .
It is impossible to fully differentiate intents only by the common
characteristics followed by concepts, terms 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-
concept proof of
concepts (PoCs), research initiatives, or open source open-source projects.
The scope of intent classification in this document includes
solutions, intent users users, and intent types, and 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 for to future
scenarios, applications applications, or domains.
2. Acronyms Abbreviations
AI: Artificial Intelligence
CE: Customer Equipment
CFS: Customer Facing Service
CLI: Command Line Command-Line Interface
DB: Database
DC: Data Center
ECA: Event-Condition-Action Event Condition Action
GBP: Group-Based Policy
GPU: Graphics Processing Unit
IBN: Intent Based Intent-Based Network
NFV: Network Function Virtualization
O&M: Operations 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
A common and shared understanding of terms and definitions related to
IBN is provided in [CLEMM], [RFC9315] as follows:
o
Intent: A set of operational goals (that a network should meet) and
outcomes (that a network is supposed to deliver), deliver) defined in a
declarative manner without specifying how to achieve or implement
them.
o
Intent-Based Network: A network that can be managed using intent.
o
Policy: A set of rules that governs the choices in behaviour behavior of a
system.
o
Intent User: A user that defines and issues the intent request to
the intent-based management system.
Other definitions relevant to this draft, document, such as intent scope,
intent network scope, intent abstraction, intent abstraction, and
intent lifecycle life cycle are available in section Section 5.
4. Abstract Intent Requirements
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.
4.1. What is Intent? intent?
The term Intent "Intent" has become very widely used in the industry for
different purposes, purposes; sometimes it its use is not even in agreement with SDO
shared
SDO-shared principles mentioned in the Introduction section.[CLEMM] draft Section 1. [RFC9315] brings
clarification with relation to what an intent is and how it
differentiates from policies and services.
Different stakeholders have different perspective perspectives of the network and
therefore network;
therefore, they have different intent requirements. Their intent is
sometimes technical, non-technical, abstract abstract, or technology specific.
Therefore, it is important to start a discussion in the industry and
academia
academic communities about what intent is for different solutions and
intent users. It is also imperative to try to propose some intent
categories/ classifications
categories/classifications that could be understood by a wider
audience. This would help us define intent interfaces, domain-
specific languages, and models.
4.2. Intent Solutions and Intent Users
Intent types are defined by all aspects that are required to profile
different requirements to easily distinguish among between them. However,
in order to facilitate a clustered classification, we can focus on
two
aspects, aspects: the solution and intent user. They can be considered as 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 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 Operator |
| | Operators, Service Designers/App Developer |
| Networks | Designers / App Developers, Service Operators |
| | Customers/Subscribers Operators, Customers / Subscribers |
+--------------------+------------------------------------+
+------------+-------------------------------------+
| DC Networks | Cloud Administrator |
| | Administrators, Underlay Network Administrator |
| Networks | Network Administrators, Application Developers |
| | Customer/Tenants Developers, Customers / Tenants |
+--------------------+------------------------------------+
+------------+-------------------------------------+
| Enterprise Networks| | Enterprise Administrator Administrators, |
| Networks | Application Developers |
| | End-Users Developers, End Users |
+--------------------+------------------------------------+
+------------+-------------------------------------+
Table 1 - 1: Intent Solutions and Intent Users
These intent solutions and intent users represent a starting point
for the classification and are expendable through the methodology
presented in section Section 6.1. .
o
* For carrier networks scenario, network scenarios, for example, if a
customer/subscriber customer/
subscriber wants to watch high-definition video, then the intent
is to convert the video image to 1080p rate.
o 1080p.
* For DC networks scenario, 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 node / container below 50% and the maximum load of any
network link below 70%.
o
* For enterprise networks scenario, network scenarios, when hosting a video conference conference,
multiple remote accesses are required. An example of the intent
from the network administrator is: is as follows: for any end-user end user of
this application, the arrival time of hologram objects of all the
remote tele-presenters should be synchronised synchronized within 50ms 50 ms to
reach the destination viewer for each conversation session.
o
4.3. Benefits of Intents for Different Stakeholders
Current network APIs and CLIs are too complex because they are highly
integrated with the low level low-level concepts exposed by networks.
Customers, application developers developers, and end-users end users must not be required
to set IP addresses, VLANs, subnets, or ports, while whereas operators may
still want to have both more technical and network visibility. All
stakeholders would benefit from the simpler interfaces, like:
o Request such as:
* request gold VPN service between my sites A, B B, and C
o Provide
* provide CE redundancy for the customer sites
o Add
* add access rules to the network service
Operators and administrators manually troubleshoot and fix their
networks and services. They instead want to:
o
* simplify and automate network operations
o
* simplify definitions of network services
o
* provide simple customer APIs for value added value-added services (operators)
o
* be informed if the network or service is not behaving as requested
o
* enable automatic optimization and correction for selected
scenarios
o
* have systems that learn from historic information and behaviour behavior
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:
o
* build their own network services with their own policies via
simple interfaces, without becoming networking experts
o
* have their network services up and running based on intent and
automation only, without any manual actions or maintenance
o
4.4. Intent Types that need That Need to be supported Be Supported
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, supported in order to address
the requirements from different solutions and intent users:
o users.
* Customer service intent
o
- for customer self-service self service with SLA
o
- for service operator orders
o
* Network and underlay network service intent
o
- for service operator orders
o
- for intent driven intent-driven network configuration, verification,
correction
correction, and optimization
o
- for intent created and provided by the underlay network
administrator
o
* Network and underlay network intent
o
- for network configuration
o
- for automated lifecycle life-cycle management of network configurations
o
- for network resources (switches, routers, routing, policies,
and underlay)
o
* Cloud management intent
o
- for DC configuration, VMs, DB servers, APP and Application servers
o
- for communication between VMs
o
* Cloud resource management intent
o
- for cloud resource life-cycle management (policy driven (policy-driven self-
configuration and auto-scaling and recovery/optimization)
o
* Strategy intent
o
- for security, QoS, application policies, traffic steering, etc.
o
- for configuring and monitoring policies, alarms alarm generation for
non-compliance, and auto-recovery
o
- for design models and policies for network and network service
design
o
- for design workflows, models models, and policies for operational task
intents
o
* Operational task intents
o
- for network migration
o
- for device replacements
o
- for network software upgrades
o
- for automating any other tasks that operators/administrator
often perform
It is important to mention there 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- short
lived, but the modification of other intents has an impact on their
life-cycle,
life cycle, so those changes must continue to be continuously
monitored and self-corrected/self-optimized. self corrected/optimized.
5. Functional Characteristics and Behaviour Behavior
Intent can be used to operate immediately on a target (much like
issuing a command), command) or whenever it is appropriate (e.g., in response
to an event). In either case, intent has a number of behaviours behaviors that
serve to further organize its purpose, as described by the following
subsections.
5.1. Abstracting Intent Operation
The modelling modeling of intents can be abstracted using the following
three-tuple: three-
tuple:
{Context, Capabilities, Constraints}
o
* Context grounds the intent, intent and determines if it is relevant or not
for the current situation. Thus, context selects intents based on
applicability.
o
* Capabilities describe the functionality that the intent can
perform. Capabilities take different forms, forms depending on the
expressivity of the intent as well as the programming paradigm(s)
used.
o
* Constraints define any restrictions on the capabilities to be used
for that particular context.
Metadata can be attached via strategy templates to each of the
elements of the three-tuple, three-tuple and may be used to describe how the
intent should be used and how it operates, 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
capabilities, and constraints.
5.2. Intent User Types
Expanding on the introduction in section 4.2. , 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, and underlay
network administrators, or application developers.
o
* Customers and end-users end users do not necessarily know the functional and
operational details of the network that they are using.
Furthermore, they lack skills to understand such details; in fact,
such knowledge is typically not relevant to their job. In
addition, the network may not expose these details to its intent
users. This class of intent users focuses on the applications
that they run, run and uses services offered by the network. Hence,
they want to specify policies that provide consistent behaviour behavior
according to their business needs. They do not have to worry
about how the intents are deployed onto the underlying network, network and
especially,
especially whether the intents need to be translated to different
forms to enable network elements to understand them.
o
* Application developers work in a set of abstractions defined by
their application and programming environment(s). For example,
many application developers think in terms of objects (e.g., a
VPN). While this makes sense to the application developer, most
network devices do not have a VPN object per se; rather, the VPN
is formed through a set of configuration statements for that
device in concert with configuration statements for the other
devices that together make up the VPN. Hence, the view of
application developers matches the services provided by the
network,
network but may not directly correspond to other views of other
intent users.
o
* Network operators may have the knowledge of the underlying
network. However, they may not understand the details of the
applications and services of customers.
5.3. Intent Scope
Intents are used to manage the behaviour behavior of the networks they are
applied to and all intents are applied within a specific scope, such
as:
o Connectivity
* connectivity scope, if the intent creates or modifies a
connection.
o Security/privacy connection
* security/privacy scope, if the intent specifies the security
characteristics of the network, customers, or end-users.
o Application end users
* application scope, when the intent specifies the applications to
be affected by the intent request.
o request
* QoS scope, when the intent specifies the QoS characteristics of
the network. network
These intent scopes are expendable through the methodology presented
in section Section 6.1. .
5.4. Intent Network Scope
Regardless on of the intent user type, their intent request is affecting 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-WAN networks, radio access networks, SD-WANs, RANs, cloud edge, edges, cloud core, branch, cores,
branches, etc.
5.5. Intent Abstraction
Intent can be classified by whether it is necessary to feedback 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.
o For non-technical
* Non-technical intent users, they users do not care how the intent is
executed, or executed
nor do they care about the details of the network. As a result,
they do not need to know the configuration information of the
underlying network. They only focus on whether the intent
execution result achieves the goal, goal and the execution effect such
as the quality of completion and the length of execution. In this
scenario, we refer to an abstraction without technical feedback.
o For administrators,
* Administrators, such as network administrators, they perform intents,
such as allocating network resources, selecting transmission
paths, handling network failures, etc. They require multiple
feedback indicators for network resource conditions, congestion
conditions, fault conditions, etc. etc., after execution. In this
case, we refer to an abstraction with technical feedback.
As per intent the definition of "intent" provided in [CLEMM], [RFC9315], lower-level
intents are not considered to qualify as intents. However, we kept
this classification to identify any PoCs/Demos/Use PoCs / Demos / Use Cases that
still either require or implement a lower level of abstraction for
intents.
5.6. Intent Life-cycle Life Cycle
Intents can be classified into transient and persistent intents:
o If the
Transient: The intent is transient, it has no life-cycle management. As soon as the
specified operation is successfully carried out, the intent is finished,
finished and can no longer affect the target object.
o If the
Persistent: The intent is persistent, it has life-cycle management. Once the intent
is successfully activated and deployed, the system will keep all
relevant intents active until they are deactivated or removed.
5.7. Autonomous Driving Levels
In different phases of the autonomous driving network [TMF-auto], [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 level levels, the customer intent is is:
* automatically converted to configuration policies only, only while at
the higher levels the customer intent is levels,
* covering the full life cycle, it
is
* converted to both configuration and monitoring policies policies, and is
self-assured
* self assured using AI.
A typical example
Typical examples of autonomous driving network networks level 0 to 5 are
listed as
shown below.
o
Level 0 - Traditional manual network:
O&M personnel manually control the network and obtain network
alarms and logs.
- No intent
o
Level 1 - Partially automated network:
Automated scripts are used to automate service provisioning,
network deployment, and maintenance. Shallow The network provides shallow
perception of the network status and decision making suggestions of machine; suggestions.
- No intent
o
Level 2 - Automated network: Automation
This entails the automation of most service provisioning, network
deployment, and maintenance of a comprehensive perception of
network status and local machine
decision making; decision-making.
- simple intent on service provisioning
o
Level 3 - Self-optimization network: Deep
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
o
Level 4 - Partial autonomous network:
In a limited environment, people do not need to participate in
decision-making and networks can adjust itself. themselves.
- Intent based on limited AI
o
Level 5 - Autonomous network:
In different network environments and network conditions, the
network can automatically adapt to and adjust to meet people's
intentions.
- Intent based on AI
6. Intent Classification
This section proposes an approach to intent classification approach that may
help to classify mainstream intent related intent-related demos/tools.
The three classifications in this document have been proposed from
scratch, following
scratch (following the methodology presented, 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, i.e. resource scope, and the classification table has been
extended accordingly.
In the future, as new scenarios, applications, and domains are
emerging, 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 this point in time. the time of writing. Additional classifications will
most
probably see the likely come to light in the future.
The output of the intent classification is the intent taxonomy
introduced in the next sections.
Thus, subsections of this section first introduces section.
Thus, the subsections of Section 6 introduce the proposed intent
classification methodology, followed by the consolidated intent taxonomy for
three intent solutions, and then by the concrete examples of intent
classifications for three different intent solutions (e.g. (e.g., carrier
network, data center, and enterprise) that were derived using the
proposed methodology and then can be filled in for PoCs, demos, research projects
projects, or future drafts. documents.
6.1. Intent Classification Methodology
This section describes the methodology used to derive the initial
classification proposed in the draft. document. The proposed methodology
can be used to create new intent classifications from scratch, scratch by analysing
analyzing the solution knowledge. As well, the methodology can be
used to update existing classification tables by adding or removing
different solutions, intent users users, or intent types in order to cater for
to future scenarios, applications 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 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 - 1: Intent Classification Methodology
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, following defines
the steps to classify an intent:
1. The Receive the information provided in the solution knowledge is given as
input for identifying the intent solution (e.g. (e.g., carrier,
enterprise, and data center). Intent solutions are reviewed
against the existing classification and they can either be used if
present or added if not
there or removed there; if not needed, they can be removed
from the classification. classification (R1-U1).
2. Identify the intent user types (e.g. (e.g., customer, network
operators, service operators, etc.), review etc.). Review the existing intent classification and
classification. Then use the intent user type if present, present; add it
if it is not there or remove it if not needed (R2-U2).
3. Identify the types of intent (e.g. (e.g., network intent, customer
service intent) and then review intent). Review the existing classification and
use/add/remove then
use, add, or remove the intent type (R3-U3).
4. Identify the intent scopes (e.g. (e.g., connectivity, application)
based on the solution knowledge and then knowledge. Then, review the existing classification and
use/add/remove
classification. Use, add, or remove the identified intent scope
(R4-U4).
5. Identify the network scopes (e.g. (e.g., campus, radio access) and then access). Then,
review the existing classification and either use it classification. Either use, add, or add/remove remove
the identified network scope (R5-U5).
6. Identify the abstractions (e.g. (e.g., technical, non-technical) and
then non-technical).
Then, review the existing classification and use/add/remove either use, add, or
remove the abstractions (R6-U6).
7. Identify the life-cycle requirements (e.g. (e.g., persistent, transient)
and then
transient). Then, review the existing classification and use/add/remove classification. Either
use, add, or remove the life-
cycle life-cycle requirements (R7-U7).
8. Identify any new categories categories. Use and use/add add the newly identified
categories. New categories can be identified as new domains or
applications are emerging, emerge or as new areas of concern (e.g. (e.g., privacy,
compliance) might arise, which arise that are not listed in the current methodology.
6.2. Intent Taxonomy
The following taxonomy describes the various intent solutions, intent
user types, intent types, intent scopes, network scopes, abstractions
and life-cycle
abstractions, and life cycles. The taxonomy represents the output of
the intent classification tables for each of the solutions addressed (i.e.
(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. 6.4.2. 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 |Customer/Subscriber/End User |
+----------+ | |Network or Service Operator |
+>+Solutions
+>+Solution +--+ |Application Developer |
| +----------+ +->|Enterprise Administrator |
| | |Cloud Administrator |
| +----------+ | |Underlay Network Administrator |
+>+Intent +---+ +--------------------------------+
| |User | +--------------------------------+
| |Types |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
+>+Abstrac- +----+ |Transport Core Physical |
| |tion | | |Cloud Edge Logical |
| +----------+ | |Cloud Core Campus |
| +----------+ | +--------------------------------+
+>+Life | | +--------------------------------+
|cycle
|Cycle +--+ +>|Technical Non-Technical |
+----------+ | +--------------------------------+
| +--------------------------------+
+-->|Persistent Transient |
+--------------------------------+
Figure 2 - 2: Intent Taxonomy
6.3. Intent Classification for Carrier Solution
6.3.1. Intent Users and Intent Types
This section addresses step steps 1, 2, and 3 from Figure 1 and the 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/ |Customer |Customer self-service | Customer | Customer self service with SLA and |
| Subscriber |Service |value added service | Service | |Intent |Example: and value-added service. |
| | Intent | |
| | | Example: Always maintain a high quality |
| | |of | quality of service and high |
| | | bandwidth for gold gold-level |
| | | |level subscribers. |
| | |Operational | |
| | | Operation statement: Measure the |
| | |network | network congestion status, give |
| | |different | different adaptive parameters to |
| | |stations | stations of different priority, thus in| priority; |
| | | |heavy thus, in a heavy load situation, make the |
| | |bandwidth | make the bandwidth of the high-priority high- |
| | | |customers priority customers guaranteed. |
| | |At | At the same time time, ensure the overall |
| | |utilization | overall utilization of system, improve the |
| | | |the system and improve the overall |
| | | throughput of the system. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| |Strategy |Customer | Strategy | Customer designs models and policy |
| |Intent |intents | Intent | policy intents to be used by |
| | | customer service intents. |
| | | |intents. |
| | |Example: | Example: Request reliable service |
| | |during | service during peak traffic |
| | | periods for apps video-type apps. |
+-------------+-------------+---------------------------------------+
| Network | |of type video. Network |
+-------------------------------------------------------------------+
|Network |Network |Service Service provided by the network service |
|Operator |Service |operator
| Operator | Service | service operator to the customer |
| |Intent |(e.g. | Intent | (e.g., the service operator) operator). |
| | | | |Example:
| | | Example: Request network service with |
| | |delay | with delay guarantee for access |
| | | customer A. |
| +-------------+---------------------------------------+
| |Network |Network | Network | Network operator requests network-wide |
| |Intent |(service | Intent | network-wide (service underlay |
| | | or other network-wide| network-wide |
| | | |configuration) configuration) or network network- |
| | | resource configurations |
| | | |configurations (switches, routers, routing, or |
| | | |routing, policies). Includes |
| | |connectivity, | connectivity, routing, QoS, security, |
| | |application | security, application policies, traffic steering |
| | |policies, configuration | traffic steering policies, alarm |
| | | |monitoring policies, alarm generation for non-compliance, |
| | | |for non-compliance, auto-recovery, etc.| etc. |
| | | |
| |Example: | | Example: Request high priority queueing| |
| |for | | queuing for traffic of class A. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| |Operational |Network | Operational | Network operator requests execution of |
| |Task |any | Task Intent | execution of any automated task |
| | | other than network service |
| | | |Intent |service intent and network intent (e.g., |
| | | |(e.g. network migration, server |
| | |replacements, | replacements, device |
| | | replacements, or network |
| | | |network software upgrades). |
| | |Example: | |
| | | Example: Request migration of all |
| | |services | all services in network N to |
| | | backup path P.| P. | +-----------------------------------------------------+
| |Strategy |Network +-------------+---------------------------------------+
| | Strategy | Network operator designs models, policy| | |Intent |intents
| | Intent | policy intents, and workflows to |
| | | be used by network service |
| | |network service Intents, | intents, network intents, and |
| | | |intents and operational task intents. |
| | |Workflows | Workflows can automate any tasks that |
| | |network | that the network operator often performed in |
| | |addition | performs in addition to network |
| | | service intents and| and network |
| | | intents. |
| |network intents | | | |Example:
| | | Example: Ensure the load on any link in| |
| |the | | link in the network is not |
| | | higher than 50%. |
+-------------+-------------+---------------------------------------+
+-------------+-------------+---------------------------------------+
| Service | Customer | Service operator's customer orders, |
| Operator | Service | orders, customer service / SLA service, or |
| | Intent | SLA. |
| | | |
| | | Example: Provide service S with |
| | | guaranteed bandwidth for |
| | | customer A. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Network | Service operator's network orders / |
| | Service | orders / network SLA SLA. |
| | Intent | |
| | | Example: Provide network guarantees in| |
| | | guarantees in terms of security, low latency and |
| | | low latency, and high bandwidth bandwidth. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Operational | Service operator requests execution of| |
| | Task Intent | execution of any automated task other than |
| | Intent | other than customer service |
| | | intent and network service |
| | | intent. |
| | | service intent |
| | | Example: Update service operator |
| | | portal platforms and their software |
| | | software regularly. Move |
| | | services from network operator 1 |
| | | operator 1 to network operator 2. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Strategy | Service operator designs models, |
| | Intent | policy intents intents, and workflows to be |
| | | be used by customer service intents, |
| | | intents, network service intents and |
| | | intents, and operational task intents. Workflows |
| | | intents. Workflows can automate |
| | | any tasks task that the service |
| | | operator often performed performs in addition |
| | | addition to network service |
| | | intents and network| network intents. |
| | | intents. |
| | | Example: Request network service |
| | | guarantee to avoid network congestion |
| | | congestion during special periods |
| | | periods such as black Friday, Black Friday and |
| | | Christmas. |
+-------------+-------------+---------------------------------------+
| Application | Customer | Customer service intent API provided |
| Developer | Service | provided to the application developers |
| | Intent | developers. |
| | | |
| | | Example: API to request network to |
| | | to watch HD video 4K/8K. (4K/8K). |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Network | Network service intent API provided to| |
| | Service | provided to the application developers |
| | Intent | Example:API developers. |
| | | |
| | | Example: API to request network service| |
| | , monitoring | service, monitoring, and traffic |
| | | grooming. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Network | Network intent API provided to the |
| | Intent | the application developers developers. |
| | | |
| | | Example: API to request network |
| | | resources configuration. resource configurations. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Operational | Operational task intent API provided |
| | Task Intent | provided to the application developers. This is| |
| Intent | | developers. This is for the |
| | | trusted internal operator / |
| | | service providers / customer DevOps |
| | | DevOps. |
| | | |
| | | Example: API to request server |
| | | migrations. |
| +-----------------------------------------------------+ +-------------+---------------------------------------+
| | Strategy | Application developer designs models, |
| | Intent | policy models, policy, and workflows to |
| | | be used by customer service |
| | | customer service intents, network service |
| | | service intents intents, and operational task |
| | | task intents. This is for the trusted |
| | | trusted internal operator/service provider/ operator / |
| | | service provider / customer DevOps |
| | | DevOps. |
| | | |
| | | Example: API to design network load |
| | | balancing load-balancing strategies during |
| | | peak times| times. |
+-------------+-------------+---------------------------------------+
Table 2 - 2: Intent Classification for Carrier Solution
6.3.2. Intent Categories
This subsection addresses step steps 4 to 7 from Figure 1, and the 1. The following
are the proposed categories:
o
Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application,
C4=QoS
o
Network Scope:
o
Network Domain: C1=Radio Access, C2=Transport
Access, C3=Transport Aggregation, C4=Transport Core, C5=Cloud
Edge, C6=Cloud Core)
o Core
Network Function (NF) Scope: C1=VNFs, C2=PNFs
o
Abstraction (ABS): C1=Technical (with technical feedback),
C2=Non-technical C2=Non-
technical (without technical feedback) see section 5.2. .
o Life-cycle (see Section 5.2).
Life cycle (L-C): C1=Persistent (full life-cycle), life cycle), C2=Transient
(short lived)
6.3.3. Intent Classification Example
This section depicts contains an example on of how the methodology described in
section 6.1.
Section 6.1 can be used in order to classify intents introduced in
the 'A "A Multi-Level Approach to IBN' IBN" PoC demonstration [POC-IBN].
This PoC is led by academics carrying out research in the area of SDN/NFV
SDN/NFV, and the specific problem they are addressing is to apply 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 top-layer
virtual functions, functions and a set of virtual switches and/or routers of
L2/L3 L2/
L3 VNFs. A service chain intent expressed 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 by
step in section 6.1. , Section 6.1, the following can be derived:
1. The intent solution for both intents is carrier network.
2. The intent user type is network operator for the slice intent, intent and
service operator for the service chain intent.
3. The type of intent, intent is a network service intent for the slice
intent,
intent and a customer service intent for the service chain
intent.
4. The intent scopes are connectivity and application.
5. The network scope is VNF, cloud edge, and cloud core.
6. The abstractions are with technical feedback for the slice intent, intent
and without technical feedback for the service chain intent intent.
7. The life-cycle life cycle is persistent.
The following table shows how to represent this information in a
tabular form. The 'X' "X" in the table refers to the slice intent, and intent; the 'Y'
"Y" in the table refers to the service chain intent.
+---------+---------+-----------+-----+-----------------+-----+-----+
| Intent | Intent | Intent | NF | Network | ABS
+==========+===========+===========+=====+=================+=====+=====+
|Intent |Intent Type|Intent |NF |Network |ABS |L-C |
|User | User | Type | Scope |Scope| Scope |Scope |Scope|Scope | | |
| | +-----------+-----+-----------------+-----+-----+ +==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
| | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|
+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Customer
+==========+===========+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
|Customer/ |Customer | | | | | | | | | | | | | | | | |
|/ Sub- |Service
|Subscriber|Service | | | | | | | | | | | | | | | | |
| scriber |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Strategy | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Network |Network |X | |X | |X | | | | | |X | |X | |X | |
|Operator |Service | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Network | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Operatio-| | +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Operational| | | | | | | | | | | | | | | | |nal Task | | | | | | | | | | |
| | | | | |
| |Intent | |Task Intent| | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Strategy | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | |
|Operator |Service | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Network | | | | | | | | | | | | | | | | |
| |Service | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Op Task | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Strategy | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|App |Customer | | | | | | | | | | | | | | | | |
|Developer|Intent
|Developer |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Network | | | | | | | | | | | | | | | | |
| |Service | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Network | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Op Task | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
| +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |Strategy | | | | | | | | | | | | | | | | |
| |Intent | | | | | | | | | | | | | | | | |
+---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Table 3 -
+----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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
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 / Customer/ | Customer | Customer self-service self service via tenant |
| Tenants | Service | portal. |
| | | |
| | | Example: Request GPU computing and |
| | | storage resources to meet 10k video |
| | | 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| |
| | | service in special and daily times. |
| | | times. |
+-------------------------------------------------------------------+
+---------------+-------------+------------------------------------+
| Cloud | Cloud | Configuration of VMs, DB Servers, |
| Cloud Administrator | Management | app servers, connectivity, and communication |
| Administrator | Intent | communication between servers and VMs. |
| | | |
| | | Example: Request connectivity |
| | | between VMs A,B,and A, B, and C in network N1.| | +---------------------------------------------------+
| | | N1. |
| +-------------+------------------------------------+
| | Cloud | Policy-driven self-configuration and| self configuration |
| | Resource | and recovery / optimization recovery/optimization. |
| | Management | |
| | Intent | Example: Request automatic life life- |
| | Intent |-cycle | 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 |
| | | in network N1. |
| | |Operational | |
| | | Operational statement: an An intent to |
| | |update | to update a system might reconfigure the| |
| |system | | reconfigure the system topology |
| | | (connect to a service| service and to |
| | | |and to peers), exchange data (update the |
| | | |the content), and uphold a certain QoE |
| | | |QoE level (allocate sufficient network |
| | | |network resources). The network, Thus, the network |
| | | |thus, carries out the necessary |
| | |configuration | configuration to best serve such an |
| | |intent; e.g. | an intent, e.g., setting up direct |
| | |connections | connections between terminals, terminals and |
| | |allocating | allocating fair shares of router |
| | |queues | queues considering other network |
| | |services. | +---------------------------------------------------+ services. |
| +-------------+------------------------------------+
| | Strategy | Cloud administrator designs models, |
| | Intent | models, policy intents intents, and workflows to be |
| | | workflows to be used by other |
| | | intents. Automate any tasks that |
| | | tasks that administrator often performs in |
| | | performs, in addition to life-cycle life cycle of cloud |
| | | of cloud management intents and cloud |
| | | 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. |
| Administrator | Service | administrator. |
| | Intent | |
| | | Example: Request underlay service |
| | Intent | between DC1 and DC2 with bandwidth |
| | | 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 the 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 & 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, VMs or DB Servers.| | Application +---------------------------------------------------+
| Developer | | 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 |
| | | correlation. |
| +---------------------------------------------------+ +-------------+------------------------------------+
| | Strategy | Application developer designs |
| | Intent | models, policy intents intents, and |
| | | building blocks to be used by |
| | | other intents. This is for the |
| | | trusted internal DCN DevOps. |
| | | |
| | | Example: API to request load load- |
| | | balancing thresholds. |
+---------------+-------------+-------------------------------------+
+---------------+-------------+------------------------------------+
Table 4 - 3: Intent Classification for Data Center Network Solutions
6.4.2. Intent Categories
The following are the proposed categories:
o
Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, C4=QoS C5=Storage
C4=QoS, C5=Storage, C6=Compute
o
Network Scope
o
Network Domain: DC Network
o
DCN Network (DCN Net) Scope: C1=Logical, C2=Physical
o
DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical
o
Abstraction (ABS): C1=Technical (with technical feedback),
C2=Non-technical C2=Non-
technical (without technical feedback), see section 5.2.
o Life-cycle feedback) (see Section 5.2).
Life cycle (L-C): C1=Persistent (full life-cycle), life cycle), C2=Transient
(short lived)
6.4.3. Intent Classification Example
This section depicts an example on how the methodology described in
section 6.1.
Section 6.1 can be used by the research community to classify
intents. As mentioned in 6.3.3. Section 6.3.3, a successful use of the
classification proposed in this draft document is introduced in the 'A Multi-
Level Approach to IBN' 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 and SDN/NFV;
the specific problem they are addressing is to apply 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. , Section 6.3.3, a slice intent expresses a
request for a network slice with two types of components: a set of
top layer
top-layer virtual functions, functions and a set of virtual switches and/or
routers of L2/L3 VNFs.
Following the intent classification methodology described step-by- step by
step in section 6.1. , Section 6.1, we identify the following:
1. The intent solution is for the data center.
2. The intent user type is the cloud administrator for the slice
intent and service chain intent.
3. The type of intent, intent is a cloud management intent, intent for the slice
intent.
4. The intent scopes are connectivity and application.
5. The network scope is logical, and logical; the resource scope is virtual.
6. The abstractions are with technical feedback for the slice
intent.
7. The life-cycle life cycle is persistent.
The following table shows how to represent this information in a
tabular form, where form; the 'X' "X" in the table refers to the slice intent.
+---------+-------------+-----------------+-----+-----+-----+-----+
+===========+=============+=================+=====+=====+=====+=====+
|Intent | Intent | User| Intent | DCN | DCN | ABS | L-C |
|User | Type |Intent |DCN |DCN |ABS |L-C | Scope
| Res | Net |Scope |Res |Net | | |
| | +-----------------+-----+-----+-----+-----+ +==+==+==+==+==+==+==+==+==+==+==+==+==+==+
| | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Customer
+===========+=============+==+==+==+==+==+==+==+==+==+==+==+==+==+==+
|Customer/ | Customer | | | | | | | | | | | | | | |
|/Tenants
|Tenants | Service | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | Strategy | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Cloud |
+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|Cloud Admin| Cloud |X | |X | | | |X | |X | |X | |X | |
| | Management | | | | | Admin | Management |X | |X | | | |X | |X | |X | |X | |
| | 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|
|Developer | Management | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | Cloud | | | | | | | | | | | | | | |
| | Resource | | | | | | | | | | | | | | |
| | Management | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | Underlay | | | | | | | | | | | | | | |
| | Network | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | Underlay | | | | | | | | | | | | | | |
| | Network | | | | | | | | | | | | | | |
| | Resource | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | Operational | | | | | | | | | | | | | | |
| | Task Intent | | | | | | | | | | | | | | |
| +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | Strategy | | | | | | | | | | | | | | |
| | Intent | | | | | | | | | | | | | | |
+---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Table 5 -
+-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: Intent Classification Example for Data Center Network
Solutions
6.5. Intent Classification for Enterprise Solution
6.5.1. Intent Users and Intent Types
The following table describes the intent users in enterprise
solutions and their intent types.
+--------------+-------------+-------------------------------------+
+---------------+-------------+------------------------------------+
| Intent User | Intent Type | Intent Type Description |
+--------------+---------------------------------------------------+
+---------------+-------------+------------------------------------+
| End-User End User | Customer | Enterprise end-user self-service or end user self service |
| | Service | applications, or applications; enterprise may have |
| | Intent | have multiple types of end-users. end users. |
| | | |
| | | Example: Request access to VPN |
| | | service. |
| | | Request video conference between |
| | | end-user between end user A and B. |
| +---------------------------------------------------+ +-------------+------------------------------------+
| | Strategy | This includes models and policy |
| | Intent | intents designed by end-users end users to be |
| | | be used by end-user intents and their |
| | | their applications. |
| | | |
| | | Example: Create a video conference |
| | | type for a weekly meeting. |
+------------------------------------------------------------------+
|Enterprise
+---------------+-------------+------------------------------------+
| Enterprise | Network | Service provided by the |
|Administrator
| Administrator | Service | administrator to the end-users end users and |
|
|(internal (internal or | Intent | and their applications. |
| MSP) | | |
| | | Example: For any end-user end user of |
| | | application X, the arrival of |
| | | hologram objects of all the remote |
| | | tele-presenters should be |
| | | synchronised synchronized within 50ms 50 ms to reach |
| | | the destination viewer for each |
| | | conversation session. Create |
| | | Create management VPN connectivity for |
| | | for type of service A. |
| | | |
| | | Operational statement: The job of |
| | | the network layer is to ensure that |
| | | that the delay is between 50-70ms through| 50-70 ms |
| | | through the routing algorithm. At the same |
| | | time,the the same time, the node resources need to meet| |
| | | need to meet the bandwidth |
| | | requirements of 4K video |
| | | video conferences. |
+------------------------------------------------------------------+
| +-------------+------------------------------------+
| | Network | Administrator requires network wide network- |
| | Intent | wide configuration (e.g. underlay, (e.g., underlay |
| | | or campus) or resource configuration |
| | | configuration (switches, routers, |
| | | or policies). |
| | | |
| | | Example: Configure switches in |
| | | campus network 1 to prioritise prioritize |
| | | traffic of type A. Configure |
| | | Configure YouTube as business |
| | | non-relevant. |
| +---------------------------------------------------+ +-------------+------------------------------------+
| | Operational | Administrator requests execution of |
| | Task Intent | of any automated task other than |
| | | network service intents and network |
| | | network intents. |
| | | |
| | | Example: Request network security |
| | | automated tasks such as web |
| | | filtering and DDOS DDoS cloud protection.| | +---------------------------------------------------+
| | | protection. |
| +-------------+------------------------------------+
| | Strategy | Administrator designs models, policy| |
| | Intent | intents policy intents, and workflows to |
| | | be used by other intents. |
| | | other intents. Automate any tasks that the |
| | | that 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 |
| | | hosting a video conference. |
| +---------------------------------------------------+ +-------------+------------------------------------+
| | Network | Network API provided to application |
| | Intent | application developers. |
| | | |
| | | Example: API for request of network requesting |
| | | devices network device configuration. |
| +---------------------------------------------------+ +-------------+------------------------------------+
| | Operational | Operational task intent API provided| |
| | Task Intent | provided to the trusted application developer| |
| | | application developer (internal |
| | | DevOps). |
| | | |
| | | Example: API for requesting |
| | | automatic monitoring and |
| | | interception for network security security. |
| +---------------------------------------------------+ +-------------+------------------------------------+
| | Strategy | Application developer designs |
| | Intent | models, policy intents intents, and building |
| | | building blocks to be used by other intents. |
| | | other intents. This is for the |
| | | trusted internal DevOps. |
| | | DevOps. |
| | | Example: API for strategy intent in |
| | | in case of emergencies. |
| | | |
+--------------+-------------+-------------------------------------+
+---------------+-------------+------------------------------------+
Table 6 - 4: Intent Classification for Enterprise Solution
6.5.2. Intent Categories
The following are the proposed categories:
o
Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application,
C4=QoS
o
Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN
o
Abstraction (ABS): C1=Technical (with technical feedback),
C2=Non-technical C2=Non-
technical (without technical feedback), see section 5.2.
o Life-cycle feedback) (see Section 5.2)
Life cycle (L-C): C1=Persistent (full life-cycle), life cycle), C2=Transient
(short lived)
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 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 | | | | | | | | | | | |
+---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
Table 7 -
Figure 5: Intent Categories for Enterprise Solution
7. Conclusions
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 on to
what an intent represents for different stakeholders through the
proposal of an Intent Classification 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 topic discussions within the NMRG.
The benefits of this intent classification draft document in the research
community have been demonstrated through a PoC implementation [POC-
IBN]
[POC-IBN] in which the draft's document's concepts have been applied at
different levels corresponding to different stakeholders have been applied to. stakeholders.
8. Security Considerations
This document identifies the security and privacy as categories of the
intent scope. The intents could be solely security intents and
privacy intents intents, or security can be embedded in the intents that
include also connectivity, application, and QoS scope.
Security and privacy scope, scope is when the intent specifies the security
characteristics of the network, customers, or end-users, end users, and privacy
for customers and end-users. end users.
More details of these security intents would will be described in future
documents that specify architecture, functionality, user intents intents, and
models. As well, an An analysis of the security considerations of the overall
intent-based system is provided in section 10 Section 9 of [CLEMM]. [RFC9315].
9. IANA Considerations
This document has no actions for IANA. IANA actions.
10. 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 drafts:
Ying Chen, China Unicom
John Strassner, Huawei
Weiping Xu, Huawei
Richard Meade, Huawei
11. Acknowledgments
This document has benefited from reviews, suggestions, comments Informative References
[Banerjee21]
Banerjee, A., Mwanje, S., and
proposed text provided by the following members, listed G. Carle, "Contradiction
Management in
alphabetical order: Mehdi Intent-driven Cognitive Autonomous RAN",
September 2021.
[Bezahaf19]
Bezahaf, Brian E Carpenter, Laurent
Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome
Francois, Pedro Andres Aranda Gutierrez, Daniel M., Hernandez, M., Bardwell, L., Davies, E.,
Broadbent, M., King, Branislav
Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff
Tantsura.
We thank to Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide
Borsatti, for contributing with their 'A multi-level approach to
IBN' PoC demonstration a first attempt to adopt D., and D. Hutchison, "Self-Generated
Intent-Based System", 10th International Conference on
Networks of the intent
classification methodology.
12. Informative References 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. C., and N. Race, N., "To All
Intents and Purposes: Towards Flexible Intent Expression,"
2021 Expression",
IEEE 7th International Conference on Network
Softwarization (NetSoft), 2021.
[Bezhaf19] Bezahaf, M., Hernandez, MP, Bardwell, L., Davies, E.,
Broadbent, M.,King, D.
DOI 10.1109/NetSoft51509.2021.9492554, July 2021,
<https://doi.org/10.1109/NetSoft51509.2021.9492554>.
[Davoli21] Davoli, G., "Programmability and Hutchison, D. , "Self-Generated
Intent-Based System," 2019 10th International Conference on
Networks Management of the Future (NoF), 2019. Software-
Defined Network Infrastructures", 2021.
[IFIP-NSM] IFIP, "Network and Service Management Taxonomy",
<https://www.simpleweb.org/ifip/taxonomy.html>.
[Jacobs18] Jacobs, A.S., Pfitscher,R.J., A., Pfitscher, R., Ferreira, R.A., R., and L. Granville, L.Z.,
"Refining Network Intents for Self-Driving Networks",
Proceedings of the Afternoon Workshop on Self-
Driving Self-Driving
Networks (SelfDN 2018), 2018.
[Banerjee21] Banerjee,A., Mwanje. S. and Carle, G., "Contradiction
Management in Intent-driven Cognitive Autonomous RAN",
2021.
[Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H. H., Ye, Q., Wang, C.,
and Zhao, B. Y., "Safely and automatically updating in-
network ACL configurations with intent language", SIGCOMM
'19, 2019. (SelfDN), DOI 10.1145/3229584.3229590, August
2018, <https://doi.org/10.1145/3229584.3229590>.
[Leivadeas21]
Leivadeas, A. and M. Falkner, M., "VNF Placement Problem: A
Multi-Tenant Intent-Based Networking Approach," Approach", 24th
Conference on Innovation in Clouds, Internet and Networks
and Workshops (ICIN), 2021.
[Davoli21] Davoli, G., "Programmability and Management of Software-
defined Network Infrastructures", 2021.
[Padovan20] Padovan, S., "Design and Implementation of a Blockchain
Intent Management System", 2020. DOI 10.1109/ICIN51074.2021.9385553,
March 2021,
<https://doi.org/10.1109/ICIN51074.2021.9385553>.
[Mehmood21]
Mehmood, K., Kralevska, K., and D. Palma, D., "Intent-driven
Autonomous Network and Service Management in Future
Networks: A Structured Literature Review", 2021.
[Szilagyi21] Szilagyi, P., "I2BN: Intelligent Intent Based Networks",
Journal
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 ICT Standardization, 2021. a Blockchain
Intent Management System", November 2020.
[POC-IBN] Barbara Martini, Walter B., Cerroni, Molka W., Gharbaoui, Davide M., and D. Borsatti,
"A multi-level approach Multi-Level Approach to IBN", IETF 108 Hackathon
Report, July 2020,
https://www.ietf.org/proceedings/108/slides/slides-108-
<https://www.ietf.org/proceedings/108/slides/slides-108-
nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-
ibn-02
[IFIP-NSM] IFIP - Network and Service Management Taxonomy,
https://www.simpleweb.org/ifip/taxonomy.html
[ONF] ONF, "Intent Definition Principles", 2017,
<https://www.opennetworking.org/images/stories/downloads/
sdn-resources/technical-reports/TR-
523_Intent_Definition_Principles.pdf>.
[ONOS] ONOS, "ONOS Intent Framework", 2017,
<https://wiki.onosproject.org/display/ONOS/Intent+Framework
/>.
[CLEMM] A.
ibn-02>.
[RFC9315] Clemm, L. A., Ciavaglia, L. L., Granville, L. Z., and J.
Tantsura, "Intent-
Based "Intent-Based Networking - Concepts and Overview", Work in
Progress, draft-irtf-nmrg-ibn-concepts-definitions-05,
February
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://tools.ietf.org/html/draft-irtf-nmrg-
ibn-concepts-definitions-05
[TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper
<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
Autonomous 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 The Telecoms Industry, inform.tmforum.org, 15 May, Industry", May 2019.
[RFC2119] Bradner, S., "Key words for use
Acknowledgments
This document has benefited from reviews, suggestions, comments, and
proposed text provided by the following members listed in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
alphabetical order: Mehdi Bezahaf, Brian E. Carpenter, B., Jiang, S., and L. Laurent
Ciavaglia, "Autonomic
Networking: Definitions Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome
Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav
Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, and Design Goals", RFC 7575, June
2015.
[RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
M., Bi, J., Cheng, Y., Jeff
Tantsura.
We thank Barbara Martini, Walter Cerroni, Molka Gharbaoui, and D. Zhang, "Policy-Based
Management Framework Davide
Borsatti for contributing with their "A multi-level approach to IBN"
PoC demonstration, a first attempt to adopt the Simplified Use of Policy
Abstractions (SUPA)", March 2018.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson,
M., Perry, J., Waldbusser, S., "Terminology for Intent-
driven Management", RFC 3198, November 2001.
[RFC6020] Bjorlund, M., "YANG - A Data Modelling Language for Network
Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W.
Roome, S. Shalunov, R. Woundy "Application-Layer Traffic
Optimization (ALTO) Protocol", September 2014.
[ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017,
<https://datatracker.ietf.org/doc/draft-du-anima-an-
intent/>.
[SUPA] Strassner, J., "Simplified Use of Policy Abstractions",
2017, <https://datatracker.ietf.org/doc/draft-ietf-supa-
generic-policy-info-model/?include_text=1>.
[ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun,
"Autonomic IPv6 Edge Prefix Management in Large-scale
Networks", draft-ietf-anima-prefix-management-07 (work intent classification
methodology.
Contributors
The following people all contributed to creating this document:
Contributed significant text:
Xueyuan Sun
China Telecom
Will (Shucheng) Liu
Huawei
Contributed text in
progress), December 2017. 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
No.118 Xizhimennei street,
Xicheng District
No.118 Xizhimennei street
Beijing
100035
P.R.
China
Email: lichen.bri@chinatelecom.cn lichen6@chinatelecom.cn
Olga Havel
Huawei Technologies
Ireland
Email: olga.havel@huawei.com
Adriana Olariu
Huawei Technologies
Ireland
Email: adriana.olariu@huawei.com
Pedro Martinez-Julia
NICT
Japan
Email: pedro@nict.go.jp
Jeferson Campos Nobre
Federal University of Rio Grande do Sul (UFRGS)
Porto Alegre Alegre-RS
Brazil
Email: jcnobre@inf.ufrgs.br
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid
28006 Madrid
Spain
Email: diego.r.lopez@telefonica.com