[要約] RFC 8991は、GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP) に関する文書です。このRFCは、自律的なネットワーク要素間の発見、メッセージ交換、およびネゴシエーションを可能にするためのAPIを定義しています。主に、自律的な運用を必要とするネットワークシステムやアプリケーションで利用されます。
From: draft-ietf-anima-grasp-api-10 Informational
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 8991 Univ. of Auckland
Category: Informational B. Liu, Ed.
ISSN: 2070-1721 Huawei Technologies
W. Wang
X. Gong
BUPT University
May 2021
GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)
一般自律神経シグナリングプロトコルアプリケーションプログラムインタフェース（GRASP API）
Abstract
概要
This document is a conceptual outline of an Application Programming Interface (API) for the GeneRic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASAs) calling the GRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems.
この文書は、一般自律神経シグナリングプロトコル（GRASP）のためのアプリケーションプログラミングインタフェース（API）の概念的な概要です。そのようなAPIは、把握プロトコルモジュールを呼び出して自律型ネットワークメッセージを他のASAと交換するために呼び出すために必要とされる。GRASPは非同期操作をサポートするように設計されているので、APIはさまざまなプログラミング言語およびオペレーティングシステムの非同期性のサポートに従って適応される必要があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8991.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8991で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. GRASP API for ASA
2.1. Design Assumptions
2.2. Asynchronous Operations
2.2.1. Alternative Asynchronous Mechanisms
2.2.2. Multiple Negotiation Scenario
2.2.3. Overlapping Sessions and Operations
2.2.4. Session Termination
2.3. API Definition
2.3.1. Overview of Functions
2.3.2. Parameters and Data Structures
2.3.3. Registration
2.3.4. Discovery
2.3.5. Negotiation
2.3.6. Synchronization and Flooding
2.3.7. Invalid Message Function
3. Security Considerations
4. IANA Considerations
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Error Codes
Acknowledgements
Authors' Addresses
As defined in [RFC8993], the Autonomic Service Agent (ASA) is the atomic entity of an autonomic function, and it is instantiated on autonomic nodes. These nodes are members of a secure Autonomic Control Plane (ACP) such as defined by [RFC8994].
[RFC8993]で定義されているように、自律型サービスエージェント（ASA）は自律型関数のアトミックエンティティであり、それは自律ノードでインスタンス化されます。これらのノードは、[RFC8994]で定義されているようなセキュアオートノミック制御プレーン（ACP）のメンバーです。
When ASAs communicate with each other, they should use the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990]. GRASP relies on the message confidentiality and integrity provided by the ACP; a consequence of this is that all nodes in a given Autonomic Network share the same trust boundary, i.e., the boundary of the ACP. Nodes that have not successfully joined the ACP cannot send, receive, or intercept GRASP messages via the ACP and cannot usurp ACP addresses. An ASA runs in an ACP node and therefore benefits from the node's security properties when transmitting over the ACP, i.e., message integrity, message confidentiality, and the fact that unauthorized nodes cannot join the ACP. All ASAs within a given Autonomic Network therefore trust each other's messages. For these reasons, the API defined in this document has no explicit security features.
ASASが互いに通信すると、それらは一般的なオートノミックシグナリングプロトコル（GRASP）[RFC8990]を使用する必要があります。GRASPは、ACPによって提供されるメッセージの機密性と整合性に依存しています。その結果、特定の自律神経ネットワーク内のすべてのノードは、同じ信頼境界、すなわちACPの境界を共有することである。ACPに正常に参加していないノードは、ACPを介してgraspメッセージを送信、受信、または傍受することはできず、ACPアドレスをUSURPすることはできません。ASAはACPノードで実行され、したがって、ACP、すなわちメッセージの整合性、メッセージの機密性、および不正なノードがACPに参加できないという事実が送信されるときに、ノードのセキュリティプロパティから利点があります。したがって、特定のオートノミックネットワーク内のすべてのASAは互いのメッセージを信頼します。これらの理由から、この文書で定義されているAPIには明示的なセキュリティ機能がありません。
An important feature of GRASP is the concept of a GRASP objective. This is a data structure encoded, like all GRASP messages, in Concise Binary Object Representation (CBOR) [RFC8949]. Its main contents are a name and a value, explained at more length in the Terminology section of [RFC8990]. When an objective is passed from one ASA to another using GRASP, its value is either conveyed in one direction (by a process of synchronization or flooding) or negotiated bilaterally. The semantics of the value are opaque to GRASP and therefore to the API. Each objective must be accurately specified in a dedicated specification, as discussed in "Objective Options" (Section 2.10 of [RFC8990]). In particular, the specification will define the syntax and semantics of the value of the objective, whether and how it supports a negotiation process, whether it supports a dry-run mode, and any other details needed for interoperability. The use of CBOR, with Concise Data Definition Language (CDDL) [RFC8610] as the data definition language, allows the value to be passed between ASAs regardless of the programming languages in use. Data storage and consistency during negotiation are the responsibility of the ASAs involved. Additionally, GRASP needs to cache the latest values of objectives that are received by flooding.
GRASPの重要な特徴は、把握目的の概念です。これは、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]で、すべてのGRASPメッセージと同様に、符号化されたデータ構造です。その主な内容は、[RFC8990]の「用語」セクションで、より多くの長さで説明されている名前と値です。 Graspを使用して対物レンズがあるASAから別のASAに渡されると、その値は一方向に（同期またはフラッディングのプロセスによって）搬送されるか、または左側にネゴシエートされます。値の意味論は把握するための不透明であり、したがってAPIに向かっています。 「目的オプション」（[RFC8990]のセクション2.10）で説明したように、各目的は専用の仕様で正確に指定されている必要があります。特に、この仕様は、それがドライランモードをサポートしているかどうか、および相互運用性に必要な他の詳細をサポートするかどうか、およびそれがどのようにしているかどうか、およびそれがどのようにしてどのように必要かをサポートするかどうか、およびそれがどのようにどのようにサポートされているかにかかわらず、その指定の意味を定義します。 CBORの使用、簡潔なデータ定義言語（CDDL）[RFC8610]データ定義言語として、使用中のプログラミング言語に関係なく、ASAS間で値を渡すことができます。交渉中のデータ保存と一貫性は、関係するASAの責任です。さらに、把握は、フラッディングによって受信された目的の最新の値をキャッシュする必要があります。
As Figure 1 shows, a GRASP implementation could contain several sub-layers. The bottom layer is the GRASP base protocol module, which is only responsible for sending and receiving GRASP messages and maintaining shared data structures. Above that is the basic API described in this document. The upper layer contains some extended API functions based upon the GRASP basic protocol. For example, [GRASP-DISTRIB] describes a possible extended function.
図1が示すように、把握実装はいくつかの副層を含むことができる。最下層はGRASSベースプロトコルモジュールであり、これはメッセージを送信および受信し、共有データ構造を維持する責任がある。上記のものは、この文書に記載されている基本的なAPIです。上位層には、GRASP基本プロトコルに基づくいくつかの拡張API関数が含まれています。たとえば、[把握分配]は、可能な拡張機能を説明しています。
+--------------+ +--------------+
| ASAs | | ASAs |
+--------------+ +--------------+
| | |
| +------------------+ |
| | GRASP Extended | |
| | Function API | |
| +------------------+ |
| | |
+------------------------------------------+
| Basic GRASP API Library |
+------------------------------------------+
|
IPC or system call
|
+------------------------------------------+
| GRASP Core |
| (functions, data structures, daemon(s)) |
+------------------------------------------+
Figure 1: Software Layout
図1：ソフトウェアレイアウト
Multiple ASAs in a single node will share the same instance of GRASP, much as multiple applications share a single TCP/IP stack. This aspect is hidden from individual ASAs by the API and is not further discussed here.
単一のノード内の複数のASAは、複数のアプリケーションが単一のTCP / IPスタックを共有するため、同じIGASPのインスタンスを共有します。この側面は、APIによって個々のASAから隠されており、ここではこれ以上議論されていない。
It is desirable that ASAs be designed as portable user-space programs using a system-independent API. In many implementations, the GRASP code will therefore be split between user space and kernel space. In user space, library functions provide the API and communicate directly with ASAs. In kernel space, a daemon, or a set of sub-services, provides GRASP core functions that are independent of specific ASAs, such as multicast handling and relaying, and common data structures, such as the discovery cache. The GRASP API library would need to communicate with the GRASP core via an interprocess communication (IPC) or a system call mechanism. The details of this are system-dependent.
ASAは、システムに依存しないAPIを使用して携帯型ユーザ空間プログラムとして設計されることが望ましい。多くの実装形態では、把握コードはユーザ空間とカーネル空間の間で分割されます。ユーザースペースでは、ライブラリ関数はAPIを提供し、ASASと直接通信します。カーネルスペース、デーモン、または一連のサブサービスでは、マルチキャスト処理や中継などの特定のASAとは無関係のGraspコア機能、およびディスカバリキャッシュなどの一般的なデータ構造が提供されています。GRASP APIライブラリは、プロセス間通信（IPC）またはシステムコールメカニズムを介してGRASPコアと通信する必要があります。これの詳細はシステム依存です。
Both the GRASP library and the extended function modules should be available to the ASAs. However, since the extended functions are expected to be added in an incremental manner, they will be the subject of future documents. This document only describes the basic GRASP API.
GRASPライブラリと拡張機能モジュールの両方がASASに利用可能になるはずです。ただし、拡張機能は増分的に追加されると予想されるので、それらは将来の文書の主題になります。この文書では、基本把握APIのみを説明しています。
The functions provided by the API do not map one-to-one onto GRASP messages. Rather, they are intended to offer convenient support for message sequences (such as a discovery request followed by responses from several peers or a negotiation request followed by various possible responses). This choice was made to assist ASA programmers in writing code based on their application requirements rather than needing to understand protocol details.
APIによって提供される関数は、1対1を把握メッセージにマッピングしません。むしろ、それらはメッセージシーケンス（たびにいくつかのピアからの応答またはネゴシエーションリクエストなどの回答などの応答などの応答などの応答など）を提供することを目的としています。この選択は、プロトコルの詳細を理解するのを必要とするのではなく、アプリケーションの要件に基づいてコードを書くのを支援するために作られました。
In addition to containing the autonomic infrastructure components described in [RFC8994] and [RFC8995], a simple autonomic node might contain very few ASAs. Such a node might directly integrate a GRASP protocol stack in its code and therefore not require this API to be installed. However, the programmer would need a deeper understanding of the GRASP protocol than what is needed to use the API.
[RFC8994]および[RFC8995]に記載されている自律型インフラストラクチャコンポーネントを含むことに加えて、単純な自律ノードにはほとんどASAが含まれていない可能性があります。そのようなノードは、graspプロトコルスタックをそのコードに直接統合することができ、したがってこのAPIをインストールする必要はない。ただし、プログラマは、APIを使用するために必要なものよりも把握プロトコルをより深く理解する必要があります。
This document gives a conceptual outline of the API. It is not a formal specification for any particular programming language or operating system, and it is expected that details will be clarified in individual implementations.
この文書はAPIの概念的な概要を示しています。特定のプログラミング言語またはオペレーティングシステムの正式な仕様ではなく、詳細は個々の実装で明確にされると予想されます。
The design assumes that an ASA needs to call a separate GRASP implementation. The latter handles protocol details (security, sending and listening for GRASP messages, waiting, caching discovery results, negotiation looping, sending and receiving synchronization data, etc.) but understands nothing about individual GRASP objectives (see Section 2.10 of [RFC8990]). The semantics of objectives are unknown to the GRASP protocol and are handled only by the ASAs. Thus, this is an abstract API for use by ASAs. Individual language bindings should be defined in separate documents.
設計は、ASAが別の把握実装を呼び出す必要があると仮定しています。後者はプロトコルの詳細を処理します（セキュリティ、メッセージの送信、待機、キャッシング、キャッシング、ネゴシエーションループ、送信、および受信同期データなど）がわかりません（[RFC8990]のセクション2.10を参照）。目的の意味論はGRASSプロトコルには知られておらず、ASASによってのみ処理されます。したがって、これはASASで使用するための抽象的なAPIです。個々の言語バインディングは別々の文書で定義されるべきです。
Different ASAs may utilize GRASP features differently, by using GRASP for:
GRASPを使用して、さまざまなASASは、次の把握を使用して、把握機能を異なる方法で利用することができます。
* discovery purposes only.
* 発見目的のみ。
* negotiation but only as an initiator (client).
* ネゴシエーションではなく、イニシエータ（クライアント）としてのみ。
* negotiation but only as a responder.
* 交渉ではなく、レスポンダとしてのみ。
* negotiation as an initiator or responder.
* イニシエータまたはレスポンダとしての交渉。
* synchronization but only as an initiator (recipient).
* 同期ではなく、イニシエータ（受信者）としてのみ。
* synchronization but only as a responder and/or flooder.
* 同期は、レスポンダおよび/または照明器としてのみ。
* synchronization as an initiator, responder, and/or flooder.
* イニシエータ、レスポンダ、および/または照明器としての同期。
The API also assumes that one ASA may support multiple objectives. Nothing prevents an ASA from supporting some objectives for synchronization and others for negotiation.
APIはまた、1人のASAが複数の目的をサポートできると仮定しています。ASAが交渉のために同期やその他のための他の目的を支えることを妨げるものはありません。
The API design assumes that the operating system and programming language provide a mechanism for simultaneous asynchronous operations. This is discussed in detail in Section 2.2.
API設計は、オペレーティングシステムとプログラミング言語が同時に非同期操作のためのメカニズムを提供すると仮定しています。これについてはセクション2.2で詳しく説明します。
A few items are out of scope in this version, since practical experience is required before including them:
それらを含める前に実際の経験が必要なので、いくつかのアイテムはこのバージョンでは範囲外にあります。
* Authorization of ASAs is not defined as part of GRASP and is a subject for future study.
* ASASの承認はGRASPの一部として定義されず、将来の研究の対象です。
* User-supplied explicit locators for an objective are not supported. The GRASP core will supply the locator, using the IP address of the node concerned.
* 目的のためのユーザー提供の明示的なロケーターはサポートされていません。関係するノードのIPアドレスを使用して、GRASPコアがロケータを供給します。
* The rapid mode of GRASP (Section 2.5.4 of [RFC8990]) is not supported.
* 把握モード（RFC8990のセクション2.5.4）はサポートされていません。
GRASP depends on asynchronous operations and wait states, and some of its messages are not idempotent, meaning that repeating a message may cause repeated changes of state in the recipient ASA. Many ASAs will need to support several concurrent operations; for example, an ASA might need to negotiate one objective with a peer while discovering and synchronizing a different objective with a different peer. Alternatively, an ASA that acts as a resource manager might need to run simultaneous negotiations for a given objective with multiple different peers. Such an ASA will probably need to support uninterruptible atomic changes to its internal data structures, using a mechanism provided by the operating system and programming language in use.
GRASPは非同期操作と待機状態に依存し、そのメッセージの一部はIDEmpotentではなく、メッセージを繰り返すと、受信者ASAの状態の繰り返しの変更が発生する可能性があります。多くのASAはいくつかの同時操作をサポートする必要があります。たとえば、ASAは、異なる目的を別のピアで検出して同期しながら、1つの目的をピアと交渉する必要があります。あるいは、リソースマネージャとして機能するASAは、複数の異なるピアを持つ特定の目的に対して同時交渉を実行する必要があるかもしれません。そのようなASAは、オペレーティングシステムおよび使用中のプログラミング言語によって提供されるメカニズムを使用して、内部データ構造に対する無停電原子の変更をサポートする必要があるでしょう。
Some ASAs need to support asynchronous operations; therefore, the GRASP core must do so. Depending on both the operating system and the programming language in use, there are various techniques for such parallel operations, three of which we consider here: multithreading, an event loop structure using polling, and an event loop structure using callback functions.
非同期操作をサポートする必要があるASAの中には、いくつかのASAが必要です。したがって、GRASPコアはそうする必要があります。使用中のオペレーティングシステムとプログラミング言語の両方に応じて、そのような並列操作のためのさまざまな技術があり、ここでは、ここで検討します。マルチスレッド、ポーリングを使用したイベントループ構造、およびコールバック関数を使用したイベントループ構造。
1. In multithreading, the operating system and language will provide the necessary support for asynchronous operations, including creation of new threads, context switching between threads, queues, locks, and implicit wait states. In this case, API calls can be treated as simple synchronous function calls within their own thread, even if the function includes wait states, blocking, and queueing. Concurrent operations will each run in their own threads. For example, the discover() call may not return until discovery results have arrived or a timeout has occurred. If the ASA has other work to do, the discover() call must be in a thread of its own.
1. マルチスレッドでは、オペレーティングシステムと言語は、新しいスレッドの作成、スレッド間のコンテキスト切り替え、キュー、ロック、および暗黙的な待機状態など、非同期操作に必要なサポートを提供します。この場合、API呼び出しは、その関数に待機状態、ブロック、およびキューイングが含まれていても、独自のスレッド内の単純な同期関数呼び出しとして扱うことができます。同時操作はそれぞれ独自のスレッドで実行されます。たとえば、ディスカバリの結果が到着したかタイムアウトが発生するまで、Discover（）呼び出しは戻ってはいけません。ASAに他の作業がある場合は、Discover（）呼び出しは独自のスレッドになければなりません。
2. In an event loop implementation with polling, blocking calls are not acceptable. Therefore, all calls must be non-blocking, and the main loop could support multiple GRASP sessions in parallel by repeatedly polling each one for a change of state. To facilitate this, the API implementation would provide non-blocking versions of all the functions that otherwise involve blocking and queueing. In these calls, a 'noReply' code will be returned by each call instead of blocking, until such time as the event for which it is waiting (or a failure) has occurred. Thus, for example, discover() would return 'noReply' instead of waiting until discovery has succeeded or timed out. The discover() call would be repeated in every cycle of the main loop until it completes. Effectively, it becomes a polling call.
2. ポーリングを伴うイベントループの実装では、ブロックコールは許可されません。したがって、すべての呼び出しはノンブロッキングでなければならず、メインループは、それぞれが状態変更のためにそれぞれを繰り返しポーリングすることによって、複数の把握セッションを並列にサポートすることができます。これを容易にするために、APIの実装は、ブロック化とキューイングを含むすべての関数の非ブロッキングバージョンを提供します。これらの呼び出しでは、それが待機しているイベント（または失敗）が発生しているイベントと同じ時間まで、ブロッキングの代わりに「Noreply」コードが返されます。したがって、たとえば、Discover（）は、ディスカバリーが成功またはタイムアウトされるまで待機するのではなく、「noreply」を返します。Discover（）呼び出しは、メインループのすべてのサイクルで完了するまで繰り返されます。事実上、それはポーリング呼び出しになります。
3. It was noted earlier that some GRASP messages are not idempotent; in particular, this applies to each step in a negotiation session -- sending the same message twice might produce unintended side effects. This is not affected by event loop polling: repeating a call after a 'noReply' does not repeat a message; it simply checks whether a reply has been received.
3. いくつかの把握メッセージがIDEmpotentではないことが前に注意していました。特に、これはネゴシエーションセッションの各ステップに適用されます - 同じメッセージを送信すると、意図しない副作用が生じる可能性があります。これはイベントループポーリングの影響を受けません。 'noreply'の後にコールを繰り返してもメッセージが繰り返されません。それは単に返信が受信されたかどうかをチェックします。
4. In an event loop implementation with callbacks, the ASA programmer would provide a callback function for each asynchronous operation. This would be called asynchronously when a reply is received or a failure such as a timeout occurs.
4. コールバックを使用したイベントループ実装では、ASAプログラマは非同期操作ごとにコールバック関数を提供します。これは、応答が受信されたとき、またはタイムアウトなどの障害が発生したときに非同期的に呼び出されます。
The design of GRASP allows the following scenario. Consider an ASA "A" that acts as a resource allocator for some objective. An ASA "B" launches a negotiation with "A" to obtain or release a quantity of the resource. While this negotiation is under way, "B" chooses to launch a second simultaneous negotiation with "A" for a different quantity of the same resource. "A" must therefore conduct two separate negotiation sessions at the same time with the same peer and must not mix them up.
GRASPの設計により、以下のシナリオが可能になります。いくつかの目的のリソースアロケータとして機能するASA "A"を考えてみましょう。ASA「B」は、数量のリソースを取得または解放するための「A」と交渉を開始します。この交渉が進行中であるが、「B」は、異なる量の同じリソースに対して「a」と第2の同時交渉を起動することを選択する。したがって、「a」は、同じピアと同時に2つの別々のネゴシエーションセッションを行わなければならず、それらを混合してはならない。
Note that ASAs could be designed to avoid such a scenario, i.e., restricted to exactly one negotiation session at a time for a given objective, but this would be a voluntary restriction not required by the GRASP protocol. In fact, GRASP assumes that any ASA managing a resource may need to conduct multiple parallel negotiations, possibly with the same peer. Communication patterns could be very complex, with a group of ASAs overlapping negotiations among themselves, as described in [ANIMA-COORD]. Therefore, the API design allows for such scenarios.
ASASは、そのようなシナリオ、すなわち特定の目的のために一度に1つのネゴシエーションセッションに限定されるように設計され得るが、これはGRASPプロトコルによって必要とされない自発的な制限であろう。実際、GRASPは、リソースを管理する任意のASAがおそらく同じピアを持つ複数の並列交渉を実行する必要があるかもしれないと仮定します。[ANIMA-COOMD]で説明されているように、コミュニケーションパターンは非常に複雑であり、ASAのグループは自分の間で交渉を重ね合わせます。したがって、API設計によりそのようなシナリオが可能になります。
In the callback model, for the scenario just described, the ASAs "A" and "B" will each provide two instances of the callback function, one for each session. For this reason, each ASA must be able to distinguish the two sessions, and the peer's IP address is not sufficient for this. It is also not safe to rely on transport port numbers for this, since future variants of GRASP might use shared ports rather than a separate port per session. Hence, the GRASP design includes a Session ID. Thus, when necessary, a session handle (see the next section) is used in the API to distinguish simultaneous GRASP sessions from each other, so that any number of sessions may proceed asynchronously in parallel.
コールバックモデルでは、今説明したシナリオの場合、ASAS "A"と "B"はそれぞれ、セッションごとに1つずつ、コールバック関数の2つのインスタンスを提供します。このため、各ASAは2つのセッションを区別できなければならず、ピアのIPアドレスはこれには十分ではありません。将来のGRASPの亜種はセッションごとに別のポートではなく共有ポートを使用する可能性があるため、これにはトランスポートポート番号に頼るのも安全ではありません。したがって、GRASP設計はセッションIDを含む。したがって、必要に応じて、同時把持セッションを互いに区別するために、セッションハンドル（次のセクションを参照）が使用され、任意の数のセッションが非同期的に並行して進行する可能性がある。
A GRASP session consists of a finite sequence of messages (for discovery, synchronization, or negotiation) between two ASAs. It is uniquely identified on the wire by a pseudorandom Session ID plus the IP address of the initiator of the session. Further details are given in "Session Identifier (Session ID)" (Section 2.7 of [RFC8990]).
GRASSセッションは、2つのASA間のメッセージの有限のシーケンス（検出、同期、ネゴシエーション用）で構成されています。それは、疑似ランダムセッションIDとセッションのイニシエータのIPアドレスによってワイヤ上で一意に識別されます。「セッション識別子（セッションID）」（[RFC8990]のセクション2.7）に詳細な詳細が与えられます。
On the first call in a new GRASP session, the API returns a 'session_handle' handle that uniquely identifies the session within the API, so that multiple overlapping sessions can be distinguished. A likely implementation is to form the handle from the underlying GRASP Session ID and IP address. This handle must be used in all subsequent calls for the same session. Also see Section 2.3.2.8.
新しいGRASSセッションの最初の呼び出しで、APIはAPI内のセッションを一意に識別する 'session_handle'ハンドルを返します。その結果、複数の重なり合いセッションを区別できます。可能性が高い実装は、基礎となる把握セッションIDおよびIPアドレスからハンドルを形成することです。このハンドルは、同じセッションに対する後続のすべての呼び出しで使用する必要があります。セクション2.3.2.8も参照のこと。
An additional mechanism that might increase efficiency for polling implementations is to add a general call, say notify(), which would check the status of all outstanding operations for the calling ASA and return the session_handle values for all sessions that have changed state. This would eliminate the need for repeated calls to the individual functions returning a 'noReply'. This call is not described below as the details are likely to be implementation specific.
ポーリング実装の効率を高める可能性のあるメカニズムは、呼び出し側ASAのすべての優れた操作のステータスを確認し、変更された状態のすべてのセッションのSESSION_HANDLE値を返します。これにより、「noreply」を返す個々の関数への繰り返し呼び出しが排除されます。詳細は実装固有のものである可能性が高いため、この呼び出しは以下の通りです。
An implication of the above for all GRASP implementations is that the GRASP core must keep state for each GRASP operation in progress, most likely keyed by the GRASP Session ID and the GRASP source address of the session initiator. Even in a threaded implementation, the GRASP core will need such state internally. The session_handle parameter exposes this aspect of the implementation.
すべてのGRASP実装について上記の意味を表すことは、Graspコアが進行中の把持操作ごとに状態を保持しなければならず、把握セッションIDとセッションイニシエータのGRASS送信元アドレスによって鍵となります。ねじ付き実装でも、GRASPコアはそのような状態を内部的に必要とするでしょう。session_handleパラメータは、この実装のこの側面を公開します。
GRASP sessions may terminate for numerous reasons. A session ends when discovery succeeds or times out, negotiation succeeds or fails, a synchronization result is delivered, the other end fails to respond before a timeout expires, a loop count expires, or a network socket error occurs. Note that a timeout at one end of a session might result in a timeout or a socket error at the other end, since GRASP does not send error messages in this case. In all cases, the API will return an appropriate code to the caller, which should then release any reserved resources. After failure cases, the GRASP specification recommends an exponential backoff before retrying.
把握セッションはさまざまな理由で終了することがあります。セッションが終了し、検出が成功したり、タイムアウトしたりすると、ネゴシエーションが成功または失敗し、同期結果が配信され、タイムアウトが期限切れになる前に、ループカウントの有効期限が切れたり、ネットワークソケットエラーが発生したりできません。この場合、セッションの一端のタイムアウトは、この場合はエラーメッセージを送信しないため、もう一方の端にタイムアウトまたはソケットエラーが発生する可能性があることに注意してください。すべての場合において、APIは呼び出し側に適切なコードを返します。これにより、予約済みリソースが解放されます。故障の後に、GRASS仕様は再試行する前に指数関数的なバックオフを推奨します。
The functions provided by the API fall into several groups:
APIによって提供される機能はいくつかのグループに分類されます。
Registration: These functions allow an ASA to register itself with the GRASP core and allow a registered ASA to register the GRASP objectives that it will manipulate.
登録：これらの機能により、ASAがGRASPコアを使用して自分自身を登録でき、登録されたASAが操作されるという把持目的を登録できるようにします。
Discovery: This function allows an ASA that needs to initiate negotiation or synchronization of a particular objective to discover a peer willing to respond.
検出：この関数は、対応する喜んで対応するピアを発見するために、特定の目的の交渉または同期を開始する必要があるASAを使用すると、
Negotiation: These functions allow an ASA to act as an initiator (requester) or responder (listener) for a GRASP negotiation session. After initiation, negotiation is a symmetric process, so most of the functions can be used by either party.
ネゴシエーション：これらの関数により、ASAが把握交渉セッションのためのイニシエータ（リクエスタ）またはレスポンダ（リスナー）として機能することを可能にします。開始後、交渉は対称プロセスであるため、ほとんどの機能はどちらの当事者によって使用できます。
Synchronization: These functions allow an ASA to act as an initiator (requester) or responder (listener and data source) for a GRASP synchronization session.
同期：これらの関数では、ASAが把握同期セッションのためにイニシエータ（リクエスタ）またはレスポンダ（リスナーとデータソース）として機能することを可能にします。
Flooding: These functions allow an ASA to send and receive an objective that is flooded to all nodes of the ACP.
フラッディング：これらの機能により、ASAはACPのすべてのノードにフラッディングされている目的を送受信できます。
Some example logic flows for a resource management ASA are given in [ASA-GUIDE], which may be of help in understanding the following descriptions. The next section describes parameters and data structures used in multiple API calls. The following sections describe various groups of function APIs. Those APIs that do not list asynchronous mechanisms are implicitly synchronous in their behavior.
Resource Management ASAのロジックフローのいくつかの例では、[ASAガイド]に記載されています。これは、以下の説明を理解するのに役立つ可能性があります。次のセクションでは、複数のAPI呼び出しで使用されるパラメータとデータ構造について説明します。以下のセクションでは、さまざまな機能APIのグループについて説明します。非同期メカニズムをリストしないAPIは、それらの動作に暗黙的に同期しています。
In this API, integers are assumed to be 32-bit unsigned integers (uint32_t) unless otherwise indicated.
このAPIでは、整数は、特に断らない限り、32ビット符号なし整数（uint32_t）と見なされます。
All functions in the API have an unsigned 'errorcode' integer as their return value (the first return value in languages that allow multiple return values). An errorcode of zero indicates success. Any other value indicates failure of some kind. The first three errorcodes have special importance:
API内のすべての機能には、符号なしの「ErrorCode」整数がそれらの戻り値（複数の戻り値を許す言語の最初の戻り値）を持ちます。ゼロのエラーコードは成功を示します。他の値はある種の失敗を示します。最初の3つのエラーコードには特別な重要性があります。
1 - Declined: used to indicate that the other end has sent a GRASP Negotiation End message (M_END) with a Decline option (O_DECLINE).
1 - 辞退しました：もう一方のエンドが辞文オプション（O_Decline）を持つ把握交渉終了メッセージ（M_END）を送信したことを示すために使用されます。
2 - No reply: used in non-blocking calls to indicate that the other end has sent no reply so far (see Section 2.2).
2 - 返信なし：他のエンドがこれまでのところ返信を送信していないことを示すための非ブロックコールで使用されます（セクション2.2を参照）。
3 - Unspecified error: used when no more specific error codes apply.
3 - 指定されていないエラー：具体的なエラーコードが適用されない場合に使用されます。
Appendix A gives a full list of currently suggested error codes, based on implementation experience. While there is no absolute requirement for all implementations to use the same error codes, this is highly recommended for portability of applications.
付録Aは、実装の経験に基づいて、現在推奨されるエラーコードの全リストを提供します。すべての実装に同じエラーコードを使用するのに絶対的な要件がないが、これはアプリケーションの移植性にとって非常に推奨されます。
Whenever a 'timeout' parameter appears, it is an unsigned integer expressed in milliseconds. If it is zero, the GRASP default timeout (GRASP_DEF_TIMEOUT; see [RFC8990]) will apply. An exception is the discover() function, which has a different interpretation of a zero timeout. If no response is received before the timeout expires, the call will fail unless otherwise noted.
'timeout'パラメータが表示されるたびに、それはミリ秒で表されていない符号なし整数です。ゼロの場合は、デフォルトのタイムアウトの把握（GRASP_DEF_TIMEOUT; [RFC8990]を参照）が適用されます。例外はdiscover（）関数です。これは、ゼロタイムアウトの異なる解釈を持ちます。タイムアウトが期限切れになる前に応答が受信されない場合、特に断りのない限り通話は失敗します。
An 'objective' parameter is a data structure with the following components:
'Objective'パラメータは、次のコンポーネントを持つデータ構造です。
name (UTF-8 string): The objective's name
名前（UTF-8文字列）：目的の名前
neg (Boolean flag): True if objective supports negotiation (default False)
NEG（ブールフラグ）：客観的なものがネゴシエーションをサポートしている場合はtrue（デフォルトfalse）
synch (Boolean flag): True if objective supports synchronization (default False)
SYNCH（ブールフラグ）：Objectiveが同期をサポートしている場合はtrue（デフォルトfalse）
dry (Boolean flag): True if objective supports dry-run negotiation (default False)
DRY（ブールフラグ）：客観的な場合はドライランネゴシエーションをサポートしている場合はtrue（デフォルトfalse）
Note 1: Only one of 'synch' or 'neg' may be True. Note 2: 'dry' must not be True unless 'neg' is also True. Note 3: In some programming languages, the preferred implementation may be to represent the Boolean flags as bits in a single byte, which is how they are encoded in GRASP messages. In other languages, an enumeration might be preferable.
注1：「同期」または「NEG」のうちの1つだけが真実である可能性があります。注2：「NEG」も真実でない限り、「ドライ 'は否定しないでください。注3：いくつかのプログラミング言語では、好ましい実装はブールフラグを1バイト内のビットとして表現することであり得、これはそれらがメッセージに統合された方法である。他の言語では、列挙が望ましいかもしれません。
loop_count (unsigned integer, uint8_t): Limit on negotiation steps, etc. (default GRASP_DEF_LOOPCT; see [RFC8990]). The 'loop_count' is set to a suitable value by the initiator of a negotiation, to prevent indefinite loops. It is also used to limit the propagation of discovery and flood messages.
loop_count（unsigned整数、uint8_t）：ネゴシエーション手順などの制限（デフォルトのGRASP_DEF_LOOPCT; [RFC8990]を参照）。'loop_count'は、無期限ループを防ぐために、ネゴシエーションのイニシエータによって適切な値に設定されます。発見メッセージとフラッドメッセージの伝播を制限するためにも使用されます。
value: A specific data structure expressing the value of the objective. The format is language dependent, with the constraint that it can be validly represented in CBOR [RFC8949].
値：目的の値を表す特定のデータ構造。フォーマットは言語に依存し、それがCBOR [RFC8949]で有効に表現できるという制約です。
An important advantage of CBOR is that the value of an objective can be completely opaque to the GRASP core yet pass transparently through it to and from the ASA. Although the GRASP core must validate the format and syntax of GRASP messages, it cannot validate the value of an objective; all it can do is detect malformed CBOR. The handling of decoding errors depends on the CBOR library in use, but a corresponding error code ('CBORfail') is defined in the API and will be returned to the ASA if a faulty message can be assigned to a current GRASP session. However, it is the responsibility of each ASA to validate the value of a received objective, as discussed in Section 5.3 of [RFC8949]. If the programming language in use is suitably object-oriented, the GRASP API may deserialize the value and present it to the ASA as an object. If not, it will be presented as a CBOR data item. In all cases, the syntax and semantics of the objective value are the responsibility of the ASA.
CBORの重要な利点は、目的の値が把持コアに完全に不透明であることがまだASAとの間で透過的に通過することができるということです。GRASPコアはGRASPメッセージのフォーマットと構文を検証する必要がありますが、目的の値を検証できません。それができることはすべて不正なコンバートのCBORを検出することです。復号エラーの処理は使用中のCBOBLIBRESライブラリによって異なりますが、対応するエラーコード（ 'CBORFAIL'）がAPIで定義され、故障したメッセージが現在のGRASSセッションに割り当てることができる場合はASAに返されます。ただし、[RFC8949]のセクション5.3で説明されているように、受信した目的の値を検証するのは各ASAの責任です。使用中のプログラミング言語が適切にオブジェクト指向である場合、GRASP APIは値を逆シリアル化し、それをオブジェクトとしてASAに提示することができる。そうでなければ、それはCBORデータ項目として提示されます。すべての場合において、客観的価値の構文と意味はASAの責任です。
A requirement for all language mappings and all API implementations is that, regardless of what other options exist for a language-specific representation of the value, there is always an option to use a raw CBOR data item as the value. The API will then wrap this with CBOR Tag 24 as an encoded CBOR data item for transmission via GRASP, and unwrap it after reception. By this means, ASAs will be able to communicate regardless of programming language.
すべての言語マッピングとすべてのAPI実装の要件は、その他の値の言語固有の表現に対して存在する他のオプションが存在することに関係なく、RAW CBORデータ項目を値として使用するオプションがあります。その後、APIは、把握を介した伝送のための符号化されたCBOBORデータ項目としてCBORタグ24と折り返し、受信後に解く。これにより、ASASはプログラミング言語に関係なく通信できるようになります。
The 'name' and 'value' fields are of variable length. GRASP does not set a maximum length for these fields, but only for the total length of a GRASP message. Implementations might impose length limits.
'name'フィールドと 'value' 'フィールドは可変長です。GRASPはこれらのフィールドの最大長を設定しませんが、GRASPメッセージの全長の場合に限ります。実装は長さ制限を課すかもしれません。
An example data structure definition for an objective in the C language, using at least the C99 version, and assuming the use of a particular CBOR library [libcbor], is:
C99バージョンを使用して、C99バージョンを使用して、特定のCBOBライブラリ[Libcbor]の使用を想定して、C言語のデータ構造定義の例を示します。
typedef struct {
unsigned char *name;
uint8_t flags; // flag bits as defined by GRASP
uint8_t loop_count;
uint32_t value_size; // size of value in bytes
cbor_mutable_data cbor_value;
// CBOR bytestring (libcbor/cbor/data.h)
} objective;
An example data structure definition for an objective in the Python language (version 3.4 or later) is:
Python言語（バージョン3.4以降）の目的のデータ構造定義の例は次のとおりです。
class objective:
"""A GRASP objective"""
def __init__(self, name):
self.name = name #Unique name (string)
self.negotiate = False #True if negotiation supported
self.dryrun = False #True if dry-run supported
self.synch = False #True if synchronization supported
self.loop_count = GRASP_DEF_LOOPCT # Default starting value
self.value = None #Place holder; any Python object
An 'asa_locator' parameter is a data structure with the following contents:
'asa_locator'パラメータは、以下の内容を備えたデータ構造です。
locator: The actual locator, either an IP address or an ASCII string.
Locator：実際のロケータ、IPアドレスまたはASCII文字列のいずれかです。
ifi (unsigned integer): The interface identifier index via which this was discovered (of limited use to most ASAs).
IFI（符号なし整数）：これが発見されたインタフェース識別子インデックス（ほとんどのASASへの制限付き）。
expire (system dependent type): The time on the local system clock when this locator will expire from the cache.
期限切れ（システム依存型）：このロケータがキャッシュから有効期限が切れると、ローカルシステムクロックの時間。
The following covers all locator types currently supported by GRASP: * is_ipaddress (Boolean) - True if the locator is an IP address.
以下は、Grasp：* IS_IPAddress（Boolean）で現在サポートされているすべてのロケータタイプをカバーしています。ロケータがIPアドレスの場合はtrueです。
* is_fqdn (Boolean) - True if the locator is a Fully Qualified Domain Name (FQDN).
* is_fqdn（boolean） - ロケータが完全修飾ドメイン名（FQDN）の場合はtrueです。
* is_uri (Boolean) - True if the locator is a URI.
* is_uri（ブール値） - ロケータがURIの場合はtrueです。
These options are mutually exclusive. Depending on the programming language, they could be represented as a bit pattern or an enumeration.
これらのオプションは相互に排他的です。プログラミング言語に応じて、それらはビットパターンまたは列挙として表すことができます。
diverted (Boolean): True if the locator was discovered via a Divert option.
diverted（ブール値）：Divertオプションを介してロケータが検出された場合はtrue。
protocol (unsigned integer): Applicable transport protocol (IPPROTO_TCP or IPPROTO_UDP). These constants are defined in the CDDL specification of GRASP [RFC8990].
プロトコル（符号なし整数）：該当するトランスポートプロトコル（IPPROTO_TCPまたはIPPROTO_UDP）。これらの定数はGRASP [RFC8990]のCDDL仕様で定義されています。
port (unsigned integer): Applicable port number.
ポート（符号なし整数）：該当するポート番号。
The 'locator' field is of variable length in the case of an FQDN or a URI. GRASP does not set a maximum length for this field, but only for the total length of a GRASP message. Implementations might impose length limits.
'locator'フィールドは、FQDNまたはURIの場合には可変長です。GRASPはこのフィールドの最大長を設定しませんが、GRASPメッセージの全長の場合に限ります。実装は長さ制限を課すかもしれません。
It should be noted that when one ASA discovers the asa_locator of another, there is no explicit authentication mechanism. In accordance with the trust model provided by the secure ACP, ASAs are presumed to provide correct locators in response to discovery. See "Locator Options" (Section 2.9.5 of [RFC8990]) for further details.
1つのASAが他のASA_LOCORATORを発見すると、明示的な認証メカニズムはありません。安全なACPによって提供される信頼モデルに従って、ASASは発見に応答して正しいロケーターを提供すると推定されます。詳細については、「ロケータオプション」（[RFC8990のセクション2.9.5）を参照してください。
A 'tagged_objective' parameter is a data structure with the following contents:
'tagged_Objective'パラメータは、以下の内容を備えたデータ構造です。
objective: An objective.
目的：目的：
locator: The asa_locator associated with the objective, or a null value.
LOCATOR：目的に関連付けられているasa_locator、またはNULL値。
Although an authentication and authorization scheme for ASAs has not been defined, the API provides a very simple hook for such a scheme. When an ASA starts up, it registers itself with the GRASP core, which provides it with an opaque handle that, although not cryptographically protected, would be difficult for a third party to predict. The ASA must present this handle in future calls. This mechanism will prevent some elementary errors or trivial attacks such as an ASA manipulating an objective it has not registered to use.
ASASの認証と認証方式は定義されていませんが、APIはそのような方式に非常に単純なフックを提供します。ASAが起動すると、暗号的に保護されていないが第三者が予測するのが不透明なハンドルでそれを提供するGraspコアと登録します。ASAは将来の電話でこのハンドルを提示しなければなりません。このメカニズムは、使用に登録されていない目的を操作するASAのようないくつかの基本的な誤りや些細な攻撃を防ぎます。
Thus, in most calls, an 'asa_handle' parameter is required. It is generated when an ASA first registers with GRASP, and the ASA must then store the asa_handle and use it in every subsequent GRASP call. Any call in which an invalid handle is presented will fail. It is an up to 32-bit opaque value (for example, represented as a uint32_t, depending on the language). Since it is only used locally, and not in GRASP messages, it is only required to be unique within the local GRASP instance. It is valid until the ASA terminates. It should be unpredictable; a possible implementation is to use the same mechanism that GRASP uses to generate Session IDs (see Section 2.3.2.8).
したがって、ほとんどの呼び出しでは、 'ASA_Handle'パラメータが必要です。ASAが最初にGRASPを登録したときに生成され、ASAはASA_HANDLEを保存し、それを後続のGRASP呼び出しごとに使用する必要があります。無効なハンドルが表示されている呼び出しは失敗します。これは最大32ビットの不透明値です（たとえば、言語によっては、uint32_tとして表されます）。メッセージを把握していないだけでなく、ローカルGRASPインスタンス内で一意であることが必要です。ASAが終了するまで有効です。予測できないはずです。可能な実装は、graspがセッションIDを生成するために使用するのと同じメカニズムを使用することです（セクション2.3.2.8を参照）。
In some calls, a 'session_handle' parameter is required. This is an opaque data structure as far as the ASA is concerned, used to identify calls to the API as belonging to a specific GRASP session (see Section 2.2.3). It will be provided as a parameter in callback functions. As well as distinguishing calls from different sessions, it also allows GRASP to detect and ignore calls from non-existent or timed-out sessions.
一部の呼び出しでは、 'session_handle'パラメータが必要です。ASAが懸念される限り、これは不透明なデータ構造であり、特定のGRASSセッションに属するものとしてAPIへの呼び出しを識別するために使用されます（セクション2.2.3を参照）。コールバック関数のパラメータとして提供されます。さまざまなセッションからの呼び出しを区別するだけでなく、存在しないセッションまたはタイムアウトされたセッションからの通話を検出して無視することもできます。
In an event loop implementation, callback functions (Section 2.2.1) may be supported for all API functions that involve waiting for a remote operation:
イベントループの実装では、リモート操作を待つすべてのAPI関数でコールバック関数（セクション2.2.1）をサポートすることができます。
discover() whose callback would be discovery_received().
そのコールバックがDiscovery_Received（）になるのを発見します。
request_negotiate() whose callback would be negotiate_step_received().
コールバックがnegotiate_step_received（）になるrequest_negotiate（）。
negotiate_step() whose callback would be negotiate_step_received().
コールバックがnegotiate_step_received（）になるnegotiate_step（）。
listen_negotiate() whose callback would be negotiate_step_received().
コールバックがNegotiate_Step_Received（）になるlisten_negotiate（）。
synchronize() whose callback would be synchronization_received().
コールバックがsynchraization_received（）になるSynchronize（）。
Further details of callbacks are implementation dependent.
コールバックのさらなる詳細は実装に依存します。
These functions are used to register an ASA, and the objectives that it modifies, with the GRASP module. In the absence of an authorization model, these functions are very simple, but they will avoid multiple ASAs choosing the same name and will prevent multiple ASAs manipulating the same objective. If an authorization model is added to GRASP, these API calls would need to be modified accordingly.
これらの関数は、ASAを登録するために使用され、それが修正する目的はGRASPモジュールを使用しています。許可モデルがない場合、これらの機能は非常に簡単ですが、同じ名前を選択する複数のASAを回避し、同じ目的を操作する複数のASAを妨げます。許可モデルがGRASPに追加された場合、これらのAPI呼び出しはそれに応じて変更する必要があります。
* register_asa()
* register_asa（）
All ASAs must use this call before issuing any other API calls.
他のAPI呼び出しを発行する前に、ASAはすべてこのコールを使用する必要があります。
- Input parameter:
- 入力パラメータ：
name of the ASA (UTF-8 string)
ASAの名前（UTF-8文字列）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
- This initializes the state in the GRASP module for the calling entity (the ASA). In the case of success, an 'asa_handle' is returned, which the ASA must present in all subsequent calls. In the case of failure, the ASA has not been authorized and cannot operate. The 'asa_handle' value is undefined.
- これにより、呼び出し側エンティティ（ASA）のGRASPモジュールの状態が初期化されます。成功した場合は、「ASA_Handle」が返され、ASAは後続のすべての呼び出しに存在していなければなりません。障害の場合、ASAは承認されておらず、操作できません。'asa_handle'値は未定義です。
* deregister_asa()
* dergister_asa（）
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
name of the ASA (UTF-8 string)
ASAの名前（UTF-8文字列）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- This removes all state in the GRASP module for the calling entity (the ASA) and deregisters any objectives it has registered. Note that these actions must also happen automatically if an ASA exits.
- これにより、呼び出し側エンティティ（ASA）のGRASSモジュールのすべての状態が除外され、登録されている目的は任意の目的を解除します。ASAが終了すると、これらのアクションも自動的に発生する必要があります。
- Note -- the ASA name is, strictly speaking, redundant in this call but is present to detect and reject erroneous deregistrations.
- 注 - ASA名は、厳密に言えば、この呼び出しで冗長で言っていますが、誤除去遅延を検出して除去するために存在します。
* register_objective()
* register_Objective（）
ASAs must use this call for any objective whose value they need to transmit by negotiation, synchronization, or flooding.
ASASは、それらがネゴシエーション、同期、またはフラッディングによって送信する必要がある値のためにこの呼び出しを使用する必要があります。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
ttl (unsigned integer -- default GRASP_DEF_TIMEOUT)
TTL（符号なし整数 - デフォルトのGRASP_DEF_TIMEOUT）
discoverable (Boolean -- default False)
discoverable（boolean - デフォルトfalse）
overlap (Boolean -- default False)
オーバーラップ（ブール値 - デフォルトfalse）
local (Boolean -- default False)
ローカル（Boolean - デフォルトfalse）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- This registers an objective that this ASA may modify and transmit to other ASAs by flooding or negotiation. It is not necessary to register an objective that is only received by GRASP synchronization or flooding. The 'objective' becomes a candidate for discovery. However, discovery responses should not be enabled until the ASA calls listen_negotiate() or listen_synchronize(), showing that it is able to act as a responder. The ASA may negotiate the objective or send synchronization or flood data. Registration is not needed for "read-only" operations, i.e., the ASA only wants to receive synchronization or flooded data for the objective concerned.
- これは、このASAがフラッディングまたはネゴシエーションによって他のASAに変更および送信できるという目的を登録します。GRASP同期またはフラッディングによってのみ受信される目的を登録する必要はありません。「目的」は発見の候補者になります。ただし、ASAがlisten_negotiate（）またはlisten_synchronize（）を呼び出すまで、ディスカバリ応答は有効になりません。それがレスポンダとして機能することができることを示しています。ASAは、目的を交渉するか、または同期データまたはフラッドデータを送信することができます。登録は「読み取り専用」の操作、すなわちASAは、当該目的のために同期またはフラッディングデータを受信したいだけであるだけである。
- The 'ttl' parameter is the valid lifetime (time to live) in milliseconds of any discovery response generated for this objective. The default value should be the GRASP default timeout (GRASP_DEF_TIMEOUT; see [RFC8990]).
- 'ttl'パラメータは、この目的で生成された検出応答のミリ秒単位で有効な有効期間（ライブ時間）です。デフォルト値はgraspデフォルトタイムアウト（GRASP_DEF_TIMEOUT; [RFC8990]を参照）にする必要があります。
- If the parameter 'discoverable' is True, the objective is immediately discoverable. This is intended for objectives that are only defined for GRASP discovery and that do not support negotiation or synchronization.
- パラメータ 'discoverable'がtrueの場合、目的はすぐに検出可能です。これは、把握発見に対してのみ定義されていて、ネゴシエーションや同期をサポートしていない目的を対象としています。
- If the parameter 'overlap' is True, more than one ASA may register this objective in the same GRASP instance. This is of value for life cycle management of ASAs [ASA-GUIDE] and must be used consistently for a given objective (always True or always False).
- パラメータ 'verblap'がtrueの場合、複数のASAがこの目的を同じGRASPインスタンスに登録することができます。これはASAのライフサイクル管理のための値です[ASAガイド]は、特定の目的で一貫して使用する必要があります（常に真または常にFALSE）。
- If the parameter 'local' is True, discovery must return a link-local address. This feature is for objectives that must be restricted to the local link.
- パラメータ 'local'がtrueの場合、検出はリンクローカルアドレスを返す必要があります。この機能は、ローカルリンクに制限されなければならない目的のためのものです。
- This call may be repeated for multiple objectives.
- この呼び出しは、複数の目的に対して繰り返されてもよい。
* deregister_objective()
* deregister_Objective（）
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- The 'objective' must have been registered by the calling ASA; if not, this call fails. Otherwise, it removes all state in the GRASP module for the given objective.
- 「目的」は、呼び出し側ASAによって登録されていなければなりません。そうでない場合、この呼び出しは失敗します。それ以外の場合は、与えられた目的のためにGRASSモジュールのすべての状態を削除します。
* discover()
* 発見する（）
This function may be used by any ASA to discover peers handling a given objective.
この機能は、特定の目的を処理するピアを発見するために、任意のASAによって使用されることがあります。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
timeout (unsigned integer)
タイムアウト（符号なし整数）
minimum_TTL (unsigned integer)
minimum_ttl（unsigned整数）
- Return values:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
locator_list (structure)
locator_list（構造）
- This returns a list of discovered 'asa_locators' for the given objective. An empty list means that no locators were discovered within the timeout. Note that this structure includes all the fields described in Section 2.3.2.5.
- これにより、特定の目的のために検出された 'asa_locators'のリストが返されます。空のリストは、タイムアウト内でロケータが検出されなかったことを意味します。この構造には、セクション2.3.2.5で説明されているすべてのフィールドが含まれています。
- The parameter 'minimum_TTL' must be greater than or equal to zero. Any locally cached locators for the objective whose remaining time to live in milliseconds is less than or equal to 'minimum_TTL' are deleted first. Thus, 'minimum_TTL' = 0 will flush all entries. Note that this will not affect sessions already in progress using the deleted locators.
- パラメータ 'minimum_ttl'はゼロ以上でなければなりません。残り時間がミリ秒単位で生きるべき時間が 'minimum_ttl'以下である目的のためのローカルキャッシュされたロケータは、最初に削除されます。したがって、 'minimum_ttl' = 0はすべてのエントリをフラッシュします。これは、削除されたロケータを使用してすでに進行中のセッションには影響しません。
- If the parameter 'timeout' is zero, any remaining locally cached locators for the objective are returned immediately, and no other action is taken. (Thus, a call with 'minimum_TTL' and 'timeout' both equal to zero is pointless.)
- パラメータ 'timeout'がゼロの場合、目的の残りのローカルキャッシュされたロケーターはすぐに返され、他のアクションは取得されません。（したがって、 'minimum_ttl'を持つ呼び出しと「タイムアウト」の両方がゼロに等しいです。）
- If the parameter 'timeout' is greater than zero, GRASP discovery is performed, and all results obtained before the timeout in milliseconds expires are returned. If no results are obtained, an empty list is returned after the timeout. That is not an error condition. GRASP discovery is not a deterministic process. If there are multiple nodes handling an objective, none, some, or all of them will be discovered before the timeout expires.
- パラメータ 'timeout'がゼロより大きい場合、greaspディスカバリが実行され、ミリ秒単位のタイムアウトで得られたすべての結果が返されます。結果が得られない場合は、タイムアウト後に空のリストが返されます。それはエラー状態ではありません。把握発見は決定論的プロセスではありません。目的を処理するノードが複数ある場合は、タイムアウトが期限切れになる前にそれらのすべて、またはそれらのすべてが検出されます。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: This should be called in a separate thread if asynchronous operation is required.
非同期操作が必要な場合は、スレッド実装：これを個別のスレッドで呼び出す必要があります。
Event loop implementation: An additional in/out 'session_handle' parameter is used. If the 'errorcode' parameter has the value 2 ('noReply'), no response has been received so far. The 'session_handle' parameter must be presented in subsequent calls. A callback may be used in the case of a non-zero timeout.
イベントループの実装：追加のイン/ out 'session_handle'パラメータが使用されます。'errorcode'パラメータの値2（ 'noreply'）がある場合、これまでのところ応答は受け取られませんでした。'session_handle'パラメータは後続の呼び出しで表示する必要があります。ゼロ以外のタイムアウトの場合、コールバックを使用することができる。
Since the negotiation mechanism is different from a typical client/ server exchange, Figure 2 illustrates the sequence of calls and GRASP messages in a negotiation. Note that after the first protocol exchange, the process is symmetrical, with negotiating steps strictly alternating between the two sides. Either side can end the negotiation. Also, the side that is due to respond next can insert a delay at any time, to extend the other side's timeout. This would be used, for example, if an ASA needed to negotiate with a third party before continuing with the current negotiation.
交渉メカニズムは典型的なクライアント/サーバ交換とは異なるため、図2は、交渉中のコールのシーケンスと把握を示しています。第1のプロトコル交換後、プロセスは対称的であり、交渉ステップは2つの側面間で厳密に交互に交互に交互になる。どちら側に交渉が終了することがあります。また、次に対応することによる側面は任意のときに遅延を挿入して反対側のタイムアウトを延ばすことができます。現在の交渉を続ける前に、ASAが第三者と交渉するのに必要な場合はこれが使用されます。
The loop count embedded in the objective that is the subject of negotiation is initialized by the ASA that starts a negotiation and is then decremented by the GRASP core at each step, prior to sending each M_NEGOTIATE message. If it reaches zero, the negotiation will fail, and each side will receive an error code.
交渉の主題である目的に埋め込まれたループ数は、交渉を開始するASAによって初期化され、次に各M_Negotiateメッセージを送信する前に、各ステップで把握コアによってデクリメントされる。ゼロに達すると、ネゴシエーションは失敗し、各側面はエラーコードを受け取ります。
Initiator Responder
--------- ---------
listen_negotiate() \ Await request
listen_negotiate（）\ awaitリクエスト
request_negotiate()
M_REQ_NEG -> negotiate_step() \ Open session,
<- M_NEGOTIATE / start negotiation
negotiate_step()
M_NEGOTIATE -> negotiate_step() \ Continue
<- M_NEGOTIATE / negotiation
...
negotiate_wait() \ Insert
M_WAIT -> / delay
negotiate_step()
M_NEGOTIATE -> negotiate_step() \ Continue
<- M_NEGOTIATE / negotiation
negotiate_step()
M_NEGOTIATE -> end_negotiate() \ End
<- M_END / negotiation
\ Process results
\プロセス結果
Figure 2: Negotiation Sequence
図2：交渉順序
As the negotiation proceeds, each side will update the value of the objective in accordance with its particular semantics, defined in the specification of the objective. Although many objectives will have values that can be ordered, so that negotiation can be a simple bidding process, it is not a requirement.
交渉が進むにつれて、各辺は目的の仕様に定義されているその特定の意味論に従って目的の値を更新する。多くの目的は注文可能な値を持つことになりますが、交渉は単純な入札プロセスになる可能性がありますが、それは要件ではありません。
Failure to agree, a timeout, or loop count exhaustion may all end a negotiation session, but none of these cases are protocol failures.
同意できない、タイムアウト、またはループカウントの枯渇は、すべてのネゴシエーションセッションを終了するかもしれませんが、これらのケースはプロトコル障害ではありません。
* request_negotiate()
* request_negotiate（）
This function is used by any ASA to initiate negotiation of a GRASP objective as a requester (client).
この関数は、要求者（クライアント）としてGRASP目標のネゴシエーションを開始するために任意のASAによって使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
peer (asa_locator)
ピア（ASA_LOCORATOR）
timeout (unsigned integer)
タイムアウト（符号なし整数）
- Return values:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
session_handle (structure) (undefined unless successful)
session_handle（構造）（成功しない限り未定義）
proffered_objective (structure) (undefined unless successful)
proffered_Objective（構造）（成功しない限り未定義）
reason (string) (empty unless negotiation declined)
理由（文字列）（交渉が拒否されない限り空）
- This function opens a negotiation session between two ASAs. Note that GRASP currently does not support multiparty negotiation, which would need to be added as an extended function.
- この関数は、2つのASA間のネゴシエーションセッションを開きます。GRASPは現在マルチパーティネゴシエーションをサポートしていないことに注意してください。これは拡張機能として追加する必要があります。
- The 'objective' parameter must include the requested value, and its loop count should be set to a suitable starting value by the ASA. If not, the GRASP default will apply.
- 'Objective'パラメータに要求された値を含める必要があり、そのループ数はASAによって適切な開始値に設定されるべきです。そうでない場合は、graspデフォルトが適用されます。
- Note that a given negotiation session may or may not be a dry-run negotiation; the two modes must not be mixed in a single session.
- 特定のネゴシエーションセッションは、ドライランネゴシエーションである場合とそうでない場合があります。2つのモードを1つのセッションで混在させてはいけません。
- The 'peer' parameter is the target node; it must be an 'asa_locator' as returned by discover(). If 'peer' is null, GRASP discovery is automatically performed first to find a suitable peer (i.e., any node that supports the objective in question).
- 'peer'パラメータはターゲットノードです。Discover（）によって返される「asa_locator」でなければなりません。'peer'がnullの場合、graspディスカバリは最初に自動的に実行され、適切なピア（すなわち、問題の目的をサポートする任意のノード）が見つかる。
- The 'timeout' parameter is described in Section 2.3.2.3.
- 'timeout'パラメータはセクション2.3.2.3で説明されています。
- If the 'errorcode' return value is 0, the negotiation has successfully started. There are then two cases:
- 'ErrorCode'の戻り値が0の場合、ネゴシエーションは正常に起動しました。次に2つのケースがあります。
1. The 'session_handle' parameter is null. In this case, the negotiation has succeeded with one exchange of messages, and the peer has accepted the request. The returned 'proffered_objective' contains the value accepted by the peer, which is therefore equal to the value in the requested 'objective'. For this reason, no session handle is needed, since the session has ended.
1. 'session_handle'パラメータはnullです。この場合、ネゴシエーションは1つのメッセージの交換に成功し、ピアは要求を受け入れました。返された「proffered_Objective」には、ピアによって受け入れられた値が含まれています。したがって、要求された「目的」の値に等しい値が含まれています。このため、セッションが終了したため、セッションハンドルは必要ありません。
2. The 'session_handle' parameter is not null. In this case, negotiation must continue. The 'session_handle' must be presented in all subsequent negotiation steps. The returned 'proffered_objective' contains the first value proffered by the negotiation peer in the first exchange of messages; in other words, it is a counter-offer. The contents of this instance of the objective must be used to prepare the next negotiation step (see negotiate_step() below) because it contains the updated loop count, sent by the negotiation peer. The GRASP code automatically decrements the loop count by 1 at each step and returns an error if it becomes zero. Since this terminates the negotiation, the other end will experience a timeout, which will terminate the other end of the session.
2. 'session_handle'パラメータはnullではありません。この場合、ネゴシエーションは続行する必要があります。'session_handle'は、後続のすべてのネゴシエーションステップで提示されなければなりません。返された 'proffered_Objective'には、最初のメッセージ交換のネゴシエーションピアによって提供された最初の値が含まれています。言い換えれば、それはカウンターオファーです。この目的のこのインスタンスの内容は、次のネゴシエーションステップを準備するために使用されなければなりません（下記のnegotiate_step（）を参照）、ネゴシエーションピアによって送信された更新されたループ数が含まれているためです。GRASSコードは各ステップでループカウントを1で自動的にデクリメントし、ゼロになるとエラーを返します。これはネゴシエーションを終了するので、もう一方のエンドはタイムアウトを経験します。これによりセッションのもう一方の端を終了します。
This function must be followed by calls to 'negotiate_step' and/or 'negotiate_wait' and/or 'end_negotiate' until the negotiation ends. 'request_negotiate' may then be called again to start a new negotiation.
この関数の後には、ネゴシエーションが終了するまで、 'negotiate_step'および/または 'negotiate_wait'および/または 'end_negotiate'を呼び出す必要があります。新しいネゴシエーションを開始するために、 'request_negotiate'を再度呼び出すことができます。
- If the 'errorcode' parameter has the value 1 ('declined'), the negotiation has been declined by the peer (M_END and O_DECLINE features of GRASP). The 'reason' string is then available for information and diagnostic use, but it may be a null string. For this and any other error code, an exponential backoff is recommended before any retry (see Section 3).
- 'errorcode'パラメータの値1（ 'refined'）がある場合、ネゴシエーションはピア（GraspのM_EndおよびO_Declineの機能）によって拒否されました。その場合、「reason」文字列は情報と診断用の使用に使用できますが、NULL文字列である可能性があります。このエラーコードとその他のエラーコードについては、リトライの前に指数バックオフをお勧めします（セクション3を参照）。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: This should be called in a separate thread if asynchronous operation is required.
非同期操作が必要な場合は、スレッド実装：これを個別のスレッドで呼び出す必要があります。
Event loop implementation: The 'session_handle' parameter is used to distinguish multiple simultaneous sessions. If the 'errorcode' parameter has the value 2 ('noReply'), no response has been received so far. The 'session_handle' parameter must be presented in subsequent calls.
イベントループの実装：「session_handle」パラメータは、複数の同時セッションを区別するために使用されます。'errorcode'パラメータの値2（ 'noreply'）がある場合、これまでのところ応答は受け取られませんでした。'session_handle'パラメータは後続の呼び出しで表示する必要があります。
- Use of dry-run mode must be consistent within a GRASP session. The state of the 'dry' flag in the initial request_negotiate() call must be the same in all subsequent negotiation steps of the same session. The semantics of the dry-run mode are built into the ASA; GRASP merely carries the flag bit.
- ドライランモードの使用は、GRASSセッション内で一貫している必要があります。最初のrequest_negotiate（）呼び出しの「DRIOD」フラグの状態は、同じセッションの後続のすべてのネゴシエーションステップで同じでなければなりません。ドライランモードのセマンティクスはASAに組み込まれています。GRASPは単にフラグビットを運ぶだけです。
- Special note for the ACP infrastructure ASA: It is likely that this ASA will need to discover and negotiate with its peers in each of its on-link neighbors. It will therefore need to know not only the link-local IP address but also the physical interface and transport port for connecting to each neighbor. One implementation approach to this is to include these details in the 'session_handle' data structure, which is opaque to normal ASAs.
- ACPインフラストラクチャに関する特別ノートASA：このASAは、そのオンリンクネイバーのそれぞれのピアを発見して交渉する必要がある可能性があります。そのため、リンクローカルIPアドレスだけでなく、各ネイバーに接続するための物理インタフェースとトランスポートポートも知る必要があります。これに対する1つの実装的アプローチは、通常のASASに不透明な「Session_Handle」データ構造にこれらの詳細を含めることです。
* listen_negotiate()
* listen_negotiate（）
This function is used by an ASA to start acting as a negotiation responder (listener) for a given GRASP objective.
この関数は、ASAが特定のGRASP目的のためのネゴシエーションレスポンダ（リスナ）として機能することを開始することによって使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
- Return values:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
session_handle (structure) (undefined unless successful)
session_handle（構造）（成功しない限り未定義）
requested_objective (structure) (undefined unless successful)
requested_Objective（構造）（成功しない限り未定義）
- This function instructs GRASP to listen for negotiation requests for the given 'objective'. It also enables discovery responses for the objective, as mentioned under register_objective() in Section 2.3.3.
- この関数は、与えられた「目的」に対するネゴシエーション要求を聞くように把握します。また、セクション2.3.3のRegister_Objective（）で述べたように、目的の検出回答を有効にします。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: It will block waiting for an incoming request, so it should be called in a separate thread if asynchronous operation is required. Unless there is an unexpected failure, this call only returns after an incoming negotiation request. If the ASA supports multiple simultaneous transactions, a new sub-thread must be spawned for each new session, so that listen_negotiate() can be called again immediately.
スレッド実装：着信要求を待ってブロックするので、非同期操作が必要な場合は別のスレッドで呼び出される必要があります。予期しない失敗がない限り、この呼び出しは着信ネゴシエーション要求の後にのみ返します。ASAが複数の同時トランザクションをサポートしている場合は、新しいセッションごとに新しいサブスレッドを生成する必要があります。
Event loop implementation: A 'session_handle' parameter is used to distinguish individual sessions. If the ASA supports multiple simultaneous transactions, a new event must be inserted in the event loop for each new session, so that listen_negotiate() can be reactivated immediately.
イベントループの実装：「session_handle」パラメータは、個々のセッションを区別するために使用されます。ASAが複数の同時トランザクションをサポートしている場合は、新しいセッションごとに新しいイベントをイベントループに挿入する必要があります。その結果、listin_negotiate（）をすぐに再アクティブ化できます。
- This call only returns (threaded model) or triggers (event loop) after an incoming negotiation request. When this occurs, 'requested_objective' contains the first value requested by the negotiation peer. The contents of this instance of the objective must be used in the subsequent negotiation call because it contains the loop count sent by the negotiation peer. The 'session_handle' must be presented in all subsequent negotiation steps.
- この呼び出しは、着信ネゴシエーション要求の後に（スレッドモデル）またはトリガー（イベントループ）のみを返します。これが発生すると、 'requested_Objective'にはネゴシエーションピアによって要求された最初の値が含まれています。この目的のこのインスタンスの内容は、ネゴシエーションピアによって送信されたループカウントが含まれているため、後続のネゴシエーション呼び出しで使用する必要があります。'session_handle'は、後続のすべてのネゴシエーションステップで提示されなければなりません。
- This function must be followed by calls to 'negotiate_step' and/or 'negotiate_wait' and/or 'end_negotiate' until the negotiation ends.
- この関数の後には、ネゴシエーションが終了するまで、 'negotiate_step'および/または 'negotiate_wait'および/または 'end_negotiate'を呼び出す必要があります。
- If an ASA is capable of handling multiple negotiations simultaneously, it may call 'listen_negotiate' simultaneously from multiple threads, or insert multiple events. The API and GRASP implementation must support re-entrant use of the listening state and the negotiation calls. Simultaneous sessions will be distinguished by the threads or events themselves, the GRASP session handles, and the underlying unicast transport sockets.
- ASAが複数のネゴシエーションを同時に処理できる場合は、複数のスレッドから同時に「listen_negotiate」または複数のイベントを挿入することができます。APIおよびGRASPの実装は、リスニング状態とネゴシエーション呼び出しの再参加者の使用をサポートしている必要があります。同時セッションは、スレッドまたはイベント自体、把握セッションハンドル、および基礎となるユニキャストトランスポートソケットによって区別されます。
* stop_listen_negotiate()
* stop_listen_negotiate（）
This function is used by an ASA to stop acting as a responder (listener) for a given GRASP objective.
この機能は、ASAが特定のGRASP目的のためのレスポンダ（リスナー）として機能する停止を停止することによって使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- Instructs GRASP to stop listening for negotiation requests for the given objective, i.e., cancels 'listen_negotiate'.
- 与えられた目的のためのネゴシエーション要求のリスニングを停止するように把握し、すなわち「listen_negotiate」をキャンセルするように指示します。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: Must be called from a different thread than 'listen_negotiate'.
スレッド実装： 'listen_negotiate'より異なるスレッドから呼び出す必要があります。
Event loop implementation: No special considerations.
イベントループの実装：特別な考慮事項はありません。
* negotiate_step()
* negotiate_step（）
This function is used by either ASA in a negotiation session to make the next step in negotiation.
この関数は、ネゴシエーションセッションのASAによって使用され、次のステップをネゴシエーションにします。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
session_handle (structure)
session_handle（構造）
objective (structure)
目的（構造）
timeout (unsigned integer) as described in Section 2.3.2.3
2.3.2.3項の説明に従ってタイムアウト（符号なし整数）
- Return values:
- 戻り値：
Exactly as for 'request_negotiate'
'request_negotiate'とまさに
- Executes the next negotiation step with the peer. The 'objective' parameter contains the next value being proffered by the ASA in this step. It must also contain the latest 'loop_count' value received from request_negotiate() or negotiate_step().
- ピアを使って次のネゴシエーションステップを実行します。'Objective'パラメータには、このステップでASAによってプロファレートされている次の値が含まれています。Request_Negotiate（）またはNegotiate_Step（）から受信した最新の 'loop_count'値も含まなければなりません。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: Usually called in the same thread as the preceding 'request_negotiate' or 'listen_negotiate', with the same value of 'session_handle'.
スレッド実装：通常、前の 'request_negotiate'または 'listen_negotiate'と同じスレッドで呼び出され、同じ値 'session_handle'。
Event loop implementation: Must use the same value of 'session_handle' returned by the preceding 'request_negotiate' or 'listen_negotiate'.
イベントループの実装：前の 'request_negotiate'または 'listen_negotiate'によって返されるのと同じ値の 'session_handle'を使用する必要があります。
* negotiate_wait()
* negotiate_wait（）
This function is used by either ASA in a negotiation session to delay the next step in negotiation.
この関数は、ネゴシエーションセッション内のASAのいずれかによって使用され、ネゴシエーションの次のステップを遅らせます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
session_handle (structure)
session_handle（構造）
timeout (unsigned integer)
タイムアウト（符号なし整数）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- Requests the remote peer to delay the negotiation session by 'timeout' milliseconds, thereby extending the original timeout. This function simply triggers a GRASP Confirm Waiting message (see [RFC8990] for details).
- リモートピアに「タイムアウト」ミリ秒でネゴシエーションセッションを遅らせるように要求し、それによって元のタイムアウトを拡張します。この関数は単に把握の確認待機メッセージを引き起こします（詳細は[RFC8990]を参照）。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: Called in the same thread as the preceding 'request_negotiate' or 'listen_negotiate', with the same value of 'session_handle'.
スレッド実装：前の 'request_negotiate'または 'listin_negotiate'と同じスレッドで呼び出され、同じ値 'session_handle'。
Event loop implementation: Must use the same value of 'session_handle' returned by the preceding 'request_negotiate' or 'listen_negotiate'.
イベントループの実装：前の 'request_negotiate'または 'listen_negotiate'によって返されるのと同じ値の 'session_handle'を使用する必要があります。
* end_negotiate()
* end_negotiate（）
This function is used by either ASA in a negotiation session to end a negotiation.
この関数は、ネゴシエーションセッションのASAのどちらかで使用され、ネゴシエーションを終了します。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
session_handle (structure)
session_handle（構造）
result (Boolean)
結果（ブール値）
reason (UTF-8 string)
理由（UTF-8文字列）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- End the negotiation session:
- ネゴシエーションセッションを終了します。
'result' = True for accept (successful negotiation), and False for decline (failed negotiation).
'result' = accept（交渉の成功）でtrue、辞退の場合はfalse（失敗したネゴシエーション）。
'reason' = string describing reason for decline (may be null; ignored if accept).
'reason' =拒否の理由を記述する文字列（nullかもしれません。受け入れられれば無視されます）。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: Called in the same thread as the preceding 'request_negotiate' or 'listen_negotiate', with the same value of 'session_handle'.
スレッド実装：前の 'request_negotiate'または 'listin_negotiate'と同じスレッドで呼び出され、同じ値 'session_handle'。
Event loop implementation: Must use the same value of 'session_handle' returned by the preceding 'request_negotiate' or 'listen_negotiate'.
イベントループの実装：前の 'request_negotiate'または 'listen_negotiate'によって返されるのと同じ値の 'session_handle'を使用する必要があります。
* synchronize()
* 同期（）
This function is used by any ASA to cause synchronization of a GRASP objective as a requester (client).
この関数は、任意のASAがgrasp目標を要求者（クライアント）として同期させるために使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
peer (asa_locator)
ピア（ASA_LOCORATOR）
timeout (unsigned integer)
タイムアウト（符号なし整数）
- Return values:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
result (structure) (undefined unless successful)
結果（構造）（成功しない限り未定義）
- This call requests the synchronized value of the given 'objective'.
- この呼び出しは、与えられた「目的」の同期値を要求します。
- If the 'peer' parameter is null, and the objective is already available in the local cache, the flooded objective is returned immediately in the 'result' parameter. In this case, the 'timeout' is ignored.
- 「Peer」パラメータがNULLで、目的がローカルキャッシュですでに利用可能な場合、フラッグ付きの目的は「result」パラメータにすぐに返されます。この場合、「タイムアウト」は無視されます。
- If the 'peer' parameter is not null, or a cached value is not available, synchronization with a discovered ASA is performed. If successful, the retrieved objective is returned in the 'result' value.
- 「ピア」パラメータがNULLでないか、キャッシュされた値が利用できない場合、検出されたASAとの同期が実行されます。成功した場合、取得した目的は 'result'値に返されます。
- The 'peer' parameter is an 'asa_locator' as returned by discover(). If 'peer' is null, GRASP discovery is automatically performed first to find a suitable peer (i.e., any node that supports the objective in question).
- 'peer'パラメータはdiscover（）によって返される 'asa_locator'です。'peer'がnullの場合、graspディスカバリは最初に自動的に実行され、適切なピア（すなわち、問題の目的をサポートする任意のノード）が見つかる。
- The 'timeout' parameter is described in Section 2.3.2.3.
- 'timeout'パラメータはセクション2.3.2.3で説明されています。
- This call should be repeated whenever the latest value is needed.
- 最新の値が必要なときはいつでもこの呼び出しを繰り返す必要があります。
- Asynchronous Mechanisms:
- 非同期メカニズム：
Threaded implementation: Call in a separate thread if asynchronous operation is required.
スレッド実装：非同期操作が必要な場合は、別のスレッドで呼び出します。
Event loop implementation: An additional in/out 'session_handle' parameter is used, as in request_negotiate(). If the 'errorcode' parameter has the value 2 ('noReply'), no response has been received so far. The 'session_handle' parameter must be presented in subsequent calls.
イベントループの実装：request_negotiate（）のように、追加のIN / OUT 'session_handle'パラメータが使用されます。'errorcode'パラメータの値2（ 'noreply'）がある場合、これまでのところ応答は受け取られませんでした。'session_handle'パラメータは後続の呼び出しで表示する必要があります。
- In the case of failure, an exponential backoff is recommended before retrying (Section 3).
- 障害の場合は、再試行する前に指数バックオフをお勧めします（セクション3）。
* listen_synchronize()
* listen_synchronize（）
This function is used by an ASA to start acting as a synchronization responder (listener) for a given GRASP objective.
この関数は、ASAが所与の把握対象の同期レスポンダ（リスナー）として機能する開始を開始することによって使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- This instructs GRASP to listen for synchronization requests for the given objective and to respond with the value given in the 'objective' parameter. It also enables discovery responses for the objective, as mentioned under register_objective() in Section 2.3.3.
- これにより、指定された目的の同期要求をリッスンし、 'Objective'パラメータで指定された値で応答するように把握します。また、セクション2.3.3のRegister_Objective（）で述べたように、目的の検出回答を有効にします。
- This call is non-blocking and may be repeated whenever the value changes.
- この呼び出しはノンブロッキングであり、値が変わるたびに繰り返される可能性があります。
* stop_listen_synchronize()
* stop_listen_synchronize（）
This function is used by an ASA to stop acting as a synchronization responder (listener) for a given GRASP objective.
この関数は、ASAが所与のGRASP対象の同期レスポンダ（リスナ）として機能する停止を停止することによって使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- This call instructs GRASP to stop listening for synchronization requests for the given 'objective', i.e., it cancels a previous listen_synchronize.
- この呼び出しは、与えられた「目的」に対する同期要求のためのリスニングを停止するように把握します。すなわち、以前のlisten_synchronizeをキャンセルします。
* flood()
* 洪水（）
This function is used by an ASA to flood one or more GRASP objectives throughout the Autonomic Network.
この関数はASAが自律型ネットワーク全体を通して1つ以上の把握目的をフラッディングするためにASAによって使用されます。
Note that each GRASP node caches all flooded objectives that it receives, until each one's time to live expires. Cached objectives are tagged with their origin as well as an expiry time, so multiple copies of the same objective may be cached simultaneously. Further details are given in "Flood Synchronization Message" (Section 2.8.11 of [RFC8990]).
各把持ノードは、それが受信したすべてのあふれされた目的をキャッシュします。キャッシュされた目的は、有効期限と同様にそれらの起源とタグ付けされているので、同じ目的の複数のコピーが同時にキャッシュされる可能性があります。詳細は「フラッド同期メッセージ」（[RFC8990]のセクション2.8.11）に記載されています。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
ttl (unsigned integer)
TTL（符号なし整数）
tagged_objective_list (structure)
tagged_objective_list（構造）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- This call instructs GRASP to flood the given synchronization objective(s) and their value(s) and associated locator(s) to all GRASP nodes.
- この呼び出しは、与えられた同期目標をフラッディングし、それらの値（S）および関連するロケータをすべてのGRASPノードにフラッディングするように把握します。
- The 'ttl' parameter is the valid lifetime (time to live) of the flooded data in milliseconds (0 = infinity).
- 'ttl'パラメータは、フラッディングされたデータの有効な有効期間（生存時間）（0 = Infinity）です。
- The 'tagged_objective_list' parameter is a list of one or more 'tagged_objective' couplets. The 'locator' parameter that tags each objective is normally null but may be a valid 'asa_locator'. Infrastructure ASAs needing to flood an {address, protocol, port} 3-tuple with an objective create an asa_locator object to do so. If the IP address in that locator is the unspecified address ('::'), it is replaced by the link-local address of the sending node in each copy of the flood multicast, which will be forced to have a loop count of 1. This feature is for objectives that must be restricted to the local link.
- 'tagged_objective_list'パラメータは、1つ以上の 'Tagged_Objective' Coupletsのリストです。各目的のタグをタグ付けする 'locator'パラメータは通常nullですが、有効な 'asa_locator'でもかまいません。Infrastructure ASAは、{Address、Protocol、Port} 3-Tupleを目的で埋め込む必要があります。そのロケータ内のIPアドレスが不特定アドレス（ '::'）の場合、それはフラッドマルチキャストの各コピー内の送信ノードのリンクローカルアドレスに置き換えられます。これは、ループ数を1にすることを余儀なくされます。。この機能は、ローカルリンクに制限されなければならない目的のためのものです。
- The function checks that the ASA registered each objective.
- この関数は、ASAが各目的を登録したことを確認します。
- This call may be repeated whenever any value changes.
- この呼び出しは、任意の値が変わるたびに繰り返されます。
* get_flood()
* get_flood（）
This function is used by any ASA to obtain the current value of a flooded GRASP objective.
この機能は、あふれされた把持目的の現在の値を取得するために任意のASAによって使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
objective (structure)
目的（構造）
- Return values:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
tagged_objective_list (structure) (undefined unless successful)
tagged_objective_list（構造）（成功しない限り未定義）
- This call instructs GRASP to return the given synchronization objective if it has been flooded and its lifetime has not expired.
- この呼び出しは、それがあふれていて、その生涯が期限切れになっていない場合、与えられた同期目標を返すように把握します。
- The 'tagged_objective_list' parameter is a list of 'tagged_objective' couplets, each one being a copy of the flooded objective and a corresponding locator. Thus, if the same objective has been flooded by multiple ASAs, the recipient can distinguish the copies.
- 'tagged_objective_list'パラメータは 'tagged_Objective' coupletsのリストです。それぞれは、あふれされた目的と対応するロケータのコピーです。したがって、同じ目的が複数のASAによってあふれている場合、受信者はコピーを区別することができます。
- Note that this call is for advanced ASAs. In a simple case, an ASA can simply call synchronize() in order to get a valid flooded objective.
- この呼び出しはASAS ASAS用です。簡単な場合では、有効なあふれされた目的を得るために、ASAは単にSynchronize（）を呼び出すことができます。
* expire_flood()
* expire_flood（）
This function may be used by an ASA to expire specific entries in the local GRASP flood cache.
この機能は、ASAがローカルの把持フラッドキャッシュ内の特定のエントリを期限切れにするために使用されます。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
tagged_objective (structure)
tagged_Objective（構造）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- This is a call that can only be used after a preceding call to get_flood() by an ASA that is capable of deciding that the flooded value is stale or invalid. Use with care.
- これは、フラッディングされた値が古くなっているか無効であることを決定することができるASAによって、get_flood（）への前の呼び出しの後にのみ使用できる呼び出しです。注意して使用してください。
- The 'tagged_objective' parameter is the one to be expired.
- 'tagged_objective'パラメータは期限切れのものです。
* send_invalid()
* send_invalid（）
This function may be used by any ASA to stop an ongoing GRASP session.
この機能は、継続的なGRASPセッションを停止するために任意のASAによって使用される可能性があります。
- Input parameters:
- 入力パラメータ：
asa_handle (unsigned integer)
ASA_HANDLE（符号なし整数）
session_handle (structure)
session_handle（構造）
info (bytes)
情報（バイト）
- Return value:
- 戻り値：
errorcode (unsigned integer)
エラーコード（符号なし整数）
- Sends a GRASP Invalid message (M_INVALID), as described in [RFC8990]. It should not be used if end_negotiate() would be sufficient. Note that this message may be used in response to any unicast GRASP message that the receiver cannot interpret correctly. In most cases, this message will be generated internally by a GRASP implementation.
- [RFC8990]の説明に従って、把握無効なメッセージ（M_INVALID）を送信します。end_negotiate（）が十分である場合は使用しないでください。このメッセージは、受信者が正しく解釈できないというユニキャスト把握メッセージに応答して使用され得ることに注意してください。ほとんどの場合、このメッセージは把握実装によって内部的に生成されます。
'info' = optional diagnostic data supplied by the ASA. It may be raw bytes from the invalid message.
'info' = ASAによって提供されるオプションの診断データ。無効なメッセージからの生のバイトかもしれません。
Security considerations for the GRASP protocol are discussed in [RFC8990]. These include denial-of-service issues, even though these are considered a low risk in the ACP. In various places, GRASP recommends an exponential backoff. An ASA using the API should use exponential backoff after failed discover(), req_negotiate(), or synchronize() operations. The timescale for such backoffs depends on the semantics of the GRASP objective concerned. Additionally, a flood() operation should not be repeated at shorter intervals than is useful. The appropriate interval depends on the semantics of the GRASP objective concerned. These precautions are intended to assist the detection of denial-of-service attacks.
GRASPプロトコルのセキュリティ上の考慮事項は[RFC8990]で説明されています。これらはACPのリスクが低いと考えられていても、サービス拒否の問題が含まれます。さまざまな場所では、把握は指数関数的なバックオフを推奨します。APIを使用したASAは、failed discover（）、req_negotiate（）、またはsynchronize（）操作の後に指数バックオフを使用する必要があります。そのようなバックオフのためのタイムスケールは、関係する把握目的の意味によって異なります。さらに、洪水（）操作は有用であるよりも短い間隔で繰り返さないようにしてください。適切な間隔は、関係する把持目的の意味論に依存します。これらの注意事項は、サービス拒否攻撃の検出を支援することを目的としています。
As a general precaution, all ASAs able to handle multiple negotiation or synchronization requests in parallel may protect themselves against a denial-of-service attack by limiting the number of requests they handle simultaneously and silently discarding excess requests. It might also be useful for the GRASP core to limit the number of objectives registered by a given ASA, the total number of ASAs registered, and the total number of simultaneous sessions, to protect system resources. During times of high autonomic activity, such as recovery from widespread faults, ASAs may experience many GRASP session failures. Guidance on making ASAs suitably robust is given in [ASA-GUIDE].
一般的な予防措置として、複数のネゴシエーションまたは同期要求を並行して処理できるすべてのASAは、過剰な要求を同時に静止している要求の数を制限することによって、サービス拒否攻撃に対して自分自身を保護することができます。把握コアが、システムリソースを保護するために、特定のASA、登録されているASAの総数、および同時セッションの総数の数を制限するのに役立ちます。広範囲の故障からの回復のような高い自律神経活動の時代には、ASAは多くの把握セッション障害を経験することがあります。ASAガイドでは、ASAを適切に堅牢にすることに関するガイダンスが与えられています。
As noted earlier, the trust model is that all ASAs in a given Autonomic Network communicate via a secure autonomic control plane; therefore, they trust each other's messages. Specific authorization of ASAs to use particular GRASP objectives is a subject for future study, also briefly discussed in [RFC8990].
前述のように、信頼モデルは、特定の自律神経ネットワーク内のすべてのASAが安全な自律神経制御プレーンを介して通信することです。したがって、彼らはお互いのメッセージを信頼します。特定の把握目的を使用するためのASAの具体的な許可は、[RFC8990]で簡単に議論された将来の研究の対象です。
The careful reader will observe that a malicious ASA could extend a negotiation session indefinitely by use of the negotiate_wait() function or by manipulating the loop count of an objective. A robustly implemented ASA could detect such behavior by a peer and break off negotiation.
慎重な読者は、Negotiate_Wait（）関数を使用するか、または目的のループ数を操作することによって、悪意のあるASAがネゴシエーションセッションを無期限に拡張できることを確認します。堅牢に実装されたASAは、そのような行動をピアで検出し、交渉を遮断することができます。
The 'asa_handle' is used in the API as a first line of defense against a malware process attempting to imitate a legitimately registered ASA. The 'session_handle' is used in the API as a first line of defense against a malware process attempting to hijack a GRASP session. Both these handles are likely to be created using GRASP's 32-bit pseudorandom Session ID. By construction, GRASP avoids the risk of Session ID collisions (see "Session Identifier (Session ID)", Section 2.7 of [RFC8990]). There remains a finite probability that an attacker could guess a Session ID, session_handle, or asa_handle. However, this would only be of value to an attacker that had already penetrated the ACP, which would allow many other simpler forms of attack than hijacking GRASP sessions.
'asa_handle'は、正当な登録されたASAを模倣しようとしているマルウェアプロセスに対する防御の最初の国防総省として、APIで使用されています。'session_handle'は、Graspセッションをハイジャックしようとしているマルウェアプロセスに対する防御の最初の防御行としてAPIで使用されます。これらのハンドルはどちらもGRASPの32ビット疑似ランダムセッションIDを使用して作成される可能性があります。構築により、GRASPはセッションIDの衝突のリスクを回避します（「セッションID（セッションID）」、[RFC8990]のセクション2.7）。攻撃者がセッションID、SESSION_HANDLE、またはASA_HANDLEを推測できるという有限の確率が残っています。しかし、これはすでにACPを透過した攻撃者にのみ価値があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/info/rfc8990>.
[RFC8990] Bormann、C、Carpenter、B.、ED。、およびB.IU、ED。、「GENICAL自律型シグナリングプロトコル（GRASP）」、RFC 8990、DOI 10.17487 / RFC8990、2021年5月、<https：//www.rfc-editor.org/info/rfc8990>。
[ANIMA-COORD] Ciavaglia, L. and P. Peloso, "Autonomic Functions Coordination", Work in Progress, Internet-Draft, draft-ciavaglia-anima-coordination-01, 21 March 2016, <https://tools.ietf.org/html/draft-ciavaglia-anima-coordination-01>.
[Anima-Coord] Ciavaglia、L.およびP. Peloso、「自律型機能調整」、進行中の作業、インターネットドラフト、ドラフト - Ciavaglia-Anima-Coordination-01,2016、<https：//tools.ietf.org / html / draft-ciavaglia-anima-cordination-01>。
[ASA-GUIDE] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso, "Guidelines for Autonomic Service Agents", Work in Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-00, 14 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-asa-guidelines-00>.
[浅ガイド]大工、B.、Ciavaglia、L.、Jiang、S.、およびP. Peloso、「自律サービスエージェントのためのガイドライン」、進捗状況、インターネットドラフト、ドラフトIETF-ANIMA-ASAガイドライン-00、2020年11月14日、<https://tools.ietf.org/html/draft-ietf-anima-asa-guldelines-00>。
[GRASP-DISTRIB] Liu, B., Xiao, X., Hecker, A., Jiang, S., Despotovic, Z., and B. Carpenter, "Information Distribution over GRASP", Work in Progress, Internet-Draft, draft-ietf-anima-grasp-distribution-02, 8 March 2021, <https://tools.ietf.org/html/draft-ietf-anima-grasp-distribution-02>.
[把持分配] Liu、B.、Xiao、X.、Hecker、A.、Jiang、S.、Pessotovic、Z.、およびB. Carpenter、「情報配信上の情報配信」、進行中、インターネットドラフト、draft-ietf-anima-grasp-distribution-02,2月8日、<https://tools.ietf.org/html/draft-ietf-anima-grasp-distribution-02>。
[libcbor] Kalvoda, P., "libcbor - libcbor 0.8.0 documentation", April 2021, <https://libcbor.readthedocs.io/>.
[Libcbor]カルボダ、P.、 "Libcbor - Libcbor 0.8.0 Documentation"、2021年4月、<https://libcbor.readthedocs.io/>。
[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, <https://www.rfc-editor.org/info/rfc8993>.
[RFC8993] Behringer、M.、Ed。、Carpenter、B.、Eckert、T.、Ciavaglia、L.、およびJ.Bobre、 "Autonomic Networkingのための参照モデル"、RFC 8993、DOI 10.17487 / RFC8993、2021年5月<https://www.rfc-editor.org/info/rfc8993>。
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.
[RFC8994] Eckert、T.、Ed。、Behringer、M.、Ed。、およびS.Bjarnason、「自律管理プレーン（ACP）」、RFC 8994、DOI 10.17487 / RFC8994、2021年5月、<https：//www.rfc-editor.org/info/rfc8994>。
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC8995] Pritikin、M.、Richardson、M.、Eckert、T.、Behringer、M.、およびK. Watsen、「ブートストラップリモートセキュリティキーインフラストラクチャ（Brski）」、RFC 8995、DOI 10.17487 / RFC8995、2021年5月<https://www.rfc-editor.org/info/rfc8995>。
This appendix lists the error codes defined so far on the basis of implementation experience, with suggested symbolic names and corresponding descriptive strings in English. It is expected that complete API implementations will provide for localization of these descriptive strings, and that additional error codes will be needed according to implementation details.
この付録では、実装エクスペリエンスに基づいて定義されたエラーコードと、推奨されるシンボル名と英語で対応する記述文字列を示します。完全なAPI実装がこれらの記述文字列のローカライズを提供し、追加のエラーコードが実装の詳細に従って必要とされることが予想されます。
The error codes that may only be returned by one or two functions are annotated accordingly, and the others may be returned by numerous functions. The 'noSecurity' error will be returned to most calls if GRASP is running in an insecure mode (i.e., with no secure substrate such as the ACP), except for the specific DULL usage mode described in "Discovery Unsolicited Link-Local (DULL) GRASP" (Section 2.5.2 of [RFC8990].
1つまたは2つの関数によってのみ返される可能性のあるエラーコードはそれに応じて注釈を付けられ、他の関数によって他の関数によって返されるかもしれません。GRASPが不安定なモードで実行されている場合（すなわち、非公式のリンク - ローカル（鈍感）に記載されている特定の鈍い使用モードを除いて、「NoSecurity」エラーはほとんどの呼び出しに返されます。grasp "（RFC8990のセクション2.5.2]。
+================+=======+=================================+
| Name | Error | Description |
| | Code | |
+================+=======+=================================+
| ok | 0 | "OK" |
+----------------+-------+---------------------------------+
| declined | 1 | "Declined" (req_negotiate, |
| | | negotiate_step) |
+----------------+-------+---------------------------------+
| noReply | 2 | "No reply" (indicates waiting |
| | | state in event loop calls) |
+----------------+-------+---------------------------------+
| unspec | 3 | "Unspecified error" |
+----------------+-------+---------------------------------+
| ASAfull | 4 | "ASA registry full" |
| | | (register_asa) |
+----------------+-------+---------------------------------+
| dupASA | 5 | "Duplicate ASA name" |
| | | (register_asa) |
+----------------+-------+---------------------------------+
| noASA | 6 | "ASA not registered" |
+----------------+-------+---------------------------------+
| notYourASA | 7 | "ASA registered but not by you" |
| | | (deregister_asa) |
+----------------+-------+---------------------------------+
| notBoth | 8 | "Objective cannot support both |
| | | negotiation and |
| | | synchronization" (register_obj) |
+----------------+-------+---------------------------------+
| notDry | 9 | "Dry-run allowed only with |
| | | negotiation" (register_obj) |
+----------------+-------+---------------------------------+
| notOverlap | 10 | "Overlap not supported by this |
| | | implementation" (register_obj) |
+----------------+-------+---------------------------------+
| objFull | 11 | "Objective registry full" |
| | | (register_obj) |
+----------------+-------+---------------------------------+
| objReg | 12 | "Objective already registered" |
| | | (register_obj) |
+----------------+-------+---------------------------------+
| notYourObj | 13 | "Objective not registered by |
| | | this ASA" |
+----------------+-------+---------------------------------+
| notObj | 14 | "Objective not found" |
+----------------+-------+---------------------------------+
| notNeg | 15 | "Objective not negotiable" |
| | | (req_negotiate, |
| | | listen_negotiate) |
+----------------+-------+---------------------------------+
| noSecurity | 16 | "No security" |
+----------------+-------+---------------------------------+
| noDiscReply | 17 | "No reply to discovery" |
| | | (req_negotiate) |
+----------------+-------+---------------------------------+
| sockErrNegRq | 18 | "Socket error sending |
| | | negotiation request" |
| | | (req_negotiate) |
+----------------+-------+---------------------------------+
| noSession | 19 | "No session" |
+----------------+-------+---------------------------------+
| noSocket | 20 | "No socket" |
+----------------+-------+---------------------------------+
| loopExhausted | 21 | "Loop count exhausted" |
| | | (negotiate_step) |
+----------------+-------+---------------------------------+
| sockErrNegStep | 22 | "Socket error sending |
| | | negotiation step" |
| | | (negotiate_step) |
+----------------+-------+---------------------------------+
| noPeer | 23 | "No negotiation peer" |
| | | (req_negotiate, negotiate_step) |
+----------------+-------+---------------------------------+
| CBORfail | 24 | "CBOR decode failure" |
| | | (req_negotiate, negotiate_step, |
| | | synchronize) |
+----------------+-------+---------------------------------+
| invalidNeg | 25 | "Invalid Negotiate message" |
| | | (req_negotiate, negotiate_step) |
+----------------+-------+---------------------------------+
| invalidEnd | 26 | "Invalid end message" |
| | | (req_negotiate, negotiate_step) |
+----------------+-------+---------------------------------+
| noNegReply | 27 | "No reply to negotiation step" |
| | | (req_negotiate, negotiate_step) |
+----------------+-------+---------------------------------+
| noValidStep | 28 | "No valid reply to negotiation |
| | | step" (req_negotiate, |
| | | negotiate_step) |
+----------------+-------+---------------------------------+
| sockErrWait | 29 | "Socket error sending wait |
| | | message" (negotiate_wait) |
+----------------+-------+---------------------------------+
| sockErrEnd | 30 | "Socket error sending end |
| | | message" (end_negotiate, |
| | | send_invalid) |
+----------------+-------+---------------------------------+
| IDclash | 31 | "Incoming request Session ID |
| | | clash" (listen_negotiate) |
+----------------+-------+---------------------------------+
| notSynch | 32 | "Not a synchronization |
| | | objective" (synchronize, |
| | | get_flood) |
+----------------+-------+---------------------------------+
| notFloodDisc | 33 | "Not flooded and no reply to |
| | | discovery" (synchronize) |
+----------------+-------+---------------------------------+
| sockErrSynRq | 34 | "Socket error sending synch |
| | | request" (synchronize) |
+----------------+-------+---------------------------------+
| noListener | 35 | "No synch listener" |
| | | (synchronize) |
+----------------+-------+---------------------------------+
| noSynchReply | 36 | "No reply to synchronization |
| | | request" (synchronize) |
+----------------+-------+---------------------------------+
| noValidSynch | 37 | "No valid reply to |
| | | synchronization request" |
| | | (synchronize) |
+----------------+-------+---------------------------------+
| invalidLoc | 38 | "Invalid locator" (flood) |
+----------------+-------+---------------------------------+
Table 1: Error Codes
表1：エラーコード
Acknowledgements
謝辞
Excellent suggestions were made by Ignas Bagdonas, Carsten Bormann, Laurent Ciavaglia, Roman Danyliw, Toerless Eckert, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Paul Kyzivat, Guangpeng Li, Michael Richardson, Joseph Salowey, Éric Vyncke, Magnus Westerlund, Rob Wilton, and other participants in the ANIMA WG and the IESG.
Ignas Bagdonas、Carsten Bormann、Laurent Ciavaglia、Laurent Ciavaglia、Laurent Ciavaglia、Toerless Eckert、Benjamin Kakuk、Erik Klawary、Murray Kikery、Guangpendson、マイカエル・リチャードソン、ジオスフ・サロン、Rob Wilton、Rob WiltonそしてAnima WGとIESGの他の参加者。
Authors' Addresses
著者の住所
Brian E. Carpenter School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
ブライアンE.カーペンターオークランド大学オブオークランド大学PB 92019オークランド1142ニュージーランド
Email: brian.e.carpenter@gmail.com
Bing Liu (editor) Huawei Technologies Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 China
Bing Liu（編集）Huawei Technologies Q14、Huawei Campus No.156 Beyqing Road Hai-Dian District、Beijing 100095中国
Email: leo.liubing@huawei.com
Wendong Wang BUPT University Beijing University of Posts & Telecom. No.10 Xitucheng Road Hai-Dian District, Beijing 100876 China
Wendong Wang Bupt大学北京大学投稿・テレコム。No.10 Xitucheng Road Hai-Dian District、北京100876中国
Email: wdwang@bupt.edu.cn
Xiangyang Gong BUPT University Beijing University of Posts & Telecom. No.10 Xitucheng Road Hai-Dian District, Beijing 100876 China
Xiangyang Gong Bupt University Beijing Posts＆Telecom。No.10 Xitucheng Road Hai-Dian District、北京100876中国
Email: xygong@bupt.edu.cn