[要約] RFC 5971は、GIST（General Internet Signalling Transport）プロトコルに関する標準仕様です。GISTは、インターネット上で信号伝送を行うための汎用的なトランスポートプロトコルであり、信号伝送の効率性と信頼性を向上させることを目的としています。
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 5971 Columbia U.
Category: Experimental R. Hancock
ISSN: 2070-1721 RMR
October 2010
GIST: General Internet Signalling Transport
要点：一般的なインターネットシグナル伝達輸送
Abstract
概要
This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.
このドキュメントは、ネットワークを通過するパスに沿った流量ごとのシグナリングメッセージのルーティングと輸送のプロトコルスタックを指定します。この設計では、一般的なメッセージングレイヤーである一般的なインターネットシグナリングトランスポート（GIST）の下で既存の輸送およびセキュリティプロトコルを使用します。これは、多様なシグナリングアプリケーションに共通のサービスを提供します。GISTは、シグナリングアプリケーションの状態自体を処理しませんが、フローパスに沿って両方向にメッセージの転送を可能にするために、基礎となる輸送およびセキュリティプロトコルの構成と自社の内部状態と構成を管理します。GISTと下層輸送およびセキュリティプロトコルの組み合わせは、「シグナリングの次のステップ」（NSIS）フレームワークの基本プロトコルコンポーネントのソリューションを提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5971.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5971で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation and Terminology . . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overall Design Approach . . . . . . . . . . . . . . . . . 8
3.2. Modes and Messaging Associations . . . . . . . . . . . . 10
3.3. Message Routing Methods . . . . . . . . . . . . . . . . . 11
3.4. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 13
3.5. GIST Peering Relationships . . . . . . . . . . . . . . . 14
3.6. Effect on Internet Transparency . . . . . . . . . . . . . 14
3.7. Signalling Sessions . . . . . . . . . . . . . . . . . . . 15
3.8. Signalling Applications and NSLPIDs . . . . . . . . . . . 16
3.9. GIST Security Services . . . . . . . . . . . . . . . . . 17
3.10. Example of Operation . . . . . . . . . . . . . . . . . . 18
4. GIST Processing Overview . . . . . . . . . . . . . . . . . . 20
4.1. GIST Service Interface . . . . . . . . . . . . . . . . . 21
4.2. GIST State . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Basic GIST Message Processing . . . . . . . . . . . . . . 25
4.4. Routing State and Messaging Association Maintenance . . . 33
5. Message Formats and Transport . . . . . . . . . . . . . . . . 45
5.1. GIST Messages . . . . . . . . . . . . . . . . . . . . . . 45
5.2. Information Elements . . . . . . . . . . . . . . . . . . 48
5.3. D-mode Transport . . . . . . . . . . . . . . . . . . . . 53
5.4. C-mode Transport . . . . . . . . . . . . . . . . . . . . 58
5.5. Message Type/Encapsulation Relationships . . . . . . . . 59
5.6. Error Message Processing . . . . . . . . . . . . . . . . 60
5.7. Messaging Association Setup . . . . . . . . . . . . . . . 61
5.8. Specific Message Routing Methods . . . . . . . . . . . . 66
6. Formal Protocol Specification . . . . . . . . . . . . . . . . 71
6.1. Node Processing . . . . . . . . . . . . . . . . . . . . . 73
6.2. Query Node Processing . . . . . . . . . . . . . . . . . . 75
6.3. Responder Node Processing . . . . . . . . . . . . . . . . 79
6.4. Messaging Association Processing . . . . . . . . . . . . 83
7. Additional Protocol Features . . . . . . . . . . . . . . . . 86
7.1. Route Changes and Local Repair . . . . . . . . . . . . . 86
7.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 93
7.3. Interaction with IP Tunnelling . . . . . . . . . . . . . 99
7.4. IPv4-IPv6 Transition and Interworking . . . . . . . . . . 100
8. Security Considerations . . . . . . . . . . . . . . . . . . . 101
8.1. Message Confidentiality and Integrity . . . . . . . . . . 102
8.2. Peer Node Authentication . . . . . . . . . . . . . . . . 102
8.3. Routing State Integrity . . . . . . . . . . . . . . . . . 103
8.4. Denial-of-Service Prevention and Overload Protection . . 104
8.5. Requirements on Cookie Mechanisms . . . . . . . . . . . . 106
8.6. Security Protocol Selection Policy . . . . . . . . . . . 108
8.7. Residual Threats . . . . . . . . . . . . . . . . . . . . 109
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1. Normative References . . . . . . . . . . . . . . . . . . 118
11.2. Informative References . . . . . . . . . . . . . . . . . 119
Appendix A. Bit-Level Formats and Error Messages . . . . . . . . 122
A.1. The GIST Common Header . . . . . . . . . . . . . . . . . 122
A.2. General Object Format . . . . . . . . . . . . . . . . . . 123
A.3. GIST TLV Objects . . . . . . . . . . . . . . . . . . . . 125
A.4. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 134
Appendix B. API between GIST and Signalling Applications . . . . 143
B.1. SendMessage . . . . . . . . . . . . . . . . . . . . . . . 143
B.2. RecvMessage . . . . . . . . . . . . . . . . . . . . . . . 145
B.3. MessageStatus . . . . . . . . . . . . . . . . . . . . . . 146
B.4. NetworkNotification . . . . . . . . . . . . . . . . . . . 147
B.5. SetStateLifetime . . . . . . . . . . . . . . . . . . . . 148
B.6. InvalidateRoutingState . . . . . . . . . . . . . . . . . 148
Appendix C. Deployment Issues with Router Alert Options . . . . 149
Appendix D. Example Routing State Table and Handshake . . . . . 151
Signalling involves the manipulation of state held in network elements. 'Manipulation' could mean setting up, modifying, and tearing down state; or it could simply mean the monitoring of state that is managed by other mechanisms. This specification concentrates mainly on path-coupled signalling, controlling resources on network elements that are located on the path taken by a particular data flow, possibly including but not limited to the flow endpoints. Examples of state management include network resource reservation, firewall configuration, and state used in active networking; examples of state monitoring are the discovery of instantaneous path properties, such as available bandwidth or cumulative queuing delay. Each of these different uses of signalling is referred to as a signalling application.
シグナル伝達には、ネットワーク要素に保持されている状態の操作が含まれます。「操作」とは、状態のセットアップ、変更、破壊を意味する場合があります。または、他のメカニズムによって管理される状態の監視を意味するだけです。この仕様は、主にパス共役シグナル伝達に集中し、特定のデータフローによって採取されたパスにあるネットワーク要素のリソースを制御します。国家管理の例には、ネットワークリソースの予約、ファイアウォールの構成、アクティブネットワーキングで使用される状態が含まれます。状態監視の例は、利用可能な帯域幅や累積キューイング遅延などの瞬間的な経路特性の発見です。これらの異なるシグナリングの使用はそれぞれ、シグナリングアプリケーションと呼ばれます。
GIST assumes other mechanisms are responsible for controlling routing within the network, and GIST is not designed to set up or modify paths itself; therefore, it is complementary to protocols like Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [22] or LDP [23] rather than an alternative. There are almost always more than two participants in a path-coupled signalling session, although there is no need for every node on the path to participate; indeed, support for GIST and any signalling applications imposes a performance cost, and deployment for flow-level signalling is much more likely on edge devices than core routers. GIST path-coupled signalling does not directly support multicast flows, but the current GIST design could be extended to do so, especially in environments where the multicast replication points can be made GIST-capable. GIST can also be extended to cover other types of signalling pattern, not related to any end-to-end flow in the network, in which case the distinction between GIST and end-to-end higher-layer signalling will be drawn differently or not at all.
GISTは、他のメカニズムがネットワーク内のルーティングの制御に責任があると想定しており、GISTはパス自体をセットアップまたは変更するようには設計されていません。したがって、代替ではなく、リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）[22]またはLDP [23]などのプロトコルを補完します。パス結合シグナリングセッションには、ほとんど常に2人以上の参加者がいますが、参加するパス上のすべてのノードは必要ありません。実際、GISTおよびシグナリングアプリケーションのサポートはパフォーマンスコストを課し、フローレベルのシグナリングの展開は、コアルーターよりもエッジデバイスではるかに可能性が高くなります。GISTパス共役シグナル伝達はマルチキャストフローを直接サポートしませんが、特にマルチキャスト複製ポイントをGIST対応にすることができる環境では、現在のGIST設計を拡張することができます。GISTは、ネットワーク内のエンドツーエンドのフローとは関係のない他のタイプのシグナル伝達パターンをカバーするために拡張することもできます。まったく。
Every signalling application requires a set of state management rules, as well as protocol support to exchange messages along the data path. Several aspects of this protocol support are common to all or a large number of signalling applications, and hence can be developed as a common protocol. The NSIS framework given in [29] provides a rationale for a function split between the common and application-specific protocols, and gives outline requirements for the former, the NSIS Transport Layer Protocol (NTLP). Several concepts in the framework are derived from RSVP [14], as are several aspects of the GIST protocol design. The application-specific protocols are referred to as NSIS Signalling Layer Protocols (NSLPs), and are defined in separate documents. The NSIS framework [29] and the accompanying threats document [30] provide important background information to this specification, including information on how GIST is expected to be used in various network types and what role it is expected to perform.
すべてのシグナリングアプリケーションには、データパスに沿ってメッセージを交換するためのプロトコルサポートと同様に、州の管理ルールのセットが必要です。このプロトコルサポートのいくつかの側面は、すべてまたは多数のシグナリングアプリケーションに共通しているため、共通のプロトコルとして開発できます。[29]に与えられたNSISフレームワークは、一般的なプロトコルとアプリケーション固有のプロトコル間の関数分割の理論的根拠を提供し、前者のNSIS輸送層プロトコル（NTLP）のアウトライン要件を提供します。フレームワークのいくつかの概念は、GISTプロトコル設計のいくつかの側面と同様に、RSVP [14]から派生しています。アプリケーション固有のプロトコルは、NSISシグナル伝達層プロトコル（NSLP）と呼ばれ、個別のドキュメントで定義されています。NSISフレームワーク[29]および付随する脅威文書[30]は、さまざまなネットワークタイプでGISTがどのように使用されるか、どのような役割を実行するかについての情報を含む、この仕様に重要な背景情報を提供します。
This specification provides a concrete solution for the NTLP. It is based on the use of existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST). GIST does not handle signalling application state itself; in that crucial respect, it differs from higher layer signalling protocols such as SIP, the Real-time Streaming Protocol (RTSP), and the control component of FTP. Instead, GIST manages its own internal state and the configuration of the underlying transport and security protocols to ensure the transfer of signalling messages on behalf of signalling applications in both directions along the flow path. The purpose of GIST is thus to provide the common functionality of node discovery, message routing, and message transport in a way that is simple for multiple signalling applications to re-use.
この仕様は、NTLPの具体的なソリューションを提供します。これは、一般的なメッセージングレイヤーである一般的なインターネットシグナリングトランスポート（GIST）の下での既存の輸送およびセキュリティプロトコルの使用に基づいています。GISTは、シグナリングアプリケーションの状態自体を処理しません。その重要な点では、SIP、リアルタイムストリーミングプロトコル（RTSP）、FTPの制御コンポーネントなどの高層シグナル伝達プロトコルとは異なります。代わりに、GISTは独自の内部状態と基礎となる輸送およびセキュリティプロトコルの構成を管理し、フローパスに沿った両方向にシグナリングアプリケーションに代わってシグナリングメッセージの転送を確保します。したがって、GISTの目的は、複数のシグナリングアプリケーションが再利用できるように簡単な方法で、ノードの発見、メッセージルーティング、およびメッセージトランスポートの共通の機能を提供することです。
The structure of this specification is as follows. Section 2 defines terminology, and Section 3 gives an informal overview of the protocol design principles and operation. The normative specification is contained mainly in Section 4 to Section 8. Section 4 describes the message sequences and Section 5 their format and contents. Note that the detailed bit formats are given in Appendix A. The protocol operation is captured in the form of state machines in Section 6. Section 7 describes some more advanced protocol features, and security considerations are contained in Section 8. In addition, Appendix B describes an abstract API for the service that GIST provides to signalling applications, and Appendix D provides an example message flow. Parts of the GIST design use packets with IP options to probe the network, that leads to some migration issues in the case of IPv4, and these are discussed in Appendix C.
この仕様の構造は次のとおりです。セクション2では、用語を定義し、セクション3では、プロトコル設計の原則と操作の非公式の概要を示します。規範的仕様は、主にセクション4からセクション8に含まれています。セクション4では、メッセージシーケンスとセクション5の形式と内容について説明します。詳細なビット形式は付録Aに記載されていることに注意してください。プロトコル操作は、セクション6のステートマシンの形式でキャプチャされます。セクション7では、より高度なプロトコル機能について説明し、セキュリティの考慮事項についてはセクション8に含まれています。GISTがシグナリングアプリケーションに提供するサービスの抽象APIについて説明し、付録Dはメッセージフローの例を提供します。GIST設計の一部は、IPv4の場合にいくつかの移行の問題につながるIPオプションを備えたパケットをIPオプションで使用し、これらについては付録Cで説明します。
Because of the layered structure of the NSIS protocol suite, protocol extensions to cover a new signalling requirement could be carried out either within GIST, or within the signalling application layer, or both. General guidelines on how to extend different layers of the protocol suite, and in particular when and how it is appropriate to extend GIST, are contained in a separate document [12]. In this document, Section 9 gives the formal IANA considerations for the registries defined by the GIST specification.
NSISプロトコルスイートの層状構造のため、新しいシグナル伝達要件をカバーするプロトコル拡張は、GIST内、またはシグナリングアプリケーション層内、またはその両方で実行できます。プロトコルスイートのさまざまな層を拡張する方法、特にいつ、どのようにGISTを拡張することが適切であるかについての一般的なガイドラインは、別のドキュメントに含まれています[12]。このドキュメントでは、セクション9では、GIST仕様によって定義されたレジストリに関する正式なIANAの考慮事項を示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [3]に記載されているように解釈される。
The terminology used in this specification is defined in this section. The basic entities relevant at the GIST level are shown in Figure 1. In particular, this diagram distinguishes the different address types as being associated with a flow (end-to-end addresses) or signalling (addresses of adjacent signalling peers).
この仕様で使用される用語は、このセクションで定義されています。GISTレベルに関連する基本的なエンティティを図1に示します。特に、この図は、さまざまなアドレスタイプを、フロー（エンドツーエンドアドレス）またはシグナリング（隣接するシグナルピアのアドレス）に関連付けられていると区別します。
Source GIST (adjacent) peer nodes Destination
ソースGIST（隣接）ピアノードの宛先
IP address IP addresses = Signalling IP address
= Flow Source/Destination Addresses = Flow
Source (depending on signalling direction) Destination
Address | | Address
V V
+--------+ +------+ Data Flow +------+ +--------+
| Flow |-----------|------|-------------|------|-------->| Flow |
| Sender | | | | | |Receiver|
+--------+ | GIST |============>| GIST | +--------+
| Node |<============| Node |
+------+ Signalling +------+
GN1 Flow GN2
>>>>>>>>>>>>>>>>> = Downstream direction
<<<<<<<<<<<<<<<<< = Upstream direction
Figure 1: Basic Terminology
図1：基本的な用語
[Data] Flow: A set of packets identified by some fixed combination of header fields. Flows are unidirectional; a bidirectional communication is considered a pair of unidirectional flows.
[データ]フロー：ヘッダーフィールドの固定組み合わせによって識別されるパケットのセット。フローは一方向です。双方向通信は、一方的な一方的な流れと見なされます。
Session: A single application layer exchange of information for which some state information is to be manipulated or monitored. See Section 3.7 for further detailed discussion.
セッション：一部の州情報が操作または監視される情報の単一のアプリケーションレイヤー交換。詳細については、セクション3.7を参照してください。
Session Identifier (SID): An identifier for a session; the syntax is a 128-bit value that is opaque to GIST.
セッション識別子（SID）：セッションの識別子。構文は、GISTに不透明な128ビット値です。
[Flow] Sender: The node in the network that is the source of the packets in a flow. A sender could be a host, or a router if, for example, the flow is actually an aggregate.
[フロー]送信者：フロー内のパケットのソースであるネットワーク内のノード。送信者は、たとえばフローが実際に集計である場合、ホスト、またはルーターになる可能性があります。
[Flow] Receiver: The node in the network that is the sink for the packets in a flow.
[フロー]受信機：フロー内のパケットのシンクであるネットワーク内のノード。
Downstream: In the same direction as the data flow.
下流：データフローと同じ方向。
Upstream: In the opposite direction to the data flow.
上流：データフローとは反対の方向。
GIST Node: Any node supporting the GIST protocol, regardless of what signalling applications it supports.
GISTノード：サポートするシグナリングアプリケーションに関係なく、GISTプロトコルをサポートするノード。
[Adjacent] Peer: The next node along the signalling path, in the upstream or downstream direction, with which a GIST node explicitly interacts.
[隣接]ピア：上流または下流方向の信号パスに沿った次のノード。
Querying Node: The GIST node that initiates the handshake process to discover the adjacent peer.
ノードのクエリ：ハンドシェイクプロセスを開始して隣接するピアを発見するGISTノード。
Responding Node: The GIST node that responds to the handshake, becoming the adjacent peer to the Querying node.
応答ノード：握手に応答する要点ノードで、クエリノードの隣接するピアになります。
Datagram Mode (D-mode): A mode of sending GIST messages between nodes without using any transport layer state or security protection. Datagram mode uses UDP encapsulation, with source and destination IP addresses derived either from the flow definition or previously discovered adjacency information.
データグラムモード（Dモード）：トランスポートレイヤー状態またはセキュリティ保護を使用せずにノード間でGISTメッセージを送信するモード。Datagramモードは、フロー定義または以前に発見された隣接情報のいずれかから派生したソースおよび宛先IPアドレスを使用して、UDPカプセル化を使用します。
Connection Mode (C-mode): A mode of sending GIST messages directly between nodes using point-to-point messaging associations (see below). Connection mode allows the re-use of existing transport and security protocols where such functionality is required.
接続モード（Cモード）：ポイントツーポイントメッセージングアソシエーションを使用して、ノード間でGISTメッセージを直接送信するモード（以下を参照）。接続モードにより、そのような機能が必要な既存のトランスポートおよびセキュリティプロトコルの再利用が可能になります。
Messaging Association (MA): A single connection between two explicitly identified GIST adjacent peers, i.e., between a given signalling source and destination address. A messaging association may use a transport protocol; if security protection is required, it may use a network layer security association, or use a transport layer security association internally. A messaging association is bidirectional: signalling messages can be sent over it in either direction, referring to flows of either direction.
メッセージング協会（MA）：2つの明示的に識別されたGIST隣接ピア、つまり特定の信号ソースと宛先アドレスの間の単一の接続。メッセージング協会は、トランスポートプロトコルを使用する場合があります。セキュリティ保護が必要な場合は、ネットワークレイヤーセキュリティ協会を使用するか、輸送層セキュリティ協会を内部的に使用する場合があります。メッセージング関連は双方向です。どちらの方向のフローを参照して、どちらの方向にもシグナリングメッセージを送信できます。
[Message] Routing: Message routing describes the process of determining which is the next GIST peer along the signalling path. For signalling along a flow path, the message routing carried out by GIST is built on top of normal IP routing, that is, forwarding packets within the network layer based on their destination IP address. In this document, the term 'routing' generally refers to GIST message routing unless particularly specified.
[メッセージ]ルーティング：メッセージルーティングは、シグナリングパスに沿った次のGISTピアであるものを決定するプロセスを説明します。フローパスに沿って信号を送信するために、GISTによって実行されるメッセージルーティングは、通常のIPルーティングの上に構築されます。つまり、宛先IPアドレスに基づいてネットワークレイヤー内のパケットを転送します。このドキュメントでは、「ルーティング」という用語は、一般に、特に指定されていない限り、GISTメッセージルーティングを指します。
Message Routing Method (MRM): There can be different algorithms for discovering the route that signalling messages should take. These are referred to as message routing methods, and GIST supports alternatives within a common protocol framework. See Section 3.3.
メッセージルーティングメソッド（MRM）：シグナリングメッセージが表示されるルートを発見するためのさまざまなアルゴリズムがあります。これらはメッセージルーティング方法と呼ばれ、GISTは共通のプロトコルフレームワーク内で代替案をサポートします。セクション3.3を参照してください。
Message Routing Information (MRI): The set of data item values that is used to route a signalling message according to a particular MRM; for example, for routing along a flow path, the MRI includes flow source and destination addresses, and protocol and port numbers. See Section 3.3.
メッセージルーティング情報（MRI）：特定のMRMに従って信号メッセージをルーティングするために使用されるデータアイテム値のセット。たとえば、フローパスに沿ったルーティングの場合、MRIにはフローソースと宛先アドレス、プロトコルとポート番号が含まれます。セクション3.3を参照してください。
Router Alert Option (RAO): An option that can be included in IPv4 and v6 headers to assist in the packet interception process; see [13] and [17].
ルーターアラートオプション（RAO）：パケット傍受プロセスを支援するためにIPv4およびV6ヘッダーに含めることができるオプション。[13]および[17]を参照してください。
Transfer Attributes: A description of the requirements that a signalling application has for the delivery of a particular message; for example, whether the message should be delivered reliably. See Section 4.1.2.
転送属性：特定のメッセージの配信に信号アプリケーションが持っている要件の説明。たとえば、メッセージを確実に配信する必要があるかどうか。セクション4.1.2を参照してください。
The generic requirements identified in the NSIS framework [29] for transport of signalling messages are essentially two-fold:
信号メッセージの輸送のためにNSISフレームワーク[29]で特定された一般的な要件は、本質的に2つあります。
Routing: Determine how to reach the adjacent signalling node along each direction of the data path (the GIST peer), and if necessary explicitly establish addressing and identity information about that peer;
ルーティング：データパス（GISTピア）の各方向に沿って隣接する信号ノードに到達する方法を決定し、必要に応じてそのピアに関するアドレス指定とID情報を明示的に確立します。
Transport: Deliver the signalling information to that peer.
トランスポート：シグナリング情報をそのピアに配信します。
To meet the routing requirement, one possibility is for the node to use local routing state information to determine the identity of the GIST peer explicitly. GIST defines a three-way handshake that probes the network to set up the necessary routing state between adjacent peers, during which signalling applications can also exchange data. Once the routing decision has been made, the node has to select a mechanism for transport of the message to the peer. GIST divides the transport functionality into two parts, a minimal capability provided by GIST itself, with the use of well-understood transport protocols for the harder cases. Here, with details discussed later, the minimal capability is restricted to messages that are sized well below the lowest maximum transmission unit (MTU) along a path, are infrequent enough not to cause concerns about congestion and flow control, and do not need security protection or guaranteed delivery.
ルーティングの要件を満たすために、1つの可能性は、ノードがローカルルーティング状態情報を使用して、GISTピアのIDを明示的に決定することです。GISTは、ネットワークを調査して隣接するピア間で必要なルーティング状態を設定する3方向の握手を定義します。その間、シグナリングアプリケーションもデータを交換できます。ルーティングの決定が行われたら、ノードはピアにメッセージを輸送するメカニズムを選択する必要があります。GISTは、輸送機能を2つの部分に分割します。これは、GIST自体によって提供される最小限の機能であり、難しい場合によく理解された輸送プロトコルを使用します。ここで、詳細が後で説明すると、最小限の機能は、パスに沿った最低透過装置（MTU）を大きく下回るサイズのメッセージに制限されており、輻輳やフロー制御について懸念を引き起こさないほど十分に頻繁にあり、セキュリティ保護は必要ありません。または保証された配達。
In [29], all of these routing and transport requirements are assigned to a single notional protocol, the NSIS Transport Layer Protocol (NTLP). The strategy of splitting the transport problem leads to a layered structure for the NTLP, with a specialised GIST messaging layer running over standard transport and security protocols. The basic concept is shown in Figure 2. Note that not every combination of transport and security protocols implied by the figure is actually possible for use in GIST; the actual combinations allowed by this specification are defined in Section 5.7. The figure also shows GIST offering its services to upper layers at an abstract interface, the GIST API, further discussed in Section 4.1.
[29]では、これらのルーティングおよび輸送要件はすべて、単一の概念的なプロトコルであるNSIS輸送層プロトコル（NTLP）に割り当てられています。輸送の問題を分割する戦略は、標準の輸送プロトコルとセキュリティプロトコルを介して実行されている特殊なGISTメッセージングレイヤーを使用して、NTLPの層状構造につながります。基本概念を図2に示します。図によって暗示される輸送プロトコルとセキュリティプロトコルのすべての組み合わせが実際にGISTで使用できるわけではないことに注意してください。この仕様で許可される実際の組み合わせは、セクション5.7で定義されています。図は、抽象インターフェイスであるGIST APIで上層層にサービスを提供するGISTも示しています。これは、セクション4.1でさらに説明します。
^^ +-------------+
|| | Signalling |
NSIS +------------|Application 2|
Signalling | Signalling +-------------+
Application |Application 1| |
Level +-------------+ |
|| | |
VV | |
========|===================|===== <-- GIST API
| |
^^ +------------------------------------------------+
|| |+-----------------------+ +--------------+ |
|| || GIST | | GIST State | |
|| || Encapsulation |<<<>>>| Maintenance | |
|| |+-----------------------+ +--------------+ |
|| | GIST: Messaging Layer |
|| +------------------------------------------------+
NSIS | | | |
Transport ..........................................
Level . Transport Layer Security (TLS or DTLS) .
(NTLP) ..........................................
|| | | | |
|| +----+ +----+ +----+ +----+
|| |UDP | |TCP | |SCTP| |DCCP| ... other
|| +----+ +----+ +----+ +----+ protocols
|| | | | |
|| .............................
|| . IP Layer Security .
|| .............................
VV | | | |
===========================|=======|=======|=======|============
| | | |
+----------------------------------------------+
| IP |
+----------------------------------------------+
Figure 2: Protocol Stack Architecture for Signalling Transport
図2：シグナリング輸送用のプロトコルスタックアーキテクチャ
Internally, GIST has two modes of operation:
内部的には、GISTには2つの動作モードがあります。
Datagram mode (D-mode): used for small, infrequent messages with modest delay constraints and no security requirements. A special case of D-mode called Query-mode (Q-mode) is used when no routing state exists.
Datagramモード（Dモード）：控えめな遅延制約とセキュリティ要件がない、小規模でまれなメッセージに使用されます。ルーティング状態が存在しない場合、Query-Mode（Q-Mode）と呼ばれるDモードの特殊なケースが使用されます。
Connection mode (C-mode): used for all other signalling traffic. In particular, it can support large messages and channel security and provides congestion control for signalling traffic.
接続モード（Cモード）：他のすべての信号トラフィックに使用されます。特に、大規模なメッセージとチャネルセキュリティをサポートし、信号トラフィックの混雑制御を提供します。
C-mode can in principle use any stream or message-oriented transport protocol; this specification defines TCP as the initial choice. It can in principle employ specific network layer security associations, or an internal transport layer security association; this specification defines TLS as the initial choice. When GIST messages are carried in C-mode, they are treated just like any other traffic by intermediate routers between the GIST peers. Indeed, it would be impossible for intermediate routers to carry out any processing on the messages without terminating the transport and security protocols used.
Cモードは、原則として、ストリームまたはメッセージ指向のトランスポートプロトコルを使用できます。この仕様では、TCPが初期選択として定義されています。原則として、特定のネットワークレイヤーセキュリティ協会、または内部輸送層セキュリティ協会を採用できます。この仕様では、TLSが初期選択として定義されています。GISTメッセージがCモードで運ばれると、GISTピア間の中間ルーターによって他のトラフィックと同じように扱われます。実際、中間ルーターは、使用されるトランスポートおよびセキュリティプロトコルを終了することなく、メッセージの処理を実行することは不可能です。
D-mode uses UDP, as a suitable NAT-friendly encapsulation that does not require per-message shared state to be maintained between the peers. Long-term evolution of GIST is assumed to preserve the simplicity of the current D-mode design. Any extension to the security or transport capabilities of D-mode can be viewed as the selection of a different protocol stack under the GIST messaging layer; this is then equivalent to defining another option within the overall C-mode framework. This includes both the case of using existing protocols and the specific development of a message exchange and payload encapsulation to support GIST requirements. Alternatively, if any necessary parameters (e.g., a shared secret for use in integrity or confidentiality protection) can be negotiated out-of-band, then the additional functions can be added directly to D-mode by adding an optional object to the message (see Appendix A.2.1). Note that in such an approach, downgrade attacks as discussed in Section 8.6 would need to be prevented by policy at the destination node.
D-Modeは、ピア間で維持されるためにメッセージごとの共有状態を必要としない適切なNATフレンドリーなカプセル化としてUDPを使用します。GISTの長期的な進化は、現在のDモード設計のシンプルさを維持するために想定されています。Dモードのセキュリティまたは輸送機能の拡張は、GISTメッセージングレイヤーの下で異なるプロトコルスタックの選択と見なすことができます。これは、全体的なCモードフレームワーク内で別のオプションを定義することと同等です。これには、既存のプロトコルを使用した場合とメッセージ交換の特定の開発と、GIST要件をサポートするペイロードカプセル化の両方が含まれます。あるいは、必要なパラメーター（例：整合性または機密性保護に使用するための共有秘密）を帯域外でネゴシエートできる場合、メッセージにオプションのオブジェクトを追加することで追加の機能をDモードに直接追加できます（付録A.2.1を参照してください。このようなアプローチでは、セクション8.6で説明したように、宛先ノードでのポリシーによって防止される必要があることに注意してください。
It is possible to mix these two modes along a path. This allows, for example, the use of D-mode at the edges of the network and C-mode towards the core. Such combinations may make operation more efficient for mobile endpoints, while allowing shared security associations and transport connections to be used for messages for multiple flows and signalling applications. The setup for these protocols imposes an initialisation cost for the use of C-mode, but in the long term this cost can be shared over all signalling sessions between peers; once the transport layer state exists, retransmission algorithms can operate much more aggressively than would be possible in a pure D-mode design.
パスに沿ってこれら2つのモードを混ぜることができます。これにより、たとえば、ネットワークのエッジでDモードを使用し、コアに向かってCモードを使用できます。このような組み合わせにより、モバイルエンドポイントの動作がより効率的になる可能性があり、共有されたセキュリティ関連と輸送接続を複数のフローとシグナリングアプリケーションのメッセージに使用できるようにします。これらのプロトコルのセットアップは、Cモードを使用するための初期化コストを課しますが、長期的には、ピア間のすべてのシグナリングセッションでこのコストを共有できます。輸送層の状態が存在すると、再送信アルゴリズムは、純粋なDモード設計で可能になるよりもはるかに積極的に動作できます。
It must be understood that the routing and transport functions within GIST are not independent. If the message transfer has requirements that require C-mode, for example, if the message is so large that fragmentation is required, this can only be used between explicitly identified nodes. In such cases, GIST carries out the three-way handshake initially in D-mode to identify the peer and then sets up the necessary connections if they do not already exist. It must also be understood that the signalling application does not make the D-mode/C-mode selection directly; rather, this decision is made by GIST on the basis of the message characteristics and the transfer attributes stated by the application. The distinction is not visible at the GIST service interface.
GIST内のルーティングおよび輸送機能は独立していないことを理解する必要があります。たとえば、メッセージ転送にCモードが必要な要件がある場合、メッセージが非常に大きいため、フラグメンテーションが必要な場合、これは明示的に識別されたノード間でのみ使用できます。そのような場合、GISTは最初にDモードで3方向の握手を実行してピアを識別し、まだ存在しない場合は必要な接続をセットアップします。また、シグナリングアプリケーションがDモード/Cモードの選択を直接作成しないことも理解する必要があります。むしろ、この決定は、メッセージの特性とアプリケーションで記載されている転送属性に基づいてGISTによって行われます。GISTサービスインターフェイスでは、区別は表示されません。
In general, the state associated with C-mode messaging to a particular peer (signalling destination address, protocol and port numbers, internal protocol configuration, and state information) is referred to as a messaging association (MA). MAs are totally internal to GIST (they are not visible to signalling applications). Although GIST may be using an MA to deliver messages about a particular flow, there is no direct correspondence between them: the GIST message routing algorithms consider each message in turn and select an appropriate MA to transport it. There may be any number of MAs between two GIST peers although the usual case is zero or one, and they are set up and torn down by management actions within GIST itself.
一般に、特定のピアへのCモードメッセージングに関連する状態（シグナリング宛先アドレス、プロトコル番号とポート番号、内部プロトコル構成、および状態情報）は、メッセージング協会（MA）と呼ばれます。MASは完全にGISTの内部です（シグナリングアプリケーションには見えません）。GISTはMAを使用して特定のフローに関するメッセージを配信している可能性がありますが、それらの間に直接的な対応はありません。GISTメッセージルーティングアルゴリズムは、各メッセージを順番に検討し、適切なMAを選択して輸送します。通常のケースはゼロまたは1つであるが、2つの要素の間には任意の数のMASがある場合があり、GIST自体内の管理アクションによってセットアップされ、取り壊されます。
The baseline message routing functionality in GIST is that signalling messages follow a route defined by an existing flow in the network, visiting a subset of the nodes through which it passes. This is the appropriate behaviour for application scenarios where the purpose of the signalling is to manipulate resources for that flow. However, there are scenarios for which other behaviours are applicable. Two examples are:
GISTのベースラインメッセージルーティング機能は、シグナリングメッセージがネットワーク内の既存のフローによって定義されたルートに従い、通過するノードのサブセットにアクセスすることです。これは、シグナリングの目的がそのフローのリソースを操作することであるアプリケーションシナリオの適切な動作です。ただし、他の動作が適用されるシナリオがあります。2つの例は次のとおりです。
Predictive Routing: Here, the intent is to signal along a path that the data flow may follow in the future. Possible cases are pre-installation of state on the backup path that would be used in the event of a link failure, and predictive installation of state on the path that will be used after a mobile node handover.
予測ルーティング：ここで、意図は、将来データフローが続く可能性のあるパスに沿って通知することです。考えられるケースは、リンク障害が発生した場合に使用されるバックアップパス上の状態の事前インストールと、モバイルノードのハンドオーバー後に使用されるパス上の状態の予測設置です。
NAT Address Reservations: This applies to the case where a node behind a NAT wishes to reserve an address at which it can be reached by a sender on the other side. This requires a message to be sent outbound from what will be the flow receiver although no reverse routing state for the flow yet exists.
NATアドレス予約：これは、NATの背後にあるノードが、反対側の送信者が到達できる住所を予約したい場合に適用されます。これには、フローのリバースルーティング状態はありませんが、フローレシーバーとはどうなるかから送信されるメッセージを送信する必要があります。
Most of the details of GIST operation are independent of the routing behaviour being used. Therefore, the GIST design encapsulates the routing-dependent details as a message routing method (MRM), and allows multiple MRMs to be defined. This specification defines the path-coupled MRM, corresponding to the baseline functionality described above, and a second ("Loose-End") MRM for the NAT Address Reservation case. The detailed specifications are given in Section 5.8.
GIST操作の詳細のほとんどは、使用されているルーティング動作とは無関係です。したがって、GISTデザインは、ルーティング依存の詳細をメッセージルーティングメソッド（MRM）としてカプセル化し、複数のMRMを定義できるようにします。この仕様は、上記のベースライン機能に対応するパス結合されたMRMと、NATアドレス予約ケースの2番目の（「ルーズエンド」）MRMを定義します。詳細な仕様は、セクション5.8に記載されています。
The content of an MRM definition is as follows, using the path-coupled MRM as an example:
MRM定義の内容は、パス結合されたMRMを例として使用して、次のとおりです。
o The format of the information that describes the path that the signalling should take, the Message Routing Information (MRI). For the path-coupled MRM, this is just the flow identifier (see Section 5.8.1.1) and some additional control information. Specifically, the MRI always includes a flag to distinguish between the two directions that signalling messages can take, denoted 'upstream' and 'downstream'.
o シグナリングが行うべきパス、メッセージルーティング情報（MRI）を説明する情報の形式。パス結合されたMRMの場合、これは単なるフロー識別子（セクション5.8.1.1を参照）といくつかの追加の制御情報です。具体的には、MRIには常に、「上流」と「下流」と表示され、シグナリングメッセージが実行できる2つの方向を区別するフラグが常に含まれています。
o A specification of the IP-level encapsulation of the messages which probe the network to discover the adjacent peers. A downstream encapsulation must be defined; an upstream encapsulation is optional. For the path-coupled MRM, this information is given in Section 5.8.1.2 and Section 5.8.1.3. Current MRMs rely on the interception of probe messages in the data plane, but other mechanisms are also possible within the overall GIST design and would be appropriate for other types of signalling pattern.
o ネットワークをプローブして隣接するピアを発見するメッセージのIPレベルのカプセル化の仕様。下流のカプセル化を定義する必要があります。上流のカプセル化はオプションです。パス結合されたMRMの場合、この情報はセクション5.8.1.2およびセクション5.8.1.3に記載されています。現在のMRMSは、データプレーン内のプローブメッセージの傍受に依存していますが、他のメカニズムは全体的なGIST設計内でも可能であり、他のタイプのシグナル伝達パターンに適しています。
o A specification of what validation checks GIST should apply to the probe messages, for example, to protect against IP address spoofing attacks. The checks may be dependent on the direction (upstream or downstream) of the message. For the path-coupled MRM, the downstream validity check is basically a form of ingress filtering, also discussed in Section 5.8.1.2.
o 検証チェックGISTの仕様は、たとえば、IPアドレスのスプーフィング攻撃から保護するために、プローブメッセージに適用する必要があります。チェックは、メッセージの方向（上流または下流）に依存する場合があります。パス結合されたMRMの場合、下流の妥当性チェックは基本的に、セクション5.8.1.2で説明されているイングレスフィルタリングの形式です。
o The mechanism(s) available for route change detection, i.e., any change in the neighbour relationships that the MRM discovers. The default case for any MRM is soft-state refresh, but additional supporting techniques may be possible; see Section 7.1.2.
o ルート変更検出に利用できるメカニズム、つまりMRMが発見した隣接関係の変化。MRMのデフォルトのケースはソフトステートリフレッシュですが、追加のサポートテクニックが可能になる場合があります。セクション7.1.2を参照してください。
In addition, it should be noted that NAT traversal may require translation of fields in the MRI object carried in GIST messages (see Section 7.2.2). The generic MRI format includes a flag that must be given as part of the MRM definition, to indicate if some kind of translation is necessary. Development of a new MRM therefore includes updates to the GIST specification, and may include updates to specifications of NAT behaviour. These updates may be done in separate documents as is the case for NAT traversal for the MRMs of the base GIST specification, as described in Section 7.2.3 and [44].
さらに、NATトラバーサルには、GISTメッセージに含まれるMRIオブジェクトのフィールドの翻訳が必要になる場合があることに注意してください（セクション7.2.2を参照）。一般的なMRI形式には、何らかの翻訳が必要かどうかを示すために、MRM定義の一部として指定する必要があるフラグが含まれています。したがって、新しいMRMの開発には、GIST仕様の更新が含まれており、NATの動作の仕様の更新が含まれる場合があります。これらの更新は、セクション7.2.3および[44]で説明されているように、ベースGIST仕様のMRMSのNATトラバーサルの場合と同様に、個別のドキュメントで行うことができます。
The MRI is passed explicitly between signalling applications and GIST; therefore, signalling application specifications must define which MRMs they require. Signalling applications may use fields in the MRI in their packet classifiers; if they use additional information for packet classification, this would be carried at the NSLP level and so would be invisible to GIST. Any node hosting a particular signalling application needs to use a GIST implementation that supports the corresponding MRMs. The GIST processing rules allow nodes not hosting the signalling application to ignore messages for it at the GIST level, so it does not matter if these nodes support the MRM or not.
MRIは、シグナリングアプリケーションとGISTの間に明示的に渡されます。したがって、シグナリングアプリケーションの仕様は、必要なMRMSを定義する必要があります。シグナリングアプリケーションは、パケット分類器のMRIのフィールドを使用する場合があります。パケット分類に追加情報を使用する場合、これはNSLPレベルで運ばれるため、GISTには見えません。特定のシグナリングアプリケーションをホストするノードは、対応するMRMをサポートするGIST実装を使用する必要があります。GIST処理ルールにより、ノードはシグナリングアプリケーションをホストしないようにGISTレベルでメッセージを無視しないため、これらのノードがMRMをサポートするかどうかは関係ありません。
GIST has six message types: Query, Response, Confirm, Data, Error, and MA-Hello. Apart from the invocation of the messaging association protocols used by C-mode, all GIST communication consists of these messages. In addition, all signalling application data is carried as additional payloads in these messages, alongside the GIST information.
GISTには、クエリ、応答、確認、データ、エラー、およびMA-Helloの6つのメッセージタイプがあります。Cモードで使用されるメッセージングアソシエーションプロトコルの呼び出しとは別に、すべてのGIST通信はこれらのメッセージで構成されています。さらに、すべてのシグナリングアプリケーションデータは、GIST情報とともに、これらのメッセージに追加のペイロードとして運ばれます。
The Query, Response, and Confirm messages implement the handshake that GIST uses to set up routing state and messaging associations. The handshake is initiated from the Querying node towards the Responding node. The first message is the Query, which is encapsulated in a specific way depending on the message routing method, in order to probe the network infrastructure so that the correct peer will intercept it and become the Responding node. A Query always triggers a Response in the reverse direction as the second message of the handshake. The content of the Response controls whether a Confirm message is sent: as part of the defence against denial-of-service attacks, the Responding node can delay state installation until a return routability check has been performed, and require the Querying node to complete the handshake with the Confirm message. In addition, if the handshake is being used to set up a new MA, the Response is required to request a Confirm. All of these three messages can optionally carry signalling application data. The handshake is fully described in Section 4.4.1.
クエリ、応答、および確認メッセージは、GISTが使用してルーティング状態およびメッセージングアソシエーションをセットアップするために使用するハンドシェイクを実装します。握手は、クエリノードから応答ノードに向かって開始されます。最初のメッセージはクエリです。これは、メッセージルーティング方法に応じて特定の方法でカプセル化され、ネットワークインフラストラクチャをプローブして、正しいピアがそれを傍受して応答するノードになります。クエリは、常に握手の2番目のメッセージとして逆方向に応答をトリガーします。応答のコンテンツは、確認メッセージが送信されるかどうかを制御します。サービス拒否攻撃に対する防御の一部として、応答ノードは返品ルー上のチェックが実行されるまで状態のインストールを遅らせ、クエリノードにクエリノードが完了する必要があります。確認メッセージでの握手。さらに、新しいMAを設定するために握手を使用している場合、確認を要求するために応答が必要です。これらの3つのメッセージはすべて、オプションでシグナリングアプリケーションデータを運ぶことができます。握手については、セクション4.4.1で完全に説明されています。
The Data message is used purely to encapsulate and deliver signalling application data. Usually, it is sent using pre-established routing state. However, if there are no security or transport requirements and no need for persistent reverse routing state, it can also be sent in the same way as the Query. Finally, Error messages are used to indicate error conditions at the GIST level, and the MA-Hello message can be used as a diagnostic and keepalive for the messaging association protocols.
データメッセージは、シグナリングアプリケーションデータをカプセル化および配信するために純粋に使用されます。通常、事前に確立されたルーティング状態を使用して送信されます。ただし、セキュリティまたは輸送の要件がなく、永続的な逆ルーティング状態の必要がない場合は、クエリと同じ方法で送信することもできます。最後に、エラーメッセージを使用して、GISTレベルでエラー条件を示すために使用され、MA-Helloメッセージは、メッセージングアソシエーションプロトコルの診断とKeepaliveとして使用できます。
Peering is the process whereby two GIST nodes create message routing states that point to each other.
ピアリングとは、2つのGISTノードが互いを指すメッセージルーティング状態を作成するプロセスです。
A peering relationship can only be created by a GIST handshake. Nodes become peers when one issues a Query and gets a Response from another. Issuing the initial Query is a result of an NSLP request on that node, and the Query itself is formatted according to the rules of the message routing method. For current MRMs, the identity of the Responding node is not known explicitly at the time the Query is sent; instead, the message is examined by nodes along the path until one decides to send a Response, thereby becoming the peer. If the node hosts the NSLP, local GIST and signalling application policy determine whether to peer; the details are given in Section 4.3.2. Nodes not hosting the NSLP forward the Query transparently (Section 4.3.4). Note that the design of the Query message (see Section 5.3.2) is such that nodes have to opt-in specifically to carry out the message interception -- GIST-unaware nodes see the Query as a normal data packet and so forward it transparently.
ピアリング関係は、要点の握手によってのみ作成できます。クエリを発行し、別のノードがクエリを発行すると、ノードがピアになります。初期クエリを発行することは、そのノードのNSLP要求の結果であり、クエリ自体はメッセージルーティング方法のルールに従ってフォーマットされます。現在のMRMSの場合、クエリが送信された時点で応答ノードのIDは明示的に知られていません。代わりに、メッセージは、応答を送信することを決定し、それによってピアになるまで、パスに沿ったノードによって調べられます。ノードがNSLPをホストしている場合、ローカルGISTおよびシグナリングアプリケーションポリシーは、ピアするかどうかを決定します。詳細については、セクション4.3.2に記載されています。NSLPをホストしていないノードは、クエリを透過的に転送します（セクション4.3.4）。クエリメッセージの設計（セクション5.3.2を参照）は、ノードがメッセージ傍受を実行するために特にオプトインする必要があることに注意してください。GIST-UNAWAREノードは、クエリを通常のデータパケットとして表示し、透過的に転送することに注意してください。。
An existing peering relationship can only be changed by a new GIST handshake; in other words, it can only change when routing state is refreshed. On a refresh, if any of the factors in the original peering process have changed, the peering relationship can also change. As well as network-level rerouting, changes could include modifications to NSIS signalling functions deployed at a node, or alterations to signalling application policy. A change could cause an existing node to drop out of the signalling path, or a new node to become part of it. All these possibilities are handled as rerouting events by GIST; further details of the process are described in Section 7.1.
既存のピアリング関係は、新しい要点の握手によってのみ変更できます。言い換えれば、ルーティング状態が更新された場合にのみ変更できます。リフレッシュすると、元のピアリングプロセスの要因のいずれかが変化した場合、ピアリングの関係も変化する可能性があります。ネットワークレベルの再ルーティングだけでなく、変更には、ノードに展開されたNSISシグナリング関数の変更、またはシグナリングアプリケーションポリシーの変更が含まれる場合があります。変更により、既存のノードが信号パスからドロップアウトされるか、新しいノードがその一部になる可能性があります。これらの可能性はすべて、GISTによる再ルーティングイベントとして処理されます。プロセスの詳細については、セクション7.1で説明します。
GIST relies on routers inside the network to intercept and process packets that would normally be transmitted end-to-end. This processing may be non-transparent: messages may be forwarded with modifications, or not forwarded at all. This interception applies only to the encapsulation used for the Query messages that probe the network, for example, along a flow path; all other GIST messages are handled only by the nodes to which they are directly addressed, i.e., as normal Internet traffic.
GISTは、ネットワーク内のルーターに依存して、通常エンドツーエンドで送信されるパケットを傍受および処理します。この処理は透明ではない場合があります。メッセージは変更で転送されるか、まったく転送されない場合があります。この傍受は、たとえば、フローパスに沿ってネットワークをプローブするクエリメッセージに使用されるカプセル化にのみ適用されます。他のすべてのGISTメッセージは、直接対処されるノード、つまり通常のインターネットトラフィックとしてのみ処理されます。
Because this interception potentially breaks Internet transparency for packets that have nothing to do with GIST, the encapsulation used by GIST in this case (called Query-mode or Q-mode) has several features to avoid accidental collisions with other traffic:
この傍受は、GISTとは関係のないパケットのインターネット透明性を破壊する可能性があるため、この場合にGISTで使用されるカプセル化（クエリモードまたはQモードと呼ばれる）には、他のトラフィックとの偶発的な衝突を避けるためのいくつかの機能があります。
o Q-mode messages are always sent as UDP traffic, and to a specific well-known port (270) allocated by IANA.
o Qモードメッセージは、常にUDPトラフィックとして送信され、IANAによって割り当てられた特定の有名なポート（270）に送信されます。
o All GIST messages sent as UDP have a magic number as the first 32- bit word of the datagram payload.
o UDPとして送信されるすべてのGISTメッセージには、データグラムペイロードの最初の32ビットワードとしてマジック番号があります。
Even if a node intercepts a packet as potentially a GIST message, unless it passes both these checks it will be ignored at the GIST level and forwarded transparently. Further discussion of the reception process is in Section 4.3.1 and the encapsulation in Section 5.3.
ノードがパケットを潜在的にGISTメッセージとしてインターセプトしたとしても、これらの両方のチェックに合格しない限り、GISTレベルで無視され、透過的に転送されます。受信プロセスのさらなる議論は、セクション4.3.1とセクション5.3のカプセル化にあります。
GIST requires signalling applications to associate each of their messages with a signalling session. Informally, given an application layer exchange of information for which some network control state information is to be manipulated or monitored, the corresponding signalling messages should be associated with the same session. Signalling applications provide the session identifier (SID) whenever they wish to send a message, and GIST reports the SID when a message is received; on messages forwarded at the GIST level, the SID is preserved unchanged. Usually, NSLPs will preserve the SID value along the entire signalling path, but this is not enforced by or even visible to GIST, which only sees the scope of the SID as the single hop between adjacent NSLP peers.
GISTでは、各メッセージをシグナリングセッションに関連付けるために、シグナリングアプリケーションが必要です。非公式には、一部のネットワーク制御状態情報を操作または監視するためのアプリケーションレイヤー情報交換を考えると、対応するシグナリングメッセージは同じセッションに関連付けられる必要があります。シグナリングアプリケーションは、メッセージを送信したいときはいつでもセッション識別子（SID）を提供し、GISTはメッセージを受信したときにSIDを報告します。GISTレベルで転送されたメッセージでは、SIDは変更されていません。通常、NSLPはシグナリングパス全体に沿ってSID値を保持しますが、これはGISTによって強制されたり、表示されたりすることはありません。これは、SIDの範囲が隣接するNSLPピア間の単一ホップとしてのみ見られます。
Most GIST processing and state information is related to the flow (defined by the MRI; see above) and signalling application (given by the NSLP identifier, see below). There are several possible relationships between flows and sessions, for example:
ほとんどのGIST処理と状態情報は、フロー（MRIで定義され、上記を参照）とシグナリングアプリケーション（NSLP識別子によって与えられた、以下を参照）に関連しています。たとえば、フローとセッションの間にはいくつかの関係があります。
o The simplest case is that all signalling messages for the same flow have the same SID.
o 最も単純なケースは、同じフローのすべてのシグナリングメッセージが同じSIDを持っていることです。
o Messages for more than one flow may use the same SID, for example, because one flow is replacing another in a mobility or multihoming scenario.
o たとえば、1つのフローがモビリティまたはマルチホームシナリオで別のフローを置き換えているため、複数のフローのメッセージが同じSIDを使用する場合があります。
o A single flow may have messages for different SIDs, for example, from independently operating signalling applications.
o 単一のフローには、たとえば独立して動作するシグナリングアプリケーションなど、さまざまなSIDのメッセージがあります。
Because of this range of options, GIST does not perform any validation on how signalling applications map between flows and sessions, nor does it perform any direct validation on the properties of the SID itself, such as any enforcement of uniqueness. GIST only defines the syntax of the SID as an opaque 128-bit identifier.
このさまざまなオプションのため、GISTは、シグナリングアプリケーションがフローとセッションの間のマッピング方法について検証を実行せず、一意性の施行など、SID自体のプロパティを直接検証する方法も実行しません。GISTは、SIDの構文を不透明な128ビット識別子として定義します。
The SID assignment has the following impact on GIST processing:
SIDの割り当てには、GIST処理に次の影響があります。
o Messages with the same SID that are to be delivered reliably between the same GIST peers are delivered in order.
o 同じGISTピア間で確実に配信される同じSIDを持つメッセージが順番に配信されます。
o All other messages are handled independently.
o 他のすべてのメッセージは独立して処理されます。
o GIST identifies routing state (upstream and downstream peer) by the MRI/SID/NSLPID combination.
o GISTは、MRI/SID/NSLPIDの組み合わせにより、ルーティング状態（上流および下流のピア）を識別します。
Strictly speaking, the routing state should not depend on the SID. However, if the routing state is keyed only by (MRI, NSLP), there is a trivial denial-of-service attack (see Section 8.3) where a malicious off-path node asserts that it is the peer for a particular flow. Such an attack would not redirect the traffic but would reroute the signalling. Instead, the routing state is also segregated between different SIDs, which means that the attacking node can only disrupt a signalling session if it can guess the corresponding SID. Normative rules on the selection of SIDs are given in Section 4.1.3.
厳密に言えば、ルーティング状態はSIDに依存すべきではありません。ただし、ルーティング状態が（MRI、NSLP）によってのみキー化されている場合、悪意のあるオフパスノードが特定のフローのピアであると主張する些細なサービス拒否攻撃（セクション8.3を参照）があります（セクション8.3を参照）。このような攻撃はトラフィックをリダイレクトしませんが、シグナリングを再ルーティングします。代わりに、ルーティング状態は異なるSID間で分離されます。つまり、攻撃ノードは、対応するSIDを推測できる場合にのみシグナリングセッションを破壊できます。SIDの選択に関する規範的規則は、セクション4.1.3に記載されています。
The functionality for signalling applications is supported by NSIS Signalling Layer Protocols (NSLPs). Each NSLP is identified by a 16-bit NSLP identifier (NSLPID), assigned by IANA (Section 9). A single signalling application, such as resource reservation, may define a family of NSLPs to implement its functionality, for example, to carry out signalling operations at different levels in a hierarchy (cf. [21]). However, the interactions between the different NSLPs (for example, to relate aggregation levels or aggregation region boundaries in the resource management case) are handled at the signalling application level; the NSLPID is the only information visible to GIST about the signalling application being used.
シグナリングアプリケーションの機能は、NSISシグナリング層プロトコル（NSLP）によってサポートされています。各NSLPは、IANA（セクション9）によって割り当てられた16ビットNSLP識別子（NSLPID）によって識別されます。リソース予約などの単一のシグナリングアプリケーションは、NSLPのファミリーを定義して、たとえば、階層の異なるレベルでシグナリング操作を実行する機能を実装することができます（[21]を参照）。ただし、異なるNSLP間の相互作用（たとえば、リソース管理ケースの集約レベルまたは集約領域の境界を関連付けるため）は、シグナリングアプリケーションレベルで処理されます。NSLPIDは、使用されているシグナリングアプリケーションについてGISTに表示される唯一の情報です。
GIST has two distinct security goals:
GISTには2つの異なるセキュリティ目標があります。
o to protect GIST state from corruption, and to protect the nodes on which it runs from resource exhaustion attacks; and
o GIST状態を腐敗から保護し、リソースの疲労攻撃から実行されるノードを保護するため。と
o to provide secure transport for NSLP messages to the signalling applications.
o 信号アプリケーションにNSLPメッセージの安全なトランスポートを提供します。
The protocol mechanisms to achieve the first goal are mainly internal to GIST. They include a cookie exchange and return routability check to protect the handshake that sets up routing state, and a random SID is also used to prevent off-path session hijacking by SID guessing. Further details are given in Section 4.1.3 and Section 4.4.1, and the overall security aspects are discussed in Section 8.
最初の目標を達成するためのプロトコルメカニズムは、主にGISTの内部です。それらには、ルーティング状態を設定するハンドシェイクを保護するためのCookie ExchangeおよびReturn Rusability Checkが含まれます。また、SIDの推測によるオフパスセッションのハイジャックを防ぐためにランダムSIDも使用されます。詳細については、セクション4.1.3およびセクション4.4.1に記載されており、全体的なセキュリティの側面についてはセクション8で説明します。
A second level of protection is provided by the use of a channel security protocol in messaging associations (i.e., within C-mode). This mechanism serves two purposes: to protect against on-path attacks on GIST and to provide a secure channel for NSLP messages. For the mechanism to be effective, it must be able to provide the following functions:
2番目のレベルの保護は、メッセージングアソシエーション（つまり、Cモード内）でチャネルセキュリティプロトコルを使用することにより提供されます。このメカニズムは、GISTに対するパス上の攻撃から保護し、NSLPメッセージに安全なチャネルを提供するという2つの目的を果たします。メカニズムが効果的であるためには、次の機能を提供できる必要があります。
o mutual authentication of the GIST peer nodes;
o GISTピアノードの相互認証。
o ability to verify the authenticated identity against a database of nodes authorised to take part in GIST signalling;
o GISTシグナル伝達に参加することを許可されたノードのデータベースに対して認証されたIDを確認する能力。
o confidentiality and integrity protection for NSLP data, and provision of the authenticated identities used to the signalling application.
o NSLPデータの機密性と整合性保護、およびシグナリングアプリケーションに使用される認証されたアイデンティティの提供。
The authorised peer database is described in more detail in Section 4.4.2, including the types of entries that it can contain and the authorisation checking algorithm that is used. The only channel security protocol defined by this specification is a basic use of TLS, and Section 5.7.3 defines the TLS-specific aspects of how these functions (for example, authentication and identity comparison) are integrated with the rest of GIST operation. At a high level, there are several alternative protocols with similar functionality, and the handshake (Section 4.4.1) provides a mechanism within GIST to select between them. However, they differ in their identity schemes and authentication methods and dependencies on infrastructure support for the authentication process, and any GIST extension to incorporate them would need to define the details of the corresponding interactions with GIST operation.
承認されたピアデータベースについては、セクション4.4.2で詳細に説明します。これには、含めることができるエントリの種類や、使用される認証チェックアルゴリズムが含まれます。この仕様で定義される唯一のチャネルセキュリティプロトコルは、TLSの基本的な使用であり、セクション5.7.3は、これらの機能（たとえば、認証とアイデンティティの比較）のTLS固有の側面を、GIST操作の残りの部分と統合する方法を定義しています。高レベルでは、同様の機能を備えたいくつかの代替プロトコルがあり、握手（セクション4.4.1）は、それらを選択するためのGIST内のメカニズムを提供します。ただし、それらは、認証プロセスのインフラストラクチャサポートのアイデンティティスキームと認証方法と依存関係が異なり、それらを組み込むためのGIST拡張は、GIST操作との対応する相互作用の詳細を定義する必要があります。
This section presents an example of GIST usage in a relatively simple (in particular, NAT-free) signalling scenario, to illustrate its main features.
このセクションでは、その主な機能を説明するために、比較的単純な（特に、NATフリー）シグナル伝達シナリオでの要点使用の例を示します。
GN1 GN2
+------------+ +------------+
NSLP | | | |
Level | >>>>>>>>>1 | | 5>>>>>>>>5 |
| ^ V | Intermediate | ^ V |
|-^--------2-| Routers |-^--------V-|
| ^ V | | ^ V |
| ^ V | +-----+ +-----+ | ^ V |
>>>>>>>>>>^ >3>>>>>>>>4>>>>>>>>>>>4>>>>>>>>>5 5>>>>>>>>>
| | | | | | | |
GIST | 6<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<6 |
Level +------------+ +-----+ +-----+ +------------+
>>>>>, <<<<< = Signalling messages
1 - 6 = Stages in the example
(stages 7 and 8 are not shown)
Figure 3: Example of Operation
図3：操作の例
Consider the case of an RSVP-like signalling application that makes receiver-based resource reservations for a single unicast flow. In general, signalling can take place along the entire end-to-end path (between flow source and destination), but the role of GIST is only to transfer signalling messages over a single segment of the path, between neighbouring resource-capable nodes. Basic GIST operation is the same, whether it involves the endpoints or only interior nodes: in either case, GIST is triggered by a request from a local signalling application. The example here describes how GIST transfers messages between two adjacent peers some distance along the path, GN1 and GN2 (see Figure 3). We take up the story at the point where a message is being processed above the GIST layer by the signalling application in GN1.
単一のユニキャストフローのレシーバーベースのリソース予約を作成するRSVP様シグナル伝達アプリケーションの場合を考えてみましょう。一般に、シグナリングはエンドツーエンドパス全体（フローソースと宛先間）に沿って行われますが、GISTの役割は、隣接するリソース対応ノード間のパスの単一セグメントにシグナリングメッセージを転送することです。基本的なGIST操作は、エンドポイントであろうとインテリアノードのみを伴うかどうかにも同じです。どちらの場合も、GISTはローカルシグナリングアプリケーションからの要求によってトリガーされます。ここでの例では、GISTがパス、GN1とGN2に沿ってある隣接する2つのピア間のメッセージをある程度伝達する方法を説明しています（図3を参照）。GN1のシグナリングアプリケーションにより、メッセージが要点層の上にメッセージが処理されているポイントでストーリーを取り上げます。
1. The signalling application in GN1 determines that this message is a simple description of resources that would be appropriate for the flow. It determines that it has no special security or transport requirements for the message, but simply that it should be transferred to the next downstream signalling application peer on the path that the flow will take.
1. GN1のシグナリングアプリケーションは、このメッセージがフローに適したリソースの簡単な説明であると判断します。メッセージの特別なセキュリティまたは輸送要件はないと判断されますが、単にフローがとるパス上の次の下流のシグナリングアプリケーションのピアに転送する必要があると判断します。
2. The message payload is passed to the GIST layer in GN1, along with a definition of the flow and description of the message transfer attributes (in this case, requesting no reliable transmission or channel security protection). GIST determines that this particular message does not require fragmentation and that it has no knowledge of the next peer for this flow and signalling application; however, it also determines that this application is likely to require secured upstream and downstream transport of large messages in the future. This determination is a function of node-internal policy interactions between GIST and the signalling application.
2. メッセージペイロードは、メッセージ転送属性のフローと説明の定義とともに、GN1のGISTレイヤーに渡されます（この場合、信頼できる送信またはチャネルセキュリティ保護を要求しません）。GISTは、この特定のメッセージは断片化を必要とせず、このフローとシグナリングアプリケーションの次のピアの知識がないことを決定します。ただし、このアプリケーションは、将来的には大きなメッセージの上流および下流の輸送が必要である可能性が高いと判断します。この決定は、GISTとシグナリングアプリケーションの間のノード内部ポリシー相互作用の関数です。
3. GN1 therefore constructs a GIST Query carrying the NSLP payload, and additional payloads at the GIST level which will be used to initiate a messaging association. The Query is encapsulated in a UDP datagram and injected into the network. At the IP level, the destination address is the flow receiver, and an IP Router Alert Option (RAO) is also included.
3. したがって、GN1は、NSLPペイロードを運ぶGISTクエリと、メッセージング関連の開始に使用されるGISTレベルで追加のペイロードを構築します。クエリはUDPデータグラムにカプセル化され、ネットワークに注入されます。IPレベルでは、宛先アドレスがフローレシーバーであり、IPルーターアラートオプション（RAO）も含まれています。
4. The Query passes through the network towards the flow receiver, and is seen by each router in turn. GIST-unaware routers will not recognise the RAO value and will forward the message unchanged; GIST-aware routers that do not support the NSLP in question will also forward the message basically unchanged, although they may need to process more of the message to decide this after initial interception.
4. クエリは、ネットワークを通過してフローレシーバーに向かって通過し、各ルーターに順番に表示されます。Gist-unawareルーターはRaoの値を認識せず、メッセージを変更せずに転送します。問題のNSLPをサポートしていないGist-Awareルーターは、基本的に変更されていないメッセージも転送しますが、最初の傍受後にこれを決定するためにもっとメッセージを処理する必要があります。
5. The message is intercepted at GN2. The GIST layer identifies the message as relevant to a local signalling application, and passes the NSLP payload and flow description upwards to it. This signalling application in GN2 indicates to GIST that it will peer with GN1 and so GIST should proceed to set up any routing state. In addition, the signalling application continues to process the message as in GN1 (compare step 1), passing the message back down to GIST so that it is sent further downstream, and this will eventually result in the message reaching the flow receiver. GIST itself operates hop-by-hop, and the signalling application joins these hops together to manage the end-to-end signalling operations.
5. メッセージはGN2で傍受されます。GISTレイヤーは、メッセージをローカルシグナリングアプリケーションに関連するものとして識別し、NSLPペイロードとフローの説明を上に渡します。GN2でのこのシグナリングアプリケーションは、GN1とピアになるため、GISTがルーティング状態を設定するために進む必要があることをGISTに示します。さらに、シグナリングアプリケーションは、GN1のようにメッセージの処理を続け（ステップ1を比較）、メッセージをGISTに戻してさらに下流に送信し、最終的にメッセージがフローレシーバーに届くようになります。Gist自体はホップバイホップを動作させ、シグナリングアプリケーションがこれらのホップを結合してエンドツーエンドのシグナリング操作を管理します。
6. In parallel, the GIST instance in GN2 now knows that it should maintain routing state and a messaging association for future signalling with GN1. This is recognised because the message is a Query, and because the local signalling application has indicated that it will peer with GN1. There are two possible cases for sending back the necessary GIST Response: 6.A - Association Exists: GN1 and GN2 already have an appropriate MA. GN2 simply records the identity of GN1 as its upstream peer for that flow and NSLP, and sends a Response back to GN1 over the MA identifying itself as the peer for this flow.
6. 並行して、GN2のGISTインスタンスは、ルーティング状態とGN1との将来のシグナル伝達のためのメッセージング協会を維持する必要があることを知っています。これは、メッセージがクエリであり、ローカルシグナリングアプリケーションがGN1とピアになることを示しているために認識されます。必要な要点応答を送り返すための2つの可能なケースがあります。6.a-関連付け：GN1とGN2にはすでに適切なMAがあります。GN2は、GN1のアイデンティティをそのフローとNSLPの上流のピアとして単純に記録し、このフローのピアとして識別するMAを介してGN1への応答を送り返します。
6.B - No Association: GN2 sends the Response in D-mode directly to GN1, identifying itself and agreeing to the messaging association setup. The protocol exchanges needed to complete this will proceed in parallel with the following stages.
6.B-アソシエーションなし：GN2はDモードの応答をGN1に直接送信し、それ自体を特定し、メッセージング協会のセットアップに同意します。これを完了するために必要なプロトコル交換は、次の段階と並行して進行します。
In each case, the result is that GN1 and GN2 are now in a peering relationship for the flow.
いずれの場合も、GN1とGN2が流れのために覗き見になっていることがあります。
7. Eventually, another NSLP message works its way upstream from the receiver to GN2. This message contains a description of the actual resources requested, along with authorisation and other security information. The signalling application in GN2 passes this payload to the GIST level, along with the flow definition and transfer attributes; in this case, it could request reliable transmission and use of a secure channel for integrity protection. (Other combinations of attributes are possible.)
7. 最終的に、別のNSLPメッセージが受信機からGN2まで上流に動作します。このメッセージには、要求された実際のリソースの説明と、認可およびその他のセキュリティ情報が含まれています。GN2のシグナリングアプリケーションは、このペイロードをGISTレベルに渡し、フロー定義と転送属性とともに渡されます。この場合、信頼できる送信と、整合性保護のための安全なチャネルの使用を要求できます。（属性の他の組み合わせが可能です。）
8. The GIST layer in GN2 identifies the upstream peer for this flow and NSLP as GN1, and determines that it has an MA with the appropriate properties. The message is queued on the MA for transmission; this may incur some delay if the procedures begun in step 6.B have not yet completed.
8. GN2のGIST層は、このフローの上流のピアを、NSLPをGN1として識別し、適切な特性を持つMAがあると判断します。メッセージは、送信のためにMAでキューに掲載されています。これにより、ステップ6.Bで開始された手順がまだ完了していない場合、これにより遅延が発生する可能性があります。
Further messages can be passed in each direction in the same way. The GIST layer in each node can in parallel carry out maintenance operations such as route change detection (see Section 7.1).
同じ方法で、各方向にさらなるメッセージを渡すことができます。各ノードのGISTレイヤーは、ルート変更検出などのメンテナンス操作を並行して実行できます（セクション7.1を参照）。
It should be understood that several of these details of GIST operations can be varied, either by local policy or according to signalling application requirements. The authoritative details are contained in the remainder of this document.
GIST操作のこれらの詳細のいくつかは、ローカルポリシーまたはシグナリングアプリケーションの要件によって変化する可能性があることを理解する必要があります。権威ある詳細は、この文書の残りの部分に含まれています。
This section defines the basic structure and operation of GIST. Section 4.1 describes the way in which GIST interacts with local signalling applications in the form of an abstract service interface. Section 4.2 describes the per-flow and per-peer state that GIST maintains for the purpose of transferring messages. Section 4.3 describes how messages are processed in the case where any necessary messaging associations and routing state already exist; this includes the simple scenario of pure D-mode operation, where no messaging associations are necessary. Finally, Section 4.4 describes how routing state and messaging associations are created and managed.
このセクションでは、要点の基本構造と動作を定義します。セクション4.1では、GISTが抽象サービスインターフェイスの形でローカルシグナリングアプリケーションと相互作用する方法について説明します。セクション4.2では、GISTがメッセージを転送する目的で維持しているフローごととピアごとの状態について説明します。セクション4.3では、必要なメッセージング関連とルーティング状態がすでに存在する場合に、メッセージがどのように処理されるかについて説明します。これには、メッセージングアソシエーションが必要ない純粋なDモード操作の単純なシナリオが含まれます。最後に、セクション4.4では、ルーティング状態とメッセージングの関連付けがどのように作成および管理されるかについて説明します。
This section describes the interaction between GIST and signalling applications in terms of an abstract service interface, including a definition of the attributes of the message transfer that GIST can offer. The service interface presented here is non-normative and does not constrain actual implementations of any interface between GIST and signalling applications; the interface is provided to aid understanding of how GIST can be used. However, requirements on SID selection and internal GIST behaviour to support message transfer semantics (such as in-order delivery) are stated normatively here.
このセクションでは、GISTが提供できるメッセージ転送の属性の定義を含む、抽象サービスインターフェイスの観点からのGISTアプリケーションとシグナリングアプリケーション間の相互作用について説明します。ここに示されているサービスインターフェイスは非規範的であり、GISTアプリケーションとシグナリングアプリケーションの間のインターフェイスの実際の実装を制限しません。インターフェイスは、GISTの使用方法の理解を支援するために提供されます。ただし、メッセージ転送セマンティクス（注文内配信など）をサポートするためのSID選択と内部GISTの動作に関する要件は、ここで規範的に記載されています。
The same service interface is presented at every GIST node; however, applications may invoke it differently at different nodes, depending for example on local policy. In addition, the service interface is defined independently of any specific transport protocol, or even the distinction between D-mode and C-mode. The initial version of this specification defines how to support the service interface using a C-mode based on TCP; if additional protocol support is added, this will support the same interface and so the change will be invisible to applications, except as a possible performance improvement. A more detailed description of this service interface is given in Appendix B.
同じサービスインターフェイスがすべてのGISTノードで表示されます。ただし、アプリケーションは、たとえばローカルポリシーに応じて、さまざまなノードで異なる呼び出しを行う場合があります。さらに、サービスインターフェイスは、特定の輸送プロトコル、またはDモードとCモードの区別とは無関係に定義されます。この仕様の初期バージョンは、TCPに基づいたCモードを使用してサービスインターフェイスをサポートする方法を定義します。追加のプロトコルサポートが追加された場合、これにより同じインターフェイスがサポートされるため、パフォーマンスの改善の可能性を除き、変更はアプリケーションに見えません。このサービスインターフェイスのより詳細な説明は、付録Bに記載されています。
Fundamentally, GIST provides a simple message-by-message transfer service for use by signalling applications: individual messages are sent, and individual messages are received. At the service interface, the NSLP payload, which is opaque to GIST, is accompanied by control information expressing the application's requirements about how the message should be routed (the MRI), and the application also provides the session identifier (SID); see Section 4.1.3. Additional message transfer attributes control the specific transport and security properties that the signalling application desires.
基本的に、GISTは、シグナリングアプリケーションによって使用するためのシンプルなメッセージごとの転送サービスを提供します。個々のメッセージが送信され、個々のメッセージが受信されます。サービスインターフェイスでは、GISTに不透明であるNSLPペイロードには、メッセージのルーティング方法に関するアプリケーションの要件（MRI）に関する要件を表す制御情報が添付され、アプリケーションはセッション識別子（SID）も提供します。セクション4.1.3を参照してください。追加のメッセージ転送属性は、信号アプリケーションが望む特定の輸送およびセキュリティプロパティを制御します。
The distinction between GIST D- and C-mode is not visible at the service interface. In addition, the functionality to handle fragmentation and reassembly, bundling together of small messages for efficiency, and congestion control are not visible at the service interface; GIST will take whatever action is necessary based on the properties of the messages and local node state.
GIST D-MODEとCモードの区別は、サービスインターフェイスでは表示されません。さらに、断片化と再組み立てを処理する機能、効率のための小さなメッセージのバンドル、および輻輳制御はサービスインターフェイスでは見えません。GISTは、メッセージのプロパティとローカルノード状態に基づいて、必要なアクションを実行します。
A signalling application is free to choose the rate at which it processes inbound messages; an implementation MAY allow the application to block accepting messages from GIST. In these circumstances, GIST MAY discard unreliably delivered messages, but for reliable messages MUST propagate flow-control condition back to the sender. Therefore, applications must be aware that they may in turn be blocked from sending outbound messages themselves.
シグナリングアプリケーションは、インバウンドメッセージを処理するレートを自由に選択できます。実装により、アプリケーションがGISTからのメッセージの受け入れをブロックできる場合があります。このような状況では、GISTは信頼できないメッセージを配信するメッセージを破棄する可能性がありますが、信頼できるメッセージの場合、フロー制御条件を送信者に戻す必要があります。したがって、アプリケーションは、アウトバウンドメッセージ自体を送信することをブロックする可能性があることに注意する必要があります。
Message transfer attributes are used by NSLPs to define minimum required levels of message processing. The attributes available are as follows:
メッセージ転送属性は、NSLPによって使用され、メッセージ処理の最小レベルを定義します。利用可能な属性は次のとおりです。
Reliability: This attribute may be 'true' or 'false'. When 'true', the following rules apply:
信頼性：この属性は「真」または「偽」である場合があります。「true」の場合、次のルールが適用されます。
* messages MUST be delivered to the signalling application in the peer exactly once or not at all;
* メッセージは、ピアのシグナリングアプリケーションに一度一度だけ配信する必要があります。
* for messages with the same SID, the delivery MUST be in order;
* 同じSIDを持つメッセージの場合、配信が整っている必要があります。
* if there is a chance that the message was not delivered (e.g., in the case of a transport layer error), an error MUST be indicated to the local signalling application identifying the routing information for the message in question.
* メッセージが配信されない可能性がある場合（たとえば、輸送層エラーの場合）、問題のメッセージのルーティング情報を識別するローカルシグナリングアプリケーションにエラーを示す必要があります。
GIST implements reliability by using an appropriate transport protocol within a messaging association, so mechanisms for the detection of message loss depend on the protocol in question; for the current specification, the case of TCP is considered in Section 5.7.2. When 'false', a message may be delivered, once, several times, or not at all, with no error indications in any of these cases.
GISTは、メッセージングアソシエーション内で適切な輸送プロトコルを使用することにより信頼性を実装するため、メッセージ損失を検出するメカニズムは、問題のプロトコルに依存します。現在の仕様では、TCPの場合はセクション5.7.2で検討されています。「false」の場合、メッセージを1回、数回、またはまったく届けない場合があり、これらの場合にエラーの表示はありません。
Security: This attribute defines the set of security properties that the signalling application requires for the message, including the type of protection required, and what authenticated identities should be used for the signalling source and destination. This information maps onto the corresponding properties of the security associations established between the peers in C-mode. Keying material for the security associations is established by the authentication mechanisms within the messaging association protocols themselves; see Section 8.2. The attribute can be specified explicitly by the signalling application, or reported by GIST to the signalling application. The latter can take place either on receiving a message, or just before sending a message but after configuring or selecting the messaging association to be used for it.
セキュリティ：この属性は、必要な保護の種類を含む、メッセージにシグナリングアプリケーションが必要とするセキュリティプロパティのセットを定義し、シグナリングソースと宛先に使用される認証されたアイデンティティを定義します。この情報は、Cモードのピア間に確立されたセキュリティ協会の対応するプロパティにマッピングされます。セキュリティ協会のキーイング資料は、メッセージング協会のプロトコル自体内の認証メカニズムによって確立されます。セクション8.2を参照してください。属性は、シグナリングアプリケーションによって明示的に指定されるか、GISTによってシグナリングアプリケーションに報告されます。後者は、メッセージの受信時、またはメッセージを送信する直前であり、それに使用するメッセージングアソシエーションを構成または選択した後に行うことができます。
This attribute can also be used to convey information about any address validation carried out by GIST, such as whether a return routability check has been carried out. Further details are discussed in Appendix B.
この属性は、RETURNルーティング可能性チェックが実行されたかどうかなど、GISTによって実行されるアドレス検証に関する情報を伝えるためにも使用できます。詳細については、付録Bで説明します。
Local Processing: An NSLP may provide hints to GIST to enable more efficient or appropriate processing. For example, the NSLP may select a priority from a range of locally defined values to influence the sequence in which messages leave a node. Any priority mechanism MUST respect the ordering requirements for reliable messages within a session, and priority values are not carried in the protocol or available at the signalling peer or intermediate nodes. An NSLP may also indicate that upstream path routing state will not be needed for this flow, to inhibit the node requesting its downstream peer to create it; conversely, even if routing state exists, the NSLP may request that it is not used, which will lead to GIST Data messages being sent Q-mode encapsulated instead.
ローカル処理：NSLPは、より効率的または適切な処理を可能にするためにGISTにヒントを提供する場合があります。たとえば、NSLPは、局所的に定義されたさまざまな値から優先度を選択して、メッセージがノードを離れるシーケンスに影響を与える場合があります。優先順位メカニズムは、セッション内の信頼できるメッセージの順序付け要件を尊重する必要があり、優先度の値はプロトコルでは携帯されていないか、シグナリングピアまたは中間ノードで使用できません。NSLPは、下流のピアを要求するノードを阻害するために、このフローには上流のパスルーティング状態が必要ではないことを示している場合があります。逆に、ルーティング状態が存在していても、NSLPは使用されていないことを要求する場合があり、代わりにQモードがカプセル化されているGISTデータメッセージが送信されます。
A GIST implementation MAY deliver messages with stronger attribute values than those explicitly requested by the application.
GIST実装は、アプリケーションで明示的に要求されたものよりも強い属性値を持つメッセージを提供する場合があります。
The fact that SIDs index routing state (see Section 4.2.1 below) means that there are requirements for how they are selected. Specifically, signalling applications MUST choose SIDs so that they are cryptographically random, and SHOULD NOT use several SIDs for the same flow, to avoid additional load from routing state maintenance. Guidance on secure randomness generation can be found in [31].
SIDSインデックスルーティング状態（以下のセクション4.2.1を参照）が、それらの選択方法には要件があることを意味します。具体的には、シグナリングアプリケーションがSIDを選択して、暗号化されたランダムであるように選択する必要があり、ルーティング状態メンテナンスからの追加負荷を回避するために、同じフローに複数のSIDを使用しないでください。安全なランダム生成に関するガイダンスは[31]にあります。
For each flow, the GIST layer can maintain message routing state to manage the processing of outgoing messages. This state is conceptually organised into a table with the following structure. Each row in the table corresponds to a unique combination of the following three items: Message Routing Information (MRI): This defines the method to be used to route the message, the direction in which to send the message, and any associated addressing information; see Section 3.3.
各フローについて、GISTレイヤーはメッセージルーティング状態を維持して、発信メッセージの処理を管理できます。この状態は、次の構造を持つテーブルに概念的に編成されています。テーブル内の各行は、次の3つの項目の一意の組み合わせに対応しています。メッセージルーティング情報（MRI）：これは、メッセージをルーティングするために使用するメソッド、メッセージを送信する方向、および関連するアドレス指定情報を定義します。セクション3.3を参照してください。
Session Identifier (SID): The signalling session with which this message should be associated; see Section 3.7.
セッション識別子（SID）：このメッセージを関連付ける必要があるシグナリングセッション。セクション3.7を参照してください。
NSLP Identifier (NSLPID): This is an IANA-assigned identifier associated with the NSLP that is generating messages for this flow; see Section 3.8. The inclusion of this identifier allows the routing state to be different for different NSLPs.
NSLP識別子（NSLPID）：これは、このフローのメッセージを生成しているNSLPに関連付けられたIANAが割り当てられた識別子です。セクション3.8を参照してください。この識別子を含めると、NSLPが異なるとルーティング状態が異なります。
The information associated with a given MRI/SID/NSLPID combination consists of the routing state to reach the peer in the direction given by the MRI. For any flow, there will usually be two entries in the table, one each for the upstream and downstream MRI. The routing state includes information about the peer identity (see Section 4.4.3), and a UDP port number for D-mode, or a reference to one or more MAs for C-mode. Entries in the routing state table are created by the GIST handshake, which is described in more detail in Section 4.4.
特定のMRI/SID/NSLPIDの組み合わせに関連付けられた情報は、MRIによって与えられた方向にピアに到達するためのルーティング状態で構成されています。フローについては、通常、テーブルには2つのエントリがあり、1つは上流と下流のMRIに1つあります。ルーティング状態には、ピアアイデンティティに関する情報（セクション4.4.3を参照）、DモードのUDPポート番号、またはCモードの1つ以上のMASへの参照が含まれます。ルーティング状態テーブルのエントリは、GISTハンドシェイクによって作成されます。これについては、セクション4.4で詳細に説明します。
It is also possible for the state information for either direction to be empty. There are several possible cases:
また、いずれかの方向が空になる可能性もあります。いくつかの可能なケースがあります：
o The signalling application has indicated that no messages will actually be sent in that direction.
o シグナリングアプリケーションは、実際にその方向にメッセージが送信されないことを示しています。
o The node is the endpoint of the signalling path, for example, because it is acting as a proxy, or because it has determined that there are no further signalling nodes in that direction.
o たとえば、ノードはシグナリングパスのエンドポイントです。たとえば、プロキシとして機能しているため、またはその方向にそれ以上のシグナリングノードがないと判断したためです。
o The node is using other techniques to route the message. For example, it can send it in Q-mode and rely on the peer to intercept it.
o ノードは、メッセージをルーティングするために他の手法を使用しています。たとえば、Qモードで送信し、ピアに依存してインターセプトできます。
In particular, if the node is a flow endpoint, GIST will refuse to create routing state for the direction beyond the end of the flow (see Section 4.3.3). Each entry in the routing state table has an associated validity timer indicating for how long it can be considered accurate. When this timer expires, the entry MUST be purged if it has not been refreshed. Installation and maintenance of routing state are described in more detail in Section 4.4.
特に、ノードがフローエンドポイントである場合、GISTはフローの終わりを超えた方向のルーティング状態の作成を拒否します（セクション4.3.3を参照）。ルーティング状態テーブルの各エントリには、正確であると見なすことができる期間を示す関連する妥当性タイマーがあります。このタイマーが期限切れになった場合、エントリが更新されていない場合は、エントリをパージする必要があります。ルーティング状態の設置とメンテナンスについては、セクション4.4で詳しく説明します。
The per-flow message routing state is not the only state stored by GIST. There is also the state required to manage the MAs. Since these are not per-flow, they are stored separately from the routing state, including the following per-MA information:
Flowメッセージルーティング状態は、GISTによって保存される唯一の状態ではありません。MASを管理するために必要な状態もあります。これらは流量あたりではないため、次のMA情報を含むルーティング状態とは別に保存されます。
o a queue of any messages that require the use of an MA, pending transmission while the MA is being established;
o MAの使用を必要とするメッセージのキュー、MAが確立されている間に送信が保留されています。
o the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5).
o ピアがMAを開いたままにしたいという欲求を再述べた時点（セクション4.4.5を参照）。
In addition, per-MA state, such as TCP port numbers or timer information, is held in the messaging association protocols themselves. However, the details of this state are not directly visible to GIST, and they do not affect the rest of the protocol description.
さらに、TCPポート番号やタイマー情報などのMAごとの状態は、メッセージングアソシエーションプロトコル自体に保持されています。ただし、この状態の詳細はGISTに直接表示されず、残りのプロトコルの説明には影響しません。
This section describes how signalling application messages are processed in the case where any necessary messaging associations and routing state are already in place. The description is divided into several parts. First, message reception, local processing, and message transmission are described for the case where the node hosts the NSLPID identified in the message. Second, in Section 4.3.4, the case where the message is handled directly in the IP or GIST layer (because there is no matching signalling application on the node) is given. An overview is given in Figure 4. This section concentrates on the GIST-level processing, with full details of IP and transport layer encapsulation in Section 5.3 and Section 5.4.
このセクションでは、必要なメッセージング関連とルーティング状態が既に整っている場合、シグナリングアプリケーションメッセージがどのように処理されるかについて説明します。説明はいくつかの部分に分かれています。最初に、メッセージで識別されたNSLPIDをノードがホストする場合については、メッセージの受信、ローカル処理、およびメッセージ伝達について説明します。第二に、セクション4.3.4では、メッセージがIPまたはGISTレイヤーで直接処理される場合（ノードに一致するシグナリングアプリケーションがないため）。概要を図4に示します。このセクションでは、GISTレベルの処理に集中し、セクション5.3およびセクション5.4のIPおよびトランスポート層のカプセル化の詳細を示しています。
+---------------------------------------------------------+
| >> Signalling Application Processing >> |
| |
+--------^---------------------------------------V--------+
^ NSLP NSLP V
^ Payloads Payloads V
+--------^---------------------------------------V--------+
| >> GIST >> |
| ^ ^ ^ Processing V V V |
+--x-----------N--Q---------------------Q--N-----------x--+
x N Q Q N x
x N Q>>>>>>>>>>>>>>>>>>>>>Q N x
x N Q Bypass at Q N x
+--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+
| C-mode | | D-mode | | D-mode | | C-mode |
|Handling| |Handling| |Handling| |Handling|
+--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+
x N Q Q N x
x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x
x N Q Bypass at Q N x
+--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+
|IP Host | | Q-mode | alert) level | Q-mode | |IP Host |
|Handling| |Handling| |Handling| |Handling|
+--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+
x N Q Q N x
+--x--N-----------Q--+ +--Q-----------N--x--+
| IP Layer | | IP Layer |
| (Receive Side) | | (Transmit Side) |
+--x--N-----------Q--+ +--Q-----------N--x--+
x N Q Q N x
x N Q Q N x
NNNNNNNNNNNNNN = Normal D-mode messages QQQQQQQQQQQQQQ = D-mode messages that are Q-mode encapsulated xxxxxxxxxxxxxx = C-mode messages RAO = Router Alert Option
nnnnnnnnnnnnnnnnn =通常のd-modeメッセージqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq dmode capsulated xxxxxxxxxxxxxx = c-modeメッセージrao =ルーターアラートオプション
Figure 4: Message Paths through a GIST Node
図4：GISTノードを通るメッセージパス
Messages can be received in C-mode or D-mode.
メッセージは、CモードまたはDモードで受信できます。
Reception in C-mode is simple: incoming packets undergo the security and transport treatment associated with the MA, and the MA provides complete messages to the GIST layer for further processing.
Cモードでの受信は簡単です。着信パケットはMAに関連するセキュリティおよび輸送処理を受け、MAはさらに処理するためにGISTレイヤーに完全なメッセージを提供します。
Reception in D-mode depends on the message type.
Dモードの受信はメッセージタイプによって異なります。
Normal encapsulation: Normal messages arrive UDP-encapsulated and addressed directly to the receiving signalling node, at an address and port learned previously. Each datagram contains a single message, which is passed to the GIST layer for further processing, just as in the C-mode case.
通常のカプセル化：通常のメッセージがudpにカプセル化され、以前に学んだアドレスとポートで、受信シグナリングノードに直接アドレス指定されます。各データグラムには、Cモードの場合と同様に、さらに処理するためにGISTレイヤーに渡される単一のメッセージが含まれています。
Q-mode encapsulation: Where GIST is sending messages to be intercepted by the appropriate peer rather than directly addressed to it (in particular, Query messages), these are UDP encapsulated, and MAY include an IP Router Alert Option (RAO) if required by the MRM. Each GIST node can therefore see every such message, but unless the message exactly matches the Q-mode encapsulation rules (Section 5.3.2) it MUST be forwarded transparently at the IP level. If it does match, GIST MUST check the NSLPID in the common header. The case where the NSLPID does not match a local signalling application at all is considered below in Section 4.3.4; otherwise, the message MUST be passed up to the GIST layer for further processing.
Q-Modeカプセル化：GISTが直接アドレス指定されるのではなく、適切なピアによって傍受されるメッセージを送信している場合（特にクエリメッセージ）、これらはUDPカプセル化されており、必要に応じてIPルーターアラートオプション（RAO）が含まれる場合があります。MRM。したがって、各Gistノードはそのようなすべてのメッセージを見ることができますが、メッセージがQモードカプセル化ルール（セクション5.3.2）と正確に一致しない限り、IPレベルで透過的に転送する必要があります。一致する場合、GISTは共通ヘッダーのNSLPIDを確認する必要があります。NSLPIDがローカルシグナリングアプリケーションとまったく一致しない場合は、セクション4.3.4で以下で考慮されます。それ以外の場合、メッセージは、さらに処理するためにGISTレイヤーに渡す必要があります。
Several different RAO values may be used by the NSIS protocol suite. GIST itself does not allocate any RAO values (for either IPv4 or IPv6); an assignment is made for each NSLP using MRMs that use the RAO in the Q-mode encapsulation. The assignment rationale is discussed in a separate document [12]. The RAO value assigned for an NSLPID may be different for IPv4 and IPv6. Note the different significance between the RAO and the NSLPID values: the meaning of a message (which signalling application it refers to, whether it should be processed at a node) is determined only from the NSLPID; the role of the RAO value is simply to allow nodes to pre-filter which IP datagrams are analysed to see if they might be Q-mode GIST messages.
NSISプロトコルスイートでは、いくつかの異なるRAO値を使用できます。GIST自体は、RAO値を割り当てません（IPv4またはIPv6のいずれか）。Qモードカプセル化でRAOを使用するMRMSを使用して、各NSLPに対して割り当てが行われます。割り当ての根拠は、別の文書[12]で説明されています。NSLPIDに割り当てられたRAO値は、IPv4とIPv6で異なる場合があります。RAOとNSLPID値の間の異なる重要性に注意してください。メッセージの意味（ノードで処理する必要があるかどうかを指すシグナリングアプリケーション）は、NSLPIDからのみ決定されます。RAO値の役割は、単にIPデータグラムが分析されるノードがQモードGISTメッセージであるかどうかを確認するために、単にノードを事前フィルターにすることです。
For all assignments associated with NSIS, the RAO-specific processing is the same and is as defined by this specification, here and in Section 4.3.4 and Section 5.3.2.
NSISに関連付けられたすべての割り当てについて、RAO固有の処理は同じであり、この仕様で定義されているとおり、ここおよびセクション4.3.4およびセクション5.3.2で定義されています。
Immediately after reception, the GIST hop count is checked. Any message with a GIST hop count of zero MUST be rejected with a "Hop Limit Exceeded" error message (Appendix A.4.4.2); note that a correct GIST implementation will never send a message with a GIST hop count of zero. Otherwise, the GIST hop count MUST be decremented by one before the next stage.
受信直後、GISTホップカウントがチェックされます。ゼロの要点ホップカウントを持つメッセージは、「ホップ制限を超えた」エラーメッセージで拒否する必要があります（付録A.4.4.2）。正しいGIST実装は、GISTホップカウントのゼロでメッセージを送信しないことに注意してください。それ以外の場合、Gist Hopカウントは、次の段階の前に1つずつ減少する必要があります。
Once a message has been received, it is processed locally within the GIST layer. Further processing depends on the message type and payloads carried; most of the GIST payloads are associated with internal state maintenance, and details are covered in Section 4.4.
メッセージが受信されると、GISTレイヤー内で局所的に処理されます。さらなる処理は、伝達されるメッセージの種類とペイロードに依存します。GISTペイロードのほとんどは、内部状態のメンテナンスに関連付けられており、詳細はセクション4.4で説明されています。
This section concentrates on the interaction with the signalling application, in particular, the decision to peer and how data is delivered to the NSLP.
このセクションでは、シグナリングアプリケーションとの相互作用、特にピアへの決定、およびデータがNSLPにどのように配信されるかとの相互作用に集中しています。
In the case of a Query, there is an interaction with the signalling application to determine which of two courses to follow. The first option (peering) MUST be chosen if the node is the final destination of the Query message.
クエリの場合、シグナリングアプリケーションとの相互作用があり、2つのコースのどれが従うべきかを判断します。ノードがクエリメッセージの最終宛先である場合、最初のオプション（ピアリング）を選択する必要があります。
1. The receiving signalling application wishes to become a signalling peer with the Querying node. GIST MUST continue with the handshake process to set up message routing state, as described in Section 4.4.1. The application MAY provide an NSLP payload for the same NSLPID, which GIST will transfer in the Response.
1. 受信シグナリングアプリケーションは、クエリノードを使用してシグナリングピアになることを望んでいます。GISTは、セクション4.4.1で説明されているように、メッセージルーティング状態を設定するために握手プロセスを継続する必要があります。アプリケーションは、同じNSLPIDに対してNSLPペイロードを提供する場合があり、GISTは応答で転送されます。
2. The signalling application does not wish to set up state with the Querying node and become its peer. This includes the case where a node wishes to avoid taking part in the signalling for overload protection reasons. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. Note that if the node that finally processes the Query returns an Error message, this will be sent directly back to the originating node, bypassing any forwarders. For these diagnostics to be meaningful, any GIST node forwarding a Query, or relaying it with modified NSLP payload, MUST NOT modify it except in the GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation.
2. シグナリングアプリケーションは、クエリノードを使用して状態を設定し、ピアになることを望みません。これには、ノードが過負荷保護の理由でシグナリングに参加しないようにしたい場合が含まれます。GISTは、セクション4.3.4で説明したケースと同様に、クエリを伝播する必要があります。メッセージはクエリノードに送信されません。アプリケーションは、同じNSLPIDに対して更新されたNSLPペイロードを提供する場合があります。これは、GISTによって転送されるクエリで使用されます。最終的にクエリを処理するノードがエラーメッセージを返す場合、これはフォワーダーをバイパスして、元のノードに直接送信されることに注意してください。これらの診断が意味のあるものであるために、GISTノードはクエリを転送するか、変更されたNSLPペイロードでリレーすることで、GIST HOPカウントを除いて変更してはなりません。特に、他のGISTペイロードやその注文を変更してはなりません。実装は、解析された内部表現から再構築するのではなく、元のメッセージを保持することにより、これを達成することを選択する場合があります。
This interaction with the signalling application, including the generation or update of an NSLP payload, SHOULD take place synchronously as part of the Query processing. In terms of the GIST service interface, this can be implemented by providing appropriate return values for the primitive that is triggered when such a message is received; see Appendix B.2 for further discussion.
NSLPペイロードの生成または更新を含むシグナリングアプリケーションとのこの相互作用は、クエリ処理の一部として同期して行われる必要があります。GISTサービスインターフェイスに関しては、このようなメッセージが受信されたときにトリガーされるプリミティブに適切な返品値を提供することにより、これを実装できます。詳細については、付録B.2を参照してください。
For all GIST message types other than Queries, if the message includes an NSLP payload, this MUST be delivered locally to the signalling application identified by the NSLPID. The format of the payload is not constrained by GIST, and the content is not interpreted. Delivery is subject to the following validation checks, which MUST be applied in the sequence given: 1. if the message was explicitly routed (see Section 7.1.5) or is a Data message delivered without routing state (see Section 5.3.2), the payload is delivered but flagged to the receiving NSLP to indicate that routing state was not validated;
クエリ以外のすべてのGISTメッセージタイプについて、メッセージにNSLPペイロードが含まれている場合、これはNSLPIDによって識別された信号アプリケーションにローカルに配信する必要があります。ペイロードの形式はGISTによって制約されず、コンテンツは解釈されません。配信には、次の検証チェックが適用されます。これは、次のようなシーケンスに適用する必要があります。1。メッセージが明示的にルーティングされた場合（セクション7.1.5を参照）、またはルーティング状態なしで配信されるデータメッセージ（セクション5.3.2を参照）、ペイロードは配信されますが、ルーティング状態が検証されていないことを示すために受信NSLPにフラグが付けられます。
2. else, if the message arrived on an association that is not associated with the MRI/NSLPID/SID combination given in the message, the message MUST be rejected with an "Incorrectly Delivered Message" error message (Appendix A.4.4.4);
2. それ以外の場合、メッセージがメッセージに記載されているMRI/NSLPID/SIDの組み合わせに関連付けられていない関連付けにメッセージが届いた場合、メッセージは「誤って配信されたメッセージ」エラーメッセージ（付録A.4.4.4）で拒否されなければなりません。
3. else, if there is no routing state for this MRI/SID/NSLPID combination, the message MUST either be dropped or be rejected with an error message (see Section 4.4.6 for further details);
3. それ以外の場合、このMRI/SID/NSLPIDの組み合わせにルーティング状態がない場合、メッセージをドロップするか、エラーメッセージで拒否する必要があります（詳細についてはセクション4.4.6を参照）。
4. else, the payload is delivered as normal.
4. そうでなければ、ペイロードは通常どおり配信されます。
Signalling applications can generate their messages for transmission, either asynchronously or in reply to an input message delivered by GIST, and GIST can also generate messages autonomously. GIST MUST verify that it is not the direct destination of an outgoing message, and MUST reject such messages with an error indication to the signalling application. When the message is generated by a signalling application, it may be carried in a Query if local policy and the message transfer attributes allow it; otherwise, this may trigger setup of an MA over which the NSLP payload is sent in a Data message.
シグナリングアプリケーションは、非同期的に、またはGISTによって配信される入力メッセージに応答して、伝送用のメッセージを生成できます。GISTは、メッセージを自律的に生成することもできます。GISTは、それが発信メッセージの直接的な宛先ではないことを確認する必要があり、シグナリングアプリケーションへのエラー表示でそのようなメッセージを拒否する必要があります。メッセージがシグナリングアプリケーションによって生成されると、ローカルポリシーとメッセージ転送属性が許可されている場合、クエリに掲載される場合があります。それ以外の場合、これは、NSLPペイロードがデータメッセージで送信されるMAのセットアップをトリガーする場合があります。
Signalling applications may specify a value to be used for the GIST hop count; otherwise, GIST selects a value itself. GIST MUST reject messages for which the signalling application has specified a value of zero. Although the GIST hop count is only intended to control message looping at the GIST level, the GIST API (Appendix B) provides the incoming hop count to the NSLPs, which can preserve it on outgoing messages as they are forwarded further along the path. This provides a lightweight loop-control mechanism for NSLPs that do not define anything more sophisticated. Note that the count will be decremented on forwarding through every GIST-aware node. Initial values for the GIST hop count are an implementation matter; one suitable approach is to use the same algorithm as for IP TTL setting [1].
シグナリングアプリケーションは、GISTホップカウントに使用する値を指定する場合があります。それ以外の場合、GISTは値自体を選択します。GISTは、シグナリングアプリケーションがゼロの値を指定したメッセージを拒否する必要があります。GISTホップカウントは、GISTレベルでのメッセージループを制御することのみを目的としていますが、GIST API（付録B）はNSLPSに着信ホップカウントを提供します。これは、より洗練されたものを定義しないNSLPの軽量ループ制御メカニズムを提供します。すべての要点を認識するノードを介して転送時にカウントが減少することに注意してください。GISTホップカウントの初期値は、実装問題です。適切なアプローチの1つは、IP TTL設定[1]と同じアルゴリズムを使用することです。
When a message is available for transmission, GIST uses internal policy and the stored routing state to determine how to handle it. The following processing applies equally to locally generated messages and messages forwarded from within the GIST or signalling application levels. However, see Section 5.6 for special rules applying to the transmission of Error messages by GIST.
メッセージが送信用に利用可能な場合、GISTは内部ポリシーと保存されたルーティング状態を使用して、それを処理する方法を決定します。以下の処理は、GISTまたはシグナリングアプリケーションレベル内から転送されるローカルで生成されたメッセージとメッセージに等しく適用されます。ただし、GISTによるエラーメッセージの送信に適用される特別なルールについては、セクション5.6を参照してください。
The main decision is whether the message must be sent in C-mode or D-mode. Reasons for using C-mode are:
主な決定は、メッセージをCモードまたはDモードで送信する必要があるかどうかです。Cモードを使用する理由は次のとおりです。
o message transfer attributes: for example, the signalling application has specified security attributes that require channel-secured delivery, or reliable delivery.
o メッセージ転送属性：たとえば、シグナリングアプリケーションには、チャネルが設定した配信、または信頼できる配信が必要なセキュリティ属性が指定されています。
o message size: a message whose size (including the GIST header, GIST objects and any NSLP payload, and an allowance for the IP and transport layer encapsulation required by D-mode) exceeds a fragmentation-related threshold MUST be sent over C-mode, using a messaging association that supports fragmentation and reassembly internally. The allowance for IP and transport layer encapsulation is 64 bytes. The message size MUST NOT exceed the Path MTU to the next peer, if this is known. If this is not known, the message size MUST NOT exceed the least of the first-hop MTU, and 576 bytes. The same limit applies to IPv4 and IPv6.
o メッセージサイズ：サイズ（GISTヘッダー、GISTオブジェクト、NSLPペイロードを含むメッセージ、およびDモードで必要なIPおよび輸送層のカプセル化の許容値）は、断片化関連のしきい値を超える必要があります。断片化と内部的に再組み立てをサポートするメッセージングアソシエーションを使用します。IPおよび輸送層のカプセル化の許容値は64バイトです。これがわかっている場合は、メッセージサイズが次のピアにパスMTUを超えてはなりません。これがわからない場合、メッセージサイズは、最初のホップMTUの少なくとも576バイトを超えてはなりません。同じ制限がIPv4とIPv6にも当てはまります。
o congestion control: D-mode SHOULD NOT be used for signalling where it is possible to set up routing state and use C-mode, unless the network can be engineered to guarantee capacity for D-mode traffic within the rate control limits imposed by GIST (see Section 5.3.3).
o 混雑制御：D-Modeは、GISTによって課されるレート制御制限内でDモードトラフィックの容量を保証するようにネットワークを設計できる場合を除き、ルーティング状態を設定してCモードを使用できる場合に可能な場合に信号を送信するために使用しないでください（C-Modeを使用できます。セクション5.3.3を参照）。
In principle, as well as determining that some messaging association must be used, GIST MAY select between a set of alternatives, e.g., for load sharing or because different messaging associations provide different transport or security attributes. For the case of reliable delivery, GIST MUST NOT distribute messages for the same session over multiple messaging associations in parallel, but MUST use a single association at any given time. The case of moving over to a new association is covered in Section 4.4.5.
原則として、いくつかのメッセージングアソシエーションを使用する必要があると判断するだけでなく、GISTは、ロード共有の場合、または異なるメッセージングアソシエーションが異なるトランスポートまたはセキュリティ属性を提供するため、たとえば、一連の代替案を選択できます。信頼できる配信の場合、GISTは複数のメッセージングアソシエーションで同じセッションのメッセージを並行して配布してはなりませんが、いつでも単一の関連付けを使用する必要があります。新しい協会に移動する場合は、セクション4.4.5で説明されています。
If the use of a messaging association (i.e., C-mode) is selected, the message is queued on the association found from the routing state table, and further output processing is carried out according to the details of the protocol stacks used. If no appropriate association exists, the message is queued while one is created (see Section 4.4.1), which will trigger the exchange of additional GIST messages. If no association can be created, this is an error condition, and should be indicated back to the local signalling application.
メッセージングアソシエーション（つまり、Cモード）の使用が選択されている場合、メッセージはルーティング状態テーブルから見つかったアソシエーションでキューに掲載され、使用されるプロトコルスタックの詳細に従ってさらに出力処理が実行されます。適切な関連付けが存在しない場合、メッセージが作成されている間にメッセージがキューになります（セクション4.4.1を参照）。これにより、追加のGISTメッセージの交換がトリガーされます。関連性を作成できない場合、これはエラー条件であり、ローカルシグナリングアプリケーションに戻る必要があります。
If a messaging association is not appropriate, the message is sent in D-mode. The processing in this case depends on the message type, local policy, and whether or not routing state exists.
メッセージングアソシエーションが適切でない場合、メッセージはDモードで送信されます。この場合の処理は、メッセージタイプ、ローカルポリシー、およびルーティング状態が存在するかどうかに依存します。
o If the message is not a Query, and local policy does not request the use of Q-mode for this message, and routing state exists, it is sent with the normal D-mode encapsulation directly to the address from the routing state table.
o メッセージがクエリではなく、ローカルポリシーがこのメッセージのQモードの使用を要求しない場合、ルーティング状態が存在する場合、通常のDモードカプセル化がルーティング状態テーブルからアドレスに直接送信されます。
o If the message is a Query, or the message is Data and local policy as given by the message transfer attributes requests the use of Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the details depend on the message routing method.
o メッセージがクエリである場合、またはメッセージがQモードの使用を要求するメッセージ転送属性によって与えられたデータとローカルポリシーである場合、セクション5.3.2で定義されているQモードで送信されます。詳細は、メッセージルーティング方法によって異なります。
o If no routing state exists, GIST can attempt to use Q-mode as in the Query case: either sending a Data message with the Q-mode encapsulation or using the event as a trigger for routing state setup (see Section 4.4). If this is not possible, e.g., because the encapsulation for the MRM is only defined for one message direction, then this is an error condition that is reported back to the local signalling application.
o ルーティング状態が存在しない場合、GISTはクエリケースのようにQモードを使用しようとすることができます。Q-Modeカプセル化を使用してデータメッセージを送信するか、状態のセットアップをルーティングするトリガーとしてイベントを使用します（セクション4.4を参照）。これが不可能な場合、たとえば、MRMのカプセル化は1つのメッセージ方向に対してのみ定義されるため、これはローカルシグナリングアプリケーションに報告されるエラー条件です。
A node may receive messages where it has no signalling application corresponding to the message NSLPID. There are several possible cases depending mainly on the encapsulation:
ノードは、メッセージNSLPIDに対応するシグナルアプリケーションがないメッセージを受信する場合があります。主にカプセル化に応じて、いくつかの可能なケースがあります。
1. A message contains an RAO value that is relevant to NSIS, but it does not exactly match the Q-mode encapsulation rules of Section 5.3.2. The message MUST be transparently forwarded at the IP layer. See Section 3.6.
1. メッセージには、NSISに関連するRAO値が含まれていますが、セクション5.3.2のQモードカプセル化ルールと正確には一致しません。メッセージは、IPレイヤーで透過的に転送する必要があります。セクション3.6を参照してください。
2. A Q-mode encapsulated message contains an RAO value that has been assigned to some NSIS signalling application but that is not used on this specific node, but the IP layer is unable to distinguish whether it needs to be passed to GIST for further processing or whether the packet should be forwarded just like a normal IP datagram.
2. Q-Modeカプセル化されたメッセージには、一部のNSISシグナリングアプリケーションに割り当てられたRAO値が含まれていますが、この特定のノードでは使用されていませんが、IPレイヤーは、さらに処理するためにGISTに渡す必要があるかどうかを区別できません。パケットは、通常のIPデータグラムと同じように転送する必要があります。
3. A Q-mode encapsulated message contains an RAO value that has been assigned to an NSIS signalling application that is used on this node, but the signalling application does not process the NSLPID in the message. (This covers the case where a signalling application uses a set of NSLPIDs.)
3. Q-Modeカプセル化されたメッセージには、このノードで使用されるNSISシグナリングアプリケーションに割り当てられたRAO値が含まれていますが、シグナリングアプリケーションではメッセージ内のNSLPIDを処理しません。（これは、シグナリングアプリケーションがNSLPIDSのセットを使用する場合をカバーします。）
4. A directly addressed message (in D-mode or C-mode) is delivered to a node for which there is no corresponding signalling application. With the current specification, this should not happen in normal operation. While future versions might find a use for such a feature, currently this MUST cause an "Unknown NSLPID" error message (Appendix A.4.4.6).
4. 直接アドレス指定されたメッセージ（DモードまたはCモード）は、対応するシグナリングアプリケーションがないノードに配信されます。現在の仕様では、これは通常の動作では発生しません。将来のバージョンはそのような機能の使用を見つけるかもしれませんが、現在、これは「不明なnslpid」エラーメッセージを引き起こす必要があります（付録A.4.4.6）。
5. A Q-mode encapsulated message arrives at the end-system that does not handle the signalling application. This is possible in normal operation, and MUST be indicated to the sender with an "Endpoint Found" informational message (Appendix A.4.4.7). The end-system includes the MRI and SID from the original message in the error message without interpreting them.
5. Qモードのカプセル化されたメッセージは、シグナリングアプリケーションを処理しない最終システムに到着します。これは通常の操作で可能であり、「エンドポイントが見つかった」情報メッセージ（付録A.4.4.7）を持つ送信者に示される必要があります。最終システムには、エラーメッセージを解釈せずに、元のメッセージからのMRIとSIDが含まれています。
6. The node is a GIST-aware NAT. See Section 7.2.
6. ノードは要点を認識しています。セクション7.2を参照してください。
In case (2) and (3), the role of GIST is to forward the message essentially as though it were a normal IP datagram, and it will not become a peer to the node sending the message. Forwarding with modified NSLP payloads is covered above in Section 4.3.2. However, a GIST implementation MUST ensure that the IP-layer TTL field and GIST hop count are managed correctly to prevent message looping, and this should be done consistently independently of where in the packet processing path the decision is made. The rules are that in cases (2) and (3), the IP-layer TTL MUST be decremented just as if the message was a normal IP forwarded packet. In case (3), the GIST hop count MUST be decremented as in the case of normal input processing, which also applies to cases (4) and (5).
（2）および（3）の場合、GISTの役割は、通常のIPデータグラムであるかのようにメッセージを本質的に転送することであり、メッセージを送信するノードのピアにはなりません。修正されたNSLPペイロードを使用した転送は、セクション4.3.2で上記の上にカバーされています。ただし、GISTの実装では、メッセージのループを防ぐためにIP層TTLフィールドとGISTホップカウントが正しく管理されていることを確認する必要があります。これは、決定が行われるパケット処理パス内の場所とは無関係に一貫して行う必要があります。ルールは、（2）および（3）の場合、メッセージが通常のIP転送パケットであるかのように、IP層TTLを減少させる必要があるということです。（3）の場合、通常の入力処理の場合と同様に、GISTホップカウントを減少させる必要があります。これは、ケース（4）および（5）にも適用されます。
A GIST node processing Q-mode encapsulated messages in this way SHOULD make the routing decision based on the full contents of the MRI and not only the IP destination address. It MAY also apply a restricted set of sanity checks and under certain conditions return an error message rather than forward the message. These conditions are:
この方法でのGISTノードの処理Qモードカプセル化メッセージは、IP宛先アドレスだけでなく、MRIの完全な内容に基づいてルーティング決定を行う必要があります。また、制限付きの正気チェックセットを適用し、特定の条件下でメッセージを転送するのではなく、エラーメッセージを返します。これらの条件は次のとおりです。
1. The message is so large that it would be fragmented on downstream links, for example, because the downstream MTU is abnormally small (less than 576 bytes). The error "Message Too Large" (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD begin messaging association setup.
1. メッセージは非常に大きいため、下流のMTUが異常に小さい（576バイト未満）ため、下流のリンクで断片化されます。エラー「メッセージが大きすぎる」（付録A.4.4.8）は、メッセージングアソシエーションのセットアップを開始するはずです。
2. The GIST hop count has reached zero. The error "Hop Limit Exceeded" (Appendix A.4.4.2) SHOULD be returned to the sender, which MAY retry with a larger initial hop count.
2. Gist Hopカウントはゼロに達しました。「ホップ制限を超えた」エラー（付録A.4.4.2）を送信者に返す必要があります。
3. The MRI represents a flow definition that is too general to be forwarded along a unique path (e.g., the destination address prefix is too short). The error "MRI Validation Failure" (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be returned to the sender, which MAY retry with restricted MRIs, possibly starting additional signalling sessions to do so. If the GIST node does not understand the MRM in question, it MUST NOT apply this check, instead forwarding the message transparently.
3. MRIは、一意のパスに沿って転送するには一般的すぎるフロー定義を表します（たとえば、宛先アドレスのプレフィックスが短すぎます）。サブコード0（「MRI Too Wild」）を備えたエラー「MRI検証障害」（付録A.4.4.12）は送信者に返されます。GISTノードが問題のMRMを理解していない場合、このチェックを適用しないでください。代わりにメッセージを透過的に転送します。
In the first two cases, only the common header of the GIST message is examined; in the third case, the MRI is also examined. The rest of the message MUST NOT be inspected in any case. Similar to the case of Section 4.3.2, the GIST payloads MUST NOT be modified or re-ordered; an implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation.
最初の2つのケースでは、GISTメッセージの共通ヘッダーのみが調べられます。3番目のケースでは、MRIも調べられます。メッセージの残りの部分は、いかなる場合でも検査してはなりません。セクション4.3.2の場合と同様に、GISTペイロードを変更または再注文してはなりません。実装は、解析された内部表現から再構築するのではなく、元のメッセージを保持することにより、これを達成することを選択する場合があります。
The main responsibility of GIST is to manage the routing state and messaging associations that are used in the message processing described above. Routing state is installed and refreshed by GIST handshake messages. Messaging associations are set up by the normal procedures of the transport and security protocols that comprise them, using peer IP addresses from the routing state. Once a messaging association has been created, its refresh and expiration can be managed independently from the routing state.
GISTの主な責任は、上記のメッセージ処理で使用されるルーティング状態およびメッセージングアソシエーションを管理することです。ルーティング状態は、GISTハンドシェイクメッセージによってインストールされ、更新されます。メッセージング関連は、ルーティング状態のピアIPアドレスを使用して、それらを構成する輸送およびセキュリティプロトコルの通常の手順によって設定されます。メッセージング協会が作成されると、その更新と有効期限は、ルーティング状態から独立して管理できます。
There are two different cases for state installation and refresh:
州の設置と更新には2つの異なるケースがあります。
1. Where routing state is being discovered or a new association is to be established; and
1. ルーティング状態が発見されている場合、または新しい関連付けが確立される場所。と
2. Where a suitable association already exists, including the case where routing state for the flow is being refreshed.
2. フローのルーティング状態が更新されている場合を含む、適切な関連性がすでに存在する場合。
These cases are now considered in turn, followed by the case of background general management procedures.
これらのケースは現在、順番に考慮され、その後、バックグラウンドの一般的な管理手順の場合が続きます。
The message sequence for GIST state setup between peers is shown in Figure 5 and described in detail below. The figure informally summarises the contents of each message, including optional elements in square brackets. An example is given in Appendix D.
ピア間のGIST状態のセットアップのメッセージシーケンスを図5に示し、以下に詳細に説明します。この図は、四角い括弧内のオプションの要素を含む、各メッセージの内容を非公式に要約しています。例を付録Dに示します。
The first message in any routing state maintenance operation is a Query, sent from the Querying node and intercepted at the responding node. This message has addressing and other identifiers appropriate for the flow and signalling application that state maintenance is being done for, addressing information about the node that generated the Query itself, and MAY contain an NSLP payload. It also includes a Query-Cookie, and optionally capability information about messaging association protocol stacks. The role of the cookies in this and later messages is to protect against certain denial-of-service attacks and to correlate the events in the message sequence (see Section 8.5 for further details).
ルーティング状態メンテナンス操作の最初のメッセージは、クエリノードから送信され、応答ノードでインターセプトされたクエリです。このメッセージには、クエリ自体を生成し、NSLPペイロードを含む可能性のあるノードに関する情報に対処するために、状態メンテナンスが行われているフローおよびシグナリングアプリケーションに適したアドレス指定およびその他の識別子があります。また、クエリクッキー、およびメッセージングアソシエーションプロトコルスタックに関する機能情報も含まれています。これと後のメッセージにおけるCookieの役割は、特定のサービス拒否攻撃から保護し、メッセージシーケンスのイベントを相関させることです（詳細については、セクション8.5を参照）。
+----------+ +----------+
| Querying | |Responding|
| Node(Q-N)| | Node(R-N)|
+----------+ +----------+
Query .............
----------------------> . .
Router Alert Option . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
Query-Cookie . at .
[Q-N Stack-Proposal . Responding.
Q-N Stack-Config-Data] . node .
[NSLP Payload] . (case 1) .
.............
......................................
. The responder can use an existing .
. messaging association if available .
. from here onwards to short-circuit .
. messaging association setup .
......................................
Response
............. <----------------------
. Routing . MRI/SID/NSLPID
. state . R-N Network Layer Info
. installed . Query-Cookie
. at . [Responder-Cookie
. Querying . [R-N Stack-Proposal
. node . R-N Stack-Config-Data]]
............. [NSLP Payload]
....................................
. If a messaging association needs .
. to be created, it is set up here .
. and the Confirm uses it .
....................................
Confirm .............
----------------------> . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
[Responder-Cookie . at .
[R-N Stack-Proposal . Responding.
[Q-N Stack-Config-Data]]] . node .
[NSLP Payload] . (case 2) .
.............
Figure 5: Message Sequence at State Setup
図5：状態セットアップでのメッセージシーケンス
Provided that the signalling application has indicated that message routing state should be set up (see Section 4.3.2), reception of a Query MUST elicit a Response. This is a normally encapsulated D-mode message with additional GIST payloads. It contains network layer information about the Responding node, echoes the Query-Cookie, and MAY contain an NSLP payload, possibly a reply to the NSLP payload in the initial message. In case a messaging association was requested, it MUST also contain a Responder-Cookie and its own capability information about messaging association protocol stacks. Even if a messaging association is not requested, the Response MAY still include a Responder-Cookie if the node's routing state setup policy requires it (see below).
ただし、シグナリングアプリケーションは、メッセージルーティング状態を設定する必要があることを示している場合（セクション4.3.2を参照）、クエリの受信は応答を引き出す必要があります。これは、追加のGISTペイロードを備えた通常カプセル化されたDモードメッセージです。応答ノードに関するネットワークレイヤー情報が含まれており、クエリクッキーをエコーし、NSLPペイロード、おそらく最初のメッセージのNSLPペイロードへの返信が含まれる場合があります。メッセージングアソシエーションが要求された場合は、レスポンダークッキーとメッセージングアソシエーションプロトコルスタックに関する独自の機能情報も含める必要があります。メッセージングアソシエーションが要求されていない場合でも、ノードのルーティング状態セットアップポリシーに必要な場合、応答にはレスポンダークッキーが含まれる場合があります（以下を参照）。
Setup of a new messaging association begins when peer addressing information is available and a new messaging association is actually needed. Any setup MUST take place immediately after the specific Query/Response exchange, because the addressing information used may have a limited lifetime, either because it depends on limited lifetime NAT bindings or because it refers to agile destination ports for the transport protocols. The Stack-Proposal and Stack-Configuration-Data objects carried in the exchange carry capability information about what messaging association protocols can be used, and the processing of these objects is described in more detail in Section 5.7. With the protocol options currently defined, setup of the messaging association always starts from the Querying node, although more flexible configurations are possible within the overall GIST design. If the messaging association includes a channel security protocol, each GIST node MUST verify the authenticated identity of the peer against its authorised peer database, and if there is no match the messaging association MUST be torn down. The database and authorisation check are described in more detail in Section 4.4.2 below. Note that the verification can depend on what the MA is to be used for (e.g., for which MRI or session), so this step may not be possible immediately after authentication has completed but some time later.
ピアアドレス指定情報が利用可能であり、実際に新しいメッセージング協会が必要なときに、新しいメッセージング協会のセットアップが始まります。使用されるアドレス指定情報の寿命は限られている可能性があるため、寿命が限られているか、輸送プロトコルのアジャイル宛先ポートを指すため、特定のクエリ/応答交換の直後にセットアップを行う必要があります。Exchange Carry機能に掲載されているスタックプロポザルおよびスタックコンフィグラーDATAオブジェクトは、メッセージングアソシエーションプロトコルを使用できるものに関する情報情報であり、これらのオブジェクトの処理については、セクション5.7でより詳細に説明します。現在定義されているプロトコルオプションにより、メッセージングアソシエーションのセットアップは常にクエリノードから開始されますが、全体的なGIST設計ではより柔軟な構成が可能です。メッセージングアソシエーションにチャネルセキュリティプロトコルが含まれている場合、各GISTノードは、その認可されたピアデータベースに対してピアの認証されたアイデンティティを検証する必要があり、一致していない場合は、メッセージングアソシエーションを取り壊す必要があります。データベースと承認チェックについては、以下のセクション4.4.2で詳しく説明します。検証は、MAが使用されるもの（たとえば、MRIまたはセッション）に依存する可能性があるため、認証が完了した直後にこのステップは不可能かもしれないことに注意してください。
Finally, after any necessary messaging association setup has completed, a Confirm MUST be sent if the Response requested it. Once the Confirm has been sent, the Querying node assumes that routing state has been installed at the responder, and can send normal Data messages for the flow in question; recovery from a lost Confirm is discussed in Section 5.3.3. If a messaging association is being used, the Confirm MUST be sent over it before any other messages for the same flow, and it echoes the Responder-Cookie and Stack-Proposal from the Response. The former is used to allow the receiver to validate the contents of the message (see Section 8.5), and the latter is to prevent certain bidding-down attacks on messaging association security (see Section 8.6). This first Confirm on a new association MUST also contain a Stack-Configuration-Data object carrying an MA-Hold-Time value, which supersedes the value given in the original Query. The association can be used in the upstream direction for the MRI and NSLPID carried in the Confirm, after the Confirm has been received.
最後に、必要なメッセージング協会のセットアップが完了した後、応答が要求された場合、確認を送信する必要があります。確認が送信されると、クエリノードは、ルーティング状態がレスポンダーにインストールされていると想定し、問題のフローの通常のデータメッセージを送信できます。失われた確認からの回復については、セクション5.3.3で説明します。メッセージングアソシエーションが使用されている場合、同じフローの他のメッセージの前に確認を送信する必要があり、応答からレスポンダークッキーとスタックプロポザルをエコーします。前者は、受信者がメッセージの内容を検証できるようにするために使用されます（セクション8.5を参照）。後者は、メッセージング協会のセキュリティに対する特定の入札ダウン攻撃を防ぐためです（セクション8.6を参照）。これは、新しいアソシエーションに関する最初の確認には、元のクエリで与えられた値に取って代わるMAホルドタイム値を持つスタックコンフィグラーデータオブジェクトも含める必要があります。協会は、確認が受信された後、確認書に掲載されたMRIおよびNSLPIDの上流方向に使用できます。
The Querying node MUST install the responder address, derived from the R-Node Network Layer info, as routing state information after verifying the Query-Cookie in the Response. The Responding node MAY install the querying address as peer state information at two points in time:
クエリノードは、応答のクエリクッキーを確認した後、R-Nodeネットワークレイヤー情報から派生したResponderアドレスをインストールする必要があります。応答するノードは、2つの時点でピアステート情報としてクエリアドレスをインストールする場合があります。
Case 1: after the receipt of the initial Query, or
ケース1：最初のクエリを受け取った後、または
Case 2: after a Confirm containing the Responder-Cookie.
ケース2：Responder-Cookieを含む確認の後。
The Responding node SHOULD derive the peer address from the Q-Node Network Layer Info if this was decoded successfully. Otherwise, it MAY be derived from the IP source address of the message if the common header flags this as being the signalling source address. The precise constraints on when state information is installed are a matter of security policy considerations on prevention of denial-of-service attacks and state poisoning attacks, which are discussed further in Section 8. Because the Responding node MAY choose to delay state installation as in case (2), the Confirm must contain sufficient information to allow it to be processed in the same way as the original Query. This places some special requirements on NAT traversal and cookie functionality, which are discussed in Section 7.2 and Section 8 respectively.
応答するノードは、これが正常にデコードされた場合、Qノードネットワークレイヤー情報からピアアドレスを導き出す必要があります。それ以外の場合は、共通ヘッダーがこれを信号ソースアドレスとしてフラグする場合、メッセージのIPソースアドレスから導き出される場合があります。州の情報がインストールされたときの正確な制約は、サービス拒否攻撃と状態中毒攻撃の防止に関するセキュリティポリシーの考慮事項の問題であり、セクション8でさらに議論されています。ケース（2）、確認には、元のクエリと同じ方法で処理できるように十分な情報を含める必要があります。これは、それぞれセクション7.2とセクション8で説明するNATトラバーサルおよびCookie機能に関する特別な要件をいくつか掲載しています。
When two GIST nodes authenticate using a messaging association, both ends have to decide whether to accept the creation of the MA and whether to trust the information sent over it. This can be seen as an authorisation decision:
2つのGISTノードがメッセージングアソシエーションを使用して認証する場合、両端は、MAの作成を受け入れるかどうか、およびその上に送信された情報を信頼するかどうかを決定する必要があります。これは、許可決定と見なすことができます。
o Authorised peers are trusted to install correct routing state about themselves and not, for example, to claim that they are on-path for a flow when they are not.
o 許可されたピアは、たとえば、彼らがそうでないときにフローのパスであると主張するためではなく、自分自身について正しいルーティング状態をインストールすると信頼されています。
o Authorised peers are trusted to obey transport- and application-level flow control rules, and not to attempt to create overload situations.
o 許可されたピアは、輸送およびアプリケーションレベルのフロー制御ルールに従うことが信頼されており、過負荷の状況を作成しようとしないようにします。
o Authorised peers are trusted not to send erroneous or malicious error messages, for example, asserting that routing state has been lost when it has not.
o 承認されたピアは、誤ったまたは悪意のあるエラーメッセージを送信しないと信頼されています。たとえば、ルーティング状態がそうでない場合に失われたと主張しています。
This specification models the decision as verification by the authorising node of the peer's identity against a local list of peers, the authorised peer database (APD). The APD is an abstract construct, similar to the security policy database of IPsec [36]. Implementations MAY provide the associated functionality in any way they choose. This section defines only the requirements for APD administration and the consequences of successfully validating a peer's identity against it.
この仕様は、ピアのローカルリストである承認されたピアデータベース（APD）に対して、ピアの身元の承認ノードによる検証として決定をモデル化します。APDは、IPSEC [36]のセキュリティポリシーデータベースと同様の抽象的な構造です。実装は、選択した方法で関連する機能を提供する場合があります。このセクションでは、APD投与の要件と、ピアのアイデンティティをうまく検証することの結果のみを定義します。
The APD consists of a list of entries. Each entry includes an identity, the namespace from which the identity comes (e.g., DNS domains), the scope within which the entry is applicable, and whether authorisation is allowed or denied. The following are example scopes:
APDは、エントリのリストで構成されています。各エントリには、アイデンティティ、アイデンティティが登場する名前空間（DNSドメインなど）、エントリが適用される範囲、許可が許可されるか拒否されるかどうかが含まれます。以下はスコープの例です。
Peer Address Ownership: The scope is the IP address at which the peer for this MRI should be; the APD entry denotes the identity as the owner of address. If the authorising node can determine this address from local information (such as its own routing tables), matching this entry shows that the peer is the correct on-path node and so should be authorised. The determination is simple if the peer is one IP hop downstream, since the IP address can be derived from the router's forwarding tables. If the peer is more than one hop away or is upstream, the determination is harder but may still be possible in some circumstances. The authorising node may be able to determine a (small) set of possible peer addresses, and accept that any of these could be the correct peer.
ピアアドレスの所有権：スコープは、このMRIのピアがあるはずのIPアドレスです。APDエントリは、アドレスの所有者としてのIDを示します。認定ノードがローカル情報（独自のルーティングテーブルなど）からこのアドレスを決定できる場合、このエントリを一致させると、ピアが正しいオンパスノードであるため、許可される必要があることがわかります。IPアドレスをルーターの転送テーブルから導き出すことができるため、ピアが下流の1つのIPホップである場合、決定は簡単です。ピアが複数のホップを離れているか、上流にある場合、決定はより困難ですが、状況によってはまだ可能になる可能性があります。認定ノードは、可能なピアアドレスの（小さな）セットを決定し、これらのいずれかが正しいピアである可能性があることを受け入れることができる場合があります。
End-System Subnet: The scope is an address range within which the MRI source or destination lies; the APD entry denotes the identity as potentially being on-path between the authorising node and that address range. There may be different source and destination scopes, to account for asymmetric routing.
エンドシステムサブネット：スコープは、MRIソースまたは宛先があるアドレス範囲です。APDエントリは、承認ノードとそのアドレス範囲の間のパス上の潜在的であるとアイデンティティを示します。非対称ルーティングを説明するために、異なるソースと宛先のスコープがある場合があります。
The same identity may appear in multiple entries, and the order of entries in the APD is significant. When a messaging association is authenticated and associated with an MRI, the authorising node scans the APD to find the first entry where the identity matches that presented by the peer, and where the scope information matches the circumstances for which the MA is being set up. The identity matching process itself depends on the messaging association protocol that carries out the authentication, and details for TLS are given in Section 5.7.3. Whenever the full set of possible peers for a specific scope is known, deny entries SHOULD be added for the wildcard identity to reject signalling associations from unknown nodes. The ability of the authorising node to reject inappropriate MAs depends directly on the granularity of the APD and the precision of the scope matching process.
同じアイデンティティが複数のエントリに表示される場合があり、APDのエントリの順序は重要です。メッセージングアソシエーションが認証され、MRIに関連付けられている場合、承認ノードはAPDをスキャンして、ピアが提示したアイデンティティが一致する最初のエントリを見つけ、スコープ情報がMAがセットアップされている状況と一致します。アイデンティティマッチングプロセス自体は、認証を実行するメッセージングアソシエーションプロトコルに依存し、TLSの詳細はセクション5.7.3に記載されています。特定の範囲の可能なピアの完全なセットがわかっているときはいつでも、不明なノードからシグナリング関連を拒否するために、ワイルドカードIDのために拒否エントリを追加する必要があります。不適切なMASを拒否する承認ノードの能力は、APDの粒度とスコープマッチングプロセスの精度に直接依存します。
If authorisation is allowed, the MA can be used as normal; otherwise, it MUST be torn down without further GIST exchanges, and any routing state associated with the MA MUST also be deleted. An error condition MAY be logged locally. When an APD entry is modified or deleted, the node MUST re-validate existing MAs and the routing state table against the revised contents of the APD. This may result in MAs being torn down or routing state entries being deleted. These changes SHOULD be indicated to local signalling applications via the NetworkNotification API call (Appendix B.4).
許可が許可されている場合、MAは通常どおり使用できます。それ以外の場合は、さらに要点交換せずに取り壊す必要があり、MAに関連するルーティング状態も削除する必要があります。エラー条件はローカルで記録される場合があります。APDエントリが変更または削除された場合、ノードは既存のMASとルーティング状態テーブルをAPDの改訂された内容に対して再検証する必要があります。これにより、MASが取り壊されるか、状態エントリが削除される可能性があります。これらの変更は、Network -Notification APIコール（付録B.4）を介してローカルシグナリングアプリケーションに示される必要があります。
This specification does not define how the APD is populated. As a minimum, an implementation MUST provide an administrative interface through which entries can be added, modified, or deleted. More sophisticated mechanisms are possible in some scenarios. For example, the fact that a node is legitimately associated with a specific IP address could be established by direct embedding of the IP address as a particular identity type in a certificate, or by a mapping that address to another identifier type via an additional database lookup (such as relating IP addresses in in-addr.arpa to domain names). An enterprise network operator could generate a list of all the identities of its border nodes as authorised to be on the signalling path to external destinations, and this could be distributed to all hosts inside the network. Regardless of the technique, it MUST be ensured that the source data justify the authorisation decisions listed at the start of this section, and that the security of the chain of operations on which the APD entry depends cannot be compromised.
この仕様では、APDがどのように埋め込まれているかを定義するものではありません。少なくとも、実装は、エントリを追加、変更、または削除できる管理インターフェイスを提供する必要があります。いくつかのシナリオでは、より洗練されたメカニズムが可能です。たとえば、ノードが特定のIPアドレスに合法的に関連付けられているという事実は、証明書の特定のIDタイプとしてIPアドレスを直接埋め込むこと、または追加のデータベースルックアップを介して別の識別子タイプにそのアドレスをマッピングすることによって確立できます。（In-addr.arpaのIPアドレスをドメイン名に関連付けるなど）。エンタープライズネットワークオペレーターは、外部宛先へのシグナリングパスにあることが許可されているように、境界ノードのすべてのアイデンティティのリストを生成でき、これはネットワーク内のすべてのホストに配布できます。この手法に関係なく、ソースデータがこのセクションの開始にリストされている承認決定を正当化し、APDエントリが依存する操作チェーンのセキュリティを侵害できないことを確認する必要があります。
It is a design goal of GIST that, as far as possible, a single messaging association should be used for multiple flows and sessions between two peers, rather than setting up a new MA for each. This re-use of existing MAs is referred to as messaging association multiplexing. Multiplexing ensures that the MA cost scales only with the number of peers, and avoids the latency of new MA setup where possible.
これは、可能な限り、それぞれに新しいMAをセットアップするのではなく、2つのピア間の複数のフローとセッションに単一のメッセージングアソシエーションを使用する必要があるというGISTの設計目標です。既存のMASのこの再利用は、メッセージングアソシエーションの多重化と呼ばれます。多重化により、MAはピア数のみでのみ拡大することが保証され、可能な限り新しいMAセットアップの遅延が回避されます。
However, multiplexing requires the identification of an existing MA that matches the same routing state and desired properties that would be the result of a normal handshake in D-mode, and this identification must be done as reliably and securely as continuing with a normal D-mode handshake. Note that this requirement is complicated by the fact that NATs may remap the node addresses in D-mode messages, and also interacts with the fact that some nodes may peer over multiple interfaces (and thus with different addresses).
ただし、多重化には、Dモードの通常の握手の結果となる同じルーティング状態と望ましいプロパティに一致する既存のMAの識別が必要であり、この識別は、通常のD-では確実かつ安全に継続するように確実かつ安全に行う必要があります。モードハンドシェイク。この要件は、NATがDモードメッセージでノードアドレスを再マッピングする可能性があるという事実によって複雑になり、一部のノードが複数のインターフェイス（したがって異なるアドレス）でピアリングする可能性があるという事実と相互作用することに注意してください。
MA multiplexing is controlled by the Network Layer Information (NLI) object, which is carried in Query, Response, and Confirm messages. The NLI object includes (among other elements):
MAマルチプレックスは、クエリ、応答、および確認メッセージで運ばれるネットワークレイヤー情報（NLI）オブジェクトによって制御されます。NLIオブジェクトには（他の要素の中でも）が含まれます。
Peer-Identity: For a given node, this is an interface-independent value with opaque syntax. It MUST be chosen so as to have a high probability of uniqueness across the set of all potential peers, and SHOULD be stable at least until the next node restart. Note that there is no cryptographic protection of this identity; attempting to provide this would essentially duplicate the functionality in the messaging association security protocols. For routers, the Router-ID [2], which is one of the router's IP addresses, MAY be used as one possible value for the Peer-Identity. In scenarios with nested NATs, the Router-ID alone may not satisfy the uniqueness requirements, in which case it MAY be extended with additional tokens, either chosen randomly or administratively coordinated.
ピアアイデンティティ：特定のノードの場合、これは不透明な構文を持つインターフェイスに依存しない値です。すべての潜在的なピアのセット全体で一意性の高い確率を持ち、少なくとも次のノードが再起動するまで安定するように選択する必要があります。このアイデンティティの暗号化保護はないことに注意してください。これを提供しようとすると、メッセージング協会のセキュリティプロトコルの機能が本質的に複製されます。ルーターの場合、ルーターのIPアドレスの1つであるルーター-ID [2]は、ピアアイデンティティの1つの可能な値として使用できます。ネストされたNATを使用したシナリオでは、Router-IDのみが一意性要件を満たさない場合があります。その場合、ランダムに選択されるか、管理上調整された追加のトークンで拡張できます。
Interface-Address: This is an IP address through which the signalling node can be reached. There may be several choices available for the Interface-Address, and further discussion of this is contained in Section 5.2.2.
インターフェイスアドレス：これは、信号ノードに到達できるIPアドレスです。インターフェイスアドレスにはいくつかの選択肢があり、これについてのさらなる議論はセクション5.2.2に含まれています。
A messaging association is associated with the NLI object that was provided by the peer in the Query/Response/Confirm at the time the association was first set up. There may be more than one MA for a given NLI object, for example, with different security or transport properties.
メッセージングアソシエーションは、Associationが最初に設定された時点で、ピアがクエリ/応答/確認で提供したNLIオブジェクトに関連付けられています。特定のNLIオブジェクトには、セキュリティまたは輸送のプロパティが異なるなど、複数のMAがある場合があります。
MA multiplexing is achieved by matching these two elements from the NLI provided in a new GIST message with one associated with an existing MA. The message can be either a Query or Response, although the former is more likely:
MAマルチプレックスは、既存のMAに関連付けられた新しいGISTメッセージと提供されているNLIのこれらの2つの要素を一致させることによって達成されます。メッセージはクエリまたは応答のいずれかになりますが、前者はより可能性が高くなります。
o If there is a perfect match to an existing association, that association SHOULD be re-used, provided it meets the criteria on security and transport properties given at the end of Section 5.7.1. This is indicated by sending the remaining messages in the handshake over that association. This will lead to multiplexing on an association to the wrong node if signalling nodes have colliding Peer-Identities and one is reachable at the same Interface-Address as another. This could be caused by an on-path attacker; on-path attacks are discussed further in Section 8.7. When multiplexing is done, and the original MA authorisation was MRI-dependent, the verification steps of Section 4.4.2 MUST be repeated for the new flow.
o 既存の協会に完全に一致する場合、セクション5.7.1の最後に与えられたセキュリティと輸送のプロパティに関する基準を満たしていれば、その関連付けは再利用されるべきです。これは、残りのメッセージをその協会に対して握手に送信することによって示されます。これにより、シグナリングノードが衝突したピアアイデンティティがあり、1つが別のインターフェースアドレスで到達可能な場合、間違ったノードへの関連付けの多重化につながります。これは、パス上の攻撃者によって引き起こされる可能性があります。パス攻撃については、セクション8.7でさらに説明します。多重化が行われ、元のMA許可がMRI依存性であった場合、新しいフローのためにセクション4.4.2の検証手順を繰り返す必要があります。
o In all other cases, the handshake MUST be executed in D-mode as usual. There are in fact four possibilities:
o 他のすべての場合、握手は通常どおりDモードで実行する必要があります。実際、4つの可能性があります。
1. Nothing matches: this is clearly a new peer.
1. 一致するものはありません：これは明らかに新しいピアです。
2. Only the Peer-Identity matches: this may be either a new interface on an existing peer or a changed address mapping behind a NAT. These should be rare events, so the expense of a new association setup is acceptable. Another possibility is one node using another node's Peer-Identity, for example, as some kind of attack. Because the Peer-Identity is used only for this multiplexing process, the only consequence this has is to require a new association setup, and this is considered in Section 8.4.
2. ピアアイデンティティマッチのみ：これは、既存のピア上の新しいインターフェイスまたはNATの背後にある変更されたアドレスマッピングのいずれかです。これらはまれなイベントである必要があるため、新しい協会のセットアップの費用は受け入れられます。別の可能性は、たとえば、ある種の攻撃として、別のノードのピアアイデンティティを使用する1つのノードです。ピアアイデンティティはこの多重化プロセスにのみ使用されるため、これが唯一の結果は新しい関連性のセットアップを必要とすることです。これはセクション8.4で考慮されます。
3. Only the Interface-Address matches: this is probably a new peer behind the same NAT as an existing one. A new association setup is required.
3. インターフェースアドレスのみが一致します。これは、おそらく既存のNATと同じNATの背後にある新しいピアです。新しい協会のセットアップが必要です。
4. Both elements of the NLI object match: this is a degenerate case, where one node recognises an existing peer, but wishes to allow the option to set up a new association in any case, for example, to create an association with different properties.
4. NLIオブジェクトの両方の要素は一致します。これは、1つのノードが既存のピアを認識しますが、たとえば、さまざまなプロパティとの関連付けを作成するためのオプションを設定するオプションを許可したい場合です。
Each item of routing state expires after a lifetime that is negotiated during the Query/Response/Confirm handshake. The Network Layer Information (NLI) object in the Query contains a proposal for the lifetime value, and the NLI in the Response contains the value the Responding node requires. A default timer value of 30 seconds is RECOMMENDED. Nodes that can exploit alternative, more powerful, route change detection methods such as those described in Section 7.1.2 MAY choose to use much longer times. Nodes MAY use shorter times to provide more rapid change detection. If the number of active routing state items corresponds to a rate of Queries that will stress the rate limits applied to D-mode traffic (Section 5.3.3), nodes MUST increase the timer for new items and on the refresh of existing ones. A suitable value is
ルーティング状態の各項目は、クエリ/応答/握手の確認中にネゴシエートされた生涯の後に期限切れになります。クエリのネットワークレイヤー情報（NLI）オブジェクトには、生涯値の提案が含まれており、応答のNLIには応答ノードが必要とする値が含まれています。30秒のデフォルトのタイマー値をお勧めします。セクション7.1.2で説明されているような代替のより強力なルート変更検出方法を活用できるノードは、はるかに長い時間を使用することを選択できます。ノードは、より短い時間を使用して、より迅速な変更検出を提供する場合があります。アクティブルーティング状態のアイテムの数が、Dモードトラフィック（セクション5.3.3）に適用されるレート制限を強調するクエリのレートに対応する場合、ノードは新しいアイテムのタイマーと既存のアイテムの更新時にタイマーを増やす必要があります。適切な値です
2 * (number of routing states) / (rate limit in packets/second)
2 *（ルーティング状態の数） /（パケットのレート制限 /秒）
which leaves a factor of two headroom for new routing state creation and Query retransmissions.
これにより、新しいルーティング状態の作成とクエリの再送信のために2つのヘッドルームが残ります。
The Querying node MUST ensure that a Query is received before this timer expires, if it believes that the signalling session is still active; otherwise, the Responding node MAY delete the state. Receipt of the message at the Responding node will refresh peer addressing state for one direction, and receipt of a Response at the Querying node will refresh it for the other. There is no mechanism at the GIST level for explicit teardown of routing state. However, GIST MUST NOT refresh routing state if a signalling session is known to be inactive, either because upstream state has expired or because the signalling application has indicated via the GIST API (Appendix B.5) that the state is no longer required, because this would prevent correct state repair in the case of network rerouting at the IP layer.
クエリノードは、シグナリングセッションがまだアクティブであると考えられている場合、このタイマーが期限切れになる前にクエリが受信されることを確認する必要があります。それ以外の場合、応答するノードは状態を削除する場合があります。応答ノードでのメッセージの受信は、一方の方向のピアアドレス指定状態を更新し、クエリノードでの応答の受信は他の方向にリフレッシュします。ルーティング状態の明示的な分解のための要点レベルにメカニズムはありません。ただし、上流の状態が期限切れになったため、またはシグナリングアプリケーションがGIST API（付録B.5）を介して状態が不要であることを示しているため、シグナリングセッションが非アクティブであることが知られている場合、GISTはルーティング状態を更新してはなりません。これにより、IPレイヤーでのネットワーク再ルーティングの場合、正しい状態修復が妨げられます。
This specification defines precisely only the time at which routing state expires; it does not define when refresh handshakes should be initiated. Implementations MUST select timer settings that take at least the following into account:
この仕様は、ルーティング状態が期限切れになる時間のみを正確に定義します。リフレッシュハンドシェイクを開始する時期は定義されません。実装は、少なくとも以下を考慮に入れるタイマー設定を選択する必要があります。
o the transmission latency between source and destination;
o ソースと宛先の間の送信潜時。
o the need for retransmissions of Query messages;
o クエリメッセージの再送信の必要性。
o the need to avoid network synchronisation of control traffic (cf. [42]).
o 制御トラフィックのネットワーク同期を回避する必要性（[42]を参照）。
In most cases, a reasonable policy is to initiate the routing state refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects.
ほとんどの場合、合理的なポリシーは、妥当性の1/2から3/4の間に最後のリフレッシュが成功していたときにルーティング状態の更新を開始することです。同期効果を避けるために、実際のモーメントをこの間隔内でランダムに選択する必要があります。
Unneeded MAs are torn down by GIST, using the teardown mechanisms of the underlying transport or security protocols if available, for example, by simply closing a TCP connection. The teardown can be initiated by either end. Whether an MA is needed is a combination of two factors:
たとえば、TCP接続を閉じるだけで、利用可能な場合は、基礎となる輸送またはセキュリティプロトコルの分解メカニズムを使用して、不必要なMASがGISTによって取り壊されます。分解は両端で開始できます。MAが必要かどうかは、2つの要因の組み合わせです。
o local policy, which could take into account the cost of keeping the messaging association open, the level of past activity on the association, and the likelihood of future activity, e.g., if there is routing state still in place that might generate messages to use it.
o メッセージング協会をオープンに保つコスト、協会の過去の活動のレベル、および将来の活動の可能性を考慮することができるローカルポリシー。たとえば、それを使用するメッセージを生成する可能性のあるルーティング状態がまだある場合。
o whether the peer still wants the MA to remain in place. During MA setup, as part of the Stack-Configuration-Data, each node advertises its own MA-Hold-Time, i.e., the time for which it will retain an MA that is not carrying signalling traffic. A node MUST NOT tear down an MA if it has received traffic from its peer over that period. A peer that has generated no traffic but still wants the MA retained can use a special null message (MA-Hello) to indicate the fact. A default value for MA-Hold-Time of 30 seconds is RECOMMENDED. Nodes MAY use shorter times to achieve more rapid peer failure detection, but need to take into account the load on the network created by the MA-Hello messages. Nodes MAY use longer times, but need to take into account the cost of retaining idle MAs for extended periods. Nodes MAY take signalling application behaviour (e.g., NSLP refresh times) into account in choosing an appropriate value.
o ピアがまだMAを所定の位置にとどめることを望んでいるかどうか。MAセットアップ中、Stack-Configuration-Dataの一部として、各ノードは独自のMAホールドタイム、つまり、シグナリングトラフィックを運ばないMAを保持する時間を宣伝します。ノードは、その期間にピアからトラフィックを受け取った場合、MAを取り壊してはなりません。トラフィックを生成していないが、まだMA保持を望んでいるピアは、特別なヌルメッセージ（MA-Hello）を使用して事実を示すことができます。30秒のMAホルドタイムのデフォルト値をお勧めします。ノードはより短い時間を使用してより迅速なピア障害検出を実現する場合がありますが、MA-Helloメッセージによって作成されたネットワーク上の負荷を考慮する必要があります。ノードはより長い時間を使用する場合がありますが、長期間にわたってアイドルMASを保持するコストを考慮する必要があります。ノードは、適切な値を選択する際に、シグナリングアプリケーションの動作（NSLP更新時間など）を考慮に入れることができます。
Because the Responding node can choose not to create state until a Confirm, an abbreviated Stack-Configuration-Data object containing just this information from the initial Query MUST be repeated by the Querying node in the first Confirm sent on a new MA. If the object is missing in the Confirm, an "Object Type Error" message (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be returned.
応答するノードは、確認が確認されるまで状態を作成しないことを選択できるため、初期クエリからこの情報のみを含む略式されたスタックコンフィグラーデータオブジェクトは、新しいMAで送信された最初の確認のクエリノードによって繰り返される必要があります。確認書にオブジェクトが欠落している場合、サブコード2（「欠落オブジェクト」）を備えた「オブジェクトタイプエラー」メッセージ（付録A.4.4.9）を返す必要があります。
Messaging associations can always be set up on demand, and messaging association status is not made directly visible outside the GIST layer. Therefore, even if GIST tears down and later re-establishes a messaging association, signalling applications cannot distinguish this from the case where the MA is kept permanently open. To maintain the transport semantics described in Section 4.1, GIST MUST close transport connections carrying reliable messages gracefully or report an error condition, and MUST NOT open a new association to be used for given session and peer while messages on a previous association could still be outstanding. GIST MAY use an MA-Hello request/reply exchange on an existing association to verify that messages sent on it have reached the peer. GIST MAY use the same technique to test the liveness of the underlying MA protocols themselves at arbitrary times.
メッセージングアソシエーションは常にオンデマンドでセットアップでき、メッセージングアソシエーションのステータスは、GISTレイヤーの外に直接表示されません。したがって、GISTが破裂し、後にメッセージングアソシエーションを再確立したとしても、シグナリングアプリケーションは、MAが永久に開いている場合とこれを区別することはできません。セクション4.1で説明されている輸送セマンティクスを維持するには、GISTは信頼できるメッセージを優雅に運ぶトランスポート接続を閉鎖するか、エラー条件を報告する必要があります。。GISTは、既存の協会でMA-Helloリクエスト/返信交換を使用して、それに送信されたメッセージがピアに届いたことを確認することができます。GISTは、同じ手法を使用して、任意の時代に基礎となるMAプロトコル自体の活性をテストする場合があります。
This specification defines precisely only the time at which messaging associations expire; it does not define when keepalives should be initiated. Implementations MUST select timer settings that take at least the following into account:
この仕様は、メッセージング関連の期限が切れる時間のみを正確に定義します。キープライブをいつ開始するかを定義しません。実装は、少なくとも以下を考慮に入れるタイマー設定を選択する必要があります。
o the transmission latency between source and destination;
o ソースと宛先の間の送信潜時。
o the need for retransmissions within the messaging association protocols;
o メッセージング協会プロトコル内の再送信の必要性。
o the need to avoid network synchronisation of control traffic (cf. [42]).
o 制御トラフィックのネットワーク同期を回避する必要性（[42]を参照）。
In most cases, a reasonable policy is to initiate the MA refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects.
ほとんどの場合、合理的なポリシーは、妥当性の1/2から3/4の間に最後のリフレッシュが成功してから経過したときにMAの更新を開始することです。同期効果を避けるために、実際のモーメントをこの間隔内でランダムに選択する必要があります。
A GIST node can receive a message from a GIST peer that can only be correctly processed in the context of some routing state, but where no corresponding routing state exists. Cases where this can arise include:
GISTノードは、いくつかのルーティング状態のコンテキストでしか正しく処理できないが、対応するルーティング状態が存在しない場合、GISTピアからメッセージを受信できます。これが発生する可能性のあるケースは次のとおりです。
o Where the message is random traffic from an attacker, or backscatter (replies to such traffic).
o メッセージが攻撃者からのランダムトラフィック、または後方散乱（そのようなトラフィックへの返信）です。
o Where routing state has been correctly installed but the peer has since lost it, for example, because of aggressive timeout settings at the peer or because the node has crashed and restarted.
o ルーティング状態が正しくインストールされていますが、たとえばピアでの積極的なタイムアウト設定やノードがクラッシュして再起動したため、ピアはそれを失いました。
o Where the routing state was not correctly installed in the first place, but the sending node does not know this. This can happen if the Confirm message of the handshake is lost.
o ルーティング状態がそもそも正しくインストールされていませんが、送信ノードはこれを知りません。これは、握手の確認メッセージが失われた場合に発生する可能性があります。
It is important for GIST to recover from such situations promptly where they represent genuine errors (node restarts, or lost messages that would not otherwise be retransmitted). Note that only Response, Confirm, Data, and Error messages ever require routing state to exist, and these are considered in turn:
GISTが本物のエラーを表すような状況から迅速に回復することが重要です（ノードの再起動、または他の方法では再送信されないメッセージの紛失）。応答、確認、データ、およびエラーメッセージのみがルーティング状態を存在させる必要があることに注意してください。これらは順番に考慮されます。
Response: A Response can be received at a node that never sent (or has forgotten) the corresponding Query. If the node wants routing state to exist, it will initiate it itself; a diagnostic error would not allow the sender of the Response to take any corrective action, and the diagnostic could itself be a form of backscatter. Therefore, an error message MUST NOT be generated, but the condition MAY be logged locally.
応答：応答は、対応するクエリを送信（または忘れた）ノードで受信できます。ノードがルーティング状態を存在させたい場合、それ自体を開始します。診断エラーでは、応答の送信者が是正措置を講じることができず、診断自体が後方散乱の一形態になる可能性があります。したがって、エラーメッセージを生成する必要はありませんが、条件をローカルで記録する場合があります。
Confirm: For a Responding node that implements delayed state installation, this is normal behaviour, and routing state will be created provided the Confirm is validated. Otherwise, this is a case of a non-existent or forgotten Response, and the node may not have sufficient information in the Confirm to create the correct state. The requirement is to notify the Querying node so that it can recover the routing state.
確認：遅延状態の設置を実装する応答ノードの場合、これは通常の動作であり、確認状態が確認されている場合、ルーティング状態が作成されます。それ以外の場合、これは存在しないまたは忘れられた応答の場合であり、ノードは確認に十分な情報がない場合があります。要件は、ルーティング状態を回復できるようにクエリノードに通知することです。
Data: This arises when a node receives Data where routing state is required, but either it does not exist at all or it has not been finalised (no Confirm message). To avoid Data being black-holed, a notification must be sent to the peer.
データ：これは、ノードがルーティング状態が必要なデータを受信したときに発生しますが、まったく存在しないか、完成していません（メッセージはありません）。データがブラックホールされないようにするには、通知をピアに送信する必要があります。
Error: Some error messages can only be interpreted in the context of routing state. However, the only error messages that require a reply within the protocol are routing state error messages themselves. Therefore, this case should be treated the same as a Response: an error message MUST NOT be generated, but the condition MAY be logged locally.
エラー：一部のエラーメッセージは、ルーティング状態のコンテキストでのみ解釈できます。ただし、プロトコル内で返信を必要とする唯一のエラーメッセージは、状態エラーメッセージ自体をルーティングすることです。したがって、このケースは応答と同じように扱う必要があります。エラーメッセージを生成する必要はありませんが、条件はローカルで記録する場合があります。
For the case of Confirm or Data messages, if the state is required but does not exist, the node MUST reject the incoming message with a "No Routing State" error message (Appendix A.4.4.5). There are then three cases at the receiver of the error message:
確認メッセージまたはデータメッセージの場合、状態が必要であるが存在しない場合、ノードは「ルーティング状態なし」エラーメッセージで着信メッセージを拒否する必要があります（付録A.4.4.5）。次に、エラーメッセージの受信者に3つのケースがあります。
No routing state: The condition MAY be logged but a reply MUST NOT be sent (see above).
ルーティング状態はありません：条件を記録することもできますが、返信を送信してはなりません（上記参照）。
Querying node: The node MUST restart the GIST handshake from the beginning, with a new Query.
ノードのクエリ：ノードは、新しいクエリを使用して、最初からGISTハンドシェイクを再起動する必要があります。
Responding node: The node MUST delete its own routing state and SHOULD report an error condition to the local signalling application.
応答ノード：ノードは独自のルーティング状態を削除する必要があり、ローカルシグナリングアプリケーションにエラー条件を報告する必要があります。
The rules at the Querying or Responding node make GIST open to disruption by randomly injected error messages, similar to blind reset attacks on TCP (cf. [46]), although because routing state matching includes the SID this is mainly limited to on-path attackers. If a GIST node detects a significant rate of such attacks, it MAY adopt a policy of using secured messaging associations to communicate for the affected MRIs, and only accepting "No Routing State" error messages over such associations.
クエリまたは応答するノードのルールは、TCPに対するブラインドリセット攻撃と同様に、ランダムに注入されたエラーメッセージによる破壊に対してGISTを開いています（[46]を参照）。攻撃者。GISTノードがそのような攻撃のかなりのレートを検出した場合、影響を受けるMRIのために安全なメッセージング協会を使用して、そのような関連性に対する「ルーティング状態なし」エラーメッセージのみを受け入れるというポリシーを採用する可能性があります。
All GIST messages begin with a common header, followed by a sequence of type-length-value (TLV) objects. This subsection describes the various GIST messages and their contents at a high level in ABNF [11]; a more detailed description of the header and each object is given in Section 5.2 and bit formats in Appendix A. Note that the NAT traversal mechanism for GIST involves the insertion of an additional NAT-Traversal-Object in Query, Response, and some Data and Error messages; the rules for this are given in Section 7.2.
すべてのGISTメッセージは、共通のヘッダーで始まり、その後にタイプ長価値（TLV）オブジェクトのシーケンスが続きます。このサブセクションでは、ABNF [11]の高レベルでのさまざまな要点メッセージとその内容について説明しています。ヘッダーと各オブジェクトのより詳細な説明は、付録Aのセクション5.2およびビット形式に記載されています。GISTのNATトラバーサルメカニズムには、クエリ、応答、および一部のデータといくつかのデータおよびいくつかのデータおよびいくつかのデータおよびいくつかのデータと追加のNATトラバーサルオブジェクトの挿入が含まれることに注意してください。エラーメッセージ;これの規則は、セクション7.2に記載されています。
GIST-Message: The primary messages are either part of the three-way handshake or a simple message carrying NSLP data. Additional types are defined for errors and keeping messaging associations alive.
要点：主要なメッセージは、3方向の握手の一部またはNSLPデータを運ぶ単純なメッセージの一部です。エラーとメッセージングアソシエーションを生かし続けるために、追加のタイプが定義されています。
GIST-Message = Query / Response / Confirm /
Data / Error / MA-Hello
The common header includes a version number, message type and size, and NSLPID. It also carries a hop count to prevent infinite message looping and various control flags, including one (the R-flag) to indicate if a reply of some sort is requested. The objects following the common header MUST be carried in a fixed order, depending on message type. Messages with missing, duplicate, or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9). Note that unknown objects indicate explicitly how they should be treated and are not covered by the above statement.
一般的なヘッダーには、バージョン番号、メッセージの種類とサイズ、およびNSLPIDが含まれます。また、無限のメッセージループやさまざまな制御フラグを防ぐためのホップカウントがあります。一般的なヘッダーに続くオブジェクトは、メッセージタイプに応じて、固定順序で運ばれる必要があります。メッセージタイプの欠落、重複、または無効なオブジェクトを備えたメッセージは、適切なサブコード（付録A.4.4.9）を使用した「オブジェクトタイプエラー」メッセージで拒否する必要があります。未知のオブジェクトは、それらをどのように扱うべきかを明示的に示しており、上記のステートメントでカバーされていないことに注意してください。
Query: A Query MUST be sent in D-mode using the special Q-mode encapsulation. In addition to the common header, it contains certain mandatory control objects, and MAY contain a signalling application payload. A stack proposal and configuration data MUST be included if the message exchange relates to setup of a messaging association, and this is the case even if the Query is intended only for refresh (since a routing change might have taken place in the meantime). The R-flag MUST always be set (R=1) in a Query, since this message always elicits a Response.
クエリ：特別なQモードカプセル化を使用して、クエリをDモードで送信する必要があります。一般的なヘッダーに加えて、特定の必須制御オブジェクトが含まれており、シグナリングアプリケーションのペイロードが含まれる場合があります。メッセージ交換がメッセージングアソシエーションのセットアップに関連する場合、スタックの提案と構成データを含める必要があります。これは、クエリが更新のみを目的としていても（その間にルーティングの変更が行われた可能性があるため）。このメッセージは常に応答を誘発するため、r-flagは常にクエリで設定する必要があります（r = 1）。
Query = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identifier
Network-Layer-Information
Query-Cookie
[ Stack-Proposal Stack-Configuration-Data ]
[ NSLP-Data ]
Response: A Response MUST be sent in D-mode if no existing messaging association can be re-used. If one is being re-used, the Response MUST be sent in C-mode. It MUST echo the MRI, SID, and Query-Cookie of the Query, and carries its own Network-Layer-Information. If the message exchange relates to setup of a new messaging association, which MUST involve a D-mode Response, a Responder-Cookie MUST be included, as well as the Responder's own stack proposal and configuration data. The R-flag MUST be set (R=1) if a Responder-Cookie is present but otherwise is optional; if the R-flag is set, a Confirm MUST be sent as a reply. Therefore, in particular, a Confirm will always be required if a new MA is being set up. Note that the direction of this MRI will be inverted compared to that in the Query, that is, an upstream MRI becomes downstream and vice versa (see Section 3.3).
応答：既存のメッセージングアソシエーションを再利用できない場合、応答をDモードで送信する必要があります。再利用されている場合、応答はCモードで送信する必要があります。クエリのMRI、SID、およびクエリクッキーをエコーし、独自のネットワーク層情報を搭載する必要があります。メッセージ交換がDモード応答を含む新しいメッセージング協会のセットアップに関連している場合、レスポンダークッキーを含める必要があります。Responder-Cookieが存在するが、それ以外の場合はオプションである場合、R-Flagを設定する必要があります（r = 1）。r-flagが設定されている場合、確認として確認する必要があります。したがって、特に、新しいMAがセットアップされている場合は、常に確認が必要になります。このMRIの方向は、クエリの方向と比較して反転することに注意してください。つまり、上流のMRIが下流になり、逆も同様です（セクション3.3を参照）。
Response = Common-Header
[ NAT-Traversal-Object ]
Message-Routing-Information
Session-Identifier
Network-Layer-Information
Query-Cookie
[ Responder-Cookie
[ Stack-Proposal Stack-Configuration-Data ] ]
[ NSLP-Data ]
Confirm: A Confirm MUST be sent in C-mode if a messaging association is being used for this routing state, and MUST be sent before other messages for this routing state if an association is being set up. If no messaging association is being used, the Confirm MUST be sent in D-mode. The Confirm MUST include the MRI (with inverted direction) and SID, and echo the Responder-Cookie if the Response carried one. In C-mode, the Confirm MUST also echo the Stack-Proposal from the Response (if present) so it can be verified that this has not been tampered with. The first Confirm on a new association MUST also repeat the Stack-Configuration-Data from the original Query in an abbreviated form, just containing the MA-Hold-Time.
確認：このルーティング状態でメッセージングアソシエーションが使用されている場合は、Cモードで確認を送信する必要があり、アソシエーションが設定されている場合は、このルーティング状態の他のメッセージの前に送信する必要があります。メッセージングアソシエーションが使用されていない場合は、dモードで確認を送信する必要があります。確認には、MRI（反転方向）とSIDを含め、応答が掲載された場合は応答者クッキーをエコーする必要があります。Cモードでは、確認は、スタックプロポザルを応答（存在する場合）からエコーする必要があるため、これが改ざんされていないことを確認できます。新しい関連付けの最初の確認は、MAホールドタイムを含むだけで、元のクエリからStack-Configuration-Dataを元のクエリから繰り返す必要があります。
Confirm = Common-Header
Message-Routing-Information
Session-Identifier
Network-Layer-Information
[ Responder-Cookie
[ Stack-Proposal
[ Stack-Configuration-Data ] ] ]
[ NSLP-Data ]
Data: The Data message is used to transport NSLP data without modifying GIST state. It contains no control objects, but only the MRI and SID associated with the NSLP data being transferred. Network-Layer-Information (NLI) MUST be carried in the D-mode case, but MUST NOT be included otherwise.
データ：データメッセージは、GIST状態を変更せずにNSLPデータの輸送に使用されます。制御オブジェクトは含まれていませんが、転送されるNSLPデータに関連付けられたMRIとSIDのみが含まれています。ネットワーク層情報（NLI）は、Dモードの場合に携帯する必要がありますが、別の方法では含めてはなりません。
Data = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identifier [ Network-Layer-Information ] NSLP-Data
data = common-header [nat-traversal-object] message-routing-information session-identifier [network-layer-information] nslp-data
Error: An Error message reports a problem determined at the GIST level. (Errors generated by signalling applications are reported in NSLP-Data payloads and are not treated specially by GIST.) If the message is being sent in D-mode, the originator of the error message MUST include its own Network-Layer-Information object. All other information related to the error is carried in a GIST-Error-Data object.
エラー：エラーメッセージは、GISTレベルで決定された問題を報告します。（シグナリングアプリケーションによって生成されるエラーは、NSLP-DATAペイロードで報告され、GISTで特別に扱われません。）メッセージがDモードで送信されている場合、エラーメッセージの発信元には独自のネットワーク層情報オブジェクトを含める必要があります。エラーに関連する他のすべての情報は、Gist-Error-Dataオブジェクトで伝えられます。
Error = Common-Header [ NAT-Traversal-Object ] [ Network-Layer-Information ] GIST-Error-Data
エラー= Common-Header [NAT-Traversal-Object] [Network-Layer-Information] Gist-Error-Data
MA-Hello: This message MUST be sent only in C-mode. It contains the common header, with a NSLPID of zero, and a message identifier, the Hello-ID. It always indicates that a node wishes to keep a messaging association open, and if sent with R=0 and zero Hello-ID this is its only function. A node MAY also invoke a diagnostic request/reply exchange by setting R=1 and providing a non-zero Hello-ID; in this case, the peer MUST send another MA-Hello back along the messaging association echoing the same Hello-ID and with R=0. Use of this diagnostic is entirely at the discretion of the initiating node.
MA-Hello：このメッセージはCモードでのみ送信する必要があります。ゼロのNSLPIDを備えた共通ヘッダーとメッセージ識別子、Hello-IDが含まれています。それは常に、ノードがメッセージングアソシエーションを開いたままにしたいことを常に示しており、r = 0およびゼロのhello-idで送信された場合、これはその唯一の関数です。ノードは、r = 1を設定し、ゼロ以外のhello-idを提供することにより、診断要求/返信交換を呼び出すこともあります。この場合、ピアは、同じHello-IDとr = 0を使用して、メッセージング協会に沿って別のMA-Helloを返送する必要があります。この診断の使用は、完全に開始ノードの裁量にあります。
MA-Hello = Common-Header Hello-ID
ma-hello = Common-Header Hello-Id
This section describes the content of the various objects that can be present in each GIST message, both the common header and the individual TLVs. The bit formats are provided in Appendix A.
このセクションでは、共通ヘッダーと個々のTLVの両方で、各GISTメッセージに存在できるさまざまなオブジェクトの内容について説明します。ビット形式は付録Aに記載されています。
Each message begins with a fixed format common header, which contains the following information:
各メッセージは、次の情報を含む固定形式の共通ヘッダーから始まります。
Version: The version number of the GIST protocol. This specification defines GIST version 1.
バージョン：GISTプロトコルのバージョン番号。この仕様では、GISTバージョン1を定義します。
GIST hop count: A hop count to prevent a message from looping indefinitely.
Gist Hopカウント：メッセージが無期限にループするのを防ぐためのホップカウント。
Length: The number of 32-bit words in the message following the common header.
長さ：一般的なヘッダーに続くメッセージ内の32ビット語の数。
Upper layer identifier (NSLPID): This gives the specific NSLP for which this message is used.
上層識別子（NSLPID）：これにより、このメッセージが使用される特定のNSLPが得られます。
Context-free flag: This flag is set (C=1) if the receiver has to be able to process the message without supporting routing state. The C-flag MUST be set for Query messages, and also for Data messages sent in Q-mode. The C-flag is important for NAT traversal processing.
コンテキストフリーフラグ：レシーバーがルーティング状態をサポートせずにメッセージを処理できる必要がある場合、このフラグは設定されています（c = 1）。c-flagは、クエリメッセージ、およびqモードで送信されたデータメッセージにも設定する必要があります。C-FLAGは、NATトラバーサル処理にとって重要です。
Message type: The message type (Query, Response, etc.).
メッセージタイプ：メッセージタイプ（クエリ、応答など）。
Source addressing mode: If set (S=1), this indicates that the IP source address of the message is the same as the IP address of the signalling peer, so replies to this message can be sent safely to this address. S is always set in C-mode. It is cleared (S=0) if the IP source address was derived from the message routing information in the payload and this is different from the signalling source address.
ソースアドレス指定モード：SET（S = 1）の場合、メッセージのIPソースアドレスが信号ピアのIPアドレスと同じであることを示します。したがって、このメッセージへの返信はこのアドレスに安全に送信できます。Sは常にCモードで設定されます。IPソースアドレスがペイロード内のメッセージルーティング情報から派生した場合、これはクリアされます（S = 0）。これは、信号ソースアドレスとは異なります。
Response requested: A flag that if set (R=1) indicates that a GIST message should be sent in reply to this message. The appropriate message type for the reply depends on the type of the initial message.
応答要求：セット（r = 1）がこのメッセージへの返信でGISTメッセージを送信する必要があることを示すフラグ。返信の適切なメッセージタイプは、最初のメッセージのタイプによって異なります。
Explicit routing: A flag that if set (E=1) indicates that the message was explicitly routed (see Section 7.1.5).
明示的なルーティング：set（e = 1）がメッセージが明示的にルーティングされたことを示すフラグ（セクション7.1.5を参照）。
Note that in D-mode, Section 5.3, there is a 32-bit magic number before the header. However, this is regarded as part of the encapsulation rather than part of the message itself.
セクション5.3のDモードでは、ヘッダーの前に32ビットのマジック番号があることに注意してください。ただし、これはメッセージ自体の一部ではなく、カプセル化の一部と見なされます。
All data following the common header is encoded as a sequence of type-length-value objects. Currently, each object can occur at most once; the set of required and permitted objects is determined by the message type and encapsulation (D-mode or C-mode).
共通ヘッダーに続くすべてのデータは、タイプ長価値オブジェクトのシーケンスとしてエンコードされます。現在、各オブジェクトはせいぜい1回発生することができます。必要なオブジェクトのセットは、メッセージタイプとカプセル化（DモードまたはCモード）によって決定されます。
Message-Routing-Information (MRI): Information sufficient to define how the signalling message should be routed through the network.
メッセージルーティング情報（MRI）：信号メッセージをネットワークを介してルーティングする方法を定義するのに十分な情報。
Message-Routing-Information = message-routing-method method-specific-information
Message-routing-information = message-routing-methodメソッド固有の情報
The format of the method-specific-information depends on the message-routing-method requested by the signalling application. Note that it always includes a flag defining the direction as either 'upstream' or 'downstream' (see Section 3.3). It is provided by the NSLP in the message sender and used by GIST to select the message routing.
メソッド固有の情報の形式は、シグナリングアプリケーションによって要求されたメッセージルーティングメソッドに依存します。「上流」または「下流」のいずれかとして方向を定義するフラグが常に含まれていることに注意してください（セクション3.3を参照）。これは、メッセージ送信者のNSLPによって提供され、GISTがメッセージルーティングを選択するために使用されます。
Session-Identifier (SID): The GIST session identifier is a 128-bit, cryptographically random identifier chosen by the node that originates the signalling exchange. See Section 3.7.
SESSION-IDENTIFIER（SID）：GISTセッション識別子は、信号交換を発信するノードによって選択された128ビットの暗号化されたランダム識別子です。セクション3.7を参照してください。
Network-Layer-Information (NLI): This object carries information about the network layer attributes of the node sending the message, including data related to the management of routing state. This includes a peer identity and IP address for the sending node. It also includes IP-TTL information to allow the IP hop count between GIST peers to be measured and reported, and a validity time (RS-validity-time) for the routing state.
ネットワークレイヤー情報（NLI）：このオブジェクトは、ルーティング状態の管理に関連するデータを含む、メッセージを送信するノードのネットワークレイヤー属性に関する情報を伝達します。これには、送信ノードのピアアイデンティティとIPアドレスが含まれます。また、GISTピア間のIPホップ数を測定および報告できるようにするIP-TTL情報、およびルーティング状態の有効時間（RS有効性時間）も含まれています。
Network-Layer-Information = peer-identity interface-address RS-validity-time IP-TTL
ネットワークレイヤーインフォメーション=ピアアイデンティティインターフェイスアドレスRS-validity-Time IP-TTL
The use of the RS-validity-time field is described in Section 4.4.4. The peer-identity and interface-address are used for matching existing associations, as discussed in Section 4.4.3.
RS有効性時間フィールドの使用については、セクション4.4.4で説明しています。セクション4.4.3で説明したように、ピアアイデンティティとインターフェイスアドレスは、既存の関連付けの一致に使用されます。
The interface-address must be routable, i.e., it MUST be usable as a destination IP address for packets to be sent back to the node generating the signalling message, whether in D-mode or C-mode. If this object is carried in a message with the source addressing mode flag S=1, the interface-address MUST match the source address used in the IP encapsulation, to assist in legacy NAT detection (Section 7.2.1). If this object is carried in a Query or Confirm, the interface-address MUST specifically be set to an address bound to an interface associated with the MRI, to allow its use in route change handling as discussed in Section 7.1. A suitable choice is the interface that is carrying the outbound flow. A node may have several choices for which of its addresses to use as the interface-address. For example, there may be a choice of IP versions, or addresses of limited scope (e.g., link-local), or addresses bound to different interfaces in the case of a router or multihomed host. However, some of these interface addresses may not be usable by the peer. A node MUST follow a policy of using a global address of the same IP version as in the MRI, unless it can establish that an alternative address would also be usable.
インターフェイスアドレスはルーティング可能でなければなりません。つまり、パケットがノードに送信されるための宛先IPアドレスとして使用可能である必要があります。このオブジェクトがソースアドレス指定モードフラグs = 1を含むメッセージに送られている場合、インターフェイスアドレスは、Legacy NAT検出を支援するために、IPカプセル化で使用されるソースアドレスと一致する必要があります（セクション7.2.1）。このオブジェクトがクエリまたは確認で運ばれる場合、インターフェイスアドレスは、セクション7.1で説明されているように、ルート変更処理での使用を可能にするために、MRIに関連付けられたインターフェイスにバインドされたアドレスに特に設定する必要があります。適切な選択は、アウトバウンドフローを運ぶインターフェイスです。ノードには、インターフェイスアドレスとして使用するアドレスのいくつかの選択肢がある場合があります。たとえば、IPバージョンの選択、または限られたスコープ（リンクローカルなど）のアドレス、またはルーターまたはマルチホームホストの場合、異なるインターフェイスにバインドされたアドレスがある場合があります。ただし、これらのインターフェイスアドレスの一部は、ピアが使用できない場合があります。ノードは、代替アドレスも使用可能であることを確認できない限り、MRIと同じIPバージョンのグローバルアドレスを使用するポリシーに従う必要があります。
The setting and interpretation of the IP-TTL field depends on the message direction (upstream/downstream as determined from the MRI as described above) and encapsulation.
IP-TTLフィールドの設定と解釈は、メッセージ方向（上記のMRIから決定された上流/下流）およびカプセル化に依存します。
* If the message is sent downstream, if the TTL that will be set in the IP header for the message can be determined, the IP-TTL value MUST be set to this value, or else set to 0.
* メッセージが下流に送信される場合、メッセージのIPヘッダーで設定されるTTLを決定できる場合、IP-TTL値をこの値に設定するか、その場合は0に設定する必要があります。
* On receiving a downstream message in D-mode, a non-zero IP-TTL is compared to the TTL in the IP header, and the difference is stored as the IP-hop-count-to-peer for the upstream peer in the routing state table for that flow. Otherwise, the field is ignored.
* Dモードでダウンストリームメッセージを受信すると、非ゼロIP-TTLがIPヘッダーのTTLと比較され、その差はルーティングの上流のピアのIP-Hop-Count-to-Peerとして保存されますそのフローの状態テーブル。それ以外の場合、フィールドは無視されます。
* If the message is sent upstream, the IP-TTL MUST be set to the value of the IP-hop-count-to-peer stored in the routing state table, or 0 if there is no value yet stored.
* メッセージが上流に送信される場合、IP-TTLは、ルーティング状態テーブルに保存されているIP-Hop-Count-to-Peerの値に設定する必要があります。
* On receiving an upstream message, the IP-TTL is stored as the IP-hop-count-to-peer for the downstream peer.
* 上流のメッセージを受信すると、IP-TTLは下流のピアのIP-Hop-Count-to-Peerとして保存されます。
In all cases, the IP-TTL value reported to signalling applications is the one stored with the routing state for that flow, after it has been updated if necessary from processing the message in question.
すべての場合において、シグナリングアプリケーションに報告されたIP-TTL値は、問題のメッセージの処理から必要に応じて更新された後、そのフローのルーティング状態に保存されているものです。
Stack-Proposal: This field contains information about which combinations of transport and security protocols are available for use in messaging associations, and is also discussed further in Section 5.7.
Stack-Proposal：このフィールドには、メッセージングアソシエーションで使用できる輸送プロトコルとセキュリティプロトコルの組み合わせに関する情報が含まれており、セクション5.7でさらに説明します。
Stack-Proposal = 1*stack-profile
stack-profile = protocol-count 1*protocol-layer
;; padded on the right with 0 to 32-bit boundary
protocol-count = %x01-FF
;; number of the following <protocol-layer>,
;; represented as one byte. This doesn't include
;; padding.
protocol-layer = %x01-FF
Each protocol-layer field identifies a protocol with a unique tag; any additional data, such as higher-layer addressing or other options data associated with the protocol, will be carried in an MA-protocol-options field in the Stack-Configuration-Data TLV (see below).
各プロトコル層フィールドは、一意のタグでプロトコルを識別します。プロトコルに関連付けられた高層化アドレス指定やその他のオプションデータなどの追加データは、Stack-Configuration-Data TLVのMAプロトコルオプションフィールドで運ばれます（以下を参照）。
Stack-Configuration-Data (SCD): This object carries information about the overall configuration of a messaging association.
Stack-Configuration-Data（SCD）：このオブジェクトには、メッセージングアソシエーションの全体的な構成に関する情報が含まれています。
Stack-Configuration-Data = MA-Hold-Time 0*MA-protocol-options
stack-configuration-data = ma-hold-time 0*ma-protocol-options
The MA-Hold-Time field indicates how long a node will hold open an inactive association; see Section 4.4.5 for more discussion. The MA-protocol-options fields give the configuration of the protocols (e.g., TCP, TLS) to be used for new messaging associations, and they are described in more detail in Section 5.7.
ma-hold-timeフィールドは、ノードが非アクティブな関連付けを開く時間を示します。詳細については、セクション4.4.5を参照してください。MA-Protocol-Optionsフィールドは、新しいメッセージング協会に使用されるプロトコル（TCP、TLSなど）の構成を提供し、セクション5.7で詳細に説明します。
Query-Cookie/Responder-Cookie: A Query-Cookie is contained in a Query and MUST be echoed in a Response; a Responder-Cookie MAY be sent in a Response, and if present MUST be echoed in the following Confirm. Cookies are variable-length bit strings, chosen by the cookie generator. See Section 8.5 for further details on requirements and mechanisms for cookie generation.
Query-Cookie/Responder-Cookie：クエリクッキーはクエリに含まれており、応答にエコーする必要があります。レスポンダークッキーを応答して送信することができ、存在する場合は次の確認に反映する必要があります。Cookieは、Cookieジェネレーターによって選択された、さまざまな長さのビット文字列です。Cookie生成の要件とメカニズムの詳細については、セクション8.5を参照してください。
Hello-ID: The Hello-ID is a 32-bit quantity that is used to correlate messages in an MA-Hello request/reply exchange. A non-zero value MUST be used in a request (messages sent with R=1) and the same value must be returned in the reply (which has R=0). The value zero MUST be used for all other messages; if a message is received with R=1 and Hello-ID=0, an "Object Value Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be returned and the message dropped. Nodes MAY use any algorithm to generate the Hello-ID; a suitable approach is a local sequence number with a random starting point.
hello-id：hello-idは、ma-helloリクエスト/返信交換のメッセージを相関させるために使用される32ビットの数量です。ゼロ以外の値は、リクエスト（r = 1で送信されたメッセージ）で使用する必要があり、応答で同じ値を返す必要があります（r = 0）。値ゼロは、他のすべてのメッセージに使用する必要があります。r = 1およびhello-id = 0でメッセージを受信した場合、サブコード1（「値はサポートされていない」）を備えた「オブジェクト値エラー」メッセージ（付録A.4.4.10）を返し、メッセージを削除する必要があります。ノードは、任意のアルゴリズムを使用してHello-IDを生成する場合があります。適切なアプローチは、ランダム開始点を持つローカルシーケンス番号です。
NSLP-Data: The NSLP payload to be delivered to the signalling application. GIST does not interpret the payload content.
NSLP-DATA：シグナリングアプリケーションに配信されるNSLPペイロード。GISTはペイロードコンテンツを解釈しません。
GIST-Error-Data: This contains the information to report the cause and context of an error.
Gist-Error-Data：これには、エラーの原因とコンテキストを報告する情報が含まれています。
GIST-Error-Data = error-class error-code error-subcode
common-error-header
[ Message-Routing-Information-content ]
[ Session-Identification-content ]
0*additional-information
[ comment ]
The error-class indicates the severity level, and the error-code and error-subcode identify the specific error itself. A full list of GIST errors and their severity levels is given in Appendix A.4. The common-error-header carries the Common-Header from the original message, and contents of the Message-Routing-Information (MRI) and Session-Identifier (SID) objects are also included if they were successfully decoded. For some errors, additional information fields can be included, and these fields themselves have a simple TLV format. Finally, an optional free-text comment may be added.
エラークラスは重大度レベルを示し、エラーコードとエラーサブコードは特定のエラー自体を識別します。GISTエラーの完全なリストとそれらの重症度レベルは、付録A.4に記載されています。Common-Error-Headerは、元のメッセージから共通ヘッダーを運び、メッセージルーティング情報（MRI）およびセッションIDENTIFIER（SID）オブジェクトの内容も、正常にデコードされた場合に含まれます。一部のエラーの場合、追加情報フィールドを含めることができ、これらのフィールド自体には簡単なTLV形式があります。最後に、オプションのフリーテキストコメントが追加される場合があります。
This section describes the various encapsulation options for D-mode messages. Although there are several possibilities, depending on message type, MRM, and local policy, the general design principle is that the sole purpose of the encapsulation is to ensure that the message is delivered to or intercepted at the correct peer. Beyond that, minimal significance is attached to the type of encapsulation or the values of addresses or ports used for it. This allows new options to be developed in the future to handle particular deployment requirements without modifying the overall protocol specification.
このセクションでは、Dモードメッセージのさまざまなカプセル化オプションについて説明します。メッセージタイプ、MRM、およびローカルポリシーに応じて、いくつかの可能性がありますが、一般的な設計の原則は、カプセル化の唯一の目的は、メッセージが正しいピアに配信または傍受されることを保証することです。それを超えて、最小限の重要性は、カプセル化のタイプまたはそれに使用されるアドレスまたはポートの値に添付されています。これにより、全体的なプロトコル仕様を変更せずに特定の展開要件を処理するために、将来新しいオプションを開発できるようになります。
Normal encapsulation MUST be used for all D-mode messages where the signalling peer is already known from previous signalling. This includes Response and Confirm messages, and Data messages except if these are being sent without using local routing state. Normal encapsulation is simple: the message is carried in a single UDP datagram. UDP checksums MUST be enabled. The UDP payload MUST always begin with a 32-bit magic number with value 0x4e04 bda5 in network byte order; this is followed by the GIST common header and the complete set of payloads. If the magic number is not present, the message MUST be silently dropped. The normal encapsulation is shown in outline in Figure 6.
通常のカプセル化は、シグナリングピアが以前のシグナリングから既に知られているすべてのDモードメッセージに使用する必要があります。これには、応答と確認メッセージ、およびこれらがローカルルーティング状態を使用せずに送信されている場合を除き、データメッセージが含まれます。通常のカプセル化は単純です。メッセージは、単一のUDPデータグラムで掲載されています。UDPチェックサムを有効にする必要があります。UDPペイロードは、常にネットワークバイトの順序で値0x4E04 BDA5を備えた32ビットマジック番号から開始する必要があります。これに続いて、GIST共通ヘッダーとペイロードの完全なセットが続きます。魔法の番号が存在しない場合、メッセージは静かにドロップする必要があります。通常のカプセル化は、図6の概要を示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IP Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// UDP Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GIST Magic Number (0x4e04bda5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// GIST Common Header //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// GIST Payloads //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Normal Encapsulation Packet Format
図6：通常のカプセル化パケット形式
The message is IP addressed directly to the adjacent peer as given by the routing state table. Where the message is a direct reply to a Query and no routing state exists, the destination address is derived from the input message using the same rules as in Section 4.4.1. The UDP port numbering MUST be compatible with that used on Query messages (see below), that is, the same for messages in the same direction and with source and destination port numbers swapped for messages in the opposite direction. Messages with the normal encapsulation MUST be sent with source addressing mode flag S=1 unless the message is a reply to a message that is known to have passed through a NAT, and the receiver MUST check the IP source address with the interface-address given in the NLI as part of legacy NAT detection. Both these aspects of message processing are discussed further in Section 7.2.1.
メッセージは、ルーティングステートテーブルで与えられた隣接するピアに直接アドレス指定されます。メッセージがクエリへの直接的な返信であり、ルーティング状態が存在しない場合、宛先アドレスは、セクション4.4.1と同じルールを使用して入力メッセージから導き出されます。UDPポート番号は、クエリメッセージで使用されるもの（以下を参照）と互換性がなければなりません。つまり、同じ方向のメッセージでも、ソースと宛先のポート番号も反対方向のメッセージに交換されます。通常のカプセル化を伴うメッセージは、メッセージがNATを通過したことが知られているメッセージへの返信である場合を除き、ソースアドレス指定モードフラグs = 1で送信する必要があり、受信者はインターフェイスアドレスが与えられたインターフェイスアドレスでIPソースアドレスを確認する必要がありますLegacy Nat検出の一部としてNLIで。メッセージ処理のこれらの両方の側面については、セクション7.2.1でさらに説明します。
Q-mode encapsulation MUST be used for messages where no routing state is available or where the routing state is being refreshed, in particular, for Query messages. Q-mode can also be used when requested by local policy. Q-mode encapsulation is similar to normal encapsulation, with changes in IP address selection, rules about IP options, and a defined method for selecting UDP ports.
Qモードカプセル化は、ルーティング状態が利用できないメッセージや、特にクエリメッセージに対してルーティング状態が更新されているメッセージに使用する必要があります。Qモードは、ローカルポリシーで要求された場合にも使用できます。Qモードのカプセル化は、IPアドレスの選択の変更、IPオプションに関するルール、およびUDPポートを選択するための定義された方法で、通常のカプセル化に似ています。
It is an essential property of the Q-mode encapsulation that it is possible for a GIST node to intercept these messages efficiently even when they are not directly addressed to it and, conversely, that it is possible for a non-GIST node to ignore these messages without overloading the slow path packet processing. This document specifies that interception is done based on RAOs.
Qモードのカプセル化の重要なプロパティであり、GISTノードがこれらのメッセージに直接対処されていなくても効率的にインターセプトできること、および逆に、非GISTノードがこれらを無視することが可能であることが可能であることが重要です。遅いパスパケット処理を過負荷にすることなくメッセージ。このドキュメントは、傍受がRAOSに基づいて行われることを指定しています。
In general, the IP addresses are derived from information in the MRI; the exact rules depend on the MRM. For the case of messages with source addressing mode flag S=1, the receiver MUST check the IP source address against the interface-address given in the NLI as part of legacy NAT detection; see Section 7.2.1.
一般に、IPアドレスはMRIの情報から派生しています。正確なルールはMRMに依存します。ソースアドレス指定モードフラグs = 1を使用したメッセージの場合、レガシーNAT検出の一部として、NLIで指定されたインターフェイスアドレスに対してIPソースアドレスを確認する必要があります。セクション7.2.1を参照してください。
Current MRMs define the use of a Router Alert Option [13] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it unless it has been specifically configured not to (see below). A node MAY make the initial interception decision based purely on IP-Protocol number transport header analysis. Implementations MAY provide an option to disable the setting of RAO on Q-mode packets on a per-destination prefix basis; however, the option MUST be disabled by default and MUST only be enabled when it has been separately verified that the next GIST node along the path to the destination is capable of intercepting packets without RAO. The purpose of this option is to allow operation across networks that do not properly support RAO; further details are discussed in Appendix C.
現在のMRMSは、NSLPIDに応じてメッセージを傍受するのを支援するために、ルーターアラートオプション[13]の使用を定義しています。MRMがRAOの使用を定義している場合、送信者は、具体的に構成されていない限り、それを含める必要があります（以下を参照）。ノードは、IP-Protocol番号トランスポートヘッダー分析に純粋に基づいて、初期傍受決定を行う場合があります。実装では、Q-ModeパケットでRAOの設定を照明ごとのプレフィックスベースで無効にするオプションが提供される場合があります。ただし、オプションはデフォルトで無効にする必要があり、宛先へのパスに沿った次のGISTノードがRAOなしでパケットを傍受できることを個別に確認した場合にのみ有効にする必要があります。このオプションの目的は、RAOを適切にサポートしていないネットワーク全体で動作を許可することです。詳細については、付録Cで説明します。
It is likely that fragmented datagrams will not be correctly intercepted in the network, since the checks that a datagram is a Q-mode packet depend on data beyond the IP header. Therefore, the sender MUST set the Don't Fragment (DF) bit in the IPv4 header. Note that ICMP "packet too large" messages will be sent to the source address of the original IP datagram, and since all MRM definitions recommend S=1 for at least some retransmissions, ICMP errors related to fragmentation will be seen at the Querying node.
データグラムがQモードパケットであるというチェックは、IPヘッダー以外のデータに依存するため、断片化されたデータグラムはネットワークで正しく傍受されない可能性があります。したがって、送信者はIPv4ヘッダーにDont Fragment（DF）ビットを設定する必要があります。ICMP「パケットが大きすぎる」メッセージが元のIPデータグラムのソースアドレスに送信されることに注意してください。すべてのMRM定義は、少なくともいくつかの再送信に対してS = 1を推奨するため、断片化に関連するICMPエラーがクエリノードで見られます。
The upper layer protocol, identified by the IP-Protocol field in the IP header, MUST be UDP.
IPヘッダーのIPプロトコルフィールドによって識別される上層プロトコルは、UDPでなければなりません。
As for IPv4, the IP addresses are derived from information in the MRI; the exact rules depend on the MRM. For the case of messages with source addressing mode flag S=1, the receiver MUST check the IP source address with the interface-address given in the NLI as part of legacy NAT detection; see Section 7.2.1.
IPv4に関しては、IPアドレスはMRIの情報から派生しています。正確なルールはMRMに依存します。ソースアドレス指定モードフラグs = 1を使用したメッセージの場合、レガシーNAT検出の一部としてNLIに与えられたインターフェイスアドレスでIPソースアドレスを確認する必要があります。セクション7.2.1を参照してください。
For all current MRMs, the IP header is given a Router Alert Option [8] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it without exception. It is RECOMMENDED that a node bases its initial interception decision purely on the presence of a hop-by-hop option header containing the RAO, which will be at the start of the header chain.
現在のすべてのMRMSについて、IPヘッダーには、NSLPIDに応じてメッセージをインターセプトするのを支援するために、ルーターアラートオプション[8]が与えられます。MRMがRAOの使用を定義している場合、送信者は例外なくそれを含める必要があります。ノードは、ヘッダーチェーンの開始時にRAOを含むホップバイホップオプションヘッダーの存在に純粋に、最初の傍受決定を下すことをお勧めします。
The upper layer protocol MUST be UDP without intervening encapsulation layers. Following any hop-by-hop option header, the IP header MUST NOT include any extension headers other than routing or destination options [5], and for the last extension header MUST have a next-header field of UDP.
上層のプロトコルは、カプセル化層に介入することなくUDPでなければなりません。ホップバイホップオプションヘッダーに続いて、IPヘッダーにはルーティングまたは宛先オプション以外の拡張ヘッダー[5]以外の拡張ヘッダーを含める必要はありません。最後の拡張ヘッダーには、UDPの次のヘッダーフィールドが必要です。
For both IP versions, the above rules require that the upper layer protocol identified by the IP header MUST be UDP. Other packets MUST NOT be identified as GIST Q-mode packets; this includes IP-in-IP tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or packets that have undergone some additional transport layer processing (transport mode AH/ESP). If IP output processing at the originating node or an intermediate router causes such additional encapsulations to be added to a GIST Q-mode packet, this packet will not be identified as GIST until the encapsulation is terminated. If the node wishes to signal for data over the network region where the encapsulation applies, it MUST generate additional signalling with an MRI matching the encapsulated traffic, and the outbound GIST Q-mode messages for it MUST bypass the encapsulation processing.
両方のIPバージョンについて、上記のルールでは、IPヘッダーによって識別される上層プロトコルがUDPでなければならないことが必要です。他のパケットをGIST Q-Modeパケットとして識別してはなりません。これには、IP-in-IPトンネルパケット、その他のトンネルパケット（トンネルモードAH/ESP）、または追加の輸送層処理（輸送モードAH/ESP）を受けたパケットが含まれます。元のノードまたは中間ルーターでのIP出力処理により、このような追加のカプセルがGIST Qモードパケットに追加されると、このパケットはカプセル化が終了するまでGISTとして識別されません。ノードがカプセル化が適用されるネットワーク領域でデータの信号を希望する場合、カプセル化されたトラフィックを一致させるMRIを使用して追加のシグナル伝達を生成する必要があり、そのためのアウトバウンドGIST Qモードメッセージはカプセル化処理をバイパスする必要があります。
Therefore, the final stage of the interception process and the final part of encapsulation is at the UDP level. The source UDP port is selected by the message sender as the port at which it is prepared to receive UDP messages in reply, and the sender MUST use the destination UDP port allocated for GIST by IANA (see Section 9). Note that for some MRMs, GIST nodes anywhere along the path can generate GIST packets with source addresses that spoof the source address of the data flow. Therefore, destinations cannot distinguish these packets from genuine end-to-end data purely on address analysis. Instead, it must be possible to distinguish such GIST packets by port analysis; furthermore, the mechanism to do so must remain valid even if the destination is GIST-unaware. GIST solves this problem by using a fixed destination UDP port from the "well known" space for the Q-mode encapsulation. This port should never be allocated on a GIST-unaware host, and therefore Q-mode encapsulated messages should always be rejected with an ICMP error. The usage of this destination port by other applications will result in reduced performance due to increased delay and packet drop rates due to their interception by GIST nodes.
したがって、傍受プロセスの最終段階とカプセル化の最終部分はUDPレベルです。ソースUDPポートは、メッセージ送信者によって選択され、返信でUDPメッセージを受信する準備ができているポートとして選択され、送信者はIANAによってGISTに割り当てられた宛先UDPポートを使用する必要があります（セクション9を参照）。一部のMRMSの場合、パス沿いのどこでもGISTノードは、データフローのソースアドレスをスプーフィングするソースアドレスを備えたGISTパケットを生成できることに注意してください。したがって、目的地は、これらのパケットを純粋にアドレス分析で真のエンドツーエンドデータと区別することはできません。代わりに、ポート分析によってそのようなGISTパケットを区別することが可能である必要があります。さらに、目的地がGIST-UNAWAREであっても、そうするメカニズムは有効なままでなければなりません。GISTは、Qモードカプセル化のために「よく知られている」スペースから固定された宛先UDPポートを使用することにより、この問題を解決します。このポートをGist-Unawareホストに割り当てることはできないため、Qモードカプセル化メッセージは常にICMPエラーで拒否される必要があります。他のアプリケーションによるこの宛先ポートの使用により、GISTノードによる傍受により、遅延の増加とパケットドロップ率が増加するため、パフォーマンスが低下します。
A GIST node will need to be capable to filter out all IP/UDP packets that have a UDP destination port number equal to the one registered for GIST Q-mode encapsulation. These packets SHOULD then be further verified to be GIST packets by checking the magic number (see Section 5.3.1). The packets that meet both port and magic number requirements are further processed as GIST Q-mode packets. Any filtered packets that fail this GIST magic number check SHOULD be forwarded towards the IP packet's destination as a normal IP datagram. To protect against denial-of-service attacks, a GIST node SHOULD have a rate limiter preventing more packets (filtered as potential Q-mode packets) from being processed than the system can safely handle. Any excess packets SHOULD be discarded.
GISTノードは、GIST Q-Modeカプセル化に登録されているものに等しいUDP宛先ポート番号を持つすべてのIP/UDPパケットをフィルタリングできる必要があります。これらのパケットは、マジック番号をチェックすることにより、GISTパケットとしてさらに検証する必要があります（セクション5.3.1を参照）。ポート番号とマジック番号の両方の要件を満たすパケットは、GIST Qモードパケットとしてさらに処理されます。このGist Magic Number Checkに失敗したフィルタリングされたパケットは、通常のIPデータグラムとしてIPパケットの宛先に向けて転送する必要があります。サービス拒否攻撃から保護するために、GISTノードには、システムが安全に処理できるよりも、より多くのパケット（潜在的なQモードパケットとしてフィルタリングされている）が処理されないようにするレートリミッターが必要です。余分なパケットは廃棄する必要があります。
For both IPv4 and IPv6, for Q-mode packets with IP options allowed by the above requirements, IP options processing is intended to be carried out independently of GIST processing. Note that for the options allowed by the above rules, the option semantics are independent of the payload: UDP payload modifications are not prevented by the options and do not affect the option content, and conversely the presence of the options does not affect the UDP payload.
IPv4とIPv6の両方の場合、上記の要件で許可されているIPオプションを備えたQ-Modeパケットの場合、IPオプション処理はGIST処理とは無関係に実行されることを目的としています。上記のルールで許可されているオプションの場合、オプションセマンティクスはペイロードに依存しないことに注意してください。UDPペイロードの変更はオプションによって防止されず、オプションコンテンツに影響を与えず、逆にオプションの存在はUDPペイロードに影響しません。。
On packets originated by GIST, IP options MAY be added according to node-local policies on outgoing IP data. On packets forwarded by GIST without NSLP processing, IP options MUST be processed as for a normally forwarded IP packet. On packets locally delivered to the NSLP, the IP options MAY be passed to the NSLP and equivalent options used on subsequently generated outgoing Q-mode packets. In this case, routing related options SHOULD be processed identically as they would be for a normally forwarded IP packet.
GISTから発信されたパケットでは、IPオプションが発信IPデータに関するノードローカルポリシーに従って追加される場合があります。NSLP処理なしでGISTによって転送されるパケットでは、通常転送されたIPパケットのようにIPオプションを処理する必要があります。NSLPにローカルに配信されたパケットでは、IPオプションがNSLPに渡され、その後生成された発信Qモードパケットで使用される同等のオプションが渡されます。この場合、ルーティング関連オプションは、通常転送されたIPパケットの場合と同じように処理する必要があります。
D-mode uses UDP, and hence has no automatic reliability or congestion control capabilities. Signalling applications requiring reliability should be serviced using C-mode, which should also carry the bulk of signalling traffic. However, some form of messaging reliability is required for the GIST control messages themselves, as is rate control to handle retransmissions and also bursts of unreliable signalling or state setup requests from the signalling applications.
D-ModeはUDPを使用するため、自動信頼性または輻輳制御機能はありません。信頼性を必要とするシグナリングアプリケーションは、Cモードを使用してサービスを提供する必要があります。これは、シグナリングトラフィックの大部分も運ぶ必要があります。ただし、再送信を処理するレートコントロールと信頼できないシグナリングまたはシグナリングアプリケーションからの状態セットアップ要求のバーストと同様に、GIST制御メッセージ自体には、何らかの形のメッセージング信頼性が必要です。
Query messages that do not receive Responses MAY be retransmitted; retransmissions MUST use a binary exponential backoff. The initial timer value is T1, which the backoff process can increase up to a maximum value of T2 seconds. The default value for T1 is 500 ms. T1 is an estimate of the round-trip time between the Querying and Responding nodes. Nodes MAY use smaller values of T1 if it is known that the Query should be answered within the local network. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high-latency access links) that the round-trip time is larger. The default value of T2 is 64*T1. Note that Queries may go unanswered either because of message loss (in either direction) or because there is no reachable GIST peer. Therefore, implementations MAY trade off reliability (large T2) against promptness of error feedback to applications (small T2). If the NSLP has indicated a timeout on the validity of this payload (see Appendix B.1), T2 MUST be chosen so that the process terminates within this timeout. Retransmitted Queries MUST use different Query-Cookie values. If the Query carries NSLP data, it may be delivered multiple times to the signalling application. These rules apply equally to the message that first creates routing state, and those that refresh it. In all cases, Responses MUST be sent promptly to avoid spurious retransmissions. Nodes generating any type of retransmission MUST be prepared to receive and match a reply to any of them, not just the one most recently sent. Although a node SHOULD terminate its retransmission process when any reply is received, it MUST continue to process further replies as normal.
応答を受信しないクエリメッセージが再送信される場合があります。再送信は、バイナリ指数バックオフを使用する必要があります。初期タイマー値はT1であり、バックオフプロセスはT2秒の最大値まで増加する可能性があります。T1のデフォルト値は500ミリ秒です。T1は、クエリノードと応答ノードの間の往復時間の推定値です。ノードは、クエリがローカルネットワーク内で回答する必要があることがわかっている場合、T1のより小さな値を使用する場合があります。T1はより大きく選択される場合があります。これは、往復時間が大きいことを事前に（高速アクセスリンクなど）既知である場合に推奨されます。T2のデフォルト値は64*T1です。クエリは、メッセージの損失（どちらの方向）または到達可能なGISTピアがないために答えられない場合があることに注意してください。したがって、実装は、アプリケーションへのエラーフィードバックの迅速性（小さなT2）に対して信頼性（大きなT2）をトレードオフする可能性があります。NSLPがこのペイロードの有効性に関するタイムアウトを示している場合（付録B.1を参照）、このタイムアウト内でプロセスが終了するようにT2を選択する必要があります。再送信されたクエリは、異なるクエリクッキー値を使用する必要があります。クエリにNSLPデータが含まれている場合、シグナリングアプリケーションに複数回配信される場合があります。これらのルールは、最初にルーティング状態を作成するメッセージと、それを更新するメッセージに等しく適用されます。すべての場合において、偽りの再送信を避けるために、回答を迅速に送信する必要があります。あらゆる種類の再送信を生成するノードは、最近送信されたものだけでなく、それらのいずれかへの返信を受け取って一致させるために準備する必要があります。ノードは、返信を受信したときに再送信プロセスを終了する必要がありますが、通常どおりにさらに返信を処理し続ける必要があります。
This algorithm is sufficient to handle lost Queries and Responses. The case of a lost Confirm is more subtle. The Responding node MAY run a retransmission timer to resend the Response until a Confirm is received; the timer MUST use the same backoff mechanism and parameters as for Responses. The problem of an amplification attack stimulated by a malicious Query is handled by requiring the cookie mechanism to enable the node receiving the Response to discard it efficiently if it does not match a previously sent Query. This approach is only appropriate if the Responding node is prepared to store per-flow state after receiving a single (Query) message, which includes the case where the node has queued NSLP data. If the Responding node has delayed state installation, the error condition will only be detected when a Data message arrives. This is handled as a routing state error (see Section 4.4.6) that causes the Querying node to restart the handshake.
このアルゴリズムは、失われたクエリと応答を処理するのに十分です。失われた確認のケースはより微妙です。応答するノードは、再送信タイマーを実行して、確認が受信されるまで応答を再送信する場合があります。タイマーは、応答と同じバックオフメカニズムとパラメーターを使用する必要があります。悪意のあるクエリによって刺激される増幅攻撃の問題は、以前に送信されたクエリと一致しない場合、ノードを受信するノードを効率的に破棄するためにノードを有効にするためにCookieメカニズムを要求することにより処理されます。このアプローチは、応答ノードが単一の（クエリ）メッセージを受信した後にフローごとの状態を保存する準備ができている場合にのみ適切です。これには、ノードがNSLPデータをキードした場合が含まれます。応答するノードが状態インストールが遅れた場合、エラー条件はデータメッセージが届くときにのみ検出されます。これは、クエリノードがハンドシェイクを再起動する原因となるルーティング状態エラー（セクション4.4.6を参照）として処理されます。
The basic rate-control requirements for D-mode traffic are deliberately minimal. A single rate limiter applies to all traffic, for all interfaces and message types. It applies to retransmissions as well as new messages, although an implementation MAY choose to prioritise one over the other. Rate-control applies only to locally generated D-mode messages, not to messages that are being forwarded. When the rate limiter is in effect, D-mode messages MUST be queued until transmission is re-enabled, or they MAY be dropped with an error condition indicated back to local signalling applications. In either case, the effect of this will be to reduce the rate at which new transactions can be initiated by signalling applications, thereby reducing the load on the network.
Dモードトラフィックの基本レート制御要件は、意図的に最小限です。すべてのインターフェイスとメッセージタイプに対して、すべてのトラフィックに単一のレートリミッターが適用されます。実装は、一方よりも優先順位を付けることを選択する場合がありますが、再送信と新しいメッセージに適用されます。レートコントロールは、転送されているメッセージではなく、ローカルで生成されたDモードメッセージにのみ適用されます。レートリミッターが有効になっている場合、送信が再度有効になるまでDモードメッセージをキューに入れる必要があります。または、ローカルシグナリングアプリケーションに戻るエラー条件でドロップされる場合があります。どちらの場合でも、この効果は、シグナリングアプリケーションによって新しいトランザクションを開始できる速度を下げて、ネットワーク上の負荷を削減することです。
The rate-limiting mechanism is implementation-defined, but it is RECOMMENDED that a token bucket limiter as described in [33] be used. The token bucket MUST be sized to ensure that a node cannot saturate the network with D-mode traffic, for example, when re-probing the network for multiple flows after a route change. A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction of the node's lowest-speed interface. It is RECOMMENDED that this fraction is no more than 5%. Note that according to the rules of Section 4.3.3, in general, D-mode SHOULD only be used for Queries and Responses rather than normal signalling traffic unless capacity for normal signalling traffic can be engineered.
レート制限メカニズムは実装定義ですが、[33]で説明されているトークンバケットリミッターを使用することをお勧めします。トークンバケットは、ノードがDモードトラフィックでネットワークを飽和させることができないようにサイズを付ける必要があります。たとえば、ルートの変更後に複数のフローについてネットワークを再プロするときは、D-Modeトラフィックでネットワークを飽和させる必要があります。適切なアプローチは、平均出力速度がノードの最低速度インターフェイスのわずかな割合になるように、トークンバケットパラメーターを制限することです。この画分は5％以下であることをお勧めします。一般に、セクション4.3.3の規則によれば、Dモードは、通常の信号トラフィックの容量を設計できない限り、通常の信号トラフィックではなく、クエリと応答にのみ使用する必要があることに注意してください。
It is a requirement of the NTLP defined in [29] that it should be able to support bundling of small messages, fragmentation of large messages, and message boundary delineation. TCP provides both bundling and fragmentation, but not message boundaries. However, the length information in the GIST common header allows the message boundary to be discovered during parsing. The bundling together of small messages either can be done within the transport protocol or can be carried out by GIST during message construction. Either way, two approaches can be distinguished:
[29]で定義されたNTLPの要件であり、小さなメッセージのバンドル、大きなメッセージの断片化、メッセージの境界描写をサポートできるはずです。TCPはバンドルと断片化の両方を提供しますが、メッセージの境界は提供しません。ただし、GIST共通ヘッダーの長さ情報により、解析中にメッセージ境界を発見できます。小さなメッセージのバンドリングは、トランスポートプロトコル内で実行することも、メッセージの構築中にGISTによって実行することもできます。いずれにせよ、2つのアプローチを区別できます。
1. As messages arrive for transmission, they are gathered into a bundle until a size limit is reached or a timeout expires (cf. the Nagle algorithm of TCP). This provides maximal efficiency at the cost of some latency.
1. 送信用のメッセージが届くと、サイズ制限に達するか、タイムアウトが切れるまでバンドルに収集されます（TCPのナグルアルゴリズムを参照）。これにより、何らかのレイテンシのコストで最大の効率が提供されます。
2. Messages awaiting transmission are gathered together while the node is not allowed to send them, for example, because it is congestion controlled.
2. たとえば、渋滞が制御されているため、ノードはそれらを送信することは許可されていませんが、送信を待っているメッセージはまとめられます。
The second type of bundling is always appropriate. For GIST, the first type MUST NOT be used for trigger messages (i.e., messages that update GIST or signalling application state), but may be appropriate for refresh messages (i.e., messages that just extend timers). These distinctions are known only to the signalling applications, but MAY be indicated (as an implementation issue) by setting the priority transfer attribute (Section 4.1.2).
バンドルの2番目のタイプが常に適切です。GISTの場合、最初のタイプをトリガーメッセージ（つまり、GISTまたはシグナリングアプリケーション状態を更新するメッセージ）に使用する必要はありませんが、更新メッセージ（つまり、タイマーを拡張するメッセージ）に適している場合があります。これらの違いは、シグナリングアプリケーションにのみ知られていますが、優先転送属性（セクション4.1.2）を設定することにより（実装の問題として）示される場合があります。
It can be seen that all of these transport protocol options can be supported by the basic GIST message format already presented. The GIST message, consisting of common header and TLVs, is carried directly in the transport protocol, possibly incorporating transport layer security protection. Further messages can be carried in a continuous stream. This specification defines only the use of TCP, but other possibilities could be included without additional work on message formatting.
これらのトランスポートプロトコルオプションはすべて、すでに提示されている基本的なGISTメッセージ形式によってサポートできることがわかります。共通ヘッダーとTLVで構成されるGISTメッセージは、輸送層のセキュリティ保護を組み込んだ場合、輸送プロトコルに直接運ばれます。さらなるメッセージは、連続ストリームで携帯することができます。この仕様はTCPの使用のみを定義しますが、メッセージのフォーマットに関する追加作業なしでは、他の可能性を含めることができます。
GIST has four primary message types (Query, Response, Confirm, and Data) and three possible encapsulation methods (normal D-mode, Q-mode, and C-mode). The combinations of message type and encapsulation that are allowed for message transmission are given in the table below. In some cases, there are several possible choices, depending on the existence of routing state or messaging associations. The rules governing GIST policy, including whether or not to create such state to handle a message, are described normatively in the other sections of this specification. If a message that can only be sent in Q-mode or D-mode arrives in C-mode or vice versa, this MUST be rejected with an "Incorrect Encapsulation" error message (Appendix A.4.4.3). However, it should be noted that the processing of the message at the receiver is not otherwise affected by the encapsulation method used, except that the decapsulation process may provide additional information, such as translated addresses or IP hop count to be used in the subsequent message processing.
GISTには、4つの主要なメッセージタイプ（クエリ、応答、確認、データ）と3つの可能なカプセル化方法（通常のDモード、Qモード、およびCモード）があります。メッセージの送信が許可されているメッセージの種類とカプセル化の組み合わせを、以下の表に示します。場合によっては、ルーティング状態またはメッセージング関連の存在に応じて、いくつかの選択肢があります。メッセージを処理するためにそのような状態を作成するかどうかを含むGISTポリシーを管理する規則は、この仕様の他のセクションで規範的に説明されています。QモードまたはDモードでのみ送信できるメッセージがCモードに到着するか、その逆の場合、これは「誤ったカプセル化」エラーメッセージで拒否される必要があります（付録A.4.4.3）。ただし、脱カプセル化プロセスが翻訳されたアドレスやIPホップカウントなどの追加情報を提供したり、後続のメッセージで使用したりすることを除いて、受信機でのメッセージの処理は、使用されるカプセル化方法の影響を受けないことに注意する必要があります。処理。
+----------+--------------+---------------------------+-------------+
| Message | Normal | Query D-mode (Q-mode) | C-mode |
| | D-mode | | |
+----------+--------------+---------------------------+-------------+
| Query | Never | Always, with C-flag=1 | Never |
| | | | |
| Response | Unless a | Never | If a |
| | messaging | | messaging |
| | association | | association |
| | is being | | is being |
| | re-used | | re-used |
| | | | |
| Confirm | Only if no | Never | If a |
| | messaging | | messaging |
| | association | | association |
| | has been set | | has been |
| | up or is | | set up or |
| | being | | is being |
| | re-used | | re-used |
| | | | |
| Data | If routing | If the MRI can be used to | If a |
| | state exists | derive the Q-mode | messaging |
| | for the flow | encapsulation, and either | association |
| | but no | no routing state exists | exists |
| | messaging | or local policy requires | |
| | association | Q-mode; MUST have | |
| | | C-flag=1 | |
+----------+--------------+---------------------------+-------------+
Special rules apply to the encapsulation and transmission of Error messages.
特別なルールは、エラーメッセージのカプセル化と送信に適用されます。
GIST only generates Error messages in reaction to incoming messages. Error messages MUST NOT be generated in reaction to incoming Error messages. The routing and encapsulation of the Error message are derived from that of the message that caused the error; in particular, local routing state is not consulted. Routing state and messaging association state MUST NOT be created to handle the error, and Error messages MUST NOT be retransmitted explicitly by GIST, although they are subject to the same rate control as other messages.
GISTは、着信メッセージに反応してエラーメッセージのみを生成します。エラーメッセージは、着信エラーメッセージに反応して生成してはなりません。エラーメッセージのルーティングとカプセル化は、エラーを引き起こしたメッセージのルーティングから導き出されます。特に、ローカルルーティング状態は相談されません。ルーティング状態およびメッセージング協会の状態を作成してエラーを処理する必要はなく、エラーメッセージはGISTによって明示的に再送信されてはなりませんが、他のメッセージと同じレートコントロールの対象です。
o If the incoming message was received in D-mode, the error MUST be sent in D-mode using the normal encapsulation, using the addressing information from the NLI object in the incoming message. If the NLI could not be determined, the error MUST be sent to the IP source of the incoming message if the S-flag was set in it. The NLI object in the Error message reports information about the originator of the error.
o 着信メッセージがDモードで受信された場合、着信メッセージのNLIオブジェクトからのアドレス指定情報を使用して、通常のカプセル化を使用してdモードでエラーを送信する必要があります。NLIを決定できなかった場合、S-Flagが設定されている場合、エラーを着信メッセージのIPソースに送信する必要があります。エラーメッセージ内のNLIオブジェクトは、エラーのオリジネーターに関する情報を報告します。
o If the incoming message was received over a messaging association, the error MUST be sent back over the same messaging association.
o 受信メッセージがメッセージングアソシエーションを介して受信された場合、エラーは同じメッセージング協会で送信される必要があります。
The NSLPID in the common header of the Error message has the value zero. If for any reason the message cannot be sent (for example, because it is too large to send in D-mode, or because the MA over which the original message arrived has since been closed), an error SHOULD be logged locally. The receiver of the Error message can infer the NSLPID for the message that caused the error from the Common Header that is embedded in the Error Object.
エラーメッセージの共通ヘッダーのNSLPIDの値はゼロです。何らかの理由でメッセージを送信できない場合（たとえば、Dモードで送信するには大きすぎるため、または元のメッセージが到着したMAが閉じられたためです）、エラーをローカルで記録する必要があります。エラーメッセージの受信機は、エラーオブジェクトに埋め込まれている共通ヘッダーからエラーを引き起こしたメッセージに対してNSLPIDを推測できます。
A key attribute of GIST is that it is flexible in its ability to use existing transport and security protocols. Different transport protocols may have performance attributes appropriate to different environments; different security protocols may fit appropriately with different authentication infrastructures. Even given an initial default mandatory protocol set for GIST, the need to support new protocols in the future cannot be ruled out, and secure feature negotiation cannot be added to an existing protocol in a backwards-compatible way. Therefore, some sort of capability discovery is required.
GISTの重要な属性は、既存の輸送プロトコルとセキュリティプロトコルを使用する能力に柔軟性があることです。異なる輸送プロトコルには、異なる環境に適したパフォーマンス属性がある場合があります。さまざまなセキュリティプロトコルは、異なる認証インフラストラクチャに適切に適合する場合があります。GISTの最初のデフォルトの必須プロトコルセットが与えられた場合でも、将来の新しいプロトコルをサポートする必要性を除外することはできず、安全な機能交渉を既存のプロトコルに後方互換の方法で追加することはできません。したがって、何らかの能力の発見が必要です。
Capability discovery is carried out in Query and Response messages, using Stack-Proposal and Stack-Configuration-Data (SCD) objects. If a new messaging association is required, it is then set up, followed by a Confirm. Messaging association multiplexing is achieved by short-circuiting this exchange by sending the Response or Confirm messages on an existing association (Section 4.4.3); whether to do this is a matter of local policy. The end result of this process is a messaging association that is a stack of protocols. If multiple associations exist, it is a matter of local policy how to distribute messages over them, subject to respecting the transfer attributes requested for each message.
能力発見は、スタックプロポザルとスタックコンフィグラーデータ（SCD）オブジェクトを使用して、クエリおよび応答メッセージで実行されます。新しいメッセージングアソシエーションが必要な場合は、セットアップされ、その後に確認されます。メッセージングアソシエーションの多重化は、既存の関連付け（セクション4.4.3）で応答を送信するか、メッセージを確認することにより、この交換を短絡することによって達成されます。これを行うかどうかは、ローカルポリシーの問題です。このプロセスの最終結果は、プロトコルのスタックであるメッセージング関連です。複数の関連付けが存在する場合、各メッセージに対して要求された転送属性を尊重することを条件として、メッセージをそれらに配布する方法はローカルポリシーの問題です。
Every possible protocol for a messaging association has the following attributes:
メッセージング協会のすべての可能なプロトコルには、次の属性があります。
o MA-Protocol-ID, a 1-byte IANA-assigned value (see Section 9).
o MA-Protocol-ID、1バイトIANAが割り当てられた値（セクション9を参照）。
o A specification of the (non-negotiable) policies about how the protocol should be used, for example, in which direction a connection should be opened.
o たとえば、接続を開く方向など、プロトコルの使用方法に関する（交渉不可能な）ポリシーの仕様。
o (Depending on the specific protocol:) Formats for an MA-protocol-options field to carry the protocol addressing and other configuration information in the SCD object. The format may differ depending on whether the field is present in the Query or Response. Some protocols do not require the definition of such additional data, in which case no corresponding MA-protocol-options field will occur in the SCD object.
o （特定のプロトコルに応じて:) SCDオブジェクトにプロトコルアドレス指定情報やその他の構成情報を伝達するMA-Protocol-Optionsフィールドのフォーマット。フォーマットは、フィールドがクエリまたは応答に存在するかどうかによって異なる場合があります。一部のプロトコルでは、このような追加データの定義は必要ありません。この場合、SCDオブジェクトでは対応するMA-Protocol-Optionsフィールドは発生しません。
A Stack-Proposal object is simply a list of profiles; each profile is a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top to bottom' order (e.g., TLS over TCP). A Stack-Proposal is generally accompanied by an SCD object that carries an MA-protocol-options field for any protocol listed in the Stack-Proposal that needs it. An MA-protocol-options field may apply globally, to all instances of the protocol in the Stack-Proposal, or it can be tagged as applying to a specific instance. The latter approach can for example be used to carry different port numbers for TCP depending on whether it is to be used with or without TLS. An message flow that shows several of the features of Stack-Proposal and Stack-Configuration-Data formats can be found in Appendix D.
スタックプロポザルオブジェクトは、単にプロファイルのリストです。各プロファイルは、MA-Protocol-IDのシーケンスです。プロファイルには、「上から下」の順序でプロトコルがリストされています（たとえば、TCPを超えるTLS）。スタックプロポザルには、一般に、それを必要とするスタックプロポザルにリストされているプロトコルのMAプロトコルオプションフィールドを搭載するSCDオブジェクトが伴います。MA-Protocol-Optionsフィールドは、スタックプロポザルのプロトコルのすべてのインスタンスにグローバルに適用される場合があります。または、特定のインスタンスに適用するとタグ付けできます。後者のアプローチは、たとえば、TLSの有無にかかわらず使用するかどうかに応じて、TCPの異なるポート番号を運ぶために使用できます。スタックプロポザルとスタックコンフィグラーデータ形式のいくつかの機能を示すメッセージフローは、付録Dにあります。
An MA-protocol-options field may also be flagged as not usable; for example, a NAT that could not handle SCTP would set this in an MA-protocol-options field about SCTP. A protocol flagged this way MUST NOT be used for a messaging association. If the Stack-Proposal and SCD are both present but not consistent, for example, if they refer to different protocols, or an MA-protocol-options field refers to a non-existent profile, an "Object Value Error" message (Appendix A.4.4.10) with subcode 5 ("Stack-Proposal - Stack-Configuration-Data Mismatch") MUST be returned and the message dropped.
MA-Protocol-Optionsフィールドには、使用できないとフラグが付けられる場合があります。たとえば、SCTPを処理できなかったNATは、これをSCTPに関するMA-Protocol-Optionsフィールドに設定します。この方法でフラグが付けられたプロトコルは、メッセージングアソシエーションに使用してはなりません。スタックプロポザルとSCDが両方とも存在しますが、一貫性がない場合、たとえば、異なるプロトコルを参照する場合、またはMA-Protocol-Optionsフィールドが存在しないプロファイル、「オブジェクト値エラー」メッセージを指します（付録A.4.4.10）サブコード5（ "Stack-Proposal-stack-configuration-data mismatch"）を返してメッセージを削除する必要があります。
A node generating an SCD object MUST honour the implied protocol configurations for the period during which a messaging association might be set up; in particular, it MUST be immediately prepared to accept incoming datagrams or connections at the protocol/port combinations advertised. This MAY require the creation of listening endpoints for the transport and security protocols in question, or a node MAY keep a pool of such endpoints open for extended periods.
SCDオブジェクトを生成するノードは、メッセージングアソシエーションが設定される可能性のある期間の暗黙のプロトコル構成を尊重する必要があります。特に、宣伝されているプロトコル/ポートの組み合わせで、着信データグラムまたは接続を受け入れるためにすぐに準備する必要があります。これには、問題のトランスポートおよびセキュリティプロトコルのリスニングエンドポイントの作成が必要になる場合があります。または、ノードがそのようなエンドポイントのプールを長時間開いたままにすることができます。
However, the received object contents MUST be retained only for the duration of the Query/Response exchange and to allow any necessary association setup to complete. They may become invalid because of expired bindings at intermediate NATs, or because the advertising node is using agile ports. Once the setup is complete, or if it is not necessary or fails for some reason, the object contents MUST be discarded. A default time of 30 seconds to keep the contents is RECOMMENDED.
ただし、受信したオブジェクトの内容は、クエリ/応答交換の期間中にのみ保持され、必要な関連付けのセットアップを完了する必要があります。中間NATでの期限切れのバインディング、または広告ノードがアジャイルポートを使用しているため、それらは無効になる可能性があります。セットアップが完了したら、または何らかの理由で必要であるか失敗しない場合は、オブジェクトの内容を破棄する必要があります。コンテンツを保持するための30秒のデフォルト時間をお勧めします。
A Query requesting messaging association setup always contains a Stack-Proposal and SCD object. The Stack-Proposal MUST only include protocol configurations that are suitable for the transfer attributes of the messages for which the Querying node wishes to use the messaging association. For example, it should not simply include all configurations that the Querying node is capable of supporting.
メッセージングアソシエーションのセットアップを要求するクエリには、常にスタックプロポザルとSCDオブジェクトが含まれています。スタックプロポザルには、クエリノードがメッセージングアソシエーションの使用を希望するメッセージの転送属性に適したプロトコル構成のみを含める必要があります。たとえば、クエリノードがサポートできるすべての構成を単純に含めるべきではありません。
The Response always contains a Stack-Proposal and SCD object, unless multiplexing (where the Responder decides to use an existing association) occurs. For such a Response, the security protocols listed in the Stack-Proposal MUST NOT depend on the Query. A node MAY make different proposals depending on the combination of interface and NSLPID. If multiplexing does occur, which is indicated by sending the Response over an existing messaging association, the following rules apply:
応答には、マルチプレックス（レスポンダーが既存の関連付けを使用することを決定）が発生しない限り、スタックプロポザルとSCDオブジェクトが常に含まれています。このような応答の場合、スタックプロポザルにリストされているセキュリティプロトコルは、クエリに依存してはなりません。ノードは、インターフェイスとNSLPIDの組み合わせに応じて、異なる提案を行う場合があります。多重化が発生した場合、これは既存のメッセージング協会で応答を送信することによって示されます。次のルールが適用されます。
o The re-used messaging association MUST NOT have weaker security properties than all of the options that would have been offered in the full Response that would have been sent without re-use.
o 再利用されたメッセージング協会は、再利用せずに送信される完全な応答で提供されていたすべてのオプションよりも弱いセキュリティプロパティを持たない必要があります。
o The re-used messaging association MUST have equivalent or better transport and security characteristics as at least one of the protocol configurations that was offered in the Query.
o 再利用されたメッセージング協会は、クエリで提供されたプロトコル構成の少なくとも1つとして、同等またはより良い輸送およびセキュリティの特性を持つ必要があります。
Once the messaging association is set up, the Querying node repeats the responder's Stack-Proposal over it in the Confirm. The Responding node MUST verify that this has not been changed as part of bidding-down attack prevention, as well as verifying the Responder-Cookie (Section 8.5). If either check fails, the Responding node MUST NOT create the message routing state (or MUST delete it if it already exists) and SHOULD log an error condition locally. If this is the first message on a new MA, the MA MUST be torn down. See Section 8.6 for further discussion.
メッセージングアソシエーションがセットアップされると、クエリノードは、確認に応答者のスタックプロポザルを繰り返します。応答するノードは、これが入札ダウン攻撃防止の一部として変更されていないことを確認する必要があり、レスポンダークッキーの検証（セクション8.5）を確認する必要があります。どちらかのチェックが失敗した場合、応答するノードはメッセージルーティング状態を作成してはなりません（または既に存在する場合は削除する必要があります）。これが新しいMAに関する最初のメッセージである場合、MAは取り壊されなければなりません。詳細については、セクション8.6を参照してください。
This MA-Protocol-ID denotes a basic use of TCP between peers. Support for this protocol is REQUIRED. If this protocol is offered, MA-protocol-options data MUST also be carried in the SCD object. The MA-protocol-options field formats are:
o in a Query: no additional options data (the MA-protocol-options Length field is zero).
o クエリでは、追加のオプションデータはありません（MA-Protocol-Optionsの長さフィールドはゼロです）。
o in a Response: 2-byte port number at which the connection will be accepted, followed by 2 pad bytes.
o 応答：接続が受け入れられる2バイトポート番号、2バイトのパッドバイトが続きます。
The connection is opened in the forwards direction, from the Querying node towards the responder. The Querying node MAY use any source address and source port. The destination information MUST be derived from information in the Response: the address from the interface-address from the Network-Layer-Information object and the port from the SCD object as described above.
接続は、クエリノードからレスポンダーに向かって、フォワード方向に開きます。クエリノードは、任意のソースアドレスとソースポートを使用する場合があります。宛先情報は、応答の情報から導き出される必要があります。上記のように、ネットワーク層情報オブジェクトからのインターフェイスアドレスからのアドレスとSCDオブジェクトからのポートから導き出される必要があります。
Associations using Forwards-TCP can carry messages with the transfer attribute Reliable=True. If an error occurs on the TCP connection such as a reset, as can be detected for example by a socket exception condition, GIST MUST report this to NSLPs as discussed in Section 4.1.2.
Forward-TCPを使用した関連付けは、転送属性の信頼性= trueでメッセージを伝えることができます。ソケット例外条件で検出できるように、リセットなどのTCP接続でエラーが発生した場合、GISTはセクション4.1.2で説明したように、これをNSLPに報告する必要があります。
This MA-Protocol-ID denotes a basic use of transport layer channel security, initially in conjunction with TCP. Support for this protocol in conjunction with TCP is REQUIRED; associations using it can carry messages with transfer attributes requesting confidentiality or integrity protection. The specific TLS version will be negotiated within the TLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to TLS1.0 [15] and MUST use the highest protocol version supported by both peers. Implementation of TLS1.2 [10] is RECOMMENDED. GIST nodes supporting TLS1.0 or TLS1.1 MUST be able to negotiate the TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. They MAY negotiate any mutually acceptable ciphersuite that provides authentication, integrity, and confidentiality.
このMA-Protocol-IDは、最初はTCPと組み合わせて、輸送層チャネルセキュリティの基本的な使用を示しています。TCPと組み合わせたこのプロトコルのサポートが必要です。それを使用する関連付けは、機密性または整合性保護を要求する転送属性を持つメッセージを伝えることができます。特定のTLSバージョンはTLSレイヤー自体内でネゴシエートされますが、実装はTLS1.0 [15]の前にプロトコルバージョンと交渉する必要はなく、両方のピアがサポートする最高のプロトコルバージョンを使用する必要があります。TLS1.2 [10]の実装をお勧めします。TLS1.0またはTLS1.1をサポートするGISTノードは、TLS Ciphersuite TLS_RSA_WITH_WITH_3DES_EDE_CBC_SHAを交渉できる必要があり、TLS CipherSuite TLS_RSA_WITH_AES_28_CBC_SHAを交渉できるはずです。彼らは、認証、整合性、および機密性を提供する相互に許容される衝撃性の微細表示と交渉する場合があります。
The default mode of TLS authentication, which applies in particular to the above ciphersuites, uses a client/server X.509 certificate exchange. The Querying node acts as a TLS client, and the Responding node acts as a TLS server. Where one of the above ciphersuites is negotiated, the GIST node acting as a server MUST provide a certificate, and MUST request one from the GIST node acting as a TLS client. This allows either server-only or mutual authentication, depending on the certificates available to the client and the policy applied at the server.
特に上記のCiphersuitesに適用されるTLS認証のデフォルトモードは、クライアント/サーバーX.509証明書交換を使用します。クエリノードはTLSクライアントとして機能し、応答するノードはTLSサーバーとして機能します。上記のCiphersuitesの1つがネゴシエートされている場合、サーバーとして機能するGISTノードは証明書を提供する必要があり、TLSクライアントとして機能するGISTノードからそれを要求する必要があります。これにより、クライアントが利用できる証明書とサーバーに適用されるポリシーに応じて、サーバーのみまたは相互認証が可能になります。
GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the negotiation of alternative ciphersuites is used to trigger alternative authentication procedures, such as the use of pre-shared keys [32]. The use of other authentication procedures may require additional specification work to define how they can be used as part of TLS within the GIST framework, and may or may not require the definition of additional MA-Protocol-IDs.
GISTノードは、他のTLS暗号化と交渉する場合があります。場合によっては、代替の衝突物の交渉を使用して、事前共有キーの使用などの代替認証手順をトリガーするために使用されます[32]。他の認証手順を使用すると、GISTフレームワーク内のTLSの一部として使用する方法を定義するために追加の仕様作業が必要になる場合があり、追加のMA-Protocol-IDの定義が必要になる場合とそうでない場合があります。
No MA-protocol-options field is required for this TLS protocol definition. The configuration information for the transport protocol over which TLS is running (e.g., TCP port number) is provided by the MA-protocol-options for that protocol.
このTLSプロトコル定義には、MA-Protocol-Optionsフィールドは必要ありません。TLSが実行されている輸送プロトコルの構成情報（たとえば、TCPポート番号）は、そのプロトコルのMA-Protocol-Optionsによって提供されます。
After TLS authentication, a node MUST check the identity presented by the peer in order to avoid man-in-the-middle attacks, and verify that the peer is authorised to take part in signalling at the GIST layer. The authorisation check is carried out by comparing the presented identity with each Authorised Peer Database (APD) entry in turn, as discussed in Section 4.4.2. This section defines the identity comparison algorithm for a single APD entry.
TLS認証の後、ノードは、中間の攻撃を避けるためにピアが提示した身元を確認し、ピアがGIST層でのシグナリングに参加することが許可されていることを確認する必要があります。承認チェックは、セクション4.4.2で説明されているように、提示されたアイデンティティを各認定ピアデータベース（APD）エントリと比較することにより実行されます。このセクションでは、単一のAPDエントリのID比較アルゴリズムを定義します。
For TLS authentication with X.509 certificates, an identity from the DNS namespace MUST be checked against each subjectAltName extension of type dNSName present in the certificate. If no such extension is present, then the identity MUST be compared to the (most specific) Common Name in the Subject field of the certificate. When matching DNS names against dNSName or Common Name fields, matching is case-insensitive. Also, a "*" wildcard character MAY be used as the left-most name component in the certificate or identity in the APD. For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com.
X.509証明書を使用したTLS認証の場合、証明書に存在するタイプDNSNAMEの各subjectAltName拡張に対してDNS名前空間からのIDを確認する必要があります。そのような拡張機能が存在しない場合、証明書の件名フィールドの（最も具体的な）一般名と同一性を比較する必要があります。DNS名をDNSNAMEまたは共通名フィールドに対して一致させる場合、マッチングはケース非感受性です。また、「*」ワイルドカード文字は、APDの証明書またはIDの左端の名前コンポーネントとして使用できます。たとえば、APDの *.example.comは、a.example.com、foo.example.com、 *.example.comなどの証明書と一致しますが、example.comと一致しません。同様に、 *.example.comの証明書は、a.example.com、foo.example.com、 *.example.comなどのAPD IDに対して有効ですが、example.comではありません。
Additionally, a node MUST verify the binding between the identity of the peer to which it connects and the public key presented by that peer. Nodes SHOULD implement the algorithm in Section 6 of [8] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings).
さらに、ノードは、接続するピアのアイデンティティと、そのピアが提示した公開鍵の間のバインディングを検証する必要があります。ノードは、一般証明書の検証のために[8]のセクション6にアルゴリズムを実装する必要がありますが、そのアルゴリズムは、同等のレベルの検証を実現する他の検証方法で補完する場合があります（既に検証された証明書とIDのローカルストアとサーバー証明書を比較するなど、バインディング）。
For TLS authentication with pre-shared keys, the identity in the psk_identity_hint (for the server identity, i.e., the Responding node) or psk_identity (for the client identity, i.e., the Querying node) MUST be compared to the identities in the APD.
事前共有キーを使用したTLS認証の場合、PSK_IDENTITY_HINT（サーバーID、つまり応答ノード）またはPSK_IDENTITY（クライアントID、つまりクエリノードの場合）のIDは、APDのIDと比較する必要があります。
Each message routing method (see Section 3.3) requires the definition of the format of the message routing information (MRI) and Q-mode encapsulation rules. These are given in the following subsections for the MRMs currently defined. A GIST implementation on a node MUST support whatever MRMs are required by the NSLPs on that node; GIST implementations SHOULD provide support for both the MRMs defined here, in order to minimise deployment barriers for new signalling applications that need them.
各メッセージルーティング方法（セクション3.3を参照）には、メッセージルーティング情報（MRI）およびQモードのカプセル化ルールの形式の定義が必要です。これらは、現在定義されているMRMSの以下のサブセクションに記載されています。ノード上のGIST実装は、そのノード上のNSLPが必要とするMRMSが何でもサポートする必要があります。GISTの実装は、それらを必要とする新しいシグナリングアプリケーションの展開障壁を最小限に抑えるために、ここで定義されているMRMの両方をサポートする必要があります。
For the path-coupled MRM, the message routing information (MRI) is conceptually the Flow Identifier as in the NSIS framework [29]. Minimally, this could just be the flow destination address; however, to account for policy-based forwarding and other issues a more complete set of header fields SHOULD be specified if possible (see Section 4.3.4 and Section 7.2 for further discussion).
パス結合されたMRMの場合、メッセージルーティング情報（MRI）は、NSISフレームワークのように概念的にフロー識別子です[29]。最終的には、これはフロー宛先アドレスにすぎない可能性があります。ただし、ポリシーベースの転送およびその他の問題を説明するには、可能であれば、より完全なヘッダーフィールドのセットを指定する必要があります（詳細については、セクション4.3.4およびセクション7.2を参照してください）。
MRI = network-layer-version source-address prefix-length destination-address prefix-length IP-protocol diffserv-codepoint [ flow-label ] [ ipsec-SPI / L4-ports]
MRI = Network-Layer-version source-addressプレフィックスレングス宛先宛先アドレスプレフィックス - レングス-length diffserv-codepoint [flow-label] [ipsec-spi / l4-ports]
Additional control information defines whether the flow-label, IPsec Security Parameters Index (SPI), and port information are present, and whether the IP-protocol and diffserv-codepoint fields should be interpreted as significant. The source and destination addresses MUST be real node addresses, but prefix lengths other than 32 or 128 (for IPv4 and IPv6, respectively) MAY be used to implement address wildcarding, allowing the MRI to refer to traffic to or from a wider address range. An additional flag defines the message direction relative to the MRI (upstream vs. downstream).
追加の制御情報は、フローラベル、IPSECセキュリティパラメーターインデックス（SPI）、およびポート情報が存在するかどうか、およびIP-Protocolとdiffserv-codePointフィールドを重要であると解釈する必要があるかどうかを定義します。ソースおよび宛先アドレスは実際のノードアドレスでなければなりませんが、32または128以外のプレフィックスの長さ（それぞれIPv4およびIPv6の場合）を使用してアドレスワイルドカードを実装して、MRIがより広いアドレス範囲との間でのトラフィックを参照できるようにします。追加のフラグは、MRI（上流と下流）に対するメッセージ方向を定義します。
The MRI format allows a potentially very large number of different flag and field combinations. A GIST implementation that cannot interpret the MRI in a message MUST return an "Object Value Error" message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") or 2 ("Invalid Flag-Field Combination") and drop the message.
MRI形式により、潜在的に非常に多数の異なるフラグとフィールドの組み合わせが可能になります。メッセージ内のMRIを解釈できないGIST実装では、サブコード1（「サポートされていない」）または2（「無効なフラグフィールドの組み合わせ」）を備えた「オブジェクト値エラー」メッセージ（付録A.4.4.10）を返す必要があります。メッセージをドロップします。
Where the signalling message is travelling in the same ('downstream') direction as the flow defined by the MRI, the IP addressing for Q-mode encapsulated messages is as follows. Support for this encapsulation is REQUIRED.
信号メッセージがMRIによって定義されたフローと同じ（「下流」）方向に移動している場合、Qモードカプセル化されたメッセージのIPアドレス指定は次のとおりです。このカプセル化のサポートが必要です。
o The destination IP address MUST be the flow destination address as given in the MRI of the message payload.
o 宛先IPアドレスは、メッセージペイロードのMRIに与えられたフロー宛先アドレスでなければなりません。
o By default, the source address is the flow source address, again from the MRI; therefore, the source addressing mode flag in the common header S=0. This provides the best likelihood that the message will be correctly routed through any region performing per-packet policy-based forwarding or load balancing that takes the source address into account. However, there may be circumstances where the use of the signalling source address (S=1) is preferable, such as:
o デフォルトでは、ソースアドレスはMRIからのフローソースアドレスです。したがって、共通ヘッダーS = 0のソースアドレス指定モードフラグ。これにより、ペケットごとのポリシーベースの転送またはロードバランシングを実行する任意の地域を介してメッセージが正しくルーティングされる可能性が最も高くなり、ソースアドレスを考慮します。ただし、次のようなシグナリングソースアドレス（S = 1）の使用が望ましい状況がある場合があります。
* In order to receive ICMP error messages about the signalling message, such as unreachable port or address. If these are delivered to the flow source rather than the signalling source, it will be very difficult for the querying node to detect that it is the last GIST node on the path. Another case is where there is an abnormally low MTU along the path, in which case the querying node needs to see the ICMP error (recall that Q-mode packets are sent with DF set).
* 到達不可能なポートやアドレスなど、信号メッセージに関するICMPエラーメッセージを受信するため。これらが信号ソースではなくフローソースに配信される場合、クエリノードがパス上の最後のGISTノードであることを検出することは非常に困難です。別のケースは、パスに沿って異常に低いMTUがある場合です。その場合、クエリノードはICMPエラーを確認する必要があります（QモードパケットがDFセットで送信されることを思い出してください）。
* In order to receive GIST Error messages where the error message sender could not interpret the NLI in the original message.
* エラーメッセージ送信者が元のメッセージでNLIを解釈できなかったGISTエラーメッセージを受信するため。
* In order to attempt to run GIST through an unmodified NAT, which will only process and translate IP addresses in the IP header (see Section 7.2.1).
* 変更されていないNATを通してGISTを実行しようとするために、IPヘッダーのIPアドレスのみを処理および変換します（セクション7.2.1を参照）。
Because of these considerations, use of the signalling source address is allowed as an option, with use based on local policy. A node SHOULD use the flow source address for initial Query messages, but SHOULD transition to the signalling source address for some retransmissions or as a matter of static configuration, for example, if a NAT is known to be in the path out of a certain interface. The S-flag in the common header tells the message receiver which option was used.
これらの考慮事項のため、ローカルポリシーに基づいて使用して、シグナリングソースアドレスの使用がオプションとして許可されています。ノードは、初期クエリメッセージにフローソースアドレスを使用する必要がありますが、たとえば、NATが特定のインターフェイスのパスにあることがわかっている場合など、一部の再送信の場合、または静的構成の問題として信号ソースアドレスに移行する必要があります。。共通ヘッダーのS-Flagは、メッセージ受信機にどのオプションが使用されたかを伝えます。
A Router Alert Option is also included in the IP header. The option value depends on the NSLP being signalled for. In addition, it is essential that the Query mimics the actual data flow as closely as possible, since this is the basis of how the signalling message is attached to the data path. To this end, GIST SHOULD set the Diffserv codepoint and (for IPv6) flow label to match the values in the MRI.
ルーターアラートオプションもIPヘッダーに含まれています。オプション値は、NSLPが信号を受けることに依存します。さらに、クエリは、信号メッセージがデータパスに添付される方法の基礎であるため、実際のデータフローを可能な限り密接に模倣することが不可欠です。この目的のために、GISTはDiffServ CodePointと（IPv6の場合）FlowラベルをMRIの値に一致させるように設定する必要があります。
A GIST implementation SHOULD apply validation checks to the MRI, to reject Query messages that are being injected by nodes with no legitimate interest in the flow being signalled for. In general, if the GIST node can detect that no flow could arrive over the same interface as the Query, it MUST be rejected with an appropriate error message. Such checks apply only to messages with the Q-mode encapsulation, since only those messages are required to track the flow path. The main checks are that the IP version used in the encapsulation should match that of the MRI and the version(s) used on that interface, and that the full range of source addresses (the source-address masked with its prefix-length) would pass ingress filtering checks. For these cases, the error message is "MRI Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP Version Mismatch" or "Ingress Filter Failure"), respectively.
GISTの実装では、検証チェックをMRIに適用して、信号されているフローに正当な関心のないノードによって注入されているクエリメッセージを拒否する必要があります。一般に、GISTノードがクエリと同じインターフェイスに到達できないことを検出できる場合、適切なエラーメッセージで拒否する必要があります。このようなチェックは、フローパスを追跡するために必要なメッセージのみが必要なため、Qモードカプセル化のメッセージにのみ適用されます。主なチェックは、カプセル化で使用されているIPバージョンがMRIのそれとそのインターフェイスで使用されるバージョンのバージョンと一致する必要があり、ソースアドレスの全範囲（そのプレフィックスレングスでマスクされたソースアドレス）はイングレスフィルタリングチェックを渡します。これらの場合、エラーメッセージは「MRI検証障害」（付録A.4.4.12）で、サブコード1または2（「IPバージョンのミスマッチ」または「イングレスフィルター障害」）を使用します。
In some deployment scenarios, it is desirable to set up routing state in the upstream direction (i.e., from flow receiver towards the sender). This could be used to support firewall signalling to control traffic from an uncooperative sender, or signalling in general where the flow sender was not NSIS-capable. This capability is incorporated into GIST by defining an encapsulation and processing rules for sending Query messages upstream.
いくつかの展開シナリオでは、上流の方向にルーティング状態を設定することが望ましいです（つまり、フローレシーバーから送信者へ）。これは、非協力的な送信者からのトラフィックを制御するためのファイアウォールシグナリングをサポートするために使用できます。この機能は、クエリメッセージを上流に送信するためのカプセル化および処理ルールを定義することにより、GISTに組み込まれます。
In general, it is not possible to determine the hop-by-hop route upstream because of asymmetric IP routing. However, in particular cases, the upstream peer can be discovered with a high degree of confidence, for example:
一般に、非対称IPルーティングのために上流のホップバイホップルートを決定することはできません。ただし、特に、上流のピアは、高度な自信を持って発見することができます。たとえば、：
o The upstream GIST peer is one IP hop away, and can be reached by tracing back through the interface on which the flow arrives.
o 上流のGISTピアは1つのIPホップアウェイであり、フローが到着するインターフェイスをトレースバックすることで到達できます。
o The upstream peer is a border router of a single-homed (stub) network.
o 上流のピアは、シングルホーム（スタブ）ネットワークのボーダールーターです。
This section defines an upstream Q-mode encapsulation and validation checks for when it can be used. The functionality to generate upstream Queries is OPTIONAL, but if received they MUST be processed in the normal way with some additional IP TTL checks. No special functionality is needed for this.
このセクションでは、上流のQモードカプセル化と検証チェックを使用することを定義します。上流クエリを生成する機能はオプションですが、受信した場合は、追加のIP TTLチェックを使用して通常の方法で処理する必要があります。これには特別な機能は必要ありません。
It is possible for routing state at a given node, for a specific MRI and NSLPID, to be created by both an upstream Query exchange (initiated by the node itself) and a downstream Query exchange (where the node is the responder). If the SIDs are different, these items of routing state MUST be considered as independent; if the SIDs match, the routing state installed by the downstream exchange MUST take precedence, provided that the downstream Query passed ingress filtering checks. The rationale for this is that the downstream Query is in general a more reliable way to install state, since it directly probes the IP routing infrastructure along the flow path, whereas use of the upstream Query depends on the correctness of the Querying node's understanding of the topology.
特定のノードで状態をルーティングし、特定のMRIおよびNSLPIDの場合、アップストリームクエリエクスチェンジ（ノード自体によって開始）とダウンストリームクエリエクスチェンジ（ノードが応答者である場合）の両方によって作成される可能性があります。SIDが異なる場合、これらのルーティング状態の項目は独立と見なされる必要があります。SIDSが一致する場合、下流のクエリがイングレスフィルタリングチェックに合格した場合、下流の交換によってインストールされたルーティング状態が優先される必要があります。これの理論的根拠は、ダウンストリームクエリは一般に、フローパスに沿ってIPルーティングインフラストラクチャを直接プローブするのに対し、上流クエリの使用はクエリノードのクエリノードの理解の正確性に依存するため、状態をインストールするためのより信頼性の高い方法であることです。トポロジー。
The details of the encapsulation are as follows:
カプセル化の詳細は次のとおりです。
o The destination address SHOULD be the flow source address as given in the MRI of the message payload. An implementation with more detailed knowledge of local IP routing MAY use an alternative destination address (e.g., the address of its default router).
o 宛先アドレスは、メッセージペイロードのMRIに与えられたフローソースアドレスである必要があります。ローカルIPルーティングのより詳細な知識を持つ実装では、代替の宛先アドレス（デフォルトルーターのアドレスなど）を使用する場合があります。
o The source address SHOULD be the signalling node address, so in the common header S=1.
o ソースアドレスはシグナリングノードアドレスである必要があるため、共通ヘッダーS = 1では。
o A Router Alert Option is included as in the downstream case.
o ダウンストリームケースのように、ルーターアラートオプションが含まれています。
o The Diffserv codepoint and (for IPv6) flow label MAY be set to match the values from the MRI as in the downstream case, and the UDP port selection is also the same.
o DiffServ CodePointと（IPv6の場合）フローラベルは、下流の場合と同様にMRIの値と一致するように設定されている場合があり、UDPポートの選択も同じです。
o The IP layer TTL of the message MUST be set to 255.
o メッセージのIPレイヤーTTLは255に設定する必要があります。
The sending GIST implementation SHOULD attempt to send the Query via the same interface and to the same link layer neighbour from which the data packets of the flow are arriving.
送信GIST実装は、同じインターフェイスを介してクエリを送信し、フローのデータパケットが到着している同じリンクレイヤーネイバーに送信しようとする必要があります。
The receiving GIST node MAY apply validation checks to the message and MRI, to reject Query messages that have reached a node at which they can no longer be trusted. In particular, a node SHOULD reject a message that has been propagated more than one IP hop, with an "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can be determined by examining the received IP layer TTL, similar to the generalised IP TTL security mechanism described in [41].
受信GISTノードは、検証チェックをメッセージとMRIに適用して、信頼できなくなったノードに到達したクエリメッセージを拒否する場合があります。特に、ノードは、「無効なIPレイヤーTTL」エラーメッセージ（付録A.4.4.11）を使用して、複数のIPホップが伝播されたメッセージを拒否する必要があります。これは、[41]で説明されている一般化IP TTLセキュリティメカニズムと同様に、受信したIPレイヤーTTLを調べることで決定できます。
Alternatively, receipt of an upstream Query at the flow source MAY be used to trigger setup of GIST state in the downstream direction. These restrictions may be relaxed in a future version.
あるいは、フローソースで上流クエリの受信を使用して、下流方向のGIST状態のセットアップをトリガーすることもできます。これらの制限は、将来のバージョンでリラックスする可能性があります。
The Loose-End MRM is used to discover GIST nodes with particular properties in the direction of a given address, for example, to discover a NAT along the upstream data path as in [34].
ルーズエンドMRMは、[34]のように上流のデータパスに沿ってNATを発見するなど、特定のアドレスの方向に特定の特性を持つGISTノードを発見するために使用されます。
For the loose-end MRM, only a simplified version of the Flow Identifier is needed.
ルーズエンドMRMの場合、単純化されたバージョンのフロー識別子のみが必要です。
MRI = network-layer-version source-address destination-address
MRI = Network-Layer-version Source-Address Destination-Address
The source address is the address of the node initiating the discovery process, for example, the node that will be the data receiver in the NAT discovery case. The destination address is the address of a node that is expected to be the other side of the node to be discovered. Additional control information defines the direction of the message relative to this flow as in the path-coupled case.
ソースアドレスは、発見プロセスを開始するノードのアドレスです。たとえば、NATディスカバリーケースのデータ受信機となるノードです。宛先アドレスは、発見されるノードの反対側になると予想されるノードのアドレスです。追加の制御情報は、パス結合した場合のように、このフローに対するメッセージの方向を定義します。
Only one encapsulation is defined for the loose-end MRM; by convention, this is referred to as the downstream encapsulation, and is defined as follows:
ルーズエンドMRMに対して定義されているカプセル化は1つだけです。慣習により、これは下流のカプセル化と呼ばれ、次のように定義されます。
o The IP destination address MUST be the destination address as given in the MRI of the message payload.
o IP宛先アドレスは、メッセージペイロードのMRIに与えられた宛先アドレスでなければなりません。
o By default, the IP source address is the source address from the MRI (S=0). However, the use of the signalling source address (S=1) is allowed as in the case of the path-coupled MRM.
o デフォルトでは、IPソースアドレスはMRI（S = 0）のソースアドレスです。ただし、シグナリングソースアドレス（S = 1）の使用は、パス結合されたMRMの場合のように許可されています。
A Router Alert Option is included in the IP header. The option value depends on the NSLP being signalled for. There are no special requirements on the setting of the Diffserv codepoint, IP layer TTL, or (for IPv6) the flow label. Nor are any special validation checks applied.
ルーターアラートオプションがIPヘッダーに含まれています。オプション値は、NSLPが信号を受けることに依存します。DiffServ CodePoint、IPレイヤーTTL、または（IPv6の場合）フローラベルの設定に関する特別な要件はありません。特別な検証チェックも適用されません。
This section provides a more formal specification of the operation of GIST processing, in terms of rules for transitions between states of a set of communicating state machines within a node. The following description captures only the basic protocol specification; additional mechanisms can be used by an implementation to accelerate route change processing, and these are captured in Section 7.1. A more detailed description of the GIST protocol operation in state machine syntax can be found in [45].
このセクションでは、ノード内の通信状態マシンのセットの状態間の遷移に関するルールの観点から、GIST処理の操作をより正式に仕様することを提供します。次の説明は、基本的なプロトコル仕様のみをキャプチャします。追加のメカニズムは、ルート変更処理を加速するために実装によって使用でき、これらはセクション7.1でキャプチャされます。ステートマシンの構文におけるGISTプロトコル操作のより詳細な説明は、[45]に記載されています。
Conceptually, GIST processing at a node may be seen in terms of four types of cooperating state machine:
概念的には、ノードでの要点処理は、4種類の協力状態マシンに関して見られる場合があります。
1. There is a top-level state machine that represents the node itself (Node-SM). It is responsible for the processing of events that cannot be directed towards a more specific state machine, for example, inbound messages for which no routing state currently exists. This machine exists permanently, and is responsible for creating per-MRI state machines to manage the GIST handshake and routing state maintenance procedures.
1. ノード自体（ノードSM）を表すトップレベルの状態マシンがあります。たとえば、より具体的な状態マシンに向けられないイベントの処理を担当します。たとえば、ルーティング状態が現在存在しないインバウンドメッセージです。このマシンは永続的に存在し、GISTハンドシェイクとルーティング状態のメンテナンス手順を管理するために、MRIあたりのマシンを作成する責任があります。
2. For each flow and signalling direction where the node is responsible for the creation of routing state, there is an instance of a Query-Node state machine (Querying-SM). This machine sends Query and Confirm messages and waits for Responses, according to the requirements from local API commands or timer processing, such as message repetition or routing state refresh.
2. ノードがルーティング状態の作成に責任を負う各フローと信号方向について、クエリノード状態マシン（Querying-SM）のインスタンスがあります。このマシンは、メッセージの繰り返しやルーティング状態の更新などのローカルAPIコマンドまたはタイマー処理の要件に従って、クエリを送信してメッセージを送信し、応答を確認します。
3. For each flow and signalling direction where the node has accepted the creation of routing state by a peer, there is an instance of a Responding-Node state machine (Responding-SM). This machine is responsible for managing the status of the routing state for that flow. Depending on policy, it MAY be responsible for transmission or retransmission of Response messages, or this MAY be handled by the Node-SM, and a Responding-SM is not even created for a flow until a properly formatted Confirm has been accepted.
3. ノードがピアによってルーティング状態の作成を受け入れた各フローと信号方向について、応答ノード状態マシン（応答SM）のインスタンスがあります。このマシンは、そのフローのルーティング状態のステータスを管理する責任があります。ポリシーに応じて、応答メッセージの送信または再送信に責任がある場合があります。これは、ノードSMによって処理される場合があり、適切にフォーマットされた確認が受け入れられるまで、フロー用に応答するSMは作成されません。
4. Messaging associations have their own lifecycle, represented by an MA-SM, from when they are first created (in an incomplete state, listening for an inbound connection or waiting for outbound connections to complete), to when they are active and available for use.
4. メッセージングアソシエーションには、MA-SMで表される独自のライフサイクルがあります。最初に作成されたとき（不完全な状態で、インバウンド接続を聞いたり、アウトバウンド接続が完了するのを待ったり）、アクティブで使用可能なときまで。
Apart from the fact that the various machines can be created and destroyed by each other, there is almost no interaction between them. The machines for different flows do not interact; the Querying-SM and Responding-SM for a single flow and signalling direction do not interact. That is, the Responding-SM that accepts the creation of routing state for a flow on one interface has no direct interaction with the Querying-SM that sets up routing state on the next interface along the path. This interaction is mediated instead through the NSLP.
さまざまなマシンを互いに作成して破壊できるという事実は別として、それらの間にはほとんど相互作用がありません。さまざまなフローのマシンは相互作用しません。単一のフローとシグナルの方向のクエリSMおよび応答SMは相互作用しません。つまり、1つのインターフェイス上のフローのルーティング状態の作成を受け入れる応答SMには、パスに沿った次のインターフェイスにルーティング状態を設定するクエリSMとの直接的な相互作用はありません。この相互作用は、代わりにNSLPを介して媒介されます。
The state machine descriptions use the terminology rx_MMMM, tg_TTTT, and er_EEEE for incoming messages, API/lower layer triggers, and error conditions, respectively. The possible events of these types are given in the table below. In addition, timeout events denoted to_TTTT may also occur; the various timers are listed independently for each type of state machine in the following subsections.
ステートマシンの説明は、着信メッセージ、API/下層トリガー、およびエラー条件にそれぞれ用語RX_MMMM、TG_TTTT、およびER_EEEEを使用します。これらのタイプの可能なイベントは、以下の表に記載されています。さらに、to_ttttと示されたタイムアウトイベントも発生する可能性があります。さまざまなタイマーは、次のサブセクションで各タイプの状態マシンについて独立してリストされています。
+---------------------+---------------------------------------------+
| Name | Meaning |
+---------------------+---------------------------------------------+
| rx_Query | A Query has been received. |
| | |
| rx_Response | A Response has been received. |
| | |
| rx_Confirm | A Confirm has been received. |
| | |
| rx_Data | A Data message has been received. |
| | |
| rx_Message | rx_Query||rx_Response||rx_Confirm||rx_Data. |
| | |
| rx_MA-Hello | An MA-Hello message has been received. |
| | |
| tg_NSLPData | A signalling application has requested data |
| | transfer (via API SendMessage). |
| | |
| tg_Connected | The protocol stack for a messaging |
| | association has completed connecting. |
| | |
| tg_RawData | GIST wishes to transfer data over a |
| | particular messaging association. |
| | |
| tg_MAIdle | GIST decides that it is no longer necessary |
| | to keep an MA open for itself. |
| | |
| er_NoRSM | A "No Routing State" error was received. |
| | |
| er_MAConnect | A messaging association protocol failed to |
| | complete a connection. |
| | |
| er_MAFailure | A messaging association failed. |
+---------------------+---------------------------------------------+
Incoming Events
着信イベント
The Node-level state machine is responsible for processing events for which no more appropriate messaging association state or routing state exists. Its structure is trivial: there is a single state ('Idle'); all events cause a transition back to Idle. Some events cause the creation of other state machines. The only events that are processed by this state machine are incoming GIST messages (Query/ Response/Confirm/Data) and API requests to send data; no other events are possible. In addition to this event processing, the Node-level machine is responsible for managing listening endpoints for messaging associations. Although these relate to Responding node operation, they cannot be handled by the Responder state machine since they are not created per flow. The processing rules for each event are as follows:
ノードレベルの状態マシンは、適切なメッセージング関連状態またはルーティング状態が存在するイベントを処理する責任があります。その構造は些細なものです。単一の状態（「アイドル」）があります。すべてのイベントにより、トランジションがアイドル状態になります。一部のイベントは、他の州のマシンの作成を引き起こします。この状態マシンによって処理される唯一のイベントは、着信GISTメッセージ（クエリ/応答/確認/データ）とデータの送信のAPI要求です。他のイベントは不可能です。このイベント処理に加えて、ノードレベルのマシンは、メッセージング関連のリスニングエンドポイントの管理を担当します。これらは応答するノード操作に関連していますが、フローごとに作成されていないため、レスポンダー状態マシンで処理することはできません。各イベントの処理ルールは次のとおりです。
Rule 1 (rx_Query): use the GIST service interface to determine the signalling application policy relating to this peer // note that this interaction delivers any NSLP-Data to // the NSLP as a side effect if (the signalling application indicates that routing state should be created) then if (routing state can be created without a 3-way handshake) then create Responding-SM and transfer control to it else send Response with R=1 else propagate the Query with any updated NSLP payload provided
ルール1（RX_QUERY）：GISTサービスインターフェイスを使用して、このピアに関連するシグナリングアプリケーションポリシーを決定します//この相互作用は、nslp-dataを// nslpに副作用として配信することに注意してください（シグナリングアプリケーションはルーティング状態を示します。（3方向の握手なしでルーティング状態を作成できる）その後、応答SMを作成してそれを転送する場合、r = 1で応答を送信します。
Rule 2 (rx_Response): // a routing state error discard message
ルール2（RX_RESPONSE）：//ルーティング状態エラー廃棄メッセージ
Rule 3 (rx_Confirm): if (routing state can be created before receiving a Confirm) then // we should already have Responding-SM for it, // which would handle this message discard message send "No Routing State" error message else create Responding-SM and pass message to it
ルール3（RX_CONFIRM）：（確認の受信前にルーティング状態を作成できる場合）// //このメッセージを処理する//「ルーティング状態なし」エラーメッセージを送信するこのメッセージを処理する//応答するSMとそれにメッセージを渡します
Rule 4 (rx_Data): if (node policy will only process Data messages with matching routing state) then send "No Routing State" error message else pass directly to NSLP
ルール4（RX_DATA）：if（ノードポリシーは一致するルーティング状態でデータメッセージのみを処理します）その後、「ルーティング状態なし」エラーメッセージを送信
Rule 4 (er_NoRSM): discard the message Rule 5 (tg_NSLPData): if Q-mode encapsulation is not possible for this MRI reject message with an error else if (local policy & transfer attributes say routing state is not needed) then send message statelessly else create Querying-SM and pass message to it
ルール4（ER_NORSM）：メッセージルール5（TG_NSLPDATA）を破棄します：Qモードのカプセル化がこのMRI拒否メッセージに対してエラーを拒否していない場合（ローカルポリシーと転送属性はルーティング状態が必要ないと言う）、メッセージを統計的に送信しますそれ以外の場合は、クエリSMを作成し、メッセージを渡します
The Querying-Node state machine (Querying-SM) has three states:
クエリノード状態マシン（Querying-SM）には3つの状態があります。
o Awaiting Response
o 応答を待っています
o Established
o 設立
o Awaiting Refresh
o リフレッシュを待っています
The Querying-SM is created by the Node-SM machine as a result of a request to send a message for a flow in a signalling direction where the appropriate state does not exist. The Query is generated immediately and the No_Response timer is started. The NSLP data MAY be carried in the Query if local policy and the transfer attributes allow it; otherwise, it MUST be queued locally pending MA establishment. Then the machine transitions to the Awaiting Response state, in which timeout-based retransmissions are handled. Data messages (rx_Data events) should not occur in this state; if they do, this may indicate a lost Response and a node MAY retransmit a Query for this reason.
クエリSMは、適切な状態が存在しない信号方向のフローのメッセージを送信するリクエストの結果として、ノード-SMマシンによって作成されます。クエリはすぐに生成され、NO_RESPONSEタイマーが開始されます。NSLPデータは、ローカルポリシーと転送属性が許可されている場合、クエリに掲載される場合があります。それ以外の場合は、MA施設が保留中の地元でキューに留められている必要があります。次に、マシンは、タイムアウトベースの再送信が処理される待望の応答状態に移行します。データメッセージ（RX_DATAイベント）は、この状態では発生しないでください。もしそうなら、これは失われた応答を示している可能性があり、ノードはこの理由でクエリを再送信する場合があります。
Once a Response has been successfully received and routing state created, the machine transitions to Established, during which NSLP data can be sent and received normally. Further Responses received in this state (which may be the result of a lost Confirm) MUST be treated the same way. The Awaiting Refresh state can be considered as a substate of Established, where a new Query has been generated to refresh the routing state (as in Awaiting Response) but NSLP data can be handled normally.
応答が正常に受信され、ルーティング状態が作成されると、マシンは確立され、その間にNSLPデータを正常に送信および受信できます。この状態で受け取ったさらなる回答（これは、失われた確認の結果である可能性があります）を同じように扱う必要があります。待ち望まれている更新状態は、ルーティング状態を更新するために新しいクエリが生成された（応答を待っているように）確立されたサブサンと見なすことができますが、NSLPデータは正常に処理できます。
The timers relevant to this state machine are as follows:
この状態マシンに関連するタイマーは次のとおりです。
Refresh_QNode: Indicates when the routing state stored by this state machine must be refreshed. It is reset whenever a Response is received indicating that the routing state is still valid. Implementations MUST set the period of this timer based on the value in the RS-validity-time field of a Response to ensure that a Query is generated before the peer's routing state expires (see Section 4.4.4).
REFRESH_QNODE：この状態マシンによって保存されているルーティング状態を更新する必要があることを示します。ルーティング状態がまだ有効であることを示す応答が受信されるたびにリセットされます。実装は、ピアのルーティング状態が期限切れになる前にクエリが生成されることを確認するために、応答のRS有効性時間フィールドの値に基づいてこのタイマーの期間を設定する必要があります（セクション4.4.4を参照）。
No_Response: Indicates that a Response has not been received in answer to a Query. This is started whenever a Query is sent and stopped when a Response is received.
no_response：クエリに応答して応答が受信されていないことを示します。これは、クエリが送信されるたびに開始され、応答が受信されたときに停止します。
Inactive_QNode: Indicates that no NSLP traffic is currently being handled by this state machine. This is reset whenever the state machine handles NSLP data, in either direction. When it expires, the state machine MAY be deleted. The period of the timer can be set at any time via the API (SetStateLifetime), and if the period is reset in this way the timer itself MUST be restarted.
Inactive_Qnode：現在、この状態マシンによってNSLPトラフィックが処理されていないことを示します。これは、状態マシンがいずれかの方向でNSLPデータを処理するたびにリセットされます。有効期限が切れると、状態マシンが削除される場合があります。タイマーの期間は、API（setStateLifetime）を介していつでも設定できます。また、この方法で期間がリセットされている場合は、タイマー自体を再起動する必要があります。
The main events (including all those that cause state transitions) are shown in the figure below, tagged with the number of the processing rule that is used to handle the event. These rules are listed after the diagram. All events not shown or described in the text above are assumed to be impossible in a correct implementation and MUST be ignored.
メインイベント（状態遷移を引き起こすすべてのものを含む）は、イベントの処理に使用される処理ルールの数でタグ付けされた下の図に示されています。これらのルールは、図の後にリストされています。上記のテキストに示されていないか説明されていないすべてのイベントは、正しい実装では不可能であると想定されており、無視する必要があります。
[Initialisation] +-----+
-------------------------|Birth|
| +-----+
| er_NoRSM[3](from all states) rx_Response[4]
| || tg_NSLPData[5]
| tg_NSLPData[1] || rx_Data[7]
| -------- -------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | |Established|
------| Response |---------------------------->> | |
| +----------+ rx_Response[4] +-----------+
| ^ | ^ |
| ^ | ^ |
| -------- | |
| to_No_Response[2] | |
| [!nResp_reached] tg_NSLPData[5] | |
| || rx_Data[7] | |
| -------- | |
| | V | |
| to_No_Response[2] | V | |
| [nResp_reached] +-----------+ rx_Response[4] | |
---------- -----------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ to_Refresh_QNode[8]
| | ^ |
V V ^ | to_No_Response[2]
V V -------- [!nResp_reached]
+-----+
|Death|<<---------------
+-----+ to_Inactive_QNode[6]
(from all states)
Figure 7: Query Node State Machine
図7：クエリノード状態マシン
The processing rules are as follows:
処理ルールは次のとおりです。
Rule 1: Store the message for later transmission
ルール1：メッセージを後で送信するために保存します
Rule 2: if number of Queries sent has reached the threshold // nQuery_isMax is true indicate No Response error to NSLP destroy self else send Query start No_Response timer with new value
ルール2：送信されたクエリの数がしきい値に達した場合// nquery_ismaxが真であることを示しますnslpはnslpを破壊する応答エラーを示します。
Rule 3: // Assume the Confirm was lost in transit or the peer has reset; // restart the handshake send Query (re)start No_Response timer
ルール3：//確認が輸送中に失われたか、ピアがリセットされていると仮定します。//ハンドシェイクを再起動しますクエリを送信（再）no_responseタイマーを開始します
Rule 4: if a new MA-SM is needed create one if the R-flag was set send a Confirm send any stored Data messages stop No_Response timer start Refresh_QNode timer start Inactive_QNode timer if it was not running if there was piggybacked NSLP-Data pass it to the NSLP restart Inactive_QNode timer
ルール4：新しいMA-SMが必要な場合は、R-FLAGが設定された場合に1つを作成します。nslpを再起動しますinactive_qnodeタイマー
Rule 5: send Data message restart Inactive_QNode timer
ルール5：データメッセージの送信inactive_qnodeタイマーを再起動します
Rule 6: Terminate
ルール6：終了します
Rule 7: pass any data to the NSLP restart Inactive_QNode timer
ルール7：データをnslpに渡すinactive_qnodeタイマーを再起動します
Rule 8: send Query start No_Response timer stop Refresh_QNode timer
ルール8：クエリの送信no_responseタイマー停止refresh_qnodeタイマー
The Responding-Node state machine (Responding-SM) has three states:
Responsing-Node State Machine（Responsing-SM）には3つの状態があります。
o Awaiting Confirm
o 待っていることを確認します
o Established
o 設立
o Awaiting Refresh
o リフレッシュを待っています
The policy governing the handling of Query messages and the creation of the Responding-SM has three cases:
クエリメッセージの処理を管理するポリシーとResponsing-SMの作成には3つのケースがあります。
1. No Confirm is required for a Query, and the state machine can be created immediately.
1. クエリには確認は必要ありません。また、状態マシンをすぐに作成できます。
2. A Confirm is required for a Query, but the state machine can still be created immediately. A timer is used to retransmit Response messages and the Responding-SM is destroyed if no valid Confirm is received.
2. クエリには確認が必要ですが、状態マシンはすぐに作成できます。タイマーは応答メッセージを再送信するために使用され、有効な確認が受信されないと応答するSMが破壊されます。
3. A Confirm is required for a Query, and the state machine can only be created when it is received; the initial Query will have been handled by the Node-level machine.
3. クエリには確認が必要であり、状態マシンは受信したときにのみ作成できます。初期クエリは、ノードレベルのマシンによって処理されます。
In case 2, the Responding-SM is created in the Awaiting Confirm state, and remains there until a Confirm is received, at which point it transitions to Established. In cases 1 and 3, the Responding-SM is created directly in the Established state. Note that if the machine is created on receiving a Query, some of the message processing will already have been performed in the node state machine. In principle, an implementation MAY change its policy on handling a Query message at any time; however, the state machine descriptions here cover only the case where the policy is fixed while waiting for a Confirm message.
ケース2では、応答性のあるSMが待機中の確認状態に作成され、確認が受信されるまでそこに残り、その時点で確立されます。ケース1および3では、応答するSMは確立された状態で直接作成されます。クエリの受信時にマシンが作成されている場合、メッセージ処理の一部は既にノード状態マシンで実行されていることに注意してください。原則として、実装は、いつでもクエリメッセージを処理することに関するポリシーを変更する場合があります。ただし、ここでの状態マシンの説明は、確認メッセージを待っている間にポリシーが修正されている場合のみをカバーしています。
In the Established state, the NSLP can send and receive data normally, and any additional rx_Confirm events MUST be silently ignored. The Awaiting Refresh state can be considered a substate of Established, where a Query has been received to begin the routing state refresh. In the Awaiting Refresh state, the Responding-SM behaves as in the Awaiting Confirm state, except that the NSLP can still send and receive data. In particular, in both states there is timer-based retransmission of Response messages until a Confirm is received; additional rx_Query events in these states MUST also generate a reply and restart the no_Confirm timer.
確立された状態では、NSLPは正常にデータを送信および受信でき、追加のRX_CONFIRMイベントは静かに無視する必要があります。待機中の更新状態は、ルーティング状態の更新を開始するためにクエリが受信された確立された物質と見なすことができます。待ち望まれている更新状態では、NSLPがデータを送信および受信できることを除いて、対応するSMは待機中の状態のように動作します。特に、両方の州では、確認が受信されるまで、回答メッセージのタイマーベースの再送信があります。これらの状態での追加のRX_Queryイベントも、返信を生成し、NO_CONFIRMタイマーを再起動する必要があります。
The timers relevant to the operation of this state machine are as follows:
この状態マシンの動作に関連するタイマーは次のとおりです。
Expire_RNode: Indicates when the routing state stored by this state machine needs to be expired. It is reset whenever a Query or Confirm (depending on local policy) is received indicating that the routing state is still valid. Note that state cannot be refreshed from the R-Node. If this timer fires, the routing state machine is deleted, regardless of whether a No_Confirm timer is running.
expire_rnode：この状態マシンによって保存されているルーティング状態を期限切れにする必要があることを示します。ルーティング状態がまだ有効であることを示すクエリまたは確認（ローカルポリシーに応じて）が受信されるたびにリセットされます。Rノードから状態をリフレッシュできないことに注意してください。このタイマーが発射すると、NO_CONFIRMタイマーが実行されているかどうかにかかわらず、ルーティング状態マシンが削除されます。
No_Confirm: Indicates that a Confirm has not been received in answer to a Response. This is started/reset whenever a Response is sent and stopped when a Confirm is received.
NO_CONFIRM：応答に応答して確認が受信されていないことを示します。これは、応答が送信されるたびに起動/リセットされ、確認が受信されたときに停止します。
The detailed state transitions and processing rules are described below as in the Query node case.
詳細な状態遷移および処理ルールは、クエリノードの場合のように以下で説明されています。
rx_Query[1] rx_Query[5]
[confirmRequired] +-----+ [!confirmRequired]
-------------------------|Birth|----------------------------
| +-----+ |
| | rx_Confirm[2] |
| ---------------------------- |
| | |
| rx_Query[5] | |
| tg_NSLPData[7] || rx_Confirm[10] | |
| || rx_Query[1] || rx_Data[4] | |
| || rx_Data[6] || tg_NSLPData[3] | |
| -------- -------------- | |
| | V | V V V
| | V | V V V
| +----------+ | +-----------+
---->>| Awaiting | rx_Confirm[8] -----------|Established|
------| Confirm |------------------------------>> | |
| +----------+ +-----------+
| ^ | ^ |
| ^ | tg_NSLPData[3] ^ |
| -------- || rx_Query[1] | |
| to_No_Confirm[9] || rx_Data[4] | |
| [!nConf_reached] -------- | |
| | V | |
| to_No_Confirm[9] | V | |
| [nConf_reached] +-----------+ rx_Confirm[8] | |
---------- ------------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ rx_Query[1]
| | ^ | [confirmRequired]
| | ^ |
| | --------
V V to_No_Confirm[9]
V V [!nConf_reached]
+-----+
|Death|<<---------------------
+-----+ er_NoRSM[11]
to_Expire_RNode[11]
(from Established/Awaiting Refresh)
Figure 8: Responder Node State Machine
図8：レスポンダーノード状態マシン
The processing rules are as follows:
処理ルールは次のとおりです。
Rule 1: // a Confirm is required send Response with R=1 (re)start No_Confirm timer with the initial timer value
ルール1：//確認が必要ですr = 1（re）no_confirmタイマーを最初のタイマー値で送信します。
Rule 2: pass any NSLP-Data object to the NSLP start Expire_RNode timer
ルール2：nslp-dataオブジェクトをnslp start expire_rnodeタイマーに渡す
Rule 3: send the Data message
ルール3：データメッセージを送信します
Rule 4: pass data to NSLP
ルール4：データをNSLPに渡します
Rule 5: // no Confirm is required send Response with R=0 start Expire_RNode timer
ルール5：//確認は必要ありませんr = 0で応答を送信
Rule 6: drop incoming data send "No Routing State" error message
ルール6：着信データをドロップして、「ルーティング状態なし」エラーメッセージを送信します
Rule 7: store Data message
ルール7：データメッセージを保存します
Rule 8: pass any NSLP-Data object to the NSLP send any stored Data messages stop No_Confirm timer start Expire_RNode timer
ルール8：NSLP-DATAオブジェクトをNSLPに渡す任意の保存されたデータメッセージを送信
Rule 9: if number of Responses sent has reached threshold // nResp_isMax is true destroy self else send Response start No_Response timer
ルール9：送信された応答の数がしきい値に達した場合// nresp_ismaxが真の自己を破壊しますelse else send no_responseタイマーを送信
Rule 10: // can happen e.g., a retransmitted Response causes a duplicate Confirm silently ignore
ルール10：//は、たとえば、再送信された応答が重複することを発生する可能性があります。
Rule 11: destroy self
規則11：自己を破壊します
Messaging associations (MAs) are modelled for use within GIST with a simple three-state process. The Awaiting Connection state indicates that the MA is waiting for the connection process(es) for every protocol in the messaging association to complete; this might involve creating listening endpoints or attempting active connects. Timers may also be necessary to detect connection failure (e.g., no incoming connection within a certain period), but these are not modelled explicitly.
メッセージングアソシエーション（MAS）は、単純な3状態のプロセスでGIST内で使用するようにモデル化されています。待機中の接続状態は、MAがメッセージング協会のすべてのプロトコルが完了するために接続プロセスを待っていることを示しています。これには、リスニングエンドポイントの作成やアクティブな接続の試みが含まれる場合があります。また、接続の障害を検出するためにタイマーが必要になる場合があります（たとえば、特定の期間内に着信接続はありません）が、これらは明示的にモデル化されていません。
The Connected state indicates that the MA is open and ready to use and that the node wishes it to remain open. In this state, the node operates a timer (SendHello) to ensure that messages are regularly sent to the peer, to ensure that the peer does not tear down the MA. The node transitions from Connected to Idle (indicating that it no longer needs the association) as a matter of local policy; one way to manage the policy is to use an activity timer but this is not specified explicitly by the state machine (see also Section 4.4.5).
接続された状態は、MAが開いていて使用できること、およびノードが開いたままでいることを望んでいることを示しています。この状態では、ノードはタイマー（SendHello）を操作して、メッセージがピアに定期的に送信されるようにし、ピアがMAを取り壊さないようにします。ノードは、現地ポリシーの問題として、接続からアイドル状態からアイドル状態（関連性が必要ではないことを示す）に移行します。ポリシーを管理する1つの方法は、アクティビティタイマーを使用することですが、これは状態マシンによって明示的に指定されていません（セクション4.4.5も参照）。
In the Idle state, the node no longer requires the messaging association but the peer still requires it and is indicating this by sending periodic MA-Hello messages. A different timer (NoHello) operates to purge the MA when these messages stop arriving. If real data is transferred over the MA, the state machine transitions back to Connected.
アイドル状態では、ノードはメッセージングアソシエーションを必要としなくなりましたが、ピアはまだそれを必要とし、定期的なMA-Helloメッセージを送信することでこれを示しています。別のタイマー（nohello）が動作し、これらのメッセージが到着しなくなったときにMAをパージするように動作します。実際のデータがMAを介して転送されると、状態マシンは接続に戻ります。
At any time in the Connected or Idle states, a node MAY test the connectivity to its peer and the liveness of the GIST instance at that peer by sending an MA-Hello request with R=1. Failure to receive a reply with a matching Hello-ID within a timeout MAY be taken as a reason to trigger er_MAFailure. Initiation of such a test and the timeout setting are left to the discretion of the implementation. Note that er_MAFailure may also be signalled by indications from the underlying messaging association protocols. If a messaging association fails, this MUST be indicated back to the routing state machines that use it, and these MAY generate indications to signalling applications. In particular, if the messaging association was being used to deliver messages reliably, this MUST be reported as a NetworkNotification error (Appendix B.4).
接続された状態またはアイドル状態のいつでも、ノードは、r = 1でma-hello要求を送信することにより、そのピアへの接続とそのピアでのGISTインスタンスの活性をテストする場合があります。タイムアウト内で一致するHello-IDで返信を受け取らないことは、ER_Mafailureをトリガーする理由としてとられる場合があります。このようなテストとタイムアウト設定の開始は、実装の裁量に任されます。ER_MAFAILUREは、基礎となるメッセージング協会のプロトコルからの適応症によっても知らせることができることに注意してください。メッセージングアソシエーションが失敗した場合、これはそれを使用するルーティング状態マシンに戻る必要があり、これらはシグナリングアプリケーションの適応を生成する可能性があります。特に、メッセージングアソシエーションがメッセージを確実に配信するために使用されている場合、これはネットワーク選択エラーとして報告する必要があります（付録B.4）。
Clearly, many internal details of the messaging association protocols are hidden in this model, especially where the messaging association uses multiple protocol layers. Note also that although the existence of messaging associations is not directly visible to signalling applications, there is some interaction between the two because security-related information becomes available during the open process, and this may be indicated to signalling applications if they have requested it.
明らかに、メッセージングアソシエーションプロトコルの多くの内部詳細は、特にメッセージングアソシエーションが複数のプロトコルレイヤーを使用する場合、このモデルに隠されています。また、メッセージング関連の存在はシグナリングアプリケーションに直接表示されないが、セキュリティ関連の情報がオープンプロセス中に利用可能になるため、2つの間に何らかの相互作用があることに注意してください。
The timers relevant to the operation of this state machine are as follows:
この状態マシンの動作に関連するタイマーは次のとおりです。
SendHello: Indicates that an MA-Hello message should be sent to the remote node. The period of this timer is determined by the MA-Hold-Time sent by the remote node during the Query/Response/ Confirm exchange.
Sendhello：ma-helloメッセージをリモートノードに送信する必要があることを示します。このタイマーの期間は、クエリ/応答/確認交換中にリモートノードによって送信されるMAホルドタイムによって決定されます。
NoHello: Indicates that no MA-Hello has been received from the remote node for a period of time. The period of this timer is sent to the remote node as the MA-Hold-Time during the Query/ Response exchange.
Nohello：リモートノードから一定期間MA-Helloが受信されていないことを示します。このタイマーの期間は、クエリ/応答交換中にMAホルドタイムとしてリモートノードに送信されます。
The detailed state transitions and processing rules are described below as in the Query node case.
詳細な状態遷移および処理ルールは、クエリノードの場合のように以下で説明されています。
[Initialisation] +-----+
----------------------------|Birth|
| +-----+ tg_RawData[1]
| || rx_Message[2]
| || rx_MA-Hello[3]
| tg_RawData[5] || to_SendHello[4]
| -------- --------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | tg_Connected[6] | Connected |
------|Connection|----------------------->>| |
| +----------+ +-----------+
| ^ |
| tg_RawData[1] ^ |
| || rx_Message[2] | | tg_MAIdle[7]
| | V
| | V
| er_MAConnect[8] +-----+ to_NoHello[8] +-----------+
---------------->>|Death|<<----------------| Idle |
+-----+ +-----------+
^ ^ |
^ ^ |
--------------- --------
er_MAFailure[8] rx_MA-Hello[9]
(from Connected/Idle)
Figure 9: Messaging Association State Machine
図9：メッセージングアソシエーションステートマシン
The processing rules are as follows:
処理ルールは次のとおりです。
Rule 1: pass message to transport layer if the NoHello timer was running, stop it (re)start SendHello
ルール1：nohelloタイマーが実行されていた場合、輸送層にメッセージを渡す、停止（再）sendhelloを開始する
Rule 2: pass message to Node-SM, or R-SM (for a Confirm), or Q-SM (for a Response) if the NoHello timer was running, stop it
ルール2：ノード-SMまたはr-SM（確認用）またはq-sm（応答用）にメッセージを渡すこと
Rule 3: if reply requested send MA-Hello restart SendHello timer
ルール3：返信が要求された場合、ma-helloの再起動sendhelloタイマーを送信します
Rule 4: send MA-Hello message restart SendHello timer
ルール4：ma-helloメッセージを送信しますsendhelloタイマーを再起動します
Rule 5: queue message for later transmission
ルール5：後の送信用のキューメッセージ
Rule 6: pass outstanding queued messages to transport layer stop any timers controlling connection establishment start SendHello timer
ルール6：卓越したキュームメッセージを通過するレイヤー輸送レイヤーコントロール接続の確立を制御するタイマーを停止しますSendhelloタイマー
Rule 7: stop SendHello timer start NoHello timer
ルール7：Sendhelloタイマーを停止します
Rule 8: report failure to routing state machines and signalling applications destroy self
規則8：状態マシンをルーティングしないことを報告し、信号アプリケーションを自己を破壊する
Rule 9: if reply requested send MA-Hello restart NoHello timer
ルール9：返信が要求された場合、ma-helloの再起動nohelloタイマーを送信します
When IP layer rerouting takes place in the network, GIST and signalling application state need to be updated for all flows whose paths have changed. The updates to signalling application state depend mainly on the signalling application: for example, if the path characteristics have changed, simply moving state from the old to the new path is not sufficient. Therefore, GIST cannot complete the path update processing by itself. Its responsibilities are to detect the route change, update its local routing state consistently, and inform interested signalling applications at affected nodes.
ネットワークでIPレイヤーの再ルーティングが行われる場合、GISTおよびシグナリングアプリケーションの状態を、パスが変更されたすべてのフローについて更新する必要があります。信号アプリケーションの状態の更新は、主に信号アプリケーションに依存します。たとえば、パスの特性が変更された場合、単に古いパスから新しいパスに移動するだけでは十分ではありません。したがって、GISTはパス更新処理を単独で完了することはできません。その責任は、ルートの変更を検出し、ローカルルーティング状態を一貫して更新し、影響を受けるノードでの関心のあるシグナリングアプリケーションを通知することです。
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x +--+ +--+ +--+ x Initial
x .|C1|_.....|D1|_.....|E1| x Configuration
x . +--+. .+--+. .+--+\. x
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
+-+ +-+ . .. .. . +-+
...|A|_......|B|/ .. .. .|F|_....
+-+ +-+ . . . . . . +-+
. . . . . .
. +--+ +--+ +--+ .
.|C2|_.....|D2|_.....|E2|/
+--+ +--+ +--+
+--+ +--+ +--+ Configuration
.|C1|......|D1|......|E1| after failure
. +--+ .+--+ +--+ of E1-F link
. \. . \. ./
+-+ +-+ . .. .. +-+
...|A|_......|B|. .. .. .|F|_....
+-+ +-+\ . . . . . +-+
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
x . +--+ +--+ +--+ . x
x .|C2|_.....|D2|_.....|E2|/ x
x +--+ +--+ +--+ x
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
........... = physical link topology
>>xxxxxxx>> = flow direction
_.......... = outgoing link for flow xxxxxx given
by local forwarding table
Figure 10: A Rerouting Event
図10：再ルーティングイベント
Route change management is complicated by the distributed nature of the problem. Consider the rerouting event shown in Figure 10. An external observer can tell that the main responsibility for controlling the updates will probably lie with nodes B and F; however, E1 is best placed to detect the event quickly at the GIST level, and C1 and D1 could also attempt to initiate the repair.
ルート変更管理は、問題の分散的な性質によって複雑になります。図10に示す再ルーティングイベントを検討してください。外部オブザーバーは、更新を制御する主な責任がおそらくノードBとFにあることを知ることができます。ただし、E1はGISTレベルでイベントをすばやく検出するのに最適な場所であり、C1とD1も修理を開始しようとすることができます。
The NSIS framework [29] makes the assumption that signalling applications are soft-state based and operate end to end. In this case, because GIST also periodically updates its picture of routing state, route changes will eventually be repaired automatically. The specification as already given includes this functionality. However, especially if upper layer refresh times are extended to reduce signalling load, the duration of inconsistent state may be very long indeed. Therefore, GIST includes logic to exchange prompt notifications with signalling applications, to allow local repair if possible. The additional mechanisms to achieve this are described in the following subsections. To a large extent, these additions can be seen as implementation issues; the protocol messages and their significance are not changed, but there are extra interactions through the API between GIST and signalling applications, and additional triggers for transitions between the various GIST states.
NSISフレームワーク[29]は、シグナリングアプリケーションがソフトステートベースであり、端から端まで動作すると仮定します。この場合、GISTはルーティング状態の画像も定期的に更新するため、ルートの変更は最終的に自動的に修復されます。すでに与えられた仕様には、この機能が含まれています。ただし、特に上層の更新時間が延長されてシグナル伝達負荷が減少する場合、一貫性のない状態の持続時間は非常に長くなる可能性があります。したがって、GISTには、可能であればローカルの修理を許可するために、シグナリングアプリケーションとプロンプト通知を交換するロジックが含まれます。これを達成するための追加のメカニズムは、以下のサブセクションで説明されています。大部分は、これらの追加を実装の問題として見ることができます。プロトコルメッセージとそれらの重要性は変更されませんが、GISTアプリケーションとシグナリングアプリケーション間のAPIを介して追加の相互作用があり、さまざまなGIST状態間の遷移の追加トリガーがあります。
There are two aspects to detecting a route change at a single node:
単一のノードでルートの変更を検出するには、2つの側面があります。
o Detecting that the outgoing path, in the direction of the Query, has or may have changed.
o クエリの方向に発信パスが変更されたか、変更された可能性があることを検出します。
o Detecting that the incoming path, in the direction of the Response, has (or may have) changed, in which case the node may no longer be on the path at all.
o 応答の方向にある入っている経路が変更された（または変化した可能性がある）ことを検出すると、その場合、ノードはまったくパスにない可能性があります。
At a single node, these processes are largely independent, although clearly a change in one direction at a node corresponds to a change in the opposite direction at its peer. Note that there are two possible forms for a route change: the interface through which a flow leaves or enters a node may change, and the adjacent peer may change. In general, a route change can include one or the other or both (or indeed neither, although such changes are very hard to detect).
単一のノードでは、これらのプロセスはほぼ独立していますが、ノードでの一方向の変化は明らかにピアの反対方向の変化に対応しています。ルート変更には2つの可能なフォームがあることに注意してください。フローがノードを消去または入るインターフェイスが変更され、隣接するピアが変更される場合があります。一般に、ルートの変更には、どちらか一方またはその両方を含めることができます（または実際にはどちらでもありませんが、そのような変更は検出が非常に困難です）。
The route change detection mechanisms available to a node depend on the MRM in use and the role the node played in setting up the routing state in the first place (i.e., as Querying or Responding node). The following discussion is specific to the case of the path-coupled MRM using downstream Queries only; other scenarios may require other methods. However, the repair logic described in the subsequent subsections is intended to be universal.
ノードが利用できるルート変更検出メカニズムは、使用中のMRMと、最初の場所でルーティング状態をセットアップする際にノードが果たす役割（つまり、クエリまたは応答するノードとして）に依存します。以下の議論は、下流クエリのみを使用してパス結合MRMの場合に固有のものです。他のシナリオには他の方法が必要になる場合があります。ただし、後続のサブセクションで説明されている修復ロジックは、普遍的であることを目的としています。
There are five mechanisms for a node to detect that a route change has occurred, which are listed below. They apply differently depending on whether the change is in the Query or Response direction, and these differences are summarised in the following table.
ノードがルートの変更が発生したことを検出するための5つのメカニズムがあります。これは以下にリストされています。それらは、変更がクエリまたは応答の方向にあるかどうかによって異なる方法で適用され、これらの違いを次の表にまとめます。
Local Trigger: In local trigger mode, GIST finds out from the local forwarding table that the next hop has changed. This only works if the routing change is local, not if it happens a few IP routing hops away, including the case that it happens at a GIST-unaware node.
ローカルトリガー：ローカルトリガーモードでは、GISTはローカル転送テーブルから次のホップが変更されたことを見つけます。これは、ルーティングの変更がローカルである場合にのみ機能しますが、Gist-Unawareノードで発生する場合を含め、数回のIPルーティングホップが発生した場合ではありません。
Extended Trigger: Here, GIST checks a link-state topology database to discover that the path has changed. This makes certain assumptions on consistency of IP route computation and only works within a single area for OSPF [16] and similar link-state protocols. Where available, this offers the most accurate and rapid indication of route changes, but requires more access to the routing internals than a typical operating system may provide.
拡張トリガー：ここで、GISTはリンク状態トポロジデータベースをチェックして、パスが変更されたことを発見します。これにより、IPルート計算の一貫性に関する特定の仮定が行われ、OSPF [16]および同様のリンク状態プロトコルの単一領域内でのみ機能します。利用可能な場合、これはルートの変更を最も正確かつ迅速に示していますが、通常のオペレーティングシステムが提供するよりもルーティング内部へのアクセスが必要です。
GIST C-mode Monitoring: GIST may find that C-mode packets are arriving (from either peer) with a different IP layer TTL or on a different interface. This provides no direct information about the new flow path, but indicates that routing has changed and that rediscovery may be required.
GIST Cモード監視：GISTは、Cモードパケットが異なるIPレイヤーTTLまたは別のインターフェイスで（どちらのピアから）到着していることがわかります。これは、新しいフローパスに関する直接的な情報を提供しませんが、ルーティングが変更され、再発見が必要になる可能性があることを示しています。
Data Plane Monitoring: The signalling application on a node may detect a change in behaviour of the flow, such as IP layer TTL change, arrival on a different interface, or loss of the flow altogether. The signalling application on the node is allowed to convey this information to the local GIST instance (Appendix B.6).
データプレーンの監視：ノード上のシグナリングアプリケーションは、IPレイヤーTTLの変更、異なるインターフェイスへの到着、またはフローの損失など、フローの動作の変化を検出する場合があります。ノード上のシグナリングアプリケーションは、この情報をローカルGISTインスタンスに伝えることができます（付録B.6）。
GIST Probing: According to the specification, each GIST node MUST periodically repeat the discovery (Query/Response) operation. Values for the probe frequency are discussed in Section 4.4.4. The period can be negotiated independently for each GIST hop, so nodes that have access to the other techniques listed above MAY use long periods between probes. The Querying node will discover the route change by a modification in the Network-Layer-Information in the Response. The Responding node can detect a change in the upstream peer similarly; further, if the Responding node can store the interface on which Queries arrive, it can detect if this interface changes even when the peer does not.
GISTプロービング：仕様によると、各GISTノードは、発見（クエリ/応答）操作を定期的に繰り返す必要があります。プローブ頻度の値については、セクション4.4.4で説明します。この期間は各Gist Hopについて独立してネゴシエートすることができるため、上記の他の手法にアクセスできるノードは、プローブ間で長期間を使用する可能性があります。クエリノードは、応答のネットワーク層情報の変更により、ルートの変更を発見します。応答するノードは、上流のピアの変化を同様に検出できます。さらに、応答するノードがクエリが到着するインターフェイスを保存できる場合、ピアがそうでない場合でもこのインターフェイスが変更されたかどうかを検出できます。
+-------------+--------------------------+--------------------------+
| Method | Query direction | Response direction |
+-------------+--------------------------+--------------------------+
| Local | Discovers new interface | Not applicable |
| Trigger | (and peer if local) | |
| | | |
| Extended | Discovers new interface | May determine that route |
| Trigger | and may determine new | from peer will have |
| | peer | changed |
| | | |
| C-mode | Provides hint that | Provides hint that |
| Monitoring | change has occurred | change has occurred |
| | | |
| Data Plane | Not applicable | NSLP informs GIST that a |
| Monitoring | | change may have occurred |
| | | |
| Probing | Discovers changed NLI in | Discovers changed NLI in |
| | Response | Query |
+-------------+--------------------------+--------------------------+
The basic GIST behaviour necessary to support rerouting can be modelled using a three-level classification of the validity of each item of current routing state. (In addition to current routing state, NSIS can maintain past routing state, described in Section 7.1.4 below.) This classification applies separately to the Querying and Responding nodes for each pair of GIST peers. The levels are:
再ルーティングをサポートするために必要な基本的な要点の動作は、現在のルーティング状態の各項目の有効性の3レベルの分類を使用してモデル化できます。（現在のルーティング状態に加えて、NSIは以下のセクション7.1.4で説明する過去のルーティング状態を維持できます。）この分類は、GISTピアの各ペアのクエリと応答のノードに個別に適用されます。レベルは次のとおりです。
Bad: The routing state is either missing altogether or not safe to use to send data.
悪い：ルーティング状態は完全に欠落しているか、データを送信するために使用しても安全ではありません。
Tentative: The routing state may have changed, but it is still usable for sending NSLP data pending verification.
暫定：ルーティング状態は変更された可能性がありますが、検証が保留中のNSLPデータを送信するにはまだ使用できます。
Good: The routing state has been established and no events affecting it have since been detected.
良い：ルーティング状態が確立されており、それに影響を与えるイベントは検出されていません。
These classifications are not identical to the states described in Section 6, but there are dependencies between them. Specifically, routing state is considered Bad until the state machine first enters the Established state, at which point it becomes Good. Thereafter, the status may be invalidated for any of the reasons discussed above; it is an implementation issue to decide which techniques to implement in any given node, and how to reclassify routing state (as Bad or Tentative) for each. The status returns to Good, either when the state machine re-enters the Established state or if GIST can determine from direct examination of the IP routing or forwarding tables that the peer has not changed. When the status returns to Good, GIST MUST if necessary update its routing state table so that the relationships between MRI/SID/NSLPID tuples and messaging associations are up to date.
これらの分類は、セクション6で説明されている状態と同一ではありませんが、それらの間には依存関係があります。具体的には、州のマシンが最初に確立された状態に入るまで、ルーティング状態は悪いと見なされます。その後、上記の理由のいずれかの理由でステータスが無効になる場合があります。特定のノードで実装する手法を決定するのは、それぞれのルーティング状態（悪いまたは暫定的）を再分類する方法を決定するための実装の問題です。ステータスは、状態マシンが確立された状態に再び入ったとき、またはGISTがピアが変更していないIPルーティングまたは転送テーブルの直接検査から決定できる場合、善に戻ります。ステータスが良好に戻ると、必要に応じてGISTがルーティング状態テーブルを更新して、MRI/SID/NSLPIDタプルとメッセージングアソシエーションの関係が最新になるようにする必要があります。
When classification of the routing state for the downstream direction changes to Bad/Tentative because of local IP routing indications, GIST MAY automatically change the classification in the upstream direction to Tentative unless local routing indicates that this is not necessary. This SHOULD NOT be done in the case where the initial change was indicated by the signalling application. This mechanism accounts for the fact that a routing change may affect several nodes, and so can be an indication that upstream routing may also have changed. In any case, whenever GIST updates the routing status, it informs the signalling application with the NetworkNotification API (Appendix B.4), unless the change was caused via the API in the first place.
ローカルIPルーティングの表示により、下流の方向のルーティング状態の分類が悪い/暫定的に変化する場合、GISTは、ローカルルーティングがこれが不要であることを示しない限り、上流方向の分類を暫定に自動的に変更する場合があります。これは、シグナリングアプリケーションによって最初の変更が示された場合には行われないでください。このメカニズムは、ルーティングの変更がいくつかのノードに影響を与える可能性があるという事実を説明しているため、上流のルーティングも変更された可能性があることを示している可能性があります。いずれにせよ、GISTがルーティングステータスを更新するたびに、変更が最初にAPIを介して引き起こされない限り、Network -Notification API（付録B.4）を使用して信号アプリケーションを通知します。
The GIST behaviour for state repair is different for the Querying and Responding nodes. At the Responding node, there is no additional behaviour, since the Responding node cannot initiate protocol transitions autonomously. (It can only react to the Querying node.) The Querying node has three options, depending on how the transition from Good was initially caused:
状態修復の要点の動作は、クエリと応答のノードで異なります。応答するノードでは、応答するノードがプロトコル遷移を自律的に開始できないため、追加の動作はありません。（クエリノードにのみ反応することができます。）クエリノードには、Goodからの移行が最初にどのように引き起こされたかに応じて、3つのオプションがあります。
1. To inspect the IP routing/forwarding table and verifying that the next peer has not changed. This technique MUST NOT be used if the transition was caused by a signalling application, but SHOULD be used otherwise if available.
1. IPルーティング/転送テーブルを検査し、次のピアが変更されていないことを確認します。この手法は、移行がシグナリングアプリケーションによって引き起こされた場合は使用しないでください。
2. To move to the Awaiting Refresh state. This technique MUST NOT be used if the current status is Bad, since data is being incorrectly delivered.
2. 待望の更新状態に移動します。データが誤って配信されているため、現在のステータスが悪い場合は、この手法を使用してはなりません。
3. To move to the Awaiting Response state. This technique may be used at any time, but has the effect of freezing NSLP communication while GIST state is being repaired.
3. 待ち望まれている応答状態に移動します。この手法はいつでも使用できますが、GIST状態が修復されている間にNSLP通信を凍結する効果があります。
The second and third techniques trigger the execution of a GIST handshake to carry out the repair. It may be desirable to delay the start of the handshake process, either to wait for the network to stabilise, to avoid flooding the network with Query traffic for a large number of affected flows, or to wait for confirmation that the node is still on the path from the upstream peer. One approach is to delay the handshake until there is NSLP data to be transmitted. Implementation of such delays is a matter of local policy; however, GIST MUST begin the handshake immediately if the status change was caused by an InvalidateRoutingState API call marked as 'Urgent', and SHOULD begin it if the upstream routing state is still known to be Good.
2番目と3番目のテクニックは、GISTの握手の実行をトリガーして修理を実行します。ネットワークが安定するのを待つか、多くの影響を受けるフローのクエリトラフィックでネットワークに浸水させないようにするか、ノードがまだ上にあることを確認するために、握手プロセスの開始を遅らせることが望ましい場合があります上流のピアからの道。1つのアプローチは、NSLPデータが送信されるまで握手を遅らせることです。このような遅延の実装は、ローカルポリシーの問題です。ただし、ステータスの変更が「緊急」とマークされたInvalidateroutingState API呼び出しによって引き起こされた場合、GISTはすぐに握手を開始する必要があり、上流のルーティング状態がまだ良好であることがわかっている場合はそれを開始する必要があります。
The Q-mode encapsulation rules of Section 5.8 try to ensure that the Query messages discovering the path mimic the flow as accurately as possible. However, in environments where there is load balancing over multiple routes, and this is based on header fields differing between flow and Q-mode packets or done on a round-robin basis, the path discovered by the Query may vary from one handshake to the next even though the underlying network is stable. This will appear to GIST as a route flap; route flapping can also be caused by problems in the basic network connectivity or routing protocol operation. For example, a mobile node might be switching back and forth between two links, or might appear to have disappeared even though it is still attached to the network via a different route.
セクション5.8のQモードカプセル化ルールは、パスを発見するクエリメッセージが可能な限り正確にフローを模倣することを確認してみてください。ただし、複数のルートで負荷分散がある環境では、これはフローとQモードパケットの間で異なるヘッダーフィールドに基づいているか、ラウンドロビンベースで行われますが、クエリによって発見されたパスは、一方のハンドシェイクごとに異なる場合があります。次に、基礎となるネットワークが安定していても。これは、ルートフラップとしてgistに表示されます。ルートフラップは、基本的なネットワーク接続またはルーティングプロトコル操作の問題によって引き起こされる可能性もあります。たとえば、モバイルノードは2つのリンク間で前後に切り替えている可能性があるか、別のルートを介してネットワークにまだ接続されているにもかかわらず、消滅したように見える可能性があります。
This specification does not define mechanisms for GIST to manage multiple parallel routes or an unstable route; instead, GIST MAY expose this to the NSLP, which can then manage it according to signalling application requirements. The algorithms already described always maintain the concept of the current route, i.e., the latest peer discovered for a particular flow. Instead, GIST allows the use of prior signalling paths for some period while the signalling applications still need them. Since NSLP peers are a single GIST hop apart, the necessary information to represent a path can be just an entry in the node's routing state table for that flow (more generally, anything that uniquely identifies the peer, such as the NLI, could be used). Rather than requiring GIST to maintain multiple generations of this information, it is provided to the signalling application in the same node in an opaque form for each message that is received from the peer. The signalling application can store it if necessary and provide it back to the GIST layer in case it needs to be used. Because this is a reference to information about the source of a prior signalling message, it is denoted 'SII-Handle' (for Source Identification Information) in the abstract API of Appendix B.
この仕様は、複数の並列ルートまたは不安定なルートを管理するためのGISTのメカニズムを定義しません。代わりに、GISTはこれをNSLPにさらし、シグナリングアプリケーションの要件に従って管理できます。すでに説明されているアルゴリズムは、常に現在のルートの概念、つまり特定のフローのために発見された最新のピアを常に維持しています。代わりに、GISTでは、シグナリングアプリケーションがまだ必要な間、以前のシグナリングパスを何らかの期間使用できます。NSLPピアは単一のGist Hopであるため、パスを表すために必要な情報は、そのフローのノードのルーティング状態テーブルの単なるエントリになります（より一般的には、NLIなどのピアをユニークに識別するものはすべて使用できます。）。この情報の複数の世代を維持するためにGISTを要求するのではなく、ピアから受信される各メッセージに対して同じノードのシグナリングアプリケーションに提供されます。シグナリングアプリケーションは、必要に応じて保存し、使用する必要がある場合に備えてGISTレイヤーに戻すことができます。これは、以前のシグナル伝達メッセージのソースに関する情報への参照であるため、付録Bの抽象APIで「SIIハンドル」（ソース識別情報のため）と表示されます。
Note that GIST if possible SHOULD use the same SII-Handle for multiple sessions to the same peer, since this then allows signalling applications to aggregate some signalling, such as summary refreshes or bulk teardowns. Messages sent using the SII-Handle MUST bypass the routing state tables at the sender, and this MUST be indicated by setting the E-flag in the common header (Appendix A.1). Messages other than Data messages MUST NOT be sent in this way. At the receiver, GIST MUST NOT validate the MRI/SID/NSLPID against local routing state and instead indicates the mode of reception to signalling applications through the API (Appendix B.2). Signalling applications should validate the source and effect of the message themselves, and if appropriate should in particular indicate to GIST (see Appendix B.5) that routing state is no longer required for this flow. This is necessary to prevent GIST in nodes on the old path initiating routing state refresh and thus causing state conflicts at the crossover router.
可能であれば、同じピアへの複数のセッションに同じSIIハンドルを使用する必要があることに注意してください。これにより、シグナリングアプリケーションは要約リフレッシュやバルク分解などのいくつかのシグナリングを集約することができます。SIIハンドルを使用して送信されたメッセージは、送信者のルーティング状態テーブルをバイパスする必要があります。これは、共通ヘッダーにe-flagを設定することで示す必要があります（付録A.1）。データメッセージ以外のメッセージは、この方法で送信してはなりません。受信機では、GISTはローカルルーティング状態に対してMRI/SID/NSLPIDを検証してはなりません。代わりに、APIを介した適応アプリケーションへの受信モードを示します（付録B.2）。シグナリングアプリケーションは、メッセージ自体のソースと効果を検証する必要があり、必要に応じて、特にこのフローにはルーティング状態が不要になったGIST（付録B.5を参照）を示す必要があります。これは、ルーティング状態の更新を開始し、クロスオーバールーターで状態競合を引き起こす古いパスのノードの要点を防ぐために必要です。
GIST notifies signalling applications about route modifications as two types of event, additions and deletions. An addition is notified as a change of the current routing state according to the Bad/ Tentative/Good classification above, while deletion is expressed as a statement that an SII-Handle no longer lies on the path. Both can be reported through the NetworkNotification API call (Appendix B.4). A minimal implementation MAY notify a route change as a single (add, delete) operation; however, a more sophisticated implementation MAY delay the delete notification, for example, if it knows that the old route continues to be used in parallel or that the true route is flapping between the two. It is then a matter of signalling application design whether to tear down state on the old path, leave it unchanged, or modify it in some signalling application specific way to reflect the fact that multiple paths are operating in parallel.
GISTは、2種類のイベント、追加、および削除として、ルートの変更に関するシグナリングアプリケーションに通知します。追加は、上記の悪い/暫定的/良い分類に従って現在のルーティング状態の変更として通知されますが、削除はSIIハンドルがもはやパスにあるという声明として表されます。どちらもNetwork -Notification APIコール（付録B.4）を通じて報告できます。最小限の実装は、ルートの変更に単一の（追加、削除）操作として通知する場合があります。ただし、たとえば、より洗練された実装は、削除通知を遅らせる可能性があります。たとえば、古いルートが並行して使用され続けていること、または真のルートが2つの間に羽ばたきしていることがわかっている場合。その場合、アプリケーションの設計には、古い経路の状態を取り壊すか、変更せずに、または複数のパスが並行して動作しているという事実を反映するために、いくつかのシグナリングアプリケーション固有の方法で変更するかどうかがシグナリングの問題です。
Signalling applications can use these functions as provided by GIST to carry out rapid local repair following rerouting events. The signalling application instances carry out the multi-hop aspects of the procedure, including crossover node detection, and tear-down/ reinstallation of signalling application state; they also trigger GIST to carry out the local routing state maintenance operations over each individual hop. The local repair procedures depend heavily on the fact that stateful NSLP nodes are a single GIST hop apart; this is enforced by the details of the GIST peer discovery process.
シグナリングアプリケーションは、GISTが提供するようにこれらの機能を使用して、再ルーティングイベント後に迅速なローカル修理を実行できます。シグナリングアプリケーションインスタンスは、クロスオーバーノードの検出、シグナリングアプリケーション状態の引き裂き/再インストールなど、手順のマルチホップの側面を実行します。また、GISTをトリガーして、個々のホップごとにローカルルーティング状態メンテナンス操作を実行します。ローカルの修理手順は、Stateful NSLPノードが単一の要素であるという事実に大きく依存しています。これは、GISTピアディスカバリープロセスの詳細によって実施されます。
The following outline description of a possible set of NSLP actions takes the scenario of Figure 10 as an example.
NSLPアクションの可能なセットの次の概要の説明は、図10のシナリオを例として採用します。
1. The signalling application at node E1 is notified by GIST of route changes affecting the downstream and upstream directions. The downstream status was updated to Bad because of a trigger from the local forwarding tables, and the upstream status changed automatically to Tentative as a consequence. The signalling application at E1 MAY begin local repair immediately, or MAY propagate a notification upstream to D1 that rerouting has occurred.
1. ノードE1でのシグナリングアプリケーションは、下流および上流の方向に影響するルートの変更の要点によって通知されます。ダウンストリームステータスは、ローカル転送テーブルからのトリガーのために悪い状態に更新され、上流のステータスは結果として自動的に暫定に変更されました。E1でのシグナリングアプリケーションは、すぐにローカル修理を開始するか、再ルーティングが発生したというD1の上流の通知を伝播する場合があります。
2. The signalling application at node D1 is notified of the route change, either by signalling application notifications or from the GIST level (e.g., by a trigger from a link-state topology database). If the information propagates faster within the IP routing protocol, GIST will change the upstream/downstream routing state to Tentative/Bad automatically, and this will cause the signalling application to propagate the notification further upstream.
2. ノードD1でのシグナリングアプリケーションは、アプリケーション通知またはGISTレベルからのシグナル伝達通知（例：リンク状態トポロジデータベースからのトリガー）のいずれかによって、ルートの変更について通知されます。情報がIPルーティングプロトコル内でより速く伝播すると、GISTは上流/下流のルーティング状態を暫定/悪い状態に自動的に変更し、これによりシグナリングアプリケーションが通知をさらに上流に伝播させます。
3. This process continues until the notification reaches node A. Here, there is no downstream routing change, so GIST only learns of the update via the signalling application trigger. Since the upstream status is still Good, it therefore begins the repair handshake immediately.
3. このプロセスは、通知がノードAに到達するまで続きます。ここでは、ダウンストリームルーティングの変更はありません。そのため、GISTはシグナリングアプリケーショントリガーを介して更新のみを学習します。上流のステータスはまだ良好なので、すぐに修理の握手を開始します。
4. The handshake initiated by node A causes its downstream routing state to be confirmed as Good and unchanged there; it also confirms the (Tentative) upstream routing state at B as Good. This is enough to identify B as the crossover router, and the signalling application and GIST can begin the local repair process.
4. ノードAによって開始された握手により、下流のルーティング状態が良好で変更されていないことが確認されます。また、Bの（暫定的な）上流のルーティング状態を確認します。これは、Bをクロスオーバールーターとして識別するのに十分であり、シグナリングアプリケーションとGISTはローカル修理プロセスを開始できます。
An alternative way to reach step (4) is that node B is able to determine autonomously that there is no likelihood of an upstream route change. For example, it could be an area border router and the route change is only intra-area. In this case, the signalling application and GIST will see that the upstream state is Good and can begin the local repair directly.
ステップ（4）に到達する別の方法は、ノードBが上流のルートの変更の可能性がないことを自律的に判断できることです。たとえば、エリアボーダールーターである可能性があり、ルートの変更はエリア内のみです。この場合、シグナリングアプリケーションとGISTは、上流の状態が良好であり、ローカルの修理を直接開始できることがわかります。
After a route deletion, a signalling application may wish to remove state at another node that is no longer on the path. However, since it is no longer on the path, in principle GIST can no longer send messages to it. In general, provided this state is soft, it will time out anyway; however, the timeouts involved may have been set to be very long to reduce signalling load. Instead, signalling applications MAY use the SII-Handle described above to route explicit teardown messages.
ルートの削除の後、シグナリングアプリケーションは、パス上にない別のノードで状態を削除したい場合があります。ただし、パス上にないため、原則として、Gistはメッセージにメッセージを送信できなくなります。一般に、この状態が柔らかい場合、とにかくタイムアウトします。ただし、関係するタイムアウトは、シグナルの負荷を減らすために非常に長く設定されている可能性があります。代わりに、シグナリングアプリケーションは、上記のSIIハンドルを使用して、明示的な分解メッセージをルーティングする場合があります。
GIST messages, for example, for the path-coupled MRM, must carry addressing and higher layer information as payload data in order to define the flow signalled for. (This applies to all GIST messages, regardless of how they are encapsulated or which direction they are travelling in.) At an addressing boundary, the data flow packets will have their headers translated; if the signalling payloads are not translated consistently, the signalling messages will refer to incorrect (and probably meaningless) flows after passing through the boundary. In addition, GIST handshake messages carry additional addressing information about the GIST nodes themselves, and this must also be processed appropriately when traversing a NAT.
たとえば、パス結合されたMRMのGISTメッセージは、信号を定義するために、ペイロードデータとしてアドレス指定と高層情報を運ぶ必要があります。（これは、それらがどのようにカプセル化されているか、どの方向に移動しているかに関係なく、すべてのGISTメッセージに適用されます。）アドレス指定境界では、データフローパケットにヘッダーが翻訳されます。シグナリングペイロードが一貫して翻訳されていない場合、シグナリングメッセージは、境界を通過した後、誤った（そしておそらく意味のない）流れを指します。さらに、GISTハンドシェイクメッセージには、GISTノード自体に関する追加のアドレス指定情報が含まれています。これは、NATを横断するときに適切に処理する必要があります。
There is a dual problem of whether the GIST peers on either side of the boundary can work out how to address each other, and whether they can work out what translation to apply to the signalling packet payloads. Existing generic NAT traversal techniques such as Session Traversal Utilities for NAT (STUN) [26] or Traversal Using Relays around NAT (TURN) [27] can operate only on the two addresses visible in the IP header. It is therefore intrinsically difficult to use these techniques to discover a consistent translation of the three or four interdependent addresses for the flow and signalling source and destination.
境界の両側にあるGISTピアがお互いに対処する方法を解決できるかどうか、およびシグナリングパケットペイロードに適用するための翻訳を解決できるかどうかという二重の問題があります。NAT（STUN）[26]のセッショントラバーサルユーティリティなどの既存のジェネリックNATトラバーサル技術や、NAT（ターン）[27]の周りのリレーを使用したトラバーサルは、IPヘッダーで見える2つのアドレスでのみ動作できます。したがって、これらの手法を使用して、フローとシグナリングソースと目的地の3つまたは4つの相互依存アドレスの一貫した翻訳を発見することは本質的に困難です。
For legacy NATs and MRMs that carry addressing information, the base GIST specification is therefore limited to detecting the situation and triggering the appropriate error conditions to terminate the signalling path. (MRMs that do not contain addressing information could traverse such NATs safely, with some modifications to the GIST processing rules. Such modifications could be described in the documents defining such MRMs.) Legacy NAT handling is covered in Section 7.2.1 below. A more general solution can be constructed using GIST-awareness in the NATs themselves; this solution is outlined in Section 7.2.2 with processing rules in Section 7.2.3.
したがって、アドレス指定情報を運ぶレガシーNATとMRMSの場合、ベースGIST仕様は状況を検出し、適切なエラー条件をトリガーしてシグナリングパスを終了することに限定されます。（アドレス指定情報を含まないMRMSは、GIST処理ルールのいくつかの変更により、そのようなNATを安全に横断する可能性があります。そのような変更は、そのようなMRMを定義するドキュメントで説明できます。）レガシーNATハンドリングは、以下のセクション7.2.1で説明されています。より一般的なソリューションは、NAT自体の要点認識を使用して構築できます。このソリューションは、セクション7.2.2のセクション7.2.3の処理ルールで概説されています。
In all cases, GIST interaction with the NAT is determined by the way the NAT handles the Query/Response messages in the initial GIST handshake; these messages are UDP datagrams. Best current practice for NAT treatment of UDP traffic is defined in [38], and the legacy NAT handling defined in this specification is fully consistent with that document. The GIST-aware NAT traversal technique is equivalent to requiring an Application Layer Gateway in the NAT for a specific class of UDP transactions -- namely, those where the destination UDP port for the initial message is the GIST port (see Section 9).
すべての場合において、NATとのGIST相互作用は、NATが最初のGISTハンドシェイクでクエリ/応答メッセージを処理する方法によって決定されます。これらのメッセージはUDPデータグラムです。UDPトラフィックのNAT処理のための最良の現在の慣行は[38]で定義されており、この仕様で定義されているレガシーNATハンドリングは、その文書と完全に一致しています。GIST AWARE NATトラバーサル手法は、UDPトランザクションの特定のクラスにNATのアプリケーションレイヤーゲートウェイを必要とすることと同等です。つまり、最初のメッセージの宛先UDPポートがGISTポートです（セクション9を参照）。
Legacy NAT detection during the GIST handshake depends on analysis of the IP header and S-flag in the GIST common header, and the NLI object included in the handshake messages. The message sequence proceeds differently depending on whether the Querying node is on the internal or external side of the NAT.
GISTハンドシェイク中のレガシーNAT検出は、GIST共通ヘッダーのIPヘッダーとS-Flagの分析、およびハンドシェイクメッセージに含まれるNLIオブジェクトの分析に依存します。メッセージシーケンスは、クエリノードがNATの内部または外部側にあるかどうかによって、異なる方法で進行します。
For the case of the Querying node on the internal side of the NAT, if the S-flag is not set in the Query (S=0), a legacy NAT cannot be detected. The receiver will generate a normal Response to the interface-address given in the NLI in the Query, but the interface- address will not be routable and the Response will not be delivered. If retransmitted Queries keep S=0, this behaviour will persist until the Querying node times out. The signalling path will thus terminate at this point, not traversing the NAT.
NATの内部側のクエリノードの場合、s-flagがクエリ（s = 0）に設定されていない場合、レガシーNATを検出できません。レシーバーは、クエリのNLIに与えられたインターフェイスアドレスに対する通常の応答を生成しますが、インターフェイスアドレスはルーータブルではなく、応答は配信されません。再送信されたクエリがS = 0を保持すると、この動作はクエリのノードが回復するまで続きます。したがって、シグナリングパスは、NATを横断するのではなく、この時点で終了します。
The situation changes once S=1 in a Query; note the Q-mode encapsulation rules recommend that S=1 is used at least for some retransmissions (see Section 5.8). If S=1, the receiver MUST check the source address in the IP header against the interface-address in the NLI. A legacy NAT has been found if these addresses do not match. For MRMs that contain addressing information that needs translation, legacy NAT traversal is not possible. The receiver MUST return an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object") indicating the MRI as the object in question. The error message MUST be addressed to the source address from the IP header of the incoming message. The Responding node SHOULD use the destination IP address of the original datagram as the source address for IP header of the Response; this makes it more likely that the NAT will accept the incoming message, since it looks like a normal UDP/IP request/reply exchange. If this message is able to traverse back through the NAT, the Querying node will terminate the handshake immediately; otherwise, this reduces to the previous case of a lost Response and the Querying node will give up on reaching its retransmission limit.
状況は、クエリでs = 1が一度変化します。注Qモードカプセル化ルールは、少なくとも一部の再送信でS = 1が使用されることを推奨しています（セクション5.8を参照）。S = 1の場合、受信者は、NLIのインターフェイスアドレスに対してIPヘッダーのソースアドレスを確認する必要があります。これらのアドレスが一致しない場合、レガシーNATが見つかりました。翻訳が必要なアドレス指定情報を含むMRMSの場合、Legacy Nat Traversalは不可能です。受信者は、問題のオブジェクトとしてMRIを示すサブコード4（「翻訳されていないオブジェクト」）を含む「オブジェクトタイプエラー」メッセージ（付録A.4.4.9）を返す必要があります。エラーメッセージは、着信メッセージのIPヘッダーのソースアドレスにアドレス指定する必要があります。応答するノードは、応答のIPヘッダーのソースアドレスとして、元のデータグラムの宛先IPアドレスを使用する必要があります。これにより、通常のUDP/IPリクエスト/返信交換のように見えるため、NATが着信メッセージを受け入れる可能性が高くなります。このメッセージがNATを通過することができる場合、クエリノードはすぐに握手を終了します。それ以外の場合、これは失われた応答の以前のケースに減少し、クエリノードは再送信の制限に達することをあきらめます。
When the Querying node is on the external side of the NAT, the Query will only traverse the NAT if some static configuration has been carried out on the NAT to forward GIST Q-mode traffic to a node on the internal network. Regardless of the S-flag in the Query, the Responding node cannot directly detect the presence of the NAT. It MUST send a normal Response with S=1 to an address derived from the Querying node's NLI that will traverse the NAT as normal UDP traffic. The Querying node MUST check the source address in the IP header with the NLI in the Response, and when it finds a mismatch it MUST terminate the handshake.
クエリノードがNATの外側にある場合、NATで静的構成が実行されて内部ネットワーク上のノードにqモードトラフィックを転送するために静的構成が実行された場合にのみ、クエリがNATを通過します。クエリのs-flagに関係なく、応答するノードはNATの存在を直接検出することはできません。S = 1の通常の応答を、通常のUDPトラフィックとしてNATを横断するクエリノードのNLIから派生したアドレスに送信する必要があります。クエリノードは、応答中にNLIを使用してIPヘッダーのソースアドレスを確認する必要があり、不一致が見つかった場合は、ハンドシェイクを終了する必要があります。
Note that in either of the error cases (internal or external Querying node), an alternative to terminating the handshake could be to invoke some legacy NAT traversal procedure. This specification does not define any such procedure, although one possible approach is described in [43]. Any such traversal procedure MUST be incorporated into GIST using the existing GIST extensibility capabilities. Note also that this detection process only functions with the handshake exchange; it cannot operate on simple Data messages, whether they are Q-mode or normally encapsulated. Nodes SHOULD NOT send Data messages outside a messaging association if they cannot ensure that they are operating in an environment free of legacy NATs.
エラーケースのいずれか（内部クエリノードまたは外部クエリノード）で、ハンドシェイクを終了する代わりに、レガシーNATトラバーサル手順を呼び出すことであることに注意してください。この仕様はそのような手順を定義しませんが、1つの考えられるアプローチは[43]で説明されています。このようなトラバーサル手順は、既存のGIST拡張性機能を使用してGISTに組み込む必要があります。また、この検出プロセスは握手交換でのみ機能することに注意してください。Qモードであろうと通常カプセル化されているかどうかにかかわらず、単純なデータメッセージで動作することはできません。ノードは、レガシーNatsのない環境で動作していることを確認できない場合、メッセージング関連の協会の外にデータメッセージを送信する必要はありません。
The most robust solution to the NAT traversal problem is to require that a NAT is GIST-aware, and to allow it to modify messages based on the contents of the MRI. This makes the assumption that NATs only rewrite the header fields included in the MRI, and not other higher layer identifiers. Provided this is done consistently with the data flow header translation, signalling messages can be valid each side of the boundary, without requiring the NAT to be signalling application aware. Note, however, that if the NAT does not understand the MRI, and the N-flag in the MRI is clear (see Appendix A.3.1), it should reject the message with an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object").
NATトラバーサルの問題に対する最も堅牢な解決策は、NATが要点を認識することを要求し、MRIの内容に基づいてメッセージを変更できるようにすることです。これにより、NATSはMRIに含まれるヘッダーフィールドのみを書き換え、他の高層識別子ではないという仮定が行われます。これがデータフローヘッダー変換と一貫して行われている場合、Signalingメッセージは、NATが信号アプリケーションを認識することなく、境界の両側に有効にすることができます。ただし、NATがMRIを理解しておらず、MRIのN-Flagが明確である場合（付録A.3.1を参照）、「オブジェクトタイプエラー」メッセージ（付録A.4.4でメッセージを拒否する必要があることに注意してください。.9）サブコード4（「翻訳されていないオブジェクト」）。
The basic concept is that GIST-aware NATs modify any signalling messages that have to be able to be interpreted without routing state being available; these messages are identified by the context-free flag C=1 in the common header, and include the Query in the GIST handshake. In addition, NATs have to modify the remaining handshake messages that set up routing state. When routing state is set up, GIST records how subsequent messages related to that routing state should be translated; if no routing state is being used for a message, GIST directly uses the modifications made by the NAT to translate it.
基本的な概念は、Gist-Aware Natsが、ルーティング状態を利用可能にせずに解釈できる必要があるシグナル伝達メッセージを変更することです。これらのメッセージは、共通ヘッダーのコンテキストフリーフラグc = 1によって識別され、GISTハンドシェイクにクエリを含めます。さらに、NATは、ルーティング状態を設定する残りの握手メッセージを変更する必要があります。ルーティング状態がセットアップされると、GISTは、そのルーティング状態に関連する後続のメッセージをどのように翻訳するかを記録します。メッセージにルーティング状態が使用されていない場合、GISTはNATによって行われた変更を直接使用して翻訳します。
This specification defines an additional NAT traversal object that a NAT inserts into all Q-mode encapsulated messages with the context-free flag C=1, and which GIST echoes back in any replies, i.e., Response or Error messages. NATs apply GIST-specific processing only to Q-mode encapsulated messages with C=1, or D-mode messages carrying the NAT traversal object. All other GIST messages, either those in C-mode or those in D-mode with no NAT-Traversal object, should be treated as normal data traffic by the NAT, i.e., with IP and transport layer header translation but no GIST-specific processing. Note that the distinction between Q-mode and D-mode encapsulation may not be observable to the NAT, which is why the setting of the C-flag or presence of the NAT traversal object is used as interception criteria. The NAT decisions are based purely on the value of the C-flag and the presence of the NAT traversal object, not on the message type.
この仕様は、NATがコンテキストフリーフラグc = 1ですべてのQモードカプセル化メッセージに挿入する追加のNATトラバーサルオブジェクトを定義し、そのGISTは任意の応答、つまり応答またはエラーメッセージに反映されます。NATは、c = 1のqモードカプセル化メッセージ、またはnatトラバーサルオブジェクトを運ぶdモードメッセージにのみ、要点固有の処理を適用します。Cモードの他のすべてのGISTメッセージまたはNATトラバーサルオブジェクトのないDモードのものでは、NAT、つまりIPおよびトランスポートレイヤーヘッダーの翻訳はありませんが、GIST固有の処理はありません。。QモードとDモードのカプセル化の区別は、NATに対して観察できない場合があることに注意してください。そのため、C-FLAGの設定またはNATトラバーサルオブジェクトの存在がインターセプト基準として使用されます。NATの決定は、メッセージタイプではなく、c-flagの値とNATトラバーサルオブジェクトの存在に純粋に基づいています。
The NAT-Traversal object (Appendix A.3.9), carries the translation between the MRIs that are appropriate for the internal and external sides of the NAT. It also carries a list of which other objects in the message have been translated. This should always include the NLI, and the Stack-Configuration-Data if present; if GIST is extended with further objects that carry addressing data, this list allows a message receiver to know if the new objects were supported by the NAT. Finally, the NAT-Traversal object MAY be used to carry data to assist the NAT in back-translating D-mode responses; this could be the original NLI or SCD, or opaque equivalents in the case of topology hiding.
NATトラバーサルオブジェクト（付録A.3.9）は、NATの内側と外側の側面に適したMRIの間の翻訳を伝えます。また、メッセージ内の他のオブジェクトが翻訳されているリストも掲載されています。これには、常にnli、および存在する場合はスタックコンフィグラーデータを含める必要があります。アドレス指定データを運ぶさらなるオブジェクトでGISTが拡張されている場合、このリストにより、メッセージ受信機は新しいオブジェクトがNATによってサポートされているかどうかを知ることができます。最後に、NATトラバーサルオブジェクトを使用してデータを運ぶことができ、逆転写Dモード応答においてNATを支援することができます。これは、元のNLIまたはSCD、またはトポロジーが隠れている場合の不透明な同等物である可能性があります。
A consequence of this approach is that the routing state tables at the signalling application peers on each side of the NAT are no longer directly compatible. In particular, they use different MRI values to refer to the same flow. However, messages after the Query/ Response (the initial Confirm and subsequent Data messages) need to use a common MRI, since the NAT does not rewrite these, and this is chosen to be the MRI of the Querying node. It is the responsibility of the Responding node to translate between the two MRIs on inbound and outbound messages, which is why the unmodified MRI is propagated in the NAT-Traversal object.
このアプローチの結果、NATの両側にあるシグナリングアプリケーションピアのルーティング状態テーブルは、もはや直接互換性がないことです。特に、同じフローを参照するために異なるMRI値を使用します。ただし、クエリ/応答の後のメッセージ（初期確認および後続のデータメッセージ）は、NATがこれらを書き直さないため、一般的なMRIを使用する必要があり、これはクエリノードのMRIに選択されています。インバウンドメッセージとアウトバウンドメッセージの2つのMRIを翻訳することは、応答するノードの責任です。そのため、変更されていないMRIがNATトラバーサルオブジェクトに伝播されます。
This specification normatively defines the behaviour of a GIST node receiving a message containing a NAT-Traversal object. However, it does not define normative behaviour for a NAT translating GIST messages, since much of this will depend on NAT implementation and policy about allocating bindings. In addition, it is not necessary for a GIST implementation itself. Therefore, those aspects of the following description are informative; full details of NAT behaviour for handling GIST messages can be found in [44].
この仕様は、NATトラバーサルオブジェクトを含むメッセージを受信するGISTノードの動作を規範的に定義します。ただし、これの多くは、バインディングの割り当てに関するNATの実装とポリシーに依存するため、NAT翻訳GISTメッセージの規範的な動作を定義するものではありません。さらに、GISTの実装自体には必要ありません。したがって、次の説明のこれらの側面は有益です。GISTメッセージを処理するためのNATの動作の詳細については、[44]をご覧ください。
A possible set of operations for a NAT to process a message with C=1 is as follows. Note that for a Data message, only a subset of the operations is applicable.
C = 1でメッセージを処理するNATが可能な操作セットは次のとおりです。データメッセージの場合、操作のサブセットのみが適用されることに注意してください。
1. Verify that bindings for any data flow are actually in place.
1. データフローのバインディングが実際に整っていることを確認してください。
2. Create a new Message-Routing-Information object with fields modified according to the data flow bindings.
2. データフローのバインディングに従ってフィールドが変更された新しいメッセージルーティング情報オブジェクトを作成します。
3. Create bindings for subsequent C-mode signalling based on the information in the Network-Layer-Information and Stack-Configuration-Data objects.
3. ネットワーク層の情報とスタックコンフィグラーデータオブジェクトの情報に基づいて、後続のCモードシグナル伝達のバインディングを作成します。
4. Create new Network-Layer-Information and if necessary Stack-Configuration-Data objects with fields to force D-mode response messages through the NAT, and to allow C-mode exchanges using the C-mode signalling bindings.
4. 新しいネットワーク層情報を作成し、必要に応じて、フィールドを備えたStack-Configuration-DataオブジェクトをNATを介してDモード応答メッセージを強制し、Cモードシグナリングバインディングを使用してCモード交換を許可します。
5. Add a NAT-Traversal object, listing the objects that have been modified and including the unmodified MRI and any other data needed to interpret the response. If a NAT-Traversal object is already present, in the case of a sequence of NATs, the list of modified objects may be updated and further opaque data added, but the MRI contained in it is left unchanged.
5. NATトラバーサルオブジェクトを追加し、変更されたオブジェクトをリストし、変更されていないMRIと応答を解釈するために必要なその他のデータを含めます。NATのシーケンスの場合、NATトラバーサルオブジェクトがすでに存在する場合、変更されたオブジェクトのリストが更新され、さらに不透明なデータが追加されますが、その中に含まれるMRIは変更されません。
6. Encapsulate the message according to the normal rules of this specification for the Q-mode encapsulation. If the S-flag was set in the original message, the same IP source address selection policy should be applied to the forwarded message.
6. Qモードカプセル化のこの仕様の通常のルールに従ってメッセージをカプセル化します。S-Flagが元のメッセージに設定されている場合、同じIPソースアドレス選択ポリシーを転送メッセージに適用する必要があります。
7. Forward the message with these new payloads.
7. これらの新しいペイロードでメッセージを転送します。
A GIST node receiving such a message MUST verify that all mandatory objects containing addressing have been translated correctly, or else reject the message with an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error message MUST include the NAT-Traversal object as the first TLV after the common header, and this is also true for any other error message generated as a reply. Otherwise, the message is processed essentially as normal. If no state needs to be updated for the message, the NAT-Traversal object can be effectively ignored. The other possibility is that a Response must be returned, because the message is either the beginning of a handshake for a new flow or a refresh for existing state. In both cases, the GIST node MUST create the Response in the normal way using the local form of the MRI, and its own NLI and (if necessary) SCD. It MUST also include the NAT-Traversal object as the first object in the Response after the common header.
このようなメッセージを受信するGISTノードは、アドレス指定を含むすべての必須オブジェクトが正しく翻訳されていることを確認する必要があります。または、サブコード4（「翻訳されていないオブジェクト」）を備えた「オブジェクトタイプエラー」メッセージ（付録A.4.4.9）でメッセージを拒否することを確認する必要があります。。エラーメッセージには、共通ヘッダー後の最初のTLVとしてNATトラバーサルオブジェクトを含める必要があります。これは、返信として生成された他のエラーメッセージにも当てはまります。それ以外の場合、メッセージは本質的に通常のように処理されます。メッセージの状態を更新する必要がない場合、NATトラバーサルオブジェクトは効果的に無視できます。もう1つの可能性は、メッセージが新しいフローの握手の始まりであるか、既存の状態のリフレッシュのいずれかであるため、応答を返す必要があるということです。どちらの場合も、GISTノードは、MRIのローカル形式、および独自のNLIおよび（必要に応じて）SCDを使用して、通常の方法で応答を作成する必要があります。また、共通ヘッダーの後の応答の最初のオブジェクトとしてNATトラバーサルオブジェクトを含める必要があります。
A NAT will intercept D-mode messages containing such echoed NAT-Traversal objects. The NAT processing is a subset of the processing for the C=1 case:
NATは、そのようなエコーされたNATトラバーサルオブジェクトを含むDモードメッセージをインターセプトします。NAT処理は、C = 1の場合の処理のサブセットです。
1. Verify the existence of bindings for the data flow.
1. データフローのバインディングの存在を確認します。
2. Leave the Message-Routing-Information object unchanged.
2. メッセージルーティング情報オブジェクトを変更せずに残します。
3. Modify the NLI and SCD objects for the Responding node if necessary, and create or update any bindings for C-mode signalling traffic.
3. 必要に応じて応答ノードのNLIおよびSCDオブジェクトを変更し、Cモードシグナリングトラフィックのバインディングを作成または更新します。
4. Forward the message.
4. メッセージを転送します。
A GIST node receiving such a message (Response or Error) MUST use the MRI from the NAT-Traversal object as the key to index its internal routing state; it MAY also store the translated MRI for additional (e.g., diagnostic) information, but this is not used in the GIST processing. The remainder of GIST processing is unchanged.
そのようなメッセージを受信するGISTノード（応答またはエラー）は、NATトラバーサルオブジェクトからのMRIを、内部ルーティング状態をインデックス化する鍵として使用する必要があります。また、翻訳されたMRIを追加（診断）情報のために保存することもできますが、これはGIST処理では使用されません。GIST処理の残りの部分は変更されていません。
Note that Confirm messages are not given GIST-specific processing by the NAT. Thus, a Responding node that has delayed state installation until receiving the Confirm only has available the untranslated MRI describing the flow, and the untranslated NLI as peer routing state. This would prevent the correct interpretation of the signalling messages; also, subsequent Query (refresh) messages would always be seen as route changes because of the NLI change. Therefore, a Responding node that wishes to delay state installation until receiving a Confirm must somehow reconstruct the translations when the Confirm arrives. How to do this is an implementation issue; one approach is to carry the translated objects as part of the Responder-Cookie that is echoed in the Confirm. Indeed, for one of the cookie constructions in Section 8.5 this is automatic.
確認メッセージには、NATによってGIST固有の処理が与えられていないことに注意してください。したがって、確認が受信されるまで状態の設置を遅らせる応答ノードは、フローを記述する翻訳されていないMRIと、ピアルーティング状態として非翻訳されていないNLIが利用可能になります。これにより、信号メッセージの正しい解釈が妨げられます。また、NLIの変更により、その後のクエリ（更新）メッセージは常にルートの変更と見なされます。したがって、確認を受信するまで状態のインストールを遅らせたい応答ノードは、確認が届いたときに何らかの形で翻訳を再構築する必要があります。これを行う方法は、実装の問題です。1つのアプローチは、確認に反映されるレスポンダークッキーの一部として翻訳されたオブジェクトを運ぶことです。実際、セクション8.5のCookie構造の1つでは、これは自動です。
The interaction between GIST and IP tunnelling is very simple. An IP packet carrying a GIST message is treated exactly the same as any other packet with the same source and destination addresses: in other words, it is given the tunnel encapsulation and forwarded with the other data packets.
GISTとIPトンネルの相互作用は非常に簡単です。GISTメッセージを運ぶIPパケットは、同じソースと宛先のアドレスを持つ他のパケットとまったく同じ扱われます。つまり、トンネルのカプセル化が与えられ、他のデータパケットで転送されます。
Tunnelled packets will not be identifiable as GIST messages until they leave the tunnel, since any Router Alert Option and the standard GIST protocol encapsulation (e.g., port numbers) will be hidden within the standard tunnel encapsulation. If signalling is needed for the tunnel itself, this has to be initiated as a separate signalling session by one of the tunnel endpoints -- that is, the tunnel counts as a new flow. Because the relationship between signalling for the microflow and signalling for the tunnel as a whole will depend on the signalling application in question, it is a signalling application responsibility to be aware of the fact that tunnelling is taking place and to carry out additional signalling if necessary; in other words, at least one tunnel endpoint must be signalling application aware.
ルーターアラートオプションと標準のGISTプロトコルカプセル化（ポート番号など）が標準トンネルカプセル化内に隠されるため、トンネルパケットはトンネルを離れるまでGISTメッセージとして識別できません。トンネル自体にシグナリングが必要な場合、これはトンネルエンドポイントの1つ、つまりトンネルが新しいフローとしてカウントされる別のシグナリングセッションとして開始する必要があります。マイクロフローのシグナル伝達とトンネル全体のシグナル伝達との関係は、問題のシグナリングアプリケーションに依存するため、トンネリングが行われているという事実を認識し、必要に応じて追加のシグナル伝達を実行することはシグナリングアプリケーションの責任です;言い換えれば、少なくとも1つのトンネルエンドポイントは、アプリケーションを認識していることを信号する必要があります。
In some cases, it is the tunnel exit point (i.e., the node where tunnelled data and downstream signalling packets leave the tunnel) that will wish to carry out the tunnel signalling, but this node will not have knowledge or control of how the tunnel entry point is carrying out the data flow encapsulation. The information about how the inner MRI/SID relate to the tunnel MRI/SID needs to be carried in the signalling data from the tunnel entry point; this functionality is the equivalent to the RSVP SESSION_ASSOC object of [18]. In the NSIS protocol suite, these bindings are managed by the signalling applications, either implicitly (e.g., by SID re-use) or explicitly by carrying objects that bind the inner and outer SIDs as part of the NSLP payload.
場合によっては、トンネルの出口ポイント（つまり、トンネルのデータとダウンストリームシグナリングパケットがトンネルを離れるノード）であり、トンネルシグナリングを実行したいと考えていますが、このノードはトンネルの入力の知識も制御もありません。Pointは、データフローのカプセル化を実行しています。内側のMRI/SIDがトンネルMRI/SIDにどのように関連するかについての情報は、トンネルの入り口からの信号データに携帯する必要があります。この機能は、[18]のRSVP Session_Assocオブジェクトに相当します。NSISプロトコルスイートでは、これらのバインディングは、暗黙的に（たとえば、SIDの再利用）、またはNSLPペイロードの一部として内側と外側のSIDを結合するオブジェクトを運ぶことによって明示的に管理されます。
GIST itself is essentially IP version neutral: version dependencies are isolated in the formats of the Message-Routing-Information, Network-Layer-Information, and Stack-Configuration-Data objects, and GIST also depends on the version independence of the protocols that support messaging associations. In mixed environments, GIST operation will be influenced by the IP transition mechanisms in use. This section provides a high level overview of how GIST is affected, considering only the currently predominant mechanisms.
GIST自体は本質的にIPバージョンのニュートラルです。バージョン依存関係は、メッセージルーティング情報、ネットワークレイヤー情報、およびスタックコンフィグラーデータオブジェクトの形式で分離され、GISTはサポートするプロトコルの独立性にも依存します。メッセージング協会。混合環境では、GIST操作は、使用中のIP遷移メカニズムの影響を受けます。このセクションでは、現在の主要なメカニズムのみを考慮して、GISTがどのように影響を受けるかの高レベルの概要を説明します。
Dual Stack: (As described in [35].) In mixed environments, GIST MUST use the same IP version for Q-mode encapsulated messages as given by the MRI of the flow for which it is signalling, and SHOULD do so for other signalling also (see Section 5.2.2). Messages with mismatching versions MUST be rejected with an "MRI Validation Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP Version Mismatch"). The IP version used in D-mode is closely tied to the IP version used by the data flow, so it is intrinsically impossible for an IPv4-only or IPv6-only GIST node to support signalling for flows using the other IP version. Hosts that are dual stack for applications and routers that are dual stack for forwarding need GIST implementations that can support both IP versions. Applications with a choice of IP versions might select a version based on which could be supported in the network by GIST, which could be established by invoking parallel discovery procedures.
デュアルスタック：（ [35]で説明されています。）混合環境では、GISTは、シグナル伝達であるフローのMRIによって与えられたQモードカプセル化メッセージに同じIPバージョンを使用する必要があり、他のシグナル伝達にはそうする必要があります。また、セクション5.2.2を参照）。不一致バージョンを使用したメッセージは、サブコード1（「IPバージョンのミスマッチ」）を備えた「MRI検証障害」エラーメッセージ（付録A.4.4.12）で拒否する必要があります。Dモードで使用されるIPバージョンは、データフローで使用されるIPバージョンに密接に関連しているため、IPv4のみまたはIPv6のみのGistノードが他のIPバージョンを使用してフローのシグナリングをサポートすることは本質的に不可能です。アプリケーションのデュアルスタックであるホストと、転送用のデュアルスタックであるルーターは、両方のIPバージョンをサポートできるGIST実装が必要です。IPバージョンの選択を備えたアプリケーションは、GISTによってネットワークでサポートできるバージョンを選択する場合があります。これは、並列発見手順を呼び出すことで確立できます。
Packet Translation: (Applicable to SIIT [7].) Some transition mechanisms allow IPv4 and IPv6 nodes to communicate by placing packet translators between them. From the GIST perspective, this should be treated essentially the same way as any other NAT operation (e.g., between internal and external addresses) as described in Section 7.2. The translating node needs to be GIST-aware; it will have to translate the addressing payloads between IPv4 and IPv6 formats for flows that cross between the two. The translation rules for the fields in the MRI payload (including, e.g., diffserv-codepoint and flow-label) are as defined in [7]. The same analysis applies to NAT-PT, although this technique is no longer proposed as a general purpose transition mechanism [40].
パケット翻訳：（ SIITに適用されます[7]。）一部の遷移メカニズムにより、IPv4およびIPv6ノードがパケット翻訳者をそれらの間に配置することで通信できます。要点の観点から、これは、セクション7.2で説明されているように、他のNAT操作（例えば、内部アドレスと外部アドレスの間）と同じ方法で扱う必要があります。翻訳ノードは概要を認識する必要があります。2つの間を横断するフローのために、IPv4形式とIPv6形式の間にアドレス指定されたペイロードを変換する必要があります。MRIペイロードのフィールドの翻訳ルール（Diffserv-CodePointやFlow-Labelなどを含む）は、[7]で定義されています。同じ分析がNAT-PTに当てはまりますが、この手法は汎用遷移メカニズムとして提案されなくなりました[40]。
Tunnelling: (Applicable to 6to4 [19].) Many transition mechanisms handle the problem of how an end-to-end IPv6 (or IPv4) flow can be carried over intermediate IPv4 (or IPv6) regions by tunnelling; the methods tend to focus on minimising the tunnel administration overhead. For GIST, the treatment should be similar to any other IP tunnelling mechanism, as described in Section 7.3. In particular, the end-to-end flow signalling will pass transparently through the tunnel, and signalling for the tunnel itself will have to be managed by the tunnel endpoints. However, additional considerations may arise because of special features of the tunnel management procedures. In particular, [20] is based on using an anycast address as the destination tunnel endpoint. GIST MAY use anycast destination addresses in the Q-mode encapsulation of D-mode messages if necessary, but MUST NOT use them in the Network-Layer-Information addressing field; unicast addresses MUST be used instead. Note that the addresses from the IP header are not used by GIST in matching requests and replies, so there is no requirement to use anycast source addresses.
トンネリング：（ 6to4 [19]に適用されます。）多くの遷移メカニズムは、エンドツーエンドのIPv6（またはIPv4）の流れが、トンネリングによって中間IPv4（またはIPv6）領域にどのように運ばれるかという問題を処理します。この方法は、頭上のトンネル投与の最小化に焦点を当てる傾向があります。GISTの場合、治療はセクション7.3で説明されているように、他のIPトンネルメカニズムと類似する必要があります。特に、エンドツーエンドの流れのシグナル伝達はトンネルを透過的に通過し、トンネル自体のシグナルをトンネルエンドポイントで管理する必要があります。ただし、トンネル管理手順の特別な機能により、追加の考慮事項が発生する場合があります。特に、[20]は、Anycastアドレスを宛先トンネルエンドポイントとして使用することに基づいています。GISTは、必要に応じてDモードメッセージのQモードカプセル化でAnycast宛先アドレスを使用できますが、ネットワーク層の情報アドレス指定フィールドで使用してはなりません。代わりにユニキャストアドレスを使用する必要があります。IPヘッダーのアドレスは、リクエストと返信を一致させる際にGISTによって使用されないため、Anycastソースアドレスを使用する必要はないことに注意してください。
The security requirement for GIST is to protect the signalling plane against identified security threats. For the signalling problem as a whole, these threats have been outlined in [30]; the NSIS framework [29] assigns a subset of the responsibilities to the NTLP. The main issues to be handled can be summarised as:
GISTのセキュリティ要件は、特定されたセキュリティの脅威からシグナリングプレーンを保護することです。全体としてのシグナル伝達の問題については、これらの脅威は[30]で概説されています。NSISフレームワーク[29]は、責任のサブセットをNTLPに割り当てます。処理される主な問題は、次のように要約できます。
Message Protection: Signalling message content can be protected against eavesdropping, modification, injection, and replay while in transit. This applies to GIST payloads, and GIST should also provide such protection as a service to signalling applications between adjacent peers.
メッセージ保護：シグナリングメッセージコンテンツは、輸送中に盗聴、変更、注入、およびリプレイから保護できます。これはGISTペイロードに適用されます。GISTは、隣接するピア間のアプリケーションを信号するサービスなどの保護も提供する必要があります。
Routing State Integrity Protection: It is important that signalling messages are delivered to the correct nodes, and nowhere else. Here, 'correct' is defined as 'the appropriate nodes for the signalling given the Message-Routing-Information'. In the case where the MRI is based on the flow identification for path-coupled signalling, 'appropriate' means 'the same nodes that the infrastructure will route data flow packets through'. GIST has no role in deciding whether the data flow itself is being routed correctly; all it can do is to ensure that signalling and data routing are consistent with each other. GIST uses internal state to decide how to route signalling messages, and this state needs to be protected against corruption.
ルーティング状態の整合性保護：シグナリングメッセージが正しいノードに配信されることが重要です。ここでは、「正しい」は「メッセージルーティング情報を与えられたシグナリングの適切なノード」として定義されます。MRIがパス結合信号のフロー識別に基づいている場合、「適切」は「インフラストラクチャがデータフローパケットをルーティングするのと同じノードを意味します」。GISTは、データフロー自体が正しくルーティングされているかどうかを決定する上で役割を果たしません。できることは、シグナルとデータルーティングが互いに一致していることを確認することです。GISTは内部状態を使用して信号メッセージをルーティングする方法を決定します。この状態は、腐敗から保護する必要があります。
Prevention of Denial-of-Service Attacks: GIST nodes and the network have finite resources (state storage, processing power, bandwidth). The protocol tries to minimise exhaustion attacks against these resources and not allow GIST nodes to be used to launch attacks on other network elements.
サービス拒否攻撃の防止：GISTノードとネットワークには、有限リソース（状態ストレージ、処理能力、帯域幅）があります。プロトコルは、これらのリソースに対する疲労攻撃を最小限に抑えようとし、他のネットワーク要素に対する攻撃を開始するためにGISTノードを使用しないようにします。
The main additional issue is handling authorisation for executing signalling operations (e.g., allocating resources). This is assumed to be done in each signalling application.
主な追加の問題は、シグナリング操作を実行するための許可を処理することです（例：リソースの割り当て）。これは、各シグナリングアプリケーションで行われると想定されています。
In many cases, GIST relies on the security mechanisms available in messaging associations to handle these issues, rather than introducing new security measures. Obviously, this requires the interaction of these mechanisms with the rest of the GIST protocol to be understood and verified, and some aspects of this are discussed in Section 5.7.
多くの場合、GISTは、新しいセキュリティ対策を導入するのではなく、これらの問題を処理するために、メッセージング協会で利用できるセキュリティメカニズムに依存しています。明らかに、これには、これらのメカニズムとGISTプロトコルの残りの部分との相互作用が理解され、検証される必要があり、これのいくつかの側面については、セクション5.7で説明します。
GIST can use messaging association functionality, specifically in this version TLS (Section 5.7.3), to ensure message confidentiality and integrity. Implementation of this functionality is REQUIRED but its use for any given flow or signalling application is OPTIONAL. In some cases, confidentiality of GIST information itself is not likely to be a prime concern, in particular, since messages are often sent to parties that are unknown ahead of time, although the content visible even at the GIST level gives significant opportunities for traffic analysis. Signalling applications may have their own mechanism for securing content as necessary; however, they may find it convenient to rely on protection provided by messaging associations, since it runs unbroken between signalling application peers.
GISTは、メッセージの機密性と整合性を確保するために、このバージョンTLS（セクション5.7.3）では、メッセージングアソシエーションの機能を使用できます。この機能の実装が必要ですが、任意のフローまたはシグナリングアプリケーションでの使用はオプションです。場合によっては、GIST情報自体の機密性は、特にメッセージが事前に知られていないパーティーに送信されることが多いため、最適な関心事ではない可能性がありますが、GISTレベルでも見えるコンテンツはトラフィック分析の大きな機会を与えます。。シグナリングアプリケーションには、必要に応じてコンテンツを保護するための独自のメカニズムがある場合があります。ただし、シグナリングアプリケーションピア間で壊れていないため、メッセージング協会によって提供される保護に頼るのが便利な場合があります。
Cryptographic protection (of confidentiality or integrity) requires a security association with session keys. These can be established by an authentication and key exchange protocol based on shared secrets, public key techniques, or a combination of both. Authentication and key agreement are possible using the protocols associated with the messaging association being secured. TLS incorporates this functionality directly. GIST nodes rely on the messaging association protocol to authenticate the identity of the next hop, and GIST has no authentication capability of its own.
（機密性または完全性の）暗号化保護には、セッションキーとのセキュリティ関連が必要です。これらは、共有された秘密、公開キーテクニック、またはその両方の組み合わせに基づいて、認証とキー交換プロトコルによって確立できます。認証と主要な契約は、セキュアされているメッセージング協会に関連するプロトコルを使用して可能です。TLSはこの機能を直接組み込みます。GISTノードは、次のホップのIDを認証するためにメッセージングアソシエーションプロトコルに依存しています。GISTには、独自の認証機能がありません。
With routing state discovery, there are few effective ways to know what is the legitimate next or previous hop as opposed to an impostor. In other words, cryptographic authentication here only provides assurance that a node is 'who' it is (i.e., the legitimate owner of identity in some namespace), not 'what' it is (i.e., a node which is genuinely on the flow path and therefore can carry out signalling for a particular flow). Authentication provides only limited protection, in that a known peer is unlikely to lie about its role. Additional methods of protection against this type of attack are considered in Section 8.3 below.
ルーティング州の発見により、詐欺師とは対照的に、正当な次または以前のホップが何であるかを知る効果的な方法はほとんどありません。言い換えれば、ここでの暗号化認証は、ノードが「WHO」であるという保証のみを提供します（すなわち、いくつかの名前空間のIDの正当な所有者）は、「それは何であるか」ではありません（すなわち、フローパス上にあるノードしたがって、特定のフローのシグナリングを実行できます）。認証は限られた保護のみを提供します。なぜなら、既知のピアがその役割について嘘をつく可能性は低いという点で。このタイプの攻撃に対する追加の保護方法は、以下のセクション8.3で考慮されます。
It is an implementation issue whether peer node authentication should be made signalling application dependent, for example, whether successful authentication could be made dependent on presenting credentials related to a particular signalling role (e.g., signalling for QoS). The abstract API of Appendix B leaves open such policy and authentication interactions between GIST and the NSLP it is serving. However, it does allow applications to inspect the authenticated identity of the peer to which a message will be sent before transmission.
たとえば、ピアノード認証をシグナリングアプリケーションに依存する必要があるかどうか、たとえば、特定のシグナル伝達の役割に関連する資格情報の提示に依存して成功する可能性があるかどうか（QoSのシグナリングなど）。付録Bの要約APIは、そのようなポリシーと認証の相互作用を開き、それが提供しているNSLPとの間の認証相互作用を開きます。ただし、アプリケーションは、送信前にメッセージが送信されるピアの認証されたアイデンティティを検査することができます。
Internal state in a node (see Section 4.2) is used to route messages. If this state is corrupted, signalling messages may be misdirected.
ノード内の内部状態（セクション4.2を参照）は、メッセージをルーティングするために使用されます。この状態が破損している場合、シグナリングメッセージが誤った方向に向けられる可能性があります。
In the case where the MRM is path-coupled, the messages need to be routed identically to the data flow described by the MRI, and the routing state table is the GIST view of how these flows are being routed through the network in the immediate neighbourhood of the node. Routes are only weakly secured (e.g., there is no cryptographic binding of a flow to a route), and there is no authoritative information about flow routes other than the current state of the network itself. Therefore, consistency between GIST and network routing state has to be ensured by directly interacting with the IP routing mechanisms to ensure that the signalling peers are the appropriate ones for any given flow. An overview of security issues and techniques in this context is provided in [37].
MRMがパス結合されている場合、メッセージはMRIによって記述されたデータフローと同じようにルーティングする必要があり、ルーティング状態テーブルは、これらのフローがすぐ近くにあるネットワークを介してルーティングされている方法の要点です。ノードの。ルートは弱く保護されているだけ（たとえば、ルートへのフローの暗号化結合はありません）。また、ネットワーク自体の現在の状態以外のフロールートに関する権威ある情報はありません。したがって、GISTとネットワークルーティング状態の一貫性は、IPルーティングメカニズムと直接相互作用して、シグナリングピアが特定のフローに適したメカニズムであることを確認することにより保証する必要があります。この文脈でのセキュリティの問題と手法の概要は[37]に記載されています。
In one direction, peer identification is installed and refreshed only on receiving a Response (compare Figure 5). This MUST echo the cookie from a previous Query, which will have been sent along the flow path with the Q-mode encapsulation, i.e., end-to-end addressed. Hence, only the true next peer or an on-path attacker will be able to generate such a message, provided freshness of the cookie can be checked at the Querying node.
一方向では、ピア識別がインストールされ、応答の受信時にのみ更新されます（図5を比較します）。これは、Qモードのカプセル化、つまりエンドツーエンドのアドレス指定でフローパスに沿って送信される前のクエリからCookieをエコーする必要があります。したがって、クエリノードでCookieの新鮮さを確認できれば、True Next PeerまたはPath On-Pathの攻撃者のみがそのようなメッセージを生成できます。
In the other direction, peer identification MAY be installed directly on receiving a Query containing addressing information for the signalling source. However, any node in the network could generate such a message; indeed, many nodes in the network could be the genuine upstream peer for a given flow. To protect against this, four strategies are used:
もう一方の方向では、シグナリングソースのアドレス指定情報を含むクエリを受信する際に、ピア識別を直接インストールすることができます。ただし、ネットワーク内のノードはそのようなメッセージを生成する可能性があります。実際、ネットワーク内の多くのノードは、特定のフローの本物の上流のピアになる可能性があります。これを保護するために、4つの戦略が使用されます。
Filtering: The receiving node MAY reject signalling messages that claim to be for flows with flow source addresses that could be ruled out by ingress filtering. An extension of this technique would be for the receiving node to monitor the data plane and to check explicitly that the flow packets are arriving over the same interface and if possible from the same link layer neighbour as the D-mode signalling packets. If they are not, it is likely that at least one of the signalling or flow packets is being spoofed.
フィルタリング：受信ノードは、イングレスフィルタリングによって除外される可能性のあるフローソースアドレスを使用してフロー用であると主張する信号メッセージを拒否する場合があります。この手法の拡張は、受信ノードがデータプレーンを監視し、フローパケットが同じインターフェイスに到着していることを明示的に確認するためのものです。そうでない場合は、信号またはフローパケットの少なくとも1つがスプーフィングされている可能性があります。
Return routability checking: The receiving node MAY refuse to install upstream state until it has completed a Confirm handshake with the peer. This echoes the Responder-Cookie of the Response, and discourages nodes from using forged source addresses. This also plays a role in denial-of-service prevention; see below.
ルーティング可能性チェックを返します：受信ノードは、ピアとの握手の確認が完了するまで、上流の状態をインストールすることを拒否する場合があります。これにより、応答の応答者クッキーが反映され、ノードが偽造されたソースアドレスを使用することを思いとどまらせます。これは、サービス拒否予防にも役割を果たします。下記参照。
Authorisation: A stronger approach is to carry out a peer authorisation check (see Section 4.4.2) as part of messaging association setup. The ideal situation is that the receiving node can determine the correct upstream node address from routing table analysis or knowledge of local topology constraints, and then verify from the authorised peer database (APD) that the peer has this IP address. This is only technically feasible in a limited set of deployment environments. The APD can also be used to list the subsets of nodes that are feasible peers for particular source or destination subnets, or to blacklist nodes that have previously originated attacks or exist in untrustworthy networks, which provide weaker levels of authorisation checking.
承認：より強力なアプローチは、メッセージング協会のセットアップの一環として、ピア承認チェック（セクション4.4.2を参照）を実行することです。理想的な状況は、受信ノードがルーティングテーブル分析またはローカルトポロジの制約の知識から正しいアップストリームノードアドレスを決定し、承認されたピアデータベース（APD）からピアがこのIPアドレスを持っていることを検証できることです。これは、限られた展開環境セットで技術的に実行可能です。APDを使用して、特定のソースまたは宛先サブネットの実行可能なピアであるノードのサブセットをリストしたり、以前に攻撃を開始したり、信頼できないネットワークに存在していたブラックリストノードをリストします。
SID segregation: The routing state lookup for a given MRI and NSLPID MUST also take the SID into account. A malicious node can only overwrite existing GIST routing state if it can guess the corresponding SID; it can insert state with random SID values, but generally this will not be used to route signalling messages for which state has already been legitimately established.
SIDの分離：特定のMRIおよびNSLPIDのルーティング状態検索もSIDを考慮する必要があります。悪意のあるノードは、対応するSIDを推測できる場合にのみ、既存のGISTルーティング状態を上書きできます。ランダムSID値で状態を挿入できますが、一般に、これは、状態がすでに合法的に確立されているシグナリングメッセージをルーティングするために使用されません。
GIST is designed so that in general each Query only generates at most one Response that is at most only slightly larger than the Query, so that a GIST node cannot become the source of a denial-of-service amplification attack. (There is a special case of retransmitted Response messages; see Section 5.3.3.) However, GIST can still be subjected to denial-of-service attacks where an attacker using forged source addresses forces a node to establish state without return routability, causing a problem similar to TCP SYN flood attacks. Furthermore, an adversary might use modified or replayed unprotected signalling messages as part of such an attack. There are two types of state attacks and one computational resource attack. In the first state attack, an attacker floods a node with messages that the node has to store until it can determine the next hop. If the destination address is chosen so that there is no GIST-capable next hop, the node would accumulate messages for several seconds until the discovery retransmission attempt times out. The second type of state-based attack causes GIST state to be established by bogus messages. A related computational/ network-resource attack uses unverified messages to cause a node query an authentication or authorisation infrastructure, or attempt to cryptographically verify a digital signature.
GISTは、一般に、各クエリが最大1つの応答のみを生成するように設計されており、最大でクエリよりもわずかに大きいだけで、GISTノードはサービス拒否増幅攻撃のソースになることができません。（再送信された応答メッセージの特別なケースがあります。セクション5.3.3を参照してください。）ただし、GISTは、フォードされたソースアドレスを使用して攻撃者がリターンのルーティング可能性なしに状態を確立するようにノードを強制し、TCP Syn洪水攻撃に似た問題。さらに、敵は、そのような攻撃の一部として修正または再生された無保護シグナルメッセージを使用する場合があります。州攻撃には2種類のタイプと1つの計算リソース攻撃があります。最初の状態攻撃では、攻撃者は、次のホップを決定できるまで、ノードが保存するメッセージでノードにあふれます。宛先アドレスが選択されているため、GIST対応の次のホップがないように選択された場合、ノードは、ディスカバリー再送信が試行されるまで数秒間メッセージを蓄積します。2番目のタイプの状態ベースの攻撃により、GIST状態は偽のメッセージによって確立されます。関連する計算/ネットワークリソース攻撃は、未確認のメッセージを使用して、ノードクエリに認証または認証インフラストラクチャをクエリしたり、デジタル署名を暗号化したりしようとします。
We use a combination of two defences against these attacks:
これらの攻撃に対する2つの防御の組み合わせを使用します。
1. The Responding node need not establish a session or discover its next hop on receiving the Query, but MAY wait for a Confirm, possibly on a secure channel. If the channel exists, the additional delay is one one-way delay and the total is no more than the minimal theoretically possible delay of a three-way handshake, i.e., 1.5 node-to-node round-trip times. The delay gets significantly larger if a new connection needs to be established first.
1. 応答するノードは、セッションを確立したり、クエリの受信時に次のホップを発見する必要はありませんが、おそらく安全なチャネルで確認を待つ場合があります。チャネルが存在する場合、追加の遅延は1つの片道遅延であり、合計は3方向の握手の理論的に可能な最小限の遅延、つまり1.5ノードからノードへのラウンドトリップ時間に過ぎません。最初に新しい接続を確立する必要がある場合、遅延は大幅に大きくなります。
2. The Response to the Query contains a cookie, which is repeated in the Confirm. State is only established for messages that contain a valid cookie. The setup delay is also 1.5 round-trip times. This mechanism is similar to that in SCTP [39] and other modern protocols.
2. クエリへの応答には、確認書で繰り返されるCookieが含まれています。状態は、有効なCookieを含むメッセージに対してのみ確立されています。セットアップ遅延も1.5往復時間です。このメカニズムは、SCTP [39]およびその他の最新のプロトコルのメカニズムに似ています。
There is a potential overload condition if a node is flooded with Query or Confirm messages. One option is for the node to bypass these messages altogether as described in Section 4.3.2, effectively falling back to being a non-NSIS node. If this is not possible, a node MAY still choose to limit the rate at which it processes Query messages and discard the excess, although it SHOULD first adapt its policy to one of sending Responses statelessly if it is not already doing so. A conformant GIST node will automatically decrease the load by retransmitting Queries with an exponential backoff. A non-conformant node (launching a DoS attack) can generate uncorrelated Queries at an arbitrary rate, which makes it hard to apply rate-limiting without also affecting genuine handshake attempts. However, if Confirm messages are requested, the cookie binds the message to a Querying node address that has been validated by a return routability check and rate-limits can be applied per source.
ノードにクエリがあふれたり、メッセージを確認している場合、潜在的な過負荷状態があります。1つのオプションは、セクション4.3.2で説明されているように、これらのメッセージを完全にバイパスすることで、効果的に非NSISノードに戻ります。これが不可能な場合、ノードは、クエリメッセージを処理して過剰を破棄するレートを制限することを選択できますが、最初にポリシーを依然としてそうしていない場合は、レスポンをステートレレスに送信するポリシーを適応させる必要があります。コンフォーマントGISTノードは、指数バックオフでクエリを再送信することにより、負荷を自動的に減少させます。不適合ノード（DOS攻撃の起動）は、任意のレートで無相関クエリを生成する可能性があるため、本物の握手の試みにも影響を与えることなく、レート制限を適用することが困難になります。ただし、確認メッセージが要求された場合、Cookieはメッセージを返信可能性チェックによって検証されたクエリノードアドレスにバインドし、ソースごとにレート制限を適用できます。
Once a node has decided to establish routing state, there may still be transport and security state to be established between peers. This state setup is also vulnerable to denial-of-service attacks. GIST relies on the implementations of the lower layer protocols that make up messaging associations to mitigate such attacks. In the current specification, the Querying node is always the one wishing to establish a messaging association, so it is the Responding node that needs to be protected. It is possible for an attacking node to execute these protocols legally to set up large numbers of associations that were never used, and Responding node implementations MAY use rate-limiting or other techniques to control the load in such cases.
ノードがルーティング状態を確立することを決定した後、ピア間で輸送とセキュリティ状態が確立される可能性があります。この州のセットアップは、サービス拒否攻撃に対しても脆弱です。GISTは、このような攻撃を緩和するためのメッセージング関連を構成する下層プロトコルの実装に依存しています。現在の仕様では、クエリノードは常にメッセージングアソシエーションを確立したいと考えているため、保護する必要があるのは応答ノードです。攻撃ノードがこれらのプロトコルを合法的に実行して、使用されない多数の関連付けをセットアップすることができ、応答するノードの実装では、レート制限またはその他の手法を使用してそのような場合の負荷を制御する可能性があります。
Signalling applications can use the services provided by GIST to defend against certain (e.g., flooding) denial-of-service attacks. In particular, they can elect to process only messages from peers that have passed a return routability check or been authenticated at the messaging association level (see Appendix B.2). Signalling applications that accept messages under other circumstances (in particular, before routing state has been fully established at the GIST level) need to take this into account when designing their denial-of-service prevention mechanisms, for example, by not creating local state as a result of processing such messages. Signalling applications can also manage overload by invoking flow control, as described in Section 4.1.1.
シグナリングアプリケーションは、GISTが提供するサービスを使用して、特定の（たとえば、洪水）サービス拒否攻撃を防御することができます。特に、彼らは、返品ルー上のチェックに合格したピアからのメッセージのみを処理することを選択できます。他の状況下でメッセージを受け入れる信号アプリケーション（特に、ルーティング状態がGISTレベルで完全に確立される前）は、サービス拒否予防メカニズムを設計する際に、これを考慮に入れる必要があります。そのようなメッセージを処理した結果。セクション4.1.1で説明されているように、シグナリングアプリケーションは、フロー制御を呼び出すことにより、過負荷を管理することもできます。
The requirements on the Query-Cookie can be summarised as follows:
クエリクッキーの要件は、次のように要約できます。
Liveness: The cookie must be live; that is, it must change from one handshake to the next. This prevents replay attacks.
livension：クッキーはライブでなければなりません。つまり、片方のハンドシェイクから次の手で変更する必要があります。これにより、リプレイ攻撃が防止されます。
Unpredictability: The cookie must not be guessable, e.g., from a sequence or timestamp. This prevents direct forgery after capturing a set of earlier messages.
予測不可能性：Cookieは、たとえば、シーケンスやタイムスタンプから推測できることではありません。これにより、以前のメッセージのセットをキャプチャした後、直接の偽造を防ぎます。
Easily validated: It must be efficient for the Q-Node to validate that a particular cookie matches an in-progress handshake, for a routing state machine that already exists. This allows to discard responses that have been randomly generated by an adversary, or to discard responses to queries that were generated with forged source addresses or an incorrect address in the included NLI object.
簡単に検証する：Qノードが、特定のCookieが、すでに存在するルーティング状態マシンについて、進行中の握手と一致することを検証することは効率的でなければなりません。これにより、敵によってランダムに生成された応答を破棄したり、付属のNLIオブジェクトに鍛造されたソースアドレスまたは誤ったアドレスで生成されたクエリに対する応答を破棄できます。
Uniqueness: Each handshake must have a unique cookie since the cookie is used to match responses within a handshake, e.g., when multiple messaging associations are multiplexed over the same transport connection.
一意性：クッキーは、同じ輸送接続で複数のメッセージング関連が多重化されている場合、クッキーは握手内の応答を一致させるために使用されるため、一意のクッキーが必要です。
Likewise, the requirements on the Responder-Cookie can be summarised as follows:
同様に、Responder-Cookieの要件は次のように要約できます。
Liveness: The cookie must be live as above, to prevent replay attacks.
活性：リプレイ攻撃を防ぐために、Cookieは上記のように生きている必要があります。
Creation simplicity: The cookie must be lightweight to generate in order to avoid resource exhaustion at the responding node.
作成のシンプルさ：応答ノードでのリソースの疲労を避けるために、Cookieは生成するために軽量でなければなりません。
Validation simplicity: It must be simple for the R-node to validate that an R-Cookie was generated by itself and no one else, without storing state about the handshake for which it was generated.
検証のシンプルさ：Rノードが、R-Cookieがそれ自体で生成され、他の誰も生成されないことを検証することは簡単でなければなりません。
Binding: The cookie must be bound to the routing state that will be installed, to prevent use with different routing state, e.g., in a modified Confirm. The routing state here includes the Peer-Identity and Interface-Address given in the NLI of the Query, and the MRI/NSLPID for the messaging.
バインディング：Cookieは、異なるルーティング状態での使用を防ぐために、修正された確認のために、インストールされるルーティング状態にバインドする必要があります。ここでのルーティング状態には、クエリのNLIに与えられたピアアイデンティティとインターフェイスアドレス、およびメッセージング用のMRI/NSLPIDが含まれます。
It can also include the interface on which the Query was received for use later in route change detection (Section 7.1.2). Since a Q-mode encapsulated message is the one that will best follow the data path, subsequent changes in this arrival interface indicate route changes between the peers.
また、ルート変更検出で後で使用するためにクエリが受信されたインターフェイスを含めることもできます（セクション7.1.2）。Qモードカプセル化されたメッセージはデータパスに最適なメッセージであるため、この到着インターフェイスのその後の変更は、ピア間のルートの変更を示します。
A suitable implementation for the Q-Cookie is a cryptographically strong random number that is unique for this routing state machine handshake. A node MUST implement this or an equivalently strong mechanism. Guidance on random number generation can be found in [31].
Q-Cookieに適した実装は、このルーティング状態マシンのハンドシェイクに固有の暗号化的に強い乱数です。ノードは、これまたは同等の強力なメカニズムを実装する必要があります。乱数生成に関するガイダンスは[31]にあります。
A suitable basic implementation for the R-Cookie is as follows:
R-Cookieに適した基本的な実装は次のとおりです。
R-Cookie = liveness data + reception interface + hash (locally known secret, Q-Node NLI identity and address, MRI, NSLPID, liveness data)
r-cookie = livenings data受信インターフェイスハッシュ（局所的に知られている秘密、q-node nliアイデンティティとアドレス、MRI、nslpid、liveningsデータ）
A node MUST implement this or an equivalently strong mechanism. There are several alternatives for the liveness data. One is to use a timestamp like SCTP. Another is to give the local secret a (rapid) rollover, with the liveness data as the generation number of the secret, like IKEv2. In both cases, the liveness data has to be carried outside the hash, to allow the hash to be verified at the Responder. Another approach is to replace the hash with encryption under a locally known secret, in which case the liveness data does not need to be carried in the clear. Any symmetric cipher immune to known plaintext attacks can be used. In the case of GIST-aware NAT traversal with delayed state installation, it is necessary to carry additional data in the cookie; appropriate constructions are described in [44].
ノードは、これまたは同等の強力なメカニズムを実装する必要があります。責任データにはいくつかの選択肢があります。1つは、SCTPのようなタイムスタンプを使用することです。もう1つは、地元の秘密に（迅速な）ロールオーバーを与えることであり、livensionデータをIKEV2のような秘密の生成数として提供することです。どちらの場合も、ハッシュをレスポンダーで検証するために、ハッシュの外側に描写される必要があります。別のアプローチは、ハッシュをローカルに知られている秘密の下で暗号化に置き換えることです。その場合、livenivesデータを明確にする必要はありません。既知のプレーンテキスト攻撃に免疫がある対称暗号を使用することができます。状態の設置が遅れているため、要点を認識しているNATトラバーサルの場合、Cookieに追加データを携帯する必要があります。適切な構造は[44]で説明されています。
To support the validation simplicity requirement, the Responder can check the liveness data to filter out some blind (flooding) attacks before beginning any cryptographic cookie verification. To support this usage, the liveness data must be carried in the clear and not be easily guessable; this rules out the timestamp approach and suggests the use of sequence of secrets with the liveness data identifying the position in the sequence. The secret strength and rollover frequency must be high enough that the secret cannot be brute-forced during its lifetime. Note that any node can use a Query to discover the current liveness data, so it remains hard to defend against sophisticated attacks that disguise such probes within a flood of Queries from forged source addresses. Therefore, it remains important to use an efficient hashing mechanism or equivalent.
検証のシンプルさの要件をサポートするために、レスポンダーは、暗号化されたCookie検証を開始する前に、視覚障害データをチェックして、盲目（洪水）攻撃を除外することができます。この使用法をサポートするには、責任データを明確にして、簡単に推測することはできません。これは、タイムスタンプのアプローチを除外し、シーケンス内の位置を識別する活性データを使用した秘密のシーケンスの使用を示唆しています。秘密の強さとロールオーバーの頻度は、その生涯に秘密をブルート強化することができないほど高くなければなりません。任意のノードはクエリを使用して現在の活性データを発見できることに注意してください。したがって、偽造ソースアドレスからのクエリの洪水の中でそのようなプローブを偽装する洗練された攻撃から防御することは困難なままです。したがって、効率的なハッシュメカニズムまたは同等物を使用することが重要です。
If a node receives a message for which cookie validation fails, it MAY return an "Object Value Error" message (Appendix A.4.4.10) with subcode 4 ("Invalid Cookie") to the sender and SHOULD log an error condition locally, as well as dropping the message. However, sending the error in general makes a node a source of backscatter. Therefore, this MUST only be enabled selectively, e.g., during initial deployment or debugging.
ノードがCookie検証に失敗するメッセージを受信した場合、サブコード4（「無効なCookie」）を備えた「オブジェクト値エラー」メッセージ（付録A.4.4.10）を送信者に返す場合があり、エラー条件をローカルに記録する必要があります。メッセージをドロップするだけでなく。ただし、一般にエラーを送信すると、ノードが後方散乱のソースになります。したがって、これは、初期展開またはデバッグ中に選択的にのみ有効にする必要があります。
This specification defines a single mandatory-to-implement security protocol (TLS; Section 5.7.3). However, it is possible to define additional security protocols in the future, for example, to allow re-use with other types of credentials, or migrate towards protocols with stronger security properties. In addition, use of any security protocol for a messaging association is optional. Security protocol selection is carried out as part of the GIST handshake mechanism (Section 4.4.1).
この仕様では、単一の必須対応セキュリティプロトコル（TLS;セクション5.7.3）を定義します。ただし、たとえば、他のタイプの資格情報との再利用を許可したり、より強力なセキュリティプロパティを備えたプロトコルに移行したりするために、将来の追加のセキュリティプロトコルを定義することができます。さらに、メッセージングアソシエーションにセキュリティプロトコルを使用することはオプションです。セキュリティプロトコルの選択は、GISTハンドシェイクメカニズムの一部として実行されます（セクション4.4.1）。
The selection process may be vulnerable to downgrade attacks, where a man in the middle modifies the capabilities offered in the Query or Response to mislead the peers into accepting a lower level of protection than is achievable. There is a two-part defence against such attacks (the following is based the same concepts as [25]): 1. The Response does not depend on the Stack-Proposal in the Query (see Section 5.7.1). Therefore, tampering with the Query has no effect on the resulting messaging association configuration.
選択プロセスは、攻撃のダウングレードに対して脆弱である可能性があります。この場合、中央の男性は、クエリまたは応答で提供される機能を修正して、ピアが達成可能なよりも低いレベルの保護を受け入れるように誤解を招くように変更します。そのような攻撃に対する2部構成の防御があります（以下は[25]と同じ概念に基づいています）：1。応答は、クエリのスタックプロポザルに依存しません（セクション5.7.1を参照）。したがって、クエリの改ざんは、結果のメッセージングアソシエーション構成に影響を与えません。
2. The Responding node's Stack-Proposal is echoed in the Confirm. The Responding node checks this to validate that the proposal it made in the Response is the same as the one received by the Querying node. Note that as a consequence of the previous point, the Responding node does not have to remember the proposal explicitly, since it is a static function of local policy.
2. 応答するノードのスタックプロポザルは、確認に反映されています。応答するノードは、これをチェックして、応答で作成した提案がクエリノードで受信したものと同じであることを検証します。前のポイントの結果として、応答するノードは、ローカルポリシーの静的機能であるため、提案を明示的に覚えておく必要はないことに注意してください。
The validity of the second part depends on the strength of the security protection provided for the Confirm. If the Querying node is prepared to create messaging associations with null security properties (e.g., TCP only), the defence is ineffective, since the man in the middle can re-insert the original Responder's Stack-Proposal, and the Responding node will assume that the minimal protection is a consequence of Querying node limitations. However, if the messaging association provides at least integrity protection that cannot be broken in real-time, the Confirm cannot be modified in this way. Therefore, if the Querying node does not apply a security policy to the messaging association protocols to be created that ensures at least this minimal level of protection is met, it remains open to the threat that a downgrade has occurred. Applying such a policy ensures capability discovery process will result in the setup of a messaging association with the correct security properties for the two peers involved.
2番目の部分の妥当性は、確認のために提供されるセキュリティ保護の強度に依存します。クエリノードがNULLセキュリティプロパティとのメッセージング関連を作成する準備ができている場合（例：TCPのみ）、防御は効果がありません。これは、中央の男性が元のResponderのスタックプロポザルを再挿入できるため、応答するノードはそれを想定します。最小限の保護は、ノードの制限のクエリの結果です。ただし、メッセージング協会が少なくともリアルタイムで破壊できない整合性保護を提供する場合、この方法で確認は変更できません。したがって、クエリノードが、少なくともこの最小レベルの保護が満たされることを保証するメッセージング協会のプロトコルにセキュリティポリシーを適用しない場合、ダウングレードが発生した脅威に対して開かれたままです。このようなポリシーを適用すると、能力の発見プロセスが、関係する2人のピアの正しいセキュリティプロパティとのメッセージング関連が設定されるようになります。
Taking the above security mechanisms into account, the main residual threats against NSIS are three types of on-path attack, vulnerabilities from particular limited modes of TLS usage, and implementation-related weaknesses.
上記のセキュリティメカニズムを考慮に入れて、NSISに対する主な残留脅威は、3種類のパス攻撃、TLS使用の特定の限られたモードの脆弱性、および実装関連の弱点です。
An on-path attacker who can intercept the initial Query can do most things it wants to the subsequent signalling. It is very hard to protect against this at the GIST level; the only defence is to use strong messaging association security to see whether the Responding node is authorised to take part in NSLP signalling exchanges. To some extent, this behaviour is logically indistinguishable from correct operation, so it is easy to see why defence is difficult. Note that an on-path attacker of this sort can do anything to the traffic as well as the signalling. Therefore, the additional threat induced by the signalling weakness seems tolerable.
最初のクエリを傍受できるパス上の攻撃者は、その後のシグナリングに望むほとんどのことを行うことができます。要点レベルでこれを保護することは非常に困難です。唯一の防御は、強力なメッセージング協会のセキュリティを使用して、応答するノードがNSLPシグナリング交換に参加することを許可されているかどうかを確認することです。ある程度、この動作は論理的に正しい操作と見分けがつかないため、防御が困難である理由は簡単にわかります。この種のパス上の攻撃者は、信号だけでなくトラフィックに対して何でもできることに注意してください。したがって、シグナルの弱点によって引き起こされる追加の脅威は許容できるようです。
At the NSLP level, there is a concern about transitivity of trust of correctness of routing along the signalling chain. The NSLP at the querying node can have good assurance that it is communicating with an on-path peer or a node delegated by the on-path node by depending on the security protection provided by GIST. However, it has no assurance that the node beyond the responder is also on-path, or that the MRI (in particular) is not being modified by the responder to refer to a different flow. Therefore, if it sends signalling messages with payloads (e.g., authorisation tokens) that are valuable to nodes beyond the adjacent hop, it is up to the NSLP to ensure that the appropriate chain of trust exists. This could be achieved using higher layer security protection such as Cryptographic Message Syntax (CMS) [28].
NSLPレベルでは、シグナル伝達チェーンに沿ったルーティングの正確性の信頼の交換性について懸念があります。クエリノードのNSLPは、GISTが提供するセキュリティ保護に応じて、オンパスのピアまたはオンパスノードによって委任されたノードと通信していることを保証できます。ただし、レスポンダーを超えたノードもパス上であるか、MRI（特に）が応答者によって変更されて別のフローを参照することを保証することはありません。したがって、隣接するホップを超えてノードにとって価値のあるペイロード（承認トークンなど）を使用して信号メッセージを送信する場合、適切な信頼チェーンが存在することを保証するのはNSLP次第です。これは、暗号化メッセージ構文（CMS）[28]などの高層セキュリティ保護を使用して達成できます。
There is a further residual attack by a node that is not on the path of the Query, but is on the path of the Response, or is able to use a Response from one handshake to interfere with another. The attacker modifies the Response to cause the Querying node to form an adjacency with it rather than the true peer. In principle, this attack could be prevented by including an additional cryptographic object in the Response that ties the Response to the initial Query and the routing state and can be verified by the Querying node.
クエリのパスにはないが、応答のパス上にあるノードによるさらなる残留攻撃があります。または、ある手節からの応答を使用して別の手作業を妨害することができます。攻撃者は、応答を変更して、クエリノードを真のピアではなく、隣接するノードを形成します。原則として、この攻撃は、初期クエリとルーティング状態に応答する応答に追加の暗号化オブジェクトを含めることで防止でき、クエリノードによって検証できます。
GIST depends on TLS for peer node authentication, and subsequent channel security. The analysis in [30] indicates the threats that arise when the peer node authentication is incomplete -- specifically, when unilateral authentication is performed (one node authenticates the other, but not vice versa). In this specification, mutual authentication can be supported either by certificate exchange or the use of pre-shared keys (see Section 5.7.3); if some other TLS authentication mechanism is negotiated, its properties would have to be analysed to determine acceptability for use with GIST. If mutual authentication is performed, the requirements for NTLP security are met.
GISTは、ピアノード認証のTLS、およびその後のチャネルセキュリティに依存します。[30]の分析は、ピアノード認証が不完全であるときに生じる脅威を示しています。具体的には、一方的な認証が実行された場合（一方のノードはもう一方を認証しますが、逆ではありません）。この仕様では、相互認証は、証明書交換または事前共有キーの使用によってサポートできます（セクション5.7.3を参照）。他のTLS認証メカニズムが交渉された場合、GISTで使用する許容性を決定するために、その特性を分析する必要があります。相互認証が実行されると、NTLPセキュリティの要件が満たされます。
However, in the case of certificate exchange, this specification allows the possibility that only a server certificate is provided, which means that the Querying node authenticates the Responding node but not vice versa. Accepting such unilateral authentication allows for partial security in environments where client certificates are not widespread, and is better than no security at all; however, it does expose the Responding node to certain threats described in Section 3.1 of [30]. For example, the Responding node cannot verify whether there is a man-in-the-middle between it and the Querying node, which could be manipulating the signalling messages, and it cannot verify the identity of the Querying node if it requests authorisation of resources. Note that in the case of host-network signalling, the Responding node could be either the host or the first hop router, depending on the signalling direction. Because of these vulnerabilities, modes or deployments of TLS which do not provide mutual authentication can be considered as at best transitional stages rather than providing a robust security solution.
ただし、証明書交換の場合、この仕様により、サーバー証明書のみが提供される可能性があります。つまり、クエリノードは応答ノードを認証しますが、その逆ではありません。このような一方的な認証を受け入れることで、クライアント証明書が広く普及しておらず、セキュリティがまったくないよりも優れている環境での部分的なセキュリティが可能になります。ただし、[30]のセクション3.1で説明されている特定の脅威に応答するノードを公開します。たとえば、応答するノードは、それとクエリノードの間に中間のマンがいるかどうかを確認することはできません。これは、シグナリングメッセージを操作している可能性があり、リソースの許可を要求するとクエリノードのIDを確認できません。。ホストネットワークシグナリングの場合、応答ノードは、信号方向に応じて、ホストまたは最初のホップルーターのいずれかである可能性があることに注意してください。これらの脆弱性のため、相互認証を提供しないTLSのモードまたは展開は、堅牢なセキュリティソリューションを提供するのではなく、せいぜい移行段階と見なすことができます。
Certain security aspects of GIST operation depend on signalling application behaviour: a poorly implemented or compromised NSLP could degrade GIST security. However, the degradation would only affect GIST handling of the NSLP's own signalling traffic or overall resource usage at the node where the weakness occurred, and implementation weakness or compromise could have just as great an effect within the NSLP itself. GIST depends on NSLPs to choose SIDs appropriately (Section 4.1.3). If NSLPs choose non-random SIDs, this makes off-path attacks based on SID guessing easier to carry out. NSLPs can also leak information in structured SIDs, but they could leak similar information in the NSLP payload data anyway.
GIST操作の特定のセキュリティの側面は、シグナリングアプリケーションの動作に依存します。NSLPが不十分に実装または侵害された場合、GISTセキュリティを分解する可能性があります。ただし、劣化は、NSLP独自のシグナリングトラフィックのGIST処理または弱点が発生したノードでの全体的なリソースの使用にのみ影響し、実装の弱点や妥協はNSLP自体内で大きな影響を与える可能性があります。GISTは、SIDを適切に選択するNSLPに依存します（セクション4.1.3）。NSLPSが非ランダムSIDを選択した場合、これによりSIDの推測に基づいて実行が容易になります。NSLPは、構造化されたSIDで情報を漏らすこともできますが、とにかくNSLPペイロードデータに同様の情報を漏らすことができます。
This section defines the registries and initial codepoint assignments for GIST. It also defines the procedural requirements to be followed by IANA in allocating new codepoints. Note that the guidelines on the technical criteria to be followed in evaluating requests for new codepoint assignments are covered normatively in a separate document that considers the NSIS protocol suite in a unified way. That document discusses the general issue of NSIS extensibility, as well as the technical criteria for particular registries; see [12] for further details.
このセクションでは、GISTのレジストリと初期コードポイント割り当てを定義します。また、新しいコードポイントを割り当てる際にIANAが従うべき手続き要件を定義します。NSISプロトコルスイートを統一された方法で考慮する別のドキュメントでは、新しいCodePoint割り当てのリクエストを評価する際に従うべき技術基準に関するガイドラインは規範的にカバーされていることに注意してください。このドキュメントでは、NSIS拡張性の一般的な問題と、特定のレジストリの技術的基準について説明します。詳細については、[12]を参照してください。
The registry definitions that follow leave large blocks of codes marked "Reserved". This is to allow a future revision of this specification or another Experimental document to modify the relative space given to different allocation policies, without having to change the initial rules retrospectively if they turn out to have been inappropriate, e.g., if the space for one particular policy is exhausted too quickly.
続くレジストリ定義は、「予約された」とマークされたコードの大きなブロックを残します。これは、この仕様または別の実験文書の将来の改訂を許可して、異なる配分ポリシーに与えられた相対的な空間を変更することです。ポリシーは速すぎます。
The allocation policies used in this section follow the guidance given in [4]. In addition, for a number of the GIST registries, this specification also defines private/experimental ranges as discussed in [9]. Note that the only environment in which these codepoints can validly be used is a closed one in which the experimenter knows all the experiments in progress.
このセクションで使用されている割り当てポリシーは、[4]で与えられたガイダンスに従います。さらに、多くのGISTレジストリの場合、この仕様は[9]で説明したプライベート/実験範囲も定義します。これらのコードポイントを有効に使用できる唯一の環境は、実験者が進行中のすべての実験を知っている閉じた環境であることに注意してください。
This specification allocates the following codepoints in existing registries:
この仕様は、既存のレジストリに次のコードポイントを割り当てます。
Well-known UDP port 270 as the destination port for Q-mode encapsulated GIST messages (Section 5.3).
Qモードがカプセル化されたGISTメッセージの宛先ポートとして有名なUDPポート270（セクション5.3）。
This specification creates the following registries with the structures as defined below:
この仕様では、以下に定義するように、構造を含む次のレジストリを作成します。
NSLP Identifiers: Each signalling application requires the assignment of one or more NSLPIDs. The following NSLPID is allocated by this specification:
NSLP識別子：各シグナリングアプリケーションでは、1つ以上のNSLPIDの割り当てが必要です。次のNSLPIDは、この仕様によって割り当てられます。
+---------+---------------------------------------------------------+
| NSLPID | Application |
+---------+---------------------------------------------------------+
| 0 | Used for GIST messages not related to any signalling |
| | application. |
+---------+---------------------------------------------------------+
Every other NSLPID that uses an MRM that requires RAO usage MUST be associated with a specific RAO value; multiple NSLPIDs MAY be associated with the same RAO value. RAO value assignments require a specification of the processing associated with messages that carry the value. NSLP specifications MUST normatively depend on this document for the processing, specifically Sections 4.3.1, 4.3.4 and 5.3.2. The NSLPID is a 16-bit integer, and the registration procedure is IESG Aproval. Further values are as follows:
RAOの使用を必要とするMRMを使用する他のすべてのNSLPIDは、特定のRAO値に関連付けられている必要があります。複数のNSLPIDは、同じRAO値に関連付けられている場合があります。RAO値の割り当てでは、値を運ぶメッセージに関連付けられた処理の仕様が必要です。NSLP仕様は、特にセクション4.3.1、4.3.4、および5.3.2の処理について、このドキュメントに依存する必要があります。NSLPIDは16ビット整数であり、登録手順はIESG Aprovalです。さらに値は次のとおりです。
1-32703: Unassigned
1-32703：割り当てられていない
32704-32767: Private/Experimental Use
32704-32767：プライベート/実験的使用
32768-65536: Reserved
32768-65536：予約
GIST Message Type: The GIST common header (Appendix A.1) contains a 7-bit message type field. The following values are allocated by this specification:
GISTメッセージタイプ：GIST共通ヘッダー（付録A.1）には、7ビットメッセージタイプフィールドが含まれています。次の値は、この仕様によって割り当てられます。
+---------+----------+
| MType | Message |
+---------+----------+
| 0 | Query |
| | |
| 1 | Response |
| | |
| 2 | Confirm |
| | |
| 3 | Data |
| | |
| 4 | Error |
| | |
| 5 | MA-Hello |
+---------+----------+
Registration procedures are as follows:
登録手順は次のとおりです。
0-31: IETF Review
0-31：IETFレビュー
32-55: Expert Review
32-55：専門家のレビュー
Further values are as follows:
さらに値は次のとおりです。
6-55: Unassigned
6-55：割り当てられていない
56-63: Private/Experimental Use
56-63：プライベート/実験的使用
64-127: Reserved
64-127：予約済み
Object Types: There is a 12-bit field in the object header (Appendix A.2). The following values for object type are defined by this specification:
オブジェクトタイプ：オブジェクトヘッダーには12ビットフィールドがあります（付録A.2）。オブジェクトタイプの次の値は、この仕様で定義されます。
+---------+-----------------------------+
| OType | Object Type |
+---------+-----------------------------+
| 0 | Message Routing Information |
| | |
| 1 | Session ID |
| | |
| 2 | Network Layer Information |
| | |
| 3 | Stack Proposal |
| | |
| 4 | Stack Configuration Data |
| | |
| 5 | Query-Cookie |
| | |
| 6 | Responder-Cookie |
| | |
| 7 | NAT Traversal |
| | |
| 8 | NSLP Data |
| | |
| 9 | Error |
| | |
| 10 | Hello ID |
+---------+-----------------------------+
Registration procedures are as follows:
登録手順は次のとおりです。
0-1023: IETF Review
0-1023：IETFレビュー
1024-1999: Specification Required
1024-1999：仕様が必要です
Further values are as follows:
さらに値は次のとおりです。
11-1999: Unassigned
11-1999：割り当てられていない
2000-2047: Private/Experimental Use
2000-2047：プライベート/実験的使用
2048-4095: Reserved
2048-4095：予約
When a new object type is allocated according to one of the procedures, the specification MUST provide the object format and define the setting of the extensibility bits (A/B; see Appendix A.2.1).
手順の1つに従って新しいオブジェクトタイプが割り当てられた場合、仕様はオブジェクト形式を提供し、拡張性ビットの設定を定義する必要があります（A/B;付録A.2.1を参照）。
Message Routing Methods: GIST allows multiple message routing methods (see Section 3.3). The MRM is indicated in the leading byte of the MRI object (Appendix A.3.1). This specification defines the following values:
メッセージルーティング方法：GISTでは、複数のメッセージルーティングメソッドが許可されます（セクション3.3を参照）。MRMは、MRIオブジェクトの主要なバイトに示されています（付録A.3.1）。この仕様は次の値を定義します。
+------------+------------------------+
| MRM-ID | Message Routing Method |
+------------+------------------------+
| 0 | Path-Coupled MRM |
| | |
| 1 | Loose-End MRM |
+------------+------------------------+
Registration procedures are as follows:
登録手順は次のとおりです。
0-63: IETF Review
0-63：IETFレビュー
64-119: Specification Required
64-119：仕様が必要です
Further values are as follows:
さらに値は次のとおりです。
2-119: Unassigned
2-119：割り当てられていない
120-127: Private/Experimental Use
120-127：プライベート/実験的使用
128-255: Reserved
128-255：予約済み
When a new MRM is allocated according to one of the registration procedures, the specification MUST provide the information described in Section 3.3.
登録手順の1つに従って新しいMRMが割り当てられた場合、仕様はセクション3.3で説明されている情報を提供する必要があります。
MA-Protocol-IDs: Each protocol that can be used in a messaging association is identified by a 1-byte MA-Protocol-ID (Section 5.7). Note that the MA-Protocol-ID is not an IP protocol number; indeed, some of the messaging association protocols -- such as TLS -- do not have an IP protocol number. This is used as a tag in the Stack-Proposal and Stack-Configuration-Data objects (Appendix A.3.4 and Appendix A.3.5). The following values are defined by this specification:
MA-Protocol-ID：メッセージングアソシエーションで使用できる各プロトコルは、1バイトのMA-Protocol-IDによって識別されます（セクション5.7）。MA-Protocol-IDはIPプロトコル番号ではないことに注意してください。実際、TLSなどのメッセージング関連プロトコルの一部には、IPプロトコル番号がありません。これは、スタックプロポザルおよびスタックコンフィグラーデータオブジェクトのタグとして使用されます（付録A.3.4および付録A.3.5）。次の値は、この仕様で定義されます。
+---------------------+-----------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+-----------------------------------------+
| 0 | Reserved |
| | |
| 1 | TCP opened in the forwards direction |
| | |
| 2 | TLS initiated in the forwards direction |
+---------------------+-----------------------------------------+
Registration procedures are as follows:
登録手順は次のとおりです。
0-63: IETF Review
0-63：IETFレビュー
64-119: Expert Review
64-119：専門家のレビュー
Further values are as follows:
さらに値は次のとおりです。
3-119: Unassigned
3-119：割り当てられていない
120-127: Private/Experimental Use
120-127：プライベート/実験的使用
128-255: Reserved
128-255：予約済み
When a new MA-Protocol-ID is allocated according to one of the registration procedures, a specification document will be required. This MUST define the format for the MA-protocol-options field (if any) in the Stack-Configuration-Data object that is needed to define its configuration. If a protocol is to be used for reliable message transfer, it MUST be described how delivery errors are to be detected by GIST. Extensions to include new channel security protocols MUST include a description of how to integrate the functionality described in Section 3.9 with the rest of GIST operation. If the new MA-Protocol-ID can be used in conjunction with existing ones (for example, a new transport protocol that could be used with Transport Layer Security), the specification MUST define the interaction between the two.
登録手順の1つに従って新しいMA-Protocol-IDが割り当てられると、仕様文書が必要になります。これにより、構成を定義するために必要なStack-Configuration-DataオブジェクトのMA-Protocol-Optionsフィールド（存在する場合）の形式を定義する必要があります。プロトコルを信頼できるメッセージ転送に使用する場合、GISTによって配信エラーがどのように検出されるかを説明する必要があります。新しいチャネルセキュリティプロトコルを含める拡張機能は、セクション3.9で説明されている機能を残りのGIST操作と統合する方法の説明を含める必要があります。新しいMA-Protocol-IDを既存のもの（たとえば、輸送層セキュリティで使用できる新しい輸送プロトコル）と組み合わせて使用できる場合、仕様は2つの間の相互作用を定義する必要があります。
Error Codes/Subcodes: There is a 2-byte error code and 1-byte subcode in the Value field of the Error Object (Appendix A.4.1). Error codes 1-12 are defined in Appendix A.4.4 together with subcodes 0-5 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code 12). Additional codes and subcodes are allocated on a first-come, first-served basis. When a new code/subcode combination is allocated, the following information MUST be provided: Error case: textual name of error
エラーコード/サブコード：エラーオブジェクトの値フィールドに2バイトエラーコードと1バイトサブコードがあります（付録A.4.1）。エラーコード1-12は、サブコード0-5（コード1）、0-5（コード9）、0-5（コード10）、および0-2（コード12）とともに、付録A.4.4で定義されています。追加のコードとサブコードは、先着順で割り当てられます。新しいコード/サブコードの組み合わせが割り当てられた場合、次の情報を提供する必要があります：エラーケース：テキストのエラー名
Error class: from the categories given in Appendix A.4.3
エラークラス：付録A.4.3に記載されているカテゴリから
Error code: allocated by IANA, if a new code is required
エラーコード：新しいコードが必要な場合は、IANAによって割り当てられています
Error subcode: subcode point, also allocated by IANA
エラーサブコード：ianaによって割り当てられたサブコードポイント
Additional information: what Additional Information fields are mandatory to include in the error message, from Appendix A.4.2
追加情報：付録A.4.2からのエラーメッセージに含めるために必須の追加情報フィールドが必須です
Additional Information Types: An Error Object (Appendix A.4.1) may contain Additional Information fields. Each possible field type is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in Appendix A.4.2; additional AI-Types are allocated on a first-come, first-served basis.
追加情報タイプ：エラーオブジェクト（付録A.4.1）には、追加情報フィールドが含まれる場合があります。可能な各フィールドタイプは、16ビットAIタイプで識別されます。AI-Types 1-4は、付録A.4.2で定義されています。追加のAI-Typesは、先着順で割り当てられます。
This document is based on the discussions within the IETF NSIS working group. It has been informed by prior work and formal and informal inputs from: Cedric Aoun, Attila Bader, Vitor Bernado, Roland Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko Chong, Luis Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann, Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor Hepworth, Thomas Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia Kappler, Georgios Karagiannis, Ruud Klaver, Max Laier, Chris Lang, Lauri Liuhto, John Loughney, Allison Mankin, Jukka Manner, Pete McCann, Andrew McDonald, Mac McTiffin, Glenn Morrow, Dave Oran, Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Nuutti Varis, Michael Welzl, Lars Westberg, and Mayi Zoumaro-djayoon. Parts of the TLS usage description (Section 5.7.3) were derived from the Diameter base protocol specification, RFC 3588. In addition, Hannes Tschofenig provided a detailed set of review comments on the security section, and Andrew McDonald provided the formal description for the initial packet formats and the name matching algorithm for TLS. Chris Lang's implementation work provided objective feedback on the clarity and feasibility of the specification, and he also provided the state machine description and the initial error catalogue and formats. Magnus Westerlund carried out a detailed AD review that identified a number of issues and led to significant clarifications, which was followed by an even more detailed IESG review, with comments from Jari Arkko, Ross Callon, Brian Carpenter, Lisa Dusseault, Lars Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen Jennings, and Tim Polk, and a very detailed analysis by Adrian Farrel from the Routing Area directorate; Suresh Krishnan carried out a detailed review for the Gen-ART.
このドキュメントは、IETF NSISワーキンググループ内の議論に基づいています。これは、以前の仕事と、セドリック・アウン、アッティラ・バダー、ヴィトル・ベルナド、ローランド・ブレイデン、ボブ・ブレーデン、マーカス・ブルナー、ブノワ・カンペデル、ヨシコ・チョン、ルイス・コルデイロ、エルウィン・デイヴィス、マイケル・ディアス、クリスチャン・ディクマン、Pasi Eronen、Alan Ford、Xiaoming Fu、Bo Gao、Ruediger Geib、Eleanor Hepworth、Thomas Herzog、Cheng Hong、Teemu Huovila、Jia Jia、Cornelia Kappler、Georgios Karagiannis、Ruud Klaver、Max Laier、Max Laier、アリソン・マンキン、ジュッカ・マナー、ピート・マッキャン、アンドリュー・マクドナルド、Mac McTiffin、グレン・モロー、デイブ・オラン、アンドレアス・パシャリディス、ヘニング・ピーターズ、トム・フェラン、アクバル・ラーマン、タカコ・サンダ、チャールズ・シェン、メリンダ・ショア、マルティン・スティミーリング、マルティン・スワニンク、トーマス、ハンヌ・ツェコフェニグ、スヴェン・ヴァン・デン・ボッシュ、ヌッティ・バリス、マイケル・ウェルツル、ラース・ウェストバーグ、マイ・ズマロ・ダジョーン。TLS使用法の説明（セクション5.7.3）の一部は、直径ベースプロトコル仕様、RFC 3588から導き出されました。さらに、Hannes Tschofenigはセキュリティセクションに関する詳細なレビューコメントを提供し、Andrew McDonaldは正式な説明を提供しました。初期パケットフォーマットとTLSの名前マッチングアルゴリズム。Chris Langの実装作業は、仕様の明確さと実現可能性に関する客観的なフィードバックを提供し、State Machineの説明と初期エラーカタログとフォーマットも提供しました。マグナス・ウェスターランドは、多くの問題を特定し、重要な説明につながった詳細な広告レビューを実施しました。その後、さらに詳細なIESGレビューが続き、Jari Arkko、Ross Callon、Brian Carpenter、Lisa Dusseault、Lars Eggert、TedHardie、Sam Hartman、Russ Housley、Cullen Jennings、ティムポーク、およびルーティングエリア局のエイドリアンファレルによる非常に詳細な分析。Suresh Krishnanは、Gen-Artの詳細なレビューを実施しました。
[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[1] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[4] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[6] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[6] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[7] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[7] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[8] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[8] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC5280、2008年5月。
[9] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[9] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
[10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[10] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[11] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[12] Mather、J.、Bless、R.、Loughney、J。、およびE. Davies、「NSISプロトコルファミリーの使用と拡張」、RFC 5978、2010年10月。
[13] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[13] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[14] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[14] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[16] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[16] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[17] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[17] Partridge、C。and A. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[18] Terzis、A.、Krawczyk、J.、Wroclawski、J。、およびL. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[19] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[19] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[20] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[20] Huitema、C。、「6to4リレールーターのAnycast Prefix」、RFC 3068、2001年6月。
[21] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[21] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「IPv4およびIPv6予約のRSVPの集約」、RFC 3175、2001年9月。
[22] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[22] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[23] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[23] Jamoussi、B.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[24] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[24] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[25] Arkko、J.、Torvinen、V.、Camarillo、G.、Niemi、A。、およびT. Haukka、「セッション開始プロトコル（SIP）のセキュリティメカニズム契約」、RFC 3329、2003年1月。
[26] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[26] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Nat（Stun）のセッショントラバーサルユーティリティ」、RFC 5389、2008年10月。
[27] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[27] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATの周りのリレーを使用したトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、RFC 5766、2010年4月。
[28] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[28] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[29] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[29] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「Signalingの次のステップ（NSIS）：フレームワーク」、RFC 4080、2005年6月。
[30] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[30] Tschofenig、H。およびD. Kroeselberg、「シグナル伝達の次のステップに対するセキュリティの脅威（NSIS）」、RFC 4081、2005年6月。
[31] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[31] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[32] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[32] Eronen、P。and H. Tschofenig、「輸送層セキュリティのための事前共有キーヒルスーツ（TLS）」、RFC 4279、2005年12月。
[33] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[33] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 4443、2006年3月。
[34] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, April 2010.
[34] Stiemerling、M.、Tschofenig、H.、Aoun、C。、およびE. Davies、「Nat/ Firewall NSIS Signaling Layer Protocol（NSLP）」、2010年4月の作業。
[35] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[35] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[36] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[36] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[37] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[37] Nikander、P.、Arkko、J.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザインの背景」、RFC 4225、2005年12月。
[38] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[38] Audet、F。およびC. Jennings、「ユニキャストUDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[39] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[39] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[40] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[40] Aoun、C。およびE. Davies、「ネットワークアドレス翻訳者を移動する理由 - プロトコル翻訳者（NAT -PT）は歴史的ステータスに」、RFC 4966、2007年7月。
[41] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[41] Gill、V.、Heasley、J.、Meyer、D.、Savola、P。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、2007年10月。
[42] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic Routing Messages", SIGCOMM Symposium on Communications Architectures and Protocols pp. 33--44, September 1993.
[42] Floyd、S。and V. Jacobson、「定期的なルーティングメッセージの同期」、Communications Architectures and Protocolspp。33--44、1993年9月のSigcommシンポジウム。
[43] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", Work in Progress, July 2007.
[43] Pashalidis、A。およびH. Tschofenig、「Gist Legacy Nat Traversal」、2007年7月の作業。
[44] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", Work in Progress, July 2007.
[44] Pashalidis、A。およびH. Tschofenig、「Gist Nat Traversal」、2007年7月、進行中の作業。
[45] Tsenov, T., Tschofenig, H., Fu, X., Aoun, C., and E. Davies, "GIST State Machine", Work in Progress, April 2010.
[45] Tsenov、T.、Tschofenig、H.、Fu、X.、Aoun、C。、およびE. Davies、「Gist State Machine」、2010年4月の作業。
[46] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, May 2010.
[46] Ramaiah、A.、Stewart、R。、およびM. Dalal、「Window In-Window攻撃に対するTCPの堅牢性の向上」、2010年5月の進行中。
This appendix provides formats for the various component parts of the GIST messages defined abstractly in Section 5.2. The whole of this appendix is normative.
この付録は、セクション5.2で抽象的に定義されたGISTメッセージのさまざまなコンポーネント部分のフォーマットを提供します。この付録の全体は規範的です。
Each GIST message consists of a header and a sequence of objects. The GIST header has a specific format, described in more detail in Appendix A.1 below. An NSLP message is one object within a GIST message. Note that GIST itself provides the NSLP message length information and signalling application identification. General object formatting guidelines are provided in Appendix A.2 below, followed in Appendix A.3 by the format for each object. Finally, Appendix A.4 provides the formats used for error reporting.
各要点メッセージは、ヘッダーと一連のオブジェクトで構成されています。GISTヘッダーには、以下の付録A.1で詳細に説明されている特定の形式があります。NSLPメッセージは、GISTメッセージ内の1つのオブジェクトです。GIST自体がNSLPメッセージの長さ情報とシグナリングアプリケーションの識別を提供することに注意してください。一般的なオブジェクトのフォーマットガイドラインは、以下の付録A.2に記載されています。付録A.3には、各オブジェクトの形式が続きます。最後に、付録A.4は、エラーレポートに使用される形式を提供します。
In the following object diagrams, '//' is used to indicate a variable-sized field and ':' is used to indicate a field that is optionally present. Any part of the object used for padding or defined as reserved (marked 'Reserved' or 'Rsv' or, in the case of individual bits, 'r' in the diagrams below) MUST be set to 0 on transmission and MUST be ignored on reception.
次のオブジェクト図では、「//」は可変サイズのフィールドを示すために使用され、 '：'は、オプションで存在するフィールドを示すために使用されます。パディングに使用される、または予約されたものとして定義されているオブジェクトの一部（「予約済み」または「RSV」とマークされている、または個々のビットの場合、下の図の「R」は送信時に0に設定する必要があり、で無視する必要があります。受信。
The objects are encoded using big endian (network byte order).
オブジェクトは、Big Endian（ネットワークバイトの順序）を使用してエンコードされます。
This header begins all GIST messages. It has a fixed format, as shown below.
このヘッダーは、すべてのGISTメッセージを開始します。以下に示すように、固定形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | GIST hops | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLPID |C| Type |S|R|E| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (8 bits): The GIST protocol version number. This specification defines version number 1.
バージョン（8ビット）：GISTプロトコルバージョン番号。この仕様はバージョン番号1を定義します。
GIST hops (8 bits): A hop count for the number of GIST-aware nodes this message can still be processed by (including the destination).
GIST HOPS（8ビット）：GIST認識ノードの数のホップカウントこのメッセージは引き続き（宛先を含む）によって処理できます。
Message Length (16 bits): The total number of 32-bit words in the message after the common header itself.
メッセージの長さ（16ビット）：共通ヘッダー自体の後のメッセージ内の32ビット語の合計数。
NSLPID (16 bits): IANA-assigned identifier of the signalling application to which the message refers.
NSLPID（16ビット）：メッセージが参照するシグナリングアプリケーションのIANAによって割り当てられた識別子。
C-flag: C=1 if the message has to be able to be interpreted in the absence of routing state (Section 5.2.1).
c-flag：c = 1ルーティング状態がない場合にメッセージを解釈できる必要がある場合（セクション5.2.1）。
Type (7 bits): The GIST message type (Query, Response, etc.).
タイプ（7ビット）：GISTメッセージタイプ（クエリ、応答など）。
S-flag: S=1 if the IP source address is the same as the signalling source address, S=0 if it is different.
s-flag：s = 1 IPソースアドレスが信号ソースアドレスと同じ場合、s = 0が異なる場合はs = 0。
R-flag: R=1 if a reply to this message is explicitly requested.
r-flag：r = 1このメッセージへの返信が明示的に要求されている場合。
E-flag: E=1 if the message was explicitly routed (Section 7.1.5).
e-flag：e = 1メッセージが明示的にルーティングされた場合（セクション7.1.5）。
The rules governing the use of the R-flag depend on the GIST message type. It MUST always be set (R=1) in Query messages, since these always elicit a Response, and never in Confirm, Data, or Error messages. It MAY be set in an MA-Hello; if set, another MA-Hello MUST be sent in reply. It MAY be set in a Response, but MUST be set if the Response contains a Responder-Cookie; if set, a Confirm MUST be sent in reply. The E-flag MUST NOT be set unless the message type is a Data message.
R-Flagの使用を管理するルールは、GISTメッセージタイプによって異なります。これらは常に応答を引き出し、確認、データ、またはエラーメッセージでは決して誘導しないため、クエリメッセージで常に（r = 1）設定する必要があります。Ma-helloで設定される場合があります。設定した場合、別のMA-Helloを返信して送信する必要があります。応答で設定される場合がありますが、応答にレスポンダークッキーが含まれている場合は設定する必要があります。設定した場合、確認を返信して送信する必要があります。メッセージタイプがデータメッセージでない限り、e-flagを設定しないでください。
Parsing failures may be caused by unknown Version or Type values; inconsistent setting of the C-flag, R-flag, or E-flag; or a Message Length inconsistent with the set of objects carried. In all cases, the receiver MUST if possible return a "Common Header Parse Error" message (Appendix A.4.4.1) with the appropriate subcode, and not process the message further.
解析障害は、不明なバージョンまたはタイプの値によって引き起こされる場合があります。C-Flag、R-Flag、またはE-Flagの一貫性のない設定。または、伝達されたオブジェクトのセットと矛盾するメッセージの長さ。すべての場合において、受信者は、可能であれば、適切なサブコードを使用して「共通ヘッダー解析エラー」メッセージ（付録A.4.4.1）を返す必要があり、メッセージをさらに処理することはできません。
Each object begins with a fixed header giving the object Type and object Length. This is followed by the object Value, which is a whole number of 32-bit words long.
各オブジェクトは、オブジェクトタイプとオブジェクトの長さを与える固定ヘッダーから始まります。これに続いて、オブジェクト値が続きます。これは、32ビットの長さの全部です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A/B flags: The bits marked 'A' and 'B' are extensibility flags, which are defined in Appendix A.2.1 below; the remaining bits marked 'r' are reserved.
A/Bフラグ：「A」と「B」とマークされたビットは、以下の付録A.2.1で定義されている拡張性フラグです。「R」とマークされた残りのビットは予約されています。
Type (12 bits): An IANA-assigned identifier for the type of object.
タイプ（12ビット）：オブジェクトのタイプのIANAが割り当てられた識別子。
Length (12 bits): Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. If the Length is not consistent with the contents of the object, an "Object Value Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect Length" MUST be returned and the message dropped.
長さ（12ビット）：長さには32ビット単語の単位があり、値の長さを測定します。値がない場合、長さ= 0。長さがオブジェクトの内容と一致していない場合、サブコード0「正しくない長さ」を備えた「オブジェクト値エラー」メッセージ（付録A.4.4.10）を返す必要があり、メッセージがドロップされます。
Value (variable): Value is (therefore) a whole number of 32-bit words. If there is any padding required, the length and location are be defined by the object-specific format information; objects that contain variable-length (e.g., string) types may need to include additional length subfields to do so.
値（変数）：値は、（したがって）32ビットの単語の全部です。パディングが必要な場合、長さと場所はオブジェクト固有の形式情報によって定義されます。可変長（たとえば、文字列）タイプを含むオブジェクトは、追加するために追加の長さサブフィールドを含める必要がある場合があります。
The leading 2 bits of the TLV header are used to signal the desired treatment for objects whose Type field is unknown at the receiver. The following three categories of objects have been identified and are described here.
TLVヘッダーの主要な2ビットを使用して、受信機でタイプフィールドが不明なオブジェクトの目的の処理を信号します。次の3つのカテゴリのオブジェクトが特定されており、ここで説明されています。
AB=00 ("Mandatory"): If the object is not understood, the entire message containing it MUST be rejected with an "Object Type Error" message (Appendix A.4.4.9) with subcode 1 ("Unrecognised Object").
ab = 00（ "必須"）：オブジェクトが理解されていない場合、それを含むメッセージ全体を「オブジェクトタイプエラー」メッセージ（付録A.4.4.9）で拒否する必要があります（「認識されていないオブジェクト」）。
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted and the rest of the message processed as usual.
ab = 01（ "Ingrore"）：オブジェクトが理解されていない場合は、削除し、メッセージの残りを通常どおり処理する必要があります。
AB=10 ("Forward"): If the object is not understood, it MUST be retained unchanged in any message forwarded as a result of message processing, but not stored locally.
AB = 10（ "Forward"）：オブジェクトが理解されていない場合、メッセージ処理の結果として転送されたメッセージで変更されずに保持する必要がありますが、ローカルに保存されません。
The combination AB=11 is reserved. If a message is received containing an object with AB=11, it MUST be rejected with an "Object Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid Extensibility Flags").
組み合わせAB = 11は予約されています。AB = 11のオブジェクトを含むメッセージを受信した場合、サブコード5（「無効な拡張性フラグ」）を備えた「オブジェクトタイプエラー」メッセージ（付録A.4.4.9）で拒否する必要があります。
These extensibility rules define only the processing within the GIST layer. There is no requirement on GIST implementations to support an extensible service interface to signalling applications, so unrecognised objects with AB=01 or AB=10 do not need to be indicated to NSLPs.
これらの拡張性ルールは、GISTレイヤー内の処理のみを定義します。GIST実装には、シグナリングアプリケーションへの拡張可能なサービスインターフェイスをサポートするための要件はありません。そのため、AB = 01またはAB = 10の認識されていないオブジェクトは、NSLPに示す必要はありません。
Type: Message-Routing-Information
タイプ：メッセージルーティング情報
Length: Variable (depends on MRM)
長さ：変数（MRMに依存）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRM-ID |N| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRM-ID (8 bits): An IANA-assigned identifier for the message routing method.
MRM-ID（8ビット）：メッセージルーティング方法のIANAが割り当てられた識別子。
N-flag: If set (N=1), this means that NATs do not need to translate this MRM; if clear (N=0), it means that the method-specific information contains network or transport layer information that a NAT must process.
n-flag：set（n = 1）の場合、これはNATがこのMRMを翻訳する必要がないことを意味します。クリア（n = 0）の場合、メソッド固有の情報には、NATが処理する必要があるネットワークまたは輸送層情報が含まれていることを意味します。
The remainder of the object contains method-specific addressing information, which is described below.
オブジェクトの残りの部分には、以下で説明するメソッド固有のアドレス指定情報が含まれています。
In the case of basic path-coupled routing, the addressing information takes the following format. The N-flag has a value of 0 for this MRM.
基本的なパス結合ルーティングの場合、アドレス指定情報は次の形式を取得します。N-Flagの値は、このMRMに対して0の値です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |P|T|F|S|A|B|D|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix | Dest Prefix | Protocol | DS-field |Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reserved | Flow Label :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Source Port : Destination Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Ver (4 bits): The IP version number, 4 or 6.
IP-ver（4ビット）：IPバージョン番号、4または6。
Source/Destination address (variable): The source and destination addresses are always present and of the same type; their length depends on the value in the IP-Ver field.
ソース/宛先アドレス（変数）：ソースおよび宛先アドレスは常に存在し、同じタイプです。それらの長さは、IP-verフィールドの値に依存します。
Source/Dest Prefix (each 8 bits): The length of the mask to be applied to the source and destination addresses for address wildcarding. In the normal case where the MRI refers only to traffic between specific host addresses, the Source/Dest Prefix values would both be 32 or 128 for IPv4 and IPv6, respectively.
ソース/DESTプレフィックス（各8ビット）：ワイルドカードのアドレスのためにソースおよび宛先アドレスに適用されるマスクの長さ。MRIが特定のホストアドレス間のトラフィックのみを指す通常の場合、Source/Destプレフィックス値は、IPv4とIPv6でそれぞれ32または128になります。
P-flag: P=1 means that the Protocol field is significant.
p-flag：p = 1は、プロトコルフィールドが重要であることを意味します。
Protocol (8 bits): The IP protocol number. This MUST be ignored if P=0. In the case of IPv6, the Protocol field refers to the true upper layer protocol carried by the packets, i.e., excluding any IP option headers. This is therefore not necessarily the same as the Next Header value from the base IPv6 header.
プロトコル（8ビット）：IPプロトコル番号。p = 0の場合、これは無視する必要があります。IPv6の場合、プロトコルフィールドは、パケットによって運ばれる真の上層プロトコル、つまりIPオプションヘッダーを除外することを指します。したがって、これは、ベースIPv6ヘッダーの次のヘッダー値と必ずしも同じではありません。
T-flag: T=1 means that the Diffserv field (DS-field) is significant.
T-FLAG：T = 1は、DiffServフィールド（DS-Field）が重要であることを意味します。
DS-field (6 bits): The Diffserv field. See [6] and [24].
DS-Field（6ビット）：DiffServフィールド。[6]および[24]を参照してください。
F-flag: F=1 means that flow label is present and is significant. F MUST NOT be set if IP-Ver is not 6.
f-flag：f = 1は、フローラベルが存在し、重要であることを意味します。IP-verが6でない場合は、Fを設定しないでください。
Flow Label (20 bits): The flow label; only present if F=1. If F=0, the entire 32-bit word containing the Flow Label is absent.
フローラベル（20ビット）：フローラベル。f = 1の場合にのみ存在します。f = 0の場合、フローラベルを含む32ビット単語全体が存在しません。
S-flag: S=1 means that the SPI field is present and is significant. The S-flag MUST be 0 if the P-flag is 0.
S-Flag：S = 1は、SPIフィールドが存在し、重要であることを意味します。p-flagが0の場合、s-flagは0でなければなりません。
SPI field (32 bits): The SPI field; see [36]. If S=0, the entire 32-bit word containing the SPI is absent.
SPIフィールド（32ビット）：SPIフィールド。[36]を参照してください。S = 0の場合、SPIを含む32ビット単語全体が存在しません。
A/B flags: These can only be set if P=1. If either is set, the port fields are also present. The A flag indicates the presence of a source port, the B flag that of a destination port. If P=0, the A/B flags MUST both be zero and the word containing the port numbers is absent.
A/Bフラグ：これらは、p = 1の場合にのみ設定できます。どちらかが設定されている場合、ポートフィールドも存在します。Aフラグは、ソースポートの存在、Bフラグの存在を示しています。p = 0の場合、A/Bフラグは両方ともゼロでなければならず、ポート番号を含む単語は存在しません。
Source/Destination Port (each 16 bits): If either of A (source), B (destination) is set, the word containing the port numbers is included in the object. However, the contents of each field is only significant if the corresponding flag is set; otherwise, the contents of the field is regarded as padding, and the MRI refers to all ports (i.e., acts as a wildcard). If the flag is set and Port=0x0000, the MRI will apply to a specific port, whose value is not yet known. If neither of A or B is set, the word is absent.
ソース/宛先ポート（それぞれ16ビット）：a（source）、b（宛先）のいずれかが設定されている場合、ポート番号を含む単語がオブジェクトに含まれています。ただし、各フィールドの内容は、対応するフラグが設定されている場合にのみ重要です。それ以外の場合、フィールドの内容はパディングと見なされ、MRIはすべてのポートを指します（つまり、ワイルドカードとして機能します）。フラグが設定され、ポート= 0x0000の場合、MRIは特定のポートに適用されますが、その値はまだわかっていません。AまたはBのいずれも設定されていない場合、単語はありません。
D-flag: The Direction flag has the following meaning: the value 0 means 'in the same direction as the flow' (i.e., downstream), and the value 1 means 'in the opposite direction to the flow' (i.e., upstream).
d-flag：方向フラグには次の意味があります。値0は「フローと同じ方向に」（すなわち、下流）を意味し、値1は「フローとは反対方向」（つまり、上流）を意味します。。
The MRI format defines a number of constraints on the allowed combinations of flags and fields in the object. If these constraints are violated, this constitutes a parse error, and an "Object Value Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag-Field Combination") MUST be returned.
MRI形式は、オブジェクト内のフラグとフィールドの許可された組み合わせに関する多くの制約を定義します。これらの制約が違反されている場合、これは解析エラーを構成し、サブコード2（「無効なフラグフィールドの組み合わせ」）を備えた「オブジェクト値エラー」メッセージ（付録A.4.4.10）を返す必要があります。
In the case of the loose-end MRM, the addressing information takes the following format. The N-flag has a value of 0 for this MRM.
ルーズエンドMRMの場合、アドレス指定情報は次の形式を取得します。N-Flagの値は、このMRMに対して0の値です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Ver (4 bits): The IP version number, 4 or 6.
Source/Destination address (variable): The source and destination addresses are always present and of the same type; their length depends on the value in the IP-Ver field.
ソース/宛先アドレス（変数）：ソースおよび宛先アドレスは常に存在し、同じタイプです。それらの長さは、IP-verフィールドの値に依存します。
D-flag: The Direction flag has the following meaning: the value 0 means 'towards the edge of the network', and the value 1 means 'from the edge of the network'. Note that for Q-mode messages, the only valid value is D=0 (see Section 5.8.2).
D-Flag：方向フラグには次の意味があります。値0は「ネットワークの端に向かって」を意味し、値1は「ネットワークの端から」を意味します。Qモードメッセージの場合、唯一の有効な値はd = 0です（セクション5.8.2を参照）。
Type: Session-Identifier
タイプ：セッションIDENTIFIER
Length: Fixed (4 32-bit words)
長さ：固定（4 32ビット語）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Network-Layer-Information
タイプ：ネットワーク層情報
Length: Variable (depends on length of Peer-Identity and IP version)
長さ：変数（ピアアイデンティティとIPバージョンの長さに依存します）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PI-Length | IP-TTL |IP-Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing State Validity Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Identity //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PI-Length (8 bits): The byte length of the Peer Identity field.
Peer Identity (variable): The Peer Identity field. Note that the Peer-Identity field itself is padded to a whole number of words.
ピアアイデンティティ（変数）：ピアアイデンティティフィールド。ピアアイデンティティフィールド自体は、すべての単語にパッドで埋められていることに注意してください。
IP-TTL (8 bits): Initial or reported IP layer TTL.
IP-TTL（8ビット）：初期または報告されたIPレイヤーTTL。
IP-Ver (4 bits): The IP version for the Interface Address field.
IP-ver（4ビット）：インターフェイスアドレスフィールドのIPバージョン。
Interface Address (variable): The IP address allocated to the interface, matching the IP-Ver field.
インターフェイスアドレス（変数）：IP-verフィールドに一致するインターフェイスに割り当てられたIPアドレス。
Routing State Validity Time (32 bits): The time for which the routing state for this flow can be considered correct without a refresh. Given in milliseconds. The value 0 (zero) is reserved and MUST NOT be used.
ルーティング状態の妥当性時間（32ビット）：このフローのルーティング状態がリフレッシュせずに正しいと見なすことができる時間。ミリ秒で与えられます。値0（ゼロ）は予約されており、使用してはなりません。
Type: Stack-Proposal
タイプ：スタックプロポザル
Length: Variable (depends on number of profiles and size of each profile)
長さ：変数（各プロファイルのプロファイルの数とサイズに依存します）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prof-Count (8 bits): The number of profiles listed. MUST be > 0.
Prof-Count（8ビット）：リストされているプロファイルの数。> 0でなければなりません。
Each profile is itself a sequence of protocol layers, and the profile is formatted as a list as follows:
各プロファイル自体はプロトコルレイヤーのシーケンスであり、プロファイルは次のようにリストとしてフォーマットされます。
o The first byte is a count of the number of layers in the profile. MUST be > 0.
o 最初のバイトは、プロファイル内のレイヤー数のカウントです。> 0でなければなりません。
o This is followed by a sequence of 1-byte MA-Protocol-IDs as described in Section 5.7.
o これに続いて、セクション5.7で説明されているように、1バイトのMA-Protocol-IDのシーケンスが続きます。
o The profile is padded to a word boundary with 0, 1, 2, or 3 zero bytes. These bytes MUST be ignored at the receiver.
o プロファイルは、0、1、2、または3ゼロバイトの単語境界にパッドで埋められています。これらのバイトは、受信機で無視する必要があります。
If there are no profiles (Prof-Count=0), then an "Object Value Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be returned; if a particular profile is empty (the leading byte of the profile is zero), then subcode 3 ("Empty List") MUST be used. In both cases, the message MUST be dropped.
プロファイル（Prof-Count = 0）がない場合、サブコード1（「値はサポートされていない」）を備えた「オブジェクト値エラー」メッセージ（付録A.4.4.10）を返す必要があります。特定のプロファイルが空の場合（プロファイルの主要なバイトがゼロ）、サブコード3（「空のリスト」）を使用する必要があります。どちらの場合も、メッセージを削除する必要があります。
Type: Stack-Configuration-Data
タイプ：Stack-configuration-data
Length: Variable (depends on number of protocols and size of each MA-protocol-options field)
長さ：変数（プロトコルの数と各MAプロトコルオプションフィールドのサイズに依存します）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPO-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MA-Hold-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MA-protocol-options 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MA-protocol-options N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MPO-Count (8 bits): The number of MA-protocol-options fields present (these contain their own length information). The MPO-Count MAY be zero, but this will only be the case if none of the MA-protocols referred to in the Stack-Proposal require option data.
MPO-Count（8ビット）：存在するMA-Protocol-Optionsフィールドの数（これらには独自の長さ情報が含まれています）。MPOカウントはゼロかもしれませんが、これは、スタックプロポザルで言及されているMAプロトコルがオプションデータを必要としない場合にのみ当てはまります。
MA-Hold-Time (32 bits): The time for which the messaging association will be held open without traffic or a hello message. Note that this value is given in milliseconds, so the default time of 30 seconds (Section 4.4.5) corresponds to a value of 30000. The value 0 (zero) is reserved and MUST NOT be used.
Ma-Hold-Time（32ビット）：メッセージングアソシエーションがトラフィックやハローメッセージなしで開かれる時間。この値はミリ秒単位で与えられているため、デフォルト時間（セクション4.4.5）のデフォルト時間は30000の値に対応していることに注意してください。値0（ゼロ）は予約されており、使用してはなりません。
The MA-protocol-options fields are formatted as follows:
MA-Protocol-Optionsフィールドは、次のようにフォーマットされています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MA-Protocol-ID | Profile | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MA-Protocol-ID (8 bits): Protocol identifier as described in Section 5.7.
MA-Protocol-ID（8ビット）：セクション5.7で説明されているプロトコル識別子。
Profile (8 bits): Tag indicating which profile from the accompanying Stack-Proposal object this applies to. Profiles are numbered from 1 upwards; the special value 0 indicates 'applies to all profiles'.
プロファイル（8ビット）：これが適用される添付のスタックプロポザルオブジェクトからのプロファイルを示すタグ。プロファイルには1から番号が付けられています。特別な値0は、「すべてのプロファイルに適用される」を示します。
Length (8 bits): The byte length of MA-protocol-options field that follows. This will be zero-padded up to the next word boundary.
長さ（8ビット）：続くMAプロトコルオプションフィールドのバイト長。これは、次の単語境界までゼロパッドになります。
D-flag: If set (D=1), this protocol MUST NOT be used for a messaging association.
d-flag：set（d = 1）の場合、このプロトコルはメッセージングアソシエーションに使用してはなりません。
Options Data (variable): Any options data for this protocol. Note that the format of the options data might differ depending on whether the field is in a Query or Response.
オプションデータ（変数）：このプロトコルのオプションデータ。オプションデータの形式は、フィールドがクエリまたは応答であるかどうかによって異なる場合があることに注意してください。
Type: Query-Cookie
タイプ：Query-Cookie
Length: Variable (selected by Querying node)
長さ：変数（ノードのクエリで選択）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Query-Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is defined by the implementation. See Section 8.5 for further discussion.
コンテンツは実装によって定義されます。詳細については、セクション8.5を参照してください。
Type: Responder-Cookie
タイプ：Responder-Cookie
Length: Variable (selected by Responding node)
長さ：変数（応答ノードによって選択）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Responder-Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is defined by the implementation. See Section 8.5 for further discussion.
コンテンツは実装によって定義されます。詳細については、セクション8.5を参照してください。
Type: Hello-ID
タイプ：hello-id
Length: Fixed (1 32-bit word)
長さ：固定（1 32ビットワード）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is defined by the implementation. See Section 5.2.2 for further discussion.
コンテンツは実装によって定義されます。詳細については、セクション5.2.2を参照してください。
Type: NAT-Traversal
タイプ：Nat-Traversal
Length: Variable (depends on length of contained fields)
長さ：変数（含まれるフィールドの長さに依存します）
This object is used to support the NAT traversal mechanisms described in Section 7.2.2.
このオブジェクトは、セクション7.2.2で説明されているNATトラバーサルメカニズムをサポートするために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRI-Length | Type-Count | NAT-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Original Message-Routing-Information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// List of translated objects //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque information | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// Information replaced by NAT #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of opaque information | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //
// Information replaced by NAT #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRI-Length (8 bits): The length of the included MRI payload in 32-bit words.
MRI-Length（8ビット）：32ビット単語の付属MRIペイロードの長さ。
Original Message-Routing-Information (variable): The MRI data from when the message was first sent, not including the object header.
元のメッセージルーティング情報（変数）：メッセージが最初に送信されたときのMRIデータ、オブジェクトヘッダーは含まれません。
Type-Count (8 bits): The number of objects in the 'List of translated objects' field.
Type-Count（8ビット）：「翻訳されたオブジェクトのリスト」フィールドのオブジェクトの数。
List of translated objects (variable): This field lists the types of objects that were translated by every NAT through which the message has passed. Each element in the list is a 16-bit field containing the first 16 bits of the object TLV header, including the AB extensibility flags, 2 reserved bits, and 12-bit object type. The list is initialised by the first NAT on the path; subsequent NATs may delete elements in the list. Padded with 2 null bytes if necessary.
翻訳されたオブジェクトのリスト（変数）：このフィールドには、メッセージが通過したすべてのNATによって翻訳されたオブジェクトのタイプがリストされています。リスト内の各要素は、AB拡張可能性フラグ、2つの予約ビット、12ビットオブジェクトタイプを含む、オブジェクトTLVヘッダーの最初の16ビットを含む16ビットフィールドです。リストは、パス上の最初のNATによって初期化されます。後続のNATは、リスト内の要素を削除する場合があります。必要に応じて、2つのヌルバイトがパッドに入っています。
NAT-Count (8 bits): The number of NATs traversed by the message, and the number of opaque payloads at the end of the object. The length fields for each opaque payload are byte counts, not including the 2 bytes of the length field itself. Note that each opaque information field is zero-padded to the next 32-bit word boundary if necessary.
NAT-Count（8ビット）：メッセージによって通過するNATの数と、オブジェクトの最後にある不透明なペイロードの数。不透明なペイロードごとの長さフィールドはバイトカウントであり、長さフィールド自体の2バイトは含まれません。必要に応じて、各不透明な情報フィールドは次の32ビットワードの境界にゼロパッドされていることに注意してください。
Type: NSLP-Data
タイプ：NSLP-DATA
Length: Variable (depends on NSLP)
長さ：変数（NSLPに依存）
This object is used to deliver data between NSLPs. GIST regards the data as a number of complete 32-bit words, as given by the length field in the TLV; any padding to a word boundary must be carried out within the NSLP itself.
このオブジェクトは、NSLP間でデータを配信するために使用されます。GISTは、TLVの長さフィールドで与えられるように、データを多くの完全な32ビット単語と見なしています。単語境界へのパディングは、NSLP自体内で実行する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NSLP Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Error
タイプ：エラー
Length: Variable (depends on error)
長さ：変数（エラーに依存）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Class | Error Code | Error Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M|C|D|Q| Reserved | MRI Length | Info Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Common Header +
| (of original message) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Session ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Routing Information :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Additional Information Fields :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Debugging Comment :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are:
S - S=1 means the Session ID object is present.
M - M=1 means MRI object is present.
C - C=1 means a debug Comment is present after header.
D - D=1 means the original message was received in D-mode.
Q - Q=1 means the original message was received Q-mode encapsulated
(can't be set if D=0).
A GIST Error Object contains an 8-bit error-class (see Appendix A.4.3), a 16-bit error-code, an 8-bit error-subcode, and as much information about the message that triggered the error as is available. This information MUST include the common header of the original message and MUST also include the Session ID and MRI objects if these could be decoded correctly. These objects are included in their entirety, except for their TLV Headers. The MRI Length field gives the length of the MRI object in 32-bit words.
GISTエラーオブジェクトには、8ビットエラークラス（付録A.4.3を参照）、16ビットエラーコード、8ビットエラーサブコード、および使用可能なエラーをトリガーしたメッセージに関する多くの情報が含まれています。この情報には、元のメッセージの共通ヘッダーを含める必要があり、これらを正しくデコードできる場合は、セッションIDとMRIオブジェクトも含める必要があります。これらのオブジェクトは、TLVヘッダーを除き、全体に含まれています。MRIの長さフィールドは、32ビット単語でMRIオブジェクトの長さを示します。
The Info Count field contains the number of Additional Information fields in the object, and the possible formats for these fields are given in Appendix A.4.2. The precise set of fields to include depends on the error code/subcode. For every error description in the error catalogue Appendix A.4.4, the line "Additional Info:" states what fields MUST be included; further fields beyond these MAY be included by the sender, and the fields may be included in any order. The Debugging Comment is a null-terminated UTF-8 string, padded if necessary to a whole number of 32-bit words with more null characters.
情報カウントフィールドには、オブジェクト内の追加情報フィールドの数が含まれており、これらのフィールドの可能な形式は付録A.4.2に記載されています。含まれるフィールドの正確なセットは、エラーコード/サブコードに依存します。エラーカタログのすべてのエラー説明について、付録A.4.4、「追加情報：」という行は、どのフィールドを含める必要があるかを記載しています。これらを超えるさらなるフィールドは送信者によって含まれる場合があり、フィールドは任意の順序で含まれる場合があります。デバッグコメントは、必要に応じてnull文字を備えた32ビット単語の全部にパッドで締め込まれたヌル終端のUTF-8文字列です。
The Common Error Header may be followed by some Additional Information fields. Each Additional Information field has a simple TLV format as follows:
一般的なエラーヘッダーの後に、いくつかの追加情報フィールドが続く場合があります。各追加情報フィールドには、次のように単純なTLV形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AI-Type | AI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// AI-Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AI-Type is a 16-bit IANA-assigned value. The AI-Length gives the number of 32-bit words in AI-Value; if an AI-Value is not present, AI-Length=0. The AI-Types and AI-Lengths and AI-Value formats of the currently defined Additional Information fields are shown below.
AIタイプは、16ビットIANAが割り当てられた値です。ai-lengthは、A-valueで32ビット単語の数を示します。AI値が存在しない場合、AI-Length = 0。現在定義されている追加情報フィールドのAIタイプとAIの長さおよびAI価値形式を以下に示します。
Message Length Info:
メッセージの長さ情報：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calculated Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 1
AI-Length: 1
Calculated Length (16 bits): the length of the original message
calculated by adding up all the objects in the message. Measured in
32-bit words.
MTU Info:
MTU情報：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 2
AI-Length: 1
Link MTU (16 bits): the IP MTU for a link along which a message
could not be sent. Measured in bytes.
Object Type Info:
オブジェクトタイプ情報：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 3
AI-Length: 1
Object type (16 bits): This provides information about the type
of object that caused the error.
Object Value Info:
オブジェクト値情報：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AI-Type: 4
AI-Length: variable (depends on object length)
This object carries information about a TLV object that was found
to be invalid in the original message. An error message MAY contain
more than one Object Value Info object.
Real Object Length (12 bits): Since the length in the original TLV header may be inaccurate, this field provides the actual length of the object (including the TLV header) included in the error message. Measured in 32-bit words.
実際のオブジェクトの長さ（12ビット）：元のTLVヘッダーの長さは不正確である可能性があるため、このフィールドはエラーメッセージに含まれる実際のオブジェクトの長さ（TLVヘッダーを含む）を提供します。32ビット語で測定されます。
Offset (16 bits): The byte in the object at which the GIST node found the error. The first byte in the object has offset=0.
オフセット（16ビット）：GISTノードがエラーを見つけたオブジェクトのバイト。オブジェクトの最初のバイトにはオフセット= 0があります。
Object (variable): The invalid TLV object (including the TLV header).
オブジェクト（変数）：無効なTLVオブジェクト（TLVヘッダーを含む）。
The first byte of the Error Object, "Error Class", indicates the severity level. The currently defined severity levels are:
エラーオブジェクトの最初のバイト「エラークラス」は、重大度レベルを示します。現在定義されている重大度レベルは次のとおりです。
0 (Informational): reply data that should not be thought of as changing the condition of the protocol state machine.
0（情報）：プロトコル状態マシンの条件を変更すると考えられるべきではないデータに返信します。
1 (Success): reply data that indicates that the message being responded to has been processed successfully in some sense.
1（成功）：応答するメッセージが何らかの意味で正常に処理されたことを示すデータ。
2 (Protocol-Error): the message has been rejected because of a protocol error (e.g., an error in message format).
2（Protocol-Error）：プロトコルエラー（メッセージ形式のエラーなど）のためにメッセージが拒否されました。
3 (Transient-Failure): the message has been rejected because of a particular local node status that may be transient (i.e., it may be worthwhile to retry after some delay).
3（一時的なフェイル）：メッセージは、一時的な特定のローカルノードステータスのために拒否されました（つまり、ある程度の遅延後に再試行する価値があるかもしれません）。
4 (Permanent-Failure): the message has been rejected because of local node status that will not change without additional out-of-band (e.g., management) operations.
4（永続的なフェイル）：追加の帯域外（管理）操作なしでは変更されないローカルノードステータスのため、メッセージは拒否されました。
Additional error class values are reserved.
追加のエラークラス値は予約されています。
The allocation of error classes to particular errors is not precise; the above descriptions are deliberately informal. Actual error processing SHOULD take into account the specific error in question; the error class may be useful supporting information (e.g., in network debugging).
特定のエラーへのエラークラスの割り当ては正確ではありません。上記の説明は意図的に非公式です。実際のエラー処理は、問題の特定のエラーを考慮に入れる必要があります。エラークラスは、情報をサポートするのに役立つ可能性があります（たとえば、ネットワークデバッグ）。
This section lists all the possible GIST errors, including when they are raised and what Additional Information fields MUST be carried in the Error Object.
このセクションには、それらが提起された時期やエラーオブジェクトにどのような追加情報フィールドを運ぶ必要があるかなど、考えられるすべての要点エラーがリストされています。
Class: Protocol-Error Code: 1 Additional Info: For subcode 3 only, Message Length Info carries the calculated message length.
クラス：プロトコルエラーコード：1追加情報：サブコード3のみの場合、メッセージの長さ情報には計算されたメッセージの長さが含まれます。
This message is sent if a GIST node receives a message where the common header cannot be parsed correctly, or where an error in the overall message format is detected. Note that in this case the original MRI and Session ID MUST NOT be included in the Error Object. This error code is split into subcodes as follows:
このメッセージは、GISTノードが共通ヘッダーを正しく解析できないメッセージを受信した場合、またはメッセージ全体のエラーが検出されるメッセージを受信した場合に送信されます。この場合、元のMRIおよびセッションIDをエラーオブジェクトに含めてはなりません。このエラーコードは、次のようにサブコードに分割されます。
0: Unknown Version: The GIST version is unknown. The (highest) supported version supported by the node can be inferred from the common header of the Error message itself.
0：不明バージョン：GISTバージョンは不明です。ノードでサポートされている（最高の）サポートされているバージョンは、エラーメッセージ自体の共通ヘッダーから推測できます。
1: Unknown Type: The GIST message type is unknown.
1：不明なタイプ：GISTメッセージタイプは不明です。
2: Invalid R-flag: The R-flag in the header is inconsistent with the message type.
2：無効なr-flag：ヘッダーのr-flagはメッセージタイプと矛盾しています。
3: Incorrect Message Length: The overall message length is not consistent with the set of objects carried.
3：誤ったメッセージの長さ：全体的なメッセージの長さは、運ばれるオブジェクトのセットと一致していません。
4: Invalid E-flag: The E-flag is set in the header, but this is not a Data message.
4：無効なe-flag：e-flagはヘッダーに設定されていますが、これはデータメッセージではありません。
5: Invalid C-flag: The C-flag was set on something other than a Query message or Q-mode Data message, or was clear on a Query message.
5：無効なC-Flag：C-Flagは、クエリメッセージまたはQモードデータメッセージ以外のものに設定されているか、クエリメッセージで明確でした。
Class: Permanent-Failure Code: 2 Additional Info: None
クラス：永続的なフェイルコード：2追加情報：なし
This message is sent if a GIST node receives a message with a GIST hop count of zero, or a GIST node tries to forward a message after its GIST hop count has been decremented to zero on reception. This message indicates either a routing loop or too small an initial hop count value.
このメッセージは、GISTノードがゼロのGISTホップカウントでメッセージを受信した場合に送信されます。または、GISTノードが、GISTホップカウントがレセプションでゼロに減少した後にメッセージを転送しようとします。このメッセージは、ルーティングループまたは初期ホップカウント値が小さすぎることを示しています。
Class: Protocol-Error Code: 3 Additional Info: None
クラス：プロトコルエラーコード：3追加情報：なし
This message is sent if a GIST node receives a message that uses an incorrect encapsulation method (e.g., a Query arrives over an MA, or the Confirm for a handshake that sets up a messaging association arrives in D-mode).
このメッセージは、GISTノードが誤ったカプセル化方法を使用するメッセージを受信した場合に送信されます（たとえば、MA上にクエリが到着し、メッセージングアソシエーションを設定するハンドシェイクの確認がDモードに到着します）。
Class: Protocol-Error Code: 4 Additional Info: None
クラス：プロトコルエラーコード：4追加情報：なし
This message is sent if a GIST node receives a message over an MA that is not associated with the MRI/NSLPID/SID combination in the message.
このメッセージは、GISTノードがメッセージ内のMRI/NSLPID/SIDの組み合わせに関連付けられていないMAを介してメッセージを受信した場合に送信されます。
Class: Protocol-Error Code: 5 Additional Info: None
クラス：プロトコルエラーコード：5追加情報：なし
This message is sent if a node receives a message for which routing state should exist, but has not yet been created and thus there is no appropriate Querying-SM or Responding-SM. This can occur on receiving a Data or Confirm message at a node whose policy requires routing state to exist before such messages can be accepted. See also Section 6.1 and Section 6.3.
このメッセージは、ノードがルーティング状態が存在するはずのメッセージを受信しているが、まだ作成されていないため、適切なクエリSMまたは応答SMがない場合に送信されます。これは、そのようなメッセージを受け入れる前にルーティング状態を存在させる必要があるノードでデータを受信したり、メッセージを確認することで発生する可能性があります。セクション6.1およびセクション6.3も参照してください。
Class: Permanent-Failure Code: 6 Additional Info: None
クラス：永続的なフェイルコード：6追加情報：なし
This message is sent if a router receives a directly addressed message for an NSLP that it does not support.
このメッセージは、ルーターがサポートしていないNSLPに対して直接アドレス指定されたメッセージを受信した場合に送信されます。
Class: Permanent-Failure Code: 7 Additional Info: None
クラス：永続的なフェイルコード：7追加情報：なし
This message is sent if a GIST node at a flow endpoint receives a Query message for an NSLP that it does not support.
このメッセージは、フローエンドポイントのGISTノードが、サポートしていないNSLPのクエリメッセージを受信した場合に送信されます。
Class: Permanent-Failure Code: 8 Additional Info: MTU Info
クラス：永続的なフェイルコード：8追加情報：MTU情報
This message is sent if a router receives a message that it can't forward because it exceeds the IP MTU on the next or subsequent hops.
このメッセージは、ルーターが次のホップまたは後続のホップでIP MTUを超えるため転送できないというメッセージを受信した場合に送信されます。
Class: Protocol-Error Code: 9 Additional Info: Object Type Info
クラス：プロトコルエラーコード：9追加情報：オブジェクトタイプ情報
This message is sent if a GIST node receives a message containing a TLV object with an invalid type. The message indicates the object type at fault in the additional info field. This error code is split into subcodes as follows:
このメッセージは、GISTノードが無効なタイプのTLVオブジェクトを含むメッセージを受信した場合に送信されます。メッセージは、追加情報フィールドの障害にあるオブジェクトタイプを示します。このエラーコードは、次のようにサブコードに分割されます。
0: Duplicate Object: This subcode is used if a GIST node receives a message containing multiple instances of an object that may only appear once in a message. In the current specification, this applies to all objects.
0：重複オブジェクト：このサブコードは、GISTノードがメッセージに1回しか表示されないオブジェクトの複数のインスタンスを含むメッセージを受信した場合に使用されます。現在の仕様では、これはすべてのオブジェクトに適用されます。
1: Unrecognised Object: This subcode is used if a GIST node receives a message containing an object that it does not support, and the extensibility flags AB=00.
1：認識されていないオブジェクト：このサブコードは、GISTノードがサポートしていないオブジェクトを含むメッセージを受信し、拡張フラグab = 00を受信した場合に使用されます。
2: Missing Object: This subcode is used if a GIST node receives a message that is missing one or more mandatory objects. This message is also sent if a Stack-Proposal is sent without a matching Stack-Configuration-Data object when one was necessary, or vice versa.
2：欠落オブジェクト：GISTノードが1つ以上の必須オブジェクトが欠落しているメッセージを受信した場合、このサブコードが使用されます。このメッセージは、必要なときに一致するスタックコンフィグラー-Dataオブジェクトなしでスタックプロポザルが送信される場合、またはその逆の場合にも送信されます。
3: Invalid Object Type: This subcode is used if the object type is known, but it is not valid for this particular GIST message type.
3：無効なオブジェクトタイプ：このサブコードは、オブジェクトタイプがわかっている場合に使用されますが、この特定のGISTメッセージタイプには有効ではありません。
4: Untranslated Object: This subcode is used if the object type is known and is mandatory to interpret, but it contains addressing data that has not been translated by an intervening NAT.
4：翻訳されていないオブジェクト：このサブコードは、オブジェクトタイプが既知であり、解釈することが必須である場合に使用されますが、介在するNATによって翻訳されていないアドレス指定データが含まれています。
5: Invalid Extensibility Flags: This subcode is used if an object is received with the extensibility flags AB=11.
5：無効な拡張可能性フラグ：このサブコードは、拡張性フラグab = 11でオブジェクトが受信された場合に使用されます。
Class: Protocol-Error Code: 10 Additional Info: 1 or 2 Object Value Info fields as given below
クラス：プロトコルエラーコード：10追加情報：1または2以下のようにオブジェクト値情報フィールド
This message is sent if a node receives a message containing an object that cannot be properly parsed. The error message contains a single Object Value Info object, except for subcode 5 as stated below. This error code is split into subcodes as follows:
このメッセージは、ノードが適切に解析できないオブジェクトを含むメッセージを受信した場合に送信されます。エラーメッセージには、以下に記載されているサブコード5を除き、単一のオブジェクト値情報オブジェクトが含まれています。このエラーコードは、次のようにサブコードに分割されます。
0: Incorrect Length: The overall length does not match the object length calculated from the object contents.
0：誤った長さ：全体の長さは、オブジェクトの内容から計算されたオブジェクトの長さと一致しません。
1: Value Not Supported: The value of a field is not supported by the GIST node.
1：サポートされていない値：フィールドの値は、GISTノードによってサポートされていません。
2: Invalid Flag-Field Combination: An object contains an invalid combination of flags and/or fields. At the moment, this only relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future there may be more.
2：無効なフラグフィールドの組み合わせ：オブジェクトには、フラグおよび/またはフィールドの無効な組み合わせが含まれています。現時点では、これはパス結合されたMRI（付録A.3.1.1）にのみ関連していますが、将来的にはさらに多くの場合があります。
3: Empty List: At the moment, this only relates to Stack-Proposals. The error message is sent if a stack proposal with a length > 0 contains only null bytes (a length of 0 is handled as "Value Not Supported").
3：空のリスト：現時点では、これはスタックプロポザルにのみ関連しています。長さ> 0のスタック提案にヌルバイトのみが含まれている場合、エラーメッセージが送信されます（長さ0は「サポートされていない値」として処理されます）。
4: Invalid Cookie: The message contains a cookie that could not be verified by the node.
4：無効なCookie：メッセージには、ノードで検証できないCookieが含まれています。
5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode is used if a GIST node receives a message in which the data in the Stack-Proposal object is inconsistent with the information in the Stack Configuration Data object. In this case, both the Stack-Proposal object and Stack-Configuration-Data object MUST be included in separate Object Value Info fields in that order.
5：Stack-Proposal-Stack-Configuration-Data Mismatch：このサブコードは、GISTノードがスタックプロポザルオブジェクトのデータがStack Configuration Dataオブジェクトの情報と矛盾するメッセージを受信した場合に使用されます。この場合、スタックプロポザルオブジェクトとスタックコンフィグラーデータオブジェクトの両方を、その順序で個別のオブジェクト値情報フィールドに含める必要があります。
Class: Permanent-Failure Code: 11 Additional Info: None
クラス：永続的なフェイルコード：11追加情報：なし
This error indicates that a message was received with an IP-layer TTL outside an acceptable range, for example, that an upstream Query was received with an IP layer TTL of less than 254 (i.e., more than one IP hop from the sender). The actual IP distance can be derived from the IP-TTL information in the NLI object carried in the same message.
このエラーは、たとえば、254未満のIPレイヤーTTL（つまり、送信者からの複数のIPホップ）でアップストリームクエリが受信されたことなど、許容範囲外のIP層TTLでメッセージを受信したことを示しています。実際のIP距離は、同じメッセージに掲載されたNLIオブジェクトのIP-TTL情報から導出できます。
Class: Permanent-Failure Code: 12 Additional Info: Object Value Info
クラス：永続的なフェイルコード：12追加情報：オブジェクト値情報
This error indicates that a message was received with an MRI that could not be accepted, e.g., because of too much wildcarding or failing some validation check (cf. Section 5.8.1.2). The Object Value Info includes the MRI so the error originator can indicate the part of the MRI that caused the problem. The error code is divided into subcodes as follows:
このエラーは、たとえば、ワイルドカードが多すぎるか、検証チェックに失敗したために、受け入れられないMRIでメッセージが受信されたことを示しています（セクション5.8.1.2を参照）。オブジェクト値情報にはMRIが含まれているため、エラーオリジネーターは問題を引き起こしたMRIの部分を示すことができます。エラーコードは、次のようにサブコードに分割されます。
0: MRI Too Wild: The MRI contained too much wildcarding (e.g., too short a destination address prefix) to be forwarded correctly down a single path.
0：MRI Too Wild：MRIには、単一のパスを正しく転送するには、ワイルドカードが多すぎる（例：宛先アドレスのプレフィックスが短すぎる）が含まれていました。
1: IP Version Mismatch: The MRI in a path-coupled Query message refers to an IP version that is not implemented on the interface used, or is different from the IP version of the Query encapsulation (see Section 7.4).
1：IPバージョンの不一致：パス結合クエリメッセージのMRIは、使用されるインターフェイスに実装されていないIPバージョンを指します。
2: Ingress Filter Failure: The MRI in a path-coupled Query message describes a flow that would not pass ingress filtering on the interface used.
2：イングレスフィルター障害：パス結合クエリメッセージのMRIは、使用されるインターフェイスのイングレスフィルタリングを通過しないフローを説明します。
This appendix provides an abstract API between GIST and signalling applications. It should not constrain implementers, but rather help clarify the interface between the different layers of the NSIS protocol suite. In addition, although some of the data types carry the information from GIST information elements, this does not imply that the format of that data as sent over the API has to be the same.
この付録は、GISTアプリケーションとシグナリングアプリケーションの間の抽象的なAPIを提供します。実装者を制約するのではなく、NSISプロトコルスイートの異なるレイヤー間のインターフェイスを明確にするのに役立ちます。さらに、一部のデータ型はGIST情報要素から情報を伝えていますが、これはAPIを介して送信されたデータの形式が同じでなければならないことを意味するものではありません。
Conceptually, the API has similarities to the sockets API, particularly that for unconnected UDP sockets. An extension for an API like that for UDP connected sockets could be considered. In this case, for example, the only information needed in a SendMessage primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle (which can be null). Other information that was persistent for a group of messages could be configured once for the socket. Such extensions may make a concrete implementation more efficient but do not change the API semantics, and so are not considered further here.
概念的には、APIはソケットAPI、特に接続されていないUDPソケットのAPIと類似しています。UDP接続ソケットのAPIの拡張機能を考慮することができます。この場合、たとえば、SendMessage Primitiveで必要な情報は、NSLP-Data、NSLP-Data-Size、およびNSLP-Messageハンドル（これはnull）です。メッセージのグループに対して永続的だったその他の情報は、ソケットに対して一度構成できます。このような拡張機能は、具体的な実装をより効率的にする可能性がありますが、APIセマンティクスを変更しないため、ここではこれ以上考慮されません。
This primitive is passed from a signalling application to GIST. It is used whenever the signalling application wants to initiate sending a message.
この原始は、シグナリングアプリケーションからGISTに渡されます。信号アプリケーションがメッセージの送信を開始したいときはいつでも使用されます。
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, NSLPID, Session-ID, MRI, SII-Handle, Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count )
SendMessage（NSLP-DATA、NSLP-DATA-SIZE、NSLP-Messageハンドル、NSLPID、セッションID、MRI、SIIハンドル、転送アトリビュート、タイムアウト、IP-TTL、Gist-Hop-Count）
The following arguments are mandatory:
次の引数は必須です。
NSLP-Data: The NSLP message itself.
NSLP-DATA：NSLPメッセージ自体。
NSLP-Data-Size: The length of NSLP-Data.
NSLP-DATA-SIZE：NSLP-DATAの長さ。
NSLP-Message-Handle: A handle for this message that can be used by GIST as a reference in subsequent MessageStatus notifications (Appendix B.3). Notifications could be about error conditions or about the security attributes that will be used for the message. A NULL handle may be supplied if the NSLP is not interested in such notifications.
NSLP-Messageハンドル：その後のMessageStatus通知の参照としてGISTによって使用できるこのメッセージのハンドル（付録B.3）。通知は、メッセージに使用されるエラー条件またはセキュリティ属性に関するものです。NSLPがそのような通知に関心がない場合、ヌルハンドルが提供される場合があります。
NSLPID: An identifier indicating which NSLP this is.
NSLPID：これがどのNSLPであるかを示す識別子。
Session-ID: The NSIS session identifier. Note that it is assumed that the signalling application provides this to GIST rather than GIST providing a value itself.
セッションID：NSISセッション識別子。シグナリングアプリケーションは、値自体を提供するGISTではなく、これをGISTに提供すると想定されていることに注意してください。
MRI: Message routing information for use by GIST in determining the correct next GIST hop for this message. The MRI implies the message routing method to be used and the message direction.
MRI：このメッセージの正しい次のGISTホップを決定する際に、GISTが使用するメッセージルーティング情報。MRIは、使用するメッセージルーティング方法とメッセージの方向を意味します。
The following arguments are optional:
次の引数はオプションです。
SII-Handle: A handle, previously supplied by GIST, to a data structure that should be used to route the message explicitly to a particular GIST next hop.
SIIハンドル：以前にGISTで提供されていたハンドルは、メッセージを特定のGIST Next Hopに明示的にルーティングするために使用する必要があるデータ構造になります。
Transfer-Attributes: Attributes defining how the message should be handled (see Section 4.1.2). The following attributes can be considered:
Transfer-Attributes：メッセージの処理方法を定義する属性（セクション4.1.2を参照）。次の属性を考慮することができます。
Reliability: Values 'unreliable' or 'reliable'.
信頼性：値「信頼できない」または「信頼性」。
Security: This attribute allows the NSLP to specify what level of security protection is requested for the message (such as 'integrity' or 'confidentiality') and can also be used to specify what authenticated signalling source and destination identities should be used to send the message. The possibilities can be learned by the signalling application from prior MessageStatus or RecvMessage notifications. If an NSLP-Message-Handle is provided, GIST will inform the signalling application of what values it has actually chosen for this attribute via a MessageStatus callback. This might take place either synchronously (where GIST is selecting from available messaging associations) or asynchronously (when a new messaging association needs to be created).
セキュリティ：この属性により、NSLPはメッセージに対してどのレベルのセキュリティ保護が要求されるか（「整合性」や「機密性」など）を指定でき、また、認証されたシグナリングソースと宛先IDを使用して使用するために使用するためにも使用できます。メッセージ。可能性は、以前のMessageStatusまたはRecVMessage通知からのシグナリングアプリケーションによって学ぶことができます。NSLP-Messageハンドルが提供されている場合、GISTは、MessageStatusコールバックを介してこの属性に対して実際に選択した値のシグナリングアプリケーションに通知します。これは、同期的に（GISTが利用可能なメッセージングアソシエーションから選択している場合）または非同期（新しいメッセージングアソシエーションを作成する必要がある場合）のいずれかが行われる場合があります。
Local Processing: This attribute contains hints from the signalling application about what local policy should be applied to the message -- in particular, its transmission priority relative to other messages, or whether GIST should attempt to set up or maintain forward routing state.
ローカル処理：この属性には、メッセージにローカルポリシーを適用すべきか、特に他のメッセージに対する送信の優先度、またはGISTが転送ルーティング状態を設定または維持しようとするかどうかについてのシグナリングアプリケーションからのヒントが含まれています。
Timeout: Length of time GIST should attempt to send this message before indicating an error.
タイムアウト：時間の長さは、エラーを示す前にこのメッセージを送信しようとする必要があります。
IP-TTL: The value of the IP layer TTL that should be used when sending this message (may be overridden by GIST for particular messages).
IP-TTL：このメッセージを送信するときに使用する必要があるIPレイヤーTTLの値（特定のメッセージのGISTによってオーバーライドされる場合があります）。
GIST-Hop-Count: The value for the hop count when sending the message.
Gist-Hop-Count：メッセージを送信するときのホップカウントの値。
This primitive is passed from GIST to a signalling application. It is used whenever GIST receives a message from the network, including the case of null messages (zero-length NSLP payload), typically initial Query messages. For Queries, the results of invoking this primitive are used by GIST to check whether message routing state should be created (see the discussion of the 'Routing-State-Check' argument below).
この原始は、要点からシグナリングアプリケーションに渡されます。GISTがネットワークからメッセージを受信するたびに使用されます。これには、nullメッセージの場合（ゼロ長nslpペイロード）、通常初期クエリメッセージが含まれます。クエリの場合、このプリミティブを呼び出す結果は、GISTによって使用されて、メッセージルーティング状態を作成する必要があるかどうかを確認します（以下の「ルーティング状態チェック」引数の説明を参照）。
RecvMessage ( NSLP-Data, NSLP-Data-Size, NSLPID, Session-ID, MRI, Routing-State-Check, SII-Handle, Transfer-Attributes, IP-TTL, IP-Distance, GIST-Hop-Count, Inbound-Interface )
recvmessage（nslp-data、nslp-data-size、nslpid、session-id、mri、routing-state-check、sii handle、transfer-attributes、ip-ttl、ip-distance、gist-hop-count、inbound-インターフェース ）
NSLP-Data: The NSLP message itself (may be empty).
NSLP-DATA：NSLPメッセージ自体（空の可能性があります）。
NSLP-Data-Size: The length of NSLP-Data (may be zero).
NSLP-DATA-SIZE：NSLP-DATAの長さ（ゼロになる可能性があります）。
NSLPID: An identifier indicating which NSLP this message is for.
NSLPID：このメッセージがどのNSLPであるかを示す識別子。
Session-ID: The NSIS session identifier.
セッションID：NSISセッション識別子。
MRI: Message routing information that was used by GIST in forwarding this message. Implicitly defines the message routing method that was used and the direction of the message relative to the MRI.
MRI：このメッセージを転送する際にGISTが使用したメッセージルーティング情報。使用されたメッセージルーティングメソッドと、MRIに対するメッセージの方向を暗黙的に定義します。
Routing-State-Check: This boolean is True if GIST is checking with the signalling application to see if routing state should be created with the peer or the message should be forwarded further (see Section 4.3.2). If True, the signalling application should return the following values via the RecvMessage call:
ルーティングステートチェック：GISTがシグナリングアプリケーションでチェックして、ルーティング状態をピアで作成するか、メッセージをさらに転送する必要があるかどうかを確認する場合、このブール値は真です（セクション4.3.2を参照）。Trueの場合、シグナリングアプリケーションは、recvmessageコールを使用して次の値を返す必要があります。
A boolean indicating whether to set up the state.
状態をセットアップするかどうかを示すブール。
Optionally, an NSLP-Payload to carry in the generated Response or forwarded Query respectively.
オプションで、生成された応答または転送クエリをそれぞれ持ち運ぶためのNSLP-Payload。
This mechanism could be extended to enable the signalling application to indicate to GIST whether state installation should be immediate or deferred (see Section 5.3.3 and Section 6.3 for further discussion).
このメカニズムを拡張して、シグナリングアプリケーションがGISTに状態の設置を即座に繰り延べるかどうかを示すことができます（詳細については、セクション5.3.3およびセクション6.3を参照）。
SII-Handle: A handle to a data structure, identifying a peer address and interface. Can be used to identify route changes and for explicit routing to a particular GIST next hop.
SIIハンドル：ピアアドレスとインターフェイスを識別するデータ構造のハンドル。ルートの変更を識別し、特定のGIST次のホップへの明示的なルーティングに使用できます。
Transfer-Attributes: The reliability and security attributes that were associated with the reception of this particular message. As well as the attributes associated with SendMessage, GIST may indicate the level of verification of the addresses in the MRI. Three attributes can be indicated:
Transfer-Attributes：この特定のメッセージの受信に関連付けられた信頼性とセキュリティ属性。SendMessageに関連する属性と同様に、GISTはMRIのアドレスの検証のレベルを示している場合があります。3つの属性を示すことができます。
* Whether the signalling source address is one of the flow endpoints (i.e., whether this is the first or last GIST hop).
* 信号ソースアドレスがフローエンドポイントの1つであるかどうか（つまり、これが最初のGISTホップか最後のGISTホップか）。
* Whether the signalling source address has been validated by a return routability check.
* 信号ソースアドレスが返品ルー上のチェックによって検証されているかどうか。
* Whether the message was explicitly routed (and so has not been validated by GIST as delivered consistently with local routing state).
* メッセージが明示的にルーティングされたかどうか（したがって、ローカルルーティング状態と一貫して配信されるGISTによって検証されていません）。
IP-TTL: The value of the IP layer TTL this message was received with (if available).
IP-TTL：IPレイヤーTTLの値このメッセージは（利用可能な場合）で受信されました。
IP-Distance: The number of IP hops from the peer signalling node that sent this message along the path, or 0 if this information is not available.
IP-Distance：このメッセージをパスに沿って送信したピアシグナリングノードからのIPホップの数、またはこの情報が利用できない場合は0。
GIST-Hop-Count: The value of the hop count the message was received with, after being decremented in the GIST receive-side processing.
Gist-Hop-Count：GIST受信側の処理で減少した後、メッセージが受信されたホップカウントの値。
Inbound-Interface: Attributes of the interface on which the message was received, such as whether it lies on the internal or external side of a NAT. These attributes have only local significance and are defined by the implementation.
インバウンドインターフェイス：メッセージが受信されたインターフェイスの属性。これは、NATの内部または外部側にあるかどうかなどです。これらの属性には局所的な重要性のみがあり、実装によって定義されます。
This primitive is passed from GIST to a signalling application. It is used to notify the signalling application that a message that it requested to be sent could not be dispatched, or to inform the signalling application about the transfer attributes that have been selected for the message (specifically, security attributes). The signalling application can respond to this message with a return code to abort the sending of the message if the attributes are not acceptable.
この原始は、要点からシグナリングアプリケーションに渡されます。これは、送信するように要求したメッセージを派遣できないことを信号アプリケーションに通知するために、またはメッセージに対して選択された転送属性（具体的にはセキュリティ属性）について信号アプリケーションに通知するために使用されます。シグナリングアプリケーションは、属性が受け入れられない場合、メッセージの送信を中止するための返品コードでこのメッセージに応答できます。
MessageStatus ( NSLP-Message-Handle, Transfer-Attributes, Error-Type )
MessageStatus（nslp-messageハンドル、転送アトリビュート、エラータイプ）
NSLP-Message-Handle: A handle for the message provided by the signalling application in SendMessage.
NSLP-Messageハンドル：SendMessageのシグナリングアプリケーションによって提供されるメッセージのハンドル。
Transfer-Attributes: The reliability and security attributes that will be used to transmit this particular message.
Transfer-Attributes：この特定のメッセージを送信するために使用される信頼性とセキュリティ属性。
Error-Type: Indicates the type of error that occurred, for example, 'no next node found'.
エラータイプ：発生したエラーのタイプを示します。たとえば、「次のノードは見つかりません」。
This primitive is passed from GIST to a signalling application. It indicates that a network event of possible interest to the signalling application occurred.
この原始は、要点からシグナリングアプリケーションに渡されます。これは、シグナリングアプリケーションに関心のあるネットワークイベントが発生したことを示しています。
NetworkNotification ( NSLPID, MRI, Network-Notification-Type )
ネットワーク通知（NSW PID、mrinetwork-notification-type）
NSLPID: An identifier indicating which NSLP this is message is for.
NSLPID：これがメッセージであるNSLPを示す識別子。
MRI: Provides the message routing information to which the network notification applies.
MRI：ネットワーク通知が適用されるメッセージルーティング情報を提供します。
Network-Notification-Type: Indicates the type of event that caused the notification and associated additional data. Five events have been identified:
Network-Notification-Type：通知と関連する追加データを引き起こしたイベントのタイプを示します。5つのイベントが特定されています。
Last Node: GIST has detected that this is the last NSLP-aware node in the path. See Section 4.3.4.
最後のノード：GISTは、これがパスの最後のNSLP認識ノードであることを検出しました。セクション4.3.4を参照してください。
Routing Status Change: GIST has installed new routing state, has detected that existing routing state may no longer be valid, or has re-established existing routing state. See Section 7.1.3. The new status is reported; if the status is Good, the SII-Handle of the peer is also reported, as for RecvMessage.
ルーティングステータスの変更：GISTは新しいルーティング状態をインストールし、既存のルーティング状態がもはや有効でない可能性があるか、既存のルーティング状態を再確立したことを検出しました。セクション7.1.3を参照してください。新しいステータスが報告されています。ステータスが良好な場合、recvmessageについては、ピアのSIIハンドルも報告されます。
Route Deletion: GIST has determined that an old route is now definitely invalid, e.g., that flows are definitely not using it (see Section 7.1.4). The SII-Handle of the peer is also reported.
ルートの削除：GISTは、古いルートが今では間違いなく無効であると判断しました。たとえば、フローは間違いなくそれを使用していません（セクション7.1.4を参照）。ピアのSIIハンドルも報告されています。
Node Authorisation Change: The authorisation status of a peer has changed, meaning that routing state is no longer valid or that a signalling peer is no longer reachable; see Section 4.4.2.
ノード認証の変更：ピアの承認ステータスが変更されました。つまり、ルーティング状態はもはや有効ではないか、シグナリングピアが到達できなくなったことを意味します。セクション4.4.2を参照してください。
Communication Failure: Communication with the peer has failed; messages may have been lost.
コミュニケーションの失敗：ピアとのコミュニケーションは失敗しました。メッセージが失われた可能性があります。
This primitive is passed from a signalling application to GIST. It indicates the duration for which the signalling application would like GIST to retain its routing state. It can also give a hint that the signalling application is no longer interested in the state.
この原始は、シグナリングアプリケーションからGISTに渡されます。これは、シグナリングアプリケーションがGISTがルーティング状態を保持することを望む期間を示しています。また、シグナリングアプリケーションがもはや州に関心がないことを示唆することができます。
SetStateLifetime ( NSLPID, MRI, SID, State-Lifetime )
SetStateLifetime（NSLPID、MRI、SID、STATE-LIFETIME）
NSLPID: Provides the NSLPID to which the routing state lifetime applies.
NSLPID：ルーティング状態の寿命が適用されるNSLPIDを提供します。
MRI: Provides the message routing information to which the routing state lifetime applies; includes the direction (in the D-flag).
MRI：ルーティング状態の寿命が適用されるメッセージルーティング情報を提供します。方向（d-flag）が含まれます。
SID: The session ID that the signalling application will be using with this routing state. Can be wildcarded.
SID：信号アプリケーションがこのルーティング状態で使用するセッションID。ワイルドカードできます。
State-Lifetime: Indicates the lifetime for which the signalling application wishes GIST to retain its routing state (may be zero, indicating that the signalling application has no further interest in the GIST state).
状態 - 一時的：シグナリングアプリケーションがGISTがルーティング状態を保持することを望んでいる寿命を示します（シグナリングアプリケーションがGIST状態にそれ以上の関心がないことを示します）。
This primitive is passed from a signalling application to GIST. It indicates that the signalling application has knowledge that the next signalling hop known to GIST may no longer be valid, either because of changes in the network routing or the processing capabilities of signalling application nodes. See Section 7.1.
この原始は、シグナリングアプリケーションからGISTに渡されます。これは、シグナリングアプリケーションには、ネットワークルーティングの変更またはシグナリングアプリケーションノードの処理能力があるため、GISTに知られている次のシグナルホップがもはや有効ではない可能性があることを知っていることを示しています。セクション7.1を参照してください。
InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data, NSLP-Data-Size, Urgent )
InvalidateroutingState（NSLPID、MRI、ステータス、NSLP-DATA、NSLP-DATA-SIZE、緊急））
NSLPID: The NSLP originating the message. May be null (in which case, the invalidation applies to all signalling applications).
NSLPID：メッセージを発信するNSLP。ヌルかもしれません（この場合、無効化はすべてのシグナリングアプリケーションに適用されます）。
MRI: The flow for which routing state should be invalidated; includes the direction of the change (in the D-flag).
MRI：ルーティング状態を無効にするフロー。変更の方向（D-Flag）が含まれています。
Status: The new status that should be assumed for the routing state, one of Bad or Tentative (see Section 7.1.3).
ステータス：ルーティング状態で想定される新しいステータス、悪いまたは暫定的な状態（セクション7.1.3を参照）。
NSLP-Data, NSLP-Data-Size: (optional) A payload provided by the NSLP to be used the next GIST handshake. This can be used as part of a conditional peering process (see Section 4.3.2). The payload will be transmitted without security protection.
NSLP-DATA、NSLP-DATA-SIZE：（オプション）次のGISTハンドシェイクで使用されるNSLPによって提供されるペイロード。これは、条件付きピアリングプロセスの一部として使用できます（セクション4.3.2を参照）。ペイロードはセキュリティ保護なしで送信されます。
Urgent: A hint as to whether rediscovery should take place immediately or only with the next signalling message.
緊急：再発見がすぐに行われるべきか、次の信号メッセージでのみ行われるべきかについてのヒント。
The GIST peer discovery handshake (Section 4.4.1) depends on the interception of Q-mode encapsulated IP packets (Section 4.3.1 and Section 5.3.2) by routers. There are two fundamental requirements on the process:
GISTピアディスカバリーハンドシェイク（セクション4.4.1）は、ルーターによるQモードカプセル化IPパケット（セクション4.3.1およびセクション5.3.2）の傍受に依存します。プロセスには2つの基本的な要件があります。
1. Packets relevant to GIST must be intercepted.
1. GISTに関連するパケットを傍受する必要があります。
2. Packets not relevant to GIST must be forwarded transparently.
2. GISTに関連しないパケットは、透過的に転送する必要があります。
This specification defines the GIST behaviour to ensure that both requirements are met for a GIST-capable node. However, GIST packets will also encounter non-GIST nodes, for which requirement (2) still applies. If non-GIST nodes block Q-mode packets, GIST will not function. It is always possible for middleboxes to block specific traffic types; by using a normal UDP encapsulation for Q-mode traffic, GIST allows NATs at least to pass these messages (Section 7.2.1), and firewalls can be configured with standard policies. However, where the Q-mode encapsulation uses a Router Alert Option (RAO) at the IP level this can lead to additional problems. The situation is different for IPv4 and IPv6.
この仕様では、GISTの動作を定義して、両方の要件がGIST対応ノードに対して満たされるようにします。ただし、GISTパケットは非GISTノードにも遭遇し、要件（2）が適用されます。非GISTノードがQモードパケットをブロックすると、GISTは機能しません。ミドルボックスが特定のトラフィックタイプをブロックすることは常に可能です。Qモードトラフィックに通常のUDPカプセル化を使用することにより、GISTを使用すると、NATは少なくともこれらのメッセージを渡すことができ（セクション7.2.1）、ファイアウォールは標準ポリシーで構成できます。ただし、Q-Modeカプセル化がIPレベルでルーターアラートオプション（RAO）を使用している場合、追加の問題につながる可能性があります。IPv4とIPv6の状況は異なります。
The IPv4 RAO is defined by [13], which defines the RAO format with a 2-byte value field; however, only one value (zero) is defined and there is no IANA registry for further allocations. It states that unknown values should be ignored (i.e., the packets forwarded as normal IP traffic); however, it has also been reported that some existing implementations simply ignore the RAO value completely (i.e. process any packet with an RAO as though the option value was zero). Therefore, the use of non-zero RAO values cannot be relied on to make GIST traffic transparent to existing implementations. (Note that it may still be valuable to be able to allocate non-zero RAO values for IPv4: this makes the interception process more efficient for nodes that do examine the value field, and makes no difference to nodes that *incorrectly* ignore it. Whether or not non-zero RAO values are used does not change the GIST protocol operation, but needs to be decided when new NSLPs are registered.)
IPv4 RAOは[13]で定義されており、RAO形式を2バイト値フィールドで定義します。ただし、定義されている値（ゼロ）は1つだけで、さらなる割り当てのためのIANAレジストリはありません。未知の値は無視する必要があると述べています（つまり、通常のIPトラフィックとして転送されるパケット）。ただし、一部の既存の実装は、RAO値を完全に無視するだけであることが報告されています（つまり、オプション値がゼロであるかのようにRAOでパケットを処理します）。したがって、ゼロ以外のRAO値の使用は、既存の実装に対してGISTトラフィックを透明にするために依存することはできません。（IPv4にゼロ以外のRAO値を割り当てることができることはまだ価値があるかもしれません。これにより、値フィールドを調べるノードの傍受プロセスがより効率的になり、 *誤って *無視するノードに違いはありません。ゼロ以外のRAO値が使用されるかどうかは、GISTプロトコル操作を変更しませんが、新しいNSLPが登録されているときに決定する必要があります。）
The second stage of the analysis is therefore what happens when a non-GIST node that implements RAO handling sees a Q-mode packet. The RAO specification simply states "Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol field, for example) to determine whether or not further processing is necessary". There are two possible basic behaviours for GIST traffic:
したがって、分析の第2段階は、RAOハンドリングを実装する非GISTノードがQモードパケットを見たときに起こることです。RAOの仕様には、「このオプションを認識するルーターは、それをより密接に携帯するパケットを調べる（たとえば、IPプロトコルフィールドをチェックして）さらなる処理が必要かどうかを判断する必要がある」と述べています。GISTトラフィックには2つの基本的な動作があります。
1. The "closer examination" of the packet is sufficiently intelligent to realise that the node does not need to process it and should forward it. This could either be by virtue of the fact that the node has not been configured to match IP-Protocol=UDP for RAO packets at all or that even if UDP traffic is intercepted the port numbers do not match anything locally configured.
1. パケットの「綿密な調査」は、ノードが処理する必要がなく、転送する必要がないことを認識するのに十分なインテリジェントです。これは、ノードがRAOパケットのIP-Protocol = UDPに一致するように構成されていないという事実のおかげであるか、UDPトラフィックが傍受されたとしても、ポート番号がローカルで構成されたものと一致しないという事実のいずれかです。
2. The "closer examination" of the packet identifies it as UDP, and delivers it to the UDP stack on the node. In this case, it can no longer be guaranteed to be processed appropriately. Most likely, it will simply be dropped or rejected with an ICMP error (because there is no GIST process on the destination port to which to deliver it).
2. パケットの「綿密な調査」は、それをUDPとして識別し、ノードのUDPスタックに配信します。この場合、適切に処理することを保証することはできません。おそらく、ICMPエラーで単純にドロップまたは拒否されるだけです（宛先ポートに配信する宛先ポートにGISTプロセスがないため）。
Analysis of open-source operating system source code shows the first type of behaviour, and this has also been seen in direct GIST experiments with commercial routers, including the case when they process other uses of the RAO (i.e., RSVP). However, it has also been reported that other RAO implementations will exhibit the second type of behaviour. The consequence of this would be that Q-mode packets are blocked in the network and GIST could not be used. Note that although this is caused by some subtle details in the RAO processing rules, the end result is the same as if the packet was simply blocked for other reasons (for example, many IPv4 firewalls drop packets with options by default).
オープンソースオペレーティングシステムのソースコードの分析は、最初のタイプの動作を示しており、これは、RAO（つまり、RSVP）の他の使用を処理する場合を含む、市販のルーターを使用した直接的なGIST実験でも見られています。ただし、他のRAOの実装が2番目のタイプの動作を示すことも報告されています。これの結果は、Qモードパケットがネットワークでブロックされ、GISTを使用できないことになります。これはRAO処理ルールのいくつかの微妙な詳細によって引き起こされますが、最終結果は他の理由でパケットが単純にブロックされた場合と同じであることに注意してください（たとえば、多くのIPv4ファイアウォールはデフォルトでオプションをドロップします）。
The GIST specification allows two main options for circumventing nodes that block Q-mode traffic in IPv4. Whether to use these options is a matter of implementation and configuration choice.
GIST仕様では、IPv4のQモードトラフィックをブロックするノードを回避するための2つの主要なオプションが可能になります。これらのオプションを使用するかどうかは、実装と構成の選択の問題です。
o A GIST node can be configured to send Q-mode packets without the RAO at all. This should avoid the above problems, but should only be done if it is known that nodes on the path to the receiver are able to intercept such packets. (See Section 5.3.2.1.)
o GISTノードは、RAOなしでQモードパケットを送信するように構成できます。これは上記の問題を回避する必要がありますが、受信機へのパス上のノードがそのようなパケットを傍受できることがわかっている場合にのみ行う必要があります。（セクション5.3.2.1を参照してください。）
o If a GIST node can identify exactly where the packets are being blocked (e.g., from ICMP messages), or can discover some point on the path beyond the blockage (e.g., by use of traceroute or by routing table analysis), it can send the Q-mode messages to that point using IP-in-IP tunelling without any RAO. This bypasses the input side processing on the blocking node, but picks up normal GIST behaviour beyond it.
o GISTノードがパケットがブロックされている場所（ICMPメッセージから）を正確に識別できる場合、または閉塞を越えたパス上のポイントを発見できる場合（たとえば、Tracerouteの使用またはルーティングテーブル分析によって）、RAOなしでIP-in-IPトネルを使用して、そのポイントへのQモードメッセージ。これにより、ブロッキングノードの入力サイド処理がバイパスされますが、それを超えて通常の要点の動作を選択します。
If in the light of deployment experience the problem of blocked Q-mode traffic turns out to be widespread and these techniques turn out to be insufficient, a further possibility is to define an alternative Q-mode encapsulation that does not use UDP. This would require a specification change. Such an option would be restricted to network-internal use, since operation through NATs and firewalls would be much harder with it.
展開の経験に照らして、ブロックされたQモードトラフィックの問題が広まっていることが判明し、これらの手法が不十分であることが判明した場合、さらなる可能性は、UDPを使用しない代替Qモードカプセル化を定義することです。これには、仕様の変更が必要です。このようなオプションは、NATとファイアウォールを介した動作がはるかに難しくなるため、ネットワーク内部の使用に制限されます。
The situation with IPv6 is rather different, since in that case the use of non-zero RAO values is well established in the specification ([17]) and an IANA registry exists. The main problem is that several implementations are still immature: for example, some treat any RAO-marked packet as though it was for local processing without further analysis. Since this prevents any RAO usage at all (including the existing standardised ones) in such a network, it seems reasonable to assume that such implementations will be fixed as part of the general deployment of IPv6.
IPv6の状況はかなり異なります。その場合、非ゼロRAO値の使用は仕様で十分に確立されており（[17]）、IANAレジストリが存在するためです。主な問題は、いくつかの実装がまだ未熟であることです。たとえば、ラオマークされたパケットを、それがさらなる分析なしでローカル処理用であるかのように扱う人もいます。これにより、このようなネットワーク内のRAOの使用（既存の標準化されたものを含む）がまったく防止されるため、そのような実装はIPv6の一般的な展開の一部として修正されると仮定するのが妥当と思われます。
Figure 11 shows a signalling scenario for a single flow being managed by two signalling applications using the path-coupled message routing method. The flow sender and receiver and one router support both; two other routers support one each. The figure also shows the routing state table at node B.
図11は、パス結合メッセージルーティング方法を使用して、2つのシグナリングアプリケーションによって管理されている単一のフローのシグナルシナリオを示しています。フロー送信者とレシーバーと1つのルーターは両方をサポートします。他の2つのルーターはそれぞれ1つをサポートしています。図は、ノードBのルーティング状態テーブルも示しています。
A B C D E
+------+ +-----+ +-----+ +-----+ +--------+
| Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow |
|Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver|
| | +-+ +-+ |GIST | |GIST | |GIST | | |
+------+ +-----+ +-----+ +-----+ +--------+
Flow Direction ------------------------------>>
+------------------------------------+---------+--------+-----------+
| Message Routing Information | Session | NSLPID | Routing |
| | ID | | State |
+------------------------------------+---------+--------+-----------+
| MRM = Path-Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0xABCD | NSLP1 | (null) |
| {IP-A, IP-E, proto/ports}; D=down | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0x1234 | NSLP2 | Points to |
| {IP-A, IP-E, proto/ports}; D=down | | | B-D MA |
+------------------------------------+---------+--------+-----------+
Figure 11: A Signalling Scenario
図11：シグナリングシナリオ
The upstream state is just the same address for each application. For the downstream direction, NSLP1 only requires D-mode messages and so no explicit routing state towards C is needed. NSLP2 requires a messaging association for its messages towards node D, and node C does not process NSLP2 at all, so the peer state for NSLP2 is a pointer to a messaging association that runs directly from B to D. Note that E is not visible in the state table (except implicitly in the address in the message routing information); routing state is stored only for adjacent peers. (In addition to the peer identification, IP hop counts are stored for each peer where the state itself if not null; this is not shown in the table.)
上流の状態は、アプリケーションごとに同じアドレスです。下流の方向には、NSLP1はDモードメッセージのみを必要とするため、Cに対する明示的なルーティング状態は必要ありません。NSLP2はノードDへのメッセージに対してメッセージング関連を必要とし、ノードCはNSLP2をまったく処理しないため、NSLP2のピアステートは、BからDに直接実行されるメッセージングアソシエーションへのポインターです。状態テーブル（メッセージルーティング情報のアドレス内で暗黙的に除く）;ルーティング状態は、隣接するピア用にのみ保存されます。（ピア識別に加えて、IPホップカウントは、NULLではない場合、状態自体がテーブルに表示されない場合、各ピアに対して保存されます。）
Figure 12 shows a GIST handshake setting up a messaging association for B-D signalling, with the exchange of Stack Proposals and MA-protocol-options in each direction. The Querying node selects TLS/ TCP as the stack configuration and sets up the messaging association over which it sends the Confirm.
図12は、各方向にスタック提案とMAプロトコルオプションの交換を伴うB-Dシグナル伝達のメッセージング関連を設定する要点の握手を示しています。クエリノードは、TLS/ TCPをスタック構成として選択し、確認を送信するメッセージングアソシエーションをセットアップします。
-------------------------- Query ---------------------------->
IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
D-mode magic number (0x4e04 bda5)
GIST(Header(Type=Query; NSLPID=NSLP2; C=1; R=1; S=0)
MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
QueryCookie(0x139471239471923526)
StackProposal(#Proposals=3;1=TLS/TCP; 2=TLS/SCTP; 3=TCP)
StackConfigurationData(HoldTime=300; #MPO=2;
TCP(Applicable: all; Data: null)
SCTP(Applicable: all; Data: null)))
<---------------------- Response ----------------------------
IP(Src=IP#D; Dst=IP#B); UDP(Src=GIST; Dst=6789)
D-mode magic number (0x4e04 bda5)
GIST(Header(Type=Response; NSLPID=NSLP2; C=0; R=1; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=up)
SessionID(0x1234) NLI(Peer='stringr2', IA=IP#D)
QueryCookie(0x139471239471923526)
ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=200; #MPO=3;
TCP(Applicable: 3; Data: port=6123)
TCP(Applicable: 1; Data: port=5438)
SCTP(Applicable: all; Data: port=3333)))
-------------------------TCP SYN----------------------->
<----------------------TCP SYN/ACK----------------------
-------------------------TCP ACK----------------------->
TCP connect(IP Src=IP#B; IP Dst=IP#D; Src Port=9166; Dst Port=6123)
<-----------------------TLS INIT----------------------->
------------------------ Confirm ---------------------------->
[Sent within messaging association]
GIST(Header(Type=Confirm; NSLPID=NSLP2; C=0; R=0; S=1)
MRI(MRM=Path-Coupled; Flow=F; Direction=down)
SessionID(0x1234) NLI(Peer='string1'; IA=IP#B)
ResponderCookie(0xacdefedcdfaeeeded)
StackProposal(#Proposals=3; 1=TCP; 2=SCTP; 3=TLS/TCP)
StackConfigurationData(HoldTime=300))
Figure 12: GIST Handshake Message Sequence
図12：GISTハンドシェイクメッセージシーケンス
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク州ニューヨーク10027米国
Phone: +1 212 939 7042
EMail: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Robert Hancock Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
ロバート・ハンコック・ローク・マナー研究古いソールズベリー・レーン・ロンシー、ハンプシャーSO51 0ZN UK
EMail: robert.hancock@roke.co.uk
URI: http://www.roke.co.uk