idnits 2.17.1
draft-irtf-nmrg-ibn-intent-classification-01.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 (November 2, 2020) is 1263 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC7575' is defined on line 1562, but no explicit
reference was found in the text
== Unused Reference: 'RFC8328' is defined on line 1567, but no explicit
reference was found in the text
== Unused Reference: 'RFC3198' is defined on line 1572, but no explicit
reference was found in the text
== Unused Reference: 'RFC6020' is defined on line 1579, but no explicit
reference was found in the text
== Unused Reference: 'RFC7285' is defined on line 1583, but no explicit
reference was found in the text
== Unused Reference: 'SUPA' is defined on line 1600, but no explicit
reference was found in the text
== Unused Reference: 'ANIMA-Prefix' is defined on line 1604, but no
explicit reference was found in the text
== Outdated reference: A later version (-03) exists of
draft-clemm-nmrg-dist-intent-02
Summary: 0 errors (**), 0 flaws (~~), 10 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 2021 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 November 2, 2020
15 Intent Classification
16 draft-irtf-nmrg-ibn-intent-classification-01
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 months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on May 2, 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 respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 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 life-cycle. Up to
62 now, there is no commonly agreed definition, interface or model of
63 intent.
65 This document discusses mostly the concept of network intents, but
66 other types of intents are also being considered. Specifically, it
67 highlights stakeholder perspectives of intent, methods to classify
68 and encode intent, the associated intent taxonomy, and defines
69 relevant intent terms where necessary. This document provides a
70 foundation for intent related research and facilitate solution
71 development.
73 Table of Contents
75 1. Introduction ................................................ 3
76 2. Key Words ................................................... 5
77 3. Acronyms .................................................... 5
78 4. Abstract Intent Requirements................................. 7
79 4.1. What is Intent?......................................... 7
80 4.2. Intent Solutions and Intent Users ....................... 8
81 4.3. Current Problems and Requirements ....................... 9
82 4.4. Intent Types that need to be supported ................. 10
83 5. Functional Characteristics and Behaviour .................... 12
84 5.1. Abstracting Intent Operation ........................... 12
85 5.2. Intent User Types ...................................... 13
86 5.3. Intent Scope ........................................... 14
87 5.4. Intent Network Scope ................................... 14
88 5.5. Intent Abstraction ..................................... 14
89 5.6. Intent Life-cycle ...................................... 15
90 5.7. Hierarchy .............................................. 15
91 6. Intent Classification ....................................... 16
92 6.1. Intent Classification Methodology ...................... 17
93 6.2. Intent Taxonomy ........................................ 20
94 6.3. Intent Classification for Carrier Solution ............. 22
95 6.3.1. Intent Users and Intent Types ..................... 22
96 6.3.2. Intent Categories ................................. 26
97 6.3.3. Intent Classification Example ..................... 26
98 6.4. Intent Classification for Data Center Solutions......... 30
99 6.4.1. Intent Users and Intent Types ..................... 30
100 6.4.2. Intent Categories ................................. 34
101 6.4.3. Intent Classification Example ..................... 34
102 6.5. Intent Classification for Enterprise Solution .......... 38
103 6.5.1. Intent Users and Intent Types ..................... 38
104 6.5.2. Intent Categories ................................. 40
105 7. Security Considerations ..................................... 42
106 8. IANA Considerations ......................................... 42
107 9. Contributors ................................................ 42
108 10. Acknowledgments ............................................ 42
109 11. References ................................................. 42
110 11.1. Normative References .................................. 42
111 11.2. Informative References ................................ 43
113 1. Introduction
115 The vision of intent-driven networks has attracted a lot of
116 attention, as it promises to simplify the management of networks by
117 human operators. This is done by simply specifying what should happen
118 on the network, without giving any instructions on how to do it. This
119 promise led many telecom companies to begin adopting this new vision,
120 and many Standards Development Organization (SDOs) to propose
121 different intent framework.
123 Several SDOs and open source projects, such as Internet Engineering
124 Task Force (IETF) (by the Autonomic Networking Integrated Model and
125 Approach Working Group [ANIMA]), Open Networking Foundation (ONF)
126 [ONF], Open Network Operating System (ONOS) [ONOS], have proposed
127 intents for defining a set of network operations to execute in a
128 declarative manner.
130 IETF [ANIMA] defines intent as a declarative policy, but still lacks
131 a more complete definition, a tentative format, and a life-cycle.
132 Within ONOS [ONOS], intent is represented as a list of Command-Line
133 Interface (CLI) commands that allows users to bypass low-level
134 details on the network, such as flows or host addresses. ONF through
135 its Boulder and Aspen projects focuses on Northbound Interface (NBI)
136 semantics and intent models.
138 The SDOs usually came up with their own way of specifying an intent,
139 and with their own understanding of what an intent is. Besides that,
140 each SDO defines a set of terms and level of abstraction, its
141 intended users, and the applications and usage scenarios.
143 However, most intent approaches proposed by SDOs share the same
144 following features:
146 o It must be declarative in nature, meaning that a user specifies the
147 goal on the network without specifying how to achieve that goal.
149 o It must be vendor agnostic, in the sense that it abstracts the
150 network capabilities, or the network infrastructure from the user,
151 and it can be ported across different platforms.
153 o It must provide an easy-to-use interface, which simplifies the
154 users' interaction with the intent system through the usage of
155 familiar terminology or concepts.
157 o It should be able to detect and resolve intent conflicts, which
158 include, for example, static (compile-time) conflicts and dynamic
159 (run-time) conflicts.
161 Currently, work is underway on unifying a common understanding of
162 intent concepts and terminology. Concerning NMRG, [CLEMM] is a
163 document to present a definition for intent as higher-level
164 declarative policy that operates at the level of network and services
165 it provides. In addition, this document captures the differences
166 between intent, policy and service.
168 However, even with proposed intent concepts and terminology, as well
169 as agreement on common intent characteristics, an intent may still be
170 viewed in different ways by different stakeholders for different use
171 cases and solutions. This document mostly addresses intents in the
172 context of network intents, however other types of intents are not
173 excluded, as presented in Section 4.4. and Section 6.2. .
175 The goal of this document is to clarify what an intent represents for
176 different stakeholders through a classification on various
177 dimensions, such as solutions, users, and intent types. This
178 classification can ensure a common understanding across all
179 participants and be used to identify the scope and priorities of
180 individual projects, Proof of Concepts (PoCs), research initiatives,
181 or open-source projects. This goal is achieved by proposing the
182 methodology and initial classification tables. This methodology can
183 be used to update the tables by adding or removing different
184 solutions, users or intent types in order to cater for future
185 scenarios, applications or domains.
187 The present document, together with [CLEMM], aims to become the
188 foundation for future intent-related topic discussions regarding the
189 NMRG.
191 2. Key Words
193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
195 document are to be interpreted as described in RFC 2119 [RFC2119].
197 3. Acronyms
199 AI: Artificial Intelligence
201 API: Application Programming Interface
203 CE: Customer Equipment
205 CFS: Customer Facing Service
206 CLI: Command Line Interface
208 DB: Data Base
210 DC: Data Center
212 ECA: Event-Condition-Action
214 GBP: Group-Based Policy
216 IETF: Internet Engineering Task Force
218 IP: Internet Protocol
220 O&M: Operations & Maintenance
222 ONF: Open Networking Foundation
224 ONOS: Open Network Operating System
226 PNF: Physical Network Function
228 QoS: Quality of Service
230 RFS: Resource Facing Service
232 SDO: Standards Development Organization
234 SD-WAN: Software-Defined Wide-Area Network
236 SLA: Service-Level Agreement
238 SUPA: Simplified Use of Policy Abstractions
240 VLAN: Virtual Local Area Network
242 VM: Virtual Machine
244 VPN: Virtual Private Network
246 4. Abstract Intent Requirements
248 In order to understand the different intent requirements that would
249 drive intent classification, we first need to understand what intent
250 means for different intent users.
252 4.1. What is Intent?
254 The term Intent has become very widely used in the industry for
255 different purposes, sometimes it is not even in agreement with SDO
256 shared principles mentioned in the Introduction.
258 Different stakeholders consider an intent to be an ECA policy, a GBP
259 policy, a business policy, a network service, a customer service, a
260 network configuration, application/application group policy, any
261 operator/administrator task, network troubleshooting/diagnostics/
262 test, a new app, a marketing term for existing
263 management/orchestration capabilities, etc. Their intent is sometimes
264 technical, non-technical, abstract or technology specific. For some
265 stakeholders, intent is a subset of these and for other stakeholders
266 intent is all of these. It has in some cases become a term to replace
267 a very generic 'service' or 'policy' terminology.
269 Concerning this, [CLEMM] draft brings clarification with relation to
270 what an intent is and how it differentiates from policies and
271 services. Future versions of this draft will be kept aligned with
272 [CLEMM].
274 While it is easier for those familiar with different standards to
275 understand what service, CFS, RFS, resource, policy continuum, ECA
276 policy, declarative policy, abstract policy or intent policy is, it
277 may be more difficult for the wider audience.
279 An intent is mistaken by many to be just a synonym for policy. While
280 it is easier for those familiar with different standards to
281 understand what service, CFS, RFS, resource, policy continuum, ECA
282 policy, declarative policy, abstract policy or intent policy is, it
283 may be more difficult for the wider audience. Furthermore, those
284 familiar with policies understand the difference between a business,
285 intent, declarative, imperative, and ECA policy.
287 Therefore, it is important to start a discussion in the industry
288 about what intent is for different solutions and intent users. It is
289 also imperative to try to propose some intent categories/
290 classifications that could be understood by a wider audience. This
291 would help us define intent interfaces, DSLs and models.
293 4.2. Intent Solutions and Intent Users
295 Different Solutions and Actors have different requirements,
296 expectations and priorities for intent-driven networking. They
297 require different intent types and have different use cases. Some
298 users are more technical and require intents that expose more
299 technical information. Other users do not understand networks and
300 require intents that shield them from different networking concepts
301 and technologies. The following are the solutions and intent users
302 that intent-driven networking needs to support:
304 +--------------------+------------------------------------+
305 | Solutions | Intent Users |
306 +--------------------+------------------------------------+
307 | Carrier Networks | Network Operator |
308 | | Service Designers |
309 | | Service Operators |
310 | | Customers/Subscribers |
311 +--------------------+------------------------------------+
312 | DC Networks | Cloud Administrator |
313 | | Underlay Network Administrator |
314 | | App Developers |
315 | | End-Users |
316 +--------------------+------------------------------------+
317 | Enterprise Networks| Enterprise Administrator |
318 | | App Developers |
319 | | End-Users |
320 +--------------------+------------------------------------+
322 These intent solutions and intent users represent a starting point
323 for the classification and are expendable through the methodology
324 presented in Section 6.1. .
326 o For carrier networks scenario, for example, if the end-users wants
327 to watch high-definition video, then the intent is to convert the
328 video image to 1080p rate for the users.
330 o For DC networks scenario, administrators have their own clear
331 network intent such as load balancing. For all traffic flows that
332 need NFV service chaining, restrict the maximum load of any VNF
333 node/container below 50% and the maximum load of any network link
334 below 70%.
336 o For Enterprise Networks scenario, enterprise administrators
337 express their intent from an external client (application service
338 provider). For example, when hosting a video conference, multiple
339 remote accesses are required. An example of the intent expressed
340 to the network operator is: For any user of this application, the
341 arrival time of hologram objects of all the remote tele-presenters
342 should be synchronised within 50ms to reach the destination viewer
343 for each conversation session.
345 4.3. Current Problems and Requirements
347 Network APIs and CLIs are too complex due to the fact that they
348 expose technologies and topologies. App developers and end-users do
349 not want to set IP Addresses, VLANs, subnets, ports, etc. Operators
350 and administrators would also benefit from the simpler interfaces,
351 like:
353 o Allow Customer Site A to be connected to Internet via Network B
355 o Allow User A to access all internal resources, except the Server B
357 o Allow User B to access Internet via Corporate Network A
359 o Move all Users from Corporate Network A to the Corporate Network B
361 o Request Gold VPN service between my sites A, B and C
363 o Provide CE Redundancy for all Customer Sites
365 o Add Access Rules to my Service
367 Networks are complex, with many different protocols and
368 encapsulations. Some basic questions are not easy to answer:
370 o Can User A talk to User B?
372 o Can Host A talk to Host B?
374 o Are there any loops in my network?
376 o Are Network A and Network B connected?
378 o Can User A listen to communications between Users B and C?
380 Operators and Administrators manually troubleshoot and fix their
381 networks and services. They instead want:
383 o a reliable network that is self-configured and self-assured based on
384 the intent
386 o to be notified about the problem before the user is aware
388 o automation of network/service recovery based on intent (self-healing,
389 self-optimization)
391 o to get suggestions about correction/optimization steps based on
392 experience (historical data and behaviour)
394 Therefore, Operators and Administrators want to:
396 o simplify and automate network operations
398 o simplify definitions of network services
400 o provide simple customer APIs for Value Added Services (operators)
402 o be informed if the network or service is not behaving as requested
404 o enable automatic optimization and correction for selected scenarios
406 o have systems that learn from historic information and behaviour
408 End-users cannot build their own services and policies without
409 becoming technical experts and they must perform manual maintenance
410 actions. Application developers and end-users/subscribers want to be
411 able to:
413 o build their own network services with their own policies via simple
414 interfaces, without becoming networking experts
416 o have their network services up and running based on intent and
417 automation only, without any manual actions or maintenance
419 4.4. Intent Types that need to be supported
421 The following intent types need to be supported, in order to address
422 the requirements from different solutions and intent users:
424 o Customer service intent
426 o for customer self-service with SLA or add a service
428 o for service operator orders
430 o Network and Underlay Network service intent
432 o for service operator orders
434 o for intent driven network configuration, verification,
435 correction and optimization
437 o for intent created and provided by the underlay network
438 administrator
440 o Network and Underlay Network intent
442 o For network configuration
444 o For automated lifecycle management of network configurations
446 o For network resources (switches, routers, routing, policies,
447 underlay)
449 o Cloud management intent
451 o For DC configuration, VMs, DB Servers, APP Servers
453 o For communication between VMs
455 o Cloud resource management intent
457 o For cloud resource life-cycle management (policy driven self-
458 configuration and auto-scaling and recovery/optimization)
460 o Strategy intent
462 o For security, QoS, application policies, traffic steering, etc.
464 o For configuring and monitoring policies, alarms generation for
465 non-compliance, auto-recovery
467 o For design models and policies for network and network service
468 design
470 o For design workflows, models and policies for operational task
471 intents
473 o Operational task intents
475 o For network migration
476 o For server replacements
478 o For device replacements
480 o For network software upgrades
482 o To automate any tasks that operators/administrator often
483 perform
485 o Intents that affect other intents
487 o It may be task-based intent that modifies many other intents.
489 o The task itself is short-lived, but the modification of other
490 intents has an impact on their life-cycle, so those changes
491 must continue to be continuously monitored and self-
492 corrected/self-optimized.
494 5. Functional Characteristics and Behaviour
496 Intent can be used to operate immediately on a target (much like
497 issuing a command), or whenever it is appropriate (e.g., in response
498 to an event). In either case, intent has a number of behaviours that
499 serve to further organize its purpose, as described by the following
500 subsections.
502 5.1. Abstracting Intent Operation
504 The modelling of Intents can be abstracted using the following
505 three-tuple:
507 {Context, Capabilities, Constraints}
509 o Context grounds the intent, and determines if it is relevant or
510 not for the current situation. Thus, context selects intents based
511 on applicability.
513 o Capabilities describe the functionality that the intent can
514 perform. Capabilities take different forms, depending on the
515 expressivity of the intent as well as the programming paradigm(s)
516 used.
518 o Constraints define any restrictions on the capabilities to be used
519 for that particular context.
521 Metadata can be attached via strategy templates to each of the
522 elements of the three-tuple, and may be used to describe how the
523 intent should be used and how it operates, as well as prescribe any
524 operational dependencies that must be taken into account.
526 5.2. Intent User Types
528 Intent user types, or intent actors as they are known in the area of
529 declarative policy, represent the users that define and issue the
530 intent request. Depending on the Intent Solutions, there are specific
531 intent actors. Examples of intent actors are customers, network
532 operators, service operators, enterprise administrators, cloud
533 administrators, and underlay network administrators, or application
534 developers.
536 o Customers and end-users do not necessarily know the functional and
537 operational details of the network that they are using.
538 Furthermore, they lack skills to understand such details; in fact,
539 such knowledge is typically not relevant to their job. In
540 addition, the network may not expose these details to its users.
541 This class of actor focuses on the applications that they run, and
542 uses services offered by the network. Hence, they want to specify
543 policies that provide consistent behaviour according to their
544 business needs. They do not have to worry about how the intents
545 are deployed onto the underlying network, and especially, whether
546 the intents need to be translated to different forms to enable
547 network elements to understand them.
549 o Application developers work in a set of abstractions defined by
550 their application and programming environment(s). For example,
551 many application developers think in terms of objects (e.g., a
552 VPN). While this makes sense to the application developer, most
553 network devices do not have a VPN object per se; rather, the VPN
554 is formed through a set of configuration statements for that
555 device in concert with configuration statements for the other
556 devices that together make up the VPN. Hence, the view of
557 application developers matches the services provided by the
558 network, but may not directly correspond to other views of other
559 actors.
561 o Management personnel, such as network operators, may have the
562 knowledge of the underlying network. However, they may not
563 understand the details of the applications and services of
564 Customers and End-Users.
566 5.3. Intent Scope
568 Intent are used to manage the behaviour of the networks they are
569 applied to and all intents are applied within a specific scope, such
570 as:
572 o Connectivity scope, if the intent creates or modifies a
573 connection.
574 o Security scope, if the intent specifies the security
575 characteristics of the network or users.
576 o Application scope, when the intent specifies the applications to
577 be affected by the intent request.
578 o QoS Scope, when the intent specifies the QoS characteristics of
579 the network.
581 These intent scopes are expendable through the methodology presented
582 in Section 6.1. .
584 5.4. Intent Network Scope
586 Regardless on the intent user type, their intent request is affecting
587 the network, or network components, which are representing the intent
588 targets.
590 Thus, intent network scope, or policy target as known in the area of
591 declarative policy, can represent VNFs or PNFs, Physical Network
592 Elements, Campus networks, SD-WAN networks, radio access networks,
593 cloud edge, cloud core, branch, etc.
595 5.5. Intent Abstraction
597 Intent can be classified by whether it is necessary to feedback
598 technical network information or non-technical information to the
599 intended proponent after the intent is executed. As well, intent
600 abstraction covers the level of technical details in the intent
601 itself.
603 o For ordinary users, they do not care how the intent is executed,
604 or the details of the network. As a result, they do not need to
605 know the configuration information of the underlying network. They
606 only focus on whether the intent execution result achieves the
607 goal, and the execution effect such as the quality of completion
608 and the length of execution. In this scenario, we refer to an
609 abstraction without technical feedback.
611 o For administrators, such as network administrators, they perform
612 intents, such as allocating network resources, selecting
613 transmission paths, handling network failures, etc. They require
614 multiple feedback indicators for network resource conditions,
615 congestion conditions, fault conditions, etc. after execution. In
616 this case, we refer to an abstraction with technical feedback.
618 As per intent definition provided in [CLEMM], lower-level intents are
619 not considered to qualify as intents. However, we kept this
620 classification to identify any PoCs/Demos/Use Cases that still either
621 require or implement lower level of abstraction for intents.
623 5.6. Intent Life-cycle
625 Intents can be classified into transient and persistent intents:
627 o If intent is transient, it has no life-cycle management. As soon
628 as the specified operation is successfully carried out, the intent
629 is finished, and can no longer affect the target object.
631 o If the intent is persistent, it has life-cycle management. Once
632 the intent is successfully activated and deployed, the system will
633 keep all relevant intents active until they are deactivated or
634 removed.
636 5.7. Hierarchy
638 In different phases of the autonomous driving network [TMF-auto], the
639 intents are different. A typical example of autonomous driving
640 network Level 0 to 5 are listed as below.
642 o Level 0 - Traditional manual network: O&M personnel manually
643 control the network and obtain network alarms and logs. - No
644 intent
646 o Level 1 - Partially automated network: Automated scripts are used
647 to automate service provisioning, network deployment, and
648 maintenance. Shallow perception of network status and decision
649 making suggestions of machine; - No intent
651 o Level 2 - Automated network: Automation of most service
652 provisioning, network deployment, and maintenance comprehensive
653 perception of network status and local machine decision making; -
654 simple intent on service provisioning
656 o Level 3 - Self-optimization network: Deep awareness of network
657 status and automatic network control, meeting users' network
658 intentions. - Intent based on network status cognition
660 o Level 4 - Partial autonomous network: In a limited environment,
661 people do not need to participate in decision-making and adjust
662 themselves. - Intent based on limited AI
664 o Level 5 - Autonomous network: In different network environments
665 and network conditions, the network can automatically adapt to and
666 adjust to meet people's intentions. - Intent based on AI
668 6. Intent Classification
670 This chapter proposes an intent classification approach that may help
671 to classify mainstream intent related demos/tools.
673 The three classifications in this draft have been proposed from
674 scratch, following the methodology presented, through three
675 iterations: one for carrier Intent Solution, one for DC Intent
676 Solution, and one for enterprise Intent Solution. For each Intent
677 solution, we identified the specific Intent Users and Intent Types.
678 Then, we further identified the Intent Scope, Network Scope,
679 Abstractions, and Life-cycle requirements.
681 These classifications and the generated tables can be easily
682 extended. For example, for the DC Intent Solution, a new category is
683 identified, i.e. Resource Scope, and the classification table has
684 been extended accordingly.
686 In the future, as new scenarios, applications, and domains are
687 emerging, new classifications and taxonomies can be identified,
688 following the proposed methodology.
690 The output of the intent classification is the intent taxonomy
691 introduced in the next sections.
693 Thus, this section first introduces the proposed intent
694 classification methodology, followed by consolidated intent taxonomy
695 for three intent solutions, and then by concrete examples of intent
696 classifications for three different intent solutions (e.g. Carrier
697 Network, Data Center, and Enterprise) that were derived using the
698 proposed methodology and then can be filled in for PoCs, demos,
699 research projects or future drafts.
701 6.1. Intent Classification Methodology
703 This section describes the methodology used to derive the initial
704 classification proposed in the draft. The proposed methodology can be
705 used to create new intent classifications from scratch, by analysing
706 the solution knowledge. As well, the methodology can be used to
707 update existing classification tables by adding or removing different
708 solutions, users or intent types in order to cater for future
709 scenarios, applications or domains.
711 The intent classification workflow starts from the Solution
712 Knowledge, which can provide information on requirements, use cases,
713 technologies used, network properties, actors that define and issue
714 the intent request, and requirements. The following, defines the
715 steps to classify an intent:
717 1. The information provided in the solution knowledge is provided as
718 input to identifying the intent solution (e.g. Carrier, Enterprise,
719 and Data Center). This intent solution is reviewed against the
720 existing classification and it can either be used or add/remove the
721 intent solution identified from the solution knowledge (R1-U1).
723 2. The next step is identifying the intent user types (e.g. customer,
724 network operators, service operators, etc.) and then review existing
725 classification and use it or add/remove the intent user type
726 identified from the solution knowledge (R2-U2).
728 3. The next phase is to identify the type of intent (e.g. Network
729 Intent, Customer Service Intent) and then review existing
730 classification and use/add/remove the intent type (R3-U3).
732 4. The forth step is identifying the intent scope (e.g. Connectivity,
733 Application) based on the Solution Knowledge and then review existing
734 classification and use/add/remove the identified intent scope (R4-
735 U4).
737 5. The next step is to identify the network scope (e.g. Campus, Radio
738 Access) and then then review existing classification and either use
739 it or add/remove the identified network scope (R5-U5).
741 6. The next phase is to identify the abstractions (e.g. technical,
742 non-technical) and then review existing classification and
743 use/add/remove the abstractions (R6-U6).
745 7. The seventh step is to identify the life-cycle requirements (e.g.
746 persistent, transient) and then review existing classification and
747 use/add/remove the life-cycle requirements (R7-U7).
749 8. The last step is to identify any new categories and use/add the
750 newly identified categories. New categories can be identified as new
751 domains or applications are emerging, or new areas of concern (e.g.
752 privacy, compliance) might arise, which are not listed in the
753 current methodology.
755 +------------------------------------------+
756 |Solution Knowledge (requirements, |
757 |use cases, technologies, network, actors, |
758 |intent requirements) |
759 +----------------+-------------------------+
760 |
761 | Input
762 v
763 +--------+--------+
764 |1.Identify Intent|
765 | Solution +------------+
766 | | |
767 +---------^-+-----+ |
768 R1 | | U1 |
769 | | |
770 +---------------+ U8 | | R2 +--v----------------+
771 |8.Identify New +---------+ | | +-----------> 2.Identify |
772 | Categories | R8 | | | | U2 | Intent |
773 | <-------- | | | | +---------+ User Types |
774 +--------^------+ | | | | | | +-------|-----------+
775 | | | | | | | |
776 | ++-+-v-v---+-v-+ |
777 +--------+------+ U7 | | R3 +------v------------+
778 |7.Identify +------> Intent +--------> 3.Identify |
779 | Life-cycle | R7 |Classification| U3 | Type |
780 | Requirements <------+ <--------+ of Intent |
781 +--------^------+ +^--^-+--^-+---+ +------|------------+
782 | || | | | | |
783 | || | | | | |
784 +--------+-----+ || | | | | R4 +-------v-----------+
785 |6.Identify | U6 || | | | +-----------> 4.Identify |
786 | Abstractions+---------| | | | U4 | Intent |
787 | <---------+ | | +-------------+ Scope |
788 +-------^------+ R6 | | +-------+-----------+
789 | | | |
790 | U5 | |R5 |
791 | +-------+-v--------+ |
792 | |5.Identify Network| |
793 +----------+ Scope <---------------+
794 +------------------+
796 6.2. Intent Taxonomy
798 The following taxonomy describes the various intent solutions, intent
799 user types, intent types, intent scopes, network scopes, abstractions
800 and life-cycle and represents the output of the intent classification
801 tables for each of the solutions addressed (i.e. Carrier Solution,
802 Data Center, and Enterprise).
804 +--------------------------------+
805 |Carrier Enterprise |
806 +-->|Data Center |
807 | +--------------------------------+
808 | +--------------------------------+
809 | |Customer |
810 +----------+ | |Network or Service Operator |
811 +>+Solutions +--+ |Application Developer |
812 | +----------+ +->|Enterprise Administrator |
813 | | |Cloud Administrator |
814 | +----------+ | |Underlay Network Administrator |
815 +>+Intent +---+ +--------------------------------+
816 | |User | +--------------------------------+
817 | |Types | |Customer Service Intent |
818 | +----------+ |Strategy Intent |
819 | +----------+ |Network Service Intent |
820 +>+Intent +----->|Underlay Network Service Intent |
821 +------+ | |Type | |Network Intent |
822 |Intent+-+ +----------+ |Underlay Network Intent |
823 +------+ | |Operational Task Intent |
824 | +----------+ |Cloud Management Intent |
825 +>+Intent +---+ |Cloud Resource Management Intent|
826 | |Scope | | +--------------------------------+
827 | +----------+ | +--------------------------------+
828 | +->|Connectivity Application |
829 | +----------+ |Security QoS |
830 +>+Network +---+ +--------------------------------+
831 | |Scope | | +--------------------------------+
832 | +----------+ | |Radio Access Branch |
833 | +->|Transport Access SD-WAN |
834 | +----------+ |Transport Aggr. VNF PNF |
835 +>+Abstrac +----+ |Transport Core Physical |
836 | |tion | | |Cloud Edge Logical |
837 | +----------+ | |Cloud Core Campus |
838 | +----------+ | +--------------------------------+
839 +>+Life | | +--------------------------------+
840 |cycle +--+ +>|Technical Non-Technical |
841 +----------+ | +--------------------------------+
842 | +--------------------------------+
843 +-->|Persistent Transient |
844 +--------------------------------+
846 6.3. Intent Classification for Carrier Solution
848 Users and Intent Types
850 The following table describes the Intent Users in Carrier Solutions
851 and Intent Types with their descriptions for different intent users.
853 +-------------+-------------+---------------------------------------+
854 | Intent User | Intent Type | Intent Type Description |
855 +-------------------------------------------------------------------+
856 | Customer/ |Customer |Customer Self-Service with SLA and |
857 | Subscriber |Service |Value Added Service |
858 | |Intent |Example: Always maintain high quality |
859 | | |of service and high bandwidth for gold |
860 | | |level users. |
861 | | |Operational statement: Measure the |
862 | | |network congestion status, give |
863 | | |different adaptive parameters to |
864 | | |stations of different priority, thus in|
865 | | |heavy load situation, makes the |
866 | | |bandwidth of the high-priority users |
867 | | |guaranteed. At the same time ensure the|
868 | | |overall utilization of system, improve |
869 | | |the overall throughput of the system. |
870 | +-----------------------------------------------------+
871 | |Strategy |Customer designs models and policy |
872 | |Intent |intents to be used by Customer Service |
873 | | |Intents. |
874 | | |Example: Request reliable service |
875 | | |during peak traffic periods for apps |
876 | | |of type video. |
877 +-------------------------------------------------------------------+
878 |Network |Network |Service provided by Network Service |
879 |Operator |Service |Operator to the Customer |
880 | |Intent |(e.g. the Service Operator) |
881 | | |Example: Request network service with |
882 | | |delay guarantee for access customer A. |
883 | +-------------+---------------------------------------+
884 | |Network |Network Operator requests network-wide |
885 | |Intent |(service underlay or other network-wide|
886 | | |configuration) or network resource |
887 | | |configurations (switches, routers, |
888 | | |routing, policies). Includes |
889 | | |Connectivity, Routing, QoS, Security, |
890 | | |Application Policies, Traffic Steering |
891 | | |Policies, Configuration policies, |
892 | | |Monitoring policies, alarm generation |
893 | | |for non-compliance, auto-recovery, etc.|
894 | | |Example: Request high priority queueing|
895 | | |for traffic of class A. |
896 | +-----------------------------------------------------+
897 | |Operational |Network Operator requests execution of |
898 | |Task |any automated task other than Network |
899 | |Intent |Service Intent and Network Intent |
900 | | |(e.g. Network Migration, Server |
901 | | |Replacements, Device Replacements, |
902 | | |Network Software Upgrades). |
903 | | |Example: Request migration of all |
904 | | |services in Network N to backup path P.|
905 | +-----------------------------------------------------+
906 | |Strategy |Network Operator designs models, policy|
907 | |Intent |intents and workflows to be used by |
908 | | |Network Service Intents, Network |
909 | | |Intents and Operational Task Intents. |
910 | | |Workflows can automate any tasks that |
911 | | |Network Operator often performed in |
912 | | |addition to Network Service Intents and|
913 | | |Network Intents |
914 | | |Example: Ensure the load on any link in|
915 | | |the network is not higher than 50%. |
916 +-------------+-------------+---------------------------------------+
917 +-------------+-------------+---------------------------------------+
918 | Service | Customer | Service Operator's Customer Orders, |
919 | Operator | Service | Customer Service / SLA |
920 | | Intent | Example: Provide service S with |
921 | | | guaranteed bandwidth for customer A. |
922 | +-----------------------------------------------------+
923 | | Network | Service Operator's Network Orders / |
924 | | Service | Network SLA |
925 | | | Example: Provide network guarantees in|
926 | | Intent | terms of security, low latency and |
927 | | | high bandwidth |
928 | +-----------------------------------------------------+
929 | | Operational | Service Operator requests execution of|
930 | | Task | any automated task other than |
931 | | Intent | Customer Service Intent and Network |
932 | | | Service Intent |
933 | | | Example: Update service operator |
934 | | | portal platforms and their software |
935 | | | regularly. Move services from Network |
936 | | | Operator 1 to Network Operator 2. |
937 | +-----------------------------------------------------+
938 | | Strategy | Service Operator designs models, |
939 | | Intent | policy intents and workflows to be |
940 | | | used by Customer Service Intents, |
941 | | | Network Service Intents and |
942 | | | Operational Task Intents. Workflows |
943 | | | can automate any tasks that Service |
944 | | | Operator often performed in addition |
945 | | | to Network Service Intents and Network|
946 | | | Intents. |
947 | | | Example: Request network service |
948 | | | guarantee to avoid network congestion |
949 | | | during special periods |
950 | | | such as Black Friday, and Christmas. |
951 +-------------+-------------+---------------------------------------+
952 | Application | Customer | Customer Service Intent API provided |
953 | Developer | Service | to the Application Developers |
954 | | Intent | Example: API to request network to |
955 | | | watch HD video 4K/8K. |
956 | +-----------------------------------------------------+
957 | | Network | Network Service Intent API provided to|
958 | | Service | the Application Developers |
959 | | Intent | Example: API to request network and |
960 | | | monitoring and traffic grooming. |
961 | +-----------------------------------------------------+
962 | | Network | Network Intent API provided to the |
963 | | Intent | Application Developers |
964 | | | Example: API to request network |
965 | | | resources configuration. |
966 | +-----------------------------------------------------+
967 | | Operational | Operational Task Intent API provided |
968 | | Task | to the Application Developers. This is|
969 | | Intent | for the trusted internal Operator / |
970 | | | Service Providers / Customer DevOps |
971 | | | Example: API to request server |
972 | | | migrations. |
973 | +-----------------------------------------------------+
974 | | Strategy | Application Developer designs models, |
975 | | Intent | policy and workflows to be used by |
976 | | | Customer Service Intents, Network |
977 | | | Service Intents and Operational |
978 | | | Task Intents. This is for the trusted |
979 | | | internal Operator/Service Provider/ |
980 | | | Customer DevOps |
981 | | | Example: API to design network load |
982 | | | balancing strategies during peak times|
983 +-------------+-------------+---------------------------------------+
985 Categories
987 The following are the proposed categories:
988 Intent Scope: C1=Connectivity, C2=Security, C3=Application,
989 C4=QoS
990 Network Scope:
991 o Network Domain: C1=Radio Access, C2=Transport Access,
992 C3=Transport Aggregation, C4=Transport Core, C5=Cloud Edge,
993 C6=Cloud Core)
994 o Network Function (NF) Scope: C1=VNFs, C2=PNFs
995 Abstraction(ABS): C1=Technical(with technical feedback), C2=Non-
996 technical (without technical feedback) see Section 5.2. .
997 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient
998 (Short Lived)
1000 Classification Example
1002 This section depicts an example on how the methodology described in
1003 Section 6.1. can be used in order to classify intents introduced in
1004 the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. The
1005 PoC considered two intents: slice intents and service chain intents.
1007 In this PoC [POC-IBN], a slice intent expresses a request for a
1008 network slice with two types of components: a set of top layer
1009 virtual functions, and a set of virtual switches and/or routers of
1010 L2/L3 VNFs. A service chain intent expressed a request for a service
1011 operated through a chain of service components running in L4-L7
1012 virtual functions.
1014 Following the intent classification methodology described step-by-
1015 step in Section 6.1. , we identify the following:
1017 1. The Intent Solution is for the Carrier.
1019 2. The Intent User Type is the Network Operator for the slice intent,
1020 and the Service Operator for the service chain intent
1022 3. The Type of Intent, is a Network Service Intent for the slice
1023 intent, and a Customer Service Intent for the service chain
1024 intent.
1026 4. The Intent Scopes are connectivity and application.
1028 5. The Network Scope is a logical one.
1030 6. The Abstractions are with technical feedback for the slice intent,
1031 and without technical feedback for the service chain intent
1033 7. The life-cycle is persistent.
1035 The following table shows how to represent this information in a
1036 tabular form. The 'X' in the table refers to the slice intent, and
1037 the 'Y' in the table refers to the service chain intent.
1039 +---------+---------+-----------+-----+-----------------+-----+-----+
1040 | Intent | Intent | Intent | NF | Network | ABS |L-C |
1041 | User | Type | Scope |Scope| Scope | | |
1042 | | +-----------+-----+-----------------+-----+-----+
1043 | | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|
1044 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1045 |Customer |Customer | | | | | | | | | | | | | | | | |
1046 |/ Sub- |Service | | | | | | | | | | | | | | | | |
1047 | scriber |Intent | | | | | | | | | | | | | | | | |
1048 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1049 | |Strategy | | | | | | | | | | | | | | | | |
1050 | |Intent | | | | | | | | | | | | | | | | |
1051 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1052 |Network |Network |X | |X | |X | | | | | |X |X |X | |X | |
1053 |Operator |Service | | | | | | | | | | | | | | | | |
1054 | |Intent | | | | | | | | | | | | | | | | |
1055 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1056 | |Network | | | | | | | | | | | | | | | | |
1057 | |Intent | | | | | | | | | | | | | | | | |
1058 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1059 | |Operatio-| | | | | | | | | | | | | | | | |
1060 | | nal Task| | | | | | | | | | | | | | | | |
1061 | |Intent | | | | | | | | | | | | | | | | |
1062 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1063 | |Strategy | | | | | | | | | | | | | | | | |
1064 | |Intent | | | | | | | | | | | | | | | | |
1065 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1066 |Service |Customer |Y | |Y | |Y | | | | | | |Y |Y |Y |Y | |
1067 |Operator |Service | | | | | | | | | | | | | | | | |
1068 | |Intent | | | | | | | | | | | | | | | | |
1069 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1070 | |Network | | | | | | | | | | | | | | | | |
1071 | |Service | | | | | | | | | | | | | | | | |
1072 | |Intent | | | | | | | | | | | | | | | | |
1073 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1074 | |Op Task | | | | | | | | | | | | | | | | |
1075 | |Intent | | | | | | | | | | | | | | | | |
1076 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1077 | |Strategy | | | | | | | | | | | | | | | | |
1078 | |Intent | | | | | | | | | | | | | | | | |
1079 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1080 |App |Customer | | | | | | | | | | | | | | | | |
1081 |Developer|Intent | | | | | | | | | | | | | | | | |
1082 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1083 | |Network | | | | | | | | | | | | | | | | |
1084 | |Service | | | | | | | | | | | | | | | | |
1085 | |Intent | | | | | | | | | | | | | | | | |
1086 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1087 | |Network | | | | | | | | | | | | | | | | |
1088 | |Intent | | | | | | | | | | | | | | | | |
1089 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1090 | |Op Task | | | | | | | | | | | | | | | | |
1091 | |Intent | | | | | | | | | | | | | | | | |
1092 | +---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1093 | |Strategy | | | | | | | | | | | | | | | | |
1094 | |Intent | | | | | | | | | | | | | | | | |
1095 +---------+---------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1096 6.4. Intent Classification for Data Center Solutions
1098 Users and Intent Types
1100 The following table describes the Intent Users in DCN Solutions and
1101 Intent Types with their descriptions for different intent users.
1103 +---------------+-------------+-------------------------------------+
1104 | Intent User | Intent Type | Intent Type Description |
1105 +-------------------------------------------------------------------+
1106 | Customer / | Customer | Customer Self-Service via Tenant |
1107 | Tenants | Service | Portal, Customers may have multiple |
1108 | | Intent | type of end-users. |
1109 | | | Example: Request GPU computing and |
1110 | | | storage resources to meet 10k video |
1111 | | | surveillance services. |
1112 | +---------------------------------------------------+
1113 | | Strategy | This includes models and policy |
1114 | | Intent | intents designed by Customers/ |
1115 | | | Tenants to be used by Customer and |
1116 | | | End-User Intents. |
1117 | | | Example: Request dynamic computing |
1118 | | | and storage resources of the service|
1119 | | | in special and daily times. |
1120 | | | |
1121 +-------------------------------------------------------------------+
1122 | | Cloud | Configuration of VMs, DB Servers, |
1123 | Cloud | Management | App Servers, Connectivity, |
1124 | Administrator | Intent | Communication between VMs. |
1125 | | | Example: Request connectivity |
1126 | | | between VMs A,B,and C in Network N1.|
1127 | +---------------------------------------------------+
1128 | | Cloud | Policy-driven self-configuration and|
1129 | | Resource | and recovery / optimization |
1130 | | Management | Example: Request automatic life |
1131 | | Intent |-cycle management of VM cloud |
1132 | | | resources. |
1133 | +---------------------------------------------------+
1134 | | Operational | Cloud Administrator requests |
1135 | | Task Intent | execution of any automated task |
1136 | | | other than Cloud Management |
1137 | | | Intents and Cloud Resource |
1138 | | | Management Intents. |
1139 | | | Example: Request upgrade operating |
1140 | | | system to version X on all VMs |
1141 | | | in Network N1. |
1142 | | |Operational statement: an intent to |
1143 | | |update a system might reconfigure the|
1144 | | |system topology (connect to a service|
1145 | | |and to peers), exchange data (update |
1146 | | |the content), and uphold a certain |
1147 | | |QoE level (allocate sufficient |
1148 | | |network resources). The network,thus,|
1149 | | |carries out the necessary |
1150 | | |configuration to best serve such an |
1151 | | |intent; e.g. setting up direct |
1152 | | |connections between terminals, and |
1153 | | |allocating fair shares of router |
1154 | | |queues considering other network |
1155 | | |services.
1156 | +---------------------------------------------------+
1157 | | Strategy | Cloud Administrator designs models, |
1158 | | Intent | policy intents and workflows to be |
1159 | | | used by other intents. Automate any |
1160 | | | tasks that Administrator often |
1161 | | | performs, in addition to life-cycle |
1162 | | | of Cloud Management Intents and |
1163 | | | Cloud Management Resource Intents. |
1164 | | | Example: In case of emergency, |
1165 | | | automatically migrate all cloud |
1166 | | | resources to DC2. |
1167 +---------------+---------------------------------------------------+
1168 | Underlay | Underlay | Service created and provided by |
1169 | Network | Network | the Underlay Network Administrator. |
1170 | Administrator | Service | Example: Request underlay service |
1171 | | Intent | between DC1 and DC2 with |
1172 | | | bandwidth B. |
1173 | +---------------------------------------------------+
1174 | | Underlay | Underlay Network Administrator |
1175 | | Network | requests some DCN-wide underlay |
1176 | | Intent | network configuration or network |
1177 | | | resource configurations. |
1178 | | | Example: Establish and allocate |
1179 | | | DHCP address pool. |
1180 | +---------------------------------------------------+
1181 | | Operational | Underlay Network Administrator |
1182 | | Task Intent | requests execution of the any |
1183 | | | automated task other than Underlay |
1184 | | | Network Service and Resource |
1185 | | | Intent. |
1186 | | | Example: Request automatic rapid |
1187 | | | detection of device failures and |
1188 | | | pre-alarm correlation. |
1189 | +---------------------------------------------------+
1190 | | Strategy | Underlay Network Administrator |
1191 | | Intent | designs models, policy intents & |
1192 | | | workflows to be used by other |
1193 | | | intents. Automate any tasks that |
1194 | | | Administrator often performs |
1195 | | | Example: For all traffic flows |
1196 | | | that need NFV service chaining, |
1197 | | | restrict the maximum load of any |
1198 | | | VNF node/container below 50% and |
1199 | | | the maximum load of any network |
1200 | | | link below 70%. |
1201 +-------------------------------------------------------------------+
1202 | | Cloud | Cloud Management Intent API |
1203 | | Management | provided to the Application |
1204 | | Intent | Developers. |
1205 | | | Example: API to request |
1206 | | | configuration of VMs,or DB Servers |
1207 | Application +---------------------------------------------------+
1208 | Developer | Cloud | Cloud Resource Management Intent |
1209 | | Resource | API provided to the Application |
1210 | | Management | Developers. |
1211 | | Intent | Example: API to request automatic |
1212 | | | life-cycle management of cloud |
1213 | | | resources. |
1214 | +---------------------------------------------------+
1215 | | Underlay | Underlay Network Service API |
1216 | | Network | provided to the Application |
1217 | | Service | Developers. |
1218 | | Intent | Example: API to request real-time |
1219 | | | monitoring of device condition. |
1220 | +---------------------------------------------------+
1221 | | Underlay | Underlay Network Resource API |
1222 | | Network | provided to the Application |
1223 | | Intent | Developers. |
1224 | | | Example: API to request dynamic |
1225 | | | management of IPv4 address pool |
1226 | | | resources. |
1227 | | | |
1228 | +---------------------------------------------------+
1229 | | Operational | Operational Task Intent API |
1230 | | Task Intent | provided to the trusted |
1231 | | | Application Developer (internal |
1232 | | | DevOps). |
1233 | | | Example: API to request automatic |
1234 | | | rapid detection of device failures |
1235 | | | and pre-alarm correlation |
1236 | | | |
1237 | +---------------------------------------------------+
1238 | | Strategy | Application Developer designs |
1239 | | Intent | models, policy intents and |
1240 | | | building blocks to be used by |
1241 | | | other intents. This is for the |
1242 | | | trusted internal DCN DevOps. |
1243 | | | Example: API to request load |
1244 | | | balancing thresholds. |
1245 +---------------+-------------+-------------------------------------+
1247 Categories
1249 The following are the proposed categories:
1250 Intent Scope: C1=Connectivity, C2=Security, C3=Application,
1251 C4=QoS C5=Storage C6=Compute
1252 Network Scope
1253 o Network Domain: DC Network
1254 o DCN Network (DCN Net) Scope: C1=Logical, C2=Physical
1255 o DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical
1256 Abstraction(ABS): C1=Technical(with technical feedback), C2=Non-
1257 technical (without technical feedback), see Section 5.2.
1258 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient
1259 (Short Lived)
1261 Classification Example
1263 This section depicts an example on how the methodology described in
1264 Section 6.1. can be used in order to classify intents introduced in
1265 the 'A Multi-Level Approach to IBN' PoC demonstration [POC-IBN]. The
1266 PoC considered two intents: slice intents and service chain intents.
1268 In this PoC [POC-IBN], a slice intent expresses a request for a
1269 network slice with two types of components: a set of top layer
1270 virtual functions, and a set of virtual switches and/or routers of
1271 L2/L3 VNFs. A service chain intent expressed a request for a service
1272 operated through a chain of service components running in L4-L7
1273 virtual functions.
1275 Following the intent classification methodology described step-by-
1276 step in Section 6.1. , we identify the following:
1278 1. The Intent Solution is for the Data Center.
1280 2. The Intent User Type is the Cloud Administrator for the slice
1281 intent and service chain intent.
1283 3. The Type of Intent, is a Cloud Management intent, for the slice
1284 and service chain intent.
1286 4. The Intent Scopes are connectivity and application.
1288 5. The Network Scope is a logical, and the resource scope is virtual.
1290 6. The Abstractions are with technical feedback for the slice intent,
1291 and without technical feedback for the service chain intent
1293 7. The life-cycle is persistent.
1295 The following table shows how to represent this information in a
1296 tabular form, where the 'X' in the table refers to the slice and
1297 service chain intent.
1299 +---------+-------------+-----------------+-----+-----+-----+-----+
1300 |Intent | Intent | Intent | DCN | DCN | ABS | L-C |
1301 |User | Type | Scope | Res | Net | | |
1302 | | +-----------------+-----+-----+-----+-----+
1303 | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
1304 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1305 |Customer | Customer | | | | | | | | | | | | | | |
1306 |/Tenants | Intent | | | | | | | | | | | | | | |
1307 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1308 | | Strategy | | | | | | | | | | | | | | |
1309 | | Intent | | | | | | | | | | | | | | |
1310 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1311 | Cloud | Cloud | | | | | | | | | | | | | | |
1312 | Admin | Management |X | |X | | | |X | |X | |X |X |X | |
1313 | | Intent | | | | | | | | | | | | | | |
1314 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1315 | | Cloud | | | | | | | | | | | | | | |
1316 | | Resource | | | | | | | | | | | | | | |
1317 | | Management | | | | | | | | | | | | | | |
1318 | | Intent | | | | | | | | | | | | | | |
1319 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1320 | | Operational | | | | | | | | | | | | | | |
1321 | | Task Intent | | | | | | | | | | | | | | |
1322 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1323 | | Strategy | | | | | | | | | | | | | | |
1324 | | Intent | | | | | | | | | | | | | | |
1325 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1326 |Underlay | Underlay | | | | | | | | | | | | | | |
1327 |Network | Network | | | | | | | | | | | | | | |
1328 |Admin | Service | | | | | | | | | | | | | | |
1329 | | Intent | | | | | | | | | | | | | | |
1330 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1331 | | Underlay | | | | | | | | | | | | | | |
1332 | | Network | | | | | | | | | | | | | | |
1333 | | Resource | | | | | | | | | | | | | | |
1334 | | Intent | | | | | | | | | | | | | | |
1335 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1336 | | Operational | | | | | | | | | | | | | | |
1337 | | Task Intent | | | | | | | | | | | | | | |
1338 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1339 | | Strategy | | | | | | | | | | | | | | |
1340 | | Intent | | | | | | | | | | | | | | |
1341 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1342 |App | Cloud | | | | | | | | | | | | | | |
1343 |Developer| Management | | | | | | | | | | | | | | |
1344 | | Intent | | | | | | | | | | | | | | |
1345 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1346 | | Cloud | | | | | | | | | | | | | | |
1347 | | Resource | | | | | | | | | | | | | | |
1348 | | Management | | | | | | | | | | | | | | |
1349 | | Intent | | | | | | | | | | | | | | |
1350 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1351 | | Underlay | | | | | | | | | | | | | | |
1352 | | Network | | | | | | | | | | | | | | |
1353 | | Service | | | | | | | | | | | | | | |
1354 | | Intent | | | | | | | | | | | | | | |
1355 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1356 | | Underlay | | | | | | | | | | | | | | |
1357 | | Network | | | | | | | | | | | | | | |
1358 | | Resource | | | | | | | | | | | | | | |
1359 | | Intent | | | | | | | | | | | | | | |
1360 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1361 | | Operational | | | | | | | | | | | | | | |
1362 | | Task Intent | | | | | | | | | | | | | | |
1363 | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1364 | | Strategy | | | | | | | | | | | | | | |
1365 | | Intent | | | | | | | | | | | | | | |
1366 +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1368 6.5. Intent Classification for Enterprise Solution
1370 Users and Intent Types
1372 The following table describes the Intent Users in Enterprise
1373 Solutions and their Intent Types.
1375 +--------------+-------------+-------------------------------------+
1376 | Intent User | Intent Type | Intent Type Description |
1377 +--------------+---------------------------------------------------+
1378 | End-User | Customer | Enterprise End-User Self-Service or |
1379 | | Service | Applications, Enterprise may have |
1380 | | Intent | multiple types of End-Users. |
1381 | | | Example: Request access to VPN |
1382 | | | service. |
1383 | | | Request video conference between |
1384 | | | user A and B. |
1385 | +---------------------------------------------------+
1386 | | Strategy | This includes models and policy |
1387 | | Intent | intents designed by End-Users to be |
1388 | | | used by End-User Intents and their |
1389 | | | Applications. |
1390 | | | Example: Create a video conference |
1391 | | | type for a weekly meeting. |
1392 +------------------------------------------------------------------+
1393 |Administrator | Network | Service provided by the |
1394 | (internal or | Service | Administrator to the End-Users |
1395 | MSP) | Intent | and their Applications. |
1396 | | | Example: For any user of application|
1397 | | | X, the arrival time of hologram |
1398 | | | objects of all the remote tele- |
1399 | | | presenters should be synchronised |
1400 | | | within 50ms to reach the destination|
1401 | | | viewer for each conversation session|
1402 | | | Create management VPN connectivity |
1403 | | | for type of service A. |
1404 | | | Operational statement: The job of |
1405 | | | the network layer is to ensure that |
1406 | | | the delay is between 50-70ms through|
1407 | | | the routing algorithm. At the same |
1408 | | | time,the node resources need to meet|
1409 | | | the bandwidth requirements of 4K |
1410 | | | video conferences. |
1411 +------------------------------------------------------------------+
1412 | | Network | Administrator requires network wide |
1413 | | Intent | configuration (e.g. underlay, |
1414 | | | campus) or resource configuration |
1415 | | | (switches, routers, policies). |
1416 | | | Example: Configure switches in |
1417 | | | campus network 1 to prioritise |
1418 | | | traffic of type A. |
1419 | | | Configure Youtube as business |
1420 | | | non-relevant. |
1421 | +---------------------------------------------------+
1422 | | Operational | Administrator requests execution of |
1423 | | Task Intent | any automated task other than |
1424 | | | Network Service Intents and Network |
1425 | | | Intents. |
1426 | | | Example: Request network security |
1427 | | | automated tasks such as Web |
1428 | | | filtering and DDOS cloud protection.|
1429 | +---------------------------------------------------+
1430 | | Strategy | Administrator designs models, policy|
1431 | | Intent | intents and workflows to be used by |
1432 | | | other intents. Automate any tasks |
1433 | | | that Administrator often performs. |
1434 | | | Example: In case of emergency, |
1435 | | | automatically shift all traffic of |
1436 | | | type A through network N. |
1437 | | | |
1438 +--------------+-------------+-------------------------------------+
1439 | Application | End-User | End-User Service / Application |
1440 | Developer | Intent | Intent API provided to the |
1441 | | | Application Developers. |
1442 | | | Example: API for request to open a |
1443 | | | VPN service. |
1444 | +---------------------------------------------------+
1445 | | Network | Network Service API Provided to |
1446 | | Service | Application Developers. |
1447 | | Intent | Example: API for request network |
1448 | | | bandwidth and latency for |
1449 | | | hosting video conference. |
1450 | +---------------------------------------------------+
1451 | | Network | Network API Provided to Application |
1452 | | Intent | Developers. |
1453 | | | Example: API for request of network |
1454 | | | devices configuration. |
1455 | +---------------------------------------------------+
1456 | | Operational | Operational Task Intent API provided|
1457 | | Task Intent | to the trusted Application Developer|
1458 | | | (internal DevOps). |
1459 | | | Example: API for requesting |
1460 | | | automatic monitoring and |
1461 | | | interception for network security |
1462 | +---------------------------------------------------+
1463 | | Strategy | Application Developer designs |
1464 | | Intent | models, policy intents and building |
1465 | | | blocks to be used by other intents. |
1466 | | | This is for the trusted internal |
1467 | | | DevOps. |
1468 | | | Example: API for strategy intent in |
1469 | | | case of emergencies. |
1470 | | | |
1471 +--------------+-------------+-------------------------------------+
1473 Categories
1475 The following are the proposed categories:
1476 Intent Scope: C1=Connectivity, C2=Security, C3=Application,
1477 C4=QoS
1478 Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN
1479 Abstraction(ABS): C1=Technical(with technical feedback), C2=Non-
1480 technical (without technical feedback), see Section 5.2.
1481 Life-cycle (L-C): C1=Persistent (Full life-cycle), C2=Transient
1482 (Short Lived)
1484 The following is the Intent Classification Table Example for
1485 Enterprise Solutions.
1487 +---------------+-------------+-----------+--------+-----+-----+
1488 | Intent User | Intent Type | Intent | Net | ABS | L-C |
1489 | | | Scope | | | |
1490 | | +-----------+--------+-----+-----+
1491 | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|
1492 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1493 | End-User | End-User | | | | | | | | | | | |
1494 | | Intent | | | | | | | | | | | |
1495 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1496 | | Strategy | | | | | | | | | | | |
1497 | | Intent | | | | | | | | | | | |
1498 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1499 | Enterprise | Network | | | | | | | | | | | |
1500 | Administrator | Intent | | | | | | | | | | | |
1501 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1502 | | Strategy | | | | | | | | | | | |
1503 | | Intent | | | | | | | | | | | |
1504 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1505 | Application | End-User | | | | | | | | | | | |
1506 | Developer | Intent | | | | | | | | | | | |
1507 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1508 | | Network | | | | | | | | | | | |
1509 | | Service | | | | | | | | | | | |
1510 | | Intent | | | | | | | | | | | |
1511 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1512 | | Network | | | | | | | | | | | |
1513 | | Intent | | | | | | | | | | | |
1514 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1515 | | Operational | | | | | | | | | | | |
1516 | | Task | | | | | | | | | | | |
1517 | | Intent | | | | | | | | | | | |
1518 | +-------------+--+--+--+--+--+--+--+--+--+--+--+
1519 | | Strategy | | | | | | | | | | | |
1520 | | Intent | | | | | | | | | | | |
1521 +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
1523 7. Security Considerations
1525 This document does not have any Security Considerations.
1527 8. IANA Considerations
1529 This document has no actions for IANA.
1531 9. Contributors
1533 The following people all contributed to creating this document,
1534 listed in alphabetical order:
1536 Ying Chen, China Unicom
1537 Richard Meade, Huawei
1538 John Strassner, Huawei
1539 Xueyuan Sun, China Telecom
1540 Weiping Xu, Huawei
1542 10. Acknowledgments
1544 This document has benefited from reviews, suggestions, comments and
1545 proposed text provided by the following members, listed in
1546 alphabetical order: Brian E Carpenter, Juergen Schoenwaelder, Laurent
1547 Ciavaglia, Xiaolin Song, Alexander Clemm, Daniel King, Mehdi Bezahaf,
1548 Yehia Elkhatib, Pedro Andres Aranda Gutierrez.
1550 We thank to Walter Cerroni, Barbara Martini, Molka Gharbaoui for
1551 contributing with their 'A multi-level approach to IBN ' PoC
1552 demonstration a first attempt to adopt the intent classification
1553 methodology.
1555 11. References
1557 11.1. Normative References
1559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1560 Requirement Levels", BCP 14, RFC 2119, March 1997.
1562 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
1563 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
1564 Networking: Definitions and Design Goals", RFC 7575, June
1565 2015.
1567 [RFC8328] Liu, W., Xie, C., Strassner, J., Karagiannis, G., Klyus,
1568 M., Bi, J., Cheng, Y., and D. Zhang, "Policy-Based
1569 Management Framework for the Simplified Use of Policy
1570 Abstractions (SUPA)", March 2018.
1572 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
1573 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson,
1574 M., Perry, J., Waldbusser, S., "Terminology for Intent-
1575 driven Management", RFC 3198, November 2001.
1577 11.2. Informative References
1579 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
1580 Network Configuration Protocol (NETCONF)", RFC 6020,
1581 October 2010.
1583 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W.
1584 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic
1585 Optimization (ALTO) Protocol", September 2014.
1587 [ANIMA] Du, Z., "ANIMA Intent Policy and Format", 2017,
1588 .
1591 [ONF] ONF, "Intent Definition Principles", 2017,
1592 .
1596 [ONOS] ONOS, "ONOS Intent Framework", 2017,
1597 .
1600 [SUPA] Strassner, J., "Simplified Use of Policy Abstractions",
1601 2017, .
1604 [ANIMA-Prefix] Jiang, S., Du, Z., Carpenter, B., and Q. Sun,
1605 "Autonomic IPv6 Edge Prefix Management in Large-scale
1606 Networks", draft-ietf-anima-prefix-management-07 (work in
1607 progress), December 2017.
1609 [TMF-auto] Aaron Richard Earl Boasman-Patel,et, A whitepaper of
1610 Autonomous Networks: Empowering Digital Transformation For
1611 the Telecoms Industry, inform.tmforum.org, 15 May, 2019.
1613 [CLEMM] A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, "Intent-
1614 Based Networking - Concepts and Overview", Work in
1615 Progress, draft-clemm-nmrg-dist-intent-03, June 2020,
1616 https://tools.ietf.org/html/draft-irtf-nmrg-ibn-concepts-
1617 definitions-02
1619 [POC-IBN] Walter Cerroni, Molka Gharbaoui, Barbara Martini, Davide
1620 Borsatti, "A multi-level approach to IBN", July 2020,
1621 https://www.ietf.org/proceedings/108/slides/slides-108-
1622 nmrg-ietf-108-hackathon-report-a-multi-level-approach-to-
1623 ibn-02
1625 Authors' Addresses
1627 Chen Li
1628 China Telecom
1629 No.118 Xizhimennei street, Xicheng District
1630 Beijing 100035
1631 P.R. China
1632 Email: lichen.bri@chinatelecom.cn
1634 Olga Havel
1635 Huawei Technologies
1636 Ireland
1637 Email: olga.havel@huawei.com
1639 Adriana Olariu
1640 Huawei Technologies
1641 Ireland
1642 Email: adriana.olariu@huawei.com
1644 Will(Shucheng) Liu
1645 Huawei Technologies
1646 P.R. China
1647 Email: liushucheng@huawei.com
1649 Pedro Martinez-Julia
1650 NICT
1651 Japan
1652 Email: pedro@nict.go.jp
1654 Jeferson Campos Nobre
1655 Federal University of Rio Grande do Sul
1656 Porto Alegre
1657 Brazil
1658 Email: jcnobre@inf.ufrgs.br
1660 Diego R. Lopez
1661 Telefonica I+D
1662 Don Ramon de la Cruz, 82
1663 Madrid 28006
1664 Spain
1665 Email: diego.r.lopez@telefonica.com