summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9316.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc9316.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc9316.txt')
-rw-r--r--doc/rfc/rfc9316.txt1941
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