idnits 2.17.1
draft-irtf-nmrg-ibn-intent-classification-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 10, 2021) is 897 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'Bezahaf19' is mentioned on line 140, but not defined
== Missing Reference: 'Jacobs18' is mentioned on line 140, but not defined
== Missing Reference: 'IBN-POC' is mentioned on line 166, but not defined
== Unused Reference: 'RFC2119' is defined on line 1712, but no explicit
reference was found in the text
== Unused Reference: 'RFC7575' is defined on line 1715, but no explicit
reference was found in the text
== Unused Reference: 'RFC8328' is defined on line 1720, but no explicit
reference was found in the text
== Unused Reference: 'RFC3198' is defined on line 1725, but no explicit
reference was found in the text
== Unused Reference: 'RFC6020' is defined on line 1738, but no explicit
reference was found in the text
== Unused Reference: 'RFC7285' is defined on line 1742, but no explicit
reference was found in the text
== Unused Reference: 'ANIMA' is defined on line 1746, but no explicit
reference was found in the text
== Unused Reference: 'ONF' is defined on line 1750, but no explicit
reference was found in the text
== Unused Reference: 'SUPA' is defined on line 1759, but no explicit
reference was found in the text
== Unused Reference: 'ANIMA-Prefix' is defined on line 1763, but no
explicit reference was found in the text
== Outdated reference: A later version (-09) exists of
draft-irtf-nmrg-ibn-concepts-definitions-05
Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group C. Li
2 Internet Draft China Telecom
3 Intended status: Informational O. Havel
4 Expires: May 2022 A. Olariu
5 Huawei Technologies
6 P. Martinez-Julia
7 NICT
8 J. Nobre
9 UFRGS
10 D. Lopez
11 Telefonica, I+D
12 November 10, 2021
14 Intent Classification
15 draft-irtf-nmrg-ibn-intent-classification-05
17 Abstract
19 Intent is an abstract, high-level policy used to operate the network.
20 Intent management system includes an interface for users to input
21 requests and an engine to translate the intents into the network
22 configuration and manage their life-cycle.
24 This document discusses mostly the concept of network intents, but
25 other types of intents are also being considered. Specifically, it
26 highlights stakeholder perspectives of intent, methods to classify
27 and encode intent, the associated intent taxonomy, and defines
28 relevant intent terms where necessary. This document provides a
29 foundation for intent related research and facilitates solution
30 development.
32 This document is a product of the IRTF Network Management Research
33 Group (NMRG).
35 Status of this Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at http://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
50 This Internet-Draft will expire on May 9, 2020.
52 Copyright Notice
54 Copyright (c) 2021 IETF Trust and the persons identified as the
55 document authors. All rights reserved.
57 This document is subject to BCP 78 and the IETF Trust's Legal
58 Provisions Relating to IETF Documents
59 (http://trustee.ietf.org/license-info) in effect on the date of
60 publication of this document. Please review these documents
61 carefully, as they describe your rights and restrictions with respect
62 to this document. Code Components extracted from this document must
63 include Simplified BSD License text as described in Section 4.e of
64 the Trust Legal Provisions and are provided without warranty as
65 described in the Simplified BSD License.
67 Table of Contents
69 1. Introduction ................................................ 4
70 1.1. Research activities..................................... 4
71 1.2. Standards and open source activities.................... 5
72 1.3. Scope .................................................. 6
73 2. Acronyms .................................................... 7
74 3. Definitions ................................................. 8
75 4. Abstract Intent Requirements................................. 8
76 4.1. What is Intent?......................................... 8
77 4.2. Intent Solutions and Intent User ....................... 9
78 4.3. Benefits of Intents to Respond to Network Requirements.. 11
79 4.4. Intent Types that need to be supported ................. 12
80 5. Functional Characteristics and Behaviour .................... 14
81 5.1. Abstracting Intent Operation ........................... 14
82 5.2. Intent User Types ...................................... 15
83 5.3. Intent Scope .......................................... 16
84 5.4. Intent Network Scope ................................... 16
85 5.5. Intent Abstraction ..................................... 16
86 5.6. Intent Life-cycle ...................................... 17
87 5.7. Autonomous Driving Levels .............................. 17
88 6. Intent Classification ....................................... 18
89 6.1. Intent Classification Methodology ...................... 19
90 6.2. Intent Taxonomy ........................................ 22
91 6.3. Intent Classification for Carrier Solution ............. 24
92 6.3.1. Intent Users and Intent Types ..................... 24
93 6.3.2. Intent Categories ................................. 28
94 6.3.3. Intent Classification Example ..................... 28
95 6.4. Intent Classification for Data Center Network Solutions. 32
96 6.4.1. Intent Users and Intent Types ..................... 32
97 6.4.2. Intent Categories ................................. 36
98 6.4.3. Intent Classification Example ..................... 36
99 6.5. Intent Classification for Enterprise Solution .......... 40
100 6.5.1. Intent Users and Intent Types ..................... 40
101 6.5.2. Intent Categories ................................. 42
102 7. Conclusions ................................................ 44
103 8. Security Considerations ..................................... 44
104 9. IANA Considerations ......................................... 44
105 10. Contributors ............................................... 45
106 11. Acknowledgments ............................................ 45
107 12. References ................................................. 45
108 12.1. Normative References .................................. 45
109 12.2. Informative References ................................ 46
111 1. Introduction
113 The vision of intent-driven networks has attracted a lot of
114 attention, as it promises to simplify the management of networks by
115 human operators. This is done by simply specifying what should happen
116 on the network, without giving any instructions on how to do it. This
117 promise led many researcher-led activities and telecom companies to
118 start researching this new vision, and many Standards Development
119 Organization (SDOs) to propose different intent frameworks.
121 This draft proposes an intent classification methodology and an
122 intent taxonomy. The scope of these proposals is to ensure a common
123 understanding in the research community in terms of what are the
124 intent users, intent types, or intent solutions, etc. for specific
125 scenarios that are being considered.
127 The document represents the consensus of the RG. During the
128 document's lifecycle it received many positive expressions of support
129 and detailed reviews beyond the authors. Only in the last call period
130 it received more than 12 positive expressions of support and more
131 than 5 detailed reviews. It is published for informational purposes.
133 1.1. Research activities
135 Intent-based networking is an active research topic which spans
136 across different areas that could benefit from an intent
137 classification and taxonomy.
139 One such area is intent expression and recognition ([Bezahaf21],
140 [Bezahaf19]), NILE [Jacobs18]). The use of a common classification
141 can provide consistency in the understanding of the various forms of
142 intent expressions being proposed and investigated.
144 Another area where this intent classification could contribute is the
145 orchestration of cognitive autonomous RANs [Banerjee21] where intents
146 are classified based on their content.
148 The work carried in intent network verification [Tian19] where the
149 authors are proposing new intent language is another candidate where
150 intent classification could be used advantageously.
152 Furthermore, this draft is proving itself already extremely relevant
153 to the research community as it has been used as the basis for
154 proposing self-generated Intent-based systems [Bezhaf19], for
155 advancing IBN-based VNF placement solutions that rely on defining
156 user intent profiles corresponding to abstract network services
157 [Leivadeas21], for improving existing solutions in provisioning
158 intent-based networks, and proposing new approaches to service
159 management [Davoli21], or even for defining grammars for users to
160 specify the high-level requirements for blockchain selection in the
161 form of intent [Padovan20]. As well, the draft has been mentioned in
162 surveys addressing the topic of intelligent intent-driven autonomous
163 networks [Mehmood21], [Szilagyi21].
165 The document describes as well an example on how this proposal has
166 been successfully applied in an academic environment [IBN-POC] by
167 researchers in the area of SDN/NFV for defining the scope of their
168 project. The specific problem addressed by researches is how to
169 apply intent concepts at different levels that correspond to
170 different stakeholders.
172 IEEE-CNOM, IRTF-NMRG and IFIP WG6.6 have developed a taxonomy for
173 network and service management [IFIP-NSM] that is used by the
174 research community in network management and operations to structure
175 the research area through a well-defined set of keywords and to
176 improve quality of reviews in submissions to journals, conferences
177 and workshops. The proposed intent taxonomy may be contributed as an
178 extension to this taxonomy for intent driven management.
180 1.2. Standards and open source activities
182 Several SDOs and open source projects, such as Internet Research Task
183 Force (IRTF)/ Network Management Research Group (NMRG), Open
184 Networking Foundation (ONF) [ONF]/Open Network Operating System
185 (ONOS) [ONOS], European Telecommunications Standards Institute
186 (ETSI)/Experiential Networked Intelligence (ENI), TMF with its
187 Autonomous Networks, have proposed intents for defining a set of
188 network operations to execute in a declarative manner.
190 More recently, the IRTF NMRG is working on the Intent-based
191 Networking - Concepts and Definitions document, [CLEMM]. This
192 document clarifies the concept of "Intent" and provides an overview
193 of the functionality that is associated with it. The goal is to
194 contribute towards a common and shared understanding of terms,
195 concepts, and functionality that can be used as the foundation to
196 guide further definition of associated research and engineering
197 problems and their solutions.
199 The present document, together with [CLEMM], aims to become the
200 foundation for future intent-related topic discussions regarding the
201 NMRG.
203 The SDOs usually came up with their own way of specifying an intent,
204 and with their own understanding of what an intent is. Besides that,
205 each SDO defines a set of terms and level of abstraction, its
206 intended intent users, and the applications and usage scenarios.
208 However, most intent approaches proposed by SDOs share the same
209 following features:
211 o It must be declarative in nature, meaning that an intent user
212 pecifies the goal on the network without specifying how to
213 achieve that goal.
215 o It must be vendor agnostic, in the sense that it abstracts the
216 network capabilities, or the network infrastructure from the
217 intent user, and it can be ported across different platforms.
219 o It must provide an easy-to-use interface, which simplifies the
220 intent users' interaction with the intent system through the usage
221 of familiar terminology or concepts.
223 It should be able to detect and resolve intent conflicts, which
224 include, for example, static (compile-time) conflicts and dynamic
225 (run-time) conflicts.
227 1.3. Scope
229 This document mostly addresses intents in the context of network
230 intents, however other types of intents are not excluded, as
231 presented in section 4.4. and section 6.2. .
233 It is impossible to fully differentiate intents only by the common
234 characteristics followed by concepts, terms and intentions. This
235 document clarifies what an intent represents for different
236 stakeholders through a classification on various dimensions, such as
237 solutions, intent users, and intent types. This classification
238 ensures common understanding among all participants and is used to
239 determine the scope and priority of individual projects, proof-of-
240 concept (PoCs), research initiatives, or open source projects.
242 The scope of intent classification in this document includes
243 solutions, intent users and intent types, and the initial
244 classification table is made according to this scope. The
245 methodology presented can be used to update the classification
246 tables by adding or removing different solutions, intent users, or
247 intent types to cater for future scenarios, applications or domains.
249 2. Acronyms
251 AI: Artificial Intelligence
253 CE: Customer Equipment
255 CFS: Customer Facing Service
257 CLI: Command Line Interface
259 DB: Database
261 DC: Data Center
263 ECA: Event-Condition-Action
265 GBP: Group-Based Policy
267 GPU: Graphics Processing Unit
269 IBN: Intent Based Network
271 NFV: Network Function Virtualization
273 O&M: Operations & Maintenance
275 ONF: Open Networking Foundation
277 ONOS: Open Network Operating System
279 PNF: Physical Network Function
281 QoE: Quality of Experience
283 RFS: Resource Facing Service
285 SDO: Standards Development Organization
287 SD-WAN: Software-Defined Wide-Area Network
288 SLA: Service Level Agreement
290 SUPA: Simplified Use of Policy Abstractions
292 VM: Virtual Machine
294 VNF: Virtual Network Function
296 3. Definitions
298 A common and shared understanding of terms and definitions related
299 to IBN is provided in [CLEMM], as follows:
301 o Intent: A set of operational goals (that a network should meet)
302 and outcomes (that a network is supposed to deliver), defined
303 in a declarative manner without specifying how to achieve or
304 implement them.
306 o Intent-Based Network: A network that can be managed using
307 intent.
309 o Policy: A set of rules that governs the choices in behaviour of
310 a system.
312 o Intent User: A user that defines and issues the intent request
313 to the intent management system.
315 Other definitions relevant to this draft, such as intent scope,
316 intent network scope, intent abstraction, intent abstraction, and
317 intent lifecycle are available in section 5.
319 4. Abstract Intent Requirements
321 In order to understand the different intent requirements that would
322 drive intent classification, we first need to understand what intent
323 means for different intent users.
325 4.1. What is Intent?
327 The term Intent has become very widely used in the industry for
328 different purposes, sometimes it is not even in agreement with SDO
329 shared principles mentioned in the Introduction section.
331 Different stakeholders consider an intent to be an ECA policy, a GBP
332 policy, a business policy, a network service, a customer service, a
333 network configuration, application/application group policy, any
334 operator/administrator task, network troubleshooting/diagnostics/
335 test, a new app, a marketing term for existing
336 management/orchestration capabilities, etc. Their intent is sometimes
337 technical, non-technical, abstract or technology specific. For some
338 stakeholders, intent is a subset of these and for other stakeholders
339 intent is all of these. It has in some cases become a term to replace
340 a very generic 'service' or 'policy' terminology.
342 Concerning this, [CLEMM] draft brings clarification with relation to
343 what an intent is and how it differentiates from policies and
344 services.
346 An intent is mistaken by many to be just a synonym for policy. While
347 it is easier for those familiar with different standards to
348 understand what service, CFS, RFS, resource, policy continuum, ECA
349 policy, declarative policy, abstract policy or intent policy is, it
350 may be more difficult for the wider audience. Furthermore, those
351 familiar with policies understand the difference between a business,
352 intent, declarative, imperative, and ECA policy.
354 Therefore, it is important to start a discussion in the industry and
355 academia communities about what intent is for different solutions and
356 intent users. It is also imperative to try to propose some intent
357 categories/ classifications that could be understood by a wider
358 audience. This would help us define intent interfaces, domain-
359 specific languages, and models.
361 4.2. Intent Solutions and Intent Users
363 Intent types are defined by all aspects that are required to profile
364 different requirements to easily distinguish among them. However, in
365 order to facilitate a clustered classification, we can focus on two
366 aspects, the solution and intent user. They can be considered as the
367 main keys to classify intents, as we can easily group requirements by
368 solution and intent user. On the one hand, different solutions and
369 intent users have different requirements, expectations and priorities
370 for intent-driven networking. Therefore, intent users require
371 different intent types, depending on their context, since they
372 participate in different use cases. For instance, some intent users
373 are more technical and require intents that expose more technical
374 information. Other intent users do not have knowledge of the network
375 infrastructure and require intents that shield them from different
376 networking concepts and technologies. The following are the solutions
377 and intent users that intent-driven networking needs to support:
379 +--------------------+------------------------------------+
380 | Solutions | Intent Users |
381 +--------------------+------------------------------------+
382 | Carrier Networks | Network Operator |
383 | | Service Designers/App Developer |
384 | | Service Operators |
385 | | Customers/Subscribers |
386 +--------------------+------------------------------------+
387 | DC Networks | Cloud Administrator |
388 | | Underlay Network Administrator |
389 | | Application Developers |
390 | | Customer/Tenants |
391 +--------------------+------------------------------------+
392 | Enterprise Networks| Enterprise Administrator |
393 | | Application Developers |
394 | | End-Users |
395 +--------------------+------------------------------------+
396 Table 1 - Intent Solutions and Intent Users
398 These intent solutions and intent users represent a starting point
399 for the classification and are expendable through the methodology
400 presented in section 6.1. .
402 o For carrier networks scenario, for example, if a
403 customer/subscriber wants to watch high-definition video, then the
404 intent is to convert the video image to 1080p rate.
406 o For DC networks scenario, administrators have their own clear
407 network intent such as load balancing. For all traffic flows that
408 need NFV service chaining, restrict the maximum load of any VNF
409 node/container below 50% and the maximum load of any network link
410 below 70%.
412 o For enterprise networks scenario, when hosting a video conference
413 multiple remote accesses are required. An example of the intent
414 from the network administrator is: for any end-user of this
415 application, the arrival time of hologram objects of all the
416 remote tele-presenters should be synchronised within 50ms to reach
417 the destination viewer for each conversation session.
419 4.3. Benefits of Intents to Respond to Network Requirements
421 Current network APIs and CLIs are too complex because they are highly
422 integrated with the low level concepts exposed by networks. More
423 specifically, network solutions must determine which low level
424 communication technologies (e.g. protocol) they will use and, even
425 more specifically, they must deal with the network topology that
426 supports such communication (e.g. structure of networks and sub-
427 networks). Customers, application developers and end-users must not
428 be required to set IP addresses, VLANs, subnets, ports, etc.
429 Therefore, all network stakeholders would benefit from the simpler
430 interfaces, like:
432 o Allow customer site A to be connected to Internet via network B
434 o Allow end-user A to access all internal resources, except the
435 server B
437 o Allow end-user B to access internet via corporate network A
439 o Move all end-user from corporate network A to the corporate
440 network B
442 o Request gold VPN service between my sites A, B and C
444 o Provide CE redundancy for all customer sites
446 o Add access rules to my service
448 Networks are complex, with many different protocols and
449 encapsulations. Some basic questions are not easy to answer:
451 o Can end-user A talk to end-user B?
453 o Can host A talk to host B?
455 o Are there any routing loops in my network?
457 o Are network A and network B connected?
459 o Can end-user A listen to communications between end-user B and C?
461 Operators and administrators manually troubleshoot and fix their
462 networks and services. They instead want:
464 o a reliable network that is self-configured and self-assured based
465 on the intent
467 o to be notified about the problem before the end-user is aware
469 o automation of network/service recovery based on intent (self-
470 healing, self-optimization)
472 o to get suggestions about correction/optimization steps based on
473 experience (historical data and behaviour)
475 Therefore, operators and administrators want to:
477 o simplify and automate network operations
479 o simplify definitions of network services
481 o provide simple customer APIs for value added services (operators)
483 o be informed if the network or service is not behaving as requested
485 o enable automatic optimization and correction for selected
486 scenarios
488 o have systems that learn from historic information and behaviour
490 Currently, intent users cannot build their own services and policies
491 without becoming technical experts and performing manual maintenance
492 actions. They want to be able to:
494 o build their own network services with their own policies via
495 simple interfaces, without becoming networking experts
497 o have their network services up and running based on intent and
498 automation only, without any manual actions or maintenance
500 4.4. Intent Types that need to be supported
502 Next to the intent solutions and intent users, another way to
503 categorize the intent is through the intent types. The following
504 intent types need to be supported, in order to address the
505 requirements from different solutions and intent users:
507 o Customer service intent
509 o for customer self-service with SLA
510 o for service operator orders
512 o Network and underlay network service intent
514 o for service operator orders
516 o for intent driven network configuration, verification,
517 correction and optimization
519 o for intent created and provided by the underlay network
520 administrator
522 o Network and underlay network intent
524 o For network configuration
526 o For automated lifecycle management of network configurations
528 o For network resources (switches, routers, routing, policies,
529 underlay)
531 o Cloud management intent
533 o For DC configuration, VMs, DB servers, APP servers
535 o For communication between VMs
537 o Cloud resource management intent
539 o For cloud resource life-cycle management (policy driven self-
540 configuration and auto-scaling and recovery/optimization)
542 o Strategy intent
544 o For security, QoS, application policies, traffic steering, etc.
546 o For configuring and monitoring policies, alarms generation for
547 non-compliance, auto-recovery
549 o For design models and policies for network and network service
550 design
552 o For design workflows, models and policies for operational task
553 intents
555 o Operational task intents
556 o For network migration
558 o For server replacements
560 o For device replacements
562 o For network software upgrades
564 o To automate any tasks that operators/administrator often
565 perform
567 o Intents that affect other intents
569 o It may be task-based intent that modifies many other intents.
571 o The task itself is short-lived, but the modification of other
572 intents has an impact on their life-cycle, so those changes
573 must continue to be continuously monitored and self-
574 corrected/self-optimized.
576 5. Functional Characteristics and Behaviour
578 Intent can be used to operate immediately on a target (much like
579 issuing a command), or whenever it is appropriate (e.g., in response
580 to an event). In either case, intent has a number of behaviours that
581 serve to further organize its purpose, as described by the following
582 subsections.
584 5.1. Abstracting Intent Operation
586 The modelling of intents can be abstracted using the following
587 three-tuple:
589 {Context, Capabilities, Constraints}
591 o Context grounds the intent, and determines if it is relevant or
592 not for the current situation. Thus, context selects intents based
593 on applicability.
595 o Capabilities describe the functionality that the intent can
596 perform. Capabilities take different forms, depending on the
597 expressivity of the intent as well as the programming paradigm(s)
598 used.
600 o Constraints define any restrictions on the capabilities to be used
601 for that particular context.
603 Metadata can be attached via strategy templates to each of the
604 elements of the three-tuple, and may be used to describe how the
605 intent should be used and how it operates, as well as prescribe any
606 operational dependencies that must be taken into account.
608 5.2. Intent User Types
610 Expanding on the introduction in section 4.2. , intent user types
611 represent the intent users that define and issue the intent request.
612 Depending on the intent solutions, there are specific intent users.
613 Examples of intent users are customers, network operators, service
614 operators, enterprise administrators, cloud administrators, and
615 underlay network administrators, or application developers.
617 o Customers and end-users do not necessarily know the functional and
618 operational details of the network that they are using.
619 Furthermore, they lack skills to understand such details; in fact,
620 such knowledge is typically not relevant to their job. In
621 addition, the network may not expose these details to its intent
622 users. This class of intent users focuses on the applications that
623 they run, and uses services offered by the network. Hence, they
624 want to specify policies that provide consistent behaviour
625 according to their business needs. They do not have to worry about
626 how the intents are deployed onto the underlying network, and
627 especially, whether the intents need to be translated to different
628 forms to enable network elements to understand them.
630 o Application developers work in a set of abstractions defined by
631 their application and programming environment(s). For example,
632 many application developers think in terms of objects (e.g., a
633 VPN). While this makes sense to the application developer, most
634 network devices do not have a VPN object per se; rather, the VPN
635 is formed through a set of configuration statements for that
636 device in concert with configuration statements for the other
637 devices that together make up the VPN. Hence, the view of
638 application developers matches the services provided by the
639 network, but may not directly correspond to other views of other
640 intent users.
642 o Network operators may have the knowledge of the underlying
643 network. However, they may not understand the details of the
644 applications and services of customers.
646 5.3. Intent Scope
648 Intents are used to manage the behaviour of the networks they are
649 applied to and all intents are applied within a specific scope, such
650 as:
652 o Connectivity scope, if the intent creates or modifies a
653 connection.
654 o Security/privacy scope, if the intent specifies the security
655 characteristics of the network, customers, or end-users.
656 o Application scope, when the intent specifies the applications to
657 be affected by the intent request.
658 o QoS scope, when the intent specifies the QoS characteristics of
659 the network.
661 These intent scopes are expendable through the methodology presented
662 in section 6.1. .
664 5.4. Intent Network Scope
666 Regardless on the intent user type, their intent request is affecting
667 the network, or network components, which are representing the intent
668 targets.
670 Thus, intent network scope, or policy target as known in the area of
671 declarative policy, can represent VNFs or PNFs, physical network
672 elements, campus networks, SD-WAN networks, radio access networks,
673 cloud edge, cloud core, branch, etc.
675 5.5. Intent Abstraction
677 Intent can be classified by whether it is necessary to feedback
678 technical network information or non-technical information to the
679 intent user after the intent is executed. As well, intent abstraction
680 covers the level of technical details in the intent itself.
682 o For non-technical intent users, they do not care how the intent is
683 executed, or the details of the network. As a result, they do not
684 need to know the configuration information of the underlying
685 network. They only focus on whether the intent execution result
686 achieves the goal, and the execution effect such as the quality of
687 completion and the length of execution. In this scenario, we refer
688 to an abstraction without technical feedback.
690 o For administrators, such as network administrators, they perform
691 intents, such as allocating network resources, selecting
692 transmission paths, handling network failures, etc. They require
693 multiple feedback indicators for network resource conditions,
694 congestion conditions, fault conditions, etc. after execution. In
695 this case, we refer to an abstraction with technical feedback.
697 As per intent definition provided in [CLEMM], lower-level intents are
698 not considered to qualify as intents. However, we kept this
699 classification to identify any PoCs/Demos/Use Cases that still either
700 require or implement lower level of abstraction for intents.
702 5.6. Intent Life-cycle
704 Intents can be classified into transient and persistent intents:
706 o If the intent is transient, it has no life-cycle management. As
707 soon as the specified operation is successfully carried out, the
708 intent is finished, and can no longer affect the target object.
710 o If the intent is persistent, it has life-cycle management. Once
711 the intent is successfully activated and deployed, the system will
712 keep all relevant intents active until they are deactivated or
713 removed.
715 5.7. Autonomous Driving Levels
717 In different phases of the autonomous driving network [TMF-auto], the
718 intents are different. A typical example of autonomous driving
719 network level 0 to 5 are listed as below.
721 o Level 0 - Traditional manual network: O&M personnel manually
722 control the network and obtain network alarms and logs. - No
723 intent
725 o Level 1 - Partially automated network: Automated scripts are used
726 to automate service provisioning, network deployment, and
727 maintenance. Shallow perception of network status and decision
728 making suggestions of machine; - No intent
730 o Level 2 - Automated network: Automation of most service
731 provisioning, network deployment, and maintenance of a
732 comprehensive perception of network status and local machine
733 decision making; - simple intent on service provisioning
735 o Level 3 - Self-optimization network: Deep awareness of network
736 status and automatic network control, meeting requirements of
737 intent users of the network. - Intent based on network status
738 cognition
740 o Level 4 - Partial autonomous network: In a limited environment,
741 people do not need to participate in decision-making and networks
742 can adjust itself. - Intent based on limited AI
744 o Level 5 - Autonomous network: In different network environments
745 and network conditions, the network can automatically adapt to and
746 adjust to meet people's intentions. - Intent based on AI
748 6. Intent Classification
750 This section proposes an intent classification approach that may help
751 to classify mainstream intent related demos/tools.
753 The three classifications in this document have been proposed from
754 scratch, following the methodology presented, through three
755 iterations: one for carrier network intent solution, one for DC
756 intent solution, and one for enterprise intent solution. For each
757 intent solution, we identified the specific intent users and intent
758 types. Then, we further identified intent scope, network scope,
759 abstractions, and life-cycle requirements.
761 These classifications and the generated tables can be easily
762 extended. For example, for the DC intent solution, a new category is
763 identified, i.e. resource scope, and the classification table has
764 been extended accordingly.
766 In the future, as new scenarios, applications, and domains are
767 emerging, new classifications and taxonomies can be identified,
768 following the proposed methodology.
770 The intent classifications have been documented to the best of our
771 knowledge at this point in time. Additional classifications will most
772 probably see the light in the future.
774 The output of the intent classification is the intent taxonomy
775 introduced in the next sections.
777 Thus, this section first introduces the proposed intent
778 classification methodology, followed by consolidated intent taxonomy
779 for three intent solutions, and then by concrete examples of intent
780 classifications for three different intent solutions (e.g. carrier
781 network, data center, and enterprise) that were derived using the
782 proposed methodology and then can be filled in for PoCs, demos,
783 research projects or future drafts.
785 6.1. Intent Classification Methodology
787 This section describes the methodology used to derive the initial
788 classification proposed in the draft. The proposed methodology can be
789 used to create new intent classifications from scratch, by analysing
790 the solution knowledge. As well, the methodology can be used to
791 update existing classification tables by adding or removing different
792 solutions, intent users or intent types in order to cater for future
793 scenarios, applications or domains.
795 +------------------------------------------+
796 |Solution Knowledge (requirements, |
797 |use cases, technologies, network, intent |
798 |users, intent requirements) |
799 +----------------+-------------------------+
800 | Input Rx=Read
801 | Ux=Update (Add/Remove)
802 +--------V--------+
803 |1.Identify Intent|
804 | Solution +------------+
805 | | |
806 +---------^-+-----+ |
807 R1 | | U1 |
808 +---------------+ U8 | | R2 +--v----------------+
809 |8.Identify New +---------+ | | +-----------> 2.Identify |
810 | Categories | R8 | | | | U2 | Intent |
811 | <-------- | | | | +---------+ User Types |
812 +--------^------+ | | | | | | +-------|-----------+
813 | | | | | | | |
814 | ++-+-v-v---+-v-+ |
815 +--------+------+ U7 | | R3 +------v------------+
816 |7.Identify +------> Intent +--------> 3.Identify |
817 | Life-cycle | R7 |Classification| U3 | Type |
818 | Requirements <------+ <--------+ of Intent |
819 +--------^------+ +^--^-+--^-+---+ +------|------------+
820 | || | | | | |
821 | || | | | | |
822 +--------+-----+ || | | | | R4 +-------v-----------+
823 |6.Identify | U6 || | | | +-----------> 4.Identify |
824 | Abstractions+---------| | | | U4 | Intent |
825 | <---------+ | | +-------------+ Scope |
826 +-------^------+ R6 | | +-------+-----------+
827 | | | |
828 | U5 | |R5 |
829 | +-------+-v--------+ |
830 | |5.Identify Network| |
831 +----------+ Scope <---------------+
832 +------------------+
833 Figure 1 - Intent Classification Methodology
835 The intent classification workflow starts from the solution
836 knowledge, which can provide information on requirements, use cases,
837 technologies used, network properties, intent users that define and
838 issue the intent request, and requirements. The following, defines
839 the steps to classify an intent:
841 1. The information provided in the solution knowledge is given as
842 input for identifying the intent solution (e.g. carrier, enterprise,
843 and data center). Intent solutions are reviewed against the existing
844 classification and they can either be used if present or added if not
845 there or removed if not needed, from the classification. (R1-U1).
847 2. Identify the intent user types (e.g. customer, network operators,
848 service operators, etc.), review existing intent classification and
849 use the intent user type if present, add if it is not there or remove
850 it if not needed (R2-U2).
852 3. Identify the types of intent (e.g. network intent, customer
853 service intent) and then review existing classification and
854 use/add/remove the intent type (R3-U3).
856 4. Identify the intent scopes (e.g. connectivity, application) based
857 on the solution knowledge and then review existing classification and
858 use/add/remove the identified intent scope (R4-U4).
860 5. Identify the network scopes (e.g. campus, radio access) and then
861 then review existing classification and either use it or add/remove
862 the identified network scope (R5-U5).
864 6. Identify the abstractions (e.g. technical, non-technical) and
865 then review existing classification and use/add/remove the
866 abstractions (R6-U6).
868 7. Identify the life-cycle requirements (e.g. persistent, transient)
869 and then review existing classification and use/add/remove the life-
870 cycle requirements (R7-U7).
872 8. Identify any new categories and use/add the newly identified
873 categories. New categories can be identified as new domains or
874 applications are emerging, or new areas of concern (e.g. privacy,
875 compliance) might arise, which are not listed in the current
876 methodology.
878 6.2. Intent Taxonomy
880 The following taxonomy describes the various intent solutions, intent
881 user types, intent types, intent scopes, network scopes, abstractions
882 and life-cycle and represents the output of the intent classification
883 tables for each of the solutions addressed (i.e. carrier, data
884 center, and enterprise solutions).
886 The intent scope categories in Figure 2 are shared among the carrier,
887 DC, and enterprise solutions. The abbreviations (Cx) in sections
888 6.3.2. 6.4.2. are introduced with the scope of fitting as column
889 title in the following tables.
891 +--------------------------------+
892 +-->|Carrier Enterprise Data Center|
893 | +--------------------------------+
894 | +--------------------------------+
895 | |Customer/Subscriber/End-User |
896 +----------+ | |Network or Service Operator |
897 +>+Solutions +--+ |Application Developer |
898 | +----------+ +->|Enterprise Administrator |
899 | | |Cloud Administrator |
900 | +----------+ | |Underlay Network Administrator |
901 +>+Intent +---+ +--------------------------------+
902 | |User | +--------------------------------+
903 | |Types | |Customer Service Intent |
904 | +----------+ |Strategy Intent |
905 | +----------+ |Network Service Intent |
906 +>+Intent +----->|Underlay Network Service Intent |
907 +------+ | |Type | |Network Intent |
908 |Intent+-+ +----------+ |Underlay Network Intent |
909 +------+ | |Operational Task Intent |
910 | +----------+ |Cloud Management Intent |
911 +>+Intent +---+ |Cloud Resource Management Intent|
912 | |Scope | | +--------------------------------+
913 | +----------+ | +--------------------------------+
914 | +->|Connectivity Application QoS |
915 | +----------+ |Security/Privacy Storage Compute|
916 +>+Network +---+ +--------------------------------+
917 | |Scope | | +--------------------------------+
918 | +----------+ | |Radio Access Branch |
919 | +->|Transport Access SD-WAN |
920 | +----------+ |Transport Aggr. VNF PNF |
921 +>+Abstrac +----+ |Transport Core Physical |
922 | |tion | | |Cloud Edge Logical |
923 | +----------+ | |Cloud Core Campus |
924 | +----------+ | +--------------------------------+
925 +>+Life | | +--------------------------------+
926 |cycle +--+ +>|Technical Non-Technical |
927 +----------+ | +--------------------------------+
928 | +--------------------------------+
929 +-->|Persistent Transient |
930 +--------------------------------+
931 Figure 2 - Intent Taxonomy
933 6.3. Intent Classification for Carrier Solution
935 6.3.1. Intent Users and Intent Types
937 This section addresses step 1, 2, and 3 from Figure 1 and the
938 following table describes the intent users in carrier solutions and
939 intent types with their descriptions for different intent users.
941 +-------------+-------------+---------------------------------------+
942 | Intent User | Intent Type | Intent Type Description |
943 +-------------------------------------------------------------------+
944 | Customer/ |Customer |Customer self-service with SLA and |
945 | Subscriber |Service |value added service |
946 | |Intent |Example: Always maintain high quality |
947 | | |of service and high bandwidth for gold |
948 | | |level subscribers. |
949 | | |Operational statement: Measure the |
950 | | |network congestion status, give |
951 | | |different adaptive parameters to |
952 | | |stations of different priority, thus in|
953 | | |heavy load situation, make the |
954 | | |bandwidth of the high-priority |
955 | | |customers guaranteed. |
956 | | |At the same time ensure the overall |
957 | | |utilization of system, improve |
958 | | |the overall throughput of the system. |
959 | +-----------------------------------------------------+
960 | |Strategy |Customer designs models and policy |
961 | |Intent |intents to be used by customer service |
962 | | |intents. |
963 | | |Example: Request reliable service |
964 | | |during peak traffic periods for apps |
965 | | |of type video. |
966 +-------------------------------------------------------------------+
967 |Network |Network |Service provided by network service |
968 |Operator |Service |operator to the customer |
969 | |Intent |(e.g. the service operator) |
970 | | |Example: Request network service with |
971 | | |delay guarantee for access customer A. |
972 | +-------------+---------------------------------------+
973 | |Network |Network operator requests network-wide |
974 | |Intent |(service underlay or other network-wide|
975 | | |configuration) or network resource |
976 | | |configurations (switches, routers, |
977 | | |routing, policies). Includes |
978 | | |connectivity, routing, QoS, security, |
979 | | |application policies, traffic steering |
980 | | |policies, configuration policies, |
981 | | |monitoring policies, alarm generation |
982 | | |for non-compliance, auto-recovery, etc.|
983 | | |Example: Request high priority queueing|
984 | | |for traffic of class A. |
985 | +-----------------------------------------------------+
986 | |Operational |Network operator requests execution of |
987 | |Task |any automated task other than network |
988 | |Intent |service intent and network intent |
989 | | |(e.g. network migration, server |
990 | | |replacements, device replacements, |
991 | | |network software upgrades). |
992 | | |Example: Request migration of all |
993 | | |services in network N to backup path P.|
994 | +-----------------------------------------------------+
995 | |Strategy |Network operator designs models, policy|
996 | |Intent |intents and workflows to be used by |
997 | | |network service Intents, network |
998 | | |intents and operational task intents. |
999 | | |Workflows can automate any tasks that |
1000 | | |network operator often performed in |
1001 | | |addition to network service intents and|
1002 | | |network intents |
1003 | | |Example: Ensure the load on any link in|
1004 | | |the network is not higher than 50%. |
1005 +-------------+-------------+---------------------------------------+
1006 +-------------+-------------+---------------------------------------+
1007 | Service | Customer | Service operator's customer orders, |
1008 | Operator | Service | customer service / SLA |
1009 | | Intent | Example: Provide service S with |
1010 | | | guaranteed bandwidth for customer A. |
1011 | +-----------------------------------------------------+
1012 | | Network | Service operator's network orders / |
1013 | | Service | network SLA |
1014 | | Intent | Example: Provide network guarantees in|
1015 | | | terms of security, low latency and |
1016 | | | high bandwidth |
1017 | +-----------------------------------------------------+
1018 | | Operational | Service operator requests execution of|
1019 | | Task | any automated task other than |
1020 | | Intent | customer service intent and network |
1021 | | | service intent |
1022 | | | Example: Update service operator |
1023 | | | portal platforms and their software |
1024 | | | regularly. Move services from network |
1025 | | | operator 1 to network operator 2. |
1026 | +-----------------------------------------------------+
1027 | | Strategy | Service operator designs models, |
1028 | | Intent | policy intents and workflows to be |
1029 | | | used by customer service intents, |
1030 | | | network service intents and |
1031 | | | operational task intents. Workflows |
1032 | | | can automate any tasks that service |
1033 | | | operator often performed in addition |
1034 | | | to network service intents and network|
1035 | | | intents. |
1036 | | | Example: Request network service |
1037 | | | guarantee to avoid network congestion |
1038 | | | during special periods |
1039 | | | such as black Friday, and Christmas. |
1040 +-------------+-------------+---------------------------------------+
1041 | Application | Customer | Customer service intent API provided |
1042 | Developer | Service | to the application developers |
1043 | | Intent | Example: API to request network to |
1044 | | | watch HD video 4K/8K. |
1045 | +-----------------------------------------------------+
1046 | | Network | Network service intent API provided to|
1047 | | Service | the application developers |
1048 | | Intent | Example:API to request network service|
1049 | | | , monitoring and traffic grooming. |
1050 | +-----------------------------------------------------+
1051 | | Network | Network intent API provided to the |
1052 | | Intent | application developers |
1053 | | | Example: API to request network |
1054 | | | resources configuration. |
1055 | +-----------------------------------------------------+
1056 | | Operational | Operational task intent API provided |
1057 | | Task | to the application developers. This is|
1058 | | Intent | for the trusted internal operator / |
1059 | | | service providers / customer DevOps |
1060 | | | Example: API to request server |
1061 | | | migrations. |
1062 | +-----------------------------------------------------+
1063 | | Strategy | Application developer designs models, |
1064 | | Intent | policy and workflows to be used by |
1065 | | | customer service intents, network |
1066 | | | service intents and operational |
1067 | | | task intents. This is for the trusted |
1068 | | | internal operator/service provider/ |
1069 | | | customer DevOps |
1070 | | | Example: API to design network load |
1071 | | | balancing strategies during peak times|
1072 +-------------+-------------+---------------------------------------+
1074 Table 2 - Intent Classification for Carrier Solution
1076 6.3.2. Intent Categories
1078 This subsection addresses step 4 to 7 from Figure 1, and the
1079 following are the proposed categories:
1081 o Intent Scope: C1=Connectivity, C2=Security/Privacy,
1082 C3=Application, C4=QoS
1083 o Network Scope:
1084 o Network Domain: C1=Radio Access, C2=Transport Access,
1085 C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge,
1086 C6=Cloud Core)
1087 o Network Function (NF) Scope: C1=VNFs, C2=PNFs
1088 o Abstraction (ABS): C1=Technical (with technical feedback),
1089 C2=Non-technical (without technical feedback) see section 5.2. .
1090 o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient
1091 (short lived)
1093 6.3.3. Intent Classification Example
1095 This section depicts an example on how the methodology described in
1096 section 6.1. can be used in order to classify intents introduced in
1097 the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. This
1098 PoC is led by academics carrying research in the area of SDN/NFV and
1099 the specific problem they are addressing is to apply the intent
1100 concept at different levels that correspond to different
1101 stakeholders. For this research work, they considered two types of
1102 intents: slice intents and service chain intents.
1104 In this PoC [POC-IBN], a slice intent expresses a request for a
1105 network slice with two types of components: a set of top layer
1106 virtual functions, and a set of virtual switches and/or routers of
1107 L2/L3 VNFs. A service chain intent expressed a request for a service
1108 operated through a chain of service components running in L4-L7
1109 virtual functions.
1111 Following the intent classification methodology described step-by-
1112 step in section 6.1. , the following can be derived:
1114 1. The intent solution for both intents is carrier network.
1116 2. The intent user type is network operator for the slice intent, and
1117 service operator for the service chain intent.
1119 3. The type of intent, is a network service intent for the slice
1120 intent,and a customer service intent for the service chain intent.
1122 4. The intent scopes are connectivity and application.
1124 5. The network scope is VNF, cloud edge, and cloud core.
1126 6. The abstractions are with technical feedback for the slice intent,
1127 and without technical feedback for the service chain intent
1129 7. The life-cycle is persistent.
1131 The following table shows how to represent this information in a
1132 tabular form. The 'X' in the table refers to the slice intent, and
1133 the 'Y' in the table refers to the service chain intent.
1135 +---------+---------+-----------+-----+-----------------+-----+-----+
1136 | Intent | Intent | Intent | NF | Network | ABS |L-C |
1137 | User | Type | Scope |Scope| Scope | | |
1138 | | +-----------+-----+-----------------+-----+-----+
1139 | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|
1140 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1141 |Customer |Customer | | | | | | | | | | | | | | | | |
1142 |/ Sub- |Service | | | | | | | | | | | | | | | | |
1143 | scriber |Intent | | | | | | | | | | | | | | | | |
1144 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1145 | |Strategy | | | | | | | | | | | | | | | | |
1146 | |Intent | | | | | | | | | | | | | | | | |
1147 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1148 |Network |Network |X | |X | |X | | | | | |X | |X | |X | |
1149 |Operator |Service | | | | | | | | | | | | | | | | |
1150 | |Intent | | | | | | | | | | | | | | | | |
1151 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1152 | |Network | | | | | | | | | | | | | | | | |
1153 | |Intent | | | | | | | | | | | | | | | | |
1154 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1155 | |Operatio-| | | | | | | | | | | | | | | | |
1156 | |nal Task | | | | | | | | | | | | | | | | |
1157 | |Intent | | | | | | | | | | | | | | | | |
1158 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1159 | |Strategy | | | | | | | | | | | | | | | | |
1160 | |Intent | | | | | | | | | | | | | | | | |
1161 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1162 |Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | |
1163 |Operator |Service | | | | | | | | | | | | | | | | |
1164 | |Intent | | | | | | | | | | | | | | | | |
1165 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1166 | |Network | | | | | | | | | | | | | | | | |
1167 | |Service | | | | | | | | | | | | | | | | |
1168 | |Intent | | | | | | | | | | | | | | | | |
1169 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1170 | |Op Task | | | | | | | | | | | | | | | | |
1171 | |Intent | | | | | | | | | | | | | | | | |
1172 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1173 | |Strategy | | | | | | | | | | | | | | | | |
1174 | |Intent | | | | | | | | | | | | | | | | |
1175 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1176 |App |Customer | | | | | | | | | | | | | | | | |
1177 |Developer|Intent | | | | | | | | | | | | | | | | |
1178 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1179 | |Network | | | | | | | | | | | | | | | | |
1180 | |Service | | | | | | | | | | | | | | | | |
1181 | |Intent | | | | | | | | | | | | | | | | |
1182 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1183 | |Network | | | | | | | | | | | | | | | | |
1184 | |Intent | | | | | | | | | | | | | | | | |
1185 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1186 | |Op Task | | | | | | | | | | | | | | | | |
1187 | |Intent | | | | | | | | | | | | | | | | |
1188 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1189 | |Strategy | | | | | | | | | | | | | | | | |
1190 | |Intent | | | | | | | | | | | | | | | | |
1191 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1193 Table 3 - Intent Classification Example for Carrier Solution
1195 6.4. Intent Classification for Data Center Network Solutions
1197 6.4.1. Intent Users and Intent Types
1199 The following table describes the intent users in DC network
1200 solutions and intent types with their descriptions for different
1201 intent users.
1203 +---------------+-------------+-------------------------------------+
1204 | Intent User | Intent Type | Intent Type Description |
1205 +-------------------------------------------------------------------+
1206 | Customer / | Customer | Customer self-service via tenant |
1207 | Tenants | Service | portal. |
1208 | | | Example: Request GPU computing and |
1209 | | | storage resources to meet 10k video |
1210 | | | surveillance services. |
1211 | +---------------------------------------------------+
1212 | | Strategy | This includes models and policy |
1213 | | Intent | intents designed by customers/ |
1214 | | | tenants to be reused later during |
1215 | | | instantiation. |
1216 | | | Example: Request dynamic computing |
1217 | | | and storage resources of the service|
1218 | | | in special and daily times. |
1219 | | | |
1220 +-------------------------------------------------------------------+
1221 | | Cloud | Configuration of VMs, DB Servers, |
1222 | Cloud | Management | app servers, connectivity, |
1223 | Administrator | Intent | communication between VMs. |
1224 | | | Example: Request connectivity |
1225 | | | between VMs A,B,and C in network N1.|
1226 | +---------------------------------------------------+
1227 | | Cloud | Policy-driven self-configuration and|
1228 | | Resource | and recovery / optimization |
1229 | | Management | Example: Request automatic life |
1230 | | Intent |-cycle management of VM cloud |
1231 | | | resources. |
1232 | +---------------------------------------------------+
1233 | | Operational | Cloud administrator requests |
1234 | | Task Intent | execution of any automated task |
1235 | | | other than cloud management |
1236 | | | intents and cloud resource |
1237 | | | management intents. |
1238 | | | Example: Request upgrade operating |
1239 | | | system to version X on all VMs |
1240 | | | in network N1. |
1241 | | |Operational statement: an intent to |
1242 | | |update a system might reconfigure the|
1243 | | |system topology (connect to a service|
1244 | | |and to peers), exchange data (update |
1245 | | |the content), and uphold a certain |
1246 | | |QoE level (allocate sufficient |
1247 | | |network resources). The network, |
1248 | | |thus, carries out the necessary |
1249 | | |configuration to best serve such an |
1250 | | |intent; e.g. setting up direct |
1251 | | |connections between terminals, and |
1252 | | |allocating fair shares of router |
1253 | | |queues considering other network |
1254 | | |services. |
1255 | +---------------------------------------------------+
1256 | | Strategy | Cloud administrator designs models, |
1257 | | Intent | policy intents and workflows to be |
1258 | | | used by other intents. Automate any |
1259 | | | tasks that administrator often |
1260 | | | performs, in addition to life-cycle |
1261 | | | of cloud management intents and |
1262 | | | cloud management resource intents. |
1263 | | | Example: In case of emergency, |
1264 | | | automatically migrate all cloud |
1265 | | | resources to DC2. |
1266 +---------------+---------------------------------------------------+
1267 | Underlay | Underlay | Service created and provided by |
1268 | Network | Network | the underlay network administrator. |
1269 | Administrator | Service | Example: Request underlay service |
1270 | | Intent | between DC1 and DC2 with |
1271 | | | bandwidth B. |
1272 | +---------------------------------------------------+
1273 | | Underlay | Underlay network administrator |
1274 | | Network | requests some DCN-wide underlay |
1275 | | Intent | network configuration or network |
1276 | | | resource configurations. |
1277 | | | Example: Establish and allocate |
1278 | | | DHCP address pool. |
1279 | +---------------------------------------------------+
1280 | | Operational | Underlay network administrator |
1281 | | Task Intent | requests execution of the any |
1282 | | | automated task other than underlay |
1283 | | | network service and resource |
1284 | | | intent. |
1285 | | | Example: Request automatic rapid |
1286 | | | detection of device failures and |
1287 | | | pre-alarm correlation. |
1288 | +---------------------------------------------------+
1289 | | Strategy | Underlay network administrator |
1290 | | Intent | designs models, policy intents & |
1291 | | | workflows to be used by other |
1292 | | | intents. Automate any tasks that |
1293 | | | administrator often performs. |
1294 | | | Example: For all traffic flows |
1295 | | | that need NFV service chaining, |
1296 | | | restrict the maximum load of any |
1297 | | | VNF node/container below 50% and |
1298 | | | the maximum load of any network |
1299 | | | link below 70%. |
1300 +-------------------------------------------------------------------+
1301 | | Cloud | Cloud management intent API |
1302 | | Management | provided to the application |
1303 | | Intent | developers. |
1304 | | | Example: API to request |
1305 | | | configuration of VMs, or DB Servers.|
1306 | Application +---------------------------------------------------+
1307 | Developer | Cloud | Cloud resource management intent |
1308 | | Resource | API provided to the application |
1309 | | Management | developers. |
1310 | | Intent | Example: API to request automatic |
1311 | | | life-cycle management of cloud |
1312 | | | resources. |
1313 | +---------------------------------------------------+
1314 | | Underlay | Underlay network service API |
1315 | | Network | provided to the application |
1316 | | Service | developers. |
1317 | | Intent | Example: API to request real-time |
1318 | | | monitoring of device condition. |
1319 | +---------------------------------------------------+
1320 | | Underlay | Underlay network resource API |
1321 | | Network | provided to the application |
1322 | | Intent | developers. |
1323 | | | Example: API to request dynamic |
1324 | | | management of IPv4 address pool |
1325 | | | resources. |
1326 | | | |
1327 | +---------------------------------------------------+
1328 | | Operational | Operational task intent API |
1329 | | Task Intent | provided to the trusted |
1330 | | | application developer (internal |
1331 | | | DevOps). |
1332 | | | Example: API to request automatic |
1333 | | | rapid detection of device failures |
1334 | | | and pre-alarm correlation |
1335 | | | |
1336 | +---------------------------------------------------+
1337 | | Strategy | Application developer designs |
1338 | | Intent | models, policy intents and |
1339 | | | building blocks to be used by |
1340 | | | other intents. This is for the |
1341 | | | trusted internal DCN DevOps. |
1342 | | | Example: API to request load |
1343 | | | balancing thresholds. |
1344 +---------------+-------------+-------------------------------------+
1346 Table 4 - Intent Classification for Data Center Network Solutions
1348 6.4.2. Intent Categories
1350 The following are the proposed categories:
1351 o Intent Scope: C1=Connectivity, C2=Security/Privacy,
1352 C3=Application, C4=QoS C5=Storage C6=Compute
1353 o Network Scope
1354 o Network Domain: DC Network
1355 o DCN Network (DCN Net) Scope: C1=Logical, C2=Physical
1356 o DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical
1357 o Abstraction (ABS): C1=Technical (with technical feedback),
1358 C2=Non-technical (without technical feedback), see section 5.2.
1359 o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient
1360 (short lived)
1362 6.4.3. Intent Classification Example
1364 This section depicts an example on how the methodology described in
1365 section 6.1. can be used by the research community to classify
1366 intents. As mentioned in 6.3.3. a successful use of the
1367 classification proposed in this draft is introduced in the 'A Multi-
1368 Level Approach to IBN' PoC demonstration [POC-IBN]. The PoC is led by
1369 academics carrying research in the area of SDN/NFV and the specific
1370 problem they are addressing is to apply the intent concept at
1371 different levels that correspond to different stakeholders.
1373 For their research work, they considered two types of intents: slice
1374 intents and service chain intents. For the data center solution, only
1375 the slice intent is relevant.
1377 As already mentioned in section 6.3.3. , a slice intent expresses a
1378 request for a network slice with two types of components: a set of
1379 top layer virtual functions, and a set of virtual switches and/or
1380 routers of L2/L3 VNFs.
1382 Following the intent classification methodology described step-by-
1383 step in section 6.1. , we identify the following:
1385 1. The intent solution is for the data center.
1387 2. The intent user type is the cloud administrator for the slice
1388 intent and service chain intent.
1390 3. The type of intent, is a cloud management intent, for the slice
1391 intent.
1393 4. The intent scopes are connectivity and application.
1395 5. The network scope is logical, and the resource scope is virtual.
1397 6. The abstractions are with technical feedback for the slice intent.
1399 7. The life-cycle is persistent.
1401 The following table shows how to represent this information in a
1402 tabular form, where the 'X' in the table refers to the slice intent.
1404 +---------+-------------+-----------------+-----+-----+-----+-----+
1405 |Intent | Intent | Intent | DCN | DCN | ABS | L-C |
1406 |User | Type | Scope | Res | Net | | |
1407 | | +-----------------+-----+-----+-----+-----+
1408 | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
1409 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1410 |Customer | Customer | | | | | | | | | | | | | | |
1411 |/Tenants | Service | | | | | | | | | | | | | | |
1412 | | Intent | | | | | | | | | | | | | | |
1413 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1414 | | Strategy | | | | | | | | | | | | | | |
1415 | | Intent | | | | | | | | | | | | | | |
1416 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1417 | Cloud | Cloud | | | | | | | | | | | | | | |
1418 | Admin | Management |X | |X | | | |X | |X | |X | |X | |
1419 | | Intent | | | | | | | | | | | | | | |
1420 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1421 | | Cloud | | | | | | | | | | | | | | |
1422 | | Resource | | | | | | | | | | | | | | |
1423 | | Management | | | | | | | | | | | | | | |
1424 | | Intent | | | | | | | | | | | | | | |
1425 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1426 | | Operational | | | | | | | | | | | | | | |
1427 | | Task Intent | | | | | | | | | | | | | | |
1428 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1429 | | Strategy | | | | | | | | | | | | | | |
1430 | | Intent | | | | | | | | | | | | | | |
1431 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1432 |Underlay | Underlay | | | | | | | | | | | | | | |
1433 |Network | Network | | | | | | | | | | | | | | |
1434 |Admin | Intent | | | | | | | | | | | | | | |
1435 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1436 | | Underlay | | | | | | | | | | | | | | |
1437 | | Network | | | | | | | | | | | | | | |
1438 | | Resource | | | | | | | | | | | | | | |
1439 | | Intent | | | | | | | | | | | | | | |
1440 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1441 | | Operational | | | | | | | | | | | | | | |
1442 | | Task Intent | | | | | | | | | | | | | | |
1443 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1444 | | Strategy | | | | | | | | | | | | | | |
1445 | | Intent | | | | | | | | | | | | | | |
1446 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1447 |App | Cloud | | | | | | | | | | | | | | |
1448 |Developer| Management | | | | | | | | | | | | | | |
1449 | | Intent | | | | | | | | | | | | | | |
1450 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1451 | | Cloud | | | | | | | | | | | | | | |
1452 | | Resource | | | | | | | | | | | | | | |
1453 | | Management | | | | | | | | | | | | | | |
1454 | | Intent | | | | | | | | | | | | | | |
1455 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1456 | | Underlay | | | | | | | | | | | | | | |
1457 | | Network | | | | | | | | | | | | | | |
1458 | | Intent | | | | | | | | | | | | | | |
1459 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1460 | | Underlay | | | | | | | | | | | | | | |
1461 | | Network | | | | | | | | | | | | | | |
1462 | | Resource | | | | | | | | | | | | | | |
1463 | | Intent | | | | | | | | | | | | | | |
1464 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1465 | | Operational | | | | | | | | | | | | | | |
1466 | | Task Intent | | | | | | | | | | | | | | |
1467 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1468 | | Strategy | | | | | | | | | | | | | | |
1469 | | Intent | | | | | | | | | | | | | | |
1470 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1472 Table 5 - Intent Classification Example for Data Center Network
1473 Solutions
1475 6.5. Intent Classification for Enterprise Solution
1477 6.5.1. Intent Users and Intent Types
1479 The following table describes the intent users in enterprise
1480 solutions and their intent types.
1482 +--------------+-------------+-------------------------------------+
1483 | Intent User | Intent Type | Intent Type Description |
1484 +--------------+---------------------------------------------------+
1485 | End-User | Customer | Enterprise end-user self-service or |
1486 | | Service | applications, enterprise may have |
1487 | | Intent | multiple types of end-users. |
1488 | | | Example: Request access to VPN |
1489 | | | service. |
1490 | | | Request video conference between |
1491 | | | end-user A and B. |
1492 | +---------------------------------------------------+
1493 | | Strategy | This includes models and policy |
1494 | | Intent | intents designed by end-users to be |
1495 | | | used by end-user intents and their |
1496 | | | applications. |
1497 | | | Example: Create a video conference |
1498 | | | type for a weekly meeting. |
1499 +------------------------------------------------------------------+
1500 |Enterprise | Network | Service provided by the |
1501 |Administrator | Service | administrator to the end-users |
1502 |(internal or | Intent | and their applications. |
1503 | MSP) | | Example: For any end-user of |
1504 | | | application X, the arrival of |
1505 | | | hologram objects of all the remote |
1506 | | | tele-presenters should be |
1507 | | | synchronised within 50ms to reach |
1508 | | | the destination viewer for each |
1509 | | | conversation session. |
1510 | | | Create management VPN connectivity |
1511 | | | for type of service A. |
1512 | | | Operational statement: The job of |
1513 | | | the network layer is to ensure that |
1514 | | | the delay is between 50-70ms through|
1515 | | | the routing algorithm. At the same |
1516 | | | time,the node resources need to meet|
1517 | | | the bandwidth requirements of 4K |
1518 | | | video conferences. |
1519 +------------------------------------------------------------------+
1520 | | Network | Administrator requires network wide |
1521 | | Intent | configuration (e.g. underlay, |
1522 | | | campus) or resource configuration |
1523 | | | (switches, routers, policies). |
1524 | | | Example: Configure switches in |
1525 | | | campus network 1 to prioritise |
1526 | | | traffic of type A. |
1527 | | | Configure YouTube as business |
1528 | | | non-relevant. |
1529 | +---------------------------------------------------+
1530 | | Operational | Administrator requests execution of |
1531 | | Task Intent | any automated task other than |
1532 | | | network service intents and network |
1533 | | | intents. |
1534 | | | Example: Request network security |
1535 | | | automated tasks such as web |
1536 | | | filtering and DDOS cloud protection.|
1537 | +---------------------------------------------------+
1538 | | Strategy | Administrator designs models, policy|
1539 | | Intent | intents and workflows to be used by |
1540 | | | other intents. Automate any tasks |
1541 | | | that administrator often performs. |
1542 | | | Example: In case of emergency, |
1543 | | | automatically shift all traffic of |
1544 | | | type A through network N. |
1545 | | | |
1546 +--------------+-------------+-------------------------------------+
1547 | Application | End-User | End-user service / application |
1548 | Developer | Intent | intent API provided to the |
1549 | | | application developers. |
1550 | | | Example: API for request to open a |
1551 | | | VPN service. |
1552 | +---------------------------------------------------+
1553 | | Network | Network service API provided to |
1554 | | Service | application developers. |
1555 | | Intent | Example: API for request network |
1556 | | | bandwidth and latency for |
1557 | | | hosting video conference. |
1558 | +---------------------------------------------------+
1559 | | Network | Network API provided to application |
1560 | | Intent | developers. |
1561 | | | Example: API for request of network |
1562 | | | devices configuration. |
1563 | +---------------------------------------------------+
1564 | | Operational | Operational task intent API provided|
1565 | | Task Intent | to the trusted application developer|
1566 | | | (internal DevOps). |
1567 | | | Example: API for requesting |
1568 | | | automatic monitoring and |
1569 | | | interception for network security |
1570 | +---------------------------------------------------+
1571 | | Strategy | Application developer designs |
1572 | | Intent | models, policy intents and building |
1573 | | | blocks to be used by other intents. |
1574 | | | This is for the trusted internal |
1575 | | | DevOps. |
1576 | | | Example: API for strategy intent in |
1577 | | | case of emergencies. |
1578 | | | |
1579 +--------------+-------------+-------------------------------------+
1580 Table 6 - Intent Classification for Enterprise Solution
1582 6.5.2. Intent Categories
1584 The following are the proposed categories:
1585 o Intent Scope: C1=Connectivity, C2=Security/Privacy,
1586 C3=Application, C4=QoS
1587 o Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN
1588 o Abstraction (ABS): C1=Technical (with technical feedback),
1589 C2=Non-technical (without technical feedback), see section 5.2.
1590 o Life-cycle (L-C): C1=Persistent (full life-cycle), C2=Transient
1591 (short lived)
1593 The following is the intent classification table example for
1594 enterprise solutions.
1596 +---------------+-------------+-----------+--------+-----+-----+
1597 | Intent User | Intent Type | Intent | Net | ABS | L-C |
1598 | | | Scope | | | |
1599 | | +-----------+--------+-----+-----+
1600 | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|
1601 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1602 | End-User | Customer | | | | | | | | | | | |
1603 | | Service | | | | | | | | | | | |
1604 | | Intent | | | | | | | | | | | |
1605 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1606 | | Strategy | | | | | | | | | | | |
1607 | | Intent | | | | | | | | | | | |
1608 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1609 | Enterprise | Network | | | | | | | | | | | |
1610 | Administrator | Service | | | | | | | | | | | |
1611 | | Intent | | | | | | | | | | | |
1612 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1613 | | Network | | | | | | | | | | | |
1614 | | Intent | | | | | | | | | | | |
1615 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1616 | | Operational | | | | | | | | | | | |
1617 | | Task | | | | | | | | | | | |
1618 | | Intent | | | | | | | | | | | |
1619 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1620 | | Strategy | | | | | | | | | | | |
1621 | | Intent | | | | | | | | | | | |
1622 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1623 | Application | End-User | | | | | | | | | | | |
1624 | Developer | Intent | | | | | | | | | | | |
1625 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1626 | | Network | | | | | | | | | | | |
1627 | | Service | | | | | | | | | | | |
1628 | | Intent | | | | | | | | | | | |
1629 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1630 | | Network | | | | | | | | | | | |
1631 | | Intent | | | | | | | | | | | |
1632 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1633 | | Operational | | | | | | | | | | | |
1634 | | Task | | | | | | | | | | | |
1635 | | Intent | | | | | | | | | | | |
1636 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1637 | | Strategy | | | | | | | | | | | |
1638 | | Intent | | | | | | | | | | | |
1639 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1640 Table 7 - Intent Categories for Enterprise Solution
1642 7. Conclusions
1644 This document is aligned with the RG objectives and supports
1645 investigations into intent-driven networking by proposing an intent
1646 categorization methodology and taxonomy. It brings clarification on
1647 what an intent represents for different stakeholders through the
1648 proposal of an Intent Classification approach, ensuring that a
1649 common understanding among all the participants exists. This,
1650 together with the proposed intent taxonomy provides a solid
1651 foundation for future intent-related topic discussions within NMRG.
1653 The benefits of this intent classification draft in the research
1654 community have been demonstrated through a PoC implementation [POC-
1655 IBN] in which the draft's concepts at different levels corresponding
1656 to different stakeholders have been applied to.
1658 8. Security Considerations
1660 This document identifies the security and privacy as categories of
1661 the intent scope. The intents could be solely security intents and
1662 privacy intents or security can be embedded in the intents that
1663 include also connectivity, application, and QoS scope.
1665 Security and privacy scope, is when the intent specifies the security
1666 characteristics of the network, customers, or end-users, and privacy
1667 for customers and end-users.
1669 More details of these security intents would be described in future
1670 documents that specify architecture, functionality, user intents and
1671 models. As well, an analysis of the security considerations of the
1672 overall intent-based system is provided in section 10 of [CLEMM].
1674 9. IANA Considerations
1676 This document has no actions for IANA.
1678 10. Contributors
1680 The following people all contributed to creating this document:
1682 Xueyuan Sun, China Telecom
1683 Will (Shucheng) Liu, Huawei
1684 Ying Chen, China Unicom
1685 John Strassner, Huawei
1686 Weiping Xu, Huawei
1687 Richard Meade, Huawei
1689 11. Acknowledgments
1691 Special thanks to Xueyuan Sun from China Telecom for significant
1692 contributions to this document, and to Will (Shucheng) Liu from
1693 Huawei for contributions and guidance.
1695 This document has benefited from reviews, suggestions, comments and
1696 proposed text provided by the following members, listed in
1697 alphabetical order: Mehdi Bezahaf, Brian E Carpenter, Laurent
1698 Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome
1699 Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav
1700 Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, Jeff
1701 Tantsura.
1703 We thank to Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide
1704 Borsatti, for contributing with their 'A multi-level approach to
1705 IBN' PoC demonstration a first attempt to adopt the intent
1706 classification methodology.
1708 12. References
1710 12.1. Normative References
1712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1713 Requirement Levels", BCP 14, RFC 2119, March 1997.
1715 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
1716 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
1717 Networking: Definitions and Design Goals", RFC 7575, June
1718 2015.
1720 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
1721 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based
1722 Management Framework for the Simplified Use of Policy
1723 Abstractions (SUPA)", March 2018.
1725 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
1726 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson,
1727 M., Perry, J., Waldbusser, S., "Terminology for Intent-
1728 driven Management", RFC 3198, November 2001.
1730 [CLEMM] A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, "Intent-
1731 Based Networking - Concepts and Overview", Work in
1732 Progress, draft-irtf-nmrg-ibn-concepts-definitions-03,
1733 February 2021, https://tools.ietf.org/html/draft-irtf-nmrg-
1734 ibn-concepts-definitions-05
1736 12.2. Informative References
1738 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
1739 Network Configuration Protocol (NETCONF)", RFC 6020,
1740 October 2010.
1742 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W.
1743 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic
1744 Optimization (ALTO) Protocol", September 2014.
1746 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017,
1747 .
1750 [ONF] ONF, "Intent Definition Principles", 2017,
1751 .
1755 [ONOS] ONOS, "ONOS Intent Framework", 2017,
1756 .
1759 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions",
1760 2017, .
1763 [ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun,
1764 "Autonomic IPv6 Edge Prefix Management in Large-scale
1765 Networks", draft-ietf-anima-prefix-management-07 (work in
1766 progress), December 2017.
1768 [TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of
1769 Autonomous Networks: Empowering Digital Transformation For
1770 the Telecoms Industry, inform.tmforum.org, 15 May, 2019.
1772 [POC-IBN] Barbara Martini, Walter Cerroni, Molka Gharbaoui, Davide
1773 Borsatti, "A multi-level approach to IBN", July 2020,
1774 https://www.ietf.org/proceedings/108/slides/slides-108-
1775 nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-
1776 ibn-02
1778 [Bezhaf19] Bezahaf, M., Hernandez, MP, Bardwell, L., Davies, E.,
1779 Broadbent, M.,King, D. and Hutchison, D. , "Self-Generated Intent-
1780 Based System," 2019 10th International Conference on Networks of the
1781 Future (NoF), 2019.
1783 [Leivadeas21] Leivadeas, A. and Falkner, M., "VNF Placement Problem:
1784 A Multi-Tenant Intent-Based Networking Approach," 24th Conference on
1785 Innovation in Clouds, Internet and Networks and Workshops (ICIN),
1786 2021.
1788 [Davoli21] Davoli, G., "Programmability and Management of Software-
1789 defined Network Infrastructures", 2021
1791 [Padovan20] Padovan, S., "Design and Implementation of a Blockchain
1792 Intent Management System", 2020.
1794 [Mehmood21] Mehmood, K., Kralevska, K., and Palma, D., "Intent-driven
1795 Autonomous Network and Service Management in Future Networks: A
1796 Structured Literature Review", 2021.
1798 [Szilagyi21] Szilagyi, P., "I2BN: Intelligent Intent Based Networks",
1799 Journal of ICT Standardization, 2021.
1801 [Bezahaf21] Bezahaf, M., Davies, E., Rotsos, C. and Race, N., "To All
1802 Intents and Purposes: Towards Flexible Intent Expression," 2021 IEEE
1803 7th International Conference on Network Softwarization (NetSoft),
1804 2021.
1806 [Banerjee21] Banerjee,A., Mwanje. S. and Carle, G., "Contradiction
1807 Management in Intent-driven Cognitive Autonomous RAN", 2021.
1809 [Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H. H., Ye, Q., Wang, C.,
1810 and Zhao, B. Y., "Safely and automatically updating in-network ACL
1811 configurations with intent language", SIGCOMM '19, 2019.
1813 [Jacobs18]Jacobs, A.S., Pfitscher,R.J., Ferreira, R.A., and
1814 Granville, L.Z., "Refining Network Intents for Self-Driving
1815 Networks", Proceedings of the Afternoon Workshop on Self-Driving
1816 Networks (SelfDN 2018), 2018.
1818 [IFIP-NSM] IFIP - Network and Service Management Taxonomy
1819 https://www.simpleweb.org/ifip/taxonomy.html
1821 Authors' Addresses
1823 Chen Li
1824 China Telecom
1825 No.118 Xizhimennei street, Xicheng District
1826 Beijing 100035
1827 P.R. China
1828 Email: lichen.bri@chinatelecom.cn
1830 Olga Havel
1831 Huawei Technologies
1832 Ireland
1833 Email: olga.havel@huawei.com
1835 Adriana Olariu
1836 Huawei Technologies
1837 Ireland
1838 Email: adriana.olariu@huawei.com
1840 Pedro Martinez-Julia
1841 NICT
1842 Japan
1843 Email: pedro@nict.go.jp
1845 Jeferson Campos Nobre
1846 Federal University of Rio Grande do Sul
1847 Porto Alegre
1848 Brazil
1849 Email: jcnobre@inf.ufrgs.br
1851 Diego R. Lopez
1852 Telefonica I+D
1853 Don Ramon de la Cruz, 82
1854 Madrid 28006
1855 Spain
1856 Email: diego.r.lopez@telefonica.com