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