[要約] RFC 9315 は、Intent-Based Networking の概念と定義を明確化し、業界全体で共通の理解を促進することを目的としています。
Internet Research Task Force (IRTF) A. Clemm
Request for Comments: 9315 Futurewei
Category: Informational L. Ciavaglia
ISSN: 2070-1721 Nokia
L. Z. Granville
Federal University of Rio Grande do Sul (UFRGS)
J. Tantsura
Microsoft
October 2022
Intent-Based Networking - Concepts and Definitions
意図ベースのネットワーキング - 概念と定義
Abstract
概要
Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." 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.
意図と意図ベースのネットワーキングは、業界を席巻しています。同時に、意図ベースのネットワーキングに関連する用語は、多くの場合、「ポリシー」などの他の概念と重複して混同されていることが多い、ゆるく一致していないことがよくあります。このドキュメントは、「意図」の概念を明確にし、それに関連する機能の概要を提供します。目標は、関連する研究と工学の問題とそのソリューションのさらなる定義を導くために基礎として使用できる用語、概念、および機能の共通と共有の理解に貢献することです。
This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes.
このドキュメントは、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/rfc9315.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9315で取得できます。
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
2. Definitions and Acronyms
3. Introduction of Concepts
3.1. Intent and Intent-Based Management
3.2. Related Concepts
3.2.1. Service Models
3.2.2. Policy and Policy-Based Network Management
3.2.3. Distinguishing between Intent, Policy, and Service
Models
4. Principles
5. Intent-Based Networking - Functionality
5.1. Intent Fulfillment
5.1.1. Intent Ingestion and Interaction with Users
5.1.2. Intent Translation
5.1.3. Intent Orchestration
5.2. Intent Assurance
5.2.1. Monitoring
5.2.2. Intent Compliance Assessment
5.2.3. Intent Compliance Actions
5.2.4. Abstraction, Aggregation, Reporting
6. Life Cycle
7. Additional Considerations
8. IANA Considerations
9. Security Considerations
10. Informative References
Acknowledgments
Authors' Addresses
This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the RG, receiving reviews and explicit support from many participants. It is published for informational purposes.
このドキュメントは、IRTFネットワーク管理研究グループ（NMRG）の製品です。これは、RGのコンセンサスを反映しており、多くの参加者からレビューと明示的なサポートを受けています。情報目的で公開されています。
In the past, interest regarding management and operations in the IETF has focused on individual network and device features. Standardization emphasis has generally been put on management instrumentation that needed to be provided to a networking device. A prime example of this is SNMP-based management [RFC3411] and the 200+ MIBs that have been defined by the IETF over the years. More recent examples include YANG data model definitions [RFC7950] for aspects such as interface configuration, Access Control List (ACL) configuration, and Syslog configuration.
過去には、IETFの管理と運用に関する関心は、個々のネットワークとデバイスの機能に焦点を当てています。一般に、ネットワークデバイスに提供する必要がある管理手段に標準化の強調が課されてきました。この例は、SNMPベースの管理[RFC3411]と、長年にわたってIETFによって定義されている200 MIBです。最近の例には、インターフェイス構成、アクセス制御リスト（ACL）構成、syslog構成などの側面のYangデータモデル定義[RFC7950]が含まれます。
There is a clear sense and reality that managing networks by configuring myriads of "nerd knobs" on a device-by-device basis is no longer an option in modern network environments. Significant challenges arise with keeping device configurations not only consistent across a network but also consistent with the needs of services and service features they are supposed to enable. Additional challenges arise with regard to being able to rapidly adapt the network as needed and to be able to do so at scale. At the same time, operations need to be streamlined and automated wherever possible to not only lower operational expenses but also allow for rapid reconfiguration of networks at sub-second time scales and to ensure that networks are delivering their functionality as expected. Among other things, this requires the ability to consume operational data, perform analytics, and dynamically take actions in a way that is aware of context as well as intended outcomes at near real-time speeds.
デバイスごとに「オタクノブ」をデバイスごとに構成することにより、ネットワークを管理することは、最新のネットワーク環境ではもはやオプションではないという明確な感覚と現実があります。デバイスの構成をネットワーク全体で一貫しているだけでなく、有効にするはずのサービスやサービス機能のニーズと一致することにも大きな課題が生じます。必要に応じてネットワークを迅速に適応させ、大規模に行うことができることに関して、追加の課題が生じます。同時に、可能な限り運用費用を削減するだけでなく、ネットワークの迅速な再構成を許可し、ネットワークが予想通り機能を提供していることを保証するために、可能な限り合理化および自動化する必要があります。とりわけ、これには運用データを消費し、分析を実行し、コンテキストを認識する方法で動的にアクションを実行する能力が必要です。
Accordingly, the IETF has begun to address end-to-end management aspects that go beyond the realm of individual devices in isolation. Examples include the definition of YANG models for network topology [RFC8345] or the introduction of service models used by service orchestration systems and controllers [RFC8309]. Much of the interest has been fueled by the discussion about how to manage autonomic networks as discussed in the ANIMA Working Group. Autonomic networks are driven by the desire to lower operational expenses and make the management of the network as a whole more straightforward, putting it at odds with the need to manage the network one device and one feature at a time. However, while autonomic networks are intended to exhibit "self-management" properties, they still require input from an operator or outside system to provide operational guidance and information about the goals, purposes, and service instances that the network is to serve.
したがって、IETFは、個々のデバイスの領域を超えて単独で進むエンドツーエンドの管理の側面に対処し始めています。例には、ネットワークトポロジのYangモデルの定義[RFC8345]またはサービスオーケストレーションシステムとコントローラー[RFC8309]が使用するサービスモデルの導入が含まれます。関心の多くは、Animaワーキンググループで議論されているように、自律的なネットワークを管理する方法についての議論によって支えられています。自律的なネットワークは、運用費用を削減し、ネットワークの管理をより簡単にしたいという要望によって推進され、1つのデバイスと1つの機能を一度に管理する必要性と対立します。ただし、自律的なネットワークは「自己管理」プロパティを示すことを目的としていますが、ネットワークがサービスを提供する目標、目的、およびサービスインスタンスに関する運用ガイダンスと情報を提供するために、オペレーターまたは外部システムからの入力が必要です。
This input and operational guidance are commonly referred to as "intent," and a network that allows network operators to provide their input using intent is referred to as an "Intent-Based Network" (IBN), while a system that helps implement intent is referred to as an "Intent-Based System" (IBS). Those systems can manifest themselves in a number of ways -- for example, as a controller or management system that is implemented as an application that runs on a server or set of servers, or as a set of functions that are distributed across a network and that collectively perform their intent-based functionality.
この入力および運用ガイダンスは一般に「意図」と呼ばれ、ネットワークオペレーターが意図を使用して入力を提供できるようにするネットワークは「意図ベースのネットワーク」（IBN）と呼ばれ、意図の実装を支援するシステムは「意図ベースのシステム」（IBS）と呼ばれます。これらのシステムは、たとえばサーバーまたはサーバーのセットで実行されるアプリケーションとして実装されているコントローラーまたは管理システムとして、またはネットワーク全体に配布される関数のセットとして、さまざまな方法で自分自身を現れることができます。これは、意図ベースの機能を集合的に実行します。
However, intent is about more than just enabling a form of operator interaction with the network that involves higher-layer abstractions. It is also about the ability to let operators focus on what they want their desired outcomes to be while leaving details to the IBN (respectively IBS) about how those outcomes would be achieved. Focusing on the outcome enables much greater operational efficiency and flexibility at greater scale, in shorter time scales, and with less dependency on human activities (and therefore less possibility for mistakes). This also makes Intent-Based Networking an ideal candidate for artificial intelligence techniques that can bring about the next level of network automation [CLEMM20].
ただし、意図は、より高い層の抽象化を伴うネットワークとのオペレーターの相互作用の形を可能にするだけではありません。また、オペレーターが、それらの結果がどのように達成されるかについてのIBN（それぞれIBS）に詳細を残しながら、希望する結果に焦点を合わせる能力についてです。結果に焦点を当てることにより、より大きなスケールで、より短い時間スケールでより大きなスケールでより大きな運用効率と柔軟性を高めることができ、人間の活動への依存度が低くなります（したがって、間違いの可能性は少なくなります）。これにより、意図ベースのネットワーキングは、次のレベルのネットワークオートメーション[CLEMM20]をもたらすことができる人工知能技術の理想的な候補になります。
This vision has since caught on with the industry, leading to a significant number of solutions that offer Intent-Based Management that promise network providers to manage networks holistically at a higher level of abstraction and as a system that happens to consist of interconnected components as opposed to a set of independent devices (that happen to be interconnected). Those offerings include IBNs and IBSs (offering a full life cycle of intent), Software-Defined Network (SDN) controllers (offering a single point of control and administration for a network), and network management and Operations Support Systems (OSSs).
このビジョンはその後、業界に巻き込まれており、ネットワークプロバイダーがより高いレベルの抽象化でネットワークを総合的に管理することを約束する意図ベースの管理を提供するかなりの数のソリューションにつながりました。独立したデバイスのセット（たまたま相互接続されています）。これらの製品には、IBNとIBSS（意図の完全なライフサイクルを提供）、ソフトウェア定義ネットワーク（SDN）コントローラー（ネットワークに単一の制御と管理のポイントを提供）、ネットワーク管理および運用サポートシステム（OSS）が含まれます。
It has been recognized for a long time that comprehensive management solutions cannot operate only at the level of individual devices and low-level configurations. In this sense, the vision of intent is not entirely new. In the past, ITU-T's model of a Telecommunications Management Network (TMN) introduced a set of management layers that defined a management hierarchy consisting of network element, network, service, and business management [M3010]. High-level operational objectives would propagate in a top-down fashion from upper to lower layers. The associated abstraction hierarchy was crucial to decompose management complexity into separate areas of concern. This abstraction hierarchy was accompanied by an information hierarchy that concerned itself at the lowest level with device-specific information, but that would, at higher layers, include, for example, end-to-end service instances. Similarly, the concept of Policy-Based Network Management (PBNM) has, for a long time, touted the ability to allow users to manage networks by specifying high-level management policies, with policy systems automatically "rendering" those policies, i.e., breaking them down into low-level configurations and control logic.
包括的な管理ソリューションは、個々のデバイスと低レベルの構成のレベルでのみ動作できないことが長い間認識されてきました。この意味で、意図のビジョンはまったく新しいものではありません。過去に、電気通信管理ネットワーク（TMN）のITU-Tのモデルは、ネットワーク要素、ネットワーク、サービス、およびビジネス管理[M3010]で構成される管理階層を定義する一連の管理レイヤーを導入しました。高レベルの運用目標は、上層層から下層までトップダウンの方法で伝播します。関連する抽象化階層は、管理の複雑さを別々の関心分野に分解するために重要でした。この抽象化階層には、デバイス固有の情報を使用して最低レベルで関係する情報階層が伴いましたが、それには、たとえば、エンドツーエンドのサービスインスタンスが含まれます。同様に、ポリシーベースのネットワーク管理（PBNM）の概念は、長い間、高レベルの管理ポリシーを指定することによりユーザーがネットワークを管理できるようにし、ポリシーシステムが自動的にこれらのポリシーを「レンダリング」すること、つまり破壊する能力を宣伝してきました。それらは低レベルの構成と制御ロジックにダウンします。
As a note, in the context of this document, "users" generally refers to operators and administrators who are responsible for the management and operation of communication services and networking infrastructures, not to "end users" of communication services.
メモとして、このドキュメントのコンテキストでは、「ユーザー」とは、一般に、通信サービスとネットワーキングインフラストラクチャの管理と運用を担当するオペレーターと管理者を指し、通信サービスの「エンドユーザー」ではありません。
What has been missing, however, is putting these concepts into a more current context and updating them to account for current technology trends. This document clarifies the concepts behind intent. It differentiates intent from related concepts. It also provides an overview of first-order principles of Intent-Based Networking as well as the associated functionality. The goal is to contribute to a common and shared understanding that can be used as a foundation to articulate research and engineering problems in the area of Intent-Based Networking.
しかし、欠落しているのは、これらの概念をより現在のコンテキストに入れ、それらを更新して現在の技術の傾向を説明することです。このドキュメントは、意図の背後にある概念を明確にします。意図と関連する概念を区別します。また、意図ベースのネットワーキングの一次原則と関連する機能の概要も提供します。目標は、意図ベースのネットワーキングの分野で研究と工学の問題を明確にするための基盤として使用できる共通の共有理解に貢献することです。
It should be noted that the articulation of IBN-related research problems is beyond the scope of this document. However, it should be recognized that Intent-Based Networking has become an important topic in the research community. Per IEEE Xplore [IEEEXPLORE], as of December 2021, in the past decade since 2012, there have been 1138 papers with the index term "intent", of which 411 specifically mention networking. The time period since 2020 alone accounts for 316 papers on intent and 153 for intent networking, indicating accelerating interest. In addition, workshops dedicated to this theme are beginning to appear, such as the IEEE International Workshop on Intent-Based Networking [WIN21], as well as various special journal issues [IEEE-TITS21]. A survey of current intent-driven networking research has been published in [PANG20], listing among the most pressing current research challenges aspects such as intent translation and understanding, intent interfaces, and security.
IBN関連の研究問題の明確化は、この文書の範囲を超えていることに注意する必要があります。ただし、意図ベースのネットワーキングが研究コミュニティで重要なトピックになっていることを認識する必要があります。IEEE XPlore [IEEExPlore]ごとに、2021年12月の時点で、2012年以降の過去10年間で、インデックス用語「意図」を含む1138の論文があり、そのうち411は特にネットワーキングに言及しています。2020年以来の期間だけで、意図に関する316の論文、意図ネットワーキングの153件を占めており、関心の加速を示しています。さらに、このテーマに特化したワークショップが、IEEE International Workshop on Intent Based Networking [Win21]やさまざまな特別なジャーナルの問題[IEEE-Tits21]など、登場し始めています。現在の意図駆動型ネットワーキング研究の調査は、[PANG20]に掲載されており、意図と理解、意図インターフェイス、セキュリティなどの最も差し迫った現在の研究の課題の側面に掲載されています。
ACL: Access Control List
ACL：アクセス制御リスト
API: Application Programming Interface
API：アプリケーションプログラミングインターフェイス
IBA: Intent-Based Analytics. Analytics that are defined and derived from users' intent and used to validate the intended state.
IBA：意図ベースの分析。ユーザーの意図から定義および導出され、意図した状態を検証するために使用される分析。
IBN: Intent-Based Network. A network that can be managed using intent.
IBN：意図ベースのネットワーク。意図を使用して管理できるネットワーク。
IBS: Intent-Based System. A system that supports management functions that can be guided using intent.
IBS：意図ベースのシステム。意図を使用してガイドできる管理機能をサポートするシステム。
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 Management: The concept of performing management based on the concept of intent.
意図ベースの管理：意図の概念に基づいた管理の概念。
PBNM: Policy-Based Network Management
PBNM：ポリシーベースのネットワーク管理
PDP: Policy Decision Point
PDP：ポリシー決定ポイント
PEP: Policy Enforcement Point
PEP：ポリシー執行ポイント
Policy: A set of rules that governs the choices in behavior of a system.
ポリシー：システムの動作の選択を管理する一連のルール。
Service Model: A model that represents a service that is provided by a network to a user.
サービスモデル：ネットワークがユーザーに提供するサービスを表すモデル。
SSoT: Single Source of Truth. A functional block in an IBN system that normalizes users' intent and serves as the single source of data for the lower layers.
SSOT：真実の単一のソース。ユーザーの意図を正規化し、下層の単一のデータソースとして機能するIBNシステムの機能ブロック。
Statement of Intent: A specification of one particular aspect or component of intent, also referred to as an intent statement.
意図の声明：意図のある特定の側面またはコンポーネントの指定、意図声明とも呼ばれます。
SVoT: Single Version of Truth
SVOT：真実の単一バージョン
User: In the context of this document, an operator and/or administrator responsible for the management and operation of communication services and networking infrastructure (as opposed to an end user of a communication service).
ユーザー：このドキュメントのコンテキストでは、コミュニケーションサービスとネットワーキングインフラストラクチャの管理と運用を担当するオペレーターおよび/または管理者（通信サービスのエンドユーザーとは対照的に）。
The following section provides an overview of the concept of intent and Intent-Based Management. It also provides an overview of the related concepts of service models and policies (and Policy-Based Network Management), and explains how they relate to intent and Intent-Based Management.
次のセクションでは、意図と意図に基づく管理の概念の概要を説明します。また、サービスモデルとポリシー（およびポリシーベースのネットワーク管理）の関連概念の概要を提供し、それらが意図と意図に基づく管理にどのように関連するかを説明します。
In this document, intent is defined as a set of operational goals (that a network is supposed to meet) and outcomes (that a network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them.
このドキュメントでは、意図は一連の運用目標（ネットワークが満たすことになっていること）および結果（ネットワークが提供することになっている）として定義され、それらを達成または実装する方法を指定せずに宣言的な方法で定義します。
The term "intent" was first introduced in the context of Autonomic Networks, where it is defined as "an abstract, high-level policy used to operate the network" [RFC7575]. According to this definition, an intent is a specific type of policy provided by a user to provide guidance to the Autonomic Network that would otherwise operate without human intervention. However, to avoid using intent simply as a synonym for policy, a distinction that differentiates intent clearly from other types of policies needs to be introduced.
「意図」という用語は、自律的ネットワークのコンテキストで最初に導入され、「ネットワークの操作に使用される抽象的で高レベルのポリシー」として定義されています[RFC7575]。この定義によれば、意図は、人間の介入なしに動作する自律的なネットワークにガイダンスを提供するために、ユーザーが提供する特定のタイプのポリシーです。ただし、単にポリシーの同義語として意図を使用することを避けるために、他のタイプのポリシーとは明確に意図を区別する区別を導入する必要があります。
One note regarding the use of the plural form of "intent": in the English language, the term "intent" is generally used only in singular form. However, the specification of intent as a whole usually involves the specification of several individual statements of intent, or intent statements. In some cases, intent statements are colloquially also referred to as "intents", although in general, the use of the term "intents" is discouraged.
「意図」の複数形の使用に関する1つのメモ：英語では、「意図」という用語は通常、単数形でのみ使用されます。ただし、意図全体の仕様には、通常、意図のいくつかの個別の声明、または意図ステートメントの仕様が含まれます。場合によっては、意図的な声明は口語的には「意図」とも呼ばれますが、一般的には「意図」という用語の使用は落胆します。
Intent-Based Management aims to lead towards networks that are fundamentally simpler to manage and operate, requiring only minimal outside intervention. Networks, even when they are autonomic, are not clairvoyant and have no way of automatically knowing particular operational goals nor which instances of networking services to support. In other words, they do not know what the intent of the network provider is that gives the network the purpose of its being. This still needs to be communicated to the network by what informally constitutes intent. That being said, the concept of intent is not limited just to autonomic networks, such as networks that feature an Autonomic Control Plane [RFC8994], but applies to any network.
意図ベースの管理は、管理と運用が基本的により簡単なネットワークに導くことを目的としており、最小限の外部介入のみを必要とします。ネットワークは、それらが自律的であっても、透視ではなく、特定の運用目標やサポートするネットワーキングサービスのインスタンスを自動的に知る方法がありません。言い換えれば、彼らはネットワークプロバイダーの意図がネットワークにその存在の目的を与えるものであることを知りません。これは、非公式に意図を構成するものによって、まだネットワークに伝える必要があります。そうは言っても、意図の概念は、自律制御プレーン[RFC8994]を特徴とするネットワークなどの自律的なネットワークだけでなく、任意のネットワークに適用されるだけではありません。
Intent defines goals and outcomes in a manner that is purely declarative, specifying what to accomplish, not how to achieve it. Intent thus applies several important concepts simultaneously:
意図は、純粋に宣言的な方法で目標と結果を定義し、それを達成する方法ではなく、何を達成するかを指定します。したがって、意図はいくつかの重要な概念を同時に適用します。
* It provides data abstraction: Users do not need to be concerned with low-level device configuration and nerd knobs.
* データの抽象化を提供します。ユーザーは、低レベルのデバイス構成とオタクノブに関心を持つ必要はありません。
* It provides functional abstraction from particular management and control logic: Users do not need to be concerned even with how to achieve a given intent. What is specified is the desired outcome with the IBS automatically figuring out a course of action (e.g., using an algorithm or applying a set of rules derived from the intent) for how to achieve the outcome.
* 特定の管理および制御ロジックから機能的な抽象化を提供します。ユーザーは、特定の意図を達成する方法でも懸念する必要はありません。指定されているのは、結果を達成する方法のために、IBSがアクションコースを自動的に把握する（例えば、意図から派生したルールのセットを適用するなど）自動的に把握することで望ましい結果です。
The following are some examples of intent, expressed in natural language for the sake of clarity (actual interfaces used to convey intent may differ):
以下は、明確にするために自然言語で表現されている意図の例です（意図を伝えるために使用される実際のインターフェイスは異なる場合があります）：
* "Steer networking traffic originating from endpoints in one geography away from a second geography, unless the destination lies in that second geography." (states what to achieve, not how.)
* 「目的地がその2番目の地理にある場合を除き、2番目の地理から離れた1つの地理のエンドポイントから発信される操縦ネットワーキングトラフィック。」（どのように達成すべきかを述べています。）
* "Avoid routing networking traffic originating from a given set of endpoints (or associated with a given customer) through a particular vendor's equipment, even if this occurs at the expense of reduced service levels." (states what to achieve, not how, providing additional guidance for how to trade off between different goals when necessary.)
* 「特定のベンダーの機器を介して、特定のエンドポイントのセット（または特定の顧客に関連付けられている）から発信されるネットワーキングトラフィックをルーティングしないでください。（必要に応じて、異なる目標間で取引する方法について追加のガイダンスを提供する方法ではなく、何を達成するかを述べます。）
* "Maximize network utilization even if it means trading off service levels (such as latency, loss) unless service levels have deteriorated 20% or more from their historical mean." (a desired outcome, with a set of constraints for additional guidance, that does not specify how to achieve this.)
* 「サービスレベルが歴史的平均から20％以上劣化していない限り、サービスレベル（レイテンシ、損失など）を取引することを意味する場合でも、ネットワークの利用を最大化します。」（これを達成する方法を指定していない追加のガイダンスのための一連の制約を備えた望ましい結果。）
* "Ensure VPN services have path protection at all times for all paths." (a desired outcome of which it may not be clear how it can be precisely accommodated.)
* 「VPNサービスには、すべてのパスに対して常にパス保護があることを確認してください。」（望ましい結果は、それがどのように正確に収容できるかは明確ではないかもしれません。）
* "Generate in situ Operations, Administration, and Maintenance (OAM) data and network telemetry for later offline analysis whenever significant fluctuations in latency across a path are observed." (goes beyond event-condition-action by not being specific about what constitutes "significant" and what specific data to collect.)
* 「パスを横切る潜伏期の著しい変動が観察されるたびに、後のオフライン分析のために、その場での操作、管理、およびメンテナンス（OAM）データとネットワークテレメトリを生成します。」（「重要な」ものと収集する特定のデータを構成するものについて具体的ではないことにより、イベント条件のアクションを超えています。）
* "Route traffic in a Space Information Network in a way that minimizes dependency on stratospheric balloons unless the intended destination is an aircraft." (does not specify how to precisely achieve this; extrapolates on scenarios mentioned in [PANG20].)
* 「目的の目的地が航空機でない限り、成層圏の風船への依存を最小限に抑える方法で、宇宙情報ネットワークの交通をルートします。」（これを正確に達成する方法を指定していません。[PANG20]に記載されているシナリオに外挿。）
* "For a smart city service, ensure traffic signal control traffic uses dedicated and redundant slices that avoid fate sharing." (a desired outcome with a set of constraints and additional guidance without specifying how to precisely achieve this; extrapolates on scenarios from [GHARBAOUI21].)
* 「スマートシティサービスの場合、トラフィック信号制御トラフィックは、運命の共有を避ける専用の冗長スライスを使用します。」（これを正確に達成する方法を指定せずに、一連の制約と追加のガイダンスを伴う望ましい結果。
In contrast, the following are examples of what would not constitute intent (again, expressed in natural language for the sake of clarity):
対照的に、以下は意図を構成しないものの例です（繰り返しますが、明確にするために自然言語で表現されています）：
* "Configure a given interface with an IP address." (This would be considered device configuration and fiddling with configuration knobs, not intent.)
* 「IPアドレスで特定のインターフェイスを構成します。」（これは、意図ではなく、デバイスの構成と構成ノブをいじることと見なされます。）
* "When interface utilization exceeds a specific threshold, emit an alert." (This would be a rule that can help support network automation, but a simple rule is not an intent.)
* 「インターフェイスの使用率が特定のしきい値を超えた場合、アラートを発します。」（これはネットワークの自動化をサポートするのに役立つルールですが、単純なルールは意図ではありません。）
* "Configure a VPN with a tunnel from A to B over path P." (This would be considered as a configuration of a service.)
* 「AからBを超えるトンネルでVPNを構成してパスPを構成する」（これはサービスの構成と見なされます。）
* "Deny traffic to prefix P1 unless it is traffic from prefix P2." (This would be an example of an access policy or a firewall rule, not intent.)
* 「プレフィックスP2からのトラフィックがない限り、P1へのトラフィックを拒否します。」（これは、意図ではなく、アクセスポリシーまたはファイアウォールルールの例です。）
In networks, in particular in networks that are deemed autonomic, intent should ideally be rendered by the network itself, i.e., translated into device-specific rules and courses of action. Ideally, intent would not need to be orchestrated or broken down by a higher-level, centralized system but by the network devices themselves using a combination of distributed algorithms and local device abstractions. In this idealized vision, because intent holds for the network as a whole, intent should ideally be automatically disseminated across all devices in the network, which can themselves decide whether they need to act on it.
ネットワークでは、特に自律的とみなされるネットワークでは、ネットワーク自体によって理想的にレンダリングされる必要があります。つまり、デバイス固有のルールとアクションコースに変換されます。理想的には、高レベルの集中システムによって組織化または分解される必要はありませんが、分散アルゴリズムとローカルデバイスの抽象化の組み合わせを使用して、ネットワークデバイス自体によって自由に分解される必要はありません。この理想的なビジョンでは、ネットワーク全体を意図が保持するため、意図は、ネットワーク内のすべてのデバイスに自動的に普及する必要があります。
However, such decentralization will not be practical in all cases. Certain functions will need to be at least conceptually centralized. For example, users may require a single conceptual point of interaction with the network. The system providing this point acts as the operational front end for the network through which users can direct requests at the network and from which they can receive updates about the network. It may appear to users as a single system, even if it is implemented in a distributed manner. In turn, it interacts with and manages other systems in the network as needed in order to realize (i.e., to fulfill and to assure) the desired intent. Likewise, the vast majority of network devices may be intent-agnostic and focus only (for example) on the actual forwarding of packets. Many devices may also be constrained in terms of their processing resources. This means that not every device may be able to act on intent on its own. Again, intent in those cases can be achieved by a separate system that performs the required actions.
ただし、そのような分散化はすべての場合に実用的ではありません。特定の機能は、少なくとも概念的に集中化する必要があります。たとえば、ユーザーは、ネットワークとの相互作用の単一の概念的なポイントを必要とする場合があります。このポイントを提供するシステムは、ユーザーがネットワークでリクエストを指示し、そこからネットワークに関する更新を受信できるネットワークの運用フロントエンドとして機能します。分散方法で実装されていても、ユーザーには単一のシステムとして表示される場合があります。次に、必要に応じて、必要に応じてネットワーク内の他のシステムと相互作用して管理し、目的の意図を実現する（つまり、充実し、保証するために）。同様に、ネットワークデバイスの大部分は意図的に依存しない可能性があり、パケットの実際の転送にのみ（たとえば）焦点を合わせている可能性があります。また、多くのデバイスが処理リソースの観点から制約される場合があります。これは、すべてのデバイスがそれ自体で意図に基づいて行動できるわけではないことを意味します。繰り返しますが、これらの場合の意図は、必要なアクションを実行する別のシステムによって達成できます。
Another reason to provide intent functionality from a conceptually centralized point is in cases where the realization of a certain type of intent benefits from global knowledge of a network and its state. In many cases, such a global view may be impractical to maintain by individual devices, for example due to the volume of data and time lags that are involved. It may even be impractical for devices to simply access such a view from another remote system if such were available.
概念的に集中化されたポイントから意図機能を提供するもう1つの理由は、ネットワークとその状態のグローバルな知識から特定のタイプの意図の利益を実現する場合です。多くの場合、このようなグローバルな見解は、たとえば、関係するデータや時間遅延のために、個々のデバイスによって維持することは非現実的である可能性があります。デバイスが利用可能な場合、別のリモートシステムからそのようなビューに単純にアクセスすることは実用的ではありません。
All of this implies that in many cases, certain intent functionality needs to be provided by functions that are specialized for that purpose and that may be provided by dedicated systems (which in some cases could also co-host other networking functions). For example, the translation of specific types of intent into corresponding courses of action and algorithms to achieve the desired outcomes may need to be provided by such specialized functions. Of course, to avoid single points of failure, the implementation and hosting of such functions may still be distributed even if conceptually centralized.
これはすべて、多くの場合、特定の意図機能を、その目的に特化し、専用システム（場合によっては他のネットワーキング機能を共同ホストする可能性がある）によって提供される機能によって提供される必要があることを意味します。たとえば、特定のタイプの意図を、対応するアクションおよびアルゴリズムへの翻訳を、そのような専門的な機能によって提供する必要がある場合があります。もちろん、単一の障害点を回避するために、そのような機能の実装とホスティングは、概念的に集中化されたとしても分散される場合があります。
Regardless of its particular implementation in a centralized or decentralized manner, an IBN is a network that can be managed using intent. This means that it is able to recognize and ingest intent of an operator or user and configure and adapt itself according to the user intent, achieving an intended outcome (i.e., a desired state or behavior) without requiring the user to specify the detailed technical steps for how to achieve the outcome. Instead, the IBN will be able to figure out on its own how to achieve the outcome. Similarly, an IBS is a system that allows users to manage a network using intent. Such a system will serve as a point of interaction with users and implement the functionality that is necessary to achieve the intended outcomes, interacting for that purpose with the network as required.
IBNは、集中型または分散化された方法での特定の実装に関係なく、意図を使用して管理できるネットワークです。これは、オペレーターまたはユーザーの意図を認識して摂取し、ユーザーの意図に従って設定して適応できることを意味し、ユーザーに詳細な技術的手順を指定することなく、意図した結果（つまり、目的の状態または行動）を達成できます。結果を達成する方法について。代わりに、IBNは結果を達成する方法を独自に理解できるようになります。同様に、IBSは、ユーザーが意図を使用してネットワークを管理できるシステムです。このようなシステムは、ユーザーとの相互作用のポイントとして機能し、意図した結果を達成するために必要な機能を実装し、必要に応じてネットワークとその目的のために相互作用します。
Other definitions of intent exist, such as [TR523]. Intent there is simply defined as a declarative interface that is typically provided by a controller. It implies the presence of a centralized function that renders the intent into lower-level policies or instructions and orchestrates them across the network. While this is certainly one way of implementation, the definition that is presented here is more encompassing and ambitious, as it emphasizes the importance of managing the network by specifying desired outcomes without the specific steps to be taken in order to achieve the outcome. A controller API that simply provides abstraction at the network level is more limited and would not necessarily qualify as intent. Likewise, ingestion and recognition of intent may not necessarily occur via an API based on function invocations and simple request-response interactions but may involve other types of human-machine interactions such as dialogs to provide clarifications and refinements to requests.
[TR523]など、その他の意図の定義が存在します。意図は、通常、コントローラーによって提供される宣言的インターフェイスとして定義されています。これは、下位レベルのポリシーまたは指示に意図を与え、ネットワーク全体でそれらを調整する集中機能の存在を意味します。これは確かに実装の方法の1つですが、ここで提示されている定義は、結果を達成するために取られるべき特定の手順なしに目的の結果を指定することにより、ネットワークを管理することの重要性を強調するため、より包括的で野心的です。ネットワークレベルで抽象化を単純に提供するコントローラーAPIは、より制限されており、必ずしも意図として適格ではありません。同様に、意図の摂取と認識は、関数の呼び出しと単純なリクエスト応答の相互作用に基づいてAPIを介して必ずしも発生するとは限らないが、ダイアログなどの他のタイプのヒューマシン相互作用が含まれる場合があります。
A service model is a model that represents a service that is provided by a network to a user. Per [RFC8309], a service model describes a service and its parameters in a portable and implementation-agnostic way that can be used independently of the equipment and operating environment on which the service is realized. Two subcategories are distinguished: a "Customer Service Model" describes an instance of a service as provided to a customer, possibly associated with a service order, and a "Service Delivery Model" describes how a service is instantiated over existing networking infrastructure.
サービスモデルは、ユーザーにネットワークによって提供されるサービスを表すモデルです。[RFC8309]によると、サービスモデルは、サービスが実現されている機器と操作環境とは無関係に使用できるポータブルおよび実装に依存しない方法でサービスとそのパラメーターを説明します。2つのサブカテゴリが際立っています。「カスタマーサービスモデル」は、顧客に提供されるサービスのインスタンスを記述し、おそらくサービス注文に関連付けられており、「サービス提供モデル」は、既存のネットワーキングインフラストラクチャにサービスがどのようにインスタンス化されるかを説明します。
An example of a service could be a Layer 3 VPN service [RFC8299], a Network Slice [NETWORK-SLICE], or residential Internet access. Service models represent service instances as entities in their own right. Services have their own parameters, actions, and life cycles. Typically, service instances can be bound to end users of communication services who might be billed for the services provided.
サービスの例は、レイヤー3 VPNサービス[RFC8299]、ネットワークスライス[ネットワークスライス]、または住宅用インターネットアクセスです。サービスモデルは、サービスインスタンスをそれ自体がエンティティとして表しています。サービスには、独自のパラメーター、アクション、ライフサイクルがあります。通常、サービスインスタンスは、提供されるサービスに対して請求される可能性のある通信サービスのエンドユーザーに拘束できます。
Instantiating a service typically involves multiple aspects:
サービスのインスタンス化には、通常、複数の側面が含まれます。
* A user (or northbound system) needs to define and/or request a service to be instantiated.
* ユーザー（または北行きのシステム）は、インスタンス化するサービスを定義および/または要求する必要があります。
* Resources, such as IP addresses, AS numbers, VLAN or VxLAN pools, interfaces, bandwidth, or memory need to be allocated.
* IPアドレス、数字、VLANまたはVXLANプール、インターフェイス、帯域幅、メモリなどのリソースを割り当てる必要があります。
* How to map services to the resources needs to be defined. Multiple mappings are often possible, which to select may depend on context (such as which type of access is available to connect the end user of a communication service with the service).
* リソースにサービスをマッピングする方法は、定義する必要があります。多くの場合、複数のマッピングが可能であり、選択することがコンテキストに依存する場合があります（通信サービスのエンドユーザーをサービスと接続するために利用可能なアクセスなど）。
* Bindings between upper- and lower-level objects need to be maintained.
* 上部レベルと低レベルのオブジェクトの間のバインディングを維持する必要があります。
* Once instantiated, the service operational state needs to be validated and assured to ensure that the network indeed delivers the service as requested.
* インスタンス化されると、サービス運用状態を検証し、保証する必要があります。
The realization of service models involves a system, such as a controller, that provides provisioning logic. This includes breaking down high-level service abstractions into lower-level device abstractions, identifying and allocating system resources, and orchestrating individual provisioning steps. Orchestration operations are generally conducted using a "push" model in which the controller/manager initiates the operations as required, then pushes down the specific configurations to the device and validates whether the new changes have been accepted and the new operational/derived states are achieved and in sync with the intent/desired state. In addition to instantiating and creating new instances of a service, updating, modifying, and decommissioning services also need to be supported. The device itself typically remains agnostic to the service or the fact that its resources or configurations are part of a service/concept at a higher layer.
サービスモデルの実現には、プロビジョニングロジックを提供するコントローラーなどのシステムが含まれます。これには、高レベルのサービス抽象化を低レベルのデバイスの抽象化に分解し、システムリソースの特定と割り当て、個々のプロビジョニングステップの調整が含まれます。オーケストレーション操作は通常、コントローラー/マネージャーが必要に応じて操作を開始し、特定の構成をデバイスに押し下げ、新しい変更が受け入れられ、新しい運用/派生状態が達成されるかどうかを検証する「プッシュ」モデルを使用して実行されます。意図/望ましい状態と同期しています。サービスの新しいインスタンスのインスタンス化と作成に加えて、サービスを更新、変更、および廃止することもサポートする必要があります。デバイス自体は通常、サービスまたはそのリソースまたは構成が高層のサービス/コンセプトの一部であるという事実に対して不可知論者のままです。
Instantiated service models map to instantiated lower-layer network and device models. Examples include instances of paths or instances of specific port configurations. The service model typically also models dependencies and layering of services over lower-layer networking resources that are used to provide services. This facilitates management by allowing to follow dependencies for troubleshooting activities and to perform impact analysis in which events in the network are assessed regarding their impact on services and customers. Services are typically orchestrated and provisioned top to bottom, which also facilitates keeping track of the assignment of network resources (composition), while troubleshooted bottom up (decomposition). Service models might also be associated with other data that does not concern the network but provides business context. This includes things such as customer data (such as billing information), service orders and service catalogs, tariffs, service contracts, and Service Level Agreements (SLAs), including contractual agreements regarding remediation actions.
インスタンス化されたサービスモデルは、インスタンス化された低層ネットワークおよびデバイスモデルにマッピングされます。例には、パスのインスタンスまたは特定のポート構成のインスタンスが含まれます。サービスモデルは通常、サービスの提供に使用される低層ネットワーキングリソースを介したサービスの依存関係とレイヤー化もモデル化します。これにより、トラブルシューティングアクティビティの依存関係に従い、サービスや顧客への影響に関してネットワーク内のイベントが評価される影響分析を実行することにより、管理を促進します。サービスは通常、組織化され、上部から下部までプロビジョニングされます。これにより、ネットワークリソース（構成）の割り当てを追跡することも容易になりますが、ボトムアップ（分解）がトラブルシューティングされます。サービスモデルは、ネットワークに関係しないがビジネスコンテキストを提供する他のデータにも関連付けられている可能性があります。これには、顧客データ（請求情報など）、サービス注文とサービスカタログ、関税、サービス契約、サービスレベル契約（SLA）など、修復措置に関する契約契約が含まれます。
[SERVICE-MAPPING-YANG] is an example of a data model that provides a mapping for customer service models (e.g., the L3VPN Service Model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Abstraction and Control of Traffic Engineered Networks Virtual Network model).
[サービスマッピングヤン]は、トラフィックエンジニアリング（TE）モデル（TEトンネルまたはトラフィックの抽象化と制御など、カスタマーサービスモデル（L3VPNサービスモデルなど）のマッピングを提供するデータモデルの例です。エンジニアリングネットワーク仮想ネットワークモデル）。
Like intent, service models provide higher layers of abstraction. Service models are often also complemented with mappings that capture dependencies between service and device or network configurations. Unlike intent, service models do not allow to define a desired "outcome" that would be automatically maintained by an IBS. Instead, the management of service models requires the development of sophisticated algorithms and control logic by network providers or system integrators.
意図と同様に、サービスモデルは抽象化のより高い層を提供します。サービスモデルは、サービスとデバイスまたはネットワーク構成の間の依存関係をキャプチャするマッピングでも補完されます。意図とは異なり、サービスモデルは、IBSによって自動的に維持される望ましい「結果」を定義することを許可していません。代わりに、サービスモデルの管理には、ネットワークプロバイダーまたはシステムインテグレーターによる洗練されたアルゴリズムと制御ロジックの開発が必要です。
Policy-Based Network Management (PBNM) is a management paradigm that separates the rules that govern the behavior of a system from the functionality of the system. It promises to reduce maintenance costs of information and communication systems while improving flexibility and runtime adaptability. It is present today at the heart of a multitude of management architectures and paradigms, including SLA-driven, business-driven, autonomous, adaptive, and self-* management [BOUTABA07]. The interested reader is asked to refer to the rich set of existing literature, which includes this and many other references. In the following, we will only provide a much-abridged and distilled overview.
ポリシーベースのネットワーク管理（PBNM）は、システムの動作をシステムの機能から支配するルールを分離する管理パラダイムです。柔軟性とランタイムの適応性を向上させながら、情報通信システムのメンテナンスコストを削減することを約束します。今日は、SLA駆動型、ビジネス駆動型、自律、適応、および自己管理[Boutaba07]を含む、多数の管理アーキテクチャとパラダイムの中心に存在しています。興味のある読者は、これや他の多くの参考文献を含む既存の文献の豊富なセットを参照するように求められます。以下では、非常に促進され、蒸留された概要のみを提供します。
At the heart of policy-based management is the concept of a policy. Multiple definitions of policy exist: "Policies are rules governing the choices in the behavior of a system" [SLOMAN94]. "Policy is a set of rules that are used to manage and control the changing and/or maintaining of the state of one or more managed objects" [STRASSNER03]. Common to most definitions is the definition of a policy as a "rule." Typically, the definition of a rule consists of an event (whose occurrence triggers a rule), a set of conditions (which get assessed and which must be true before any actions are actually "fired"), and finally, a set of one or more actions that are carried out when the condition holds.
政策ベースの管理の中心にあるのは、政策の概念です。ポリシーの複数の定義が存在します：「ポリシーは、システムの動作の選択を管理する規則です」[Sloman94]。「ポリシーは、1つ以上の管理されたオブジェクトの状態の変化および/または維持の管理と制御に使用される一連のルールです」[strassner03]。ほとんどの定義に共通するのは、「ルール」としてのポリシーの定義です。通常、ルールの定義は、イベント（その発生がルールをトリガーする）、一連の条件（評価され、実際に「発射」される前に真でなければならない）で構成され、最後に、1つまたは1つのセットで構成されています。条件が保持されたときに実行されるより多くのアクション。
Policy-based management can be considered an imperative management paradigm: Policies precisely specify what needs to be done when and in which circumstance. By using policies, management can, in effect, be defined as a set of simple control loops. This makes policy-based management a suitable technology to implement autonomic behavior that can exhibit self-* management properties, including self-configuration, self-healing, self-optimization, and self-protection. This is notwithstanding the fact that policy-based management may make use of the concept of abstractions (such as, "Bob gets gold service") that hide from the user the specifics of how that abstraction is rendered in a particular deployment.
ポリシーベースの管理は、命令的な管理パラダイムと見なすことができます。ポリシーは、いつ、どのような状況で行う必要があるかを正確に指定します。ポリシーを使用することにより、管理は実際には、単純な制御ループのセットとして定義できます。これにより、ポリシーベースの管理により、自己構成、自己修復、自己最適化、自己保護など、自己管理特性を示すことができる自律行動を実装する適切な技術になります。これは、ポリシーベースの経営陣が、特定の展開でその抽象化がどのようにレンダリングされるかの詳細をユーザーから隠す抽象化の概念（「ゴールドサービス」など）を利用できるという事実にもかかわらずです。
Policies typically involve a certain degree of abstraction in order to cope with the heterogeneity of networking devices. Rather than having a device-specific policy that defines events, conditions, and actions in terms of device-specific commands, parameters, and data models, a policy is defined at a higher level of abstraction involving a canonical model of systems and devices to which the policy is to be applied. A policy agent on a controller or the device subsequently "renders" the policy, i.e., translates the canonical model into a device-specific representation. This concept allows applying the same policy across a wide range of devices without needing to define multiple variants. In other words, policy definition is decoupled from policy instantiation and policy enforcement. This enables operational scale and allows network operators and authors of policies to think in higher terms of abstraction than device specifics and be able to reuse the same, high-level definition across different networking domains, WAN, data center (DC), or public cloud.
通常、ポリシーには、ネットワーキングデバイスの不均一性に対処するために、ある程度の抽象化が含まれます。デバイス固有のコマンド、パラメーター、およびデータモデルの観点からイベント、条件、およびアクションを定義するデバイス固有のポリシーを持つのではなく、ポリシーは、システムとデバイスの標準モデルを含むより高いレベルの抽象化で定義されます。ポリシーが適用されます。その後、コントローラーまたはデバイスのポリシーエージェントがポリシーを「レンダリング」します。つまり、標準モデルをデバイス固有の表現に変換します。この概念により、複数のバリエーションを定義する必要なく、幅広いデバイスに同じポリシーを適用できます。言い換えれば、ポリシーの定義は、ポリシーのインスタンス化とポリシーの執行から切り離されています。これにより、運用スケールが可能になり、ネットワークオペレーターとポリシーの著者がデバイスの詳細よりも高い抽象化の用語で考えることができ、異なるネットワーキングドメイン、WAN、データセンター（DC）、またはパブリッククラウドで同じ高レベルの定義を再利用できるようになります。 。
PBNM is typically "push-based": Policies are pushed onto devices where they are rendered and enforced. The push operations are conducted by a manager or controller that is responsible for deploying policies across the network and monitoring their proper operation. That being said, other policy architectures are possible. For example, policy-based management can also include a pull component in which the decision regarding which action to take is delegated to a so-called Policy Decision Point (PDP). This PDP can reside outside the managed device itself and has typically global visibility and context with which to make policy decisions. Whenever a network device observes an event that is associated with a policy but lacks the full definition of the policy or the ability to reach a conclusion regarding the expected action, it reaches out to the PDP for a decision (reached, for example, by deciding on an action based on various conditions). Subsequently, the device carries out the decision as returned by the PDP; the device "enforces" the policy and hence acts as a PEP (Policy Enforcement Point). Either way, PBNM architectures typically involve a central component from which policies are deployed across the network and/or policy decisions served.
PBNMは通常、「プッシュベース」です。ポリシーは、レンダリングおよび実施されるデバイスにプッシュされます。プッシュ操作は、ネットワーク全体にポリシーを展開し、適切な操作を監視する責任があるマネージャーまたはコントローラーによって実施されます。そうは言っても、他のポリシーアーキテクチャが可能です。たとえば、ポリシーベースの管理には、どのアクションを実行するかに関する決定がいわゆるポリシー決定ポイント（PDP）に委任されるプルコンポーネントを含めることもできます。このPDPは、管理されたデバイス自体の外側に存在する可能性があり、通常、政策決定を行うためのグローバルな可視性とコンテキストを備えています。ネットワークデバイスがポリシーに関連付けられているが、ポリシーの完全な定義または予想アクションに関する結論に達する能力がないイベントを観察するたびに、決定のためにPDPに到達します（たとえば、決定することにより到達しました。さまざまな条件に基づくアクションについて）。その後、デバイスはPDPによって返される決定を実行します。デバイスはポリシーを「強制」するため、PEP（ポリシー執行ポイント）として機能します。いずれにせよ、PBNMアーキテクチャには、通常、ネットワーク全体にポリシーが展開される中央コンポーネントおよび/またはポリシー決定が含まれます。
Like intent, policies provide a higher layer of abstraction. Policy systems are also able to capture dynamic aspects of the system under management through the specification of rules that allow defining various triggers for specific courses of action. Unlike intent, the definition of those rules (and courses of action) still needs to be articulated by users. Since the intent is unknown, conflict resolution within or between policies requires interactions with a user or some kind of logic that resides outside of PBNM. In that sense, policy constitutes a lower level of abstraction than intent, and it is conceivable for IBSs to generate policies that are subsequently deployed by a PBNM system, allowing PBNM to support Intent-Based Networking.
意図と同様に、ポリシーは抽象化のより高い層を提供します。また、ポリシーシステムは、特定のアクションコースのさまざまなトリガーを定義できるルールの仕様を通じて、管理下のシステムの動的な側面をキャプチャすることもできます。意図とは異なり、これらのルール（およびアクションコース）の定義は、ユーザーが引き続き明確にする必要があります。意図は不明であるため、ポリシー内またはポリシー間の紛争解決には、ユーザーとの相互作用またはPBNMの外にあるある種のロジックが必要です。その意味で、ポリシーは意図よりも低いレベルの抽象化を構成し、IBSSがPBNMシステムによってその後展開されるポリシーを生成し、PBNMが意図ベースのネットワーキングをサポートできるようにすることが考えられます。
What intent, policy, and service models all have in common is the fact that they involve a higher layer of abstraction of a network that does not involve device specifics, generally transcends individual devices, and makes the network easier to manage for applications and human users compared to having to manage the network one device at a time. Beyond that, differences emerge.
意図、ポリシー、およびサービスモデルのすべてが共通しているのは、デバイスの詳細を伴わず、一般に個々のデバイスを超越し、アプリケーションや人間のユーザーのネットワークを容易にするネットワークの抽象化のより高い層を含むという事実です。ネットワーク1つのデバイスを一度に管理する必要があるのと比較してください。それを超えて、違いが現れます。
Summarized differences:
要約された違い：
* A service model is a data model that is used to describe instances of services that are provided to customers. A service model has dependencies on lower-level models (device and network models) when describing how the service is mapped onto the underlying network and IT infrastructure. Instantiating a service model requires orchestration by a system; the logic for how to orchestrate/manage/provide the service model and how to map it onto underlying resources is not included as part of the model itself.
* サービスモデルは、顧客に提供されるサービスのインスタンスを説明するために使用されるデータモデルです。サービスモデルには、サービスが基礎ネットワークおよびITインフラストラクチャにマッピングされる方法を説明する際の低レベルモデル（デバイスモデルとネットワークモデル）に依存関係があります。サービスモデルをインスタンス化するには、システムによるオーケストレーションが必要です。サービスモデルを調整/管理/提供する方法のロジックと、それを基礎となるリソースにマッピングする方法は、モデル自体の一部として含まれていません。
* Policy is a set of rules, typically modeled around a variation of events/conditions/actions, used to express simple control loops that can be rendered by devices without requiring intervention by the outside system. Policies let users define what to do under what circumstances, but they do not specify the desired outcome.
* ポリシーは一連のルールであり、通常、イベント/条件/アクションのバリエーションを中心にモデル化され、外部システムによる介入を必要とせずにデバイスによってレンダリングできる単純な制御ループを表現するために使用されます。ポリシーでは、ユーザーがどのような状況で何をすべきかを定義できますが、目的の結果を指定しません。
* Intent is a high-level, declarative goal that operates at the level of a network and services it provides, not individual devices. It is used to define outcomes and high-level operational goals, without specifying how those outcomes should be achieved or how goals should specifically be satisfied, and without the need to enumerate specific events, conditions, and actions. Which algorithm or rules to apply can be automatically "learned/derived from intent" by the IBS. In the context of autonomic networking, intent is ideally rendered by the network itself; also, the dissemination of intent across the network and any required coordination between nodes is resolved by the network without the need for external systems.
* 意図は、個々のデバイスではなく、それが提供するネットワークとサービスのレベルで動作する高レベルの宣言的な目標です。これらの結果を達成する方法や目標をどのように具体的に満たすべきか、特定のイベント、条件、および行動を列挙する必要なく、結果と高レベルの運用目標を定義するために使用されます。適用するアルゴリズムまたはルールは、IBSによって自動的に「意図から学習/導出される」ことができます。自律的なネットワーキングの文脈では、意図はネットワーク自体によって理想的にレンダリングされます。また、ネットワーク全体の意図の普及とノード間の必要な調整は、外部システムを必要とせずにネットワークによって解決されます。
One analogy to capture the difference between policy-based systems and IBSs is that of Expert Systems and Learning Systems in the field of Artificial Intelligence. Expert Systems operate on knowledge bases with rules that are supplied by users, analogous to policy systems whose policies are supplied by users. They are able to make automatic inferences based on those rules but are not able to "learn" new rules on their own. Learning Systems (popularized by deep learning and neural networks), on the other hand, are able to learn without depending on user programming or articulation of rules. However, they do require a learning or training phase requiring large data sets; explanations of actions that the system actually takes provide a different set of challenges. Analogous to IBSs, users focus on what they would like the learning system to accomplish but not how to do it.
ポリシーベースのシステムとIBSSの違いを把握するための類似性の1つは、人工知能の分野における専門家システムと学習システムの違いです。エキスパートシステムは、ユーザーがポリシーを提供するポリシーシステムに類似した、ユーザーが提供するルールを備えた知識ベースで動作します。彼らはこれらのルールに基づいて自動推論を行うことができますが、自分で新しいルールを「学ぶ」ことはできません。一方、学習システム（ディープラーニングとニューラルネットワークによって普及）は、ユーザーのプログラミングやルールの明確化に依存せずに学習することができます。ただし、大規模なデータセットを必要とする学習段階またはトレーニングフェーズが必要です。システムが実際に取るアクションの説明は、異なる一連の課題を提供します。IBSSと同様に、ユーザーは学習システムに達成したいものに焦点を当てていますが、それを行う方法ではありません。
The following main operating principles allow characterizing the intent-based/-driven/-defined nature of a system.
次の主要な動作原則により、システムの意図ベース/駆動型/定義された性質を特徴付けることができます。
1. Single Source of Truth (SSoT) and Single Version of Truth (SVoT). The SSoT is an essential component of an IBS as it enables several important operations. The set of validated intent expressions is the system's SSoT. SSoT and the records of the operational states enable comparing the intended/desired state and actual/operational states of the system and determining drift between them. SSoT and the drift information provide the basis for corrective actions. If the IBS is equipped with the means to predict states, it can further develop strategies to anticipate, plan, and pro-actively act on any diverging trends with the aim to minimize their impact. Beyond providing a means for consistent system operation, SSoT also allows for better traceability to validate if/how the initial intent and associated business goals have been properly met in order to evaluate the impacts of changes in the intent parameters and impacts and effects of the events occurring in the system.
1. 真実の単一ソース（SSOT）と真理の単一バージョン（SVOT）。SSOTは、いくつかの重要な操作を可能にするため、IBSの重要なコンポーネントです。検証された意図式のセットは、システムのSSOTです。SSOTと運用状態の記録により、システムの意図/目的の状態と実際の/運用状態を比較し、それらの間のドリフトを決定できます。SSOTとドリフト情報は、是正措置の基礎を提供します。IBSに状態を予測する手段が装備されている場合、その影響を最小限に抑えることを目的として、異なる傾向を予測、計画、および積極的に行動する戦略をさらに開発できます。SSOTは、一貫したシステム操作の手段を提供するだけでなく、意図パラメーターの変化とイベントの影響と影響の影響の影響を評価するために、/最初の意図と関連するビジネス目標が適切に満たされたかどうかを検証するためのより良いトレーサビリティを可能にします。システムで発生します。
Single Version (or View) of Truth derives from the SSoT and can be used to perform other operations such as querying, polling, or filtering measured and correlated information in order to create so-called "views." These views can serve the users of the IBS. In order to create intent statements as single sources of truth, the IBS must follow well-specified and well-documented processes and models. In other contexts, SSoT is also referred to as the invariance of the intent [LENROW15].
真実の単一バージョン（またはビュー）はSSOTに由来し、いわゆる「ビュー」を作成するために、クエリ、ポーリング、またはフィルタリング測定および相関した情報などの他の操作を実行するために使用できます。これらのビューは、IBSのユーザーにサービスを提供できます。単一の真実のソースとして意図的なステートメントを作成するために、IBSは、明確に指定され、十分に文書化されたプロセスとモデルに従わなければなりません。他の文脈では、SSOTは意図の不変性とも呼ばれます[Lenrow15]。
2. One touch but not one shot. In an ideal IBS, the user expresses intent in one form or another, and then the system takes over all subsequent operations (one touch). A zero-touch approach could also be imagined in the case where the IBS has the capabilities or means to recognize intentions in any form of data. However, the zero- or one-touch approach should not distract from the fact that reaching the state of a well-formed and valid intent expression is not a one-shot process. On the contrary, the interfacing between the user and the IBS could be designed as an interactive and iterative process. Depending on the level of abstraction, the intent expressions may initially contain more or less implicit parts and imprecise or unknown parameters and constraints. The role of the IBS is to parse, understand, and refine the intent expression to reach a well-formed and valid intent expression that can be further used by the system for the fulfillment and assurance operations. An intent refinement process could use a combination of iterative steps involving the user to validate the proposed refined intent and to ask the user for clarifications in case some parameters or variables could not be deduced or learned by means of the system itself. In addition, the IBS will need to moderate between conflicting intent, helping users to properly choose between intent alternatives that may have different ramifications.
2. 1回のタッチですが、1発ではありません。理想的なIBSでは、ユーザーは何らかの形で意図を表明し、システムはその後のすべての操作を引き継ぎます（1つのタッチ）。 IBSにあらゆる形式のデータの意図を認識する機能または手段がある場合、ゼロタッチアプローチも想像できます。ただし、ゼロまたはワンタッチのアプローチは、適切に形成された有効な意図表現の状態に到達することはワンショットプロセスではないという事実から気を散らすものではありません。それどころか、ユーザーとIBSの間のインターフェースは、インタラクティブで反復的なプロセスとして設計できます。抽象化のレベルに応じて、意図式には最初に多かれ少なかれ暗黙の部分と不正確または未知のパラメーターと制約が含まれている場合があります。 IBSの役割は、意図的な表現を解析し、理解し、洗練して、履行および保証操作のためにシステムがさらに使用できる、形成された有効な意図表現に到達することです。意図の洗練プロセスでは、ユーザーが関与する反復ステップの組み合わせを使用して、提案された洗練された意図を検証し、システム自体によっていくつかのパラメーターまたは変数を推定または学習できない場合に、ユーザーに明確化を依頼することができます。さらに、IBSは矛盾する意図の間で緩和する必要があり、ユーザーが異なる影響を与える可能性のある意図的な代替案を適切に選択するのに役立ちます。
3. Autonomy and Supervision. A desirable goal for an IBS is to offer a high degree of flexibility and freedom on both the user side and system side, e.g., by giving the user the ability to express intent using the user's own terms, by supporting different forms of expression for individual statements of intent and being capable of refining the intent expressions to well-formed and exploitable expressions. The dual principle of autonomy and supervision allows operating a system that will have the necessary levels of autonomy to conduct its tasks and operations without requiring the intervention of the user and taking its own decisions (within its areas of concern and span of control) as how to perform and meet the user expectations in terms of performance and quality, while at the same time providing the proper level of supervision to satisfy the user requirements for reporting and escalation of relevant information.
3. 自律と監督。IBSの望ましい目標は、ユーザー側とシステム側の両方で高度な柔軟性と自由を提供することです。意図の声明と意図的な表現を、整形式で搾取可能な表現に改良することができます。自律性と監督の二重の原則は、ユーザーの介入を必要とせずにタスクと運用を実施するために必要な自律性のレベルを持つシステムを操作することを可能にし、どのようにユーザーの介入を必要とせず、それ自体の決定を下します（懸念の分野と制御の範囲内）パフォーマンスと品質の観点からユーザーの期待を実行および満たすと同時に、関連情報の報告とエスカレーションのためのユーザー要件を満たすために適切なレベルの監督を提供します。
4. Learning. An IBS is a learning system. In contrast to an imperative type of system, such as Event-Condition-Action policy rules, where the user defines beforehand the expected behavior of the system to various events and conditions, in an IBS, the user only declares what the system is supposed to achieve and not how to achieve these goals. There is thus a transfer of reasoning/ rationality from the human (domain knowledge) to the system. This transfer of cognitive capability also implies the availability in the IBS of capabilities or means for learning, reasoning, and knowledge representation and management. The learning abilities of an IBS can apply to different tasks such as optimization of the intent rendering or intent refinement processes. The fact that an IBS is a continuously evolving system creates the condition for continuous learning and optimization. Other cognitive capabilities such as planning can also be leveraged in an IBS to anticipate or forecast future system state and response to changes in intent or network conditions and thus elaboration of plans to accommodate the changes while preserving system stability and efficiency in a trade-off with cost and robustness of operations.
4. 学ぶ。 IBSは学習システムです。イベントの条件付きアクションポリシールールなどの命令的なタイプのシステムとは対照的に、ユーザーはシステムの予想される動作をさまざまなイベントおよび条件に事前に定義します。IBSでは、ユーザーはシステムが想定されるもののみを宣言します。これらの目標を達成する方法ではなく、達成します。したがって、人間（ドメイン知識）からシステムへの推論/合理性の転送があります。この認知能力の移転は、学習、推論、および知識の表現と管理のための能力または手段のIBSの可用性を意味します。 IBSの学習能力は、意図のレンダリングや洗練プロセスの最適化など、さまざまなタスクに適用できます。 IBSが継続的に進化するシステムであるという事実は、継続的な学習と最適化の条件を生み出します。計画などの他の認知機能は、IBSで活用して、将来のシステム状態と意図またはネットワーク条件の変化に対する応答を予測または予測することもできます。運用のコストと堅牢性。
5. Capability exposure. Capability exposure consists in the need for expressive network capabilities, requirements, and constraints to be able to compose/decompose intent and map the user's expectations to the system capabilities.
5. 機能エクスポージャー。能力エクスポージャーは、意図を構成/分解し、ユーザーの期待をシステム機能にマッピングできるように、表現力のあるネットワーク機能、要件、および制約の必要性で構成されています。
6. Abstract and outcome-driven. Users do not need to be concerned with how intent is achieved and are empowered to think in terms of outcomes. In addition, they can refer to concepts at a higher level of abstractions, independent, e.g., of vendor-specific renderings.
6. 抽象的および結果主導。ユーザーは、意図がどのように達成されるかに関心を持つ必要はなく、結果の観点から考える力が与えられます。さらに、ベンダー固有のレンダリングなど、より高いレベルの抽象化、たとえば独立した抽象化で概念を指すことができます。
The described principles are perhaps the most prominent, but they are not an exhaustive list. There are additional aspects to consider, such as:
記載されている原則はおそらく最も顕著ですが、それらは網羅的なリストではありません。次のような、考慮すべき追加の側面があります。
* Intent targets are not individual devices but typically aggregations (such as groups of devices adhering to a common criteria, such as devices of a particular role) or abstractions (such as service types, service instances, or topologies).
* 意図ターゲットは個々のデバイスではなく、通常、集約（特定の役割のデバイスなどの共通の基準を順守するデバイスのグループなど）または抽象化（サービスタイプ、サービスインスタンス、トポロジなど）です。
* Abstraction and inherent virtualization: agnostic to implementation details.
* 抽象化と固有の仮想化：実装の詳細への不可知論者。
* Human-tailored network interaction: IBN should speak the language of the user as opposed to requiring the user to speak the language of the device/network.
* ヒューマンテールネットワークの相互作用：IBNは、ユーザーにデバイス/ネットワークの言語を話すように要求するのではなく、ユーザーの言語を話す必要があります。
* Explainability as an important IBN function, detection and IBN-aided resolution of conflicting intent, and reconciliation of what the user wants and what the network can actually do.
* 重要なIBN関数、検出、IBN支援の矛盾する意図の解決、およびユーザーが望むものとネットワークが実際にできることの調整としての説明可能性。
* Inherent support, verification, and assurance of trust.
* 固有のサポート、検証、および信頼の保証。
All of these principles and considerations have implications on the design of IBSs and their supporting architecture. Accordingly, they need to be considered when deriving functional and operational requirements.
これらの原則と考慮事項はすべて、IBSSの設計とそのサポートアーキテクチャに影響を及ぼします。したがって、機能的および運用上の要件を導き出すときは、考慮する必要があります。
Intent-Based Networking involves a wide variety of functions that can be roughly divided into two categories:
意図ベースのネットワーキングには、2つのカテゴリにほぼ分割できるさまざまな機能が含まれます。
* Intent Fulfillment provides functions and interfaces that allow users to communicate intent to the network and that perform the necessary actions to ensure that intent is achieved. This includes algorithms to determine proper courses of action and functions that learn to optimize outcomes over time. In addition, it also includes functions such as any required orchestration of coordinated configuration operations across the network and rendering of higher-level abstractions into lower-level parameters and control knobs.
* Intent Fulfillmentは、ユーザーがネットワークに意図を通信できるようにし、意図が達成されることを保証するために必要なアクションを実行できる関数とインターフェイスを提供します。これには、時間の経過とともに結果を最適化することを学ぶアクションと機能の適切なコースを決定するアルゴリズムが含まれます。さらに、ネットワーク全体の調整された構成操作の必要なオーケストレーションや、低レベルの抽象化の低レベルパラメーターとコントロールノブへのレンダリングなどの関数も含まれます。
* Intent Assurance provides functions and interfaces that allow users to validate and monitor that the network is indeed adhering to and complying with intent. This is necessary to assess the effectiveness of actions taken as part of fulfillment, providing important feedback that allows those functions to be trained or tuned over time to optimize outcomes. In addition, Intent Assurance is necessary to address "intent drift." Intent is not meant to be transactional, i.e., "set and forget", but is expected to remain in effect over time (unless explicitly stated otherwise). Intent drift occurs when a system originally meets the intent, but over time gradually allows its behavior to change or be affected until it no longer does or does so in a less effective manner.
* Intent Assuranceは、ユーザーがネットワークが実際に順守し、意図を順守していることを検証および監視できる機能とインターフェイスを提供します。これは、履行の一環として取られたアクションの有効性を評価するために必要であり、結果を最適化するためにこれらの機能を時間の経過とともに訓練または調整できる重要なフィードバックを提供します。さらに、「意図ドリフト」に対処するには、意図保証が必要です。意図は、トランザクション、つまり「設定と忘れ」であることを意図したものではなく、時間の経過とともに有効であり続けることが期待されています（明示的に特に述べられていない限り）。システムが元々意図を満たしているときに意図ドリフトが発生しますが、時間の経過とともに、徐々にその動作が変化したり、影響を与えたり、効果的ではない方法で影響を受けることができます。
The following sections provide a more comprehensive overview of those functions.
次のセクションでは、これらの機能のより包括的な概要を説明します。
Intent fulfillment is concerned with the functions that take intent from its origination by a user (generally, an administrator of the responsible organization) to its realization in the network.
意図の履行は、ユーザー（一般的に、責任ある組織の管理者）がネットワークでの実現に至るまでの意図を引き受ける機能に関係しています。
The first set of functions is concerned with "ingesting" intent, i.e., obtaining intent through interactions with users. They provide functions that recognize intent from interaction with the user as well as functions that allow users to refine their intent and articulate it in such ways so that it becomes actionable by an IBS. Typically, those functions go beyond those provided by a non-intent-based API, although non-intent-based APIs may also still be provided (and needed for interactions beyond human users, i.e., with other machines). Many cases would also involve a set of intuitive and easy-to-navigate workflows that guide users through the intent ingestion phase, making sure that all inputs that are necessary for intent modeling and consecutive translation have been gathered. They may support unconventional human-machine interactions, in which a human will not simply give commands but instead a human-machine dialog is used to provide clarifications, to explain ramifications and trade-offs, and to facilitate refinements.
関数の最初のセットは、「摂取」意図、つまりユーザーとのやり取りを通じて意図を取得することに関係しています。ユーザーとのやり取りから意図を認識する関数と、ユーザーがIBSによって実行可能になるように意図を改良し、そのような方法で明確にする機能を提供します。通常、これらの関数は、非目的ベースのAPIによって提供される機能を超えていますが、非目的ベースのAPIも依然として提供されている可能性があります（そして、人間のユーザーを超えて、つまり他のマシンとの相互作用に必要です）。また、多くのケースには、意図的な摂取段階をユーザーに導く直感的で簡単にナビゲーションのワークフローのセットが含まれ、意図モデリングと連続翻訳に必要なすべての入力が収集されていることを確認します。彼らは、型破りなヒューマンマシンの相互作用をサポートする場合があります。この相互作用では、人間は単にコマンドを与えるのではなく、人間のマシンの対話を使用して、明確化を提供し、影響とトレードオフを説明し、改良を促進するために使用されます。
The goal is ultimately to make IBSs as easy and natural to use and interact with as possible, in particular allowing human users to interact with the IBS in ways that do not involve a steep learning curve that forces the user to learn the "language" of the system. Ideally, it will be the IBSs that are increasingly able to learn how to understand the user, as opposed to the other way around. Of course, further research will be required to make this a reality.
目標は、最終的にIBSSを可能な限り使いやすく、対話するのが簡単で自然なものにすることです。特に、人間のユーザーは、ユーザーにの「言語」を学習させる急な学習曲線を伴わないIBSと対話できるようにすることです。システム。理想的には、他の方法とは対照的に、ユーザーを理解する方法をますます学ぶことができるのはIBSSです。もちろん、これを実現するにはさらなる研究が必要になります。
A second set of functions needs to translate user intent into courses of action and requests to take against the network, which will be meaningful to network configuration and provisioning systems. These functions lie at the core of IBS, bridging the gap between interaction with users on the one hand and the management and operations side that will need to orchestrate provisioning and configuration across the network.
2番目の関数セットは、ユーザーの意図をアクションコースに変換し、ネットワークに対抗するリクエストを要求する必要があります。これは、ネットワークの構成とプロビジョニングシステムにとって意味があります。これらの機能はIBSの中核にあり、一方でユーザーとのやり取りと、ネットワーク全体でプロビジョニングと構成を調整する必要がある管理と運用の側面との間のギャップを埋めます。
Beyond merely breaking down a higher layer of abstraction (intent) into a lower layer of abstraction (policies and device configuration), Intent Translation functions can be complemented with functions and algorithms that perform optimizations and that are able to learn and improve over time in order to result in the best outcomes, specifically in cases where multiple ways of achieving those outcomes are conceivable. For example, satisfying an intent may involve computation of paths and other parameters that will need to be configured across the network. Heuristics and algorithms to do so may evolve over time to optimize outcomes that may depend on a myriad of dynamic network conditions and context.
抽象化（意図）のより高い層を抽象化の下層層（ポリシーとデバイスの構成）に分解するだけでなく、意図的な翻訳関数は、最適化を実行し、順序で時間の経過とともに学習および改善できる関数とアルゴリズムで補完できます。特に、これらの結果を達成する複数の方法が考えられる場合の場合の最良の結果をもたらすために。たとえば、意図を満たすには、ネットワーク全体で構成する必要があるパスやその他のパラメーターの計算が含まれる場合があります。そのためのヒューリスティックとアルゴリズムは、無数の動的ネットワーク条件とコンテキストに依存する可能性のある結果を最適化するために時間とともに進化する可能性があります。
A third set of functions deals with the actual configuration and provisioning steps that need to be orchestrated across the network and that were determined by the previous intent translation step.
関数の3番目のセットは、ネットワーク全体で調整する必要があり、以前の意図翻訳ステップによって決定された実際の構成とプロビジョニングステップを扱います。
Intent Assurance is concerned with the functions that are necessary to ensure that the network indeed complies with the desired intent once it has been fulfilled.
意図保証は、ネットワークが満たされると、ネットワークが望ましい意図に実際に準拠することを保証するために必要な機能に関係しています。
A first set of assurance functions monitors and observes the network and its exhibited behavior. This includes all the usual assurance functions such as monitoring the network for events and performance outliers, performing measurements to assess service levels that are being delivered, and generating and collecting telemetry data. Monitoring and observation are required as the basis for the next set of functions that assess whether the observed behavior is in fact in compliance with the behavior that is expected based on the intent.
最初の保証機能セットは、ネットワークとその展示された動作を監視し、観察します。これには、イベントやパフォーマンスの外れ値のネットワークの監視、配信されているサービスレベルを評価する測定の実行、テレメトリデータの生成と収集など、通常の保証関数がすべて含まれます。監視と観察は、観察された行動が実際に意図に基づいて予想される行動に準拠しているかどうかを評価する次の一連の関数の基礎として必要です。
At the core of Intent Assurance are functions that compare the actual network behavior that is being monitored and observed with the intended behavior that is expected per the intent and is held by SSoT. These functions continuously assess and validate whether the observation indicates compliance with intent. This includes assessing the effectiveness of intent fulfillment actions, including verifying that the actions had the desired effect and assessing the magnitude of the effect as applicable. It can also include functions that perform analysis and aggregation of raw observation data. The results of the assessment can be fed back to facilitate learning functions that optimize outcomes.
意図保証の中心にあるのは、意図ごとに予想され、SSOTによって保持される意図された動作と監視および観察されている実際のネットワーク動作を比較する関数です。これらの関数は、観察が意図への準拠を示しているかどうかを継続的に評価および検証します。これには、アクションが望ましい効果があることを確認し、該当する場合の効果の大きさを評価するなど、意図の履行行動の有効性の評価が含まれます。また、生の観測データの分析と集約を実行する関数を含めることもできます。評価の結果は、結果を最適化する学習機能を促進するために供給されます。
Intent compliance assessment also includes assessing whether intent drift occurs over time. Intent drift can be caused by a control plane or lower-level management operations that inadvertently cause behavior changes that conflict with intent that was orchestrated earlier. IBSs and Networks need to be able to detect when such drift occurs or is about to occur as well as assess the severity of the drift.
意図コンプライアンスの評価には、意図ドリフトが時間の経過とともに発生するかどうかの評価も含まれます。意図のドリフトは、コントロールプレーンまたは下位レベルの管理操作によって引き起こされる可能性があります。これは、以前に調整された意図と矛盾する行動の変化を不注意に引き起こします。IBSとネットワークは、そのようなドリフトがいつ発生したか、または発生しようとしているときに検出し、ドリフトの重症度を評価できる必要があります。
When intent drift occurs or network behavior is inconsistent with desired intent, functions that are able to trigger corrective actions are needed. This includes actions needed to resolve intent drift and bring the network back into compliance. Alternatively, and where necessary, reporting functions need to be triggered that alert operators and provide them with the necessary information and tools to react appropriately, e.g., by helping them articulate modifications to the original intent to moderate between conflicting concerns.
意図ドリフトが発生した場合、またはネットワークの動作が望ましい意図と矛盾する場合、是正措置をトリガーできる機能が必要です。これには、意図のドリフトを解決し、ネットワークをコンプライアンスに戻すために必要なアクションが含まれます。あるいは、必要に応じて、レポート機能をアラートオペレーターにトリガーし、適切に対応するために必要な情報とツールを提供する必要があります。
The outcome of Intent Assurance needs to be reported back to the user in ways that allow the user to relate the outcomes to their intent. This requires a set of functions that are able to analyze, aggregate, and abstract the results of the observations accordingly. In many cases, lower-level concepts such as detailed performance statistics and observations related to low-level settings need to be "up-leveled" to concepts the user can relate to and take action on.
意図保証の結果は、ユーザーが結果を意図に関連付けることができる方法でユーザーに報告する必要があります。これには、それに応じて観測の結果を分析、集約、抽象化できる一連の関数が必要です。多くの場合、詳細なパフォーマンス統計や低レベルの設定に関連する観察などの低レベルの概念は、ユーザーが関連し、行動を起こすことができる概念に「アップレベル」する必要があります。
The required aggregation and analysis functionality needs to be complemented with functions that report intent compliance status and provide adequate summarization and visualization to human users.
必要な集約および分析機能は、意図コンプライアンスステータスを報告し、人間のユーザーに適切な要約と視覚化を提供する機能で補完する必要があります。
Intent is subject to a life cycle: it comes into being, may undergo changes over the course of time, and may at some point be retracted. This life cycle is closely tied to various interconnection functions that are associated with the intent concept.
意図はライフサイクルの対象となります。それは、時間の経過とともに変化する可能性があり、ある時点で撤回される可能性があります。このライフサイクルは、意図の概念に関連付けられているさまざまな相互接続関数と密接に結びついています。
Figure 1 depicts an intent life cycle and its main functions. The functions were introduced in Section 5 and are divided into two functional (horizontal) planes reflecting the distinction between fulfillment and assurance. In addition, they are divided into three (vertical) spaces.
図1は、意図のライフサイクルとその主な機能を示しています。機能はセクション5で導入され、充足と保証の区別を反映して、2つの機能的な（水平）平面に分割されます。さらに、それらは3つの（垂直）スペースに分割されます。
The spaces indicate the different perspectives and interactions with different roles that are involved in addressing the functions:
スペースは、機能の対処に関与するさまざまな視点と相互作用を示しています。
* The User Space involves the functions that interface the network and IBS with the human user. It involves the functions that allow users to articulate and the IBS to recognize that intent. It also involves the functions that report back the status of the network relative to the intent and that allow users to assess outcomes and whether their intent has the desired effect.
* ユーザースペースには、ネットワークとIBSがヒューマンユーザーとインターフェイスする機能が含まれます。これには、ユーザーが明確にし、IBSがその意図を認識できるようにする機能が含まれます。また、意図に対するネットワークのステータスを報告し、ユーザーが結果を評価できるようにする機能と、その意図が望ましい効果をもたらすかどうかを伴います。
* The Translation, or Intent-Based System (IBS) Space involves the functions that bridge the gap between intent users and the network operations infrastructure. This includes the functions used to translate an intent into a course of action as well as the algorithms that are used to plan and optimize those courses of action also in consideration of feedback and observations from the network. It also includes the functions to analyze and aggregate observations from the network in order to validate compliance with the intent and to take corrective actions as necessary. In addition, it includes functions that abstract observations from the network in ways that relate them to the intent as communicated by users. This facilitates the reporting functions in the user space.
* 翻訳、または意図ベースのシステム（IBS）スペースには、意図ユーザーとネットワークオペレーションインフラストラクチャの間のギャップを埋める機能が含まれます。これには、意図をアクションコースに変換するために使用される機能と、ネットワークからのフィードバックと観測を考慮して、これらのアクションコースを計画および最適化するために使用されるアルゴリズムが含まれます。また、意図のコンプライアンスを検証し、必要に応じて是正措置を講じるために、ネットワークからの観測を分析および集約する機能も含まれています。さらに、ネットワークからの観測を抽象化する機能が、ユーザーが通信する意図に関連付ける機能を含みます。これにより、ユーザースペースのレポート機能が容易になります。
* The Network Operations Space, finally, involves orchestration, configuration, monitoring, and measurement functions, which are used to effectuate the rendered intent and observe its effects on the network.
* 最後に、ネットワーク操作スペースには、オーケストレーション、構成、監視、測定機能が含まれます。これらは、レンダリングされた意図を影響し、ネットワークに対する影響を観察するために使用されます。
User Space : Translation / IBS : Network Ops
: Space : Space
: :
+----------+ : +----------+ +-----------+ : +-----------+
Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/|
|generate | | | | plan/ | | provision |
|intent |<--- | refine | | render | : | |
+----^-----+ : +----------+ +-----^-----+ : +-----------+
| : | : |
.............|................................|................|.....
| : +----+---+ : v
| : |validate| : +----------+
| : +----^---+ <----| monitor/ |
Assure +---+---+ : +---------+ +-----+---+ : | observe/ |
|report | <---- |abstract |<---| analyze | <----| |
+-------+ : +---------+ |aggregate| : +----------+
: +---------+ :
Figure 1: Intent Life Cycle
図1：意図的なライフサイクル
When carefully inspecting the diagram, it becomes apparent that the intent life cycle, in fact, involves two cycles, or loops:
図を慎重に検査すると、実際には意図的なライフサイクルには2つのサイクルまたはループが含まれていることが明らかになります。
* The "inner" intent control loop between IBS and Network Operations space is completely autonomic and does not involve any human in the loop. It represents closed-loop automation that involves automatic analysis and validation of intent based on observations from the network operations space. Those observations are fed into the function that plans the rendering of networking intent in order to make adjustments as needed in the configuration of the network. The loop addresses and counteracts any intent drift that may be occurring, using observations to assess the degree of the network's intent compliance and automatically prompting actions to address any discrepancies. Likewise, the loop allows to assess the effectiveness of any actions that are taken in order to continuously learn and improve how intent needs to be rendered in order to achieve the desired outcomes.
* IBSとネットワーク操作スペースの間の「内部」意図制御ループは完全に自律的であり、ループ内の人間は関与していません。これは、ネットワーク操作スペースからの観測に基づいて、自動分析と意図の検証を含む閉ループオートメーションを表します。これらの観察結果は、ネットワークの構成で必要に応じて調整を行うためにネットワーク意図のレンダリングを計画する関数に供給されます。ループは、発生している可能性のある意図ドリフトに対処し、対処し、観測を使用してネットワークの意図コンプライアンスの程度を評価し、矛盾に対処するためのアクションを自動的に促します。同様に、ループは、望ましい結果を達成するために、意図を継続的に学習および改善するために継続的に学習および改善するために行われるアクションの有効性を評価できます。
* The "outer" intent control loop extends to the user space. It includes the user taking action and adjusting their intent based on observations and feedback from the IBS. Intent is thus subjected to a life cycle: It comes into being, may undergo refinements, modifications, and changes of time, and may at some point in time even get retracted.
* 「外側」意図制御ループは、ユーザースペースに拡張されます。これには、ユーザーがアクションを実行し、IBSからの観察とフィードバックに基づいて意図を調整することが含まれます。したがって、意図はライフサイクルにさらされます。それは存在し、改良、修正、時間の変化を受ける可能性があり、ある時点で撤回される可能性があります。
Given the popularity of the term "intent," it is tempting to broaden its use to encompass other related concepts, resulting in "intent-washing" that paints those concepts in a new light by simply applying new intent terminology to them. A common example concerns referring to the northbound interface of SDN controllers as "intent interface." However, in some cases, this actually makes sense not just as a marketing ploy but as a way to better relate previously existing and new concepts.
「意図」という用語の人気を考えると、他の関連する概念を包含するための使用を拡大することは魅力的であり、その結果、新しい意図の用語を単に適用することでそれらの概念を新しい観点から描く「意図的な洗浄」をもたらします。一般的な例は、SDNコントローラーの北行きのインターフェイスを「意図インターフェイス」と呼ぶことに関するものです。ただし、場合によっては、これは実際にはマーケティングの策略としてだけでなく、以前の既存の概念や新しい概念をよりよく関連付ける方法として理にかなっています。
In that sense and with regards to intent, it makes sense to distinguish various subcategories of intent as follows:
その意味で、意図に関しては、次のように、意図のさまざまなサブカテゴリを区別することは理にかなっています。
Operational Intent: defines intent related to operational goals of an operator; it corresponds to the original "intent" term and the concepts defined in this document.
運用上の意図：オペレーターの運用目標に関連する意図を定義します。これは、元の「意図」用語と、このドキュメントで定義されている概念に対応します。
Rule Intent: a synonym for policy rules regarding what to do when certain events occur.
ルールの意図：特定のイベントが発生したときに何をすべきかに関するポリシールールの同義語。
Service Intent: a synonym for customer service model [RFC8309].
サービスの意図：カスタマーサービスモデルの同義語[RFC8309]。
Flow Intent: a synonym for a Service Level Objective for a given flow.
フロー意図：特定のフローのサービスレベルの目的の同義語。
A comprehensive set of classifications of different concepts and categories of intent will be described in a separate document.
さまざまな概念と意図のカテゴリの包括的な分類セットについては、別のドキュメントで説明します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document describes concepts and definitions of Intent-Based Networking. As such, the below security considerations remain high level, i.e., in the form of principles, guidelines, or requirements. More detailed security considerations will be described in the documents that specify the architecture and functionality.
このドキュメントでは、意図ベースのネットワーキングの概念と定義について説明します。そのため、以下のセキュリティ上の考慮事項は、原則、ガイドライン、または要件の形で高いレベルのままです。より詳細なセキュリティ上の考慮事項は、アーキテクチャと機能を指定するドキュメントで説明されています。
Security in Intent-Based Networking can apply to different facets:
意図ベースのネットワーキングのセキュリティは、さまざまなファセットに適用できます。
* Securing the IBS itself.
* IBS自体を確保します。
* Mitigating the effects of erroneous, harmful, or compromised intent statements.
* 誤った、有害、または侵害された意図的な声明の影響を軽減します。
* Expressing security policies or security-related parameters with intent statements.
* 意図的なステートメントを含むセキュリティポリシーまたはセキュリティ関連のパラメーターを表現します。
Securing the IBS aims at making the IBS operationally secure by implementing security mechanisms and applying security best practices. In the context of Intent-Based Networking, such mechanisms and practices may consist of intent verification and validation, operations on intent by authenticated and authorized users only, and protection against or detection of tampered statements of intent. Such mechanisms may also include the introduction of multiple levels of intent. For example, intent related to securing the network should occur at a "deeper" level that overrides other levels of intent if necessary, and that is not subject to modification through regular operations but through ones that are specifically secured. Use of additional mechanisms such as explanation components that describe the security ramifications and trade-offs should be considered as well.
IBSのセキュリティは、セキュリティメカニズムを実装し、セキュリティベストプラクティスを適用することにより、IBSを動作的に安全にすることを目指しています。意図ベースのネットワーキングのコンテキストでは、そのようなメカニズムと実践は、意図の検証と検証、認証された認定ユーザーのみによる意図の操作、および改ざんされた意図の声明に対する保護または検出で構成される場合があります。このようなメカニズムには、複数のレベルの意図の導入も含まれる場合があります。たとえば、ネットワークのセキュリティに関連する意図は、必要に応じて他のレベルの意図をオーバーライドする「より深い」レベルで発生する必要があります。これは、通常の操作ではなく、特異的に保護されている操作を介して変更されません。セキュリティの影響やトレードオフを説明する説明コンポーネントなどの追加のメカニズムの使用も考慮する必要があります。
Mitigating the effects of erroneous or compromised statements of intent aims at making the IBS operationally safe by providing checkpoint and safeguard mechanisms and operating principles. In the context of Intent-Based Networking, such mechanisms and principles may consist of the ability to automatically detect unintended, detrimental, or abnormal behavior; the ability to automatically (and gracefully) roll back or fall back to a previous "safe" state; the ability to prevent or contain error amplification (due to the combination of a higher degree of automation and the intrinsic higher degree of freedom, ambiguity, and implicit information conveyed by intent statements); and dynamic levels of supervision and reporting to make the user aware of the right information at the right time with the right level of context. Erroneous or harmful intent statements may inadvertently propagate and compromise security. In addition, compromised intent statements (for example, forged by an inside attacker) may sabotage or harm the network resources and make them vulnerable to further, larger attacks, e.g., by defeating certain security mechanisms.
誤ったまたは妥協した意図の声明の影響を軽減することは、チェックポイントと保護メカニズムと運用原則を提供することにより、IBSを運用上安全にすることを目的としています。意図ベースのネットワーキングのコンテキストでは、そのようなメカニズムと原則は、意図しない、有害、または異常な行動を自動的に検出する能力で構成されている可能性があります。自動的に（そして優雅に）ロールバックするか、以前の「安全な」状態に戻る能力。エラー増幅を防止または封じ込める能力（高度の自動化と、意図的な声明によって伝えられる本質的な高度の自由度、曖昧さ、暗黙の情報の組み合わせによる）。適切なレベルのコンテキストで適切なタイミングで適切な情報をユーザーに認識させるための動的レベルの監督と報告。誤ったまたは有害な意図的な声明は、セキュリティを誤って伝播し、妥協する可能性があります。さらに、侵害された意図的な声明（たとえば、内部攻撃者によって偽造された）は、ネットワークリソースを妨害または損害し、特定のセキュリティメカニズムを打ち負かすことにより、さらに大きな攻撃に対して脆弱にする可能性があります。
Expressing security policies or security-related parameters as intent consists of using the intent formalism (a high-level, declarative abstraction) or part(s) of an intent statement to define security-related aspects such as:
セキュリティポリシーまたはセキュリティ関連のパラメーターを意図として表現することは、意図形式主義（高レベル、宣言的抽象化）または意図的なステートメントの一部を使用して、次のようなセキュリティ関連の側面を定義することで構成されています。
* data governance;
* データガバナンス。
* level(s) of confidentiality in data exchange;
* データ交換における機密性のレベル。
* level(s) of availability of system resources, of protection in forwarding paths, and of isolation in processing functions;
* システムリソースの可用性、転送パスの保護、および処理機能の分離のレベル。
* level(s) of encryption; and
* 暗号化のレベル。と
* authorized entities for given operations.
* 指定されたオペレーションの許可されたエンティティ。
The development and introduction of Intent-Based Networking in operational environments will certainly create new security concerns. Such security concerns have to be anticipated at the design and specification time. However, Intent-Based Networking may also be used as an enabler for better security. For instance, security and privacy rules could be expressed in a more human-friendly and generic way and be less technology specific and less complex, leading to fewer low-level configuration mistakes. The detection of threats or attacks could also be made more simple and comprehensive thanks to conflict detection at higher level or at coarser granularity.
運用環境での意図ベースのネットワーキングの開発と導入は、確かに新しいセキュリティ上の懸念を生み出します。このようなセキュリティの懸念は、設計と仕様の時間に予想される必要があります。ただし、意図ベースのネットワーキングは、セキュリティを向上させるためのイネーブラーとしても使用できます。たとえば、セキュリティとプライバシーのルールは、より人間に優しい方法で一般的な方法で表現でき、テクノロジーに具体的で複雑ではなく、低レベルの構成のミスが少なくなります。脅威または攻撃の検出は、より高いレベルまたはより粗い粒度での紛争検出のおかげで、より単純で包括的なものにすることもできます。
More thorough security analyses should be conducted as our understanding of Intent-Based Networking technology matures.
意図ベースのネットワーキングテクノロジーの理解が成熟するにつれて、より徹底的なセキュリティ分析を実施する必要があります。
[BOUTABA07] Boutaba, R. and I. Aib, "Policy-Based Management: A Historical Perspective", Journal of Network and Systems Management (JNSM), Vol. 15, Issue 4, DOI 10.1007/s10922-007-9083-8, November 2007, <https://doi.org/10.1007/s10922-007-9083-8>.
[Boutaba07] Boutaba、R。およびI. AIB、「政策ベースの管理：歴史的視点」、Journal of Network and Systems Management（JNSM）、Vol。15、第4号、DOI 10.1007/s10922-007-9083-8、2007年11月、<https://doi.org/10.1007/S10922-007-9083-8>。
[CLEMM20] Clemm, A., Faten Zhani, M., and R. Boutaba, "Network Management 2030: Operations and Control of Network 2030 Services", Journal of Network and Systems Management (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0, October 2020, <https://doi.org/10.1007/s10922-020-09517-0>.
[Clemm20] Clemm、A.、Faten Zhani、M。、およびR. Boutaba、「ネットワーク管理2030：ネットワーク2030サービスの運用と制御」、Journal of Network and Systems Management（JNSM）、Vol。28、第4号、DOI 10.1007/s10922-020-09517-0、2020年10月、<https://doi.org/10.1007/S10922-020-09517-0>。
[GHARBAOUI21] Gharbaoui, M., Martini, B., and P. Castoldi, "Implementation of an Intent Layer for SDN-enabled and QoS-Aware Network Slicing", 2021 IEEE 7th International Conference on Network Softwarization (NetSoft), pp. 17-23, DOI 10.1109/NetSoft51509.2021.9492643, June 2021, <https://doi.org/10.1109/NetSoft51509.2021.9492643>.
[Gharbaoui21] Gharbaoui、M.、Martini、B。、およびP. Castoldi、「SDN対応およびQoS-Awareネットワークスライスの意図層の実装」、2021 IEEE第7回ネットワークソフトウェア化に関する国際会議（Netsoft）、pp。17-23、doi 10.1109/netsoft51509.2021.9492643、2021年6月、<https://doi.org/10.1109/Netsoft51509.2021.9492643>。
[IEEE-TITS21] Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad, N., and R. R. V. Prasad, "Guest Editorial Special Issue on Intent-Based Networking for 5G-Envisioned Internet of Connected Vehicles", IEEE Transactions on Intelligent Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017, DOI 10.1109/TITS.2021.3101259, August 2021, <https://doi.org/10.1109/TITS.2021.3101259>.
[IEEE-TITS21] Garg、S.、Guizani、M.、Liang、Y-C。、Granelli、F.、Prasad、N.、およびR. R. V. Prasad、「5G拡張された5Gが拡大したインターネットのインターネントベースのネットワーキングに関するゲスト編集特別問題」コネクテッドビークル」、IEEEトランザクションに関するインテリジェント輸送システム、Vol。22、第8号、pp。5009-5017、doi 10.1109/tits.2021.3101259、2021年8月、<https://doi.org/10.1109/tits.2021.3101259>。
[IEEEXPLORE] IEEE, "IEEE Xplore", <https://ieeexplore.ieee.org/>.
[IEEExPlore] IEEE、 "IEEE XPLORE"、<https://ieeexplore.ieee.org/>。
[LENROW15] Lenrow, D., "Intent As The Common Interface to Network Resources", Intent Based Network Summit 2015 ONF Boulder: IntentNBI, February 2015.
[Lenrow15] Lenrow、D。、「ネットワークリソースへの共通インターフェイスとしての意図」、Intent Based Network Summit 2015 ONF Boulder：Intentnbi、2015年2月。
[M3010] ITU-T, "Principles for a telecommunications management network", ITU-T Recommendation M.3010, February 2000.
[M3010] ITU-T、「電気通信管理ネットワークの原則」、ITU-T推奨M.3010、2000年2月。
[NETWORK-SLICE] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3 August 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-14>.
[Network-Slice] Farrel、A.、Ed。、Drake、J.、Ed。、Rokui、R.、Homma、S.、Makhijani、K.、Contreras、L。M.、およびJ. Tantsura、 "Framework for IETF Networkスライス」、進行中の作業、インターネットドラフト、ドラフト-ITEAS-IITF-NETWORK-SLICES-14、2022年8月3日、<https://datatracker.ietf.org/doc/html/draft-ietf-teas--ietf-network-slices-14>。
[PANG20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, "A Survey on Intent-Driven Networks", IEEE Access, Vol. 8, pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January 2020, <https://doi.org/10.1109/ACCESS.2020.2969208>.
[Pang20] Pang、L.、Yang、C.、Chen、D.、Song、Y.、およびM. Guizan、「Intent駆動型ネットワークに関する調査」、IEEE Access、vol。8、pp.22862-22873、doi 10.1109/access.2020.2969208、2020年1月、<https://doi.org/10.1109/access.2020.2969208>。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、Std 62、RFC 3411、DOI 10.17487/RFC3411、2002年12月、<：//www.rfc-editor.org/info/rfc3411>。
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.
[RFC7575] Behringer、M.、Pritikin、M.、Bjarnason、S.、Clemm、A.、Carpenter、B.、Jiang、S.、およびL. Ciavaglia、「自律的ネットワーキング：定義と設計目標」、RFC 7575、doi 10.17487/rfc7575、2015年6月、<https://www.rfc-editor.org/info/rfc7575>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.
[RFC8299] Wu、Q.、Ed。、Litkowski、S.、Tomotaki、L。、およびK. Ogaki、「L3VPNサービス提供のYangデータモデル」、RFC 8299、DOI 10.17487/RFC8299、2018年1月、<HTTPS：//www.rfc-editor.org/info/rfc8299>。
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.
[RFC8309] Wu、Q.、Liu、W。、およびA. Farrel、「サービスモデルの説明」、RFC 8309、DOI 10.17487/RFC8309、2018年1月、<https://www.rfc-editor.org/info/RFC8309>。
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8345] Clemm、A.、Medved、J.、Varga、R.、Bahadur、N.、Ananthakrishnan、H。、およびX. Liu、「ネットワークトポロジーのヤンデータモデル」、RFC 8345、DOI 10.17487/RFC8345555555555555555、2018年3月、<https://www.rfc-editor.org/info/rfc8345>。
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.
[RFC8994] Eckert、T.、Ed。、Behringer、M.、ed。、およびS. Bjarnason、「An Autonomic Control Plane（ACP）」、RFC 8994、DOI 10.17487/RFC8994、2021年5月、<https：///////////www.rfc-editor.org/info/rfc8994>。
[SERVICE-MAPPING-YANG] Lee, Y., Ed., Dhody, Dhruv., Ed., Fioccola, G., Wu, Q., Ed., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-11, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-11>.
[Service-Mapping-Yang] Lee、Y.、ed。、Dhody、Dhruv。、ed。、Fioccola、G.、Wu、Q.、ed。、Ceccarelli、D。、およびJ. Tantsura、 "Traffic Engineering（TE）およびサービスマッピングYangデータモデル」、作業中の進行中、インターネットドラフト、ドラフト-ITES-TES-Service-Mapping-Yang-11、2022年7月11日、<https://datatracker.ietf.org/doc/html/draft-iitf-teas-te-service-mapping-yang-ang-11>。
[SLOMAN94] Sloman, M., "Policy Driven Management for Distributed Systems", Journal of Network and Systems Management (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994.
[Sloman94] Sloman、M。、「分散システムのポリシー主導型管理」、Journal of Network and Systems Management（JNSM）、Vol。2、第4号、pp。333-360、1994年12月。
[STRASSNER03] Strassner, J., "Policy-Based Network Management", August 2003.
[Strassner03] Strassner、J。、「ポリシーベースのネットワーク管理」、2003年8月。
[TR523] Open Networking Foundation, "Intent NBI - Definition and Principles", ONF TR-523, October 2016.
[TR523] Open Networking Foundation、「Intent NBI-定義と原則」、ONF TR -523、2016年10月。
[WIN21] Ciavaglia, L. and E. Renault, "1st International Workshop on Intent-Based Networking", IEEE International Conference on Network Softwarization, June 2021, <https://netsoft2021.ieee-netsoft.org/program/workshops/ win-2021/>.
[Win21] Ciavaglia、L。and E. Renault、「Intentベースのネットワーキングに関する第1回国際ワークショップ」、IEEE Network Softwarizationに関する国際会議、2021年6月、<https://netsoft2021.ieee-netsoft.org/program/workshops/Win-2021/>。
Acknowledgments
謝辞
We would like to thank the members of the IRTF Network Management Research Group (NMRG) for many valuable discussions and feedback. In particular, we would like to acknowledge the feedback and support from Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu Song, Peter Szilagyi, and Csaba Vulkan. Of those, we would like to thank the following persons who went one step further and also provided reviews of the document: Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, Peter Szilagyi, and Csaba Vulkan.
多くの貴重な議論とフィードバックについて、IRTFネットワーク管理研究グループ（NMRG）のメンバーに感謝します。特に、レミ・バドンネル、ウォルター・セロニ、マリノス・チャラランビデス、ルイス・コントレラス、ジェローム・フランソワ、モルカ・ガルバウイ、オルガ・ハヴェル、チェン・リー、ウィリアム・リュー、バーバラ・マティーニ、ステフェン・ムワンジェ、ジェイフェーソン・ノブレ、ハイオー・ノブレのフィードバックとサポートを認めたいと思います。歌、ピーター・シラギー、およびcsaba vulkan。それらのうち、私たちは、さらに一歩進んで、レミ・バドンネル、ウォルター・セロニ、ジェローム・フランソワ、モルカ・ガルバウイ、バーバラ・マティーニ、スティーブン・ムワンジー、ピーター・シラギー、およびCsaba Vulkanなどのレビューを提供してくれた次の人に感謝したいと思います。
Authors' Addresses
著者のアドレス
Alexander Clemm Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America Email: ludwig@clemm.org
Alexander Clemm Futurewei 2330 Central Expressway Santa Clara、CA 95050 United States of America：ludwig@clemm.org
Laurent Ciavaglia Nokia Route de Villejust 91620 Nozay France Email: laurent.ciavaglia@nokia.com
Laurent Ciavaglia Nokia Route de Villejust 91620 Nozay Franceメール：laurent.ciavaglia@nokia.com
Lisandro Zambenedetti Granville Federal University of Rio Grande do Sul (UFRGS) Av. Bento Gonçalves Porto Alegre-RS 9500 Brazil Email: granville@inf.ufrgs.br
Lisandro Zambenedetti Granville Federal University of Rio Grande do Sul（UFRGS）av。BentoGonçalvesPorto Alegre-RS 9500 Brazilメール：granville@inf.ufrgs.br
Jeff Tantsura Microsoft Email: jefftant.ietf@gmail.com
Jeff Tantsura Microsoftメール：jefftant.ietf@gmail.com