diff options
Diffstat (limited to 'doc/rfc/rfc9316.txt')
| -rw-r--r-- | doc/rfc/rfc9316.txt | 1941 |
1 files changed, 1941 insertions, 0 deletions
diff --git a/doc/rfc/rfc9316.txt b/doc/rfc/rfc9316.txt new file mode 100644 index 0000000..3d4e463 --- /dev/null +++ b/doc/rfc/rfc9316.txt @@ -0,0 +1,1941 @@ + + + + +Internet Research Task Force (IRTF) C. Li +Request for Comments: 9316 China Telecom +Category: Informational O. Havel +ISSN: 2070-1721 A. Olariu + Huawei Technologies + P. Martinez-Julia + NICT + J. Nobre + UFRGS + D. Lopez + Telefonica, I+D + October 2022 + + + Intent Classification + +Abstract + + Intent is an abstract, high-level policy used to operate a network. + An intent-based management system includes an interface for users to + input requests and an engine to translate the intents into the + network configuration and manage their life cycle. + + This document mostly discusses the concept of network intents, but + other types of intents are also considered. Specifically, this + document highlights stakeholder perspectives of intent, methods to + classify and encode intent, and the associated intent taxonomy; it + also defines relevant intent terms where necessary, provides a + foundation for intent-related research, and facilitates solution + development. + + This document is a product of the IRTF Network Management Research + Group (NMRG). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Network + Management Research Group of the Internet Research Task Force (IRTF). + Documents approved for publication by the IRSG are not candidates for + any level of Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9316. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 1.1. Research Activities + 1.2. Standards and Open-Source Activities + 1.3. Scope + 2. Abbreviations + 3. Definitions + 4. Abstract Intent Requirements + 4.1. What is intent? + 4.2. Intent Solutions and Intent Users + 4.3. Benefits of Intents for Different Stakeholders + 4.4. Intent Types That Need to Be Supported + 5. Functional Characteristics and Behavior + 5.1. Abstracting Intent Operation + 5.2. Intent User Types + 5.3. Intent Scope + 5.4. Intent Network Scope + 5.5. Intent Abstraction + 5.6. Intent Life Cycle + 5.7. Autonomous Driving Levels + 6. Intent Classification + 6.1. Intent Classification Methodology + 6.2. Intent Taxonomy + 6.3. Intent Classification for Carrier Solution + 6.3.1. Intent Users and Intent Types + 6.3.2. Intent Categories + 6.3.3. Intent Classification Example + 6.4. Intent Classification for Data Center Network Solutions + 6.4.1. Intent Users and Intent Types + 6.4.2. Intent Categories + 6.4.3. Intent Classification Example + 6.5. Intent Classification for Enterprise Solution + 6.5.1. Intent Users and Intent Types + 6.5.2. Intent Categories + 7. Conclusions + 8. Security Considerations + 9. IANA Considerations + 10. Informative References + Acknowledgments + Contributors + Authors' Addresses + +1. Introduction + + The vision of intent-based networks has attracted a lot of attention + because it promises to simplify the management of networks by human + operators. This is done by simply specifying what should happen on + the network without giving any instructions on how to do it. This + promise caused many researcher-led activities and telecom companies + to start researching this new vision and many Standards Development + Organizations (SDOs) to propose different intent frameworks. + + This document proposes an intent classification methodology and an + intent taxonomy. The scope of these proposals is to ensure a common + understanding in the research community in terms of what the intent + users, intent types, or intent solutions, etc., are for specific + scenarios that are being considered. + + The document represents the consensus of the Network Management + Research Group (NMRG). It has been reviewed extensively by the + Research Group (RG) members who are actively involved in the research + and development of the technology covered by this document. It is + not an IETF product and is not a standard. + +1.1. Research Activities + + Intent-based networking is an active research topic spanning across + different areas that could benefit from an intent classification and + taxonomy. + + Some examples include: + + * intent expression and recognition ([Bezahaf21], [Bezahaf19], + [Jacobs18]). The use of a common classification could provide + consistency in the understanding of the various forms of intent + expressions being proposed and investigated. + + * the orchestration of cognitive autonomous radio access networks + (RANs) [Banerjee21] where intents are classified based on their + content. + + * intent network verification [Tian19], where the authors are + working to propose new intent language. + + Furthermore, this document is already proving to be extremely + relevant to the research community as it has been used as the basis + for proposing self-generated Intent-based systems [Bezahaf19], for + advancing Virtual Network Function (VNF) placement solutions based on + Internet-Based Networks (IBNs) that rely on defining user intent + profiles corresponding to abstract network services [Leivadeas21], + for improving existing solutions in provisioning intent-based + networks, for proposing new approaches to service management + [Davoli21], and even for defining grammars for users to specify the + high-level requirements for blockchain selection in the form of + intent [Padovan20]. As well, the document has been mentioned in + surveys addressing the topic of intelligent intent-based autonomous + networks [Mehmood21] [Szilagyi21]. + + This document also describes an example on how this proposal has been + successfully applied in an academic environment [POC-IBN] by + researchers in the area of Software-Defined Networking / Network + Function Virtualization (SDN/NFV) for defining the scope of their + project. The specific problem addressed by researchers is how to + apply intent concepts at different levels that correspond to + different stakeholders. + + The IEEE Communications Society Technical Committee on Network + Operation and Management (IEEE-CNOM), IRTF Network Management + Research Group, and IFIP WG6.6 have developed a taxonomy for network + and service management [IFIP-NSM] that is used by the research + community in network management and operations to structure the + research area through a well-defined set of keywords and to improve + quality of reviews in submissions to journals, conferences, and + workshops. The proposed intent taxonomy may be contributed as an + extension to this taxonomy for intent-driven management. + +1.2. Standards and Open-Source Activities + + Several SDOs and open-source projects, such as the IRTF NMRG, Open + Networking Foundation (ONF) [ONF] / Open Network Operating System + (ONOS) [ONOS], European Telecommunications Standards Institute (ETSI) + / Experiential Networked Intelligence (ENI), and TMF with its + autonomous networks, have proposed intents for defining a set of + network operations to execute in a declarative manner. + + More recently, the IRTF NMRG is working on "Intent-Based Networking - + Concepts and Definitions" [RFC9315]. This document clarifies the + concept of "Intent" and provides an overview of the functionality + that is associated with it. The goal is to contribute towards a + common and shared understanding of terms, concepts, and functionality + that can be used as the foundation to guide further definition of + associated research and engineering problems and their solutions. + + The present document, together with [RFC9315], aims to become the + foundation for future intent-related topic discussions regarding the + NMRG. + + The SDOs usually come up with their own way of specifying an intent + and their own understanding of what an intent is. Additionally, each + SDO defines a set of terms and level of abstraction, its intent + users, and the applications and usage scenarios. + + However, most intent approaches proposed by SDOs share the same + features: + + * It must be declarative in nature, meaning that an intent user + specifies the goal on the network without specifying how to + achieve that goal. + + * It must be vendor agnostic in the sense that it abstracts the + network capabilities or the network infrastructure from the intent + user, and it can be ported across different platforms. + + * It must provide an easy-to-use interface, which simplifies the + interaction of the intent users with the intent system through the + usage of familiar terminology or concepts. + + * It should be able to detect and resolve intent conflicts, which + include, for example, static (compile-time) conflicts and dynamic + (run-time) conflicts. + +1.3. Scope + + The focus of this document is on the definition of criteria enabling + the categorization of intents from viewpoint of the stakeholders. + Concepts and definitions related to IBN are provided in [RFC9315]. + + This document mostly addresses intents in the context of network + intents; however, other types of intents are not excluded, as + presented in Sections 4.4 and 6.2. + + It is impossible to fully differentiate intents only by the common + characteristics followed by concepts, terms, and intentions. This + document clarifies what an intent represents for different + stakeholders through a classification on various dimensions, such as + solutions, intent users, and intent types. This classification + ensures common understanding among all participants and is used to + determine the scope and priority of individual projects, proof of + concepts (PoCs), research initiatives, or open-source projects. + + The scope of intent classification in this document includes + solutions, intent users, and intent types; the initial classification + table is made according to this scope. The methodology presented can + be used to update the classification tables by adding or removing + different solutions, intent users, or intent types to cater to future + scenarios, applications, or domains. + +2. Abbreviations + + AI: Artificial Intelligence + + CE: Customer Equipment + + CFS: Customer Facing Service + + CLI: Command-Line Interface + + DB: Database + + DC: Data Center + + ECA: Event Condition Action + + GBP: Group-Based Policy + + GPU: Graphics Processing Unit + + IBN: Intent-Based Network + + NFV: Network Function Virtualization + + O&M: OAM & Maintenance + + ONF: Open Networking Foundation + + ONOS: Open Network Operating System + + PNF: Physical Network Function + + QoE: Quality of Experience + + RFS: Resource Facing Service + + SDO: Standards Development Organization + + SD-WAN: Software-Defined Wide-Area Network + + SLA: Service Level Agreement + + SUPA: Simplified Use of Policy Abstractions + + VM: Virtual Machine + + VNF: Virtual Network Function + +3. Definitions + + A common and shared understanding of terms and definitions related to + IBN is provided in [RFC9315] as follows: + + Intent: A set of operational goals (that a network should meet) and + outcomes (that a network is supposed to deliver) defined in a + declarative manner without specifying how to achieve or implement + them. + + Intent-Based Network: A network that can be managed using intent. + + Policy: A set of rules that governs the choices in behavior of a + system. + + Intent User: A user that defines and issues the intent request to + the intent-based management system. + + Other definitions relevant to this document, such as intent scope, + intent network scope, intent abstraction, intent abstraction, and + intent life cycle are available in Section 5. + +4. Abstract Intent Requirements + + In order to understand the different intent requirements that would + drive intent classification, we first need to understand what intent + means for different intent users. + +4.1. What is intent? + + The term "Intent" has become very widely used in the industry for + different purposes; sometimes its use is not even in agreement with + SDO-shared principles mentioned in Section 1. [RFC9315] brings + clarification with relation to what an intent is and how it + differentiates from policies and services. + + Different stakeholders have different perspectives of the network; + therefore, they have different intent requirements. Their intent is + sometimes technical, non-technical, abstract, or technology specific. + Therefore, it is important to start a discussion in the industry and + academic communities about what intent is for different solutions and + intent users. It is also imperative to try to propose some intent + categories/classifications that could be understood by a wider + audience. This would help us define intent interfaces, domain- + specific languages, and models. + +4.2. Intent Solutions and Intent Users + + Intent types are defined by all aspects that are required to profile + different requirements to easily distinguish between them. However, + in order to facilitate a clustered classification, we can focus on + two aspects: the solution and intent user. They can be considered to + be the main keys to classify intents, as we can easily group + requirements by solution and intent user. + + On the one hand, different solutions and intent users have different + requirements, expectations, and priorities for intent-based + networking. Therefore, intent users require different intent types, + depending on their context, since they participate in different use + cases. For instance, some intent users are more technical and + require intents that expose more technical information. Other intent + users do not have knowledge of the network infrastructure and require + intents that shield them from different networking concepts and + technologies. + + The following are the solutions and intent users that intent-based + networking needs to support: + + +============+=====================================+ + | Solutions | Intent Users | + +============+=====================================+ + | Carrier | Network Operators, Service | + | Networks | Designers / App Developers, Service | + | | Operators, Customers / Subscribers | + +------------+-------------------------------------+ + | DC | Cloud Administrators, Underlay | + | Networks | Network Administrators, Application | + | | Developers, Customers / Tenants | + +------------+-------------------------------------+ + | Enterprise | Enterprise Administrators, | + | Networks | Application Developers, End Users | + +------------+-------------------------------------+ + + Table 1: Intent Solutions and Intent Users + + These intent solutions and intent users represent a starting point + for the classification and are expendable through the methodology + presented in Section 6.1. + + * For carrier network scenarios, for example, if a customer/ + subscriber wants to watch high-definition video, then the intent + is to convert the video image to 1080p. + + * For DC network scenarios, administrators have their own clear + network intent such as load balancing. For all traffic flows that + need NFV service chaining, they can restrict the maximum load of + any VNF node / container below 50% and the maximum load of any + network link below 70%. + + * For enterprise network scenarios, when hosting a video conference, + multiple remote accesses are required. An example of the intent + from the network administrator is as follows: for any end user of + this application, the arrival time of hologram objects of all the + remote tele-presenters should be synchronized within 50 ms to + reach the destination viewer for each conversation session. + +4.3. Benefits of Intents for Different Stakeholders + + Current network APIs and CLIs are too complex because they are highly + integrated with the low-level concepts exposed by networks. + Customers, application developers, and end users must not be required + to set IP addresses, VLANs, subnets, or ports, whereas operators may + still want to have both more technical and network visibility. All + stakeholders would benefit from simpler interfaces, such as: + + * request gold VPN service between sites A, B, and C + + * provide CE redundancy for the customer sites + + * add access rules to the network service + + Operators and administrators manually troubleshoot and fix their + networks and services. They instead want to: + + * simplify and automate network operations + + * simplify definitions of network services + + * provide simple customer APIs for value-added services (operators) + + * be informed if the network or service is not behaving as requested + + * enable automatic optimization and correction for selected + scenarios + + * have systems that learn from historic information and behavior + + Currently, intent users cannot build their own services and policies + without becoming technical experts and performing manual maintenance + actions. They instead want to be able to: + + * build their own network services with their own policies via + simple interfaces, without becoming networking experts + + * have their network services up and running based on intent and + automation only, without any manual actions or maintenance + +4.4. Intent Types That Need to Be Supported + + Next to the intent solutions and intent users, another way to + categorize the intent is through the intent types. The following + intent types and subtypes need to be supported in order to address + the requirements from different solutions and intent users. + + * Customer service intent + + - for customer self service with SLA + + - for service operator orders + + * Network and underlay network service intent + + - for service operator orders + + - for intent-driven network configuration, verification, + correction, and optimization + + - for intent created and provided by the underlay network + administrator + + * Network and underlay network intent + + - for network configuration + + - for automated life-cycle management of network configurations + + - for network resources (switches, routers, routing, policies, + and underlay) + + * Cloud management intent + + - for DC configuration, VMs, DB servers, and Application servers + + - for communication between VMs + + * Cloud resource management intent + + - for cloud resource life-cycle management (policy-driven self- + configuration and auto-scaling and recovery/optimization) + + * Strategy intent + + - for security, QoS, application policies, traffic steering, etc. + + - for configuring and monitoring policies, alarm generation for + non-compliance, and auto-recovery + + - for design models and policies for network and network service + design + + - for design workflows, models, and policies for operational task + intents + + * Operational task intents + + - for network migration + + - for device replacements + + - for network software upgrades + + - for automating any other tasks that operators/administrator + often perform + + It is important to mention all of the previously mentioned types and + subtypes may affect other intents. For example, operational task + intent can modify many other intents. The task itself is short + lived, but the modification of other intents has an impact on their + life cycle, so those changes must continue to be continuously + monitored and self corrected/optimized. + +5. Functional Characteristics and Behavior + + Intent can be used to operate immediately on a target (much like + issuing a command) or whenever it is appropriate (e.g., in response + to an event). In either case, intent has a number of behaviors that + serve to further organize its purpose, as described by the following + subsections. + +5.1. Abstracting Intent Operation + + The modeling of intents can be abstracted using the following three- + tuple: + + {Context, Capabilities, Constraints} + + * Context grounds the intent and determines if it is relevant or not + for the current situation. Thus, context selects intents based on + applicability. + + * Capabilities describe the functionality that the intent can + perform. Capabilities take different forms depending on the + expressivity of the intent as well as the programming paradigm(s) + used. + + * Constraints define any restrictions on the capabilities to be used + for that particular context. + + Metadata can be attached via strategy templates to each of the + elements of the three-tuple and may be used to describe how the + intent should be used and how it operates as well as prescribe any + operational dependencies that must be taken into account. + + Although different intent categories share the same abstracted intent + model, each category will have its own specific context, + capabilities, and constraints. + +5.2. Intent User Types + + Expanding on the introduction in Section 4.2, intent user types + represent the intent users that define and issue the intent request. + Depending on the intent solutions, there are specific intent users. + Examples of intent users are customers, network operators, service + operators, enterprise administrators, cloud administrators, underlay + network administrators, or application developers. + + * Customers and end users do not necessarily know the functional and + operational details of the network that they are using. + Furthermore, they lack skills to understand such details; in fact, + such knowledge is typically not relevant to their job. In + addition, the network may not expose these details to its intent + users. This class of intent users focuses on the applications + that they run and uses services offered by the network. Hence, + they want to specify policies that provide consistent behavior + according to their business needs. They do not have to worry + about how the intents are deployed onto the underlying network and + especially whether the intents need to be translated to different + forms to enable network elements to understand them. + + * Application developers work in a set of abstractions defined by + their application and programming environment(s). For example, + many application developers think in terms of objects (e.g., a + VPN). While this makes sense to the application developer, most + network devices do not have a VPN object per se; rather, the VPN + is formed through a set of configuration statements for that + device in concert with configuration statements for the other + devices that together make up the VPN. Hence, the view of + application developers matches the services provided by the + network but may not directly correspond to other views of other + intent users. + + * Network operators may have the knowledge of the underlying + network. However, they may not understand the details of the + applications and services of customers. + +5.3. Intent Scope + + Intents are used to manage the behavior of the networks they are + applied to and all intents are applied within a specific scope, such + as: + + * connectivity scope, if the intent creates or modifies a connection + + * security/privacy scope, if the intent specifies the security + characteristics of the network, customers, or end users + + * application scope, when the intent specifies the applications to + be affected by the intent request + + * QoS scope, when the intent specifies the QoS characteristics of + the network + + These intent scopes are expendable through the methodology presented + in Section 6.1. + +5.4. Intent Network Scope + + Regardless of the intent user type, their intent request affects the + network, or network components, which are representing the intent + targets. + + Thus, the intent network scope, or policy target as known in the area + of declarative policy, can represent VNFs or PNFs, physical network + elements, campus networks, SD-WANs, RANs, cloud edges, cloud cores, + branches, etc. + +5.5. Intent Abstraction + + Intent can be classified by whether it is necessary to feed back + technical network information or non-technical information to the + intent user after the intent is executed. As well, intent + abstraction covers the level of technical details in the intent + itself. + + * Non-technical intent users do not care how the intent is executed + nor do they care about the details of the network. As a result, + they do not need to know the configuration information of the + underlying network. They only focus on whether the intent + execution result achieves the goal and the execution effect such + as the quality of completion and the length of execution. In this + scenario, we refer to an abstraction without technical feedback. + + * Administrators, such as network administrators, perform intents, + such as allocating network resources, selecting transmission + paths, handling network failures, etc. They require multiple + feedback indicators for network resource conditions, congestion + conditions, fault conditions, etc., after execution. In this + case, we refer to an abstraction with technical feedback. + + As per the definition of "intent" provided in [RFC9315], lower-level + intents are not considered to qualify as intents. However, we kept + this classification to identify any PoCs / Demos / Use Cases that + still either require or implement a lower level of abstraction for + intents. + +5.6. Intent Life Cycle + + Intents can be classified into transient and persistent intents: + + Transient: The intent has no life-cycle management. As soon as the + specified operation is successfully carried out, the intent is + finished and can no longer affect the target object. + + Persistent: The intent has life-cycle management. Once the intent + is successfully activated and deployed, the system will keep all + relevant intents active until they are deactivated or removed. + +5.7. Autonomous Driving Levels + + In different phases of the autonomous driving network [TMF-AUTO], the + intents are different. Depending on the Autonomous Network Level of + the overall solution, we may have different intent requirements and + types. For example, at lower levels, the customer intent is: + + * automatically converted to configuration policies only while at + the higher levels, + + * covering the full life cycle, + + * converted to both configuration and monitoring policies, and + + * self assured using AI. + + Typical examples of autonomous driving networks level 0 to 5 are + shown below. + + Level 0 - Traditional manual network: + O&M personnel manually control the network and obtain network + alarms and logs. + + - No intent + + Level 1 - Partially automated network: + Automated scripts are used to automate service provisioning, + network deployment, and maintenance. The network provides shallow + perception of the network status and decision making suggestions. + + - No intent + + Level 2 - Automated network: + This entails the automation of most service provisioning, network + deployment, and maintenance of a comprehensive perception of + network status and local machine decision-making. + + - simple intent on service provisioning + + Level 3 - Self-optimization network: + This entails a deep awareness of network status and automatic + network control, meeting requirements of intent users of the + network. + + - Intent based on network status cognition + + Level 4 - Partial autonomous network: + In a limited environment, people do not need to participate in + decision-making and networks can adjust themselves. + + - Intent based on limited AI + + Level 5 - Autonomous network: + In different network environments and network conditions, the + network can automatically adapt and adjust to meet people's + intentions. + + - Intent based on AI + +6. Intent Classification + + This section proposes an approach to intent classification that may + help to classify mainstream intent-related demos/tools. + + The three classifications in this document have been proposed from + scratch (following the methodology presented) through three + iterations: one for a carrier network intent solution, one for a DC + intent solution, and one for an enterprise intent solution. For each + intent solution, we identified the specific intent users and intent + types. Then, we further identified intent scope, network scope, + abstractions, and life-cycle requirements. + + These classifications and the generated tables can be easily + extended. For example, for the DC intent solution, a new category + "resource scope" is identified, and the classification table has been + extended accordingly. + + In the future, as new scenarios, applications, and domains emerge, + new classifications and taxonomies can be identified, following the + proposed methodology. + + The intent classifications have been documented to the best of our + knowledge at the time of writing. Additional classifications will + most likely come to light in the future. + + The output of the intent classification is the intent taxonomy + introduced in the subsections of this section. + + Thus, the subsections of Section 6 introduce the proposed intent + classification methodology, the consolidated intent taxonomy for + three intent solutions, and the concrete examples of intent + classifications for three different intent solutions (e.g., carrier + network, data center, and enterprise) that were derived using the + proposed methodology and can be filled in for PoCs, demos, research + projects, or future documents. + +6.1. Intent Classification Methodology + + This section describes the methodology used to derive the initial + classification proposed in the document. The proposed methodology + can be used to create new intent classifications from scratch by + analyzing the solution knowledge. As well, the methodology can be + used to update existing classification tables by adding or removing + different solutions, intent users, or intent types in order to cater + to future scenarios, applications, or domains. + + +------------------------------------------+ + |Solution Knowledge (requirements, | + |use cases, technologies, network, intent | + |users, intent requirements) | + +----------------+-------------------------+ + | Input Rx=Read + | Ux=Update (Add/Remove) + +--------V--------+ + |1.Identify Intent| + | Solution +------------+ + | | | + +---------^-+-----+ | + R1 | | U1 | + +---------------+ U8 | | R2 +--v----------------+ + |8.Identify New +---------+ | | +-----------> 2.Identify | + | Categories | R8 | | | | U2 | Intent | + | <-------- | | | | +---------+ User Types | + +--------^------+ | | | | | | +-------|-----------+ + | | | | | | | | + | ++-+-v-v---+-v-+ | + +--------+------+ U7 | | R3 +------v------------+ + |7.Identify +------> Intent +--------> 3.Identify | + | Life-Cycle | R7 |Classification| U3 | Type | + | Requirements <------+ <--------+ of Intent | + +--------^------+ +^--^-+--^-+---+ +------|------------+ + | || | | | | | + | || | | | | | + +--------+-----+ || | | | | R4 +-------v-----------+ + |6.Identify | U6 || | | | +-----------> 4.Identify | + | Abstractions+---------| | | | U4 | Intent | + | <---------+ | | +-------------+ Scope | + +-------^------+ R6 | | +-------+-----------+ + | | | | + | U5 | |R5 | + | +-------+-v--------+ | + | |5.Identify Network| | + +----------+ Scope <---------------+ + +------------------+ + + Figure 1: Intent Classification Methodology + + The intent classification workflow starts from the solution + knowledge, which can provide information on requirements, use cases, + technologies used, network properties, intent users that define and + issue the intent request, and requirements. The following defines + the steps to classify an intent: + + 1. Receive the information provided in the solution knowledge as + input for identifying the intent solution (e.g., carrier, + enterprise, and data center). Intent solutions are reviewed + against the existing classification and can either be used if + present or added if not there; if not needed, they can be removed + from the classification (R1-U1). + + 2. Identify the intent user types (e.g., customer, network + operators, service operators, etc.). Review the existing intent + classification. Then use the intent user type if present; add it + if it is not there or remove it if not needed (R2-U2). + + 3. Identify the types of intent (e.g., network intent, customer + service intent). Review the existing classification and then + use, add, or remove the intent type (R3-U3). + + 4. Identify the intent scopes (e.g., connectivity, application) + based on the solution knowledge. Then, review the existing + classification. Use, add, or remove the identified intent scope + (R4-U4). + + 5. Identify the network scopes (e.g., campus, radio access). Then, + review the existing classification. Either use, add, or remove + the identified network scope (R5-U5). + + 6. Identify the abstractions (e.g., technical, non-technical). + Then, review the existing classification and either use, add, or + remove the abstractions (R6-U6). + + 7. Identify the life-cycle requirements (e.g., persistent, + transient). Then, review the existing classification. Either + use, add, or remove the life-cycle requirements (R7-U7). + + 8. Identify any new categories. Use and add the newly identified + categories. New categories can be identified as new domains or + applications emerge or as new areas of concern (e.g., privacy, + compliance) arise that are not listed in the current methodology. + +6.2. Intent Taxonomy + + The following taxonomy describes the various intent solutions, intent + user types, intent types, intent scopes, network scopes, + abstractions, and life cycles. The taxonomy represents the output of + the intent classification tables for each of the solutions addressed + (i.e., carrier, data center, and enterprise solutions). + + The intent scope categories in Figure 2 are shared among the carrier, + DC, and enterprise solutions. The abbreviations (Cx) in Sections + 6.3.2 and 6.4.2 are introduced with the scope of fitting as column + title in the following tables. + + +--------------------------------+ + +-->|Carrier Enterprise Data Center| + | +--------------------------------+ + | +--------------------------------+ + | |Customer/Subscriber/End User | + +----------+ | |Network or Service Operator | + +>+Solution +--+ |Application Developer | + | +----------+ +->|Enterprise Administrator | + | | |Cloud Administrator | + | +----------+ | |Underlay Network Administrator | + +>+Intent +---+ +--------------------------------+ + | |User | +--------------------------------+ + | |Type | |Customer Service Intent | + | +----------+ |Strategy Intent | + | +----------+ |Network Service Intent | + +>+Intent +----->|Underlay Network Service Intent | + +------+ | |Type | |Network Intent | + |Intent+-+ +----------+ |Underlay Network Intent | + +------+ | |Operational Task Intent | + | +----------+ |Cloud Management Intent | + +>+Intent +---+ |Cloud Resource Management Intent| + | |Scope | | +--------------------------------+ + | +----------+ | +--------------------------------+ + | +->|Connectivity Application QoS | + | +----------+ |Security/Privacy Storage Compute| + +>+Network +---+ +--------------------------------+ + | |Scope | | +--------------------------------+ + | +----------+ | |Radio Access Branch | + | +->|Transport Access SD-WAN | + | +----------+ |Transport Aggr. VNF PNF | + +>+Abstrac- +----+ |Transport Core Physical | + | |tion | | |Cloud Edge Logical | + | +----------+ | |Cloud Core Campus | + | +----------+ | +--------------------------------+ + +>+Life | | +--------------------------------+ + |Cycle +--+ +>|Technical Non-Technical | + +----------+ | +--------------------------------+ + | +--------------------------------+ + +-->|Persistent Transient | + +--------------------------------+ + + Figure 2: Intent Taxonomy + +6.3. Intent Classification for Carrier Solution + +6.3.1. Intent Users and Intent Types + + This section addresses steps 1, 2, and 3 from Figure 1. The + following table describes the intent users in carrier solutions and + intent types with their descriptions for different intent users. + + +=============+=============+=======================================+ + | Intent User | Intent Type | Intent Type Description | + +=============+=============+=======================================+ + | Customer/ | Customer | Customer self service with SLA | + | Subscriber | Service | and value-added service. | + | | Intent | | + | | | Example: Always maintain a high | + | | | quality of service and high | + | | | bandwidth for gold-level | + | | | subscribers. | + | | | | + | | | Operation statement: Measure the | + | | | network congestion status, give | + | | | different adaptive parameters to | + | | | stations of different priority; | + | | | thus, in a heavy load situation, | + | | | make the bandwidth of the high- | + | | | priority customers guaranteed. | + | | | At the same time, ensure the | + | | | overall utilization of the | + | | | system and improve the overall | + | | | throughput of the system. | + | +-------------+---------------------------------------+ + | | Strategy | Customer designs models and | + | | Intent | policy intents to be used by | + | | | customer service intents. | + | | | | + | | | Example: Request reliable | + | | | service during peak traffic | + | | | periods for video-type apps. | + +-------------+-------------+---------------------------------------+ + | Network | Network | Service provided by the network | + | Operator | Service | service operator to the customer | + | | Intent | (e.g., the service operator). | + | | | | + | | | Example: Request network service | + | | | with delay guarantee for access | + | | | customer A. | + | +-------------+---------------------------------------+ + | | Network | Network operator requests | + | | Intent | network-wide (service underlay | + | | | or other network-wide | + | | | configuration) or network- | + | | | resource configurations | + | | | (switches, routers, routing, or | + | | | policies). Includes | + | | | connectivity, routing, QoS, | + | | | security, application policies, | + | | | traffic steering policies, alarm | + | | | generation for non-compliance, | + | | | auto-recovery, etc. | + | | | | + | | | Example: Request high priority | + | | | queuing for traffic of class A. | + | +-------------+---------------------------------------+ + | | Operational | Network operator requests | + | | Task Intent | execution of any automated task | + | | | other than network service | + | | | intent and network intent (e.g., | + | | | network migration, server | + | | | replacements, device | + | | | replacements, or network | + | | | software upgrades). | + | | | | + | | | Example: Request migration of | + | | | all services in network N to | + | | | backup path P. | + | +-------------+---------------------------------------+ + | | Strategy | Network operator designs models, | + | | Intent | policy intents, and workflows to | + | | | be used by network service | + | | | intents, network intents, and | + | | | operational task intents. | + | | | Workflows can automate any tasks | + | | | that the network operator often | + | | | performs in addition to network | + | | | service intents and network | + | | | intents. | + | | | | + | | | Example: Ensure the load on any | + | | | link in the network is not | + | | | higher than 50%. | + +-------------+-------------+---------------------------------------+ + | Service | Customer | Service operator's customer | + | Operator | Service | orders, customer service, or | + | | Intent | SLA. | + | | | | + | | | Example: Provide service S with | + | | | guaranteed bandwidth for | + | | | customer A. | + | +-------------+---------------------------------------+ + | | Network | Service operator's network | + | | Service | orders / network SLA. | + | | Intent | | + | | | Example: Provide network | + | | | guarantees in terms of security, | + | | | low latency, and high bandwidth. | + | +-------------+---------------------------------------+ + | | Operational | Service operator requests | + | | Task Intent | execution of any automated task | + | | | other than customer service | + | | | intent and network service | + | | | intent. | + | | | | + | | | Example: Update service operator | + | | | portal platforms and their | + | | | software regularly. Move | + | | | services from network operator 1 | + | | | to network operator 2. | + | +-------------+---------------------------------------+ + | | Strategy | Service operator designs models, | + | | Intent | policy intents, and workflows to | + | | | be used by customer service | + | | | intents, network service | + | | | intents, and operational task | + | | | intents. Workflows can automate | + | | | any task that the service | + | | | operator often performs in | + | | | addition to network service | + | | | intents and network intents. | + | | | | + | | | Example: Request network service | + | | | guarantee to avoid network | + | | | congestion during special | + | | | periods such as Black Friday and | + | | | Christmas. | + +-------------+-------------+---------------------------------------+ + | Application | Customer | Customer service intent API | + | Developer | Service | provided to the application | + | | Intent | developers. | + | | | | + | | | Example: API to request network | + | | | to watch HD video (4K/8K). | + | +-------------+---------------------------------------+ + | | Network | Network service intent API | + | | Service | provided to the application | + | | Intent | developers. | + | | | | + | | | Example: API to request network | + | | | service, monitoring, and traffic | + | | | grooming. | + | +-------------+---------------------------------------+ + | | Network | Network intent API provided to | + | | Intent | the application developers. | + | | | | + | | | Example: API to request network | + | | | resource configurations. | + | +-------------+---------------------------------------+ + | | Operational | Operational task intent API | + | | Task Intent | provided to the application | + | | | developers. This is for the | + | | | trusted internal operator / | + | | | service providers / customer | + | | | DevOps. | + | | | | + | | | Example: API to request server | + | | | migrations. | + | +-------------+---------------------------------------+ + | | Strategy | Application developer designs | + | | Intent | models, policy, and workflows to | + | | | be used by customer service | + | | | intents, network service | + | | | intents, and operational task | + | | | intents. This is for the | + | | | trusted internal operator / | + | | | service provider / customer | + | | | DevOps. | + | | | | + | | | Example: API to design network | + | | | load-balancing strategies during | + | | | peak times. | + +-------------+-------------+---------------------------------------+ + + Table 2: Intent Classification for Carrier Solution + +6.3.2. Intent Categories + + This subsection addresses steps 4 to 7 from Figure 1. The following + are the proposed categories: + + Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, + C4=QoS + + Network Scope: + + Network Domain: C1=Radio Access, C2=Transport + Access, C3=Transport Aggregation, C4=Transport Core, C5=Cloud + Edge, C6=Cloud Core + + Network Function (NF) Scope: C1=VNFs, C2=PNFs + + Abstraction (ABS): C1=Technical (with technical feedback), C2=Non- + technical (without technical feedback) (see Section 5.2). + + Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient + (short lived) + +6.3.3. Intent Classification Example + + This section contains an example of how the methodology described in + Section 6.1 can be used in order to classify intents introduced in + the "A Multi-Level Approach to IBN" PoC demonstration [POC-IBN]. + This PoC is led by academics carrying out research in the area of + SDN/NFV, and the specific problem they are addressing is the + application of the intent concept at different levels that correspond + to different stakeholders. For this research work, they considered + two types of intents: slice intents and service chain intents. + + In this PoC [POC-IBN], a slice intent expresses a request for a + network slice with two types of components: a set of top-layer + virtual functions and a set of virtual switches and/or routers of L2/ + L3 VNFs. A service chain intent expresses a request for a service + operated through a chain of service components running in L4-L7 + virtual functions. + + Following the intent classification methodology described step by + step in Section 6.1, the following can be derived: + + 1. The intent solution for both intents is carrier network. + + 2. The intent user type is network operator for the slice intent and + service operator for the service chain intent. + + 3. The type of intent is a network service intent for the slice + intent and a customer service intent for the service chain + intent. + + 4. The intent scopes are connectivity and application. + + 5. The network scope is VNF, cloud edge, and cloud core. + + 6. The abstractions are with technical feedback for the slice intent + and without technical feedback for the service chain intent. + + 7. The life cycle is persistent. + + The following table shows how to represent this information in a + tabular form. The "X" in the table refers to the slice intent; the + "Y" in the table refers to the service chain intent. + ++==========+===========+===========+=====+=================+=====+=====+ +|Intent |Intent Type|Intent |NF |Network |ABS |L-C | +|User | |Scope |Scope|Scope | | | +| | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ +| | |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2| ++==========+===========+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ +|Customer/ |Customer | | | | | | | | | | | | | | | | | +|Subscriber|Service | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Strategy | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | ++----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +|Network |Network |X | |X | |X | | | | | |X | |X | |X | | +|Operator |Service | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Network | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Operational| | | | | | | | | | | | | | | | | +| |Task Intent| | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Strategy | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | ++----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +|Service |Customer |Y | |Y | |Y | | | | | |Y |Y | |Y |Y | | +|Operator |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Network | | | | | | | | | | | | | | | | | +| |Service | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Op Task | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Strategy | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | ++----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +|App |Customer | | | | | | | | | | | | | | | | | +|Developer |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Network | | | | | | | | | | | | | | | | | +| |Service | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Network | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Op Task | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | +| +-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| |Strategy | | | | | | | | | | | | | | | | | +| |Intent | | | | | | | | | | | | | | | | | ++----------+-----------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 3: Intent Classification Example for Carrier Solution + +6.4. Intent Classification for Data Center Network Solutions + +6.4.1. Intent Users and Intent Types + + The following table describes the intent users in DC network + solutions and intent types with their descriptions for different + intent users. + + +===============+=============+====================================+ + | Intent User | Intent Type | Intent Type Description | + +===============+=============+====================================+ + | Customer/ | Customer | Customer self service via tenant | + | Tenants | Service | portal. | + | | | | + | | | Example: Request GPU computing and | + | | | storage resources to meet 10k | + | | | video surveillance services. | + | +-------------+------------------------------------+ + | | Strategy | This includes models and policy | + | | Intent | intents designed by customers/ | + | | | tenants to be reused later during | + | | | instantiation. | + | | | | + | | | Example: Request dynamic computing | + | | | and storage resources of the | + | | | service in special and daily | + | | | times. | + +---------------+-------------+------------------------------------+ + | Cloud | Cloud | Configuration of VMs, DB Servers, | + | Administrator | Management | app servers, and communication | + | | Intent | between servers and VMs. | + | | | | + | | | Example: Request connectivity | + | | | between VMs A, B, and C in network | + | | | N1. | + | +-------------+------------------------------------+ + | | Cloud | Policy-driven self configuration | + | | Resource | and recovery/optimization. | + | | Management | | + | | Intent | Example: Request automatic life- | + | | | cycle management of VM cloud | + | | | resources. | + | +-------------+------------------------------------+ + | | Operational | Cloud administrator requests | + | | Task Intent | execution of any automated task | + | | | other than cloud management | + | | | intents and cloud resource | + | | | management intents. | + | | | | + | | | Example: Request upgrade operating | + | | | system to version X on all VMs in | + | | | network N1. | + | | | | + | | | Operational statement: An intent | + | | | to update a system might | + | | | reconfigure the system topology | + | | | (connect to a service and to | + | | | peers), exchange data (update the | + | | | content), and uphold a certain QoE | + | | | level (allocate sufficient network | + | | | resources). Thus, the network | + | | | carries out the necessary | + | | | configuration to best serve such | + | | | an intent, e.g., setting up direct | + | | | connections between terminals and | + | | | allocating fair shares of router | + | | | queues considering other network | + | | | services. | + | +-------------+------------------------------------+ + | | Strategy | Cloud administrator designs | + | | Intent | models, policy intents, and | + | | | workflows to be used by other | + | | | intents. Automate any tasks that | + | | | administrator often performs in | + | | | addition to life cycle of cloud | + | | | management intents and cloud | + | | | management resource intents. | + | | | | + | | | Example: In case of emergency, | + | | | automatically migrate all cloud | + | | | resources to DC2. | + +---------------+-------------+------------------------------------+ + | Underlay | Underlay | Service created and provided by | + | Network | Network | the underlay network | + | Administrator | Service | administrator. | + | | Intent | | + | | | Example: Request underlay service | + | | | between DC1 and DC2 with bandwidth | + | | | B. | + | +-------------+------------------------------------+ + | | Underlay | Underlay network administrator | + | | Network | requests some DCN-wide underlay | + | | Intent | network configuration or network | + | | | resource configurations. | + | | | | + | | | Example: Establish and allocate | + | | | DHCP address pool. | + | +-------------+------------------------------------+ + | | Operational | Underlay network administrator | + | | Task Intent | requests execution of any | + | | | automated task other than underlay | + | | | network service and resource | + | | | intent. | + | | | | + | | | Example: Request automatic rapid | + | | | detection of device failures and | + | | | pre-alarm correlation. | + | +-------------+------------------------------------+ + | | Strategy | Underlay network administrator | + | | Intent | designs models, policy intents, | + | | | and workflows to be used by other | + | | | intents. Automate any tasks that | + | | | the administrator often performs. | + | | | | + | | | Example: For all traffic flows | + | | | that need NFV service chaining, | + | | | restrict the maximum load of any | + | | | VNF node/container below 50% and | + | | | the maximum load of any network | + | | | link below 70%. | + +---------------+-------------+------------------------------------+ + | Application | Cloud | Cloud management intent API | + | Developer | Management | provided to the application | + | | Intent | developers. | + | | | | + | | | Example: API to request | + | | | configuration of VMs or DB | + | | | Servers. | + | +-------------+------------------------------------+ + | | Cloud | Cloud resource management intent | + | | Resource | API provided to the application | + | | Management | developers. | + | | Intent | | + | | | Example: API to request automatic | + | | | life-cycle management of cloud | + | | | resources. | + | +-------------+------------------------------------+ + | | Underlay | Underlay network service API | + | | Network | provided to the application | + | | Service | developers. | + | | Intent | | + | | | Example: API to request real-time | + | | | monitoring of device condition. | + | +-------------+------------------------------------+ + | | Underlay | Underlay network resource API | + | | Network | provided to the application | + | | Intent | developers. | + | | | | + | | | Example: API to request dynamic | + | | | management of IPv4 address pool | + | | | resources. | + | +-------------+------------------------------------+ + | | Operational | Operational task intent API | + | | Task Intent | provided to the trusted | + | | | application developer (internal | + | | | DevOps). | + | | | | + | | | Example: API to request automatic | + | | | rapid detection of device failures | + | | | and pre-alarm correlation. | + | +-------------+------------------------------------+ + | | Strategy | Application developer designs | + | | Intent | models, policy intents, and | + | | | building blocks to be used by | + | | | other intents. This is for the | + | | | trusted internal DCN DevOps. | + | | | | + | | | Example: API to request load- | + | | | balancing thresholds. | + +---------------+-------------+------------------------------------+ + + Table 3: Intent Classification for Data Center Network Solutions + +6.4.2. Intent Categories + + The following are the proposed categories: + + Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, + C4=QoS, C5=Storage, C6=Compute + + Network Scope + + Network Domain: DC Network + + DCN Network (DCN Net) Scope: C1=Logical, C2=Physical + + DCN Resource (DCN Res) Scope: C1=Virtual, C2=Physical + + Abstraction (ABS): C1=Technical (with technical feedback), C2=Non- + technical (without technical feedback) (see Section 5.2). + + Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient + (short lived) + +6.4.3. Intent Classification Example + + This section depicts an example on how the methodology described in + Section 6.1 can be used by the research community to classify + intents. As mentioned in Section 6.3.3, a successful use of the + classification proposed in this document is introduced in the PoC + demonstration titled "A Multi-Level Approach to IBN" [POC-IBN]. The + PoC is led by academics carrying out research in the area of SDN/NFV; + the specific problem they are addressing is the application of the + intent concept at different levels that correspond to different + stakeholders. + + For their research work, they considered two types of intents: slice + intents and service chain intents. For the data center solution, + only the slice intent is relevant. + + As already mentioned in Section 6.3.3, a slice intent expresses a + request for a network slice with two types of components: a set of + top-layer virtual functions and a set of virtual switches and/or + routers of L2/L3 VNFs. + + Following the intent classification methodology described step by + step in Section 6.1, we identify the following: + + 1. The intent solution is data center. + + 2. The intent user type is the cloud administrator for the slice + intent and service chain intent. + + 3. The type of intent is a cloud management intent for the slice + intent. + + 4. The intent scopes are connectivity and application. + + 5. The network scope is logical; the resource scope is virtual. + + 6. The abstractions are with technical feedback for the slice + intent. + + 7. The life cycle is persistent. + + The following table shows how to represent this information in a + tabular form; the "X" in the table refers to the slice intent. + + + +===========+=============+=================+=====+=====+=====+=====+ + |Intent User| Intent Type |Intent |DCN |DCN |ABS |L-C | + | | |Scope |Res |Net | | | + | | +==+==+==+==+==+==+==+==+==+==+==+==+==+==+ + | | |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2| + +===========+=============+==+==+==+==+==+==+==+==+==+==+==+==+==+==+ + |Customer/ | Customer | | | | | | | | | | | | | | | + |Tenants | Service | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |Cloud Admin| Cloud |X | |X | | | |X | |X | |X | |X | | + | | Management | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Cloud | | | | | | | | | | | | | | | + | | Resource | | | | | | | | | | | | | | | + | | Management | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Operational | | | | | | | | | | | | | | | + | | Task Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |Underlay | Underlay | | | | | | | | | | | | | | | + |Network | Network | | | | | | | | | | | | | | | + |Admin | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Underlay | | | | | | | | | | | | | | | + | | Network | | | | | | | | | | | | | | | + | | Resource | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Operational | | | | | | | | | | | | | | | + | | Task Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |App | Cloud | | | | | | | | | | | | | | | + |Developer | Management | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Cloud | | | | | | | | | | | | | | | + | | Resource | | | | | | | | | | | | | | | + | | Management | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Underlay | | | | | | | | | | | | | | | + | | Network | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Underlay | | | | | | | | | | | | | | | + | | Network | | | | | | | | | | | | | | | + | | Resource | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Operational | | | | | | | | | | | | | | | + | | Task Intent | | | | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | | | | + +-----------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 4: Intent Classification Example for Data Center Network + Solutions + +6.5. Intent Classification for Enterprise Solution + +6.5.1. Intent Users and Intent Types + + The following table describes the intent users in enterprise + solutions and their intent types. + + +---------------+-------------+------------------------------------+ + | Intent User | Intent Type | Intent Type Description | + +---------------+-------------+------------------------------------+ + | End User | Customer | Enterprise end user self service | + | | Service | or applications; enterprise may | + | | Intent | have multiple types of end users. | + | | | | + | | | Example: Request access to VPN | + | | | service. Request video conference | + | | | between end user A and B. | + | +-------------+------------------------------------+ + | | Strategy | This includes models and policy | + | | Intent | intents designed by end users to | + | | | be used by end-user intents and | + | | | their applications. | + | | | | + | | | Example: Create a video conference | + | | | type for a weekly meeting. | + +---------------+-------------+------------------------------------+ + | Enterprise | Network | Service provided by the | + | Administrator | Service | administrator to the end users and | + | (internal or | Intent | their applications. | + | MSP) | | | + | | | Example: For any end user of | + | | | application X, the arrival of | + | | | hologram objects of all the remote | + | | | tele-presenters should be | + | | | synchronized within 50 ms to reach | + | | | the destination viewer for each | + | | | conversation session. Create | + | | | management VPN connectivity for | + | | | type of service A. | + | | | | + | | | Operational statement: The job of | + | | | the network layer is to ensure | + | | | that the delay is between 50-70 ms | + | | | through the routing algorithm. At | + | | | the same time, the node resources | + | | | need to meet the bandwidth | + | | | requirements of 4K video | + | | | conferences. | + | +-------------+------------------------------------+ + | | Network | Administrator requires network- | + | | Intent | wide configuration (e.g., underlay | + | | | or campus) or resource | + | | | configuration (switches, routers, | + | | | or policies). | + | | | | + | | | Example: Configure switches in | + | | | campus network 1 to prioritize | + | | | traffic of type A. Configure | + | | | YouTube as business non-relevant. | + | +-------------+------------------------------------+ + | | Operational | Administrator requests execution | + | | Task Intent | of any automated task other than | + | | | network service intents and | + | | | network intents. | + | | | | + | | | Example: Request network security | + | | | automated tasks such as web | + | | | filtering and DDoS cloud | + | | | protection. | + | +-------------+------------------------------------+ + | | Strategy | Administrator designs models, | + | | Intent | policy intents, and workflows to | + | | | be used by other intents. | + | | | Automate any tasks that the | + | | | administrator often performs. | + | | | | + | | | Example: In case of emergency, | + | | | automatically shift all traffic of | + | | | type A through network N. | + +---------------+-------------+------------------------------------+ + | Application | End-User | End-user service / application | + | Developer | Intent | intent API provided to the | + | | | application developers. | + | | | | + | | | Example: API for request to open a | + | | | VPN service. | + | +-------------+------------------------------------+ + | | Network | Network service API provided to | + | | Service | application developers. | + | | Intent | | + | | | Example: API for request network | + | | | bandwidth and latency for hosting | + | | | a video conference. | + | +-------------+------------------------------------+ + | | Network | Network API provided to | + | | Intent | application developers. | + | | | | + | | | Example: API for requesting | + | | | network device configuration. | + | +-------------+------------------------------------+ + | | Operational | Operational task intent API | + | | Task Intent | provided to the trusted | + | | | application developer (internal | + | | | DevOps). | + | | | | + | | | Example: API for requesting | + | | | automatic monitoring and | + | | | interception for network security. | + | +-------------+------------------------------------+ + | | Strategy | Application developer designs | + | | Intent | models, policy intents, and | + | | | building blocks to be used by | + | | | other intents. This is for the | + | | | trusted internal DevOps. | + | | | | + | | | Example: API for strategy intent | + | | | in case of emergencies. | + +---------------+-------------+------------------------------------+ + + Table 4: Intent Classification for Enterprise Solution + +6.5.2. Intent Categories + + The following are the proposed categories: + + Intent Scope: C1=Connectivity, C2=Security/Privacy, C3=Application, + C4=QoS + + Network (Net) Scope: C1=Campus, C2=Branch, C3=SD-WAN + + Abstraction (ABS): C1=Technical (with technical feedback), C2=Non- + technical (without technical feedback) (see Section 5.2) + + Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient + (short lived) + + The following is the intent classification table example for + enterprise solutions. + + + +---------------+-------------+-----------+--------+-----+-----+ + | Intent User | Intent Type | Intent | Net | ABS | L-C | + | | | Scope | | | | + | | +-----------+--------+-----+-----+ + | | |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2| + +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ + | End User | Customer | | | | | | | | | | | | + | | Service | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ + | Enterprise | Network | | | | | | | | | | | | + | Administrator | Service | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Network | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Operational | | | | | | | | | | | | + | | Task | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ + | Application | End-User | | | | | | | | | | | | + | Developer | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Network | | | | | | | | | | | | + | | Service | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Network | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Operational | | | | | | | | | | | | + | | Task | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + | +-------------+--+--+--+--+--+--+--+--+--+--+--+ + | | Strategy | | | | | | | | | | | | + | | Intent | | | | | | | | | | | | + +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 5: Intent Categories for Enterprise Solution + +7. Conclusions + + This document is aligned with the RG objectives and supports + investigations into intent-based networking by proposing an intent + categorization methodology and taxonomy. It brings clarification to + what an intent represents for different stakeholders through the + proposal of an intent classification approach, ensuring that a common + understanding among all the participants exists. This, together with + the proposed intent taxonomy provides a solid foundation for future + intent-related discussions within the NMRG. + + The benefits of this intent classification document in the research + community have been demonstrated through a PoC implementation + [POC-IBN] in which the document's concepts have been applied at + different levels corresponding to different stakeholders. + +8. Security Considerations + + This document identifies security and privacy as categories of the + intent scope. The intents could be solely security intents and + privacy intents, or security can be embedded in the intents that + include also connectivity, application, and QoS scope. + + Security and privacy scope is when the intent specifies the security + characteristics of the network, customers, or end users, and privacy + for customers and end users. + + More details of these security intents will be described in future + documents that specify architecture, functionality, user intents, and + models. An analysis of the security considerations of the overall + intent-based system is provided in Section 9 of [RFC9315]. + +9. IANA Considerations + + This document has no IANA actions. + +10. Informative References + + [Banerjee21] + Banerjee, A., Mwanje, S., and G. Carle, "Contradiction + Management in Intent-driven Cognitive Autonomous RAN", + September 2021. + + [Bezahaf19] + Bezahaf, M., Hernandez, M., Bardwell, L., Davies, E., + Broadbent, M., King, D., and D. Hutchison, "Self-Generated + Intent-Based System", 10th International Conference on + Networks of the Future (NoF), + DOI 10.1109/NoF47743.2019.9015045, October 2019, + <https://doi.org/10.1109/NoF47743.2019.9015045>. + + [Bezahaf21] + Bezahaf, M., Davies, E., Rotsos, C., and N. Race, "To All + Intents and Purposes: Towards Flexible Intent Expression", + IEEE 7th International Conference on Network + Softwarization (NetSoft), + DOI 10.1109/NetSoft51509.2021.9492554, July 2021, + <https://doi.org/10.1109/NetSoft51509.2021.9492554>. + + [Davoli21] Davoli, G., "Programmability and Management of Software- + Defined Network Infrastructures", 2021. + + [IFIP-NSM] IFIP, "Network and Service Management Taxonomy", + <https://www.simpleweb.org/ifip/taxonomy.html>. + + [Jacobs18] Jacobs, A., Pfitscher, R., Ferreira, R., and L. Granville, + "Refining Network Intents for Self-Driving Networks", + Proceedings of the Afternoon Workshop on Self-Driving + Networks (SelfDN), DOI 10.1145/3229584.3229590, August + 2018, <https://doi.org/10.1145/3229584.3229590>. + + [Leivadeas21] + Leivadeas, A. and M. Falkner, "VNF Placement Problem: A + Multi-Tenant Intent-Based Networking Approach", 24th + Conference on Innovation in Clouds, Internet and Networks + and Workshops (ICIN), DOI 10.1109/ICIN51074.2021.9385553, + March 2021, + <https://doi.org/10.1109/ICIN51074.2021.9385553>. + + [Mehmood21] + Mehmood, K., Kralevska, K., and D. Palma, "Intent-driven + Autonomous Network and Service Management in Future + Networks: A Structured Literature Review", + DOI 10.48550/arXiv.2108.04560, August 2021, + <https://doi.org/10.48550/arXiv.2108.04560>. + + [ONF] Open Networking Foundation, "Intent NBI - Definition and + Principles", October 2016, + <https://opennetworking.wpengine.com/wp- + content/uploads/2014/10/TR- + 523_Intent_Definition_Principles.pdf>. + + [ONOS] Koshibe, A., "Intent Framework", 2016, + <https://wiki.onosproject.org/display/ONOS/ + Intent+Framework/>. + + [Padovan20] + Padovan, S., "Design and Implementation of a Blockchain + Intent Management System", November 2020. + + [POC-IBN] Martini, B., Cerroni, W., Gharbaoui, M., and D. Borsatti, + "A Multi-Level Approach to IBN", IETF 108 Hackathon + Report, July 2020, + <https://www.ietf.org/proceedings/108/slides/slides-108- + nmrg-ietf-108-hackathon-report-a-multi-level-approach-to- + ibn-02>. + + [RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. + Tantsura, "Intent-Based Networking - Concepts and + Definitions", RFC 9315, DOI 10.17487/RFC9315, October + 2022, <https://www.rfc-editor.org/info/rfc9315>. + + [Szilagyi21] + Szilágyi, P., "I2BN: Intelligent Intent Based Networks", + Journal of ICT Standardization, Volume 9, Issue 2, + DOI 10.13052/jicts2245-800X.926, June 2021, + <https://doi.org/10.13052/jicts2245-800X.926>. + + [Tian19] Tian, B., Zhang, X., Zhai, E., Liu, H., Ye, Q., Wang, C., + Wu, X., Ji, Z., Sang, Y., Zhang, M., Yu, D., Tian, C., + Zheng, H., and B. Zhao, "Safely and automatically updating + in-network ACL configurations with intent language", + SIGCOMM '19: Proceedings of the ACM Special Interest Group + on Data Communication, DOI 10.1145/3341302.3342088, August + 2019, <https://doi.org/10.1145/3341302.3342088>. + + [TMF-AUTO] Boasman-Patel, A., Sun, D., Wang, Y., Maitre, C., + Domingos, J., Troullides, Y., Mas, I., Traver, G., and G. + Lupo, "Autonomous Networks: Empowering Digital + Transformation For The Telecoms Industry", May 2019. + +Acknowledgments + + This document has benefited from reviews, suggestions, comments, and + proposed text provided by the following members listed in + alphabetical order: Mehdi Bezahaf, Brian E. Carpenter, Laurent + Ciavaglia, Benoit Claise, Alexander Clemm, Yehia Elkhatib, Jerome + Francois, Pedro Andres Aranda Gutierrez, Daniel King, Branislav + Meandzija, Bob Natale, Juergen Schoenwaelder, Xiaolin Song, and Jeff + Tantsura. + + We thank Barbara Martini, Walter Cerroni, Molka Gharbaoui, and Davide + Borsatti for contributing with their "A multi-level approach to IBN" + PoC demonstration, a first attempt to adopt the intent classification + methodology. + +Contributors + + The following people all contributed to creating this document: + + Contributed significant text: + + Xueyuan Sun + China Telecom + + + Will (Shucheng) Liu + Huawei + + + Contributed text in early draft versions of this document: + + Ying Chen + China Unicom + + + John Strassner + Huawei + + + Weiping Xu + Huawei + + + Richard Meade + Huawei + + +Authors' Addresses + + Chen Li + China Telecom + Xicheng District + No.118 Xizhimennei street + Beijing + 100035 + China + Email: lichen6@chinatelecom.cn + + + Olga Havel + Huawei Technologies + Ireland + Email: olga.havel@huawei.com + + + Adriana Olariu + Huawei Technologies + Ireland + Email: adriana.olariu@huawei.com + + + Pedro Martinez-Julia + NICT + Japan + Email: pedro@nict.go.jp + + + Jeferson Campos Nobre + Federal University of Rio Grande do Sul (UFRGS) + Porto Alegre-RS + Brazil + Email: jcnobre@inf.ufrgs.br + + + Diego R. Lopez + Telefonica I+D + Don Ramon de la Cruz, 82 + 28006 Madrid + Spain + Email: diego.r.lopez@telefonica.com |