Internet Engineering Task Force (IETF) E. Birrane, III
Request for Comments: 9675 S. Heiner
Category: Informational E. Annis
ISSN: 2070-1721 JHU/APL
November 2024
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices.
遅延耐性ネットワーキング（DTN）アーキテクチャは、長い信号伝播の遅延、頻繁なリンクの破壊、またはその両方によって通信が大きな影響を受ける可能性のある挑戦されたネットワークの一種を説明しています。この環境のユニークな特性には、非同期輸送、自律的なローカル制御、および制約されたデバイスに展開するために（リソースと依存関係の両方で）小さなフットプリントをサポートするネットワーク管理へのユニークなアプローチが必要です。
This document describes a DTN Management Architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over unidirectional links and other places where BP is the preferred transport.
このドキュメントでは、チャレンジされた環境でデバイスの管理に適したDTN管理アーキテクチャ（DTNMA）について説明しますが、特に、DTNバンドルプロトコル（BP）を使用して通信するものです。BPを介して動作するには、同期された輸送挙動もクエリ応答メカニズムに依存していないアーキテクチャが必要です。このDTNMAに準拠した実装は、単方向の過剰リンクやBPが優先輸送である他の場所など、非常に困難な状況でうまく動作することを期待するはずです。
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/rfc9675.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9675で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Organization
2. Terminology
3. Challenged Network Overview
3.1. Challenged Network Constraints
3.2. Topology and Service Implications
3.2.1. Tiered Management
3.2.2. Remote and Local Manager Associations
3.3. Management Special Cases
4. Desirable Design Properties
4.1. Dynamic Architectures
4.2. Hierarchically Modeled Information
4.3. Adaptive Push of Information
4.4. Efficient Data Encoding
4.5. Universal, Unique Data Identification
4.6. Runtime Data Definitions
4.7. Autonomous Operation
5. Current Remote Management Approaches
5.1. SNMP and SMI Models
5.1.1. The SMI Modeling Language
5.1.2. SNMP and Transport
5.2. XML-Infoset-Based Protocols and YANG Data Models
5.2.1. The YANG Modeling Language
5.2.2. NETCONF Protocol and Transport
5.2.3. RESTCONF Protocol and Transport
5.2.4. CORECONF Protocol and Transport
5.3. gRPC Network Management Interface (gNMI)
5.3.1. The Protobuf Modeling Language
5.3.2. gRPC Protocol and Transport
5.4. Intelligent Platform Management Interface (IPMI)
5.5. Autonomic Networking
5.6. Deep Space Autonomy
6. Motivation for New Features
7. Reference Model
7.1. Important Concepts
7.2. Model Overview
7.3. Functional Elements
7.3.1. Managed Applications and Services
7.3.2. DTNMA Agent (DA)
7.3.3. Managing Applications and Services
7.3.4. DTNMA Manager (DM)
7.3.5. Pre-Shared Definitions
8. Desired Services
8.1. Local Monitoring and Control
8.2. Local Data Fusion
8.3. Remote Configuration
8.4. Remote Reporting
8.5. Authorization
9. Logical Autonomy Model
9.1. Overview
9.2. Model Characteristics
9.3. Data Value Representation
9.4. Data Reporting
9.5. Command Execution
9.6. Predicate Autonomy Rules
10. Use Cases
10.1. Notation
10.2. Serialized Management
10.3. Intermittent Connectivity
10.4. Open-Loop Reporting
10.5. Multiple Administrative Domains
10.6. Cascading Management
11. IANA Considerations
12. Security Considerations
13. Informative References
Acknowledgements
Authors' Addresses
This document describes a logical, informational Delay-Tolerant Networking Management Architecture (DTNMA) suitable for operating devices in a challenged architecture, such as those communicating using the DTN Bundle Protocol version 7 (BPv7) [RFC9171].
このドキュメントでは、DTNバンドルプロトコルバージョンバージョン7（BPV7）[RFC9171]を使用して通信するなど、挑戦されたアーキテクチャの操作デバイスに適した論理的な情報遅延ネットワーク管理アーキテクチャ（DTNMA）について説明します。
Challenged networks have certain properties that differentiate them from other kinds of networks. These properties, outlined in Section 2.2.1 of [RFC7228], include lacking end-to-end IP connectivity, having "serious interruptions" to end-to-end connectivity, and exhibiting delays longer than can be tolerated by end-to-end synchronization mechanisms (such as TCP).
挑戦されたネットワークには、他の種類のネットワークと区別する特定のプロパティがあります。[RFC7228]のセクション2.2.1で概説されているこれらのプロパティには、エンドツーエンドのIP接続の欠如、エンドツーエンドの接続に「深刻な中断」があり、エンドツーツーから容認できるよりも長い遅延を示すことが含まれます。末端同期メカニズム（TCPなど）。
These challenged network properties can be caused by a variety of factors such as physical constraints (e.g., long signal propagation delays and frequent link disruptions), administrative policies (e.g., quality-of-service prioritization, service-level agreements, and traffic management and scheduling), and off-nominal behaviors (e.g., active attackers and misconfigurations). Since these challenges are not solely caused by sparseness, instances of challenged networks will persist even in increasingly connected environments.
これらの挑戦されたネットワークプロパティは、物理的制約（例えば、長い信号伝播遅延や頻繁なリンクの破壊）、管理ポリシー（例えば、サービスレベルの契約、交通管理、および交通管理やスケジューリング）、および統一的な動作（例：アクティブな攻撃者や誤解）。これらの課題はスパース性だけによって引き起こされるわけではないため、挑戦されたネットワークの事例は、ますます接続されている環境でも持続します。
The DTN architecture, described in [RFC4838], has been designed for data exchange in challenged networks. Just as the DTN architecture requires new capabilities for transport and transport security, special consideration is needed for the operation of devices in a challenged network.
[RFC4838]に記載されているDTNアーキテクチャは、課題のあるネットワークでのデータ交換用に設計されています。DTNアーキテクチャが輸送および輸送のセキュリティに新しい機能を必要とするように、挑戦されたネットワークでのデバイスの運用には特別な考慮事項が必要です。
This document describes how challenged network properties affect the operation of devices in such networks. This description is presented as a logical architecture formed from a union of best practices for operating devices deployed in challenged environments.
このドキュメントでは、挑戦されたネットワークプロパティがそのようなネットワーク内のデバイスの動作にどのように影響するかについて説明します。この説明は、挑戦された環境で展開された操作デバイスのベストプラクティスの連合から形成された論理アーキテクチャとして提示されています。
One important practice captured in this document is the concept of self-operation. Self-operation involves operating a device without human interactivity, without system-in-the-loop synchronous functions, and without a synchronous underlying transport layer. This means that devices determine their own schedules for data reporting, determine their own operational configuration, and perform their own error discovery and mitigation.
このドキュメントで撮影された重要な実践の1つは、自己操作の概念です。自己操作には、人間の対話性なしで、システムインザループの同期関数なしで、および同期の基礎となる輸送層なしでデバイスを操作することが含まれます。これは、デバイスがデータレポートの独自のスケジュールを決定し、独自の運用構成を決定し、独自のエラーの発見と緩和を実行することを意味します。
This document includes the information necessary to document existing practices for operating devices in a challenged network in the context of a logical architecture. A logical architecture describes the logical operation of a system by identifying components of the system (such as in a reference model), the behaviors they enable, and use cases describing how those behaviors result in the desired operation of the system.
このドキュメントには、論理アーキテクチャのコンテキストで、挑戦されたネットワークで操作デバイスの既存のプラクティスを文書化するために必要な情報が含まれています。論理アーキテクチャは、システムのコンポーネント（参照モデルなど）、有効な動作、およびそれらの動作がシステムの望ましい動作をもたらす方法を説明するユースケースを識別することにより、システムの論理操作を説明します。
Logical architectures are not functional architectures. Therefore, any functional design for achieving desired behaviors is out of scope for this document. The set of architectural principles presented here is not meant to completely specify interfaces between components.
論理アーキテクチャは機能的なアーキテクチャではありません。したがって、このドキュメントでは、望ましい動作を達成するための機能設計は範囲外です。ここに示されている一連の建築原則は、コンポーネント間のインターフェイスを完全に指定することを意図したものではありません。
The selection of any particular transport or network layer is outside of the scope of this document. The DTNMA does not require the use of any specific protocol such as IP, BP, TCP, or UDP. In particular, the DTNMA design does not presume the use of BPv7, IPv4, or IPv6.
特定のトランスポートレイヤーまたはネットワークレイヤーの選択は、このドキュメントの範囲外です。DTNMAは、IP、BP、TCP、またはUDPなどの特定のプロトコルの使用を必要としません。特に、DTNMA設計では、BPV7、IPv4、またはIPv6の使用を推定していません。
NOTE: As BPv7 is the preferred transport for networks conforming to the DTN architecture, the DTNMA should be considered for any BPv7 network deployment. However, the DTNMA may also be used in other networks that have similar needs for this particular style of self-operation. For this reason, the DTNMA does not require the use of BPv7 to transport management information.
注：BPV7はDTNアーキテクチャに準拠するネットワークの好ましいトランスポートであるため、BPV7ネットワークの展開についてはDTNMAを考慮する必要があります。ただし、DTNMAは、この特定のスタイルの自己操作に同様のニーズを持つ他のネットワークでも使用される場合があります。このため、DTNMAは管理情報を輸送するためにBPV7を使用する必要はありません。
Network features such as naming, addressing, routing, and communications security are out of scope for the DTNMA. It is presumed that any operational network communicating DTNMA messages would implement these services for any payloads carried by that network.
命名、アドレス指定、ルーティング、通信セキュリティなどのネットワーク機能は、DTNMAの範囲外です。DTNMAメッセージを通信する運用ネットワークは、そのネットワークが携帯するペイロードに対してこれらのサービスを実装すると推定されます。
The interactions between and amongst the DTNMA and other management approaches are outside of the scope of this document.
DTNMAとその他の管理アプローチの間での相互作用は、このドキュメントの範囲外です。
The following nine sections provide details regarding the DTNMA.
次の9つのセクションでは、DTNMAに関する詳細を提供します。
Terminology:
用語：
Section 2 identifies terms fundamental to understanding DTNMA concepts. Whenever possible, these terms align in both word selection and meaning with their use in other management protocols.
セクション2では、DTNMAの概念を理解するための基本的な用語を特定します。可能な場合はいつでも、これらの用語は、他の管理プロトコルでの使用とともに、単語の選択と意味の両方に合わせます。
Challenged Network Overview:
挑戦されたネットワークの概要：
Section 3 describes important aspects of challenged networks and necessary approaches for their management.
セクション3では、挑戦されたネットワークの重要な側面と、それらの管理に必要なアプローチについて説明します。
Desirable Design Properties:
望ましい設計特性：
Section 4 defines those properties of the DTNMA needed to operate within the constraints of a challenged network. These properties are similar to the specification of system-level requirements of a DTN management solution.
セクション4では、挑戦されたネットワークの制約内で動作するために必要なDTNMAのプロパティを定義しています。これらのプロパティは、DTN管理ソリューションのシステムレベルの要件の仕様に似ています。
Current Remote Management Approaches:
現在のリモート管理アプローチ：
Section 5 provides a brief overview of existing remote management approaches. Where possible, the DTNMA adopts concepts from these approaches.
セクション5では、既存のリモート管理アプローチの簡単な概要を説明します。可能であれば、DTNMAはこれらのアプローチから概念を採用しています。
Motivation for New Features:
新機能の動機：
Section 6 provides an overall motivation for this work. It also explains why a management architecture for challenged networks is useful and necessary.
セクション6では、この作業の全体的な動機を提供します。また、挑戦されたネットワークの管理アーキテクチャが有用で必要である理由も説明しています。
Reference Model:
参照モデル：
Section 7 defines a reference model that can be used to analyze the DTNMA independently of an implementation or implementation architecture. This model identifies the logical components of the system and the high-level relationships and behaviors amongst those components.
セクション7では、実装または実装アーキテクチャとは無関係にDTNMAを分析するために使用できる参照モデルを定義します。このモデルは、システムの論理コンポーネントと、それらのコンポーネント間の高レベルの関係と動作を識別します。
Desired Services:
望ましいサービス：
Section 8 identifies and defines the DTNMA services provided to network and mission operators.
セクション8では、ネットワークおよびミッションオペレーターに提供されるDTNMAサービスを特定および定義します。
Logical Autonomy Model:
論理自律モデル：
Section 9 provides an example data model that can be used to analyze DTNMA control and data flows. This model is based on the DTNMA reference model.
セクション9では、DTNMA制御とデータフローの分析に使用できるデータモデルの例を示します。このモデルは、DTNMA参照モデルに基づいています。
Use Cases:
ユースケース：
Section 10 presents multiple use cases accommodated by the DTNMA. Each use case is presented as a set of control and data flows referencing the DTNMA reference model and logical autonomy model.
セクション10では、DTNMAに対応した複数のユースケースを示します。各ユースケースは、DTNMA参照モデルと論理自律モデルを参照する一連の制御およびデータフローとして提示されます。
This section defines terminology that is either unique to the DTNMA or necessary for understanding the concepts defined in this specification.
このセクションでは、DTNMAに固有の、またはこの仕様で定義されている概念を理解するために必要な用語を定義します。
Timely Data Exchange:
タイムリーなデータ交換：
The ability to communicate information between two (or more) entities within a required period of time. In some cases, a 1-second exchange may not be timely; in other cases, a 1-hour exchange may be timely.
必要な期間内に2つ（またはそれ以上）のエンティティ間で情報を伝える機能。場合によっては、1秒の交換はタイムリーではない場合があります。それ以外の場合、1時間の交換はタイムリーな場合があります。
Local Operation:
ローカル操作：
The operation of a device by an application co-resident on that device. Local operators are applications running on a device, and there might be one or more of these applications working independently or as one to perform the local operations function. Absent error conditions, local operators are always expected to be available to the devices they manage.
そのデバイス上のアプリケーションの共同住宅によるデバイスの操作。ローカルオペレーターは、デバイスで実行されているアプリケーションであり、これらのアプリケーションの1つ以上が独立して動作するか、ローカルオペレーション機能を実行するために1つとして動作する可能性があります。エラー条件がない場合、ローカルオペレーターは常に、管理するデバイスで利用できると予想されます。
Remote Operation:
リモート操作：
The operation of a device by an application running on a separate device. Remote operators communicate with operated devices over a network. Remote operators are not always expected to be available to the devices they operate.
別のデバイスで実行されているアプリケーションによるデバイスの操作。リモートオペレーターは、ネットワークを介して動作したデバイスと通信します。リモートオペレーターは、操作するデバイスで常に利用できるとは限りません。
DTN Management:
DTN管理：
The management, monitoring, and control of a device that does not depend on stateful connections, timely data exchange of management messages, or system-in-the-loop synchronous functions. DTN management is accomplished as a fusion of local operation and remote operation techniques; remote operators manage the configuration of local operators who provide monitoring and control of their co-resident devices.
ステートフルな接続、管理メッセージのタイムリーなデータ交換、またはループ内の同期関数に依存しないデバイスの管理、監視、および制御。DTN管理は、ローカル操作とリモート操作技術の融合として達成されます。リモートオペレーターは、共同居住デバイスの監視と制御を提供するローカルオペレーターの構成を管理します。
DTNMA Agent (DA):
DTNMAエージェント（DA）：
A role associated with a managed device responsible for reporting performance data, accepting policy directives, performing autonomous local control, error handling, and data validation. DAs exchange information with DTNMA Managers (DMs) operating on the same device and/or on remote devices in the network. A DA is a type of local operator.
パフォーマンスデータの報告、ポリシー指令の受け入れ、自律的なローカル制御の実行、エラー処理、およびデータ検証を担当する管理されたデバイスに関連する役割。DASは、同じデバイスやネットワーク内のリモートデバイスで動作するDTNMAマネージャー（DMS）と情報を交換します。DAはローカルオペレーターの一種です。
DTNMA Manager (DM):
DTNMAマネージャー（DM）：
A role associated with a managing device responsible for configuring the behavior of, and eventually receiving information from, DAs. DMs interact with one or more DAs located on the same device and/or on remote devices in the network. A DM is a type of remote operator.
DASの動作の構成と最終的に情報を受信するための管理デバイスに関連する役割。DMSは、同じデバイスまたはネットワーク内のリモートデバイスにある1つ以上のDAと対話します。DMはリモート演算子の一種です。
Controls:
コントロール：
Procedures run by a DA to change the behavior, configuration, or state of an application or protocol managed by that DA. These include procedures to manage the DA itself, such as having the DA produce performance reports or applying new management policies.
DAが実行する手順は、そのDAによって管理されるアプリケーションまたはプロトコルの動作、構成、または状態を変更します。これらには、DAがパフォーマンスレポートを作成したり、新しい管理ポリシーを適用したりするなど、DA自体を管理する手順が含まれます。
Externally Defined Data (EDD):
外部定義データ（EDD）：
Typed information made available to a DA by its hosting device but not computed directly by the DA itself.
HostingデバイスによってDAが利用できるようになったタイプ化された情報は、DA自体によって直接計算されません。
Data Report:
データレポート：
A typed, ordered collection of data values gathered by one or more DAs and provided to one or more DMs. Reports comply with the format of a given data report schema.
1つまたは複数のDAによって収集され、1つ以上のDMに提供されたデータ値の順序付けられた順序付けられたコレクション。レポートは、特定のデータレポートスキーマの形式に準拠しています。
Data Report Schema:
データレポートスキーマ：
A named, ordered collection of data elements that represent the schema of a data report.
データレポートのスキーマを表すデータ要素の指定された順序付けられたコレクション。
Rule:
ルール：
Unit of autonomous specification that provides a stimulus-response relationship between time or state on a DA and the actions or operations to be run as a result of that time or state.
DAでの時間または状態との間の刺激反応関係を提供する自律仕様の単位と、その時間または状態の結果として実行されるアクションまたは操作。
The DTNMA provides network management services able to operate in challenged network environments for which the DTN architecture was created. This section describes what is meant by the term "challenged network", the important properties of such a network, and observations on impacts to management approaches.
DTNMAは、DTNアーキテクチャが作成された課題のあるネットワーク環境で動作できるネットワーク管理サービスを提供します。このセクションでは、「挑戦されたネットワーク」という用語、そのようなネットワークの重要な特性、および管理アプローチへの影響に関する観察の意味を説明します。
Constrained networks are defined as networks where "some of the characteristics pretty much taken for granted with link layers in common use in the Internet at the time of writing are not attainable" [RFC7228]. This broad definition captures a variety of potential issues relating to physical, technical, and regulatory constraints on message transmission. Constrained networks typically include nodes that regularly reboot or are otherwise turned off for long periods of time, transmit at low or asynchronous bitrates, and/or have very limited computational resources.
制約されたネットワークは、「執筆時点でインターネットで一般的に使用されているリンクレイヤーとほとんど当たり前の特性が達成できない」[RFC7228]であるネットワークとして定義されます。この広範な定義は、メッセージ伝達に関する物理的、技術的、規制上の制約に関連するさまざまな潜在的な問題を捉えています。制約されたネットワークには、通常、定期的に再起動する、またはそれ以外の場合は長期間オフになっているノード、低いまたは非同期のビットレートで送信、および/または計算リソースが非常に限られているノードが含まれます。
Separately, a challenged network is defined as one that "has serious trouble maintaining what an application would today expect of the end-to-end IP model" [RFC7228]. Links in such networks may be impacted by attenuation, propagation delays, mobility, occultation, and other limitations imposed by energy and mass considerations. Therefore, systems relying on such links cannot guarantee timely end-to-end data exchange.
それとは別に、挑戦されたネットワークは、「今日アプリケーションがエンドツーエンドIPモデルに期待するものを維持することを深刻な問題を抱えている」ものとして定義されています[RFC7228]。このようなネットワークのリンクは、減衰、伝播の遅延、機動性、潜在性、およびエネルギーと大量の考慮事項によって課されるその他の制限の影響を受ける可能性があります。したがって、このようなリンクに依存するシステムは、タイムリーなエンドツーエンドのデータ交換を保証することはできません。
NOTE: Because challenged networks might not provide services expected of the end-to-end IP model, devices in such networks might not implement networking stacks associated with the end-to-end IP model. This means that devices might not include support for certain transport protocols (TCP/QUIC/UDP), web protocols (HTTP), or internetworking protocols (IPv4/IPv6).
注：挑戦されたネットワークは、エンドツーエンドIPモデルに期待されるサービスを提供しない可能性があるため、このようなネットワーク内のデバイスは、エンドツーエンドIPモデルに関連付けられたネットワークスタックを実装しない場合があります。つまり、デバイスには、特定のトランスポートプロトコル（TCP/QUIC/UDP）、Webプロトコル（HTTP）、またはインターネットワークプロトコル（IPv4/IPv6）のサポートが含まれない場合があります。
By these definitions, a "challenged" network is a special type of "constrained" network, where constraints prevent timely end-to-end data exchange. As such, "All challenged networks are constrained networks ... but not all constrained networks are challenged networks ... Delay-Tolerant Networking (DTN) has been designed to cope with challenged networks" [RFC7228].
これらの定義により、「挑戦された」ネットワークは、制約がタイムリーなエンドツーエンドのデータ交換を防ぐ特別なタイプの「制約付き」ネットワークです。そのため、「すべての挑戦されたネットワークは制約されたネットワークです...しかし、すべての制約されたネットワークが挑戦されたネットワークであるわけではありません...遅延耐性ネットワーク（DTN）は、挑戦されたネットワークに対処するように設計されています」[RFC7228]。
Solutions that work in constrained networks might not be solutions that work in challenged networks. In particular, challenged networks exhibit the following properties that impact the way in which the function of network management is considered.
制約されたネットワークで機能するソリューションは、挑戦されたネットワークで機能するソリューションではない可能性があります。特に、挑戦されたネットワークは、ネットワーク管理の機能が考慮される方法に影響を与える次のプロパティを示します。
* Timely end-to-end data exchange cannot be guaranteed to exist at any given time between any two nodes.
* タイムリーなエンドツーエンドのデータ交換は、任意の2つのノードの間にいつでも存在することを保証できません。
* Latencies on the order of seconds, hours, or days must be tolerated.
* 数秒、時間、または日数のレイテンシは容認する必要があります。
* Managed devices cannot be guaranteed to always be powered so as to receive ad hoc management requests (even requests with artificially extended timeout values).
* マネージドデバイスは、アドホック管理リクエスト（人為的に拡張されたタイムアウト値を持つリクエストも）を受信するために、常に電源を入れることを保証することはできません。
* Individual links may be unidirectional.
* 個々のリンクは一方向にある場合があります。
* Bidirectional links may have asymmetric data rates.
* 双方向リンクには非対称データレートがある場合があります。
* The existence of external infrastructure, services, systems, or processes such as a Domain Name System (DNS) or a Certificate Authority (CA) cannot be guaranteed.
* 外部インフラストラクチャ、サービス、システム、またはドメイン名システム（DNS）や証明書当局（CA）などのプロセスの存在は保証できません。
The set of constraints that might be present in a challenged network impacts both the topology of the network and the services active within that network.
挑戦されたネットワークに存在する可能性のある制約のセットは、ネットワークとそのネットワーク内でアクティブなサービスのトポロジの両方に影響を与えます。
Operational networks handle cases where nodes join and leave the network over time. These topology changes may or may not be planned, they may or may not represent errors, and they may or may not impact network services. Challenged networks differ from other networks not in the presence of topological change but in the likelihood that impacts to topology result in impacts to network services.
運用ネットワークは、ノードが結合してネットワークを時間の経過とともに離れるケースを処理します。これらのトポロジの変更は、計画されている場合とそうでない場合があり、エラーを表している場合と表していない場合があり、ネットワークサービスに影響を与える場合と影響を与えない場合があります。挑戦されたネットワークは、トポロジーの変化の存在ではなく、トポロジに影響を与える可能性がある他のネットワークとは異なり、ネットワークサービスに影響を与えます。
The difference between topology impacts and service impacts can be expressed in terms of connectivity. Topological connectivity usually refers to the existence of a path between an application message source and destination. Service connectivity, alternatively, refers to the existence of a path between a node and one or more services needed to process -- often just in time -- application messaging. Examples of service connectivity include access to infrastructure services such as a Domain Name System (DNS) or a CA.
トポロジの影響とサービスへの影響の違いは、接続性の観点から表現できます。トポロジカル接続は通常、アプリケーションメッセージソースと宛先間のパスの存在を指します。または、サービスの接続性は、ノードと処理に必要な1つ以上のサービス（多くの場合すぐに時間内に）のアプリケーションメッセージングの間のパスの存在を指します。サービス接続の例には、ドメイン名システム（DNS）やCAなどのインフラストラクチャサービスへのアクセスが含まれます。
In networks that might be partitioned most of the time, it is less likely that a node would concurrently access both an application endpoint and one or more network service endpoints. For this reason, network services in a challenged network should be designed to allow for asynchronous operation. Accommodating this use case often involves the use of local caching, pre-placing information, and not hard-coding message information at a source that might change when a message reaches its destination.
ほとんどの場合分割される可能性のあるネットワークでは、ノードがアプリケーションエンドポイントと1つ以上のネットワークサービスエンドポイントの両方に同時にアクセスする可能性は低くなります。このため、挑戦されたネットワーク内のネットワークサービスは、非同期操作を可能にするように設計する必要があります。このユースケースに対応するには、多くの場合、ローカルキャッシュ、事前配置情報の使用、およびメッセージが宛先に到達したときに変更される可能性のあるソースでのハードコーディングメッセージ情報の使用が含まれます。
NOTE: One example of rethinking services in a challenged network is the securing of BPv7 bundles. The Bundle Protocol Security (BPSec) [RFC9172] security extensions to BPv7 do not encode security destinations when applying security. Instead, BPSec requires nodes in a network to identify themselves as security verifiers or acceptors when receiving and processing secured messages.
注：挑戦されたネットワークでサービスを再考する例の1つは、BPV7バンドルの保護です。BPV7へのバンドルプロトコルセキュリティ（BPSEC）[RFC9172]セキュリティ拡張は、セキュリティを適用する際にセキュリティ宛先をエンコードしません。代わりに、BPSECはネットワーク内のノードを必要として、セキュリティの検証因子またはアクセプターとして自分自身を識別し、セキュリティで保護されたメッセージを受信および処理します。
Network operations and management approaches need to adapt to the topology and service impacts encountered in challenged networks. In particular, the roles and responsibilities of "managers" and "agents" need to be different than what would be expected of unchallenged networks.
ネットワークの運用と管理アプローチは、課題のあるネットワークで遭遇するトポロジとサービスの影響に適応する必要があります。特に、「マネージャー」と「エージェント」の役割と責任は、挑戦されていないネットワークに期待されるものとは異なる必要があります。
When connectivity to a manager cannot be guaranteed, agents will need to rely on locally available information and local autonomy to react to changes at the node. When an agent uses local autonomy for self-operation, it acts as a local operator serving as a proxy for an absent remote operator.
マネージャーへの接続を保証できない場合、エージェントは、ノードの変更に対応するために、ローカルに利用可能な情報とローカルの自律性に依存する必要があります。エージェントが自己操作のためにローカルの自律性を使用する場合、それは不在のリモートオペレーターのプロキシとして機能するローカルオペレーターとして機能します。
Therefore, the role of a "manager" must become one of a remote operator generating configurations and other essential updates for the local operator "agents" that are co-resident on a managed device.
したがって、「マネージャー」の役割は、管理されたデバイスの共同住宅であるローカルオペレーター「エージェント」のリモートオペレーター生成構成とその他の重要な更新の1つになる必要があります。
This approach creates a two-tiered management architecture. The first tier is the management of the local operator configuration using any one of a variety of standard mechanisms, models, and protocols. The second tier is the operation of the local device through the local operator.
このアプローチは、2段の管理アーキテクチャを作成します。最初の層は、さまざまな標準メカニズム、モデル、およびプロトコルのいずれかを使用したローカルオペレーター構成の管理です。2番目の層は、ローカルオペレーターを介したローカルデバイスの動作です。
The DTNMA defines the DTNMA Manager (DM) as a remote operator application and the DTNMA Agent (DA) as an agent acting as a local operator application. In this model, which is illustrated in Figure 1, the DM and DA can be viewed as applications, with the DM producing new configurations and the DA receiving those configurations from an underlying management mechanism.
DTNMAは、DTNMAマネージャー（DM）をリモートオペレーターアプリケーションとして定義し、DTNMAエージェント（DA）をローカルオペレーターアプリケーションとして機能するエージェントとして定義します。図1に示すこのモデルでは、DMとDAをアプリケーションと見なすことができ、DMは新しい構成を生成し、DAは基礎となる管理メカニズムからそれらの構成を受信します。
_
/
/ +------------+ +-----------+ Local +---------+
TIER / | DM (Remote | | DA (Local | Operation | Managed |
2 \ | Operator) | | Operator) | <---------> | Apps |
MGMT \ +------------+ +-----------+ +---------+
\_ ^ ^
| configs | configs
_ | |
/ V V
/ +------------+ Remote +------------+
TIER / | Management | Management | Management |
1 \ | Client | <----------> | Server |
MGMT \ +------------+ +------------+
\_
Figure 1: Two-Tiered Management Architecture
図1：2段の管理アーキテクチャ
In this approach, the configurations produced by the DM are based on the DA features and associated data model. How those configurations are transported between the DM and the DA, and how results are communicated back from the DA to the DM, can be accomplished using whatever mechanism is most appropriate for the network and the device platforms -- for example, the use of a Network Configuration Protocol (NETCONF), RESTCONF, or Simple Network Management Protocol (SNMP) server on the managed device to provide configurations to a DA.
このアプローチでは、DMによって生成される構成は、DA機能と関連データモデルに基づいています。これらの構成がDMとDAの間でどのように輸送されるか、および結果がDAからDMに伝達される方法は、ネットワークとデバイスプラットフォームに最も適したメカニズム、たとえばAの使用を使用して達成できます。ネットワーク構成プロトコル（NetConf）、RestConf、またはManagedデバイス上のSimple Network Management Protocol（SNMP）サーバーは、DAに構成を提供します。
In addition to disconnectivity, topological change can alter the associations amongst managed and managing devices. Different managing devices might be active in a network at different times or in different partitions. Managed devices might communicate with some, all, or none of these managing devices as a function of their own local configuration and policy.
切断性に加えて、トポロジーの変化は、管理されたデバイスと管理デバイス間の関連を変える可能性があります。さまざまなマネージングデバイスが、異なる時間または異なるパーティションでネットワークでアクティブになる可能性があります。管理されたデバイスは、独自のローカル構成とポリシーの関数として、これらの管理デバイスの一部、すべて、またはまったく通信する場合があります。
NOTE: These concepts relate to practices in conventional networks. For example, supporting multiple managing devices is similar to deploying multiple instances of a network service such as a DNS server or CA node. Selecting from a set of managing devices is similar to a sensor node's practice of electing cluster heads to act as privileged nodes for data storage and exfiltration.
注：これらの概念は、従来のネットワークのプラクティスに関連しています。たとえば、複数の管理デバイスをサポートすることは、DNSサーバーやCAノードなどのネットワークサービスの複数のインスタンスを展開することに似ています。一連の管理デバイスから選択することは、センサーノードのクラスターヘッドを選択して、データストレージと抽出の特権ノードとして機能するという練習に似ています。
Therefore, a network management architecture for challenged networks should:
したがって、挑戦されたネットワークのネットワーク管理アーキテクチャは次のとおりです。
1. Support a many-to-many association amongst managing and managed devices, and
1. 管理と管理されたデバイスの間の多目的な関連性をサポートし、
2. Allow "control from" and "reporting to" managing devices to function independently of one another.
2. 互いに独立して機能するようにデバイスの管理を「コントロール」と「レポート」を許可します。
The following special cases illustrate some of the operational situations that can be encountered in the management of devices in a challenged network.
次の特別なケースは、挑戦されたネットワーク内のデバイスの管理で遭遇する可能性のある運用状況の一部を示しています。
One-Way Management:
一方向の管理：
A managed device can only be accessed via a unidirectional link or via a link whose duration is shorter than a single round-trip propagation time. Results of this management may come back at a different time, over a different path, and/or as observable from out-of-band changes to device behavior.
管理されたデバイスは、単方向リンクまたは1回の往復伝播時間よりも期間が短いリンクを介してのみアクセスできます。この管理の結果は、別のパスで、および/または帯域外の変更からデバイスの動作に至るまで観察できるように、異なる時間に戻ってくる可能性があります。
Summary Data:
概要データ：
A managing device might only receive summary data regarding a managed device's state because a link or path is constrained by capacity or reliability.
管理デバイスは、リンクまたはパスが容量または信頼性によって制約されるため、管理されたデバイスの状態に関する略式データのみを受信する場合があります。
Bulk Historical Reporting:
一括歴史的報告：
A managing device receives a large volume of historical report data for a managed device. This can occur when a managed device rejoins a network or has temporary access to a high-capacity link (or path) between itself and the managing device.
管理デバイスは、管理されたデバイスの大量の履歴レポートデータを受信します。これは、管理されたデバイスがネットワークに再加入したり、それ自体と管理デバイスの間の大容量リンク（またはパス）に一時的にアクセスできる場合に発生する可能性があります。
Multiple Managers:
複数のマネージャー：
A managed device tracks multiple managers in the network and communicates with them as a function of time, local state, or network topology. This scenario would also apply to challenged networks that interconnect two or more unchallenged networks such that managed and managing devices exist in different networks.
マネージドデバイスは、ネットワーク内の複数のマネージャーを追跡し、時間、地方の状態、またはネットワークトポロジの関数としてそれらと通信します。このシナリオは、異なるネットワークにデバイスの管理と管理デバイスが存在するように、2つ以上の挑戦的なネットワークを相互接続する挑戦されたネットワークにも適用されます。
These special cases highlight the need for managed devices to operate without presupposing a dedicated connection to a single managing device. Managing devices in a challenged network might never expect a reply to a command, and communications from managed devices may be delivered much later than the events being reported.
これらの特別なケースは、単一の管理デバイスへの専用の接続を前提とすることなく、管理されたデバイスが動作する必要性を強調しています。挑戦されたネットワークでデバイスを管理することは、コマンドへの返信を期待することは決してなく、管理されたデバイスからの通信は、報告されているイベントよりもはるかに遅れて配信される場合があります。
This section describes those design properties that are desirable when defining a management architecture operating across challenged links in a network. These properties ensure that network management capabilities are retained even as delays and disruptions in the network scale. Ultimately, these properties are the driving design principles for the DTNMA.
このセクションでは、ネットワーク内の課題のあるリンク全体で動作する管理アーキテクチャを定義する際に望ましい設計プロパティについて説明します。これらのプロパティは、ネットワークスケールの遅延と中断としてもネットワーク管理機能が保持されることを保証します。最終的に、これらのプロパティは、DTNMAの運転設計原則です。
NOTE: These properties may influence the design, construction, and adaptation of existing management tools for use in challenged networks. For example, the properties of the DTN architecture [RFC4838] resulted in the development of BPv7 [RFC9171] and BPSec [RFC9172]. Implementing the DTNMA model may result in the construction of new management data models, policy expressions, and/or protocols.
注：これらのプロパティは、課題のあるネットワークで使用するための既存の管理ツールの設計、構造、および適応に影響を与える可能性があります。たとえば、DTNアーキテクチャ[RFC4838]の特性により、BPV7 [RFC9171]およびBPSEC [RFC9172]が発生しました。DTNMAモデルを実装すると、新しい管理データモデル、ポリシー式、および/またはプロトコルが構築される場合があります。
The DTNMA should be agnostic to the underlying physical topology, transport protocols, security solutions, and supporting infrastructure of a given network. Due to the likelihood of operating in a frequently partitioned environment, the topology of a network may change over time. Attempts to stabilize an architecture around individual nodes can result in a brittle management framework and the creation of congestion points during periods of connectivity.
DTNMAは、基礎となる物理的トポロジ、輸送プロトコル、セキュリティソリューション、および特定のネットワークのインフラストラクチャのサポートに不可知論される必要があります。頻繁に分割された環境で動作する可能性があるため、ネットワークのトポロジーは時間とともに変化する可能性があります。個々のノードの周りのアーキテクチャを安定させようとすると、接続の期間中に脆性管理フレームワークと輻輳ポイントの作成が生じる可能性があります。
The DTNMA should not prescribe any association between a DM and a DA other than those defined in this document. There should be no logical limitation on the number of DMs that can control a DA, the number of DMs that a DA should report to, or any requirement that a DM and DA relationship imply a pair.
DTNMAは、このドキュメントで定義されているもの以外のDMとDAの間の関連付けを規定すべきではありません。DAを制御できるDMの数、DAが報告すべきDMの数、またはDMとDAの関係がペアを意味するという要件には、論理的な制限はないはずです。
NOTE: Practical limitations on the relationships between and amongst DMs and DAs will exist as a function of the capabilities of networked devices. These limitations derive from processing and storage constraints, performance requirements, and other engineering factors. Implementors of managed and managing devices must account for these limitations in their device designs.
注：DMSとDAS間の関係に関する実際の制限は、ネットワークデバイスの機能の関数として存在します。これらの制限は、処理とストレージの制約、パフォーマンス要件、およびその他のエンジニアリング要因に由来します。マネージドデバイスとマネージングデバイスの実装者は、デバイスの設計におけるこれらの制限を考慮する必要があります。
The DTNMA should use data models to define the syntactic and semantic contracts for data exchange between a DA and a DM. A given model should have the ability to "inherit" the contents of other models to form hierarchical data relationships.
DTNMAは、データモデルを使用して、DAとDMの間のデータ交換のための構文契約とセマンティック契約を定義する必要があります。特定のモデルには、他のモデルの内容を「継承」して階層データ関係を形成する機能を備えている必要があります。
NOTE: The term "data model" in this context refers to a schema that defines a contract between a DA and a DM regarding how information is represented and validated.
注：「データモデル」という用語は、情報の表現方法と検証方法に関するDAとDMの間の契約を定義するスキーマを指します。
Many network management solutions use data models to specify the semantic and syntactic representation of data exchanged between managed and managing devices. The DTNMA is not different in this regard; information exchanged between DAs and DMs should conform to one or more predefined, normative data models.
多くのネットワーク管理ソリューションは、データモデルを使用して、マネージドデバイスと管理デバイスの間で交換されるデータのセマンティックおよび構文表現を指定しています。この点でDTNMAは違いはありません。DASとDMの間で交換される情報は、1つ以上の事前定義された規範的データモデルに適合する必要があります。
A common best practice when defining a data model is to make it cohesive. A cohesive model is one that includes information related to a single purpose such as managing a single application or protocol. When applying this practice, it is not uncommon to develop a large number of small data models that, together, describe the information needed to manage a device.
データモデルを定義するときの一般的なベストプラクティスは、それをまとまりのあるものにすることです。まとまりのあるモデルとは、単一のアプリケーションまたはプロトコルの管理など、単一の目的に関連する情報を含むモデルです。このプラクティスを適用する場合、デバイスの管理に必要な情報を一緒に説明する多数の小さなデータモデルを開発することは珍しくありません。
Another best practice for data model development is the use of inclusion mechanisms to allow one data model to include information from another data model. This ability to include a data model avoids repeating information in different data models. When one data model includes information from another data model, there is an implied model hierarchy.
データモデル開発のもう1つのベストプラクティスは、インクルージョンメカニズムを使用して、あるデータモデルが別のデータモデルからの情報を含めることを可能にすることです。データモデルを含めるこの機能により、さまざまなデータモデルで情報が繰り返されないようになります。あるデータモデルに別のデータモデルからの情報が含まれている場合、暗黙のモデル階層があります。
Data models in the DTNMA should allow for the construction of both cohesive models and hierarchically related models. These data models should be used to define all sources of information that can be retrieved, configured, or executed in the DTNMA. These actions would include supporting DA autonomy functions such as parameterization, filtering, and event-driven behaviors. These models will be used to both implement interoperable autonomy engines on DAs and define interoperable report parsing mechanisms on DMs.
DTNMAのデータモデルは、まとまりのあるモデルと階層的に関連するモデルの両方の構築を可能にする必要があります。これらのデータモデルは、DTNMAで取得、構成、または実行できるすべての情報ソースを定義するために使用する必要があります。これらのアクションには、パラメーター化、フィルタリング、イベント駆動型の動作などのDA自律機能のサポートが含まれます。これらのモデルは、DASに相互運用可能な自律エンジンを実装し、DMSの相互運用可能なレポート解析メカニズムを定義するために使用されます。
NOTE: While data model hierarchies can result in a more concise data model, arbitrarily complex nesting schemes can also result in very verbose encodings. Where possible, data identification schemes should be constructed that allow for both hierarchical data and highly compressible data identification.
注：データモデルの階層はより簡潔なデータモデルをもたらす可能性がありますが、任意に複雑なネストスキームは非常に冗長なエンコーディングをもたらす可能性があります。可能であれば、階層データと非常に圧縮可能なデータ識別の両方を可能にするデータ識別スキームを構築する必要があります。
DAs in the DTNMA should determine when to push information to DMs as a function of their local state.
DTNMAのDASは、地方の国家の関数としてDMSに情報をいつプッシュするかを決定する必要があります。
"Pull" management mechanisms require a managing device to send a query to a managed device and then wait for a response to that specific query. This practice implies some knowledge synchronization between entities (which may be as simple as knowing when a managed device might be powered). However, challenged networks cannot guarantee timely round-trip data exchange. For this reason, pull mechanisms should be avoided in the DTNMA.
「プル」管理メカニズムには、管理されたデバイスにクエリを送信し、その特定のクエリへの応答を待つために管理デバイスが必要です。このプラクティスは、エンティティ間の知識の同期を意味します（これは、管理されたデバイスがいつ電力を供給されるかを知るのと同じくらい簡単かもしれません）。ただし、挑戦されたネットワークは、タイムリーな往復データ交換を保証することはできません。このため、DTNMAではプルメカニズムを避ける必要があります。
"Push" mechanisms, in this context, indicate the ability of DAs to leverage local autonomy to determine when and what information should be sent to which DMs. The push is considered adaptive because a DA determines what information to push (and when) as an adaptation to changes to the DA's internal state. Once pushed, information might still be queued, pending connectivity of the DA to the network.
このコンテキストでは、「プッシュ」メカニズムは、DASが現地の自律性を活用して、どの情報をDMに送信するかを決定する能力を示しています。DAは、DAの内部状態の変更への適応としてどのような情報を押す（そしていつ）プッシュするかを決定するため、プッシュは適応型と見なされます。プッシュされると、DAのネットワークへの接続が保留されている場合、情報が依然としてキューになっている可能性があります。
Even in cases where a round-trip exchange can occur, pull mechanisms increase the overall amount of traffic in the network and preclude the use of autonomy at managed devices. So, even when pull mechanisms are feasible, they should not be considered a pragmatic alternative to push mechanisms.
往復交換が発生する場合でも、プルメカニズムはネットワーク内のトラフィック全体を増やし、管理されたデバイスでの自律性の使用を妨げます。したがって、プルメカニズムが実現可能であっても、プッシュメカニズムの実用的な代替品と見なされるべきではありません。
Messages exchanged between a DA and a DM in the DTNMA should be defined in a way that allows for efficient on-the-wire encoding. DTNMA design decisions that result in smaller message sizes should be preferred over those that result in larger message sizes.
DTNMAでDAとDMの間で交換されるメッセージは、効率的なオンザワイヤエンコーディングを可能にする方法で定義する必要があります。メッセージサイズが大きい場合よりも、メッセージサイズが大きい場合よりも、メッセージサイズが大きくなるDTNMA設計の決定が優先される必要があります。
There is a relationship between message encoding and message processing time at a node. Messages with few or no encodings may simplify node processing, whereas more compact encodings may require additional activities to generate/parse encoded messages. Generally, compressing a message takes processing time at the sender and decompressing a message takes processing time at a receiver. Therefore, there is a design trade-off between minimizing message sizes and minimizing node processing.
ノードでのメッセージエンコード時間とメッセージ処理時間の間には関係があります。エンコーディングが少ない、またはまったくないメッセージは、ノード処理を簡素化する場合がありますが、コンパクトなエンコーディングが増えると、エンコードされたメッセージを生成/解析するために追加のアクティビティが必要になる場合があります。一般に、メッセージを圧縮するには、送信者での処理時間がかかり、メッセージを減圧すると、受信者での処理時間がかかります。したがって、メッセージサイズを最小化することとノード処理の最小化との間には、設計トレードオフがあります。
There is a significant advantage to smaller DTNMA message sizes in a challenged network. Smaller messages require shorter periods of viable transmission for communication, they incur less retransmission cost, and they consume fewer resources when persistently stored en route in the network.
挑戦されたネットワークでは、より小さなDTNMAメッセージサイズに大きな利点があります。小さなメッセージには、通信のために実行可能な送信の期間が短くなり、再送信コストが少なくなり、ネットワークに途中で保存されている場合、リソースを消費するリソースが少なくなります。
NOTE: Naive approaches to minimizing message size through general-purpose compression algorithms do not produce minimal encodings. Data models can, and should, be designed for compact encoding from the beginning. Design strategies for compact encodings involve using structured data, hierarchical data models, and common substructures within data models. These strategies allow for compressibility beyond what would otherwise be achieved by computing large hash values over generalized data structures.
注：汎用圧縮アルゴリズムを介してメッセージサイズを最小化するための素朴なアプローチは、最小限のエンコーディングを生成しません。データモデルは、最初からコンパクトエンコード用に設計することができます。コンパクトエンコーディングの設計戦略には、構造化されたデータ、階層データモデル、およびデータモデル内の一般的な下部構造の使用が含まれます。これらの戦略により、一般化されたデータ構造よりも大きなハッシュ値を計算することによって達成されるものを超えて圧縮性が可能になります。
Data elements within the DTNMA should be uniquely identifiable so that they can be individually manipulated. Further, these identifiers should be universal -- the identifier for a data element should be the same, regardless of role, implementation, or network instance.
DTNMA内のデータ要素は、個別に操作できるように一意に識別できる必要があります。さらに、これらの識別子は普遍的である必要があります。データ要素の識別子は、役割、実装、またはネットワークインスタンスに関係なく、同じでなければなりません。
Identification schemes that would be relative to a specific DA or specific system configuration might change over time and should be avoided. Relying on relative identification schemes would require resynchronizing relative state when nodes in a challenged network reconnect after periods of partition. This type of resynchronization should be avoided whenever possible.
特定のDAまたは特定のシステム構成に関連する識別スキームは、時間とともに変化する可能性があり、避ける必要があります。相対識別スキームに依存するには、パーティションの期間後に挑戦されたネットワークのノードが再接続する場合、相対状態を再同期させる必要があります。このタイプの再同期は、可能な限り回避する必要があります。
NOTE: Consider a common management technique for approximating an associative array lookup. If a managed device tracks the number of bytes passed by multiple named interfaces, then the number of bytes through a specific named interface ("int_foo") would be retrieved in the following way:
注：連想配列の検索を近似するための一般的な管理手法を検討してください。マネージドデバイスが複数の名前付きインターフェイスで渡されるバイト数を追跡する場合、特定の名前のインターフェイス（「int_foo "）を介したバイト数が次の方法で取得されます。
1. Query a list of ordered interface names from an agent.
1. エージェントからの順序付けられたインターフェイス名のリストをクエリします。
2. Find the name that matches "int_foo", and infer the agent's index of "int_foo" from the ordered interface list. In this instance, assume that "int_foo" is the fourth interface in the list.
2. 「int_foo」に一致する名前を見つけ、順序付けられたインターフェイスリストからエージェントの「int_foo」のインデックスを推測します。この例では、「int_foo」がリスト内の4番目のインターフェイスであると仮定します。
3. Query the agent (again) to now return the number of bytes passed through the fourth interface.
3. エージェントをクエリして（もう一度）、4番目のインターフェイスを通過したバイト数を返します。
Ignoring the inefficiency of two round-trip exchanges, this mechanism will fail if an agent implementation changes its index mapping between the first and second queries.
2つの往復交換の非効率性を無視すると、エージェントの実装が最初のクエリと2番目のクエリ間でインデックスマッピングを変更すると、このメカニズムが失敗します。
The desired data being queried, "number of bytes through 'int_foo'", should be uniquely and universally identifiable and independent of how that data exists in any agent's custom implementation.
「 'int_foo'」を介した「バイト数」「バイト数」が照会された目的のデータは、エージェントのカスタム実装にそのデータが存在する方法と一意に普遍的に識別可能である必要があります。
The DTNMA allows for the addition of new data elements to a data model as part of the runtime operation of the management system. These definitions may represent custom data definitions that are applicable only for a particular device or network. Custom definitions should also be able to be removed from the system during runtime.
DTNMAは、管理システムのランタイム操作の一部として、データモデルに新しいデータ要素を追加することを可能にします。これらの定義は、特定のデバイスまたはネットワークにのみ適用されるカスタムデータ定義を表している場合があります。カスタム定義は、ランタイム中にシステムから削除できる必要があります。
The goal of this approach is to dynamically add or remove data elements to the local runtime schemas as needed, such as the definition of new counters, new reports, or new rules.
このアプローチの目標は、新しいカウンター、新しいレポート、新しいルールの定義など、必要に応じてローカルランタイムスキーマにデータ要素を動的に追加または削除することです。
The custom definition of new data from existing data (such as through data fusion, averaging, sampling, or other mechanisms) provides the ability to communicate desired information in as compact a form as possible.
既存のデータからの新しいデータのカスタム定義（データの融合、平均化、サンプリング、その他のメカニズムなど）は、可能な限りコンパクトなフォームとして望ましい情報を通知する機能を提供します。
NOTE: A DM could, for example, define a custom data report that includes only summary information about a specific operational event or as part of specific debugging. DAs could then produce this smaller report until it is no longer necessary, at which point the custom report could be removed from the management system.
注：たとえば、DMは、特定の運用イベントに関する要約情報のみを含むカスタムデータレポートまたは特定のデバッグの一部として定義できます。その後、DASはこの小さなレポートを必要としなくなるまで作成できます。その時点で、カスタムレポートを管理システムから削除できます。
Custom data elements should be calculated and used both as parameters for DA autonomy and for more efficient reporting to DMs. Defining new data elements allows for DAs to perform local data fusion, and defining new reporting templates allows for DMs to specify desired formats and generally save on link capacity, storage, and processing time.
カスタムデータ要素を計算し、DAの自律性のパラメーターとして、およびDMSへのより効率的なレポートの両方として使用する必要があります。新しいデータ要素を定義することで、DASがローカルデータフュージョンを実行でき、新しいレポートテンプレートを定義することで、DMが目的の形式を指定し、一般にリンク容量、ストレージ、および処理時間を節約できます。
The management of applications by a DA should be achievable using only knowledge local to the DA because DAs might need to operate during times when they are disconnected from a DM.
DAがDMから切断されたときに操作する必要があるため、DAによるアプリケーションの管理は、DAにローカルローカルの知識のみを使用して達成できる必要があります。
DA autonomy may be used for simple automation of predefined tasks or to support semi-autonomous behavior in determining when to run tasks and how to configure or parameterize tasks when they are run.
DAの自律性は、事前定義されたタスクの単純な自動化や、タスクを実行するタイミングと実行時にタスクを構成またはパラメーター化する方法を決定する際の半自律的な動作をサポートするために使用できます。
Important features provided by the DA are listed below. These features work together to accomplish tasks. As such, there is commonality amongst their definitions and nature of their benefits.
DAが提供する重要な機能を以下に示します。これらの機能は、タスクを達成するために協力します。そのため、彼らの定義と彼らの利益の性質には共通性があります。
Standalone Operation:
スタンドアロン操作：
Preconfiguration allows DAs to operate without regular contact with other nodes in the network. Updates for configurations remain difficult in a challenged network, but this approach removes the requirement that a DM be in the loop during regular operations. Preconfiguring stimuli and responses on a DA during periods of connectivity allows DAs to self-manage during periods of disconnectivity.
事前設定により、DASはネットワーク内の他のノードと定期的に接触することなく動作できます。チャレンジネットワークでは、構成の更新は依然として困難ですが、このアプローチは、通常の操作中にDMがループ内にあるという要件を削除します。接続の期間中のDAでの刺激と応答を事前に構成することにより、DASは切断された期間中に自己管理を可能にします。
Deterministic Behavior:
決定論的行動：
Operational systems might need to act in a deterministic way, even in the absence of an operator in the loop. Deterministic behavior allows an out-of-contact DM to predict the state of a DA and to determine how a DA got into a particular state.
ループにオペレーターがいない場合でも、運用システムは決定論的な方法で行動する必要があるかもしれません。決定論的な動作により、コンタクト外のDMがDAの状態を予測し、DAが特定の状態にどのように入ったかを判断することができます。
Engine-Based Behavior:
エンジンベースの動作：
Operational systems might not be able to deploy "mobile code" solutions [RFC4949] due to network bandwidth, memory or processor loading, or security concerns. Engine-based approaches provide configurable behavior without incurring these concerns.
ネットワーク帯域幅、メモリまたはプロセッサの読み込み、またはセキュリティの懸念により、運用システムは「モバイルコード」ソリューション[RFC4949]を展開できない場合があります。エンジンベースのアプローチは、これらの懸念を負うことなく、構成可能な動作を提供します。
Authorization and Accounting:
承認と会計：
The DTNMA does not require a specific underlying transport protocol, a specific network infrastructure, or specific network services. Therefore, mechanisms for authorization and accounting need to be present in a standard way at DAs and DMs to provide these functions if the underlying network does not. This is particularly true in cases where multiple DMs may be active concurrently in the network.
DTNMAは、特定の基礎となる輸送プロトコル、特定のネットワークインフラストラクチャ、または特定のネットワークサービスを必要としません。したがって、承認と会計のメカニズムは、基礎となるネットワークがそうでない場合、これらの機能を提供するために、DASおよびDMSに標準的な方法で存在する必要があります。これは、複数のDMがネットワークで同時にアクティブになっている場合に特に当てはまります。
To understand the contributions of these features to a common type of behavior, consider the example of a managed device coming online with a set of preinstalled configurations. In this case, the device's standalone operation comes from the preconfiguration of its local autonomy engine. This engine-based behavior allows the system to behave in a deterministic way, and any new configurations will need to be authorized before being adopted.
これらの機能が一般的なタイプの動作に貢献していることを理解するには、プリインストールされた構成のセットを備えたオンラインで管理されているデバイスの例を考えてください。この場合、デバイスのスタンドアロン操作は、ローカル自律エンジンの事前構成から来ています。このエンジンベースの動作により、システムは決定論的な方法で動作することができ、採用される前に新しい構成を許可する必要があります。
Features such as deterministic processing and engine-based behavior are separate from (but do not preclude the use of) other Artificial Intelligence (AI) and Machine Learning (ML) approaches for device management.
決定論的処理やエンジンベースの動作などの機能は、デバイス管理のために他の人工知能（AI）および機械学習（ML）アプローチとは別に（ただし、使用を妨げない）。
Several remote management solutions have been developed for both local area networks and wide area networks. Their capabilities range from simple configuration and report generation to complex modeling of device settings, state, and behavior. All of these approaches are successful in the domains for which they have been built but are not all equally functional when deployed in a challenged network.
ローカルエリアネットワークと広いエリアネットワークの両方に対して、いくつかのリモート管理ソリューションが開発されています。それらの機能は、単純な構成とレポート生成から、デバイス設定、状態、および動作の複雑なモデリングにまで及びます。これらのアプローチはすべて、それらが構築されたドメインで成功していますが、挑戦されたネットワークに展開されたときにすべて等しく機能しているわけではありません。
This section describes some of the well-known protocols for remote management and contrasts their purposes with the desirable properties of the DTNMA. The purpose of this comparison is to identify parts of existing approaches that can be adopted or adapted for use in challenged networks and where new capabilities should be created specifically for such environments.
このセクションでは、リモート管理のためのよく知られたプロトコルのいくつかについて説明し、DTNMAの望ましい特性とそれらの目的を対比します。この比較の目的は、挑戦されたネットワークで使用するために採用または適応できる既存のアプローチの一部を識別し、そのような環境に特に新しい機能を作成する必要がある場合です。
An early and widely used example of a remote management protocol is SNMP, which is currently at version 3 [RFC3410]. SNMP utilizes a request-response model to get and set data values within an arbitrarily deep object hierarchy. Objects are used to identify data such as host identifiers, link utilization metrics, error rates, and counters between application software on managing and managed devices [RFC3411]. Additionally, SNMP supports a model for unidirectional push messages, called event notifications, based on agent-defined triggering events.
リモート管理プロトコルの初期に広く使用されている例はSNMPで、現在バージョン3 [RFC3410]です。SNMPは、リクエスト応答モデルを使用して、任意の深いオブジェクト階層内でデータ値を取得および設定します。オブジェクトは、ホスト識別子、リンク使用率のメトリック、エラー率、およびマネージャーと管理されたデバイスのアプリケーションソフトウェア間のカウンター[RFC3411]などのデータを識別するために使用されます。さらに、SNMPは、エージェント定義のトリガーイベントに基づいて、イベント通知と呼ばれる単方向プッシュメッセージのモデルをサポートしています。
SNMP relies on logical sessions with predictable round-trip latency to support its pull mechanism, but a single activity is likely to require many round-trip exchanges. Complex management can be achieved, but only through careful orchestration of real-time, end-to-end, managing-device-generated query-and-response logic.
SNMPは、プルメカニズムをサポートするために予測可能な往復遅延を備えた論理セッションに依存していますが、単一のアクティビティでは多くの往復交換が必要になる可能性があります。複雑な管理を達成することができますが、リアルタイム、エンドツーエンド、マネージングデバイスで生成されたクエリと応答ロジックの慎重なオーケストレーションによってのみ達成できます。
There is existing work that uses the SNMP data model to support some low-fidelity agent-side processing; this work includes using "Distributed Management Expression MIB" [RFC2982] and "Definitions of Managed Objects for the Delegation of Management Scripts" [RFC3165]. However, agent autonomy is not an SNMP mechanism, so support for a local agent response to an initiating event is limited. In a challenged network where the delay between a managing device receiving an alert and sending a response can be significant, SNMP is insufficient for autonomous event handling.
SNMPデータモデルを使用して、忠実度の低いエージェント側の処理をサポートする既存の作業があります。この作業には、「分散管理式MIB」[RFC2982]および「管理スクリプトの委任のための管理されたオブジェクトの定義」[RFC3165]の使用が含まれます。ただし、エージェントの自律性はSNMPメカニズムではないため、開始イベントに対するローカルエージェント応答のサポートは限られています。アラートを受信して応答を送信する管理デバイス間の遅延が重要な場合がある挑戦されたネットワークでは、SNMPは自律イベントの取り扱いには不十分です。
SNMP separates the representations for managed data models from messaging, sequencing, and encoding between managers and agents. Each data model is termed a "Management Information Base" (or "MIB") [RFC3418] and uses the Structure of Management Information (SMI) modeling language [RFC2578]. Additionally, the SMI itself is based on the ASN.1 syntax [ASN.1], which is used not just for SMI but for other, unrelated data structure specifications such as the Cryptographic Message Syntax (CMS) [RFC5652]. Separating data models from messaging and encoding is a best practice in remote management protocols and is also necessary for the DTNMA.
SNMPは、マネージャーとエージェントの間のメッセージング、シーケンス、エンコードから管理されたデータモデルの表現を分離します。各データモデルは、「管理情報ベース」（または「MIB」）[RFC3418]と呼ばれ、管理情報（SMI）モデリング言語[RFC2578]の構造を使用します。さらに、SMI自体はASN.1構文[ASN.1]に基づいています。これは、SMIだけでなく、暗号化メッセージ構文（CMS）[RFC5652]などの他の無関係なデータ構造仕様に使用されます。データモデルをメッセージングとエンコードから分離することは、リモート管理プロトコルのベストプラクティスであり、DTNMAにも必要です。
Each SNMP MIB is composed of managed object definitions, each of which is associated with a hierarchical Object Identifier (OID). Because of the arbitrarily deep nature of MIB object trees, the size of OIDs is not strictly bounded by the protocol (though it may be bounded by implementations).
各SNMP MIBは管理されたオブジェクト定義で構成されており、それぞれが階層オブジェクト識別子（OID）に関連付けられています。MIBオブジェクトツリーの任意の深い性質のため、OIDのサイズはプロトコルによって厳密に制限されていません（ただし、実装によって制限される場合があります）。
SNMPv2 [RFC3416] [RFC3417] and SNMPv3 [RFC3414] can operate over a variety of transports, including plaintext UDP/IP [RFC3417], SSH/TCP/ IP [RFC5592], and DTLS/UDP/IP or TLS/TCP/IP [RFC6353].
SNMPV2 [RFC3416] [RFC3417]およびSnmpv3 [RFC3414]は、Plantext UDP/IP [RFC3417]、SSH/TCP/IP [RFC5592]、DTLS/UDP/IPまたはTLS/TCP/を含むさまざまな輸送で動作できます。[RFC6353]。
SNMP uses an abstracted security model to provide authentication, integrity, and confidentiality. There are options for the User-based Security Model (USM) [RFC3414], which uses in-message security, and the Transport Security Model (TSM) [RFC5591], which relies on the transport to provide security functions and interfaces.
SNMPは、抽象化されたセキュリティモデルを使用して、認証、完全性、および機密性を提供します。ユーザーベースのセキュリティモデル（USM）[RFC3414]には、セキュリティおよびインターフェイスを提供するためにトランスポートに依存するトランスポートセキュリティモデル（TSM）[RFC5591] [RFC3414]にはオプションがあります。
Several network management protocols, including NETCONF [RFC6241], RESTCONF [RFC8040], and the Constrained Application Protocol (CoAP) Management Interface (CORECONF) [CORE-COMI], share the same XML Information Set [xml-infoset] for the information set's hierarchical managed information and XPath expressions [XPath] to identify nodes of that information model. Since they share the same information model and the same data manipulation operations, together they will be referred to as "*CONF" protocols. Each protocol, however, provides a different encoding of that information set and its related operation-specific data.
NetConf [RFC6241]、RestConf [RFC8040]、および制約付きアプリケーションプロトコル（COAP）管理インターフェイス（CoreCONF）[Core-Comi]を含むいくつかのネットワーク管理プロトコルは、情報セットの同じXML情報セット[XML-Infoset]を共有します。その情報モデルのノードを識別するための階層的な管理情報とXPath式[XPath]。彼らは同じ情報モデルと同じデータ操作操作を共有するため、一緒に「*conf」プロトコルと呼ばれます。ただし、各プロトコルは、その情報セットとその関連する操作固有のデータの異なるエンコードを提供します。
The YANG modeling language as defined in [RFC7950] is used to define the data model for these management protocols. Currently, YANG represents the IETF standard for defining managed information models.
[RFC7950]で定義されているYangモデリング言語は、これらの管理プロトコルのデータモデルを定義するために使用されます。現在、Yangは、管理された情報モデルを定義するためのIETF標準を表しています。
The YANG modeling language defines a syntax and modular semantics for organizing and accessing a device's configuration or operational information. YANG allows subdividing a full managed configuration into separate namespaces defined by separate YANG modules. Once a module is developed, it is used (directly or indirectly) on both the client and server to serve as a contract between the two. A YANG module can be complex, describing a deeply nested and interrelated set of data nodes, actions, and notifications.
Yangモデリング言語は、デバイスの構成または運用情報を整理およびアクセスするための構文とモジュラーセマンティクスを定義します。Yangを使用すると、完全な管理された構成を個別のYangモジュールで定義された個別の名前空間に細分化できます。モジュールが開発されると、クライアントとサーバーの両方で（直接的または間接的に）使用され、2つの間の契約として使用されます。Yangモジュールは複雑であり、深くネストされた相互に関連したデータノード、アクション、および通知を記述します。
Unlike the separation between ASN.1 syntax and module semantics from higher-level SMI data model semantics as discussed in Section 5.1.1, YANG defines both a text syntax and module semantics together with data model semantics.
セクション5.1.1で説明した高レベルのSMIデータモデルセマンティクスからのASN.1の構文とモジュールのセマンティクスの分離とは異なり、Yangはテキストの構文とモジュールのセマンティクスの両方をデータモデルセマンティクスとともに定義します。
The YANG modeling language provides flexibility in the organization of model objects to the model developer. YANG supports a broad range of data types as noted in [RFC6991]. YANG also supports the definition of parameterized Remote Procedure Calls (RPCs) and actions to be executed on managed devices as well as the definition of event notifications within the model.
Yang Modeling Languageは、モデルオブジェクトの組織化にモデル開発者に柔軟性を提供します。Yangは、[RFC6991]に記載されている幅広いデータ型をサポートしています。Yangは、パラメーター化されたリモートプロシージャコール（RPC）の定義と、マネージドデバイスで実行されるアクション、およびモデル内のイベント通知の定義もサポートしています。
Current *CONF notification logic allows a client to subscribe to the delivery of specific containers or data nodes defined in the model, on either a periodic or "on-change" basis [RFC8641]. These notification events can be filtered according to XPath or subtree filtering [XPath] [RFC6241] as described in Section 2.2 of [RFC8639].
現在 *conf化通知ロジックにより、クライアントは、周期または「変更」ベース[RFC8641]で、モデルで定義された特定のコンテナまたはデータノードの配信をサブスクライブできます。これらの通知イベントは、[RFC8639]のセクション2.2で説明されているように、XPathまたはサブツリーフィルタリング[XPath] [RFC6241]に従ってフィルタリングできます。
The use of YANG for data modeling necessarily comes with some side effects, some of which are described here.
データモデリングにYangを使用するには、必然的に副作用が必要であり、その一部はここで説明されています。
Text Naming:
テキストの命名：
Data nodes, RPCs, and notifications within a YANG data model are named by a namespace-qualified, text-based path of the module, submodule, container, and any data nodes such as lists, leaf-lists, or leaves, without any explicit hierarchical organization based on data or object type.
Yangデータモデル内のデータノード、RPC、および通知は、モジュール、サブモジュール、コンテナの名前空間認定パス、およびリスト、葉のリスト、葉などのデータノードによって、明示的な明示的なものなしで名前が付けられています。データまたはオブジェクトタイプに基づく階層組織。
Existing efforts to make compressed names for YANG objects, such as the YANG Schema Item iDentifiers (SIDs) as discussed in Section 3.2 of [RFC9254], allow a node to be named by a globally unique integer value but are still relatively verbose (up to 8 bytes per item) and still must be translated into text form for things like instance identification (see below). Additionally, when representing a tree of named instances, the child elements can use differential encoding of SID integer values as "delta" integers. The mechanisms for assigning SIDs and the lifecycle of those SIDs are discussed in [RFC9595].
[RFC9254]のセクション3.2で説明したヤンスキーマアイテム識別子（SIDS）など、Yangオブジェクトの圧縮名を作成するための既存の取り組みは、グローバルに一意の整数値によってノードを命名しますが、まだ比較的冗長です（アイテムごとに8バイト）、インスタンス識別などのもののためにテキストフォームに翻訳する必要があります（以下を参照）。さらに、名前付きインスタンスのツリーを表す場合、子要素はsid整数値の微分エンコードを「デルタ」整数として使用できます。SIDを割り当てるためのメカニズムとそれらのSIDのライフサイクルについては、[RFC9595]で説明されています。
Text Values and Built-In Types:
テキスト値と組み込みタイプ：
Because the original use of YANG with NETCONF was to model XML Information Sets, the values and built-in types are necessarily text based. JSON encoding of YANG data [RFC7951] allows for optimized representations of many built-in types; similarly, Concise Binary Object Representation (CBOR) encoding [RFC9254] allows for different optimized representations.
Yangを使用したYangの当初の使用はXML情報セットをモデル化することであるため、値と組み込みタイプは必然的にテキストベースです。Yang Data [RFC7951]のJSONエンコードにより、多くの組み込みタイプの最適化された表現が可能になります。同様に、[RFC9254]をエンコードする簡潔なバイナリオブジェクト表現（CBOR）により、最適化された異なる表現が可能になります。
In particular, the YANG built-in types support a fixed range of decimal fractions (Section 9.3 of [RFC7950]) but purposefully do not support floating-point numbers. There are alternatives, such as the type bandwidth-ieee-float32 [RFC8294] or using the "binary" type with one of the IEEE-754 encodings.
特に、Yangの組み込みタイプは、固定範囲の小数画分（[RFC7950]のセクション9.3）をサポートしていますが、意図的に浮動小数点数をサポートしていません。型帯域幅-ieee-float32 [RFC8294]などの代替案があり、IEEE-754エンコーディングのいずれかを備えた「バイナリ」タイプを使用しています。
Deep Hierarchy:
深い階層：
YANG allows for, and current YANG modules take advantage of, the ability to deeply nest a model hierarchy to represent complex combinations and compositions of data nodes. When a model uses a deep hierarchy of nodes, this necessarily means that the qualified paths to name those nodes and instances are longer than they would be in a flat namespace.
Yangは、モデルの階層を深くネストして、データノードの複雑な組み合わせを表す能力を可能にし、現在のYangモジュールを利用します。モデルがノードの深い階層を使用する場合、これは必然的に、それらのノードを名前を付ける適格なパスがフラットネームスペースにあるよりも長いことを意味します。
Instance Identification:
インスタンス識別：
The node instances in a YANG module necessarily use XPath expressions for identification. Some identification is constrained to be strictly within the YANG domain, such as "must", "when", "augment", or "deviation" statements. Other identification needs to be processed by a managed device -- for example, via the "instance-identifier" built-in type. This means that any implementation of a managed device must include XPath processing and related information model handling per Section 6.4 of [RFC7950] and its referenced documents.
Yangモジュールのノードインスタンスは、必然的に識別のためにXPath式を使用します。一部の識別は、「必須」、「いつ」、「拡張」、「逸脱」ステートメントなど、ヤンドメイン内に厳密に拘束されるように制約されています。その他の識別は、たとえば「Instance-Identifier」組み込み型を介して、管理されたデバイスによって処理する必要があります。これは、管理されたデバイスの実装には、[RFC7950]のセクション6.4およびその参照ドキュメントごとのXPath処理および関連情報モデルの処理を含める必要があることを意味します。
Protocol Coupling:
プロトコルカップリング：
A significant amount of existing YANG tooling or modeling presumes the use of YANG data within a management protocol with specific operations available. For example, the access control model defined in [RFC8341] relies on those operations specific to the *CONF protocols for proper behavior.
かなりの量の既存のYangツールまたはモデリングは、特定の操作が利用可能な管理プロトコル内でYangデータの使用を推測します。たとえば、[RFC8341]で定義されているアクセス制御モデルは、適切な動作のために *confプロトコルに固有の操作に依存しています。
The emergence of multiple NETCONF-derived protocols may make these presumptions less problematic in the future. Work to more consistently identify different types of YANG modules and their use has been undertaken to disambiguate how YANG modules should be treated [RFC8199].
複数のNetConf由来のプロトコルが出現すると、これらの推定が将来的に問題を減らす可能性があります。さまざまな種類のヤンモジュールをより一貫して特定する作業とその使用は、Yangモジュールをどのように扱うべきかを明確にするために行われています[RFC8199]。
Manager-Side Control:
マネージャー側のコントロール：
YANG RPCs and actions execute on a managed device and generate an expected, structured response. RPC execution is strictly limited to those issued by the manager. Commands are executed immediately and sequentially as they are received by the managed device, and there is no method to autonomously execute RPCs triggered by specific events or conditions.
Yang RPCとアクションは、管理されたデバイスで実行され、予想される構造化された応答を生成します。RPCの実行は、マネージャーが発行したものに厳密に制限されています。コマンドは、管理されたデバイスによって受信されたときにすぐに順番に実行され、特定のイベントまたは条件によってトリガーされるRPCを自律的に実行する方法はありません。
The YANG modeling language continues to evolve as new features are needed by adopting management protocols.
Yangモデリング言語は、管理プロトコルを採用することで新機能が必要であるため、進化し続けています。
NETCONF is a stateful, XML-encoding-based protocol that provides a syntax to retrieve, edit, copy, or delete any data nodes or exposed functionality on a server. It requires that underlying transport protocols support long-lived, reliable, low-latency, sequenced data delivery sessions. A bidirectional NETCONF session needs to be established before any data transfer (or notification) can occur.
NetConfは、サーバー上のデータノードまたは公開された機能を取得、編集、コピー、または削除する構文を提供するステートフルでXMLエンコードベースのプロトコルです。基礎となる輸送プロトコルは、長寿命の信頼性が高く、低遅延、シーケンスされたデータ配信セッションをサポートする必要があります。データ転送（または通知）が発生する前に、双方向NetConfセッションを確立する必要があります。
The XML exchanged within NETCONF messages is structured according to YANG modules supported by the NETCONF agent, and the data nodes reside within one of possibly many datastores in accordance with the Network Management Datastore Architecture (NMDA) [RFC8342].
NetConfメッセージ内で交換されたXMLは、NetConfエージェントがサポートするYangモジュールに従って構成されており、データノードは、ネットワーク管理データストアアーキテクチャ（NMDA）[RFC8342]に従って、おそらく多くのデータストアの1つに存在します。
NETCONF transports are required to provide authentication, data integrity, confidentiality, and replay protection. Currently, NETCONF can operate over SSH/TCP/IP [RFC6242] or TLS/TCP/IP [RFC7589].
認証、データの整合性、機密性、およびリプレイ保護を提供するには、NetConfトランスポートが必要です。現在、NetConfはSSH/TCP/IP [RFC6242]またはTLS/TCP/IP [RFC7589]を介して動作できます。
RESTCONF is a stateless, JSON-encoding-based protocol that provides the same operations as NETCONF, using the same YANG modules for structure and the same NMDA datastores, but using RESTful exchanges over HTTP. It uses HTTP methods to express its allowed operations: GET, POST, PUT, PATCH, or DELETE data nodes within a datastore.
RestConfは、構造と同じNMDAデータストアに同じYangモジュールを使用して、HTTPを介したRestful Exchangeを使用して、NetConfと同じ操作を提供するステートレスのJSONエンコードベースのプロトコルです。HTTPメソッドを使用して、データストア内のデータノードを取得、投稿、配置、パッチ、または削除する許可操作を表現します。
Although RESTCONF is a logically stateless protocol, it does rely on state within its transport protocol to achieve behaviors such as authentication and security sessions. Because RESTCONF uses the same data node semantics as NETCONF, a typical activity can involve the use of several sequential round trips of exchanges to first discover managed device state and then act upon it.
RestConfは論理的にステートレスプロトコルですが、認証やセキュリティセッションなどの動作を実現するために、輸送プロトコル内の状態に依存しています。RestConfはNetConfと同じデータノードセマンティクスを使用するため、典型的なアクティビティは、最初に管理されたデバイス状態を発見してから作用するために、いくつかの連続した丸い交換の使用を伴います。
CORECONF is an emerging stateless protocol built atop CoAP [RFC7252] that defines a messaging construct developed to operate specifically on constrained devices and networks by limiting message size and fragmentation. CoAP also implements a request-response system and methods for GET, POST, PUT, and DELETE.
CoreConfは、COAP [RFC7252]で構築された新たなステートレスプロトコルであり、メッセージのサイズと断片化を制限することにより、制約されたデバイスとネットワークを特別に動作させるために開発されたメッセージング構成を定義します。Coapは、リクエスト応答システムと、Get、Post、Put、および削除のための方法も実装しています。
Another emerging, but not IETF-affiliated, management protocol is the gRPC Network Management Interface (gNMI) [gNMI], which is based on gRPC messaging and uses Google protobuf data modeling.
IETFに関連していないもう1つの出現した管理プロトコルは、GRPCメッセージングに基づいてGoogle Protobufデータモデリングを使用しているGRPCネットワーク管理インターフェイス（GNMI）[GNMI]です。
The same limitations as those listed above for RESTCONF apply to gNMI because of its reliance on synchronous HTTP exchanges and TLS for normal operations, as well as the likely deep nesting of data schemas. gNMI is capable of transporting JSON-encoded YANG-modeled data, but how to compose such data is not yet fully standardized.
RestConfの上記の上記の制限と同じ制限は、通常の操作の同期HTTP交換とTLSに依存しているため、データスキーマの深いネスティングの可能性があるため、GNMIに適用されます。GNMIはJSONエンコードされたヤンモデルのデータを輸送することができますが、そのようなデータを作成する方法はまだ完全に標準化されていません。
The data managed and exchanged via gNMI is encoded and modeled using Google protobuf, an encoding and modeling syntax not affiliated with the IETF (although an attempt has been made and abandoned [PROTOCOL-BUFFERS]).
GNMIを介して管理および交換されたデータは、IETFと提携していないエンコードおよびモデリング構文であるGoogle ProtoBufを使用してエンコードおよびモデル化されます（ただし、試行が行われ、放棄されました[プロトコルバッファ]）。
Because the protobuf modeling syntax is a relatively low-level syntax (about the same as ASN.1 or CBOR), there are some efforts as part of the OpenConfig work [gNMI] to translate YANG modules into protobuf schemas (similar to translation to XML or JSON schemas for NETCONF and RESTCONF, respectively), but there is no required interoperability between management via gRPC or any of the *CONF protocols.
Protobufモデリング構文は比較的低レベルの構文であるため（asn.1またはcborとほぼ同じ）、openconfig作業の一部としていくつかの努力があります[GNMI]または、それぞれNetConfとRestConfのJSONスキーマ）が、GRPCまたは *confプロトコルを介した管理の間に必要な相互運用性はありません。
The message encoding and exchange for gNMI, as the name implies, is the gRPC protocol [gRPC]. gRPC exclusively uses HTTP/2 [RFC9113] for transport and relies on some aspects specific to HTTP/2 for its operations (such as HTTP trailer fields). While not mandated by gRPC, when used to transport gNMI data, TLS is required for transport security.
名前が示すように、GNMIのエンコードと交換はGRPCプロトコル[GRPC]です。GRPCは、輸送にHTTP/2 [RFC9113]のみを使用しており、その操作（HTTPトレーラーフィールドなど）にHTTP/2に固有のいくつかの側面に依存しています。GRPCによって義務付けられていませんが、GNMIデータの輸送に使用される場合、TLSは輸送セキュリティに必要です。
A lower-level remote management protocol, intended to be used to manage hardware devices and network appliances below the operating system (OS), is the Intelligent Platform Management Interface (IPMI), standardized in [IPMI]. The IPMI is focused on health monitoring, event logging, firmware management, and Serial over LAN (SOL) remote console access in a "pre-OS or OS-absent" host environment. The IPMI operates over a companion Remote Management Control Protocol (RMCP) for messaging, which itself can use UDP for transport.
オペレーティングシステム（OS）の下のハードウェアデバイスとネットワークアプライアンスを管理するために使用することを目的とした低レベルのリモート管理プロトコルは、[IPMI]に標準化されたインテリジェントなプラットフォーム管理インターフェイス（IPMI）です。IPMIは、ヘルスモニタリング、イベントロギング、ファームウェア管理、およびLAN（SOL）のリモートコンソールアクセスを「Pre-OSまたはOS-Absent」ホスト環境でのシリアルに焦点を当てています。IPMIは、メッセージング用にコンパニオンリモート管理コントロールプロトコル（RMCP）を操作します。これは、それ自体が輸送にUDPを使用できます。
Because the IPMI and RCMP are tailored to low-level and well-connected devices within a data center, with typical workflows requiring many messaging round trips or low-latency interactive sessions, they are not suitable for operation over a challenged network.
IPMIとRCMPは、データセンター内の低レベルで適切に接続されたデバイスに合わせて調整されており、一般的なワークフローが多くのメッセージングラウンドトリップや低遅延のインタラクティブセッションを必要とするため、チャレンジネットワーク上の操作には適していません。
The future of network operations requires more autonomous behavior, including self-configuration, self-management, self-healing, and self-optimization. One approach to support this is termed "Autonomic Networking" [RFC7575].
ネットワーク操作の将来には、自己構成、自己管理、自己修復、自己最適化など、より自律的な行動が必要です。これをサポートする1つのアプローチは、「自律的ネットワーク」と呼ばれます[RFC7575]。
There is a large and growing set of work within the IETF focused on developing an Autonomic Networking Integrated Model and Approach (ANIMA). The ANIMA work has developed a comprehensive reference model for distributing autonomic functions across multiple nodes in an Autonomic Networking infrastructure [RFC8993].
自律的なネットワーク統合モデルとアプローチ（ANIMA）の開発に焦点を当てたIETF内には、大規模で成長する一連の作業があります。Anima作業は、自律的なネットワーキングインフラストラクチャ[RFC8993]で複数のノードに自律機能を分散するための包括的な参照モデルを開発しました。
This work, focused on learning the behavior of distributed systems to predict future events, is an emerging network management capability. This includes the development of signaling protocols such as the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] and the Autonomic Control Plane (ACP) [RFC8368].
この作業は、将来のイベントを予測するために分散システムの動作を学ぶことに焦点を当てており、新興のネットワーク管理機能です。これには、一般的な自律的シグナル伝達プロトコル（GRASP）[RFC8990]や自律制御平面（ACP）[RFC8368]などのシグナル伝達プロトコルの開発が含まれます。
Both autonomic and challenged networks require similar degrees of autonomy. However, challenged networks cannot provide the complex coordination between nodes and distributed supporting infrastructure necessary for the frequent data exchanges for negotiation, learning, and bootstrapping associated with the above capabilities.
自律的なネットワークと挑戦されたネットワークの両方に、同様の程度の自律性が必要です。ただし、挑戦されたネットワークは、上記の機能に関連する交渉、学習、ブートストラップのために頻繁にデータ交換するために必要なノードと分散サポートインフラストラクチャとの間の複雑な調整を提供することはできません。
There is some emerging work in ANIMA as to how disconnected devices might join and leave the ACP over time. However, this work is addressing a different problem than that encountered by challenged networks.
アニマには、切断されたデバイスがどのように時間の経過とともにACPを結合して出発するかについて、いくつかの新たな作業があります。ただし、この作業は、挑戦されたネットワークが遭遇した問題とは異なる問題に取り組んでいます。
Outside of the terrestrial networking community, there are existing and established remote management systems used for deep space mission operations. Two examples of such systems are the New Horizons mission to Pluto [NEW-HORIZONS] and the Double Asteroid Redirection Test (DART) mission to the asteroid Dimorphos [DART].
地上のネットワーキングコミュニティ以外には、ディープスペースミッションオペレーションに使用される既存および確立されたリモート管理システムがあります。このようなシステムの2つの例は、Pl王星[新人]へのNew Horizons Missionと、小惑星Dimorphos [DART]への二重小惑星リダイレクトテスト（DART）ミッションです。
The DTNMA has some heritage in the concepts of deep space autonomy, but each of those mission instantiations uses mission-specific data encoding, messaging, and transport as well as mission-specific (or heavily mission-tailored) modeling concepts and languages. Part of the goal of the DTNMA is to take the proven concepts from these missions and standardize a messaging syntax as well as a modular data modeling method.
DTNMAには、ディープスペースの自律性の概念にある程度の遺産がありますが、それらのミッションインスタンス化のそれぞれは、ミッション固有のデータエンコード、メッセージング、トランスポート、およびミッション固有の（または重大なミッションテール付き）モデリングの概念と言語を使用します。DTNMAの目標の一部は、これらのミッションから実証済みの概念を取り、メッセージングの構文とモジュラーデータモデリング方法を標準化することです。
Management mechanisms that provide the complete set of DTNMA desirable properties do not currently exist. This is not surprising, since autonomous management in the context of a challenged networking environment is a new and emerging use case.
DTNMA望ましい特性の完全なセットを提供する管理メカニズムは現在存在しません。これは驚くことではありません。これは、挑戦されたネットワーキング環境のコンテキストでの自律的な管理が新しいユースケースであるため、驚くことではありません。
In particular, a management architecture is needed that integrates the following motivating features.
特に、次の動機付け機能を統合する管理アーキテクチャが必要です。
Open-Loop Control:
オープンループコントロール：
Freedom from a request-response architecture, API, or other presumption of timely round-trip communications. This is particularly important when managing networks that are not built over an HTTP or TCP/TLS infrastructure.
リクエスト応答アーキテクチャ、API、またはタイムリーな往復通信のその他の推定からの自由。これは、HTTPまたはTCP/TLSインフラストラクチャに基づいて構築されていないネットワークを管理する場合に特に重要です。
Standard Autonomy Model:
標準的な自律モデル：
An autonomy model that allows for standard expressions of policy to guarantee deterministic behavior across devices and vendor implementations.
ポリシーの標準的な表現を可能にする自律モデルは、デバイスとベンダーの実装間で決定論的な動作を保証します。
Compressible Model Structure:
圧縮性モデル構造：
A data model that allows for very compact encodings by defining and exploiting common structures for data schemas.
データスキーマの共通構造を定義および悪用することにより、非常にコンパクトなエンコーディングを可能にするデータモデル。
Combining these new features with existing mechanisms for message data exchange (such as BP), data representations (such as CBOR), and data modeling languages (such as YANG) will form a pragmatic approach to defining challenged network management.
これらの新機能と、メッセージデータ交換（BPなど）、データ表現（CBORなど）、およびデータモデリング言語（Yangなど）の既存のメカニズムと組み合わせると、挑戦されたネットワーク管理を定義するための実用的なアプローチが形成されます。
This section describes a reference model for analyzing network management concepts for challenged networks (generally) and those conforming to the DTN architecture (in particular). The goal of this section is to describe how DTNMA services provide DTNMA desirable properties.
このセクションでは、挑戦されたネットワーク（一般）およびDTNアーキテクチャ（特に）に準拠したネットワークのネットワーク管理概念を分析するための参照モデルについて説明します。このセクションの目標は、DTNMAサービスがDTNMA望ましいプロパティをどのように提供するかを説明することです。
Like other network management architectures, the DTNMA draws a logical distinction between a managed device and a managing device. Managed devices use a DA to manage resident applications. Managing devices use a DM to both monitor and control DAs.
他のネットワーク管理アーキテクチャと同様に、DTNMAは、管理されたデバイスと管理デバイスとの間に論理的な区別を導き出します。管理されたデバイスは、DAを使用して居住者のアプリケーションを管理します。デバイスの管理はDMを使用して、DASを監視および制御します。
The terms "managing" and "managed" represent logical characteristics of a device and are not, themselves, mutually exclusive. For example, a managed device might, itself, also manage some other device in the network. Therefore, a device may support either or both of these characteristics.
「管理」と「管理」という用語は、デバイスの論理的特性を表し、相互に排他的ではありません。たとえば、管理されたデバイス自体は、ネットワーク内の他のデバイスも管理する場合があります。したがって、デバイスは、これらの特性のいずれかまたは両方をサポートする場合があります。
The DTNMA differs from some other management architectures in three significant ways, all related to the need for a device to self-manage when disconnected from a managing device.
DTNMAは、他のいくつかの管理アーキテクチャと3つの重要な方法で異なります。これらはすべて、管理デバイスから切断されたときにデバイスが自己管理する必要性に関連しています。
Pre-Shared Definitions:
恥ずかしい定義：
Managing and managed devices should operate using pre-shared data definitions and models. This implies that static definitions should be standardized whenever possible and that managing and managed devices may need to negotiate definitions during periods of connectivity.
管理および管理されたデバイスの管理および管理されたデバイスは、事前に共有データの定義とモデルを使用して動作する必要があります。これは、静的定義を可能な限り標準化する必要があり、管理および管理されたデバイスが接続期間中に定義をネゴシエートする必要があることを意味します。
Agent Self-Management:
エージェントの自己管理：
A managed device may find itself disconnected from its managing device. In many challenged networking scenarios, a managed device may spend the majority of its time without a regular connection to a managing device. In these cases, DAs manage themselves by applying pre-shared policies received from managing devices.
管理されたデバイスは、その管理デバイスから切断される可能性があります。多くの挑戦されたネットワーキングシナリオでは、管理されたデバイスは、管理デバイスへの定期的な接続なしにその時間の大部分を費やすことがあります。これらの場合、DASは、デバイスの管理から受け取った事前に共有されたポリシーを適用することにより、自分自身を管理します。
Command-Based Interface:
コマンドベースのインターフェイス：
Managing devices communicate with managed devices through a command-based interface. Instead of exchanging variables, objects, or documents, a managing device issues commands to be run by a managed device. These commands may create or update variables, change datastores, or impact the managed device in ways similar to other network management approaches. The use of commands is, in part, driven by the need for DAs to receive updates from both remote management devices and local autonomy. The use of Controls for the implementation of commands is discussed in more detail in Section 9.5.
マネージャーデバイスは、コマンドベースのインターフェイスを介してマネージドデバイスと通信します。変数、オブジェクト、またはドキュメントを交換する代わりに、管理されているデバイスの問題コマンドが管理されたデバイスによって実行されます。これらのコマンドは、変数を作成または更新したり、データストアを変更したり、他のネットワーク管理アプローチと同様の方法で管理されたデバイスに影響を与える場合があります。コマンドの使用は、部分的に、DASがリモート管理デバイスとローカルの自律性の両方から更新を受信する必要性によって推進されています。コマンドの実装のためのコントロールの使用については、セクション9.5で詳しく説明します。
A DTNMA reference model is provided in Figure 2 below. In this reference model, applications and services on a managing device communicate with a DM that uses pre-shared definitions to create a set of policy directives that can be sent to a managed device's DA via a command-based interface. The DA provides local monitoring and control (commanding) of the applications and services resident on the managed device. The DA also performs local data fusion as necessary to synthesize data products (such as reports) that can be sent back to the DM when appropriate.
DTNMA参照モデルを以下の図2に示します。このリファレンスモデルでは、管理デバイスのアプリケーションとサービスは、コマンドベースのインターフェイスを介して管理されたデバイスのDAに送信できる一連のポリシーディレクティブを作成するために、事前共有定義を使用するDMと通信します。DAは、管理されたデバイスに住むアプリケーションとサービスのローカル監視と制御（指揮）を提供します。DAはまた、必要に応じてデータ製品（レポートなど）を合成するために必要に応じてローカルデータ融合を実行します。
Managed Device Managing Device
+----------------------------+ +-----------------------------+
| +------------------------+ | | +-------------------------+ |
| |Applications & Services | | | | Applications & Services | |
| +----------^-------------+ | | +-----------^-------------+ |
| | | | | |
| +----------v-------------+ | | +-----------v-------------+ |
| | DTNMA +-------------+ | | | | +-----------+ DTNMA | |
| | AGENT | Monitor and | | |Commanding | | | Policy | MANAGER | |
| | | Control | | |<==========| | | Encoding | | |
| | +------+-------------+ | | | | +-----------+-------+ | |
| | |Admin | Data Fusion | | |==========>| | | Reporting | Admin | | |
| | +------+-------------+ | | Reporting | | +-----------+-------+ | |
| +------------------------+ | | +-------------------------+ |
+----------------------------+ +-----------------------------+
^ ^
| Pre-Shared Definitions |
| +---------------------------+ |
+--------| - Autonomy Model |--------+
| - Application Data Models |
| - Runtime Datastores |
+---------------------------+
Figure 2: DTNMA Reference Model
図2：DTNMA参照モデル
This model preserves the familiar concept of "managers" resident on managing devices and "agents" resident on managed devices. However, the DTNMA model is unique in how the DM and DA operate. The DM is used to preconfigure DAs in the network with management policies. It is expected that the DAs, themselves, perform monitoring and control functions on their own. In this way, a properly configured DA may operate without a reliable connection back to a DM.
このモデルは、管理されたデバイスのマネービングデバイスと「エージェント」居住者の「マネージャー」居住者の馴染みのある概念を保持します。ただし、DTNMAモデルは、DMとDAの動作においてユニークです。DMは、管理ポリシーを備えたネットワーク内のDASを事前に設定するために使用されます。DAS自体が独自に監視および制御機能を実行することが期待されています。このようにして、適切に構成されたDAは、DMに戻る信頼できる接続なしで動作する場合があります。
The reference model illustrated in Figure 2 implies the existence of certain logical components whose roles and responsibilities are discussed in this section.
図2に示す参照モデルは、このセクションで役割と責任について説明する特定の論理コンポーネントの存在を意味します。
By definition, managed applications and services reside on a managed device. These software entities can be controlled through some interface by the DA, and their state can be sampled as part of periodic monitoring. It is presumed that the DA on the managed device has the proper data model, control interface, and permissions to alter the configuration and behavior of these software applications.
定義上、マネージドアプリケーションとサービスは管理されたデバイスにあります。これらのソフトウェアエンティティは、DAによって何らかのインターフェイスを介して制御でき、それらの状態は定期的な監視の一部としてサンプリングできます。管理されたデバイス上のDAには、これらのソフトウェアアプリケーションの構成と動作を変更するための適切なデータモデル、制御インターフェイス、およびアクセス許可があると推定されます。
A DA resides on a managed device. As is the case with other network management approaches, this agent is responsible for the monitoring and control of the applications local to that device. Unlike other network management approaches, the agent accomplishes this task without a regular connection to a DM.
DAは管理されたデバイスにあります。他のネットワーク管理アプローチの場合と同様に、このエージェントは、そのデバイスにローカルなアプリケーションの監視と制御を担当しています。他のネットワーク管理アプローチとは異なり、エージェントはDMへの定期的な接続なしにこのタスクを達成します。
The DA performs three major functions on a managed device: the monitoring and control of local applications, production of data analytics, and the administrative control of the agent itself.
DAは、管理されたデバイスで3つの主要な機能を実行します。ローカルアプリケーションの監視と制御、データ分析の生産、およびエージェント自体の管理制御です。
DAs monitor the status of applications running on their managed device and selectively control those applications as a function of that monitoring. The following components are used to perform monitoring and control on an agent.
DASは、管理されたデバイスで実行されているアプリケーションのステータスを監視し、そのモニタリングの関数としてそれらのアプリケーションを選択的に制御します。次のコンポーネントは、エージェントの監視と制御を実行するために使用されます。
Rule Database:
ルールデータベース：
Each DA maintains a database of policy expressions that form rules regarding the behavior of the managed device. Within this database, each rule regarding behavior is a tuple of a stimulus and a response. Within the DTNMA, these rules are the embodiment of policy expressions received from DMs and evaluated at regular intervals by the autonomy engine. The rule database is the collection of active rules known to the DA.
各DAは、管理されたデバイスの動作に関するルールを形成するポリシー表現のデータベースを維持しています。このデータベース内では、動作に関する各ルールは、刺激と応答のタプルです。DTNMA内では、これらのルールは、DMSから受け取った政策表現の具体化であり、自律エンジンによって定期的に評価されます。ルールデータベースは、DAに知られているアクティブルールのコレクションです。
Autonomy Engine:
自律エンジン：
The DA autonomy engine monitors the state of the managed device, looking for predefined stimuli and, when such stimuli are encountered, issuing a predefined response. To the extent that this function is driven by the rule database, this engine acts as a policy execution engine. This engine may also be directly configured by managers during periods of connectivity for actions separate from those in the rule database (such as enabling or disabling sets of rules). Once configured, the engine may function without other access to any managing device. This engine may also reconfigure itself as a function of policy.
DA自律エンジンは、事前に定義された刺激を探し、そのような刺激が遭遇した場合、事前定義された応答を発行し、管理されたデバイスの状態を監視します。この関数がルールデータベースによって駆動される限り、このエンジンはポリシー実行エンジンとして機能します。また、このエンジンは、ルールデータベースのアクションとは別のアクション（ルールのセットの有効化や無効化など）とは別のアクションの接続期間中にマネージャーによって直接構成される場合があります。構成されたら、エンジンは、管理デバイスへの他のアクセスなしで機能する場合があります。このエンジンは、ポリシーの関数としてそれ自体を再構成することもできます。
Application Control Interfaces:
アプリケーション制御インターフェイス：
DAs support control interfaces for all managed applications. Control interfaces are used to alter the configuration and behavior of an application. These interfaces may be custom for each application or as provided through a common framework, protocol, or OS.
すべてのマネージドアプリケーションのDASサポート制御インターフェイス。制御インターフェイスは、アプリケーションの構成と動作を変更するために使用されます。これらのインターフェイスは、アプリケーションごとにカスタムである場合、または一般的なフレームワーク、プロトコル、またはOSを介して提供される場合があります。
DAs generate new data elements as a function of the current state of the managed device and its applications. These new data products may take the form of individual data values or of new collections of data used for reporting. The logical components responsible for these behaviors are as follows.
DASは、管理されたデバイスの現在の状態とそのアプリケーションの関数として新しいデータ要素を生成します。これらの新しいデータ製品は、個々のデータ値またはレポートに使用される新しいデータコレクションの形をとる場合があります。これらの動作を担当する論理コンポーネントは次のとおりです。
Application Data Interfaces:
アプリケーションデータインターフェイス：
DAs support mechanisms by which important state is retrieved from various applications resident on the managed device. These data interfaces may be custom for each application or as provided through a common framework, protocol, or OS.
DASは、管理されたデバイスに居住しているさまざまなアプリケーションから重要な状態が取得されるメカニズムをサポートしています。これらのデータインターフェイスは、アプリケーションごとにカスタムであるか、一般的なフレームワーク、プロトコル、またはOSを介して提供される場合があります。
Data Value Generators:
データ値ジェネレーター：
DAs may support the generation of new data values as a function of other values collected from the managed device. These data generators may be configured with descriptions of data values, and the data values they generate may be included in the overall monitoring and reporting associated with the managed device.
DASは、管理されたデバイスから収集された他の値の関数として、新しいデータ値の生成をサポートする場合があります。これらのデータジェネレーターは、データ値の説明で構成されている場合があり、生成するデータ値は、管理されたデバイスに関連付けられた全体的な監視とレポートに含まれる場合があります。
Report Generators:
レポートジェネレーター：
DAs may, as appropriate, generate collections of data values and provide them to whatever local mechanism takes responsibility for their eventual transmission (or expiration and removal). Reports can be generated as a matter of policy or in response to the handling of critical events (such as errors) or other logging needs. The generation of a report is independent of whether there exists any connectivity between a DA and a DM.
DASは、必要に応じて、データ値のコレクションを生成し、最終的な送信（または有効期限と削除）に対して責任を負うローカルメカニズムにそれらを提供する場合があります。レポートは、ポリシーの問題として、または重要なイベント（エラーなど）やその他のロギングニーズの処理に応じて生成できます。レポートの生成は、DAとDMの間に接続性が存在するかどうかに依存しません。
DAs perform a variety of administrative services in support of their configuration, such as the following.
DASは、次のような構成をサポートするために、さまざまな管理サービスを実行します。
Manager Mapping:
マネージャーマッピング：
The DTNMA allows for a many-to-many relationship amongst DAs and DMs. A single DM may configure multiple DAs, and a single DA may be configured by multiple DMs. Multiple managers may exist in a network for at least the following two reasons. First, different managers may exist to control different applications on a device. Second, multiple managers increase the likelihood of an agent encountering a manager when operating in a sparse or challenged environment.
DTNMAは、DASとDMSの間の多くの関係を可能にします。単一のDMは複数のDAを構成し、単一のDAを複数のDMで構成できます。少なくとも次の2つの理由で、複数のマネージャーがネットワークに存在する場合があります。まず、デバイス上のさまざまなアプリケーションを制御するために、異なるマネージャーが存在する場合があります。第二に、複数のマネージャーが、エージェントがまばらまたは挑戦された環境で操作するときにマネージャーに遭遇する可能性を高めます。
While multiple managers are needed for proper operation in a dynamically partitioned network, conflicting information from different managers can result. Implementations of the DTNMA should consider conflict resolution mechanisms. Such mechanisms might include analyzing managed content, time, agent location, or other relevant information to select one manager input over other manager inputs.
動的に分割されたネットワークでの適切な操作には複数のマネージャーが必要ですが、異なるマネージャーからの矛盾する情報が生じる可能性があります。DTNMAの実装は、紛争解決メカニズムを考慮する必要があります。このようなメカニズムには、管理されたコンテンツの分析、時間、エージェントの場所、または他のマネージャーの入力を選択するためのその他の関連情報が含まれます。
Data Verifiers:
データ検証剤：
DAs might handle large amounts of data produced by various sources, to include data from local managed applications, remote managers, and self-calculated values. DAs should ensure, when possible, that externally generated data values have the proper syntax and semantic constraints (e.g., data type and ranges) and any required authorization.
DASは、さまざまなソースによって生成された大量のデータを処理して、ローカルマネージドアプリケーション、リモートマネージャー、自己計算値からのデータを含めることができます。DASは、可能であれば、外部から生成されたデータ値に適切な構文とセマンティックの制約（データ型と範囲など）と必要な承認があることを確認する必要があります。
Access Controllers:
アクセスコントローラー：
DAs support authorized access to the management of individual applications, to include the administrative management of the agent itself. This means that a manager may only set policy on the agent pursuant to verifying that the manager is authorized to do so.
DASは、エージェント自体の管理管理を含めるために、個々のアプリケーションの管理へのアクセスを承認しました。これは、マネージャーがマネージャーがそうする権限があることを確認することに従って、エージェントにポリシーのみを設定できることを意味します。
Managing applications and services reside on a managing device and serve as both the source of DA policy statements and the target of DA reporting. They may operate with or without an operator in the loop.
アプリケーションとサービスの管理は、管理デバイスに存在し、DAポリシーステートメントのソースとDAレポートの目標の両方として機能します。それらは、ループ内のオペレーターの有無にかかわらず動作する場合があります。
Unlike management applications in unchallenged networks, these applications cannot exert closed-loop control over any managed device application. Instead, they exercise open-loop control by producing policies that can be configured and enforced on managed devices by DAs.
挑戦されていないネットワークの管理アプリケーションとは異なり、これらのアプリケーションは、管理されたデバイスアプリケーションにクローズドループ制御を行うことはできません。代わりに、DASが管理したデバイスで構成および実施できるポリシーを作成することにより、オープンループ制御を行使します。
NOTE: Closed-loop control in this context refers to the practice of waiting for a response from a managed device prior to issuing new commands to that device. These "loops" may be closed quickly (in milliseconds) or over much longer periods (hours, days, years). The alternative to closed-loop control is open-loop control, where the issuance of new commands is not dependent on receiving responses to previous commands. Additionally, there might not be a one-to-one mapping between commands and responses. A DA may, for example, produce a single response that represents the end state of applying multiple commands.
注：このコンテキストでの閉ループ制御とは、そのデバイスに新しいコマンドを発行する前に、管理されたデバイスからの応答を待つ練習を指します。これらの「ループ」は、すぐに（ミリ秒単位で）閉じられているか、はるかに長い期間（時間、日、年）に閉じられている場合があります。閉ループ制御に代わるものは、新しいコマンドの発行が以前のコマンドに対する回答の受信に依存しないオープンループ制御です。さらに、コマンドと応答の間に1対1のマッピングがない場合があります。たとえば、DAは、複数のコマンドを適用する最終状態を表す単一の応答を生成する場合があります。
A DM resides on a managing device. This manager provides an interface between various managing applications and services and the DAs that enforce their policies. In providing this interface, DMs translate between whatever innate interface exists to various managing applications and the autonomy models used to encode management policy.
DMは管理デバイスにあります。このマネージャーは、さまざまな管理アプリケーションとサービスと、ポリシーを実施するDASとの間のインターフェイスを提供します。このインターフェイスを提供する際に、DMSは、さまざまな管理アプリケーションと管理ポリシーをエンコードするために使用されるさまざまな管理アプリケーションに存在する生来のインターフェイスとの間に翻訳されます。
The DM performs three major functions on a managing device: policy encoding, reporting, and administration.
DMは、管理デバイスで3つの主要な機能を実行します：ポリシーエンコード、レポート、および管理。
DMs translate policy directives from managing applications and services into standardized policy expressions that can be recognized by DAs. The following logical components are used to perform this policy encoding.
DMSは、ポリシー指令をアプリケーションとサービスの管理から、DASが認識できる標準化されたポリシー表現に変換します。次の論理コンポーネントを使用して、このポリシーエンコードを実行します。
Application Control Interfaces:
アプリケーション制御インターフェイス：
DMs support control interfaces for managing applications. These control interfaces are used to receive desired policy statements from applications. These interfaces may be custom for each application or as provided through a common framework, protocol, or OS.
DMSは、アプリケーションを管理するための制御インターフェイスをサポートします。これらの制御インターフェイスは、アプリケーションから目的のポリシーステートメントを受信するために使用されます。これらのインターフェイスは、アプリケーションごとにカスタムである場合、または一般的なフレームワーク、プロトコル、またはOSを介して提供される場合があります。
Policy Encoders:
ポリシーエンコーダー：
DAs implement a standardized autonomy model comprising standardized data elements. This allows the open-loop control structures provided by managing applications to be represented in a common language. Policy encoders perform this encoding function.
DASは、標準化されたデータ要素を含む標準化された自律モデルを実装します。これにより、アプリケーションを管理することによって提供されるオープンループ制御構造を共通言語で表現できます。ポリシーエンコーダーはこのエンコード関数を実行します。
Policy Aggregators:
ポリシーアグリゲーター：
DMs collect multiple encoded policies into messages that can be sent to DAs over the network. This implies the proper addressing of agents and the creation of messages that support store-and-forward operations. It is recommended that control messages be packaged using BP bundles when there may be intermittent connectivity between DMs and DAs.
DMは、複数のエンコードされたポリシーを、ネットワーク上でDASに送信できるメッセージに収集します。これは、エージェントの適切なアドレス指定と、ストアアンドフォワード操作をサポートするメッセージの作成を意味します。DMSとDASの間に断続的な接続性がある場合は、BPバンドルを使用してコントロールメッセージをパッケージ化することをお勧めします。
DMs receive reports on the status of managed devices during periods of connectivity with the DAs on those devices. The following logical components are needed to implement reporting capabilities on a DM.
DMSは、これらのデバイスのDASとの接続期間中に管理されたデバイスのステータスに関するレポートを受け取ります。DMにレポート機能を実装するには、次の論理コンポーネントが必要です。
Report Collectors:
レポートコレクター：
DMs receive reports from DAs in an asynchronous manner. This means that reports may be received out of chronological order and in ways that are difficult or impossible to associate with a specific policy from a managing application. DMs collect these reports and extract their data in support of subsequent data analytics.
DMSは、DASから非同期的にレポートを受け取ります。これは、レポートが年代順に、および管理アプリケーションから特定のポリシーに関連付けることが困難または不可能な方法で受信される可能性があることを意味します。DMSはこれらのレポートを収集し、その後のデータ分析をサポートしてデータを抽出します。
Data Analyzers:
データアナライザー：
DMs review sets of data reports from DAs with the purpose of extracting relevant data to communicate with managing applications. This may include simple data extraction or may include more complex processing such as data conversion, data fusion, and appropriate data analytics.
DMSは、関連するデータを抽出してマネービングアプリケーションと通信する目的で、DASからの一連のデータレポートセットを確認します。これには、単純なデータ抽出が含まれる場合や、データ変換、データ融合、適切なデータ分析などのより複雑な処理が含まれる場合があります。
Application Data Interfaces:
アプリケーションデータインターフェイス：
DMs support mechanisms by which data retrieved from DAs may be provided back to managing devices. These interfaces may be custom for each application or as provided through a common framework, protocol, or OS.
DMSは、DASから取得されたデータを管理デバイスに提供できるメカニズムをサポートします。これらのインターフェイスは、アプリケーションごとにカスタムである場合、または一般的なフレームワーク、プロトコル、またはOSを介して提供される場合があります。
DMs in the DTNMA perform a variety of administrative services, such as the following.
DTNMAのDMSは、以下などのさまざまな管理サービスを実行します。
Agent Mappings:
エージェントマッピング：
The DTNMA allows DMs to communicate with multiple DAs. However, not every agent in a network is expected to support the same set of application data models or otherwise have the same set of managed applications running. For this reason, DMs determine individual DA capabilities to ensure that only appropriate Controls are sent to a DA.
DTNMAにより、DMSは複数のDAと通信できます。ただし、ネットワーク内のすべてのエージェントが同じアプリケーションデータモデルのセットをサポートしたり、同じマネージドアプリケーションのセットを実行しているとは限りません。このため、DMは個々のDA機能を決定して、適切なコントロールのみがDAに送信されるようにします。
Data Verifiers:
データ検証剤：
DMs handle large amounts of data produced by various sources, to include data from managing applications and DAs. DMs should ensure, when possible, that data values received from DAs over a network have the proper syntax and semantic constraints (e.g., data type and ranges) and any required authorization.
DMSは、さまざまなソースによって生成された大量のデータを処理し、アプリケーションとDASの管理からのデータを含めます。DMSは、可能であれば、ネットワーク上のDASから受信したデータ値に、適切な構文とセマンティックの制約（データ型と範囲など）および必要な承認があることを確認する必要があります。
Access Controllers:
アクセスコントローラー：
DMs should only send Controls to DAs when the manager is configured with appropriate access to both the agent and the applications being managed.
DMSは、管理対象のアプリケーションの両方に適切なアクセスでマネージャーが設定されている場合にのみ、DASにコントロールを送信する必要があります。
A consequence of operating in a challenged environment is the potential inability to negotiate information in real time. For this reason, the DTNMA requires that managed and managing devices operate using pre-shared definitions rather than relying on data definition negotiation.
挑戦された環境での運用の結果、情報をリアルタイムで交渉できない可能性があります。このため、DTNMAは、データ定義のネゴシエーションに依存するのではなく、事前に共有された定義を使用して、管理および管理デバイスが動作することを要求しています。
The three types of pre-shared definitions in the DTNMA are the DA autonomy model, managed application data models, and any runtime data shared by managers and agents.
DTNMAの3つのタイプの事前に共有された定義は、DA自律モデル、管理されたアプリケーションデータモデル、およびマネージャーとエージェントが共有するランタイムデータです。
Autonomy Model:
自律モデル：
A DTNMA autonomy model represents the data elements and associated autonomy structures that define the behavior of the agent autonomy engine. A standardized autonomy model allows for individual implementations of DAs and DMs to interoperate. A standardized model also provides guidance to the design and implementation of both managed and managing applications.
DTNMA自律モデルは、エージェントの自律エンジンの動作を定義するデータ要素と関連する自律構造を表します。標準化された自律モデルにより、DASとDMの個々の実装が相互操作できます。標準化されたモデルは、マネージドアプリケーションとマネージングアプリケーションの両方の設計と実装へのガイダンスも提供します。
Application Data Models:
アプリケーションデータモデル：
As with other network management architectures, the DTNMA presupposes that managed applications (and services) define their own data models. These data models include the data produced by, and Controls implemented by, the application. These models are expected to be static for individual applications and standardized for applications implementing standard protocols.
他のネットワーク管理アーキテクチャと同様に、DTNMAは、マネージドアプリケーション（およびサービス）が独自のデータモデルを定義していることを前提としています。これらのデータモデルには、アプリケーションによって生成されたデータと実装されたコントロールが含まれます。これらのモデルは、個々のアプリケーションの静的であり、標準プロトコルを実装するアプリケーション用に標準化されると予想されます。
Runtime Datastores:
ランタイムデータストア：
Runtime datastores, by definition, include data that is defined at runtime. As such, the data is not pre-shared prior to the deployment of DMs and DAs. Pre-sharing in this context means that DMs and DAs are able to define and synchronize data elements prior to their operational use in the system. This synchronization happens during periods of connectivity between DMs and DAs.
定義上、ランタイムデータストアには、実行時に定義されるデータが含まれます。そのため、データは、DMSおよびDASの展開前に事前に共有されていません。このコンテキストでの事前共有は、DMSとDASがシステムでの運用使用の前にデータ要素を定義および同期することができることを意味します。この同期は、DMSとDAS間の接続期間中に行われます。
This section describes the services provided by DTNMA components on both managing and managed devices. Most of the services discussed in this section attempt to provide continuous operation of a managed device through periods of no connectivity with a managing device.
このセクションでは、管理デバイスと管理されたデバイスの両方でDTNMAコンポーネントが提供するサービスについて説明します。このセクションで説明したサービスのほとんどは、管理デバイスとの接続なしの期間を通じて管理されたデバイスの継続的な動作を提供しようとします。
DTNMA monitoring is associated with some DA autonomy engine. The term "monitoring" implies regular access to information such that state changes may be acted upon within some response time period.
DTNMAモニタリングは、一部のDA自律エンジンに関連付けられています。「監視」という用語は、一部の応答期間内に状態の変更を行うことができるように、情報への定期的なアクセスを意味します。
Predicate autonomy on a managed device should collect state associated with the device at regular intervals and evaluate that collected state for any changes that require a preventative or corrective action. Similarly, this monitoring may cause the device to generate one or more reports destined to a managing device.
管理されたデバイスの述語自律性は、定期的にデバイスに関連付けられた状態を収集し、予防的または是正措置を必要とする変更について、その収集状態を評価する必要があります。同様に、この監視により、デバイスは管理デバイスに運命づけられた1つ以上のレポートを生成する可能性があります。
Like monitoring, DTNMA control results in actions by the agent to change the state or behavior of the managed device. All control in the DTNMA is local control. In cases where there exists a timely connection to a DM, received Controls are still evaluated and run locally as part of local autonomy. In this case, the autonomy stimulus is the receipt of the Control, and the response is to immediately run the Control. In this way, there is never a dependency on a session or other stateful exchange with any remote entity.
監視と同様に、DTNMA制御により、エージェントが管理したデバイスの状態または動作を変更するアクションが発生します。DTNMAのすべての制御はローカルコントロールです。DMへのタイムリーな接続が存在する場合、受信コントロールは依然として評価され、ローカルの自律性の一部としてローカルに実行されます。この場合、自律刺激はコントロールの受領であり、対応はすぐにコントロールを実行することです。このようにして、セッションやリモートエンティティとの他のステートフルな交換に依存することはありません。
DTNMA fusion services produce new data products from existing state on the managed device. These fusion products can be anything from simple summations of sampled counters to complex calculations of behavior over time.
DTNMA Fusionサービスは、管理されたデバイス上の既存の状態から新しいデータ製品を生産します。これらの融合製品は、サンプリングされたカウンターの単純な合計から、時間の経過に伴う行動の複雑な計算まで、あらゆるものにすることができます。
Fusion is an important service in the DTNMA because fusion products are part of the overall state of a managed device. Complete knowledge of this overall state is important for the management of the device, and the predicates of rules on a DA may refer to fused data.
融合製品は管理されたデバイスの全体的な状態の一部であるため、FusionはDTNMAの重要なサービスです。この状態の完全な知識は、デバイスの管理にとって重要であり、DAのルールの述語は融合データを指す場合があります。
In situ data fusion is an important function, as it allows for the construction of intermediate summary data, the reduction of stored and transmitted raw data, and possibly fewer predicates in rule definitions; this type of data fusion insulates the data source from conclusions drawn from that data.
in situデータ融合は、中間要約データの構築、保存および送信された生データの削減、およびルール定義の可能性のある述語の削減を可能にするため、重要な機能です。このタイプのデータフュージョンは、そのデータから引き出された結論からデータソースを隔離します。
The DTNMA requires fusion to occur on the managed device itself. If the network is partitioned such that no connection to a managing device is available, then fusion needs to happen locally. Similarly, connections to a managing device might not remain active long enough for round-trip data exchange or may not have the bandwidth to send all sampled data.
DTNMAは、管理されたデバイス自体で融合する必要があります。ネットワークが管理されているように分割されている場合、管理デバイスへの接続が利用できない場合、Fusionはローカルで発生する必要があります。同様に、管理デバイスへの接続は、ラウンドトリップデータ交換に十分な長さのアクティブではない場合や、サンプリングされたすべてのデータを送信するための帯域幅がない場合があります。
NOTE: The DTNMA does not restrict the storage and transmission of raw (pre-fused) data. Such raw data can be useful for debugging managed devices, understanding complex interactions and underlying conditions, and tuning for better performance and/or better outcomes.
注：DTNMAは、RAW（事前に融合した）データのストレージと送信を制限していません。Such raw data can be useful for debugging managed devices, understanding complex interactions and underlying conditions, and tuning for better performance and/or better outcomes.
DTNMA configuration services update the local configuration of a managed device with the intent of impacting the behavior and capabilities of that device.
DTNMA構成サービスそのデバイスの動作と機能に影響を与える目的で、管理されたデバイスのローカル構成を更新します。
The DTNMA configuration service is unique in that the selection of managed device configurations occurs as a function of the state of the device. This implies that management proxies on the device store multiple configuration functions that can be applied as needed without consultation from a managing device.
DTNMA構成サービスは、管理されたデバイス構成の選択がデバイスの状態の関数として発生するという点でユニークです。これは、管理デバイスからの相談なしに必要に応じて適用できる複数の構成関数をデバイスに保存していることを管理することを意味します。
This approach differs from other management concepts of selecting from multiple datastores. DTNMA configuration functions can target individual data elements and can calculate new values from local device state.
このアプローチは、複数のデータストアから選択する他の管理概念とは異なります。DTNMA構成関数は、個々のデータ要素をターゲットにすることができ、ローカルデバイスの状態から新しい値を計算できます。
When detecting stimuli, the agent autonomy engine supports a mechanism for evaluating whether application monitoring data or runtime data values are recent enough to indicate a change of state. In cases where data has not been updated recently, it may be considered stale and therefore not used to reliably indicate that some stimulus has occurred.
刺激を検出するとき、エージェントの自律エンジンは、アプリケーション監視データまたはランタイムデータ値が状態の変化を示すのに十分な最近であるかどうかを評価するためのメカニズムをサポートします。データが最近更新されていない場合、それは古くなっていると見なされる可能性があり、したがって、いくつかの刺激が発生したことを確実に示すために使用されない可能性があります。
DTNMA reporting services collect information known to the managed device and prepare it for eventual transmission to one or more managing devices. The contents of these reports, and the frequency at which they are generated, occur as a function of the state of the managed device, independent of the managing device.
DTNMAレポートサービスは、管理されたデバイスに知られている情報を収集し、1つ以上の管理デバイスへの最終的な送信のために準備します。これらのレポートの内容と生成される頻度は、管理デバイスとは無関係に、管理されたデバイスの状態の関数として発生します。
Once generated, it is expected that reports might be queued, pending a connection back to a managing device. Therefore, reports need to be differentiable as a function of the time they were generated.
生成されると、管理デバイスへの接続が保留されている場合、レポートがキューに登録される可能性があります。したがって、レポートは、生成された時間の関数として微分可能である必要があります。
NOTE: When reports are queued pending transmission, the overall storage capacity at the queuing device needs to be considered. There may be cases where queued reports can be considered expired because they have been either queued for too long or replaced by a newer report. When a report is considered expired, it may be considered for removal and, thus, never transmitted. This consideration is expected to be part of the implementation of the queuing device and not the responsibility of the reporting function within the DTNMA.
注：レポートが送信が保留されている場合、キューイングデバイスの全体的なストレージ容量を考慮する必要があります。キューに長い間キューに入れられているか、新しいレポートに置き換えられているため、キューに登録されたレポートが期限切れと見なされる可能性がある場合があります。報告書が期限切れと見なされると、削除と見なされるため、送信されない可能性があります。この考慮事項は、DTNMA内のレポート関数の責任ではなく、キューイングデバイスの実装の一部であると予想されます。
When reports are sent to a managing device over a challenged network, they may arrive out of order due to taking different paths through the network or being delayed due to retransmissions. A managing device should not infer meaning from the order in which reports are received.
レポートが挑戦されたネットワークを介して管理デバイスに送信されると、ネットワークを介して異なるパスを取るか、再送信のために遅延しているため、故障して故障する場合があります。管理デバイスは、レポートを受信した順序から意味を推測してはなりません。
Reports may or may not be associated with a specific Control. Some reports may be annotated with the Control that caused the report to be generated. Sometimes, a single report will represent the end state of applying multiple Controls.
レポートは、特定のコントロールに関連付けられている場合と関連付けられている場合があります。いくつかのレポートには、レポートが生成される原因となったコントロールが注釈が付けられている場合があります。時には、単一のレポートが複数のコントロールを適用する最終状態を表す場合があります。
Both local and remote services provided by the DTNMA affect the behavior of multiple applications on a managed device and may interface with multiple managing devices.
DTNMAが提供するローカルサービスとリモートサービスの両方が、管理されたデバイス上の複数のアプリケーションの動作に影響し、複数の管理デバイスとインターフェイスできます。
Authorization services enforce the potentially complex mapping of other DTNMA services amongst managed and managing devices in the network. For example, fine-grained access control can determine which managing devices receive which reports, and what Controls can be used to alter which managed applications.
認証サービスは、ネットワーク内の管理および管理デバイスの間で、他のDTNMAサービスの潜在的に複雑なマッピングを実施します。たとえば、ファイングレインのアクセス制御は、どのレポートを受信するか、どのコントロールを使用してどのマネージャーアプリケーションを変更できるかを決定できます。
This is particularly beneficial in networks that deal with either multiple administrative entities or overlay networks that cross administrative boundaries. Allowlists, blocklists, key-based infrastructures, or other schemes may be used for this purpose.
これは、複数の管理エンティティまたは管理境界を越えたオーバーレイネットワークを扱うネットワークで特に有益です。Allowlists、ブロックリスト、キーベースのインフラストラクチャ、またはその他のスキームは、この目的に使用できます。
An important characteristic of the DTNMA is the shift in the role of a managing device. One way to describe the behavior of the agent autonomy engine is to describe the characteristics of the autonomy model it implements.
DTNMAの重要な特徴は、管理デバイスの役割の変化です。エージェント自律エンジンの動作を説明する1つの方法は、実装する自律モデルの特性を記述することです。
This section describes a logical autonomy model in terms of the abstract data elements that would comprise the model. Defining abstract data elements allows for an unambiguous discussion of the behavior of an autonomy model without mandating a particular design, encoding, or transport associated with that model.
このセクションでは、モデルを構成する抽象的なデータ要素の観点から論理自律モデルについて説明します。抽象データ要素を定義することで、そのモデルに関連する特定の設計、エンコード、または輸送を義務付けることなく、自律モデルの動作について明確な議論をすることができます。
A managing autonomy capability on a potentially disconnected device needs to behave in both an expressive and deterministic way. Expressivity allows for the model to be configured for a wide range of future situations. Determinism allows for the forensic reconstruction of device behavior as part of debugging or recovery efforts. It also is necessary to ensure predictable behavior.
潜在的に切断されたデバイスでの自律性能力の管理は、表現力豊かで決定論的な方法の両方で動作する必要があります。表現力により、幅広い将来の状況に合わせてモデルを構成できます。決定論により、デバッグまたは回復の取り組みの一環として、デバイスの動作の法医学的再構築が可能になります。また、予測可能な動作を確保する必要があります。
NOTE: The use of predicate logic and a stimulus-response system does not conflict with the use of higher-level autonomous functions or the incorporation of Machine Learning (ML). Specifically, the DTNMA deterministic autonomy model can coexist with other autonomous functions managing applications and network services.
注：述語論理と刺激応答システムの使用は、高レベルの自律機能の使用または機械学習（ML）の組み込みと矛盾しません。具体的には、DTNMA決定論的自律モデルは、アプリケーションやネットワークサービスを管理する他の自律機能と共存できます。
An example of such coexistence is the use of the DTNMA model to ensure that a device stays within safe operating parameters while a less deterministic ML model directs other behaviors for the device.
このような共存の例は、DTNMAモデルを使用して、デバイスが安全な動作パラメーター内にとどまることを保証し、決定論的でないMLモデルがデバイスの他の動作を指示することです。
The DTNMA autonomy model is a rule-based model in which individual rules associate a pre-identified stimulus with a preconfigured response to that stimulus.
DTNMA自律モデルは、個々のルールが事前に特定された刺激をその刺激に対する事前に構成した応答と関連付けるルールベースのモデルです。
Stimuli are identified using one or more predicate logic expressions that examine aspects of the state of the managed device. Responses are implemented by running one or more procedures on the managed device.
刺激は、管理されたデバイスの状態の側面を調べる1つ以上の述語論理式を使用して特定されます。応答は、管理されたデバイスで1つ以上の手順を実行することにより実装されます。
In its simplest form, a stimulus is a single predicate expression of a condition that examines some aspect of the state of the managed device. When the condition is met, a predetermined response is applied. This behavior can be captured using the construct:
最も単純な形式では、刺激は、管理されたデバイスの状態のいくつかの側面を調べる条件の単一の述語発現です。条件が満たされると、所定の応答が適用されます。この動作は、構成要素を使用してキャプチャできます。
IF <condition 1> THEN <response 1>
In more complex forms, a stimulus may include both a common condition shared by multiple rules and a specific condition for each individual rule. If the common condition is not met, the evaluation of the specific condition of each rule sharing the common condition can be skipped. In this way, the total number of predicate evaluations can be reduced. This behavior can be captured using the construct:
より複雑な形式では、刺激には、複数のルールで共有される一般的な条件と、個々のルールごとに特定の条件の両方が含まれる場合があります。一般的な条件が満たされない場合、共通の条件を共有する各ルールの特定の条件の評価をスキップできます。このようにして、述語評価の総数を減らすことができます。この動作は、構成要素を使用してキャプチャできます。
IF <common condition> THEN
IF <specific condition 1> THEN <response 1>
IF <specific condition 2> THEN <response 2>
IF <specific condition 3> THEN <response 3>
NOTE: The DTNMA model remains a stimulus-response system, regardless of whether a common condition is part of the stimulus. However, it is recommended that implementations incorporate a common condition because of the efficiency provided by such a bulk evaluation.
注：DTNMAモデルは、一般的な条件が刺激の一部であるかどうかに関係なく、刺激反応システムのままです。ただし、このようなバルク評価によって提供される効率のため、実装に共通の状態を組み込むことをお勧めします。
NOTE: One use of a stimulus "common condition" is to associate the condition with an onboard event such as the expiring of a timer or the changing of a monitored value.
注：刺激の「一般的な状態」の1つの使用は、タイマーの期限切れや監視対象の値の変更など、条件をオンボードイベントに関連付けることです。
The DTNMA does not prescribe when to evaluate rule stimuli. Implementations may choose to evaluate rule stimuli at periodic intervals (such as 1 Hz or 100 Hz). When stimuli include onboard events, implementations may choose to perform an immediate evaluation at the time of the event rather than waiting for a periodic evaluation.
DTNMAは、ルール刺激を評価するタイミングを規定していません。実装は、定期的な間隔（1 Hzまたは100 Hzなど）でルール刺激を評価することを選択できます。刺激にオンボードイベントが含まれる場合、実装は定期的な評価を待つのではなく、イベント時に即時評価を実行することを選択できます。
The flow of data into and out of the agent autonomy engine is illustrated in Figure 3.
エージェント自律エンジンへの出入りのデータの流れを図3に示します。
Managed Applications | DTNMA Agent | DTNMA Manager
+---------------------+--------------------------------+--------------+
| +---------+ |
| | Local | | Encoded
| | Rule DB |<-------------------- Policy
| +---------+ | Expressions
| ^ |
| | |
| v |
| +----------+ +---------+ |
Monitoring Data------>| Agent | | Runtime | |
| | Autonomy |<-->| Data- |<---- Definitions
Application Control<------| Engine | | store | |
| +----------+ +---------+ |
| | |
| +-------------------------> Reports
| |
Figure 3: DTNMA Autonomy Model
図3：DTNMA自律モデル
In the model shown in Figure 3, the autonomy engine stores the combination of stimulus conditions and associated responses as a set of "rules" in a rule database. This database is updated through the execution of the autonomy engine and as configured from policy statements received by DMs.
図3に示すモデルでは、自律エンジンは、刺激条件と関連する応答の組み合わせを、ルールデータベースの「ルール」のセットとして保存します。このデータベースは、自律エンジンの実行を通じて更新され、DMSが受け取ったポリシーステートメントから構成されています。
Stimuli are detected by examining the state of applications as reported through application monitoring interfaces and through any locally derived data. Local data is calculated in accordance with definitions also provided by DMs as part of the runtime datastore.
刺激は、アプリケーション監視インターフェイスを通じて、およびローカル派生データを通じて報告されているアプリケーションの状態を調べることによって検出されます。ローカルデータは、ランタイムデータストアの一部としてDMSによって提供される定義に従って計算されます。
Responses to stimuli may include updates to the rule database, updates to the runtime datastore, Controls sent to applications, and the generation of reports.
刺激への応答には、ルールデータベースの更新、ランタイムデータストアの更新、アプリケーションに送信されたコントロール、およびレポートの生成が含まれる場合があります。
There are several practical challenges to the implementation of a distributed rule-based system. Large numbers of rules may be difficult to understand, deconflict, and debug. Rules whose conditions are given by fused or other dynamic data may require data logging and reporting for deterministic offline analysis. Rule differences across managed devices may lead to oscillating effects. This section identifies those characteristics of an autonomy model that might help implementations mitigate some of these challenges.
分散ルールベースのシステムの実装には、いくつかの実際的な課題があります。多数のルールを理解し、デコンフリクトし、デバッグすることは困難な場合があります。融合またはその他の動的データによって条件が与えられるルールでは、決定論的なオフライン分析のためにデータの記録とレポートが必要になる場合があります。管理されたデバイス間のルールの違いは、振動効果につながる可能性があります。このセクションでは、実装がこれらの課題のいくつかを軽減するのに役立つ自律モデルの特性を特定します。
There are a number of ways to represent data values, and many data modeling languages exist for this purpose. When considering how to model data in the context of the DTNMA autonomy model, there are some modeling features that should be present to enable functionality. There are also some modeling features that should be prevented to avoid ambiguity.
データ値を表す方法はいくつかあり、この目的のために多くのデータモデリング言語が存在します。DTNMA自律モデルのコンテキストでデータをモデル化する方法を検討する場合、機能を有効にするために存在する必要があるモデリング機能がいくつかあります。曖昧さを避けるために防止する必要があるモデリング機能もいくつかあります。
Conventional network management approaches favor flexibility in their data models. The DTNMA stresses deterministic behavior that supports forensic analysis of agent activities "after the fact". As such, the following statements should be true of all data representations relating to DTNMA autonomy.
従来のネットワーク管理は、データモデルの柔軟性を好みます。DTNMAは、「事実後」のエージェント活動の法医学的分析をサポートする決定論的行動を強調します。そのため、次のステートメントは、DTNMAの自律性に関連するすべてのデータ表現に当てはまるはずです。
Strong Typing:
強いタイピング：
The predicates and expressions that comprise the autonomy services in the DTNMA should require strict data typing. This avoids errors associated with implicit data conversions and helps detect misconfigurations.
DTNMAの自律サービスを構成する述語と表現は、厳密なデータタイピングを必要とするはずです。これにより、暗黙のデータ変換に関連するエラーが回避され、誤った採掘の検出に役立ちます。
Acyclic Dependency:
非環式依存関係：
Many dependencies exist in an autonomy model, particularly when combining individual expressions or results to create complex behaviors. Implementations that conform to the DTNMA need to prevent circular dependencies.
特に個々の表現または結果を組み合わせて複雑な動作を作成する場合、多くの依存関係が自律モデルに存在します。DTNMAに準拠する実装は、円形の依存関係を防ぐ必要があります。
Fresh Data:
新鮮なデータ：
Autonomy models operating on data values presume that their data inputs represent the actionable state of the managed device. If a data value has failed to be refreshed within a time period, autonomy might incorrectly infer an operational state. Regardless of whether a data value has changed, DTNMA implementations should provide some indicator of whether the data value is "fresh", i.e., meaning that it still represents the current state of the device.
データ値で動作する自律モデルは、データ入力が管理されたデバイスの実用的な状態を表していると推測しています。期間内にデータ値が更新されなかった場合、自律性は誤って運用状態を推測する可能性があります。データ値が変更されたかどうかにかかわらず、DTNMAの実装は、データ値が「新鮮」であるかどうか、つまりデバイスの現在の状態を表すかどうかの指標を提供する必要があります。
Pervasive Parameterization:
一般的なパラメーター化：
Where possible, autonomy model objects should support parameterization to allow for flexibility in the specification. Parameterization allows for the definition of fewer unique model objects and also can support the substitution of local device state when exercising device control or data reporting.
可能であれば、自律モデルオブジェクトは、仕様の柔軟性を可能にするパラメーター化をサポートする必要があります。パラメーター化により、より少ない一意のモデルオブジェクトの定義が可能になり、デバイス制御またはデータレポートを行使するときにローカルデバイス状態の置換をサポートできます。
Configurable Cardinality:
構成可能なカーディナリティ：
The number of data values that can be supported in a given implementation is finite. For devices operating in challenged environments, the number of supported objects may be far fewer than the number of objects that can be supported by devices in well-resourced environments. DTNMA implementations should define limits to the number of supported objects that can be active in a system at one time, as a function of the resources available to the implementation.
特定の実装でサポートできるデータ値の数は有限です。課題のある環境で動作するデバイスの場合、サポートされているオブジェクトの数は、リソースされた環境でデバイスでサポートできるオブジェクトの数よりもはるかに少ない場合があります。DTNMAの実装は、実装が利用できるリソースの関数として、一度にシステムでアクティブになる可能性のあるサポートされているオブジェクトの数に制限を定義する必要があります。
Control-Based Updates:
コントロールベースの更新：
The agent autonomy engine changes the state of the managed device by running Controls on the device. This is different from approaches where the behavior of a managed device is influenced by updating configuration values, such as in a table or datastore. Altering behavior via one or more Controls allows checking all preconditions before making changes as well as providing more granularity in the way in which the device is updated. Where necessary, Controls can be defined to perform bulk updates of configuration data so as not to lose that update modality. One important update precondition is that the system is not performing an action that would prevent the update (such as currently applying a competing update).
エージェントの自律エンジンは、デバイスでコントロールを実行することにより、管理されたデバイスの状態を変更します。これは、テーブルやデータストアなどの構成値を更新することにより、管理されたデバイスの動作が影響を受けるアプローチとは異なります。1つ以上のコントロールを介して動作を変更すると、変更を加える前にすべての前提条件をチェックするだけでなく、デバイスの更新方法をより詳細に提供することができます。必要に応じて、コントロールを定義して、その更新モダリティを失わないように、構成データのバルク更新を実行できます。重要な更新の前提条件の1つは、システムが更新を妨げるアクションを実行していないことです（現在競合するアップデートを適用しているなど）。
The expressive representation of simple data values is fundamental to the successful construction and evaluation of predicates in the DTNMA autonomy model. When defining such values, there are useful distinctions regarding how values are identified and whether values are generated in a way that is internal or external to the autonomy model.
単純なデータ値の表現的表現は、DTNMA自律モデルの述語の構築と評価の成功の基本です。そのような値を定義するとき、値の識別方法と、自律モデルの内部または外部の方法で値が生成されるかどうかに関して有用な区別があります。
A DTNMA data value should combine a base type (e.g., integer, real, string) representation with relevant semantic information. Base types are used for proper storage and encoding. Semantic information allows for additional typing, constraint definitions, and mnemonic naming. This expanded definition of data values allows for better predicate construction, better evaluation, and early type checking.
DTNMAデータ値は、関連するセマンティック情報とベースタイプ（整数、リアル、文字列）表現を組み合わせる必要があります。ベースタイプは、適切な保存とエンコードに使用されます。セマンティック情報により、追加のタイピング、制約定義、およびニーモニックネーミングが可能になります。この拡張されたデータ値の定義により、述語構築、より良い評価、および初期型チェックが可能になります。
Data values may further be annotated based on whether their value is the result of a DA calculation or the result of some external process on the managed device. For example, operators may wish to know which values can be updated by actions on the DA versus which values (such as sensor readings) cannot be reliably changed because they are calculated in a way that is external to the DA.
データ値は、その値がDAの計算の結果であるか、管理されたデバイス上の何らかの外部プロセスの結果であるかに基づいて、さらに注釈される場合があります。たとえば、オペレーターは、DAの外部の方法で計算されるため、どの値（センサーの測定値など）が確実に変更できないかをDAとどの値（センサーの測定値など）で更新できるかを知りたい場合があります。
The DTNMA autonomy model should, as required, report on the state of its managed device (to include the state of the model itself). This reporting should be done as a function of the changing state of the managed device, independent of the connection to any managing device. Queuing reports allows for later forensic analysis of device behavior; this feature is a desirable property of DTNMA management.
DTNMA自律モデルは、必要に応じて、その管理されたデバイスの状態について報告する必要があります（モデル自体の状態を含めるため）。このレポートは、管理されたデバイスへの接続とは無関係に、管理されたデバイスの変化する状態の関数として行う必要があります。キューイングレポートでは、デバイスの動作の後の法医学的分析が可能になります。この機能は、DTNMA管理の望ましいプロパティです。
DTNMA data reporting consists of the production of some data report instance conforming to a data report schema. The use of schemas allows a report instance to identify the schema to which it conforms instead of carrying the structure in the report itself. This approach can significantly reduce the size of generated reports.
DTNMAデータレポートは、データレポートスキーマに準拠したデータレポートインスタンスの生成で構成されています。スキーマの使用により、レポートインスタンスは、レポート自体に構造を運ぶ代わりに、それが適合するスキーマを識別できます。このアプローチは、生成されたレポートのサイズを大幅に削減できます。
The DTNMA data reporting concept is intentionally distinct from the concept of exchanging datastores across a network. It is envisioned that a DA might generate a data report instance of a data report schema at regular intervals or in response to local events. In this model, many report schemas may be defined to capture unique, relevant combinations of known data values rather than sending bulk datastores off-platform for analysis.
DTNMAデータレポートの概念は、ネットワーク全体のデータストアを交換するという概念と意図的に異なります。DAは、定期的に、またはローカルイベントに応じて、データレポートスキーマのデータレポートインスタンスを生成する可能性があることを想定しています。このモデルでは、分析のためにバルクデータストアをオフプラットフォームに送信するのではなく、既知のデータ値の一意で関連する組み合わせをキャプチャするために、多くのレポートスキーマを定義することができます。
NOTE: It is not required that data report schemas be tabular in nature. Individual implementations might define tabular schemas for table-like data and other report schemas for more heterogeneous reporting.
注：データレポートスキーマが本質的に表形式であることは必須ではありません。個々の実装は、テーブルのようなデータの表形式スキーマや、より異種レポートのためのその他のレポートスキーマを定義する場合があります。
The agent autonomy engine requires that managed devices issue commands on themselves as if they were otherwise being controlled by a managing device. The DTNMA implements commanding through the use of Controls and macros.
エージェントの自律性エンジンは、管理されたデバイスが自分自身のコマンドを発行することを要求しています。DTNMAは、コントロールとマクロを使用して指揮する実装を実施します。
Controls represent parameterized, predefined procedures run by the DA either as directed by the DM or as part of a rule response from the DA autonomy engine. Macros represent ordered sequences of Controls.
コントロールは、DMが指示するように、またはDA自律エンジンからのルール応答の一部として、DAによって実行されるパラメーター化された事前定義された手順を表します。マクロは、順序付けられたコントロールシーケンスを表します。
Controls are conceptually similar to RPCs in that they represent parameterized functions run on the managed device. However, they are conceptually dissimilar to RPCs in that they do not have a concept of a return code because they operate over an asynchronous transport. The concept of a return code in an RPC implies a synchronous relationship between the caller of the procedure and the procedure being called, which might not be possible within the DTNMA.
コントロールは、管理されたデバイスで実行されるパラメーター化された関数を表すという点で、RPCと概念的に類似しています。ただし、非同期輸送で動作するため、リターンコードの概念を持っていないという点で、RPCと概念的に類似しています。RPCにおける返品コードの概念は、手順の発信者と呼び出される手順との間の同期関係を意味します。これはDTNMA内では不可能かもしれません。
The success or failure of a Control may be handled locally by the agent autonomy engine. Local error handling is particularly important in this architecture, given the potential for long periods of disconnectivity between a DA and a DM. The failure of one or more Controls is part of the state of the DA and can be used to trigger rules within the DA autonomy engine.
コントロールの成功または失敗は、エージェントの自律エンジンによってローカルに処理される場合があります。このアーキテクチャでは、DAとDMの間の切断性の長時間の可能性を考えると、局所的なエラー処理が特に重要です。1つ以上のコントロールの障害はDAの状態の一部であり、DA自律エンジン内のルールをトリガーするために使用できます。
The impact of a Control is externally observable via the generation and eventual examination of data reports produced by the managed device.
コントロールの影響は、管理されたデバイスによって生成されたデータレポートの生成と最終的な調査を介して外部的に観察できます。
The failure of certain Controls might leave a managed device in an undesirable state. Therefore, it is important that there be consideration for Control-specific recovery mechanisms (such as a rollback or safing mechanism). When a Control that is part of a macro (such as in an autonomy response) fails, there may be a need to implement a safe state for the managed device based on the nature of the failure.
特定のコントロールの障害により、管理されたデバイスが望ましくない状態になる可能性があります。したがって、制御固有の回復メカニズム（ロールバックやセーフメカニズムなど）を考慮することが重要です。マクロの一部である（自律応答など）のコントロールが失敗する場合、障害の性質に基づいて管理されたデバイスに安全な状態を実装する必要がある場合があります。
NOTE: The use of the term "Control" in the DTNMA is derived in part from the concept of Command and Control (C2), where control implies the operational instructions undertaken to implement (or maintain) a commanded objective. The DA autonomy engine implements controls on a managed device to allow it to fulfill some commanded objective known by a (possibly disconnected) managing device.
注：DTNMAでの「コントロール」という用語の使用は、一部がコマンドとコントロール（C2）の概念から導き出されます。ここでは、コントロールは、指揮された目的を実装（または維持）するために行われた運用指示を意味します。DA Autonomy Engineは、管理されたデバイスの管理を実装して、（おそらく切断された）管理デバイスによって知られる指揮された目的を満たすことができるようにします。
For example, a device might be commanded to maintain a safe internal thermal environment. Actions taken by a DA to manage heaters, louvers, and other temperature-affecting components are controls taken in service of that commanded objective.
たとえば、安全な内部熱環境を維持するようにデバイスが命じられる場合があります。ヒーター、ルーバー、およびその他の温度に影響を与えるコンポーネントを管理するためにDAがとるアクションは、その指揮された目的の使用において取られたコントロールです。
As discussed in Section 9.1, the DTNMA rule-based stimulus-response system associates stimulus detection with a predetermined response. Rules may be categorized based on whether (1) their stimuli include generic statements of managed device state or (2) they are optimized to only consider the passage of time on the device.
セクション9.1で説明したように、DTNMAルールベースの刺激応答システムは、刺激の検出を所定の応答に関連付けます。ルールは、（1）それらの刺激に管理されたデバイス状態の一般的なステートメントが含まれているか、（2）デバイスの時間の経過を考慮するように最適化されているかどうかに基づいて分類される場合があります。
State-based rules are those whose stimulus is based on the evaluated state of the managed device. Time-based rules are a unique subset of state-based rules whose stimulus is given only by a time-based event. Implementations might create different structures and evaluation mechanisms for these two different types of rules to achieve more efficient processing on a platform.
状態ベースのルールとは、刺激が管理されたデバイスの評価された状態に基づいているルールです。時間ベースのルールは、時間ベースのイベントによってのみ刺激が与えられる状態ベースのルールのユニークなサブセットです。実装は、プラットフォーム上でより効率的な処理を実現するために、これら2つの異なるタイプのルールの異なる構造と評価メカニズムを作成する可能性があります。
Using the autonomy model defined in Section 9, this section describes flows through sample configurations conforming to the DTNMA. These use cases illustrate remote configuration, local monitoring and control, support for multiple DMs, and data fusion.
セクション9で定義されている自律モデルを使用して、このセクションでは、DTNMAに準拠したサンプル構成の流れについて説明します。これらのユースケースは、リモート構成、ローカル監視と制御、複数のDMのサポート、およびデータ融合を示しています。
The use cases presented in this section are documented with a shorthand notation to describe the types of data sent between managers and agents. This notation, outlined in Table 1, leverages the definitions of the autonomy model components defined in Section 9.
このセクションで提示されたユースケースは、マネージャーとエージェント間で送信されるデータの種類を説明する速記表記で文書化されています。表1に概説されているこの表記法は、セクション9で定義されている自律モデルコンポーネントの定義を活用しています。
+==============+=======================================+===========+
| Term | Definition | Example |
+==============+=======================================+===========+
| EDD# | Externally Defined Data -- a data | EDD1, |
| | value defined in a way that is | EDD2 |
| | external to the DA. | |
+--------------+---------------------------------------+-----------+
| V# | Variable -- a data value defined in a | V1 = EDD1 |
| | way that is internal to the DA. | + 7 |
+--------------+---------------------------------------+-----------+
| EXPR | Predicate expression -- used to | V1 > 5 |
| | define a rule stimulus. | |
+--------------+---------------------------------------+-----------+
| ID | DTNMA Object Identifier. | V1, EDD2 |
+--------------+---------------------------------------+-----------+
| ACL# | Enumerated Access Control List. | ACL1 |
+--------------+---------------------------------------+-----------+
| DEF(ACL, ID, | Define "ID" from expression. Allow | DEF(ACL1, |
| EXPR) | DMs in ACL to see this ID. | V1, EDD1 |
| | | + EDD2) |
+--------------+---------------------------------------+-----------+
| PROD(P, ID) | Produce "ID" according to predicate | PROD(1s, |
| | P. P may be a time period (1 second, | EDD1) |
| | or 1s) or an expression (EDD1 > 10). | |
+--------------+---------------------------------------+-----------+
| RPT(ID) | A report instance containing data | RPT(EDD1) |
| | named "ID". | |
+--------------+---------------------------------------+-----------+
Table 1: Terminology
表1：用語
These notations do not imply any implementation approach. They only provide a succinct syntax for expressing the data flows in the use case diagrams in the remainder of this section.
これらの表記は、実装アプローチを意味するものではありません。このセクションの残りの部分で、ユースケース図でデータフローを表現するための簡潔な構文のみを提供します。
This nominal configuration shows a single DM interacting with multiple DAs. The control flow for this scenario is outlined in Figure 4.
この公称構成は、複数のDAと相互作用する単一のDMを示しています。このシナリオの制御フローを図4に概説しています。
+-----------+ +---------+ +---------+
| DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Agent B |
+----+------+ +----+----+ +----+----+
| | |
|-----PROD(1s, EDD1)--->| | (1)
|----------------------------PROD(1s, EDD1)-->|
| | |
| | |
|<-------RPT(EDD1)------| | (2)
|<----------------------------RPT(EDD1)-------|
| | |
| | |
|<-------RPT(EDD1)------| |
|<----------------------------RPT(EDD1)-------|
| | |
| | |
|<-------RPT(EDD1)------| |
|<----------------------------RPT(EDD1)-------|
| | |
Figure 4: Serialized Management Control Flow
図4：シリアル化された管理制御フロー
In a serialized management scenario, a single DM interacts with multiple DAs.
シリアル化された管理シナリオでは、単一のDMが複数のDAと相互作用します。
In this figure, DM A sends a policy to DAs A and B to report the value of an EDD (EDD1) every second (step 1). Each DA receives this policy and configures their respective autonomy engines for this production. Thereafter (step 2), each DA produces a report containing data element EDD1; each such report is then sent back to the DM.
この図では、DM AはDAS AとBにポリシーを送信して、EDD（EDD1）の値を1秒ごとに報告します（ステップ1）。各DAはこのポリシーを受け取り、この生産のためにそれぞれの自律エンジンを構成します。その後（ステップ2）、各DAはデータ要素EDD1を含むレポートを作成します。そのような各レポートは、DMに送り返されます。
This behavior continues without any additional communications from the DM.
この動作は、DMからの追加の通信なしで続きます。
Building on the nominal configuration discussed in Section 10.2, this scenario shows a challenged network in which connectivity between DA B and the DM is temporarily lost. The control flow for this case is outlined in Figure 5.
セクション10.2で説明した名目上の構成に基づいて、このシナリオは、DA BとDM間の接続性が一時的に失われる挑戦的なネットワークを示しています。このケースの制御フローを図5に概説しています。
+-----------+ +---------+ +---------+
| DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Agent B |
+----+------+ +----+----+ +----+----+
| | |
|-----PROD(1s, EDD1)--->| | (1)
|----------------------------PROD(1s, EDD1)-->|
| | |
| | |
|<-------RPT(EDD1)------| | (2)
|<----------------------------RPT(EDD1)-------|
| | |
| | |
|<-------RPT(EDD1)------| |
|<----------------------------RPT(EDD1)-------|
| | |
| | |
|<-------RPT(EDD1)------| |
| | RPT(EDD1)| (3)
| | |
| | |
|<-------RPT(EDD1)------| |
| | RPT(EDD1)| (4)
| | |
| | |
|<-------RPT(EDD1)------| |
|<----------------RPT(EDD1), RPT(EDD1)--------| (5)
| | |
Figure 5: Challenged Management Control Flow
図5：挑戦された管理制御フロー
In a challenged network, DAs store reports, pending a transmit opportunity.
挑戦されたネットワークでは、Das Storeが報告し、送信機会が保留されています。
In this figure, DM A sends a policy to DAs A and B to produce an EDD (EDD1) every second (step 1). Each DA receives this policy and configures their respective autonomy engines for this production. Produced reports are transmitted when there is connectivity between the DA and DM (step 2).
この図では、DM AはDas AとBにポリシーを送信して、1秒ごとにEDD（EDD1）を作成します（ステップ1）。各DAはこのポリシーを受け取り、この生産のためにそれぞれの自律エンジンを構成します。作成されたレポートは、DAとDMの間に接続性がある場合に送信されます（ステップ2）。
At some point, DA B loses the ability to transmit in the network (steps 3 and 4). During this time period, DA B continues to produce reports, but they are queued for transmission. This queuing might be done by the DA itself or by a supporting transport such as BP. Eventually (and before the next scheduled production of EDD1), DA B is able to transmit in the network again (step 5), and all queued reports are sent at that time. DA A maintains connectivity with the DM during steps 3-5 and continues to send reports as they are generated.
ある時点で、Da Bはネットワーク内で送信する能力を失います（ステップ3および4）。この期間中、DA Bはレポートの作成を続けていますが、伝送のために列に並んでいます。このキューイングは、DA自体またはBPなどのサポートトランスポートによって行われる場合があります。最終的に（そして次のスケジュールされたEDD1の生産の前）、DA Bは再びネットワークで送信することができ（ステップ5）、その時点ですべてのキューに登録されたレポートが送信されます。DA Aは、ステップ3-5でDMとの接続性を維持し、生成されたレポートを送信し続けます。
This scenario illustrates the DTNMA open-loop control paradigm, where DAs manage themselves in accordance with policies provided by DMs and provide reports to DMs based on these policies.
このシナリオは、DTNMAオープンループ制御パラダイムを示しています。ここでは、DASはDMSが提供するポリシーに従って自分自身を管理し、これらのポリシーに基づいてDMSにレポートを提供します。
The control flow shown in Figure 6 includes an example of data fusion, where multiple policies configured by a DM result in a single report from a DA.
図6に示す制御フローには、DMによって構成された複数のポリシーがDAからの単一のレポートになります。
+-----------+ +---------+ +---------+
| DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Agent B |
+----+------+ +----+----+ +----+----+
| | |
|-----PROD(1s, EDD1)--->| | (1)
|----------------------------PROD(1s, EDD1)-->|
| | |
| | |
|<-------RPT(EDD1)------| | (2)
|<----------------------------RPT(EDD1)-------|
| | |
| | |
|----------------------------PROD(1s, EDD2)-->| (3)
| | |
| | |
|<-------RPT(EDD1)------| |
|<-------------------------RPT(EDD1, EDD2)----| (4)
| | |
| | |
|<-------RPT(EDD1)------| |
|<-------------------------RPT(EDD1, EDD2)----|
| | |
Figure 6: Consolidated Management Control Flow
図6：統合された管理制御フロー
A many-to-one mapping between management policy and device state reporting is supported by the DTNMA.
管理ポリシーとデバイス状態レポートの間の多面マッピングは、DTNMAによってサポートされています。
In this figure, DM A sends a policy statement in the form of a rule to DAs A and B, which instructs the DAs to produce a report for EDD1 every second (step 1). Each DA receives this policy, which is stored in its respective rule database, and configures its autonomy engine. Reports are transmitted by each DA when produced (step 2).
この図では、DM Aは、DAS AとBにルールの形でポリシーステートメントを送信します。これは、DASにEDD1のレポートを1秒ごとに作成するよう指示します（ステップ1）。各DAは、それぞれのルールデータベースに保存されているこのポリシーを受け取り、自律エンジンを構成します。レポートは、作成時に各DAによって送信されます（ステップ2）。
At a later time, DM A sends an additional policy to DA B, requesting the production of a report for EDD2 every second (step 3). This policy is added to DA B's rule database.
後で、DM AはDA Bに追加のポリシーを送信し、1秒ごとにEDD2のレポートの作成を要求します（ステップ3）。このポリシーは、DA Bのルールデータベースに追加されます。
Following this policy update, DA A will continue to produce EDD1, and DA B will produce both EDD1 and EDD2 (step 4). However, DA B may provide these values to the DM in a single report rather than as two independent reports. In this way, there is no direct mapping between the consolidated reports sent by DA B (from step 4 onwards) and the two different policies sent to DA B (steps 1 and 3) that produce the information included in those consolidated reports.
このポリシーの更新に続いて、DA Aは引き続きEDD1を生成し、DA BはEDD1とEDD2の両方を生成します（ステップ4）。ただし、DA Bは、2つの独立したレポートとしてではなく、単一のレポートでこれらの値をDMに提供する場合があります。このようにして、DA Bが送信した連結レポート（ステップ4以降）とDA B（ステップ1および3）に送信された2つの異なるポリシーとの間に直接マッピングはありません。
The managed applications on a DA may be controlled by different administrative entities in a network. The DTNMA allows DAs to communicate with multiple DMs in the network, such as in cases where there is one DM per administrative domain.
DAのマネージドアプリケーションは、ネットワーク内のさまざまな管理エンティティによって制御される場合があります。DTNMAにより、DASは、管理ドメインごとに1つのDMがある場合など、ネットワーク内の複数のDMと通信できます。
Whenever a DM sends a policy expression to a DA, that policy expression may be associated with authorization information. One method of representing this is an ACL.
DMがポリシー表現をDAに送信するたびに、そのポリシー表現は認証情報に関連付けられている可能性があります。これを表現する1つの方法はACLです。
The use of an ACL in this use case does not imply that the DTNMA requires ACLs to annotate policy expressions. ACLs and their representation in this context are for example purposes only.
このユースケースでのACLの使用は、DTNMAがポリシー式に注釈を付けるためにACLSを必要とすることを意味するものではありません。この文脈でのACLとその表現は、たとえば目的のみです。
The ability of one DM to access the results of policy expressions configured by some other DM will be limited to the authorization annotations of those policy expressions.
他のDMによって構成されたポリシー式の結果にアクセスする1つのDMの能力は、これらのポリシー式の認可注釈に限定されます。
An example of multi-manager authorization is illustrated in Figure 7.
マルチマネージャー認証の例を図7に示します。
+-----------+ +---------+ +-----------+
| DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Manager B |
+-----+-----+ +----+----+ +-----+-----+
| | |
|--DEF(ACL1, V1, EDD1*2)-->|<---DEF(ACL2, V2, EDD2*2)---| (1)
| | |
|---PROD(1s, V1)---------->|<---PROD(1s, V2)------------| (2)
| | |
|<--------RPT(V1)----------| | (3)
| |--------RPT(V2)------------>|
|<--------RPT(V1)----------| |
| |--------RPT(V2)------------>|
| | |
| |<---PROD(1s, V1)------------| (4)
| | |
| |---ERR(V1 not permitted)--->|
| | |
|--DEF(NULL, V3, EDD3*3)-->| | (5)
| | |
|---PROD(1s, V3)---------->| | (6)
| | |
| |<----PROD(1s, V3)-----------|
| | |
|<--------RPT(V3)----------|--------RPT(V3)------------>| (7)
|<--------RPT(V1)----------| |
| |--------RPT(V2)------------>|
|<-------RPT(V3)-----------|--------RPT(V3)------------>|
|<-------RPT(V1)-----------| |
| |--------RPT(V2)------------>|
Figure 7: Multiplexed Management Control Flow
図7：多重化された管理制御フロー
Multiple DMs may interface with a single DA, particularly in complex networks.
複数のDMは、特に複雑なネットワークで、単一のDAとのインターフェースがあります。
In this figure, both DM A and DM B send policies to DA A (step 1). DM A defines a variable (V1) whose value is given by the mathematical expression (EDD1 * 2) and is associated with an ACL (ACL1) that restricts access to V1 to DM A only. Similarly, DM B defines a variable (V2) whose value is given by the mathematical expression (EDD2 * 2) and is associated with an ACL (ACL2) that restricts access to V2 to DM B only.
この図では、DM AとDM Bの両方がDA Aにポリシーを送信します（ステップ1）。DM Aは、数学的式（EDD1 * 2）によって値が与えられ、V1へのアクセスのみをDM Aのみを制限するACL（ACL1）に関連付けられている変数（V1）を定義します。同様に、DM Bは、数学的式（EDD2 * 2）によって値が与えられた変数（V2）を定義し、V2へのアクセスをDM Bのみに制限するACL（ACL2）に関連付けられています。
Both DM A and DM B also send policies to DA A to report on the values of their variables at 1-second intervals (step 2). Since DM A can access V1 and DM B can access V2, there is no authorization issue with these policies, and they are both accepted by the autonomy engine on DA A. DA A produces reports as expected, sending them to their respective managers (step 3).
DM AとDM Bの両方は、1秒間隔で変数の値を報告するためにポリシーをDA Aに送信します（ステップ2）。DM AはV1とDM BがV2にアクセスできるため、これらのポリシーに許可の問題はありません。どちらもDa A. Aの自律エンジンに受け入れられています。3）。
Later (step 4), DM B attempts to configure DA A to also report to it the value of V1. Since DM B does not have authorization to view this variable, DA A does not include this in the configuration of its autonomy engine; instead, some indication of a permission error is included in any regular reporting back to DM B.
後で（ステップ4）、DM BはDA Aを構成してV1の値を報告しようとします。DM Bにはこの変数を表示する許可がないため、DA Aは自律エンジンの構成にこれを含めません。代わりに、DM Bに戻る定期的なレポートに許可エラーのいくつかの兆候が含まれています。
DM A also sends a policy to DA A (step 5) that defines a variable (V3) whose value is given by the mathematical expression (EDD3 * 3) and is not associated with an ACL, indicating that any DM can access V3. In this instance, both DM A and DM B can then send policies to DA A to report the value of V3 (step 6). Since there is no authorization restriction on V3, these policies are accepted by the autonomy engine on DA A, and reports are sent to both DM A and DM B over time (step 7).
DM Aは、数学的式（EDD3 * 3）によって値が与えられ、ACLに関連付けられていない変数（V3）を定義するDA A（ステップ5）にポリシーを送信し、DMがV3にアクセスできることを示しています。この例では、DM AとDM Bの両方がDA Aにポリシーを送信してV3の値を報告できます（ステップ6）。V3に認可制限がないため、これらのポリシーはDA Aの自律エンジンによって受け入れられ、レポートは時間の経過とともにDM AとDM Bの両方に送信されます（ステップ7）。
There are times when a single network device may serve as both a DM for other DAs in the network and, itself, as a device managed by someone else. This may be the case on nodes serving as gateways or proxies. The DTNMA accommodates this case by allowing a single device to run both a DA and a DM.
単一のネットワークデバイスは、ネットワーク内の他のDASのDMとして、およびそれ自体が他の誰かによって管理されているデバイスとして機能する場合があります。これは、ゲートウェイまたはプロキシとして機能するノードの場合かもしれません。DTNMAは、単一のデバイスがDAとDMの両方を実行できるようにすることにより、このケースに対応します。
An example of this configuration is illustrated in Figure 8.
この構成の例を図8に示します。
---------------------------------------
| Node B |
| |
+-----------+ | +-----------+ +---------+ | +---------+
| DTNMA | | | DTNMA | | DTNMA | | | DTNMA |
| Manager A | | | Manager B | | Agent B | | | Agent C |
+---+-------+ | +-----+-----+ +----+----+ | +----+----+
| | | | | |
|----------DEF(NULL, V0, EDD1 + EDD2)-->| | | (1)
|-------------PROD(1s, V0)------------->| | |
| | | | | |
| | |-PROD(1s, EDD1)-->| | | (2)
| | |--------------------PROD(1s, EDD2)-->| (2)
| | | | | |
| | | | | |
| | |<----RPT(EDD1)----| | | (3)
| | |<--------------------RPT(EDD2)-------| (3)
| | | | | |
|<-------------RPT(V0)------------------| | | (4)
| | | | | |
| | | | | |
| |
| |
---------------------------------------
Figure 8: Cascading Management Control Flow
図8：カスケード管理制御フロー
A device can operate as both a DM and a DA.
デバイスは、DMとDAの両方として動作できます。
In this example, we presume that DA B is able to sample a given EDD (EDD1) and that DA C is able to sample a different EDD (EDD2). Node B houses DM B (which controls DA C) and DA B (which is controlled by DM A). DM A must periodically receive some new value that is calculated as a function of both EDD1 and EDD2.
この例では、DA Bは特定のEDD（EDD1）をサンプリングできること、DA Cが別のEDD（EDD2）をサンプリングできると仮定します。ノードBには、DM B（DA Cを制御）およびDA B（DM Aによって制御されています）があります。DM Aは、EDD1とEDD2の両方の関数として計算される新しい値を定期的に受信する必要があります。
First, DM A sends a policy to DA B to define a variable (V0) whose value is given by the mathematical expression (EDD1 + EDD2) without a restricting ACL. Further, DM A sends a policy to DA B to report on the value of V0 every second (step 1).
まず、DM AはDA Bにポリシーを送信して、ACLを制限せずに数学的式（EDD1 + EDD2）によって値が与えられる変数（V0）を定義します。さらに、DM AはDA Bにポリシーを送信して、1秒ごとにV0の値を報告します（ステップ1）。
DA B needs the ability to monitor both EDD1 and EDD2 to produce V0. DA B is able to sample EDD1, so DM B sends a policy to DA B to report on the value of EDD1. However, the only way to receive EDD2 values is to have them reported back to Node B by DA C and included in the Node B runtime datastores. Therefore, DM B also sends a policy to DA C to report on the value of EDD2 (step 2).
DA Bには、V0を生成するためにEDD1とEDD2の両方を監視する機能が必要です。DA BはEDD1をサンプリングできるため、DM BはDA Bにポリシーを送信して、EDD1の値を報告します。ただし、EDD2値を受信する唯一の方法は、DA CによってノードBに報告され、ノードBランタイムデータストアに含まれることです。したがって、DM BはDA Cにポリシーを送信して、EDD2の価値を報告します（ステップ2）。
DA B receives the policy in its autonomy engine and produces reports on the value of EDD2 every second. Similarly, DA C receives the policy in its autonomy engine and produces reports on the value of EDD2 every second (step 3).
DA Bは、自律エンジンでポリシーを受け取り、毎秒EDD2の価値に関するレポートを作成します。同様に、DA Cは自律エンジンでポリシーを受け取り、毎秒EDD2の価値に関するレポートを作成します（ステップ3）。
DA B may locally sample EDD1 and EDD2 and uses that to compute values of V0 and report on those values at regular intervals to DM A (step 4).
DA BはEDD1とEDD2を局所的にサンプリングすることができ、それを使用してV0の値を計算し、それらの値を定期的にDM Aに報告します（ステップ4）。
While a trivial example, the mechanism of associating fusion with the DA function rather than the DM function scales with fusion complexity. Within the DTNMA, DAs and DMs are not required to be separate software implementations. There may be a single software application running on Node B implementing both DM B and DA B roles.
些細な例ですが、DM関数が融合の複雑さを伴うのではなく、融合をDA関数に関連付けるメカニズム。DTNMA内では、DASとDMSは別々のソフトウェア実装である必要はありません。DM BとDA Bの両方の役割を実装するノードBで実行されている単一のソフトウェアアプリケーションがある場合があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Security within a DTNMA exists in at least the following two layers: security in the data model and security in the messaging and encoding of the data model.
DTNMA内のセキュリティは、少なくとも次の2つのレイヤーに存在します：データモデルのセキュリティとデータモデルのメッセージングとエンコードのセキュリティ。
Data model security refers to the validity and accessibility of data elements. For example, a data element might be available to certain DAs or DMs in a system, whereas the same data element may be hidden from other DAs or DMs. Both verification and authorization mechanisms at DAs and DMs are important to achieve this type of security.
データモデルセキュリティとは、データ要素の有効性とアクセシビリティを指します。たとえば、システム内の特定のDASまたはDMSがデータ要素を使用できる場合がありますが、同じデータ要素は他のDASまたはDMSから隠されている場合があります。このタイプのセキュリティを達成するには、DASとDMSでの検証メカニズムと承認メカニズムの両方が重要です。
NOTE: One way to provide finer-grained application security is through the use of ACLs that would be defined as part of the configuration of DAs and DMs. It is expected that many common data model tools provide mechanisms for the definition of ACLs and best practices for their operational use.
注：より細かい粒度のアプリケーションセキュリティを提供する1つの方法は、DASおよびDMSの構成の一部として定義されるACLSを使用することです。多くの一般的なデータモデルツールは、ACLSの定義のメカニズムと運用用のベストプラクティスを提供することが期待されています。
The exchange of information between and amongst DAs and DMs in the DTNMA is expected to be accomplished through some secured messaging transport.
DTNMAのDASとDMの間で情報の交換は、一部の安全なメッセージングトランスポートを通じて達成されると予想されます。
[ASN.1] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[CORE-COMI]
Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Ed.,
Bierman, A., and C. Bormann, Ed., "CoAP Management
Interface (CORECONF)", Work in Progress, Internet-Draft,
draft-ietf-core-comi-19, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
comi-19>.
[DART] Tropf, B. T., Haque, M., Behrooz, N., and C. Krupiarz,
"The DART Autonomy System", DOI 10.1109/SMC-
IT56444.2023.00020, August 2023,
<https://ieeexplore.ieee.org/abstract/document/10207457>.
[gNMI] Borman, P., Hines, M., Lebsack, C., Morrow, C., Shaikh,
A., Shakir, R., Li, W., and D. Loher, "gRPC Network
Management Interface (gNMI)", Version 10.0, May 2023,
<https://www.openconfig.net/docs/gnmi/gnmi-
specification/>.
[gRPC] gRPC Authors, "gRPC Documentation", 2024,
<https://grpc.io/docs/>.
[IPMI] Intel, Hewlett-Packard, NEC, and Dell, "Intelligent
Platform Management Interface Specification, Second
Generation", Version 2.0, October 2013,
<https://www.intel.la/content/dam/www/public/us/en/
documents/specification-updates/ipmi-intelligent-platform-
mgt-interface-spec-2nd-gen-v2-0-spec-update.pdf>.
[NEW-HORIZONS]
Moore, R. C., "Autonomous safeing and fault protection for
the New Horizons mission to Pluto", Acta Astronautica,
Volume 61, Issues 1-6, June-August 2007, Pages 398-405,
DOI 10.1016/j.actaastro.2007.01.009, August 2007,
<https://www.sciencedirect.com/science/article/pii/
S0094576507000604>.
[PROTOCOL-BUFFERS]
Stuart, S. and R. Fernando, "Encoding rules and MIME type
for Protocol Buffers", Work in Progress, Internet-Draft,
draft-rfernando-protocol-buffers-00, 8 October 2012,
<https://datatracker.ietf.org/doc/html/draft-rfernando-
protocol-buffers-00>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<https://www.rfc-editor.org/info/rfc2578>.
[RFC2982] Kavasseri, R., Ed., "Distributed Management Expression
MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000,
<https://www.rfc-editor.org/info/rfc2982>.
[RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed
Objects for the Delegation of Management Scripts",
RFC 3165, DOI 10.17487/RFC3165, August 2001,
<https://www.rfc-editor.org/info/rfc3165>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410,
DOI 10.17487/RFC3410, December 2002,
<https://www.rfc-editor.org/info/rfc3410>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414,
DOI 10.17487/RFC3414, December 2002,
<https://www.rfc-editor.org/info/rfc3414>.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
<https://www.rfc-editor.org/info/rfc3416>.
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3417,
DOI 10.17487/RFC3417, December 2002,
<https://www.rfc-editor.org/info/rfc3417>.
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, DOI 10.17487/RFC3418, December 2002,
<https://www.rfc-editor.org/info/rfc3418>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
<https://www.rfc-editor.org/info/rfc5591>.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June
2009, <https://www.rfc-editor.org/info/rfc5592>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[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>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
<https://www.rfc-editor.org/info/rfc6353>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[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>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[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>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[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>.
[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>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
[RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
C., and M. Richardson, "Encoding of Data Modeled with YANG
in the Concise Binary Object Representation (CBOR)",
RFC 9254, DOI 10.17487/RFC9254, July 2022,
<https://www.rfc-editor.org/info/rfc9254>.
[RFC9595] Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed.,
Bormann, C., and M. Richardson, "YANG Schema Item
iDentifier (YANG SID)", RFC 9595, DOI 10.17487/RFC9595,
July 2024, <https://www.rfc-editor.org/info/rfc9595>.
[xml-infoset]
Cowan, J., Ed. and R. Tobin, Ed., "XML Information Set
(Second Edition)", W3C Recommendation REC-xml-infoset-
20040204, February 2004,
<https://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
[XPath] Robie, J., Ed., Dyck, M., Ed., and J. Spiegel, Ed., "XML
Path Language (XPath) 3.1", March 2017,
<https://www.w3.org/TR/2017/REC-xpath-31-20170321/>.
Latest version available at
<https://www.w3.org/TR/xpath-31/>.
Brian Sipos of the Johns Hopkins University Applied Physics Laboratory (JHU/APL) provided excellent technical review of the DTNMA concepts presented in this document and additional information related to existing network management techniques.
ジョンズホプキンス大学のブライアンSipos Applied Physics Laboratory（JHU/APL）は、この文書に示されているDTNMAコンセプトと既存のネットワーク管理手法に関連する追加情報の優れた技術レビューを提供しました。
Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu
Sarah Heiner
The Johns Hopkins University Applied Physics Laboratory
Email: Sarah.Heiner@jhuapl.edu
Emery Annis
The Johns Hopkins University Applied Physics Laboratory
Email: Emery.Annis@jhuapl.edu