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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]ではなく代替。パス上のすべてのノードが参加する必要はありませんが、二つ以上の参加者が、パス結合シグナルのセッションではほとんど常にあります。確かに、GISTおよび任意のシグナリングアプリケーションのサポートは、パフォーマンスコストを課し、およびフローレベルシグナリングの展開は、コアルータよりも、エッジデバイスに多くの可能性が高いです。 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
すべてのシグナリングアプリケーションは、データ経路に沿ってメッセージを交換する状態管理ルールのセット、ならびにプロトコルのサポートを必要とします。このプロトコルのサポートのいくつかの側面は、すべてまたはシグナリング多数のアプリケーションに共通であるので、一般的なプロトコルとして開発することができます。 [29]で与えられたNSISフレームワークが共通とアプリケーション固有のプロトコルとの間の機能分割のための根拠を提供し、前者アウトライン要件を与え、NSISトランスポート層プロトコル（NTLP）。 GISTプロトコル設計のいくつかの側面があるように、フレームワーク内のいくつかの概念は、RSVP [14]から誘導されます。アプリケーション固有のプロトコルはNSISシグナリング層プロトコル（NSLPs）と呼ばれ、別の文書で定義されています。 NSISフレームワーク[29]および添付の脅威ドキュメント[30]は、重要な背景を提供します
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.
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節では、プロトコル設計原理及び動作の非公式の概要を示します。規範的仕様は、第8部4に主セクション4に含まれ、そのフォーマット及びコンテンツメッセージシーケンス及び第5節を記述する。いくつかのより高度なプロトコルの機能について説明し、セキュリティ上の考慮事項がまた、セクション8に含まれている詳細なビット・フォーマットは付録Aに記載されているプロトコル動作は第6セクション7で状態機械の形で捕捉されることに留意されたい、付録B GISTは、シグナリングアプリケーションに提供するサービスの抽象APIを説明し、付録Dは、例示的メッセージフローを提供します。 IPオプションを持つGISTのデザイン使用パケットの部分は、IPv4の場合には、いくつかの移行の問題につながるネットワークをプローブするように、これらは、付録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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
[隣接]ピア：シグナリングパスに沿って次のノード、上流又は下流方向に、GISTノードが明示的に相互作用します。
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.
応答ノード：クエリノードに隣接ピアになって、シェイクに応答GISTノード。
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メッセージを送信するモード。データグラムモードは、どちらかのフロー定義から派生元と送信先の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ピアであるかを決定する方法を記載しています。流路に沿ってシグナリングするため、メッセージのルーティングは、通常のIPルーティングの上に構築されGISTによって行わ、それは、その宛先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ピア）の各方向に沿って隣接する信号ノードに到達し、必要に応じて明示的にアドレス指定およびそのピアに関する識別情報を確立する方法を決定します。
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.
ノードが明示的にGISTピアのアイデンティティを決定するために、ローカルルーティング状態情報を使用するためのルーティングの要件を満たすために、一つの可能性です。 GISTは、シグナリングアプリケーションは、データを交換することができ、その間、隣接するピア間で必要なルーティング状態を設定するためにネットワークをプローブスリーウェイハンドシェイクを定義します。ルーティングの決定がなされた後、ノードは、ピアへのメッセージを搬送するための機構を選択しなければなりません。 GISTは困難な場合のために十分に理解トランスポートプロトコルを使用して、二つの部分、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のための層状構造につながります。基本的な考え方は、図中の図によって暗黙のトランスポートとセキュリティプロトコルのすべての組み合わせは、GISTでの使用のために実際に可能ではありません。2.注意を示しています。この仕様で許可された実際の組み合わせは、5.7節で定義されています。また、この図は、さらに4.1節で述べた抽象インタフェース、GISTのAPI、で上位層にサービスを提供するGISTを示しています。
^^ +-------------+
|| | 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.
データグラムモード（Dモード）：控えめな遅延制約なしセキュリティ要件を持つ小さな、不定期メッセージに使用されます。 Dモードの特別な場合には、ルーティングの状態が存在しない場合に使用されるクエリモード（Qモード）と呼ばれます。
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モードは、ピア間で維持されるメッセージごとの共有状態を必要としない適切な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つのモードを混在させることも可能です。これは、例えば、コアに向かってネットワークとCモードのエッジでDモードの使用を可能にします。共有セキュリティアソシエーションと転送接続が複数のフローおよびシグナリングアプリケーションのためのメッセージのために使用されることを可能にしながら、そのような組み合わせは、モバイルエンドポイントの動作をより効率的にすることができます。これらのプロトコルの設定は、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モードで最初にスリーウェイハンドシェイクを実行し、それらがまだ存在しない場合、必要な接続を設定します。また、シグナリングアプリケーションを直接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を選択します。が通常の場合は、0または1であるが、2つのGISTピア間のMAの任意の数であってもよく、それらは設定および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における機能ルーティングベースラインメッセージは、シグナリングメッセージは、それが通過するノードのサブセットを訪問し、ネットワーク内の既存のフローによって定義された経路をたどることです。これは、シグナリングの目的は、そのフローのためのリソースを操作することであるアプリケーションシナリオのための適切な行動です。しかし、他の行動が適用されるシナリオがあります。二つの例は以下のとおりです。
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アドレス予約場合の第二（「ルーズエンド」）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.
隣接ピアを発見するためにネットワークをプローブメッセージのIPレベルでのカプセル化の仕様O。下流カプセル化が定義されなければなりません。上流のカプセル化は任意です。パス結合MRMのために、この情報は、セクション5.8.1.2および5.8.1.3節に記載されています。現在のMRMは、データプレーン内のプローブ・メッセージの傍受に依存しているが、他の機構が、全体的な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.
経路変更検出、MRMが発見ネイバー関係で、すなわち、任意の変更のために利用可能な機構（S）O。任意の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メッセージ（7.2.2項を参照）で運ばMRIオブジェクト内のフィールドの翻訳を必要とするかもしれないことに留意すべきです。一般的なMRIフォーマットは、翻訳のいくつかの種類が必要であるかどうかを示すために、MRM定義の一部として与えられなければならないフラグを含みます。新しいMRMの開発は、したがって、GIST仕様への更新を含み、NAT振る舞いの仕様への更新を含むことができます。ベースGIST仕様のMRMのためのNATトラバーサルの場合のように、セクション7.2.3に記載したように、これらの更新は、別の文書で行うことができる[44]。
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の間で明示的に渡されます。そのため、シグナリングのアプリケーションの仕様は、彼らが必要とするのMRM定義する必要があります。シグナリングアプリケーションは、パケット分類における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.
クエリ、応答、確認して、データ、エラー、およびMA-こんにちは：GISTは、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.
クエリ、応答、およびConfirmメッセージは、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メッセージは、メッセージング関連プロトコルのための診断およびキープアライブとして使用することができます。
Peering is the process whereby two GIST nodes create message routing states that point to each other.
ピアリングは、二つの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.
ピアリング関係はGISTハンドシェークによって作成することができます。 1クエリを発行し、他からの応答を取得するときにノードは、ピアになります。最初のクエリを発行すると、そのノード上のNSLP要求の結果であり、クエリ自体は、メッセージルーティング方法のルールに従ってフォーマットされます。現在のMRMのために、応答ノードのアイデンティティは、クエリが送信された時点で明示的に知られていません。一つは、それによってピアになって、応答を送信することを決定するまで代わりに、メッセージは、パスに沿ったノードによって検査されます。ノードはNSLP、ローカルGISTおよびピアするかどうかを決定するアプリケーションポリシーシグナリングをホストしている場合。詳細は4.3.2項に記載されています。ノードは、透過的に（セクション4.3.4）を前方NSLPクエリをホストしていません。 GIST非対応ノードが通常のデータパケットとしてクエリを参照し、そう前方に透過 - Queryメッセージ（セクション5.3.2を参照）の設計は、ノードがオプトインするために特異的にメッセージのインターセプトを実行しなければならないようなものであることに注意してください。
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.
既存のピアリング関係は、新しいGISTハンドシェークによって変更することができます。ルーティングの状態が更新されたとき、他の言葉で、それだけで変更することができます。オリジナルのピアリングプロセスの要因のいずれかが変更されている場合はリフレッシュには、ピアリング関係も変更することができます。同様にネットワーク・レベルの再ルーティングとして、変更は、アプリケーションポリシーをシグナリングする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とは何の関係もないパケットのためのインターネットの透明性を壊しているので、（クエリモードまたはQモードと呼ばれる）、この場合にGISTで使用されるカプセル化は、他のトラフィックとの偶発的衝突を避けるために、いくつかの機能があります。
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は変更されずに保存されています。通常、NSLPs全体シグナリング経路に沿っSID値が保持されますが、これはによって強制のみ隣接NSLPピア間の単一のホップとしてSIDの範囲を見GIST、にも見えません。
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つ以上のフローのためのメッセージは、例えば、同一の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は、不透明な128ビットの識別子としてSIDの構文を定義します。
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.
同じGISTピア間で確実に送達される同じSIDを持つOメッセージは順番に配信されます。
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を参照）があります。このような攻撃は、トラフィックをリダイレクトしないだろうが、シグナリングを再ルーティングします。代わりに、ルーティングの状態はまた、対応する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シグナリング層プロトコル（NSLPs）によってサポートされています。各NSLPは、IANA（セクション9）によって割り当てられた16ビットNSLP識別子（NSLPID）によって識別されます。単一のシグナリング・アプリケーションは、そのようなリソース予約として、階層内の異なるレベルで操作をシグナリング実行するために、例えば、その機能を実現するためにNSLPsのファミリを定義することができる（参照[21]）。しかし、異なるNSLPs間の相互作用は、（例えば、リソース管理の場合に集約レベルまたは凝集領域の境界を関連付けるために）シグナリングアプリケーション・レベルで処理されます。 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.
シグナリングアプリケーションにNSLPメッセージのための安全な輸送を提供するために、O。
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、主に内部です。彼らは、クッキー交換を含めると状態をルーティング設定握手を保護するためにルータビリティチェックを返すと、ランダム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:
保護の第二のレベルは、メッセージング・アソシエーション（即ち、Cモード内）におけるチャネルセキュリティプロトコルを使用することによって提供されます。このメカニズムは、2つの目的があります：GIST上のパス攻撃から保護し、NSLPメッセージのセキュアなチャネルを提供します。メカニズムが有効であるためには、以下の機能を提供することができなければなりません。
o mutual authentication of the GIST peer nodes;
GISTピア・ノードの相互認証がOであり;
o ability to verify the authenticated identity against a database of nodes authorised to take part in GIST signalling;
O GISTシグナリングに参加することを許可ノードのデータベースに対して認証されたアイデンティティを検証する能力。
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は、これらの機能（例えば、認証および同一性比較）がGIST操作の残りの部分と一体化されている方法のTLS-特定の側面を画定します。ハイレベルで、同様の機能を持ついくつかの代替のプロトコルがあり、ハンドシェイク（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-フリーで）比較的単純でGISTの使用例を示します。
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は、ローカルシグナリングアプリケーションからの要求によってトリガされます。ここでの例では、2つの隣接ピア間のどのGIST転送メッセージ経路に沿ってある距離を説明し、GN1およびGN2（図3参照）。私たちは、メッセージがGN1でシグナリングアプリケーションによってGIST層の上に処理されている時点での話を取り上げます。
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したがって、メッセージング・アソシエーションを開始するために使用されるGISTレベルでGISTのNSLPペイロードを運ぶ問い合わせ、および追加のペイロードを構築します。クエリは、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非対応のルータがRAO値を認識せず、そのままメッセージを転送します。彼らは最初の傍受した後、これを決定するために、メッセージの多くを処理する必要があるかもしれないが、問題のNSLPをサポートしていないGIST対応のルータはまた、基本的には変わらないメッセージを転送します。
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.
前記メッセージは、GN2でインターセプトされます。 GIST層はローカルシグナリングアプリケーションに関連するようにメッセージを識別し、上向きにそれにNSLPペイロードおよびフロー記述を渡します。 GN2におけるこのシグナリングアプリケーションはGN1とピアであろうとそうGISTは、任意のルーティング状態を設定するために進むべきであるGISTに示します。また、シグナリングアプリケーションは、それがさらに下流送信され、これは最終的にフロー受信機に到達するメッセージが表示されるように、GISTに戻ってダウンメッセージを渡す（ステップ1を比較）GN1のようにメッセージを処理し続けます。 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.は、GN2にGISTインスタンスは、今ではGN1とシグナリング将来のルーティング状態とメッセージの関連付けを維持しなければならないことを知っています。メッセージがクエリであるため、およびローカルシグナリングアプリケーションがGN1とピアであろうことを示しているので、これが認識されています。必要なGISTのレスポンスを返送するための2つの可能なケースがあります。
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.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は自身を識別し、メッセージング関連の設定に同意し、GN1に直接D-モードでレスポンスを送信します。これを完了するために必要なプロトコル交換は、次の段階と並行して進めてまいります。
In each case, the result is that GN1 and GN2 are now in a peering relationship for the flow.
それぞれの場合において、結果は、GN2 GN1とは、フローのためのピアリング関係になっていることです。
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層はGN1としてこのフロー及びNSLPのための上流のピアを識別し、それは適切な特性を有する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.
このセクションでは、GISTの基本的な構造および動作を定義します。セクション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-及び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:
メッセージ転送属性は、メッセージ処理の必要最小限のレベルを定義するためにNSLPsによって使用されます。次のように使用可能な属性は以下のとおりです。
Reliability: This attribute may be 'true' or 'false'. When 'true', the following rules apply:
信頼性：この属性は、「true」または「false」かもしれません。ときに「真」、次の規則が適用されます。
* 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」に、メッセージが配信される場合は、一度、数回、または全くない、これらの例いずれにもエラー表示と。
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.
この属性はまた、リターン・ルータビリティ・チェックが行われたかどうかなど、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].
実際には、SIDのインデックスルーティング状態は、（下記のセクション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:
各フローに対して、GIST層は、送信メッセージの処理を管理するための状態メッセージルーティングを維持することができます。この状態は、概念的に次のような構造を持つテーブルに編成されます。表の各行は、次の3つの項目のユニークな組み合わせに対応します。
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.
メッセージルーティング情報（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節を参照してください。この識別子を含めることは、ルーティング状態が異なるNSLPsに異なることを可能にします。
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つのテーブル内のエントリ、上流及び下流のMRIに1つずつ存在することになります。ルーティング状態は、ピア・アイデンティティ（セクション4.4.3を参照）、およびDモード用UDPポート番号、またはCモードのための1つ以上のMAへの参照情報を含みます。ルーティング状態テーブルのエントリは、4.4節でより詳細に記載されてGISTハンドシェークによって作成されます。
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:
フロー毎のメッセージルーティング状態はGISTによって記憶されただけの状態ではありません。 MAを管理するために必要な状態もあります。これらごとの流れはないので、それらは以下あたり-MA情報を含むルーティング状態、別に格納されています。
o a queue of any messages that require the use of an MA, pending transmission while the MA is being established;
MAが確立されている間、送信を保留し、MAの使用を必要とするメッセージのキューO。
o the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5).
ピア・オープンMAを保つためにその願望を再述べているので、時間O（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層に直接処理される場合を説明します。概要このセクションでは、完全なIPの詳細は、セクション5.3および5.4でトランスポート層カプセル化、GISTレベルの処理に集中し、図4に示されています。
+---------------------------------------------------------+
| >> 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
NNNNNNNNNNNNNN =ノーマルDモードメッセージQモードカプセル化xxxxxxxxxxxxxx = CモードメッセージRAO =ルータ警告オプションであるQQQQQQQQQQQQQQ = Dモードメッセージ
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モードのカプセル化：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.
いくつかの異なるRAO値はNSISプロトコルスイートによって使用されてもよいです。 GIST自体は、（IPv4またはIPv6のいずれかのために）任意RAO値を割り当てません。割り当ては、Qモードのカプセル化でRAOを使用するのMRMを使用して、各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のホップ数がチェックされます。ゼロのGISTホップカウントを有する任意のメッセージは、エラー・メッセージ（付録A.4.4.2）「を限界を超えホップ」で拒否されなければなりません。正しいGISTの実装はゼロのGISTのホップ数でメッセージを送信することはありませんのでご注意。それ以外の場合は、GISTのホップ数は、次の段階の前に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で説明したように、メッセージルーティング状態を設定するためのハンドシェイクプロセスを続行しなければなりません。アプリケーションは、GISTはレスポンスに転送されます同じNSLPID、のためのNSLPペイロードを提供することができます。
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項で説明した場合と同様にクエリを伝搬しなければなりません。何のメッセージは照会ノードに戻って送信されません。アプリケーションは、GISTによって転送クエリで使用される同じNSLPID、のために更新NSLPペイロードを提供することができます。最後にクエリを処理するノードは、エラーメッセージを返す場合、これは任意のフォワーダをバイパスして、元のノードに直接送り返されることに注意してください。これらの診断は有意義であるために、任意のGISTノードは、クエリを転送し、または改変NSLPペイロードとそれを中継、GISTホップカウントを除いて変更してはいけません。特に、それは他の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:
メッセージはNSLPペイロードを含む場合クエリ以外の全てのGISTメッセージタイプのために、これはNSLPIDによって識別シグナリングアプリケーションに局所的に送達されなければなりません。ペイロードの形式は、GISTによって制約されず、コンテンツは解釈されません。送達は、所定のシーケンスに適用されなければならない次の検証チェックの対象です。
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;
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);
メッセージはメッセージで与えられたMRI / NSLPID / SIDの組み合わせに関連付けられていない関連に到着した場合、他の2は、メッセージが「間違って配信されるメッセージ」のエラーメッセージを拒絶しなければなりません（付録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);
このMRI / SID / NSLPIDの組み合わせのためのルーティング状態が存在しない場合は他の3は、メッセージのいずれかドロップしなければならないか、またはエラーメッセージ（詳細については、セクション4.4.6を参照）と拒否されます。
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、着信ホップカウントを提供します。これは、より洗練された何かを定義していないNSLPsための軽量ループ制御メカニズムを提供します。カウントは、すべてのGIST認識ノードを介して転送するにデクリメントされることに注意してください。 GISTのホップ数の初期値は、実装上の問題です。一つの適切なアプローチは、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トランスポート層カプセル化のための手当を含む）は、そのサイズのメッセージがフラグメンテーション関連閾値はCモードを介して送信されなければならない超え、内部断片化と再構築をサポートし、メッセージングの関連付けを使用して。 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輻輳制御：ネットワークはGISTによって課されたレート制御限界内にDモードトラフィックの容量を保証するように操作することができない限り、Dモードでは、ルーティング状態を設定し、Cモードを使用することが可能である場合、シグナリングは使用しないでください（セクション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モード）が選択された場合に、メッセージがルーティング状態テーブルから求めアソシエーションにキューイングされ、さらに出力処理は、使用されるプロトコルスタックの内容に応じて行われます。いかなる適切な関連付けが存在しない場合は、1つが作成されている間、メッセージがキューイングされ、追加のGISTメッセージの交換をトリガする、（セクション4.4.1を参照）。全く関連が作成できない場合、これはエラー状態であり、バックローカルシグナリングアプリケーションに指示されるべきです。
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.
メッセージは、クエリではなく、ローカルポリシーは、このメッセージのQモードの使用を要求しない、およびルーティング状態が存在する場合は、O、それがルーティング状態テーブルからアドレスに直接ノーマル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モードのカプセル化データメッセージを送信するか（セクション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. A Qモードカプセル化されたメッセージは、いくつかの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. A Qモードカプセル化されたメッセージがこのノードで使用される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. Aは、直接該当するシグナリングアプリケーションが存在しないいるノードに配信される（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. A Qモードカプセル化されたメッセージは、シグナリングアプリケーションを処理しないエンドシステムに到着します。これは、通常の操作で可能であり、「エンドポイントの発見」情報メッセージ（付録A.4.4.7）で送信者に示さなければなりません。エンドシステムは、それらを解釈せずにエラーメッセージにおける元のメッセージからMRIおよびSIDを含みます。
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層のTTLがちょうどメッセージはIPパケットを転送正常であったかのように減らさなければならないということです。ケース（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-modeは、MRIのすべての内容だけでなく、IP宛先アドレスに基づいてルーティング決定を行う必要があり、このようにメッセージをカプセル化。また、エラーメッセージを返す健全性チェックのと、一定の条件の下で制限されたセットを適用するのではなく、メッセージを転送することができます。これらの条件は以下のとおりです。
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）は、メッセージング関連のセットアップを開始しなければならない差出人に戻されるべきである（SHOULD）。
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のホップカウントがゼロに達しています。エラー「超過ホップリミット」（付録A.4.4.2）は、より大きな初期のホップ数を再試行するかもしれ差出人に戻されるべきである（SHOULD）。
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.
前記MRIは、一意のパスに沿って転送されるにはあまりにも一般的であるフロー定義を表す（例えば、宛先アドレスプレフィックスが短すぎます）。サブコード0（「MRIあまりにもワイルド」）とのエラー「MRI検証失敗」（付録A.4.4.12）は、制限されたMRIのでリトライ可能性がそうするように、追加のシグナリングセッションを開始するかもしれ差出人に戻されるべきである（SHOULD）。 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メッセージの唯一の共通ヘッダが検査されます。第三の場合には、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ペイロードを含むかもしれました。それはまた、クエリクッキー、およびメッセージング関連プロトコルスタックについて必要に応じて能力情報を含みます。この中に、クッキー、後でメッセージの役割は、（詳細については、セクション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.
ピアアドレス情報が利用可能であり、新しいメッセージング関連付けが実際に必要になったときに新しいメッセージング関連のセットアップが開始されます。任意の設定が使用されるアドレス指定情報は限られた寿命を有することができるので、それは限られた寿命のNATバインディングに依存していずれかであるため、特定のクエリ/レスポンス交換した直後に行わたりしなければならない、それはトランスポートプロトコルのためのアジャイル宛先ポートを参照しているため。メッセージング関連プロトコルを使用することができるかについての交換キャリー能力情報、およびこれらのオブジェクトの処理に運ばスタック-提案とスタック・コンフィギュレーション・データオブジェクトは、5.7節でより詳細に記載されています。プロトコルオプションは、現在定義されていると、より柔軟な構成が全体的にGISTの設計内で可能であるものの、メッセージング関連の設定は常に、照会ノードから開始します。メッセージング・アソシエーションは、チャネルセキュリティプロトコルが含まれている場合、各GISTノードは、その認可ピアデータベースに対してピアの認証IDを確認しなければならない、と一致しない場合、メッセージング関連は解体されなければなりません。データベースおよび承認チェックは、以下の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
任意の必要なメッセージング関連のセットアップが完了した後に応答がそれを要求した場合は最後に、確認を送らなければなりません。確認が送信された後、クエリノードは、ルーティング状態をレスポンダに設置されていることを前提とし、当該フローのための通常のデータメッセージを送信することができます。失われたことを確認からの回復は、セクション5.3.3で説明されています。メッセージングの関連付けが使用されている場合、確認は同じ流れのための任意の他のメッセージの前に、それを介して送らなければなりません、そして、それはレスポンスからレスポンダ-Cookieとスタック・提案をエコーします。前者は（セクション8.5を参照）受信機は、メッセージの内容を検証できるようにするために使用され、後者は（セクション8.6を参照）、メッセージング関連のセキュリティ上のある入札ダウン攻撃を防ぐためです。新しい上のこの最初の確認
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.
協会はまた、元のクエリで指定された値より優先さ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-ノードネットワークレイヤ情報由来のレスポンダアドレスを、インストールする必要があります。応答ノードは、2つの時点でのピア状態情報として照会アドレスをインストールすることができます。
Case 1: after the receipt of the initial Query, or
ケース1：最初のクエリ、または受領後
Case 2: after a Confirm containing the Responder-Cookie.
ケース2：レスポンダ-クッキーを含むことを確認した後。
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認定ピアがtransport-とアプリケーションレベルのフロー制御ルールに従うように信頼され、過負荷状況を作成しようとしません。
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の管理と正常に反対ピアのIDを検証の結果のための唯一の要件を定義します。
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のエントリは、アドレスの所有者としてのアイデンティティを表します。認可ノードは、（例えば、自身のルーティングテーブルのような）ローカル情報からこのアドレスを決定することができる場合は、このエントリに一致すると、ピアが正しいオンパスのノードであるので、許可されるべきであることを示しています。 IPアドレスが、ルータの転送テーブルから誘導することができるので、ピアは、ある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.
同じIDを複数のエントリに表示されること、およびAPDのエントリの順序は重要です。メッセージング・アソシエーションが認証され、MRIに関連付けられている場合、許可ノードが同一のピアによって提示されたものと一致する最初のエントリを見つけるために、APDをスキャンし、スコープ情報MAが設定されている状況と一致する場合。アイデンティティマッチング処理自体は、認証を行い、TLSの詳細は、セクション5.7.3に記載されているメッセージング・アソシエーションプロトコルに依存します。特定範囲の可能なピアのフルセットが既知であるときはいつでも、エントリが未知のノードからのシグナリングアソシエーションを拒否するためにワイルドカード識別のために添加されるべきである拒否する。不適切のMAを除去する認可ノードの能力は、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は通常通り使用することができます。それ以外の場合は、さらにGIST交換せずに解体されなければならない、そしてMAに関連する任意のルーティング状態も削除しなければなりません。エラー状態をローカルに記録されることがあります。 APDエントリが変更または削除された場合、ノードは、再検証APDの改訂内容に対して既存のMAおよびルーティング状態テーブルをしなければなりません。これはのMAをもたらす可能性が取り壊されているまたはルーティング状態のエントリが削除されます。これらの変更はNetworkNotification 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アドレスを関連付けるなど）。外部の宛先へのシグナリングパス上にあることが許可されるよう企業ネットワークオペレータは、その境界ノードのすべてのIDのリストを生成することができ、これは、ネットワーク内のすべてのホストに配布することができます。かかわらず、技術のは、ソース・データは、このセクションの最初に記載されている許可の決定を正当化していること、および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の設計目標です。既存のMAのこの再利用は、メッセージング関連の多重化と呼ばれています。多重化は、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.
ピア・アイデンティティ：所与のノードの場合、これは、不透明な構文とのインターフェースに依存しない値です。これは、すべての潜在的なピアのセットにわたって一意性の高い確率を有するように選択されなければならない、少なくとも次のノードの再起動まで安定であるべきです。このアイデンティティのない暗号保護がないことに注意してください。これを提供しようとすると、基本的に、メッセージング関連のセキュリティプロトコルでの機能を複製します。ルータは、ルータ-ID [2]、ルータのIPアドレスの一つである、ピア・アイデンティティのための1つの可能な値として使用することができます。ネストされたNATを有するシナリオでは、ルータ-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.
メッセージング・アソシエーションは、アソシエーションが最初にセットアップされた時点で確認/クエリ/応答にピアによって提供された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つの可能性は、実際にあります。
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の背後に新しいピアです。新しいアソシエーションの設定が必要です。
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.
NLIオブジェクト一致4.両方の要素：これは異なる特性との関連付けを作成するために、一つのノードが既存のピアを認識したが、オプションは、例えば、いずれの場合にも新たな関連付けを設定できるようにしたい縮退場合、あります。
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レベルでのメカニズムはありません。シグナリングセッションがアクティブであることが知られている場合は、どちらかの上流の状態の期限が切れたため、またはシグナリングアプリケーションは、状態がもはや必要とされていること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]).
制御トラフィック（参照[42]）のネットワーク同期を回避する必要O。
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:
不要のMAは、例えば、単にTCP接続を閉じることにより、利用可能な場合、基礎となるトランスポートまたはセキュリティプロトコルのティアダウンのメカニズムを使用して、GISTによって取り壊されます。ティアダウンは、どちらかの端で開始することができます。 MAが必要とされているかどうかは、二つの要因の組み合わせです：
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.
ピアはまだMAが所定の位置に残っているしたいかどうか、O。 MAのセットアップ時には、スタック・コンフィギュレーション・データの一部として、各ノードは、自身のMA-ホールドタイムをアドバタイズし、すなわち、それは、シグナリングトラフィックを伝送していませんMAを保持する時間。それはその期間にわたりそのピアからのトラフィックを受信した場合のノードはMAを取り壊すてはなりません。トラフィックを生成しませんが、それでもMAは事実を示すために、特別なヌルメッセージ（MA-こんにちは）を使用することができます保持したいと考えていましたピア。 30秒のMA-ホールドタイムのデフォルト値が推奨されます。ノードは、より迅速なピア障害検出を実現するために短い時間を使用しますが、考慮にMA-Helloメッセージによって作成されたネットワークの負荷を取る必要があるかもしれません。ノードは、長い時間を使用していますが、考慮に長時間アイドルのMAを保持するコストを取る必要があるかもしれません。ノードは、適切な値を選択する際に考慮に（例えば、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-こんにちは要求を使用し、その上に送信されたメッセージがピアに到達していることを確認するために、既存の関連に交換を応答することができます。 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]).
制御トラフィック（参照[42]）のネットワーク同期を回避する必要O。
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:
状態が要求されているが存在しない場合の確認、又はデータ・メッセージの場合には、ノードが「Noルーティング状態」エラーメッセージ（付録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.
ルーティング状態のマッチングがSIDを含むので、これは上の経路に主に限られているが照会または応答ノードにおけるルールは、TCP（参照[46]）に対する攻撃をリセットブラインドに似ランダムに注入したエラーメッセージによって中断にGISTがオープンします攻撃者。 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で高いレベルでの様々なGISTメッセージとその内容を説明[11]。ヘッダの詳細な説明および各オブジェクトはGISTのNATトラバーサル機構は、クエリ応答に追加のNATトラバーサル・オブジェクトの挿入を含むこと付録A注セクション5.2ビット形式で与えられ、そしていくつかのデータであり、及びエラーメッセージ。このための規則は、セクション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.
GIST-メッセージ：主なメッセージは、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を含みます。それはまた、ある種の応答が要求されているかどうかを示すために、1つ（Rフラグ）を含む、ループ無限メッセージおよび種々の制御フラグを防止するために、ホップカウントを運びます。共通ヘッダ次のオブジェクトは、メッセージのタイプに応じて、決まった順序で実行されなければなりません。メッセージタイプの欠落しているとのメッセージ、複製、または無効なオブジェクトは適切なサブコード（付録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-フラグは常に、クエリ中（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モードの応答に関与しなければならない新しいメッセージング関連の設定に関連する場合、レスポンダ-cookieが含まれ、同様にレスポンダ独自のスタックの提案およびコンフィギュレーションデータでなければなりません。レスポンダクッキーが存在するが、そうでなければ任意である場合にR-フラグ（R = 1）に設定されなければなりません。 Rフラグが設定されている場合、確認は、返信として送信されなければなりません。新しい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を含み、応答が1つを行った場合レスポンダクッキーをエコーしなければなりません。 Cモードでは、確認はまた、応答（存在する場合）からスタックの提案をエコーしなければならないので、これは改ざんされていないことを検証することができます。新しいアソシエーションの最初の確認もちょうどMA-ホールドタイムを含む、短縮形で元のクエリからのスタック・コンフィギュレーション・データを繰り返す必要があります。
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
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-データペイロードに報告され、GISTによって特別に処理されていない。）メッセージがDモードで送信されている場合、エラーメッセージの発信者は、自身のネットワークレイヤ情報オブジェクトを含まなければなりません。エラーに関連する他のすべての情報は、GIST、エラー・データオブジェクトで運ばれます。
Error = 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-こんにちは：このメッセージはCモードで送らなければなりません。これは、ゼロのNSLPID、及びメッセージ識別子、ハロー-IDと、共通ヘッダを含んでいます。それは、常にノードがオープンメッセージングの関連付けを維持するために望んでいることを示し、R = 0とゼロのHello-IDを使用して送信される場合、これはその唯一の機能です。ノードはまた、R = 1を設定し、非ゼロのHello-IDを提供することにより、交換を返信/診断要求を呼び出すことができます。この場合には、ピアが同じハロー-IDをエコーメッセージング関連沿っ及びR = 0とバック別のMA-ハローを送らなければなりません。この診断の使用は、完全に開始ノードの裁量です。
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.
このセクションでは、各GISTメッセージ、両方の共通ヘッダと個々のTLVで存在することができる様々なオブジェクトの内容を記述する。ビットフォーマットは、付録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ホップ数：ホップ数が無限にループからのメッセージを防止することができます。
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-フラグはクエリメッセージのため、また、Qモードで送信されたデータメッセージのために設定しなければなりません。 Cフラグは、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.
ソースアドレッシングモード：設定した場合は（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).
明示的ルーティング：設定されている場合、フラグ（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.
Dモード、セクション5.3で、ヘッダの前に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).
共通ヘッダに続くすべてのデータは、タイプレングス値オブジェクトのシーケンスとして符号化されます。現在、各オブジェクトは、最も一度に発生する可能性があります。必要と許可オブジェクトのセットは、メッセージタイプおよびカプセル化（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
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.
セッション識別子（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
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.
インターフェイスアドレス、すなわち、DモードまたはCモードにするかどうか、バックシグナリングメッセージを生成するノードに送信するパケットの宛先IPアドレスとして使用していなければなりません、ルーティング可能でなければなりません。このオブジェクトはソースアドレッシングモードフラグS = 1のメッセージで運ばれている場合、インターフェイスアドレスは、レガシーNAT検出（7.2.1項）を支援するために、IPカプセル化に使用される送信元アドレスと一致しなければなりません。このオブジェクトがクエリで運ばまたは確認された場合、インターフェイスアドレスは、具体的には、セクション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ホップ・カウント・ツー・ピアとしての上流ピアの差が記憶されていますそのフローの状態テーブルをルーティングします。それ以外の場合は、フィールドは無視されます。
* 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ホップ・ツー・ピア・カウント、または0の値に設定しなければなりません。
* On receiving an upstream message, the IP-TTL is stored as the IP-hop-count-to-peer for the downstream peer.
*上流のメッセージを受信すると、IP-TTLはIPホップ・カウント・ツー・ピアとして下流ピアのために記憶されます。
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.
スタック提案：このフィールドは、トランスポートとセキュリティプロトコルの組み合わせは、メッセージング団体での使用に利用可能であるかについての情報が含まれており、また、5.7節で詳しく説明されています。
Stack-Proposal = 1*stack-profile
スタック-提案= 1 *スタックのプロフィール
stack-profile = protocol-count 1*protocol-layer ;; padded on the right with 0 to 32-bit boundary
スタック・プロファイル=プロトコルカウント1 *プロトコル層;; 0から32ビット境界と右側に埋め
protocol-count = %x01-FF ;; number of the following <protocol-layer>, ;; represented as one byte. This doesn't include ;; padding.
プロトコルカウント=％X01-FF ;;次の<プロトコル層>の数、;; 1つのバイトとして表現。これは含まれていません;;パディング。
protocol-layer = %x01-FF
プロトコル層=％の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).
各プロトコルレイヤのフィールドは、一意のタグ付きプロトコルを識別する。このようなアドレッシング上位層またはプロトコルに関連する他のオプションデータとして任意の追加データは、（下記参照）スタック構成 - データTLVでMA-プロトコル・オプション・フィールドで運ばれます。
Stack-Configuration-Data (SCD): This object carries information about the overall configuration of a messaging association.
スタックの構成 - データ（SCD）：このオブジェクトは、メッセージング関連の全体構成についての情報を運びます。
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-ホールドタイムフィールドは、ノードが非アクティブアソシエーションを開く保持する期間を示し;より多くの議論については、セクション4.4.5を参照してください。 MA-プロトコルオプションフィールドは、プロトコルの構成（例えば、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.
クエリクッキー/レスポンダクッキー：クッキークエリは、クエリに含まれ、それに応答してエコーされなければなりません。レスポンダ-クッキーは応答で送信され、存在する場合は、以下の確認にエコーされなければなりません。クッキーは、クッキー発生器によって選択された可変長ビット列です。クッキーの生成のための要件とメカニズムの詳細については、セクション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.
ハロー-ID：こんにちは-IDは、MA-ハローリクエスト/応答交換にメッセージを相関させるために使用される32ビット量です。非ゼロ値は、要求（R = 1で送信されるメッセージ）で使用されなければならないと同じ値（R = 0を有する）応答で返さなければなりません。値ゼロは、他のすべてのメッセージに使用されなければなりません。メッセージは、R = 1、こんにちは-ID = 0、サブコード1（「サポートされていない値」）と「オブジェクトの値エラー」メッセージ（付録A.4.4.10）で受信された場合に返され、メッセージを下げなければなりません。ノードは、こんにちは-IDを生成するために、任意のアルゴリズムを使用することができます。適切なアプローチは、ランダムな出発点とローカルシーケンス番号です。
NSLP-Data: The NSLP payload to be delivered to the signalling application. GIST does not interpret the payload content.
NSLP-データ：NSLPペイロードは、シグナリングアプリケーションに配信されます。 GISTは、ペイロードの内容を解釈することはありません。
GIST-Error-Data: This contains the information to report the cause and context of an error.
GIST-エラー・データ：これは、エラーの原因と状況を報告するための情報が含まれています。
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に与えられています。一般的な誤りヘッダは、元のメッセージから共通ヘッダを運び、それらが正常に復号された場合、メッセージルーティング-情報（MRI）の内容とセッション識別子（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ペイロードは常に値と32ビットのマジックナンバーとネットワークバイト順に0x4e04 bda5を開始しなければなりません。これは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.
メッセージは、ルーティング状態テーブルによって与えられるIPは、隣接ピアに直接アドレス指定されます。メッセージは、クエリに直接応答であるとNOルーティング状態が存在しない場合、宛先アドレスはセクション4.4.1と同じルールを使用して入力メッセージから導出されます。 UDPポート番号は、すなわち、同一の同方向および逆方向のメッセージと交換元および宛先ポート番号を持つメッセージのQueryメッセージ（下記参照）に使用されるものと適合しなければなりません。メッセージは、NATを通過したことが知られているメッセージに対する応答がない限り、通常のカプセル化されたメッセージは、ソースアドレッシングモードフラグS = 1で送信されなければならない、受信機は、所与のインタフェースアドレスと送信元IPアドレスをチェックしなければなりませんNLIでレガシーNAT検出の一環として。両方のメッセージ処理のこれらの態様は、セクション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.
それは、彼らが直接非GISTノードはこれらを無視することが可能であること、逆に、それに対処していない場合であっても効率的にこれらのメッセージを傍受するGISTのノードに対して可能であるQ-モードのカプセル化の本質的な特性でありますスローパスパケット処理の過負荷をせずにメッセージを。この文書では、傍受が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.
現在のMRMはNSLPIDに応じてメッセージを傍受でピアを支援するために、ルータ警告オプション[13]の使用を定義します。 MRMは、RAOの使用を定義する場合、具体的に（下記参照）しないように構成されていない限り、送信側はそれを含まなければなりません。ノードはIP-プロトコル番号のトランスポートヘッダ解析に純粋に基づいて初期傍受の決定を行うことができます。実装は、配送先ごとのプレフィックスごとにQモードパケットにRAOの設定を無効にするオプションを提供してもよい（MAY）。ただし、オプションはデフォルトで無効にされなければならないし、個別に目的地への経路に沿って次の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ヘッダーのないフラグメント（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.
現在のすべてのMRMのために、IPヘッダーは、[8] NSLPIDに応じてメッセージを傍受でピアを支援するために、ルータ警告オプションが与えられます。 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の次ヘッダフィールドを持たなければなりません。
5.3.2.3. Upper Layer Encapsulation and Overall Interception Requirements
5.3.2.3。上位レイヤのカプセル化と全体的な傍受の要件
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モードパケットとして指定することはできません。これは、IPイン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を参照）。一部のMRMのために、どこでもパスに沿ってGISTノードがデータフローの送信元アドレスを偽装送信元アドレスを持つGISTパケットを生成することができることに留意されたいです。そのため、宛先は純粋にアドレス解析に本物のエンドツーエンドのデータから、これらのパケットを区別することはできません。代わりに、ポート分析することによって、このようなGISTパケットを区別することが可能でなければなりません。また、そうするためのメカニズムは、宛先がGIST非対応の場合でも有効でなければなりません。 GISTは、Qモードのカプセル化のための「周知の」宇宙から固定の宛先UDPポートを使用することによって、この問題を解決します。このポートは、GIST非対応のホストに割り当てられるべきではありませんので、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モードのカプセル化のために登録されたものと等しいUDP宛先ポート番号を持つすべてのIP / UDPパケットをフィルタリングすることができるようにする必要があります。これらのパケットは、その後、マジックナンバーをチェックしてGISTのパケットであることがさらに検証する必要があります（5.3.1項を参照してください）。ポートとマジックナンバーの両方の要件を満たすパケットは、さらにGIST Qモードパケットとして処理されます。このGISTマジックナンバーチェックに失敗任意のフィルタリングされたパケットは通常の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モードのパケットについて、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オプションは、その後に生成され、発信Qモードパケットを上使用NSLPと同等のオプションに渡すことができます。彼らは通常、転送された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モードは、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.
応答を受信しないクエリメッセージを再送することができ、再送信は、バイナリ指数バックオフを使用しなければなりません。初期タイマ値は、バックオフプロセスは、T2秒の最大値まで増やすことができT1、です。 T1のデフォルト値は500ミリ秒です。 T1は、クエリと応答ノードの間の往復時間の推定値です。クエリは、ローカルネットワーク内で答えられる必要があることが知られている場合、ノードは、T1の小さい値を使用することができます。 T1は大きく選択することができる、そしてラウンドトリップ時間が大きいこと（このような高レイテンシアクセスリンク上など）が予め分かっている場合、これは推奨されています。 T2のデフォルト値は64 * T1です。クエリが原因で（いずれかの方向に）メッセージ損失または全く到達GISTピアが存在しないため、いずれかの未回答の行くことができることに留意されたいです。したがって、実装は、アプリケーションにエラーフィードバックの迅速に対する信頼性（大T2）（小T2）をトレードオフするかもしれません。 NSLPこのペイロードの有効性のタイムアウトを示している場合、プロセスは、このタイムアウト時間内に終了するように、T2が選択されなければならない（付録B.1を参照）。再送されたクエリは別のクエリ・クッキー値を使用しなければなりません。クエリNSLPデータを搬送する場合、それは、シグナリングアプリケーションに複数回送達されてもよいです。これらのルールは、第1のルーティング状態を作成し、それを更新するものメッセージにも同様に適用されます。すべての場合において、応答は、スプリアス再送を避けるために速やかに送らなければなりません。再送信のいずれかのタイプを生成するノードが受信して、それらのいずれかへの応答に合わせて準備しておく必要があり、ちょうど1最近送信されません。任意の応答を受信したとき、ノードは、その再送処理を終了するべきであるが、それは通常のようにさらに応答を処理し続けなければなりません。
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.
このアルゴリズムは、失われたクエリと応答を処理するのに十分です。失われたことを確認した場合は、より微妙です。応答ノードは、確認が受信されるまでレスポンスを再送する再送タイマーを実行することができます。タイマーは応答と同じバックオフメカニズムとパラメータを使用しなければなりません。悪意のあるクエリによって刺激増幅攻撃の問題は、それが以前に送信されたクエリと一致しない場合に効率的に廃棄する応答を受信するノードを有効にするには、クッキー機構を必要とすることによって処理されます。応答ノードは、ノードが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モードのトラフィックのための基本的なレート制御要件は、意図的に最小限です。シングルレートリミッタは、すべてのインターフェイスとメッセージタイプのために、すべてのトラフィックに適用されます。実装は他の上で1つの優先順位を決定することを選択するかもしれないが、それは、再送信だけでなく、新しいメッセージに適用されます。レート制御はいない転送されたメッセージに、ローカルでのみ生成された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モード・トラフィックとネットワークを飽和しないことを保証するようなサイズにされなければなりません。適切なアプローチは、平均出力レートはノードの最低速インターフェースのごく一部であるように、トークン・バケット・パラメータを制限することです。この割合が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のNagleアルゴリズムを参照）に達したか、タイムアウトが期限切れにされるまで、それらが束に集められます。これは、いくつかの待ち時間のコストで最大の効率を提供します。
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).
同梱の第二のタイプは、常に適切です。 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のメッセージ形式でサポートできることがわかります。 GISTメッセージは、共通ヘッダとのTLVからなる、おそらくはトランスポート層セキュリティ保護を組み込んで、トランスポート・プロトコルで直接行われます。さらに、メッセージは連続的な流れで実施することができます。この仕様は、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.
着信メッセージがDモードで受信された場合、O、エラーは、着信メッセージにNLIオブジェクトからアドレッシング情報を使用して、通常のカプセル化を使用して、Dモードで送信されなければなりません。 NLIが決定できなかった場合はS-フラグは、それに設定されている場合、エラーは、着信メッセージの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をので閉鎖されているため、OR）、エラーがローカルにログに記録します。エラーメッセージの受信機は、エラーオブジェクトに埋め込まれている共通ヘッダからエラーの原因メッセージの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-プロトコル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（特定のプロトコルに依存:) MA-プロトコル・オプション・フィールドのフォーマットをSCDオブジェクトにプロトコルアドレス指定および他の構成情報を搬送します。フォーマットフィールドは、クエリまたは応答中に存在するかどうかに応じて異なっていてもよいです。一部のプロトコルには、対応するMA-プロトコル・オプション・フィールドは、SCDのオブジェクトに発生しません、その場合には、そのような追加データの定義は、必要ありません。
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-プロトコル-IDのシーケンスです。プロファイルは「上から下へ」の順序でプロトコルを示し（例えば、TLS TCP上）。スタック提案は、一般に、それを必要とするスタック提案に記載されている任意のプロトコルのためのMA-プロトコル・オプション・フィールドを運ぶSCDオブジェクトを伴います。 MA-プロトコルオプションフィールドはスタック提案中のプロトコルのすべてのインスタンスに対して、グローバルに適用することができる、またはそれは、特定のインスタンスに適用することとしてタグ付けすることができます。後者のアプローチは、例えば、それがまたは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-プロトコルオプションフィールドも使用できないとしてフラグを立てることができます。例えば、SCTPを扱うことができませんでしたNATは、SCTPに関するMA-プロトコル・オプション・フィールドでこれを設定します。プロトコルは、この方法は、メッセージング関連のために使用してはいけませんフラグを立て。それらは異なるプロトコルを参照して、又はMA-プロトコルオプションフィールドが存在しないプロファイルを参照する場合スタック提案及びSCDは、例えば、「オブジェクト値エラー」メッセージ（付録A存在するが一貫していないの両方である場合.4.4.10）サブコード5で（「スタック・提案 - スタック・コンフィギュレーション・データ不一致」）が返されなければならないとのメッセージが低下しました。
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:
（Responderが既存の関連付けを使用することを決定した）多重化が発生しない限り、応答は常に、スタック・提案と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再利用メッセージ関連クエリに提供されたプロトコルの構成の少なくとも一つと同等以上のトランスポートおよびセキュリティ特性を有しなければなりません。
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:
このMA-プロトコル-IDは、ピア間のTCPの基本的な使用を示しています。このプロトコルのサポートが必要です。このプロトコルが提供される場合、MA-プロトコルオプションデータは、SCDのオブジェクトに実行されなければなりません。 MA-プロトコル・オプション・フィールドの形式は次のとおりです。
o in a Query: no additional options data (the MA-protocol-options Length field is zero).
クエリ中のO：なし追加オプションデータ（MA-プロトコルオプション長フィールドがゼロです）。
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.
転送にメッセージを伝えることができます転送し、TCPを使用して関連付けをTrue =信頼性の高い属性。ソケット例外条件によって、例えば検出することができるように、エラーが、このようなリセットのようなTCP接続上で発生した場合は、セクション4.1.2で説明したように、GISTはNSLPsに報告しなければなりません。
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-プロトコル-IDは、最初にTCPと連動して、トランスポート層のチャネルセキュリティの基本的な使用を示しています。 TCPと併せて、このプロトコルのサポートが必要です。転送にメッセージを伝えることができ、それを使用する団体は、機密性や完全性保護を要求する属性。特定TLSバージョンはTLS層自体内でネゴシエートされますが、実装はTLS1.0 [15]の前にプロトコルバージョンに交渉してはいけませんし、両方のピアによってサポートされる最も高いプロトコルバージョンを使用しなければなりません。 TLS1.2 [10]の実装を推奨します。 TLS1.0又はTLS1.1を支持GISTノードがTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号スイートTLSを交渉することができなければならなくて、TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートTLSを交渉することができるべきです。彼らは、認証、完全性、機密性を提供する任意の相互に受け入れ可能な暗号スイートを交渉することができます。
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.
上記の暗号スイートに当てはまるTLS認証のデフォルトモードでは、クライアント/サーバーのX.509証明書の交換を使用しています。クエリノードは、TLSクライアントとして動作し、かつ応答ノードは、TLSサーバーとして機能します。上記の暗号スイートの1が交渉されている場合、サーバーとして動作するGISTのノードは、証明書を提供しなければならない、とTLSクライアントとして動作するGISTのノードから1を要求しなければなりません。これは、クライアントとサーバーに適用されたポリシーに利用可能な証明書に応じて、いずれかのサーバーのみまたは相互認証を行うことができます。
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-プロトコル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.
いいえMA-プロトコル・オプション・フィールドは、このTLSプロトコルの定義のために必要とされません。 TLSが実行されている上にトランスポートプロトコル（例えば、TCPポート番号）の設定情報は、そのプロトコルのMA-プロトコルオプションによって提供されます。
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認証した後、ノードは、man-in-the-middle攻撃を避けるために、ピアによって提示されたアイデンティティをチェックし、ピアはGIST層でのシグナル伝達に参加することを許可されていることを確かめなければなりません。 4.4.2項で述べたように、認可チェックは、順番に各認定ピアデータベース（APD）のエントリで提示アイデンティティを比較することで行われます。このセクションでは、単一のAPDエントリの同一性比較アルゴリズムを定義します。
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認証の場合は、DNS名前空間のアイデンティティが証明書に存在するタイプのdNSNameの各subjectAltName拡張に対してチェックしなければなりません。そのような拡張機能が存在しない場合、アイデンティティは、証明書のSubjectフィールドで（最も特定の）一般名と比較されなければなりません。 dNSNameまたは共通名フィールドに対してDNS名を照合すると、マッチングは大文字と小文字を区別しません。また、「*」ワイルドカード文字は、APDで証明書またはアイデンティティで一番左の名前の成分として使用することができます。たとえば、* .example.comとAPDではa.example.com、foo.example.com、* .example.comと、などの証明書と一致しますが、example.comが一致しません。同様に、* .example.comのための証明書がa.example.com、foo.example.com、* .example.comと、などのAPDのアイデンティティのために有効ではなく、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にアルゴリズムを実装する必要があり、そのような検査済みの証明書と同一のローカルストアに対してサーバ証明書を比較するよう検証の等価レベルを（達成する他の検証方法とそのアルゴリズムを補うMAYバインディング）。
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認証のために、（クライアントID、即ち、照会ノードの場合）またはpsk_identity（サーバアイデンティティ、即ち、応答ノード用）psk_identity_hintのIDは、APDにおけるアイデンティティと比較されなければなりません。
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モードのカプセル化ルールをルーティングメッセージのフォーマットの定義を必要とします。これらは、現在定義されているのMRMは、次の項に記載されています。ノード上のGISTの実装は、そのノード上のNSLPsによって必要とされるものは何でものMRMサポートしなければなりません。 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]
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プロトコルとのDiffServコードポイント・フィールドは重要なものとして解釈されるべきであるかどうかを定義します。送信元および宛先アドレスは、実際のノードアドレスが、（IPv4とIPv6のために、それぞれ）MRIは、またはより広いアドレス範囲からのトラフィックを参照できるように、アドレスワイルドカードを実装するために使用される32又は128以外のプレフィックス長でなければなりません。追加のフラグは、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.
メッセージペイロードのMRIで与えられるO宛先IPアドレスは、フローの宛先アドレスでなければなりません。
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ノードであることを検出するために、クエリノードは非常に困難であろう。クエリノードはICMPエラー（QモードパケットがDFセットで送信されたリコール）を参照する必要がある場合には、パスに沿って異常に低いMTUがある場合、別の場合です。
* 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).
*（7.2.1項を参照）のみIPヘッダ内のIPアドレスを処理し、変換れる、変更されていないNAT経由GISTを実行しようとするために。
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は、MRIでの値と一致したDiffservコードポイントと（IPv6用）フローラベルを設定する必要があります。
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とそのインターフェイス上で使用されるバージョン（複数可）のものと一致する必要があり、その送信元アドレスの全範囲（そのプレフィックス長でマスクソースアドレス）ということですイングレスフィルタリングチェックを通過します。これらの場合、エラーメッセージは、それぞれ、サブコード1または2（「IPバージョンの不一致」または「進入フィルターの失敗」）と「MRI検証失敗」（付録A.4.4.12）です。
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.
いくつかの展開シナリオでは、上り方向の状態をルーティング設定することが望ましい（すなわち、送信者に向かって流れる受信機から）。これは、ファイアウォールの非協力的な送信者からのトラフィックを制御するためのシグナリング、またはフローの送信者がNSIS-ことができなかったところ、一般的には、シグナリングをサポートするために使用することができます。この機能は、クエリメッセージをアップストリーム送信するためのカプセル化と処理ルールを定義することによって、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.
上流GISTピア1つのIPはOホップ離れ、フローが到着するインターフェイスを介してバックトレースすることにより到達することができます。
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が異なる場合、状態をルーティングするこれらの項目は、独立したとみなされなければなりません。 SIDが一致する場合、優先されなければならない下流交換によってインストールルーティング状態は、下流クエリイングレスフィルタリングチェックに合格したことを条件とします。この理論的根拠は、上流のクエリの使用がのクエリノードの理解の正確さに依存するのに対し、それが直接、流路に沿って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をフローラベル（IPv6の場合）のDiffservコードポイントと下流と同様に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は、与えられたアドレスの方向に特定の特性を有するGISTノードを発見するために使用され、例えば、[34]のようにアップストリームデータパスに沿ってNATを発見します。
For the loose-end MRM, only a simplified version of the Flow Identifier is needed.
ルーズエンドMRMのために、フロー識別子のみ簡略化が必要です。
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のために定義されています。慣例により、これは、下流のカプセル化と呼ばれ、以下のように定義されます。
o The IP destination address MUST be the destination address as given in the MRI of the message payload.
メッセージペイロードのMRIで与えられるO IP宛先アドレスは、宛先アドレスでなければなりません。
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のコードポイント、IPレイヤTTL、またはフローラベル（IPv6の場合）の設定に関する特別な要件はありません。 NOR特別な検証チェックが適用されます。
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:
概念的に、ノードにおけるGIST処理は状態機械を協働する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）を表す最上位レベルのステートマシンがあります。これは、より具体的なステートマシンに向けられないルーティング状態が現在存在しないため、例えば、インバウンドメッセージことができないイベントの処理を担当します。このマシンは永続的に存在し、あたり-MRIステート・マシンはGISTハンドシェークとルーティング状態の保守手順を管理するために作成するための責任があります。
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.は、クエリノード状態機械（クエリ-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）のインスタンスがあります。このマシンは、そのフローのルーティング状態の状態を管理する責任があります。ポリシーによっては、応答メッセージの送信または再送信のために責任があるかもしれない、またはこれは、Node-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
別に様々なマシンが作成され、互いにによって破壊することができるという事実から、それらの間のほとんどの相互作用があります。異なるフローのためのマシンが相互作用しません。クエリ-SMと
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は、経路に沿った次のインターフェイス上での状態をルーティング設定問合せ-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を//する任意NSLP-データを配信することに注意してください作成されるべきである）をIF（ルーティング状態は、3ウェイハンドシェイクなしで作成することができる）、それはそうでなければ他= 1が提供された更新NSLPペイロードでクエリを伝播Rで応答を送信する応答のSM及び転送制御作成
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を対応している必要があります対応-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）：（一致ルーティング状態を持つノードのポリシーをする唯一のプロセスデータメッセージ）ならば、そうでなければ「いいえルーティング状態を」送信エラーメッセージがNSLPに直接渡します
Rule 4 (er_NoRSM): discard the message
ルール4（er_NoRSM）：メッセージを破棄する
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
ルール5（tg_NSLPData）：（ローカルポリシー＆転送属性は、ルーティング状態が必要とされていないと言う）場合は、このMRIは他のエラーでメッセージを拒否するためにQモードのカプセル化は可能でないならば、クエリ-SMを作成して、メッセージを渡すステートレスに他のメッセージを送信それ
The Querying-Node state machine (Querying-SM) has three states:
クエリ・ノードのステートマシン（クエリ-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：この状態機械によって保存されたルーティング状態をリフレッシュしなければならないときを示します。応答が受信されるたびに、それは、ルーティング状態がまだ有効であることを示すリセットされます。実装は、ピアのルーティング状態の有効期限が切れる前に、クエリ（4.4.4項を参照）が生成されることを保証するために、応答のRS-妥当性 - 時間フィールドの値に基づいて、このタイマーの時間を設定しなければなりません。
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に応答なしのエラーを示していない他の自己が新しい値でNO_RESPONSEタイマーを起動するクエリを送信破壊します
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-フラグが設定された場合は、1つを作成することを確認し、任意の保存されたデータメッセージがピギーバックNSLP-データパスがあった場合、それが実行されていなかった場合NO_RESPONSEタイマー開始Refresh_QNodeタイマーがInactive_QNodeタイマーを開始、停止送る送信それ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:
対応ノードのステートマシン（対応-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:
クエリメッセージの処理と対応-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が確立状態で直接作成されます。マシンがクエリを受けて作成された場合は、メッセージ処理のいくつかはすでにノード・ステート・マシンで実行されていることに注意してください。原則として、実装はいつでもQueryメッセージの取り扱いに関する方針を変更することができ、しかし、ここではステートマシンの記述は、確認メッセージを待っている間にポリシーが固定されている場合のみをカバーしています。
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イベントは黙って無視されなければならないことができます。待ち状態の更新は、クエリが、ルーティング状態のリフレッシュを開始するために受信されている設立のサブ状態、と考えることができます。待機中のリフレッシュ状態では、対応-SMはNSLPは、まだデータを送受信できることを除いて、状態を確認待ちのように振る舞います。具体的には、両方の状態における応答メッセージのタイマーに基づく再送信確認が受信されるまでがあります。これらの状態で追加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（再）起動No_Confirmタイマーで必要な送信応答であります
Rule 2: pass any NSLP-Data object to the NSLP start Expire_RNode timer
ルール2：NSLPに任意のNSLP-データオブジェクトを渡す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開始Expire_RNodeタイマー付きノー確認が必要な送信レスポンス
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：任意の保存されたデータメッセージがNo_ConfirmタイマースタートExpire_RNodeタイマーを停止送るNSLPに任意の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が他の自己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が完了するメッセージング・アソシエーション内のすべてのプロトコルの接続処理（ES）を待っていることを示しています。これは、リスニングのエンドポイントを作成したり、アクティブコネクトを試みる伴うかもしれません。タイマーは、接続障害（例えば、一定期間内には、着信接続）を検出する必要があるかもしれないが、これらは明示的にモデル化されていません。
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がオープンし、使用する準備ができていることを示し、ノードは、それが開いたままを望んでいること。この状態では、ノードは、ピアがMAを取り壊すしないことを確実にするために、メッセージが定期的にピアに送信されることを保証するためにタイマー（SendHello）を操作します。ローカルポリシーの問題として（それがもはや関連が必要であることを示していない）をアイドルに接続されたノードから移行;ポリシーを管理するための一つの方法は、アクティビティタイマーを使用することですが、これは（セクション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-ハローリクエストを送信することによって、そのピアにピアへの接続とGISTインスタンスの生存性を試験することができます。タイムアウト時間内にマッチングこんにちは-IDを持つ応答を受信しなかった場合は、er_MAFailureをトリガーする理由としてもよいです。そのような試験およびタイムアウト設定の開始は、実装の裁量に委ねられます。 er_MAFailureはまた、基礎となるメッセージング・アソシエーションプロトコルからの指示によって通知されてもよいことに留意されたいです。メッセージング関連付けが失敗した場合、これはそれを使用するルーティングステート・マシンにバックを示さなければなりません、そしてこれらは、シグナリングアプリケーションへの適応を生成することができます。メッセージング・アソシエーションを確実にメッセージを配信するために使用された場合は特に、これはNetworkNotification誤差（付録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-こんにちはしばらくの間、リモート・ノードから受信していないことを示します。このタイマーの期間はクエリ/レスポンス交換中に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：NoHelloタイマーが実行されていた場合、それを停止（レスポンスの場合）、または（確認用）R-SM、またはQ-SM-SMをノードにメッセージを渡します
Rule 3: if reply requested send MA-Hello restart SendHello timer
ルール3：返信要求された送信MA-こんにちはSendHelloタイマーを再起動した場合
Rule 4: send MA-Hello message restart SendHello timer
ルール4：MA-こんにちは送信メッセージの再起動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：停止NoHelloの時間を開始helloタイマーを送ります
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-こんにちは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状態の間の遷移のためのGISTとシグナリングアプリケーション、および追加のトリガ間のAPIを介して余分な相互作用があります。
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は、ネクストホップが変更されたローカル転送テーブルから探し出します。少数のIPルーティングは、それがGIST非対応ノードで行われた場合を含め、ホップ離れ発生した場合、ルーティングの変更は、ローカルでない場合にのみ機能します。
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ホップごとに独立ネゴシエートすることができます。照会ノードが応答したネットワークレイヤの情報で変更することにより、経路変更を発見するでしょう。応答ノードは、同様に、上流ピアの変化を検出することができます。応答ノードは、クエリが到着するインターフェイスを格納することができる場合はピアがない場合でも、このインタフェースが変更された場合、さらに、それが検出することができます。
+-------------+--------------------------+--------------------------+
| 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:
再ルーティングをサポートするのに必要な基本的なGISTの動作は、現在のルーティング状態の各項目の有効性の3レベルの分類を使用してモデル化することができます。 （現在のルーティング状態に加えて、NSISは、以下のセクション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節で説明した状態と同じではありませんが、それらの間の依存関係があります。状態機械は最初、それが良好となるこの時点で確立された状態に入るまで、具体的には、ルーティング状態が悪いと考えられます。その後、ステータスは、上述のいずれかの理由で無効にされてもよいです。任意の所与のノードに実装するためにどの技術、及び各々について（不良または仮のような）状態をルーティング再分類する方法を決定するために、実装上の問題です。いずれかの状態機械ESTABLISHED状態に再び入る場合やGIST良好に状態復帰は、IPルーティングの直接検査又はピアが変更されていない転送テーブルから決定することができます。ときに良い、GISTのMUSTにステータスを返すかの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は自動的に暫定的に上流方向に分類を変更することができます。これは、最初の変更がシグナリングアプリケーションによって示された場合に行われるべきではありません。このメカニズムは、ルーティング変更が複数のノードに影響を与える可能性があるという事実を考慮し、そのため上流ルーティングも変更されたことを指示することができます。変更が最初の場所でAPIを介して引き起こされていない限り、いずれの場合においても、GISTは、ルーティング状態を更新するたびに、それは、NetworkNotificationの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:
状態の修理のためのGISTの動作は、クエリと対応のノードで異なります。応答ノードが自律的プロトコル遷移を開始することができないので、応答ノードに、追加の動作は、存在しません。 （それだけ照会ノードに反応することができる。）照会ノードは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.
第二及び第三の技術は、修復を実行するためにGISTハンドシェークの実行をトリガします。ハンドシェイクプロセスの開始を遅らせるために、いずれかのネットワークを安定させるために、影響を受けたフローの数が多いため、クエリトラフィックでネットワークを氾濫を避けるために、またはノードが上のままであることの確認を待つために、待機することが望ましいかもしれません上流のピアからの経路。一つのアプローチは、送信するNSLPデータがあるまで握手を遅らせることです。このような遅延の実装は、ローカルポリシーの問題です。しかし、GISTは、ステータスの変更が「緊急」としてマークされInvalidateRoutingStateのAPI呼び出しによって引き起こされた場合は、直ちにハンドシェイクを開始しなければならない、と上流のルーティング状態はまだ良いであることが知られている場合は、それを開始する必要があります。
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モードのパケットとの間の異なるヘッダフィールドに基づいて、またはラウンドロビン方式で行われている環境では、クエリによって発見された経路は、1つのハンドシェイク異なっていてもよいです次の基礎となるネットワークが安定しているにもかかわらず。これは、ルートフラップなどGISTに表示されます。ルートフラッピングは、基本的なネットワーク接続またはルーティングプロトコルの動作に問題が原因で発生することができます。例えば、モバイルノードは、二つのリンク間で前後に切り替えることがあり、またはそれは依然として異なる経路を介してネットワークに接続されていても消えたように見えるかもしれません。
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、これを公開してもよい（MAY）。アルゴリズムは、すでに現在のルート、すなわち、特定のフローのために発見された最新のピアの概念を維持し、常に説明します。シグナリングアプリケーションはまだそれらを必要としながら、その代わり、GISTは、いくつかの期間の前の信号パスを使用することができます。 NSLPピアが単一GIST離れホップであるので、パスを表すために必要な情報は、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ハンドルを使用する必要がある場合、そのGISTに留意されたいです。 SII-ハンドルを使用して送信されたメッセージは、送信者にルーティング状態テーブルをバイパスしなければならず、これは、共通ヘッダ（付録A.1）にE-フラグをセットすることによって示されなければなりません。データメッセージ以外のメッセージは、このように送ってはいけません。受信機において、GISTは、ローカルルーティング状態に対してMRI / SID / NSLPIDを検証し、代わりにAPI（付録B.2）を介してアプリケーションシグナリングに受信モードを示してはいけません。シグナリングアプリケーションは、ソースおよびメッセージの効果自体を検証し、適切なは、特に必要がある場合べき状態をルーティングすることは、もはやこのフローのために必要であること（付録B.5参照）GISTを示しません。これは、状態の更新をルーティングするので、クロスオーバールータの状態の矛盾を引き起こす開始旧経路上のノードにGISTを防止する必要があります。
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は、イベント、付加および欠失の二つのタイプのような経路変更に関するアプリケーションシグナリング通知します。削除はもはやSIIは、ハンドルの経路上にある、という記述として表現されている間さらには、上記バッド/暫定/グッド分類に従って現在のルーティング状態の変化として通知されます。どちらも、NetworkNotification 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をトリガします。ローカル修復手順は、ステートフルNSLPノードが単一GIST離れホップであるという事実に大きく依存します。これは、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でシグナリングアプリケーションは、下流と上流の方向に影響を与えるルート変更のGISTで通知されます。下流の状況があるため、ローカル転送テーブルからのトリガの悪いに更新され、上流のステータスが結果として暫定的に自動的に変更されました。 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.
GISTメッセージは、例えば、パス結合MRMため、流れはの合図を定義するためにアドレッシング及びペイロードデータとして上位レイヤ情報を運ばなければなりません。 （これは関係なく、それらがカプセル化されるか、またはそれらが進行している方向方法の、すべてのGISTメッセージに適用される。）アドレッシング境界では、データフローのパケットは、それらのヘッダが翻訳されなければなりません。シグナリングペイロードが一貫して翻訳されていない場合は、シグナリングメッセージが正しくない（おそらく無意味）を参照する境界を通過した後の流れ。また、GISTハンドシェークメッセージ自体をノード、およびNATを横断するとき、これはまた、適切に処理しなければならないGISTに関する追加のアドレッシング情報を運びます。
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（TURN）の周りにリレーを使用してNAT（STUN）のセッショントラバーサルユーティリティ[26]またはトラバーサルなどの既存の一般的なNATトラバーサル技法[27]だけIPヘッダ内の目に見える二つのアドレス上で動作することができます。流れとシグナリング送信元と宛先のための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とのMRMのために、ベースGIST仕様は状況を検出し、シグナリングパスを終端するために適切なエラー状態をトリガすることが制限されています。 （GIST処理ルールにはいくつかの修正を加えて、安全にそのようなのNATをトラバースすることができアドレス情報が含まれていないのMRMは、このような修飾は、このようなのMRMを定義文書に記載することができる。）レガシーNAT処理は、以下のセクション7.2.1で説明されています。より一般的な解決策は、NATを自分自身でGIST-意識を使用して構築することができます。このソリューションは、7.2.3項で処理ルールと7.2.2項に概説されています。
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は、その文書と完全に一致していますさ。すなわち、最初のメッセージの宛先UDPポートがGISTポートであるもの（セクション9を参照） - GIST対応NATトラバーサル技法は、UDPトランザクションの特定のクラスのためのNATのアプリケーションレイヤーゲートウェイを必要とすることと等価です。
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フラグの分析に依存し、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.
Sフラグがクエリ（S = 0）に設定されていない場合、NATの内側に照会ノードの場合について、従来のNATを検出することができません。受信機は、クエリでNLIに所定のインターフェイスアドレスに対して正常な応答を生成するが、interface-アドレスがルーティング可能でなくなり、応答が配信されません。再送クエリは、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.
状況は、クエリで= 1 Sいったん変更します。カプセル化規則はS = 1は、いくつかの再送信のために少なくとも使用されることをお勧めしますQモードに注意してください（セクション5.8を参照してください）。 S = 1の場合、受信機は、NLIのインターフェイスアドレスに対するIPヘッダのソースアドレスをチェックしなければなりません。これらのアドレスが一致しない場合は、従来のNATが発見されました。翻訳が必要なアドレス指定情報を含んでのMRMのために、従来のNATトラバーサルはできません。受信機は、当該オブジェクトとして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の外側にある場合には、いくつかの静的な設定は、内部ネットワーク上のノードにGIST Qモードのトラフィックを転送するためにNAT上で行われている場合、クエリのみNATを通過します。かかわらず、クエリのSフラグ、応答ノードは、直接NATの存在を検出することができません。これは、通常のUDPトラフィックとしてNATを横断するクエリ・ノードのNLIから派生したアドレスにS = 1で正常な応答を送らなければなりません。照会ノードは、応答に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トラバーサルプロシージャを起動することができることに留意されたいです。一つの可能なアプローチは、[43]に記載されているが、この明細書は、このような手順を定義しません。そのような任意のトラバーサル手順は、既存のGISTの拡張機能を使用してGISTに組み込まなければなりません。また、注ハンドシェーク交換この検出プロセスでのみ機能します。それは彼らがQ-モードまたは正常に封入されているかどうか、簡単なデータメッセージを操作することはできません。彼らはレガシーのNATの自由な環境で動作していることを確認できない場合、ノードは、メッセージング関連外のデータメッセージを送るべきではありません。
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は、GIST認識していることを要求し、それはMRIの内容に基づいてメッセージを変更できるようにすることです。これは、NATをのみヘッダフィールドがMRIには含まれず、他の上位層識別子書き換えという仮定を行います。提供これは、メッセージが対応するアプリケーションをシグナリングするNATを必要とせず、境界の各側有効であることができ、シグナリング、データ・フロー・ヘッダ変換と一貫して行われます。ただし、そのNATは、MRI、およびMRIにおけるN-フラグを理解していない場合でクリア（付録A.3.1を参照）、それは「オブジェクトの種類エラー」メッセージとメッセージを拒否すべきである（付録A.4.4 0.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対応のNATが利用可能である状態をルーティングすることなく解釈されることができなければならない任意のシグナリングメッセージを修正することです。これらのメッセージは、共通ヘッダに文脈自由フラグ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.
本明細書は、文脈自由フラグC = 1を有する全てのQ-モードカプセル化されたメッセージにNATインサートという追加NATトラバーサルオブジェクトを定義し、かつGIST任意の応答、すなわち、応答またはエラーメッセージにエコーバック。 NATは唯一C = 1、またはNATトラバーサルオブジェクトを運ぶDモードメッセージとQモードカプセル化メッセージにGIST固有の処理を適用します。他の全てのGISTのメッセージ、のいずれかでCモードまたは全くNATトラバーサルオブジェクトとDモードのそれらのものは、IPおよびトランスポート層ヘッダ翻訳なくないGIST固有の処理で、すなわち、NATにより、通常のデータトラフィックとして扱われるべきです。 QモードとDモードのカプセル化との間の区別は、CフラグまたはNATトラバーサル物体の存在の設定を代行基準として使用されている理由であるNATに観察可能ではないかもしれないことに留意されたいです。 NATの決定は純粋にCフラグおよび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であるように選択されます。未修正のMRIがNATトラバーサルのオブジェクトに伝播される理由である、インバウンドおよびアウトバウンドメッセージ上の2つのMRIの間の変換に対応するノードの責任です。
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の実装とバインディングの割り当てに関するポリシーに依存しますので、しかし、それは、GISTのメッセージを翻訳するNAT用の規範的な振る舞いを定義していません。また、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のための操作可能なセットです。データメッセージのために、操作のサブセットのみが適用可能であることに留意されたいです。
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.新しいネットワークレイヤ情報を作成した場合に必要なスタック・コンフィギュレーション・データは、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.変更されたオブジェクトを一覧表示し、変更されていないMRIと応答を解釈するために必要なその他のデータを含め、NATトラバーサルオブジェクトを追加します。 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フラグを元のメッセージに設定された場合、同一のIP送信元アドレス選択ポリシーは、転送されたメッセージに適用されるべきです。
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トラバーサルのオブジェクトを効果的に無視することができます。他の可能性は、メッセージが、新しいフローのためのハンドシェイクの先頭または既存の状態のリフレッシュのいずれかであるため、レスポンスは、返却しなければならないということです。両方の場合において、GISTノードは、MRIのローカル形式を使用して通常の方法で応答を作成する必要があり、そしてそれ自身のNLI及び（必要ならば）SCD。それはまた、共通ヘッダの後に応答して第1のオブジェクトとして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の場合の処理のサブセットです。
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モードシグナリングトラフィックのための任意のバインディングを作成または更新。
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変化のルート変更と見られます。確認が到着したときにそのため、確認を受信するまで状態のインストールを遅らせることを望む応答ノードは、何らかの形で翻訳を再構築しなければなりません。これを行うにはどのように実装の問題です。一つのアプローチは、確認にエコーさレスポンダクッキーの一部として翻訳対象物を搬送することです。確かに、セクション8.5でクッキーの構造の一つのために、これは自動的に行われます。
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.
場合によっては、トンネル出口ポイントトンネルシグナリングを行うことを望むであろう（トンネルデータおよび下流のシグナリングパケットがトンネルを残しすなわち、ノード）であるが、このノードは、どのトンネルエントリの知識又は制御を有していませんポイントは、データフローのカプセル化を行っています。内側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）を拒絶しなければなりません。それは他のIPバージョンを使用して、フローのためのシグナリングをサポートするために、IPv4のみ、またはIPv6のみGISTノードに対して本質的に不可能であるので、D-モードで使用されるIPバージョンは密接に、データ・フローによって使用される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で説明したようにGISTの観点から、これは、本質的に（内部と外部アドレスとの間の例えば、）他のNAT動作と同じように扱われるべきです。翻訳ノードは、GISTを意識する必要があります。それは2間のクロスフローにIPv4とIPv6のフォーマット間のアドレス指定のペイロードを変換する必要があります。 [7]で定義されるように（例えば、DiffServの-コードポイントとフローラベルを含む）MRIペイロードのフィールドのための変換ルールです。この技術は、もはや汎用転移機構[40]として提案されているが、同じ分析は、NAT-PTに適用されません。
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）トンネリングによる領域にわたって実施することができる方法の問題を扱います。方法は、トンネル管理オーバーヘッドを最小限に集中する傾向があります。セクション7.3で説明したようにGISTため、治療は、他のIPトンネリングメカニズムに類似していなければなりません。具体的には、エンド・ツー・エンドのフローシグナリングがトンネルを通って透過的に通過し、トンネル自体のためのシグナリングは、トンネルエンドポイントにより管理されなければなりません。しかし、追加の考慮事項があるため、トンネル管理手順の特別な機能を生じる可能性があります。具体的には、[20]は宛先トンネルエンドポイントとしてエニーキャストアドレスを使用することに基づきます。 GISTは、必要に応じて、D-モードメッセージのQモードのカプセル化でエニーキャスト宛先アドレスを使用することができるが、ネットワークレイヤ情報のアドレス指定フィールドにそれらを使用してはなりません。ユニキャストアドレスが代わりに使用されなければなりません。 IPヘッダからのアドレスは、要求と応答との対応付けのGISTで使用されていないことに留意されたいので、エニーキャスト送信元アドレスを使用する必要はありません。
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.
状態の発見をルーティングでは、詐欺師とは対照的に、正当な次または前のホップであるかを知るためにいくつかの効果的な方法があります。つまり、暗号化認証は、ここでの唯一のノードは、それが（すなわち、いくつかの名前空間におけるアイデンティティの正当な所有者）ではなく、それは、流路に真にである（すなわち、ノード「何である「人」であることを保証しますしたがって、）特定のフローのためのシグナリングを行うことができます。知られているピアがその役割を偽ることはほとんどありませんことには認証は、限られた保護を提供します。このタイプの攻撃に対する保護のさらなる方法は、以下のセクション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は、GIST、それがサービスを提供している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図でありますノードの。ルートは弱くしか（例えば、経路への流れのない暗号結合が存在しない）固定され、そしてネットワーク自体の現在の状態以外の流動経路についての信頼できる情報がありません。したがって、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モードでカプセル化された流路に沿って送られてきたであろう前のクエリからクッキーをエコーしなければならない、すなわち、エンドツーエンド対処。したがって、唯一の真の次のピアまたはオンパス攻撃者がそのようなメッセージを生成することができるであろう、クッキーの提供鮮度は、照会ノードで確認することができます。
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.
フィルタリング：受信ノードは、イングレスフィルタリングにより除外することができたフローの送信元アドレスを持つフローのためであると主張するシグナリングメッセージを拒否するかもしれません。この技術の拡張は、データプレーンを監視し、フローパケットがDモードシグナリングパケットと同じリンク層ネイバーから同一のインタフェースを介して、可能であれば到着していることを明示的に確認するために受信ノードのためであろう。そうでない場合は、シグナリングまたはフローのパケットの少なくとも一方が詐称されている可能性があります。
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項を参照）、メッセージング関連の設定の一部として。理想的な状況は、受信ノードは、ルーティングテーブル解析またはローカルトポロジー制約の知識から正しい上流ノードのアドレスを決定し、その後、ピアは、このIPアドレスを持っていることを承認ピアデータベース（APD）から確認することができるということです。これは、デプロイメント環境の限定セットにのみ技術的に可能です。 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.)
一般に、各クエリのみGISTノードがサービス拒否増幅攻撃の源になることができないように、最大でもわずかに大きいだけクエリよりも多くても1つの応答を生成するようにGISTが設計されています。 （再送された応答メッセージの特殊なケースがあり、セクション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はまだ偽造送信元アドレスを使用して、攻撃者は、TCP SYNフラッド攻撃に対して同様の問題を引き起こして、リターンルータビリティない状態を確立するためにノードを強制的にDoS攻撃を受けることができます。さらに、敵は、このような攻撃の一部のように変形または再生保護されていないシグナリングメッセージを使用するかもしれません。状態攻撃の2種類と1回の計算資源の攻撃があります。第1の状態の攻撃では、攻撃者は、ノードが次のホップを決定することができるまで保存しなければならないメッセージでノードをフラッディング。何GIST対応の次のホップがないように、宛先アドレスを選択した場合、ノードは、発見再送信試行がタイムアウトするまでの数秒間のメッセージを蓄積します。状態ベースの攻撃の第二のタイプは、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.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.クエリに対する応答は確認で繰り返されるクッキーを、含まれています。状態は、唯一の有効なクッキーが含まれているメッセージのために確立されています。セットアップ遅延も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つのオプションは、非NSISノードであると効果的にフォールバック、セクション4.3.2に記載したように完全に、これらのメッセージをバイパスするノードのためのものです。これが不可能な場合、それはまだ行っていないされている場合、それは最初のステートレスに応答を送信するものにそのポリシーを適応させる必要がありますが、ノードはまだ、それがクエリメッセージを処理する速度を制限し、過剰分を捨てるのを選ぶかもしれ。適合GISTノードは自動的に指数バックオフを用いてクエリを再送信することにより、負荷を減少させます。 （DoS攻撃を起動する）非準拠のノードは、ハードも本物のハンドシェイクの試みに影響を与えずに速度制限を適用することができる任意のレートで非相関クエリを生成することができます。確認メッセージが要求された場合は、クッキーは、ソースごとに適用可能なリターン・ルータビリティチェックおよびレート制限によって検証された照会ノードアドレスにメッセージをバインドします。
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が提供するサービスを利用することができます。特に、それらは、リターンルータビリティチェックに合格したか、メッセージング・アソシエーション・レベルで認証されてピアからのメッセージのみを処理することを選択することができます（付録B.2を参照してください）。 （ルーティング状態が完全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.
生存性：クッキーは、ライブでなければなりません。つまり、それは1回の握手から次へと変更する必要があります。これは、リプレイ攻撃を防ぐことができます。
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.
予測不可能性：クッキーは、シーケンスまたはタイムスタンプから、例えば、推測であってはなりません。これは、以前の一連のメッセージをキャプチャした後、直接偽造を防止します。
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-ノードがすでに存在しているルーティングステートマシンのために、特定のクッキーが進行中のハンドシェイクと一致することを検証することは効率的でなければなりません。これは、ランダムに敵によって生成された応答を破棄し、または偽造送信元アドレスまたは含ま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:
次のように同様に、レスポンダ・クッキーの要件をまとめることができます。
Liveness: The cookie must be live as above, to prevent replay attacks.
ライブネス：クッキーは、リプレイ攻撃を防ぐために、上記のように生きなければなりません。
Creation simplicity: The cookie must be lightweight to generate in order to avoid resource exhaustion at the responding node.
作成シンプル：クッキーは、応答ノードのリソースの枯渇を避けるために生成する、軽量でなければなりません。
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-クッキーは、それ自体、他誰によって生成されたことを確認することが簡単でなければなりません。
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.
結合：クッキーは、修正の確認で、例えば、異なるルーティング状態で使用を防止するために、インストールされるルーティング状態に結合されなければなりません。ここで、ルーティング状態は、ピア・アイデンティティとメッセージングのためのクエリの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-クッキーのための適切な実装は、このルーティングステートマシンハンドシェイクに固有の暗号的に強い乱数です。ノードは、このまたは同等に強力なメカニズムを実装しなければなりません。乱数生成に関するガイダンスは、[31]に見出すことができます。
A suitable basic implementation for the R-Cookie is as follows:
次のようにR-クッキーに適した基本的な実装です。
R-Cookie = liveness data + reception interface
+ hash (locally known secret,
Q-Node NLI identity and address, MRI, NSLPID,
liveness data)
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].
ノードは、このまたは同等に強力なメカニズムを実装しなければなりません。ライブネスデータのためのいくつかの選択肢があります。一つは、SCTPのようなタイムスタンプを使用することです。もう一つは、IKEv2のような秘密の世代番号、としてライブネスデータを、ローカル秘密に（急速に）ロールオーバーを与えることです。両方の場合において、生存性のデータは、ハッシュがレスポンダで検証できるようにするために、ハッシュ外に運ばれなければなりません。別のアプローチは、ライブネスデータが明確で運ばれる必要はありません、その場合には局部的に知られている秘密、下の暗号化とハッシュを交換することです。クリブへの任意の対称暗号免疫を使用することができます。遅延状態のインストールでGIST対応のNATトラバーサルの場合は、クッキーに追加のデータを運ぶことが必要です。適切な構成は[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.
検証シンプルさの要件をサポートするために、Responderは任意の暗号クッキーの検証を開始する前に、いくつかのブラインド（洪水）攻撃をフィルタリングする生存性のデータを確認することができます。この使用法をサポートするために、ライブネスデータを簡単に推測することが明確でない中で行わなければなりません。これは、タイムスタンプアプローチを除外し、配列中の位置を特定ライブネスデータと秘密のシーケンスを使用することを示唆しています。秘密の強度とロールオーバー周波数は、秘密はその生涯の間にブルート強制することはできないことを十分に高くなければなりません。いずれかのノードが現在のライブネスデータを発見するためにクエリを使用することができますので、偽造送信元アドレスからのクエリの洪水の中、このようなプローブを偽装洗練された攻撃を防御するのは難しいまま。そのため、効率的なハッシュメカニズムまたは同等を使用することが重要まま。
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.
ノードは、クッキーの検証が失敗し、それが送信者にサブコード4（「無効なクッキー」）と「オブジェクトの値エラー」メッセージ（付録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).
この仕様は、単一強制的に実装セキュリティプロトコル（;セクション5.7.3 TLS）を定義します。しかし、例えば、将来的に追加のセキュリティプロトコルを定義するために資格証明書の他のタイプの再利用を可能にするために、またはより強力なセキュリティ特性を持つプロトコルに向かって移動することも可能です。また、メッセージング関連付けのいずれかのセキュリティプロトコルの使用はオプションです。セキュリティプロトコルの選択は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]):
選択プロセスは、中央に人が達成可能であるよりも、保護のより低いレベルを受け入れるにピアを誤解するクエリまたは応答で提供される機能を変更攻撃を、ダウングレードに対して脆弱であり得ます。そのような攻撃に対する二部防衛がある（同じ概念に基づいており、以下のように[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.
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.
第二部の有効性は確認のために提供されるセキュリティ保護の強度に依存します。照会ノードがnullのセキュリティプロパティ（のみ例えば、TCP）とメッセージング関連付けを作成する用意がある場合は、防御が無効である、真ん中の男を再挿入することができるので、元のレスポンダのスタック・提案、および対応ノードがあることを前提とします最小限の保護は、ノードの制限の照会の結果です。メッセージング関連がリアルタイムに分割できない最小完全性保護で提供している場合ただし、確認は、この方法で変更することはできません。したがって、照会ノードが保護の少なくともこの最小限のレベルを確実に作成するメッセージング関連プロトコルにセキュリティポリシーを適用しない場合が満たされ、それがダウングレードが発生したことを脅威に開いたままになります。そのようなポリシーを適用すると、機能の発見プロセスが関与する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.
最初のクエリを傍受することができます上のパス攻撃者は、それがその後のシグナリングを望んでいるほとんどの事を行うことができます。 GISTのレベルでこれを防御することは非常に困難です。唯一の防御が応答ノードが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.
クエリのパスではありませんが、レスポンスのパス上にある、または相互に干渉するために、1つのハンドシェイクの応答を使用することが可能であるノードによる更なる残留攻撃があります。攻撃者は、それに隣接ではなく、真のピアを形成するために、クエリノードを引き起こすへの応答を変更します。原理的には、この攻撃は、最初のクエリへの応答およびルーティング状態を結び付けるとクエリノードによって検証することができる応答に追加の暗号化オブジェクトを含むことによって防ぐことができます。
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に記載の特定の脅威に応答ノードを露出ありません。例えば、応答ノードが存在するかどうかを確認することができないのman-in-the-middleシグナリングメッセージを操作することができ、そしてそれは、リソースの承認を要求した場合、それは照会ノードの身元を確認することができないこととクエリノードの間に、 。ホストネットワークシグナリングの場合に、応答ノードは、シグナリング方向に応じて、ホストまたは最初のホップルータのいずれかであり得ることに留意されたいです。そのため、これらの脆弱性により、相互認証を提供しない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.
不十分な実装や妥協NSLPがGISTのセキュリティを低下させる可能性：GIST操作の特定のセキュリティ面では、アプリケーションの動作を信号に依存しています。しかし、劣化が唯一の弱点が発生したノードでNSLP自身のシグナリングトラフィックや全体的なリソース使用量のGISTハンドリングに影響を与える、と実装の弱さや妥協はNSLP自体の中に、同じように大きな効果を持つことができます。 GISTは、適切なSIDを選択するNSLPs（4.1.3項）に依存します。 NSLPsは非ランダムSIDを選択した場合、これは実行するために簡単に推測SIDに基づいて、オフパス攻撃を行います。 NSLPsも構造化された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プロトコル・スイートを考慮し、別の文書で規範的に覆われている新しいコードポイントの割り当ての要求を評価する際に従うべきことに注意してください。その文書には、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]で与えられたガイダンスに従います。 [9]で説明したように加えて、GISTレジストリの数のため、本明細書は、プライベート/実験の範囲を定義します。これらのコードポイントが有効に使用することができる唯一の環境は、実験者は、進行中のすべての実験を知っている中で、閉じた一つであることに注意してください。
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のメッセージ（5.3節）の宛先ポートとしてUDPポート270をよく知られています。
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つまたは複数のNSLPIDsの割り当てを必要とします。以下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の使用は、特定のRAO値に関連付けられなければならない必要MRMを使用するすべての他のNSLPID。複数のNSLPIDsは同じ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).
新しいオブジェクトタイプが手順のいずれかに従って割り当てられる場合、仕様は、オブジェクトフォーマットを提供し、拡張ビットの設定を定義する必要があります（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.
新しいMRMは、登録手順の1つに従って割り当てられる場合、仕様は、セクション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-プロトコルのID：メッセージング関連して使用することができる各プロトコルは、1バイトのMA-プロトコルIDによって識別される（セクション5.7）。 MA-プロトコル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.
新しいMA-プロトコルIDが登録手順の1つに従って割り当てられる場合、仕様書が必要となります。これは、その設定を定義するために必要とされるスタック・コンフィギュレーション・データ・オブジェクト内の（もしあれば）MA-プロトコル・オプション・フィールドのフォーマットを定義しなければなりません。プロトコルは、信頼性の高いメッセージ転送に使用する場合、配信エラーがGISTによって検出される方法を説明しなければなりません。新しいチャネルセキュリティプロトコルを含むように拡張はGIST操作の残りの部分と、セクション3.9で説明した機能を統合する方法の説明を含まなければなりません。新しいMA-プロトコル-IDは、既存のものと組み合わせて使用することができる場合（例えば、トランスポート層セキュリティを使用することができ、新たなトランスポートプロトコル）は、仕様では、両者の間の相互作用を定義しなければなりません。
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:
エラーコード/サブコード：エラーオブジェクト（付録A.4.1）の値]フィールドに2バイトのエラーコードと1バイトのサブコードがあります。エラーコード1-12サブコード0-5（コード1）、0-5（符号9）、0-5（符号10）とともに、付録A.4.4で規定され、及び0-2（符号12）されています。追加のコードやサブコードは、先着順に割り当てられます。新しいコード/サブコードの組み合わせが割り当てられる場合、以下の情報を提供しなければなりません。
Error case: textual name of error
エラーの場合：エラーのテキスト名
Error class: from the categories given in Appendix A.4.3
Errorクラス：付録に与えられたカテゴリから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-タイプ1-4は、付録A.4.2で定義されています。追加のAI-タイプは、先着順に割り当てられます。
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
このドキュメントはIETF NSISワーキンググループ内での議論に基づいています。セドリックアウン、アッティラバーダー、ビトーBernado、ローランド祝福、ボブブレーデン、マーカスブルンナー、ブノワCampedel、佳子チョン、ルイス・Cordeiro、エルウィン・デイヴィス、ミシェル・ディアス、クリスチャンDickmann、：それは前の仕事からの公式、非公式の入力によって通知されましたパシEronen、アラン・フォード、暁明フー、ボーガオ、Ruediger Geib、エレノア・ヘップワース、トーマス・ヘルツォーク、チェン香港、テームHuovila、嘉嘉、コーネリアKappler、ゲオルギオスKaragiannis、ルードKlaver、マックスLaier、クリス・ラング、ラウリLiuhto、ジョンLoughney 、アリソンマンキン、ユッカマナー、ピートマッキャン、アンドリュー・マクドナルド、マックMcTiffin、グレン・モロー、デイブ・オラン、アンドレアスPashalidis、ヘニング・ピーターズ、トム・フェラン、アクバル・ラーマン、貴子三田、チャールズ・シェン、メリンダ・ショア、マーティンStiemerling、マルタインSwanink、マイクトーマス、ハンネスTschofenig、スヴェン・バン・デン・ボッシュ、Nuuttiヴァリス、マイケルWelzl、ラースWestberg、およびMAYI Zoumaro-djayoon。 TLSの使用説明（セクション5.7.3）の部分直径ベースプロトコル仕様に由来し、またRFC 3588.、ハンスTschofenigセキュリティセクションのレビューコメントの詳細なセットを提供し、そしてアンドリューマクドナルドのための正式な説明を提供しました最初のパケットフォーマットおよびTLSの名前マッチングアルゴリズム。クリス・ラングの実装作業は、仕様の明確性と実現可能性について客観的なフィードバックを提供する、と彼はまた、ステートマシンの説明と初期エラーカタログやフォーマットを提供しました。マグヌスウェスターは、多くの問題を特定し、ヤリArkko、ロスCallon、ブライアン・カーペンター、リサDusseault、ラースEggertの、テッドからのコメントでも、より詳細なIESGのレビューが続いた重要な明確化、につながった詳細なADの見直しを行ってハーディ、サム・ハートマン、ラスHousley、カレン
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.
ジェニングス、およびティムポーク、およびルーティングエリアの理事からのエードリアンファレルによって、非常に詳細な分析。スレシュクリシュナンは、ジェン・ARTのための詳細な検討を行いました。
[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[1]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2]ベイカー、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]デアリング、S.と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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.ブラック、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、RFC 2474、1998年12月。
[7] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[7] Nordmarkと、E.、 "ステートレス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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン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]クロッカー、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.
2010年10月、RFC 5978 "NSISプロトコルファミリを使用し、拡張" [12]ようにして、J.、ブレス、R.、Loughney、J.、およびE.デイヴィス、。
[13] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[13]カッツ、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[16] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[16]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[17] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[17]ウズラ、C.とA.ジャクソン、 "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.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[19] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[19]カーペンター、B.およびK.ムーア、 "IPv4の雲を介したIPv6ドメインの接続"、RFC 3056、2001年2月。
[20] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
、RFC 3068、2001年6月、 "6to4リレールータのエニーキャストプレフィックス" [20]のHuitema、C.、。
[21] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[21]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209年12月2001。
[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.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、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]グロスマン、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.、カマリロ、G.、ニエミ、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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルは、NATの周りにリレーを使用して（TURN）：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]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（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]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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.と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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン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.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（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.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[36] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[36]ケント、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.、オーラ、T.、モンテネグロ、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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[39] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[39]スチュワート、R.、 "ストリーム制御伝送プロトコル"、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]アウン、C.およびE.デイヴィス、 "ネットワークアドレス変換に移動する理由 - 歴史的な状態にプロトコル変換（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]ギル、V.、Heasley、J.、マイヤー、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]フロイド、S.及び通信アーキテクチャ及びプロトコルPP上V. Jacobsonの "周期的ルーティングメッセージの同期"、SIGCOMMシンポジウム。33--44、1993年9月。
[43] Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal", Work in Progress, July 2007.
[43] Pashalidis、A.およびH. Tschofenig、 "GISTレガシーNATトラバーサル"、進歩、2007年7月の作業。
[44] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", Work in Progress, July 2007.
[44] Pashalidis、A.およびH. Tschofenig、 "GIST NATトラバーサル"、進歩、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.、フー、X.、アウン、C.、およびE.デイヴィス、 "GISTステートマシン"、進歩、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.、スチュワート、R.、およびM. Dalal、 "ブラインドインウィンドウ攻撃へのTCPの頑健性を向上させる"、進歩、2010年5月での作業。
Appendix A. Bit-Level Formats and Error Messages
付録A.ビットレベルのフォーマットとエラーメッセージ
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メッセージは、ヘッダと、オブジェクトの配列からなります。 GISTヘッダは、以下の付録A.1でより詳細に記載された特定のフォーマットを有します。 NSLPメッセージはGISTメッセージ内の一つの目的です。なお、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.
次のオブジェクト図において、「//」は、可変サイズのフィールドを示すために使用され、「」は、任意に存在しているフィールドを示すために使用されます。オブジェクトの任意の部分は、パディングのために使用されるか、または送信に0に設定しなければなりません予約（個々のビットは、以下の図において「R」の場合には、マークされた「予約済み」または「RSV」または）として定義され、上で無視しなければなりません受信。
The objects are encoded using big endian (network byte order).
オブジェクトは、ビッグエンディアン（ネットワークバイトオーダー）を使用してエンコードされています。
A.1. The GIST Common Header
A.1。 GIST共通ヘッダ
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ホップ（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フラグ：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フラグ：S = 1のIP送信元アドレスは、シグナリング・ソース・アドレスと同じであれば、S = 0は、それが異なる場合。
R-flag: R=1 if a reply to this message is explicitly requested.
Rフラグ：R = 1このメッセージへの応答が明示的に要求された場合。
E-flag: E=1 if the message was explicitly routed (Section 7.1.5).
Eフラグ：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フラグの使用を管理する規則は、GISTメッセージタイプに依存します。それは、常にこれらは常に応答を誘発するので、クエリメッセージで（R = 1）設定されていない、と決して確認、データ、またはエラーメッセージでなければなりません。これは、MA-こんにちはに設定することができ、設定した場合は、他のMA-こんにちは返事を送らなければなりません。これは、レスポンスに設定してもよいが、応答がレスポンダ-クッキーが含まれている場合、設定しなければなりません。設定されている場合、確認は返信で送らなければなりません。メッセージタイプはデータメッセージでない限り、Eフラグが設定されてはいけません。
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-フラグの設定、Rフラグ、またはE-フラグ。または実行オブジェクトのセットと矛盾メッセージ長。全ての場合において、受信機は、可能な場合は、適切なサブコードと「共通ヘッダ解析エラー」メッセージ（付録A.4.4.1）を返し、さらにメッセージを処理してはいけません。
A.2. General Object Format
A.2。一般的なオブジェクトフォーマット
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.
/ 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ビットワードの整数です。必要なパディングがある場合、長さ及び位置は、オブジェクト固有の書式情報によって定義されます。可変長（例えば、ストリング）タイプを含むオブジェクトは、そうするために、追加の長さサブフィールドを含める必要があるかもしれません。
A.2.1. Object Extensibility
A.2.1。オブジェクトの拡張
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（「必須」）は：オブジェクトが理解されていない場合、それを含むメッセージ全体は、サブコード1（「認識できないオブジェクト」）と「オブジェクト・タイプ・エラー」メッセージ（付録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（「無視」）：オブジェクトが理解されていない場合、それは削除され、通常どおり処理されたメッセージの残りなければなりません。
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（「フォワード」）：オブジェクトが理解されていない場合は、メッセージ処理の結果として転送されたメッセージで不変保持するが、ローカルに格納されないことを意味します。
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を有するように認識されていないオブジェクトNSLPsに指示する必要はありませんがありません。
A.3. GIST TLV Objects
A.3。 GIST TLVオブジェクト
A.3.1. Message-Routing-Information (MRI)
A.3.1。メッセージのルーティング・インフォメーション（MRI）
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フラグ：設定された場合（N = 1）、これはNATのこのMRMを翻訳する必要がないことを意味します。もしクリア（N = 0）には、メソッド固有の情報は、NATが処理しなければならないことをネットワークまたはトランスポートレイヤ情報が含まれていることを意味します。
The remainder of the object contains method-specific addressing information, which is described below.
オブジェクトの残りの部分は、以下に記載される方法に固有のアドレス情報を含んでいます。
A.3.1.1. Path-Coupled MRM
A.3.1.1。パス、結合MRM
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フラグは、この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.
ソース/取引先プレフィックス（各8ビット）：アドレスワイルドカードのソースおよび宛先アドレスに適用されるマスクの長さ。 MRIは、特定のホストアドレスとの間のトラフィックを意味する通常の場合では、ソース/取引先プレフィックス値は両方、それぞれ、IPv4およびIPv6の32または128であろう。
P-flag: P=1 means that the Protocol field is significant.
Pフラグ：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フラグ：T = 1は、DiffServフィールド（DSフィールド）が重要であることを意味します。
DS-field (6 bits): The Diffserv field. See [6] and [24].
DSフィールド（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-フラグ：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フラグ：S = 1は、SPIフィールドが存在し、重要であることを意味します。 P-フラグが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ビット）：（ソース）のいずれかの場合、B（目的地）が設定されている、ポート番号を含む単語は、オブジェクトに含まれています。対応するフラグがセットされている場合は、各フィールドの内容は、重要です。そうでない場合、フィールドの内容は、パディングとみなし、及びMRIは、すべてのポート（すなわち、ワイルドカードとして機能する）を指します。フラグが設定されている場合、ポート= 0000は、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-フラグ：方向フラグは、以下の意味を有する：「流れと反対の方向に」値「の流れと同じ方向に」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）が返されなければなりません。
A.3.1.2. Loose-End MRM
A.3.1.2。ルースエンドMRM
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フラグは、この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.
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フィールドの値に依存します。
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-フラグ：「ネットワークのエッジに向かって」値0手段、及び「ネットワークのエッジから」値1手段は方向フラグは、以下の意味を有します。 （セクション5.8.2を参照）Q-モードメッセージのために、唯一の有効な値は、D = 0であることに注意してください。
A.3.2. Session Identifier
A.3.2。セッション識別子
Type: Session-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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.3.3. Network-Layer-Information (NLI)
A.3.3。ネットワークレイヤ情報（NLI）
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.
PI-長（8ビット）：ピアのアイデンティティ・フィールドのバイト長。
Peer Identity (variable): The Peer Identity field. Note that the Peer-Identity field itself is padded to a whole number of words.
ピア・アイデンティティ（変数）：ピアIDフィールド。ピア・アイデンティティフィールド自体が言葉の全体数に埋められていることに注意してください。
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（ゼロ）が予約されており、使用してはいけません。
A.3.4. Stack-Proposal
A.3.4。スタック提案
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.
教授・カウント（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.
セクション5.7で説明したように、Oこれは、1バイトのMA-プロトコル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.
プロファイルなし（教授・カウント= 0）が存在しない場合には、サブコード1（「値がサポートされていない」）と「オブジェクトの値エラー」メッセージ（付録A.4.4.10）が返されなければなりません。特定のプロファイルが（プロファイルの先頭バイトがゼロである）が空である場合、サブコード3（「空リスト」）が使用されなければなりません。両方の場合において、メッセージは破棄されなければなりません。
A.3.5. Stack-Configuration-Data
A.3.5。スタックの設定 - データ
Type: 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-数（8ビット）：本MA-プロトコルオプションフィールドの数（これらは、独自の長さ情報を含みます）。 MPO-Countは0であってもよいが、スタック・提案に言及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-保持時間（32ビット）：メッセージング・アソシエーションがトラフィック又はハローメッセージなしに開いた状態に保持される時間。この値はミリ秒単位で与えられていることに留意されたいので、30秒（セクション4.4.5）のデフォルト時間値0（ゼロ）30000の値に対応する予約されており、使用してはいけません。
The MA-protocol-options fields are formatted as follows:
次のように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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MA-Protocol-ID | Profile | Length |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MA-Protocol-ID (8 bits): Protocol identifier as described in Section 5.7.
MA-プロトコル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フラグ：（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.
オプションデータ（変数）：このプロトコルのための任意のオプションデータ。オプションデータの形式は、フィールドがクエリまたは応答であるかどうかに応じて異なる場合がありますので注意してください。
A.3.6. Query-Cookie
A.3.6。クエリクッキー
Type: 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を参照してください。
A.3.7. Responder-Cookie
A.3.7。レスポンダ-クッキー
Type: 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を参照してください。
A.3.8. Hello-ID
A.3.8。こんにちは-ID
Type: Hello-ID
タイプ：こんにちは-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を参照してください。
A.3.9. NAT-Traversal
A.3.9。 NATトラバーサル
Type: NAT-Traversal
タイプ：NATトラバーサル
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長（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.
タイプ数（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つのNULLバイトで埋め。
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-数（8ビット）：メッセージが横断するのNATの数、及びオブジェクトの終了時に不透明なペイロードの数。各不透明なペイロードの長さフィールドは長さフィールド自体の2つのバイトを含まないバイト数です。必要に応じて各不透明情報フィールドは、次の32ビットワード境界にゼロパディングであることに留意されたいです。
A.3.10. NSLP-Data
A.3.10。 NSLP-データ
Type: NSLP-Data
タイプ：NSLP-データ
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.
このオブジェクトはNSLPs間でデータを配信するために使用されます。 TLVの長さフィールドによって与えられるGISTは、完全な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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4. Errors
A.4。エラー
A.4.1. Error Object
A.4.1。エラーオブジェクト
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).
フラグは以下のとおりS - S = 1は、セッションIDのオブジェクトが存在することを意味します。 M - M = 1は、MRIオブジェクトが存在することを意味します。 C - C = 1デバッグコメントヘッダの後に存在することを意味します。 D - D = 1は、元のメッセージがDモードで受信されたことを意味します。 Q - Q = 1は、元のメッセージが（D = 0の場合に設定することができない）カプセル化されたQ-モードを受け取ったことを意味します。
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.
情報は、Countフィールドオブジェクト内の追加情報フィールドの数が含まれており、これらのフィールドの可能なフォーマットは、付録A.4.2に与えられています。含めるフィールドの正確なセットは、エラーコード/サブコードに依存します。エラーカタログの付録A.4.4内のすべてのエラーの説明については、ライン「追加情報：」フィールドが含まれなければならないことを述べ、これらを超えた更なるフィールドは、送信者が含まれるかもしれ、およびフィールドは、任意の順序で含まれることができます。デバッグコメントは、必要に応じて複数のヌル文字で32ビット・ワードの整数に埋めたヌルで終了するUTF-8文字列です。
A.4.2. Additional Information Fields (AI)
A.4.2。追加情報フィールド（AI）
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はAI-値の32ビットワードの数を与えます。 AI-値が存在しない場合、AI-長さ= 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.
このオブジェクトは、元のメッセージに無効であることが見出されたTLVオブジェクトに関する情報を搬送します。エラーメッセージは、複数のオブジェクトの値インフォオブジェクトを含むかもしれません。
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.
GISTノードがエラーを発見した時にオブジェクト内のバイト（16ビット）のオフセット。オブジェクトの最初のバイト= 0をオフセットしています。
Object (variable): The invalid TLV object (including the TLV header).
オブジェクト（変数）：（TLVヘッダを含む）を無効TLVオブジェクト。
A.4.3. Error Classes
A.4.3。エラークラス
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（プロトコルエラー）メッセージが原因でプロトコルエラーを拒否された（例えば、メッセージフォーマットのエラー）。
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).
A.4.4. Error Catalogue
A.4.4。エラーカタログ
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.
このセクションでは、彼らが提起されており、どのような追加情報フィールドはエラーオブジェクトで運ばなければならないときなど、すべての可能なGISTのエラーを示しています。
A.4.4.1. Common Header Parse Error
A.4.4.1。共通ヘッダ解析エラー
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フラグ：ヘッダ内のRフラグは、メッセージタイプと矛盾しています。
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-フラグ：E-フラグがヘッダに設定され、これはデータ・メッセージではありません。
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フラグ：Cフラグは、照会メッセージまたはQモードデータメッセージ以外の何かに設定し、またはクエリ・メッセージに透明でした。
A.4.4.2. Hop Limit Exceeded
A.4.4.2。ホップ制限超過します
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ノードはその要旨ホップカウントが受信にゼロまでデクリメントされた後にメッセージを転送しようとした場合、このメッセージが送信されます。このメッセージは、ルーティングループまたは小さすぎる最初のホップカウント値のいずれかを示します。
A.4.4.3. Incorrect Encapsulation
A.4.4.3。誤ったカプセル化
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モードに到着）を使用してメッセージを受信した場合、このメッセージが送信されます。
A.4.4.4. Incorrectly Delivered Message
A.4.4.4。間違って配信されたメッセージ
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上にメッセージを受信した場合、このメッセージが送信されます。
A.4.4.5. No Routing State
A.4.4.5。いいえルーティングステートありません
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節を参照してください。
A.4.4.6. Unknown NSLPID
A.4.4.6。不明NSLPID
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のための直接アドレス指定されたメッセージを受信した場合、このメッセージが送信されます。
A.4.4.7. Endpoint Found
A.4.4.7。エンドポイントが見つかりました
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のためにQueryメッセージを受信した場合、このメッセージが送信されます。
A.4.4.8. Message Too Large
A.4.4.8。大きすぎメッセージ
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を超えているので、それは転送できませんというメッセージを受信した場合、このメッセージが送信されます。
A.4.4.9. Object Type Error
A.4.4.9。オブジェクトタイプエラー
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: 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つ以上の必須オブジェクトが欠落しているメッセージを受信した場合、このサブコードが使用されます。スタック提案は、1つが必要であったときに一致するスタック構成 - データオブジェクトなしで送信され、またはその逆されている場合、このメッセージは、送信されます。
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で受信される場合、このサブコードが使用されます。
A.4.4.10. Object Value Error
A.4.4.10。オブジェクト値エラー
Class: Protocol-Error Code: 10 Additional Info: 1 or 2 Object Value Info fields as given below
クラス：プロトコル・エラーコード：10追加情報：1または2のオブジェクト値Infoフィールド下記の通り
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とスタックの提案が唯一のNULLバイトが含まれている場合は、エラーメッセージが送信される（0の長さは、「サポートされていない値」として扱われます）。
4: Invalid Cookie: The message contains a cookie that could not be verified by the node.
4：無効クッキー：メッセージがノードによって検証することができなかったクッキーを含んでいます。
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：スタック提案 - スタック構成 - データ不一致：GISTノードはスタック提案対象のデータがスタック構成データオブジェクトの情報と矛盾しているメッセージを受信した場合、このサブコードが使用されます。この場合、両方のスタック・提案オブジェクトおよびスタック・コンフィギュレーション・データオブジェクトは、そのために別のオブジェクトの値Infoフィールドに含まれなければなりません。
A.4.4.11. Invalid IP-Layer TTL
A.4.4.11。無効なIPレイヤのTTL
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層TTLで受信されたことを示す（すなわち、送信者から複数のIPホップ）。実際のIP距離は同じメッセージで運ばNLIオブジェクト内のIP-TTL情報から導出することができます。
A.4.4.12. MRI Validation Failure
A.4.4.12。 MRI検証の失敗
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:
このエラーメッセージがあるためあまりワイルドカードまたは障害のいくつかの検証チェック（参照セクション5.8.1.2）の、例えば、受け入れることができなかったMRIを用いて受信されたことを示しています。エラー発信者が問題を引き起こした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あまりにもワイルド：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バージョンの不一致：パス結合QueryメッセージにおけるMRI（セクション7.4を参照）を使用するインターフェイス上に実装、またはクエリのカプセル化のIPバージョンは異なるされていない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：イングレスフィルタ障害：パス結合QueryメッセージにおけるMRIを用いるインターフェイスにイングレスフィルタリングを通過しないであろう流れを記述する。
Appendix B. API between GIST and Signalling Applications
GISTとシグナリングアプリケーション間の付録B API
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は、特にその接続されていないUDPソケットのためのソケットAPIへの類似性を持っています。 UDP接続ソケットのためにそのようなAPIの拡張を考えることができます。この場合、例えば、プリミティブのSendMessageに必要な唯一の情報は、（NULLであることができる）NSLP-データ、NSLP-データサイズ、及びNSLP-メッセージハンドルであろう。メッセージのグループの永続的だった他の情報は、ソケットに対して一度に構成することができます。このような拡張は、具体的な実装をより効率的にするかもしれませんが、APIのセマンティクスを変更しない、ので、ここでは考慮されません。
B.1. SendMessage
B.1。メッセージを送る
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-データ、NSLP-データサイズ、NSLP-メッセージハンドル、NSLPID、セッションID、MRI、SII-ハンドル、転送属性、タイムアウト、IP-TTL、GISTホップ・カウント）
The following arguments are mandatory:
次の引数は必須です。
NSLP-Data: The NSLP message itself.
NSLP-データ：NSLPメッセージそのもの。
NSLP-Data-Size: The length of NSLP-Data.
NSLP-データサイズ：NSLP-データの長さ。
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-メッセージハンドル：後続MessageStatus通知（付録B.3）の基準とGISTで使用することができ、このメッセージのハンドル。通知は、エラー条件についてやメッセージのために使われるセキュリティ属性についてである可能性があります。 NSLPは、このような通知に興味を持っていない場合はNULLハンドルが供給されてもよいです。
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によって供給されます。
Transfer-Attributes: Attributes defining how the message should be handled (see Section 4.1.2). The following attributes can be considered:
転送属性：メッセージを処理する方法を定義する属性（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は、（このような「整合性」や「機密」として）メッセージのために要求されるセキュリティ保護のレベルを指定することができますし、送信元と送信先のアイデンティティを知らせる認証済みかを指定することも使用することができます送信するために使用すべきですメッセージ。可能性は前MessageStatusまたはRecvMessage通知からのシグナリングアプリケーションによって学習することができます。 NSLP-メッセージハンドルが提供されている場合は、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.
タイムアウト：時間GISTの長さは、エラーを示す前に、このメッセージを送信しようとすべきです。
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ホップ・カウント：ホップ数の値のメッセージを送信します。
B.2. RecvMessage
B.2。 RecvMessage
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からのシグナリングアプリケーションに渡されます。 GISTは、ヌルメッセージ（長さゼロの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-データ、NSLP-データサイズ、NSLPID、セッションID、MRI、ルーティングステートチェック、SII-ハンドル、転送属性、IP-TTL、IP-距離、GISTホップ・カウント、Inbound-インタフェース）
NSLP-Data: The NSLP message itself (may be empty).
NSLP-データ：NSLPメッセージ自体（空であってもよいです）。
NSLP-Data-Size: The length of NSLP-Data (may be zero).
NSLP-データサイズ：NSLP-データの長さ（ゼロであってもよいです）。
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:
ルーティングステートチェック：このブール値は、（4.3.2項を参照）GISTは、ルーティング状態がピアで作成する必要がありますまたはメッセージをさらに転送すべきかどうかを確認するためにシグナリングアプリケーションに確認された場合はTrueです。 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ペイロードは、それぞれ、生成された応答または転送クエリに運びます。
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).
このメカニズムは、（さらなる議論については、セクション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:
転送属性：この特定のメッセージの受信に関連した信頼性とセキュリティ属性。同様の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ホップであるかどうか）。
* 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-距離：この情報が利用できない場合、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ホップ数：ホップの値は、メッセージが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の内部または外側にあるかどうかのようなメッセージを受信したインタフェースの属性、。これらの属性は、ローカルな意味を持っており、実装によって定義されています。
B.3. MessageStatus
B.3。 MessageStatus
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.
このプリミティブは、GISTからのシグナリングアプリケーションに渡されます。送信される要求メッセージをディスパッチすることができなかった、またはメッセージ（具体的には、セキュリティ属性）のために選択された転送属性についてシグナリングアプリケーションに通知するためのシグナリングアプリケーションに通知するために使用されます。シグナリングアプリケーションは、属性が受け入れられない場合、メッセージの送信を中止する戻りコードで、このメッセージに応答することができます。
MessageStatus ( NSLP-Message-Handle, Transfer-Attributes, Error-Type )
MessageStatus（NSLP-メッセージハンドル、転送属性、エラー・タイプ）
NSLP-Message-Handle: A handle for the message provided by the signalling application in SendMessage.
NSLP-メッセージハンドル：のSendMessageでシグナリングアプリケーションによって提供されるメッセージのハンドル。
Transfer-Attributes: The reliability and security attributes that will be used to transmit this particular message.
転送-属性：この特定のメッセージを送信するために使用される信頼性とセキュリティ属性。
Error-Type: Indicates the type of error that occurred, for example, 'no next node found'.
エラー・タイプ：例えば、「は次のノードが見つからない」、発生したエラーのタイプを示します。
B.4. NetworkNotification
B.4。ネットワーク通知
This primitive is passed from GIST to a signalling application. It indicates that a network event of possible interest to the signalling application occurred.
このプリミティブは、GISTからのシグナリングアプリケーションに渡されます。これは、シグナリングアプリケーションへの可能な関心のネットワークイベントが発生したことを示します。
NetworkNotification ( NSLPID, MRI, Network-Notification-Type )
NetworkNotification（NSLPID、MRI、NetworkNotification型）
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:
ネットワーク-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を参照してください。新しいステータスが報告されています。状態が良好であれば、ピアのSII-ハンドルもRecvMessage用として、報告されています。
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.
通信障害：ピアとの通信に失敗しました。メッセージが失われた可能性があります。
B.5. SetStateLifetime
B.5。 SetStateLifetime
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、国家-寿命）
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フラグで）方向を含みます。
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は、ルーティング状態を維持することを望むために寿命を示します。
B.6. InvalidateRoutingState
B.6。 InvalidateRoutingState
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へのシグナリングアプリケーションから渡されます。これは、シグナリングアプリケーションは、ネットワークのルーティングの変更またはアプリケーションノードシグナリングの処理能力の趣旨に知られている次のシグナリングのホップがもはや有効であるという知識、のいずれかを有することを示します。 7.1節を参照してください。
InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data, NSLP-Data-Size, Urgent )
InvalidateRoutingState（NSLPID、MRI、ステータス、NSLP-データ、NSLP-データサイズ、緊急）
NSLPID: The NSLP originating the message. May be null (in which case, the invalidation applies to all signalling applications).
NSLPID：メッセージを発信するNSLP。 nullの場合もある（この場合、無効化はすべてのシグナリングのアプリケーションに適用されます）。
MRI: The flow for which routing state should be invalidated; includes the direction of the change (in the D-flag).
MRI：ルーティング状態は、無効化されるべき対象のフロー。 （Dフラグで）変化の方向を含みます。
Status: The new status that should be assumed for the routing state, one of Bad or Tentative (see Section 7.1.3).
ステータス：ルーティング状態、不良または仮の1のために想定されるべき新しいステータス（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-データ、NSLP-データサイズ：次GISTハンドシェークを使用するNSLPによって提供（任意）ペイロード。これは条件付きのピアプロセスの一部として使用することができる（セクション4.3.2参照）。ペイロードには、セキュリティ保護なしで送信されます。
Urgent: A hint as to whether rediscovery should take place immediately or only with the next signalling message.
緊急：再発見は、次のシグナリングメッセージですぐにのみ行われるべきかどうかのヒント。
Appendix C. Deployment Issues with Router Alert Options
ルータアラートオプションと付録C.展開の問題
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つの基本的な要件があります。
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パケットはまた、要件（2）が依然として適用されるため、非GISTノードに遭遇します。非GISTノードがQモードのパケットをブロックした場合、GISTは機能しません。ミドルボックスは、特定のトラフィックタイプをブロックすることは常に可能です。 Qモードのトラフィックのための通常のUDPカプセル化を使用することにより、GISTは、NATのは、少なくともこれらのメッセージ（7.2.1）を渡すことができますし、ファイアウォールは、標準的なポリシーを設定することができます。 Qモードのカプセル化は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は、2バイトの値フィールドとRAOのフォーマットを定義する、[13]によって定義されます。しかし、一つだけの値（ゼロ）を定義し、さらに割り当てのためのIANAレジストリが存在していません。それは未知の値が無視されるべきであると述べている（すなわち、通常のIPトラフィックとして転送されたパケット）。しかし、また、いくつかの既存の実装は、単に（オプション値がゼロであったかのように、すなわちRAOを有する任意のパケットを処理）が完全RAO値を無視することが報告されています。したがって、非ゼロRAO値の使用は、既存の実装にGISTのトラフィックを透明にするために依拠することはできません。 （まだIPv4の非ゼロRAO値を割り当てることができることは貴重であってもよいことに注意：これは、値フィールドを調べないノードのための傍受プロセスをより効率的になり、そして*それを無視誤っ*ノードに違いはありません。非ゼロRAO値が使用されているか否かは、GISTプロトコルの動作を変更するが、新しいNSLPsが登録されている時に決定する必要はありません。）
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:
分析の第二段階は、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パケットの「綿密に検討するには、」ノードがそれを処理する必要がないし、それを転送する必要があることを実現するために十分にインテリジェントです。これは、いずれかのノードが全くまたはUDPトラフィックを傍受された場合でも、ポート番号がローカルに設定されたものと一致しないことをRAOパケットのIP-プロトコル= 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スタックに配信します。この場合、もはや適切に処理されることが保証できません。 （それを提供するための宛先ポートにはGISTのプロセスが存在しないため）ほとんどの場合、それは単にICMPエラーでドロップまたは拒否されます。
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の実装は、行動の第二のタイプを示すことが報告されています。この結果、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.
GISTのノードは、パケットが（例えば、ICMPメッセージから）ブロックされている、又は閉塞を越えて経路上のいくつかの点を発見することができる場所を正確に特定することができる場合は、O（例えば、トレースルートの使用によって、またはテーブル分析をルーティングすることによって）、それが送ることができます任意のRAOせずにIP・イン・IP tunellingを使用して、その時点までQモードメッセージ。これはブロッキングノードの入力側の処理をバイパスし、それを超えて通常GISTの動作をピックアップ。
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.
その場合に非ゼロRAO値の使用は十分明細書において確立されている（[17]）とIANAレジストリが存在するので、IPv6での状況は、かなり異なっています。主な問題は、いくつかの実装はまだ未熟であるということです。それは、さらに分析することなく、ローカル処理のためだったかのように、たとえば、いくつかは、任意のRAO-マークされたパケットを処理します。これは、ネットワーク内（既存の標準化されたものを含む）すべてで任意RAOの使用を防止するため、そのような実装は、IPv6の一般的な展開の一部として固定されると仮定することは妥当と思われます。
Appendix D. Example Routing State Table and Handshake
付録D.例のルーティングステートテーブルと握手
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つの他のルータが一つずつをサポートしています。図はまた、ノード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のピア状態は、Eはで表示されていないことD.注にBから直接実行メッセージング・アソシエーションへのポインタであります（暗黙的にルーティング情報メッセージのアドレスを除く）状態テーブル。ルーティング状態のみ隣接ピアのために記憶されます。 （ピアの識別に加えて、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シグナリングのためのメッセージング・アソシエーションを設定GISTハンドシェイクを示します。照会ノードは、スタック構成として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コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7042 EMail: hgs+nsis@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7042 Eメール：hgs+nsis@cs.columbia.edu URI：http://www.cs.columbia.edu
Robert Hancock Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
ロバート・ハンコックRokeマナー研究オールド・ソールズベリーレーンロムジー、ハンプシャーSO51 0ZN英国
EMail: robert.hancock@roke.co.uk URI: http://www.roke.co.uk
電子メール：robert.hancock@roke.co.uk URI：http://www.roke.co.uk