[要約] RFC 8993は自律型ネットワーキングのための参照モデルを定義しており、ネットワークの自己管理機能を強化することを目的としています。このモデルは、効率的な運用、自己修復、自己最適化などの機能を自動化するために利用されます。
Internet Engineering Task Force (IETF) M. Behringer, Ed.
Request for Comments: 8993
Category: Informational B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
T. Eckert
Futurewei USA
L. Ciavaglia
Nokia
J. Nobre
UFRGS
May 2021
A Reference Model for Autonomic Networking
自律ネットワーキングのための参照モデル
Abstract
概要
This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.
この文書では、管理対象ネットワークの自律ネットワーキングのための参照モデルについて説明します。それは自律ノードの動作を定義し、自律本的なコンテキスト内のさまざまな要素はどのように機能するか、および自律神経サービスをインフラストラクチャを使用できる方法を定義します。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。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/rfc8993.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8993で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Network View
3. Autonomic Network Element
3.1. Architecture
3.2. Adjacency Table
3.3. State Machine
3.3.1. State 1: Factory Default
3.3.2. State 2: Enrolled
3.3.3. State 3: In ACP
4. Autonomic Networking Infrastructure
4.1. Naming
4.2. Addressing
4.3. Discovery
4.4. Signaling between Autonomic Nodes
4.5. Routing
4.6. Autonomic Control Plane
4.7. Information Distribution (*)
5. Security and Trust Infrastructure
5.1. Public Key Infrastructure
5.2. Domain Certificate
5.3. MASA
5.4. Subdomains (*)
5.5. Cross-Domain Functionality (*)
6. Autonomic Service Agents (ASAs)
6.1. General Description of an ASA
6.2. ASA Life-Cycle Management
6.3. Specific ASAs for the Autonomic Networking Infrastructure
6.3.1. Enrollment ASAs
6.3.2. ACP ASA
6.3.3. Information Distribution ASA (*)
7. Management and Programmability
7.1. Managing a (Partially) Autonomic Network
7.2. Intent (*)
7.3. Aggregated Reporting (*)
7.4. Feedback Loops to NOC (*)
7.5. Control Loops (*)
7.6. APIs (*)
7.7. Data Model (*)
8. Coordination between Autonomic Functions (*)
8.1. Coordination Problem (*)
8.2. Coordination Functional Block (*)
9. Security Considerations
9.1. Protection against Outsider Attacks
9.2. Risk of Insider Attacks
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The document "Autonomic Networking: Definitions and Design Goals" [RFC7575] explains the fundamental concepts behind Autonomic Networking and defines the relevant terms in this space and a high-level reference model. [RFC7576] provides a gap analysis between traditional and autonomic approaches.
文書「自律ネットワーキング：定義と設計目標」[RFC7575]は、自律ネットワーキングの背後にある基本的な概念と、このスペースの関連用語と高レベルの参照モデルを定義します。[RFC7576]は、伝統的なアプローチと自律神経的アプローチの間のギャップ分析を提供します。
This document defines this reference model with more detail to allow for functional and protocol specifications to be developed in an architecturally consistent, non-overlapping manner.
この文書は、機能的およびプロトコルの仕様がアーキテクチャ的に一貫した非重複する方法で開発されることを可能にするために、この参照モデルをより詳細に定義しています。
As discussed in [RFC7575], the goal of this work is not to focus exclusively on fully autonomic nodes or networks. In reality, most networks will run with some autonomic functions, while the rest of the network is traditionally managed. This reference model allows for this hybrid approach.
[RFC7575]で説明したように、この作業の目的は完全自律型ノードまたはネットワークに専ら集中しないことです。実際には、ほとんどのネットワークはいくつかの自律型関数で実行され、一方ネットワークの残りの部分は伝統的に管理されています。この参照モデルはこのハイブリッドアプローチを可能にします。
For example, it is possible in an existing, non-autonomic network to enroll devices in a traditional way to bring up a trust infrastructure with certificates. This trust infrastructure could then be used to automatically bring up an Autonomic Control Plane (ACP) and run traditional network operations over the secure and self-healing ACP. See [RFC8368] for a description of this use case.
たとえば、既存の非自律型ネットワークでは、従来の方法でデバイスを登録して証明書との信頼インフラストラクチャを起動することが可能です。この信頼インフラストラクチャを使用して自動的に自律型制御プレーン（ACP）を起動し、安全で自己修復ACPを介して従来のネットワーク操作を実行することができます。このユースケースの説明については、[RFC8368]を参照してください。
The scope of this model is therefore limited to networks that are to some extent managed by skilled human operators, loosely referred to as "professionally managed" networks. Unmanaged networks raise additional security and trust issues that this model does not cover.
したがって、このモデルの範囲は、「専門的に管理されている」ネットワークと疎まつぼての熟練した人間演算子によって管理されているネットワークに限定されています。管理対象外ネットワークは、このモデルがカバーしていない追加のセキュリティと信頼の問題を引き上げます。
This document describes the first phase of an Autonomic Networking solution that is both simple and implementable. It is expected that the experience from this phase will be used in defining updated and extended specifications over time. Some topics are considered architecturally in this document but are not yet reflected in the implementation specifications. They are marked with an (*).
この文書では、簡単で実装可能な自律技術ネットワーキングソリューションの最初のフェーズについて説明します。この段階からの経験は、時間の経過とともに更新され拡張仕様の定義に使用されます。このドキュメントでは、一部のトピックはアーキテクチャであると考えられていますが、実装仕様にはまだ反映されていません。それらは（*）でマークされています。
This section describes the various elements in a network with autonomic functions and explains how these entities work together on a high level. Subsequent sections explain the detailed inside view for each of the Autonomic Network elements, as well as the network functions (or interfaces) between those elements.
このセクションでは、自律型機能を持つネットワーク内のさまざまな要素について説明し、これらのエンティティがハイレベルでどのように機能するかを説明します。後続のセクションでは、各自律型ネットワーク要素の詳細な内側ビュー、およびそれらの要素間のネットワーク機能（またはインタフェース）について説明します。
Figure 1 shows the high-level view of an Autonomic Network. It consists of a number of autonomic nodes, which interact directly with each other. Those autonomic nodes provide a common set of capabilities across the network, called the "Autonomic Networking Infrastructure (ANI)". The ANI provides functions like naming, addressing, negotiation, synchronization, discovery, and messaging.
図1は、自律型ネットワークの高度なビューを示しています。それは互いに直接対話する多数の自律型ノードで構成されています。これらのオートノミックノードは、「自律ネットワーキングインフラストラクチャ（ANI）」と呼ばれる、ネットワーク全体に共通の機能セットを提供します。ANIは、命名、アドレス指定、ネゴシエーション、同期、検出、およびメッセージングなどの機能を提供します。
Autonomic functions typically span several, possibly all, nodes in the network. The atomic entities of an autonomic function are called the "Autonomic Service Agents (ASAs)", which are instantiated on nodes.
自律神経機能は通常、ネットワーク内のいくつかの、場合によってはすべてのノードにまたがっています。自律型関数のアトミックエンティティは、ノード上でインスタンス化されている「自律型サービスエージェント（ASAS）」と呼ばれます。
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : Autonomic Function 1 : :
: ASA 1 : ASA 1 : ASA 1 : ASA 1 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : :
: +- - - - - - - - - - - - - - + :
: : Autonomic Function 2 : :
: : ASA 2 : ASA 2 : :
: +- - - - - - - - - - - - - - + :
: : :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: Autonomic Networking Infrastructure :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+ : +--------+ : +--------+ : +--------+
| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
+--------+ : +--------+ : +--------+ : +--------+
Figure 1: High-Level View of an Autonomic Network
図1：自律網の高水準図
In a horizontal view, autonomic functions span across the network, as well as the ANI. In a vertical view, a node always implements the ANI, plus it may have one or several ASAs. ASAs may be standalone or use other ASAs in a hierarchical way.
水平方向のビューでは、ANIだけでなく、ネットワーク全体にわたる自律型関数が及びます。垂直方向のビューでは、ノードは常にANIを実装し、さらにそれが1つまたは複数のASAを持つことがあります。ASASはスタンドアロンであるか、他のASAを階層的に使用することができます。
Therefore, the ANI is the foundation for autonomic functions.
したがって、ANIは自律型関数の基礎です。
This section explains the general architecture of an Autonomic Network element (Section 3.1), how it tracks its surrounding environment in an adjacency table (Section 3.2), and the state machine that defines the behavior of the network element (Section 3.3), based on that adjacency table.
このセクションでは、Autonomic Network Element（セクション3.1）、隣接テーブル（セクション3.2）内のその周囲の環境の追跡、およびネットワーク要素の動作を定義するステートマシン（セクション3.3）の一般的なアーキテクチャについて説明します。その隣接テーブル。
This section describes an Autonomic Network element and its internal architecture. The reference model explained in the document "Autonomic Networking: Definitions and Design Goals" [RFC7575] shows the sources of information that an ASA can leverage: self-knowledge, network knowledge (through discovery), Intent (see Section 7.2), and feedback loops. There are two levels inside an autonomic node: the level of ASAs and the level of the ANI, with the former using the services of the latter. Figure 2 illustrates this concept.
このセクションでは、自律型ネットワーク要素とその内部アーキテクチャについて説明します。文書「自律ネットワーキング：定義と設計目標」で説明されている参照モデル[RFC7575]は、ASAが活用できる情報の情報源を示しています。ループ。自律ノードには2つのレベルがあります。前者のサービスを使用して、ASAのレベルとANIのレベル。図2はこの概念を示しています。
+------------------------------------------------------------+
| |
| +-----------+ +------------+ +------------+ |
| | Autonomic | | Autonomic | | Autonomic | |
| | Service | | Service | | Service | |
| | Agent 1 | | Agent 2 | | Agent 3 | |
| +-----------+ +------------+ +------------+ |
| ^ ^ ^ |
| - - | - - API level - -| - - - - - - - |- - - |
| V V V |
|------------------------------------------------------------|
| Autonomic Networking Infrastructure |
| - Data structures (ex: certificates, peer information) |
| - Generalized Autonomic Control Plane (GACP) |
| - Autonomic node addressing and naming |
| - Discovery, negotiation and synchronization functions |
| - Distribution of Intent and other information |
| - Aggregated reporting and feedback loops |
| - Routing |
|------------------------------------------------------------|
| Basic Operating System Functions |
+------------------------------------------------------------+
Figure 2: Model of an Autonomic Node
図2：自律ノードのモデル
The ANI (lower part of Figure 2) contains node-specific data structures (for example, trust information about itself and its peers) as well as a generic set of functions, independent of a particular usage. This infrastructure should be generic and support a variety of ASAs (upper part of Figure 2). It contains addressing and naming of autonomic nodes, discovery, negotiation and synchronization functions, distribution of information, reporting, feedback loops, and routing inside the ACP.
ANI（図2の下部）は、特定の使用法とは無関係に、ノード固有のデータ構造（自分自身とそのピアに関する信頼情報）と一般的な関数のセットを含みます。このインフラストラクチャは一般的であり、さまざまなASAをサポートしている必要があります（図2の上部）。それは自律ノード、検出、ネゴシエーションおよび同期機能、情報の配信、報告、フィードバックループ、およびACP内部のルーティングのアドレッシングとネーミングを含みます。
The Generalized ACP (GACP) is the summary of all interactions of the ANI with other nodes and services. A specific implementation of the GACP is referred to here as the ACP and described in [RFC8994].
一般化ACP（GACP）は、ANIと他のノードとサービスとのすべての対話の概要です。GACPの具体的な実装は、ここではACPと呼ばれ、[RFC8994]に記載されています。
The use cases of "Autonomics" (such as self-management, self-optimization, etc.) are implemented as ASAs. They use the services and data structures of the underlying ANI, which should be self-managing.
「自律論」（自己管理、自己最適化など）のユースケースはASASとして実装されています。それらは、基礎となるANIのサービスとデータ構造を使用します。これは自己管理であるべきです。
The Basic Operating System Functions (lower part of Figure 2) include the normal OS (e.g., the network stack and security functions).
基本的なオペレーティングシステム機能（図2の下部）は、通常のOS（例えば、ネットワークスタックおよびセキュリティ機能）を含む。
Full Autonomic Network (AN) nodes have the full ANI, with the full functionality described in this document. At a later stage, the ANIMA Working Group may define a scope for constrained nodes with a reduced ANI and well-defined minimal functionality. These are currently out of scope.
フルオートノミックネットワーク（A）ノードは、この文書に記載されている全機能を伴うフルANIを持っています。後の段階で、Anima Workingグループは、ANIの低減および明確な最小限の機能を持つ制約付きノードのスコープを定義できます。これらは現在範囲外です。
Autonomic Networking is based on direct interactions between devices of a domain. The ACP is normally constructed on a hop-by-hop basis. Therefore, many interactions in the ANI are based on the ANI adjacency table. There are interactions that provide input into the adjacency table and other interactions that leverage the information contained in it.
自律神経ネットワーキングは、ドメインのデバイス間の直接的な相互作用に基づいています。ACPは通常、ホップバイホップごとに構築されています。したがって、ANI内の多くの相互作用はANI隣接テーブルに基づいています。隣接テーブルへの入力およびその中に含まれる情報を活用する他の対話を提供する対話があります。
The ANI adjacency table contains, at a minimum, information about adjacent autonomic nodes: Node-ID, IP address in data plane, IP address in ACP, domain, and certificate. An autonomic node maintains this adjacency table up to date. The adjacency table only contains information about other nodes that are capable of Autonomic Networking; non-autonomic nodes are normally not tracked here. However, the information is tracked independently of the status of the peer nodes; specifically, the adjacency table contains information about non-enrolled nodes of the same and other domains. The adjacency table may contain information about the validity and trust level of the adjacent autonomic nodes.
ANI隣接テーブルには、隣接するオートノミックノードに関する情報、node-id、データプレーン内のIPアドレス、ACP、ドメイン、および証明書に関する情報が含まれています。自律ノードは、この隣接テーブルを最新の状態に保持します。隣接テーブルには、自律型ネットワーキングが可能な他のノードに関する情報しか含まれていません。非自律ノードは通常ここで追跡されません。ただし、情報はピアノードのステータスとは無関係に追跡されます。具体的には、隣接テーブルには、同じドメインの非登録ノードに関する情報が含まれています。隣接テーブルには、隣接する自律ノードの有効性と信頼レベルに関する情報を含めることができます。
The adjacency table is fed by the following inputs:
隣接テーブルは次の入力によって入力されます。
* Link-local discovery: This interaction happens in the data plane, using IPv6 link-local addressing only, because this addressing type is itself autonomic. This way the node learns about all autonomic nodes around itself. The related Standards Track documents ([RFC8990], [RFC8995], and [RFC8994]) describe in detail how link-local discovery is used.
* Link-Local Discovery：このインタラクションは、IPv6リンクローカルアドレッシングのみを使用して、データプレーンで発生します。このアドレッシングタイプはそれ自体自律詞です。このようにして、ノードはそれ自体の周囲のすべての自律型ノードについて学習します。関連標準は文書を追跡します（[RFC8990]、[RFC8995]、[RFC8994]）は、Link-Local Discoveryの使用方法を詳細に説明しています。
* Vendor redirect: A new device may receive information on where its home network is through a vendor-based Manufacturer Authorized Signing Authority (MASA) (see Section 5.3) redirect; this is typically a routable address.
* ベンダーリダイレクト：新しいデバイスは、そのホームネットワークがベンダーベースの製造元認定署名権限（MASA）を通じて、そのホームネットワークがどこにあるかについての情報を受け取ることがあります（5.3項を参照）。これは通常、ルーティング可能なアドレスです。
* Non-autonomic input: A node may be configured manually with an autonomic peer; it could learn about autonomic nodes through DHCP options, DNS, and other non-autonomic mechanisms. Generally, such non-autonomic mechanisms require some administrator intervention. The key purpose is to bypass a non-autonomic device or network. As this pertains to new devices, it is covered in Appendices A and B of [RFC8995].
* 非自律型入力：ノードは、自律型ピアを使用して手動で構成できます。DHCPオプション、DNS、およびその他の非自律型メカニズムを介して自律ノードについて学習できます。一般に、そのような非自律的なメカニズムは何らかの管理者の介入を必要とする。重要な目的は、非自律型デバイスまたはネットワークを迂回することです。これは新しいデバイスに関するものとして、[RFC8995]の付録AとBで網羅されています。
The adjacency table defines the behavior of an autonomic node:
隣接テーブルは、自律ノードの動作を定義します。
* If the node has not bootstrapped into a domain (i.e., doesn't have a domain certificate), it rotates through all nodes in the adjacency table that claim to have a domain and will attempt bootstrapping through them, one by one. One possible response is a redirect via a vendor MASA, which will be entered into the adjacency table (see second bullet above). See [RFC8995] for details.
* ノードがドメインにブートストラップされていない場合（すなわち、ドメイン証明書を持っていない）場合、それはドメインを持つと主張する隣接テーブル内のすべてのノードを介して回転し、それらを通るブートストラップを1つずつ試みます。1つの可能な応答はベンダーMASAを介したリダイレクトです。これは隣接テーブルに入力されます（上記の2番目の箇条書きを参照）。詳細については[RFC8995]を参照してください。
* If the adjacent node has the same domain, it will authenticate that adjacent node and, if successful, establish the ACP. See [RFC8994].
* 隣接ノードが同じドメインを持つ場合、隣接ノードを認証し、成功した場合はACPを確立します。[RFC8994]を参照してください。
* Once the node is part of the ACP of a domain, it will use GRASP [RFC8990] to find the registrar(s) of its domain and potentially other services.
* ノードがドメインのACPの一部であると、それはgrasp [rfc8990]を使用してそのドメインのレジストラと他のサービスを見つけるでしょう。
* If the node is part of an ACP and has discovered at least one registrar in its domain via GRASP, it will start the join proxy ASA and act as a join proxy for neighboring nodes that need to be bootstrapped. See Section 6.3.1.2 for details.
* ノードがACPの一部であり、graspを介してそのドメイン内で少なくとも1つのレジストラを検出した場合は、結合プロキシASAを起動し、ブートストラップする必要がある隣接ノードの結合プロキシとして機能します。詳細は6.3.1.2項を参照してください。
* Other behaviors are possible, for example, establishing the ACP with devices of a subdomain or other domains. These will likely be controlled by Intent and are outside the scope of this document. Note that Intent is distributed through the ACP; therefore, a node can only adapt Intent-driven behavior once it has joined the ACP. At the moment, the ANIMA Working Group does not consider providing Intent outside the ACP; this can be considered later.
* たとえば、サブドメインまたは他のドメインのデバイスでACPを確立することができます。これらは意図によって制御され、この文書の範囲外です。IntentはACPを介して配布されています。したがって、ノードはACPに参加したら、意図駆動の動作を適応させることができます。現時点では、Anima Working GroupはACPの外部の意図を提供することを検討しません。これは後で考えることができます。
Once a node has joined the ACP, it will also learn the ACP addresses of its adjacent nodes and add them to the adjacency table to allow for communication inside the ACP. Further autonomic domain interactions will now happen inside the ACP. At this moment, only negotiation and synchronization via GRASP [RFC8990] are defined. (Note that GRASP runs in the data plane, as an input in building the adjacency table, as well as inside the ACP.)
ノードがACPに参加したら、隣接ノードのACPアドレスを学習し、ACP内部の通信を可能にするためにそれらを隣接テーブルに追加します。ACP内では、さらに自律型ドメインのインタラクションが発生します。現時点では、GRASP [RFC8990]を介したネゴシエーションと同期のみが定義されています。（graspはデータプレーン内で実行されていることに注意して、ACPの内部だけでなく、隣接テーブルの構築の入力として。）
Autonomic functions consist of ASAs. They run logically above the ANI and may use the adjacency table, the ACP, negotiation and synchronization through GRASP in the ACP, Intent, and other functions of the ANI. Since the ANI only provides autonomic interactions within a domain, autonomic functions can also use any other context on a node, specifically the global data plane.
自律神経機能はASASで構成されています。それらはANIの上に論理的に実行され、ACP、Intent、およびANIの他の関数でgraspを介して隣接テーブル、ACP、ネゴシエーション、および同期を使用することができます。ANIはドメイン内で自律的なインタラクションのみを提供するため、自律神経機能はノード、特にグローバルデータプレーン上の他のコンテキストも使用できます。
Autonomic Networking applies during the full life cycle of a node. This section describes a state machine of an autonomic node throughout its life.
オートノミックネットワーキングは、ノードのフルライフサイクルの間に適用されます。このセクションでは、その寿命を通して自律ノードの状態マシンについて説明します。
A device is normally expected to store its domain-specific identity, the Local Device Identifier (LDevID) (see Section 5.2), in persistent storage to be available after a power-cycle event. For device types that cannot store the LDevID in persistent storage, a power-cycle event is effectively equivalent to a factory reset.
デバイスは通常、そのドメイン固有のID、ローカルデバイス識別子（LDEVID）（セクション5.2を参照）を保存することが期待されています。これは、パワーサイクルイベントの後に使用可能な永続的な記憶域で、永続的な記憶域では永続的な記憶域で保存されます。永続ストレージにLDEVIDを保存できないデバイスタイプの場合、電力サイクルイベントは工場出荷時のリセットと効果的に同等です。
An autonomic node leaves the factory in this state. In this state, the node has no domain-specific configuration, specifically no LDevID, and could be used in any particular target network. It does, however, have a vendor/manufacturer-specific ID, the Initial Device Identifier (IDevID) [IDevID]. Nodes without IDevID cannot be autonomically and securely enrolled into a domain; they require manual pre-staging, in which case the pre-staging takes them directly to state 2.
自律ノードはこの状態で工場を出ます。この状態では、ノードにはドメイン固有の設定、特にLDEVIDがないため、特定のターゲットネットワークで使用できます。ただし、ベンダー/製造業者固有のID、初期デバイス識別子（IDEVID）[IDEVID]があります。IDEVIDなしのノードは、自律的に、そしてドメインに安全に登録することはできません。それらは手動の事前ステージングを必要とし、その場合、前ステージングはそれらを直接状態2に連れて行く。
Transitions:
トランジション：
* Bootstrap event: The device enrolls into a domain; as part of this process it receives a domain identity (LDevID). If enrollment is successful, the next state is state 2. See [RFC8995] for details on enrollment.
* ブートストラップイベント：デバイスはドメインに登録します。このプロセスの一部として、ドメインID（LDEVID）を受け取ります。登録が成功すると、次の状態は状態2です。登録の詳細については、[RFC8995]を参照してください。
* Power-cycle event: The device loses all state tables. It remains in state 1.
* パワーサイクルイベント：デバイスはすべての状態テーブルを失います。それは状態1に残ります。
An autonomic node is in the "enrolled" state if it has a domain identity (LDevID) and has currently no ACP channel up. It may have further configuration or state, for example, if it had been in state 3 before but lost all its ACP channels. The LDevID can only be removed from a device through a factory reset, which also removes all other state from the device. This ensures that a device has no stale domain-specific state when entering the "enrolled" state from state 1.
自律ノードは、ドメインID（LDEVID）がある場合は「登録」状態にあり、現在ACPチャンネルUPがありません。それは、例えば、それが状態3にあったが、そのACPチャネルを全て失った場合など、さらなる構成または状態を有することができる。LDEVIDは、工場出荷時のリセットを介してデバイスからのみ削除できます。これはデバイスから他のすべての状態を削除します。これにより、状態1から「登録された」状態を入力するときに、デバイスに古いドメイン固有の状態がないことが保証されます。
Transitions:
トランジション：
* Joining ACP: The device establishes an ACP channel to an adjacent device. See [RFC8994] for details. Next state: 3.
* ACPに参加する：デバイスはACPチャネルを隣接するデバイスに確立します。詳細については[RFC8994]を参照してください。次の状態：3。
* Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1.
* 工場出荷時のリセット：工場出荷時のリセットは、装置からすべての設定とドメインID（LDEVID）を削除します。次の状態：1。
* Power-cycle event: The device loses all state tables, but not its domain identity (LDevID). It remains in state 2.
* パワーサイクルイベント：デバイスはすべての状態テーブルを失いますが、そのドメインID（LDEVID）は負けません。状態2に残ります。
In this state, the autonomic node has at least one ACP channel to another device. The node can now participate in further autonomic transactions, such as starting ASAs (e.g., it must now enable the join proxy ASA, to help other devices to join the domain). Other conditions may apply to such interactions, for example, to serve as a join proxy, the device must first discover a bootstrap registrar.
この状態では、自律ノードは他の装置に少なくとも1つのACPチャネルを有する。ノードは、ASASの起動などのさらなる自律型トランザクションに参加することができます（たとえば、参加プロキシASAがドメインに参加するのを助けるために）。他の条件は、例えば結合プロキシとして機能するようにそのようなインタラクションに適用されるかもしれません、デバイスは最初にブートストラップレジストラを発見する必要があります。
Transitions:
トランジション：
* Leaving ACP: The device drops the last (or only) ACP channel to an adjacent device. Next state: 2.
* ACPを残す：デバイスは最後の（または唯一の）ACPチャネルを隣接するデバイスにドロップします。次の状態：2。
* Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1.
* 工場出荷時のリセット：工場出荷時のリセットは、装置からすべての設定とドメインID（LDEVID）を削除します。次の状態：1。
* Power-cycle event: The device loses all state tables but not its domain identity (LDevID). Next state: 2.
* パワーサイクルイベント：デバイスはすべての状態テーブルを失いますが、そのドメインID（LDEVID）は負けません。次の状態：2。
The ANI provides a layer of common functionality across an Autonomic Network. It provides the elementary functions and services, as well as extensions. An autonomic function, comprising of ASAs on nodes, uses the functions described in this section.
ANIは、自律型ネットワーク全体で共通の機能の層を提供します。それはエレメンタリー機能とサービス、そして拡張機能を提供します。ノード上のASASを含む自律型関数は、このセクションに記載されている機能を使用しています。
Inside a domain, each autonomic device should be assigned a unique name. The naming scheme should be consistent within a domain. Names are typically assigned by a registrar at bootstrap time and are persistent over the lifetime of the device. All registrars in a domain must follow the same naming scheme.
ドメイン内には、各自律型デバイスに一意の名前を割り当てる必要があります。命名方式はドメイン内で一貫しているはずです。名前は通常、ブートストラップ時間のレジストラによって割り当てられ、デバイスの有効期間にわたって永続的です。ドメイン内のすべてのレジストラは、同じ命名方式に従う必要があります。
In the absence of a domain-specific naming scheme, a default naming scheme should use the same logic as the addressing scheme discussed in [RFC8994]. The device name is then composed of a Registrar-ID (for example, taking a Media Access Control (MAC) address of the registrar) and a device number. An example name would then look like this:
ドメイン固有の命名方式がない場合、デフォルトの命名方式は[RFC8994]で説明されているアドレス指定方式と同じ論理を使用する必要があります。デバイス名は次にレジストラID（例えば、レジストラのメディアアクセス制御（MAC）アドレスをとる）とデバイス番号で構成されます。例の名前は次のようになります。
0123-4567-89ab-0001
0123-4567-89AB-0001.
The first three fields are the MAC address, and the fourth field is the sequential number for the device.
最初の3つのフィールドはMACアドレスであり、4番目のフィールドはデバイスのシーケンシャル番号です。
ASAs need to communicate with each other, using the autonomic addressing of the ANI of the node they reside on. This section describes the addressing approach of the ANI used by ASAs.
ASASは、存在するノードのANIの自律的アドレッシングを使用して、互いに通信する必要があります。このセクションでは、ASAが使用するANIのアドレス指定方法について説明します。
Addressing approaches for the data plane of the network are outside the scope of this document. These addressing approaches may be configured and managed in the traditional way or negotiated as a service of an ASA. One use case for such an autonomic function is described in [RFC8992].
ネットワークのデータプレーンのアドレス指定アプローチは、この文書の範囲外です。これらのアドレス指定アプローチは、従来の方法で構成され管理されているか、またはASAのサービスとして交渉されてもよい。そのような自律型関数のための1つのユースケースは[RFC8992]に記載されている。
Autonomic addressing is a function of the ANI (lower part of Figure 2), specifically the ACP. ASAs do not have their own addresses. They may use either API calls or the autonomic addressing scheme of the ANI.
自律神経アドレッシングは、ANI（図2の下部）、具体的にはACPの関数です。ASAS独自のアドレスを持っていません。それらは、API呼び出しまたはANIの自律型アドレッシング方式を使用することができる。
An autonomic addressing scheme has the following requirements:
自律型アドレッシング方式には、次の要件があります。
* Zero-touch for simple networks: Simple networks should have complete self-management of addressing and not require any central address management, tools, or address planning.
* 単純なネットワークのためのゼロタッチ：単純なネットワークはアドレス指定の完全な自己管理を持ち、中央アドレス管理、ツール、またはアドレスの計画を必要としません。
* Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high-level guidance only, expressed in Intent.
* 複雑なネットワークのためのロータッチ：複雑なネットワークが自律型アドレス管理のためのオペレータ入力を必要とする場合、それは意図的に表現された、高レベルのガイダンスだけに制限されるべきです。
* Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around and for the network to grow, split, and merge.
* 柔軟性：アドレッシング方式は、ノードが動き回り、ネットワークが成長、分割、およびマージできるようにするのに十分柔軟でなければなりません。
* Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context.
* 堅牢性：管理者が、自律文脈でアドレス指定（したがって接続性）に悪影響を及ぼすようにできるだけ困難になるはずです。
* Stability: The addressing scheme should be as stable as possible. However, implementations need to be able to recover from unexpected address changes.
* 安定性：アドレッシング方式はできるだけ安定している必要があります。ただし、実装は予期しないアドレス変更から回復できる必要があります。
* Support for virtualization: Autonomic functions can exist either at the level of the physical network and physical devices or at the level of virtual machines, containers, and networks. In particular, autonomic nodes may support ASAs in virtual entities. The infrastructure, including the addressing scheme, should be able to support this architecture.
* 仮想化のためのサポート：自律型関数は、物理ネットワークと物理デバイスのレベル、または仮想マシン、コンテナ、およびネットワークのレベルで存在できます。特に、自律ノードは仮想エンティティ内のASASをサポートすることがあります。アドレス指定方式を含むインフラストラクチャは、このアーキテクチャをサポートできるはずです。
* Simplicity: The addressing scheme should be simple to make engineering easier and to give the human administrator an easy way to troubleshoot autonomic functions.
* 単純さ：アドレッシングスキームは、エンジニアリングを容易にし、人間管理者に自律型機能をトラブルシューティングする簡単な方法で簡単にすることが簡単です。
* Scale: The proposed scheme should work in any network of any size.
* スケール：提案された方式は、任意のサイズのネットワークでも機能する必要があります。
* Upgradability: The scheme must be able to support different addressing concepts in the future.
* アップグレード可能性：このスキームは、将来的には異なるアドレス指定の概念をサポートできなければなりません。
The proposed addressing scheme is described in the document "An Autonomic Control Plane (ACP)" [RFC8994].
提案されたアドレッシング方式は、「自律制御プレーン（ACP）」[RFC8994]文書に記載されている。
Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should rely on such northbound interfaces minimally or not at all; therefore, it needs to discover peers and other resources in the network. This section describes various discovery functions in an Autonomic Network.
伝統的に、ノードが必要とするほとんどの情報は、構成またはノースバウンドインターフェイスを介して提供されます。自律型関数は、そのようなノースバウンドインターフェイスに最小限または全く依存しているはずです。したがって、ネットワーク内のピアやその他のリソースを発見する必要があります。このセクションでは、自律ネットワークでさまざまな検出機能について説明します。
First, discovering nodes and their properties and capabilities is a core function to establish an autonomic domain is the mutual discovery of autonomic nodes, primarily adjacent nodes and secondarily off-link peers. This may, in principle, either leverage existing discovery mechanisms or use new mechanisms tailored to the autonomic context. An important point is that discovery must work in a network with no predefined topology, ideally no manual configuration of any kind, and with nodes starting up from factory condition or after any form of failure or sudden topology change.
まず、ノードの検出とそのプロパティと機能は、自律型ドメインを確立するためのコア関数であり、主に隣接ノードと2次オフリンクピアの相互発見です。これは、原則として、既存の発見メカニズムを活用したり、自律文脈に合わせた新しいメカニズムを使用したりすることがあります。重要な点は、検出が定義されたトポロジなしで、理想的には手動構成を持たず、ファクトリの状態から起動したり、障害が発生したり突然のトポロジーの誤ったトポロジーの後に始まって、検出が必要でなければならないということです。
Second, network services such as Authentication, Authorization, and Accounting (AAA) should also be discovered and not configured. Service discovery is required for such tasks. An Autonomic Network can leverage existing service discovery functions, use a new approach, or use a mixture.
第二に、認証、承認、および会計（AAA）などのネットワークサービスも発見され、設定されていないはずです。そのような作業にはサービス発見が必要です。自律型ネットワークは既存のサービス発見機能を活用し、新しいアプローチを使用するか、または混合を使用することができます。
Thus, the discovery mechanism could either be fully integrated with autonomic signaling (next section) or use an independent discovery mechanism such as DNS-based Service Discovery or the Service Location Protocol. This choice could be made independently for each ASA, although the infrastructure might require some minimal lowest common denominator (e.g., for discovering the security bootstrap mechanism or the source of information distribution (Section 4.7)).
したがって、発見メカニズムは、自律型シグナリング（次のセクション）と完全に統合されているか、またはDNSベースのサービス検出やサービスロケーションプロトコルなどの独立した発見メカニズムを使用することができます。インフラストラクチャには、インフラストラクチャに最小限の低い共通の分母を必要とするかもしれませんが、ISAごとに独立して行うことができます（たとえば、セキュリティブートストラップメカニズムまたは情報配信元のソースを検出するためのもの）。
Phase 1 of Autonomic Networking uses GRASP [RFC8990] for discovery.
オートノミックネットワーキングのフェーズ1は、検出のためにGRASP [RFC8990]を使用します。
Autonomic nodes must communicate with each other, for example, to negotiate and/or synchronize technical objectives (i.e., network parameters) of any kind and complexity. This requires some form of signaling between autonomic nodes. Autonomic nodes implementing a specific use case might choose their own signaling protocol, as long as it fits the overall security model. However, in the general case, any pair of autonomic nodes might need to communicate, so there needs to be a generic protocol for this. A prerequisite for this is that autonomic nodes can discover each other without any preconfiguration, as mentioned above. To be generic, discovery and signaling must be able to handle any sort of technical objective, including ones that require complex data structures. The document "GeneRic Autonomic Signaling Protocol (GRASP)" [RFC8990] describes more detailed requirements for discovery, negotiation, and synchronization in an Autonomic Network. It also defines a protocol, called GRASP, for this purpose; GRASP includes an integrated but optional discovery process.
オートノミックノードは、例えば、任意の種類および複雑さの技術的目的（すなわちネットワークパラメータ）を交渉および/または同期させるために、互いに通信する必要がある。これには、自律ノード間である種のシグナリングが必要です。特定のユースケースを実装する自律ノードは、セキュリティモデル全体に適合する限り、独自のシグナリングプロトコルを選択することがあります。ただし、一般的な場合では、任意のペアのオートノミックノードが通信する必要があるかもしれませんので、これには一般的なプロトコルが必要です。このための前提条件は、前述のように、自律型ノードが事前設定なしにお互いを発見できることです。一般的な、ディスカバリとシグナリングは、複雑なデータ構造を必要とするものを含む、あらゆる種類の技術的な目的を処理できる必要があります。 「一般自律神経シグナリングプロトコル（GRASP）」[RFC8990]は、オートノミックネットワークにおける発見、ネゴシエーション、および同期に関するより詳細な要件を説明しています。この目的のために、GRASPと呼ばれるプロトコルも定義します。 GRASPには、統合されているがオプションの発見プロセスが含まれています。
GRASP is normally expected to run inside the ACP (see Section 4.6) and to depend on the ACP for security. It may run insecurely for a short time during bootstrapping.
GRASPは通常、ACPの内部で実行されると予想されます（セクション4.6を参照）、セキュリティのACPに依存します。ブートストラップ中は短時間で安全に動作する可能性があります。
An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are not excluded.
自律ノードは通常、複数のASASで使用されている把握の単一のインスタンスを実行します。ただし、把握の複数のインスタンスが単一のノードで実行されるシナリオは、おそらく異なるセキュリティプロパティを持つ、除外されません。
All autonomic nodes in a domain must be able to communicate with each other, and in later phases, they must also be able to communicate with autonomic nodes outside their own domain. Therefore, an ACP relies on a routing function. For Autonomic Networks to be interoperable, they must all support one common routing protocol.
ドメイン内のすべてのオートノミックノードは、互いに通信できる必要があり、後のフェーズでは、それらは独自のドメインの外部で自律ノードと通信できる必要があります。したがって、ACPはルーティング機能に依存しています。自律網ネットワークが相互運用可能であるためには、それらはすべて1つの共通ルーティングプロトコルをサポートする必要があります。
The routing protocol is defined in the ACP document [RFC8994].
ルーティングプロトコルはACPドキュメント[RFC8994]で定義されています。
The ACP carries the control protocols in an Autonomic Network. In the architecture described in this document, it is implemented as an overlay network. The document "An Autonomic Control Plane (ACP)" [RFC8994] describes the implementation details suggested in this document. This document uses the term "overlay" to mean a set of point-to-point adjacencies congruent with the underlying interconnection topology. The terminology may not be aligned with a common usage of the term "overlay" in the routing context. See [RFC8368] for uses cases for the ACP.
ACPは自律型ネットワーク内の制御プロトコルを担当します。この文書に記載されているアーキテクチャでは、オーバーレイネットワークとして実装されています。「自律管理プレーン（ACP）」[RFC8994]は、この文書で提案されている実装の詳細を説明しています。この文書は、「オーバーレイ」という用語を使用して、基礎となる相互接続トポロジと一致するポイントツーポイント隣接関係を意味します。ルーティングコンテキストの「オーバーレイ」という用語の一般的な使用方法と整列させない場合があります。ACPの場合は[RFC8368]を参照してください。
Certain forms of information require distribution across an autonomic domain. The distribution of information runs inside the ACP. For example, Intent is distributed across an autonomic domain, as explained in [RFC7575].
特定の形態の情報は、自律ドメイン間の分布を必要とします。情報の分布はACP内で実行されます。たとえば、[RFC7575]で説明されているように、意図は自律型ドメインに分散されています。
Intent is the policy language of an Autonomic Network (see also Section 7.2). It is a high-level policy and should change only infrequently (order of days). Therefore, information such as Intent should be simply flooded to all nodes in an autonomic domain, and there is currently no perceived need to have more targeted distribution methods. Intent is also expected to be monolithic and flooded as a whole. One possible method for distributing Intent, as well as other forms of data, is discussed in [GRASP-DISTRIB]. Intent and information distribution are not part of the ANIMA Working Group charter.
Intentは自律網の政策言語です（7.2項も参照）。それは高レベルのポリシーであり、変化するべきではない（日数）。したがって、意図などの情報は、自律ドメイン内のすべてのノードに単純にフラッディングされるべきであり、現在ターゲットにターゲットに済みます。意図はモノリシックであり、全体としてあふれさせると予想されます。Intentを配布するための1つの可能な方法、ならびに他の形態のデータは[把握分配]で説明されている。意図と情報の配布は、Anima Working Group Charterの一部ではありません。
An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security, with the exception of setting up a PKI infrastructure.
自律型ネットワークは自己保護です。PKIインフラストラクチャの設定を除き、管理者がセキュリティを明示的に設定する必要なしに、すべてのプロトコルはデフォルトで安全です。
Autonomic nodes have direct interactions between themselves, which must be secured. Since an Autonomic Network does not rely on configuration, it is not an option to configure, for example, pre-shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. In this first phase of Autonomic Networking, a device is either 1) within the trust domain and fully trusted or 2) outside the trust domain and fully untrusted.
自律ノードは自分の間の直接の相互作用を持ち、それは確保されなければなりません。オートノミックネットワークは構成に依存しないため、プリシェアードキーなどを構成するオプションではありません。PKIインフラストラクチャなどの信頼インフラストラクチャが整っていなければなりません。このセクションでは、この信頼インフラストラクチャの原則について説明します。自律技術ネットワーキングのこの最初のフェーズでは、信頼ドメイン内でデバイスが1）、完全に信頼されているか2）信頼ドメインの外側で完全に信頼されていません。
The default method to automatically bring up a trust infrastructure is defined in the document "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995]. The ASAs required for this enrollment process are described in Section 6.3. An autonomic node must implement the enrollment and join proxy ASAs. The registrar ASA may be implemented only on a subset of nodes.
自動的に信頼インフラストラクチャを起動するためのデフォルトのメソッドは、ドキュメント「ブートストラップリモートセキュアキーインフラストラクチャ（BRSKI）」[RFC8995]で定義されています。この登録プロセスに必要なASAは、6.3項で説明されています。自律ノードは登録を実行し、プロキシASAを結合する必要があります。Registrar ASAはノードのサブセット上でのみ実装されてもよい。
An autonomic domain uses a PKI model. The root of trust is a Certification Authority (CA). A registrar acts as a Registration Authority (RA).
自律型ドメインはPKIモデルを使用します。信頼の根本は認証局（CA）です。レジストラは登録局（RA）として機能します。
A minimum implementation of an autonomic domain contains one CA, one registrar, and network elements.
自律型ドメインの最小実装は、1つのCA、1つのレジストラ、およびネットワーク要素を含む。
Each device in an autonomic domain uses a domain certificate (LDevID) to prove its identity. A new device uses its manufacturer-provided certificate (IDevID) during bootstrap to obtain a domain certificate. [RFC8995] describes how a new device receives a domain certificate and defines the certificate format.
自律型ドメイン内の各デバイスは、そのアイデンティティを証明するためにドメイン証明書（LDEVID）を使用します。新しいデバイスは、ブートストラップ中に製造元提供の証明書（IDEVID）を使用してドメイン証明書を取得します。[RFC8995]新しいデバイスがドメイン証明書を受信し、証明書フォーマットを定義する方法を説明します。
The Manufacturer Authorized Signing Authority (MASA) is a trusted service for bootstrapping devices. The purpose of the MASA is to provide ownership tracking of devices in a domain. The MASA provides audit, authorization, and ownership tokens to the registrar during the bootstrap process to assist in the authentication of devices attempting to join an autonomic domain and to allow a joining device to validate whether it is joining the correct domain. The details for MASA service, security, and usage are defined in [RFC8995].
製造元認定署名権限（MASA）は、ブートストラップデバイスのための信頼できるサービスです。MASAの目的は、ドメイン内のデバイスの所有権追跡を提供することです。MASAは、ブートストラッププロセス中に監査、承認、および所有権トークンを、オートノミックドメインに参加しようとしたデバイスの認証を支援し、接続装置が正しいドメインに参加しているかどうかを検証できるようにするための監査機能を提供します。MASAサービス、セキュリティ、および使用方法の詳細は[RFC8995]で定義されています。
By default, subdomains are treated as different domains. This implies no trust between a domain and its subdomains and no trust between subdomains of the same domain. Specifically, no ACP is built, and Intent is valid only for the domain it is defined for explicitly.
デフォルトでは、サブドメインは異なるドメインとして扱われます。これは、ドメインとそのサブドメインとの間の信頼は信頼できません。同じドメインのサブドメイン間の信頼はありません。具体的には、ACPは構築されず、Intentは明示的に定義されているドメインに対してのみ有効です。
In the ANIMA Working Group charter, alternative trust models should be defined, for example, to allow full or limited trust between domain and subdomain.
Anima Working Group Charterでは、ドメインとサブドメイン間の完全な信頼または限定的な信頼を許可するために、代替信頼モデルを定義する必要があります。
By default, different domains do not interoperate, no ACP is built, and no trust is implied between them.
デフォルトでは、異なるドメインは相互運用しない、ACPは構築されず、それらの間に信頼は暗黙のうちに暗黙的にはいません。
In the future, models can be established where other domains can be trusted in full or for limited operations between the domains.
将来的には、他のドメインを完全に信頼するか、またはドメイン間の限られた操作を信頼できるようにするモデルを確立できます。
This section describes how autonomic services run on top of the ANI.
このセクションでは、ANIの上部にオートノミックサービスがどのように実行されるかについて説明します。
An ASA is defined in [RFC7575] as "An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole". Thus, it is a process that makes use of the features provided by the ANI to achieve its own goals, usually including interaction with other ASAs via GRASP [RFC8990] or otherwise. Of course, it also interacts with the specific targets of its function, using any suitable mechanism. Unless its function is very simple, the ASA will need to handle overlapping asynchronous operations. It may therefore be a quite complex piece of software in its own right, forming part of the application layer above the ANI. ASA design guidelines are available in [ASA-GUIDELINES].
ASAは[RFC7575]で「オートノミック関数を実装したエージェント」として「Autonomic関数を実装したエージェント」で定義されています。したがって、ANIによって提供される特徴を利用して、通常は把握[RFC8990]またはそれ以外の場合を介した他のASAとの相互作用を含むそれ自体の目標を達成するプロセスです。もちろん、それはまた任意の適切なメカニズムを使用して、その機能の特定の標的と相互作用する。その関数が非常に単純でない限り、ASAは重複する非同期操作を処理する必要があります。したがって、それはそれ自体の右側にある非常に複雑なソフトウェアの一部であり、ANIの上のアプリケーション層の一部を形成することができる。ASA設計ガイドラインは[ASAガイドライン]で入手できます。
Thus, we can distinguish at least three classes of ASAs:
したがって、私たちは少なくとも3つのASASを区別することができます。
* Simple ASAs with a small footprint that could run anywhere.
* どこにでも走ることができる小さな足跡を持つ単純なasas。
* Complex, possibly multi-threaded ASAs that have a significant resource requirement and will only run on selected nodes.
* 重要なリソース要件を持つ複雑な、マルチスレッドASASで、選択されたノードでのみ実行されます。
* A few 'infrastructure ASAs' that use basic ANI features in support of the ANI itself, which must run in all autonomic nodes. These are outlined in the following sections.
* ANI自体をサポートしている基本的なANI機能を使用するいくつかの「インフラストラクチャASAS」。これらは以下のセクションで概説されています。
Autonomic nodes, and therefore their ASAs, know their own capabilities and restrictions, derived from hardware, firmware, or pre-installed software; they are "self-aware".
オートノミックノード、したがって、そのASAは、ハードウェア、ファームウェア、またはプレインストールされているソフトウェアから派生した独自の機能と制限を知っています。彼らは「自己認識」です。
The role of an autonomic node depends on Intent and on the surrounding network behaviors, which may include forwarding behaviors, aggregation properties, topology location, bandwidth, tunnel or translation properties, etc. For example, a node may decide to act as a backup node for a neighbor, if its capabilities allow it to do so.
オートノミックノードの役割は、転送動作、アグリゲーションプロパティ、トポロジの場所、帯域幅、トンネルまたは翻訳プロパティなどを含むことができる、周囲のネットワークビヘイビアに依存します。たとえば、ノードはバックアップノードとして機能することを決定できます。能力の場合、その機能がそうすることができる場合。
Following an initial discovery phase, the node's properties and those of its neighbors are the foundation of the behavior of a specific node. A node and its ASAs have no pre-configuration for the particular network in which they are installed.
最初の発見フェーズに続いて、ノードのプロパティとその隣接者のものは、特定のノードの動作の基盤です。ノードとそのASAは、インストールされている特定のネットワークの事前設定はありません。
Since all ASAs will interact with the ANI, they will depend on appropriate application programming interfaces (APIs). It is desirable that ASAs are portable between operating systems, so these APIs need to be universal. An API for GRASP is described in [RFC8991].
すべてのASAはANIと対話するため、適切なアプリケーションプログラミングインタフェース（API）によって異なります。ASASがオペレーティングシステム間で移植可能であることが望ましいので、これらのAPIは普遍的である必要があります。[RFC8991]には、把握用のAPIが記載されています。
ASAs will, in general, be designed and coded by experts in a particular technology and use case, not by experts in the ANI and its components. Also, they may be coded in a variety of programming languages, in particular, languages that support object constructs as well as traditional variables and structures. The APIs should be designed with these factors in mind.
ASASは一般的に、ANIの専門家とそのコンポーネントではなく、特定の技術とユースケースの専門家によって設計およびコーディングされます。また、さまざまなプログラミング言語、特に、オブジェクト構文と伝統的な変数や構造をサポートする言語を様々なプログラミング言語でコーディングすることができます。APIはこれらの要因を念頭に置いて設計されるべきです。
It must be possible to run ASAs as non-privileged (user space) processes except for those (such as the infrastructure ASAs) that necessarily require kernel privilege. Also, it is highly desirable that ASAs can be dynamically loaded on a running node.
カーネル特権が必要なもの（インフラストラクチャのASAなど）を除いて、特権（ユーザースペース）プロセスとしてASAを実行することが可能でなければなりません。また、実行中のノードにASAを動的にロードできることが非常に望ましい。
Since autonomic systems must be self-repairing, it is of great importance that ASAs are coded using robust programming techniques. All runtime error conditions must be caught, leading to suitable minimally disruptive recovery actions, but a complete restart of the ASA must also be considered. Conditions such as discovery failures or negotiation failures must be treated as routine, with the ASA retrying the failed operation, preferably with an exponential back-off in the case of persistent errors. When multiple threads are started within an ASA, these threads must be monitored for failures and hangups, and appropriate action taken. Attention must be given to garbage collection, so that ASAs never run out of resources. There is assumed to be no human operator; again, in the worst case, every ASA must be capable of restarting itself.
自律システムが自己修復でなければならないので、ASASが堅牢なプログラミング技術を使用して符号化されていることが非常に重要です。すべてのランタイムエラー状態を捉える必要がありますが、最小限の最小混乱の回復行動につながるが、ASAの完全な再起動も考慮する必要があります。発見の失敗や交渉の失敗などの条件は、永続的なエラーの場合には、障害のある操作を再試行していることが好ましく、障害のある操作を再試行して、ルーチンとして扱われなければなりません。複数のスレッドがASA内で起動されると、これらのスレッドは障害とハングアップのために監視され、適切な処置が必要です。ガベージコレクションに注意を払う必要があるので、ASAはリソースを不足しないようにします。人間のオペレータではないと仮定されています。繰り返しますが、最悪の場合、すべてのASAは自身を再起動できなければなりません。
ASAs will automatically benefit from the security provided by the ANI, specifically by the ACP and by GRASP. However, beyond that, they are responsible for their own security, especially when communicating with the specific targets of their function. Therefore, the design of an ASA must include a security analysis beyond 'use ANI security'.
ASASは自動的にANIによって提供されたセキュリティ、特にACPと把握によって利益を得るでしょう。しかし、それを超えて、それらは特に彼らの関数の特定のターゲットと通信するときに彼ら自身のセキュリティを担当します。したがって、ASAの設計には、「ANI Securityを使用する」を超えたセキュリティ分析を含める必要があります。
ASAs operating on a given ANI may come from different providers and pursue different objectives. Management of ASAs and their interactions with the ANI should follow the same operating principles and thus comply to a generic life-cycle management model.
与えられたANI上で動作するASAは、さまざまなプロバイダーから来て、異なる目的を追求する可能性があります。ASAの管理とANIとの相互作用は、同じ動作原則に従うべきであり、したがって一般的なライフサイクル管理モデルに準拠しています。
The ASA life cycle provides standard processes to:
ASAライフサイクルは、次の標準的なプロセスを提供します。
* install ASA: copy the ASA code onto the node and start it.
* ASAをインストールする：ASAコードをノードにコピーして起動します。
* deploy ASA: associate the ASA instance with a (some) managed network device(s) (or network function).
* ASAを展開：ASAインスタンスを（一部の）管理対象ネットワークデバイス（またはネットワーク機能）に関連付けます。
* control ASA execution: when and how an ASA executes its control loop.
* ASAの実行を制御する：ASAがその制御ループを実行するとき、およびASAの実行方法。
This life cycle will also define which interactions ASAs have with the ANI in between the different states. The noticeable interactions are:
このライフサイクルはまた、どのインタラクションが異なる状態の間にANIと共に持つかを定義するであろう。顕著な相互作用は次のとおりです。
* Self-description of ASA instances at the end of deployment: Its format needs to define the information required for the management of ASAs by ANI entities.
* 展開終了時のASAインスタンスの自己説明：そのフォーマットは、ANIエンティティによるASAの管理に必要な情報を定義する必要があります。
* Control of the ASA control loop during the operation: Signaling has to carry formatted messages to control ASA execution (at least starting and stopping the control loop).
* 操作中のASA制御ループの制御：シグナリングは、ASAの実行を制御するためのフォーマットされたメッセージを搬送しなければなりません（少なくとも制御ループの開始と停止）。
The following functions provide essential, required functionality in an Autonomic Network and are therefore mandatory to implement on unconstrained autonomic nodes. They are described here as ASAs that include the underlying infrastructure components, but implementation details might vary.
以下の関数は、自律型ネットワークにおいて必須の要求された機能を提供し、したがって、制約されていないオートノミックノードに実装することを強義しています。それらは、基礎となるインフラストラクチャコンポーネントを含むASASとして説明されていますが、実装の詳細は異なる場合があります。
The first three (pledge, join proxy, join registrar) support together the trust enrollment process described in Section 5. For details see [RFC8995].
最初の3つ（PREDCK、JOINプロキシ、参加し、登録）は、セクション5で説明されている信頼登録プロセスをサポートしています[RFC8995]を参照してください。
This ASA includes the function of an autonomic node that bootstraps into the domain with the help of a join proxy ASA (see below). Such a node is known as a pledge during the enrollment process. This ASA must be installed by default on all nodes that require an autonomic zero-touch bootstrap.
このASAには、結合プロキシASAのヘルプを持つドメインにブートストラップが起動する自律ノードの機能が含まれています（下記参照）。そのようなノードは登録プロセス中の誓約として知られている。このASAは、自律ゼロタッチブートストラップを必要とするすべてのノードでデフォルトでインストールする必要があります。
This ASA includes the function of an autonomic node that helps non-enrolled, adjacent devices to enroll into the domain. This ASA must be installed on all nodes, although only one join proxy needs to be active on a given LAN. See also [RFC8995].
このASAには、登録されていないデバイスでドメインに入るのに役立つ自律ノードの機能が含まれています。このASAはすべてのノードにインストールする必要がありますが、1つの結合プロキシは特定のLANでアクティブにする必要があります。[RFC8995]も参照してください。
This ASA includes the Join Registrar function in an Autonomic Network. This ASA does not need to be installed on all nodes, but only on nodes that implement the Join Registrar function.
このASAは、自律ネットワーク内の結合レジストラ機能を含みます。このASAはすべてのノードにインストールする必要はありませんが、結合レジストラ機能を実装するノード上でのみインストールされます。
This ASA includes the ACP function in an Autonomic Network. In particular, it acts to discover other potential ACP nodes and to support the establishment and teardown of ACP channels. This ASA must be installed on all nodes. For details, see Section 4.6 and [RFC8994].
このASAは、自律ネットワーク内のACP機能を含みます。特に、他の潜在的なACPノードを発見し、ACPチャンネルの設立と破壊をサポートするように作用します。このASAはすべてのノードにインストールする必要があります。詳細は4.6 and [RFC8994]を参照してください。
This ASA is currently out of scope in the ANIMA Working Group charter and is provided here only as background information.
このASAは現在、Anima Working Group Charterでは範囲外であり、ここで背景情報として提供されています。
This ASA includes the information distribution function in an Autonomic Network. In particular, it acts to announce the availability of Intent and other information to all other autonomic nodes. This ASA does not need to be installed on all nodes, but only on nodes that implement the information distribution function. For details, see Section 4.7.
このASAは、自律型ネットワーク内の情報配信機能を含みます。特に、それは他のすべての自律本ノードへの意図およびその他の情報の可用性を発表するように機能します。このASAはすべてのノードにインストールする必要はありませんが、情報配信機能を実装するノードだけではありません。詳しくは4.7項を参照してください。
Note that information distribution can be implemented as a function in any ASA. See [GRASP-DISTRIB] for more details on how information is suggested to be distributed.
情報配信は、ASAの関数として実装できます。情報を配布する方法の提案方法について詳しくは、[把握分散]を参照してください。
This section describes how an Autonomic Network is managed and programmed.
このセクションでは、オートノミックネットワークの管理とプログラム方法について説明します。
Autonomic management usually coexists with traditional management methods in most networks. Thus, autonomic behavior will be defined for individual functions in most environments. Examples of overlap are:
自律管理管理は通常、ほとんどのネットワークで従来の管理方法と共存します。したがって、オートノミック動作は、ほとんどの環境で個々の機能に対して定義されます。オーバーラップの例は次のとおりです。
* Autonomic functions can use traditional methods and protocols (e.g., SNMP and the Network Configuration Protocol (NETCONF)) to perform management tasks, inside and outside the ACP.
* 自律神経機能は、ACPの内外で管理タスクを実行するために、従来のメソッドおよびプロトコル（例えば、SNMPおよびネットワーク構成プロトコル（NETCONF））を使用することができます。
* Autonomic functions can conflict with behavior enforced by the same traditional methods and protocols.
* 自律神経機能は、同じ従来のメソッドとプロトコルによって強制される動作と競合する可能性があります。
* Traditional functions can use the ACP, for example, if reachability on the data plane is not (yet) established.
* データプレーン上の到達可能性が（まだ）確立されていない場合、伝統的な機能はACPを使用できます。
The autonomic Intent is defined at a high level of abstraction. However, since it is necessary to address individual managed elements, autonomic management needs to communicate in lower-level interactions (e.g., commands and requests). For example, it is expected that the configuration of such elements be performed using NETCONF and YANG modules as well as the monitoring be executed through SNMP and MIBs.
自律型の意図は、高レベルの抽象化で定義されています。ただし、個々の管理対象要素に対処する必要があるため、自律管理管理は、低レベルのインタラクション（例えば、コマンドと要求）で通信する必要があります。例えば、そのような要素の構成は、NETCONFおよびYANGモジュールを使用して実行され、SNMPおよびMIBを介して監視を実行することが予想される。
Conflict can occur between autonomic default behavior, autonomic Intent, and traditional management methods. Conflict resolution is achieved in autonomic management through prioritization [RFC7575]. The rationale is that manual and node-based management have a higher priority than autonomic management. Thus, the autonomic default behavior has the lowest priority, then comes the autonomic Intent (medium priority), and, finally, the highest priority is taken by node-specific network management methods, such as the use of command-line interfaces.
競合は、自律型のデフォルトの動作、自律的な意図、および従来の管理方法の間で発生する可能性があります。競合解決は、優先順位付けを通じて自律管理で達成されます[RFC7575]。根拠は、マニュアルとノードベースの管理が自律管理よりも優先順位が高いということです。したがって、自律型のデフォルトの動作は最優先順位が最も低いので、自律型の意図（中優先順位）になり、最後に、コマンドラインインタフェースの使用などのノード固有のネットワーク管理方法によって最大の優先順位が取られます。
Intent is not covered in the current implementation specifications. This section discusses a topic for further research.
現在の実装仕様では、意図はカバーされていません。このセクションでは、さらなる研究のトピックについて説明します。
This section gives an overview of Intent and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., Policy Core Information Model (PCIM)) and in other Standards Development Organizations (SDOs) (e.g., the Distributed Management Task Force (DMTF)).
このセクションでは、意図の概要と管理方法を説明します。意図および政策ベースのネットワーク管理（PBNM）は、IETF（例えば、Policy Core Information Model（PCIM））および他の規格開発組織（例えば、分散管理タスクフォース（DMTF））内で既に記述されている。
Intent can be described as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network [RFC7575]. Intent should be limited to high-level guidance only; thus, it does not directly define a policy for every network element separately.
インテントは、エンタープライズネットワーク[RFC7575]などの自律ドメインを操作するために使用される抽象的、宣言的で高水準のポリシーとして説明できます。意図は高レベルのガイダンスのみに制限されるべきです。したがって、ネットワーク要素すべてのネットワーク要素のポリシーを別々に定義しません。
Intent can be refined to lower-level policies using different approaches. This is expected in order to adapt the Intent to the capabilities of managed devices. Intent may contain role or function information, which can be translated to specific nodes [RFC7575]. One of the possible refinements of the Intent is using Event-Condition-Action (ECA) rules.
意図は、異なるアプローチを使用して低レベルのポリシーに洗練することができます。これは、管理対象デバイスの機能を適応させるために予想されます。Intentには、特定のノード[RFC7575]に変換することができる役割または機能情報が含まれている場合があります。意図の可能な改良の可能性の1つは、イベント状態 - アクション（ECA）規則を使用しています。
Different parameters may be configured for Intent. These parameters are usually provided by the human operator. Some of these parameters can influence the behavior of specific autonomic functions as well as the way the Intent is used to manage the autonomic domain.
意図のために異なるパラメータを構成することができる。これらのパラメータは通常、人間のオペレータによって提供されます。これらのパラメータのいくつかは、特定の自律型関数の動作、ならびに自律ドメインの管理に使用される方法に影響を与える可能性があります。
Intent is discussed in more detail in [ANIMA-INTENT]. Intent as well as other types of information are distributed via GRASP; see [GRASP-DISTRIB].
意図については、[Anima-Intent]で詳しく説明しています。意図や他の種類の情報はGRASP経由で配布されています。[把握分配]を参照してください。
Aggregated reporting is not covered in the current implementation specifications. This section discusses a topic for further research.
集約されたレポートは、現在の実装仕様ではカバーされていません。このセクションでは、さらなる研究のトピックについて説明します。
An Autonomic Network should minimize the need for human intervention. In terms of how the network should behave, this is done through an autonomic Intent provided by the human administrator. In an analogous manner, the reports that describe the operational status of the network should aggregate the information produced in different network elements in order to present the effectiveness of autonomic Intent enforcement. Therefore, reporting in an Autonomic Network should happen on a network-wide basis [RFC7575].
自律神経ネットワークは、人間の介入の必要性を最小限に抑えるべきです。ネットワークがどのように動作するかという点で、これは人間管理者によって提供された自律的な意図を通して行われます。同様に、ネットワークの動作状態を記述するレポートは、自律型の意図執行の有効性を提示するために、さまざまなネットワーク要素で生成された情報を集計する必要があります。したがって、自律型ネットワークへの報告はネットワーク全体で発生する必要があります[RFC7575]。
Multiple simultaneous events can occur in an Autonomic Network in the same way they can happen in a traditional network. However, when reporting to a human administrator, such events should be aggregated to avoid notifications about individual managed elements. In this context, algorithms may be used to determine what should be reported (e.g., filtering), how it should be reported, and how different events are related to each other. Besides that, an event in an individual element can be compensated by changes in other elements to maintain a network-wide target that is described in the autonomic Intent.
複数の同時イベントは、従来のネットワークで発生する可能性があるのと同じ方法で、自律型ネットワークで発生する可能性があります。ただし、人間の管理者に報告するとき、そのようなイベントは個々の管理対象要素に関する通知を回避するために集約されるべきです。これに関連して、アルゴリズムを使用して、報告されるべきもの（例えば、フィルタリング）、報告されるべきこと、および互いに異なるイベントがどのように関連しているかを決定することができる。それ以外に、個々の要素内のイベントは、自律型の意図に記載されているネットワーク全体のターゲットを維持するために他の要素の変更によって補償され得る。
Reporting in an Autonomic Network may be at the same abstraction level as Intent. In this context, the aggregated view of the current operational status of an Autonomic Network can be used to switch to different management modes. Despite the fact that autonomic management should minimize the need for user intervention, some events may need to be addressed by the actions of a human administrator.
自律神経ネットワークにおける報告は、意図と同じ抽象化レベルであり得る。これに関連して、オートノミックネットワークの現在の動作状態の集約ビューを使用して、異なる管理モードに切り替えることができます。自律神経経営者がユーザの介入の必要性を最小限に抑えるべきであるにもかかわらず、いくつかのイベントは人間の管理者の行動によって対処される必要があるかもしれません。
Feedback loops are required in an Autonomic Network to allow the intervention of a human administrator or central control systems while maintaining a default behavior. Through a feedback loop, an administrator must be prompted with a default action and has the possibility to acknowledge or override the proposed default action.
デフォルトの動作を維持しながら、ヒューマン管理者または中央制御システムの介入を可能にするために、自律型ネットワークではフィードバックループが必要です。フィードバックループを介して、管理者はデフォルトのアクションで求められ、提案されたデフォルトアクションを確認または上書きする可能性があります。
Unidirectional notifications to the Network Operations Center (NOC) that do not propose any default action and do not allow an override as part of the transaction are considered like traditional notification services, such as syslog. They are expected to coexist with autonomic methods but are not covered in this document.
デフォルトのアクションを提案しないネットワークオペレーションセンター（NOC）への単方向通知、およびトランザクションの一部として上書きを許可しないで、syslogなどの従来の通知サービスのように考慮されます。それらは自律的方法と共存することが期待されていますが、この文書ではカバーされていません。
Control loops are not covered in the current implementation specifications. This section discusses a topic for further research.
制御ループは、現在の実装仕様ではカバーされていません。このセクションでは、さらなる研究のトピックについて説明します。
Control loops are used in Autonomic Networking to provide a generic mechanism to enable the autonomic system to adapt (on its own) to various factors that can change the goals that the Autonomic Network is trying to achieve or how those goals are achieved. For example, as user needs, business goals, and the ANI itself changes, self-adaptation enables the ANI to change the services and resources it makes available to adapt to these changes.
対照ループは自律型ネットワーキングで使用され、自律神経システムが（独自）に適応させるための一般的なメカニズムを提供して、自律神経ネットワークが達成しようとしている目標を変更することができるさまざまな要因に適応させることができます。たとえば、ユーザーのニーズ、ビジネスの目標、およびANI自体が変更されるにつれて、自己適応により、ANIはこれらの変更に適応できるサービスとリソースを変更することができます。
Control loops operate to continuously observe and collect data that enables the autonomic management system to understand changes to the behavior of the system being managed and then provide actions to move the state of the system being managed toward a common goal. Self-adaptive systems move decision making from static, pre-defined commands to dynamic processes computed at runtime.
制御ループは、自律神経管理システムが管理されているシステムの動作への変更を理解してから共通の目標に管理されているシステムの状態を移動させるためのアクションを提供することを可能にするデータを継続的に観察して収集するように動作します。自己適応システムは、実行時に計算された動的プロセスに、静的な予め定義されたコマンドからの意思決定を行います。
Most autonomic systems use a closed control loop with feedback. Such control loops should be able to be dynamically changed at runtime to adapt to changing user needs, business goals, and changes in the ANI.
ほとんどの自律系システムはフィードバック付きの閉じた制御ループを使用します。このような制御ループは、実行時に動的に変更されて、ユーザーのニーズ、ビジネスの目標、およびANIの変更に適応するように適応させる必要があります。
[RFC8991] defines a conceptual outline for an API for the GeneRic Autonomic Signaling Protocol (GRASP). This conceptual API is designed for ASAs to communicate with other ASAs through GRASP. Full Standards Track API specifications are not covered in the current implementation specifications.
[RFC8991]一般自律神経シグナリングプロトコルのAPIの概念的な概要（GRASP）を定義します。この概念APIは、ASASがGRASPを通じて他のASAと通信するように設計されています。FULL Standards Track API仕様は、現在の実装仕様ではカバーされていません。
Most APIs are static, meaning that they are pre-defined and represent an invariant mechanism for operating with data. An Autonomic Network should be able to use dynamic APIs in addition to static APIs.
ほとんどのAPIは静的です。つまり、それらが事前定義されており、データを操作するための不変メカニズムを表します。自律型ネットワークは、静的APIに加えて動的APIを使用できるはずです。
A dynamic API retrieves data using a generic mechanism and then enables the client to navigate the retrieved data and operate on it. Such APIs typically use introspection and/or reflection. Introspection enables software to examine the type and properties of an object at runtime, while reflection enables a program to manipulate the attributes, methods, and/or metadata of an object.
動的APIは一般的なメカニズムを使用してデータを取得し、次にクライアントが検索されたデータをナビゲートして動作させることを可能にします。そのようなAPIは通常、イントロスペクションおよび/または反射を使用する。イントロスペクシには、ソフトウェアが実行時にオブジェクトの種類とプロパティを調べることができますが、Reflectionはプログラムがオブジェクトの属性、メソッド、および/またはメタデータを操作することを可能にします。
APIs must be able to express and preserve the semantics of data models. For example, software contracts [Meyer97] are based on the principle that a software-intensive system, such as an Autonomic Network, is a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations that interacting components must respect. This typically includes specifying:
APIはデータモデルのセマンティクスを表現して保存できる必要があります。例えば、ソフトウェア契約[Meyer97]は、自律型ネットワークなどのソフトウェア集約型システムであるという原則に基づいており、その相互作用が相互義務の正確に定義された仕様に基づく一連の通信コンポーネントであることを基本的に基づいています。これは通常、次のように指定されています。
* pre-conditions that must be satisfied before the method can start execution
* メソッドが実行を開始する前に満たす必要がある事前条件
* post-conditions that must be satisfied when the method has finished execution
* メソッドが実行を完了したときに満たされる必要がある条件
* invariant attributes that must not change during the execution of the method
* メソッドの実行中に変更しない不変属性
Data models are not covered in the current implementation specifications. This section discusses a topic for further research.
データモデルは現在の実装仕様ではカバーされていません。このセクションでは、さらなる研究のトピックについて説明します。
The following definitions of "data model" and "information model" are adapted from [SUPA-DATA].
以下の「データモデル」および「情報モデル」の定義は、[SUPA-DATA]から適応しています。
An information model is a representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, and protocol. In contrast, a data model is a representation of concepts of interest to an environment in a form that is dependent on data repository, data definition language, query language, implementation language, and protocol.
情報モデルは、データリポジトリ、データ定義言語、クエリ言語、実装言語、およびプロトコルとは無関係の形式の環境に対する興味の概念の表現です。対照的に、データモデルは、データリポジトリ、データ定義言語、クエリ言語、実装言語、およびプロトコルに依存する形の環境に対する関心の概念の表現です。
The utility of an information model is to define objects and their relationships in a technology-neutral manner. This forms a consensual vocabulary that the ANI and ASAs can use. A data model is then a technology-specific mapping of all or part of the information model to be used by all or part of the system.
情報モデルの有用性は、テクノロジの中立的な方法でオブジェクトとそれらの関係を定義することです。これは、ANIとASAが使用できる合意の語彙を形成します。データモデルは、システムの全部または一部によって使用される情報モデルの全部または一部の技術固有のマッピングである。
A system may have multiple data models. Operational Support Systems, for example, typically have multiple types of repositories, such as SQL and NoSQL, to take advantage of the different properties of each. If multiple data models are required by an autonomic system, then an information model should be used to ensure that the concepts of each data model can be related to each other without technological bias.
システムは複数のデータモデルを持つことができます。たとえば、運用サポートシステムは通常、それぞれの異なるプロパティを利用するために、SQLやNoSQLなどの複数の種類のリポジトリを持ちます。自律システムによって複数のデータモデルが必要な場合は、情報モデルを使用して、各データモデルの概念を技術的なバイアスなしで互いに関連付けることができるようにする必要があります。
A data model is essential for certain types of functions, such as a Model-Reference Adaptive Control Loop (MRACL). More generally, a data model can be used to define the objects, attributes, methods, and relationships of a software system (e.g., the ANI, an autonomic node, or an ASA). A data model can be used to help design an API, as well as any language used to interface to the Autonomic Network.
データモデルは、モデル基準適応制御ループ（MRACL）などの特定の種類の機能にとって不可欠です。より一般的には、データモデルを使用して、ソフトウェアシステム（例えば、ANI、自律ノード、またはASA）のオブジェクト、属性、方法、および関係を定義することができる。データモデルを使用して、APIを設計するのに役立ち、自律網へのインターフェースに使用される任意の言語を提供することができます。
Coordination between autonomic functions is not covered in the current implementation specifications. This section discusses a topic for further research.
自律型関数間の調整は、現在の実装仕様ではカバーされていません。このセクションでは、さらなる研究のトピックについて説明します。
Different autonomic functions may conflict in setting certain parameters. For example, an energy efficiency function may want to shut down a redundant link, while a load-balancing function would not want that to happen. The administrator must be able to understand and resolve such interactions to steer Autonomic Network performance to a given (intended) operational point.
特定のパラメータを設定すると、異なる自律型関数が競合する可能性があります。例えば、エネルギー効率関数は冗長リンクを停止したいが、負荷分散機能はそれを起こしたくないであろう。管理者は、特定の（意図された）運用ポイントへの自律神経ネットワーク性能を維持するためにそのような相互作用を理解し解決することができなければなりません。
Several interaction types may exist among autonomic functions, for example:
次のように、いくつかの対話型が自律型関数に存在する可能性があります。
* Cooperation: An autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function.
* 協力：自律神経機能は、トラフィック割り当て関数によって使用されるトラフィック予測関数のような他の自律型関数の動作または性能を向上させることができる。
* Dependency: An autonomic function cannot work without another one being present or accessible in the Autonomic Network.
* 依存関係：自律型関数は、自律型ネットワークで存在しなくてもアクセスできないものではありません。
* Conflict: A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions.
* 競合：メトリック値の競合は、1つのメトリックが異なる自律型関数のパラメータによって影響される衝突です。パラメータ値の競合は、1つのパラメータが異なる自律型関数によって変更された競合です。
Solving the coordination problem beyond one-by-one cases can rapidly become intractable for large networks. Specifying a common functional block on coordination is a first step to address the problem in a systemic way. The coordination life cycle consists of three states:
1つのケースを超えて調整問題を解決することは、大規模ネットワークにとって急速に難治性になる可能性があります。調整に関する一般的な機能ブロックを指定することは、システム上の方法で問題に対処するための最初のステップです。調整寿命サイクルは3つの状態で構成されています。
* At build-time, a "static interaction map" can be constructed on the relationship of functions and attributes. This map can be used to (pre-)define policies and priorities for identified conflicts.
* ビルド時には、関数と属性の関係に「静的インタラクションマップ」を構築することができます。このマップは、識別された競合のためのポリシーと優先順位の定義に（前）に使用できます。
* At deploy-time, autonomic functions are not yet active/acting on the network. A "dynamic interaction map" is created for each instance of each autonomic function on a per-resource basis, including the actions performed and their relationships. This map provides the basis to identify conflicts that will happen at runtime, categorize them, and plan for the appropriate coordination strategies and mechanisms.
* デプロイ時に、自律型関数はまだネットワーク上でアクティブ/行動されていません。「動的インタラクションマップ」は、実行されたアクションとそれらの関係を含む、リソースごとに各自律型関数の各インスタンスに対して作成されます。この地図は、実行時に発生し、それらを分類し、適切な調整戦略とメカニズムを計画するための競合を特定するための基礎を提供します。
* At runtime, when conflicts happen, arbitration is driven by the coordination strategies. Also, new dependencies can be observed and inferred, resulting in an update of the dynamic interaction map and adaptation of the coordination strategies and mechanisms.
* 実行時に、競合が発生すると、調停戦略によって仲裁が推進されます。また、新たな依存関係を観察し、推測することができ、動的相互作用マップの更新と調整戦略とメカニズムの適応をもたらします。
Multiple coordination strategies and mechanisms exist and can be devised. The set ranges from basic approaches (such as random process or token-based process), to approaches based on time separation and hierarchical optimization, to more complex approaches (such as multi-objective optimization and other control theory approaches and algorithm families).
複数の調整戦略とメカニズムが存在し、考案することができます。セットは、基本的なアプローチ（ランダムプロセスやトークンベースのプロセスなど）から、時間の分離と階層的最適化に基づいて、より複雑なアプローチ（マルチオブジェクト最適化や他の制御理論のアプローチやアルゴリズムファミリなど）に基づいて近づくことです。
A common coordination functional block is a desirable component of the ANIMA reference model. It provides a means to ensure network properties and predictable performance or behavior, such as stability and convergence, in the presence of several interacting autonomic functions.
共通の調整機能ブロックは、AniMa参照モデルの望ましい成分です。それは、いくつかの相互作用する自律型関数の存在下で、安定性および収束などのネットワーク特性および予測可能な性能または動作を確実にするための手段を提供する。
A common coordination function requires:
共通の調整機能には：
* A common description of autonomic functions, their attributes, and life cycle.
* 自律型関数、その属性、およびライフサイクルの一般的な説明。
* A common representation of information and knowledge (e.g., interaction maps).
* 情報と知識の一般的な表現（例えば、インタラクションマップ）。
* A common "control/command" interface between the coordination "agent" and the autonomic functions.
* 協調「エージェント」と自律型関数の間の一般的な「制御/コマンド」インタフェース。
Guidelines, recommendations, or BCPs can also be provided for aspects pertaining to the coordination strategies and mechanisms.
調整戦略およびメカニズムに関する側面についても、ガイドライン、推奨事項、またはBCPを提供することもできます。
In this section, we distinguish outsider and insider attacks. In an outsider attack, all network elements and protocols are securely managed and operating, and an outside attacker can sniff packets in transit, inject, and replay packets. In an insider attack, the attacker has access to an autonomic node or other means (e.g., remote code execution in the node by exploiting ACP-independent vulnerabilities in the node platform) to produce arbitrary payloads on the protected ACP channels.
このセクションでは、アウトサイダーとインサイダーの攻撃を区別します。アウトサイダー攻撃では、すべてのネットワーク要素とプロトコルがしっかりと管理されていて動作されており、外部の攻撃者は輸送、注入、および再生パケットのパケットをスニフすることができます。インサイダー攻撃では、攻撃者は、保護されたACPチャネル上で任意のペイロードを生成するために、オートノミックノードまたは他の手段（ノードプラットフォーム内のACP非依存の脆弱性を利用することによって、ノード内のリモートコードの実行）にアクセスする。
If a system has vulnerabilities in the implementation or operation (configuration), an outside attacker can exploit such vulnerabilities to become an insider attacker.
システムが実装または操作（構成）で脆弱性を持っている場合、外部の攻撃者はそのような脆弱性を悪用してインサイダーの攻撃者になることができます。
Here, we assume that all systems involved in an Autonomic Network are secured and operated according to best current practices. These protection methods comprise traditional security implementation and operation methods (such as code security, strong randomization algorithms, strong passwords, etc.) as well as mechanisms specific to an Autonomic Network (such as a secured MASA service).
ここでは、自律神経ネットワークに関与するすべてのシステムが最良の現在の慣行に従って保護され運営されていると仮定しています。これらの保護方法は、従来のセキュリティ実装および操作方法（コードセキュリティ、強い無作為化アルゴリズム、強力なパスワードなど）、および自律網に固有のメカニズム（固定されたマササービスなど）を含む。
Traditional security methods for both implementation and operation are outside the scope of this document.
実装と操作の両方の従来のセキュリティ方法は、この文書の範囲外です。
AN-specific protocols and methods must also follow traditional security methods, in that all packets that can be sniffed or injected by an outside attacker are:
外部の攻撃者によって遮られるかまたは注入される可能性があるすべてのパケットは、従来のセキュリティメソッドと、特有のプロトコルとメソッドを続ける必要があります。
* protected against modification
* 修正から保護されています
* authenticated
* 認証された
* protected against replay attacks
* 再生攻撃から保護されています
* confidentiality protected (encrypted)
* 機密保持（暗号化）
In addition, the AN protocols should be robust against packet drops and man-in-the-middle attacks.
さらに、プロトコルは、パケットドロップや中間攻撃に対して堅牢であるべきです。
How these requirements are met is covered in the AN Standards Track documents that define the methods used, specifically [RFC8990], [RFC8994], and [RFC8995].
これらの要件が満たされる方法は、使用される方法、特に[RFC8990]、[RFC8994]、[RFC8995]を定義する標準トラック文書で説明されています。
Most AN messages run inside the cryptographically protected ACP. The unprotected AN messages outside the ACP are limited to a simple discovery method, defined in Section 2.5.2 of [RFC8990]: the Discovery Unsolicited Link-Local (DULL) message, with detailed rules on its usage.
ほとんどのメッセージは暗号化されて保護されたACP内で実行されます。保護されていない保護されていないメッセージは、[RFC8990]のセクション2.5.2で定義されている単純な検出方法に制限されています。
If AN messages can be observed by a third party, they might reveal valuable information about network configuration, security precautions in use, individual users, and their traffic patterns. If encrypted, AN messages might still reveal some information via traffic analysis.
メッセージが第三者によって観察され得る場合、それらはネットワーク構成、使用中のセキュリティ上の注意、個々のユーザー、およびそれらのトラフィックパターンに関する貴重な情報を明らかにするかもしれません。暗号化されている場合、メッセージはトラフィック分析によって何らかの情報を表示する可能性があります。
An Autonomic Network consists of autonomic devices that form a distributed self-managing system. Devices within a domain have credentials issued from a common trust anchor and can use them to create mutual trust. This means that any device inside a trust domain can by default use all distributed functions in the entire autonomic domain in a malicious way.
自律神経ネットワークは、分散型自主管理システムを構成する自律型装置で構成されています。ドメイン内のデバイスは、共通の信頼のアンカーから発行された資格情報を持ち、それらを使用して相互信頼を作成することができます。つまり、信頼ドメイン内の任意のデバイスは、デフォルトですべての分散関数を使用することができます。
An inside attacker, or an outsider in the presence of protocol vulnerabilities or insecure operation, has the following generic ways to take control of an Autonomic Network:
攻撃者の内部攻撃者、またはプロトコルの脆弱性または安全でない操作の存在下では、オートノミックネットワークを制御する一般的な方法があります。
* Introducing a fake device into the trust domain by subverting the authentication methods. This depends on the correct specification, implementation, and operation of the AN protocols.
* 認証方法を縮小することによって、偽デバイスを信頼ドメインに紹介します。これは、プロトコルの正しい仕様、実装、および動作によって異なります。
* Subverting a device that is already part of a trust domain and modifying its behavior. This threat is not specific to the solution discussed in this document and applies to all network solutions.
* すでに信頼ドメインの一部であるデバイスを縮小し、その動作を変更します。この脅威は、この文書で説明したソリューションに固有のものではなく、すべてのネットワークソリューションに適用されます。
* Exploiting potentially yet unknown protocol vulnerabilities in the AN or other protocols. This is also a generic threat that applies to all network solutions.
* ANまたは他のプロトコルにおける潜在的に未知のプロトコルの脆弱性を利用しています。これはすべてのネットワークソリューションに適用される一般的な脅威です。
The above threats are, in principle, comparable to other solutions: in the presence of design, implementation, or operational errors, security is no longer guaranteed. However, the distributed nature of AN, specifically the ACP, increases the threat surface significantly. For example, a compromised device may have full IP reachability to all other devices inside the ACP and can use all AN methods and protocols.
上記の脅威は、原則として、他の解決策に匹敵することができます。設計、実装、または運用上のエラーがある場合、セキュリティはもはや保証されていません。しかしながら、特にACPの分散性は脅威面を大きく増大させる。例えば、妥協のある装置は、ACP内の他のすべての装置への完全なIP到達可能性を有することができ、そしてすべての方法およびプロトコルを使用することができる。
For the next phase of the ANIMA Working Group, it is therefore recommended to introduce a subdomain security model to reduce the attack surface and not expose a full domain to a potential intruder. Furthermore, additional security mechanisms on the ASA level should be considered for high-risk autonomic functions.
したがって、Anima Working Groupの次の段階では、攻撃面を小さくし、潜在的な侵入者に全体のドメインを公開するためにサブドメインセキュリティモデルを導入することをお勧めします。さらに、ASAレベルの追加のセキュリティメカニズムは、高リスクの自律型機能のために考慮されるべきです。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[IDevID] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR, <https://1.ieee802.org/security/802-1ar>.
[IDEVID] IEEE、「ローカルとメトロポリタンエリアネットワークのIEEE規格 - Secure Device Identity」、IEEE 802.1ar、<https：//1.ieee802.org/security/802-1a>。
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.
[RFC8990] Bormann、C、Carpenter、B.、ED。、およびB.IU、ED。、「GENICAL自律型シグナリングプロトコル（GRASP）」、RFC 8990、DOI 10.17487 / RFC8990、2021年5月、<https：//www.rfc-editor.org/info/rfc8990>。
[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、「自律管理プレーン（ACP）」、RFC 8994、DOI 10.17487 / RFC8994、2021年5月、<https：//www.rfc-editor.org/info/rfc8994>。
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC8995] Pritikin、M.、Richardson、M.、Eckert、T.、Behringer、M.、およびK. Watsen、「ブートストラップリモートセキュリティキーインフラストラクチャ（Brski）」、RFC 8995、DOI 10.17487 / RFC8995、2021年5月<https://www.rfc-editor.org/info/rfc8995>。
[ANIMA-INTENT] Du, Z., Jiang, S., Nobre, J. C., Ciavaglia, L., and M. Behringer, "ANIMA Intent Policy and Format", Work in Progress, Internet-Draft, draft-du-anima-an-intent-05, 14 February 2017, <https://tools.ietf.org/html/draft-du-anima-an-intent-05>.
[Anima-Intent] du、Z.、Jiang、S.、Nobre、JC、Ciavaglia、L.、およびM. Behringer、 "Anima Intent Policy and Format"、進行中の作業、インターネットドラフト、ドラフトデュアニマ-an-Intent-05,2017、<https://tools.ietf.org/html/draft-du-anima-an-intent-05>
[ASA-GUIDELINES] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso, "Guidelines for Autonomic Service Agents", Work in Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-00, 14 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-asa-guidelines-00>.
[ASAガイドライン] Carpenter、B.、Ciavaglia、L.、Jiang、S.、およびP. Peloso、「自律サービスエージェントのためのガイドライン」、進行中、インターネットドラフト、ドラフトIETF-ANIMA-ASAガイドライン-00、2020年11月14日、<https://tools.ietf.org/html/draft-ietf-anima-asa-guldelines-00>。
[GRASP-DISTRIB] Liu, B., Ed., Xiao, X., Ed., Hecker, A., Jiang, S., Despotovic, Z., and B. Carpenter, "Information Distribution over GRASP", Work in Progress, Internet-Draft, draft-ietf-anima-grasp-distribution-02, 8 March 2021, <https://tools.ietf.org/html/draft-ietf-anima-grasp-distribution-02>.
[把持分配] Liu、B.、Ed。、Xiao、X.、ED。、ヘッカ、A.、Jiang、S.、Pessotovic、Z.、およびB. Carpenter、「把握上の情報配信」、働く進捗状況、インターネットドラフト、ドラフト-IETF-ANIMA-GRASP-DISTRAIGS-02,2021、<https：//tools.ietf.org/html/draft-ietf-anima-grasp-distribution-02>。
[Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd edition)", Prentice Hall, ISBN 978-0136291558, 1997.
[Meyer97] Meyer、B.、「オブジェクト指向ソフトウェア構築（第2版）」、Prentice Hall、ISBN 978-0136291558,1997。
[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>。
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, <https://www.rfc-editor.org/info/rfc7576>.
[RFC7576] Jiang、S.、Carpenter、B.およびM. Behringer、「自律ネットワーキングのための一般的なギャップ分析」、RFC 7576、DOI 10.17487 / RFC7576、2015年6月、<https：//www.rfc-editor.org/ info / rfc7576>。
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)", RFC 8368, DOI 10.17487/RFC8368, May 2018, <https://www.rfc-editor.org/info/rfc8368>.
[RFC8368] Eckert、T.、ED。M. Behringer、「ネットワーク事業の安定した接続、管理、メンテナンス（OAM）」、RFC 8368、DOI 10.17487 / RFC8368、2018年5月、<https：//www.rfc-editor.org/ info / rfc8368>。
[RFC8991] Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong, "GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991, May 2021, <https://www.rfc-editor.org/info/rfc8991>.
[RFC8991]大工、B.、Liu、B、Ed。、Wang、W.、およびX. Gong、 "Genical Autical Signaling Protocolアプリケーションプログラムインタフェース（Grasp API）"、RFC 8991、DOI 10.17487 / RFC8991、2021年5月<https：//www.rfc-editor.org/info/rfc8991>。
[RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun, "Autonomic IPv6 Edge Prefix Management in Large-Scale Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021, <https://www.rfc-editor.org/info/rfc8992>.
[RFC8992] Jiang、S.、Ed。、DU、Z.、Carpenter、B.、およびQ. Sun、「大規模ネットワークにおける自律型IPv6エッジプレフィックス管理」、RFC 8992、DOI 10.17487 / RFC8992、2021年5月<https://www.rfc-editor.org/info/rfc8992>。
[SUPA-DATA] Halpern, J. and J. Strassner, "Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)", Work in Progress, Internet-Draft, draft-ietf-supa-generic-policy-data-model-04, 18 June 2017, <https://tools.ietf.org/html/ draft-ietf-supa-generic-policy-data-model-04>.
[SUPA-DATA] HALPERN、J.およびJ.STRASSNER、「Policy Abstrisions（SUPA）の使用のための一般的なポリシーデータモデル」、進行中の作業、インターネットドラフト、ドラフト-IETF-SUPA-Generic Policy-Data-Model-04,18 2017年6月18日、<https：//tools.ietf.org/html/ romft-ietf-supa-generic-policy-data-model-04>。
Acknowledgements
謝辞
The following people provided feedback and input to this document: Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, and Artur Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, Tianran Zhou, and Christian Hopps.
以下の人々はこの文書へのフィードバックと入力を提供しました：Sheng Jiang、Roberta Maglione、Jonathan Hansford、Jason Coleman、Artur Hecker。Joel Halpern、Radia Perlman、Tianran Zhou、およびChristian Hoppsによって有用レビューが行われました。
Contributors
貢献者
Significant contributions to this document were made by John Strassner (Huawei), Bing Liu (Huawei), and Pierre Peloso (Nokia).
この文書への重要な貢献は、John Strassner（Huawei）、Bing Liu（Huawei）、およびPierre Peloso（Nokia）によって行われました。
Authors' Addresses
著者の住所
Michael H. Behringer (editor)
Michael H. Behringer（編集）
Email: Michael.H.Behringer@gmail.com
Brian Carpenter School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
オークランド大学Brian Carpenter School of Auckland PB 92019オークランド1142ニュージーランド
Email: brian.e.carpenter@gmail.com
Toerless Eckert Futurewei USA 2330 Central Expy Santa Clara, CA 95050 United States of America
TOERLESS ECKERT FUTUREWEI USA 2330中央費用サンタクララ、CA 95050アメリカ合衆国
Email: tte+ietf@cs.fau.de
Laurent Ciavaglia Nokia Villarceaux 91460 Nozay France
Laurent Ciavaglia Nokia Villarceaux 91460 Nozay France
Email: laurent.ciavaglia@nokia.com
Jéferson Campos Nobre Federal University of Rio Grande do Sul (UFRGS) Av. Bento Gonçalves, 9500 Porto Alegre-RS 91501-970 Brazil
JéfersonCampos Nobre Rio Grande Do Sul（UFRGS）AV。BentoGonçalves、9500 Porto Alegre-RS 91501-970ブラジル
Email: jcnobre@inf.ufrgs.br