Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 5971 Columbia U.
Category: Experimental R. Hancock
ISSN: 2070-1721 RMR
October 2010
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
要点：通用Internet信令传输
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.
本文档指定了协议栈，用于沿网络中每个流所采用的路径对每个流的信令消息进行路由和传输。该设计使用通用消息层（通用Internet信令传输（GIST））下的现有传输和安全协议，该层为各种信令应用提供通用服务。GIST本身不处理信令应用程序状态，但管理其自身的内部状态以及底层传输和安全协议的配置，以支持沿流路径双向传输消息。GIST与较低层传输和安全协议的结合为“信令中的下一步”（NSIS）框架的基本协议组件提供了解决方案。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5971.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
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）。框架中的几个概念源自RSVP[14]，GIST协议设计的几个方面也是如此。特定于应用程序的协议称为NSIS信令层协议（NSLP），并在单独的文档中定义。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提供了具体的解决方案。它基于通用消息层（通用Internet信令传输（GIST））下现有传输和安全协议的使用。GIST本身不处理信令应用程序状态；在这一关键方面，它不同于更高层的信令协议，如SIP、实时流协议（RTSP）和FTP的控制组件。相反，GIST管理其自身的内部状态以及底层传输和安全协议的配置，以确保代表信令应用程序在流路径的两个方向上传输信令消息。因此，GIST的目的是以便于多个信令应用程序重用的方式提供节点发现、消息路由和消息传输的通用功能。
The structure of this specification is as follows. Section 2 defines terminology, and Section 3 gives an informal overview of the protocol design principles and operation. The normative specification is contained mainly in Section 4 to Section 8. Section 4 describes the message sequences and Section 5 their format and contents. Note that the detailed bit formats are given in Appendix A. The protocol operation is captured in the form of state machines in Section 6. Section 7 describes some more advanced protocol features, and security considerations are contained in Section 8. In addition, Appendix B describes an abstract API for the service that GIST provides to signalling applications, and Appendix D provides an example message flow. Parts of the GIST design use packets with IP options to probe the network, that leads to some migration issues in the case of IPv4, and these are discussed in Appendix C.
本规范的结构如下所示。第2节定义了术语，第3节给出了协议设计原则和操作的非正式概述。本规范主要包含在第4节至第8节中。第4节描述了消息序列，第5节描述了它们的格式和内容。请注意，附录A中给出了详细的位格式。第6节以状态机的形式捕获了协议操作。第7节介绍了一些更高级的协议功能，第8节包含了安全注意事项。此外，附录B描述了GIST向信令应用程序提供的服务的抽象API，附录D提供了一个示例消息流。GIST设计的一部分使用带有IP选项的数据包来探测网络，这在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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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).
本节定义了本规范中使用的术语。图1显示了与GIST级别相关的基本实体。特别地，该图区分与流（端到端地址）或信令（相邻信令对等方的地址）相关联的不同地址类型。
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
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
>>>>>>>>>>>>>>>>> = 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]发送方：网络中作为流中数据包源的节点。发送方可以是主机，也可以是路由器（如果流实际上是聚合的话）。
[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消息而不使用任何传输层状态或安全保护的模式。数据报模式使用UDP封装，源和目标IP地址来自流定义或以前发现的邻接信息。
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）：两个明确标识的相邻对等方之间的单一连接，即给定信令源和目标地址之间的连接。消息传递关联可以使用传输协议；如果需要安全保护，它可以使用网络层安全关联，或者在内部使用传输层安全关联。消息关联是双向的：信令消息可以通过它向任一方向发送，引用任一方向的流。
[Message] Routing: Message routing describes the process of determining which is the next GIST peer along the signalling path. For signalling along a flow path, the message routing carried out by GIST is built on top of normal IP routing, that is, forwarding packets within the network layer based on their destination IP address. In this document, the term 'routing' generally refers to GIST message routing unless particularly specified.
[消息]路由：消息路由描述了确定沿信令路径的下一个GIST对等点的过程。对于沿流路径发送的信令，GIST执行的消息路由建立在正常IP路由之上，也就是说，在网络层内根据数据包的目的IP地址转发数据包。在本文件中，“路由”一词通常指GIST消息路由，除非另有规定。
Message Routing Method (MRM): There can be different algorithms for discovering the route that signalling messages should take. These are referred to as message routing methods, and GIST supports alternatives within a common protocol framework. See Section 3.3.
消息路由方法（MRM）：可以有不同的算法来发现信令消息应该采用的路由。这些被称为消息路由方法，GIST支持公共协议框架内的备选方案。见第3.3节。
Message Routing Information (MRI): The set of data item values that is used to route a signalling message according to a particular MRM; for example, for routing along a flow path, the MRI includes flow source and destination addresses, and protocol and port numbers. See Section 3.3.
消息路由信息（MRI）：用于根据特定MRM路由信令消息的一组数据项值；例如，对于沿流路径的路由，MRI包括流源和目标地址以及协议和端口号。见第3.3节。
Router Alert Option (RAO): An option that can be included in IPv4 and v6 headers to assist in the packet interception process; see [13] and [17].
路由器警报选项（RAO）：可以包含在IPv4和v6报头中的选项，以协助数据包拦截过程；见[13]和[17]。
Transfer Attributes: A description of the requirements that a signalling application has for the delivery of a particular message; for example, whether the message should be delivered reliably. See Section 4.1.2.
传输属性：对信令应用程序传递特定消息的要求的描述；例如，消息是否应该可靠地传递。见第4.1.2节。
The generic requirements identified in the NSIS framework [29] for transport of signalling messages are essentially two-fold:
NSIS框架[29]中确定的信令消息传输的一般要求基本上有两个方面：
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
在[29]中，所有这些路由和传输要求都分配给一个概念协议，NSIS传输层协议（NTLP）。分割传输问题的策略导致NTLP的分层结构，并具有专门的GIST消息传递
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.
在标准传输和安全协议上运行的层。基本概念如图2所示。请注意，并非图中暗示的所有传输和安全协议的组合实际上都可以在GIST中使用；本规范允许的实际组合见第5.7节。该图还显示了GIST通过抽象接口（GIST API）向上层提供服务，第4.1节将进一步讨论。
^^ +-------------+
|| | Signalling |
NSIS +------------|Application 2|
Signalling | Signalling +-------------+
Application |Application 1| |
Level +-------------+ |
|| | |
VV | |
========|===================|===== <-- GIST API
| |
^^ +------------------------------------------------+
|| |+-----------------------+ +--------------+ |
|| || GIST | | GIST State | |
|| || Encapsulation |<<<>>>| Maintenance | |
|| |+-----------------------+ +--------------+ |
|| | GIST: Messaging Layer |
|| +------------------------------------------------+
NSIS | | | |
Transport ..........................................
Level . Transport Layer Security (TLS or DTLS) .
(NTLP) ..........................................
|| | | | |
|| +----+ +----+ +----+ +----+
|| |UDP | |TCP | |SCTP| |DCCP| ... other
|| +----+ +----+ +----+ +----+ protocols
|| | | | |
|| .............................
|| . IP Layer Security .
|| .............................
VV | | | |
===========================|=======|=======|=======|============
| | | |
+----------------------------------------------+
| IP |
+----------------------------------------------+
^^ +-------------+
|| | 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内部有两种操作模式：
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模式）：用于具有适度延迟约束且无安全要求的小而不频繁的消息。当不存在路由状态时，使用称为查询模式（Q模式）的D模式的特殊情况。
Connection mode (C-mode): used for all other signalling traffic. In particular, it can support large messages and channel security and provides congestion control for signalling traffic.
连接模式（C模式）：用于所有其他信号传输。特别是，它可以支持大型消息和通道安全，并为信令流量提供拥塞控制。
C-mode can in principle use any stream or message-oriented transport protocol; this specification defines TCP as the initial choice. It can in principle employ specific network layer security associations, or an internal transport layer security association; this specification defines TLS as the initial choice. When GIST messages are carried in C-mode, they are treated just like any other traffic by intermediate routers between the GIST peers. Indeed, it would be impossible for intermediate routers to carry out any processing on the messages without terminating the transport and security protocols used.
C模式原则上可以使用任何面向流或消息的传输协议；本规范将TCP定义为初始选择。原则上，它可以采用特定的网络层安全关联，或内部传输层安全关联；本规范将TLS定义为初始选择。当GIST消息以C模式传输时，GIST对等点之间的中间路由器会将其视为与任何其他流量一样。实际上，中间路由器不可能在不终止所使用的传输和安全协议的情况下对消息执行任何处理。
D-mode uses UDP, as a suitable NAT-friendly encapsulation that does not require per-message shared state to be maintained between the peers. Long-term evolution of GIST is assumed to preserve the simplicity of the current D-mode design. Any extension to the security or transport capabilities of D-mode can be viewed as the selection of a different protocol stack under the GIST messaging layer; this is then equivalent to defining another option within the overall C-mode framework. This includes both the case of using existing protocols and the specific development of a message exchange and payload encapsulation to support GIST requirements. Alternatively, if any necessary parameters (e.g., a shared secret for use in integrity or confidentiality protection) can be negotiated out-of-band, then the additional functions can be added directly to D-mode by adding an optional object to the message (see Appendix A.2.1). Note that in such an approach, downgrade attacks as discussed in Section 8.6 would need to be prevented by policy at the destination node.
D-mode使用UDP作为合适的NAT友好封装，不需要在对等方之间维护每条消息的共享状态。GIST的长期演变被假定为保持当前D模式设计的简单性。D-mode安全或传输能力的任何扩展都可以被视为GIST消息层下不同协议栈的选择；这相当于在整个C模式框架中定义另一个选项。这包括使用现有协议的情况，以及支持GIST需求的消息交换和有效负载封装的具体开发。或者，如果任何必要的参数（例如，用于完整性或机密性保护的共享秘密）可以在带外协商，则可以通过向消息中添加可选对象（见附录a.2.1）将附加功能直接添加到D模式。注意，在这种方法中，第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
可以沿一条路径混合这两种模式。例如，这允许在网络边缘使用D模式，在核心使用C模式。这种组合可以使移动端点的操作更加高效，同时允许共享安全关联和传输连接用于多个流和信令应用的消息。这些的设置
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.
协议规定了使用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来传输它。两个GIST对等点之间可能存在任意数量的MAs，尽管通常情况下是零或一个，并且它们是由GIST内部的管理操作设置和拆除的。
The baseline message routing functionality in GIST is that signalling messages follow a route defined by an existing flow in the network, visiting a subset of the nodes through which it passes. This is the appropriate behaviour for application scenarios where the purpose of the signalling is to manipulate resources for that flow. However, there are scenarios for which other behaviours are applicable. Two examples are:
GIST中的基线消息路由功能是，信令消息遵循网络中现有流定义的路由，访问其通过的节点子集。这是应用程序场景的适当行为，其中信令的目的是为该流操纵资源。但是，也存在其他行为适用的场景。两个例子是：
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始终包括一个标志，用于区分信令消息可以采取的两个方向，表示为“上游”和“下游”。
o A specification of the IP-level encapsulation of the messages which probe the network to discover the adjacent peers. A downstream encapsulation must be defined; an upstream encapsulation is optional. For the path-coupled MRM, this information is given in Section 5.8.1.2 and Section 5.8.1.3. Current MRMs rely on the interception of probe messages in the data plane, but other mechanisms are also possible within the overall GIST design and would be appropriate for other types of signalling pattern.
o 消息的IP级封装规范，用于探测网络以发现相邻的对等点。必须定义下游封装；上游封装是可选的。对于路径耦合MRM，第5.8.1.2节和第5.8.1.3节给出了该信息。当前的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 验证检查应应用于探测消息的规范，例如，用于防止IP地址欺骗攻击。检查可能取决于消息的方向（上游或下游）。对于路径耦合MRM，下游有效性检查基本上是入口过滤的一种形式，也在第5.8.1.2节中讨论。
o The mechanism(s) available for route change detection, i.e., any change in the neighbour relationships that the MRM discovers. The default case for any MRM is soft-state refresh, but additional supporting techniques may be possible; see Section 7.1.2.
o 可用于路由变化检测的机制，即MRM发现的相邻关系中的任何变化。任何MRM的默认情况都是软状态刷新，但也可以使用其他支持技术；见第7.1.2节。
In addition, it should be noted that NAT traversal may require translation of fields in the MRI object carried in GIST messages (see Section 7.2.2). The generic MRI format includes a flag that must be given as part of the MRM definition, to indicate if some kind of translation is necessary. Development of a new MRM therefore includes updates to the GIST specification, and may include updates to specifications of NAT behaviour. These updates may be done in separate documents as is the case for NAT traversal for the MRMs of the base GIST specification, as described in Section 7.2.3 and [44].
此外，应注意，NAT穿越可能需要翻译GIST消息中携带的MRI对象中的字段（见第7.2.2节）。通用MRI格式包括一个标志，该标志必须作为MRM定义的一部分给出，以指示是否需要某种翻译。因此，新MRM的开发包括对GIST规范的更新，并可能包括对NAT行为规范的更新。这些更新可以在单独的文件中完成，如第7.2.3节和[44]所述，基本GIST规范MRMs的NAT遍历情况。
The MRI is passed explicitly between signalling applications and GIST; therefore, signalling application specifications must define which MRMs they require. Signalling applications may use fields in the MRI in their packet classifiers; if they use additional information for packet classification, this would be carried at the NSLP level and so would be invisible to GIST. Any node hosting a particular signalling application needs to use a GIST implementation that supports the corresponding MRMs. The GIST processing rules allow nodes not hosting the signalling application to ignore messages for it at the GIST level, so it does not matter if these nodes support the MRM or not.
MRI在信号应用程序和GIST之间显式传递；因此，信令应用规范必须定义所需的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.
GIST有六种消息类型：查询、响应、确认、数据、错误和MA Hello。除了调用C-mode使用的消息关联协议外，所有GIST通信都由这些消息组成。此外，所有信令应用程序数据在这些消息中作为附加有效载荷与GIST信息一起携带。
The Query, Response, and Confirm messages implement the handshake that GIST uses to set up routing state and messaging associations. The handshake is initiated from the Querying node towards the Responding node. The first message is the Query, which is encapsulated in a specific way depending on the message routing method, in order to probe the network infrastructure so that the correct peer will intercept it and become the Responding node. A Query always triggers a Response in the reverse direction as the second message of the handshake. The content of the Response controls whether a Confirm message is sent: as part of the defence against denial-of-service attacks, the Responding node can delay state installation until a return routability check has been performed, and require the Querying node to complete the handshake with the Confirm message. In addition, if the handshake is being used to set up a new MA, the Response is required to request a Confirm. All of these three messages can optionally carry signalling application data. The handshake is fully described in Section 4.4.1.
查询、响应和确认消息实现GIST用于设置路由状态和消息关联的握手。握手从查询节点向响应节点发起。第一条消息是查询，它根据消息路由方法以特定方式封装，以便探测网络基础设施，以便正确的对等方将拦截它并成为响应节点。查询总是以相反的方向触发响应，作为握手的第二条消息。响应的内容控制是否发送确认消息：作为防御拒绝服务攻击的一部分，响应节点可以延迟状态安装，直到执行返回路由性检查，并要求查询节点完成与确认消息的握手。此外，如果握手用于设置新的MA，则需要响应以请求确认。所有这三条消息都可以选择性地携带信令应用程序数据。握手在第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.
对等关系只能通过握手创建。当一个节点发出查询并从另一个节点获得响应时，节点成为对等节点。发出初始查询是该节点上NSLP请求的结果，查询本身根据消息路由方法的规则进行格式化。对于当前MRM，在发送查询时，响应节点的标识不明确；相反，节点沿着路径检查消息，直到一个节点决定发送响应，从而成为对等节点。如果节点承载NSLP，则本地GIST和信令应用策略确定是否对等；详情见第4.3.2节。不承载NSLP的节点透明地转发查询（第4.3.4节）。请注意，查询消息的设计（参见第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
GIST依靠网络内的路由器拦截和处理通常端到端传输的数据包。此处理可能是不透明的：消息可能经过修改后转发，也可能根本不转发。此拦截适用
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消息仅由其直接寻址的节点处理，即作为正常的Internet通信。
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无关的数据包的Internet透明度，因此GIST在本例中使用的封装（称为查询模式或Q模式）具有多个功能，以避免与其他流量发生意外冲突：
o Q-mode messages are always sent as UDP traffic, and to a specific well-known port (270) allocated by IANA.
o Q模式消息始终作为UDP通信发送，并发送到IANA分配的特定已知端口（270）。
o All GIST messages sent as UDP have a magic number as the first 32- bit word of the datagram payload.
o 作为UDP发送的所有GIST消息都有一个幻数作为数据报有效负载的第一个32位字。
Even if a node intercepts a packet as potentially a GIST message, unless it passes both these checks it will be ignored at the GIST level and forwarded transparently. Further discussion of the reception process is in Section 4.3.1 and the encapsulation in Section 5.3.
即使一个节点截获了一个可能是GIST消息的数据包，除非它通过了这两个检查，否则它将在GIST级别被忽略并透明地转发。第4.3.1节对接收过程进行了进一步讨论，第5.3节对封装进行了进一步讨论。
GIST requires signalling applications to associate each of their messages with a signalling session. Informally, given an application layer exchange of information for which some network control state information is to be manipulated or monitored, the corresponding signalling messages should be associated with the same session. Signalling applications provide the session identifier (SID) whenever they wish to send a message, and GIST reports the SID when a message is received; on messages forwarded at the GIST level, the SID is preserved unchanged. Usually, NSLPs will preserve the SID value along the entire signalling path, but this is not enforced by or even visible to GIST, which only sees the scope of the SID as the single hop between adjacent NSLP peers.
GIST要求信令应用程序将其每条消息与信令会话相关联。非正式地说，给定一个应用层信息交换，其中一些网络控制状态信息将被操纵或监视，相应的信令消息应与同一会话相关联。信令应用程序在希望发送消息时提供会话标识符（SID），GIST在收到消息时报告SID；在GIST级别转发的消息中，SID保持不变。通常，NSLP将沿整个信令路径保留SID值，但GIST不强制执行，甚至不可见，GIST只将SID的范围视为相邻NSLP对等点之间的单跳。
Most GIST processing and state information is related to the flow (defined by the MRI; see above) and signalling application (given by the NSLP identifier, see below). There are several possible relationships between flows and sessions, for example:
大多数GIST处理和状态信息与流（由MRI定义；见上文）和信令应用程序（由NSLP标识符给出，见下文）相关。流和会话之间有几种可能的关系，例如：
o The simplest case is that all signalling messages for the same flow have the same SID.
o 最简单的情况是，相同流的所有信令消息都具有相同的SID。
o Messages for more than one flow may use the same SID, for example, because one flow is replacing another in a mobility or multihoming scenario.
o 例如，多个流的消息可能使用相同的SID，因为在移动性或多归属场景中，一个流正在替换另一个流。
o A single flow may have messages for different SIDs, for example, from independently operating signalling applications.
o 单个流可能具有针对不同SID的消息，例如，来自独立运行的信令应用程序的消息。
Because of this range of options, GIST does not perform any validation on how signalling applications map between flows and sessions, nor does it perform any direct validation on the properties of the SID itself, such as any enforcement of uniqueness. GIST only defines the syntax of the SID as an opaque 128-bit identifier.
由于有这一系列选项，GIST不会对流和会话之间的信令应用程序映射方式执行任何验证，也不会对SID本身的属性执行任何直接验证，例如唯一性的任何强制。GIST仅将SID的语法定义为不透明的128位标识符。
The SID assignment has the following impact on GIST processing:
SID分配对GIST处理有以下影响：
o Messages with the same SID that are to be delivered reliably between the same GIST peers are delivered in order.
o 要在相同GIST对等方之间可靠传递的具有相同SID的消息按顺序传递。
o All other messages are handled independently.
o 所有其他消息都是独立处理的。
o GIST identifies routing state (upstream and downstream peer) by the MRI/SID/NSLPID combination.
o GIST通过MRI/SID/NSLPID组合标识路由状态（上游和下游对等）。
Strictly speaking, the routing state should not depend on the SID. However, if the routing state is keyed only by (MRI, NSLP), there is a trivial denial-of-service attack (see Section 8.3) where a malicious off-path node asserts that it is the peer for a particular flow. Such an attack would not redirect the traffic but would reroute the signalling. Instead, the routing state is also segregated between different SIDs, which means that the attacking node can only disrupt a signalling session if it can guess the corresponding SID. Normative rules on the selection of SIDs are given in Section 4.1.3.
严格地说，路由状态不应该依赖于SID。但是，如果路由状态仅由（MRI、NSLP）设置密钥，则存在一种轻微的拒绝服务攻击（参见第8.3节），其中恶意的非路径节点断言它是特定流的对等方。这种攻击不会重定向通信量，但会重新路由信号。相反，路由状态也在不同的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分配的16位NSLP标识符（NSLPID）标识（第9节）。单个信令应用程序，例如资源预留，可以定义一系列NSLP来实现其功能，例如，在层次结构中的不同级别执行信令操作（参见[21]）。然而，不同NSLP之间的交互（例如，在资源管理情况下关联聚合级别或聚合区域边界）在信令应用程序级别处理；NSLPID是GIST可以看到的关于所使用的信令应用程序的唯一信息。
GIST has two distinct security goals:
GIST有两个不同的安全目标：
o to protect GIST state from corruption, and to protect the nodes on which it runs from resource exhaustion attacks; and
o 保护GIST状态不受损坏，并保护其运行的节点不受资源耗尽攻击；和
o to provide secure transport for NSLP messages to the signalling applications.
o 为NSLP消息向信令应用程序提供安全传输。
The protocol mechanisms to achieve the first goal are mainly internal to GIST. They include a cookie exchange and return routability check to protect the handshake that sets up routing state, and a random SID is also used to prevent off-path session hijacking by SID guessing. Further details are given in Section 4.1.3 and Section 4.4.1, and the overall security aspects are discussed in Section 8.
实现第一个目标的协议机制主要是GIST内部的。它们包括cookie交换和返回可路由性检查，以保护设置路由状态的握手，并且还使用随机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模式内）中使用信道安全协议来提供第二级保护。该机制有两个目的：防止GIST上的路径攻击，并为NSLP消息提供安全通道。为了使该机制有效，它必须能够提供以下功能：
o mutual authentication of the GIST peer nodes;
o GIST对等节点的相互认证；
o ability to verify the authenticated identity against a database of nodes authorised to take part in GIST signalling;
o 能够根据授权参与GIST信令的节点数据库验证认证身份；
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 +------------+ +-----+ +-----+ +------------+
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)
>>>>>, <<<<< = Signalling messages
1 - 6 = Stages in the example
(stages 7 and 8 are not shown)
Figure 3: Example of Operation
图3：操作示例
Consider the case of an RSVP-like signalling application that makes receiver-based resource reservations for a single unicast flow. In general, signalling can take place along the entire end-to-end path (between flow source and destination), but the role of GIST is only to transfer signalling messages over a single segment of the path, between neighbouring resource-capable nodes. Basic GIST operation is the same, whether it involves the endpoints or only interior nodes: in either case, GIST is triggered by a request from a local signalling application. The example here describes how GIST transfers messages between two adjacent peers some distance along the path, GN1 and GN2 (see Figure 3). We take up the story at the point where a message is being processed above the GIST layer by the signalling application in GN1.
考虑RSVP类信令应用的情况，这使得基于单播流的基于接收器的资源保留。一般来说，信令可以沿着整个端到端路径（在流源和目的地之间）进行，但GIST的作用只是在具有资源能力的相邻节点之间通过路径的单个段传输信令消息。无论是涉及端点还是仅涉及内部节点，GIST的基本操作都是相同的：在这两种情况下，GIST都是由来自本地信令应用程序的请求触发的。这里的示例描述了GIST如何在沿着路径GN1和GN2的一段距离的两个相邻对等方之间传输消息（参见图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构造了一个携带NSLP有效负载的GIST查询，以及GIST级别的额外有效负载，这些负载将用于启动消息传递关联。查询被封装在UDP数据报中并注入网络。在IP级别，目标地址是流接收器，还包括IP路由器警报选项（RAO）。
4. The Query passes through the network towards the flow receiver, and is seen by each router in turn. GIST-unaware routers will not recognise the RAO value and will forward the message unchanged; GIST-aware routers that do not support the NSLP in question will also forward the message basically unchanged, although they may need to process more of the message to decide this after initial interception.
4. 查询通过网络到达流接收器，然后依次被每个路由器看到。路由器将不识别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.
5. 该消息在GN2被截获。GIST层将消息标识为与本地信令应用程序相关，并向上传递NSLP有效负载和流描述。GN2中的这个信令应用程序向GIST表明它将与GN1对等，因此GIST应该继续设置任何路由状态。此外，信令应用程序继续处理GN1中的消息（比较步骤1），将消息向下传递给GIST，以便将其发送到更远的下游，这将最终导致消息到达流接收器。GIST本身逐跳运行，信令应用程序将这些跳连接在一起以管理端到端信令操作。
6. In parallel, the GIST instance in GN2 now knows that it should maintain routing state and a messaging association for future signalling with GN1. This is recognised because the message is a Query, and because the local signalling application has indicated that it will peer with GN1. There are two possible cases for sending back the necessary GIST Response:
6. 同时，GN2中的GIST实例现在知道它应该维护路由状态和消息关联，以便将来与GN1进行信令。这是可以识别的，因为消息是一个查询，并且本地信令应用程序已指示它将与GN1对等。返回必要的GIST响应可能有两种情况：
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.存在关联：GN1和GN2已具有适当的MA。GN2只是记录GN1作为该流和NSLP的上游对等方的身份，并通过MA向GN1发送一个响应，将其自身标识为该流的对等方。
6.B - No Association: GN2 sends the Response in D-mode directly to GN1, identifying itself and agreeing to the messaging association setup. The protocol exchanges needed to complete this will proceed in parallel with the following stages.
6.B-无关联：GN2以D模式直接向GN1发送响应，识别自身并同意消息关联设置。完成这项工作所需的协议交换将与以下阶段并行进行。
In each case, the result is that GN1 and GN2 are now in a peering relationship for the flow.
在每种情况下，结果是GN1和GN2现在处于流的对等关系中。
7. Eventually, another NSLP message works its way upstream from the receiver to GN2. This message contains a description of the actual resources requested, along with authorisation and other security information. The signalling application in GN2 passes this payload to the GIST level, along with the flow definition and transfer attributes; in this case, it could request reliable transmission and use of a secure channel for integrity protection. (Other combinations of attributes are possible.)
7. 最终，另一条NSLP消息从接收器向上到达GN2。此消息包含请求的实际资源的描述，以及授权和其他安全信息。GN2中的信令应用程序将此有效负载连同流定义和传输属性一起传递到GIST级别；在这种情况下，它可以请求可靠传输并使用安全通道进行完整性保护。（其他属性组合也是可能的。）
8. The GIST layer in GN2 identifies the upstream peer for this flow and NSLP as GN1, and determines that it has an MA with the appropriate properties. The message is queued on the MA for transmission; this may incur some delay if the procedures begun in step 6.B have not yet completed.
8. GN2中的GIST层将此流的上游对等方和NSLP标识为GN1，并确定其具有具有适当属性的MA。消息在MA上排队等待传输；如果在步骤6.B中开始的程序尚未完成，这可能会导致一些延迟。
Further messages can be passed in each direction in the same way. The GIST layer in each node can in parallel carry out maintenance operations such as route change detection (see Section 7.1).
进一步的消息可以以相同的方式在每个方向传递。每个节点中的GIST层可以并行执行维护操作，如路线变化检测（见第7.1节）。
It should be understood that several of these details of GIST operations can be varied, either by local policy or according to signalling application requirements. The authoritative details are contained in the remainder of this document.
应该理解的是，GIST操作的一些细节可以根据本地政策或信令应用要求而变化。权威详细信息包含在本文件的其余部分中。
This section defines the basic structure and operation of GIST. Section 4.1 describes the way in which GIST interacts with local signalling applications in the form of an abstract service interface. Section 4.2 describes the per-flow and per-peer state that GIST maintains for the purpose of transferring messages. Section 4.3 describes how messages are processed in the case where any necessary messaging associations and routing state already exist; this includes
本节定义了GIST的基本结构和操作。第4.1节描述了GIST以抽象服务接口的形式与本地信令应用程序交互的方式。第4.2节描述了GIST为传输消息而维护的每流和每对等状态。第4.3节描述了在已经存在任何必要的消息关联和路由状态的情况下如何处理消息；这包括
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.
纯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.
在服务接口上看不到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可能会丢弃不可靠传递的消息，但对于可靠消息，GIST必须将流控制条件传播回发送方。因此，应用程序必须意识到，它们可能会被阻止自己发送出站消息。
Message transfer attributes are used by NSLPs to define minimum required levels of message processing. The attributes available are as follows:
NSLP使用消息传输属性来定义所需的最小消息处理级别。可用的属性如下所示：
Reliability: This attribute may be 'true' or 'false'. When 'true', the following rules apply:
可靠性：此属性可能为“真”或“假”。如果为“true”，则适用以下规则：
* messages MUST be delivered to the signalling application in the peer exactly once or not at all;
* 消息必须准确地传递到对等方的信令应用程序一次，或者根本不传递；
* for messages with the same SID, the delivery MUST be in order;
* 对于具有相同SID的消息，传递必须有序；
* if there is a chance that the message was not delivered (e.g., in the case of a transport layer error), an error MUST be indicated to the local signalling application identifying the routing information for the message in question.
* 如果消息有可能未被传递（例如，在传输层错误的情况下），则必须向本地信令应用程序指示一个错误，以标识所讨论消息的路由信息。
GIST implements reliability by using an appropriate transport protocol within a messaging association, so mechanisms for the detection of message loss depend on the protocol in question; for the current specification, the case of TCP is considered in Section 5.7.2. When 'false', a message may be delivered, once, several times, or not at all, with no error indications in any of these cases.
GIST通过在消息关联中使用适当的传输协议来实现可靠性，因此用于检测消息丢失的机制取决于所讨论的协议；对于当前规范，第5.7.2节考虑了TCP的情况。当“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
安全性：此属性定义信令应用程序对消息所需的一组安全属性，包括所需的保护类型，以及信令源和目标应使用哪些经过身份验证的标识。该信息映射到C模式下对等方之间建立的安全关联的相应属性上。安全关联的密钥材料由消息传递关联协议本身内的认证机制建立；见第8.2节。该属性可以由信令应用程序显式指定，也可以由GIST报告给信令应用程序。后者可以发生
either on receiving a message, or just before sending a message but after configuring or selecting the messaging association to be used for it.
在接收消息时，或在发送消息之前，但在配置或选择要用于该消息的消息关联之后。
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也可能请求不使用它，这将导致GIST数据消息以Q模式发送。
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].
小岛屿发展中国家索引路由状态（见下文第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层可以维护消息路由状态，以管理传出消息的处理。此状态在概念上组织为具有以下结构的表。表中的每一行对应于以下三项的唯一组合：
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）：这是IANA分配的标识符，与为该流生成消息的NSLP关联；见第3.8节。包含此标识符允许不同NSLP的路由状态不同。
The information associated with a given MRI/SID/NSLPID combination consists of the routing state to reach the peer in the direction given by the MRI. For any flow, there will usually be two entries in the table, one each for the upstream and downstream MRI. The routing state includes information about the peer identity (see Section 4.4.3), and a UDP port number for D-mode, or a reference to one or more MAs for C-mode. Entries in the routing state table are created by the GIST handshake, which is described in more detail in Section 4.4.
与给定MRI/SID/NSLPID组合相关联的信息包括沿MRI给定方向到达对等方的路由状态。对于任何流量，表中通常有两个条目，上游和下游MRI各一个。路由状态包括关于对等身份的信息（见第4.4.3节），D模式的UDP端口号，或C模式的一个或多个MAs参考。路由状态表中的条目是通过GIST握手创建的，第4.4节对此进行了更详细的描述。
It is also possible for the state information for either direction to be empty. There are several possible cases:
任一方向的状态信息也可能为空。有几种可能的情况：
o The signalling application has indicated that no messages will actually be sent in that direction.
o 信令应用程序表明，实际上不会向该方向发送任何消息。
o The node is the endpoint of the signalling path, for example, because it is acting as a proxy, or because it has determined that there are no further signalling nodes in that direction.
o 该节点是信令路径的端点，例如，因为它充当代理，或者因为它已确定该方向上没有其他信令节点。
o The node is using other techniques to route the message. For example, it can send it in Q-mode and rely on the peer to intercept it.
o 节点正在使用其他技术路由消息。例如，它可以在Q模式下发送，并依靠对等方进行拦截。
In particular, if the node is a flow endpoint, GIST will refuse to create routing state for the direction beyond the end of the flow (see Section 4.3.3). Each entry in the routing state table has an associated validity timer indicating for how long it can be considered accurate. When this timer expires, the entry MUST be purged if it has not been refreshed. Installation and maintenance of routing state are described in more detail in Section 4.4.
特别是，如果节点是流端点，GIST将拒绝为流端点以外的方向创建路由状态（参见第4.3.3节）。路由状态表中的每个条目都有一个关联的有效性计时器，指示它可以被视为准确的时间长度。此计时器过期时，如果未刷新条目，则必须清除该条目。第4.4节详细介绍了布线状态的安装和维护。
The per-flow message routing state is not the only state stored by GIST. There is also the state required to manage the MAs. Since these are not per-flow, they are stored separately from the routing state, including the following per-MA information:
每流消息路由状态不是GIST存储的唯一状态。还有管理MAs所需的状态。由于这些不是每流，因此它们与路由状态分开存储，包括以下每毫安信息：
o a queue of any messages that require the use of an MA, pending transmission while the MA is being established;
o 需要使用MA的任何消息的队列，在MA建立期间等待传输；
o the time since the peer re-stated its desire to keep the MA open (see Section 4.4.5).
o 对等方重新声明其希望保持MA开放的时间（见第4.4.5节）。
In addition, per-MA state, such as TCP port numbers or timer information, is held in the messaging association protocols themselves. However, the details of this state are not directly visible to GIST, and they do not affect the rest of the protocol description.
此外，每MA状态（如TCP端口号或计时器信息）保存在消息关联协议本身中。但是，GIST无法直接看到此状态的详细信息，并且不会影响协议描述的其余部分。
This section describes how signalling application messages are processed in the case where any necessary messaging associations and routing state are already in place. The description is divided into several parts. First, message reception, local processing, and message transmission are described for the case where the node hosts the NSLPID identified in the message. Second, in Section 4.3.4, the case where the message is handled directly in the IP or GIST layer (because there is no matching signalling application on the node) is given. An overview is given in Figure 4. This section concentrates on the GIST-level processing, with full details of IP and transport layer encapsulation in Section 5.3 and Section 5.4.
本节描述了在任何必要的消息关联和路由状态已经存在的情况下，如何处理信令应用程序消息。描述分为几个部分。首先，针对节点承载消息中标识的NSLPID的情况，描述消息接收、本地处理和消息传输。其次，在第4.3.4节中，给出了直接在IP或GIST层处理消息的情况（因为节点上没有匹配的信令应用程序）。图4给出了一个概述。本节主要介绍GIST级处理，第5.3节和第5.4节详细介绍了IP和传输层封装。
+---------------------------------------------------------+
| >> Signalling Application Processing >> |
| |
+--------^---------------------------------------V--------+
^ NSLP NSLP V
^ Payloads Payloads V
+--------^---------------------------------------V--------+
| >> GIST >> |
| ^ ^ ^ Processing V V V |
+--x-----------N--Q---------------------Q--N-----------x--+
x N Q Q N x
x N Q>>>>>>>>>>>>>>>>>>>>>Q N x
x N Q Bypass at Q N x
+--x-----+ +--N--Q--+ GIST level +--Q--N--+ +-----x--+
| C-mode | | D-mode | | D-mode | | C-mode |
|Handling| |Handling| |Handling| |Handling|
+--x-----+ +--N--Q--+ +--Q--N--+ +-----x--+
x N Q Q N x
x NNNNNN Q>>>>>>>>>>>>>>>>>>>>>Q NNNNNN x
x N Q Bypass at Q N x
+--x--N--+ +-----Q--+ IP (router +--Q-----+ +--N--x--+
|IP Host | | Q-mode | alert) level | Q-mode | |IP Host |
|Handling| |Handling| |Handling| |Handling|
+--x--N--+ +-----Q--+ +--Q-----+ +--N--x--+
x N Q Q N x
+--x--N-----------Q--+ +--Q-----------N--x--+
| IP Layer | | IP Layer |
| (Receive Side) | | (Transmit Side) |
+--x--N-----------Q--+ +--Q-----------N--x--+
x N Q Q N x
x N Q Q N x
+---------------------------------------------------------+
| >> 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
nnnnnnnnnnnnnnnnnn=正常D模式消息QQQQQQQ=Q模式封装的D模式消息XXXXXXXXXXXXX=C模式消息RAO=路由器警报选项
Figure 4: Message Paths through a GIST Node
图4：通过GIST节点的消息路径
Messages can be received in C-mode or D-mode.
消息可以在C模式或D模式下接收。
Reception in C-mode is simple: incoming packets undergo the security and transport treatment associated with the MA, and the MA provides complete messages to the GIST layer for further processing.
C模式下的接收很简单：传入的数据包经过与MA相关的安全和传输处理，MA向GIST层提供完整的消息以供进一步处理。
Reception in D-mode depends on the message type.
D模式下的接收取决于消息类型。
Normal encapsulation: Normal messages arrive UDP-encapsulated and addressed directly to the receiving signalling node, at an address and port learned previously. Each datagram contains a single message, which is passed to the GIST layer for further processing, just as in the C-mode case.
正常封装：正常消息通过UDP封装到达，并直接发送到接收信令节点，地址和端口为之前了解到的地址和端口。每个数据报包含一条消息，该消息被传递到GIST层进行进一步处理，就像C模式的情况一样。
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封装的，如果MRM需要，还可能包括IP路由器警报选项（RAO）。因此，每个GIST节点都可以看到每一条这样的消息，但除非消息完全符合Q模式封装规则（第5.3.2节），否则必须在IP级别透明地转发。如果匹配，GIST必须检查公共标头中的NSLPID。下文第4.3.4节考虑了NSLPID与本地信令应用完全不匹配的情况；否则，必须将消息传递到GIST层进行进一步处理。
Several different RAO values may be used by the NSIS protocol suite. GIST itself does not allocate any RAO values (for either IPv4 or IPv6); an assignment is made for each NSLP using MRMs that use the RAO in the Q-mode encapsulation. The assignment rationale is discussed in a separate document [12]. The RAO value assigned for an NSLPID may be different for IPv4 and IPv6. Note the different significance between the RAO and the NSLPID values: the meaning of a message (which signalling application it refers to, whether it should be processed at a node) is determined only from the NSLPID; the role of the RAO value is simply to allow nodes to pre-filter which IP datagrams are analysed to see if they might be Q-mode GIST messages.
NSIS协议套件可以使用几个不同的RAO值。GIST本身不分配任何RAO值（对于IPv4或IPv6）；使用在Q模式封装中使用RAO的MRMs为每个NSLP进行分配。分配理由在单独的文件[12]中讨论。对于IPv4和IPv6，为NSLPID分配的RAO值可能不同。注意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.
对于与NSI相关的所有任务，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.
在查询的情况下，会与信令应用程序进行交互，以确定要遵循两个过程中的哪一个。如果节点是查询消息的最终目的地，则必须选择第一个选项（对等）。
1. The receiving signalling application wishes to become a signalling peer with the Querying node. GIST MUST continue with the handshake process to set up message routing state, as described in Section 4.4.1. The application MAY provide an NSLP payload for the same NSLPID, which GIST will transfer in the Response.
1. 接收信令应用程序希望成为查询节点的信令对等方。GIST必须继续进行握手过程，以设置消息路由状态，如第4.4.1节所述。应用程序可以为相同的NSLPID提供NSLP有效载荷，GIST将在响应中传输该有效载荷。
2. The signalling application does not wish to set up state with the Querying node and become its peer. This includes the case where a node wishes to avoid taking part in the signalling for overload protection reasons. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. Note that if the node that finally processes the Query returns an Error message, this will be sent directly back to the originating node, bypassing any forwarders. For these diagnostics to be meaningful, any GIST node forwarding a Query, or relaying it with modified NSLP payload, MUST NOT modify it except in the GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation.
2. 信令应用程序不希望与查询节点建立状态并成为其对等节点。这包括节点出于过载保护的原因希望避免参与信令的情况。GIST必须传播查询，类似于第4.3.4节中描述的情况。不会将任何消息发送回查询节点。应用程序可以为相同的NSLPID提供更新的NSLP有效载荷，该有效载荷将用于GIST转发的查询中。请注意，如果最终处理查询的节点返回错误消息，则会绕过任何转发器，直接将其发送回原始节点。为了使这些诊断有意义，任何转发查询或使用修改后的NSLP有效负载中继查询的GIST节点不得修改它，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:
对于除查询以外的所有GIST消息类型，如果消息包含NSLP有效负载，则必须在本地将其传递到由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);
2. 否则，如果消息到达的关联与消息中给出的MRI/NSLPID/SID组合无关，则必须拒绝该消息，并发出“错误传递消息”错误消息（附录A.4.4.4）；
3. else, if there is no routing state for this MRI/SID/NSLPID combination, the message MUST either be dropped or be rejected with an error message (see Section 4.4.6 for further details);
3. 否则，如果此MRI/SID/NSLPID组合没有路由状态，则必须删除该消息或拒绝该消息并显示错误消息（有关详细信息，请参阅第4.4.6节）；
4. else, the payload is delivered as normal.
4. 否则，有效载荷将正常交付。
Signalling applications can generate their messages for transmission, either asynchronously or in reply to an input message delivered by GIST, and GIST can also generate messages autonomously. GIST MUST verify that it is not the direct destination of an outgoing message, and MUST reject such messages with an error indication to the signalling application. When the message is generated by a signalling application, it may be carried in a Query if local policy and the message transfer attributes allow it; otherwise, this may trigger setup of an MA over which the NSLP payload is sent in a Data message.
信令应用程序可以异步或响应GIST提供的输入消息生成其传输消息，GIST也可以自主生成消息。GIST必须验证它不是传出消息的直接目的地，并且必须拒绝向信令应用程序发出错误指示的此类消息。当消息由信令应用程序生成时，如果本地策略和消息传输属性允许，则可以在查询中携带该消息；否则，这可能触发在数据消息中发送NSLP有效负载的MA的设置。
Signalling applications may specify a value to be used for the GIST hop count; otherwise, GIST selects a value itself. GIST MUST reject messages for which the signalling application has specified a value of zero. Although the GIST hop count is only intended to control message looping at the GIST level, the GIST API (Appendix B) provides the incoming hop count to the NSLPs, which can preserve it on outgoing messages as they are forwarded further along the path. This provides a lightweight loop-control mechanism for NSLPs that do not define anything more sophisticated. Note that the count will be decremented on forwarding through every GIST-aware node. Initial values for the GIST hop count are an implementation matter; one suitable approach is to use the same algorithm as for IP TTL setting [1].
信令应用可指定用于GIST跳数的值；否则，GIST会自行选择一个值。GIST必须拒绝信令应用程序已指定值为零的消息。尽管GIST跃点计数仅用于控制GIST级别的消息循环，但GIST API（附录B）向NSLP提供传入跃点计数，当传出消息沿着路径进一步转发时，NSLP可以将其保留在传出消息上。这为NSLP提供了一个轻量级的循环控制机制，它没有定义任何更复杂的内容。请注意，在通过每个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
当消息可用于传输时，GIST使用内部策略和存储的路由状态来确定如何处理该消息。以下处理同样适用于本地生成的消息和从GIST或信令中转发的消息
application levels. However, see Section 5.6 for special rules applying to the transmission of Error messages by 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 拥塞控制：如果可以设置路由状态并使用C模式，则不应将D模式用于信令，除非网络可以设计为在GIST规定的速率控制限制内保证D模式流量的容量（见第5.3.3节）。
In principle, as well as determining that some messaging association must be used, GIST MAY select between a set of alternatives, e.g., for load sharing or because different messaging associations provide different transport or security attributes. For the case of reliable delivery, GIST MUST NOT distribute messages for the same session over multiple messaging associations in parallel, but MUST use a single association at any given time. The case of moving over to a new association is covered in Section 4.4.5.
原则上，除了确定必须使用某些消息关联外，GIST还可以在一组备选方案之间进行选择，例如，为了负载共享或因为不同的消息关联提供不同的传输或安全属性。对于可靠传递的情况，GIST不得通过多个消息关联并行地分发同一会话的消息，但必须在任何给定时间使用单个关联。第4.4.5节介绍了转移到新协会的情况。
If the use of a messaging association (i.e., C-mode) is selected, the message is queued on the association found from the routing state table, and further output processing is carried out according to the details of the protocol stacks used. If no appropriate association exists, the message is queued while one is created (see Section 4.4.1), which will trigger the exchange of additional GIST messages. If no association can be created, this is an error condition, and should be indicated back to the local signalling application.
如果选择使用消息关联（即，C模式），则消息将在路由状态表中找到的关联上排队，并根据所用协议栈的详细信息执行进一步的输出处理。如果不存在适当的关联，则在创建关联时将消息排入队列（参见第4.4.1节），这将触发其他GIST消息的交换。如果无法创建关联，则这是一种错误情况，应将其指示回本地信令应用程序。
If a messaging association is not appropriate, the message is sent in D-mode. The processing in this case depends on the message type, local policy, and whether or not routing state exists.
如果消息关联不合适，则以D模式发送消息。这种情况下的处理取决于消息类型、本地策略以及路由状态是否存在。
o If the message is not a Query, and local policy does not request the use of Q-mode for this message, and routing state exists, it is sent with the normal D-mode encapsulation directly to the address from the routing state table.
o 如果该消息不是查询，并且本地策略不请求对此消息使用Q模式，并且存在路由状态，则它将通过正常的D模式封装直接从路由状态表发送到地址。
o If the message is a Query, or the message is Data and local policy as given by the message transfer attributes requests the use of Q-mode, then it is sent in Q-mode as defined in Section 5.3.2; the details depend on the message routing method.
o 如果消息是查询，或消息是数据，且消息传输属性给出的本地策略要求使用Q模式，则按照第5.3.2节中的定义以Q模式发送；详细信息取决于消息路由方法。
o If no routing state exists, GIST can attempt to use Q-mode as in the Query case: either sending a Data message with the Q-mode encapsulation or using the event as a trigger for routing state setup (see Section 4.4). If this is not possible, e.g., because the encapsulation for the MRM is only defined for one message direction, then this is an error condition that is reported back to the local signalling application.
o 如果不存在路由状态，GIST可以尝试使用查询案例中的Q模式：发送带有Q模式封装的数据消息或使用事件作为路由状态设置的触发器（参见第4.4节）。如果这是不可能的，例如，因为MRM的封装仅为一个消息方向定义，则这是一个错误情况，将报告回本地信令应用程序。
A node may receive messages where it has no signalling application corresponding to the message NSLPID. There are several possible cases depending mainly on the encapsulation:
节点可以在其没有对应于消息NSLPID的信令应用的情况下接收消息。有几种可能的情况主要取决于封装：
1. A message contains an RAO value that is relevant to NSIS, but it does not exactly match the Q-mode encapsulation rules of Section 5.3.2. The message MUST be transparently forwarded at the IP layer. See Section 3.6.
1. 消息包含与NSIS相关的RAO值，但与第5.3.2节的Q模式封装规则不完全匹配。消息必须在IP层透明转发。见第3.6节。
2. A Q-mode encapsulated message contains an RAO value that has been assigned to some NSIS signalling application but that is not used on this specific node, but the IP layer is unable to distinguish whether it needs to be passed to GIST for further processing or whether the packet should be forwarded just like a normal IP datagram.
2. Q模式封装的消息包含一个RAO值，该值已分配给某些NSIS信令应用程序，但未在该特定节点上使用，但IP层无法区分是否需要将其传递给GIST进行进一步处理，或者是否应像普通IP数据报一样转发该数据包。
3. A Q-mode encapsulated message contains an RAO value that has been assigned to an NSIS signalling application that is used on this node, but the signalling application does not process the NSLPID in the message. (This covers the case where a signalling application uses a set of NSLPIDs.)
3. Q模式封装消息包含已分配给此节点上使用的NSIS信令应用程序的RAO值，但信令应用程序不处理消息中的NSLPID。（这包括信令应用程序使用一组NSLPID的情况。）
4. A directly addressed message (in D-mode or C-mode) is delivered to a node for which there is no corresponding signalling application. With the current specification, this should not happen in normal operation. While future versions might find a use for such a feature, currently this MUST cause an "Unknown NSLPID" error message (Appendix A.4.4.6).
4. 直接寻址消息（在D模式或C模式下）被传送到没有相应信令应用程序的节点。根据当前规范，正常操作中不应出现这种情况。虽然将来的版本可能会使用这种功能，但目前这必须导致“未知NSLPID”错误消息（附录a.4.4.6）。
5. A Q-mode encapsulated message arrives at the end-system that does not handle the signalling application. This is possible in normal operation, and MUST be indicated to the sender with an "Endpoint Found" informational message (Appendix A.4.4.7). The end-system includes the MRI and SID from the original message in the error message without interpreting them.
5. Q模式封装消息到达不处理信令应用程序的终端系统。这在正常操作中是可能的，并且必须向发送方显示“找到端点”信息消息（附录A.4.4.7）。终端系统包括错误消息中原始消息中的MRI和SID，而不解释它们。
6. The node is a GIST-aware NAT. See Section 7.2.
6. 该节点是一个支持GIST的NAT。见第7.2节。
In case (2) and (3), the role of GIST is to forward the message essentially as though it were a normal IP datagram, and it will not become a peer to the node sending the message. Forwarding with modified NSLP payloads is covered above in Section 4.3.2. However, a GIST implementation MUST ensure that the IP-layer TTL field and GIST hop count are managed correctly to prevent message looping, and this should be done consistently independently of where in the packet processing path the decision is made. The rules are that in cases (2) and (3), the IP-layer TTL MUST be decremented just as if the message was a normal IP forwarded packet. In case (3), the GIST hop count MUST be decremented as in the case of normal input processing, which also applies to cases (4) and (5).
在案例（2）和（3）中，GIST的作用是转发消息，本质上就像转发普通IP数据报一样，并且它不会成为发送消息的节点的对等方。上文第4.3.2节介绍了使用修改后的NSLP有效载荷进行转发。然而，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:
以这种方式处理Q模式封装消息的GIST节点应根据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）返回给发送方，发送方应开始消息关联设置。
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. 跳数已达到零。应将错误“超出跃点限制”（附录A.4.4.2）返回给发送方，发送方可使用较大的初始跃点计数重试。
3. The MRI represents a flow definition that is too general to be forwarded along a unique path (e.g., the destination address prefix is too short). The error "MRI Validation Failure" (Appendix A.4.4.12) with subcode 0 ("MRI Too Wild") SHOULD be returned to the sender, which MAY retry with restricted MRIs, possibly starting additional signalling sessions to do so. If the GIST node does not understand the MRM in question, it MUST NOT apply this check, instead forwarding the message transparently.
3. MRI表示的流定义过于笼统，无法沿唯一路径转发（例如，目标地址前缀太短）。子代码为0（“MRI太野”）的错误“MRI验证失败”（附录A.4.4.12）应返回给发送方，发送方可使用受限MRI重试，可能会启动额外的信令会话来执行此操作。如果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.
在前两种情况下，只检查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:
状态安装和刷新有两种不同的情况：
1. Where routing state is being discovered or a new association is to be established; and
1. 正在发现路由状态或要建立新关联的位置；和
2. Where a suitable association already exists, including the case where routing state for the flow is being refreshed.
2. 已经存在适当关联的情况，包括正在刷新流的路由状态的情况。
These cases are now considered in turn, followed by the case of background general management procedures.
现在依次审议这些案例，然后审议背景一般管理程序。
The message sequence for GIST state setup between peers is shown in Figure 5 and described in detail below. The figure informally summarises the contents of each message, including optional elements in square brackets. An example is given in Appendix D.
对等点之间GIST状态设置的消息序列如图5所示，并在下面详细描述。该图非正式地总结了每条消息的内容，包括方括号中的可选元素。附录D中给出了一个示例。
The first message in any routing state maintenance operation is a Query, sent from the Querying node and intercepted at the responding node. This message has addressing and other identifiers appropriate for the flow and signalling application that state maintenance is being done for, addressing information about the node that generated the Query itself, and MAY contain an NSLP payload. It also includes a Query-Cookie, and optionally capability information about messaging association protocol stacks. The role of the cookies in this and later messages is to protect against certain denial-of-service attacks and to correlate the events in the message sequence (see Section 8.5 for further details).
任何路由状态维护操作中的第一条消息都是查询，从查询节点发送并在响应节点截获。该消息具有适合于正在进行状态维护的流和信令应用程序的寻址和其他标识符，寻址关于生成查询本身的节点的信息，并且可能包含NSLP负载。它还包括一个查询Cookie，以及关于消息传递关联协议栈的可选功能信息。Cookie在该消息和以后的消息中的作用是防止某些拒绝服务攻击，并将消息序列中的事件关联起来（有关更多详细信息，请参阅第8.5节）。
+----------+ +----------+
| Querying | |Responding|
| Node(Q-N)| | Node(R-N)|
+----------+ +----------+
Query .............
----------------------> . .
Router Alert Option . Routing .
MRI/SID/NSLPID . state .
Q-N Network Layer Info . installed .
Query-Cookie . at .
[Q-N Stack-Proposal . Responding.
Q-N Stack-Config-Data] . node .
[NSLP Payload] . (case 1) .
.............
......................................
. The responder can use an existing .
. messaging association if available .
. from here onwards to short-circuit .
. messaging association setup .
......................................
+----------+ +----------+
| 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]
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 .
....................................
....................................
. 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) .
.............
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节），则接收查询必须引发响应。这是一个通常封装的D模式消息，带有额外的GIST有效载荷。它包含关于响应节点的网络层信息，回显查询Cookie，并且可能包含NSLP有效负载，可能是对初始消息中NSLP有效负载的回复。在请求消息关联的情况下，它还必须包含响应者Cookie及其自身关于消息关联协议栈的功能信息。即使未请求消息关联，如果节点的路由状态设置策略需要，响应也可能包含响应器Cookie（请参见下文）。
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绑定，或者因为它引用了传输协议的敏捷目标端口。exchange承载能力中包含的堆栈建议和堆栈配置数据对象包含有关可以使用哪些消息关联协议的信息，第5.7节将更详细地描述这些对象的处理。根据当前定义的协议选项，消息传递关联的设置始终从查询节点开始，尽管在整个GIST设计中可以进行更灵活的配置。如果消息关联包括通道安全协议，则每个GIST节点必须根据其授权的对等数据库验证对等方的身份验证，如果不匹配，则必须拆除消息关联。下文第4.4.2节详细介绍了数据库和授权检查。请注意，验证可能取决于MA的用途（例如，用于哪个MRI或会话），因此该步骤可能无法在验证完成后立即执行，但需要一段时间。
Finally, after any necessary messaging association setup has completed, a Confirm MUST be sent if the Response requested it. Once the Confirm has been sent, the Querying node assumes that routing state has been installed at the responder, and can send normal Data messages for the flow in question; recovery from a lost Confirm is discussed in Section 5.3.3. If a messaging association is being used, the Confirm MUST be sent over it before any other messages for the same flow, and it echoes the Responder-Cookie and Stack-Proposal from the Response. The former is used to allow the receiver to validate the contents of the message (see Section 8.5), and the latter is to prevent certain bidding-down attacks on messaging association security (see Section 8.6). This first Confirm on a new
最后，在完成任何必要的消息关联设置后，如果响应请求确认，则必须发送确认。一旦发送了确认，查询节点就假设路由状态已经安装在响应方，并且可以为所讨论的流发送正常的数据消息；第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 Hold Time值的堆栈配置数据对象，该值将取代原始查询中给定的值。在收到确认后，该关联可用于确认中携带的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:
在验证响应中的查询Cookie后，查询节点必须安装从R节点网络层信息派生的响应者地址作为路由状态信息。响应节点可以在两个时间点将查询地址安装为对等状态信息：
Case 1: after the receipt of the initial Query, or
案例1：收到初始查询后，或
Case 2: after a Confirm containing the Responder-Cookie.
案例2：确认包含响应者Cookie后。
The Responding node SHOULD derive the peer address from the Q-Node Network Layer Info if this was decoded successfully. Otherwise, it MAY be derived from the IP source address of the message if the common header flags this as being the signalling source address. The precise constraints on when state information is installed are a matter of security policy considerations on prevention of denial-of-service attacks and state poisoning attacks, which are discussed further in Section 8. Because the Responding node MAY choose to delay state installation as in case (2), the Confirm must contain sufficient information to allow it to be processed in the same way as the original Query. This places some special requirements on NAT traversal and cookie functionality, which are discussed in Section 7.2 and Section 8 respectively.
如果成功解码，响应节点应从Q节点网络层信息中获取对等地址。否则，如果公共报头将消息的IP源地址标记为信令源地址，则可以从该消息的IP源地址派生。安装状态信息的确切时间限制是关于防止拒绝服务攻击和状态中毒攻击的安全策略考虑事项，将在第8节中进一步讨论。由于响应节点可能会选择延迟状态安装，如案例（2）所示，因此确认必须包含足够的信息，以允许以与原始查询相同的方式对其进行处理。这对NAT遍历和cookie功能提出了一些特殊要求，分别在第7.2节和第8节中讨论。
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:
当两个GIST节点使用消息关联进行身份验证时，两端必须决定是否接受MA的创建以及是否信任通过MA发送的信息。这可视为授权决定：
o Authorised peers are trusted to install correct routing state about themselves and not, for example, to claim that they are on-path for a flow when they are not.
o 授权的对等方被信任为自己安装正确的路由状态，例如，当它们不在某个流的路径上时，不会声称它们在该路径上。
o Authorised peers are trusted to obey transport- and application-level flow control rules, and not to attempt to create overload situations.
o 授权的对等方可以遵守传输和应用程序级别的流控制规则，并且不会试图造成过载情况。
o Authorised peers are trusted not to send erroneous or malicious error messages, for example, asserting that routing state has been lost when it has not.
o 授权的对等方被信任不会发送错误或恶意的错误消息，例如，当路由状态未丢失时，会断言路由状态已丢失。
This specification models the decision as verification by the authorising node of the peer's identity against a local list of peers, the authorised peer database (APD). The APD is an abstract construct, similar to the security policy database of IPsec [36]. Implementations MAY provide the associated functionality in any way they choose. This section defines only the requirements for APD administration and the consequences of successfully validating a peer's identity against it.
本规范将决策建模为授权节点根据本地对等方列表（授权对等方数据库（APD））验证对等方身份。APD是一种抽象结构，类似于IPsec的安全策略数据库[36]。实现可以以他们选择的任何方式提供相关的功能。本节仅定义APD管理的要求以及成功验证对等身份的后果。
The APD consists of a list of entries. Each entry includes an identity, the namespace from which the identity comes (e.g., DNS domains), the scope within which the entry is applicable, and whether authorisation is allowed or denied. The following are example scopes:
APD由条目列表组成。每个条目都包括一个标识、标识来源的名称空间（例如DNS域）、条目适用的范围，以及是否允许或拒绝授权。以下是示例范围：
Peer Address Ownership: The scope is the IP address at which the peer for this MRI should be; the APD entry denotes the identity as the owner of address. If the authorising node can determine this address from local information (such as its own routing tables), matching this entry shows that the peer is the correct on-path node and so should be authorised. The determination is simple if the peer is one IP hop downstream, since the IP address can be derived from the router's forwarding tables. If the peer is more than one hop away or is upstream, the determination is harder but may still be possible in some circumstances. The authorising node may be able to determine a (small) set of possible peer addresses, and accept that any of these could be the correct peer.
对等地址所有权：范围是此MRI的对等方应位于的IP地址；APD条目表示地址所有者的身份。如果授权节点可以根据本地信息（如其自身的路由表）确定此地址，则匹配此条目表明对等方是正确的路径节点，因此应进行授权。由于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.
同一身份可能出现在多个条目中，并且APD中条目的顺序很重要。当消息传递关联经过身份验证并与MRI关联时，授权节点扫描APD以查找第一个条目，其中身份与对等方提供的身份匹配，并且范围信息与设置MA的环境匹配。身份匹配过程本身取决于执行身份验证的消息传递关联协议，第5.7.3节给出了TLS的详细信息。只要知道特定作用域的全套可能对等点，就应该为通配符标识添加拒绝条目，以拒绝来自未知节点的信令关联。授权节点拒绝不适当的MAs的能力直接取决于APD的粒度和范围匹配过程的精度。
If authorisation is allowed, the MA can be used as normal; otherwise, it MUST be torn down without further GIST exchanges, and any routing state associated with the MA MUST also be deleted. An error condition MAY be logged locally. When an APD entry is modified or deleted, the node MUST re-validate existing MAs and the routing state table against the revised contents of the APD. This may result in MAs being torn down or routing state entries being deleted. These changes SHOULD be indicated to local signalling applications via the NetworkNotification API call (Appendix B.4).
如果允许授权，MA可以正常使用；否则，必须在不进一步交换GIST的情况下将其拆除，并且还必须删除与MA相关联的任何路由状态。可能会在本地记录错误情况。修改或删除APD条目时，节点必须根据修改后的APD内容重新验证现有MAs和路由状态表。这可能导致MAs被拆除或路由状态条目被删除。这些更改应通过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地址合法关联的事实可以通过将IP地址作为特定身份类型直接嵌入证书中，或者通过额外的数据库查找将该地址映射到另一个标识符类型（例如将in-addr.arpa中的IP地址与域名关联）来建立. 企业网络运营商可以生成其边界节点的所有身份列表，这些身份被授权位于到外部目的地的信令路径上，并且可以分发到网络内的所有主机。无论采用何种技术，必须确保源数据证明本节开头列出的授权决定是合理的，并且APD条目所依赖的操作链的安全性不会受到损害。
It is a design goal of GIST that, as far as possible, a single messaging association should be used for multiple flows and sessions between two peers, rather than setting up a new MA for each. This re-use of existing MAs is referred to as messaging association multiplexing. Multiplexing ensures that the MA cost scales only with the number of peers, and avoids the latency of new MA setup where possible.
GIST的设计目标是，应尽可能将单个消息关联用于两个对等方之间的多个流和会话，而不是为每个对等方设置新的MA。这种对现有MAs的重用称为消息关联多路复用。多路复用可确保MA成本仅随对等方数量的增加而增加，并尽可能避免新MA设置的延迟。
However, multiplexing requires the identification of an existing MA that matches the same routing state and desired properties that would be the result of a normal handshake in D-mode, and this identification must be done as reliably and securely as continuing with a normal D-mode handshake. Note that this requirement is complicated by the fact that NATs may remap the node addresses in D-mode messages, and also interacts with the fact that some nodes may peer over multiple interfaces (and thus with different addresses).
然而，多路复用需要识别与D模式下正常握手的结果相同的路由状态和期望属性相匹配的现有MA，并且该识别必须像继续正常D模式握手一样可靠和安全。请注意，由于NAT可能会在D模式消息中重新映射节点地址，并且一些节点可能会通过多个接口（从而使用不同的地址）进行对等，因此该要求变得复杂。
MA multiplexing is controlled by the Network Layer Information (NLI) object, which is carried in Query, Response, and Confirm messages. The NLI object includes (among other elements):
MA多路复用由网络层信息（NLI）对象控制，该对象包含在查询、响应和确认消息中。NLI对象包括（除其他元素外）：
Peer-Identity: For a given node, this is an interface-independent value with opaque syntax. It MUST be chosen so as to have a high probability of uniqueness across the set of all potential peers, and SHOULD be stable at least until the next node restart. Note that there is no cryptographic protection of this identity; attempting to provide this would essentially duplicate the functionality in the messaging association security protocols. For routers, the Router-ID [2], which is one of the router's IP addresses, MAY be used as one possible value for the Peer-Identity. In scenarios with nested NATs, the Router-ID alone may not satisfy the uniqueness requirements, in which case it MAY be extended with additional tokens, either chosen randomly or administratively coordinated.
对等标识：对于给定节点，这是一个具有不透明语法的独立于接口的值。必须选择它，以便在所有潜在对等点集合中具有较高的唯一性概率，并且至少在下一个节点重新启动之前保持稳定。请注意，此身份没有加密保护；试图提供这一点实际上会复制消息传递关联安全协议中的功能。对于路由器，路由器ID[2]是路由器的IP地址之一，可以用作对等身份的一个可能值。在嵌套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多路复用是通过将新GIST消息中提供的NLI中的这两个元素与与现有MA相关联的元素进行匹配来实现的。消息可以是查询或响应，但前者更可能是：
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节末尾给出的安全和运输属性标准。这通过通过通过该关联发送握手中的剩余消息来表示。如果信令节点具有冲突的对等身份，并且一个节点可以在与另一个节点相同的接口地址访问，则这将导致在关联上多路复用到错误的节点。这可能是由路径上的攻击者造成的；第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模式下执行。事实上，有四种可能性：
1. Nothing matches: this is clearly a new peer.
1. 没有匹配的：这显然是一个新的同行。
2. Only the Peer-Identity matches: this may be either a new interface on an existing peer or a changed address mapping behind a NAT. These should be rare events, so the expense of a new association setup is acceptable. Another possibility is one node using another node's Peer-Identity, for example, as some kind of attack. Because the Peer-Identity is used only for this multiplexing process, the only consequence this has is to require a new association setup, and this is considered in Section 8.4.
2. 只有对等身份匹配：这可能是现有对等上的新接口，也可能是NAT后更改的地址映射。这些应该是罕见的事件，因此新关联设置的费用是可以接受的。另一种可能性是一个节点使用另一个节点的对等身份，例如，作为某种攻击。由于对等身份仅用于此多路复用过程，因此唯一的结果是需要新的关联设置，这在第8.4节中考虑。
3. Only the Interface-Address matches: this is probably a new peer behind the same NAT as an existing one. A new association setup is required.
3. 只有接口地址匹配：这可能是与现有NAT相同的NAT后面的新对等方。需要新的关联设置。
4. Both elements of the NLI object match: this is a degenerate case, where one node recognises an existing peer, but wishes to allow the option to set up a new association in any case, for example, to create an association with different properties.
4. NLI对象的两个元素都匹配：这是一种退化情况，其中一个节点识别现有对等节点，但希望允许在任何情况下设置新关联的选项，例如，创建具有不同属性的关联。
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 * (number of routing states) / (rate limit in packets/second)
which leaves a factor of two headroom for new routing state creation and Query retransmissions.
这为新的路由状态创建和查询重传留下了两倍的净空。
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不得刷新路由状态，这可能是因为上游状态已过期，或者是因为信令应用程序已通过GIST API（附录B.5）指示不再需要该状态，因为在IP层网络重新路由的情况下，这将阻止正确的状态修复。
This specification defines precisely only the time at which routing state expires; it does not define when refresh handshakes should be initiated. Implementations MUST select timer settings that take at least the following into account:
本规范仅精确定义路由状态到期的时间；它没有定义何时应该启动刷新握手。实施必须选择至少考虑以下因素的计时器设置：
o the transmission latency between source and destination;
o 源和目标之间的传输延迟；
o the need for retransmissions of Query messages;
o 需要重新传输查询消息；
o the need to avoid network synchronisation of control traffic (cf. [42]).
o 需要避免控制流量的网络同步（参见[42]）。
In most cases, a reasonable policy is to initiate the routing state refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects.
在大多数情况下，一个合理的策略是在自上次成功刷新以来已过1/2到3/4的有效时间时启动路由状态刷新。必须在此间隔内随机选择实际力矩，以避免同步效应。
Unneeded MAs are torn down by GIST, using the teardown mechanisms of the underlying transport or security protocols if available, for example, by simply closing a TCP connection. The teardown can be initiated by either end. Whether an MA is needed is a combination of two factors:
GIST使用底层传输或安全协议（如果可用）的拆卸机制（例如，通过简单地关闭TCP连接）来拆卸不需要的MAs。拆卸可以由任意一端启动。是否需要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
o 对等方是否仍希望MA保持不变。在MA设置过程中，作为堆栈配置数据的一部分，每个节点公布其自身的MA保持时间，即其将保持的时间
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。如果节点在该时间段内已从其对等方接收到流量，则不得中断MA。没有生成流量但仍希望保留MA的对等方可以使用特殊的空消息（MA Hello）来指示事实。建议MA保持时间的默认值为30秒。节点可以使用更短的时间来实现更快速的对等故障检测，但需要考虑MA Hello消息在网络上产生的负载。节点可能使用更长的时间，但需要考虑在较长时间内保留空闲MAs的成本。节点在选择适当的值时可以考虑信令应用程序行为（例如，NSLP刷新时间）。
Because the Responding node can choose not to create state until a Confirm, an abbreviated Stack-Configuration-Data object containing just this information from the initial Query MUST be repeated by the Querying node in the first Confirm sent on a new MA. If the object is missing in the Confirm, an "Object Type Error" message (Appendix A.4.4.9) with subcode 2 ("Missing Object") MUST be returned.
由于响应节点可以选择在确认之前不创建状态，因此在新MA上发送的第一次确认中，查询节点必须重复仅包含来自初始查询的此信息的缩写堆栈配置数据对象。如果确认中缺少对象，则必须返回带有子代码2（“缺少对象”）的“对象类型错误”消息（附录A.4.4.9）。
Messaging associations can always be set up on demand, and messaging association status is not made directly visible outside the GIST layer. Therefore, even if GIST tears down and later re-establishes a messaging association, signalling applications cannot distinguish this from the case where the MA is kept permanently open. To maintain the transport semantics described in Section 4.1, GIST MUST close transport connections carrying reliable messages gracefully or report an error condition, and MUST NOT open a new association to be used for given session and peer while messages on a previous association could still be outstanding. GIST MAY use an MA-Hello request/reply exchange on an existing association to verify that messages sent on it have reached the peer. GIST MAY use the same technique to test the liveness of the underlying MA protocols themselves at arbitrary times.
消息关联始终可以按需设置，并且消息关联状态不会直接显示在GIST层之外。因此，即使GIST中断并随后重新建立消息关联，信令应用程序也无法将其与MA保持永久打开的情况区分开来。为了维护第4.1节中所述的传输语义，GIST必须优雅地关闭承载可靠消息的传输连接或报告错误情况，并且不得打开用于给定会话和对等方的新关联，而以前关联上的消息可能仍然未完成。GIST可以在现有关联上使用MA Hello请求/应答交换来验证在其上发送的消息是否已到达对等方。GIST可以使用相同的技术在任意时间测试底层MA协议本身的活性。
This specification defines precisely only the time at which messaging associations expire; it does not define when keepalives should be initiated. Implementations MUST select timer settings that take at least the following into account:
本规范仅精确定义了消息关联过期的时间；它没有定义什么时候应该启动keepalives。实施必须选择至少考虑以下因素的计时器设置：
o the transmission latency between source and destination;
o 源和目标之间的传输延迟；
o the need for retransmissions within the messaging association protocols;
o 在消息传递关联协议内重新传输的需要；
o the need to avoid network synchronisation of control traffic (cf. [42]).
o 需要避免控制流量的网络同步（参见[42]）。
In most cases, a reasonable policy is to initiate the MA refresh when between 1/2 and 3/4 of the validity time has elapsed since the last successful refresh. The actual moment MUST be chosen randomly within this interval to avoid synchronisation effects.
在大多数情况下，合理的策略是在自上次成功刷新以来已过1/2到3/4的有效时间时启动MA刷新。必须在此间隔内随机选择实际力矩，以避免同步效应。
A GIST node can receive a message from a GIST peer that can only be correctly processed in the context of some routing state, but where no corresponding routing state exists. Cases where this can arise include:
GIST节点可以从GIST对等方接收消息，该消息只能在某些路由状态的上下文中正确处理，但不存在相应的路由状态。可能出现这种情况的情况包括：
o Where the message is random traffic from an attacker, or backscatter (replies to such traffic).
o 其中消息是来自攻击者的随机流量，或反向散射（对此类流量的回复）。
o Where routing state has been correctly installed but the peer has since lost it, for example, because of aggressive timeout settings at the peer or because the node has crashed and restarted.
o 路由状态已正确安装，但对等方已丢失路由状态，例如，由于对等方的主动超时设置或节点已崩溃并重新启动。
o Where the routing state was not correctly installed in the first place, but the sending node does not know this. This can happen if the Confirm message of the handshake is lost.
o 其中，路由状态首先没有正确安装，但发送节点不知道这一点。如果握手的确认消息丢失，则可能发生这种情况。
It is important for GIST to recover from such situations promptly where they represent genuine errors (node restarts, or lost messages that would not otherwise be retransmitted). Note that only Response, Confirm, Data, and Error messages ever require routing state to exist, and these are considered in turn:
GIST必须迅速从这些情况中恢复过来，因为它们代表了真正的错误（节点重新启动，或者丢失了本来不会重新传输的消息）。请注意，只有响应、确认、数据和错误消息需要路由状态存在，这些信息依次考虑：
Response: A Response can be received at a node that never sent (or has forgotten) the corresponding Query. If the node wants routing state to exist, it will initiate it itself; a diagnostic error would not allow the sender of the Response to take any corrective action, and the diagnostic could itself be a form of backscatter. Therefore, an error message MUST NOT be generated, but the condition MAY be logged locally.
响应：可以在从未发送（或忘记）相应查询的节点上接收响应。如果节点希望路由状态存在，它将自己启动路由状态；诊断错误将不允许响应的发送方采取任何纠正措施，并且诊断本身可能是一种形式的反向散射。因此，不得生成错误消息，但可在本地记录该情况。
Confirm: For a Responding node that implements delayed state installation, this is normal behaviour, and routing state will be created provided the Confirm is validated. Otherwise, this is a case of a non-existent or forgotten Response, and the node may not have sufficient information in the Confirm to create the correct state. The requirement is to notify the Querying node so that it can recover the routing state.
确认：对于实现延迟状态安装的响应节点，这是正常行为，只要确认有效，就会创建路由状态。否则，这是不存在或忘记响应的情况，并且节点在确认中可能没有足够的信息来创建正确的状态。需求是通知查询节点，以便它可以恢复路由状态。
Data: This arises when a node receives Data where routing state is required, but either it does not exist at all or it has not been finalised (no Confirm message). To avoid Data being black-holed, a notification must be sent to the peer.
数据：当节点接收到需要路由状态的数据，但该数据根本不存在或尚未确定（无确认消息）时，会出现这种情况。为了避免数据被黑洞，必须向对等方发送通知。
Error: Some error messages can only be interpreted in the context of routing state. However, the only error messages that require a reply within the protocol are routing state error messages themselves. Therefore, this case should be treated the same as a Response: an error message MUST NOT be generated, but the condition MAY be logged locally.
错误：某些错误消息只能在路由状态的上下文中解释。但是，协议中唯一需要回复的错误消息是路由状态错误消息本身。因此，应将此情况视为响应：不得生成错误消息，但可在本地记录该情况。
For the case of Confirm or Data messages, if the state is required but does not exist, the node MUST reject the incoming message with a "No Routing State" error message (Appendix A.4.4.5). There are then three cases at the receiver of the error message:
对于确认或数据消息，如果状态是必需的但不存在，则节点必须拒绝带有“无路由状态”错误消息的传入消息（附录a.4.4.5）。然后，在错误消息的接收者处有三种情况：
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.
查询或响应节点上的规则使GIST容易受到随机注入错误消息的干扰，类似于TCP上的盲重置攻击（参见[46]），尽管由于路由状态匹配包括SID，这主要限于路径上的攻击者。如果GIST节点检测到此类攻击的显著比率，则它可以采用使用安全消息传递关联来为受影响的MRI进行通信的策略，并且仅通过此类关联接受“无路由状态”错误消息。
All GIST messages begin with a common header, followed by a sequence of type-length-value (TLV) objects. This subsection describes the various GIST messages and their contents at a high level in ABNF [11]; a more detailed description of the header and each object is given in Section 5.2 and bit formats in Appendix A. Note that the NAT traversal mechanism for GIST involves the insertion of an additional NAT-Traversal-Object in Query, Response, and some Data and Error messages; the rules for this are given in Section 7.2.
所有GIST消息都以一个公共标头开头，后跟一系列类型长度值（TLV）对象。本小节描述了ABNF[11]中的各种GIST消息及其高级别内容；标题和每个对象的更详细描述见第5.2节和附录a中的比特格式。请注意，GIST的NAT遍历机制涉及在查询、响应和一些数据和错误消息中插入额外的NAT遍历对象；第7.2节给出了相关规则。
GIST-Message: The primary messages are either part of the three-way handshake or a simple message carrying NSLP data. Additional types are defined for errors and keeping messaging associations alive.
GIST消息：主要消息要么是三方握手的一部分，要么是承载NSLP数据的简单消息。为错误和保持消息关联活动定义了其他类型。
GIST-Message = Query / Response / Confirm /
Data / Error / MA-Hello
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。它还携带一个跃点计数以防止无限消息循环和各种控制标志，包括一个（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 ]
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
响应：如果没有可重复使用的现有消息关联，则必须以D模式发送响应。如果一个正在重复使用，则必须以C模式发送响应。它必须回显查询的MRI、SID和查询Cookie，并携带自己的网络层信息。如果消息交换涉及新消息关联的设置（必须涉及D模式响应），则必须包括响应者Cookie以及响应者自己的堆栈建议和配置数据。如果存在响应器Cookie，则必须设置R标志（R=1），否则是可选的；如果设置了R标志，则必须发送确认作为回复。因此，特别是，如果正在设置新的MA，则始终需要确认。请注意
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).
该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 ]
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，如果响应带有Cookie，则回显响应者Cookie。在C模式下，确认还必须响应响应（如果存在）中的堆栈建议，以便验证该建议是否未被篡改。新关联的第一次确认还必须以缩写形式重复原始查询中的堆栈配置数据，仅包含MA保持时间。
Confirm = Common-Header
Message-Routing-Information
Session-Identifier
Network-Layer-Information
[ Responder-Cookie
[ Stack-Proposal
[ Stack-Configuration-Data ] ] ]
[ NSLP-Data ]
Confirm = Common-Header
Message-Routing-Information
Session-Identifier
Network-Layer-Information
[ Responder-Cookie
[ Stack-Proposal
[ Stack-Configuration-Data ] ] ]
[ NSLP-Data ]
Data: The Data message is used to transport NSLP data without modifying GIST state. It contains no control objects, but only the MRI and SID associated with the NSLP data being transferred. Network-Layer-Information (NLI) MUST be carried in the D-mode case, but MUST NOT be included otherwise.
数据：数据消息用于在不修改GIST状态的情况下传输NSLP数据。它不包含控制对象，只包含与正在传输的NSLP数据相关联的MRI和SID。网络层信息（NLI）必须在D模式下携带，但不得包含在其他情况下。
Data = Common-Header [ NAT-Traversal-Object ] Message-Routing-Information Session-Identifier [ Network-Layer-Information ] NSLP-Data
数据=公共头[NAT遍历对象]消息路由信息会话标识符[Network Layer Information]NSLP数据
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
Error=公共头[NAT遍历对象][网络层信息]GIST错误数据
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为零的公共标头和消息标识符Hello-ID。它始终表示节点希望保持消息关联处于打开状态，如果发送时R=0且Hello ID为零，则这是其唯一的功能。节点还可以通过设置R＝1并提供非零Hello ID来调用诊断请求/应答交换；在这种情况下，对等方必须沿消息传递关联发送另一个MA Hello，回显相同的Hello ID，R=0。此诊断的使用完全由发起节点自行决定。
MA-Hello = Common-Header Hello-ID
MA Hello=公共头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 hop count：防止消息无限循环的跃点计数。
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）。必须为查询消息以及以Q模式发送的数据消息设置C标志。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地址。它还包括IP-TTL信息，以允许测量和报告GIST对等点之间的IP跃点计数，以及路由状态的有效时间（RS有效时间）。
Network-Layer-Information = peer-identity interface-address RS-validity-time IP-TTL
网络层信息=对等身份接口地址RS有效时间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.
第4.4.4节描述了RS有效时间字段的使用。对等身份和接口地址用于匹配现有关联，如第4.4.3节所述。
The interface-address must be routable, i.e., it MUST be usable as a destination IP address for packets to be sent back to the node generating the signalling message, whether in D-mode or C-mode. If this object is carried in a message with the source addressing mode flag S=1, the interface-address MUST match the source address used in the IP encapsulation, to assist in legacy NAT detection (Section 7.2.1). If this object is carried in a Query or Confirm, the interface-address MUST specifically be set to an address bound to an interface associated with the MRI, to allow its use in route change handling as discussed in Section 7.1. A suitable choice is the interface that is carrying the outbound flow. A node may have several choices for which of its addresses to use as the interface-address. For example, there may be a choice of IP versions, or addresses of limited scope (e.g., link-local), or addresses bound to different interfaces in the case of a router or multihomed host. However, some of these interface addresses may not be usable by the peer. A node MUST follow a policy of using a global address of the same IP version as in the MRI, unless it can establish that an alternative address would also be usable.
接口地址必须是可路由的，即它必须可用作要发送回生成信令消息的节点的数据包的目的地IP地址，无论是D模式还是C模式。如果在源寻址模式标志S=1的消息中携带此对象，则接口地址必须与IP封装中使用的源地址相匹配，以协助传统NAT检测（第7.2.1节）。如果在查询或确认中携带此对象，则接口地址必须特别设置为绑定到与MRI相关联的接口的地址，以允许其用于第7.1节中讨论的路线变更处理。一个合适的选择是承载出站流的接口。一个节点可以有几个选择，将其哪个地址用作接口地址。例如，在路由器或多主机的情况下，可以选择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
Stack-Proposal = 1*stack-profile
stack-profile = protocol-count 1*protocol-layer
;; padded on the right with 0 to 32-bit boundary
stack-profile = protocol-count 1*protocol-layer
;; padded on the right with 0 to 32-bit boundary
protocol-count = %x01-FF
;; number of the following <protocol-layer>,
;; represented as one byte. This doesn't include
;; padding.
protocol-count = %x01-FF
;; number of the following <protocol-layer>,
;; represented as one byte. This doesn't include
;; padding.
protocol-layer = %x01-FF
protocol-layer = %x01-FF
Each protocol-layer field identifies a protocol with a unique tag; any additional data, such as higher-layer addressing or other options data associated with the protocol, will be carried in an MA-protocol-options field in the Stack-Configuration-Data TLV (see below).
每个协议层字段用唯一的标签标识协议；任何附加数据，如高层寻址或与协议相关的其他选项数据，将在堆栈配置数据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
堆栈配置数据=MA保持时间0*MA协议选项
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.
查询Cookie/响应器Cookie：查询中包含一个查询Cookie，并且必须在响应中回显；响应者Cookie可以在响应中发送，如果存在，则必须在下面的确认中回显。cookie是可变长度的位字符串，由cookie生成器选择。有关cookie生成的要求和机制的更多详细信息，请参见第8.5节。
Hello-ID: The Hello-ID is a 32-bit quantity that is used to correlate messages in an MA-Hello request/reply exchange. A non-zero value MUST be used in a request (messages sent with R=1) and the same value must be returned in the reply (which has R=0). The value zero MUST be used for all other messages; if a message is received with R=1 and Hello-ID=0, an "Object Value Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be returned and the message dropped. Nodes MAY use any algorithm to generate the Hello-ID; a suitable approach is a local sequence number with a random starting point.
Hello ID：Hello ID是一个32位的数量，用于关联MA Hello请求/应答交换中的消息。请求中必须使用非零值（以R=1发送的消息），回复中必须返回相同的值（以R=0发送）。值0必须用于所有其他消息；如果收到R=1且Hello ID=0的消息，则必须返回子代码为1（“值不受支持”）的“对象值错误”消息（附录a.4.4.10），并删除该消息。节点可以使用任何算法来生成Hello ID；一种合适的方法是具有随机起点的局部序列号。
NSLP-Data: The NSLP payload to be delivered to the signalling application. GIST does not interpret the payload content.
NSLP数据：要传递给信令应用程序的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 ]
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
根据路由状态表的规定，该消息被IP地址直接发送到相邻的对等方。如果消息是对查询的直接回复，且不存在路由状态，则使用与第4.4.1节中相同的规则从输入消息派生目标地址。UDP端口编号必须与查询消息上使用的端口编号兼容（请参见下文），也就是说，同一地址中的消息编号相同
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.
方向和，源端口号和目标端口号交换为相反方向的消息。具有正常封装的消息必须使用源寻址模式标志S=1发送，除非该消息是对已知已通过NAT的消息的答复，并且作为传统NAT检测的一部分，接收方必须使用NLI中给出的接口地址检查IP源地址。第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-mode封装与普通封装类似，在IP地址选择、关于IP选项的规则以及选择UDP端口的已定义方法方面有所更改。
It is an essential property of the Q-mode encapsulation that it is possible for a GIST node to intercept these messages efficiently even when they are not directly addressed to it and, conversely, that it is possible for a non-GIST node to ignore these messages without overloading the slow path packet processing. This document specifies that interception is done based on RAOs.
Q模式封装的一个基本特性是，GIST节点可以有效地截获这些消息，即使这些消息没有直接发送给它，相反，非GIST节点可以忽略这些消息，而不会使慢路径数据包处理过载。本文件规定拦截是基于RAO进行的。
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定义了路由器警报选项[13]的使用，以帮助对等方根据NSLPID拦截消息。如果MRM定义了RAO的使用，则发送方必须将其包括在内，除非已明确配置为不使用（见下文）。节点可以纯粹基于IP协议号传输报头分析做出初始拦截决策。实现可以提供一种选项，用于基于每个目的地前缀禁用Q模式分组上的RAO设置；但是，该选项在默认情况下必须禁用，并且只有在单独验证沿到目的地的路径的下一个GIST节点能够在没有RAO的情况下拦截数据包时才必须启用。此选项的目的是允许在不适当支持RAO的网络上运行；更多细节见附录C。
It is likely that fragmented datagrams will not be correctly intercepted in the network, since the checks that a datagram is a Q-mode packet depend on data beyond the IP header. Therefore, the sender MUST set the Don't Fragment (DF) bit in the IPv4 header. Note that ICMP "packet too large" messages will be sent to the source address of the original IP datagram, and since all MRM definitions recommend S=1 for at least some retransmissions, ICMP errors related to fragmentation will be seen at the Querying node.
由于检查数据报是否为Q模式数据包取决于IP报头以外的数据，因此可能无法在网络中正确截获碎片数据报。因此，发送方必须在IPv4报头中设置不分段（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
对于这两个IP版本，上述规则要求IP头标识的上层协议必须是UDP。其他数据包不得被识别为GIST Q模式数据包；这包括IP隧道数据包中的IP、其他隧道数据包（隧道模式AH/ESP）或经过一些额外传输层处理（传输模式AH/ESP）的数据包。如果在发起节点或中间路由器处的IP输出处理导致将此类附加封装添加到GIST Q-mode分组，则在封装终止之前，该分组将不会被识别为GIST。如果节点希望通过网络区域发送数据信号，则
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.
应用封装时，它必须生成与封装流量匹配的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通过使用来自“已知”空间的固定目标UDP端口进行Q模式封装来解决此问题。此端口不应分配到主机上，因此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节点需要能够过滤出UDP目标端口号等于GIST Q模式封装注册端口号的所有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选项。在GIST转发的没有NSLP处理的数据包上，必须像处理正常转发的IP数据包一样处理IP选项。在本地传送到NSLP的分组上，IP选项可以传递给NSLP，并且在随后生成的输出Q模式分组上使用等效选项。在这种情况下，路由相关选项的处理方式应与正常转发的IP数据包相同。
D-mode uses UDP, and hence has no automatic reliability or congestion control capabilities. Signalling applications requiring reliability should be serviced using C-mode, which should also carry the bulk of signalling traffic. However, some form of messaging reliability is required for the GIST control messages themselves, as is rate control to handle retransmissions and also bursts of unreliable signalling or state setup requests from the signalling applications.
D模式使用UDP，因此没有自动可靠性或拥塞控制功能。需要可靠性的信令应用应使用C模式进行服务，C模式也应承载大部分信令业务。然而，GIST控制消息本身需要某种形式的消息传递可靠性，处理重传的速率控制以及来自信令应用程序的不可靠信令突发或状态设置请求也是如此。
Query messages that do not receive Responses MAY be retransmitted; retransmissions MUST use a binary exponential backoff. The initial timer value is T1, which the backoff process can increase up to a maximum value of T2 seconds. The default value for T1 is 500 ms. T1 is an estimate of the round-trip time between the Querying and Responding nodes. Nodes MAY use smaller values of T1 if it is known that the Query should be answered within the local network. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high-latency access links) that the round-trip time is larger. The default value of T2 is 64*T1. Note that Queries may go unanswered either because of message loss (in either direction) or because there is no reachable GIST peer. Therefore, implementations MAY trade off reliability (large T2) against promptness of error feedback to applications (small T2). If the NSLP has indicated a timeout on the validity of this payload (see Appendix B.1), T2 MUST be chosen so that the process terminates within this timeout. Retransmitted Queries MUST use different Query-Cookie values. If the Query carries NSLP data, it may be delivered multiple times to the signalling application. These rules apply equally to the message that first creates routing state, and those that refresh it. In all cases, Responses MUST be sent promptly to avoid spurious retransmissions. Nodes generating any type of retransmission MUST be prepared to receive and match a reply to any of them, not just the one most recently sent. Although a node SHOULD terminate its retransmission process when any reply is received, it MUST continue to process further replies as normal.
不接收响应的查询消息可以重新传输；重新传输必须使用二进制指数退避。初始计时器值为T1，退避过程可将其增加至最大值T2秒。T1的默认值为500毫秒。T1是查询节点和响应节点之间往返时间的估计值。如果知道查询应该在本地网络内得到回答，则节点可以使用较小的T1值。T1可以选择更大，如果预先知道（例如在高延迟接入链路上）往返时间更大，则建议选择更大的T1。T2的默认值是64*T1。请注意，查询可能会因为消息丢失（在任何方向）或因为没有可访问的GIST对等方而无法响应。因此，实现可能会权衡可靠性（大T2）和对应用程序的错误反馈的及时性（小T2）。如果NSLP已指示该有效载荷的有效性超时（见附录B.1），则必须选择T2，以便进程在此超时内终止。重新传输的查询必须使用不同的查询Cookie值。如果查询携带NSLP数据，则可能会将其多次发送到信令应用程序。这些规则同样适用于首先创建路由状态的消息和刷新路由状态的消息。在所有情况下，必须及时发送响应，以避免虚假的重新传输。生成任何类型的重传的节点必须准备好接收并匹配对其中任何一个的回复，而不仅仅是最近发送的回复。虽然节点应该在收到任何回复时终止其重传过程，但它必须继续正常处理进一步的回复。
This algorithm is sufficient to handle lost Queries and Responses. The case of a lost Confirm is more subtle. The Responding node MAY run a retransmission timer to resend the Response until a Confirm is received; the timer MUST use the same backoff mechanism and parameters as for Responses. The problem of an amplification attack stimulated by a malicious Query is handled by requiring the cookie mechanism to enable the node receiving the Response to discard it efficiently if it does not match a previously sent Query. This approach is only appropriate if the Responding node is prepared to store per-flow state after receiving a single (Query) message, which includes the case where the node has queued NSLP data. If the Responding node has delayed state installation, the error condition will only be detected when a Data message arrives. This is handled as a routing state error (see Section 4.4.6) that causes the Querying node to restart the handshake.
此算法足以处理丢失的查询和响应。丢失确认的情况更为微妙。响应节点可运行重传定时器以重新发送响应，直到接收到确认；计时器必须使用与响应相同的回退机制和参数。恶意查询引发的放大攻击问题是通过要求cookie机制来处理的，该机制使接收响应的节点能够在响应与之前发送的查询不匹配时有效地丢弃响应。仅当响应节点在接收到单个（查询）消息后准备存储每个流状态时，此方法才适用，其中包括节点已将NSLP数据排队的情况。如果响应节点已延迟状态安装，则仅当数据消息到达时才会检测到错误情况。这被视为路由状态错误（参见第4.4.6节），导致查询节点重新启动握手。
The basic rate-control requirements for D-mode traffic are deliberately minimal. A single rate limiter applies to all traffic, for all interfaces and message types. It applies to retransmissions as well as new messages, although an implementation MAY choose to prioritise one over the other. Rate-control applies only to locally generated D-mode messages, not to messages that are being forwarded. When the rate limiter is in effect, D-mode messages MUST be queued until transmission is re-enabled, or they MAY be dropped with an error condition indicated back to local signalling applications. In either case, the effect of this will be to reduce the rate at which new transactions can be initiated by signalling applications, thereby reducing the load on the network.
D模式流量的基本速率控制要求是故意最小化的。单个速率限制器适用于所有流量、所有接口和消息类型。它适用于重传以及新消息，尽管实现可能会选择优先于另一个。速率控制仅适用于本地生成的D模式消息，而不适用于正在转发的消息。当速率限制器生效时，D模式消息必须排队，直到重新启用传输，否则它们可能会被丢弃，并将错误情况指示回本地信令应用程序。在任何一种情况下，这都会降低通过信令应用程序启动新事务的速率，从而降低网络上的负载。
The rate-limiting mechanism is implementation-defined, but it is RECOMMENDED that a token bucket limiter as described in [33] be used. The token bucket MUST be sized to ensure that a node cannot saturate the network with D-mode traffic, for example, when re-probing the network for multiple flows after a route change. A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction of the node's lowest-speed interface. It is RECOMMENDED that this fraction is no more than 5%. Note that according to the rules of Section 4.3.3, in general, D-mode SHOULD only be used for Queries and Responses rather than normal signalling traffic unless capacity for normal signalling traffic can be engineered.
速率限制机制由实现定义，但建议使用[33]中所述的令牌桶限制器。令牌桶的大小必须确保节点不会使网络饱和D模式流量，例如，在路由更改后重新探测网络中的多个流时。一种合适的方法是限制令牌桶参数，以便平均输出速率仅为节点最低速度接口的一小部分。建议该分数不超过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
[29]中定义的NTLP要求它能够支持小消息的捆绑、大消息的分段和消息边界划分。TCP提供捆绑和分段，但不提供消息边界。但是,
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:
GIST公共头中的长度信息允许在解析期间发现消息边界。小消息的捆绑可以在传输协议内完成，也可以在消息构造期间由GIST执行。无论哪种方式，都可以区分两种方法：
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
GIST有四种主要消息类型（查询、响应、确认和数据）和三种可能的封装方法（普通D模式、Q模式和C模式）。下表给出了允许进行消息传输的消息类型和封装的组合。在某些情况下，根据路由状态或消息关联的存在，有几种可能的选择。管理GIST策略的规则，包括是否创建这样的状态来处理消息，在本规范的其他部分中进行了规范性描述。如果只能以Q模式或D模式发送的消息以C模式到达，或以C模式到达，则必须以“错误封装”错误消息拒绝该消息（附录a.4.4.3）。然而，应当注意，在接收器处对消息的处理不受所使用的封装方法的影响，除非
decapsulation process may provide additional information, such as translated addresses or IP hop count to be used in the subsequent message processing.
解封装过程可提供附加信息，例如在后续消息处理中使用的翻译地址或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 | |
+----------+--------------+---------------------------+-------------+
+----------+--------------+---------------------------+-------------+
| Message | Normal | Query D-mode (Q-mode) | C-mode |
| | D-mode | | |
+----------+--------------+---------------------------+-------------+
| Query | Never | Always, with C-flag=1 | Never |
| | | | |
| Response | Unless a | Never | If a |
| | messaging | | messaging |
| | association | | association |
| | is being | | is being |
| | re-used | | re-used |
| | | | |
| Confirm | Only if no | Never | If a |
| | messaging | | messaging |
| | association | | association |
| | has been set | | has been |
| | up or is | | set up or |
| | being | | is being |
| | re-used | | re-used |
| | | | |
| Data | If routing | If the MRI can be used to | If a |
| | state exists | derive the Q-mode | messaging |
| | for the flow | encapsulation, and either | association |
| | but no | no routing state exists | exists |
| | messaging | or local policy requires | |
| | association | Q-mode; MUST have | |
| | | C-flag=1 | |
+----------+--------------+---------------------------+-------------+
Special rules apply to the encapsulation and transmission of Error messages.
特殊规则适用于错误消息的封装和传输。
GIST only generates Error messages in reaction to incoming messages. Error messages MUST NOT be generated in reaction to incoming Error messages. The routing and encapsulation of the Error message are derived from that of the message that caused the error; in particular, local routing state is not consulted. Routing state and messaging association state MUST NOT be created to handle the error, and Error messages MUST NOT be retransmitted explicitly by GIST, although they are subject to the same rate control as other messages.
GIST仅生成错误消息以响应传入消息。不得生成错误消息以响应传入的错误消息。错误消息的路由和封装源自导致错误的消息的路由和封装；特别是，不咨询本地路由状态。不得创建路由状态和消息关联状态来处理错误，且错误消息不得通过GIST显式重新传输，尽管它们与其他消息受相同的速率控制。
o If the incoming message was received in D-mode, the error MUST be sent in D-mode using the normal encapsulation, using the addressing information from the NLI object in the incoming message. If the NLI could not be determined, the error MUST be sent to the IP source of the incoming message if the S-flag was set in it. The NLI object in the Error message reports information about the originator of the error.
o 如果传入消息是在D模式下接收的，则必须使用正常封装，使用传入消息中NLI对象的寻址信息，在D模式下发送错误。如果无法确定NLI，则必须将错误发送到传入消息的IP源（如果在其中设置了S标志）。错误消息中的NLI对象报告有关错误发起人的信息。
o If the incoming message was received over a messaging association, the error MUST be sent back over the same messaging association.
o 如果通过消息关联接收传入消息，则必须通过同一消息关联发回错误。
The NSLPID in the common header of the Error message has the value zero. If for any reason the message cannot be sent (for example, because it is too large to send in D-mode, or because the MA over which the original message arrived has since been closed), an error SHOULD be logged locally. The receiver of the Error message can infer the NSLPID for the message that caused the error from the Common Header that is embedded in the Error Object.
错误消息的公共标头中的NSLPID的值为零。如果由于任何原因无法发送消息（例如，因为消息太大，无法以D模式发送，或者因为原始消息到达的MA已关闭），则应在本地记录错误。错误消息的接收者可以从错误对象中嵌入的公共头推断导致错误的消息的NSLPID。
A key attribute of GIST is that it is flexible in its ability to use existing transport and security protocols. Different transport protocols may have performance attributes appropriate to different environments; different security protocols may fit appropriately with different authentication infrastructures. Even given an initial default mandatory protocol set for GIST, the need to support new protocols in the future cannot be ruled out, and secure feature negotiation cannot be added to an existing protocol in a backwards-compatible way. Therefore, some sort of capability discovery is required.
GIST的一个关键特性是它能够灵活地使用现有的传输和安全协议。不同的传输协议可能具有适合不同环境的性能属性；不同的安全协议可能适合不同的身份验证基础架构。即使给定GIST的初始默认强制协议集，也不能排除将来支持新协议的需要，并且不能以向后兼容的方式将安全功能协商添加到现有协议中。因此，需要某种能力发现。
Capability discovery is carried out in Query and Response messages, using Stack-Proposal and Stack-Configuration-Data (SCD) objects. If a new messaging association is required, it is then set up, followed by a Confirm. Messaging association multiplexing is achieved by short-circuiting this exchange by sending the Response or Confirm messages on an existing association (Section 4.4.3); whether to do this is a matter of local policy. The end result of this process is a messaging association that is a stack of protocols. If multiple associations exist, it is a matter of local policy how to distribute messages over them, subject to respecting the transfer attributes requested for each message.
使用堆栈建议和堆栈配置数据（SCD）对象在查询和响应消息中执行能力发现。如果需要新的消息关联，则会设置该关联，然后进行确认。通过在现有关联上发送响应或确认消息（第4.4.3节），使该交换短路，从而实现消息关联多路复用；是否这样做是当地政策的问题。这个过程的最终结果是一个消息关联，它是一个协议栈。如果存在多个关联，则如何在其上分发消息是本地策略的问题，这取决于对每个消息请求的传输属性的尊重。
Every possible protocol for a messaging association has the following attributes:
消息关联的每个可能协议都具有以下属性：
o MA-Protocol-ID, a 1-byte IANA-assigned value (see Section 9).
o MA协议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对象中承载协议寻址和其他配置信息。根据查询或响应中是否存在字段，格式可能会有所不同。某些协议不需要定义此类附加数据，在这种情况下，SCD对象中不会出现相应的MA协议选项字段。
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。配置文件以“从上到下”的顺序列出协议（例如，TCP上的TLS）。堆栈建议通常伴随一个SCD对象，该对象包含一个MA协议选项字段，用于堆栈建议中列出的任何需要它的协议。MA协议选项字段可以全局应用于堆栈方案中协议的所有实例，也可以标记为应用于特定实例。例如，后一种方法可用于承载TCP的不同端口号，具体取决于它是否与TLS一起使用。可以在附录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协议选项字段中设置此选项。以这种方式标记的协议不得用于消息关联。如果堆栈建议和SCD都存在但不一致，例如，如果它们引用不同的协议，或者MA协议选项字段引用不存在的配置文件，则必须返回带有子代码5（“堆栈建议-堆栈配置数据不匹配”）的“对象值错误”消息（附录a.4.4.10），并删除该消息。
A node generating an SCD object MUST honour the implied protocol configurations for the period during which a messaging association might be set up; in particular, it MUST be immediately prepared to accept incoming datagrams or connections at the protocol/port combinations advertised. This MAY require the creation of listening endpoints for the transport and security protocols in question, or a node MAY keep a pool of such endpoints open for extended periods.
生成SCD对象的节点必须在可能建立消息关联的期间遵守隐含的协议配置；特别是，它必须立即准备好接受所公布的协议/端口组合处的传入数据报或连接。这可能需要为所讨论的传输和安全协议创建侦听端点，或者节点可能会使此类端点池在较长时间内保持打开状态。
However, the received object contents MUST be retained only for the duration of the Query/Response exchange and to allow any necessary association setup to complete. They may become invalid because of expired bindings at intermediate NATs, or because the advertising node is using agile ports. Once the setup is complete, or if it is not necessary or fails for some reason, the object contents MUST be discarded. A default time of 30 seconds to keep the contents is RECOMMENDED.
但是，接收到的对象内容必须仅在查询/响应交换期间保留，并允许完成任何必要的关联设置。由于中间NAT的绑定已过期，或者由于播发节点正在使用敏捷端口，它们可能会变得无效。一旦安装完成，或者如果没有必要或由于某种原因失败，则必须丢弃对象内容。建议保留内容的默认时间为30秒。
A Query requesting messaging association setup always contains a Stack-Proposal and SCD object. The Stack-Proposal MUST only include protocol configurations that are suitable for the transfer attributes of the messages for which the Querying node wishes to use the messaging association. For example, it should not simply include all configurations that the Querying node is capable of supporting.
请求消息关联设置的查询始终包含堆栈建议和SCD对象。堆栈建议必须仅包括适合于查询节点希望使用消息关联的消息的传输属性的协议配置。例如，它不应该简单地包括查询节点能够支持的所有配置。
The Response always contains a Stack-Proposal and SCD object, unless multiplexing (where the Responder decides to use an existing association) occurs. For such a Response, the security protocols listed in the Stack-Proposal MUST NOT depend on the Query. A node MAY make different proposals depending on the combination of interface and NSLPID. If multiplexing does occur, which is indicated by sending the Response over an existing messaging association, the following rules apply:
响应始终包含堆栈建议和SCD对象，除非发生多路复用（响应者决定使用现有关联）。对于这种响应，堆栈建议中列出的安全协议不得依赖于查询。根据接口和NSLPID的组合，节点可以提出不同的建议。如果确实发生了多路复用（通过在现有消息关联上发送响应表示），则应用以下规则：
o The re-used messaging association MUST NOT have weaker security properties than all of the options that would have been offered in the full Response that would have been sent without re-use.
o 重复使用的消息关联的安全属性不得低于在不重复使用的情况下发送的完整响应中提供的所有选项。
o The re-used messaging association MUST have equivalent or better transport and security characteristics as at least one of the protocol configurations that was offered in the Query.
o 重复使用的消息关联必须具有与查询中提供的至少一种协议配置相同或更好的传输和安全特性。
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.
一旦建立了消息传递关联，查询节点将在确认中重复响应者的堆栈建议。响应节点必须验证这一点未被更改，作为竞价拒绝攻击预防的一部分，以及验证响应者Cookie（第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个pad字节。
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的关联可以携带传输属性为Reliable=True的消息。如果TCP连接上发生错误（如重置），例如可通过套接字异常条件检测到的错误，GIST必须向NSLPs报告，如第4.1.2节所述。
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节点必须能够与_3DES_EDE_CBC_SHA协商TLS密码套件TLS_RSA_，并且应该能够与_AES_128_CBC_SHA协商TLS密码套件TLS_RSA_。他们可以协商提供身份验证、完整性和保密性的任何相互接受的密码套件。
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
TLS身份验证的默认模式（尤其适用于上述密码套件）使用客户机/服务器X.509证书交换。查询节点充当TLS客户端，响应节点充当TLS服务器。当协商上述密码套件之一时，充当服务器的GIST节点必须提供
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客户端的GIST节点请求一个证书。这允许仅服务器身份验证或相互身份验证，具体取决于客户端可用的证书和服务器上应用的策略。
GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the negotiation of alternative ciphersuites is used to trigger alternative authentication procedures, such as the use of pre-shared keys [32]. The use of other authentication procedures may require additional specification work to define how they can be used as part of TLS within the GIST framework, and may or may not require the definition of additional MA-Protocol-IDs.
GIST节点可以协商其他TLS密码套件。在某些情况下，备用密码套件的协商用于触发备用身份验证程序，例如使用预共享密钥[32]。使用其他身份验证过程可能需要额外的规范工作来定义如何将其作为GIST框架内TLS的一部分使用，并且可能需要也可能不需要定义额外的MA协议ID。
No MA-protocol-options field is required for this TLS protocol definition. The configuration information for the transport protocol over which TLS is running (e.g., TCP port number) is provided by the MA-protocol-options for that protocol.
此TLS协议定义不需要MA协议选项字段。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认证后，节点必须检查对等方提供的身份，以避免中间人攻击，并验证对等方是否有权参与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身份验证，必须针对证书中存在的dNSName类型的每个subjectAltName扩展检查DNS命名空间中的标识。如果不存在这样的扩展名，则必须将标识与证书主题字段中的（最具体的）通用名称进行比较。将DNS名称与dNSName或公用名称字段匹配时，匹配不区分大小写。此外，“*”通配符可以用作APD中证书或标识中最左边的名称组件。例如，APD中的*.example.com将与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
此外，节点必须验证其连接的对等方的标识与该对等方提供的公钥之间的绑定。节点应实现[8]第6节中针对一般证书验证的算法，但可以补充该算法
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).
使用其他实现同等验证级别的验证方法（例如，将服务器证书与已验证证书和标识绑定的本地存储进行比较）。
For TLS authentication with pre-shared keys, the identity in the psk_identity_hint (for the server identity, i.e., the Responding node) or psk_identity (for the client identity, i.e., the Querying node) MUST be compared to the identities in the APD.
对于使用预共享密钥的TLS身份验证，必须将psk_identity_提示中的标识（对于服务器标识，即响应节点）或psk_标识（对于客户端标识，即查询节点）与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实现必须支持该节点上NSLP所需的任何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]
MRI=网络层版本源地址前缀长度目标地址前缀长度IP协议区分服务代码点[流标签][ipsec SPI/L4端口]
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代码点字段解释为重要字段。源地址和目标地址必须是真实的节点地址，但前缀长度不是32或128（分别适用于IPv4和IPv6）可用于实现地址通配符，从而允许MRI引用进出更宽地址范围的流量。另一个标志定义了相对于MRI的消息方向（上游与下游）。
The MRI format allows a potentially very large number of different flag and field combinations. A GIST implementation that cannot interpret the MRI in a message MUST return an "Object Value Error" message (Appendix A.4.4.10) with subcodes 1 ("Value Not Supported") or 2 ("Invalid Flag-Field Combination") and drop the message.
MRI格式允许大量不同的标志和字段组合。无法解释消息中MRI的GIST实现必须返回带有子代码1（“值不受支持”）或2（“无效标志字段组合”）的“对象值错误”消息（附录A.4.4.10），并删除该消息。
Where the signalling message is travelling in the same ('downstream') direction as the flow defined by the MRI, the IP addressing for Q-mode encapsulated messages is as follows. Support for this encapsulation is REQUIRED.
当信令消息沿着与MRI定义的流相同的（“下游”）方向传输时，Q模式封装消息的IP地址如下所示。需要对这种封装的支持。
o The destination IP address MUST be the flow destination address as given in the MRI of the message payload.
o 目标IP地址必须是消息有效负载的MRI中给出的流目标地址。
o By default, the source address is the flow source address, again from the MRI; therefore, the source addressing mode flag in the common header S=0. This provides the best likelihood that the message will be correctly routed through any region performing per-packet policy-based forwarding or load balancing that takes the source address into account. However, there may be circumstances where the use of the signalling source address (S=1) is preferable, such as:
o 默认情况下，源地址也是来自MRI的流源地址；因此，公共报头中的源寻址模式标志S=0。这提供了消息通过任何区域正确路由的最佳可能性，该区域执行基于每个数据包策略的转发或负载平衡，并将源地址考虑在内。然而，可能存在优选使用信令源地址（S＝1）的情况，例如：
* In order to receive ICMP error messages about the signalling message, such as unreachable port or address. If these are delivered to the flow source rather than the signalling source, it will be very difficult for the querying node to detect that it is the last GIST node on the path. Another case is where there is an abnormally low MTU along the path, in which case the querying node needs to see the ICMP error (recall that Q-mode packets are sent with DF set).
* 以接收有关信令消息的ICMP错误消息，例如无法访问的端口或地址。如果这些数据被传送到流源而不是信令源，查询节点将很难检测到它是路径上的最后一个GIST节点。另一种情况是，路径上的MTU异常低，在这种情况下，查询节点需要查看ICMP错误（回想一下，Q模式数据包是使用DF set发送的）。
* In order to receive GIST Error messages where the error message sender could not interpret the NLI in the original message.
* 为了接收GIST错误消息，错误消息发送者无法解释原始消息中的NLI。
* In order to attempt to run GIST through an unmodified NAT, which will only process and translate IP addresses in the IP header (see Section 7.2.1).
* 为了尝试通过未修改的NAT运行GIST，NAT将只处理和转换IP报头中的IP地址（参见第7.2.1节）。
Because of these considerations, use of the signalling source address is allowed as an option, with use based on local policy. A node SHOULD use the flow source address for initial Query messages, but SHOULD transition to the signalling source address for some retransmissions or as a matter of static configuration,
由于这些考虑因素，允许使用信令源地址作为选项，使用基于本地策略。节点应将流源地址用于初始查询消息，但应转换为信令源地址用于某些重传或静态配置，
for example, if a NAT is known to be in the path out of a certain interface. The S-flag in the common header tells the message receiver which option was used.
例如，如果已知NAT位于某个接口的外部路径中。公共标头中的S标志告诉消息接收器使用了哪个选项。
A Router Alert Option is also included in the IP header. The option value depends on the NSLP being signalled for. In addition, it is essential that the Query mimics the actual data flow as closely as possible, since this is the basis of how the signalling message is attached to the data path. To this end, GIST SHOULD set the Diffserv codepoint and (for IPv6) flow label to match the values in the MRI.
IP报头中还包括路由器警报选项。选项值取决于发送信号的NSLP。此外，查询必须尽可能地模拟实际数据流，因为这是信令消息如何附加到数据路径的基础。为此，GIST应设置Diffserv代码点和（对于IPv6）流标签，以匹配MRI中的值。
A GIST implementation SHOULD apply validation checks to the MRI, to reject Query messages that are being injected by nodes with no legitimate interest in the flow being signalled for. In general, if the GIST node can detect that no flow could arrive over the same interface as the Query, it MUST be rejected with an appropriate error message. Such checks apply only to messages with the Q-mode encapsulation, since only those messages are required to track the flow path. The main checks are that the IP version used in the encapsulation should match that of the MRI and the version(s) used on that interface, and that the full range of source addresses (the source-address masked with its prefix-length) would pass ingress filtering checks. For these cases, the error message is "MRI Validation Failure" (Appendix A.4.4.12) with subcodes 1 or 2 ("IP Version Mismatch" or "Ingress Filter Failure"), respectively.
GIST实现应该对MRI应用验证检查，以拒绝节点注入的查询消息，而这些节点对发送信号的流没有合法的兴趣。通常，如果GIST节点可以检测到没有流可以通过与查询相同的接口到达，则必须使用适当的错误消息拒绝该查询。这种检查只适用于具有Q模式封装的消息，因为跟踪流路径只需要这些消息。主要检查是封装中使用的IP版本应与MRI和该接口上使用的版本相匹配，并且源地址的完整范围（用前缀长度屏蔽的源地址）将通过入口过滤检查。对于这些情况，错误消息分别为“MRI验证失败”（附录A.4.4.12）和子代码1或2（“IP版本不匹配”或“入口过滤器故障”）。
In some deployment scenarios, it is desirable to set up routing state in the upstream direction (i.e., from flow receiver towards the sender). This could be used to support firewall signalling to control traffic from an uncooperative sender, or signalling in general where the flow sender was not NSIS-capable. This capability is incorporated into GIST by defining an encapsulation and processing rules for sending Query messages upstream.
在某些部署场景中，需要在上游方向（即，从流接收器到发送器）设置路由状态。这可用于支持防火墙信令，以控制来自不合作发送方的流量，或在流量发送方不具备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.
o 上游GIST对等点距离IP跃点只有一步之遥，可以通过流到达的接口进行回溯。
o The upstream peer is a border router of a single-homed (stub) network.
o 上游对等方是单宿（存根）网络的边界路由器。
This section defines an upstream Q-mode encapsulation and validation checks for when it can be used. The functionality to generate upstream Queries is OPTIONAL, but if received they MUST be processed in the normal way with some additional IP TTL checks. No special functionality is needed for this.
本节定义了上游Q模式封装和验证检查，以确定何时可以使用它。生成上游查询的功能是可选的，但如果收到这些查询，则必须通过一些额外的IP TTL检查以正常方式进行处理。这不需要特殊的功能。
It is possible for routing state at a given node, for a specific MRI and NSLPID, to be created by both an upstream Query exchange (initiated by the node itself) and a downstream Query exchange (where the node is the responder). If the SIDs are different, these items of routing state MUST be considered as independent; if the SIDs match, the routing state installed by the downstream exchange MUST take precedence, provided that the downstream Query passed ingress filtering checks. The rationale for this is that the downstream Query is in general a more reliable way to install state, since it directly probes the IP routing infrastructure along the flow path, whereas use of the upstream Query depends on the correctness of the Querying node's understanding of the topology.
对于特定MRI和NSLPID，给定节点的路由状态可能由上游查询交换（由节点本身发起）和下游查询交换（其中节点是响应者）创建。如果SID不同，则必须将这些路由状态项视为独立的；如果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 Diffserv码点和（对于IPv6）流标签可以设置为与下游情况下的MRI值相匹配，UDP端口选择也相同。
o The IP layer TTL of the message MUST be set to 255.
o 消息的IP层TTL必须设置为255。
The sending GIST implementation SHOULD attempt to send the Query via the same interface and to the same link layer neighbour from which the data packets of the flow are arriving.
发送GIST实现应尝试通过相同接口将查询发送到流的数据包到达的相同链路层邻居。
The receiving GIST node MAY apply validation checks to the message and MRI, to reject Query messages that have reached a node at which they can no longer be trusted. In particular, a node SHOULD reject a message that has been propagated more than one IP hop, with an "Invalid IP layer TTL" error message (Appendix A.4.4.11). This can be determined by examining the received IP layer TTL, similar to the generalised IP TTL security mechanism described in [41].
接收GIST节点可以对消息和MRI应用验证检查，以拒绝已到达不再信任它们的节点的查询消息。特别是，节点应拒绝已传播多个IP跃点的消息，并显示“无效IP层TTL”错误消息（附录a.4.4.11）。这可以通过检查接收到的IP层TTL来确定，类似于[41]中描述的通用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节点，例如，沿上游数据路径发现NAT，如[34]所示。
For the loose-end MRM, only a simplified version of the Flow Identifier is needed.
对于松散端MRM，只需要简化版本的流标识符。
MRI = network-layer-version source-address destination-address
MRI=网络层版本源地址目标地址
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.
o IP目标地址必须是消息有效负载的MRI中给出的目标地址。
o By default, the IP source address is the source address from the MRI (S=0). However, the use of the signalling source address (S=1) is allowed as in the case of the path-coupled MRM.
o 默认情况下，IP源地址是来自MRI的源地址（S=0）。然而，与路径耦合MRM的情况一样，允许使用信令源地址（S=1）。
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）流标签的设置没有特殊要求。也不适用任何特殊的验证检查。
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处理可以根据四种类型的协作状态机来看待：
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）的实例。此计算机负责管理该流的路由状态的状态。根据策略，它可能负责响应消息的传输或重传，或者这可能由节点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.
状态机描述分别使用术语rx_MMMM、tg_TTTT和er_EEEE来表示传入消息、API/底层触发器和错误条件。下表给出了这些类型的可能事件。此外，还可能发生表示为_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. |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| 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
节点级状态机负责处理不存在更合适的消息关联状态或路由状态的事件。它的结构很简单：只有一个状态（“空闲”）；所有事件都会导致转换回空闲状态。某些事件会导致创建其他状态机。此状态机处理的唯一事件是传入的GIST消息（查询/响应/确认/数据）和发送数据的API请求；没有其他事件是可能的。除了此事件处理之外，节点级计算机还负责管理消息传递的侦听端点
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:
协会。尽管这些与响应节点操作有关，但响应程序状态机无法处理它们，因为它们不是按流创建的。每个事件的处理规则如下：
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_查询）：使用GIST服务接口确定与该对等方相关的信令应用程序策略//注意，此交互将任何NSLP数据作为副作用传递给//NSLP，如果（信令应用程序指示应创建路由状态），则如果（无需三方握手即可创建路由状态）然后创建响应SM并将控制转移给它，否则发送R=1的响应，否则使用提供的任何更新的NSLP负载传播查询
Rule 2 (rx_Response): // a routing state error discard message
规则2（rx\U响应）：//路由状态错误丢弃消息
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_数据）：如果（节点策略将仅处理具有匹配路由状态的数据消息），则发送“无路由状态”错误消息，否则直接传递给NSLP
Rule 4 (er_NoRSM): discard the message
第四条规则：丢弃信息
Rule 5 (tg_NSLPData): if Q-mode encapsulation is not possible for this MRI reject message with an error else if (local policy & transfer attributes say routing state is not needed) then send message statelessly else create Querying-SM and pass message to it
规则5（tg_NSLPData）：如果此MRI无法进行Q模式封装，则拒绝消息并出现错误，否则如果（本地策略和传输属性表示不需要路由状态），则无状态发送消息，否则创建查询SM并将消息传递给它
The Querying-Node state machine (Querying-SM) has three states:
查询节点状态机（查询SM）有三种状态：
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机器创建，作为在不存在适当状态的信令方向上发送流消息的请求的结果。立即生成查询并启动无响应计时器。如果本地策略和传输属性允许，可以在查询中携带NSLP数据；否则，它必须在本地排队等待MA建立。然后，机器转换到等待响应状态，在此状态下处理基于超时的重新传输。数据消息（rx_数据事件）不应在此状态下出现；如果这样做，这可能表示响应丢失，并且节点可能因此而重新传输查询。
Once a Response has been successfully received and routing state created, the machine transitions to Established, during which NSLP data can be sent and received normally. Further Responses received in this state (which may be the result of a lost Confirm) MUST be treated the same way. The Awaiting Refresh state can be considered as a substate of Established, where a new Query has been generated to refresh the routing state (as in Awaiting Response) but NSLP data can be handled normally.
一旦成功接收到响应并创建路由状态，机器将转换为已建立，在此期间可以正常发送和接收NSLP数据。在此状态下收到的进一步响应（可能是丢失确认的结果）必须以相同的方式处理。等待刷新状态可被视为已建立的子状态，其中已生成新查询以刷新路由状态（如等待响应），但NSLP数据可以正常处理。
The timers relevant to this state machine are as follows:
与此状态机相关的计时器如下所示：
Refresh_QNode: Indicates when the routing state stored by this state machine must be refreshed. It is reset whenever a Response is received indicating that the routing state is still valid. Implementations MUST set the period of this timer based on the value in the RS-validity-time field of a Response to ensure that a Query is generated before the peer's routing state expires (see Section 4.4.4).
Refresh_QNode：指示何时必须刷新此状态机存储的路由状态。每当接收到指示路由状态仍然有效的响应时，它就会重置。实现必须基于响应的RS validity time字段中的值设置此计时器的周期，以确保在对等路由状态过期之前生成查询（请参阅第4.4.4节）。
No_Response: Indicates that a Response has not been received in answer to a Query. This is started whenever a Query is sent and stopped when a Response is received.
No_Response（无响应）：表示尚未收到对查询的响应。无论何时发送查询，这都会启动，当收到响应时，这都会停止。
Inactive_QNode: Indicates that no NSLP traffic is currently being handled by this state machine. This is reset whenever the state machine handles NSLP data, in either direction. When it expires, the state machine MAY be deleted. The period of the timer can be set at any time via the API (SetStateLifetime), and if the period is reset in this way the timer itself MUST be restarted.
Inactive_QNode：表示此状态机当前未处理NSLP通信。每当状态机处理任意方向的NSLP数据时，都会重置此值。当它过期时，状态机可能会被删除。可以通过API（SetStateLifetime）随时设置计时器的周期，如果以这种方式重置周期，则必须重新启动计时器本身。
The main events (including all those that cause state transitions) are shown in the figure below, tagged with the number of the processing rule that is used to handle the event. These rules are listed after the diagram. All events not shown or described in the text above are assumed to be impossible in a correct implementation and MUST be ignored.
下图显示了主要事件（包括所有导致状态转换的事件），标记了用于处理事件的处理规则的编号。这些规则列在图表后面。以上文本中未显示或描述的所有事件都假定在正确的实现中是不可能的，必须忽略。
[Initialisation] +-----+
-------------------------|Birth|
| +-----+
| er_NoRSM[3](from all states) rx_Response[4]
| || tg_NSLPData[5]
| tg_NSLPData[1] || rx_Data[7]
| -------- -------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | |Established|
------| Response |---------------------------->> | |
| +----------+ rx_Response[4] +-----------+
| ^ | ^ |
| ^ | ^ |
| -------- | |
| to_No_Response[2] | |
| [!nResp_reached] tg_NSLPData[5] | |
| || rx_Data[7] | |
| -------- | |
| | V | |
| to_No_Response[2] | V | |
| [nResp_reached] +-----------+ rx_Response[4] | |
---------- -----------| Awaiting |----------------- |
| | | Refresh |<<-------------------
| | +-----------+ to_Refresh_QNode[8]
| | ^ |
V V ^ | to_No_Response[2]
V V -------- [!nResp_reached]
+-----+
|Death|<<---------------
+-----+ to_Inactive_QNode[6]
(from all states)
[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为true，则向NSLP destroy self发出无响应错误，否则发送查询以新值启动无响应计时器
Rule 3:
// Assume the Confirm was lost in transit or the peer has reset;
// restart the handshake
send Query
(re)start No_Response timer
Rule 3:
// Assume the Confirm was lost in transit or the peer has reset;
// restart the handshake
send Query
(re)start No_Response timer
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标志，则创建一个MA-SM发送确认发送任何存储的数据消息停止无响应计时器启动刷新计时器启动非活动计时器启动非活动计时器如果没有运行，如果有搭载的NSLP数据，则将其传递给NSLP重启非活动计时器
Rule 5: send Data message restart Inactive_QNode timer
规则5：发送数据消息重新启动非活动节点计时器
Rule 6: Terminate
规则6：终止
Rule 7: pass any data to the NSLP restart Inactive_QNode timer
规则7：将任何数据传递给NSLP重新启动非活动节点计时器
Rule 8: send Query start No_Response timer stop Refresh_QNode timer
规则8：发送查询开始无响应计时器停止刷新QNode计时器
The Responding-Node state machine (Responding-SM) has three states:
响应节点状态机（响应SM）有三种状态：
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创建的策略有三种情况：
1. No Confirm is required for a Query, and the state machine can be created immediately.
1. 查询不需要确认，可以立即创建状态机。
2. A Confirm is required for a Query, but the state machine can still be created immediately. A timer is used to retransmit Response messages and the Responding-SM is destroyed if no valid Confirm is received.
2. 查询需要确认，但仍然可以立即创建状态机。计时器用于重新传输响应消息，如果未收到有效确认，则会销毁响应SM。
3. A Confirm is required for a Query, and the state machine can only be created when it is received; the initial Query will have been handled by the Node-level machine.
3. 查询需要确认，只有收到状态机时才能创建状态机；初始查询将由节点级计算机处理。
In case 2, the Responding-SM is created in the Awaiting Confirm state, and remains there until a Confirm is received, at which point it transitions to Established. In cases 1 and 3, the Responding-SM is created directly in the Established state. Note that if the machine is created on receiving a Query, some of the message processing will already have been performed in the node state machine. In principle, an implementation MAY change its policy on handling a Query message at any time; however, the state machine descriptions here cover only the case where the policy is fixed while waiting for a Confirm message.
在情况2中，响应SM在等待确认状态下创建，并保持在那里，直到收到确认，此时它转换为已建立。在情况1和3中，直接在已建立状态下创建响应SM。注意，如果机器是在接收查询时创建的，那么一些消息处理将已经在节点状态机中执行。原则上，实现可以随时更改其处理查询消息的策略；但是，此处的状态机描述仅涵盖在等待确认消息时策略已修复的情况。
In the Established state, the NSLP can send and receive data normally, and any additional rx_Confirm events MUST be silently ignored. The Awaiting Refresh state can be considered a substate of Established, where a Query has been received to begin the routing state refresh. In the Awaiting Refresh state, the Responding-SM behaves as in the Awaiting Confirm state, except that the NSLP can still send and receive data. In particular, in both states there is timer-based retransmission of Response messages until a Confirm is received; additional rx_Query events in these states MUST also generate a reply and restart the no_Confirm timer.
在已建立的状态下，NSLP可以正常发送和接收数据，任何额外的rx_确认事件都必须被静默忽略。等待刷新状态可被视为已建立的子状态，其中已接收到开始路由状态刷新的查询。在等待刷新状态下，响应SM的行为与等待确认状态相同，只是NSLP仍然可以发送和接收数据。特别地，在这两种状态中，在接收到确认之前，存在基于定时器的响应消息的重传；这些状态下的其他rx_查询事件还必须生成应答并重新启动no_确认计时器。
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\u RNode：指示此状态机存储的路由状态何时需要过期。每当接收到指示路由状态仍然有效的查询或确认（取决于本地策略）时，它就会重置。请注意，无法从R节点刷新状态。如果此计时器启动，则路由状态机将被删除，而与否确认计时器是否正在运行无关。
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)
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的响应（重新）启动不确认计时器和初始计时器值
Rule 2: pass any NSLP-Data object to the NSLP start Expire_RNode timer
规则2：将任何NSLP数据对象传递给NSLP开始过期\r节点计时器
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开始过期\R节点计时器的响应
Rule 6: drop incoming data send "No Routing State" error message
规则6：删除传入数据发送“无路由状态”错误消息
Rule 7: store Data message
规则7：存储数据消息
Rule 8: pass any NSLP-Data object to the NSLP send any stored Data messages stop No_Confirm timer start Expire_RNode timer
规则8：将任何NSLP数据对象传递给NSLP发送任何存储的数据消息停止否\u确认计时器开始过期\u r节点计时器
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为true，则销毁自身，否则发送响应启动无响应计时器
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）建模，以便在GIST中使用一个简单的三状态过程。等待连接状态指示MA正在等待消息传递关联中的每个协议的连接过程完成；这可能涉及创建侦听端点或尝试活动连接。定时器也可能是检测连接故障所必需的（例如，在特定时间段内没有传入连接），但它们没有明确建模。
The Connected state indicates that the MA is open and ready to use and that the node wishes it to remain open. In this state, the node operates a timer (SendHello) to ensure that messages are regularly sent to the peer, to ensure that the peer does not tear down the MA. The node transitions from Connected to Idle (indicating that it no longer needs the association) as a matter of local policy; one way to manage the policy is to use an activity timer but this is not specified explicitly by the state machine (see also Section 4.4.5).
连接状态表示MA已打开并准备好使用，并且节点希望其保持打开状态。在此状态下，节点操作计时器（SendHello），以确保消息定期发送到对等方，以确保对等方不会破坏MA。根据本地策略，节点从已连接转换为空闲（表示不再需要关联）；管理策略的一种方法是使用活动计时器，但状态机未明确指定（另请参见第4.4.5节）。
In the Idle state, the node no longer requires the messaging association but the peer still requires it and is indicating this by sending periodic MA-Hello messages. A different timer (NoHello) operates to purge the MA when these messages stop arriving. If real data is transferred over the MA, the state machine transitions back to Connected.
在空闲状态下，节点不再需要消息关联，但对等方仍然需要它，并通过定期发送MA Hello消息来指示这一点。当这些消息停止到达时，另一个计时器（NoHello）工作以清除MA。如果真实数据通过MA传输，状态机将转换回已连接状态。
At any time in the Connected or Idle states, a node MAY test the connectivity to its peer and the liveness of the GIST instance at that peer by sending an MA-Hello request with R=1. Failure to receive a reply with a matching Hello-ID within a timeout MAY be taken as a reason to trigger er_MAFailure. Initiation of such a test and the timeout setting are left to the discretion of the implementation. Note that er_MAFailure may also be signalled by indications from the underlying messaging association protocols. If a messaging association fails, this MUST be indicated back to the routing state machines that use it, and these MAY generate indications to signalling applications. In particular, if the messaging association was being used to deliver messages reliably, this MUST be reported as a NetworkNotification error (Appendix B.4).
在连接或空闲状态下的任何时候，节点可以通过发送R＝1的MA Hello请求来测试其对等方的连接性以及该对等方的GIST实例的活跃度。未能在超时时间内收到具有匹配Hello ID的回复可能被视为触发er_MAFailure的原因。此类测试的启动和超时设置由实现自行决定。注意，er_MAFailure也可能由来自底层消息关联协议的指示发出信号。如果消息关联失败，则必须将其指示回使用它的路由状态机，这些状态机可能会向信令应用程序生成指示。特别是，如果消息关联用于可靠地传递消息，则必须将其报告为网络通知错误（附录B.4）。
Clearly, many internal details of the messaging association protocols are hidden in this model, especially where the messaging association uses multiple protocol layers. Note also that although the existence of messaging associations is not directly visible to signalling applications, there is some interaction between the two because
显然，消息传递关联协议的许多内部细节隐藏在该模型中，特别是在消息传递关联使用多个协议层的情况下。还要注意的是，尽管消息传递关联的存在对于信令应用程序不是直接可见的，但两者之间存在一些交互，因为
security-related information becomes available during the open process, and this may be indicated to signalling applications if they have requested it.
安全相关信息在开放过程中变得可用，如果信令应用程序已请求，则可向其指示。
The timers relevant to the operation of this state machine are as follows:
与此状态机操作相关的计时器如下所示：
SendHello: Indicates that an MA-Hello message should be sent to the remote node. The period of this timer is determined by the MA-Hold-Time sent by the remote node during the Query/Response/ Confirm exchange.
SendHello：表示应向远程节点发送MA Hello消息。此计时器的周期由远程节点在查询/响应/确认交换期间发送的MA保持时间确定。
NoHello: Indicates that no MA-Hello has been received from the remote node for a period of time. The period of this timer is sent to the remote node as the MA-Hold-Time during the Query/ Response exchange.
NoHello：表示在一段时间内没有从远程节点接收到MA Hello。在查询/响应交换期间，此计时器的周期作为MA保持时间发送到远程节点。
The detailed state transitions and processing rules are described below as in the Query node case.
详细的状态转换和处理规则如下所述，如查询节点案例所示。
[Initialisation] +-----+
----------------------------|Birth|
| +-----+ tg_RawData[1]
| || rx_Message[2]
| || rx_MA-Hello[3]
| tg_RawData[5] || to_SendHello[4]
| -------- --------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | tg_Connected[6] | Connected |
------|Connection|----------------------->>| |
| +----------+ +-----------+
| ^ |
| tg_RawData[1] ^ |
| || rx_Message[2] | | tg_MAIdle[7]
| | V
| | V
| er_MAConnect[8] +-----+ to_NoHello[8] +-----------+
---------------->>|Death|<<----------------| Idle |
+-----+ +-----------+
^ ^ |
^ ^ |
--------------- --------
er_MAFailure[8] rx_MA-Hello[9]
(from Connected/Idle)
[Initialisation] +-----+
----------------------------|Birth|
| +-----+ tg_RawData[1]
| || rx_Message[2]
| || rx_MA-Hello[3]
| tg_RawData[5] || to_SendHello[4]
| -------- --------
| | V | V
| | V | V
| +----------+ +-----------+
---->>| Awaiting | tg_Connected[6] | Connected |
------|Connection|----------------------->>| |
| +----------+ +-----------+
| ^ |
| tg_RawData[1] ^ |
| || rx_Message[2] | | tg_MAIdle[7]
| | V
| | V
| er_MAConnect[8] +-----+ to_NoHello[8] +-----------+
---------------->>|Death|<<----------------| Idle |
+-----+ +-----------+
^ ^ |
^ ^ |
--------------- --------
er_MAFailure[8] rx_MA-Hello[9]
(from Connected/Idle)
Figure 9: Messaging Association State Machine
图9：消息关联状态机
The processing rules are as follows:
处理规则如下：
Rule 1: pass message to transport layer if the NoHello timer was running, stop it (re)start SendHello
规则1：将消息传递到传输层如果NoHello计时器正在运行，请停止它（重新）启动SendHello
Rule 2: pass message to Node-SM, or R-SM (for a Confirm), or Q-SM (for a Response) if the NoHello timer was running, stop it
规则2：将消息传递给节点SM、R-SM（用于确认）或Q-SM（用于响应）。如果NoHello计时器正在运行，请停止它
Rule 3: if reply requested send MA-Hello restart SendHello timer
规则3：如果请求回复发送MA Hello，则重新启动SendHello计时器
Rule 4: send MA-Hello message restart SendHello timer
规则4：发送MA Hello消息重新启动SendHello计时器
Rule 5: queue message for later transmission
规则5：将消息排队以供以后传输
Rule 6: pass outstanding queued messages to transport layer stop any timers controlling connection establishment start SendHello timer
规则6：将未完成的排队消息传递给传输层停止控制连接建立的任何计时器启动SendHello计时器
Rule 7: stop SendHello timer start NoHello timer
规则7：停止发送Hello计时器启动NoHello计时器
Rule 8: report failure to routing state machines and signalling applications destroy self
规则8：向路由状态机和信令应用程序报告故障
Rule 9: if reply requested send MA-Hello restart NoHello timer
规则9：如果请求回复，发送MA Hello重新启动NoHello计时器
When IP layer rerouting takes place in the network, GIST and signalling application state need to be updated for all flows whose paths have changed. The updates to signalling application state depend mainly on the signalling application: for example, if the path characteristics have changed, simply moving state from the old to the new path is not sufficient. Therefore, GIST cannot complete the path update processing by itself. Its responsibilities are to detect the route change, update its local routing state consistently, and inform interested signalling applications at affected nodes.
当网络中发生IP层重新路由时，需要为其路径已更改的所有流更新GIST和信令应用程序状态。对信令应用程序状态的更新主要取决于信令应用程序：例如，如果路径特征已更改，仅将状态从旧路径移动到新路径是不够的。因此，GIST无法自行完成路径更新处理。它的职责是检测路由变化，一致地更新其本地路由状态，并通知受影响节点上感兴趣的信令应用程序。
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
x +--+ +--+ +--+ x Initial
x .|C1|_.....|D1|_.....|E1| x Configuration
x . +--+. .+--+. .+--+\. x
>>xxxxxxxxxxxxx . . . . . . xxxxxx>>
+-+ +-+ . .. .. . +-+
...|A|_......|B|/ .. .. .|F|_....
+-+ +-+ . . . . . . +-+
. . . . . .
. +--+ +--+ +--+ .
.|C2|_.....|D2|_.....|E2|/
+--+ +--+ +--+
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
+--+ +--+ +--+ 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
........... = physical link topology
>>xxxxxxx>> = flow direction
_.......... = outgoing link for flow xxxxxx given
by local forwarding table
Figure 10: A Rerouting Event
图10：重新路由事件
Route change management is complicated by the distributed nature of the problem. Consider the rerouting event shown in Figure 10. An external observer can tell that the main responsibility for controlling the updates will probably lie with nodes B and F; however, E1 is best placed to detect the event quickly at the GIST level, and C1 and D1 could also attempt to initiate the repair.
路线变更管理由于问题的分布性而变得复杂。考虑图10所示的重路由事件。外部观察者可以判断控制更新的主要责任可能在于节点B和F；但是，E1最适合在GIST级别快速检测事件，C1和D1也可以尝试启动修复。
The NSIS framework [29] makes the assumption that signalling applications are soft-state based and operate end to end. In this case, because GIST also periodically updates its picture of routing state, route changes will eventually be repaired automatically. The specification as already given includes this functionality. However, especially if upper layer refresh times are extended to reduce signalling load, the duration of inconsistent state may be very long indeed. Therefore, GIST includes logic to exchange prompt notifications with signalling applications, to allow local repair if possible. The additional mechanisms to achieve this are described in the following subsections. To a large extent, these additions can be seen as implementation issues; the protocol messages and their significance are not changed, but there are extra interactions through the API between GIST and signalling applications, and additional triggers for transitions between the various GIST states.
NSIS框架[29]假设信令应用程序是基于软状态的，并且端到端运行。在这种情况下，由于GIST还定期更新其路由状态图片，因此路由更改最终将自动修复。已经给出的规范包括此功能。然而，特别是如果延长上层刷新时间以减少信令负载，则不一致状态的持续时间可能确实很长。因此，GIST包括与信令应用程序交换提示通知的逻辑，以便在可能的情况下允许本地修复。实现这一点的其他机制将在以下小节中描述。在很大程度上，这些增加可以被视为执行问题；协议消息及其重要性没有改变，但GIST和信令应用程序之间通过API进行了额外的交互，并为各种GIST状态之间的转换提供了额外的触发器。
There are two aspects to detecting a route change at a single node:
检测单个节点上的路由更改有两个方面：
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).
在单个节点上，这些过程在很大程度上是独立的，尽管很明显，节点上一个方向的变化对应于对等节点上相反方向的变化。请注意，路由更改有两种可能的形式：流离开或进入节点的接口可能会更改，而相邻的对等节点可能会更改。一般来说，路线更改可以包括一个或另一个或两个（或者两者都不包括，尽管这种更改很难检测到）。
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
节点可用的路由更改检测机制取决于使用中的MRM以及节点在设置路由状态时首先扮演的角色（即，作为查询或响应节点）。以下讨论针对路径耦合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.
仅使用下游查询；其他场景可能需要其他方法。然而，后续小节中描述的维修逻辑是通用的。
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.
节点有五种机制来检测发生的路由更改，如下所示。根据更改是在查询方向上还是在响应方向上，它们的应用有所不同，下表总结了这些差异。
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路由跳转之外发生，包括在一个节点上发生的情况。
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-mode监控：GIST可能会发现C-mode数据包（来自任何一个对等方）以不同的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 |
+-------------+--------------------------+--------------------------+
+-------------+--------------------------+--------------------------+
| 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行为可以使用当前路由状态每个项目有效性的三级分类进行建模。（除了当前路由状态外，NSI还可以保持过去的路由状态，如下文第7.1.4节所述。）该分类分别适用于每对GIST对等点的查询和响应节点。这些级别是：
Bad: The routing state is either missing altogether or not safe to use to send data.
错误：路由状态要么完全丢失，要么用于发送数据不安全。
Tentative: The routing state may have changed, but it is still usable for sending NSLP data pending verification.
暂定：路由状态可能已更改，但仍可用于发送待验证的NSLP数据。
Good: The routing state has been established and no events affecting it have since been detected.
良好：路由状态已建立，此后未检测到影响路由状态的事件。
These classifications are not identical to the states described in Section 6, but there are dependencies between them. Specifically, routing state is considered Bad until the state machine first enters the Established state, at which point it becomes Good. Thereafter, the status may be invalidated for any of the reasons discussed above; it is an implementation issue to decide which techniques to implement in any given node, and how to reclassify routing state (as Bad or Tentative) for each. The status returns to Good, either when the state machine re-enters the Established state or if GIST can
这些分类与第6节中描述的状态不同，但它们之间存在依赖关系。具体来说，在状态机第一次进入已建立状态之前，路由状态被认为是坏的，在该状态机第一次进入已建立状态时，路由状态变为好的。此后，该状态可能因上述任何原因而无效；一个实现问题是决定在任何给定节点中实现哪些技术，以及如何为每个节点重新分类路由状态（坏的或暂时的）。当状态机重新进入已建立状态或GIST可以恢复时，状态将恢复为良好
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.
通过直接检查IP路由或转发表，确定对等方未发生更改。当状态恢复为良好时，GIST必须在必要时更新其路由状态表，以便MRI/SID/NSLPID元组和消息关联之间的关系是最新的。
When classification of the routing state for the downstream direction changes to Bad/Tentative because of local IP routing indications, GIST MAY automatically change the classification in the upstream direction to Tentative unless local routing indicates that this is not necessary. This SHOULD NOT be done in the case where the initial change was indicated by the signalling application. This mechanism accounts for the fact that a routing change may affect several nodes, and so can be an indication that upstream routing may also have changed. In any case, whenever GIST updates the routing status, it informs the signalling application with the NetworkNotification API (Appendix B.4), unless the change was caused via the API in the first place.
当下游方向的路由状态分类由于本地IP路由指示而更改为坏/暂定时，GIST可自动将上游方向的分类更改为暂定，除非本地路由指示不需要这样做。在信号应用程序指示初始变化的情况下，不应这样做。这种机制解释了路由更改可能会影响多个节点的事实，因此可以表示上游路由也可能已更改。在任何情况下，只要GIST更新路由状态，它就会用NetworkNotification API（附录B.4）通知信令应用程序，除非更改首先是通过API引起的。
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行为是不同的。在响应节点上，没有其他行为，因为响应节点无法自主启动协议转换。（它只能对查询节点作出反应。）查询节点有三个选项，具体取决于从良好状态过渡的最初原因：
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
第二和第三种技术触发执行GIST握手以执行修复。可能希望延迟握手过程的开始，以等待网络稳定，避免大量受影响流的查询流量淹没网络，或等待确认节点仍在来自上游对等方的路径上。一种方法是延迟握手，直到有NSLP数据要传输。实施此类延误是当地政策的问题；但是，如果状态发生变化，GIST必须立即开始握手
caused by an InvalidateRoutingState API call marked as 'Urgent', and SHOULD begin it if the upstream routing state is still known to be Good.
由标记为“紧急”的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模式数据包之间不同的报头字段或基于循环的方式进行的，即使底层网络是稳定的，查询发现的路径也可能在一次握手到下一次握手之间变化。这将看起来像是一个路线皮瓣；路由抖动也可能由基本网络连接或路由协议操作中的问题引起。例如，移动节点可能在两个链路之间来回切换，或者可能看起来已经消失，即使它仍然通过不同的路由连接到网络。
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，然后NSLP可以根据信令应用要求对其进行管理。已经描述的算法始终保持当前路由的概念，即为特定流发现的最新对等点。相反，GIST允许在一段时间内使用先前的信令路径，而信令应用程序仍然需要它们。由于NSLP对等点之间是单跳的，因此表示路径的必要信息可以只是该流的节点路由状态表中的一个条目（更一般地说，可以使用唯一标识对等点的任何信息，例如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
请注意，GIST（如果可能）应在同一对等方的多个会话中使用相同的SII句柄，因为这将允许信令应用程序聚合一些信令，例如摘要刷新或批量拆分。使用SII句柄发送的消息必须绕过发送方的路由状态表，这必须通过在公共头中设置E标志来指示（附录A.1）。数据消息以外的消息不得以这种方式发送。在接收器处，GIST不得根据本地数据验证MRI/SID/NSLPID
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.
路由状态，而是通过API指示信号应用程序的接收模式（附录B.2）。信令应用程序应验证消息本身的来源和效果，如果合适，应特别向GIST（见附录B.5）表明该流不再需要路由状态。这对于防止旧路径上的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）。最低限度的实现可能会将路由更改作为单个（添加、删除）操作通知；然而，更复杂的实现可能会延迟删除通知，例如，如果它知道旧路由继续并行使用，或者真实路由在两者之间摆动。然后是信令应用程序设计的问题，即是拆除旧路径上的状态，保持不变，还是以特定于信令应用程序的方式对其进行修改，以反映多条路径并行运行的事实。
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对等发现过程的细节强制执行的。
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来通知。由于本地转发表的触发，下游状态被更新为Bad，因此上游状态自动更改为暂定状态。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不再在路径上，因此原则上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
例如，对于路径耦合的MRM，GIST消息必须携带寻址和更高层信息作为有效负载数据，以便定义为其发送信号的流。（这适用于所有GIST消息，无论它们是如何封装的，也不管它们是朝哪个方向移动的。）在寻址边界处，数据流包将对其头部进行翻译；如果没有一致地转换信令有效负载，则信令消息将在通过
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握手消息携带有关GIST节点本身的附加寻址信息，并且在穿越NAT时也必须适当处理这些信息。
There is a dual problem of whether the GIST peers on either side of the boundary can work out how to address each other, and whether they can work out what translation to apply to the signalling packet payloads. Existing generic NAT traversal techniques such as Session Traversal Utilities for NAT (STUN) [26] or Traversal Using Relays around NAT (TURN) [27] can operate only on the two addresses visible in the IP header. It is therefore intrinsically difficult to use these techniques to discover a consistent translation of the three or four interdependent addresses for the flow and signalling source and destination.
存在一个双重问题，即边界两侧的GIST对等方是否能够确定如何相互寻址，以及它们是否能够确定将什么转换应用于信令分组有效负载。现有的通用NAT遍历技术，如NAT的会话遍历实用程序（STUN）[26]或使用NAT周围的中继进行遍历（TURN）[27]，只能在IP报头中可见的两个地址上运行。因此，本质上很难使用这些技术来发现流和信令源和目的地的三个或四个相互依赖的地址的一致转换。
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规范仅限于检测情况并触发适当的错误条件以终止信令路径。（不包含寻址信息的MRM可以安全地穿越此类NAT，并对GIST处理规则进行一些修改。此类修改可在定义此类MRM的文件中描述。）下面第7.2.1节介绍了遗留NAT处理。使用NAT本身的GIST感知可以构建更通用的解决方案；第7.2.2节概述了该解决方案，第7.2.3节介绍了处理规则。
In all cases, GIST interaction with the NAT is determined by the way the NAT handles the Query/Response messages in the initial GIST handshake; these messages are UDP datagrams. Best current practice for NAT treatment of UDP traffic is defined in [38], and the legacy NAT handling defined in this specification is fully consistent with that document. The GIST-aware NAT traversal technique is equivalent to requiring an Application Layer Gateway in the NAT for a specific class of UDP transactions -- namely, those where the destination UDP port for the initial message is the GIST port (see Section 9).
在所有情况下，GIST与NAT的交互由NAT在初始GIST握手中处理查询/响应消息的方式决定；这些消息是UDP数据报。[38]中定义了UDP流量NAT处理的最佳当前实践，本规范中定义的传统NAT处理与该文档完全一致。GIST感知NAT遍历技术相当于要求NAT中的应用层网关用于特定类别的UDP事务，即初始消息的目标UDP端口为GIST端口的事务（参见第9节）。
Legacy NAT detection during the GIST handshake depends on analysis of the IP header and S-flag in the GIST common header, and the NLI object included in the handshake messages. The message sequence proceeds differently depending on whether the Querying node is on the internal or external side of the NAT.
GIST握手期间的传统NAT检测取决于对GIST公共报头中的IP报头和S标志以及握手消息中包含的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-
对于NAT内部的查询节点，如果在查询中未设置S标志（S=0），则无法检测到遗留NAT。接收方将对查询中NLI中给出的接口地址生成正常响应，但接口-
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=0，则此行为将持续到查询节点超时。因此，信令路径将在该点终止，而不是穿过NAT。
The situation changes once S=1 in a Query; note the Q-mode encapsulation rules recommend that S=1 is used at least for some retransmissions (see Section 5.8). If S=1, the receiver MUST check the source address in the IP header against the interface-address in the NLI. A legacy NAT has been found if these addresses do not match. For MRMs that contain addressing information that needs translation, legacy NAT traversal is not possible. The receiver MUST return an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object") indicating the MRI as the object in question. The error message MUST be addressed to the source address from the IP header of the incoming message. The Responding node SHOULD use the destination IP address of the original datagram as the source address for IP header of the Response; this makes it more likely that the NAT will accept the incoming message, since it looks like a normal UDP/IP request/reply exchange. If this message is able to traverse back through the NAT, the Querying node will terminate the handshake immediately; otherwise, this reduces to the previous case of a lost Response and the Querying node will give up on reaching its retransmission limit.
在查询中，一旦S=1，情况就会发生变化；注：Q模式封装规则建议至少在某些重传中使用S=1（见第5.8节）。如果S=1，接收方必须对照NLI中的接口地址检查IP报头中的源地址。如果这些地址不匹配，则已找到旧NAT。对于包含需要转换的寻址信息的MRM，传统NAT遍历是不可能的。接收器必须返回“对象类型错误”消息（附录A.4.4.9），子代码为4（“未翻译对象”），表明MRI为相关对象。错误消息必须从传入消息的IP头发送到源地址。响应节点应使用原始数据报的目的IP地址作为响应IP报头的源地址；这使得NAT更有可能接受传入消息，因为它看起来像一个普通的UDP/IP请求/应答交换。如果该消息能够穿越NAT，查询节点将立即终止握手；否则，这将减少到前一种丢失响应的情况，并且查询节点将在达到其重传限制时放弃。
When the Querying node is on the external side of the NAT, the Query will only traverse the NAT if some static configuration has been carried out on the NAT to forward GIST Q-mode traffic to a node on the internal network. Regardless of the S-flag in the Query, the Responding node cannot directly detect the presence of the NAT. It MUST send a normal Response with S=1 to an address derived from the Querying node's NLI that will traverse the NAT as normal UDP traffic. The Querying node MUST check the source address in the IP header with the NLI in the Response, and when it finds a mismatch it MUST terminate the handshake.
当查询节点位于NAT的外部时，只有在NAT上执行了一些静态配置以将GIST Q模式流量转发到内部网络上的节点时，查询才会遍历NAT。不管查询中的S标志是什么，响应节点都无法直接检测NAT的存在。它必须将S=1的正常响应发送到从查询节点的NLI派生的地址，该NLI将作为正常UDP通信量遍历NAT。查询节点必须使用响应中的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），则NAT应拒绝带有子代码4（“未翻译对象”）的“对象类型错误”消息（附录A.4.4.9）的消息。
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.
本规范定义了一个附加的NAT遍历对象，NAT将该对象插入到所有无上下文标志C=1的Q模式封装消息中，GIST在任何回复（即响应或错误消息）中回显。NAT仅对C=1的Q模式封装消息或承载NAT遍历对象的D模式消息应用GIST特定处理。所有其他GIST消息，无论是C模式中的消息还是D模式中没有NAT遍历对象的消息，都应被NAT视为正常数据流量，即，具有IP和传输层头翻译，但没有GIST特定处理。注意，对于NAT来说，Q模式和D模式封装之间的区别可能不可见，这就是为什么使用C标志的设置或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
NAT穿越对象（附录A.3.9）承载适用于NAT内外侧的MRI之间的转换。它还包含消息中已翻译的其他对象的列表。这应始终包括NLI和堆栈配置数据（如果存在）；如果GIST扩展为包含寻址数据的其他对象，则此列表允许
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是否支持新对象。最后，NAT遍历对象可用于携带数据以协助NAT反向转换D模式响应；这可能是原始的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值来表示相同的流量。但是，查询/响应之后的消息（初始确认和后续数据消息）需要使用公共MRI，因为NAT不会重写这些消息，而这将被选择为查询节点的MRI。响应节点负责在入站和出站消息的两个MRI之间进行转换，这就是未修改的MRI在NAT遍历对象中传播的原因。
This specification normatively defines the behaviour of a GIST node receiving a message containing a NAT-Traversal object. However, it does not define normative behaviour for a NAT translating GIST messages, since much of this will depend on NAT implementation and policy about allocating bindings. In addition, it is not necessary for a GIST implementation itself. Therefore, those aspects of the following description are informative; full details of NAT behaviour for handling GIST messages can be found in [44].
该规范规范性地定义了接收包含NAT遍历对象的消息的GIST节点的行为。但是，它没有定义NAT转换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.
NAT处理C=1消息的一组可能操作如下所示。请注意，对于数据消息，只有操作的子集是适用的。
1. Verify that bindings for any data flow are actually in place.
1. 验证任何数据流的绑定是否实际到位。
2. Create a new Message-Routing-Information object with fields modified according to the data flow bindings.
2. 创建一个新的消息路由信息对象，其中的字段根据数据流绑定进行修改。
3. Create bindings for subsequent C-mode signalling based on the information in the Network-Layer-Information and Stack-Configuration-Data objects.
3. 根据网络层信息和堆栈配置数据对象中的信息，为后续C模式信令创建绑定。
4. Create new Network-Layer-Information and if necessary Stack-Configuration-Data objects with fields to force D-mode response messages through the NAT, and to allow C-mode exchanges using the C-mode signalling bindings.
4. 创建新的网络层信息，并在必要时使用字段堆叠配置数据对象，以强制D模式响应消息通过NAT，并允许使用C模式信令绑定进行C模式交换。
5. Add a NAT-Traversal object, listing the objects that have been modified and including the unmodified MRI and any other data needed to interpret the response. If a NAT-Traversal object is already present, in the case of a sequence of NATs, the list of modified objects may be updated and further opaque data added, but the MRI contained in it is left unchanged.
5. 添加NAT遍历对象，列出已修改的对象，包括未修改的MRI和解释响应所需的任何其他数据。如果NAT遍历对象已经存在，则在NAT序列的情况下，可以更新修改对象的列表并添加进一步的不透明数据，但其中包含的MRI保持不变。
6. Encapsulate the message according to the normal rules of this specification for the Q-mode encapsulation. If the S-flag was set in the original message, the same IP source address selection policy should be applied to the forwarded message.
6. 根据本规范中Q模式封装的正常规则封装消息。如果在原始邮件中设置了S标志，则应将相同的IP源地址选择策略应用于转发的邮件。
7. Forward the message with these new payloads.
7. 用这些新的有效载荷转发消息。
A GIST node receiving such a message MUST verify that all mandatory objects containing addressing have been translated correctly, or else reject the message with an "Object Type Error" message (Appendix A.4.4.9) with subcode 4 ("Untranslated Object"). The error message MUST include the NAT-Traversal object as the first TLV after the common header, and this is also true for any other error message generated as a reply. Otherwise, the message is processed essentially as normal. If no state needs to be updated for the message, the NAT-Traversal object can be effectively ignored. The other possibility is that a Response must be returned, because the message is either the beginning of a handshake for a new flow or a refresh for existing state. In both cases, the GIST node MUST create the Response in the normal way using the local form of the MRI, and its own NLI and (if necessary) SCD. It MUST also include the NAT-Traversal object as the first object in the Response after the common header.
接收此类消息的GIST节点必须验证包含寻址的所有强制对象是否已正确翻译，或者使用带有子代码4（“未翻译对象”）的“对象类型错误”消息（附录A.4.4.9）拒绝该消息。错误消息必须包括NAT遍历对象作为公共头之后的第一个TLV，对于作为应答生成的任何其他错误消息也是如此。否则，消息基本上按正常方式处理。如果不需要更新消息的状态，可以有效地忽略NAT遍历对象。另一种可能性是必须返回响应，因为该消息要么是新流握手的开始，要么是现有状态的刷新。在这两种情况下，GIST节点必须使用MRI的局部形式以及其自身的NLI和（如有必要）SCD以正常方式创建响应。它还必须包括NAT遍历对象，作为公共头之后响应中的第一个对象。
A NAT will intercept D-mode messages containing such echoed NAT-Traversal objects. The NAT processing is a subset of the processing for the C=1 case:
NAT将截获包含此类回显NAT遍历对象的D模式消息。NAT处理是C=1情况下处理的子集：
1. Verify the existence of bindings for the data flow.
1. 验证数据流是否存在绑定。
2. Leave the Message-Routing-Information object unchanged.
2. 保持邮件路由信息对象不变。
3. Modify the NLI and SCD objects for the Responding node if necessary, and create or update any bindings for C-mode signalling traffic.
3. 如有必要，修改响应节点的NLI和SCD对象，并为C模式信令流量创建或更新任何绑定。
4. Forward the message.
4. 转发消息。
A GIST node receiving such a message (Response or Error) MUST use the MRI from the NAT-Traversal object as the key to index its internal routing state; it MAY also store the translated MRI for additional (e.g., diagnostic) information, but this is not used in the GIST processing. The remainder of GIST processing is unchanged.
接收此类消息（响应或错误）的GIST节点必须使用来自NAT遍历对象的MRI作为索引其内部路由状态的键；它还可以存储翻译后的MRI以获取附加（例如，诊断）信息，但这不用于GIST处理。GIST处理的其余部分保持不变。
Note that Confirm messages are not given GIST-specific processing by the NAT. Thus, a Responding node that has delayed state installation until receiving the Confirm only has available the untranslated MRI describing the flow, and the untranslated NLI as peer routing state. This would prevent the correct interpretation of the signalling messages; also, subsequent Query (refresh) messages would always be seen as route changes because of the NLI change. Therefore, a Responding node that wishes to delay state installation until receiving a Confirm must somehow reconstruct the translations when the Confirm arrives. How to do this is an implementation issue; one approach is to carry the translated objects as part of the Responder-Cookie that is echoed in the Confirm. Indeed, for one of the cookie constructions in Section 8.5 this is automatic.
请注意，NAT不会对确认消息进行GIST特定的处理。因此，延迟状态安装直到接收确认的响应节点仅具有描述流的未翻译MRI和作为对等路由状态的未翻译NLI。这将妨碍对信令消息的正确解释；此外，由于NLI更改，后续查询（刷新）消息将始终被视为路由更改。因此，希望延迟状态安装直到收到确认的响应节点必须在确认到达时以某种方式重建翻译。如何做到这一点是一个实施问题；一种方法是将翻译后的对象作为响应器Cookie的一部分携带，该Cookie在确认中被回响。事实上，对于第8.5节中的cookie构造之一，这是自动的。
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协议封装（例如端口号）都将隐藏在标准隧道封装中。如果隧道本身需要信令，则必须由其中一个隧道端点作为单独的信令会话启动—也就是说，隧道计为新流。由于微流信号和整个隧道信号之间的关系将取决于相关的信号应用，因此，信号应用负责了解隧道正在进行的事实，并在必要时执行额外的信号；换句话说，至少有一个隧道端点必须能够感知应用程序的信令。
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
在某些情况下，希望执行隧道信令的是隧道出口点（即隧道数据和下游信令包离开隧道的节点），但该节点不知道或控制隧道入口点如何执行数据流封装。需要携带有关内部MRI/SID与隧道MRI/SID之间关系的信息
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.
来自隧道入口点的信令数据；此功能相当于[18]中的RSVP SESSION_ASSOC对象。在NSIS协议套件中，这些绑定由信令应用程序管理，或者隐式（例如，通过SID重用）或者显式地通过携带将内部和外部SID绑定为NSLP有效负载一部分的对象来管理。
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版本发送信号，并且还应使用相同的IP版本发送其他信号（见第5.2.2节）。版本不匹配的消息必须被拒绝，并显示子代码为1（“IP版本不匹配”）的“MRI验证失败”错误消息（附录A.4.4.12）。D模式中使用的IP版本与数据流使用的IP版本密切相关，因此仅IPv4或仅IPv6 GIST节点本质上不可能支持使用其他IP版本的流的信令。对于应用程序来说是双栈的主机和对于转发来说是双栈的路由器需要能够支持这两个IP版本的GIST实现。可以选择IP版本的应用程序可以选择GIST在网络中支持的版本，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节点通过在它们之间放置数据包转换器进行通信。从GIST的角度来看，这应该与第7.2节中描述的任何其他NAT操作（例如，内部和外部地址之间）基本相同。翻译节点需要注意要点；它将必须在IPv4和IPv6格式之间转换寻址有效负载，以实现跨IPv4和IPv6格式的流。MRI有效载荷中字段的转换规则（包括，例如，diffserv codepoint和flow label）如[7]中所定义。同样的分析也适用于NAT-PT，尽管这种技术不再被提议作为通用转换机制[40]。
Tunnelling: (Applicable to 6to4 [19].) Many transition mechanisms handle the problem of how an end-to-end IPv6 (or IPv4) flow can be carried over intermediate IPv4 (or IPv6) regions by tunnelling; the methods tend to focus on minimising the tunnel administration overhead. For GIST, the treatment should be similar to any other IP tunnelling mechanism, as described in Section 7.3. In particular, the end-to-end flow signalling will pass transparently through the tunnel, and signalling for the tunnel itself will have to be managed by the tunnel endpoints. However, additional considerations may arise because of special features of the tunnel management procedures. In particular, [20] is based on using an anycast address as the destination tunnel endpoint. GIST MAY use anycast destination addresses in the Q-mode encapsulation of D-mode messages if necessary, but MUST NOT use them in the Network-Layer-Information addressing field; unicast addresses MUST be used instead. Note that the addresses from the IP header are not used by GIST in matching requests and replies, so there is no requirement to use anycast source addresses.
隧道：（适用于6to4[19]）许多转换机制处理如何通过隧道在中间IPv4（或IPv6）区域上传输端到端IPv6（或IPv4）流的问题；这些方法倾向于将隧道管理开销降至最低。对于GIST，处理应类似于第7.3节所述的任何其他IP隧道机制。特别是，端到端流量信令将透明地通过隧道，隧道本身的信令必须由隧道端点管理。然而，由于隧道管理程序的特殊性，可能会引起额外的考虑。具体而言，[20]基于使用选播地址作为目标隧道端点。如有必要，GIST可在D模式消息的Q模式封装中使用选播目标地址，但不得在网络层信息寻址字段中使用它们；必须改用单播地址。请注意，GIST在匹配请求和回复时不使用IP头中的地址，因此不需要使用选播源地址。
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.
路由状态完整性保护：重要的是将信令消息传递到正确的节点，而不是其他节点。这里，“correct”定义为“给定消息路由信息的信令的适当节点”。在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节点依靠消息传递关联协议来验证下一跳的身份，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和网络路由状态之间的一致性必须通过直接与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）。这必须回显来自上一个查询的cookie，该查询将通过Q模式封装（即端到端寻址）沿流路径发送。因此，只有真正的下一个对等方或路径上的攻击者才能生成这样的消息，前提是可以在查询节点检查cookie的新鲜度。
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:
这样的信息；事实上，网络中的许多节点可能是给定流的真正上游对等点。为了防止出现这种情况，使用了四种策略：
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.
返回可路由性检查：接收节点可能会拒绝安装上游状态，直到完成与对等方的确认握手。这会回显响应的响应器Cookie，并阻止节点使用伪造的源地址。这在防止拒绝服务方面也发挥了作用；见下文。
Authorisation: A stronger approach is to carry out a peer authorisation check (see Section 4.4.2) as part of messaging association setup. The ideal situation is that the receiving node can determine the correct upstream node address from routing table analysis or knowledge of local topology constraints, and then verify from the authorised peer database (APD) that the peer has this IP address. This is only technically feasible in a limited set of deployment environments. The APD can also be used to list the subsets of nodes that are feasible peers for particular source or destination subnets, or to blacklist nodes that have previously originated attacks or exist in untrustworthy networks, which provide weaker levels of authorisation checking.
授权：更强的方法是执行对等授权检查（见第4.4.2节），作为消息关联设置的一部分。理想情况是，接收节点可以通过路由表分析或本地拓扑约束知识确定正确的上游节点地址，然后从授权对等数据库（APD）验证对等方是否具有此IP地址。这仅在有限的部署环境中在技术上可行。APD还可用于列出特定源或目标子网的可行对等节点的子集，或列出先前发起攻击或存在于不可信网络中的黑名单节点，这些节点提供较弱的授权检查级别。
SID segregation: The routing state lookup for a given MRI and NSLPID MUST also take the SID into account. A malicious node can only overwrite existing GIST routing state if it can guess the corresponding SID; it can insert state with random SID values, but generally this will not be used to route signalling messages for which state has already been legitimately established.
SID隔离：给定MRI和NSLPID的路由状态查找也必须考虑SID。恶意节点只能在猜测相应SID的情况下覆盖现有GIST路由状态；它可以插入具有随机SID值的状态，但通常不会用于路由已合法建立状态的信令消息。
GIST is designed so that in general each Query only generates at most one Response that is at most only slightly larger than the Query, so that a GIST node cannot become the source of a denial-of-service amplification attack. (There is a special case of retransmitted Response messages; see Section 5.3.3.)
GIST的设计使得通常每个查询最多只能生成一个响应，该响应最多只能略大于查询，因此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洪水攻击的问题。此外，作为此类攻击的一部分，敌方可能会使用经过修改或重放的未受保护的信令消息。有两种类型的状态攻击和一种计算资源攻击。在第一次状态攻击中，攻击者向节点发送大量消息，该节点必须存储这些消息，直到能够确定下一跳。如果选择了目标地址，使得下一跳没有GIST功能，则节点将累积消息数秒，直到发现重传尝试超时。第二类基于状态的攻击导致GIST状态由虚假消息建立。相关的计算/网络资源攻击使用未经验证的消息导致节点查询身份验证或授权基础设施，或尝试以加密方式验证数字签名。
We use a combination of two defences against these attacks:
我们结合使用两种防御措施来抵御这些攻击：
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. 对查询的响应包含一个cookie，该cookie在确认中重复。仅为包含有效cookie的消息建立状态。设置延迟也是往返时间的1.5倍。该机制类似于SCTP[39]和其他现代协议中的机制。
There is a potential overload condition if a node is flooded with Query or Confirm messages. One option is for the node to bypass these messages altogether as described in Section 4.3.2, effectively falling back to being a non-NSIS node. If this is not possible, a node MAY still choose to limit the rate at which it processes Query messages and discard the excess, although it SHOULD first adapt its policy to one of sending Responses statelessly if it is not already doing so. A conformant GIST node will automatically decrease the load by retransmitting Queries with an exponential backoff. A non-conformant node (launching a DoS attack) can generate uncorrelated Queries at an arbitrary rate, which makes it hard to apply rate-limiting without also affecting genuine handshake attempts. However,
如果节点充满查询或确认消息，则可能会出现过载情况。一种选择是节点完全绕过这些消息，如第4.3.2节所述，实际上退回到非NSIS节点。如果这是不可能的，那么节点仍然可以选择限制其处理查询消息的速率并丢弃多余的消息，尽管它应该首先调整其策略以适应无状态发送响应（如果它还没有这样做的话）。一致性GIST节点将通过使用指数退避重新传输查询来自动减少负载。非一致性节点（发起DoS攻击）可以以任意速率生成不相关的查询，这使得在不影响真正握手尝试的情况下很难应用速率限制。然而
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.
如果请求确认消息，cookie将消息绑定到查询节点地址，该地址已通过返回路由性检查验证，并且可以对每个源应用速率限制。
Once a node has decided to establish routing state, there may still be transport and security state to be established between peers. This state setup is also vulnerable to denial-of-service attacks. GIST relies on the implementations of the lower layer protocols that make up messaging associations to mitigate such attacks. In the current specification, the Querying node is always the one wishing to establish a messaging association, so it is the Responding node that needs to be protected. It is possible for an attacking node to execute these protocols legally to set up large numbers of associations that were never used, and Responding node implementations MAY use rate-limiting or other techniques to control the load in such cases.
一旦节点决定建立路由状态，对等节点之间可能仍有传输和安全状态需要建立。此状态设置也容易受到拒绝服务攻击。GIST依赖于组成消息关联的低层协议的实现来减轻此类攻击。在当前规范中，查询节点始终是希望建立消息关联的节点，因此需要保护的是响应节点。攻击节点可能合法地执行这些协议以建立大量从未使用过的关联，并且响应节点实现可能使用速率限制或其他技术来控制此类情况下的负载。
Signalling applications can use the services provided by GIST to defend against certain (e.g., flooding) denial-of-service attacks. In particular, they can elect to process only messages from peers that have passed a return routability check or been authenticated at the messaging association level (see Appendix B.2). Signalling applications that accept messages under other circumstances (in particular, before routing state has been fully established at the GIST level) need to take this into account when designing their denial-of-service prevention mechanisms, for example, by not creating local state as a result of processing such messages. Signalling applications can also manage overload by invoking flow control, as described in Section 4.1.1.
信令应用程序可以使用GIST提供的服务来防御某些（如洪水）拒绝服务攻击。特别是，他们可以选择只处理来自已通过返回可路由性检查或已在消息关联级别验证的对等方的消息（见附录B.2）。在其他情况下（特别是在GIST级别完全建立路由状态之前）接受消息的信令应用程序在设计其拒绝服务预防机制时需要考虑到这一点，例如，在处理此类消息时不创建本地状态。信令应用程序还可以通过调用流控制来管理过载，如第4.1.1节所述。
The requirements on the Query-Cookie can be summarised as follows:
查询Cookie的要求可概括如下：
Liveness: The cookie must be live; that is, it must change from one handshake to the next. This prevents replay attacks.
活力：饼干必须是活的；也就是说，它必须从一次握手转换到下一次握手。这可以防止重播攻击。
Unpredictability: The cookie must not be guessable, e.g., from a sequence or timestamp. This prevents direct forgery after capturing a set of earlier messages.
不可预测性：cookie不能是可猜测的，例如，从序列或时间戳。这可以防止在捕获一组早期消息后直接伪造。
Easily validated: It must be efficient for the Q-Node to validate that a particular cookie matches an in-progress handshake, for a routing state machine that already exists. This allows to discard responses that have been randomly generated by an adversary, or to discard responses to queries that were generated with forged source addresses or an incorrect address in the included NLI object.
易于验证：对于已经存在的路由状态机，Q节点验证特定cookie是否与正在进行的握手匹配必须是有效的。这允许放弃对手随机生成的响应，或放弃对使用伪造源地址或包含的NLI对象中不正确地址生成的查询的响应。
Uniqueness: Each handshake must have a unique cookie since the cookie is used to match responses within a handshake, e.g., when multiple messaging associations are multiplexed over the same transport connection.
唯一性：每次握手都必须有一个唯一的cookie，因为cookie用于匹配握手中的响应，例如，在同一传输连接上多路传输多个消息关联时。
Likewise, the requirements on the Responder-Cookie can be summarised as follows:
同样，对响应者Cookie的要求可以总结如下：
Liveness: The cookie must be live as above, to prevent replay attacks.
活跃度：cookie必须如上所述处于活动状态，以防止重播攻击。
Creation simplicity: The cookie must be lightweight to generate in order to avoid resource exhaustion at the responding node.
创建简单性：为了避免响应节点的资源耗尽，cookie必须是轻量级的才能生成。
Validation simplicity: It must be simple for the R-node to validate that an R-Cookie was generated by itself and no one else, without storing state about the handshake for which it was generated.
验证简单性：R-node必须能够简单地验证R-Cookie是由自身生成的，而不是由其他人生成的，并且不存储生成该R-Cookie的握手的状态。
Binding: The cookie must be bound to the routing state that will be installed, to prevent use with different routing state, e.g., in a modified Confirm. The routing state here includes the Peer-Identity and Interface-Address given in the NLI of the Query, and the MRI/NSLPID for the messaging.
绑定：cookie必须绑定到将要安装的路由状态，以防止使用不同的路由状态，例如，在修改的确认中。此处的路由状态包括查询的NLI中给出的对等身份和接口地址，以及消息传递的MRI/NSLPID。
It can also include the interface on which the Query was received for use later in route change detection (Section 7.1.2). Since a Q-mode encapsulated message is the one that will best follow the data path, subsequent changes in this arrival interface indicate route changes between the peers.
它还可以包括接收查询的接口，以便稍后在路线变更检测中使用（第7.1.2节）。由于Q模式封装的消息最符合数据路径，因此此到达接口中的后续更改指示对等方之间的路由更改。
A suitable implementation for the Q-Cookie is a cryptographically strong random number that is unique for this routing state machine handshake. A node MUST implement this or an equivalently strong mechanism. Guidance on random number generation can be found in [31].
Q-Cookie的一个合适实现是一个加密强随机数，它对于这种路由状态机握手是唯一的。节点必须实现此机制或同等强大的机制。有关随机数生成的指导，请参见[31]。
A suitable basic implementation for the R-Cookie is as follows:
适用于R-Cookie的基本实现如下所示：
R-Cookie = liveness data + reception interface + hash (locally known secret, Q-Node NLI identity and address, MRI, NSLPID, liveness data)
R-Cookie=活跃度数据+接收接口+散列（本地已知秘密、Q节点NLI标识和地址、MRI、NSLPID、活跃度数据）
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
节点必须实现此机制或同等强大的机制。活跃度数据有几种选择。一种是使用类似SCTP的时间戳。另一种方法是对本地秘密进行（快速）翻滚，使用活跃度数据作为秘密的生成编号，如IKEv2。在这两种情况下，活性数据都必须
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].
携带到散列之外，以允许在响应者处验证散列。另一种方法是用本地已知秘密下的加密替换散列，在这种情况下，不需要以明文形式携带活跃度数据。可以使用任何对已知明文攻击免疫的对称密码。在GIST感知的NAT穿越和延迟状态安装的情况下，有必要在cookie中携带额外的数据；[44]中描述了适当的构造。
To support the validation simplicity requirement, the Responder can check the liveness data to filter out some blind (flooding) attacks before beginning any cryptographic cookie verification. To support this usage, the liveness data must be carried in the clear and not be easily guessable; this rules out the timestamp approach and suggests the use of sequence of secrets with the liveness data identifying the position in the sequence. The secret strength and rollover frequency must be high enough that the secret cannot be brute-forced during its lifetime. Note that any node can use a Query to discover the current liveness data, so it remains hard to defend against sophisticated attacks that disguise such probes within a flood of Queries from forged source addresses. Therefore, it remains important to use an efficient hashing mechanism or equivalent.
为了支持验证简单性要求，响应者可以在开始任何加密cookie验证之前检查活跃度数据以过滤掉一些盲（泛洪）攻击。为了支持这种用法，活性数据必须以清晰且不易猜测的方式携带；这排除了时间戳方法，并建议使用秘密序列和活跃度数据来标识序列中的位置。秘密强度和翻滚频率必须足够高，以确保秘密在其生命周期内不会被野蛮强制。请注意，任何节点都可以使用查询来发现当前活跃度数据，因此很难抵御复杂的攻击，这些攻击会在大量伪造源地址的查询中隐藏此类探测。因此，使用有效的散列机制或等效机制仍然很重要。
If a node receives a message for which cookie validation fails, it MAY return an "Object Value Error" message (Appendix A.4.4.10) with subcode 4 ("Invalid Cookie") to the sender and SHOULD log an error condition locally, as well as dropping the message. However, sending the error in general makes a node a source of backscatter. Therefore, this MUST only be enabled selectively, e.g., during initial deployment or debugging.
如果节点接收到cookie验证失败的消息，它可能会向发送方返回带有子代码4（“无效cookie”）的“对象值错误”消息（附录a.4.4.10），并应在本地记录错误情况，同时删除该消息。但是，发送错误通常会使节点成为后向散射源。因此，这只能选择性地启用，例如在初始部署或调试期间。
This specification defines a single mandatory-to-implement security protocol (TLS; Section 5.7.3). However, it is possible to define additional security protocols in the future, for example, to allow re-use with other types of credentials, or migrate towards protocols with stronger security properties. In addition, use of any security protocol for a messaging association is optional. Security protocol selection is carried out as part of the GIST handshake mechanism (Section 4.4.1).
本规范规定了实施安全协议（TLS；第5.7.3节）的单一强制性要求。但是，将来可以定义其他安全协议，例如，允许与其他类型的凭据一起重新使用，或者迁移到具有更强安全属性的协议。此外，对消息关联使用任何安全协议都是可选的。安全协议选择是GIST握手机制的一部分（第4.4.1节）。
The selection process may be vulnerable to downgrade attacks, where a man in the middle modifies the capabilities offered in the Query or Response to mislead the peers into accepting a lower level of protection than is achievable. There is a two-part defence against such attacks (the following is based the same concepts as [25]):
选择过程可能易受降级攻击，其中中间人修改查询或响应中提供的能力，以误导对等体接受比所能实现的更低级别的保护。针对此类攻击有两部分防御（以下基于与[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.
第二部分的有效性取决于为确认提供的安全保护的强度。如果查询节点准备创建与空安全属性（例如，仅TCP）的消息关联，则防御是无效的，因为中间的人可以重新插入原始响应者的堆栈建议，并且响应节点将假定最小保护是查询节点限制的结果。但是，如果消息关联至少提供了不能实时中断的完整性保护，则不能以这种方式修改确认。因此，如果查询节点未将安全策略应用于要创建的消息传递关联协议，以确保至少满足此最低级别的保护，则它仍会面临降级的威胁。应用这样的策略可确保功能发现过程将为所涉及的两个对等方建立具有正确安全属性的消息关联。
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.
考虑到上述安全机制，针对NSI的主要剩余威胁有三种类型的路径攻击、特定有限TLS使用模式的漏洞以及与实现相关的弱点。
An on-path attacker who can intercept the initial Query can do most things it wants to the subsequent signalling. It is very hard to protect against this at the GIST level; the only defence is to use strong messaging association security to see whether the Responding node is authorised to take part in NSLP signalling exchanges. To some extent, this behaviour is logically indistinguishable from correct operation, so it is easy to see why defence is difficult. Note that an on-path attacker of this sort can do anything to the traffic as well as the signalling. Therefore, the additional threat induced by the signalling weakness seems tolerable.
能够截获初始查询的路径上攻击者可以对后续的信令执行其想要的大部分操作。在要点层面上很难防范这种情况；唯一的防御措施是使用强消息关联安全性来查看响应节点是否被授权参与NSLP信令交换。在某种程度上，这种行为在逻辑上与正确的操作是无法区分的，因此很容易理解为什么防御是困难的。请注意，这种类型的路径上攻击者可以对通信量和信令做任何事情。因此，信号弱引起的额外威胁似乎是可以容忍的。
At the NSLP level, there is a concern about transitivity of trust of correctness of routing along the signalling chain. The NSLP at the querying node can have good assurance that it is communicating with an on-path peer or a node delegated by the on-path node by depending on the security protection provided by GIST. However, it has no assurance that the node beyond the responder is also on-path, or that the MRI (in particular) is not being modified by the responder to refer to a different flow. Therefore, if it sends signalling messages with payloads (e.g., authorisation tokens) that are valuable to nodes beyond the adjacent hop, it is up to the NSLP to ensure that the appropriate chain of trust exists. This could be achieved using higher layer security protection such as Cryptographic Message Syntax (CMS) [28].
在NSLP级别，人们关注沿信令链的路由正确性信任的传递性。根据GIST提供的安全保护，查询节点处的NSLP可以很好地保证它正在与路径上对等方或路径上节点委托的节点通信。然而，它不能保证响应者之外的节点也在路径上，或者MRI（特别是）没有被响应者修改以引用不同的流。因此，如果它发送带有有效负载（例如，授权令牌）的信令消息，而这些有效负载对相邻跃点以外的节点是有价值的，则由NSLP来确保存在适当的信任链。这可以通过使用更高层的安全保护来实现，如加密消息语法（CMS）[28]。
There is a further residual attack by a node that is not on the path of the Query, but is on the path of the Response, or is able to use a Response from one handshake to interfere with another. The attacker modifies the Response to cause the Querying node to form an adjacency with it rather than the true peer. In principle, this attack could be prevented by including an additional cryptographic object in the Response that ties the Response to the initial Query and the routing state and can be verified by the Querying node.
不在查询路径上，但在响应路径上，或者能够使用一次握手的响应来干扰另一次握手的节点还存在另一次剩余攻击。攻击者修改响应，使查询节点与其相邻，而不是真正的对等节点。原则上，可以通过在响应中包含额外的加密对象来防止此攻击，该对象将响应与初始查询和路由状态联系起来，并可由查询节点进行验证。
GIST depends on TLS for peer node authentication, and subsequent channel security. The analysis in [30] indicates the threats that arise when the peer node authentication is incomplete -- specifically, when unilateral authentication is performed (one node authenticates the other, but not vice versa). In this specification, mutual authentication can be supported either by certificate exchange or the use of pre-shared keys (see Section 5.7.3); if some other TLS authentication mechanism is negotiated, its properties would have to be analysed to determine acceptability for use with GIST. If mutual authentication is performed, the requirements for NTLP security are met.
GIST依赖TLS进行对等节点身份验证和后续通道安全。[30]中的分析指出了对等节点身份验证不完整时产生的威胁——特别是在执行单边身份验证时（一个节点验证另一个节点，但不是相反）。在本规范中，可通过证书交换或使用预共享密钥支持相互认证（见第5.7.3节）；如果协商其他TLS认证机制，则必须分析其属性，以确定与GIST一起使用的可接受性。如果执行相互身份验证，则满足NTLP安全性要求。
However, in the case of certificate exchange, this specification allows the possibility that only a server certificate is provided, which means that the Querying node authenticates the Responding node but not vice versa. Accepting such unilateral authentication allows for partial security in environments where client certificates are not widespread, and is better than no security at all; however, it does expose the Responding node to certain threats described in Section 3.1 of [30]. For example, the Responding node cannot verify whether there is a man-in-the-middle between it and the Querying node, which could be manipulating the signalling messages, and it cannot verify the identity of the Querying node if it requests authorisation of resources. Note that in the case of host-network signalling, the Responding node could be either the host or the first
但是，在证书交换的情况下，该规范允许仅提供服务器证书，这意味着查询节点验证响应节点，而不是相反。接受这种单边身份验证允许在客户端证书不广泛的环境中实现部分安全性，这比完全没有安全性要好；但是，它确实会使响应节点暴露于[30]第3.1节所述的某些威胁。例如，响应节点无法验证它和查询节点之间是否有人，查询节点可能正在操纵信令消息，并且如果请求资源授权，则无法验证查询节点的身份。注意，在主机网络信令的情况下，响应节点可以是主机或第一个
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.
跳路由器，取决于信令方向。由于这些漏洞，不提供相互认证的TLS模式或部署可被视为处于最佳过渡阶段，而不是提供强健的安全解决方案。
Certain security aspects of GIST operation depend on signalling application behaviour: a poorly implemented or compromised NSLP could degrade GIST security. However, the degradation would only affect GIST handling of the NSLP's own signalling traffic or overall resource usage at the node where the weakness occurred, and implementation weakness or compromise could have just as great an effect within the NSLP itself. GIST depends on NSLPs to choose SIDs appropriately (Section 4.1.3). If NSLPs choose non-random SIDs, this makes off-path attacks based on SID guessing easier to carry out. NSLPs can also leak information in structured SIDs, but they could leak similar information in the NSLP payload data anyway.
GIST操作的某些安全方面取决于信令应用程序行为：实施不当或受损的NSLP可能会降低GIST的安全性。然而，降级只会影响NSLP自身信令业务的GIST处理或出现弱点的节点处的总体资源使用，并且实现弱点或妥协可能在NSLP本身内产生同样大的影响。GIST取决于NSLP适当选择小岛屿发展中国家（第4.1.3节）。如果NSLP选择非随机SID，则基于SID猜测的非路径攻击更容易实施。NSLP也可能泄漏结构化SID中的信息，但无论如何，它们也可能泄漏NSLP有效载荷数据中的类似信息。
This section defines the registries and initial codepoint assignments for GIST. It also defines the procedural requirements to be followed by IANA in allocating new codepoints. Note that the guidelines on the technical criteria to be followed in evaluating requests for new codepoint assignments are covered normatively in a separate document that considers the NSIS protocol suite in a unified way. That document discusses the general issue of NSIS extensibility, as well as the technical criteria for particular registries; see [12] for further details.
本节定义GIST的注册表和初始代码点分配。它还定义了IANA在分配新代码点时应遵循的程序要求。请注意，在评估新代码点分配请求时应遵循的技术标准指南在一份单独的文件中进行了规范性介绍，该文件以统一的方式考虑了NSIS协议套件。该文件讨论了国家统计信息系统可扩展性的一般问题，以及特定登记册的技术标准；有关更多详细信息，请参见[12]。
The registry definitions that follow leave large blocks of codes marked "Reserved". This is to allow a future revision of this specification or another Experimental document to modify the relative space given to different allocation policies, without having to change the initial rules retrospectively if they turn out to have been inappropriate, e.g., if the space for one particular policy is exhausted too quickly.
随后的注册表定义将大块代码标记为“保留”。这是为了允许本规范或其他实验性文件的未来修订修改不同分配策略的相对空间，而不必在初始规则被证明不合适时（例如，如果某一特定策略的空间过快耗尽）追溯更改初始规则。
The allocation policies used in this section follow the guidance given in [4]. In addition, for a number of the GIST registries, this specification also defines private/experimental ranges as discussed in [9]. Note that the only environment in which these codepoints can validly be used is a closed one in which the experimenter knows all the experiments in progress.
本节中使用的分配政策遵循[4]中给出的指导。此外，对于许多GIST注册中心，本规范还定义了[9]中讨论的私有/实验范围。请注意，这些代码点可以有效使用的唯一环境是一个封闭的环境，在这个环境中，实验者知道所有正在进行的实验。
This specification allocates the following codepoints in existing registries:
本规范在现有注册表中分配以下代码点：
Well-known UDP port 270 as the destination port for Q-mode encapsulated GIST messages (Section 5.3).
众所周知的UDP端口270是Q模式封装GIST消息的目标端口（第5.3节）。
This specification creates the following registries with the structures as defined below:
本规范创建具有以下定义结构的以下注册表：
NSLP Identifiers: Each signalling application requires the assignment of one or more NSLPIDs. The following NSLPID is allocated by this specification:
NSLP标识符：每个信令应用程序都需要分配一个或多个NSLPID。本规范分配了以下NSLPID：
+---------+---------------------------------------------------------+
| NSLPID | Application |
+---------+---------------------------------------------------------+
| 0 | Used for GIST messages not related to any signalling |
| | application. |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| NSLPID | Application |
+---------+---------------------------------------------------------+
| 0 | Used for GIST messages not related to any signalling |
| | application. |
+---------+---------------------------------------------------------+
Every other NSLPID that uses an MRM that requires RAO usage MUST be associated with a specific RAO value; multiple NSLPIDs MAY be associated with the same RAO value. RAO value assignments require a specification of the processing associated with messages that carry the value. NSLP specifications MUST normatively depend on this document for the processing, specifically Sections 4.3.1, 4.3.4 and 5.3.2. The NSLPID is a 16-bit integer, and the registration procedure is IESG Aproval. Further values are as follows:
使用需要RAO使用的MRM的每个其他NSLPID必须与特定RAO值相关联；多个NSLPID可能与同一RAO值关联。RAO值分配要求指定与携带该值的消息相关联的处理。NSLP规范必须规范性地依赖于本文件进行处理，特别是第4.3.1、4.3.4和5.3.2节。NSLPID是一个16位整数，注册过程是IESG APPROVAL。其他值如下所示：
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 |
+---------+----------+
+---------+----------+
| 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 |
+---------+-----------------------------+
+---------+-----------------------------+
| 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 |
+------------+------------------------+
+------------+------------------------+
| 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时，规范必须提供第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 |
+---------------------+-----------------------------------------+
+---------------------+-----------------------------------------+
| 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时，将需要一份规范文件。这必须定义定义其配置所需的堆栈配置数据对象中MA协议选项字段（如果有）的格式。如果协议用于可靠的消息传输，则必须说明GIST如何检测传递错误。包括新通道安全协议的扩展必须包括如何将第3.9节中描述的功能与GIST操作的其余部分集成的说明。如果新的MA协议ID可以与现有的协议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:
错误代码/子代码：错误对象的值字段中有2字节错误代码和1字节子代码（附录a.4.1）。附录A.4.4中定义了错误代码1-12以及子代码0-5（代码1）、0-5（代码9）、0-5（代码10）和0-2（代码12）。额外的代码和子代码按照先到先得的原则分配。分配新代码/子代码组合时，必须提供以下信息：
Error case: textual name of error
错误案例：错误的文本名称
Error class: from the categories given in Appendix A.4.3
错误类别：来自附录A.4.3中给出的类别
Error code: allocated by IANA, if a new code is required
错误代码：如果需要新代码，则由IANA分配
Error subcode: subcode point, also allocated by IANA
错误子代码：子代码点，也由IANA分配
Additional information: what Additional Information fields are mandatory to include in the error message, from Appendix A.4.2
附加信息：附录A.4.2中的错误消息中必须包含哪些附加信息字段
Additional Information Types: An Error Object (Appendix A.4.1) may contain Additional Information fields. Each possible field type is identified by a 16-bit AI-Type. AI-Types 1-4 are defined in Appendix A.4.2; additional AI-Types are allocated on a first-come, first-served basis.
附加信息类型：错误对象（附录A.4.1）可能包含附加信息字段。每个可能的字段类型由16位AI类型标识。附录A.4.2中定义了AI类型1-4；额外的人工智能类型以先到先得的方式分配。
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工作组内的讨论。它已从以下人员的先前工作以及正式和非正式投入中获悉：塞德里克·奥恩、阿提拉·贝德、维托·贝纳多、罗兰·布莱斯、鲍勃·布拉登、马库斯·布伦纳、贝诺特·坎佩德尔、吉彦·庄、路易斯·科尔代罗、埃尔温·戴维斯、米歇尔·迪亚兹、克里斯蒂安·迪克曼、帕西·埃隆、艾伦·福特、傅晓明、高波、鲁迪格·盖布、埃莉诺·赫沃斯、托马斯·赫尔佐格、，程红、蒂姆·霍维拉、贾佳、科妮莉亚·卡普勒、乔治亚·卡拉吉安尼斯、路德·克拉弗、马克斯·莱尔、克里斯·朗、劳里·利希托、约翰·洛尼、艾利森·曼金、朱卡·韦德、皮特·麦肯、安德鲁·麦克唐纳、麦克·麦克蒂芬、格伦·莫罗、戴夫·奥兰、安德烈亚斯·帕沙利迪斯、海宁·彼得斯、汤姆·费兰、阿克巴·拉赫曼、高科·桑达、查尔斯·申、梅林达·肖尔、，Martin Stiemerling、Martijn Swanink、Mike Thomas、Hannes Tschofenig、Sven van den Bosch、Nuutti Varis、Michael Welzl、Lars Westberg和Mayi Zoumaro djayoon。TLS使用说明的部分内容（第5.7.3节）源自Diameter基本协议规范RFC 3588。此外，Hannes Tschofenig提供了一组关于安全部分的详细审查意见，Andrew McDonald提供了初始数据包格式和TLS名称匹配算法的正式说明。Chris Lang的实施工作为规范的清晰性和可行性提供了客观反馈，他还提供了状态机描述以及初始错误目录和格式。Magnus Westerlund进行了详细的广告审查，确定了一些问题并进行了重大澄清，随后进行了更详细的IESG审查，Jari Arkko、Ross Callon、Brian Carpenter、Lisa Dusseault、Lars Eggert、Ted Hardie、Sam Hartman、Russ Housley、Cullen发表了评论
Jennings, and Tim Polk, and a very detailed analysis by Adrian Farrel from the Routing Area directorate; Suresh Krishnan carried out a detailed review for the Gen-ART.
Jennings和Tim Polk，以及路由区域董事会的Adrian Farrel所做的非常详细的分析；Suresh Krishnan对Gen ART进行了详细审查。
[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[1] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[4] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[6] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[6] Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[7] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[7] Nordmark，E.，“无状态IP/ICMP转换算法（SIIT）”，RFC 27652000年2月。
[8] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[8] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[9] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[9] Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[10] Dierks，T.和E.Rescorla，“传输层安全（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] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[12] Way，J.，Bless，R.，Loughney，J.，和E.Davies，“使用和扩展NSIS协议系列”，RFC 5978，2010年10月。
[13] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[13] Katz，D.，“IP路由器警报选项”，RFC 2113，1997年2月。
[14] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[14] Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[15] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[16] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[16] Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[17] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[17] 帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[18] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[18] Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[19] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[19] Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[20] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[20] Huitema，C.，“6to4中继路由器的选播前缀”，RFC 3068，2001年6月。
[21] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[21] Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月。
[22] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[22] Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[23] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[23] Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.，和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[24] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[24] Grossman，D.“区分服务的新术语和澄清”，RFC3260，2002年4月。
[25] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
[25] Arkko，J.，Torvinen，V.，Camarillo，G.，Niemi，A.，和T.Haukka，“会话启动协议（SIP）的安全机制协议”，RFC 33292003年1月。
[26] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[26] Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，2008年10月。
[27] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[27] Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（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 56522009年9月。
[29] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[29] Hancock，R.，Karagiannis，G.，Loughney，J.，和S.Van den Bosch，“信号的下一步（NSIS）：框架”，RFC 40802005年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 40812005年6月。
[31] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[31] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年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] Conta，A.，Deering，S.，和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 44432006年3月。
[34] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, April 2010.
[34] Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“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.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[36] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[36] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[37] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[37] Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[38] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[38] Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[39] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[39] Stewart，R.，“流控制传输协议”，RFC 4960，2007年9月。
[40] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[40] Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
[41] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[41] Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[42] Floyd, S. and V. Jacobson, "The Synchronisation of Periodic Routing Messages", SIGCOMM Symposium on Communications Architectures and Protocols pp. 33--44, September 1993.
[42] Floyd，S.和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.，Fu，X.，Aoun，C.，和E.Davies，“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.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，正在进行的工作，2010年5月。
This appendix provides formats for the various component parts of the GIST messages defined abstractly in Section 5.2. The whole of this appendix is normative.
本附录提供了第5.2节中抽象定义的GIST消息各组成部分的格式。本附录全部为规范性附录。
Each GIST message consists of a header and a sequence of objects. The GIST header has a specific format, described in more detail in Appendix A.1 below. An NSLP message is one object within a GIST message. Note that GIST itself provides the NSLP message length information and signalling application identification. General object formatting guidelines are provided in Appendix A.2 below, followed in Appendix A.3 by the format for each object. Finally, Appendix A.4 provides the formats used for error reporting.
每个GIST消息由一个标题和一系列对象组成。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.
在以下对象关系图中，“//”用于指示可变大小的字段，“：”用于指示可选存在的字段。用于填充或定义为保留的对象的任何部分（标记为“保留”或“Rsv”，或者，对于下图中的单个位，“r”），在传输时必须设置为0，在接收时必须忽略。
The objects are encoded using big endian (network byte order).
对象使用big-endian（网络字节顺序）编码。
This header begins all GIST messages. It has a fixed format, as shown below.
此标题以所有GIST消息开头。它有一个固定的格式，如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | GIST hops | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLPID |C| Type |S|R|E| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位）：主要消息类型（查询、响应等）。
S-flag: S=1 if the IP source address is the same as the signalling source address, S=0 if it is different.
S标志：如果IP源地址与信令源地址相同，则S=1；如果不同，则S=0。
R-flag: R=1 if a reply to this message is explicitly requested.
R-flag：如果明确请求回复此消息，则R=1。
E-flag: E=1 if the message was explicitly routed (Section 7.1.5).
E-标志：如果消息明确路由（第7.1.5节），则E=1。
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 Hello中；如果设置，则必须发送另一个MA Hello作为回复。它可以在响应中设置，但如果响应包含响应器Cookie，则必须设置；如果已设置，则必须发送确认回复。除非消息类型为数据消息，否则不得设置电子标志。
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），并且不得进一步处理该消息。
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A/B flags: The bits marked 'A' and 'B' are extensibility flags, which are defined in Appendix A.2.1 below; the remaining bits marked 'r' are reserved.
A/B标志：标记为“A”和“B”的位是可扩展性标志，在下面的附录A.2.1中定义；标记为“r”的其余位保留。
Type (12 bits): An IANA-assigned identifier for the type of object.
类型（12位）：IANA为对象类型分配的标识符。
Length (12 bits): Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. If the Length is not consistent with the contents of the object, an "Object Value Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect Length" MUST be returned and the message dropped.
长度（12位）：长度以32位字为单位，测量值的长度。如果没有值，则长度=0。如果长度与对象内容不一致，则必须返回子代码为0“长度不正确”的“对象值错误”消息（附录A.4.4.10），并删除该消息。
Value (variable): Value is (therefore) a whole number of 32-bit words. If there is any padding required, the length and location are be defined by the object-specific format information; objects that contain variable-length (e.g., string) types may need to include additional length subfields to do so.
值（变量）：值是（因此）32位字的整数。如果需要任何填充，则长度和位置由特定于对象的格式信息定义；包含可变长度（例如字符串）类型的对象可能需要包含额外的长度子字段才能执行此操作。
The leading 2 bits of the TLV header are used to signal the desired treatment for objects whose Type field is unknown at the receiver. The following three categories of objects have been identified and are described here.
TLV报头的前导2位用于向接收端类型字段未知的对象发送所需处理的信号。以下三类物体已被识别，并在此处进行描述。
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的未识别对象不需要向NSLP指示。
Type: Message-Routing-Information
类型：消息路由信息
Length: Variable (depends on MRM)
长度：变量（取决于MRM）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRM-ID |N| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRM-ID |N| Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRM-ID (8 bits): An IANA-assigned identifier for the message routing method.
MRM-ID（8位）：IANA为消息路由方法分配的标识符。
N-flag: If set (N=1), this means that NATs do not need to translate this MRM; if clear (N=0), it means that the method-specific information contains network or transport layer information that a NAT must process.
N-flag：如果设置（N=1），这意味着NAT不需要翻译此MRM；如果清除（N=0），则表示特定于方法的信息包含NAT必须处理的网络或传输层信息。
The remainder of the object contains method-specific addressing information, which is described below.
对象的其余部分包含特定于方法的寻址信息，如下所述。
In the case of basic path-coupled routing, the addressing information takes the following format. The N-flag has a value of 0 for this MRM.
在基本路径耦合路由的情况下，寻址信息采用以下格式。对于此MRM，N标志的值为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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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版本（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.
Source/Dest Prefix（每个8位）：用于地址通配符的源地址和目标地址的掩码长度。在MRI仅指特定主机地址之间的通信量的正常情况下，对于IPv4和IPv6，Source/Dest前缀值将分别为32或128。
P-flag: P=1 means that the Protocol field is significant.
P-flag:P=1表示协议字段有效。
Protocol (8 bits): The IP protocol number. This MUST be ignored if P=0. In the case of IPv6, the Protocol field refers to the true upper layer protocol carried by the packets, i.e., excluding any IP option headers. This is therefore not necessarily the same as the Next Header value from the base IPv6 header.
协议（8位）：IP协议编号。如果P=0，则必须忽略此项。在IPv6的情况下，协议字段指的是数据包携带的真正的上层协议，即不包括任何IP选项头。因此，这不一定与基本IPv6报头的下一个报头值相同。
T-flag: T=1 means that the Diffserv field (DS-field) is significant.
T-flag:T=1表示区分服务字段（DS字段）是有效的。
DS-field (6 bits): The Diffserv field. See [6] and [24].
DS字段（6位）：区分服务字段。见[6]和[24]。
F-flag: F=1 means that flow label is present and is significant. F MUST NOT be set if IP-Ver is not 6.
F-flag:F=1表示流标签存在且意义重大。如果IP版本不是6，则不能设置F。
Flow Label (20 bits): The flow label; only present if F=1. If F=0, the entire 32-bit word containing the Flow Label is absent.
流量标签（20位）：流量标签；仅当F=1时出现。如果F=0，则不存在包含流标签的整个32位字。
S-flag: S=1 means that the SPI field is present and is significant. The S-flag MUST be 0 if the P-flag is 0.
S-flag:S=1表示SPI字段存在且有效。如果P标志为0，则S标志必须为0。
SPI field (32 bits): The SPI field; see [36]. If S=0, the entire 32-bit word containing the SPI is absent.
SPI字段（32位）：SPI字段；见[36]。如果S=0，则不存在包含SPI的整个32位字。
A/B flags: These can only be set if P=1. If either is set, the port fields are also present. The A flag indicates the presence of a source port, the B flag that of a destination port. If P=0, the A/B flags MUST both be zero and the word containing the port numbers is absent.
A/B标志：只有在P=1时才能设置。如果设置了其中一个，则端口字段也存在。A标志表示存在源端口，B标志表示存在目标端口。如果P=0，A/B标志必须同时为零，并且包含端口号的字不存在。
Source/Destination Port (each 16 bits): If either of A (source), B (destination) is set, the word containing the port numbers is included in the object. However, the contents of each field is only significant if the corresponding flag is set; otherwise, the contents of the field is regarded as padding, and the MRI refers to all ports (i.e., acts as a wildcard). If the flag is set and Port=0x0000, the MRI will apply to a specific port, whose value is not yet known. If neither of A or B is set, the word is absent.
源/目标端口（每个16位）：如果设置了A（源）、B（目标）中的任何一个，则包含端口号的字将包含在对象中。然而，每个字段的内容只有在设置了相应的标志时才有意义；否则，字段的内容被视为填充，MRI引用所有端口（即充当通配符）。如果设置了该标志且端口=0x0000，则MRI将应用于特定端口，该端口的值未知。如果A或B均未设置，则该词不存在。
D-flag: The Direction flag has the following meaning: the value 0 means 'in the same direction as the flow' (i.e., downstream), and the value 1 means 'in the opposite direction to the flow' (i.e., upstream).
D-标志：方向标志具有以下含义：值0表示“与流量方向相同”（即下游），值1表示“与流量方向相反”（即上游）。
The MRI format defines a number of constraints on the allowed combinations of flags and fields in the object. If these constraints are violated, this constitutes a parse error, and an "Object Value Error" message (Appendix A.4.4.10) with subcode 2 ("Invalid Flag-Field Combination") MUST be returned.
MRI格式对对象中允许的标志和字段组合定义了许多约束。如果违反这些约束，则构成解析错误，必须返回带有子代码2（“无效标志字段组合”）的“对象值错误”消息（附录a.4.4.10）。
In the case of the loose-end MRM, the addressing information takes the following format. The N-flag has a value of 0 for this MRM.
对于松散端MRM，寻址信息采用以下格式。对于此MRM，N标志的值为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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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版本（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表示“从网络边缘”。请注意，对于Q模式消息，唯一有效的值是D=0（见第5.8.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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Session ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Network-Layer-Information
类型：网络层信息
Length: Variable (depends on length of Peer-Identity and IP version)
长度：变量（取决于对等身份的长度和IP版本）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PI-Length | IP-TTL |IP-Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing State Validity Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Peer Identity //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
对等身份（变量）：对等身份字段。请注意，对等标识字段本身填充为一个完整的单词数。
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版本（4位）：接口地址字段的IP版本。
Interface Address (variable): The IP address allocated to the interface, matching the IP-Ver field.
接口地址（变量）：分配给接口的IP地址，与IP版本字段匹配。
Routing State Validity Time (32 bits): The time for which the routing state for this flow can be considered correct without a refresh. Given in milliseconds. The value 0 (zero) is reserved and MUST NOT be used.
路由状态有效时间（32位）：此流的路由状态在不刷新的情况下被视为正确的时间。以毫秒为单位给出。值0（零）为保留值，不得使用。
Type: Stack-Proposal
类型：堆栈建议
Length: Variable (depends on number of profiles and size of each profile)
长度：可变（取决于外形数量和每个外形的大小）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prof-Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Profile N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prof-Count (8 bits): The number of profiles listed. MUST be > 0.
Prof Count（8位）：列出的配置文件数。必须大于0。
Each profile is itself a sequence of protocol layers, and the profile is formatted as a list as follows:
每个配置文件本身就是一系列协议层，配置文件的格式如下所示：
o The first byte is a count of the number of layers in the profile. MUST be > 0.
o 第一个字节是配置文件中层数的计数。必须大于0。
o This is followed by a sequence of 1-byte MA-Protocol-IDs as described in Section 5.7.
o 随后是一系列1字节MA协议ID，如第5.7节所述。
o The profile is padded to a word boundary with 0, 1, 2, or 3 zero bytes. These bytes MUST be ignored at the receiver.
o 配置文件被填充到具有0、1、2或3个零字节的字边界。必须在接收器处忽略这些字节。
If there are no profiles (Prof-Count=0), then an "Object Value Error" message (Appendix A.4.4.10) with subcode 1 ("Value Not Supported") MUST be returned; if a particular profile is empty (the leading byte of the profile is zero), then subcode 3 ("Empty List") MUST be used. In both cases, the message MUST be dropped.
如果没有配置文件（Prof Count=0），则必须返回带有子代码1（“不支持值”）的“对象值错误”消息（附录A.4.4.10）；如果特定配置文件为空（配置文件的前导字节为零），则必须使用子代码3（“空列表”）。在这两种情况下，都必须删除消息。
Type: Stack-Configuration-Data
类型：堆栈配置数据
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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计数可能为零，但只有在堆栈方案中提到的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位）：消息关联在没有流量或hello消息的情况下保持打开的时间。请注意，该值以毫秒为单位，因此默认时间30秒（第4.4.5节）对应的值为30000。值0（零）为保留值，不得使用。
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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'.
Profile（8位）：标记，指示此应用于随附堆栈建议对象中的哪个概要文件。剖面从1向上编号；特殊值0表示“适用于所有配置文件”。
Length (8 bits): The byte length of MA-protocol-options field that follows. This will be zero-padded up to the next word boundary.
长度（8位）：后面MA协议选项字段的字节长度。这将被零填充到下一个单词边界。
D-flag: If set (D=1), this protocol MUST NOT be used for a messaging association.
D-flag：如果设置（D=1），则此协议不得用于消息关联。
Options Data (variable): Any options data for this protocol. Note that the format of the options data might differ depending on whether the field is in a Query or Response.
选项数据（变量）：此协议的任何选项数据。请注意，选项数据的格式可能会有所不同，这取决于字段是在查询中还是在响应中。
Type: Query-Cookie
类型：查询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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Query-Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is defined by the implementation. See Section 8.5 for further discussion.
内容由实现定义。进一步讨论见第8.5节。
Type: Responder-Cookie
类型：响应器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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Responder-Cookie //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is defined by the implementation. See Section 8.5 for further discussion.
内容由实现定义。进一步讨论见第8.5节。
Type: Hello-ID
类型：你好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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content is defined by the implementation. See Section 5.2.2 for further discussion.
内容由实现定义。进一步讨论见第5.2.2节。
Type: NAT-Traversal
类型：NAT遍历
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位）：包含的MRI有效负载的长度，以32位字表示。
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所翻译的对象类型。列表中的每个元素是一个16位字段，包含对象TLV头的前16位，包括AB扩展性标志、2个保留位和12位对象类型。列表由路径上的第一个NAT初始化；后续NAT可能会删除列表中的元素。如有必要，用2个空字节填充。
NAT-Count (8 bits): The number of NATs traversed by the message, and the number of opaque payloads at the end of the object. The length fields for each opaque payload are byte counts, not including the 2 bytes of the length field itself. Note that each opaque information field is zero-padded to the next 32-bit word boundary if necessary.
NAT计数（8位）：消息遍历的NAT数，以及对象末尾的不透明有效负载数。每个不透明负载的长度字段都是字节计数，不包括长度字段本身的2个字节。请注意，如有必要，每个不透明信息字段将被零填充到下一个32位字边界。
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.
此对象用于在NSLP之间传递数据。GIST将数据视为TLV中长度字段给出的完整32位字的数量；对单词边界的任何填充都必须在NSLP本身内执行。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NSLP Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NSLP Data //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Error
类型：错误
Length: Variable (depends on error)
长度：变量（取决于错误）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Class | Error Code | Error Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|M|C|D|Q| Reserved | MRI Length | Info Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Common Header +
| (of original message) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Session ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Routing Information :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Additional Information Fields :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Debugging Comment :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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表示原始消息是以Q模式接收的（如果D=0，则无法设置）。
A GIST Error Object contains an 8-bit error-class (see Appendix A.4.3), a 16-bit error-code, an 8-bit error-subcode, and as much information about the message that triggered the error as is available. This information MUST include the common header of the original message and MUST also include the Session ID and MRI objects if these could be decoded correctly. These objects are included in their entirety, except for their TLV Headers. The MRI Length field gives the length of the MRI object in 32-bit words.
GIST错误对象包含一个8位错误类（见附录A.4.3）、一个16位错误代码、一个8位错误子代码，以及关于触发错误的消息的尽可能多的可用信息。此信息必须包括原始消息的公共标头，如果可以正确解码，还必须包括会话ID和MRI对象。这些对象包括在它们的整体中，除了它们的TLV头。MRI长度字段以32位字表示MRI对象的长度。
The Info Count field contains the number of Additional Information fields in the object, and the possible formats for these fields are given in Appendix A.4.2. The precise set of fields to include depends on the error code/subcode. For every error description in the error catalogue Appendix A.4.4, the line "Additional Info:" states what fields MUST be included; further fields beyond these MAY be included by the sender, and the fields may be included in any order. The Debugging Comment is a null-terminated UTF-8 string, padded if necessary to a whole number of 32-bit words with more null characters.
Info Count字段包含对象中附加信息字段的数量，这些字段的可能格式见附录A.4.2。要包含的精确字段集取决于错误代码/子代码。对于错误目录附录A.4.4中的每个错误描述，“附加信息：”行说明必须包括哪些字段；发送方可以包括这些字段之外的其他字段，并且这些字段可以按任何顺序包括。调试注释是以null结尾的UTF-8字符串，如有必要，可填充为包含更多null字符的32位字的整数。
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 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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长度给出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.
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.
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.
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)
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.
偏移量（16位）：GIST节点发现错误的对象中的字节。对象中的第一个字节的偏移量为0。
Object (variable): The invalid TLV object (including the TLV header).
对象（变量）：无效的TLV对象（包括TLV标头）。
The first byte of the Error Object, "Error Class", indicates the severity level. The currently defined severity levels are:
错误对象的第一个字节“Error Class”表示严重性级别。当前定义的严重性级别为：
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).
The allocation of error classes to particular errors is not precise;
the above descriptions are deliberately informal. Actual error
processing SHOULD take into account the specific error in question;
the error class may be useful supporting information (e.g., in
network debugging).
This section lists all the possible GIST errors, including when they are raised and what Additional Information fields MUST be carried in the Error Object.
本节列出了所有可能的GIST错误，包括何时出现错误以及错误对象中必须包含哪些附加信息字段。
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：无效电子标志：在标头中设置了电子标志，但这不是数据消息。
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模式数据消息以外的其他消息上，或者在查询消息上清除。
Class: Permanent-Failure Code: 2 Additional Info: None
类别：永久性故障代码：2其他信息：无
This message is sent if a GIST node receives a message with a GIST hop count of zero, or a GIST node tries to forward a message after its GIST hop count has been decremented to zero on reception. This message indicates either a routing loop or too small an initial hop count value.
如果GIST节点接收到GIST跃点计数为零的消息，或者GIST节点在接收时将GIST跃点计数减为零后尝试转发消息，则发送此消息。此消息表示路由循环或初始跃点计数值太小。
Class: Protocol-Error Code: 3 Additional Info: None
类别：协议错误代码：3其他信息：无
This message is sent if a GIST node receives a message that uses an incorrect encapsulation method (e.g., a Query arrives over an MA, or the Confirm for a handshake that sets up a messaging association arrives in D-mode).
如果GIST节点接收到使用错误封装方法的消息（例如，通过MA到达查询，或者设置消息关联的握手确认以D模式到达），则发送此消息。
Class: Protocol-Error Code: 4 Additional Info: None
类别：协议错误代码：4其他信息：无
This message is sent if a GIST node receives a message over an MA that is not associated with the MRI/NSLPID/SID combination in the message.
如果GIST节点通过MA接收到与消息中的MRI/NSLPID/SID组合不相关的消息，则发送此消息。
Class: Protocol-Error Code: 5 Additional Info: None
类别：协议错误代码：5其他信息：无
This message is sent if a node receives a message for which routing state should exist, but has not yet been created and thus there is no appropriate Querying-SM or Responding-SM. This can occur on receiving a Data or Confirm message at a node whose policy requires routing state to exist before such messages can be accepted. See also Section 6.1 and Section 6.3.
如果节点接收到路由状态应该存在但尚未创建的消息，因此没有适当的查询SM或响应SM，则会发送此消息。这可能发生在节点接收数据或确认消息时，该节点的策略要求在接受此类消息之前存在路由状态。另见第6.1节和第6.3节。
Class: Permanent-Failure Code: 6 Additional Info: None
类别：永久性故障代码：6其他信息：无
This message is sent if a router receives a directly addressed message for an NSLP that it does not support.
如果路由器收到其不支持的NSLP的直接寻址消息，则发送此消息。
Class: Permanent-Failure Code: 7 Additional Info: None
类别：永久性故障代码：7其他信息：无
This message is sent if a GIST node at a flow endpoint receives a Query message for an NSLP that it does not support.
如果流端点处的GIST节点接收到不支持的NSLP查询消息，则会发送此消息。
Class: Permanent-Failure Code: 8 Additional Info: MTU Info
类别：永久性故障代码：8附加信息：MTU信息
This message is sent if a router receives a message that it can't forward because it exceeds the IP MTU on the next or subsequent hops.
如果路由器收到无法转发的消息，则会发送此消息，因为它在下一个或后续跃点上超过了IP MTU。
Class: Protocol-Error Code: 9 Additional Info: Object Type Info
类别：协议错误代码：9其他信息：对象类型信息
This message is sent if a GIST node receives a message containing a TLV object with an invalid type. The message indicates the object type at fault in the additional info field. This error code is split into subcodes as follows:
如果GIST节点接收到包含类型无效的TLV对象的消息，则会发送此消息。该消息在附加信息字段中指示出现故障的对象类型。此错误代码分为以下子代码：
0: Duplicate Object: This subcode is used if a GIST node receives a message containing multiple instances of an object that may only appear once in a message. In the current specification, this applies to all objects.
0:复制对象：如果GIST节点接收到包含一个对象的多个实例的消息，并且该对象在消息中只能出现一次，则使用此子代码。在当前规范中，这适用于所有对象。
1: 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节点接收到缺少一个或多个必需对象的消息，则使用此子代码。如果发送堆栈建议时没有匹配的堆栈配置数据对象（必要时），也会发送此消息，反之亦然。
3: Invalid Object Type: This subcode is used if the object type is known, but it is not valid for this particular GIST message type.
3：无效的对象类型：如果对象类型已知，则使用此子代码，但对于此特定GIST消息类型无效。
4: Untranslated Object: This subcode is used if the object type is known and is mandatory to interpret, but it contains addressing data that has not been translated by an intervening NAT.
4：未翻译对象：如果对象类型已知且必须解释，但它包含未被中间NAT翻译的寻址数据，则使用此子代码。
5: Invalid Extensibility Flags: This subcode is used if an object is received with the extensibility flags AB=11.
5：扩展性标志无效：如果接收到扩展性标志AB=11的对象，则使用此子代码。
Class: Protocol-Error Code: 10 Additional Info: 1 or 2 Object Value Info fields as given below
类别：协议错误代码：10个附加信息：1或2个对象值信息字段，如下所示
This message is sent if a node receives a message containing an object that cannot be properly parsed. The error message contains a single Object Value Info object, except for subcode 5 as stated below. This error code is split into subcodes as follows:
如果节点接收到包含无法正确解析的对象的消息，则会发送此消息。错误消息包含单个对象值Info对象，子代码5除外，如下所述。此错误代码分为以下子代码：
0: Incorrect Length: The overall length does not match the object length calculated from the object contents.
0:长度不正确：总长度与根据对象内容计算的对象长度不匹配。
1: Value Not Supported: The value of a field is not supported by the GIST node.
1：不支持值：GIST节点不支持字段的值。
2: Invalid Flag-Field Combination: An object contains an invalid combination of flags and/or fields. At the moment, this only relates to the Path-Coupled MRI (Appendix A.3.1.1), but in future there may be more.
2：无效的标志字段组合：对象包含无效的标志和/或字段组合。目前，这仅与路径耦合MRI有关（附录A.3.1.1），但将来可能会有更多。
3: Empty List: At the moment, this only relates to Stack-Proposals. The error message is sent if a stack proposal with a length > 0 contains only null bytes (a length of 0 is handled as "Value Not Supported").
3：空列表：目前，这仅与堆栈建议相关。如果长度>0的堆栈建议仅包含空字节（长度为0被处理为“值不受支持”），则会发送错误消息。
4: Invalid Cookie: The message contains a cookie that could not be verified by the node.
4:无效Cookie:消息包含节点无法验证的Cookie。
5: Stack-Proposal - Stack-Configuration-Data Mismatch: This subcode is used if a GIST node receives a message in which the data in the Stack-Proposal object is inconsistent with the information in the Stack Configuration Data object. In this case, both the Stack-Proposal object and Stack-Configuration-Data object MUST be included in separate Object Value Info fields in that order.
5：堆栈建议-堆栈配置数据不匹配：如果GIST节点接收到堆栈建议对象中的数据与堆栈配置数据对象中的信息不一致的消息，则使用此子代码。在这种情况下，堆栈建议对象和堆栈配置数据对象必须按顺序包含在单独的对象值信息字段中。
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.
此错误表示接收到的消息的IP层TTL超出可接受范围，例如，接收到的上游查询的IP层TTL小于254（即，来自发送方的多个IP跃点）。实际IP距离可以从同一消息中携带的NLI对象中的IP-TTL信息中导出。
Class: Permanent-Failure Code: 12 Additional Info: Object Value Info
类别：永久性故障代码：12附加信息：对象值信息
This error indicates that a message was received with an MRI that could not be accepted, e.g., because of too much wildcarding or failing some validation check (cf. Section 5.8.1.2). The Object Value Info includes the MRI so the error originator can indicate the part of the MRI that caused the problem. The error code is divided into subcodes as follows:
此错误表示接收到的MRI信息无法接受，例如，由于通配符过多或验证检查失败（参见第5.8.1.2节）。对象值信息包括MRI，因此错误发起人可以指出导致问题的MRI部分。错误代码分为以下子代码：
0: MRI Too Wild: The MRI contained too much wildcarding (e.g., too short a destination address prefix) to be forwarded correctly down a single path.
0:MRI太宽：MRI包含太多通配符（例如，目标地址前缀太短），无法沿单个路径正确转发。
1: IP Version Mismatch: The MRI in a path-coupled Query message refers to an IP version that is not implemented on the interface used, or is different from the IP version of the Query encapsulation (see Section 7.4).
1：IP版本不匹配：路径耦合查询消息中的MRI指的是未在所用接口上实现的IP版本，或与查询封装的IP版本不同（参见第7.4节）。
2: Ingress Filter Failure: The MRI in a path-coupled Query message describes a flow that would not pass ingress filtering on the interface used.
2：入口过滤器故障：路径耦合查询消息中的MRI描述了无法通过所用接口上入口过滤的流。
This appendix provides an abstract API between GIST and signalling applications. It should not constrain implementers, but rather help clarify the interface between the different layers of the NSIS protocol suite. In addition, although some of the data types carry the information from GIST information elements, this does not imply that the format of that data as sent over the API has to be the same.
本附录提供GIST和信令应用程序之间的抽象API。它不应该约束实现者，而应该帮助澄清NSIS协议套件不同层之间的接口。此外，尽管某些数据类型携带来自GIST信息元素的信息，但这并不意味着通过API发送的数据的格式必须相同。
Conceptually, the API has similarities to the sockets API, particularly that for unconnected UDP sockets. An extension for an API like that for UDP connected sockets could be considered. In this case, for example, the only information needed in a SendMessage primitive would be NSLP-Data, NSLP-Data-Size, and NSLP-Message-Handle (which can be null). Other information that was persistent for a group of messages could be configured once for the socket. Such extensions may make a concrete implementation more efficient but do not change the API semantics, and so are not considered further here.
从概念上讲，该API与套接字API相似，特别是对于未连接的UDP套接字。可以考虑对类似UDP连接套接字的API进行扩展。例如，在这种情况下，SendMessage原语中需要的唯一信息是NSLP数据、NSLP数据大小和NSLP消息句柄（可以为null）。对于一组消息，其他持久的信息可以为套接字配置一次。这样的扩展可以使具体的实现更加高效，但不会改变API语义，因此这里不再进一步讨论。
This primitive is passed from a signalling application to GIST. It is used whenever the signalling application wants to initiate sending a message.
此原语从信令应用程序传递到GIST。每当信令应用程序想要开始发送消息时，就使用它。
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, NSLPID, Session-ID, MRI, SII-Handle, Transfer-Attributes, Timeout, IP-TTL, GIST-Hop-Count )
SendMessage（NSLP数据、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消息句柄：GIST可将此消息的句柄用作后续消息状态通知中的参考（附录B.3）。通知可能与错误条件有关，也可能与将用于消息的安全属性有关。如果NSLP对此类通知不感兴趣，则可以提供空句柄。
NSLPID: An identifier indicating which NSLP this is.
NSLPID：一个标识符，指示这是哪个NSLP。
Session-ID: The NSIS session identifier. Note that it is assumed that the signalling application provides this to GIST rather than GIST providing a value itself.
会话ID：NSIS会话标识符。注意，假设信令应用程序向GIST提供该值，而不是GIST本身提供值。
MRI: Message routing information for use by GIST in determining the correct next GIST hop for this message. The MRI implies the message routing method to be used and the message direction.
MRI：GIST用于确定此消息的正确下一个GIST跃点的消息路由信息。MRI表示要使用的消息路由方法和消息方向。
The following arguments are optional:
以下参数是可选的：
SII-Handle: A handle, previously supplied by GIST, to a data structure that should be used to route the message explicitly to a particular GIST next hop.
SII句柄：以前由GIST提供的数据结构句柄，用于将消息显式路由到特定GIST下一跳。
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或RecVMMessage通知中了解这些可能性。如果提供了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 Hop Count：发送消息时的跃点计数值。
This primitive is passed from GIST to a signalling application. It is used whenever GIST receives a message from the network, including the case of null messages (zero-length NSLP payload), typically initial Query messages. For Queries, the results of invoking this primitive are used by GIST to check whether message routing state should be created (see the discussion of the 'Routing-State-Check' argument below).
该原语从GIST传递到信令应用程序。只要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 )
RecVMMessage（NSLP数据、NSLP数据大小、NSLPID、会话ID、MRI、路由状态检查、SII句柄、传输属性、IP-TTL、IP距离、GIST跳数、入站接口）
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:
路由状态检查：如果GIST正在与信令应用程序进行检查，以确定是否应与对等方一起创建路由状态或是否应进一步转发消息，则此布尔值为真（见第4.3.2节）。如果为True，则信令应用程序应通过RecVMMessage调用返回以下值：
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句柄：数据结构的句柄，标识对等地址和接口。可用于识别路由更改，并用于显式路由到特定的下一跳。
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:
传输属性：与接收此特定消息相关的可靠性和安全属性。GIST以及与SendMessage相关联的属性可以指示MRI中地址的验证级别。可以指出三个属性：
* Whether the signalling source address is one of the flow endpoints (i.e., whether this is the first or last GIST hop).
* 信令源地址是否为流端点之一（即，这是第一跳还是最后一跳）。
* 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的内部还是外部。这些属性仅具有局部意义，由实现定义。
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'.
错误类型：指示发生的错误类型，例如，“未找到下一个节点”。
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 )
网络通知（NSLPID、MRI、网络通知类型）
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:
网络通知类型：指示导致通知和相关附加数据的事件类型。已查明五个事件：
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句柄，如RecVMMessage。
Route Deletion: GIST has determined that an old route is now definitely invalid, e.g., that flows are definitely not using it (see Section 7.1.4). The SII-Handle of the peer is also reported.
路由删除：GIST已确定旧路由现在肯定无效，例如，流肯定不使用它（参见第7.1.4节）。还报告对等方的SII句柄。
Node Authorisation Change: The authorisation status of a peer has changed, meaning that routing state is no longer valid or that a signalling peer is no longer reachable; see Section 4.4.2.
节点授权更改：对等方的授权状态已更改，这意味着路由状态不再有效或信令对等方不再可访问；见第4.4.2节。
Communication Failure: Communication with the peer has failed; messages may have been lost.
通信失败：与对等方的通信失败；消息可能已丢失。
This primitive is passed from a signalling application to GIST. It indicates the duration for which the signalling application would like GIST to retain its routing state. It can also give a hint that the signalling application is no longer interested in the state.
此原语从信令应用程序传递到GIST。它指示信令应用程序希望保留其路由状态的持续时间。它还可以提示信令应用程序不再对状态感兴趣。
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状态没有进一步的兴趣）。
This primitive is passed from a signalling application to GIST. It indicates that the signalling application has knowledge that the next signalling hop known to GIST may no longer be valid, either because of changes in the network routing or the processing capabilities of signalling application nodes. See Section 7.1.
此原语从信令应用程序传递到GIST。它表示信令应用程序知道GIST已知的下一个信令跳可能不再有效，这可能是由于网络路由或信令应用程序节点的处理能力的改变。见第7.1节。
InvalidateRoutingState ( NSLPID, MRI, Status, NSLP-Data, NSLP-Data-Size, Urgent )
InvalidateRoutingState（NSLPID、MRI、状态、NSLP数据、NSLP数据大小、紧急）
NSLPID: The NSLP originating the message. May be null (in which case, the invalidation applies to all signalling applications).
NSLPID：发起消息的NSLP。可能为空（在这种情况下，无效适用于所有信令应用）。
MRI: The flow for which routing state should be invalidated; includes the direction of the change (in the D-flag).
MRI：路由状态应无效的流；包括更改的方向（在D标志中）。
Status: The new status that should be assumed for the routing state, one of Bad or Tentative (see Section 7.1.3).
状态：应为路由状态假定的新状态，为坏状态或暂定状态之一（见第7.1.3节）。
NSLP-Data, NSLP-Data-Size: (optional) A payload provided by the NSLP to be used the next GIST handshake. This can be used as part of a conditional peering process (see Section 4.3.2). The payload will be transmitted without security protection.
NSLP数据，NSLP数据大小：（可选）NSLP提供的用于下一次GIST握手的有效负载。这可以用作条件对等过程的一部分（见第4.3.2节）。有效载荷将在没有安全保护的情况下传输。
Urgent: A hint as to whether rediscovery should take place immediately or only with the next signalling message.
紧急：提示是否应立即进行重新发现，或仅在发出下一条信号消息时进行。
The GIST peer discovery handshake (Section 4.4.1) depends on the interception of Q-mode encapsulated IP packets (Section 4.3.1 and Section 5.3.2) by routers. There are two fundamental requirements on the process:
GIST对等发现握手（第4.4.1节）取决于路由器拦截Q模式封装的IP数据包（第4.3.1节和第5.3.2节）。该过程有两个基本要求：
1. Packets relevant to GIST must be intercepted.
1. 必须截获与GIST相关的数据包。
2. Packets not relevant to GIST must be forwarded transparently.
2. 与GIST无关的数据包必须透明地转发。
This specification defines the GIST behaviour to ensure that both requirements are met for a GIST-capable node. However, GIST packets will also encounter non-GIST nodes, for which requirement (2) still applies. If non-GIST nodes block Q-mode packets, GIST will not function. It is always possible for middleboxes to block specific traffic types; by using a normal UDP encapsulation for Q-mode traffic, GIST allows NATs at least to pass these messages (Section 7.2.1), and firewalls can be configured with standard policies. However, where the Q-mode encapsulation uses a Router Alert Option (RAO) at the IP level this can lead to additional problems. The situation is different for IPv4 and IPv6.
本规范定义了GIST行为，以确保能够使用GIST的节点满足这两个要求。然而，GIST数据包也会遇到非GIST节点，这一要求（2）仍然适用。如果非GIST节点阻塞Q模式数据包，GIST将不起作用。中间箱始终可以阻止特定的交通类型；通过对Q模式流量使用普通UDP封装，GIST允许NAT至少传递这些消息（第7.2.1节），并且可以使用标准策略配置防火墙。但是，如果Q模式封装在IP级别使用路由器警报选项（RAO），则可能会导致其他问题。IPv4和IPv6的情况不同。
The IPv4 RAO is defined by [13], which defines the RAO format with a 2-byte value field; however, only one value (zero) is defined and there is no IANA registry for further allocations. It states that unknown values should be ignored (i.e., the packets forwarded as normal IP traffic); however, it has also been reported that some existing implementations simply ignore the RAO value completely (i.e. process any packet with an RAO as though the option value was zero). Therefore, the use of non-zero RAO values cannot be relied on to make GIST traffic transparent to existing implementations. (Note that it may still be valuable to be able to allocate non-zero RAO values for IPv4: this makes the interception process more efficient for nodes that do examine the value field, and makes no difference to nodes that *incorrectly* ignore it. Whether or not non-zero RAO values are used does not change the GIST protocol operation, but needs to be decided when new NSLPs are registered.)
IPv4 RAO由[13]定义，它使用一个2字节的值字段定义RAO格式；但是，只定义了一个值（零），并且没有用于进一步分配的IANA注册表。它表示应忽略未知值（即，作为正常IP流量转发的数据包）；然而，也有报道称，一些现有实现完全忽略RAO值（即，使用RAO处理任何数据包，就好像选项值为零一样）。因此，不能依靠使用非零RAO值来使GIST流量对现有实现透明。（请注意，能够为IPv4分配非零RAO值可能仍然很有价值：对于检查值字段的节点，这会使拦截过程更有效，对于*错误*忽略值字段的节点，这一点没有区别。是否使用非零RAO值不会改变GIST协议操作，但需要e在注册新NSLP时决定。）
The second stage of the analysis is therefore what happens when a non-GIST node that implements RAO handling sees a Q-mode packet. The RAO specification simply states "Routers that recognize this option shall examine packets carrying it more closely (check the IP Protocol
因此，分析的第二阶段是当实现RAO处理的非GIST节点看到Q模式数据包时发生的情况。RAO规范仅规定“识别该选项的路由器应更仔细地检查携带该选项的数据包（检查IP协议）
field, for example) to determine whether or not further processing is necessary". There are two possible basic behaviours for GIST traffic:
字段），以确定是否需要进一步处理”。GIST流量有两种可能的基本行为：
1. The "closer examination" of the packet is sufficiently intelligent to realise that the node does not need to process it and should forward it. This could either be by virtue of the fact that the node has not been configured to match IP-Protocol=UDP for RAO packets at all or that even if UDP traffic is intercepted the port numbers do not match anything locally configured.
1. 对数据包的“更仔细的检查”是足够智能的，可以意识到节点不需要处理它，而应该转发它。这可能是由于节点根本没有配置为匹配RAO数据包的IP Protocol=UDP，或者即使截获UDP通信，端口号也与本地配置的任何内容不匹配。
2. The "closer examination" of the packet identifies it as UDP, and delivers it to the UDP stack on the node. In this case, it can no longer be guaranteed to be processed appropriately. Most likely, it will simply be dropped or rejected with an ICMP error (because there is no GIST process on the destination port to which to deliver it).
2. 对数据包的“仔细检查”将其标识为UDP，并将其发送到节点上的UDP堆栈。在这种情况下，无法再保证对其进行适当处理。最有可能的情况是，它将被丢弃或拒绝，并出现ICMP错误（因为在要将其传递到的目标端口上没有GIST进程）。
Analysis of open-source operating system source code shows the first type of behaviour, and this has also been seen in direct GIST experiments with commercial routers, including the case when they process other uses of the RAO (i.e., RSVP). However, it has also been reported that other RAO implementations will exhibit the second type of behaviour. The consequence of this would be that Q-mode packets are blocked in the network and GIST could not be used. Note that although this is caused by some subtle details in the RAO processing rules, the end result is the same as if the packet was simply blocked for other reasons (for example, many IPv4 firewalls drop packets with options by default).
对开放源代码操作系统源代码的分析显示了第一种行为，在商业路由器的直接GIST实验中也看到了这一点，包括它们处理RAO的其他用途（即RSVP）的情况。然而，也有报道称，其他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模式流量的节点。是否使用这些选项取决于实现和配置选择。
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节点可以被配置为发送Q模式分组，而根本不需要RAO。这应该可以避免上述问题，但只有在已知到接收器的路径上的节点能够截获此类数据包时，才应该这样做。（见第5.3.2.1节。）
o If a GIST node can identify exactly where the packets are being blocked (e.g., from ICMP messages), or can discover some point on the path beyond the blockage (e.g., by use of traceroute or by routing table analysis), it can send the Q-mode messages to that point using IP-in-IP tunelling without any RAO. This bypasses the input side processing on the blocking node, but picks up normal GIST behaviour beyond it.
o 如果GIST节点能够准确地识别数据包被阻塞的位置（例如，来自ICMP消息），或者能够发现阻塞之外路径上的某个点（例如，通过使用跟踪路由或路由表分析），那么它可以使用IP in IP调谐将Q模式消息发送到该点，而无需任何RAO。这会绕过阻塞节点上的输入端处理，但会拾取超出它的正常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.
IPv6的情况大不相同，因为在这种情况下，规范（[17]）中明确规定了使用非零RAO值，并且存在IANA注册表。主要的问题是，一些实现仍然不成熟：例如，一些实现将任何RAO标记的数据包当作本地处理，而不进行进一步的分析。由于这阻止了在这样的网络中使用任何RAO（包括现有的标准化RAO），因此可以合理地假设，这些实现将作为IPv6总体部署的一部分进行固定。
Figure 11 shows a signalling scenario for a single flow being managed by two signalling applications using the path-coupled message routing method. The flow sender and receiver and one router support both; two other routers support one each. The figure also shows the routing state table at node B.
图11显示了使用路径耦合消息路由方法由两个信令应用程序管理的单个流的信令场景。流发送器和接收器以及一个路由器都支持这两种功能；另外两个路由器各支持一个。该图还显示了节点B处的路由状态表。
A B C D E
+------+ +-----+ +-----+ +-----+ +--------+
| Flow | +-+ +-+ |NSLP1| |NSLP1| | | | Flow |
|Sender|====|R|====|R|====|NSLP2|====| |====|NSLP2|====|Receiver|
| | +-+ +-+ |GIST | |GIST | |GIST | | |
+------+ +-----+ +-----+ +-----+ +--------+
Flow Direction ------------------------------>>
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 |
+------------------------------------+---------+--------+-----------+
+------------------------------------+---------+--------+-----------+
| Message Routing Information | Session | NSLPID | Routing |
| | ID | | State |
+------------------------------------+---------+--------+-----------+
| MRM = Path-Coupled; Flow ID = | 0xABCD | NSLP1 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0xABCD | NSLP1 | (null) |
| {IP-A, IP-E, proto/ports}; D=down | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0x1234 | NSLP2 | IP-A |
| {IP-A, IP-E, proto/ports}; D=up | | | |
| | | | |
| MRM = Path-Coupled; Flow ID = | 0x1234 | NSLP2 | Points to |
| {IP-A, IP-E, proto/ports}; D=down | | | B-D MA |
+------------------------------------+---------+--------+-----------+
Figure 11: A Signalling Scenario
图11：信令场景
The upstream state is just the same address for each application. For the downstream direction, NSLP1 only requires D-mode messages and so no explicit routing state towards C is needed. NSLP2 requires a messaging association for its messages towards node D, and node C does not process NSLP2 at all, so the peer state for NSLP2 is a pointer to a messaging association that runs directly from B to D. Note that E is not visible in the state table (except implicitly in the address in the message routing information); routing state is stored only for adjacent peers. (In addition to the peer identification, IP hop counts are stored for each peer where the state itself if not null; this is not shown in the table.)
上游状态对于每个应用程序都是相同的地址。对于下游方向，NSLP1只需要D模式消息，因此不需要指向C的显式路由状态。NSLP2需要为其指向节点D的消息建立消息关联，而节点C根本不处理NSLP2，因此NSLP2的对等状态是指向直接从B到D运行的消息关联的指针。请注意，E在状态表中不可见（消息路由信息中的地址隐式除外）；路由状态仅为相邻对等方存储。（除了对等标识外，还为每个状态本身不为null的对等方存储IP跃点计数；此表中未显示。）
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显示了GIST握手，为B-D信令建立消息关联，在每个方向交换堆栈建议和MA协议选项。查询节点选择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)))
-------------------------- 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)))
<---------------------- 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----------------------->
-------------------------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))
------------------------ 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号
Phone: +1 212 939 7042
EMail: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7042
EMail: hgs+nsis@cs.columbia.edu
URI: http://www.cs.columbia.edu
Robert Hancock Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
Robert Hancock Roke Manor Research Old Salisbury Lane Romsey，英国汉普郡SO51 0ZN
EMail: robert.hancock@roke.co.uk
URI: http://www.roke.co.uk
EMail: robert.hancock@roke.co.uk
URI: http://www.roke.co.uk