[要約] RFC 9316 - Intent Classificationは、ネットワークを操作するための抽象的で高レベルなポリシーであるIntentに焦点を当て、ユーザーがリクエストを入力し、それをネットワーク構成に変換してライフサイクルを管理するためのエンジンを含むIntentベースの管理システムの目的を議論しています。
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).
このドキュメントは、IRTFネットワーク管理研究グループ（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.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のネットワーク管理研究グループのコンセンサスを表しています。IRSGによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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.
意図ベースのネットワークのビジョンは、人間のオペレーターによるネットワークの管理を簡素化することを約束するため、多くの注目を集めています。これは、それを行う方法についての指示を与えることなく、ネットワークで何が起こるべきかを単に指定するだけで行われます。この約束により、多くの研究者主導の活動や通信会社は、この新しいビジョンと多くの標準開発組織（SDO）の研究を開始し、さまざまな意図フレームワークを提案しました。
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.
このドキュメントは、ネットワーク管理研究グループ（NMRG）のコンセンサスを表しています。この文書の対象となる技術の研究開発に積極的に関与している研究グループ（RG）メンバーによって広範囲にレビューされています。IETF製品ではなく、標準でもありません。
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.
* 意図的な表現と認識（[bezahaf21]、[bezahaf19]、[jacobs18]）。一般的な分類を使用すると、提案および調査されているさまざまな形式の意図表現の理解に一貫性があります。
* the orchestration of cognitive autonomous radio access networks (RANs) [Banerjee21] where intents are classified based on their content.
* 認知自律無線アクセスネットワーク（RANS）[Banerjee21]のオーケストレーションでは、コンテンツに基づいて意図が分類されます。
* intent network verification [Tian19], where the authors are working to propose new intent language.
* Intent Network検証[Tian19]。著者が新しい意図言語を提案するために取り組んでいます。
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].
さらに、このドキュメントは、インターネットに基づいた仮想ネットワーク機能（VNF）配置ソリューションを進めるための自己生成された意図ベースのシステム[Bezahaf19]を提案するための基礎として使用されているため、研究コミュニティに非常に関連していることがすでに証明されています。抽象的なネットワークサービス[Leivadeas21]に対応するユーザーの意図プロファイルの定義、意図ベースのネットワークのプロビジョニングにおける既存のソリューションの改善、サービス管理への新しいアプローチ[davoli21]を提案し、ユーザー向けの文法を定義するためのベースのネットワーク（IBN）意図の形でブロックチェーン選択の高レベルの要件を指定する[Padovan20]。同様に、この文書は、インテリジェントな意図に基づいた自律ネットワークのトピックに対処する調査で言及されています[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.
このドキュメントでは、この提案が、ソフトウェア定義のネットワーク /ネットワーク関数仮想化（SDN / NFV）の分野の研究者によって、プロジェクトの範囲を定義するための学術環境[POC-IBN]でどのように成功したかについての例についても説明しています。研究者が扱う特定の問題は、異なる利害関係者に対応するさまざまなレベルで意図の概念を適用する方法です。
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.
ネットワーク運用と管理に関するIEEEコミュニケーションソサエティ技術委員会（IEEE-CNOM）、IRTFネットワーク管理研究グループ、およびIFIP WG6.6は、研究コミュニティが使用するネットワークおよびサービス管理[IFIP-NSM]の分類法を開発しました。ネットワーク管理と操作は、明確に定義されたキーワードセットを通じて研究分野を構築し、ジャーナル、会議、ワークショップへの提出のレビューの質を向上させます。提案された意図分類法は、意図駆動型管理のためのこの分類法の延長として貢献することができます。
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.
IRTF NMRG、Open Networking Foundation（ONF） / Open Network Operating System（ONOS）[ONOS]、European Telecommunications Standards Institute（ETSI） / Experiential Networked Intelligence（ENI）など、いくつかのSDOおよびオープンソースプロジェクト。また、自律的なネットワークを備えたTMFは、宣言的な方法で実行するために一連のネットワーク操作を定義するための意図を提案しています。
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.
最近では、IRTF NMRGは「意図ベースのネットワーク - 概念と定義」[RFC9315]に取り組んでいます。このドキュメントは、「意図」の概念を明確にし、それに関連する機能の概要を提供します。目標は、関連する研究と工学の問題とそのソリューションのさらなる定義を導くために基礎として使用できる用語、概念、および機能の共通と共有の理解に貢献することです。
The present document, together with [RFC9315], aims to become the foundation for future intent-related topic discussions regarding the NMRG.
現在の文書は、[RFC9315]とともに、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.
SDOは通常、意図と意図が何であるかについての独自の方法を指定する独自の方法を思いつきます。さらに、各SDOは、一連の用語と抽象化のレベル、その意図ユーザー、アプリケーションと使用シナリオを定義します。
However, most intent approaches proposed by SDOs share the same features:
ただし、SDOSによって提案されているほとんどの意図的アプローチは、同じ機能を共有しています。
* 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.
* Intentユーザーからネットワーク機能またはネットワークインフラストラクチャを抽象化し、さまざまなプラットフォームに移植できるという意味で、ベンダーの不可知論者でなければなりません。
* 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.
* 意図的な競合を検出して解決できるはずです。これには、たとえば静的（コンパイル時間）競合や動的（実行時）競合などが含まれます。
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].
このドキュメントの焦点は、利害関係者の視点から意図の分類を可能にする基準の定義にあります。IBNに関連する概念と定義は、[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.
このドキュメントは、主にネットワーク意図のコンテキストでの意図に対応しています。ただし、セクション4.4および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.
共通の特性によってのみ意図を完全に区別することは不可能です。その後、概念、用語、意図が続きます。このドキュメントは、ソリューション、意図ユーザー、意図タイプなどのさまざまな次元に関する分類を通じて、さまざまな利害関係者にとって意図が表すものを明確にします。この分類は、すべての参加者間の共通の理解を保証し、個々のプロジェクトの範囲と優先順位、概念実証（POC）、研究イニシアチブ、またはオープンソースプロジェクトを決定するために使用されます。
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.
このドキュメントの意図分類の範囲には、ソリューション、意図ユーザー、および意図タイプが含まれます。初期分類テーブルは、この範囲に従って作成されます。提示された方法論は、さまざまなソリューション、意図的なユーザー、または意図タイプを追加または削除して、将来のシナリオ、アプリケーション、またはドメインに対応することにより、分類テーブルを更新するために使用できます。
AI: Artificial Intelligence
AI：人工知能
CE: Customer Equipment
CE：顧客機器
CFS: Customer Facing Service
CFS：顧客に対応するサービス
CLI: Command-Line Interface
CLI：コマンドラインインターフェイス
DB: Database
DB：データベース
DC: Data Center
DC：データセンター
ECA: Event Condition Action
ECA：イベント状態アクション
GBP: Group-Based Policy
GBP：グループベースのポリシー
GPU: Graphics Processing Unit
GPU：グラフィックプロセッシングユニット
IBN: Intent-Based Network
IBN：意図ベースのネットワーク
NFV: Network Function Virtualization
NFV：ネットワーク機能仮想化
O&M: OAM & Maintenance
O＆M：OAM＆メンテナンス
ONF: Open Networking Foundation
ONF：Open Networking Foundation
ONOS: Open Network Operating System
ONOS：オープンネットワークオペレーティングシステム
PNF: Physical Network Function
PNF：物理ネットワーク機能
QoE: Quality of Experience
QOE：経験の質
RFS: Resource Facing Service
RFS：リソース対応サービス
SDO: Standards Development Organization
SDO：標準開発組織
SD-WAN: Software-Defined Wide-Area Network
SD-WAN：ソフトウェア定義の広いエリアネットワーク
SLA: Service Level Agreement
SLA：サービスレベル契約
SUPA: Simplified Use of Policy Abstractions
SUPA：ポリシーの抽象化の簡略化
VM: Virtual Machine
VM：仮想マシン
VNF: Virtual Network Function
VNF：仮想ネットワーク機能
A common and shared understanding of terms and definitions related to IBN is provided in [RFC9315] as follows:
次のように、[RFC9315]にIBNに関連する用語と定義の一般的かつ共有された理解が提供されています。
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.
Intentベースのネットワーク：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.
Intentユーザー：意図ベースの管理システムに意図要求を定義および発行するユーザー。
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.
意図範囲、意図ネットワークスコープ、意図の抽象化、意図抽象化、意図のライフサイクルなど、このドキュメントに関連するその他の定義は、セクション5で利用できます。
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.
意図の分類を促進するさまざまな意図要件を理解するには、まず異なる意図ユーザーにとって意図の意味を理解する必要があります。
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.
「意図」という用語は、さまざまな目的で業界で非常に広く使用されています。その使用は、セクション1で述べたSDO共有原則と一致しない場合があります。
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.
異なる利害関係者は、ネットワークの異なる視点を持っています。したがって、それらは異なる意図要件を持っています。それらの意図は、技術的、非技術的、抽象的、または技術固有の場合があります。したがって、さまざまなソリューションと意図的なユーザーに対する意図について、業界や学術コミュニティで議論を開始することが重要です。また、より多くの聴衆が理解できるいくつかの意図的なカテゴリ/分類を提案しようとすることも不可欠です。これにより、意図インターフェイス、ドメイン固有の言語、およびモデルを定義するのに役立ちます。
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.
意図タイプは、異なる要件をプロファイルするために必要なすべての側面によって定義されます。ただし、クラスター化された分類を容易にするために、ソリューションと意図ユーザーの2つの側面に焦点を当てることができます。ソリューションとインテントユーザーごとに要件を簡単にグループ化できるため、意図を分類するための主要なキーと見なすことができます。
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
表1：意図的なソリューションと意図ユーザー
These intent solutions and intent users represent a starting point for the classification and are expendable through the methodology presented in Section 6.1.
これらの意図ソリューションと意図ユーザーは、分類の出発点を表し、セクション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.
* たとえば、キャリアネットワークシナリオの場合、顧客/サブスクライバーが高解像度のビデオを視聴したい場合、ビデオ画像を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%.
* DCネットワークシナリオの場合、管理者はロードバランシングなどの独自の明確なネットワーク意図を持っています。NFVサービスチェーンが必要なすべてのトラフィックフローについて、VNFノード /コンテナの最大負荷を50％未満に制限し、ネットワークリンクの最大負荷を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.
* エンタープライズネットワークシナリオの場合、ビデオ会議を開催する場合、複数のリモートアクセスが必要です。ネットワーク管理者からの意図の例は次のとおりです。このアプリケーションのすべてのエンドユーザーの場合、すべてのリモートテレプレゼンターのホログラムオブジェクトの到着時間は、各会話セッションの宛先ビューアーに到達するために50ミリ秒以内に同期する必要があります。
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:
現在のネットワークAPIとCLIは、ネットワークによって公開される低レベルの概念と高度に統合されているため、複雑すぎます。顧客、アプリケーション開発者、およびエンドユーザーは、IPアドレス、VLAN、サブネット、またはポートを設定する必要はありませんが、オペレーターはさらに技術的およびネットワークの可視性の両方を持ちたい場合があります。すべての利害関係者は、次のようなよりシンプルなインターフェイスの恩恵を受けるでしょう。
* request gold VPN service between sites A, B, and C
* サイトa、b、およびcの間のゴールドVPNサービスをリクエストする
* 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)
* 付加価値サービス（オペレーター）にシンプルな顧客APIを提供する
* 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
* 手動のアクションやメンテナンスなしに、意図と自動化のみに基づいてネットワークサービスを稼働させ、実行してください
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
- 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
- DC構成、VMS、DBサーバー、アプリケーションサーバー用
- for communication between VMs
- VM間の通信
* 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.
- セキュリティ、QoS、アプリケーションポリシー、トラフィックステアリングなど。
- 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.
前述のすべてのタイプに言及することが重要であり、サブタイプは他の意図に影響を与える可能性があります。たとえば、運用上のタスク意図は、他の多くの意図を変更できます。タスク自体は短命ですが、他の意図の変更はライフサイクルに影響を与えるため、これらの変更は引き続き継続的に監視され、自己修正/最適化されている必要があります。
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.
意図を使用して、ターゲット（コマンドの発行によく似ている）または適切な場合（例：イベントに応じて）いつでも操作することができます。どちらの場合でも、意図には、次のサブセクションで説明されているように、その目的をさらに整理するのに役立つ多くの行動があります。
The modeling of intents can be abstracted using the following three-tuple:
意図のモデリングは、次の3タプルを使用して抽象化できます。
{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.
メタデータは、戦略テンプレートを介して3タプルの各要素に添付でき、意図をどのように使用するか、どのように動作するかを説明し、考慮に入れる必要がある運用依存関係を処方するために使用できます。
Although different intent categories share the same abstracted intent model, each category will have its own specific context, capabilities, and constraints.
異なる意図カテゴリは同じ抽象化された意図モデルを共有していますが、各カテゴリには独自の特定のコンテキスト、機能、制約があります。
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.
セクション4.2の紹介で展開すると、意図のユーザータイプは、意図要求を定義および発行する意図ユーザーを表します。意図ソリューションに応じて、特定の意図ユーザーがいます。意図的なユーザーの例は、顧客、ネットワークオペレーター、サービスオペレーター、エンタープライズ管理者、クラウド管理者、アンダーレイネットワーク管理者、またはアプリケーション開発者です。
* 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.
* アプリケーション開発者は、アプリケーションとプログラミング環境によって定義された一連の抽象化で動作します。たとえば、多くのアプリケーション開発者は、オブジェクト（VPNなど）の観点から考えています。これはアプリケーション開発者にとって理にかなっていますが、ほとんどのネットワークデバイスにはVPNオブジェクト自体がありません。むしろ、VPNは、VPNを構成する他のデバイスの構成ステートメントと協力して、そのデバイスの構成ステートメントのセットを通じて形成されます。したがって、アプリケーション開発者のビューは、ネットワークが提供するサービスと一致しますが、他の意図ユーザーの他のビューに直接対応しない場合があります。
* Network operators may have the knowledge of the underlying network. However, they may not understand the details of the applications and services of customers.
* ネットワークオペレーターは、基礎となるネットワークの知識を持っている場合があります。ただし、顧客のアプリケーションとサービスの詳細を理解していない場合があります。
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
* QoSスコープ、意図がネットワークのQOS特性を指定するとき
These intent scopes are expendable through the methodology presented in Section 6.1.
これらの意図スコープは、セクション6.1に示されている方法論を通じて消耗します。
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.
したがって、宣言的ポリシーの分野で知られている意図ネットワークスコープ、またはポリシーターゲットは、VNFまたはPNF、物理ネットワーク要素、キャンパスネットワーク、SD-WAN、RANS、クラウドエッジ、クラウドコア、ブランチなどを表します。
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.
[RFC9315]で提供されている「意図」の定義に従って、下位レベルの意図は意図としての資格とは見なされません。ただし、この分類を維持して、意図の低レベルの抽象化を必要とするか実装するPOC /デモ /ユースケースを特定しました。
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.
永続的：意図にはライフサイクル管理があります。意図が正常にアクティブ化され、展開されると、システムは、無効化または削除されるまで、関連するすべての意図をアクティブに保ちます。
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:
自律運転ネットワーク[TMF-Auto]のさまざまな段階では、意図は異なります。ソリューション全体の自律ネットワークレベルに応じて、意図の要件とタイプが異なる場合があります。たとえば、より低いレベルでは、顧客の意図は次のとおりです。
* 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.
* AIを使用して自己保証。
Typical examples of autonomous driving networks level 0 to 5 are shown below.
自律運転ネットワークレベル0〜5の典型的な例を以下に示します。
Level 0 - Traditional manual network: O&M personnel manually control the network and obtain network alarms and logs.
レベル0-従来のマニュアルネットワーク：O＆M担当者は、ネットワークを手動で制御し、ネットワークアラームとログを取得します。
- 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.
レベル1-部分的に自動化されたネットワーク：自動化されたスクリプトは、サービスプロビジョニング、ネットワーク展開、およびメンテナンスを自動化するために使用されます。ネットワークは、ネットワークのステータスと意思決定の提案に対する浅い認識を提供します。
- 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.
レベル2-自動ネットワーク：これには、ほとんどのサービスプロビジョニング、ネットワーク展開、およびネットワークステータスとローカルマシンの意思決定の包括的な認識のメンテナンスの自動化が必要です。
- 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.
レベル3-自己最適化ネットワーク：これには、ネットワークステータスと自動ネットワーク制御、ネットワークの意図ユーザーの要件を満たすことを深く認識します。
- 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.
レベル4-部分的な自律ネットワーク：限られた環境では、人々は意思決定に参加する必要がなく、ネットワークは自分自身を調整できます。
- Intent based on limited AI
- 限られたAIに基づく意図
Level 5 - Autonomous network: In different network environments and network conditions, the network can automatically adapt and adjust to meet people's intentions.
レベル5-自律ネットワーク：さまざまなネットワーク環境とネットワーク条件では、ネットワークは自動的に適応して調整して、人々の意図を満たすことができます。
- Intent based on AI
- AIに基づく意図
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.
このドキュメントの3つの分類は、3つの繰り返しを通じてゼロから提案されています。各意図ソリューションについて、特定の意図ユーザーと意図タイプを特定しました。次に、意図の範囲、ネットワークスコープ、抽象化、ライフサイクル要件をさらに特定しました。
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.
これらの分類と生成されたテーブルは、簡単に拡張できます。たとえば、DC意図ソリューションの場合、新しいカテゴリ「リソーススコープ」が識別され、それに応じて分類テーブルが拡張されました。
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のサブセクションでは、提案された意図分類方法論、3つの意図ソリューションの連結意図分類法、および導出された3つの異なる意図ソリューション（キャリアネットワーク、データセンター、エンタープライズなど）の意図分類の具体的な例を紹介します。提案された方法論を使用し、POC、デモ、研究プロジェクト、または将来の文書に記入することができます。
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
図1：意図分類方法論
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).
1. 意図ソリューション（キャリア、エンタープライズ、データセンターなど）を特定するための入力としてソリューション知識に提供された情報を受け取ります。意図ソリューションは既存の分類に対してレビューされ、存在する場合は使用するか、そこに追加されていない場合は使用できます。必要ない場合は、分類（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).
2. 意図のユーザータイプ（顧客、ネットワークオペレーター、サービスオペレーターなど）を特定します。既存の意図分類を確認します。次に、存在する場合はIntentユーザータイプを使用します。そこにない場合は追加するか、必要でない場合は削除します（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).
3. 意図の種類を特定します（たとえば、ネットワーク意図、カスタマーサービスの意図）。既存の分類を確認し、意図タイプ（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).
4. ソリューションの知識に基づいて、意図のスコープ（接続性、アプリケーションなど）を特定します。次に、既存の分類を確認します。識別された意図スコープ（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).
5. ネットワークスコープ（キャンパス、ラジオアクセスなど）を特定します。次に、既存の分類を確認します。識別されたネットワークスコープ（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).
6. 抽象化を特定します（たとえば、技術、非技術）。次に、既存の分類を確認し、抽象化（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).
7. ライフサイクルの要件を特定します（例：持続性、一時的）。次に、既存の分類を確認します。ライフサイクル要件（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.
8. 新しいカテゴリを特定します。新しく識別されたカテゴリを使用して追加します。新しいカテゴリは、新しいドメインまたはアプリケーションが出現するか、現在の方法論にはリストされていない新しいドメインまたは懸念事項（プライバシー、コンプライアンスなど）が生じるように識別できます。
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.
図2の意図スコープカテゴリは、キャリア、DC、およびエンタープライズソリューションの間で共有されています。セクション6.3.2および6.4.2の略語（CX）は、次の表の列のタイトルとしてフィッティングの範囲を導入します。
+--------------------------------+
+-->|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
図2：意図的な分類法
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.
このセクションでは、図1の手順1、2、および3について説明します。次の表は、さまざまな意図ユーザーの説明を使用して、キャリアソリューションと意図タイプの意図ユーザーを説明しています。
+=============+=============+=======================================+
| 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
表2：キャリアソリューションの意図分類
This subsection addresses steps 4 to 7 from Figure 1. The following are the proposed categories:
このサブセクションは、図1からの手順4〜7に対応しています。以下は、提案されているカテゴリです。
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).
抽象化（ABS）：C1 =テクニカル（技術的なフィードバック付き）、C2 =非技術（技術的なフィードバックなし）（セクション5.2を参照）。
Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient (short lived)
ライフサイクル（L-C）：C1 =永続的（フルライフサイクル）、C2 =一時的（短命）
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.
このセクションには、「IBNへのマルチレベルアプローチ」POCデモンストレーション[POC-IBN]で導入された意図を分類するために、セクション6.1で説明した方法論をどのように使用できるかの例が含まれています。このPOCは、SDN/NFVの分野で研究を実施する学者が主導しており、彼らが対処している特定の問題は、異なる利害関係者に対応する異なるレベルでの意図概念の適用です。この研究作業では、スライスの意図とサービスチェーンの意図という2種類の意図を検討しました。
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.
このPOC [POC-IBN]では、スライスの意図は、2種類のコンポーネントを備えたネットワークスライスのリクエストを表現します：一連のトップレイヤー仮想関数とL2/ L3 VNFの仮想スイッチおよび/またはルーターのセット。サービスチェーンの意図は、L4-L7仮想関数で実行されている一連のサービスコンポーネントを介して運用されるサービスのリクエストを表します。
Following the intent classification methodology described step by step in Section 6.1, the following can be derived:
セクション6.1で段階的に説明されている意図分類方法に従って、以下を導き出すことができます。
1. The intent solution for both intents is carrier network.
1. 両方の意図の意図ソリューションは、キャリアネットワークです。
2. The intent user type is network operator for the slice intent and service operator for the service chain intent.
2. 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.
3. 意図のタイプは、スライスの意図に対するネットワークサービスの意図と、サービスチェーンの意図に対するカスタマーサービスの意図です。
4. The intent scopes are connectivity and application.
4. 意図のスコープは、接続とアプリケーションです。
5. The network scope is VNF, cloud edge, and cloud core.
5. ネットワークスコープは、VNF、Cloud Edge、およびCloud Coreです。
6. The abstractions are with technical feedback for the slice intent and without technical feedback for the service chain intent.
6. 抽象化は、スライスの意図のための技術的なフィードバックと、サービスチェーンの意図のための技術的なフィードバックなしです。
7. The life cycle is persistent.
7. ライフサイクルは永続的です。
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.
次の表は、この情報を表形式で表現する方法を示しています。表の「x」は、スライスの意図を指します。表の「Y」は、サービスチェーンの意図を指します。
+==========+===========+===========+=====+=================+=====+=====+
|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
図3：キャリアソリューションの意図分類例
The following table describes the intent users in DC network solutions and intent types with their descriptions for different intent users.
次の表では、DCネットワークソリューションの意図ユーザーと、さまざまな意図ユーザー向けの説明を使用して、意図タイプを説明しています。
+===============+=============+====================================+
| 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
表3：データセンターネットワークソリューションの意図分類
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
ネットワークドメイン：DCネットワーク
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).
抽象化（ABS）：C1 =テクニカル（技術的なフィードバック付き）、C2 =非技術（技術的なフィードバックなし）（セクション5.2を参照）。
Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient (short lived)
ライフサイクル（L-C）：C1 =永続的（フルライフサイクル）、C2 =一時的（短命）
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.
このセクションでは、セクション6.1で説明されている方法論を、研究コミュニティが意図を分類するためにどのように使用できるかについての例を示しています。セクション6.3.3で述べたように、このドキュメントで提案されている分類の使用が成功したことは、「IBNへのマルチレベルアプローチ」[POC-IBN]というタイトルのPOCデモンストレーションで紹介されています。POCは、SDN/NFVの分野で研究を実施する学者が主導しています。彼らが対処している特定の問題は、異なる利害関係者に対応するさまざまなレベルでの意図概念の適用です。
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.
彼らの研究作業では、彼らはスライスの意図とサービスチェーンの意図の2つのタイプの意図を検討しました。データセンターソリューションの場合、スライスの意図のみが関連します。
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.
セクション6.3.3ですでに述べたように、スライス意図は、2種類のコンポーネントを備えたネットワークスライスのリクエストを表現します：一連のトップレイヤー仮想関数とL2/L3 VNFの仮想スイッチおよび/またはルーターのセット。
Following the intent classification methodology described step by step in Section 6.1, we identify the following:
セクション6.1で段階的に説明されている意図分類方法に従って、以下を特定します。
1. The intent solution is data center.
1. 意図ソリューションはデータセンターです。
2. The intent user type is the cloud administrator for the slice intent and service chain intent.
2. 意図のユーザータイプは、スライスの意図とサービスチェーンの意図のクラウド管理者です。
3. The type of intent is a cloud management intent for the slice intent.
3. 意図のタイプは、スライスの意図に対するクラウド管理の意図です。
4. The intent scopes are connectivity and application.
4. 意図のスコープは、接続とアプリケーションです。
5. The network scope is logical; the resource scope is virtual.
5. ネットワークスコープは論理的です。リソーススコープは仮想です。
6. The abstractions are with technical feedback for the slice intent.
6. 抽象化は、スライスの意図のための技術的なフィードバックを使用しています。
7. The life cycle is persistent.
7. ライフサイクルは永続的です。
The following table shows how to represent this information in a tabular form; the "X" in the table refers to the slice intent.
次の表は、この情報を表形式で表現する方法を示しています。表の「x」は、スライスの意図を指します。
+===========+=============+=================+=====+=====+=====+=====+
|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
図4：データセンターネットワークソリューションの意図分類の例
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
表4：エンタープライズソリューションの意図分類
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)
抽象化（ABS）：C1 =テクニカル（技術的なフィードバック付き）、C2 =非技術（技術的なフィードバックなし）（セクション5.2を参照）
Life cycle (L-C): C1=Persistent (full life cycle), C2=Transient (short lived)
ライフサイクル（L-C）：C1 =永続的（フルライフサイクル）、C2 =一時的（短命）
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
図5：エンタープライズソリューションの意図カテゴリ
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.
このドキュメントは、RGの目標と整合しており、意図的な分類方法と分類法を提案することにより、意図ベースのネットワーキングの調査をサポートしています。それは、意図分類アプローチの提案を通じて、さまざまな利害関係者に意図が表すものを明確にし、すべての参加者の間に共通の理解が存在するようにします。これは、提案された意図分類法とともに、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.
研究コミュニティにおけるこの意図分類文書の利点は、文書の概念が異なる利害関係者に対応するさまざまなレベルで適用されているPOC実装[POC-IBN]を通じて実証されています。
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.
このドキュメントは、セキュリティとプライバシーを意図範囲のカテゴリとして識別します。意図は、セキュリティの意図とプライバシーの意図のみである可能性があります。また、セキュリティは、接続性、アプリケーション、およびQoSスコープを含む意図に組み込むことができます。
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].
これらのセキュリティの意図の詳細については、アーキテクチャ、機能、ユーザーの意図、モデルを指定する将来のドキュメントで説明します。[RFC9315]のセクション9では、意図ベースの全体的なシステムのセキュリティに関する考慮事項の分析を提供しています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[Banerjee21] Banerjee, A., Mwanje, S., and G. Carle, "Contradiction Management in Intent-driven Cognitive Autonomous RAN", September 2021.
[Banerjee21] Banerjee、A.、Mwanje、S。、およびG. Carle、「意図駆動型認知自律RANにおける矛盾管理」、2021年9月。
[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>.
[Bezahaf19] Bezahaf、M.、Hernandez、M.、Bardwell、L.、Davies、E.、Broadbent、M.、King、D。、およびD. Hutchison、「自己生成された意図ベースのシステム」、10th International将来のネットワークに関する会議（NOF）、DOI 10.1109/NOF47743.2019.9015045、2019年10月、<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>.
[Bezahaf21] Bezahaf、M.、Davies、E.、Rotsos、C。、およびN. Race、「すべての意図と目的に向けて：柔軟な意図表現に向けて」、IEEE第7回ネットワークソフトウェア化に関する国際会議（Netsoft）、DOI 10.1109/Netsoft51509.2021.9492554、2021年7月、<https://doi.org/10.1109/Netsoft51509.2021.949254>。
[Davoli21] Davoli, G., "Programmability and Management of Software-Defined Network Infrastructures", 2021.
[Davoli21] Davoli、G。、「ソフトウェア定義のネットワークインフラストラクチャのプログラマ性と管理」、2021。
[IFIP-NSM] IFIP, "Network and Service Management Taxonomy", <https://www.simpleweb.org/ifip/taxonomy.html>.
[ifip-nsm] ifip、「ネットワークおよびサービス管理分類法」、<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>.
[Jacobs18] Jacobs、A.、Pfitscher、R.、Ferreira、R.、およびL. Granville、「自動運転ネットワークのネットワーク意図の精製」、自動運転ネットワークに関する午後のワークショップの議事録（SelfDN）、DOI 10.1145/3229584.3229590、2018年8月、<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>.
[Leivadeas21] Leivadeas、A。and M. Falkner、「VNF配置問題：マルチテナントの意図ベースのネットワーキングアプローチ」、クラウド、インターネット、ネットワークおよびワークショップ（ICIN）のイノベーションに関する第24回会議（ICIN）、DOI 10.1109/ICIN51074.2021.9385555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555、2021年3月、<https://doi.org/10.1109/icin51074.2021.938553>。
[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>.
[Mehmood21] Mehmood、K.、Kralevska、K。、およびD. Palma、「将来のネットワークにおける意図駆動型の自律ネットワークとサービス管理：構造化された文献レビュー」、DOI 10.48550/arxiv.2108.04560、8月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>.
[ONF] Open Networking Foundation、「Intent NBI-定義と原則」、2016年10月、<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/>.
[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.
[Padovan20] Padovan、S。、「ブロックチェーン意図管理システムの設計と実装」、2020年11月。
[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>.
[Poc-Ibn] Martini、B.、Cerroni、W.、Gharbaoui、M。、およびD. Borsatti、「IBNへのマルチレベルのアプローチ」、IETF 108 Hackathon Report、2020年7月、<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>.
[RFC9315] CLEMM、A.、Ciavaglia、L.、Granville、L。Z。、およびJ. Tantsura、「Intent Based Networking-概念と定義」、RFC 9315、DOI 10.17487/RFC9315、2022年10月、<.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>.
[Szilagyi21]Szilágyi、P。、「I2BN：Intelligent Intent Based Networks」、Journal of ICT Standardization、Volume 9、Issue 2、DOI 10.13052/jicts2245-800x.926、2021年6月、<https://doi.org/10.130522/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>.
[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。、およびB. Zhao、「意図言語でネットワーク内のACL構成を安全かつ自動的に更新する」、Sigcomm '19：ACM特別利益グループの議事録データ通信、DOI 10.1145/3341302.3342088、2019年8月、<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.
[TMF-AUTO] Boasman-Patel、A.、Sun、D.、Wang、Y.、Maitre、C.、Domingos、J.、Troullides、Y.、Mas、I.、Traver、G。、およびG.Lupo、「自律ネットワーク：電気通信業界向けのデジタル変革の力」、2019年5月。
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.
この文書は、アルファベット順にリストされている以下のメンバーによって提供されたレビュー、提案、コメント、および提案されたテキストの恩恵を受けています：Mehdi Bezahaf、Brian E. Carpenter、Laurent Ciavaglia、Benoit Claise、Alexander Clemm、Yehia Elkhatib、Jerome Francoisグティエレス、ダニエル・キング、ブラニスラフ・ミーンズジャ、ボブ・ナタール、ジュエルゲン・シェーンワエルダー、Xiaolinの歌、ジェフ・タンツラ。
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.
Barbara Martini、Walter Cerroni、Molka Gharbaoui、およびDavide Borsattiに感謝します。「IBNへのマルチレベルのアプローチ」POCデモンストレーション、意図分類方法を採用する最初の試みです。
Contributors
貢献者
The following people all contributed to creating this document:
次の人々はすべて、このドキュメントの作成に貢献しました。
Contributed significant text:
重要なテキストを提供しました：
Xueyuan Sun China Telecom
Xueyuan Sun China Telecom
Will (Shucheng) Liu Huawei
ウィル（shucheng）liu huawei
Contributed text in early draft versions of this document:
このドキュメントの初期ドラフトバージョンに貢献したテキスト：
Ying Chen China Unicom
Ying Chen China Unicom
John Strassner Huawei
ジョン・ストラスナー・フアウェイ
Weiping Xu Huawei
xu huaweiをweiping
Richard Meade Huawei
リチャード・ミード・フアウェイ
Authors' Addresses
著者のアドレス
Chen Li China Telecom Xicheng District No.118 Xizhimennei street Beijing 100035 China Email: lichen6@chinatelecom.cn
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
Olga Havel Huawei Technologies Ireland Email：olga.havel@huawei.com
Adriana Olariu Huawei Technologies Ireland Email: adriana.olariu@huawei.com
Adriana olaliu Huawei Technologies Irelandメール：Adriana.olariu@huawei.com
Pedro Martinez-Julia NICT Japan Email: pedro@nict.go.jp
Pedro Martinez-Julia Nict Japaneail：pedro@nict.go.jp
Jeferson Campos Nobre Federal University of Rio Grande do Sul (UFRGS) Porto Alegre-RS Brazil Email: jcnobre@inf.ufrgs.br
ジェファーソン・カンポス・ノブレ・フェデラル大学リオ・グランデ・ドゥル（UFRGS）ポルト・アレグレ・RS・ブラジル・メール：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
ディエゴ・R・ロペス・テレフォニカI Dドン・ラモン・デ・ラ・クルス、82 28006マドリード・スペインメール：diego.R.Lopez@telefonica.com