idnits 2.17.1
draft-li-nmrg-intent-classification-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (April 20, 2020) is 1459 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC7575' is defined on line 1482, but no explicit
reference was found in the text
== Unused Reference: 'RFC8328' is defined on line 1487, but no explicit
reference was found in the text
== Unused Reference: 'RFC3198' is defined on line 1492, but no explicit
reference was found in the text
== Unused Reference: 'RFC6020' is defined on line 1499, but no explicit
reference was found in the text
== Unused Reference: 'RFC7285' is defined on line 1503, but no explicit
reference was found in the text
== Unused Reference: 'SUPA' is defined on line 1520, but no explicit
reference was found in the text
== Unused Reference: 'ANIMA-Prefix' is defined on line 1524, but no
explicit reference was found in the text
Summary: 0 errors (**), 0 flaws (~~), 9 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: October 2020 W. Liu
5 A. Olariu
6 Huawei Technologies
7 P. Martinez-Julia
8 NICT
9 J. Nobre
10 UFRGS
11 D. Lopez
12 Telefonica I+D
13 April 20, 2020
15 Intent Classification
16 draft-li-nmrg-intent-classification-03
18 Status of this Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at
32 http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six
35 months and may be updated, replaced, or obsoleted by other documents
36 at any time. It is inappropriate to use Internet-Drafts as
37 reference material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on October 16, 2020.
41 Copyright Notice
43 Copyright (c) 2020 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with
51 respect to this document. Code Components extracted from this
52 document must include Simplified BSD License text as described in
53 Section 4.e of the Trust Legal Provisions and are provided without
54 warranty as described in the Simplified BSD License.
56 Abstract
58 RFC7575 defines Intent as an abstract high-level policy used to
59 operate the network. Intent management system includes an interface
60 for users to input requests and an engine to translate the intents
61 into the network configuration and manage their lifecycle. Up to
62 now, there is no commonly agreed definition, interface or model of
63 intent.
65 This document discusses what intent means to different stakeholders,
66 describes different ways to classify intent, and an associated
67 taxonomy of this classification. This is a foundation for discussion
68 intent related topics.
70 Table of Contents
72 1. Introduction ................................................ 3
73 2. Acronyms .................................................... 5
74 3. Abstract intent requirements ................................. 5
75 3.1. What is Intent?......................................... 6
76 3.2. Intent Solutions & Intent Users ......................... 6
77 3.3. Current Problems & Requirements ......................... 7
78 3.4. Intent Types that need to be supported .................. 9
79 4. Functional Characteristics and Behavior ..................... 11
80 4.1. Abstracting Intent Operation ........................... 11
81 4.2. Intent User Types ...................................... 11
82 4.3. Intent Scope .......................................... 12
83 4.4. Intent Network Scope ................................... 13
84 4.5. Intent Abstraction ..................................... 13
85 4.6. Intent Lifecycle ....................................... 13
86 4.7. Hierarchy ............................................. 14
87 5. Intent Classification ....................................... 14
88 5.1. Intent Classification Methodology ...................... 15
89 5.2. Intent Taxonomy........................................ 17
90 5.3. Intent Classification for Carrier Solution ............. 19
91 5.3.1. Intent Users and Intent Types ..................... 19
92 5.3.2. Intent Categories ................................. 22
93 5.4. Intent Classification for Data Center Solutions ......... 25
94 5.4.1. Intent Users and Intent Types ..................... 25
95 5.4.2. Intent Categories ................................. 29
96 5.5. Intent Classification for Enterprise Solution .......... 31
97 5.5.1. Intent Users and Intent Types ..................... 31
98 5.5.2. Intent Categories ................................. 34
99 6. Involvement of intent in the application of AI to Network Manage
100 ment .......................................................... 36
101 7. Security Considerations ..................................... 37
102 8. IANA Considerations ........................................ 37
103 9. Contributors ............................................... 37
104 10. Acknowledgments ........................................... 38
105 11. References ................................................ 38
106 11.1. Normative References .................................. 38
107 11.2. Informative References ................................ 38
109 1. Introduction
111 The vision of intent-driven networks has attracted a lot of
112 attention, as it promises to simplify the management of networks by
113 human operators by simply specifying what should happen on the
114 network, without giving any instructions on how to do it. This
115 promise led many telecom companies to begin adopting this new
116 paradigm, and many SDOs to propose various intent variants.
118 All SDOs, such as IETF [ANIMA], ONF [ONF], ONOS [ONOS], have
119 proposed intents as a declarative interface for defining a set of
120 network operations to execute.
122 As such, IETF [ANIMA] defines intent as a declarative policy and
123 focuses on providing a more complete definition of it, a tentative
124 format, and a life-cycle. Within ONF [ONOS] intent is represented as
125 a list of CLI commands that allows users to pass low-level details
126 on the network, such as flows, or host addresses. ONF through its
127 Boulder and Aspen projects focuses on NBI semantics and intent
128 models.
130 As it can be observed, each of these SDOs came up with their own way
131 of specifying an intent, and with their own understanding of what an
132 Intent is in terms of the level of abstraction, intended users or
133 scenarios.
135 However, all intent approaches proposed by SDOs share the same
136 following features:
138 o It must be declarative in nature, meaning that a user specifies
139 the goal on the network without specifying how to achieve that
140 goal
142 o It must be vendor agnostic, in the sense that it abstracts the
143 network capabilities, or the network infrastructure from the
144 user, and it can be ported across different platforms
146 o It must provide an easy-to-use interface, which simplifies the
147 users' interaction with the intent system through the usage of
148 familiar terminology or concepts.
150 o It should be able to detect and resolve intent conflicts.
152 Currently, work is underway on unifying a common understanding of
153 intent concepts and terminology. [CLEMM] is currently leading these
154 efforts by defining intent as higher-level declarative policy that
155 operates at the level of network and services it provides, and by
156 capturing the differences between intent, policy and service.
158 However, even with proposed intent concepts and terminology, and
159 agreement on common intent characteristics, an intent may still be
160 viewed in different ways by different stakeholders for different use
161 cases and solutions.
163 Thus, the goal of this document is to bring clarity to what an
164 intent represents for different stakeholders, by means of
165 classification on various dimensions, such as solutions, users and
166 intent types. This classification would ensure a common
167 understanding across all participants and it can be used to identify
168 the scope and priorities of individual projects, PoCs, research or
169 open-source projects.
171 This is achieved by proposing initial classification tables and the
172 methodology used for generating them. This methodology can be used
173 to update the tables by adding or removing different solutions,
174 users or intent types in order to cater for future scenarios,
175 applications or domains.
177 This draft together with [CLEMM] aims to become the foundation for
178 future intent-related topic discussions where all participants have
179 the same common understanding.
181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
183 document are to be interpreted as described in RFC 2119 [RFC2119].
185 2. Acronyms
187 CFS: Customer Facing Service
189 CLI: Command Line Interface
191 DC: Data Center
193 ECA: Event-Condition-Action
195 RFS: Resource Facing Service
197 SDO: Standards Development Organization
199 SUPA: Simplified Use of Policy Abstractions
201 VPN: Virtual Private Network
203 3. Abstract intent requirements
205 In order to understand the different intent requirements that would
206 drive intent classification, we first need to understand what intent
207 means for different intent users.
209 3.1. What is Intent?
211 The term Intent has become very widely used in the industry for
212 different purposes, sometimes it is not even in agreement with SDO
213 shared principles mentioned in the Introduction.
215 Different stakeholders consider an intent to be an ECA policy, a GBP
216 policy, a business policy, a network service, a customer service, a
217 network configuration, application / application group policy, any
218 operator/administrator task, network troubleshooting / diagnostics /
219 test, a new app, a marketing term for existing
220 management/orchestration capabilities, etc. Their intent is
221 sometimes technical, non-technical, abstract or technology specific.
222 For some stakeholders, intent is a subset of these and for other
223 stakeholders intent is all of these. It has in some cases become a
224 term to replace a very generic 'service' or 'policy' terminology.
226 Concerning this, [CLEMM] draft brings clarification with relation to
227 what an intent is and how it differentiates from policies and
228 services.
230 While it is easier for those familiar with different standards to
231 understand what service, CFS, RFS, resource, policy continuum, ECA
232 policy, declarative policy, abstract policy or intent policy is, it
233 may be more difficult for the wider audience. Intent is very often
234 just a synonym for policy. Those familiar with policies understand
235 the difference between a business, intent, declarative, imperative
236 and ECA policy. But maybe the wider audience does not understand the
237 difference and sometimes equates the policy to an ECA policy.
239 Therefore, it is important to start a discussion in the industry
240 about what intent is for different solutions and intent users. It is
241 also imperative to try to propose some intent categories /
242 classifications that could be understood by a wider audience. This
243 would help us define intent interfaces, DSLs and models.
245 3.2. Intent Solutions & Intent Users
247 Different Solutions and Actors have different requirements,
248 expectations and priorities for intent driven networking. They
249 require different intent types and have different use cases. Some
250 users are more technical and require intents that expose more
251 technical information. Other users do not understand networks and
252 require intents that shield them from different networking concepts
253 and technologies. The following are the solutions and intent users
254 that intent driven networking needs to support:
256 +--------------------+------------------------------------+
257 | Solutions | Intent Users |
258 +--------------------+------------------------------------+
259 | Carrier Networks | Network Operator |
260 | | Service Designers |
261 | | Service Operators |
262 | | Customers/Subscribers |
263 +--------------------+------------------------------------+
264 | DC Networks | Cloud Administrator |
265 | | Underlay Network Administrator |
266 | | App Developers |
267 | | End Users |
268 +--------------------+------------------------------------+
269 | Enterprise Networks| Enterprise Administrator |
270 | | App Developers |
271 | | End Users |
272 +--------------------+------------------------------------+
274 o For carrier networks scenario, for example, if the end users
275 wants to watch high-definition video, then the intent is to
276 convert the video image to 1080p rate for the users.
278 o For DC networks scenario, administrators have their own clear
279 network intent such as load balancing. For all traffic flows that
280 need NFV service chaining, restrict the maximum load of any VNF
281 node/container below 50% and the maximum load of any network link
282 below 70%.
284 o For Enterprise Networks scenario, enterprise administrators
285 express their intent from an external client(application service
286 provider).For example, when hosting a video conference, multiple
287 remote access is required. The intent expressed to the network
288 operator: For any user of this application, the arrival time of
289 hologram objects of all the remote tele-presenters should be
290 synchronised within 50ms to reach the destination viewer for each
291 conversation session.
293 3.3. Current Problems & Requirements
295 Network APIs and CLIs are too complex due to the fact that they
296 expose technologies & topologies. App developers and end-users do
297 not want to set IP Addresses, VLANs, subnets, ports, etc. Operators
298 and administrators would also benefit from the simpler interfaces,
299 like:
301 o Allow Customer Site A to be connected to Internet via Network B
303 o Allow User A to access all internal resources, except the Server
304 B
306 o Allow User B to access Internet via Corporate Network A
308 o Move all Users from Corporate Network A to the Corporate Network
309 B
311 o Request Gold VPN service between my sites A, B and C
313 o Provide CE Redundancy for all Customer Sites
315 o Add Access Rules to my Service
317 Networks are complex, with many different protocols and
318 encapsulations. Some basic questions are not easy to answer:
320 o Can User A talk to User B?
322 o Can Host A talk to Host B?
324 o Are there any loops in my network?
326 o Are Network A and Network B connected?
328 o Can User A listen to communications between Users B & C?
330 Operators and Administrators manually troubleshoot and fix their
331 networks and services. They instead want:
333 o a reliable network that is self-configured and self-assured based
334 on the intent
336 o to be notified about the problem before the user is aware
338 o automation of network/service recovery based on intent (self-
339 healing, self-optimization)
341 o to get suggestions about correction/optimization steps based on
342 experience (historical data & behaviour)
344 Therefore, Operators and Administrators want to:
346 o simplify and automate network operations
347 o simplify definitions of network services
349 o provide simple customer APIs for Value Added Services (operators)
351 o be informed if the network or service is not behaving as
352 requested
354 o enable automatic optimization and correction for selected
355 scenarios
357 o have systems that learn from historic information and behaviour
359 End-Users cannot build their own services and policies without
360 becoming technical experts and they must perform manual maintenance
361 actions. Application developers and end-users/subscribers want to be
362 able to:
364 o build their own network services with their own policies via
365 simple interfaces, without becoming networking experts
367 o have their network services up and running based on intent and
368 automation only, without any manual actions or maintenance
370 3.4. Intent Types that need to be supported
372 The following intent types need to be supported, in order to address
373 the requirements from different solutions and intent users:
375 o Customer network service intent
377 o for customer self-service
379 o for service operator orders
381 o for intent driven network configuration, verification,
382 correction and optimization
384 o Network resource management
386 o For network configuration
388 o For automated lifecycle management of network configurations
390 o For network resources (switches, routers, routing, policies,
391 underlay)
393 o Cloud and cloud resource management
394 o For DC configuration, VMs, DB Servers, APP Servers
396 o For communication between VMs
398 o For cloud resource lifecycle management (policy driven self-
399 configuration & auto-scaling & recovery/optimization)
401 o Network Policy intent
403 o For security, QoS, application policies, traffic steering, etc
405 o For configuring & monitoring policies, alarms generation for
406 non-compliance, auto-recovery
408 o Task based intents
410 o For network migration
412 o For server replacements
414 o For device replacements
416 o For network software upgrades
418 o To automate any tasks that operators/administrator often
419 perform
421 o System policies intents
423 o For intent management system policies
425 o For design models and policies for network service design
427 o For design models and policies for network design
429 o For design workflows, models and policies for task based
430 intents
432 o Intents that affect other intents
434 o It may be task based intent that modifies many other intents.
436 o The task itself is short-lived, but the modification of other
437 intents has an impact on their lifecycle, so those changes
438 must continue to be continuously monitored and self-
439 corrected/self-optimized.
441 4. Functional Characteristics and Behavior
443 Intent can be used to operate immediately on a target (much like
444 issuing a command), or whenever it is appropriate (e.g., in response
445 to an event). In either case, intent has a number of behaviors that
446 serve to further organize its purpose, as described by the following
447 subsections.
449 4.1. Abstracting Intent Operation
451 The modelling of Intents can be abstracted using the following three-
452 tuple:
454 {Context, Capabilities, Constraints}
456 o Context grounds the intent, and determines if it is relevant or
457 not for the current situation. Thus, context selects intents
458 based on applicability.
460 o Capabilities describe the functionality that the intent can
461 perform. Capabilities take different forms, depending on the
462 expressivity of the intent as well as the programming paradigm(s)
463 used.
465 o Constraints define any restrictions on the capabilities to be
466 used for that particular context
468 Metadata can be attached via strategy templates to each of the
469 elements of the three-tuple, and may be used to describe how the
470 intent should be used and how it operates, as well as prescribe any
471 operational dependencies that must be taken into account.
473 4.2. Intent User Types
475 Intent user types, or intent actors as they are known in the area of
476 declarative policy, represent the users that define and issue the
477 intent request. Depending on the Intent Solutions, there are
478 specific intent actors. Examples of intent actors are customers,
479 network operators, service operators, enterprise, cloud, and
480 underlay network administrators, or application developers.
482 o Customers and end-users do not necessarily know the functional
483 and operational details of the network that they are using.
484 Furthermore, they lack skills to understand such details; in
485 fact, such knowledge is typically not relevant to their job. In
486 addition, the network may not expose these details to its users.
487 This class of actor focuses on the applications that they run,
488 and uses services offered by the network. Hence, they want to
489 specify policies that provide consistent behaviour according to
490 their business needs. They do not have to worry about how the
491 intents are deployed onto the underlying network, and especially,
492 whether the intents need to be translated to different forms to
493 enable network elements to understand them.
495 o Application developers work in a set of abstractions defined by
496 their application and programming environment(s). For example,
497 many application developers think in terms of objects (e.g., a
498 VPN). While this makes sense to the application developer, most
499 network devices do not have a VPN object per se; rather, the VPN
500 is formed through a set of configuration statements for that
501 device in concert with configuration statements for the other
502 devices that together make up the VPN. Hence, the view of
503 application developers matches the services provided by the
504 network, but may not directly correspond to other views of other
505 actors.
507 o Management personnel, such as network operators, may have the
508 knowledge of the underlying network. However, they may not
509 understand the details of the applications and services of
510 Customers and End-Users.
512 4.3. Intent Scope
514 Intent are used to manage the behaviour of the networks they are
515 applied to and all intents are applied within a specific scope, such
516 as:
518 o Connectivity scope, if the intent creates or modifies a
519 connection.
521 o Security scope, if the intent specifies the security
522 characteristics of the network or users.
524 o Application scope, when the intent specifies the applications to
525 be affected by the intent request
527 o QoS Scope, when the intent specifies the QoS characteristics of
528 the network
530 4.4. Intent Network Scope
532 Regardless on the intent user type, their intent request is
533 affecting the network, or network components, which are representing
534 the intent targets.
536 Thus, intent network scope, or policy target as known in the area of
537 declarative policy, can represent VNFs or PNFs, Physical Network
538 Elements, Campus networks, SD-WAN networks, radio access networks,
539 cloud edge, cloud core, branch, etc.
541 4.5. Intent Abstraction
543 Intent can be classified by whether it is necessary to feedback
544 technical network information or non-technical information to the
545 intended proponent after the intent is executed. As well, intent
546 abstraction covers the level of technical details in the intent
547 itself.
549 o For ordinary users, they do not care how the intent is executed,
550 or the details of the network. As a result, they do not need to
551 know the configuration information of the underlying network.
552 They only focus on whether the intent execution result achieves
553 the goal, and the execution effect such as the quality of
554 completion and the length of execution. In this scenario, we
555 refer to an abstraction without technical feedback.
557 o For administrators, such as network administrators, they perform
558 intents, such as allocating network resources, selecting
559 transmission paths, handling network failures, etc. They require
560 multiple feedback indicators for network resource conditions,
561 congestion conditions, fault conditions, etc. after execution. In
562 this case, we refer to an abstraction with technical feedback
564 4.6. Intent Lifecycle
566 Intents can be classified into transient and persistent intents:
568 o If intent is transient, it has no lifecycle management. As soon
569 as the specified operation is successfully carried out, the
570 intent is finished, and can no longer affect the target object.
572 o If the intent is persistent, it has lifecycle management. Once
573 the intent is successfully activated and deployed, the system
574 will keep all relevant intents active until they are deactivated
575 or removed.
577 4.7. Hierarchy
579 In different phases of the autonomous driving network [TMF-auto],
580 the intents are different. A typical example of autonomous driving
581 network Level 0 to 5 are listed as below.
583 o Level 0 - Traditional manual network: O&M personnel manually
584 control the network and obtain network alarms and logs. - No
585 intent
587 o Level 1 - Partially automated network: Automated scripts are used
588 to automate service provisioning, network deployment, and
589 maintenance. Shallow perception of network status and decision
590 making suggestions of machine; - No intent
592 o Level 2 - Automated network: Automation of most service
593 provisioning, network deployment, and maintenance comprehensive
594 perception of network status and local machine decision making;
595 - simple intent on service provisioning
597 o Level 3 - Self-optimization network: Deep awareness of network
598 status and automatic network control, meeting users' network
599 intentions. - Intent based on network status cognition
601 o Level 4 - Partial autonomous network: In a limited environment,
602 people do not need to participate in decision-making and adjust
603 themselves. - Intent based on limited AI
605 o Level 5 - Autonomous network: In different network environments
606 and network conditions, the network can automatically adapt to
607 and adjust to meet people's intentions. - Intent based on AI
609 5. Intent Classification
611 This chapter proposes an intent classification approach that may
612 help to classify mainstream intent related demos / tools.
614 The three classifications in this draft have been proposed from
615 scratch, following the methodology presented, through three
616 iterations: one for carrier Intent Solution, one for DC Intent
617 Solution, and one for enterprise Intent Solution. For each Intent
618 solution, we identified the specific Intent Users and Intent Types.
619 Then, we further identified the Intent Scope, Network Scope,
620 Abstractions, and Lifecycle requirements.
622 These classifications and the generated tables can be easily
623 extended. For example, for the DC Intent Solution, a new category is
624 identified, i.e. Resource Scope, and the classification table has
625 been extended accordingly.
627 In the future, as new scenarios, applications, and domain are
628 emerging, new classifications and taxonomies can be identified,
629 following the proposed methodology.
631 The output of the intent classification is the intent taxonomy
632 introduced in the next sections.
634 Thus, this section first introduces the proposed intent
635 classification methodology, followed by consolidated intent taxonomy
636 for three intent solutions, and then by concrete examples of intent
637 classifications for three different intent solutions (e.g. Carrier
638 Network, Data Center, and Enterprise) that were derived using the
639 proposed methodology and then can be filled in for PoCs, demos,
640 research projects or future drafts.
642 5.1. Intent Classification Methodology
644 This section describes the methodology used to derive the initial
645 classification proposed in the draft. The proposed methodology can
646 be used to create new intent classifications from scratch, by
647 analysing the solution knowledge. As well, the methodology can be
648 used to update existing classification tables by adding or removing
649 different solutions, users or intent types in order to cater for
650 future scenarios, applications or domains.
652 We first classify intents into intent types and describe each type
653 based on the solution it belongs to and what intent user it is for.
654 We than present different categories that these intent type can
655 belong to, based on intent scope, network scope, intent abstraction
656 and lifecycle.
658 +------------------------------------------+
659 |Solution Knowledge (requirements, |
660 |use cases, technologies, network, actors, |
661 |intent requirements) |
662 +----------------+-------------------------+
663 |
664 | Input
665 v
666 +--------+--------+
667 |Identify Intent |
668 |Solution +------------+
669 | | |
670 +---------^-+-----+ |
671 R1 | | U1 |
672 | | |
673 +-------------+ U8 | | R2 +--v----------------+
674 |Identify New +-----------+ | | +-----------> Identify |
675 |Categories | R8 | | | | U2 | Intent |
676 | <---------- | | | | +---------+ User Types |
677 +--------+----+ | | | | | | +-------------------+
678 ^ | | | | | |
679 | +-+-v-+-v---+-v+
680 +--------+----+ U7 | | R3 +-------------------+
681 |Identify +------->Intent +--------> Identify |
682 |Lifecycle | R7 |Classification| U3 | Type |
683 |Requirements <-------+ <--------+ of Intent |
684 +--------+----+ +-^--^-+--^-+--+ +-------------------+
685 ^ || | | | |
686 | || | | | |
687 +--------+----+ || | | | | R4 +-------------------+
688 |Identify | U6 || | | | +-----------> Identify |
689 |Abstractions +----------| | | | U4 | Intent |
690 | <----------+ | | +-------------+ Scope |
691 +-------+-----+ R6 | | +-------+-----------+
692 ^ | | |
693 | U5 | |R5 |
694 | +-------+-v-------+ |
695 | |Identify Network | |
696 +----------+Scope <----------------+
697 +-----------------+
699 In the above methodology, the arrows mean the following:
701 o Input represents the Solution Knowledge comprising of knowledge
702 about solution requirements, targeted use cases, available
703 technologies and networks, actors, intent requirements.
705 o R1-U1: Review existing classification and use/add/remove the
706 intent solution
708 o R2-U2: Review existing classification and use/add/remove the
709 intent user type
711 o R3-U3: Review existing classification and use/add/remove the
712 intent types
714 o R4-U4: Review existing classification and use/add/remove the
715 intent scopes
717 o R5-U5: Review existing classification and use/add/remove the
718 network scopes
720 o R6-U6: Review existing classification and use/add/remove the
721 abstractions
723 o R7-U7: Review existing classification and use/add/remove the
724 lifecycle requirements
726 o R8-U8: Review existing classification and use/add the newly
727 identified categories.
729 5.2. Intent Taxonomy
731 The following taxonomy describes the various intent solutions,
732 intent user types, intent types, intent scopes, network scopes,
733 abstractions and lifecycle and represents the output of the intent
734 classification tables for each of the solutions addressed (i.e.
735 Carrier Solution, Data Center, and Enterprise).
737 +--------------------------------+
738 |Carrier Enterprise |
739 +-->|Data Center |
740 | +--------------------------------+
741 | +--------------------------------+
742 | |Customer |
743 +----------+ | |Network or Service Operator |
744 +>+Solutions +--+ |Application Developer |
745 | +----------+ +->|Enterprise Administrator |
746 | | |Cloud Administrator |
747 | +----------+ | |Underlay Network Administrator |
748 +>+Intent +---+ +--------------------------------+
749 | |User | +--------------------------------+
750 | |Types | |Customer Service Intent |
751 | +----------+ |Strategy Intent |
752 | +----------+ |Network Service Intent |
753 +>+Intent +----->|Underlay Network Service Intent |
754 +------+ | |Type | |Network Intent |
755 |Intent+-+ +----------+ |Underlay Network Intent |
756 +------+ | |Operational Task Intent |
757 | +----------+ |Cloud Management Intent |
758 +>+Intent +---+ |Cloud Resource Management Intent|
759 | |Scope | | +--------------------------------+
760 | +----------+ | +--------------------------------+
761 | +->|Connectivity Application |
762 | +----------+ |Security QoS |
763 +>+Network +---+ +--------------------------------+
764 | |Scope | | +--------------------------------+
765 | +----------+ | |Radio Access Branch |
766 | +->|Transport Access SD-WAN |
767 | +----------+ |Transport Aggr. VNF PNF |
768 +>+Abstrac +----+ |Transport Core Phisical |
769 | |tion | | |Cloud Edge Logical |
770 | +----------+ | |Cloud Core Campus |
771 | +----------+ | +--------------------------------+
772 +>+Life | | +--------------------------------+
773 |cycle +--+ +>|Technical Non-Technical |
774 +----------+ | +--------------------------------+
775 | +--------------------------------+
776 +-->|Persistent Transient |
777 +--------------------------------+
779 5.3. Intent Classification for Carrier Solution
781 5.3.1. Intent Users and Intent Types
783 The following table describes the Intent Users in Carrier Solutions
784 and Intent Types with their descriptions for different intent users.
786 +-------------+-------------+--------------------------------------+
787 | Intent User | Intent Type | Intent Type Description |
788 +------------------------------------------------------------------+
789 | Customer/ |Customer |Customer Self-Service with SLA and |
790 | Subscriber |Service |Value Added Service |
791 | |Intent |Example: Always maintain high quality |
792 | | |of service and high bandwidth for gold|
793 | | |level users. |
794 | +----------------------------------------------------+
795 | |Strategy |Customer designs models and policy |
796 | |Intent |intents to be used by Customer Service|
797 | | |Intents. |
798 | | |Example: Request reliable service |
799 | | |during peak traffic periods for apps |
800 | | |of type video. |
801 +------------------------------------------------------------------+
802 |Network |Network |Service provided by Network Service |
803 |Operator |Service |Operator to the Customer |
804 | |Intent |(e.g. the Service Operator) |
805 | | |Example: Request network service with |
806 | | |delay guarantee for access customer A.|
807 +-------------+-------------+--------------------------------------+
808 | Customer/ |Customer |Customer Self-Service with SLA and |
809 | Subscriber |Service |Value Added Service |
810 | |Intent |Example: Always maintain high quality |
811 | | |of service and high bandwidth for gold |
812 | | |level users. |
813 | +-----------------------------------------------------+
814 | |Strategy |Customer designs models and policy |
815 | |Intent |intents to be used by Customer Service |
816 | | |Intents. |
817 | | |Example: Request reliable service |
818 | | |during peak traffic periods for |
819 | | |applications of type video. |
820 +-------------+-------------+---------------------------------------+
821 |Network |Network |Service provided by the Network Service|
822 |Operator |Service |Operator to the Customer (e.g. the |
823 | |Intent |Service Operator) |
824 | | |Example: Request network service with |
825 | | |delay guarantee for access customer A. |
826 | +-----------------------------------------------------+
827 | |Network |Network Operator requests network-wide |
828 | |Intent |(service underlay or other network-wide|
829 | | |configuration) or network resource |
830 | | |configurations (switches, routers, |
831 | | |routing, policies). Includes |
832 | | |Connectivity, Routing, QoS, Security, |
833 | | |Application Policies, Traffic Steering |
834 | | |Policies, Configuration policies, |
835 | | |Monitoring policies, alarm generation |
836 | | |for non-compliance, auto-recovery, etc.|
837 | | |Example: Request high priority queueing|
838 | | |for traffic of class A. |
839 | +-----------------------------------------------------+
840 | |Operational |Network Operator requests execution of |
841 | |Task |any automated task other than Network |
842 | |Intent |Service Intent and Network Intent |
843 | | |(e.g. Network Migration, Server |
844 | | |Replacements, Device Replacements, |
845 | | |Network Software Upgrades. |
846 | | |Example: Request migration of all |
847 | | |services in Network N to backup path P.|
848 | +-----------------------------------------------------+
849 | |Strategy |Network Operator designs models, policy|
850 | |Intent |intents and workflows to be used by |
851 | | |Network Service Intents, Network |
852 | | |Intents and Operational Task Intents. |
853 | | |Workflows can automate any tasks that |
854 | | |Network Operator often performed in |
855 | | |addition to Network Service Intents and|
856 | | |Network Intents |
857 | | |Example: Ensure the load on any link in|
858 | | |the network is not higher than 50%. |
859 +-------------+-------------+---------------------------------------+
860 +-------------+-------------+---------------------------------------+
861 | Service | Customer | Service Operator's Customer Orders, |
862 | Operator | Service | Customer Service / SLA |
863 | | Intent | Example: Provide service S with |
864 | | | guaranteed bandwidth for customer A. |
865 | +-----------------------------------------------------+
866 | | Network | Service Operator's Network Orders / |
867 | | Service | Network SLA |
868 | | | Example: Provide network guarantees in|
869 | | Intent | terms of security, low latency and |
870 | | | high bandwidth |
871 | +-----------------------------------------------------+
872 | | Operational | Service Operator requests execution of|
873 | | Task | the any automated task other than |
874 | | Intent | Customer Service Intent and Network |
875 | | | Service Intent |
876 | | | Example: Update service operator |
877 | | | portal platforms and their software |
878 | | | regularly. Move services from Network |
879 | | | Operator 1 to Network Operator 2. |
880 | +-----------------------------------------------------+
881 | | Strategy | Service Operator designs models, |
882 | | Intent | policy intents and workflows to be |
883 | | | used by Customer Service Intents, |
884 | | | Network Service Intents and |
885 | | | Operational Task Intents. Workflows |
886 | | | can automate any tasks that Service |
887 | | | Operator often performed in addition |
888 | | | to Network Service Intents and Network|
889 | | | Intents . |
890 | | | Example: Request network service |
891 | | | guarantee to avoid network congestion |
892 | | | during special periods |
893 | | | such as Black Friday, and Christmas. |
894 +-------------+-------------+---------------------------------------+
895 |Application | Customer | Customer Service Intent API provided |
896 | Developer | Service | to the Application Developers |
897 | | Intent | Example: API to request network to |
898 | | | watch HD video 4K/8K. |
899 | +-----------------------------------------------------+
900 | | Network | Network Service Intent API provided to|
901 | | Service | the Application Developers |
902 | | Intent | Example: API to request network and |
903 | | | monitoring an traffic grooming |
904 | +-----------------------------------------------------+
905 | | Network | Network Intent API provided to the |
906 | | Intent | Application Developers |
907 | | | Example: API to request network |
908 | | | resources configuration. |
909 | +-----------------------------------------------------+
910 | | Operational | Operational Task Intent API provided |
911 | | Task | to the Application Developers. This is|
912 | | Intent | for the trusted internal Operator / |
913 | | | Service Providers / Customer DevOps |
914 | | | Example: API to request server |
915 | | | migrations. |
916 | +-----------------------------------------------------+
917 | | Strategy | Application Developer designs models, |
918 | | Intent | policy and workflows to be used by |
919 | | | Customer Service Intents, Network |
920 | | | Service Intents and Operational |
921 | | | Task Intents. This is for the trusted |
922 | | | internal Operator/Service Provider/ |
923 | | | Customer DevOps |
924 | | | Example: API to design network load |
925 | | | balancing strategies during peak times|
926 +-------------+-------------+---------------------------------------+
928 5.3.2. Intent Categories
930 The following arethe proposed categories:
931 Intent Scope: C1=Connectivity, C2=Security, C3=Application,
932 C4=QoS
933 Network Function (NF) Scope: C1=VNFs, C2=PNFs
934 Network Scope: C1=Radio Access, C2=Transport Access,
935 C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge,
936 C6=Cloud Core)
937 Abstraction(ABS): C1=Technical(with technical feedback),
938 C2=Non-technical (without technical feedback) , see Section 4.2
939 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient
940 (Short Lived)
941 The following is the Classification Table Example for Carrier.
943 +---------+---------+-----------+-----+-----------------+-----+-----+
944 | Intent | Intent | Intent | NF | Network | ABS |L-C |
945 | User | Type | Scope |Scope| Scope | | |
946 | | +-----------+-----+-----------------+-----+-----+
947 | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|
948 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
949 |Customer |Customer | | | | | | | | | | | | | | | | |
950 |/ Sub- |Service | | | | | | | | | | | | | | | | |
951 | scriber |Intent | | | | | | | | | | | | | | | | |
952 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
953 | |Strategy | | | | | | | | | | | | | | | | |
954 | |Intent | | | | | | | | | | | | | | | | |
955 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
956 |Network |Network | | | | | | | | | | | | | | | | |
957 |Operator |Service | | | | | | | | | | | | | | | | |
958 | |Intent | | | | | | | | | | | | | | | | |
959 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
960 | |Network | | | | | | | | | | | | | | | | |
961 | |Intent | | | | | | | | | | | | | | | | |
962 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
963 | |Operatio-| | | | | | | | | | | | | | | | |
964 | | nal Task| | | | | | | | | | | | | | | | |
965 | |Intent | | | | | | | | | | | | | | | | |
966 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
967 | |Strategy | | | | | | | | | | | | | | | | |
968 | |Intent | | | | | | | | | | | | | | | | |
969 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
970 |Service |Customer | | | | | | | | | | | | | | | | |
971 |Operator |Service | | | | | | | | | | | | | | | | |
972 | |Intent | | | | | | | | | | | | | | | | |
973 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
974 | |Network | | | | | | | | | | | | | | | | |
975 | |Service | | | | | | | | | | | | | | | | |
976 | |Intent | | | | | | | | | | | | | | | | |
977 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
978 | |Op Task | | | | | | | | | | | | | | | | |
979 | |Intent | | | | | | | | | | | | | | | | |
980 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
981 | |Strategy | | | | | | | | | | | | | | | | |
982 | |Intent | | | | | | | | | | | | | | | | |
983 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
984 |App |Customer | | | | | | | | | | | | | | | | |
985 |Developer|Intent | | | | | | | | | | | | | | | | |
986 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
987 | |Network | | | | | | | | | | | | | | | | |
988 | |Service | | | | | | | | | | | | | | | | |
989 | |Intent | | | | | | | | | | | | | | | | |
990 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
991 | |Network | | | | | | | | | | | | | | | | |
992 | |Intent | | | | | | | | | | | | | | | | |
993 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
994 | |Op Task | | | | | | | | | | | | | | | | |
995 | |Intent | | | | | | | | | | | | | | | | |
996 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
997 | |Strategy | | | | | | | | | | | | | | | | |
998 | |Intent | | | | | | | | | | | | | | | | |
999 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1000 5.4. Intent Classification for Data Center Solutions
1002 5.4.1. Intent Users and Intent Types
1004 The following table describes the Intent Users in DCN Solutions and
1005 Intent Types with their descriptions for different intent users.
1007 +---------------+-------------+-------------------------------------+
1008 | Intent User | Intent Type | Intent Type Description |
1009 +-------------------------------------------------------------------+
1010 | Customer / | Customer | Customer Self-Service via Tenant |
1011 | Tenants | Intent | Portal, Customers may have multiple |
1012 | | | type of end users. |
1013 | | | Example: Request GPU computing and |
1014 | | | storage resources to meet 10k video |
1015 | | | surveillance services. |
1016 | | | |
1017 | +---------------------------------------------------+
1018 | | Strategy | This includes models and policy |
1019 | | Intent | intents designed by Customers/ |
1020 | | | Tenants to be used by Customer and |
1021 | | | End-User Intents. |
1022 | | | Example: Request dynamic computing |
1023 | | | and storage resources of the service|
1024 | | | in special and daily times. |
1025 | | | |
1026 +-------------------------------------------------------------------+
1027 | | Cloud | Configuration of VMs, DB Servers, |
1028 | Cloud | Management | App Servers, Connectivity, |
1029 | | | Communication between VMs. |
1030 | Administrator | Intent | Example: Request connectivity |
1031 | | | between VMs A,B,and C in Network N1.|
1032 | +---------------------------------------------------+
1033 | | Cloud | Policy-driven self-configuration and|
1034 | | Resource | and recovery / optimization |
1035 | | Management | Example: Request automatic life |
1036 | | Intent |-cycle management of VM cloud |
1037 | | | resources. |
1038 | +---------------------------------------------------+
1039 | | Operational | Cloud Administrator requests |
1040 | | Task Intent | execution of any automated task |
1041 | | | other than Cloud Management |
1042 | | | Intents and Cloud Resource |
1043 | | | Management Intents. |
1044 | | | Example: Request upgrade operating |
1045 | | | system to version X on all VMs |
1046 | | | in Network N1. |
1047 | +---------------------------------------------------+
1048 | | Strategy | Cloud Administrator designs models, |
1049 | | Intent | policy intents and workflows to be |
1050 | | | used by other intents. Automate any |
1051 | | | tasks that Administrator often |
1052 | | | performs, in addition to lifecycle |
1053 | | | of Cloud Management Intents and |
1054 | | | Cloud Management Resource Intents. |
1055 | | | Example: In case of emergency, |
1056 | | | automatically migrate all cloud |
1057 | | | resources to DC2. |
1058 +---------------+--------------------------------------------------+
1059 | Underlay | Underlay | Service created and provided by |
1060 | Network | Network | the Underlay Network Administrator|
1061 | Administrator | Service | Example: Request underlay service |
1062 | | Intent | between DC1 and DC2 with |
1063 | | | bandwidth B . |
1064 | +-------------------------------------------------+
1065 | | Underlay | Underlay Network Administrator |
1066 | | Network | requests some DCN-wide underlay |
1067 | | Intent | network configuration or network |
1068 | | | resource configurations. |
1069 | | | Example: Establish and allocate |
1070 | | | DHCP address pool. |
1071 | +-------------------------------------------------+
1072 | | Operational | Underlay Network Administrator |
1073 | | Task Intent | requests execution of the any |
1074 | | | automated task other than Underlay|
1075 | | | Network Service and Resource |
1076 | | | Intent. |
1077 | | | Example: Request automatic rapid |
1078 | | | detection of device failures and |
1079 | | | pre-alarm correlation. |
1080 | +-------------------------------------------------+
1081 | | Strategy | Underlay Network Administrator |
1082 | | Intent | designs models, policy intents & |
1083 | | | workflows to be used by other |
1084 | | | intents. Automate any tasks that |
1085 | | | Administrator often performs |
1086 | | | Example: For all traffic flows |
1087 | | | that need NFV service chaining, |
1088 | | | restrict the maximum load of any |
1089 | | | VNF node/container below 50% and |
1090 | | | the maximum load of any network |
1091 | | | link below 70%. |
1092 +-----------------------------------------------------------------+
1093 | | Cloud | Cloud Management Intent API |
1094 | | Management | provided to the Application |
1095 | | Intent | Developers. |
1096 | | | Example: API to request |
1097 | | | configuration of VMs,or DB Servers|
1098 | Application +-------------------------------------------------+
1099 | Developer | Cloud | Cloud Resource Management Intent |
1100 | | Resource | API provided to the Application |
1101 | | Management | Developers. |
1102 | | Intent | Example: API to request automatic |
1103 | | | lifecycle management of cloud |
1104 | | | resources. |
1105 | +-------------------------------------------------+
1106 | | Underlay | Underlay Network Service API |
1107 | | Network | provided to the Application |
1108 | | Service | Developers. |
1109 | | Intent | Example: API to request real-time |
1110 | | | monitoring of device condition. |
1111 | +-------------------------------------------------+
1112 | | Underlay | Underlay Network Resource API |
1113 | | Network | provided to the Application |
1114 | | Intent | Developers. |
1115 | | | Example: API to request dynamic |
1116 | | | management of IPv4 address pool |
1117 | | | resources. |
1118 | | | |
1119 | +-------------------------------------------------+
1120 | | Operational | Operational Task Intent API |
1121 | | Task Intent | provided to the trusted |
1122 | | | Application Developer (internal |
1123 | | | DevOps). |
1124 | | | Example: API to request automatic |
1125 | | | rapid detection of device failures|
1126 | | | and pre-alarm correlation |
1127 | | | |
1128 | +-------------------------------------------------+
1129 | | Strategy | Application Developer designs |
1130 | | Intent | models, policy intents and |
1131 | | | building blocks to be used by |
1132 | | | other intents. This is for the |
1133 | | | trusted internal DCN DevOps. |
1134 | | | Example: API to request load |
1135 | | | balancing thresholds. |
1136 +---------------+-------------+-----------------------------------+
1138 5.4.2. Intent Categories
1140 The following are the proposed categories:
1141 Intent Scope: C1=Connectivity, C2=Security, C3=Application,
1142 C4=QoS C5=Storage C6=Compute
1143 DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical
1144 DCN Network (DCN Net) Scope: C1=Logical, C2=Physical
1145 Abstraction(ABS): C1=Technical(with technical feedback),
1146 C2=Non-technical (without technical feedback), see Section 4.2
1147 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient
1148 (Short Lived)
1150 The following is the Classification Table Example for DC Solutions.
1152 +---------+-------------+-----------------+-----+-----+-----+-----+
1153 |Intent | Intent | Intent | DCN | DCN | ABS | L-C |
1154 |User | Type | Scope | Res | Net | | |
1155 | | +-----------------+-----+-----+-----+-----+
1156 | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
1157 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1158 |Customer | Customer | | | | | | | | | | | | | | |
1159 |/Tenants | Intent | | | | | | | | | | | | | | |
1160 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1161 | | Strategy | | | | | | | | | | | | | | |
1162 | | Intent | | | | | | | | | | | | | | |
1163 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1164 | Cloud | Cloud | | | | | | | | | | | | | | |
1165 | Admin | Management | | | | | | | | | | | | | | |
1166 | | Intent | | | | | | | | | | | | | | |
1167 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1168 | | Cloud | | | | | | | | | | | | | | |
1169 | | Resource | | | | | | | | | | | | | | |
1170 | | Management | | | | | | | | | | | | | | |
1171 | | Intent | | | | | | | | | | | | | | |
1172 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1173 | | Operational | | | | | | | | | | | | | | |
1174 | | Task Intent | | | | | | | | | | | | | | |
1175 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1176 | | Strategy | | | | | | | | | | | | | | |
1177 | | Intent | | | | | | | | | | | | | | |
1178 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1179 |Underlay | Underlay | | | | | | | | | | | | | | |
1180 |Network | Network | | | | | | | | | | | | | | |
1181 |Admin | Service | | | | | | | | | | | | | | |
1182 | | Intent | | | | | | | | | | | | | | |
1183 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1184 | | Underlay | | | | | | | | | | | | | | |
1185 | | Network | | | | | | | | | | | | | | |
1186 | | Resource | | | | | | | | | | | | | | |
1187 | | Intent | | | | | | | | | | | | | | |
1188 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1189 | | Operational | | | | | | | | | | | | | | |
1190 | | Task Intent | | | | | | | | | | | | | | |
1191 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1192 | | Strategy | | | | | | | | | | | | | | |
1193 | | Intent | | | | | | | | | | | | | | |
1194 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1195 |App | Cloud | | | | | | | | | | | | | | |
1196 |Developer| Management | | | | | | | | | | | | | | |
1197 | | Intent | | | | | | | | | | | | | | |
1198 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1199 | | Cloud | | | | | | | | | | | | | | |
1200 | | Resource | | | | | | | | | | | | | | |
1201 | | Management | | | | | | | | | | | | | | |
1202 | | Intent | | | | | | | | | | | | | | |
1203 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1204 | | Underlay | | | | | | | | | | | | | | |
1205 | | Network | | | | | | | | | | | | | | |
1206 | | Service | | | | | | | | | | | | | | |
1207 | | Intent | | | | | | | | | | | | | | |
1208 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1209 | | Underlay | | | | | | | | | | | | | | |
1210 | | Network | | | | | | | | | | | | | | |
1211 | | Resource | | | | | | | | | | | | | | |
1212 | | Intent | | | | | | | | | | | | | | |
1213 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1214 | | Operational | | | | | | | | | | | | | | |
1215 | | Task Intent | | | | | | | | | | | | | | |
1216 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1217 | | Strategy | | | | | | | | | | | | | | |
1218 | | Intent | | | | | | | | | | | | | | |
1219 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1221 5.5. Intent Classification for Enterprise Solution
1223 5.5.1. Intent Users and Intent Types
1225 The following table describes the Intent Users in Enterprise
1226 Solutions and their Intent Types.
1228 +--------------+-------------+-------------------------------------+
1229 | Intent User | Intent Type | Intent Type Description |
1230 +--------------+---------------------------------------------------+
1231 | End-User | End-User | Enterprise End User Self-Service or |
1232 | | Intent | Applications, Enterprise may have |
1233 | | | multiple types of End-Users. |
1234 | | | Example: Request access to VPN |
1235 | | | service. |
1236 | | | Request video conference between |
1237 | | | user A and B. |
1238 | +---------------------------------------------------+
1239 | | Strategy | This includes models and policy |
1240 | | Intent | intents designed by End-Users to be |
1241 | | | used by End-User Intents and their |
1242 | | | Applications. |
1243 | | | Example: Create a video conference |
1244 | | | type for a weekly meeting. |
1245 +------------------------------------------------------------------+
1246 |Administrator | Network | Service provided by the |
1247 | (internal or | Service | Administrator to the End-Users |
1248 | MSP) | Intent | and their Applications. |
1249 | | | Example: For any user of application|
1250 | | | X, the arrival time of hologram |
1251 | | | objects of all the remote tele- |
1252 | | | presenters should be synchronised |
1253 | | | within 50ms to reach the destination|
1254 | | | viewer for each conversation session|
1255 | | | Create management VPN connectivity |
1256 | | | for type of service A. |
1257 +------------------------------------------------------------------+
1258 | | Network | Administrator requires network wide |
1259 | | Intent | configuration (e.g. underlay, |
1260 | | | campus) or resource configuration |
1261 | | | (switches, routers, policies). |
1262 | | | Example: Configure switches in |
1263 | | | campus network 1 to prioritise |
1264 | | | traffic of type A. |
1265 | | | Configure Youtube as business |
1266 | | | non-relevant. |
1267 | +---------------------------------------------------+
1268 | | Operational | Administrator requests execution of |
1269 | | Task Intent | any automated task other than |
1270 | | | Network Service Intents and Network |
1271 | | | Intents. |
1272 | | | Example: Request network security |
1273 | | | automated tasks such as Web |
1274 | | | filtering and DDOS cloud protection.|
1275 | +---------------------------------------------------+
1276 | | Strategy | Administrator designs models, policy|
1277 | | Intent | intents and workflows to be used by |
1278 | | | other intents. Automate any tasks |
1279 | | | that Administrator often performs. |
1280 | | | Example: In case of emergency, |
1281 | | | automatically shift all traffic of |
1282 | | | type A through network N. |
1283 | | | |
1284 +--------------+-------------+-------------------------------------+
1285 | Application | End-User | End-User Service / Application |
1286 | Developer | Intent | Intent API provided to the |
1287 | | | Application Developers. |
1288 | | | Example: API for request to open a |
1289 | | | VPN service. |
1290 | +---------------------------------------------------+
1291 | | Network | Network Service API Provided to |
1292 | | Service | Application Developers. |
1293 | | Intent | Example: API for request network |
1294 | | | bandwidth and latency for |
1295 | | | hosting video conference. |
1296 | +---------------------------------------------------+
1297 | | Network | Network API Provided to Application |
1298 | | Intent | Developers. |
1299 | | | Example: API for request of network |
1300 | | | devices configuration. |
1301 | +---------------------------------------------------+
1302 | | Operational | Operational Task Intent API provided|
1303 | | Task Intent | to the trusted Application Developer|
1304 | | | (internal DevOps). |
1305 | | | Example: API for requesting |
1306 | | | automatic monitoring and |
1307 | | | interception for network security |
1308 | +---------------------------------------------------+
1309 | | Strategy | Application Developer designs |
1310 | | Intent | models, policy intents and building |
1311 | | | blocks to be used by other intents. |
1312 | | | This is for the trusted internal |
1313 | | | DevOps. |
1314 | | | Example: API for strategy intent in |
1315 | | | case of emergencies. |
1316 | | | |
1317 +--------------+-------------+-------------------------------------+
1319 5.5.2. Intent Categories
1321 The following are the proposed categories:
1322 Intent Scope: C1=Connectivity, C2=Security, C3=Application,
1323 C4=QoS
1324 Enterpise Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN
1325 Abstraction(ABS): C1=Technical(with technical feedback),
1326 C2=Non-technical (without technical feedback), see Section 4.2
1327 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient
1328 (Short Lived)
1330 The following is the Intent Classification Table Example for
1331 Enterprise Solutions.
1333 +---------------+-------------+-----------+--------+-----+-----+
1334 | Intent User | Intent Type | Intent | Net | ABS | L-C |
1335 | | | Scope | | | |
1336 | | +-----------+--------+-----+-----+
1337 | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|
1338 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1339 | End-User | End-User | | | | | | | | | | | |
1340 | | Intent | | | | | | | | | | | |
1341 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1342 | | Strategy | | | | | | | | | | | |
1343 | | Intent | | | | | | | | | | | |
1344 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1345 | Enterprise | Network | | | | | | | | | | | |
1346 | Administrator | Intent | | | | | | | | | | | |
1347 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1348 | | Strategy | | | | | | | | | | | |
1349 | | Intent | | | | | | | | | | | |
1350 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1351 | Application | End-User | | | | | | | | | | | |
1352 | Developer | Intent | | | | | | | | | | | |
1353 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1354 | | Network | | | | | | | | | | | |
1355 | | Service | | | | | | | | | | | |
1356 | | Intent | | | | | | | | | | | |
1357 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1358 | | Network | | | | | | | | | | | |
1359 | | Intent | | | | | | | | | | | |
1360 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1361 | | Operational | | | | | | | | | | | |
1362 | | Task | | | | | | | | | | | |
1363 | | Intent | | | | | | | | | | | |
1364 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1365 | | Strategy | | | | | | | | | | | |
1366 | | Intent | | | | | | | | | | | |
1367 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1369 6. Involvement of intent in the application of AI to Network Manage
1370 ment
1372 In the application of AI to NM, an intent is expected to be, on the
1373 one hand, a formal definitions of a goal or policy instructed to the
1374 decision system and, on the other hand, a formal definition of the
1375 specific actions that some network controller must perform. Goal
1376 intents and policy intents have different meanings. The former will
1377 establish an objective for the automated management system to
1378 accomplish, such as "avoiding latency to be higher than 10 ms".
1379 Meanwhile, policy intents set the overall regulations and possible
1380 actions that the AI system can use to achieve those goals. Both goal
1381 and policy intents are expected to be provided by humans, although
1382 they must be in some very formal language that can be easily
1383 understood by computers. All those relations make the degree of
1384 formality an important dimension to classify intents so that users,
1385 which here are AI-based agents, can be able to choose the proper
1386 solution to consume them.
1388 AI technology has played an important role in the different stages
1389 of the intent network implementation.
1391 o Help identify and prevent security threats: Classification
1392 algorithms can attempt to identify malware or other undesirable
1393 web content or usage;
1395 o Intentional translation: use AI algorithm to assist the
1396 translation module, split translation into the requirements
1397 contained in the semantics of the intention; automatic delivery
1398 and execution strategy;Automate tasks and appropriate network
1399 changes based on the existing network infrastructure
1400 configuration according to the policy model;
1402 o Adaptive adjustment: perceive the quality of the user experience
1403 and perform predictive analysis to proactively optimize
1404 performance, such as excessive access time;
1406 To enforce the resulting actions determined by AI-based control
1407 modules, action intents will have a format that avoids
1408 misconceptions as much as possible. This means that they will be
1409 closer to machine language structures than natural (human) language
1410 structures. This can sacrificing some degree of human
1411 understandability, so it forms another dimension in the
1412 classification of intents. This dimension allows automated systems
1413 to discern which format of intent to use in relation to the
1414 possibility and degree of humans to be involved in their exchanges.
1416 Finally, as intents can use different words and languages to refer
1417 to the same concepts, all intents related to AI will be required to
1418 follow a specific ontology. This way, input intents will be easily
1419 semantically translated to formal structures. Output intents will
1420 also be composed by following the ontology, so receivers of those
1421 intents will be able to easily understand them.
1423 For instance, in the intent classification, the machine learning
1424 algorithm can be utilized to extract the intent feature values and
1425 classify the intent according to the intent feature distribution.
1426 For example, using artificial intelligence clustering algorithm, a
1427 large number of intents proposed by different users are used as
1428 training data to extract multiple feature dimensions, such as
1429 vocabulary information intended to be used, related feature
1430 parameters, context proposed by the intent, and the like.Cluster
1431 analysis is performed in the same form as the coordinate system, and
1432 multiple categories are classified according to the characteristics
1433 of the sample point distribution. For the input intent later, the
1434 category of the intent is judged based on the similarity with all
1435 categories.
1437 o For specific classification intents, such as safety or fault
1438 information, conditions can be preset in advance, and once a
1439 common error message occurs, it will automatically alarm.
1441 o For the network resource information, set the corresponding
1442 threshold information. When there is a certain number of link
1443 users or the network traffic is too large, the adjustment
1444 intention is started.
1446 o For users with higher priority, the resources can be configured
1447 preferentially.
1449 7. Security Considerations
1451 This document does not have any Security Considerations.
1453 8. IANA Considerations
1455 This document has no actions for IANA.
1457 9. Contributors
1459 The following people all contributed to creating this document,
1460 listed in alphabetical order:
1462 Ying Chen, China Unicom
1463 Richard Meade, Huawei
1464 John Strassner, Huawei
1465 Xueyuan Sun, China Telecom
1466 Weiping Xu, Huawei
1468 10. Acknowledgments
1470 This document has benefited from reviews, suggestions, comments and
1471 proposed text provided by the following members, listed in
1472 alphabetical order: Brian E Carpenter, Juergen Schoenwaelder,
1473 Laurent Ciavaglia, Xiaolin Song.
1475 11. References
1477 11.1. Normative References
1479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1480 Requirement Levels", BCP 14, RFC 2119, March 1997.
1482 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
1483 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
1484 Networking: Definitions and Design Goals", RFC 7575, June
1485 2015.
1487 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
1488 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based
1489 Management Framework for the Simplified Use of Policy
1490 Abstractions (SUPA)", March 2018.
1492 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
1493 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson,
1494 M., Perry, J., Waldbusser, S., "Terminology for Intent-
1495 driven Management", RFC 3198, November 2001.
1497 11.2. Informative References
1499 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
1500 Network Configuration Protocol (NETCONF)", RFC 6020,
1501 October 2010.
1503 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W.
1504 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic
1505 Optimization (ALTO) Protocol", September 2014.
1507 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017,
1508 .
1511 [ONF] ONF, "Intent Definition Principles", 2017,
1512 .
1516 [ONOS] ONOS, "ONOS Intent Framework", 2017,
1517 .
1520 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions",
1521 2017, .
1524 [ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun,
1525 "Autonomic IPv6 Edge Prefix Management in Large-scale
1526 Networks", draft-ietf-anima-prefix-management-07 (work in
1527 progress), December 2017.
1529 [TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of
1530 Autonomous Networks: Empowering Digital Transformation For
1531 the Telecoms Industry, inform.tmforum.org, 15 May, 2019.
1533 [CLEMM] Alexander Clemm and Laurent Ciavaglia and Lisandro
1534 Zambenedetti Granville and Jeff Tantsura, Intent-Based
1535 Networking - Concepts and Overview, 4 Nov, 2019
1537 Authors' Addresses
1539 Chen Li
1540 China Telecom
1541 No.118 Xizhimennei street, Xicheng District
1542 Beijing 100035
1543 P.R. China
1544 Email: lichen6@chinatelecom.cn
1545 Olga Havel
1546 Huawei Technologies
1547 Email: olga.havel@huawei.com
1549 Adriana Olariu
1550 Huawei Technologies
1551 Email: adriana.olariu@huawei.com
1553 Will(Shucheng) Liu
1554 Huawei Technologies
1555 P.R. China
1556 Email: liushucheng@huawei.com
1558 Pedro Martinez-Julia
1559 NICT
1560 Japan
1561 Email: pedro@nict.go.jp
1563 Jeferson Campos Nobre
1564 University of Vale do Rio dos Sinos
1565 Porto Alegre
1566 Brazil
1567 Email: jcnobre@inf.ufrgs.br
1569 Diego R. Lopez
1570 Telefonica I+D
1571 Don Ramon de la Cruz, 82
1572 Madrid 28006
1573 Spain
1574 Email: diego.r.lopez@telefonica.com