[要約] RFC 9222 は、自律ネットワーク向けの自律サービスエージェントの設計に関するガイドラインを提案しています。自律サービスエージェントは、自律ネットワークエコシステムの基本要素であり、自律ネットワークインフラストラクチャ、自律制御プレーン、およびジェネリック自律シグナリングプロトコルと共に構成されています。
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 9222 Univ. of Auckland
Category: Informational L. Ciavaglia
ISSN: 2070-1721 Rakuten Mobile
S. Jiang
Huawei Technologies Co., Ltd
P. Peloso
Nokia
March 2022
Guidelines for Autonomic Service Agents
自律サービスエージェントのガイドライン
Abstract
概要
This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic Control Plane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem.
この文書は、自律型ネットワークの自律型サービスエージェントの設計に関するガイドラインを提案しています。自律型サービスエージェントは、自律型ネットワークインフラストラクチャ、自律統制プレーン、および一般的な自律型シグナリングプロトコルと共に、自律実体ネットワーキング生態系の基本要素を構成します。
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/rfc9222.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9222で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Logical Structure of an Autonomic Service Agent
4. Interaction with the Autonomic Networking Infrastructure
4.1. Interaction with the Security Mechanisms
4.2. Interaction with the Autonomic Control Plane
4.3. Interaction with GRASP and its API
4.4. Interaction with Policy Mechanisms
5. Interaction with Non-autonomic Components and Systems
6. Design of GRASP Objectives
7. Life Cycle
7.1. Installation Phase
7.1.1. Installation Phase Inputs and Outputs
7.2. Instantiation Phase
7.2.1. Operator's Goal
7.2.2. Instantiation Phase Inputs and Outputs
7.2.3. Instantiation Phase Requirements
7.3. Operation Phase
7.4. Removal Phase
8. Coordination and Data Models
8.1. Coordination between Autonomic Functions
8.2. Coordination with Traditional Management Functions
8.3. Data Models
9. Robustness
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Example Logic Flows
Acknowledgements
Authors' Addresses
This document proposes guidelines for the design of Autonomic Service Agents (ASAs) in the context of an Autonomic Network (AN) based on the Autonomic Network Infrastructure (ANI) outlined in the autonomic networking reference model [RFC8993]. This infrastructure makes use of the Autonomic Control Plane (ACP) [RFC8994] and the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990]. A general introduction to this environment may be found at [IPJ], which also includes explanatory diagrams, and a summary of terminology is in Section 2.
この資料は、自律ネットワークインフラストラクチャ（ANI）のコンテキストにおける自律型サービスエージェント（ASAS）の設計のガイドライン（Autonomic Network Infrastructure（ANI）を提案しています[RFC8993]。このインフラストラクチャは、自律制御プレーン（ACP）[RFC8994]と一般的な自律型シグナリングプロトコル（GRASP）[RFC8990]を利用します。この環境の一般的な紹介は、説明図を含む[IPJ]で見つけることができ、ターメロの概要はセクション2にあります。
This document is a contribution to the description of an autonomic networking ecosystem, recognizing that a deployable autonomic network needs more than just ACP and GRASP implementations. Such an autonomic network must achieve management tasks that a Network Operations Center (NOC) cannot readily achieve manually, such as continuous resource optimization or automated fault detection and repair. These tasks, and other management automation goals, are described at length in [RFC7575]. The net result should be significant operational improvement. To achieve this, the autonomic networking ecosystem must include at least a library of ASAs and corresponding GRASP technical objective definitions. A GRASP objective [RFC8990] is a data structure whose main contents are a name and a value. The value consists of a single configurable parameter or a set of parameters of some kind.
この文書は、展開可能な自律神経ネットワークが単なるACP以上の実装以上のものを必要とすることを認識して、自律技術ネットワーク生態系の説明への貢献です。そのような自律神経ネットワークは、連続リソース最適化または自動故障検出および修理など、ネットワークオペレーションセンター（NOC）が手動で容易に達成できないという管理タスクを達成しなければならない。これらのタスク、およびその他の管理オートメーションの目標は、[RFC7575]の長さで説明されています。正味の結果は著しい運営改善になるはずです。これを達成するために、自律型ネットワーキングエコシステムは、ASASのライブラリと対応する技術的目標の定義のライブラリを含める必要があります。GRASP目標[RFC8990]は、主な内容が名前と値のデータ構造です。値は、単一の設定可能なパラメータまたはある種のパラメータのセットで構成されています。
There must also be tools to deploy and oversee ASAs, and integration with existing operational mechanisms [RFC8368]. However, this document focuses on the design of ASAs, with some reference to implementation and operational aspects.
ASASを展開および監督するためのツール、および既存の運用メカニズムとの統合も必要です[RFC8368]。ただし、この文書はASAの設計に焦点を当てており、実装や運用の側面へのいくつかの参考です。
There is considerable literature about autonomic agents with a variety of proposals about how they should be characterized. Some examples are [DEMOLA06], [HUEBSCHER08], [MOVAHEDI12], and [GANA13]. However, for the present document, the basic definitions and goals for autonomic networking given in [RFC7575] apply. According to RFC 7575, an Autonomic Service Agent is "An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole."
特徴的な方法についてのさまざまな提案を持つ自律技術者についてはかなりの文献があります。いくつかの例は[Demola06]、[HuebsCher08]、[Movahedi12]、[Gana13]です。ただし、本文書では、[RFC7575]で与えられた自律技術ネットワーキングの基本的な定義と目標が適用されます。RFC 7575によると、自律型サービスエージェントは「自律型関数を実装するエージェント」であり、（分散関数の場合は全体の場合）または全体のいずれかで、自律型関数を実装しています。
ASAs must be distinguished from other forms of software components. They are components of network or service management; they do not in themselves provide services to end users. They do, however, provide management services to network operators and administrators. For example, the services envisaged for network function virtualization (NFV) [NFV] or for service function chaining (SFC) [RFC7665] might be managed by an ASA rather than by traditional configuration tools.
ASAは他の形態のソフトウェアコンポーネントと区別されなければなりません。それらはネットワークまたはサービス管理のコンポーネントです。彼らは自分自身ではエンドユーザーにサービスを提供していません。ただし、ネットワーク事業者や管理者に管理サービスを提供しています。たとえば、ネットワーク機能仮想化（NFV）[NFV]またはサービス機能連鎖（SFC）の場合は、従来の構成ツールではなくASAによって管理されることがあります。
Another example is that an existing script running within a router to locally monitor or configure functions or services could be upgraded to an ASA that could communicate with peer scripts on neighboring or remote routers. A high-level API will allow such upgraded scripts to take full advantage of the secure ACP and the discovery, negotiation, and synchronization features of GRASP. Familiar tasks such as configuring an Interior Gateway Protocol (IGP) on neighboring routers or even exchanging IGP security keys could be performed securely in this way. This document mainly addresses issues affecting quite complex ASAs, but initially, the most useful ASAs may in fact be rather simple evolutions of existing scripts.
もう1つの例は、ローカルに機能またはサービスを構成するためのルータ内で実行されている既存のスクリプトが、隣接またはリモートルータのピアスクリプトと通信できるASAにアップグレードされる可能性があることです。高レベルのAPIは、そのようなアップグレードされたスクリプトが、セキュアACPとGraspの検出、ネゴシエーション、および同期機能を最大限に活用することを可能にします。このようにして、隣接ルータにインテリアゲートウェイプロトコル（IGP）を設定するなどのおなじみのタスクをしっかりと実行できます。この文書は主に非常に複雑なASAに影響を与える問題に対処していますが、最初は最も便利なASAが実際には既存のスクリプトのかなり単純な進化である可能性があります。
The reference model [RFC8993] for autonomic networks explains further the functionality of ASAs by adding the following:
自律型ネットワークの参照モデル[RFC8993]は、次のものを追加することによってASAの機能をさらに説明します。
| [An ASA 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.
As mentioned, there will certainly be simple ASAs that manage a single objective in a straightforward way and do not need asynchronous operations. In nodes where computing power and memory space are limited, ASAs should run at a much lower frequency than the primary workload, so CPU load should not be a big issue, but memory footprint in a constrained node is certainly a concern. ASAs installed in constrained devices will have limited functionality. In such cases, many aspects of the current document do not apply. However, in the general case, an ASA may be a relatively complex software component that will in many cases control and monitor simpler entities in the same or remote host(s). For example, a device controller that manages tens or hundreds of simple devices might contain a single ASA.
上述のように、確かに単一の目的を簡単な方法で管理し、非同期操作を必要としないような簡単なASAになるでしょう。コンピューティング電力とメモリ空間が制限されているノードでは、ASASはプライマリワークロードよりもはるかに低い周波数で実行されるため、CPU負荷は大きな問題になる必要がありますが、制約ノード内のメモリフットプリントは確かに懸念されます。制約付きデバイスにインストールされているASAは機能性が制限されます。そのような場合、現在の文書の多くの側面は適用されません。ただし、一般的な場合では、ASAは、多くの場合、同じまたはリモートホスト内のより単純なエンティティを制御および監視することになる比較的複雑なソフトウェアコンポーネントであり得る。たとえば、TENSまたは何百もの単純なデバイスを管理するデバイスコントローラには、1つのASAが含まれている可能性があります。
The remainder of this document offers guidance on the design of complex ASAs. Some of the material may be familiar to those experienced in distributed fault-tolerant and real-time control systems. Robustness and security are of particular importance in autonomic networks and are discussed in Sections 9 and 10.
この文書の残りの部分は、複雑なASAの設計に関するガイダンスを提供します。いくつかの材料は、分散型フォールトトレラントおよびリアルタイム制御システムで経験されたものによく知られている可能性があります。堅牢性とセキュリティは自律神経ネットワークでは特に重要であり、セクション9と10で説明されています。
This section summarizes various acronyms and terminology used in the document. Where no other reference is given, please consult [RFC8993] or [RFC7575].
この節では、文書で使用されているさまざまな頭字語と用語をまとめたものです。その他の参照が与えられていない場合は、[RFC8993]または[RFC7575]にお問い合わせください。
Autonomic: self-managing (self-configuring, self-protecting, self-healing, self-optimizing), but allowing high-level guidance by a central entity such as a NOC
自律神経：自己管理（自己管理、自己保護、自己修復、自己最適化）、しかし、NOCなどの中心的な企業による高レベルのガイダンスを可能にする
Autonomic Function: a function that adapts on its own to a changing environment
自律神経機能：変化する環境に独自に適応する関数
Autonomic Node: a node that employs autonomic functions
自律ノード：自律型関数を使用するノード
ACP: Autonomic Control Plane [RFC8994]
ACP：オートノミックコントロールプレーン[RFC8994]
AN: Autonomic Network; a network of autonomic nodes, which interact directly with each other
AN：オートノミックネットワーク。互いに直接対話する自律ノードのネットワーク
ANI: Autonomic Network Infrastructure
ANI：自律技術ネットワークインフラストラクチャー
ASA: Autonomic Service Agent; an agent installed on an autonomic node that implements an autonomic function, either partially (in the case of a distributed function) or completely
ASA：自律型サービスエージェント。独自関数を実装する自律型ノードにインストールされているエージェント（分散関数の場合）または完全に
BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995]
BRSKI：ブートストラップリモートセキュアキーインフラストラクチャ[RFC8995]
CBOR: Concise Binary Object Representation[RFC8949]
CBOR：簡潔なバイナリオブジェクト表現[RFC8949]
GRASP: GeneRric Autonomic Signaling Protocol [RFC8990]
把握：寛大な自律神経シグナリングプロトコル[RFC8990]
GRASP API: GRASP Application Programming Interface [RFC8991]
GRASS API：Application Programming Interface [RFC8991]
NOC: Network Operations Center [RFC8368]
NOC：ネットワークオペレーションセンター[RFC8368]
Objective: A GRASP technical objective is a data structure whose main contents are a name and a value. The value consists of a single configurable parameter or a set of parameters of some kind [RFC8990].
目的：把握技術目的は、主な内容が名前と値であるデータ構造である。値は、単一の設定可能なパラメータまたはある種のパラメータのセット[RFC8990]で構成されています。
As mentioned above, all but the simplest ASAs will need to support asynchronous operations. Different programming environments support asynchronicity in different ways. In this document, we use an explicit multi-threading model to describe operations. This is illustrative, and alternatives to multi-threading are discussed in detail in connection with the GRASP API (see Section 4.3).
上記のように、最も簡単なASAは非同期操作をサポートする必要があります。さまざまなプログラミング環境はさまざまな方法で非同期性をサポートします。このドキュメントでは、操作を説明するために明示的なマルチスレッドモデルを使用します。これは例示であり、マルチスレッドへの代替案はGRASP APIに関連して詳細に説明されている（セクション4.3を参照）。
A typical ASA will have a main thread that performs various initial housekeeping actions such as:
典型的なASAは、次のようなさまざまな初期のハウスキーピングアクションを実行するメインスレッドを持ちます。
* obtain authorization credentials, if needed
* 必要に応じて認証資格情報を入手してください
* register the ASA with GRASP
* graspでASAを登録してください
* acquire relevant policy parameters
* 関連するポリシーパラメータを取得します
* declare data structures for relevant GRASP objectives
* 関連する把握目的のためのデータ構造を宣言します
* register with GRASP those objectives that it will actively manage
* 積極的に管理する目的を把握する
* launch a self-monitoring thread
* 自己監視スレッドを起動します
* enter its main loop
* メインループを入力してください
The logic of the main loop will depend on the details of the autonomic function concerned. Whenever asynchronous operations are required, extra threads may be launched. Examples of such threads include:
メインループのロジックは、関係する自律型関数の詳細によって異なります。非同期操作が必要なときはいつでも、余分なスレッドが起動される可能性があります。そのようなスレッドの例は次のとおりです。
* repeatedly flood an objective to the AN so that any ASA can receive the objective's latest value
* ASAが目的の最新の値を受け取ることができるように、繰り返しANをANに充填する
* accept incoming synchronization requests for an objective managed by this ASA
* このASAによって管理されている目的のための着信同期要求を受け入れる
* accept incoming negotiation requests for an objective managed by this ASA, and then conduct the resulting negotiation with the counterpart ASA
* このASAによって管理されている目的のための着信交渉要求を受け入れてから、その結果として得られた交渉をASAに基づいて行ってください。
* manage subsidiary non-autonomic devices directly
* 子会社の非自律型装置を直接管理する
These threads should all either exit after their job is done or enter a wait state for new work to avoid wasting system resources.
これらのスレッドは、それらのジョブが完了した後に終了するか、システムリソースの無駄を避けるために新しい作業の待機状態を入力する必要があります。
According to the degree of parallelism needed by the application, some of these threads might be launched in multiple instances. In particular, if negotiation sessions with other ASAs are expected to be long or to involve wait states, the ASA designer might allow for multiple simultaneous negotiating threads, with appropriate use of queues and synchronization primitives to maintain consistency.
アプリケーションによって必要とされる並列度によると、これらのスレッドのいくつかは複数のインスタンスで起動される可能性があります。特に、他のASASとのネゴシエーションセッションが長くなると予想される場合、または待機状態を伴う場合、ASAデザイナは、一貫性を維持するためにキューと同期プリミティブを適切に使用して、複数の同時交渉スレッドを可能にする可能性があります。
The main loop itself could act as the initiator of synchronization requests or negotiation requests when the ASA needs data or resources from other ASAs. In particular, the main loop should watch for changes in policy parameters that affect its operation and, if appropriate, occasionally refresh authorization credentials. It should also do whatever is required to avoid unnecessary resource consumption, for example, by limiting its frequency of execution.
主ループ自体は、ASAが他のASAからデータまたはリソースを必要とする場合、同期要求またはネゴシエーション要求のイニシエータとして機能する可能性があります。特に、メインループは、その操作に影響を与えるポリシーパラメータの変更を監視し、必要に応じて許可認証情報を更新します。また、実行頻度を制限することによって、不要なリソース消費を避けるために必要なものは何でもする必要があります。
The self-monitoring thread is of considerable importance. Failure of autonomic service agents is highly undesirable. To a large extent, this depends on careful coding and testing, with no unhandled error returns or exceptions, but if there is nevertheless some sort of failure, the self-monitoring thread should detect it, fix it if possible, and, in the worst case, restart the entire ASA.
自己監視糸はかなり重要である。自律型サービスエージェントの障害は非常に望ましくありません。大幅に、これは慎重なコーディングとテストに依存しています。ケースはASA全体を再起動します。
Appendix A presents some example logic flows in informal pseudocode.
付録Aは、非公式の疑似コードにおける論理フローの例をいくつか示しています。
An ASA by definition runs in an autonomic node. Before any normal ASAs are started, such nodes must be bootstrapped into the autonomic network's secure key infrastructure, typically in accordance with [RFC8995]. This key infrastructure will be used to secure the ACP (next section) and may be used by ASAs to set up additional secure interactions with their peers, if needed.
定義によるASAは自律ノードで実行されます。通常のASASが開始される前に、そのようなノードは通常[RFC8995]に従って、自律型ネットワークの安全なキーインフラストラクチャにブートストラップする必要があります。このキーインフラストラクチャは、ACP（次のセクション）を保護するために使用され、必要に応じてASASによって使用されます。
Note that the secure bootstrap process itself incorporates simple special-purpose ASAs that use a restricted mode of GRASP (Section 4 of [RFC8995]).
セキュアブートストラッププロセス自体は、制限された把握モードを使用する単純な専用ASASを組み込んでいます（[RFC8995]のセクション4）。
In a normal autonomic network, ASAs will run as clients of the ACP, which will provide a fully secured network environment for all communication with other ASAs, in most cases mediated by GRASP (next section).
通常のオートノミックネットワークでは、ASASはACPのクライアントとして実行されます。これは、他のASAとのすべての通信に対して完全に保護されたネットワーク環境（次のセクション）によって仲介されます。
Note that the ACP formation process itself incorporates simple special-purpose ASAs that use a restricted mode of GRASP (Section 6.4 of [RFC8994]).
ACP形成プロセス自体には、制限された把握モードを使用する単純な専用ASAが組み込まれています（[RFC8994]のセクション6.4）。
In a node where a significant number of ASAs are installed, GRASP [RFC8990] is likely to run as a separate process with its API [RFC8991] available in user space. Thus, ASAs may operate without special privilege, unless they need it for other reasons. The ASA's view of GRASP is built around GRASP objectives (Section 6), defined as data structures containing administrative information such as the objective's unique name, and its current value. The format and size of the value is not restricted by the protocol, except that it must be possible to serialize it for transmission in Concise Binary Object Representation (CBOR) [RFC8949], subject only to GRASP's maximum message size as discussed in Section 6.
かなりの数のASAがインストールされているノードでは、[RFC8990]がAPI [RFC8991]をユーザースペースで使用可能な別のプロセスとして実行される可能性があります。したがって、ASASは他の理由でそれを必要としない限り、特別な特権なしで動作することがあります。ASAのGRASPの見解は、目的の固有の名前などの管理情報を含むデータ構造として定義されているGRASP目標（セクション6）の周囲に構築されています。値のフォーマットとサイズは、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]で送信するためにそれをシリアル化することが可能である必要がある場合を除き、セクション6で説明したようにGRASPの最大メッセージサイズにのみ対象となることを除いて、プロトコルによって制限されません。
As discussed in Section 3, GRASP is an asynchronous protocol, and this document uses a multi-threading model to describe operations. In many programming environments, an "event loop" model is used instead, in which case each thread would be implemented as an event handler called in turn by the main loop. For this case, the GRASP API must provide non-blocking calls and possibly support callbacks. This topic is discussed in more detail in [RFC8991], and other asynchronicity models are also possible. Whenever necessary, the GRASP session identifier will be used to distinguish simultaneous operations.
セクション3で説明したように、GRASPは非同期プロトコルであり、この文書はマルチスレッドモデルを使用して操作を説明する。多くのプログラミング環境では、代わりに「イベントループ」モデルが使用されています。その場合、各スレッドはメインループによって順番に呼び出されるイベントハンドラとして実装されます。この場合、GRASP APIは、ブロックされていない呼び出しを提供し、コールバックをサポートする必要があります。このトピックについては、[RFC8991]で詳しく説明し、他の非同期モデルも可能です。必要に応じて、把握セッション識別子は同時操作を区別するために使用されます。
The GRASP API should offer the following features:
GRASS APIは次の機能を提供する必要があります。
* Registration functions, so that an ASA can register itself and the objectives that it manages.
* ASAが自分自身とそれが管理する目的を登録できるように登録機能。
* A discovery function, by which an ASA can discover other ASAs supporting a given objective.
* ASAが特定の目的をサポートする他のASAを発見できる発見機能。
* A negotiation request function, by which an ASA can start negotiation of an objective with a counterpart ASA. With this, there is a corresponding listening function for an ASA that wishes to respond to negotiation requests and a set of functions to support negotiating steps. Once a negotiation starts, it is a symmetric process with both sides sending successive objective values to each other until agreement is reached (or the negotiation fails).
* ASAがASAを使用して目的の交渉を開始できる交渉要求機能。これにより、ネゴシエーション要求に応答したいASAのリスニング機能と、交渉ステップをサポートするための一連の機能があります。交渉が開始されると、合意に達するまで（またはネゴシエーションに失敗する）互いに連続する目的の値を互いに送信することが双方の対称的なプロセスです。
* A synchronization function, by which an ASA can request the current value of an objective from a counterpart ASA. With this, there is a corresponding listening function for an ASA that wishes to respond to synchronization requests. Unlike negotiation, synchronization is an asymmetric process in which the listener sends a single objective value to the requester.
* ASAが対象ASAから目的の現在の値を要求できる同期機能。これにより、同期要求に応答したいASAのための対応するリスニング機能がある。交渉とは異なり、同期はリスナーが単一の客観的な値をリクエスタに送信する非対称プロセスです。
* A flood function, by which an ASA can cause the current value of an objective to be flooded throughout the AN so that any ASA can receive it.
* ASAがANAを通して洪水にあふれさせることができるように、ASAがANAを通過することができる洪水機能。
For further details and some additional housekeeping functions, see [RFC8991].
詳細といくつかの追加のハウスキーピング機能については、[RFC8991]を参照してください。
The GRASP API is intended to support the various interactions expected between most ASAs, such as the interactions outlined in Section 3. However, if ASAs require additional communication between themselves, they can do so directly over the ACP to benefit from its security. One option is to use GRASP discovery and synchronization as a rendezvous mechanism between two ASAs, passing communication parameters such as a TCP port number via GRASP. The use of TLS over the ACP for such communications is advisable, as described in Section 6.9.2 of [RFC8994].
GRASS APIは、セクション3で概説されている対話など、ほとんどのASA間で予想されるさまざまな対話をサポートすることを目的としています。1つのオプションは、2つのASA間のランデブのメカニズムとしての把握と同期を使用し、TCPポート番号などの通信パラメータを把握します。[RFC8994]の第6.9.2項に記載されているように、そのような通信のためのACP上のTLSの使用は推奨されます。
At the time of writing, the policy mechanisms for the ANI are undefined. In particular, the use of declarative policies (aka Intents) for the definition and management of an ASA's behaviors remains a research topic [IBN-CONCEPTS].
書き込み時には、ANIのポリシーメカニズムは未定義です。特に、ASAの行動の定義と管理のための宣言的政策（別名の意図）の使用は、研究トピック[IBN概念]です。
In the cases where ASAs are defined as closed control loops, the specifications defined in [ZSM009-1] regarding imperative and declarative goal statements may be applicable.
ASASがクローズドコントロールループとして定義されている場合、命令と宣言的な目標ステートメントに関する[ZSM009-1]で定義されている仕様が適用可能です。
In the ANI, policy dissemination is expected to operate by an information distribution mechanism (e.g., via GRASP [RFC8990]) that can reach all autonomic nodes and therefore every ASA. However, each ASA must be capable of operating "out of the box" in the absence of locally defined policy, so every ASA implementation must include carefully chosen default values and settings for all policy parameters.
ANIでは、政策普及は、すべての自律型ノード、したがってすべてのASAに到達できる情報配信機構（例えば、Grasp [RFC8990]を介して）によって動作すると予想される。ただし、各ASAは、ローカルに定義されたポリシーがない場合に「箱から」操作できなければなりません。そのため、すべてのASA実装には、すべてのポリシーパラメータの慎重に選択されたデフォルト値と設定が含まれている必要があります。
To have any external effects, an ASA must also interact with non-autonomic components of the node where it is installed. For example, an ASA whose purpose is to manage a resource must interact with that resource. An ASA managing an entity that is also managed by local software must interact with that software. For example, if such management is performed by NETCONF [RFC6241], the ASA must interact with the NETCONF server as an independent NETCONF client in the same node to avoid any inconsistency between configuration changes delivered via NETCONF and configuration changes made by the ASA.
外部効果を持つために、ASAはインストールされているノードの非自律型コンポーネントと対話する必要があります。たとえば、リソースを管理する目的がそのリソースと対話する必要があります。ローカルソフトウェアによって管理されているエンティティを管理するASAは、そのソフトウェアと対話する必要があります。たとえば、このような管理がNETCONF [RFC6241]によって実行された場合、ASAは、NetConfを介して配信された構成変更とASAによって行われた構成変更との間の矛盾を回避するために、同じノード内の独立したNetConfクライアントとしてNetConfサーバと対話する必要があります。
In an environment where systems are virtualized and specialized using techniques such as network function virtualization or network slicing, there will be a design choice whether ASAs are deployed once per physical node or once per virtual context. A related issue is whether the ANI as a whole is deployed once on a physical network or whether several virtual ANIs are deployed. This aspect needs to be considered by the ASA designer.
システムが仮想化され、ネットワーク機能の仮想化やネットワークスライスなどのテクニックを使用して特殊化されている環境では、ASAが物理ノードごとに1回、または仮想コンテキストごとに1回展開されているかどうかをデザイン選択できます。関連する問題は、ANI全体が物理ネットワーク上で一度展開されているか、複数の仮想ANIがデプロイされているかどうかです。この側面はASAデザイナーによって考慮される必要があります。
The design of an ASA will often require the design of a new GRASP objective. The general rules for the format of GRASP objectives, their names, and IANA registration are given in [RFC8990]. Additionally, that document discusses various general considerations for the design of objectives, which are not repeated here. However, note that GRASP, like HTTP, does not provide transactional integrity. In particular, steps in a GRASP negotiation are not idempotent. The design of a GRASP objective and the logic flow of the ASA should take this into account. One approach, which should be used when possible, is to design objectives with idempotent semantics. If this is not possible, typically if an ASA is allocating part of a shared resource to other ASAs, it needs to ensure that the same part of the resource is not allocated twice. The easiest way is to run only one negotiation at a time. If an ASA is capable of overlapping several negotiations, it must avoid interference between these negotiations.
ASAの設計はしばしば新しい把握目的の設計を必要とします。 [RFC8990]には、GRASP目標、その名前、およびIANA登録のフォーマットの一般的な規則があります。さらに、その文書は目的の設計に関するさまざまな一般的な考慮事項について説明しています。ただし、HTTPのようなGRASPはトランザクションの整合性を提供しません。特に、把握交渉におけるステップはIDEmpotentではありません。 ASAの把握目的と論理フローの設計はこれを考慮に入れるべきです。可能であれば使用する必要がある1つのアプローチは、IDEmpotent Semanticsを持つ目的を設計することです。これが不可能な場合は、通常、ASAが共有リソースの一部を他のASAに割り当てる場合は、リソースの同じ部分が2回割り当てられていないことを確認する必要があります。最も簡単な方法は一度に1つのネゴシエーションのみを実行することです。 ASAがいくつかの交渉を重ね合わせることができる場合、それはこれらの交渉の間の干渉を避ける必要があります。
Negotiations will always end, normally because one end or the other declares success or failure. If this does not happen, either a timeout or exhaustion of the loop count will occur. The definition of a GRASP objective should describe a specific negotiation policy if it is not self-evident.
常に交渉は常に終了します。通常、一方の終了または他方は成功または失敗を宣言しています。これが起こらない場合は、ループ数のタイムアウトまたは枯渇のいずれかが発生します。GRASP目標の定義は、自明ではない場合は、特定のネゴシエーションポリシーを説明する必要があります。
GRASP allows a "dry run" mode of negotiation, where a negotiation session follows its normal course but is not committed at either end until a subsequent live negotiation session. If dry run mode is defined for the objective, its specification, and every implementation, must consider what state needs to be saved following a dry run negotiation, such that a subsequent live negotiation can be expected to succeed. It must be clear how long this state is kept and what happens if the live negotiation occurs after this state is deleted. An ASA that requests a dry run negotiation must take account of the possibility that a successful dry run is followed by a failed live negotiation. Because of these complexities, the dry run mechanism should only be supported by objectives and ASAs where there is a significant benefit from it.
Graspは、ネゴシエーションセッションがその通常のコースに従いますが、その後のライブネゴシエーションセッションまでのどちらの端でコミットされていません。DRY RUNモードが目的、その仕様、およびすべての実装に定義されている場合は、その後のライブネゴシエーションが成功すると予想されるように、乾いたラン交渉に従ってどのような状態を保存する必要があるかを考慮する必要があります。この状態がどのくらい維持されているか、この状態が削除された後に生活交渉が発生したらどうなるかを明確にする必要があります。乾いたラン交渉を要求するASAは、成功したドライランの後に失敗したライブネゴシエーションが続く可能性を考慮に入れなければなりません。これらの複雑さのために、ドライランメカニズムはそれから重要な利益がある目的やASAによってのみ支持されるべきです。
The actual value field of an objective is limited by the GRASP protocol definition to any data structure that can be expressed in Concise Binary Object Representation (CBOR) [RFC8949]. For some objectives, a single data item will suffice, for example, an integer, a floating point number, a UTF-8 string, or an arbitrary byte string. For more complex cases, a simple tuple structure such as [item1, item2, item3] could be used. Since CBOR is closely linked to JSON, it is also rather easy to define an objective whose value is a JSON structure. The formats acceptable by the GRASP API will limit the options in practice. A generic solution is for the API to accept and deliver the value field in raw CBOR, with the ASA itself encoding and decoding it via a CBOR library (Section 2.3.2.4 of [RFC8991]).
目標の実際の値フィールドは、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]で表現できる任意のデータ構造に把握プロトコル定義によって制限されています。いくつかの目的では、単一のデータ項目は、例えば、整数、浮動小数点数、UTF - 8文字列、または任意のバイト文字列で十分であろう。より複雑な場合については、[ITEM1、ITM2、ITEM3]などの簡単なタプル構造を使用することができます。CBORはJSONに密接に関連しているので、その値がJSON構造である目的を定義するのもかなり簡単です。GRASP APIによって許容されるフォーマットは、実際にはオプションを制限します。一般的な解決策は、APIがRaw CBORの値フィールドを受け入れて配信するためのものです.ASA自身がCBORライブラリを介して符号化して復号する（[RFC8991]のセクション2.3.2.4）。
The maximum size of the value field of an objective is limited by the GRASP maximum message size. If the default maximum size specified as GRASP_DEF_MAX_SIZE by [RFC8990] is not enough, the specification of the objective must indicate the required maximum message size for both unicast and multicast messages.
目的の値フィールドの最大サイズは、最大メッセージサイズの把握によって制限されます。[RFC8990]によってGRASP_DEF_MAX_SIZEとして指定されたデフォルトの最大サイズが十分でない場合、目的の指定はユニキャストメッセージとマルチキャストメッセージの両方に必要な最大メッセージサイズを示している必要があります。
A mapping from YANG to CBOR is defined by [CBOR-YANG]. Subject to the size limit defined for GRASP messages, nothing prevents objectives transporting YANG in this way.
Yangから居酒屋へのマッピングは[CBOR-YANG]によって定義されています。把握メッセージに定義されたサイズ制限の対象となる、このようにヤンを転送する目的を妨げるものはありません。
The flexibility of CBOR implies that the value field of many objectives can be extended in service, to add additional information or alternative content, especially if JSON-like structures are used. This has consequences for the robustness of ASAs, as discussed in Section 9.
CBORの柔軟性は、特にJSON様構造が使用されている場合に、多くの目的の値フィールドをサービス内で拡張できることを意味します。セクション9で説明したように、これはASAの堅牢性に影響を与えます。
The ASA life cycle is discussed in [AUTONOMIC-FUNCTION], from which the following text was derived. It does not cover all details, and some of the terms used would require precise definitions in a given implementation.
ASAライフサイクルについては[自律型機能]で説明しています。これから次のテキストが導き出されました。それはすべての詳細をカバーしていません、そして使用される用語のいくつかは与えられた実装で正確な定義を必要とするでしょう。
In simple cases, autonomic functions could be permanent, in the sense that ASAs are shipped as part of a product and persist throughout the product's life. However, in complex cases, a more likely situation is that ASAs need to be installed or updated dynamically because of new requirements or bugs. This section describes one approach to the resulting life cycle of individual ASAs. It does not consider wider issues such as updates of shared libraries.
単純な場合では、自律神経機能は恒久的なものであり、ASAが製品の一部として出荷され、製品の寿命を通して持続しているという意味で恒久的なものである可能性があります。ただし、複雑なケースでは、新しい要件やバグのためにASAを動的にインストールまたは更新する必要があるという状況が軽減されます。このセクションでは、個々のASAの結果として生じるライフサイクルへの1つのアプローチについて説明します。共有ライブラリのアップデートなどのより広い問題を考慮していません。
Because continuity of service is fundamental to autonomic networking, the process of seamlessly replacing a running instance of an ASA with a new version needs to be part of the ASA's design. The implication of service continuity on the design of ASAs can be illustrated along the three main phases of the ASA life cycle, namely installation, instantiation, and operation.
サービスの継続性は自律技術ネットワーキングの基本であるため、ASAの実行中のインスタンスを新しいバージョンでシームレスに置き換えるプロセスは、ASAのデザインの一部である必要があります。ASAの設計上のサービス継続性の影響は、ASAライフサイクルの3つの主段階、すなわち設置、インスタンス化、および操作に沿って示されています。
+--------------+
Undeployed ------>| |------> Undeployed
| Installed |
+-->| |---+
Mandate | +--------------+ | Receives a
is revoked | +--------------+ | Mandate
+---| |<--+
| Instantiated |
+-->| |---+
set | +--------------+ | set
down | +--------------+ | up
+---| |<--+
| Operational |
| |
+--------------+
Figure 1: Life Cycle of an Autonomic Service Agent
図1：自律型サービスエージェントのライフサイクル
We define "installation" to mean that a piece of software is loaded into a device, along with any necessary libraries, but is not yet activated.
私たちは、必要なライブラリとともに、一部のソフトウェアがデバイスにロードされることを意味するための「インストール」を定義しますが、まだ有効になっていません。
Before being able to instantiate and run ASAs, the operator will first provision the infrastructure with the sets of ASA software corresponding to its needs and objectives. Such software must be checked for integrity and authenticity before installation. The provisioning of the infrastructure is realized in the installation phase and consists of installing (or checking the availability of) the pieces of software of the different ASAs in a set of Installation Hosts within the autonomic network.
ASAをインスタンス化して実行することができる前に、オペレータは最初にインフラストラクチャをそのニーズと目的に対応するASAソフトウェアのセットとプロビジョニングされます。そのようなソフトウェアは、インストール前に完全性と信頼性をチェックする必要があります。インフラストラクチャのプロビジョニングは、インストールフェーズで実現され、オートノミックネットワーク内のインストールホストのセット内の異なるASAのソフトウェアのインストール（または可用性を確認する）からなることからなります。
There are three properties applicable to the installation of ASAs:
ASASのインストールには3つのプロパティがあります。
* The dynamic installation property allows installing an ASA on demand, on any hosts compatible with the ASA.
* 動的インストールプロパティでは、ASAと互換性のあるホストで、ASA On Demandをインストールできます。
* The decoupling property allows an ASA on one machine to control resources in another machine (known as "decoupled mode").
* デカップリングプロパティでは、1台のマシン上のASAが別のマシン内のリソースを制御できます（「デカップリングモード」として知られています）。
* The multiplicity property allows controlling multiple sets of resources from a single ASA.
* 多重度プロパティは、単一のASAから複数のリソースセットを制御できます。
These three properties are very important in the context of the installation phase as their variations condition how the ASA could be installed on the infrastructure.
これら3つのプロパティは、インストールフェーズのコンテキストでは、ASAがインフラストラクチャにどのようにインストールできるのかという変動条件として非常に重要です。
Inputs are:
入力は次のとおりです。
* [ASA_type]: specifies which ASA to install.
* [ASA_TYPE]：インストールするASAを指定します。
* [Installation_target_infrastructure]: specifies the candidate installation Hosts.
* [installation_target_infrastructure]：候補インストールホストを指定します。
* [ASA_placement_function]: specifies how the installation phase will meet the operator's needs and objectives for the provision of the infrastructure. This function is only useful in the decoupled mode. It can be as simple as an explicit list of hosts on which the ASAs are to be installed, or it could consist of operator-defined criteria and constraints.
* [asa_placement_function]：インストールフェーズがインフラストラクチャを提供するためのオペレータのニーズと目的をどのように満たすかを指定します。この関数はデカップリングモードでのみ役立ちます。ASASがインストールされるホストの明示的なリストと同じくらい簡単であるか、オペレータ定義の基準と制約からなることもできます。
The main output of the installation phase is a [List_of_ASAs] installed on [List_of_hosts]. This output is also useful for the coordination function where it acts as a static interaction map (see Section 8.1).
インストールフェーズのメイン出力は[LIST_OF_HOSTS]にインストールされている[LIST_OF_ASAS]です。この出力は、静的インタラクションマップとして機能する調整機能にも役立ちます（セクション8.1参照）。
The condition to validate in order to pass to next phase is to ensure that [List_of_ASAs] are correctly installed on [List_of_hosts]. A minimum set of primitives to support the installation of ASAs could be the following: install (List_of_ASAs, Installation_target_infrastructure, ASA_placement_function) and uninstall (List_of_ASAs).
次のフェーズに渡すために検証する条件は、[LIST_OF_ASAS]が[LIST_OF_HOSTS]に正しくインストールされていることを確認することです。ASASのインストールをサポートする最小限のプリミティブセットは、次のものになる可能性があります。インストール（list_of_asas、installation_target_infrasture、asa_plaction_function）とアンインストール（list_of_asas）です。
We define "instantiation" as the operation of creating a single ASA instance from the corresponding piece of installed software.
対応するインストールされているソフトウェアから単一のASAインスタンスを作成する操作として「インスタンス化」を定義します。
Once the ASAs are installed on the appropriate hosts in the network, these ASAs may start to operate. From the operator viewpoint, an operating ASA means the ASA manages the network resources as per the objectives given. At the ASA local level, operating means executing their control loop algorithm.
ASASがネットワーク内の適切なホストにインストールされると、これらのASAは動作を開始することがあります。オペレータビューポイントから、ASAが指定された目的者に従って、ネットワークリソースを管理することを意味します。ASAローカルレベルで、オペレーティング手段は制御ループアルゴリズムを実行します。
There are two aspects to take into consideration. First, having a piece of code installed and available to run on a host is not the same as having an agent based on this piece of code running inside the host. Second, in a coupled case, determining which resources are controlled by an ASA is straightforward (the ASA runs on the same autonomic node as the resources it is controlling). In a decoupled mode, determining this is a bit more complex: a starting agent will have to either discover the set of resources it ought to control, or such information has to be communicated to the ASA.
考慮に入れるべき2つの側面があります。まず、一枚のコードをインストールしてホスト上で実行できるようにすることは、ホスト内で実行されているこのコードに基づいてエージェントを持つものと同じではありません。第二に、結合されたケースでは、どのリソースがASAによって制御されているかを判断することが簡単です（ASAは、それが制御されているリソースと同じ自律ノード上で実行されます）。デカップリングモードでは、これを決定することはもう少し複雑です。起動エージェントは、制御するべきか、またはそのような情報をASAに伝達されなければなりません。
The instantiation phase of an ASA covers both these aspects: starting the agent code (when this does not start automatically) and determining which resources have to be controlled (when this is not straightforward).
ASAのインスタンス化フェーズは、これらの側面をカバーします。
Through this phase, the operator wants to control its autonomic network regarding at least two aspects:
このフェーズを通して、オペレータは少なくとも2つの側面に関する自律神経ネットワークを制御したいと考えています。
1. determine the scope of autonomic functions by instructing which network resources have to be managed by which autonomic function (and more precisely by which release of the ASA software code, e.g., version number or provider).
1. どのネットワークリソースを管理しなければならないネットワークリソースを管理する必要があるかを、どのネットワークリソース（より正確にはASAソフトウェアコード、例えば、バージョン番号またはプロバイダのリリース）を指示します。
2. determine how the autonomic functions are organized by instantiating a set of ASAs across one or more autonomic nodes and instructing them accordingly about the other ASAs in the set as necessary.
2. 必要に応じて、1つまたは複数の自律型ノードにわたってASAのセットをインスタンス化し、それに応じて他のASAについて指示することによって、自律詞関数がどのように構成されているかを決定します。
In this phase, the operator may also want to set goals for autonomic functions, e.g., by configuring GRASP objectives.
この段階では、オペレータは、把握目的を構成することによって、自律神経機能の目標を設定することもできます。
The operator's goal can be summarized in an instruction to the autonomic ecosystem matching the following format, explained in detail in the next sub-section:
オペレータの目標は、次のサブセクションで詳しく説明されている、次の形式と一致するオートノミックエコシステムへの指示にまとめることができます。
[Instances_of_ASA_type] ready to control
[Instantiation_target_infrastructure] with
[Instantiation_target_parameters]
Inputs are:
入力は次のとおりです。
* [Instances_of_ASA_type]: specifies which ASAs to instantiate
* [Instances_of_asa_type]：インスタンス化するASAを指定します
* [Instantiation_target_infrastructure]: specifies which resources are to be managed by the autonomic function; this can be the whole network or a subset of it like a domain, a physical segment, or even a specific list of resources.
* [instantiation_target_infrastructure]：自律関数によって管理されるリソースを指定します。これは、ネットワーク全体、またはドメイン、物理セグメント、または特定のリソースのリストなどのそれのサブセットです。
* [Instantiation_target_parameters]: specifies which GRASP objectives are to be sent to ASAs (e.g., an optimization target)
* [Instantiation_target_parameters]：どのGRASP目標をASAS（例えば最適化対象）に送信するかを指定します。
Outputs are:
出力は次のとおりです。
* [Set_of_ASA_resources_relations]: describes which resources are managed by which ASA instances; this is not a formal message but a resulting configuration log for a set of ASAs.
* [set_of_asa_resources_relations]：どのリソースが管理されているか、どのASAインスタンスが管理されています。これは正式なメッセージではありませんが、結果としてのASASの設定ログです。
The instructions described in Section 7.2 could be either of the following:
セクション7.2に記載されている手順は、次のいずれかです。
* Sent to a targeted ASA. In this case, the receiving Agent will have to manage the specified list of [Instantiation_target_infrastructure], with the [Instantiation_target_parameters].
* ターゲットのASAに送信されました。この場合、受信側エージェントは[Instantiation_Target_Parameters]を指定して、指定された[Instantiation_Target_Infrastructure]のリストを管理する必要があります。
* Broadcast to all ASAs. In this case, the ASAs would determine from the list which ASAs would handle which [Instantiation_target_infrastructure], with the [Instantiation_target_parameters].
* すべてのASAに放送する。この場合、ASASは、[Instantiation_Target_Parameters]を使用して、どのASASがどの[Instantiation_target_infrastructure]を処理するリストから決定します。
These instructions may be grouped as a specific data structure referred to as an ASA Instance Mandate. The specification of such an ASA Instance Mandate is beyond the scope of this document.
これらの命令は、ASAインスタンス義務と呼ばれる特定のデータ構造としてグループ化されてもよい。そのようなASAインスタンスの義務の指定はこの文書の範囲を超えています。
The conclusion of this instantiation phase is a set of ASA instances ready to operate. These ASA instances are characterized by the resources they manage, the metrics being monitored, and the actions that can be executed (like modifying certain parameter values). The description of the ASA instance may be defined in an ASA Instance Manifest data structure. The specification of such an ASA Instance Manifest is beyond the scope of this document.
このインスタンス化フェーズの結論は、動作する準備ができているASAインスタンスのセットです。これらのASAインスタンスは、管理されているリソース、監視されているメトリック、および実行できるアクションによって特徴付けられます（特定のパラメータ値を変更する）。ASAインスタンスの説明は、ASAインスタンスマニフェストデータ構造で定義できます。そのようなASAインスタンスマニフェストの仕様はこの文書の範囲を超えています。
The ASA Instance Manifest does not only serve informational purposes such as acknowledgement of successful instantiation to the operator but is also necessary for further autonomic operations with:
ASAインスタンスマニフェストは、演算子へのインスタンス化が成功したことの確認応答などの情報提供を提供するだけでなく、次のようなさらなるオートノミック操作にも必要です。
* coordinated entities (see Section 8.1)
* 協調エンティティ（セクション8.1を参照）
* collaborative entities with purposes such as to establish knowledge exchange (some ASAs may produce knowledge or monitor metrics that would be useful for other ASAs)
* 知識交換を確立するなどの目的を持つ共同エンティティ（ASASの中には、他のASAにとって有用な知識または監視測定基準を生成することがあります）
During the operation phase, the operator can:
操作段階では、オペレータは次のことができます。
* activate/deactivate ASAs: enable/disable their autonomic loops
* ASASの有効化/無効化：自律ループを有効/無効にする
* modify ASA targets: set different technical objectives
* ASAターゲットを変更する：さまざまな技術的な目的を設定します
* modify ASAs managed resources: update the Instance Mandate to specify a different set of resources to manage (only applicable to decoupled ASAs)
* ASAS管理対象リソースを変更する：インスタンスの必須を更新して管理するために異なるリソースセットを指定します（ASASを切り離すために該当する）
During the operation phase, running ASAs can interact with other ASAs:
操作段階では、ASAを実行していると、他のASAと対話できます。
* in order to exchange knowledge (e.g., an ASA providing traffic predictions to a load balancing ASA)
* 知識を交換するために（例えば、荷重バランスを取得したASAへの交通予測を提供するASA）
* in order to collaboratively reach an objective (e.g., ASAs pertaining to the same autonomic function will collaborate, e.g., in the case of a load balancing function, by modifying link metrics according to neighboring resource loads)
* 対物レンズに協力的に到達するために（例えば、同じ自律型関数に関するASASは、隣接リソース負荷に従ってリンクメトリックを変更することによって、例えば負荷分散関数の場合には共同作業する。
During the operation phase, running ASAs are expected to apply coordination schemes as per Section 8.1.
運用段階では、ASAを実行しているASASはセクション8.1に従って調整スキームを適用すると予想されます。
When an ASA is removed from service and uninstalled, the above steps are reversed. It is important that its data, especially any security key material, is purged.
ASAをサービスから取り外してアンインストールすると、上記のステップが逆になります。そのデータ、特にすべてのセキュリティキーマテリアルがパージされることが重要です。
Some autonomic functions will be completely independent of each other. However, others are at risk of interfering with each other; for example, two different optimization functions might both attempt to modify the same underlying parameter in different ways. In a complete system, a method is needed for identifying ASAs that might interfere with each other and coordinating their actions when necessary.
いくつかの自律神経機能は互いに完全に独立しているでしょう。しかし、他のものは互いに干渉する危険性があります。たとえば、2つの異なる最適化関数が、異なる方法で同じ基礎となるパラメータを変更しようとしています。完全なシステムでは、互いに干渉し、必要に応じて自分の行動を調整することができるASASを識別するための方法が必要です。
Some ASAs will have functions that overlap with existing configuration tools and network management mechanisms such as command-line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF. This is, of course, an existing problem whenever multiple configuration tools are in use by the NOC. Each ASA designer will need to consider this issue and how to avoid clashes and inconsistencies in various deployment scenarios. Some specific considerations for interaction with OAM tools are given in [RFC8368]. As another example, [RFC8992] describes how autonomic management of IPv6 prefixes can interact with prefix delegation via DHCPv6. The description of a GRASP objective and of an ASA using it should include a discussion of any such interactions.
一部のASASは、コマンドラインインターフェイス、DHCP、DHCPv6、SNMP、NETCONF、およびRESTCONFなどの既存の設定ツールとネットワーク管理メカニズムと重複する機能を持ちます。これは、もちろん、複数の構成ツールがNOCによって使用されているときはいつでも既存の問題です。各ASAデザイナーは、この問題を検討する必要があり、さまざまな展開シナリオの衝突や矛盾を回避する必要があります。OAMツールとの相互作用に関するいくつかの具体的な考慮事項は[RFC8368]に示されています。別の例として、[RFC8992]は、IPv6プレフィックスの自律管理管理がDHCPv6を介してプレフィックスの委任と対話する方法を説明しています。把握目的とそれを使用したASAの説明は、そのような相互作用の議論を含むべきです。
Management functions often include a shared data model, quite likely to be expressed in a formal notation such as YANG. This aspect should not be an afterthought in the design of an ASA. To the contrary, the design of the ASA and of its GRASP objectives should match the data model; as noted in Section 6, YANG serialized as CBOR may be used directly as the value of a GRASP objective.
管理機能には共有データモデルが含まれていることがよくあり、ヤンなどの正式な表記で表現される可能性が非常に高いです。この側面はASAの設計における後期であるべきではありません。それどころか、ASAとその把握目的の設計はデータモデルと一致する必要があります。セクション6に記載されているように、CBORとしてシリアライズされたYangは、把握対象の値として直接使用されてもよい。
It is of great importance that all components of an autonomic system are highly robust. Although ASA designers should aim for their component to never fail, it is more important to design the ASA to assume that failures will happen and to gracefully recover from those failures when they occur. Hence, this section lists various aspects of robustness that ASA designers should consider:
自律神経システムのすべての構成要素が非常に堅牢であることが非常に重要です。ASAデザイナーが自分のコンポーネントが失敗することを目指しているべきですが、失敗が発生し、発生時にそれらの失敗から正常に回復すると仮定するようにASAを設計することがより重要です。したがって、このセクションでは、ASAデザイナーが考慮すべき堅牢性のさまざまな側面を示します。
1. If despite all precautions, an ASA does encounter a fatal error, it should in any case restart automatically and try again. To mitigate a loop in case of persistent failure, a suitable pause should be inserted before such a restart. The length of the pause depends on the use case; randomization and exponential backoff should be considered.
1. すべての予防措置にもかかわらず、ASAが致命的なエラーに発生しているため、どの場合は自動的に再起動してやり直してください。永続的な失敗の場合にループを軽減するために、そのような再起動の前に適切な一時停止を挿入する必要があります。一時停止の長さはユースケースによって異なります。ランダム化と指数バックオフを考慮する必要があります。
2. If a newly received or calculated value for a parameter falls out of bounds, the corresponding parameter should be either left unchanged or restored to a value known to be safe in all configurations.
2. パラメータの新たに受信された値または計算値が範囲外になると、対応するパラメータは変更されず、すべての構成で安全であることが知られている値に復元されるべきです。
3. If a GRASP synchronization or negotiation session fails for any reason, it may be repeated after a suitable pause. The length of the pause depends on the use case; randomization and exponential backoff should be considered.
3. 把握同期またはネゴシエーションセッションが何らかの理由で失敗した場合は、適切な一時停止後に繰り返すことができます。一時停止の長さはユースケースによって異なります。ランダム化と指数バックオフを考慮する必要があります。
4. If a session fails repeatedly, the ASA should consider that its peer has failed, and it should cause GRASP to flush its discovery cache and repeat peer discovery.
4. セッションが繰り返し失敗した場合、ASAはそのピアが失敗したと考える必要があり、その検出キャッシュをフラッシュしてピア検出を繰り返すことを把握する必要があります。
5. In any case, it may be prudent to repeat discovery periodically, depending on the use case.
5. いずれにせよ、ユースケースに応じて、定期的に発見を繰り返すことは慎重になるかもしれません。
6. Any received GRASP message should be checked. If it is wrongly formatted, it should be ignored. Within a unicast session, an Invalid message (M_INVALID) may be sent. This function may be provided by the GRASP implementation itself.
6. 受信した把握メッセージを確認する必要があります。誤ってフォーマットされている場合は、無視する必要があります。ユニキャストセッション内では、無効なメッセージ（M_INVALID）が送信されることがあります。この機能は、把握実装自体によって提供されてもよい。
7. Any received GRASP objective should be checked. Basic formatting errors like invalid CBOR will likely be detected by GRASP itself, but the ASA is responsible for checking the precise syntax and semantics of a received objective. If it is wrongly formatted, it should be ignored. Within a negotiation session, a Negotiation End message (M_END) with a Decline option (O_DECLINE) should be sent. An ASA may log such events for diagnostic purposes.
7. 受信された把握目的をチェックする必要があります。無効なCBORのような基本的なフォーマットエラーは、把握自体によって検出される可能性がありますが、ASAは受信された目的の正確な構文と意味をチェックする責任があります。誤ってフォーマットされている場合は、無視する必要があります。交渉セッション内では、辞退オプション（O_Decline）を備えたネゴシエーション終了メッセージ（M_END）を送信する必要があります。ASAは診断目的のためにそのようなイベントを記録することができます。
8. On the other hand, the definitions of GRASP objectives are very likely to be extended, using the flexibility of CBOR or JSON. Therefore, ASAs should be able to deal gracefully with unknown components within the values of objectives. The specification of an objective should describe how unknown components are to be handled (ignored, logged and ignored, or rejected as an error).
8. 一方、CBORまたはJSONの柔軟性を使用して、GRASP目標の定義は延長される可能性が非常に高いです。したがって、ASAは目的の値内で不明なコンポーネントを適切に対処できるはずです。目的の指定は、未知のコンポーネントを処理する方法を説明する必要があります（無視され、ログに記録され、無視されるか、エラーとして拒否されます）。
9. If an ASA receives either an Invalid message (M_INVALID) or a Negotiation End message (M_END) with a Decline option (O_DECLINE), one possible reason is that the peer ASA does not support a new feature of either GRASP or the objective in question. In such a case, the ASA may choose to repeat the operation concerned without using that new feature.
9. ASAが辞退オプション（O_DECLINE）を持つ無効なメッセージ（M_INVALID）またはネゴシエーション終了メッセージ（M_END）を受信した場合、ピアASAが問題の把握または目的の新しい機能をサポートしていないことの1つです。そのような場合、ASAはその新機能を使用せずに関係する操作を繰り返すことを選択できます。
10. All other possible exceptions should be handled in an orderly way. There should be no such thing as an unhandled exception (but see point 1 above).
10. 他のすべての例外は整然とした方法で処理されるべきです。未処理の例外のようなものはありません（上記の点1を参照）。
At a slightly more general level, ASAs are not services in themselves, but they automate services. This has a fundamental impact on how to design robust ASAs. In general, when an ASA observes a particular state (1) of operations of the services/ resources it controls, it typically aims to improve this state to a better state, say (2). Ideally, the ASA is built so that it can ensure that any error encountered can still lead to returning to (1) instead of a state (3), which is worse than (1). One example instance of this principle is "make-before-break" used in reconfiguration of routing protocols in manual operations. This principle of operations can accordingly be coded into the operation of an ASA. The GRASP dry run option mentioned in Section 6 is another tool helpful for this ASA design goal of "test-before-make".
もう少し一般的なレベルでは、ASASは自分自身のサービスではありませんが、サービスを自動化します。これは、堅牢なASAの設計方法に基本的な影響を与えます。一般に、ASAがそれが制御するサービス/リソースの動作の特定の状態（1）を観察すると、通常、この状態をより良い状態に向上させることを目的としている（2）。理想的には、ASAは、（1）よりも悪い状態（3）ではなく、遭遇したエラーが発生しようとする可能性があることを確実にすることができるように構築されています。この原則の一例の例は、手動操作でのルーティングプロトコルの再構成に使用される「前断頭」です。その結果、この動作原理はASAの動作に符号化することができる。セクション6に記載されているDry Runオプションの把握は、「テスト前メーク」のこのASA設計目標に役立つもう1つのツールです。
ASAs are intended to run in an environment that is protected by the Autonomic Control Plane [RFC8994], admission to which depends on an initial secure bootstrap process such as BRSKI [RFC8995]. Those documents describe security considerations relating to the use of and properties provided by the ACP and BRSKI, respectively. Such an ACP can provide keying material for mutual authentication between ASAs as well as confidential communication channels for messages between ASAs. In some deployments, a secure partition of the link layer might be used instead. GRASP itself has significant security considerations [RFC8990]. However, this does not relieve ASAs of responsibility for security. When ASAs configure or manage network elements outside the ACP, potentially in a different physical node, they must interact with other non-autonomic software components to perform their management functions. The details are specific to each case, but this has an important security implication. An ASA might act as a loophole by which the managed entity could penetrate the security boundary of the ANI. Thus, ASAs must be designed to avoid loopholes such as passing on executable code or proxying unverified commands and should, if possible, operate in an unprivileged mode. In particular, they must use secure coding practices, e.g., carefully validate all incoming information and avoid unnecessary elevation of privilege. This will apply in particular when an ASA interacts with a management component such as a NETCONF server.
ASASは、自律型制御プレーン[RFC8994]によって保護されている環境で実行されることを意図しています。これらの文書は、ACPとBRSKIの使用とプロパティに関するセキュリティ上の考慮事項を説明しています。そのようなACPは、ASAS間の機密通信チャネルと、ASA間の機密通信チャネルとの間の相互認証のためのキー化材料を提供することができる。展開によっては、代わりにリンクレイヤのセキュアパーティションが使用される可能性があります。把握自体には著しいセキュリティ上の考慮事項があります[RFC8990]。ただし、これはセキュリティに対する責任のASASを軽減しません。 ASASがACPの外部のネットワーク要素を構成または管理する場合は、異なる物理ノードに潜在的に、他の非自律型ソフトウェアコンポーネントと対話して管理機能を実行する必要があります。詳細はそれぞれの場合に固有のものですが、これには重要なセキュリティの意味があります。 ASAは、管理対象事業体がANIのセキュリティ境界を侵入する可能性がある抜け穴として機能する可能性があります。したがって、ASAは、実行可能コードまたは不明確なコマンドをプロキシするなどの抜け穴を回避するように設計されている必要があります。可能であれば、特権モードで動作します。特に、それらは安全なコーディング慣行、例えば、すべての着信情報を慎重に検証し、特権の不必要な標高を避ける必要があります。これは、特にASAがNetConfサーバーなどの管理コンポーネントと対話するときに適用されます。
A similar situation will arise if an ASA acts as a gateway between two separate autonomic networks, i.e., it has access to two separate ACPs. Such an ASA must also be designed to avoid loopholes and to validate incoming information from both sides.
ASAが2つの別々の自律神経ネットワーク間のゲートウェイとして機能する場合、同様の状況が生じ、すなわち2つの別々のACPへのアクセスがある。そのようなASAは、抜け穴を避け、両側から入ってくる情報を検証するように設計されている必要があります。
As a reminder, GRASP does not intrinsically provide transactional integrity (Section 6).
リマインダーとして、GRASSは本質的にトランザクションの整合性を提供しません（セクション6）。
As appropriate to their specific functions, ASAs should take account of relevant privacy considerations [RFC6973].
特定の機能に応じて、ASASは関連するプライバシーに関する考慮事項[RFC6973]を考慮に入れるべきです。
The initial version of the autonomic infrastructure assumes that all autonomic nodes are trusted by virtue of their admission to the ACP. ASAs are therefore trusted to manipulate any GRASP objective simply because they are installed on a node that has successfully joined the ACP. In the general case, a node may have multiple roles, and a role may use multiple ASAs, each using multiple GRASP objectives. Additional mechanisms for the fine-grained authorization of nodes and ASAs to manipulate specific GRASP objectives could be designed. Meanwhile, we repeat that ASAs should run without special privilege if possible. Independently of this, interfaces between ASAs and the router configuration and monitoring services of the node can be subject to authentication that provides more fine-grained authorization for specific services. These additional authentication parameters could be passed to an ASA during its instantiation phase.
自律型インフラストラクチャの初期バージョンは、ACPへの入場によってすべての自律ノードが信頼されていると想定しています。したがって、ASASは、ACPに正常に結合されたノードにインストールされているため、把握目的を操作すると信頼されています。一般的な場合では、ノードは複数の役割を持つことができ、ロールは複数のASAを使用して、それぞれ複数の把握目的を使用しています。特定の把握目的を操作するためのノードとASAの微細な承認のための追加のメカニズムを設計することができます。一方、可能であれば、ASASが特別な特権なしで実行されるべきであることを繰り返します。これとは無関係に、ASAとノードのルータ構成と監視サービスとの間のインタフェースは、特定のサービスに対してよりきめ細かい認証を提供する認証の対象となる可能性があります。これらの追加の認証パラメータは、そのインスタンス化フェーズ中にASAに渡すことができます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[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. LIU、ED。、「GENEIC自律型シグナリングプロトコル（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、「Autolonic Control Plane（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>。
[AUTONOMIC-FUNCTION] Pierre, P. and L. Ciavaglia, "A Day in the Life of an Autonomic Function", Work in Progress, Internet-Draft, draft-peloso-anima-autonomic-function-01, 21 March 2016, <https://datatracker.ietf.org/doc/html/draft-peloso-anima-autonomic-function-01>.
[自律型機能] Pierre、P.およびL. Ciavaglia、「自律神経機能の生活の中の一日」、進行中の作業、インターネットドラフト、ドラフト - ペロソアニマ - オートノミック機能-01,2016、<https://datatracker.ietf.org/doc/html/draft-peloso-anima-autonom-function-01>。
[CBOR-YANG] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, "CBOR Encoding of Data Modeled with YANG", Work in Progress, Internet-Draft, draft-ietf-core-yang-cbor-18, December 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-18>.
[CBOR-YANG] Veillette、M.、ED。、Petrov、I。、ED。、Pelov、A.、Bormann、C.、およびM.リチャードソン、「ヤンでモデル化したデータのCBORエンコーディング」、進行中の仕事インターネットドラフト、ドラフト - IETF-CORE-YANG-CBOBOR-18、2021年12月、<https：//datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-18>。
[DEMOLA06] De Mola, F. and R. Quitadamo, "Towards an Agent Model for Future Autonomic Communications", Proceedings of the 7th WOA 2006 Workshop From Objects to Agents 51-59, September 2006.
[Demola06] De Mola、F.およびR.Quitadamo、「将来の自律神経コミュニケーションのためのエージェントモデルに向けて」、2006年9月、オブジェクトからエージェントへの第7回WOA 2006ワークショップの議事録。
[GANA13] ETSI, "Autonomic network engineering for the self-managing Future Internet (AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management)", GS AFI 002, V1.1.1, April 2013, <https://www.etsi.org/deliver/etsi_gs/ AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.
[GANA13] ETSI、「自主管理将来インターネット（AFI）のための自律型ネットワークエンジニアリング;一般的な自律技術的ネットワークアーキテクチャ（自律網、認知ネットワーク、自己管理のための建築参照モデル）、GS AFI 002、V1.1.1、2013年4月、<https://www.etsi.org/deliver/etsi_gs/ AFI / 001_099 / 002 / 01.01.01_60 / GS_AFI002V010101P.PDF>。
[HUEBSCHER08] Huebscher, M. C. and J. A. McCann, "A survey of autonomic computing - degrees, models, and applications", ACM Computing Surveys (CSUR), Volume 40, Issue 3, DOI 10.1145/1380584.1380585, August 2008, <https://doi.org/10.1145/1380584.1380585>.
[huebscher08] Huebscher、MC、JA McCann、「自律計算度、モデル、およびアプリケーションの調査」、ACMコンピューティング調査（CSUR）、第40号、号3、DOI 10.1145 / 1380584.1380585、<https：//doi.org/10.1145/1380584.1380585>。
[IBN-CONCEPTS] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", Work in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-09, 24 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09>.
[IBN-Concepts] CLEMM、A。、CIAVAGLIA、L.、GRANVILLE、LZ、J.Tantsura、「インテントベースのネットワーキング - コンセプトと定義」、進行中の作業、インターネットドラフト、ドラフトIRTF-NMRG-IBN-concepts-definitions-09,2022、<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09>。
[IPJ] Behringer, M., Bormann, C., Carpenter, B. E., Eckert, T., Campos Nobre, J., Jiang, S., Li, Y., and M. C. Richardson, "Autonomic Networking Gets Serious", The Internet Protocol Journal, Volume 24, Issue 3, Page(s) 2 - 18, ISSN 1944-1134, October 2021, <https://ipj.dreamhosters.com/wp-content/uploads/2021/10/243-ipj.pdf>.
[IPJ] BEHRINGER、M.、Bormann、C.、Carpenter、Be、Eckert、T.、Campos Nobre、J.、J.、S.、Li、Y.、Mc Richardson、Mc Richardson、 "Autonomic Networkingが深刻化する"、インターネットプロトコルジャーナル、第24巻、第3巻、2 - 18、ISSN 1944-1134、2021年10月、<https：//ipj.dreamhosters.com/wp-content/uploads/2021/10/243-IPJ.pdf>。
[MOVAHEDI12] Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A Survey of Autonomic Network Architectures and Evaluation Criteria", IEEE Communications Surveys & Tutorials, Volume 14, Issue 2, Pages 464 - 490, DOI 10.1109/SURV.2011.042711.00078, 2012, <https://doi.org/10.1109/SURV.2011.042711.00078>.
[Movahedi12] Movahedi、Z.、Ayari、M.、Langar、R.、およびG. Pujolle、「自律型ネットワークアーキテクチャと評価基準の調査」、IEEEコミュニケーションズ調査・チュートリアル、第14巻、464ページ - 490、DOI 10.1109 / brous.2011.042711.00078,2012、<https：//doi.org/10.1109/surv.2011.042711.00078>。
[NFV] ETSI, "Network Functions Virtualisation", SDN and OpenFlow World Congress, October 2012, <https://portal.etsi.org/NFV/NFV_White_Paper.pdf>.
[NFV] ETSI、「ネットワーク機能仮想化」、SDN、OpenFlow World Congress、2012年10月、<https://portal.etsi.org/nfv/nfv_white_paper.pdf>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] ENNS、R.、ED。、Bjorklund、M.、Ed。、Schoenwaelder、J.、Ed。、およびA. Bierman、ED。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487 /RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルに関するプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[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>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、ED。C. Pignataro、Ed。、「サービス機能連鎖（SFC）アーキテクチャ」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https：//www.rfc-editor.org/info/rfc7665>。
[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、「一般自律神経シグナリングプロトコルアプリケーションプログラムインタフェース（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>。
[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, <https://www.rfc-editor.org/info/rfc8993>.
[RFC8993] Behringer、M.、Ed。、Carpenter、B.、Eckert、T.、Ciavaglia、L.、およびJ.Bobre、 "Autonomic Networkingのための参照モデル"、RFC 8993、DOI 10.17487 / RFC8993、2021年5月、<https://www.rfc-editor.org/info/rfc8993>。
[ZSM009-1] ETSI, "Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 1: Enablers", GS ZSM 009-1, Version 1.1.1, June 2021, <https://www.etsi.org/deliver/etsi_gs/ ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf>.
[ZSM009-1] ETSI、「ゼロタッチネットワークとサービス管理（ZSM）;閉ループ自動化;第1部：イネーブラ」、GS ZSM 009-1、GS ZSM 009-1、<https：// www・jetsi.org / difigand / etsi_gs / zsm / 001_099 / 00901 / 01.01.01_60 / gs_zsm00901v010101p.pdf>。
This appendix describes generic logic flows that combine to act as an Autonomic Service Agent (ASA) for resource management. Note that these are illustrative examples and are in no sense requirements. As long as the rules of GRASP are followed, a real implementation could be different. The reader is assumed to be familiar with GRASP [RFC8990] and its conceptual API [RFC8991].
この付録では、リソース管理のために自律型サービスエージェント（ASA）として機能する汎用ロジックフローについて説明します。これらは例示的な例であり、意味のない要件にありません。把握規則に従う限り、実際の実装は異なる可能性があります。リーダーはGRASP [RFC8990]とその概念API [RFC8991]に精通していると見なされます。
A complete autonomic function for a distributed resource will consist of a number of instances of the ASA placed at relevant points in a network. Specific details will, of course, depend on the resource concerned. One example is IP address prefix management, as specified in [RFC8992]. In this case, an instance of the ASA will exist in each delegating router.
分散リソースの完全な自律型関数は、ネットワーク内の関連するポイントに配置されたASAの多くのインスタンスで構成されます。具体的な詳細は、もちろん関心のあるリソースに依存します。1つの例は、[RFC8992]で指定されているように、IPアドレスプレフィックス管理です。この場合、ASAのインスタンスは各委任ルータに存在します。
An underlying assumption is that there is an initial source of the resource in question, referred to here as an origin ASA. The other ASAs, known as delegators, obtain supplies of the resource from the origin, delegate quantities of the resource to consumers that request it, and recover it when no longer needed.
根本的な仮定は、問題のリソースの初期源があるということです。ここでは原点ASAと呼ばれます。委任者として知られている他のASAは、原点からリソースの電源を入手し、それを要求する消費者に数量を委任し、それを必要としなくなったときにそれを回復する。
Another assumption is there is a set of network-wide policy parameters, which the origin will provide to the delegators. These parameters will control how the delegators decide how much resource to provide to consumers. Thus, the ASA logic has two operating modes: origin and delegator. When running as an origin, it starts by obtaining a quantity of the resource from the NOC, and it acts as a source of policy parameters, via both GRASP flooding and GRASP synchronization. (In some scenarios, flooding or synchronization alone might be sufficient, but this example includes both.)
もう一つの仮定は、原点が委任者に提供するネットワーク全体のポリシーパラメータのセットがある。これらのパラメータは、デリゲータが消費者にどのようなリソースをどのように決定するかをどのように決定するかを制御します。したがって、ASAロジックには、OriginとDelegatorの2つの動作モードがあります。原点として実行すると、NOCからのリソースの数量を取得することから始まり、把握フラッディングと把握同期の両方を介して、ポリシーパラメータのソースとして機能します。（いくつかのシナリオでは、フラッディングまたは同期だけでは十分であるかもしれませんが、この例は両方を含みます。）
When running as a delegator, it starts with an empty resource pool, acquires the policy parameters by GRASP synchronization, and delegates quantities of the resource to consumers that request it. Both as an origin and as a delegator, when its pool is low, it seeks quantities of the resource by requesting GRASP negotiation with peer ASAs. When its pool is sufficient, it hands out resource to peer ASAs in response to negotiation requests. Thus, over time, the initial resource pool held by the origin will be shared among all the delegators according to demand.
委任者として実行すると、空のリソースプールから始まり、同期の把握によってポリシーパラメータを取得し、そのリソースの数量を要求する消費者に委任します。原点として、デレゲーターとしてのどちらも、プールが低い場合は、ピアASASとの把握交渉を要求することでリソースの量を探します。プールで十分である場合は、ネゴシエーション要求に応答してISASへのリソースを取り出します。したがって、経時的に、原点によって保持されている初期リソースプールは、需要に応じてすべての委任者間で共有されます。
In theory, a network could include any number of origins and any number of delegators, with the only condition being that each origin's initial resource pool is unique. A realistic scenario is to have exactly one origin and as many delegators as you like. A scenario with no origin is useless.
理論的には、ネットワークには、各原点の初期リソースプールが一意であるという点で唯一の状態があるため、任意の数の起源と任意の数のデリゲータを含めることができます。現実的なシナリオは、あなたが好きなのと同じくらい多くの出身の委任者を持つことです。起源のないシナリオは無用です。
An implementation requirement is that resource pools are kept in stable storage. Otherwise, if a delegator exits for any reason, all the resources it has obtained or delegated are lost. If an origin exits, its entire spare pool is lost. The logic for using stable storage and for crash recovery is not included in the pseudocode below, which focuses on communication between ASAs. Since GRASP operations are not intrinsically idempotent, data integrity during failure scenarios is the responsibility of the ASA designer. This is a complex topic in its own right that is not discussed in the present document.
実装要件は、リソースプールが安定したストレージに保持されるということです。それ以外の場合、委任者が何らかの理由で終了した場合、それが取得または委任したすべてのリソースが失われます。原点が終了すると、そのスペアプール全体が失われます。安定した記憶域を使用し、クラッシュ回復のためのロジックは、以下の疑似コードに含まれておらず、ASA間の通信に焦点を当てています。GRASP操作は本質的にIDEmpotentではないため、障害シナリオ中のデータの整合性はASAデザイナの責任です。これは、本文書では議論されていない独自の権利の複雑なトピックです。
The description below does not implement GRASP's dry run function. That would require temporarily marking any resource handed out in a dry run negotiation as reserved, until either the peer obtains it in a live run, or a suitable timeout occurs.
以下の説明では、GRASSのドライラス機能を実装していません。それは、ピアがライブランでそれを取得するか適切なタイムアウトが発生するまで、ドライランネゴシエーションで配信されたリソースを一時的にマークします。
The main data structures used in each instance of the ASA are:
ASAの各インスタンスで使用されている主なデータ構造は次のとおりです。
* resource_pool: an ordered list of available resources, for example. Depending on the nature of the resource, units of resource are split when appropriate, and a background garbage collector recombines split resources if they are returned to the pool.
* resource_pool：たとえば利用可能なリソースの順序付きリスト。リソースの性質に応じて、必要に応じてリソースの単位が分割され、バックグラウンドガベージコレクタはプールに返された場合にリソースの分割を再結合します。
* delegated_list: where a delegator stores the resources it has given to subsidiary devices.
* delegated_list：委任者がそれが補助装置に与えられたリソースを保存する場所。
Possible main logic flows are below, using a threaded implementation model. As noted above, alternative approaches to asynchronous operations are possible. The transformation to an event loop model should be apparent; each thread would correspond to one event in the event loop.
スレッド化された実装モデルを使用して、可能なメインロジックフローは以下のとおりです。上記のように、非同期操作への代替アプローチが可能です。イベントループモデルへの変換は明らかであるはずです。各スレッドはイベントループ内の1つのイベントに対応します。
The GRASP objectives are as follows:
把握目的は次のとおりです。
* ["EX1.Resource", flags, loop_count, value], where the value depends on the resource concerned but will typically include its size and identification.
* ["ex1.resource"、flags、loop_count、値]。値は関係するリソースによって異なりますが、通常そのサイズと識別が含まれます。
* ["EX1.Params", flags, loop_count, value], where the value will be, for example, a JSON object defining the applicable parameters.
* ["ex1.params"、flags、loop_count、value]。値は、たとえば、適用可能なパラメータを定義するJSONオブジェクトになります。
In the outline logic flows below, these objectives are represented simply by their names.
下のアウトラインロジックでは、これらの目的はそれらの名前だけで表されます。
MAIN PROGRAM:
メインプログラム：
Create empty resource_pool (and an associated lock)
Create empty delegated_list
Determine whether to act as origin
if origin:
Obtain initial resource_pool contents from NOC
Obtain value of EX1.Params from NOC
Register ASA with GRASP
Register GRASP objectives EX1.Resource and EX1.Params
if origin:
Start FLOODER thread to flood EX1.Params
Start SYNCHRONIZER listener for EX1.Params
Start MAIN_NEGOTIATOR thread for EX1.Resource
if not origin:
Obtain value of EX1.Params from GRASP flood or synchronization
Start DELEGATOR thread
Start GARBAGE_COLLECTOR thread
good_peer = none
do forever:
if resource_pool is low:
Calculate amount A of resource needed
Discover peers using GRASP M_DISCOVER / M_RESPONSE
if good_peer in peers:
peer = good_peer
else:
peer = #any choice among peers
grasp.request_negotiate("EX1.Resource", peer)
#i.e., send negotiation request
Wait for response (M_NEGOTIATE, M_END or M_WAIT)
if OK:
if offered amount of resource sufficient:
Send M_END + O_ACCEPT #negotiation succeeded
Add resource to pool
good_peer = peer #remember this choice
else:
Send M_END + O_DECLINE #negotiation failed
good_peer = none #forget this choice
sleep() #periodic timer suitable for application scenario
MAIN_NEGOTIATOR thread:
main_negotiatorスレッド：
do forever: grasp.listen_negotiate("EX1.Resource") #i.e., wait for negotiation request Start a separate new NEGOTIATOR thread for requested amount A
永遠に行う：GRASP.LISTEN_NEGOTIATE（ "ex1.resource"）＃すなわち、ネゴシエーション要求を待ち、要求された金額のための別の新しいネゴシエータスレッドを開始
NEGOTIATOR thread:
ネゴシエータスレッド：
Request resource amount A from resource_pool if not OK: while not OK and A > Amin: A = A-1 Request resource amount A from resource_pool if OK: Offer resource amount A to peer by GRASP M_NEGOTIATE if received M_END + O_ACCEPT: #negotiation succeeded elif received M_END + O_DECLINE or other error: #negotiation failed Return resource to resource_pool else: Send M_END + O_DECLINE #negotiation failed #thread exits
OKではなくOKではなく、A amin：A = A-1 OKの場合はResource_Poolからリソース額aを要求します.M_END O_Acceptを受信した場合、grasp m_negotiate：#negotiationはELIFに成功した場合M_END O_DECLINEまたはその他のエラーを受信しました：#negotiation failure Return Returne Returne Retures_Poolへのリソース：送信M_End O_Decline #negotiationに失敗しました#thread exits
DELEGATOR thread:
デリゲータースレッド：
do forever: Wait for request or release for resource amount A if request: Get resource amount A from resource_pool if OK: Delegate resource to consumer #atomic Record in delegated_list #operation else: Signal failure to consumer Signal main thread that resource_pool is low else: Delete resource from delegated_list Return resource amount A to resource_pool
永遠に：リクエストAのリクエストまたはリリースを待ちます。リクエストの場合は、リソースをrecorde_poolから取得するOK：lease_poolからのリソースを消費者に委任します。lease_listの解析_list #Atomic Record #Operation elsether：consumer signal signal signal signal signal signal signalsメインスレッドのメインスレッドdelegated_listからリソースを削除するリソース額をRESOURCE_POOLに返す
SYNCHRONIZER thread:
シンクロナイザスレッド：
do forever: Wait for M_REQ_SYN message for EX1.Params Reply with M_SYNCH message for EX1.Params
永遠に：ex1.paramsのM_Synchメッセージでm_req_synメッセージを待ってください。
FLOODER thread:
洪水糸：
do forever: Send M_FLOOD message for EX1.Params sleep() #periodic timer suitable for application scenario
永遠に：ex1.params sleep（）のためにm_floodメッセージを送信するアプリケーションのシナリオに適した＃周期的タイマー
GARBAGE_COLLECTOR thread:
Garbage_Collectorスレッド：
do forever: Search resource_pool for adjacent resources Merge adjacent resources sleep() #periodic timer suitable for application scenario
永遠に：隣接リソースのためのResource_poolを検索する
Acknowledgements
謝辞
Valuable comments were received from Michael Behringer, Menachem Dodge, Martin Dürst, Toerless Eckert, Thomas Fossati, Alex Galis, Bing Liu, Benno Overeinder, Michael Richardson, Rob Wilton, and other IESG members.
Michael Behringer、Manachem Dodge、MartinDürst、MartinDürst、Toerless Eckert、Thomas Fossati、Alex Galis、Bing Liu、Benno Overeinder、Michael Richardson、Rob Wilton、その他のIESGメンバーから受信されました。
Authors' Addresses
著者の住所
Brian Carpenter School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com
オークランド大学オークランド大学のBrian Carpenter School of Auckland 1142 New Zealand Eメール：brian.e.carpenter@gmail.com
Laurent Ciavaglia Rakuten Mobile Paris France Email: laurent.ciavaglia@rakuten.com
Laurent Ciavaglia Rakuten Mobile Paris Franceメール：Laurent.ciavaglia@rakuten.com
Sheng Jiang Huawei Technologies Co., Ltd Q14 Huawei Campus 156 Beiqing Road Hai-Dian District Beijing 100095 China Email: jiangsheng@huawei.com
Sheng Jiang Huawei Technologies Co.、Ltd Q14 Huawei Campus 156 Beiqing Road Hai-Dian地区北京100095中国Eメール：jiangsheng@huawei.com
Pierre Peloso Nokia Villarceaux 91460 Nozay France Email: pierre.peloso@nokia.com
Pierre Peloso Nokia Villarceaux 91460 Nozay Franceメール：Pierre.peloso@nokia.com